Internet Draft MPLS Working Group A. Conta (Lucent) INTERNET-DRAFT P. Doolan (Cisco) September 1997 Use of Label Switching With Frame Relay Specification draft-conta-mpls-fr-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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a "working draft" or "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). Distribution of this memo is unlimited. Abstract This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. A Multiprotocol Label Switching Architecture is described in [ARCH]. MPLS enables the use of Frame Relay Switches as Label Switching Routers (LSRs). The Frame Relay Switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is based on the results of these routing algorithms. No Frame Relay- specific routing is needed. Conta Expires in six months [Page 1] INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997 Table of Contents Status of this Memo.........................................1 Table of Contents...........................................2 1. Introduction................................................3 2. Terminology.................................................3 3. Special Characteristics of Frame Relay Switches.............4 4 Label Switching Control Component for Frame Relay...........4 5 Hybrid Switches (Ships in the Night) ......................5 6 Use of DLCIs ..............................................6 7 Label Allocation and Maintenance Procedures ................7 7.1 Edge LSR Behavior......................................7 7.2 Efficient use of label space.. ......................10 8 Label Encapsulation ......................................10 9 Security Considerations ..................................11 10 Acknowledgments ..........................................11 11 References ...............................................11 12 Authors' Addresses .......................................12 Conta Expires in six months [Page 2] INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997 1. Introduction A Multiprotocol Label Switching Architecture is described in [ARCH]. It is possible to use Frame Relay switches as Label Switching Routers. Such Frame Relay switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their forwarding is based on the results of these routing algorithms. No specific Frame Relay routing is needed. Frame Relay permanent virtual circuits (PVCs) could be configured to carry label switching based traffic. The traffic through the PVCs would be forwarded based on network layer routing information. When a Frame Relay switch is used for label switching, the label on which forwarding decisions are based is carried in the DLCI field of the Frame Relay data link layer header of a frame. In this case other labels, if the packet is multiply labeled, are carried in the generic MPLS encapsulation defined in [STACK]. Although we deal here with the use of DLCIs as MPLS Labels and the transformation thereby of FR Switches into MPLS switches we note that MPLS traffic could be carried over FR PVCs using the techniques of RFC1490. The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in RFC 2119. 2. Terminology LSR A Label Switching Router (LSR) is a device which implements the label switching control and forwarding components described in [ARCH]. LC-FR A label switching controlled Frame Relay (LC-FR) interface is a Frame Relay interface controlled by the label switching control component. Packets traversing such an interface carry labels in the DLCI field. FR-LSR A FR-LSR is an LSR with a number of LC-FR interfaces which forwards frames between these interfaces using labels carried in Conta Expires in six months [Page 3] INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997 the DLCI field. FR-LSR cloud A FR-LSR cloud is a set of FR-LSRs which are mutually interconnected by LC-FR interfaces. Edge Set The Edge Set of an FR-LSR cloud is the set of LSRs which are connected to the cloud by LC-FR interfaces. 3. Special characteristics of Frame Relay Switches While the label switching architecture permits considerable flexibility in LSR implementation, a FR-LSR is constrained by the capabilities of the (possibly pre-existing) hardware and the restrictions on such matters as frame format imposed by RFC 1490, or Frame Relay standards (Q.922, etc). Because of these constraints, some special procedures are required for FR-LSRs. Some of the key features of Frame Relay switches that affects their behavior as LSRs are: - the label swapping function is performed on fields (DLCI) in the frame's Frame Relay data link header; this dictates the size and placement of the label(s) in a packet. The size of the DLCI field can be 10 (default), 17, or 24 bits, and it can span two, three, or respectively four bytes in the header. - congestion control is performed by each node based on parameters that are passed at circuit creation. Flags in the frame headers may be set as a consequence of congestion, or exceeding the contractual parameters of the circuit. - multipoint-to-point and multipoint-to-multipoint VCs are generally not supported. - there is generally no capability to perform a `TTL-decrement' function as is performed on IP headers in routers. This document describes ways of applying label switching to Frame Relay switches which work within these constraints. Conta Expires in six months [Page 4] INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997 4. Label Switching Control Component for Frame Relay To support label switching a Frame Relay Switch must implement the control component of label switching. This consists primarily of label allocation and maintenance procedures. Label binding information may be communicated by several mechanisms, one of which is the Label Distribution Protocol (LDP) [LDP]. Since the label switching control component uses information learned directly from network layer routing protocols, this implies that the switch must participate as a peer in these protocols (e.g., OSPF, IS-IS). In some cases, LSRs make use of other protocols (e.g. RSVP, PIM, BGP) to distribute label bindings. In these cases, a Frame Relay LSR would need to participate in these protocols. Frame Relay permanent virtual circuits (PVCs) can be used to carry MPLS traffic using the encapsulation techniques described in RFC1490. In such a case the DLCIs allocated for the PVCs will be distributed as MPLS labels by LDP. In the case where Frame Relay circuits are established via LDP, or RSVP, with no involvement from traditional Frame Relay mechanisms, it is assumed that circuit establishing contractual information such as input/output maximum frame size, incoming/outgoing requested/agreed throughput, incoming/outgoing acceptable throughput, incoming/outgoing burst size, incoming/outgoing frame rate, used in transmitting, and congestion control could be passed to the FR-LSRs through RSVP. It is also assumed that congestion control and frame header flagging as a consequence of congestion, would be done by the FR-LSRs in a similar fashion as for traditional Frame Relay circuits. Control and state information for the circuits based on MPLS could be communicated through LDP. Support of label switching on a Frame Relay switch does not require the switch to support the Frame Relay control component defined by the ITU (I.451, Q.922) and Frame Relay Forum (e.g., UNI, NNI). A FR- LSR may optionally support and respond to LMI commands. 5. Hybrid Switches (Ships in the Night) The existence of the label switching control component on a Frame Conta Expires in six months [Page 5] INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997 Relay switch does not preclude the ability to support the Frame Relay control component defined by the ITU and Frame Relay Forum on the same switch and the same interfaces. The two control components, label switching and the ITU/Frame Relay Forum defined, would operate independently. Definition of how such a device operates is beyond the scope of this document. However, only a small amount of information needs to be consistent between the two control components, such as the portions of the DLCI space which are available to each component. 6. Use of DLCIs Label switching is accomplished by associating labels with routes and using the label value to forward packets, including determining the value of any replacement label. See [ARCH] for further details. In a FR-LSR, the current (top) MPLS label is carried in the DLCI field of the Frame Relay data link layer header of the frame. Just as in conventional Frame Relay, for a frame arriving at an interface, the DLCI carried by the Frame Relay data link header is looked up in the Label Information Base, replaced with the correspondent output DLCI, and transmitted on the outgoing interface (forwarded to the next hop node). Note that the current label information is also carried in the top of the label stack. In the top level entry, only the TTL field is truely significant. For two connected FR-LSRs, a full-duplex connection must be available for LDP. By default, the DLCI for the LDP VC is assigned a value of [TBD]. With the exception of this reserved value, the DLCI values used in the two directions of the link may be treated as belonging to two independent spaces, i.e. VCs may be half-duplex, each direction with its own DLCI. In case of DLCI aggregation (DLCI space conservation), half-duplex (unidirectional) VCs are desired, since a "many to few" aggregation is possible in one direction but not in reverse. The allowable ranges of DLCIs are always communicated through LDP. Note that the range of DLCIs used for labels depends on the size of the DLCI field, which can be 10 (default), 17, or 24 bits. Conta Expires in six months [Page 6] INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997 7 Label Allocation and Maintenance Procedures FR-LSRs use the downstream-on-demand allocation mechanism described in [ARCH]. 7.1 Edge LSR Behavior Consider a member of the Edge Set of a FR-LSR cloud. Assume that, as a result of its routing calculations, it selects a FR-LSR as the next hop of a certain route, and that the next hop is reachable via a LC- Frame Relay interface. The Edge LSR uses LDP's BIND_REQUEST to request a label binding from the next hop. The hop count field in the request is set to 1. Once the Edge LSR receives the label binding information, the label is used as an outgoing label. The binding received by the edge LSR may contain a hop count, which represents the number of hops a packet will take to cross the FR-LSR cloud when using this label. The edge LSR may either - use this hop count to decrement the TTL of packets before transmitting them over the cloud - decrement the TTL of packets by one before transmitting them over the cloud. The choice between these two options should be made based on local configuration. When a member of the Edge Set of the FR-LSR cloud receives a label binding request from a FR-LSR, it allocates a label, creates a new entry in its Label Information Base (LIB), places that label in the incoming label component of the entry, and returns (via LDP) a binding containing the allocated label back to the peer that originated the request. It sets the hop count in the binding to 1. When a routing calculation causes an Edge LSR to change the next hop for a route, and the former next hop was in the FR-LSR cloud, the Edge LSR should notify the former next hop (via LDP) that the label binding associated with the route is no longer needed. When a Frame Relay-LSR receives (via LDP) a label binding request for a certain route from a peer connected to the FR-LSR over a LC-FR interface, the FR-LSR takes the following actions: - it allocates a label, creates a new entry in its Label Conta Expires in six months [Page 7] INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997 Information Base (LIB), and places that label in the incoming label component of the entry; - it requests (via LDP) a label binding from the next hop for that route; - it returns (via LDP) a binding containing the allocated incoming label back to the peer that originated the request. The hop count field in the request that the FR-LSR sends (to the next hop LSR) is set to the hop count field in the request that it received from the upstream LSR plus one. Once the FR-LSR receives the binding from the next hop, it places the label from the binding into the outgoing label component of the LIB entry. The FR-LSR may choose to wait for the request to be satisfied from downstream before returning the binding upstream (a "conservative" approach). In this case, the FR-LSR increments the hop count it received from downstream and uses this value in the binding it returns upstream. If the value of the hop count equals MAX_HOP_COUNT the FR-LSR should notify the upstream neighbor that it could not satisfy the binding request. Alternatively, the FR-LSR may return the binding upstream without waiting for a binding from downstream (an "optimistic" approach). In this case, it uses a reserved value for hop count in the binding, indicating that it is unknown. The correct value for hop count will be returned later, as described below. Since both the conservative and the optimistic approach has advantages and disadvantages, this is left as an implementation choice. Note that a FR-LSR, or a member of the edge set of a FR-LSR cloud, may receive multiple binding requests for the same route from the same FR-LSR. It must generate a new binding for each request (assuming adequate resources to do so), and retain any existing binding(s). For each request received, a FR-LSR should also generate a new binding request toward the next hop for the route. When a routing calculation causes a FR-LSR to change the next hop for a route, the FR-LSR should notify the former next hop (via LDP) that the label binding associated with the route is no longer needed. When a LSR receives a notification that a particular label binding is no longer needed, the LSR may deallocate the label associated with Conta Expires in six months [Page 8] INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997 the binding, and destroy the binding. In the case where a FR-LSR receives such notification and destroys the binding, it should notify the next hop for the route that the label binding is no longer needed. If a LSR does not destroy the binding, it may re-use the binding only if it receives a request for the same route with the same hop count as the request that originally caused the binding to be created. When a route changes, the label bindings are re-established from the point where the route diverges from the previous route. LSRs upstream of that point are (with one exception, noted below) oblivious to the change. Whenever a LSR changes its next hop for a particular route, if the new next hop is a FR-LSR or a member of the edge set reachable via a LC-FR interface, then for each entry in its LIB associated with the route the LSR should request (via LDP) a binding from the new next hop. When a FR-LSR receives a label binding from a downstream neighbor, it may already have provided a corresponding label binding for this route to an upstream neighbor, either because it is operating optimistically or because the new binding from downstream is the result of a routing change. In this case, it should extract the hop count from the new binding and increment it by one. If the new hop count is different from that which was previously conveyed to the upstream neighbor (including the case where the upstream neighbor was given the value `unknown') the FR-LSR must notify the upstream neighbor of the change. Each FR-LSR in turn increments the hop count and passes it upstream until it reaches the ingress Edge LSR. If at any point the value of the hop count equals MAX_HOP_COUNT, the FR- LSR should withdraw the binding from the upstream neighbor. Whenever a FR-LSR originates a label binding request to its next hop LSR as a result of receiving a label binding request from another (upstream) LSR, and the request to the next hop LSR is not satisfied, the FR-LSR should destroy the binding created in response to the received request, and notify the requester (via LDP). If a FR-LSR receives a binding request containing a hop count that equals MAX_HOP_COUNT, no binding should be established and an error message should be returned to the requester. When a LSR determines that it has lost its LDP session with another LSR, the following actions are taken. Any binding information learned via this connection must be discarded. For any label bindings that were created as a result of receiving label binding requests from the peer, the LSR may destroy these bindings (and deallocate labels associated with these binding). Conta Expires in six months [Page 9] INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997 7.2 Efficient use of label space The above discussion assumes that an edge LSR will request one label for each prefix in its routing table that has a next hop in the FR- LSR cloud. In fact, it is possible to significantly reduce the number of labels needed by having the edge LSR request instead one label for several routes. Use of many-to-one mappings between routes (address prefixes) and labels using the notion of Forwarding Equivalence Classes (as described in [ARCH]) provides a mechanism to conserve the number of labels. Note that conserving label space may be restricted in case the frame traffic requires Frame Relay fragmentation. The issue is that Frame Relay fragments must be transmitted in sequence, i.e. fragments of distinct frames must not be interleaved. If the fragmenting FR-LSR ensures the transmission in sequence of all fragments of a frame, without interleaving with fragments of other frames, then label conservation (aggregation) can be performed. In the case where the label space is to be conserved, it is desirable to use half-duplex (unidirectional) VCs, since a "many to few" aggregation is possible in one direction but not in reverse. 8. Label Encapsulation By default, all labeled packets should be transmitted with the generic label encapsulation as defined in [STACK], using the frame relay encapsulation mechanisms described in RFC 1490, and protocol types defined in [STACK]. Rules regarding the construction of the label stack, and error messages returned to the frame source are also described in [STACK]. Since the value at the top of the label stack is determined from the DLCI field, the information carried in the label stack for the current label is significant only for the TTL field. The generic encapsulation contains n labels for a label stack of depth n, where the only significant field in the current label stack entry is TTL. This means that for one level of labels the generic encapsulation consists of a label carrying a TTL only. Conta Expires in six months [Page 10] INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997 9. Security Considerations This section looks at the security aspects of: - frame traffic - label distribution. Altering by accident or forgery an existent label in the DLCI field of the Frame Relay data link layer header of a frame or one or more fields in a potentially following label stack affects the forwarding of that frame. The label distribution mechanism can be secured by applying the appropriate level of security to the underlying protocol carrying label information - authentication or encryption - see [LDP]. 10. Acknowledgments This document is derived from the Label Switching over ATM document [ATM]. Thanks for the extensive reviewing and constructive comments from (in alphabetical order) Dan Harrington, Milan Merhar, Martin Mueller. 11. References [RFC-1490] T. Bradley, C. Brown, A. Malis "Multiprotocol Interconnect over Frame Relay" [ARCH] "Proposed Architecture for MPLS" in "draft-rosen-mpls-00.txt" by Rosen, Callon, Vishwanathan. [LDP] Label Distribution Protocol - work in progress. [STACK] "Label Switching: Label Stack Encodings" "draft-rosen-tag- stack-02.txt" by Rosen et al. [ATM] "draft-davie-tag-switchingatm-01.txt" by Davie et al. Conta Expires in six months [Page 11] INTERNET-DRAFT Use of Label Switching With Frame Relay September 15, 1997 Authors' Addresses: Alex Conta Paul Doolan Lucent Technologies Inc. Cisco Systems, Inc 300 Baker Ave, Suite 100 250 Apollo Drive Concord, MA 01742 Chelmsford, MA, 01824 +1-508-287-2842 +1-508-244-8917 E-mail: aconta@lucent.com E-mail: pdoolan@cisco.com Conta Expires in six months [Page 12]