Internet Draft MPLS Working Group G.Wright Internet Draft S. Ballarte Expiration Date: September 2000 T. Pearson Nortel Networks March 2000 CR-LDP Extensions for Interworking with RSVP-TE draft-wright-mpls-er-interwork-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The development of two explicit routing protocols RSVP-TE[RSVP-TE] and CR-LDP[CR-LDP] within MPLS has created the need to allow interworking between the two MPLS. Explict routed (ER) label switch paths do not have a prior knowledge of the ER signaling method in use within the various links comprising a domain. In an integrated environment an ER path may crisscross between RSVP-TE and CR-LDP nodes numerous times. This document describes the procedures for the establishment of an RSVP-TE originated LSP transiting or terminating within a CR-LDP domain and the procedures for the establishment of a CR-LDP originated LSP terminating within an RSVP-TE domain. 2. Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 3. Introduction Wright, et al. 1 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 Traffic engineering has been identified as one of the fundamental advantages of MPLS [MPLS ARCH]. MPLS can be used to simplify traffic engineering by the use of a label to infer an explicit route through a network. Label Switched Routers (LSRs) are informed of the meaning of the labels via a label distribution protocol. The MPLS architecture document [MPLS ARCH] explicitly recognizes that a single label distribution protocol does not exist. A number of protocols have been defined for the purpose of distributing MPLS labels, including CR-LDP [CR-LDP] and extensions to RSVP [RSVP-TE]. This document is a specification for the functionality which is supported by the interworking of the CR-LDP and RSVP-TE label distribution protocols. This document provides a framework to understand the interoperable components and the behaviors, which can be expected in a network utilizing both signaling protocols. Interworking between other MPLS label distribution methodologies is For Future Study. The basic interworking scenarios between MPLS LSRs in a network supporting CR-LDP and RSVP-TE are: (1) RSVP-TE -> CR-LDP (2) CR-LDP -> RSVP-TE (3) RSVP-TE -> CR-LDP -> RSVP-TE (4) CR-LDP -> RSVP-TE -> CR-LDP Scenarios 1, 2 are mutually exclusive and represent the minimum interworking requirement for bi-directional communications. Scenarios 3 and 4 use the same signaling protocol at the origination and termination links of the explicit path, with a dissimilar signaling protocol in the transit network. Scenario 3 is the target for this interworking specification. Scenario 4, while also technically possible, is beyond the scope of this draft. The motivation for this document is as follows: i) Given that multiple label distribution protocols are envisioned as part of an MPLS network [MPLS ARCH] then it is reasonable to expect that in any single network, multiple MPLS label distribution methodologies will be deployed. This document addresses the interworking aspects for the two traffic engineering label distribution protocols, CR-LDP and RSVP-TE. ii) In a large MPLS based network it is not reasonable to expect an end user device or service to have 'a priori' knowledge of the deployed MPLS-LDP, nor is it reasonable to expect homogeneity of the deployed infrastructure. This document ensures consistent network behavior by defining the interworking Wright, et al. 2 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 functions of network elements, which support CR-LDP and RSVP- TE. iii) The ability to scale the control plane for some MPLS label distribution protocols supporting explicit routes is a recognized issue [RSVP RRED]. This specification addresses one anticipated deployment scenario where RSVP-TE is deployed at the network edges and CR-LDP is deployed to resolve the scalability issue in the network core. Other combinations of MPLS-LDP for scalability are beyond the scope of this specification. 3.1 Reference network D / / +:::::6::::7::::+ Legend :: | | :: :: | | :: : RSVP-TE link A///1-----2----3::::4:::::5///B - CR-LDP link :: | | | :: / Endpoint link (non-mpls) :: | | | :: +:::::8----9----10:::::+ / / C Figure 1: Reference network for interworking scenarios The reference network for RSVP-TE/CR-LDP interworking scenarios is shown in figure 1. Both RSVP-TE and CR-LDP protocols are deployed in this network. Nodes 1,3,4,6,7,8, and 10 contain both RSVP-TE links and CR-LDP links. Nodes 2 and 9 contain CR-LDP links only. A,B, and C are connection endpoints (source or destination). This network identifies the interworking scenarios for RSVP-TE and CR-LDP. Consider the following examples: 1. RSVP-TE to RSVP-TE is required from A->B when using nodes 1, 6, 7, 4, 5 to transit the network. 2. RSVP-TE to CR-LDP interworking is required from A->C when using nodes 1,8,9,10 to transit the network. 3. RSVP-TE to CR-LDP to RSVP-TE interworking is required from A-> B when using nodes 1,8,9,10,5 to transit the network. 4. CR-LDP to RSVP-TE to CR-LDP interworking is required from C-> D when using nodes 7,3,4,10 to transit the network. Wright, et al. 3 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 Scenario 1 is already supported by RSVP-TE. Scenario 2 & 3 is what will be considered in this specification. Scenario 4 is not supported by this specification. The introduction of failure scenarios into the network topology in figure 1 also serves to clarify the requirement for this draft. The failure of a single link in this network can require a previously homogeneous signaling path (e.g., A->C using nodes 1,2,8,9,10 which all support CR-LDP; introduce a failure on the link between nodes 1 and 2 and the restoration path will require RSVP-TE to CR-LDP interworking) to require an interworking function to restore the explicitly routed path. 4. Interworking LSR (IW LSR) CR-LDP and RSVP-TE both achieve the definition of an explicitly routed path between source and destination nodes through the exchange of protocol signaling messages. To allow interworking between the two protocols, a mapping MUST be made between the intrinsically different message exchange processes used by CR-LDP and RSVP-TE. For purpose of RSVP-TE and CRLDP interworking, we define an interworking node LSR (IW LSR) as an LSR that can convert RSVP-TE signaling messages to CRLDP signaling messages (and viceversa) for the purpose of establishing and maintaining explicitly routed label switch paths. An IW LSR MUST map messages with its respective objects or TLVs in a downstream on demand label distribution mode with ordered control. The IW LSR MUST also preserve the soft state nature of the RSVP-TE protocol and at the same time maintain the hard state nature of CR- LDP. How the IW LSR handles the interworking between RSVP-TE and CR- LDP depends very much on the network scenario and state of the LSP. For example, the IW LSR must deal with the different behaviors for CR-LDP and RSVP-TE during LSP establishment and network dynamic changes in resource and topology. During LSP establishment, the IW LSR must do protocol interworking between RSVP_TE and CR-LDP. The IW LSR may only need to do protocol interworking for certain refresh messages if there is a change in the state. Another key area is the handling of error failures across the two protocols. In this case, the IW LSR may not only need to provide protocol interworking but also needs to take action during failure scenarios (i.e. trigger a PathTear or ResvTear message). Procedures on how to handle the hard state and soft state attributes of RSVP-TE and CR-LDP are described in the following section. 5. Message and Parameter Interworking Message and paramter interworking between CR-LDP and RSVP-TE is not a 'one-for-one' substitution. In some cases, several different Wright, et al. 4 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 RSVP-TE messages may be mapped to the same CR-LDP message. In other cases, several different CR-LDP messages may be mapped to the same RSVP-TE message. A similar approach happens when doing object to TLVs mappings and viceversa. The tables below identify the source protocol of the signaled connection in the left hand column and the destination protocol in the right hand column, with appropriate message and parameter mappings defined. The table below defines the message mappings from RSVP-TE to CR-LDP. RSVP-TE Messages CR-LDP Messages ---------------- --------------- Path Message ----> Label Request Message Resv Message ----> Label Mapping Message PathTear Message ----> Label Release Message ResvTear Message ----> Label Withdraw Message PathErr Message ----> Notification Message ResvErr Message ----> Label Release Messages ResvConf Message ----> Not supported The table below defines the message mappings from CR-LDP to RSVP-TE. CR-LDP Messages RSVP-TE Messages ---------------- ---------------- Label Request Message ----> Path Message Label Mapping Message ----> Resv Message Label Release Message ----> PathTear Message Label Withdraw Message ----> ResvTear Message Notification Message ----> PathErr Message Label Abort Request Message ----> PathTear Message The table below defines the RSVP-TE object to CRLDP TLV mapping. RSVP-TE Objects CR-LDP TLVs ---------------- --------------- Integrity ----> local ro RSVP-TE, not required RSVP Hop ----> local to RSVP-TE, not required Time Values ----> local to RSVp-TE, not required Resv Confirm ----> For Future Study Scope ----> local to RSVP-TE, not required Session ----> L3PID TLV, LSPID TLV Session Attribute ----> Preemption TLV Sender Template ----> Aux LSPID TLV, LSPID TLV Explicit Route ----> ER Hop Type TLV Policy Data ----> For Future study STYLE ----> Only FF style supported in this specification, SE style is FFS Adspec ----> For Future Study Sender Tspec ----> Traffic Parameters TLV Flowspec ----> Traffic Parameters TLV Filter Spec ----> Aux LSPID TLV Wright, et al. 5 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 Label ----> Stacked Label TLV Record Route ----> Route Record Diff-Serv ----> Diff-Serv Error Spec ----> Status TLV, Error Node Address TLV The table below defines the CRLDP TLV to RSVP-TE object mapping. CRLDP TLVs RSVP-TE Objects ---------------- --------------- FEC TLV ----> Last hop in Explicit Route object Explicit Route TLV ----> Explicit Route Object Traffic Parameter ----> Sender Tspec, FlowSpec Pinning TLV ----> none, maps to ERO procedures Resource Class ----> not supported Preemption TLV ----> Session Attribute Object Status TLV ----> Error Spec Object 6. Interworking Procedures This specification defines the procedures required by the IW LSR to support RSVP-TE <--> CRLDP interworking within a single MPLS domain. The interworking procedures can be described in three stages: a) LSP Establishment b) LSP Teardown c) Errors/Failures Information available for protocol message mapping depends on the interworking network scenario (see reference network in section 3.1). For each stage, the interworking procedures will be described based on the following scenarios: a) LSPs originating from an RSVP-TE LSR and terminating on a CRLDP LSR (RSVP-TE - CRLDP) b) LSPs originating from a CRLDP LSR and terminating on a RSVP-TE LSR (CRLDP - RSVP-TE) c) LSPs originating and terminating on a RSVP-TE LSR but crossing CRLDP LSR(s) (RSVP-TE - CRLDP - RSVP-TE) In order to support the three networking scenarios mentioned above, the IW LSR MUST be able to handle all procedures as described in the following sections. 6.1 LSP Establishment An explicit path request may require interworking between RSVP-TE and CR-LDP based on networking scenarios a, b and c. To successfully establish an explicit path, messages are mapped between the two signaling protocols via the IW LSR. How the IW LSR handles the protocol exchange depends on the information received by the peer LSRs. The following sections describe the interworking procedures an IW LSR SHOULD follow for LSP establishment. Wright, et al. 6 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 6.1.1. RSVP-TE -> CRLDP LSP Establishment: Description of protocol exchange for scenarios a and c. In scenarios a and c, an explicit path request message is originated from an RSVP-TE LSR and requires interworking to a CR-LDP LSR. The Path message is mapped to a Label Request message at the interworking LSR. The CRLDP destination LSR replies with a Label Mapping message which is mapped by the IW LSR to a Reservation message. The IW LSR SHOULD preserve the soft nature of RSVP-TE. For interworking purposes, the initial Path message SHOULD trigger a corresponding CRLDP Label Request message. Subsequent Path refreshes SHOULD NOT be propagated towards LSR unless a change in the state path occurs. ------- -------- ------- |RSVP TE| | IW LSR | | CRLDP | | LSR |----------------| |-----------------------| LSR | ------- -------- ------- LSP Establishment: Path Message -> Label Request Msg -> <- Resv Message <- Label Mapping Msg 6.1.1.1 Handling RSVP Path Message In the case of RSVP-TE to CR-LDP signaling interworking as in scenarios a & c, those mandatory and optional objects that are not of local significance to the RSVP-TE MUST be mapped to CR-LDP messages and TLVs. Optional elements of the CR-LDP protocol need not be considered in the RSVP-TE to CR-LDP example except where required for proper interworking. The case of CR-LDP to RSVP-TE mapping is discussed in Section 6.1.2. To establish an LSP tunnel, the ingress RSVP-TE LSR generates a Path message that contains a Label_Request object and a session type of LSP_Tunnel_IPv4 as per [RSVP-TE]. The Path message MUST include the SESSION object, RSVP_HOP object, TIME_VALUES object, and LABEL_REQUEST object. The RSVP_HOP and TIME_VALUES object is local to the RSVP-TE interface and does not require mapping to CRLDP TLVs. When a Path message arrives at the IW LSR, the LSR MUST follow the Path state procedures as defined in [RSVP-TE] and initiate message and object conversion towards the CRLDP LSR. Wright, et al. 7 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 A Path message is mapped to a Label Request message. The Label Request message MUST support the mandatory FEC TLV and LSPID TLV. The FEC element of the FEC TLV SHOULD be set to the CRLSP FEC element. The LSPID TLV of the Label Request message is generated by: - setting the Local CR-LSP ID to the Tunnel ID of the SESSION object - setting the Ingress LSR Router ID to the Extended Tunnel ID of the SESSION object. The LSPID TLV may no longer uniquely identify the LSP within an MPLS network, since in RSVP_TE the Extended Tunnel ID is optional and may be set to zero(0). RSVP-TE uniquely identifies the tunnel by combining the tunnel endpoint address, a tunnel id, the tunnel ingress node address and the sender address with its local LSPID. Thus, for interoperability purposes a new Aux LSPID TLV is defined. The Aux LSPID TLV SHOULD be included in the Label request message to specify the LSPID local to the ingress LSR and the IPv4 tunnel sender address as indicated in the SENDER_TEMPLATE Object. If the Path message includes an Explicit Route Object this can be mapped to an ER-TLV. The loose or strict attributes are easily mapped from the ERO to the ER-HOP TLV. In addition, the last ER-Hop of the ER TLV MUST be contain the Ipv4 Tunnel Endpoint Address of the SESSION object in order to indicate where the ER-LSP tunnel terminates. This ER-Hop MUST be set with a loose attribute. If a resource reservation is indicated in the Path message, the traffic characteristic of the service requested can be described using the CRLDP Traffic Parameters. In particular, the IntServ Controlled-Load service can be supported by CR-LDP. Details of how the traffic parameters map to offer the IntServ Controlled-Load service appear in section 8.8. Support for other Integrated Services service classes is for future study. Where the RSVP-TE sender and the IW LSR supports Diff-Serv, the establishment of E-LSPs or L-LSPs is possible by mapping the Diff- Serv Object to the Diff-Serv TLV. The handling of the Diff-Serv object and Diff-Serv TLV follows the procedures as described in [MPLS DIFF-SERV]. If the Path message contains a CoS SENDER_TSPEC and a Diff-Serv object, the diff-serv procedures are followed as described in [MPLS DIFF-SERV]. If the Path message contains a CoS SENDER_TSPEC but not a Diff-Serv object, the LSP will be established without bandwidth reservation. The use of the CoS SENDER_TSPEC depends on the diff-serv capabilities of the IW LSR towards the CR-LDP LSR. If the IW LSR is Wright, et al. 8 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 diff-Serv capable, the CoS SENDER_TSPEC may be mapped to a Diff-Serv TLV and follow the procedures for E-LSPs or L-LSPs as specified in [MPLS DIFF-SERV]. If the IW LSR is not diff-serv capable the use of the CoS FLOWSPEC is as defined in [RSVP-TE]. If the CoS is zero (0), best effort is assumed and the LSP is established without any traffic parameters TLV towards the CR-LDP LSR. The interworking of other CoS values is for future study. If preemption is indicated in the Path message, the setup and holding priorities are easily mapped to the CRLDP Preemption TLV. Both RSVP-TE and CRLDP follow common procedures for path preemption. If the RSVP-TE sender has requested a record route operation, CRLDP is extended to include a Route Record TLV. The Route Record TLV will be used to collect detail path information such as node address and label(s) allocated by each node. The above procedures support network scenario (a). In order to support network scenario (c), it is necessary for CR-LDP to indicate the network layer protocol. For this, a new L3PID TLV was created and is mandatory to signal it when interworking from RSVP-TE to CRLDP. 6.1.1.2 Handling Label Mapping Message The IW LSR receiving a Label Mapping message, MUST generate a Resv message towards the upstream RSVP-TE LSR to effectively complete the LSP establishment. The Resv message MUST carry the mandatory objects SESSION, RSVP_HOP, TIME_VALUES, STYLE, FILTER_SPEC and LABEL. The objects RSVP_HOP and TIME_VALUEs can be generated locally at the RSVP-TE interface. The IPv4 tunnel endpoint address of the SESSION object is obtained from the last ER HOP TLV. If the last ER HOP TLV does not contain an IPv4 address type, the IW LSR SHOULD NOT progress the label request. The IW LSR SHOULD initiate teardown procedures towards the upstream RSVP-TE LSR with an error value "No route available toward destination". The LABEL object is generated locally according to the RSVP-TE procedures. The initial work of this specification is limited to the FF style, SE style is for future study. Thus, the reservation style is set to FF(01010b) and included in the STYLE object. If the LSP has requested bandwidth reservation with an IntServ Controlled Load service, an IntServ FlowSpec object MUST be included in the Resv message. The CRLDP traffic parameters for the Controlled Wright, et al. 9 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 Load service will map to the Flowspec attributes as indicated in section 9.4. If the LSP does not require bandwidth reservation, the use of the CoS FLOWSPEC depends on the diff-serv capabilities of the IW LSR towards the CRLDP LSR. If the IW LSR is diff-Serv capable, the use of the CoS FLOWSPEC with E-LSPs and L-LSPs follows the procedures as specified in [MPLS DIFF-SERV]. If the IW LSR is not diff-serv capable the use of the CoS FLOWSPEC is as defined in [RSVP-TE]. If the CoS is zero (0), best effort is assumed and the LSP is established without any traffic parameters TLV towards the CR-LDP LSR. The interworking of other CoS values is for future study. The IPV4 Tunnel sender address and LSPID attributes of the FILTER_SPEC SHOULD be obtained from the Aux LSPID TLV. In network scenario (c), the Aux LSPID TLV SHOULD be present at the IW LSR. However, in network scenario (b) the presence of the Aux LSPID TLV is not guarantee and the LSP establishment may fail. If the Label Mapping message includes a Route Record TLV, the Resv message will also include a Record Route object. The Record Route object SHOULD include the recorded path and labels as signaled in the Route Record TLV and update the information according to the RRO procedures stated in [RSVP-TE]. The RSVP_HOP object, TIME_VALUES object and optional INTEGRITY object can be generated locally. 6.1.2 CR-LDP -> RSVP-TE LSP Establishment: Description of protocol exchange for scenarios b and c. In scenarios b and c, an explicit path request message is either originated from a CR-LDP LSR or is in transit from a CR-LDP LSR and requires interworking to an RSVP-TE LSR. A label request message is originated from a CR-LDP LSR. The label request is mapped to a path message at the interworking node. The RSVP-TE destination LSR replies with a reservation message which is mapped by the interworking LSR to a label mapping message. The explicitly routed LSP has been established. The initial Resv messages SHOULD trigger a corresponding CRLDP Label Mapping message. Subsequent Resv refreshes SHOULD NOT trigger CRLDP Label Mapping messages to the corresponding CRLDP LSR unless the reservation state changes. Bandwidth modification under this condition is still under study. (need to verify how draft ASH could fit into this scenario) ------- -------- -------- | CRLDP | | IW LSR | |RSVP TE | | LSR |-------------------| |--------------------| LSR | ------- -------- -------- Wright, et al. 10 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 LSP Establishment: Label Request Msg -> Path Message -> <- Label Mapping Msg <- Resv Message 6.1.2.1 Handling Label Request Message When an LSP originates from a CRLDP LSR, the Label Request messages will carry at least the mandatory TLVs FEC and LSPID. At the IW LSR, the Label Request message is mapped to a Path message that MUST contain a LABEL_REQUEST object and a session type of LSP_Tunnel_IPv4 as per [RSVP-TE]. The LABEL_REQUEST object will be set with a label range corresponding to the underlying media. If the LSP originated from an RSVP-TELSR as in scenario (c), the L3PID information will be obtained from the new L3PID TLV signaled in the Label Request message. If the LSP originated from a CRLDP LSR (scenario b), the new L3PID TLV may not be present. This specification recommends that any Label Request message SHOULD include the L3PID TLV. How to handle a LABEL_REQUEST object when the L3PID TLV is not present is implementation specific. The SESSION object will use the information in the LSPID TLV to identify the session. The Tunnel ID field in the SESSION object will be set to the Local CR-LSP ID. The Extended Tunnel ID in the SESION object will be set to the Ingress LSR Router ID. The IPv4 Tunnel Endpoint address will be obtained from the last ER-HOP TLV found in the Label Request message. The Path message SHOULD continue to indicate the constraint-based path of the LSP. The list of ER Hops to be traversed by the LSP MUST be indicated in the EXPLICIT_ROUTE object. All ER Hop TLVs (except the LSPID ER Hop Type) map directly to the existing RSVP- TEEXPLICIT_ROUTE object. The loose and strict attributes of each ER hop maintain the same semantic between both protocols. If a LSPID ER Hop Type is present, the IW LSR SHOULD NOT progress the label request message and SHOULD send back a No Route Notification message. If the Label Request message specifies a desired QoS, this information MUST be carried in the FlowSpec and SENDER_TSPEC of the Path message. CR-LDP traffic parameters are much richer in nature and thus may support other non-IntServ services such as ATM and Frame Relay[CR-LDP]. RSVP-TE lacks the support of these services and as such cannot provide this level of service interworking. Under this circumstances an IW LSR will need to release the LSP towards the originating LSR. Wright, et al. 11 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 If the Label Request carries a request for path preemption, this request can easily be accommodated in the Path message by making use of the SESSION_ATTRIBUTE Object. The semantics of the Setup and Holding priorities are identical between both protocols and are simply mapped to their corresponding values. The session name in SESSION_ATTRIBUTE object is set to NULL, since there is no equivalent attribute in CRLDP. If the Label Request message indicates a Resource Class TLV, this information will not be able to be transported to a RSVP-TE LSR. There is no equivalent RSVP-TE object that can contain this information. If the Label Request indicates route pinning, the IW LSR will ensure that route pinning occurs from CR-LDP to RSVP-TE by following the RRO procedures to pin down a session path as described in [RSVP-TE]. 6.1.2.2 Handling RSVP Resv Message The IW LSR receiving an RSVP Resv Message, MUST propagate a Label Mapping message towards the upstream CRLDP LSR to effectively establish the LSP. The Label Mapping message SHOULD include the FEC TLV, the Label TLV and LSPID TLV. The information required to generate the FEC TLV and LSPID TLV is available at the IW LSR from the original Label Request message. The generation and processing of the Label TLV is local and follows the label mapping procedures as specified in [CR-LDP]. If the Resv Message indicates a record route operation, the IW LSR will handle the RRO request as specified in [RSVP-TE]. The IW LSR will continue the record route operation towards the CRLDP LSR by including the Route Record TLV in the Label Mapping message. The Route Record TLV will contain the updated path and label(s) if label recording was also requested. If the Resv Message includes a FLOWSPEC Object requesting a desired QoS service, the service SHOULD be mapped to the corresponding CRLDP Traffic Parameters as specified in [CR-LDP]. Note that this specification only indicates support for the IntServ Controlled-Load service. Support for other IntServ services is for further study. If the FLOWSPEC indicates a CoS SENDER_TSPEC value, the IW LSR will interpret that the LSP to be establish has no bandwidth reservation and will establish the LSP towards the CRLDP LSR without specifying traffic parameters (pending the CoS value is zero). If the IW LSR is diff-serv capable, the use of COS for E-LSPs and L-LSPs will apply as specified [MPLS DIFF-SERV]. 6.2 LSP Teardown Wright, et al. 12 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 An explicit LSP may be terminated by either the source or destination node, which could be a CRLDP or RSVP-TE LSR. To successfully release an explicit path, messages are mapped between the two signaling protocols via the IW LSR. The following sections describe the interworking procedures an IW LSR SHOULD follow in order to clear an explicit LSP. The teardown procedures are described based on network scenarios a, b and c. An IW LSR may also triger the teardown of an LSP, however this is considered a failure scenario and is described in section 6.3. 6.2.1 LSP Teardown for scenario a and c An explicit LSP established from a RSVP-TE LSR to a CR-LDP LSR may be terminated by either the upstream RSVP-TE node or the downstream CR-LDP node using the following interworking messages. LSP Teardown by upstream RSVP-TE LSR ------- -------- ------- |RSVP TE| | IW LSR | | CRLDP | | LSR |----------------| |-----------------------| LSR | ------- -------- ------- PathTear Message -> Label Release Msg -> Or LSP Teardown by downstream CR-LDP LSR <- Label Withdraw Msg <- ResvTear Message Label Release Msg -> 6.2.1.1 Handling RSVP PathTear Receipt of a Path Tear message deletes the matching path state for the session as per [RFC 2205]. This indicates to the IW LSR that a particular LSP MUST be teardown. The IW LSR initiates a Label Release message towards the CRLDP LSR. The Label Release message will contain the FEC TLV and the Label TLV. The FEC and Label information is already available at the IW LSR based on information received during LSP establishment. 6.2.1.2 Handling Label Withdraw Message Receipt of a Label Withdraw message indicates that a particular FEC- label mapping or LSP is no longer required. The IW LSR follows the Label Withdraw procedures as indicated in [LDP] and [CR-LDP]. The IW LSR initiates reservation clearing procedures towards the RSVP-TE node by sending a ResvTear message. The ResvTear message MUST include a SESSION, STYLE and FILTER_SPEC objects to identify the Wright, et al. 13 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 session and reservation. This information is available at the IW LSR from the current reservation state. 6.2.2 LSP Teardown for scenario b and c An explicit LSP established from a CRLDP LSR to a RSVP-TE LSR may be terminated by either the upstream CRLDP node or the downstream RSVP- TE node using the following interworking messages. ------- -------- -------- | CRLDP | | IW LSR | |RSVP TE | | LSR |-------------------| |--------------------| LSR | ------- -------- -------- LSP Teardown by upstream CRLDP LSR Label Release Msg -> PathTear Message -> Or LSP Teardown by downstream RSVP-TELSR <- Label Withdraw Msg <- ResvTear Message Label Release Msg -> 6.2.2.1 Handling Label Release Message Receipt of a Label Release message indicates that a particular FEC- label mapping or LSP is no longer required. The IW LSR follows the Label Release procedures as indicated in [LDP] and [CR-LDP]. The IW LSR initiates path clearing procedures towards the RSVP-TE node by sending a PathTear message. The PathTear message SHOULD include a SESSION, SESSION_TEMPLATE and RSVP_HOP objects to identify the session. This information is available at the IW LSR from the current path state. 6.2.2.2 Handling RSVP ResvTear An IW LSR receiving a ResvTear (reservation teardown) message deletes the matching reservation state as specified in [RFC 2205]. In return it initiates a Label Withdraw message towards the upstream CRLDP LSR. The Label Withdraw message will include the FEC TLV and Label TLV. The FEC and label information is available to the IW LSR once it determines the LSP to be cleared from the ResvTear message. 6.3 Error and Failures Protocol message mappings require context in order to be properly applied. In particular, errors and failures MUST be properly handled by the IW LSR in order to ensure recovery or teardown of the Wright, et al. 14 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 LSPs. The interworking procedures for handling errors and failures are described based on network scenarios a, b and c. The most common failure scenarios for the RSVP-TE to CR-LDP case (scenarios a and c) are: - Failure of RSVP-TE reservation after CR-LDP has provided a label. - Initiating a RSVP-TE path request and failure of CR-LDP to provide a label. The most common failure scenarios for the CR-LDP to RSVP-TE case (scenarios b and c) are: - CR-LDP label request aborted. - RSVP-TE path error. - Resource reservation error by the interworking LSR. The following sections describe the interworking procedures for handling errors and failures. The interworking procedures define the message transfer mappings and sequence in which they would occur. A separate section describes error message handling and protocol interworking. 6.3.1 Failure on RSVP Reservation In this example, an error occurs in the RSVP-TE portion of the network and the protocol messages are mapped by the interworking node to ensure each signaling protocol cleans up the resource allocations which occurred prior to the error. Description of Protocol Exchange An explicit path request message is originated from an RSVP-TE LSR. The path message is mapped to a label request message at the interworking node. The CRLDP destination LSR replies with a Label mapping message which is mapped by the interworking LSR to a reservation message. The RSVP-TE LSR does not accept the reservation message and sends a reservation error message towards the destination. The reservation error message triggers the label release message by the interworking LSR to the CR-LDP destination node. A reservation tear message is propagated by the interworking LSR towards the RSVP-TE LSR. ------- -------- ------- |RSVP TE| | IW LSR | | CRLDP | | LSR |----------------| |-----------------------| LSR | ------- -------- ------- Path Message -> Label Request Msg -> <- Resv Message <- Label Mapping Msg ResvErr Message -> Label Release Msg -> Wright, et al. 15 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 <- ResvTear Message Under normal conditions in RSVP-TE, a ResvErr message does not necessarily trigger the teardown of the LSP. This option is left up to the receiver to either modify the reservation or teardown the session. However, this option is not available in CRLDP to RSVP-TE interworking. CRLDP does not offer the capability to notify such information without releasing the LSP. Thus, the IW LSR takes the action of releasing the LSP towards both endpoints. 6.3.2 Failure on CR-LDP Label Request(i.e. Label Request Aborted) In this example, an error occurs in the CR-LDP portion of the network and the protocol messages are mapped by the interworking node. The IW LSR ensures each signaling protocol is aware of the error and takes appropriate action. Description of Protocol Exchange An explicit path request message is originated from an RSVP-TE LSR. The path message is mapped to a label request message at the interworking node. The CRLDP destination LSR replies with a notification that the request cannot be accepted. The notification message is mapped to a path error message by the interworking LSR. The sender may originate a PathTear message. ------- -------- ------- |RSVP TE| | IW LSR | | CRLDP | | LSR |----------------| |-----------------------| LSR | ------- -------- ------- Path Message -> Label Request Msg -> <- PathErr Message <- Notification PathTear Message -> 6.3.3 Label Abort Request by CRLDP LSR In this example, an explicit path requested by the CR-LDP LSR is aborted by the CR-LDP node prior to the LSP being established. The exchange of messages by the interworking LSR ensures each protocol cleans up all state information relating to the aborted request. Description of Protocol Exchange A Label Request message is originated by the CR-LDP LSR followed by a Label Abort request. Each message is processed by the interworking node. The Label Request message is mapped to a RSVP-TE path message; the Label Abort request is mapped to a RSVP-TE path Wright, et al. 16 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 tear message. This message exchange ensures the RSVP-TE protocol has cleared any resources allocated to the initial label request. ------- -------- -------- | CRLDP | | IW LSR | |RSVP TE | | LSR |-------------------| |--------------------| LSR | ------- -------- -------- Label Request Msg -> Path Message -> Label Abort Request -> PathTear Message -> 6.3.4 Path Error by RSVP-TE LSR In this example, a label request is initiated by the CR-LDP LSR but the RSVP-TE LSR is unable to accept the request and returns an error message. The exchange of messages by the interworking LSR ensures each protocol cleans up all state information relating to the unsuccessful LSP request. Description of Protocol Exchange A Label Request message is originated by the CR-LDP LSR. The Label request message is mapped to a RSVP-TE path message. The RSVP-TE portion of the network is unable to accept the path and replies with a path error message. The interworking node returns a notification message to clear the LSP towards the CR-LDP portion of the network and forces a Path tear message to the RSVP-TE LSR. This message exchange ensures each protocol has cleared any resources allocated to the initial label request. ------- -------- -------- | CRLDP | | IW LSR | |RSVP TE | | LSR |-------------------| |--------------------| LSR | ------- -------- -------- Label Request Msg -> Path Message -> <- Notification Msg <- PathErr Message PathTear Message -> 6.3.5 Error by IW LSR In this example, a label request is initiated by the CR-LDP LSR, the RSVP-TE LSR accepts the request but the interworking LSR is unable to process the reservation. The interworking LSR initiates messages to both the CR-LDP and RSVP-TE LSRS to ensure each protocol cleans up all state information relating to the unsuccessful LSP request. Description of Protocol Exchange Wright, et al. 17 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 A label request message is originated from a CR-LDP LSR. The label request is mapped to a path message at the interworking node. The RSVP-TE destination LSR replies with a reservation message. The interworking LSR is unable to process the RSVP_TE reservation message and forces a PathTear towards the RSVP-TE LSR. The IW LSR initiates LSP clearing procedures towards the CRLDP LSR by sending a notification message. ------- -------- -------- | CRLDP | | IW LSR | |RSVP TE | | LSR |-------------------| |--------------------| LSR | ------- -------- -------- Label Request Msg -> Path Message -> <- Resv Message <- Notification Msg PathTear Message -> 6.3.6 Handling RSVP Refresh Timeouts In the case where refresh messages expire and the LSP needs to be released, a Label Release/Label Withdraw message MUST be propagated towards the corresponding CRLDP LSR nodes to release the label switch path. 7.0 Summary of Changes 7.1 Extensions to CRLDP Messages We propose several additional TLVs that extend CRLDP, allowing the establishment of explicitly routed label switch paths across RSVP-TE and CR-LDP capable LSRs. The extended CR-LDP messages are illustrated in the following sections. 7.1.1 CRLDP Label Request Message The encoding of the Label Request Message is extended with a Aux LSPID TLV, Route Record TLV, and Interworking TLV as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPID TLV (CR-LDP, mandatory) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wright, et al. 18 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 | ER-TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pinning TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Class TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pre-emption TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L3PID TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aux LSPID TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Record TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.1.2 CRLDP Label Mapping Message The encoding for the CR-LDP Label Mapping Message is extended with a Aux LSPID TLV, Route Record TLV, and Stacked Label TLV as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Mapping (0x0400) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Request Message ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPID TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aux LSPID TLV (CR-LDP, optional) | Wright, et al. 19 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Record TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stacked Label TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8. RSVP Object to CRLDP TLV Mapping This section describes how to map the different RSVP-TE objects to CR-LDP TLVs, which are necessary for establishing explicit routed label switch paths based on the message interworking described in section 6. When necessary, new CR-LDP TLVs are introduced in order to facilitate RSVP-TE to CR-LDP interworking. 8.1 Session Attribute Object The RSVP-TE SESSION_ATTRIBUTE object maps to a modified CRLDP Preemption TLV. CRLDP Preemption TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Preemption-TLV (0x0820) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SetPrio | HoldPrio | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RSVP-TE Setup Priority and Holding Priority fields are mapped directly to the CRLDP Setup and Holding Priority values. In both protocols, the setup and holding priority values range from zero (0) to seven(7). The value of zero (0) is the highest priority. A new Flags field is created from part of the reserved field in the CRLDP Preemption TLV. This field supports the following values: Flags: 0x01 - Local Protection Permitted 0x02 - Merging Permitted 0x04 - Ingress node may reroute 0x08 - Label Recording desired Values 0x01, 0x02, and 0x04 map directly to the RSVP-TE Session Attribute Flags field. Value 0x08 indicates that each LSR SHOULD take the action to label record the route. Wright, et al. 20 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 The session attribute fields "Name Length" and "Session Name" are not supported. 8.2 Session Object The RSVP-TE Session Object maps to a new L3PID TLV, LSPID TLV and ER TLV. The Ipv4 tunnel endpoint address field in the RSVP-TE session object is added as the last ER Hop TLV of the ER TLV list. If the current last ER hop matches the same IPv4 address as the Ipv4 tunnel endpoint address then no modification to the ER TLV list is required. The L3PID information maps to the following new L3PID TLV. L3PID TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|L3PID(xTBD)| Reserved | L3PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type L3PID 0xTDB Reserved This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. L3PID An identifier of the layer 3 protocol using this path. Standard Ethertype values are used. The RSVP-TE session object Tunnel ID and Extended Tunnel ID fields map to the Local CR-LSP ID field and Ingress LSR Router ID field of the CR-LSP LSPID TLV. CR-LSP LSPID TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| LSPID-TLV (0x0821) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |ActFlg | Local CR-LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress LSR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wright, et al. 21 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 8.3 Explicit Route Object The RSVP-TE EXPLICIT_ROUTE Object type 1(IPv4), 2(Ipv6), and 32(AS Number) map directly to existing CR-LDP ER-Hop-Type TLVs. Type 64(MPLS Path Termination) is supported by modifying the ER-Hop-Type TLV with the addition of a new "T" bit. Modification of CRLDP ER-HOP Type-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| ER-Hop-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|T| Content | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T - Terminate MPLS label switched path. When set this bit instructs the node to remove one level of label from all packets following this LSP. The instruction only takes place at the node that pops the ER-HOP Type TLV. 8.4 Label Request Object The label request object, with the exception of the L3PID field, is a local function handled by normal existing LDP procedures. The L3PID indicates the encapsulated data protocol type. To support this requirement, a new L3PID TLV for the Label Request message has been created (refer to section 8.2). 8.5 Record Route Object The RSVP-TE RECORD_ROUTE object type 1(Ipv4) and type 2(Ipv6) map directly into the new CR-LDP Route Record TLV. CR-LDP Route Record TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Route Record (0xTBD)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Address Family | Host Addr Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Host Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stacked Labels | | | Wright, et al. 22 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Route Record TLV 0xTDB Length Specifies the length of the value field in bytes. Flags 0x01 - Local Protection Available Indicates the link downstream of this node is protected by a local repair mechanism. 0x02 - Local Protection in Use Indicates that a local protection mechanism is in use to maintain this LSP. Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC 1700] that encodes the address for the address prefix in the Prefix field. Host Addr Len Length of the Host address in octets. Host Addr An address encoded according to the Address Family field. Stacked Labels The label(s) assigned at this interface by the LSR. The CR-LDP Route Record TLV is specified here for interworking purpose. Its use for other applications is outside the scope of this draft. 8.6 Sender Template The RSVP-TE SENDER_TEMPLATE maps to a new CR-LDP TLV the Aux LSPID TLV and to the actflgs within the LSPID TLV. Aux LSPID-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Aux LSPID-TLV (0xTBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Local CR-LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress LSR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wright, et al. 23 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 Type Aux LSPID-TLV 0xTDB Length Specifies the length of the value field in bytes. Reserved Zero on transmission. Ignored on receipt. Local CR-LSP ID A 2-byte field indicating the LSPID local to the ingress LSR. Ingress LSR Router ID An LSR may use any of its own IPv4 addresses in this field. On initial LSP establishment, the Sender Template IPv4 tunnel sender address and LSP ID are copied over to the Aux LSPID TLV. The actflag of the LSPID TLV is set to 0000 indicating initial setup. The LSP ID is saved by the IW LSR. After initial establishment the LSP ID is compared against the saved value, if it has changed, the new value is saved, the LSPID actflg is set to 0001 and the new tunnel sender address and LSP ID is copied into the Aux LSPID TLV. 8.7 Tspec and Flowspec Objects for Class of Service CR-LDP will use the diff-serv over MPLS procedures as described in [MPLS DIFF-SERV] for establishing explicitly routed LSPs that do not require bandwidth reservation. When processing a path (respectively Resv) message for an E-LSP or L-LSP using the RSVP CoS service, a Diff-Serv capable IW LSR MUST ignore the value of the CoS field within a CoS SENDER_TSPEC (respectively CoS FLOWSPEC). Instead, it will use the preconfigured diff-serv mappings or use the DIFFSERV object(if present). If the DIFFSERV object is present, this information will be signaled in the diff-serv TLV following the procedures as stated in [MPLS DIFF- SERV]. 8.8 SENDER_TSPEC and FLOWSPEC Object for Int-Serv Controlled Load The Int-Serv Controlled Load service can be supported in CR-LDP by mapping the attributes of the SENDER_TSPEC (Path message)and FLOWSPEC (Resv message) to the CR-LDP parameters of the Label Request/Label Mapping message as follows: Controlled Load Service ======================= Wright, et al. 24 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 PDR: p PBS: M CDR: r CBS: b EBS: 0 Service Frequency: Frequent Edge rules: (r,b) policing with marking option Traffic in excess of rT+b SHOULD be marked as non-conformant The Int-Serv Guaranteed Service is not supported. 8.9 Filter Specification Object The RSVP FILTER_SPEC maps to the new CR-LDP Aux LSPID TLV defined in section 8.6. FILTER_SPEC Object Aux LSPID TLV IPv4 tunnel sender address <-> Ingress LSR Router ID LSP ID <-> Local CR-LSP ID 8.10 Label Object The RSVP-TE LABEL Object may carry a stack of labels in Resv messages. When interworking from RSVP-TE to CR-LDP, the top label of the stack is processed according to the Label Mapping procedures described in [CR-LDP]. The rest of the label stack SHOULD be passed through using the new Stacked Label TLV as defined below. Stacked Label TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Stacked Label-TLV (0xTBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Stacked Labels // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Stacked Label-TLV 0xTDB Length Specifies the length of the value field in bytes. Stacked Labels List of labels. Each label 4 bytes in length. 8.11 Error Spec Object Wright, et al. 25 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 A subset of the error conditions reported by the ERROR_SPEC object can be specified in the Status TLV as an optional parameter in the Notification and/or Label Release messages. An additional optional parameter, the Error Node Address TLV, will include the Ipv4/Ipv6 address of the node generating the error. The encoding for the new Error Node Address TLV is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Error Node Addr (xTBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv | Address Family | Host Addr Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Host Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Zero on transmission. Ignored on receipt. Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC 1700] that encodes the address family for the address prefix in the Prefix field. Host Addr Len Length of the Host address in octets. Host Addr An address encoded according to the Address Family field. The flags defined in the ERROR_SPEC object used by the ResvErr message do not need to be supported in the Error Node Address TLV. Reservations that remain in place at the failure point, will be deleted by the IW LSR. An IW LSR will send a PathTear/ResvTear as a result of receiving a ResvErr/PathErr message. The RSVP-TE error code and error values are mapped to the CR-LDP status codes of the Status TLV as defined later in section 9.8. RSVP-TE error codes not mentioned in that section are for future study. 9. CRLDP TLVs to RSVP-TE Object Mapping Wright, et al. 26 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 9.1 CR-LSP FEC TLV The CR-LSP FEC TLV does not need to be mapped to any RSVP-TE Object. The CR-LSP FEC is an opaque FEC and will be ignored when interworking from RSVP_TE to CR-LDP. 9.2 LSPID TLV CR-LDP uniquely identifies an explicitly routed label switch path by assigning an LSPID. The LSPID, composed of the ingress LSR router ID and a locally unique ID, is mapped to the Extended Tunnel ID and to the Tunnel ID attribute of the SESSION object. 9.3 Explicit Route TLV, Explicit Route Hop TLV The ER TLV specifies the path to be taken by the LSP being established. The path is specified in a set of one or more ER Hop TLVs. Each ER Hop TLV is mapped to a RSVP-TE EXPLICIT_ROUTE subobject. The ER Hop TLV Types 0x801(IPv4 prefix), 0x802(Ipv6 prefix), and 0x803(AS Number) map directly to existing RSVP-TE EXPLICIT_ROUTE types 1(Ipv4), 2(Ipv6), and 32(AS number). The LSPID ER Hop type is not supported by RSVP-TE. The L bit, an indication of the hop attribute, is mapped to the L bit of the EXPLICIT_ROUTE subobject. It maintain the same semantic, when set the L bit indicates a loose hop. The contents, a variable field containing a node or abstract node, maps to a Ipv4 prefix subobject, Ipv6 prefix subobject or AS number subobject depending on the ER Hop type. 9.4 Traffic Parameters TLV The CR-LDP Traffic parameters can be used to describe the Controlled-Load service for bandwidth reservation as indicated in [CR-LDP]. The CR-LDP traffic parameters map to the IntServ Controlled Load service parameters as follows: Controlled Load Service ======================= PDR: p PBS: M CDR: r CBS: b EBS: 0 Service Frequency: Frequent Wright, et al. 27 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 The m attribute is a configured value at the IW LSR. In this scenario, CR-LDP traffic parameters map to the attributes (r,b,p,m,M) of the SENDER_TSPEC object used in the Path message and to the attributes (r,b,p) of the FLOWSPECT object used in the RESV message. CR-LDP traffic parameters are much richer in nature and thus may support other services such as ATM and Frame Relay as specified in [CR-LDP]. RSVP-TE lacks the support of these services and as such cannot provide this level of service interworking. 9.5 Pinning TLV CR-LDP uses the Pinning TLV to request route pinning during label request. An IW node will ensure that route pinning occurs from CR- LDP to RSVP-TE by following the RRO procedures to pin down a session path as described in [RSVP-TE]. Route pinning from RSVP-TE to CR-LDP is implementation dependent, as it may require a priori knowledge of the pinning requirements of the ER-LSP. 9.6 Resource Class TLV The resource class bit mask indicating which of the 32 administrative groups or colors_of links an explicitly routed LSP can traverse is not supported in RSVP-TE. 9.7 Preemption TLV The Preemption TLV indicates the Setup and Holding priorities of the LSP. The Setup and Holding Priority map directly to the Setup and Holding priority indicated in the RSVP-TE SESSION_ATTRIBUTE Object. In both protocols, the setup and holding priority values range from zero (0) to seven(7). The value of zero (0) is the highest priority. 9.8 Status TLV The Status TLV used for advisory notification of an LSP is mapped to the RSVP ERROR_SPEC object. The Error Node Address field (Ipv4/Ipv6) of the Status TLV maps to the ERROR_SPEC IPv4/IPv6 Error node address. The ERROR_SPEC flag is set to a default value of 0x00. The flag values 0x01 and 0x02 are not supported. The CR-LDP status codes map to the error code and error code values of the ERROR_SPEC object as follows: Wright, et al. 28 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 CR-LDP Status Codes ERROR_SPEC code & value ------------------- ----------------------- Bad Explicit Routing TLV Error Error code 24, value 1 Bad Strict Node Error Error code 24, value 2 Bad Loose Node Error Error code 24, value 3 Bad Initial ER-Hop Error Error code 24, value 4 Resource Unavailable Error code 01, value 2 Traffic Parameters Unavailable Error code 21, value 2 Setup Abort Error code 21, value 2 Modify Request Not Supported tbd New CR-LDP Status codes are defined in order to report interworking errors: Status Code E Status Data ----------- - ----------- Interworking Not Available 0 0x44000009 Interworking Failed/ Parameter not supported 0 0x44000010 Interworking Failed/ Message not supported 0 0x44000011 Interworking Failed/ Parameter Unknown 0 0x44000012 Unsupported L3PID 0 0x44000013 The interworking errors SHOULD be reported in RSVP with error code "Routing Problem", and the error value "MPLS being negotiated, but a non-RSVP capable router stands in the path". Mapping of other LDP/CRLDP status codes to RSVP error codes/values are for future study. 10. Security Considerations No additional security issues are introduced in this draft. As extensions to LDP and CR-LDP, this proposal shares the security concerns associated with LDP and CR-LDP. 11. Acknowledgments The authors would also like to acknowledge the review and comments of Geping Chen. 12. References [MPLS DIFF-SERV] Le Faucher et al, "MPLS Support of Differentiated Services", draft-ietf-mpls-diff-ext- 03.txt, February 2000 Wright, et al. 29 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 [RFC 1700] Reynolds & Postel, "Assigned Numbers", October 1994 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RSVP-TE] Awduche et al, "Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-03.txt, September 1999 [MPLS ARCH] Rosen et al, " Multiprotocol Label Switching Architecture", draft-ietf-mpls-arch-06.txt, August 1999 [RSVP RRED] Berger et al, "RSVP Refresh Overhead Reduction Extensions", draft-ietf-rsvp-refresh-reduct-02.txt, January, 2000 13. Author's Addresses Gregory Wright Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 613 765-7912 gwright@nortelnetworks.com Sandra Ballarte Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 613 763-9510 ballarte@nortelnetworks.com Tim Pearson Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 613 763-9510 tpearson@nortelnetworks.com Full Copyright Statement "Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it Wright, et al. 30 Internet Draft draft-wright-MPLS-ER-Interwork-00.txt March 2000 or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process MUST be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.