Differentiated Services and Integrated Services Use of MPLS

Transcription

1 Differentiated Services and Integrated Services Use of Eric Horlait University Pierre et Marie Curie France Nicolas Rouhana University Saint-Joseph Lebanon Abstract All the new emerging QoS service architectures are motivated by the desire to improve the overall performance of an IP network. The Integrated Services (Intserv) architecture provides means for the delivery of end-to-end QoS to applications over heterogeneous networks. Differentiated Services (Diffserv) define a model for implementing scalable differentiation of QoS in the Internet. Multiprotocol Label Switching () is a fast label-based switching technique that offers new QoS capabilities for large scale IP networks. Traffic Engineering, the ability of network operators to dictate path that traffic takes through their network, is an example of a key application where is a very useful tool superior to any currently available IP technology. also aims to support the QoS models that are available for IP, such as Integrated Services and Differentiated Services. In this paper, we propose a service architecture where part of the underlying technology used for IP transport is using Diffserv-like mechanisms and constraintbased routing for traffic engineering. We also illustrate how this transport architecture can be used and benefited from to support end-to-end service deliveries for both Diffserv and Intserv neighboring networks. 1. Introduction At present, the market is rapidly demanding the development of QoS solutions that address the needs of the Internet as well as enterprise networks to facilitate deployment of various multimedia applications such as IP-telephony, video-on-demand, and various nonmultimedia but mission-critical applications. Hence, in the past several years, works on QoS enabled networks at the Internet Engineering Task Force (IETF) first proposed the Integrated Services (Intserv) architecture [1] with the RSVP signaling protocol [2] that applications used for setting up paths and reserving resources towards receivers before sending data. However, the reliance of RSVP on end-to-end per-flow state and per-flow processing in every node was the major drawback against its large-scale deployment because of scalability concerns in large networks [3]. This led the IETF to develop the Differentiated Services (Diffserv) architecture [4], which classify packets into a small number of aggregated flows or classes, based on the DiffServ CodePoint (DSCP) in the packet's IP header [5] which invokes a per-hop behavior (PHB) at each Diffserv router for specific forwarding treatment. The amount of state information at each node is reduced to the number of classes rather than the number of flows, and functions such as classification, marking and policing are only needed at the edge nodes of the network while core nodes need only to have PHB classification. This yields in much more scalability than integrated services. Multiprotocol Label Switching () [6][21] is a label switching technique where packets are assigned a label as they enter an network, and all subsequent packet treatment within the network is based on that label only. was originally presented as a way of improving the forwarding speed of routers, but is now emerging as a crucial standard technology that offers new capabilities for large-scale IP networks. Constraint-based routing, the ability to compute routes subject to multiple constraints such as bandwidth or delay requirement, is an important tool used by for arranging how traffic flows through the network and improve the utilization of the network. In that respect, Intserv/RSVP, Diffserv, and constraint-based routing are viewed as complementary technologies in the pursuit of end-to-end QoS. In this paper, we expose a service definition in the network and then show how service interworking could be achieved between an domain and Diffserv and Intserv domains to provide end-to-end scalable QoS. The models presented are implemented using the network simulator [33] in which we added support for label switching nodes and static constraint-based routing for unicast and unidirectional links. The release will be publicly available for research purposes [34]. The next section motivates our work on and QoS integration. Section 3 shows the features of which makes it a value-added technology for QoS provisioning. In section 4, we propose a service architecture for QoS support in and explain analytically the inherent mechanisms. Section 5 gives an application on how to

2 provide service for both Diffserv and Intserv network domains. 2. Related works There are many papers on each of integrated services, RSVP, differentiated services,, traffic engineering [9] and constraint-based routing. Some of several ongoing works are already proposing mechanisms to combine some of these architectures: [7] seeks interworking between Intserv and Diffserv networks, whilst [8] introduces Diffserv-like (DS) mechanisms in networks for scalable QoS support. Since is a core technology, the focus of QoS support in networks should be aggregation, i.e. to provide the means for ensuring individual end-to-end QoS guarantees without maintaining awareness of individual flows on each and every segment of their path. Diffserv [32] is therefore a good candidate to provide QoS within networks because services are based on a per-hop model and aggregate forwarding resources (buffer space, bandwidth, scheduling policy) and will be pre-allocated in each node for each service type. The inherent characteristics of make it easily support aggregated flows, i.e. a number of flows that share forwarding state along a sequence of routers. Our work extend the vision of an Internet in which the core network is -based providing QoS guaranties and the boundaries networks support Intserv and Diffserv network architectures; Intserv enabling hosts to request per-flow, quantifiable resources, along end-to-end data paths, Diffserv enabling scalability across large networks, and technology providing fast-switching and traffic engineering mechanisms Introduction Traditional IP routers analyze the network layer header of each packet and parse their routing table in search of the longest prefix match for choosing the next hop. is a technology that integrates label-swapping paradigm with network-layer routing within Label Switch Routers (s). The essence of is the generation of a short fixed-length label that acts as a shorthand representation of an IP packet s header that is subsequently used for packet forwarding within the network resulting in high-speed switching. The ingress analyses the contents of the incoming packet IP header and selects the appropriate header with which to encapsulate the packet. The shim header contains a 20-bit label, a 3-bit field initially defined as erimental and currently used as Class of Service (COS) field, a 1-bit label stack indicator, and a 8- bit Time-To-Live (TTL) field. When the Ss receive a labeled packet, they use the label as an index in an Incoming Label Map (ILM) table containing entries of the form <in label, out label> called Next Hop Label Forwarding Entry (NHLFE). The incoming label is replaced with the new outgoing label and the packet is forwarded to the next hop, Finally, the egress decapsulate the header as the packets leave the network The sequence of labels from an ingress to an egress is called a Label Switched Path (LSP), which is similar to a unidirectional ATM Virtual Circuit, whereas the labels have a local significance. LSP setup can be control-driven (i.e., triggered by control traffic such as management, routing updates or resource reservation) or data-driven (i.e., triggered by the presence of a specific flow). Also, LSP setup can follow a downstream (resp. upstream) approach whereas the downstream (resp. upstream ) at the end (resp. beginning) of the link initiates the LSP, or a downstream-on-demand approach where the downstream generates the labels in response to requests made by an upstream. A mapping between IP packets and an LSP must take place at the ingress by specifying a Forward Equivalence Class (FEC) to a label. A FEC is defined as a group of packets that can be treated in an equivalent manner for purposes of forwarding. The ingress uses a FEC-to-NHLFE Map (FTN) which is used when forwarding packets that arrive unlabeled and are to be labeled before forwarding. An example of an FEC is the set of unicast packets whose destination addresses match a particular IP address prefix. FECs can also be defined at different levels of granularity (source, destination, port level). 3.2 Classes and trunks According to [10], when an aggregation of flows is placed inside an LSP, the result is called a traffic trunk. To support service differentiation in, packets should be divided into separate traffic classes. Hence, the number of trunks within a given topology has a worst case of one trunk per traffic class from each entry router to each exit router, i.e. if there are N boundary routers in the topology and C service classes, there would be (N * (N-1) * C) trunks and C Virtual s overlaid on the same network. Flows Flows LSP LSP Link Figure 1. s and LSPs

3 However, many different trunks, each with its own traffic class, may share an LSP as shown in figure 1. When packets sent along an LSP belong to more than one forwarding class, the service class of each packet can be indicated by the 3 bit Exp field of the packet header, and the result LSP is called -Inferred-Perhop Scheduling Class LSP (E-LSP) [8]. In that case, no more than eight Behavior Aggregates (BA) classes can be defined within the network. If more than 8 BAs are required, then Label-Inferred-PSC LSPs (L-LSP) should be setup, and service class is then inferred from both the label and the Exp fields (e.g. drop precedence). E-LSPs scale better than L-LSPs because they result in less state information and signaling operations to be handled by the s in the network. The LSP is orthogonal to its service class, i.e. the associated level of service applied to consequent labeled packets is derived directly from the Exp field, so no need to specify its value in the E-LSP setup messages, or keep Exp information within the various tables (ILM, FTN). Furthermore, since the exact set of BAs/PHBs are supported over the E-LSPs and use the same PHB mapping, LSPs can be merged implicitly in case of E-LSPs. 3.3 Traffic engineering and constraint-based routing There is increasing interest in the ability to perform Traffic Engineering on IP networks. Traffic engineering is the ability to arrange how traffic flows through a network by moving traffic flows away from the shortest path calculated by routing protocols in order to avoid congestion caused by uneven network utilization. This interest falls into two main areas: traffic based and resource based. The former pertains to optimizing the key traffic performance characteristics such as delay, packet loss and throughput efficiency. The latter refers to using the available network resource in the most efficient manner to avoid congestion and under-utilization. Any IP network aiming to provide QoS for IP sessions should support these principles. If we consider the current definition of Diffserv, it does not contain any simple solution to the problem of resource provisioning. Admission control at the boundary does not consider the availability of resources in the Diffserv network region along a specific path. For instance, uneven distribution of the Premium traffic inside the network may cause a problem for premium service. In a Diffserv network, aggregation of traffic from the boundary routers to a core router is inevitable; but this is not much of a problem since the output links to the core are much faster than input links coming from the clients. Therefore, if premium traffic is distributed evenly among the links and limited to a small percentage of the bandwidth of the links, this should guarantee that the service rate of the premium traffic is much higher than the arrival rate. However, aggregation of premium traffic at the core may invalidate the assumption that the arrival rate of premium traffic being far below the service rate and differentiated services alone cannot solve this problem. This is referred to as topology aware admission control in [7]. Both and constraint-based routing (CR) are useful tools for traffic engineering. The route taken by an LSP between two edge s can be the same as the conventional network layer route, or the sender can specify an explicit route for this LSP consisting of a sequence of hops between an ingress and an egress [11][12]. Constraint-based routing is used to compute routes that are subject to multiple constraints, namely explicit route constraints and QoS constraints. An explicit route needs to be specified at the time that labels are assigned, and does not have to be specified with each IP packet. When a packet enters the network, its path, QoS, and forwarding information are already fully determined and there is no need to enumerate every intermediate router and treatment along the path. This provides an efficient and unique tunneling mechanism compared to other schemes [13]. Explicit routes can be selected either by configuration (manual setup by the network administrator) or dynamically using routing protocols such as QOSPF [14]. 1 INGRESS Figure 2. Example of Explicit Routes in Simulations in [15] show the effectiveness of traffic engineering and explicitly forwarding different classes of traffic into disjoint paths across the network. Figure 2 shows another example of two LSPs between two endpoints, one following a short path with low delays characteristics (DS) and the other a longer path with highthroughput (TS) irrespective of delays. A traffic flow that is delay-sensitive can then be chosen to follow the end-toend path DS presenting the low delays, whereas another traffic flow that is throughput-sensitive can follow the TS path. 3.4 LSP setup LSP (TS) LSP (DS) 2 In order for an LSP to be setup, labels are negotiated and distributed through signaling messages that s use to inform their peers of the label/fec bindings they have made. This signaling information can be carried either by

4 a new protocol like the Label Distribution Protocol (LDP) [16][17], either piggybacked on extensions made to existing protocols (i.e. RSVP [18]). Whether to use LDP or RSVP in is still a hotly debated issue, and work has been carried out on both protocols to provide similar functionality in respect to setting up LSPs as well as support for constraint-based routing for traffic engineering. LDP is a generic label distribution protocol that uses TCP (Transmission Control Protocol) based reliable connections to maintain signaling sessions between the s and exchange messages. The information carried by LDP messages is encoded by using a TLV (Type-Length- Value) scheme allowing it to be extensible and support easily the addition of new entries. Figure 3 shows an example of a constraint-based LSP setup using an LDP Label_Request message with some of the accompanying TLV entries and the corresponding Label_Mapping response message with its TLV entries. Ingress LS R Figure 3. CR-LSP setup using LDP The other method for distributing label-binding information and creating LSPs is through extensions to RSVP. The design of RSVP allowed it to carry opaque objects making it easily extensible to add new objects to support LSP setup. Initial implementers of chose to extend RSVP because of already existing RSVP implementations and it would provide a unified signaling system within the network. In that respect, PATH messages carry now objects like Label_Request (LRO) and Explicit_Route (ERO), and RESV messages carry Label (LO) objects and Record_Route (RRO) objects. Figure 4 shows an example of a constraint-based LSP setup using RSVP Ingress LS R Label_Request (FEC, Explicit_Route, Traffic params LSP_ID, LR_ID) Label_Mapping (FEC,LSP_ID,Traffic params,lr_id) PATH message (Session,LRO, ERO,RRO) RESV message (Session,LO, RRO) Egress Egress Figure 4. CR-LSP setup using extended RSVP Since RSVP does not run over reliable transport, RSVP PATH and RESV messages must be periodically refreshed to maintain LSP state in the s. A number of extensions have been defined to enhance scalability, latency and reliability of RSVP signaling [19]. 4. A service architecture using 4.1 A service example We now consider the example of a Service Provider running less than 8 BAs through his network, representing the following service classes: A delay-sensitive service class, called Premium, where the network commits to deliver with high probability user datagrams at a rate of a Peak Data Rate (PDR) with minimum delay requirements. Datagrams in excess of PDR are discarded. A throughput sensitive service class, called Olympic, inspired from [20], consisting of three service classes: Gold, Silver and Bronze with two drop precedence levels within each class. The network commits to deliver with high probability user datagrams at a rate of at least a Committed Data Rate (CDR). The user may transmit at a rate higher than CDR but datagrams in excess of CDR have a lower probability of being delivered. The default Best Effort (BE) service class with no expected guarantees from the network. When an edge receives a packet, it associates the packet with a particular forwarding class and/or drop precedence. For that purpose, a list of supported Exp field value => (FCI value, DPI value) mappings is defined at each, where the FCI (Forwarding Class Indicator) value indicates a forwarding class and the DPI (Drop Precedence Indicator) value indicates a level of drop precedence. The Exp field values are usually network specific and are defined by the network operator. Table 1 proposes mappings between the Exp field value and the corresponding service class. Service Class field Drop precedence Premium 111 Gold 110 Low 101 High Silver 100 Low 011 High Bronze 010 Low 001 High Best Effort 000 Table 1. Exp to class mapping We will now explain how to provide differentiated services in an network. In order for a customer to receive differentiated services from the network, he must have a service level agreement (SLA) with the provider. The SLA is a contract, established either statically or

5 dynamically, that specifies the overall performance and features which can be expected by the customer based on the amount of traffic requested. The Service Level Specification (SLS) is a subset of the SLA which provides the technical specification of the service. A profound subset of the SLS is the Traffic Conditioning Specification (TCS) which specifies detailed service parameters for each service level (shaping, drop probability, etc). Static SLAs are negotiated on a regular (e.g., monthly or yearly) basis. Dynamic SLAs require the use of some signaling protocol (e.g., RSVP or COPS [22][23][24]) to request service on demand. The network provider has to configure resource allocation inside his network and setup the LSPs between the edge s with the necessary bandwidth to accommodate the streams that will be admitted in the network. In order to support both types of SLAs and to minimize the LSP setup delay, the Service Provider can provision his network to accept the arriving traffic by statically allocating the necessary resources and setting up all the constraint-based LSPs between the end-points, based on customers needs and anticipated traffic patterns through the SLAs. For example, an organization wishing to reserve a certain amount of bandwidth to interconnect its two sites across an network can do so through a static or dynamic SLA. In either case, the network manager should find an already established LSP across his network with remaining QoS characteristics satisfying the customer s needs in which to tunnel the flow. Hence, in addition to setting up the LSPs, the ingress is also responsible for the classification, policing and shaping rules. Figures 5 and 6 respectively show the architecture of ingress s and core s that are DScompliant. The next sub-sections explain the associated nodal mechanisms. incoming packets Policy cntrl Packet classifier Management console bind[(fec<->lsp),<qos>] Traffic Conditioner FTN table Label+QoS mapping lsp-cr[<er>,<qos>] admission control LSP setup module (LDP or "extended" RSVP process) Classifier Routing protocols (QOSPF) Link admission control Link Scheduler LSP setup Outgoing link Figure 5. Functional elements of an ingress incoming packets 4.2 LSP setup LSP setup ILM table Label swapping/ forwarding engine LSP setup module (LDP or "extended" RSVP process) Classifier Link admission control Link Scheduler packets Figure 6. Functional elements of a core The first thing the network manager does from his management console at each ingress is issue a command to setup each LSP specifying the explicit route and the associated traffic parameters, which, for simplicity, are in the form of token buckets values (r,b), and should be sufficient to accommodate the traffic of all classes to be forwarded on that LSP, i.e., must reflect at least the sum of the traffic parameters of the flows traversing it. The LSPs are setup using either LDP or extended RSVP with a control-driven downstream-ondemand allocation approach, a scheme most commonly adopted today in networks because providing more network control (all s belonging to the same LSP perform the label binding in an ordered manner) and better scalability in resource conservation. The LDP (or RSVP) module first checks the link admission control module of the outgoing interface to the next hop on the path to try reserving the required bandwidth. If successful, the remaining capacity of the link is diminished by (r,b) and a Label Request (LR) message is sent to the next hop in the explicit route of that LSP, which also checks its link admission control to setup a reservation and so forth until the egress of the explicit route is reached. The egress then sends a Label Mapping (LM) message back to the originating (OSR) following the reverse explicit route path with the label information. If the LSP setup fails due to insufficient resources along the explicit path, an error message is sent back to the OSR, and the administrator would then try another path. The link admission control module uses admission control algorithms [25] to provide control-load support. Once the LSP is setup, the desired requested bandwidth would then be available end-to-end on the explicit route for the sum of all aggregate traffic in all the classes.

6 1 INGRESS 50 kbps LSP 2Mbps 100 kbps LSP Link admission control Figure 7. Link admission control Figure 7 shows an LSP between 1 and 2 for an aggregate end-to-end capacity of 100kbps, and a LSP between 1 and 3 of 50kbps over a 2Mbps ingress link. A value of around 1.85Mbps would still available for reservation on the outgoing interface of 1 after the setup of these two LSPs. At the ingress, a table with bandwidth characteristics is associated with each LSP in the FTN table (table 2). LSP_ID Label Total Used Out kbps kbps 0 Table 2. Example of a label table of an FTN (the LSP_ID identifies the LSP at the ingress) and the corresponding bandwidth information. The network administrator can now start allocating bandwidth statically for each service class within that LSP. 4.3 Packet classifier 3 2 Packet classification is a significant function that is required at the edge of the network. Its goal is to provide identification of the packets belonging to a traffic stream to an FEC. The classifier is a Multi-Field (MF) classifier, which performs the selection based on the combination of one or more header fields in the incoming IP packet (source address IP/port, destination address IP/port). Once the LSPs are setup, the next thing to be done is bind a certain flow, specified with its token bucket parameters (r,b) and class of service required to an LSP according to the SLA and configure the classifier. FEC LSP_ID Label Total Used element Value Out flow kbps 20kbps flow Table 3. Example of a label table of an FTN (the FEC Element identifies the flow) Table 3 shows the binding of two Premium flows to the same LSP that are using 20kbps of the bandwidth of the LSP. A trunk admission control module at the ingress is for control-load support on that LSP at the ingress. This module measures whether bandwidth is still available on that LSP for the traffic parameters requested by the new flow being added to that path. i.e. much like a Bandwidth Broker [26] acting on a particular ingress node. 4.4 Traffic conditioners Traffic conditioners form the most vital part of a differentiated services network. Their goal is to apply conditioning functions on the previously classified packets according to a predefined TCS. Traffic conditioners (figure 8) act on the classified packets and consists of a leaky bucket associated with each incoming Premium traffic, and a token bucket for each Olympic traffic. Packets that are out-of-profile are either discarded (e.g., Premium), either given a high drop precedence (e.g. in each Olympic class). incoming packets Classifier Figure 8. Traffic conditioners 4.5 Per-Hop scheduling class An example of a scheduling behavior and drop policy is implementing five simple priority queues (figure 9), one assigned for each class, and having admission control making sure that the high priority queues do not starve the low priority queues. The Premium service is the one with the highest priority, with tail-drop discard giving the minimum service delay for the packets. Each class of the Olympic service uses a separate queue with Random Early Detection (RED) with In and Out (RIO) [27] to handle the conforming and non-conforming flows. classifier BE Leaky buckets Leaky buckets DropTail Premi um Gold RIO BE RED Token buckets Token buckets Figure 9. Forwarding engine PQ WFQ

7 Another scheme uses Weighted Fair Queuing (WFQ) [28] using the Exp field as a relative weight between all the classes. 5. Interworking with Diffserv and Intserv domains In this section, we show how the service architecture can support QoS for Intserv and Diffserv networks and provide interoperability at the boundary. Figure 10 shows a typical network configuration with an region containing a mesh of routers in the middle of a larger network with regions containing meshes of routers and attached hosts coming from Intserv regions and Diffserv regions supporting respectively Intserv and Diffserv end-to-end mechanisms. network region. As such, they reshape aggregate traffic coming from within the Diffserv region to conform to the Service Agreement with the domain. A resource controller called the bandwidth broker can also be used to manage the resources of the domain and signal service requirements coming from the Diffserv network using either COPS or RSVP. 5.3 network region 1 and 2 are edge Label Switch Routers responsible for setting up the LSPs, in addition to classifying, applying (and removing) the requisite labels to incoming packets. Figure 11 shows the functions of the edge as an InterWorking Function (IWF) unit. IP IWF IntServ ER1 ER2 IntServ Admission control and signaling (RSVP or COPS/LDAP) Service mapping LSP management Signaling and control DiffServ INGRESS BR1 Figure 10. Sample network configuration We consider that QoS senders from the Intserv (resp. Diffserv) networks need to communicate with QoS receivers in other Intserv (resp. Diffserv) networks through the transit network. This vision extends the services of the carrier networks to offer Virtual Private s (VPNs) with the ability to seamlessly connect organizations to their multiple sites with compatible end-to-end QoS needs. We now define below the major components of the reference network in figure routers 1 ER1 and ER2 are edge routers, residing in the Intserv network region adjacent to the network region. They act as pure Intserv routers, i.e. they process normal RSVP signaling messages between the senders and the receivers, and apply admission control based on resource availability within the Intserv network and on customer defined policy. 5.2 Border routers Transit 2 DiffServ BR1 and BR2 are Diffserv border routers [26], residing in the Diffserv network regions adjacent to the BR2 Classifying, policing and scheduling encapsulation Figure 11. device functions showing the IWF Some functions, such as scheduling, are shown separately since they can be present in both the IP and sides. However, the implementation combines the similar functions. The edge s also participate in signaling coming from the adjacent regions, and police submitted traffic based on the service level specified and the agreement negotiated with customers from the neighboring regions. 5.4 Diffserv/Intserv and service mapping The adjacent regions of the domain specify their QoS requirements through Service Level Agreements using RSVP messages if coming from Intserv networks (for Guaranteed Service [29] or Controlled-Load service [30]), or either statically or dynamically through COPS or RSVP with the neighboring Diffserv domains (for Expedited Forwarding [31] or Assured Forwarding [20] service). Incoming service requirements Guaranteed Service (GS)/ Expedited Forwarding (EF) Controlled-Load (CL)/ Assured Forwarding (AF) Best Effort Scheduling and shaping matching service Premium Service Olympic Service Best Effort Table 4. Service map from Intserv/Diffserv to

8 The network, like in ATM networks (with traffic classes CBR, VBR, etc), maps the incoming QoS requests to the corresponding service class within the network. In this model, each incoming flow is assigned to one of the available classes for the duration of the flow and traverses the cloud in this class. The service mappings given in table 4 follow most naturally from the service definitions. For completeness, we propose in table 5 possible mappings for all service combinations and identify how the Exp field is to be used in the header of packets across the network to obtain the equivalent service. Taking into account that the 8 BAs within the network offer less service granularity than the Diffserv classes (one EF and four AF with three possible drop precedence levels in each class [20]), traffic flows requiring similar service are grouped together into a single class, while the system's admission control and class selection rules ensure that the service requirements for flows in each of the classes are met. Intserv service Diffserv class service type PHB DSCP field class GS EF Premium CL AF Gold AF AF CL AF Silver AF AF CL AF Bronze AF AF AF AF AF BE DF Best Effort Table 5. Proposed QoS mapping It is the responsibility of the network administrator to configure the mappings of the DSCP values that Diffserv QoS uses, as well as the incoming Intserv service request, to the Exp value for egress port scheduling and congestion avoidance. For instance as seen in table 1, AFx2 and AFx3 (x=1,2,3) are given the same Exp field (i.e. drop precedence) within each service class x, and AF4x packets are all given Exp value 001. As for incoming Controlled-Load service requests, the Exp value can vary between Gold, Silver or Bronze service depending on preconfigured settings based on per customer criteria. 5.5 Service delivery using dynamic reservation We now describe how the signaling information travels end-to-end from one network to another through the region considering Intserv neighboring networks. The reference network is given in figure 12. To establish a flow to node B, node A first generates an RSVP PATH message which describes the flow in detail. For example, the flow might require 3kbps of bandwidth, be insensitive to jitter of less than 50ms, and require a delay of less than 200ms. This message is passed through node A's network and eventually arrives at 1, after normal RSVP operations within the Intserv region. 1 has already an established and maintained LSP that terminates at egress 2. At this point, 1 matches the flow requirements in the RSVP PATH message to the characteristics (e.g., remaining capacity) of the LSP to 2. Assuming that the requirements are compatible, it then notes that the flow should be aggregated into the LSP. If the admission control decision is negative, the 1 can inform node A using RSVP. To insure that the flow reservation happens end to end, the RSVP PATH message is then encapsulated into the LSP itself, where it is transmitted to 2. It eventually reaches the end of the LSP where it is decapsulated by router 2. PATH messages are then propagated all the way to the ultimate destination B. The end-to-end RSVP RESV response message coming from B is carefully handled by router 2 and returned via a tunnel back to 1. A IntServ ER1 INGRESS Figure 12. Propagation of RSVP messages The data packets corresponding to this flow are then bound to the LSP and marked with the pre-configured Exp value at the ingress Conclusion 1 In this paper, we showed how combined with differentiated services and constraint-based routing can form a simple and efficient Internet model capable of providing applications with differential QoS. No per-flow state information is required leading to increased scalability. We also proposed how this service architecture can interoperate with neighboring regions supporting Intserv and Diffserv QoS mechanisms. We developed an implementation that integrates and supports our models and provides the necessary functionality to statically provision network resources within the network. Future work on the platform is to automate the traffic engineering process by using QOSPF. Transit 2 ER2 IntServ B

9 References [1] Braden, R., Clark, D. and Shenker, S., "Integrated Services in the Internet Architecture: an Overview", Internet RFC 1633, June 1994 [2] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", RFC 2205, Proposed Standard, September 1997 [3] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based QoS Requests", Internet Draft, draft-guerin-aggregrsvp-00.txt, November [4] Blake, S., et al., "An Architecture for Differentiated Services." RFC 2475, December [5] Nichols, Kathleen, et al., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December [6] Rosen et al., "Multiprotocol label switching Architecture", work in progress, (draft-ietf-mpls-arch-06.txt), August [7] Bernet, Y. et al. A Framework for Integrated Services Operations over Diffserv s, draft-ietf-issl-diffservrsvp-03.txt, Sept 99. [8] Le Faucheur et al., Support of Differentiated Services, draft-ietf-mpls-diff-ext-02.txt, October 1999 [9] Awduche et al., Requirements for trafiic Engineering Over, draft-ietf-mpls-traffic-eng-01.txt, June 1999 [10] Li T., Rekhter Y., A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE), RFC2430, October 1998 [11] M. Chatzaki, and S. Sartzetakis. QoS-Policy based Routing in Public Heterogeneous Broadband s". In Proceedings of Interworking'98 Conference, Ottawa, Canada, 6-10 July [12] B. Davie et. al., Use of Label Switching With RSVP, draft-ietf-mpls-rsvp-00.txt. AND Explicit Route Support in, draft-davie-mpls-explicit-routes-00.txt. [13] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP Reservation Aggregation", Internet Draft, draft-ietfissll-aggregation-00.txt, September [14] R. Guerin et al., QoS Routing Mechanisms and OSPF Extensions, draft-guerin-qos-routing-ospf-03.txt, January 1998 [15] Jain, R, et al. Quality of Service using Traffic Engineering over : An Analysis, Internet Draft, draft-bhani-mplste-anal-00.txt, March 1999 [16] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- 05.txt, June 99 [17] Jamoussi et al., "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-03.txt, October 1999 [18] Awduche et al, "Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-03.txt, September 1999 [19] Yuhara, M et al, RSVP extensions for ID-based refreshes, draft-yuhara-rsvp-refresh-00.txt, April 1999 [20] Heinanen et al., "Assured Forwarding PHB Group", RFC- 2597, June [21] Callon, R. et al., A framework for Multiprotocol Label Switching, draft-ietf-mpls-framework-03.txt, June 1999 [22] Boyle, J. et al., COPS Usage for RSVP, draft-ietf-rapcops-rsvp-00.txt, August 1998 [23] Boyle, J. et al., COPS: Common Open Policy Server, draft-ietf-rap-cops-02.txt, August 1998 [24] Reichmeyer, F. et al., COPS Usage for Differentiated Services, draft-ietf-rap-cops-ds-00.txt, August 1998 [25] Jamin, S., et al., Comparaison of measurement-based admission control algorithms for controlled-load service, Proc. IEEE INFOCOM 97, April [26] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit Differentiated Services Architecture for the Internet", RFC2638, July [27] D. Clark and J. Wroclawski, An approach to service allocation in the Internet, draft-clark-different-svc-alloc- 00.txt, July 1997 [28] H. Zhang, Service disciplines for guaranteed performance service in packet-switching networks, Proc IEEE, vol. 83, no. 10, October 1995 [29] S. Shenker, et al., Specification of the guaranteed quality of service rfc 2212 September [30] J. Wroclawski. Specification of the controlled-load network element service. Request for comments, rfc 2211, Internet Engineering Task Force, September [31] Jacobson et al., "An Expedited Forwarding PHB", RFC- 2598, June [32] Bernet, Y., et al., _A Framework for Differentiated Services_, Internet draft, draft-ietf-diffserv-framework- 02.txt, February [33] The ns-2 simulator, URL: [34] URL:ftp://ftp.usj.edu.lb/pub/mpls-ns