Internet Draft Soft State Switching A Proposal to Extend RSVP for Switching RSVP Flows <draft-viswanathan-mpls-rsvp-00.txt> Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes a mechanism for establishing a switched path with guaranteed Quality of Service for RSVP [1] flows in a MultiProtocol Label Switching (MPLS) environment. It proposes an extension to the RSVP protocol that allows the establishment of a sequence of label switched hops along the hop-by-hop routed path by enabling adjacent nodes to exchange MPLS labels [11]. The labels may correspond to information that identifies a layer 2 virtual connection; for example, the VPI/VCI value in the case of an ATM-based infrastructure. Viswanathan, et al. Expires: January 1998 [Page 1] Internet-Draft Soft State Switching August 1997 1. Introduction A Label Switching Router (LSR) is a label switching node that has an IP Control Point (IP-CP) and implements an IP label switching technology [2-4]. LSRs form adjacencies using a well-known label switched path (LSP), also called the default path, that terminates at the adjacent LSR's IP-CP. This hop-by-hop LSP connectivity gives a network of LSRs the same nature as any ubiquitous IP internet. The objective is to label switch RSVP flows in such an environment. This document proposes an extension to RSVP that introduces new objects to the existing RSVP messages. Using these objects, each downstream LSR provides its neighboring upstream LSR with the label on which it wishes to receive a RSVP flow. In an ATM-based LSR environment, this label would correspond to a VPI/VCI value for the ATM virtual circuit on which the LSR wishes to receive traffic from the RSVP flow. Then, using an approach similar to those outlined in [2], [3], and [4], the labels are spliced hop-by-hop to form an ingress-to-egress LSP. The data from the RSVP flow then traverses this LSP, and the RSVP signaling messages are forwarded hop-by-hop via default paths. By moving RSVP flows from the hop-by-hop routed path to a dedicated ingress-to-egress LSP, it is possible to leverage the QoS capabilities of the underlying switching technology to provide the type of service desired for the reserved flow. The memo proposes a "one label per flow" approach, where a flow is synonymous with a particular sender (source address/source port) and session (destination address/protocol/destination port). It is assumed here that the LSRs on the edge of a MPLS network can either auto-learn or are configured to indicate that they are edge LSRs (on a per interface basis). 2. Soft State Switching In soft state switching, the goal is to switch packets from a RSVP flow at layer 2 instead of having to forward them hop-by-hop as in conventional IP routers. By doing so, it is possible to leverage the high-performance switching and Quality of Service capabilities of the layer 2 technology. This is achieved when all neighboring LSRs along the routed path can exchange labels for establishing the switched path for RSVP flows. Then, the labels may be "spliced" hop-by-hop to set up an end-to-end (ingress-to-egress) LSP along the preferred routed path. By splicing, we refer to the process by which an incoming label is associated with an outgoing label at layer 2, without traffic encapsulated by the incoming label being processed at the network layer. For example, this can be achieved in ATM switches by establishing this association in the ATM switching tables. Once Viswanathan, et al. Expires: January 1998 [Page 2] Internet-Draft Soft State Switching August 1998 the splicing is complete, the default path carrying best effort traffic between adjacent LSRs provides the IP forwarding path. The RSVP signaling messages are forwarded on the default path. The labels are assumed to have only unidirectional significance. In other words, there exists a separate label space for each direction of flow on a link. Moreover, the downstream LSR is chosen to be the label space owner (allocator) on a link. The single owner approach keeps the label usage simple and manageable. If a label space had more than one owner, it would require that the owners synchronize their use of the labels or the space would have to be partitioned amongst the owners. For flexibility, the proposed extension to RSVP also supports the concept of "upstream on demand" allocation as described in [3]. In this method, the upstream LSR allocates labels when demanded by a downstream LSR. This enables co-existence with other protocols that consume labels. 3. Motivation In this section, we discuss why the RSVP protocol is ideal for establishing a label switched path for reserved flows. One motivating factor for using RSVP is that mapping the network- layer QoS request to a layer 2 virtual connection is simple. The RESV message carries the QoS requested by the receiver(s) of the RSVP flow. For example, this could correspond to one of the Integrated Service classes described in [6-8]. This QoS information is needed when layer 2 labels are set up and spliced; i.e., when the resource reservations are made. Otherwise, the LSP establishment protocol would have to carry its own QoS entity and/or map the label setup to RSVP tables at each LSR hop. Another motivating reason for extending RSVP is multicast support. RSVP is designed to scale well for multicast sessions requiring resource reservation. RSVP also allows receivers to join existing sessions with different QoS requirements. An independent LSP establishment protocol should be able to handle such session "joins" equally well. With the RSVP protocol the receivers can make sender selection through the provision of different filter styles. In this, multiple sender flows (as chosen by the receivers) in a RSVP session can be associated with a single reservation. In other words, sender flows in a RSVP session can be merged into a single downstream reservation. A new LSP establishment protocol would have to support a similar mechanism for seamless interoperability with the RSVP protocol. Viswanathan, et al. Expires: January 1998 [Page 3] Internet-Draft Soft State Switching August 1997 Finally, any mechanism for setup of LSPs would, in any case, require extensive interfacing with the RSVP protocol and/or its state tables. Due to these reasons, it is best if RSVP can be extended without changing its existing mechanics, to provide support for setting up the switched path for RSVP flows. This need not be viewed as "piggy-backing" another protocol on RSVP, but rather, a natural extension to RSVP to provide QoS in a MPLS environment. 4. L2 Label Exchange Mechanism The proposed extension to RSVP calls for adding a new object to carry MPLS label information within RESV, PATH, and RESVERR messages. The egress LSR, say LSR A, (i.e. the "last" node in the MPLS environment, or the LSR through which the RSVP flow exits the MPLS environment) will place this object in any RESV message that it sends to the PHOP LSR for a flow (as stored in the Path state for this flow) -- call this LSR B. The RESV message is sent to LSR B via the default routed path. If LSR B rejects the reservation (i.e., if the reservation is rejected by either policy or admission control, or due to an error), it then forwards a RESVERR message with the appropriate error code to LSR A. The RESVERR message includes the MPLS label object received from LSR A (RESVERR nack). Receipt of the RESVERR nack indicates that the upstream LSR will not forward the reserved flow on the requested LSP. In the event that this occurs, LSR A may choose to release its reservation or it may choose to classify and forward packets received on the default path from LSR B at the network layer. If LSR B accepts the reservation, it will use the label in the RESV message to setup a LSP to LSR A (in this case, the egress LSR) on the outgoing interface. The QoS for this LSP corresponds to a mapping of the Integrated Service class specified in the RESV message to an appropriate set of QoS values for the layer 2 technology. LSR B will forward a PATH message for the reserved flow to LSR A which includes the MPLS label object allocated by LSR A (PATH ack). This MPLS label object will also be included in all subsequent PATH messages for the reserved flow sent to LSR A while the reservation remains in place. LSR B will then choose a new label on the incoming interface through which the RSVP flow enters the LSR, and send this label to its own PHOP, LSR C, by passing the new MPLS label object in a RESV message. LSR B may optimistically choose to splice the label on the incoming interface from LSR C to the label on the outgoing interface to LSR A by modifying its layer 2 label swap table, or it may choose to wait for the receipt of a PATH ack from LSR C. If LSR C accepts the Viswanathan, et al. Expires: January 1998 [Page 4] Internet-Draft Soft State Switching August 1997 reservation then it will forward a PATH ack to LSR B. If LSR C rejects the reservation, it will then send a RESVERR nack to LSR B. LSR B has the option of releasing its reservation (by transmitting a RESVERR nack downstream to LSR A) or of classifying the packets of the reserved flow on the default path from LSR C and forwarding them on the previously established QoS LSP to LSR A, while sending a RESVERR message without the label object to LSR A. In the event of success at each PHOP LSR, the RESV will eventually reach the ingress LSR (the LSR through which the RSVP flow enters the MPLS environment). The ingress LSR will make necessary classifier entries to forward packets for this flow through the LSP identified by the label in the RESV message received from downstream. An ingress LSR will delete the MPLS label object before forwarding a RESV message to any of its PHOP nodes. The labels used for a RSVP reservation are released whenever the RSVP reservation is torn down or is timed-out. Using this process, an end-to-end switched path is established for an RSVP flow through a MPLS network. The data packets from the RSVP flow are forwarded via this switched path, while RSVP control messages continue to use the default paths between LSRs. 5. Partial QoS Paths The procedure described in Section 4 must be clarified in the event that the reserved traffic from a sender (source address/port) is transported initially across a LSP from the ingress to the egress LSR that has been established by an IP switching protocol [2-4, 9]. In this case, the best-effort packets are not forwarded along the hop- by-hop default path and processed at the network layer within each intermediate LSR, but are instead forwarded along a series of spliced label switched hops, and hence are not normally available for packet classification. If a reservation should succeed all the way back to the ingress LSR for a reserved flow, that LSR will classify the packets from the flow and move them onto the new ingress-to-egress QoS LSP. However, if the reservation succeeds on some of the LSRs on the reverse path from the egress but not all the way back to the ingress, then QoS for the flow cannot be achieved on the path through the LSRs which accepted the reservation unless the farthest upstream LSR which accepted the reservation unsplices the best-effort LSP, classifies the packets of the reserved flow, and forwards them on the QoS LSP to the egress LSR. Note that the default behavior of RSVP is to allow partial QoS paths from the receiver back towards the sender by allowing reservations which have succeeded at a node to remain in Viswanathan, et al. Expires: January 1998 [Page 5] Internet-Draft Soft State Switching August 1997 place in the event that the reservation fails further upstream. Because it is likely that some LSRs will lack sufficient network- layer forwarding capability to unsplice and route many best-effort LSPs simultaneously, the behavior of a LSR which has accepted a reservation, established a QoS LSP on the appropriate downstream interface(s), but subsequently receives a RESVERR nack from upstream should be configurable. In the event that the LSR chooses to classify the reserved flow at the network layer by unsplicing the best-effort LSP, there are no required changes to the protocol exchange described in Section 4. However, if the LSR chooses to release the reservation, then it should transmit a RESVERR nack downstream and establish blockade state for the reservation. Subsequent reservations for the flow with an equal or greater flowspec should be rejected and blockaded until the blockade timer expires. This prevents the establishment of a potentially unused QoS LSP through the LSR until the blockade timer for the reservation expires. Reservations for the flow with a strictly smaller flowspec can be accepted and propagated upstream. Receipt of a RESVERR nack should be taken as definitive, even if it immediately follows (or precedes) a PATH ack. Another alternative is to continue to propagate RESV messages and labels all the way to the ingress LSR, with an indication that the reservation has failed somewhere downstream, and that QoS need not be provided for the upstream segments of the LSP. These RESV messages would terminate at the ingress LSR without generating a RESVERR message on any node upstream of the reservation failure. This approach would entail modifications to the RSVP message processing rules. 6. Merging RSVP scales by merging reservation requests as they propagate upstream towards senders, and by merging QoS handling state as the data flows propagate downstream towards the receivers. The ability to perform merging in a LSR environment is dependent on the switching capabilities of the LSRs. There are several switching technologies available today (ATM, Frame Relay etc.) and perhaps more in the future. Moreover, the capabilities of a switch of a certain technology vary from vendor to vendor. Three basic characteristics are identified that determine how the underlying switching technology can be used in conjunction with this proposal to address merging of flows under the appropriate environment. They are: Viswanathan, et al. Expires: January 1998 [Page 6] Internet-Draft Soft State Switching August 1997 o Attribute A: Can correctly merge several upstream LSPs into a single downstream LSP ("VC merge"). Frame switches are typically able to do this in a straightforward manner. However, for ATM switches without appropriate functionality built in, cells from different AAL SDUs may become interleaved on the outgoing VC (LSP), thus corrupting the higher-layer information. o Attribute B: Can treat a set of labels as a single entity for QoS purposes. A switch with this property is able to treat all traffic from a set of labels in a like manner for purposes of scheduling, fair queueing etc. For example, an ATM switch that performs per-class queueing would assign all the VCs from a given set to a particular class. Then, cells from all the VCs in the sets would receive the QoS corresponding to that class. o Attribute C: Can demultiplex senders flows in a single LSP into a separate LSP for a sender. For example, using the label stack for L2 tunneling [3,4]. One logical candidate for flow merging would be support for shared explicit and wildcard reservations, where resources are shared among a set of multiple senders. The difficulty this poses is the potential need to demultiplex senders from the merged flow for downstream receivers which have made reservations for only a subset of the senders, as described in [10]. Merging of multiple sender LSPs into a single LSP (Attribute A) requires support for Attribute C in the LSRs to permit sender demultiplexing. Support for Attribute B permits LSRs to share QoS resources among a group of per-sender LSPs while still facilitating sender demultiplexing. 7. Multicast Support 7.1 Packet Replication In order to support multicast sessions, at split points within the MPLS network, where data from upstream LSRs splits into multiple downstream flows, the LSR can perform the required duplication (at layer 2) of packets by utilizing the hardware multicast capability (for example, point-to-multipoint VC) of the switch, if available. Otherwise, the flow has to be processed at the network layer and multicast in the normal manner. Note that network layer forwarding is interoperable with all switch types. 7.2 Packet Duplication In configurations where a per-source or shared multicast tree is Viswanathan, et al. Expires: January 1998 [Page 7] Internet-Draft Soft State Switching August 1997 mapped to a point-to-multipoint LSP rooted at an ingress LSR and terminating at each egress LSR with one or more downstream receivers, packet duplication can occur if receivers make a reservation for a particular flow initially being carried on the multicast LSP. This occurs because the flow's packets are carried on both the best-effort and QoS LSP, which are delivered to each egress LSR on the multicast tree. This problem can be avoided if the packets of the reserved flow are removed from the best-effort multicast LSP and carried only on the QoS LSP. 7.3 Unreserved Receivers When none of the receivers have made a reservation, the multicast session may flow through the default multicast LSP as best-effort traffic. But as soon as a receiver makes a reservation, and packets from the reserved flow are removed from the best-effort LSP, the data flow may stop to receivers that have not made a reservation. The receivers without a reservation only get PATH messages but no data (even at best-effort). This problem can be addressed in several different ways determined by the switch architecture. This problem can be avoided for switches that support Attribute A. They can add the default best-effort LSP for the (source/)group as a branch in the point-to-multipoint per-flow QoS LSP by merging the QoS LSP back onto the best-effort LSP on those branches of the tree where there are no downstream receivers. If the switch architecture allows adding the local IP-CP to the point-to-multipoint QoS LSP, then the IP-CP can multicast the packets only to those interfaces from which there is no reservation but which are listed in the multicast table. If the switch architecture does not support Attribute A, and can not efficiently perform the multicast forwarding in the IP-CP, then one approach is to build the per-flow QoS LSP to all egress LSRs on the multicast tree (whether they forwarded a RESV or not). The QoS on each branch of this point-to-multipoint LSP would be configured based on the amount of resources reserved on that branch. For best-effort branches, a UBR-like QoS would be used. The LSP construction could be performed under the control of the ingress LSR rooting the multicast tree. Another way to construct the LSP is to use a PATH message to perform the LSP establishment from the node downstream of which there are interfaces through which no reservation has been received. This would be initiated whenever there is at least one reservation in place at the node for the RSVP flow. This may not work in environments where upstream label allocation is not permitted. Viswanathan, et al. Expires: January 1998 [Page 8] Internet-Draft Soft State Switching August 1997 7.4 Shared Media Label Allocation This memo describes a RSVP extension for the MPLS environment where the downstream LSR is the label space owner. As discussed in [5] and [10], this can lead to an allocation deadlock if the downstream receivers on a shared media subnet cannot agree on the value for the label. One approach suggested in [10] is to permit a receiver to suggest a label by passing one upstream in a RESV message, but to allow the upstream node to select the definitive label and pass it downstream within a PATH ack. Another alternative is to support upstream on demand allocation. In this case, a receiver forwards a RESV message using a NULL MPLS label object to indicate a request for label allocation. The upstream LSR will respond with a label for the RSVP flow in the PATH message to the downstream neighbors. The downstream receivers are responsible for using the label selected by the upstream node, and should include this label in all subsequent RESV messages. In the event that the label selected upstream is out-of-range for a particular receiver, then the receiver can forward a new RESV message with a NULL MPLS label object to trigger a new label allocation. Note that a PATHERR message is not suitable for communicating this error since it propagates all the way back to the sender. The flexibility of upstream on demand label allocation is also useful in non-shared media environments as it allows co-existence with other IP switching protocols. 8. TTL Decrement When IP packets flow through a switched path, the TTL value in the IP header cannot be decremented. The decrementing of the TTL value is used to delete packets in a routing loop to avoid/reduce congestion. For this purpose, the proposed LSR Hop Count Object carries a hop- count that counts the number of consecutive LSR hops. The LSRs increment the hop-count only if there is a switched path for that sender flow through that LSR. All LSRs maintain the hop count in the Path state. Only the egress LSR on which the LSP terminates would use the count to decrement the TTL on packets for that sender flow. The LSRs of a switching technology that have a TTL equivalent in the layer 2 header may choose not to use the LSR Hop Count Object. 9. Adjacency LSR neighbors need some mechanism to establish adjacencies. This is required because the neighbors need to exchange the label range for Viswanathan, et al. Expires: January 1998 [Page 9] Internet-Draft Soft State Switching August 1997 correct label allocation. They also need to elect the label allocator. The current version of this memo does not propose any extension to the RSVP protocol for this mechanism. It is assumed that adjacency would be established by another protocol (as proposed in [2], [3] or [4]) and such information would be made available to the RSVP module. In the absence of such a mechanism the LSRs would have to be configured with the required information to operate as described in this memo. 10. Object Formats This section describes the object formats for the proposed extension. The label objects for ATM LSRs are defined below. Label formats for additional link-layer media will be proposed in a future revision of this memo. o LSR HOP COUNT object: Class = x, C-Type = 1 +-------------+-------------+-------------+-------------+ | Hop Count | Reserved | +-------------+-------------+-------------+-------------+ Hop Count Counts the length (in LSR hops) of the switched path. o NULL Label Object: Class = y, C-Type = 1 o ATM RESV Label object: Class = y, C-Type = 2 +-------------+-------------+-------------+-------------+ | IPv4 SrcAddress (4 bytes) | +-------------+-------------+-------------+-------------+ | ////// | ////// | SrcPort | +-------+-----+-------------+-------------+-------------+ | Flags | VPI | VCI | +-------+-------------------+-------------+-------------+ // // +-------------+-------------+-------------+-------------+ | IPv4 SrcAddress (4 bytes) | +-------------+-------------+-------------+-------------+ | ////// | ////// | SrcPort | +-------+-----+-------------+-------------+-------------+ | Flags | VPI | VCI | +-------+-------------------+-------------+-------------+ IPv4 SrcAddress IPv4 address of the sender. Viswanathan, et al. Expires: January 1998 [Page 10] Internet-Draft Soft State Switching August 1997 Flags - 4 bits 0x01 - Implies that the reservation is not in place in the node forwarding the RESVERR message and that the reserved traffic is not being forwarded via the VC (RESVERR nack). VPI - 12 bits Virtual Path Identifier. If less than 12 bits are significant, then it is right justified in this field. VCI - 16 bits Virtual Circuit Identifier. If less than 16 bits are significant, then it is right justified in this field. o ATM PATH Label object: Class = y, C-Type = 3 +-------+-------------------+-------------+-------------+ | Flags | VPI | VCI | +-------+-------------------+-------------+-------------+ Flags - 4 bits 0x01 - Implies that the PATH message is in response to an upstream on demand label allocation and may not be propagated any further. 0x02 - Implies that the PATH message is in response to a RESV message carrying a RESV Label object (PATH ack) and may not be propagated any further. VPI - 12 bits Virtual Path Identifier. If less than 12 bits are significant, then it is right justified in this field. VCI - 16 bits Virtual Circuit Identifier. If less than 16 bits are significant, then it is right justified in this field. The IPv6 extension and error codes will be defined in a later revision of this memo. The reader may have noticed that the new ATM RESV Label object has duplicated information already present in the FILTER_SPEC object. Another approach could be to extend the FILTER_SPEC object definition to carry the link-layer labels or insert the label object following the FILTER_SPEC object. Viswanathan, et al. Expires: January 1998 [Page 11] Internet-Draft Soft State Switching August 1997 11. Security Considerations Security considerations are not discussed in this memo. 12. Acknowledgements The authors wish to acknowledge Shailendra Bhatnagar, Nancy Feldman, Liang Li, Steve Nadas, and Bruce Sinclair for their input. 13. References [1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. Internet Draft, draft-ietf-rsvp-spec-16, June 1997. [2] P. Newman, W. L. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall, Ipsilon Flow Management Protocol Specification for IPv4, Version 1.0. Internet RFC 1953, May 1996. [3] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, D. Farinacci, Tag Switching Architecture - Overview. Internet Draft, draft-rekhter-tagswitch-arch-00.txt, January 1997. [4] A. Viswanathan, N. Feldman, R. Boivie, R. Woundy, ARIS: Aggregated Route-Based IP Switching. Internet Draft, draft-viswanathan-aris-overview-00.txt, March 1997. [5] D. Farinacci, Partitioning Tag Space among Multicast Routers on a Common Subnet. Internet Draft, draft-farinacci-multicast-tag-part-00.txt, December 1996. [6] S. Shenker, C. Partridge, R. Guerin, Specification of Guaranteed Quality of Service. Internet Draft, draft-ietf-intserv-guaranteed-svc-08.txt, February 1997. [7] J. Wroclawski, Specification of the Controlled-Load Network Element Service. Internet Draft, draft-ietf-intserv-ctrl-load-svc-05.txt, May 1997. [8] F. Baker, R. Guerin, D. Kandlur, Specification of Committed Rate Quality of Service. Internet Draft, draft-ietf-intserv-commit-rate-svc-00.txt, June 1996. [9] K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, Viswanathan, et al. Expires: January 1998 [Page 12] Internet-Draft Soft State Switching August 1997 T. Jinmei, H. Esaki, Flow Attribute Notification Protocol (FANP) Specification, Internet Draft, draft-rfced-info-nagami-00.txt, February 1997. [10] B. Davie, Y. Rekhter, E. Rosen, Use of Label Switching With RSVP, Internet Draft, draft-davie-mpls-rsvp-00.txt, May 1997. [11] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, A. Viswanathan, A Framework for Multiprotocol Label Switching, Internet Draft, draft-ietf-mpls-framework-00.txt, May 1997. Author's Address Arun Viswanathan IBM Corporation 17 Skyline Drive Hawthorne, NY 10532 Phone: +1 (914) 784-3273 Email: arunv@vnet.ibm.com Vijay Srinivasan IBM Corporation PO Box 12195 Research Triangle Park, NC 27709 Phone: +1 (919) 254-2730 Email: vijay@raleigh.ibm.com Steven Blake IBM Corporation PO Box 12195 Research Triangle Park, NC 27709 Phone: +1 (919) 254-2030 Email: slblake@raleigh.ibm.com Viswanathan, et al. Expires: January 1998 [Page 13]