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.