QoS was not one of the strong points of IP, but it now finds itself in need of it badly. IP is currently a best-efforts service. With the current boon in Internet usage especially due to its proliferation into business, there is a greater and more urgent need for ISPs (Internet Service Providers) to be able to provide QoS. This means providing different treatment to different customers and to be able to guarantee certain levels of service quality according to the users needs and the size of their wallets. Several methods are under discussion for such QoS provisioning.
ATM was “designed for QoS “ so to speak. ATM allows point to point and point to multipoint virtual circuit to be requested with pre-specified QOS. ATM provides a rich set of QoS mechanisms with a wide variety of service categories or QoS descriptors which offers a fine control over the traffic parameters requested and managed. ATM offers a sophisticated signaling mechanism that can be used effectively by any agent that needs to take care of QoS provisioning.
If ATM is available then IP can thus take full use of it in providing QoS. Given there is a large effort currently being made to incorporate QoS in IP, it would be wise to take full benefit of any inherent support for QoS in an underlying layer. This is especially true if that underlying layer is ATM. Moreover the many ISPs are already using ATM in their backbones. It is this topic, IP QoS over ATM that this survey paper addresses. The paper begins by first discussing QoS mechanisms that have been proposed for IP. These are Intserv, RSVP, diffserv and MPLS. Then it surveys the work that has been done on providing these QoS mechanisms over ATM.
Back to the Table of Contents.
Back to the Table of Contents.
MPLS supports domains, hierarchical routing and can be used for tunneling. Domain boundaries are defined by boundary routers which inserts the appropriate label onto a stack, which is removed by the egress boundary router. A route can be explicitly specified by a router. During tunneling the ingress Label Switched Router defines the entire Label Switched Path through the tunnel.
Intserv involves a fundamental change in that it extends the current architectural model on which the Internet is based, this extension has been called IS extension (Integrated Services Extension). There are three such fundamentally important extensions: The IS extended routers now would have to maintain flow state, routers will have a capability to reserve resources, and the resource controlling mechanism will be explicit. Such a control involves scheduling, classification and admission control all done at the router. It has been proposed that such traffic control be primarily implemented by a combination of Weighted Fair Queuing, and Priority Queuing.
Several types of services are provided by the Intserv service model. It allows for the provision of quality of services for the individual flows or for aggregate flows. The individual flows are essentially based on time of delay. The aggregate flow services are primarily based on divvying up the available BW among flow aggregates. Packets can be marked preemptable. Other components of the service model such as usage feedback and the reservation model, which deals with the question of how exactly the application requests reserves and how the network grants them, are all still under consideration.
Intserv model used the Resource Reservation Protocol (RSVP) for setting up the reservation. RFC introducing IntServ architecture is [ RFC1633] more details can be obtained from that source and the list of bibliography that it gives.
Integrated services for the Internet has two broad classes of Quality Of Service: The Guaranteed Services (GS) and the Controlled Load Services(CLS). The specifications of these services can be found in [ RFC2211]and [ RFC2212]respectively. These services differ in how tight a guarantee the services provide. Controlled load service provides less tight guarantees. The user gives a traffic specification (TSPEC) in order to request the controlled load service. All that this service does for the applications is provide an assurance that, for the requested traffic specification, a very high fraction of the data transmitted will experience a delay close to the minimum delay seen. The packets can expect to find conditions very close to that where the network is not congested. Guaranteed Service on the other hand provide tighter guarantees. The application provides information about its token bucket for IP datagrams. This is given in terms of bucket size in bytes and token rate in terms of bytes/sec. The application also gives it peak IP datagram rate. Guaranteed Service will accept the traffic only if it can assure the application of a guaranteed upper bound on the maximum delay that the datagrams will experience. This delay is only the queuing delay and the application must also add the fixed delay to the queuing delay in order to estimate completely the actual delay the packet will experience.
Intserv however puts a lot of demand on the routers. routers must now store state information and it increases in direct proportion to the number of flows. The functionality required of the router increases too. The routers must now understand RSVP, must make more decisions on accepting flows, and must implement queues in order to classify and provide appropriate services to the flows. The next section considers a scalable service scheme, which does not put so much demand on the routers, the differentiated services, or Diffserv.
Back to the Table of Contents.
Diffserv is different form Intserv primarily in its level of aggregation, scalability and location of complexity. Intserv, as seen above would have to maintain state information on each of the nodes. This entails a large load especially on large on fast networks. Diffserv aggregates the individual flows at the core of the network, thereby taking the load of routers where it mattered most…at the core where traffic is the highest. Also Diffserv does not depend on RSVP like Intserv. The complex task of classification is undertaken at the boundaries where speed is relatively less important. Speed however is very important at the core routers and diffserv does not burden these routers with complex tasks. In Diffserv the classification of the packet and traffic conditioning takes place at the edges. These classification is more coarse grained than in the Intserv model. As mentioned before DS field in the IP header is used to mark the aggregates. Traffic conditioning involves metering, marking, dropping and shaping. In the core, the traffic is given differentiated treatment according to the per hop behavior defined for these marked aggregates. Diffserv maintains the ordering of the packets of
Figure 1:Diffserv Architecture showing core routers, boundary routers, and their main responsibilities.
the same microflow if they belong to the same Assured Forwarding class. Any set of behavior aggregates that are all constrained by the same ordering constraint have been termed Scheduling Aggregate (SA) or Ordering Aggregate (OA) . We will come across this terminology when we visit MPLS over ATM. Per Hop Scheduling Class (PSC) refers to one or more Per Hop Behaviors applied to the set of Behavior Aggregates forming a given OA. The figure above shows a high level view of the diffserv architecture and illustrates that the responsibility of classification and conditioning is pushed to the edge or leaf routers.
Diffserv is flexible. The services provided and traffic conditioning is sufficiently decoupled from the forwarding behavior at the core. Thus new services can be easily added to the existing ones. The interaction between the edge nodes where traffic conditioning is performed the core nodes would require some sort of a control or administrative entity, possibly with a protocol of its own. The Diffserv architecture does not specify or limit what this protocol ought to be.
Interoperability with non-diffserv nodes and multicast packets give rise to some special issues. Non Diffserv nodes can only be handled if they are nodes that implements IP precedence classification and forwarding [ RFC 791, RFC1812]. If they are not, then the behavior of those nodes is undefined if the DS field is non zero. While handling multicast packets it is difficult, especially when the group membership is dynamic, to predict how much resources will be required for the traffic. This makes it difficult to give quantitative assurances to the multicast transmitter. Also multicast traffic can infringe on unicast traffic if they are not sufficiently decoupled. It has been proposed that separate DSCP
Figure 2:The Differentiated services field formed out of the 8-bit IP TOS field. The low order two bits are Currently Unused (CU bits)
(Differentiated Services Code Point) for unicast and having separate 7 service level agreements for unicast and multicast traffic.
Possible security hazards could arise due to the inherent capability of differentiating services of the packets transmitted. Thus security screenings must be provided, primarily at the ingress nodes, to prevent unauthorized modification of the DS field. Such a modification could lead to illegal appropriation of the resources constituting denial of service to other peers.
The previous sections considered. QoS provisioning in IP networks in general. A popular forwarding scheme, MPLS was considered briefly. Two important service currently under study, Integrated Services and Differentiates Services were considered and compared. A signaling protocol that can be used to support these schemes is RSVP. The above treatment was general in the sense it did not assume any specific underlying network. The next section will deal with the specifics if the underlying network was ATM. As mentioned in the introduction ATM could be profitably used as it has a versatile QoS mechanism already built in.
When MPLS is run over, say, PPP, an additional shim header is added which is a label stack with possibly more than one entry. Also in MPLS there is a 3 bit EXP field that is free to be used for any miscellaneous purposes. Now, if we restrict the number of Behavior Aggregates to 8 then all these behavior aggregates can be bundled into a single MPLS LSP by using the 3 bit EXP field of the shim header. If more than 8 behavior aggregates are to be treated then a combination of packets belonging to several behavior aggregates may need to be bundled into the same LSP. It has been proposed that in such cases a combination of a Forwarding Equivalence Class and Ordered Aggregate be routed to the same LSP. The EXP field in the shim header is used as before.
Back to the Table of Contents.
While ATM has its claims to providing QoS assurances, it however cannot do anything above layer 2. That means that all layer 3 flows that have been aggregated together cannot be differentiated by ATM, and thus they all end up competing against one and another for the same resources. Thus there is needed a way to implement finer granularity in the control of traffic flow, and this is best done in layer 3. This is where Intserv/RSVP and Diffserv come in handy.
This section will review the current state of affairs in the symbiotic interoperation of ATM and IP QoS architectures discussed in the previous section. First we consider IntServ over ATM and then Diffserv over ATM. MPLS support is then addressed. Many of these architectures rely to a lesser or greater extent on RSVP for signaling so we will visit RSVP over ATM issues in several parts of the section as we go along.
Figure 3:IP Intserv packets pass through an intermediate ATM cloud. The Edge device takes care of the required address translation and speak both languages.
Intserv, as seen before, uses RSVP as a signaling protocol to provide QoS. Conformance to this Integrated service model is required if QoS provisioning is to be made for any IP traffic. Thus, when the IP protocol stack is implemented on top of ATM and such conformance to the Integrated Services model is to be ensured, there is a need to map RSVP signaling to ATM signaling. Such a mapping essentially consists of two problems, one involving QoS parameters that are used and the other the virtual circuit management. QoS specification in the Integrated services model is not identical to that in ATM. Thus a QoS translation needs to be done for IP QoS over ATM. IP traffic is aggregated into flows. ATM, in layer two, aggregates it further and assigns Virtual Circuits to these aggregates. Thus there arises the issue of which flow goes into which VC and how many such VC to create.
Now we will consider in brief some of the issues that are being worked on or needs to be worked on in integrating intserv/RSVP over ATM. More details can be obtained from the [ RFC2382]. This RFC gives a good treatment of the outstanding issues and therefore and parts of the following is based on this RFC.
A) Control and data message paths: In RSVP the PATH message installs the path that the data would take. This means that RSVP PATH message must follow the same path as that of the data. In the case of an underlying ATM cloud, the ingress and egress points of the cloud should be the same for both RSVP control message and data.
B) Service Mappings between Internet and ATM [ RFC2381]. As explained before, the Integrated Services for IP essentially consists of two service types apart from the best effort service: Guaranteed and Controlled Load Service. ATM services include Constant Bit Rate (CBR), rtVBR(real time Variable Bit Rate), nrtVBR(non real time Variable Bit Rate), UBR(Unspecifies Bit Rate) and (ABR)Available Bit Rate. The following mapping has been proposed between ATM and IIS for IP.
| ATM Service | Internet Integrated Service |
| CBR or rtVBR | Guranteed service |
| nrtVBR or ABR(Minimum Cell Rate) | Controlled Load |
| UBR or ABR | Best Effort |
B) QoS connections for RSVP over ATM: In the case of PVCs the end devices must provide services to assign several flows over a given VC. Care must be taken with PVCs so as to avoid underutilization of resources due to idle PVCs. PVCs are frequently set up such that if the available BW is less than that would be required if all the PVCs are simultaneously utilized. However while using Intserv/RSVP over ATM it needs to be ensured that all the QoS that has been granted is satisfied. Otherwise there would be no point in giving a QoS assurance.
C) SVCs allow flexibility but it has its attendant complexity. Cost and the time needed to set up SVC should be taken into account before deciding on using SVCs to route QoS traffic.
D) In order to support IP multicast it would be necessary to take advantage of the point to multipoint VCs. However there is a difficulty here. ATM UNI 4.0 allows only one service class for all the recipient VCs. Thus in order to allow the recipients to request different QoS, it would be necessary to have a separate VC for the recipient. This has the potential to give rise to scaling problems.
E) Short Cut using Next Hop Resolution Protocol (NHRP): When an ATM cloud consists of several Logical IP subnets, it is possible to use NHRP to go from a router in one subnet directly to a router in another subnet. But this would mean storing of an additional state information of the address mapping. The cost-benefit analysis of this is an open issue.
F) Simultaneous best effort service: The Intserv models do not allow dropping of non-conforming packets. This is to avoid denial of service security attacks. Implementing this on ATM is an issue still to be solved.
G) Variegated VCs: It has been proposed that ATM incorporate point to multipoint VCs where different VCs have different QoS requirements. Issues that are open here concern how the cells are dropped when traffic goes from a branch with QoS corresponding it a larger BW to one with a smaller BW. Early Packet Dropping has also been proposed wherein all cells of one packet are dropped before dropping cells from another packet. This would prevent a large number of packets being rendered useless at the same time as opposed to just a few.
H) A less complex signaling mechanism has been proposed to reduce the overhead.
I) Dynamic QoS renegotiations: RSVP allows such dynamic changing of reservation parameters. It would be better integration of ATM does the same too. Some headstart has already been made in that PCR can now be changed dynamically
J) Mapping to group addresses: This would be needed to provide the many-to-many communication available in IP.
I) QoS routing: It has been proposed that RSVP while asking for the next hop for a given destination address it could also provide information regarding the QoS requirements to the routing protocol. The routing protocol can then factor in this information in arriving at routing decision. PNNI routing has also been considered for providing QoS routing [ RFC2386]
J) Mapping QoS parameters: QoS parameters need to be mapped from the ATM model to the Intserv/RSVP model. Complications can arise here due to differences in implementation methods possible, policy mismatches and cost issues. There is a need to come up with a matrix of possible mappings for various networks.
I) Policy: CAC mechanisms fit well with IP policy mechanisms. Some policies unique to IP over ATM could be not allowing a dynamic change of QoS over certain VCs.
This section began by considering the general architecture of and IP over ATM network with support for the integrated services model. The role of the edge routers was described. A proposed mapping between ATM QoS and IP QoS was provided. Then several outstanding issues in providing Integrated Services for an IP network over ATM. The next section will deal with providing Diffserv over ATM.
Back to the Table of Contents.
Two important per hop behavior has been defined by IETF for diffserv. Expedited forwarding (EF) PHB [ EF]assures bandwidth availability irrespective of other traffic sharing the link. This PHB provides facilities for peak rate specification and traffic policing. This service is similar to that provided in ATM CBR or rt-VBR. This Assured Forwarding (AF) [ AF] assures a certain minimum amount of available of BW. Assured Forwarding itself consists of four sub classes of traffic. AF PHB is then similar to ABR and nrt-VBR of ATM.
However the mapping, taken as such, is not identical. ATM provides end-to-end BW guarantee. Neither does EF or AF have connection admission control. Diffserv is designed to avoid flow control at small levels so as to impart scalability in the amount of work that the core routers need to perform or the amount of state information it needs to store. Providing end-to-end services is not a trivial task with diffserv as it has be implemented as a concatenation of several PHBs. The proposed mappings are shown below in the following tables. These tables are from [ ATMF99-205]
Table 1. Differentiated Services and their Corresponding ATM services
| Descriptor | Differential Internet Service | Matching ATM service | Matching ATM service |
| Name | Premium service and other services
based on EF PHB |
CBR | rt-VBR |
| Policing | Strict control of traffic descriptor. Violation results in discard. | Strict control of traffic descriptor. Violation results in cell discard. | Strict control of traffic descriptor. Violation results in cell discard. |
| Traffic descriptors | Peak Packet Rate
Maximum Packet Size |
Peak Cell Rate
Cell Delay Variation Tolerance |
Peak Cell Rate
Cell Delay Variation Tolerance Sustainable Cell Rate Maximum Burst Size |
| QoS | Low Loss and low delay guarantee; Suiting real time requirements | Class 1: Low loss and low delay guarantee; Suiting real time requirements | Class 1: Low loss and low delay guarantee; Suiting real time requirements |
| Buffer policy | Highest Priority Queue
(or similar) Depth 1 or 2 packets |
Highest Priority Queue
Depth ca. 100 cells |
Highest Priority Queue
Depth ca. 100 cells |
| Descriptor | Differential Internet Service | Matching ATM service | Matching ATM service |
| Name | Services based on AF PHB | VBR3 | GFR |
| Policing | Strict control of the „Assured" traffic descriptor. Violation results in degradation of transport quality to best effort [DSOP0] for the violating packets | Strict control of the "SCR and MBS" traffic descriptors. Violation results in degradation of transport quality to best effort. Cells above PCR will be discarded. | Strict control of the "MCR, MFS and MBS" traffic descriptors. Violation results in degradation of transport quality to best effort. Cells above PCR will be discarded. |
| Traffic descriptors | Assured Packet Rate; Maximum Burst Size | Peak Cell Rate Sustainable Cell Rate; Maximum Burst Size | Peak Cell Rate Minimum Cell Rate; Maximum Frame Size, Maximum Burst Size |
| QoS | Assured component (marked): moderate loss delay.
Best Effort (mark removed) other packets |
„Class 3 (bi-level)": Class 2 service (low loss guarantee and moderate delay) for the traffic up to SCR/MBS. Best Effort (Class U) up to PCR. | „Class 3 (bi-level)": Class 2 service (low loss guarantee and moderate delay) for the traffic up to MCR/MFS/MBS. Best Effort (Class U) up to PCR. |
| Buffer policy | Second Priority Queue (or similar), shared by assured & best effort traffic. Discard threshold for best effort traffic much lower then that for assured traffic. RIO-RED. | Second Priority Queue, shared by Class 2 traffic & Class U traffic. Discard threshold for best effort traffic much lower then that for Class 2 quality traffic. (Some implementations may support EPD). Note 2 | Second Priority Queue, shared by Class 2 & Class U traffic. Discard threshold for best effort traffic much lower then that for Class 2 quality traffic. (EPD or PPD should be supported). Note 2 |
| Descriptor | Differential Internet Service | Matching ATM service |
| Name | Best Effort | UBR |
| Policing | None | None |
| Traffic descriptors | None | None (informative Peak Cell Rate proposed by specification to support network planning) |
| QoS | Best Effort | Best Effort (Class U) |
| Buffer policy | Lowest Priority Queue. Discard Threshold for best effort traffic much lower than that for any other traffic. | Lowest Priority Queue. Discard Threshold for Class U traffic much lower than that for any other traffic.
Note |
Diffserv over ATM would necessitate a mapping of the IP header to a VC, which can read frame boundaries. Also a mapping between the DS code point (DSCP) and the PHBs need to be identified.
Some of the issues in providing interoperability between ATM and Diffserv will now be considered.
A) Permanent VPs with QoS. This is easy to implement but may lead to a wastage if the link is underutilized.
B) Mapping with SVCs Each new IP DS connection is carried by a separate ATM SVC. Though this method does not cost in terms of unused BW, however, does increase the set up time and could lead to a VC explosion. RSVP can be used to implement this method.
C) Role of router topology in deciding simplicity of Connection Admission Control (CAC): CAC complexity increases with the router network topology.
D) Bandwidth can be used more economically: This is achieved by letting best-efforts/UBR traffic to consume unused resources that were occupied by the original ATM VP.
E) New Communication Protocols needed: Diffserv makes use of what are called Bandwidth Brokers to maintain a database QoS requests from the members of a domain and act as an ambassador to facilitate communication with external domain as regards to resource management and traffic control.. In order for IP QoS over ATM to work the ATM management system must communicate with the bandwidth brokers for Diffserv. Protocols are needed for this.
F) Address Mapping: Permanent ATM connection are mapped to individual VCs. VPs may also be used between the end users to map the aggregated IP addresses, while the individual DSCP address of the flows will then be mapped on to the corresponding VCs of that VP. The advantage of this option is that it is required for SVCs anyway and the scalability property is better too. The resources granted to the individual VCs then are limited by the resources allotted to the VP to which it belongs.
Now we will look into what are the actions that need to take place at the ATM switch for DiffServ over ATM [ ATMF99-204]. These actions can be broadly classified as bandwidth provisioning, relative resource allocation, and priority control. We will consider them one by one in the following..
Bandwidth provisioning VCs are mapped and threaded through a sequence of Per Hop Bandwidth Aggregates(PHBA). The threading is necessary because the PHBAs are not end to end but only hop to hop. The binding of VCs to PHBAs is done by a Behavior Class Selector.
Figure 4:Per Hop Behavior Aggregates mapped to VCs in a switch with 3 ports. Each port has two Per Hop Behavior Aggregates and two Behavior Classes.
The figure shows the mapping of PHBA to Virtual Circuits. 1,2,3 are ports. X and Y are separate Behavior Class Selectors (BCS). PHBA6/Y etc. are PHBA configuration, here stating that the aggregate no. 6 with the BCS identifier Y. Five Vcs are shown in the figure. The function of the BCS is that it defines which PHBA is mapped on the output port. Incoming Vcs from port 1 are routed to port 2 and those from port 3 are routed to port 1. The actual mapping can be done by setting up a PVC or by using signaling to create to SVCs. The DSCP can be mapped now to the BCS number. All VCs within a same PHBA can be allocated the same UBR service category. It is assumed that the competition among the VCs within a PHBA will be fair.
Figure 4 shows one such PHBA configuration over an intranetwork. The network
Figure 5:PHBA configuration for an intra network consisting of two BCSs X and Y
has two BCS and each link has that many number of PHBAs (two in this case) associated with it. The scalability of Diffserv is also evident from this. Thus the node involved in routing would just need to pick an appropriate PHBA to forward the packet to. The actual computation of the route can be done using traditional ATM’s PNNI.
.
Relative Weighting of VCs within a service category: ATM does not inherently support such a differential weighting within a service category. This is achieved by creating a number of VC classes with no predefined QoS parameters for the VCs. These VCs use the UBR service category. The network operator then manually configures the resource weights for the classes. It is these resource weights that enable the provision of services that are relatively weighted.
Priority Queuing: The traffic class is determined from the BCS value corresponding to the VC. Cells from a particular queue belonging to a traffic class is selected for dispatch only if the queues corresponding to numerically higher values of traffic class (higher priority) are all empty.
To summarize, features of Diffserv over ATM implementation as proposed in are the following
* Support for AF, and 802.1D user priorities
* Uses UBR for the VCs
* Now new service category need be created
* Current ATM switches emulate Diffserv Router
* Individual VCs are signaled with BCS for each of those VCs.
* No bandwidth signaled for PCs.
Recently it has been suggested that the BCS will not be sufficient. ISPs would be serving several customers at a time. BCS can only identify the PHBA-VC pair given a port number at the node. However it cannot identify the individual customers, which is what the ISPs would want to do. An open issue here is that [ ATMF99-091]
Who has a say in how much buffer space and bandwidth is allocated at the edge devices? It could be the edge device itself or the job could be left in the control of the network operator. The authors here argue that in the case of multiple customers the control is better left to the edge devices. The reason being that if there are many customers handling and coordinating all the BCS, this would cause too much overhead at the ISP equipment side. The multiple customers must also be isolated from each other. This might again call for a “bundling” of VCs from a particular customer or for each source-distinct destination pair of a customer. End to end service creation is also a goal the achievability of which is not very obvious. These issues have not yet been addressed properly and are still being hotly debated..
Back to the Table of Contents.
[MPLS1] gives a discussion of Label Switching with ATM switches. Fundamentally the operation of ATM switches is very simlar to that of label swithches. However with MPLS and ATM interoperability demands that the MPLS labels be somehow encoded into fields that the ATM switch can recognize. ATM switches that can do this are called ATM-LSR (ATM Label Switch Routers). Note that unlike the case discussed for PPP, ATM does not use a shim header. What has been proposed [MPLS1] is that the a combination of VPI/VCI fields be used for this purpose to encode one or more label stacks. It is very possible to encounter a situation where different ATM-LSRs will use different encoding techniques. However, ATM swithces do not posses the ability to translate encodings. Thus if MPLS is to be used then successive LSRs should necessarily use the same encoding. Switches that are capable of both using the VPI/VCI field to encode the label and of using a shim header would be necessary in the case of networks that have both ATM switches acting as Label Swithced Routers and other Label Switch Router that use only a shim header. ATM swithches may have an option of taking the label of packets which could all be different but need to be all forwarded onto one Forward Equiavant Class. This would mean that the different labels on the packets will be replaced with an identical one. This process is called VC Merge and the swithces that do this are called VC merge capable Label Switched Routers.
The MPLS header, as seen before, should be invisible to layer 2 protocols. ATM should not see the MPLS header directly. It has been proposed that that a separate Label Switched Path be created for each Forwarding Equivalent Class/Scheduling Aggregate pair. Diffrentiation in treatment of packets from different behavior aggregates would have to be implemented by maping the CLP bit to drop precedence. Thus when the underlying technology used is ATM. it can only support two levels of drop precedence. However, by making use of the EXP field in the shim header for the top label stack entry, support for all the drop precedence can be provided in PPP MPLS clouds that may surround an ATM MPLS cloud.
implemented per Forwarding Equivalence Class, Scheduling Aggregate pair, as opposed to 8 were the EXP field of a shim header be used.
The essential stages involved in Diffserv label switching are details can be had from [ Wu992]
A) Incoming Per Hop Behavior and Forwarding Equivalence Determination
B) Outgoing Per Hop Behavior determination by local policy and traffic conditioning(optional)
C) Outgoing EXP field and label determination.
Extensions have been proposed to the protocols, LSP and RSVP, that are used in establishing a Label Switched Path.The Per Hop Scheduling should be signaled in the MPLS label request messages. New message formats have been proposed for RSVP and LDP signaling protocols. The new RSVP format is shown in figure below. This is an object class defined as class of service.
Fig5 a)The new LDP Time-Length-Value field and the b)RSVP Object format.
Figure 6 a) shows the fields for the new LDP format and Fig. b shows the same for RSVP.
This object can be carried in the PATH message that carries the label request object to indicate the PHS for which a label is required. It can also be used in the RESV messages carrying the label object indicating the PHS for which the label is to be used. All LDP messages have a common structure and uses what is called a Type-Length-Value encoding scheme (TLV). It has been proposed to encode the above illustrated PHS TLV as a nested TLV in the COS value of the COS TLV. The advantage of this is that future additions of new TLVs can all be grouped logically inside the COS TLV. New security mechanisms have not been proposed specific to this implementation. Thus it retains only the mechanisms available in DiffServ, MPLS and RSVP.
Back to the Table of Contents.
Back to the Table of Contents.
Back to the Table of Contents.
Back to the Table of Contents.
Back to the Table of Contents.