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-crldp-rsvpte-iw-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

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

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.