Internet Draft                           Jean-Philippe Vasseur (Editor) 
MPLS WG                                                       Zafar Ali 
                                                         Siva Sivabalan 
                                                    Cisco Systems, Inc. 
                                                               
Proposed Status: Standard 
Expires: November 2005                                                
                                                               May 2005 
 
 
                                
              draft-ietf-mpls-nodeid-subobject-06.txt 
 
 
              Definition of an RRO node-id subobject 
 
 
 
Status of this Memo 
 
By submitting this Internet-Draft, each author represents that any 
applicable patent or other IPR claims of which he or she is aware 
have been or will be disclosed, and any of which he or she becomes 
aware will be disclosed, in accordance with Section 6 of BCP 79. 
 
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. 
 











Vasseur, Ali and Sivabalan                                    1 
 

 
draft-ietf-mpls-nodeid-subobject-06.txt                        May 2005 
 
 
Abstract 
 
In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is 
required at the Point of Local Repair (PLR) in order to select a backup 
tunnel intersecting a fast reroutable Traffic Engineering Label 
Switched Path (TE LSP) on a downstream Label Switch Router (LSR).  
However, existing protocol mechanisms are not sufficient to find an MP 
address in multi-domain routing networks where a domain is defined as 
an IGP area or an Autonomous System. Hence, the current MPLS Fast 
Reroute mechanism cannot be used to protect inter-domain TE LSPs from a 
failure of an ABR (Area Border Router) or ASBR (Autonomous System 
Border Router) respectively. This document specifies the use of 
existing Route Record Object (RRO) IPv4 and IPv6 sub-objects (with a 
new flag defined) thus defining the node-id subobject in order to solve 
this issue. Note that the MPLS Fast reroute mechanism mentioned in this 
document refers to the "Facility backup" MPLS TE Fast Reroute method. 
 
Table of content 
 
1. Terminology ----------------------------- 
2. Introduction ---------------------------- 
3. Signaling node-ids in RROs ------------- 
4. Finding Merge Point --------------------- 
5. Security Considerations ----------------- 
6. IANA Consideration 
7. Intellectual Property Considerations ---- 
8. Acknowledgments ------------------------- 
9. References 
9.1 Normative references 
9.2 Informative references 
10. Authors' addresses 
 
Conventions used in this document 
 
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 [i]. 
 
 
1.     Terminology 
  
Bypass Tunnel: an LSP that is used to protect a set of LSPs passing 
over a common facility. 
 
Backup Tunnel: the LSP that is used to backup up one of the many LSPs 
in many-to-one backup. 
 
CSPF: Constraint-based Shortest Path First. 
 
Inter-area TE LSP: TE LSP whose head-end LSR and tail-end LSR do not 
reside within the same IGP area or whose head-end LSR and tail-end LSR 
 
Vasseur, Ali and Sivabalan                                    2 
 

 
draft-ietf-mpls-nodeid-subobject-06.txt                        May 2005 
 
 
are both in the same IGP area although the TE-LSP transiting path may 
be across different IGP areas. 
 
Inter-AS MPLS TE LSP: TE LSP whose Head-end LSR and Tail-end LSR do not 
reside within the same Autonomous System (AS) or both Head-end  
LSR and Tail-end LSR are in the same AS but the TE tunnel transiting 
path may be across different ASes 
 
Interconnect or ASBR Routers:  Routers used to connect to another AS of 
a different or the same Service Provider via one or more Inter-AS 
links.  
 
LER: Label Edge Router. 
 
LSDB: Link State Database. 
 
LSP: An MPLS Label Switched Path 
 
LSR: Label Switch Router 
 
Local Repair: techniques used to repair LSP tunnels quickly when a node 
or link along the LSPs path fails. 
 
PCC: Path Computation Client: any client application requesting a path 
computation to be performed by the Path Computation Element. 
 
PCE: Path Computation Element: an entity (component, application or 
network node) that is capable of computing a network path or route 
based on a network graph and applying computational constraints (see 
further description in section 3). 
 
MP: Merge Point. The LSR where detour or backup tunnels meet the 
protected LSP. In case of one-to-one backup, this is where multiple 
detours converge. A MP may also be a PLR. 
 
Protected LSP: an LSP is said to be protected at a given hop if it has 
one or multiple associated backup tunnels originating at that hop. 
 
PLR: Point of Local Repair. The head-end of a backup tunnel or a detour 
LSP. 
 
Reroutable LSP: Any LSP for with the "Local protection desired" bit is 
set in the Flag field of the SESSION_ATTRIBUTE object of its Path 
messages. 
 
2. Introduction    

MPLS Fast Reroute (FRR) ([FAST-REROUTE]) is a fast recovery local 
protection technique used to protect Traffic Engineering LSPs from 
link/SRLG/node failure.  One or more backup tunnels are pre-established 
to protect against the failure of a link/node/SRLG. In case of failure, 
 
Vasseur, Ali and Sivabalan                                    3 
 

 
draft-ietf-mpls-nodeid-subobject-06.txt                        May 2005 
 
 
every protected TE LSP traversing the failed resource is rerouted onto 
the appropriate backup tunnels in tens of msecs. 
 
There are several requirements on the backup tunnel path that must be 
satisfied. First, the backup tunnel must not traverse the element that 
it protects. Additionally, a primary tunnel and its associated backup 
tunnel should intersect at least at two points (nodes): Point of Local 
Repair (PLR) and Merge Point (MP). The former should be the head-end 
LSR of the backup tunnel and the latter should be the tail-end LSR of 
the backup tunnel. The PLR is where FRR is triggered when 
link/node/SRLG failure happens.  
 
There are different methods for computing paths for backup tunnels at a 
given PLR. Specifically, a user can statically configure one or more 
backup tunnels at the PLR with an explicitly configured path or the PLR 
can be configured to automatically compute a backup path or to send a 
path computation request to a PCE. 
 
Consider the following scenario (figure 1) 
 
Assumptions: 
- A multi-area network made of three areas: 0, 1 and 2, 
- A fast reroutable TE LSP T1 (TE LSP signaled with the "local 
Protection desired" bit set in the SESSION-ATTRIBUTE object or the 
FAST-REROUTE object) from R0 to R3, 
- A backup tunnel B1 from R1 to R2, not traversing ABR1, and following 
the R1-ABR3-R2 path.  
- The PLR R1 reroutes any protected TE LSP traversing ABR1 onto the 
backup tunnel B1 in case of ABR1's failure. 
 
           <--- area 1 --><---area 0---><---area 2---> 
              R0-----R1-ABR1--R2------ABR2--------R3 
                     \        / 
                      \      / 
                        ABR3 
 
Figure 1: Use of Fast Reroute to protect a TE LSP against an ABR 
failure with MPLS Traffic Engineering Fast Reroute 
 
When T1 is first signaled, the PLR R1 needs to dynamically select an 
appropriate backup tunnel intersecting T1 on a downstream LSR. However, 
existing protocol mechanisms are not sufficient to unambiguously find 
the MP address in a network with inter-domain TE LSP. Note that 
although the example above was given in the context of inter-area TE 
LSPs, a similar reasoning applies to the case of inter-AS TE LSP. This 
document addresses these limitations.  
 
R1 needs to ensure the following:  
 
  1. The backup tunnel intersects with the primary tunnel at the MP 
     (and thus has a valid MP address). For the sake of illustration, 
 
Vasseur, Ali and Sivabalan                                    4 
 

 
draft-ietf-mpls-nodeid-subobject-06.txt                        May 2005 
 
 
     in Figure 1, R1 needs to determine that T1 and B1 share the same 
     MP node R2. 
 
  2. The backup tunnel satisfies the primary LSP's request with 
     respect to the bandwidth protection request (i.e., bandwidth 
     guaranteed for the primary tunnel during failure), and the type 
     of protection (preferably, protecting against a node failure 
     versus a link failure), as specified in [FAST-REROUTE]. 
 
A PLR can make sure that condition (1) is met by examining the Record 
Route Object (RRO) of the primary tunnel to see if any of the addresses 
specified in the RRO is attached to the tail-end of the backup tunnel. 
As per [RSVP-TE], the addresses specified in the RRO IPv4 or IPv6 sub-
objects sent in Resv messages can be node-ids and/or interface 
addresses. Hence, in Figure 1, router R2 may specify interface 
addresses in the RROs for T1 and B1. Note that these interface 
addresses are different in this example.  
 
The problem of finding the MP using the interface addresses or node-ids 
can be easily solved in the case of a single IGP area. Specifically, in 
the case of a single IGP area, the PLR has the knowledge of all the 
interfaces attached to the tail-end of the backup tunnel. This 
information is available in PLR's IGP topology database. Thus, the PLR 
can unambiguously determine whether a backup tunnel intersecting a 
protected TE LSP on a downstream node exists and can also find the MP 
address regardless of how the addresses carried in the RRO IPv4 or IPv6 
sub-objects are specified (i.e., whether using the interface addresses 
or the node-ids). However, such routing information is not available in 
the case of inter-domain environments. Hence, unambiguously making sure 
that condition (1) above is met in the case of inter-domain TE LSPs is 
not possible with existing mechanisms. 
 
In this document, we define extensions to and describe the use of RSVP 
[RSVP, RSVP-TE] to solve the above-mentioned problem. Note that the 
requirement for the support of the fast recovery technique specified in 
[FAST-REROUTE] to inter-domain TE LSPs has been specified in [INTER-
AREA-TE-REQS] and [INTER-AREA-TE-REQS]. 
 
2.     Signaling node-ids in RROs
 
As mentioned above, the limitation that we need to address is the 
generality of the contents of the RRO IPv4 and IPv6 sub-objects, as 
defined in [RSVP-TE]. [RSVP-TE] defines the IPv4 and IPv6 RRO sub-
objects. Moreover, two additional flags are defined in [FAST-REROUTE]: 
the "Local Protection Available" and "Local protection in use" bits. 
 
In this document, we define the following new flag: 
 
Node-id: 0x20 
 
 
Vasseur, Ali and Sivabalan                                    5 
 

 
draft-ietf-mpls-nodeid-subobject-06.txt                        May 2005 
 
 
      When set, this indicates that the address specified in the 
      RRO's IPv4 or IPv6 subobject is a node-id address, which refers 
      to the "Router Address" as defined in [OSPF-TE], or "Traffic 
      Engineering Router ID" as defined in [ISIS-TE]. A node MUST use 
      the same address consistently. Once an address is used in RRO's 
      IPv4 or IPv6 subobject, it should always be used for the 
      lifetime of the LSP. 
 
An IPv4 or IPv6 RRO subobject with the node-id flag set is also called 
a node-id subobject. The problem of finding a MP address in a network 
with inter-domain TE LSP is solved by inserting a node-id subobject (an 
RRO "IPv4" and "IPv6" sub-object with the 0x20 flag set) in the RRO 
object carried in the RSVP Resv message. 
       
An implementation may either decide to:  
 
1) Add the node-id subobject in an RSVP Resv message and, when 
required, also add another IPv4/IPv6 subobject to record interface 
address. 
 
Example: an inter-domain fast reroutable TE LSP would have in the RRO 
object carried in Resv message two sub-objects: a node-id subobject and 
a label sub-object. If recording the interface address is required, 
then an additional IPv4/IPv6 subobject is added.  
 
2) Add an IPv4/IPv6 sub-object recording the interface address and, 
when required, add a node-id subobject in the RRO object. 
 
Example: an inter-domain fast reroutable TE LSP would have in the RRO 
object carried in Resv message three sub-objects: an IPv4/IPv6 sub-
object recording interface address, a label sub-object and a node-id 
sub-object. 
 
Note also that the node-id sub-object may have other application than 
Fast Reroute backup tunnel selection. Moreover, it is RECOMMENDED that 
an LSR recording a node-id address in an IPv4/IPv6 RRO sub-object also 
set the Node-id flag. 
 
3.     Finding Merge Point                                   
 
Two cases should be considered: 
 
- Case 1: the backup tunnel destination is the MP's node-id. Then a PLR 
can find the MP and suitable backup tunnel by simply comparing the 
backup tunnel's destination address with the node-id included in the 
RRO of the primary tunnel.  
- Case 2: the backup tunnel terminates at an address different than the 
MP's node-id. Then a node-id subobject MUST also be included in the RRO 
object of the backup tunnel. A PLR can find the MP and suitable backup 
tunnel by simply comparing the node-ids present in the RRO objects of 
both the primary and backup tunnels. 
 
Vasseur, Ali and Sivabalan                                    6 
 

 
draft-ietf-mpls-nodeid-subobject-06.txt                        May 2005 
 
 
 
When both IPv4 node-id and IPv6 node-id sub-objects are present, a PLR 
may use any or both of them in finding the MP address.  
 
4.     Security Considerations                              
 
This document does not introduce new security issues. The security 
considerations pertaining to [RSVP] and [RSVP-TE] remain relevant. 
 
5.     IANA considerations                                 
 
IANA will assign a new flag in the RRO object defined in [RSVP-TE]: 
 
Node-id flag: 0x20 (to be assigned by IANA). 
 
6.     Intellectual Property Considerations              
 
The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has made 
any independent effort to identify any such rights. Information on the 
procedures with respect to rights in RFC documents can be found in BCP 
78 and BCP 79. 
 
Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this specification 
can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 
 
The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary rights 
that may cover technology that may be required to implement this 
standard. Please address the information to the IETF at ietf-   
ipr@ietf.org. 
 
7.     Acknowledgments                                  
 
We would like to acknowledge input and helpful comments from Carol 
Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, Philip Matthews and 
Adrian Farrel. 
 
8.     References                                      
 
8.1 Normative References 
 
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 
 
Vasseur, Ali and Sivabalan                                    7 
 

 
draft-ietf-mpls-nodeid-subobject-06.txt                        May 2005 
 
 
 
[RFC3667]Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, 
February 2004. 
 
[RFC3668]Bradner, S., Ed., "Intellectual Property Rights in IETF 
Technology", BCP 79, RFC 3668, February 2004. 
 
[RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version 
1, Functional Specification", RFC 2205, September 1997. 
 
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 
3209, December 2001. 
 
[FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for 
LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt. Work in 
progress. 
 
[OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF  
Version 2", RFC3630.  
    
[ISIS-TE] Smit et al., "Intermediate System to Intermediate System (IS-
IS) - Extensions for Traffic Engineering (TE)IS-IS extensions for 
Traffic Engineering", RFC3784.  
 
8.2 Informative references 
 
[INTER-AREA-TE-REQS] Le Roux, Vasseur, Boyle et al., "Requirements for 
Inter-Area MPLS Traffic Engineering", draft-ietf-tewg-interarea-mpls-te-
req-03.txt. Work in progress. 
 
[INTER-AS-TE-REQS] Zhang, Vasseur et al, "MPLS Inter-AS Traffic 
Engineering requirements", draft-tewg-interas-te-req-09.txt. Work in 
progress. 
 
 
9.     Authors' Addresses        
 
Jean-Philippe Vasseur 
Cisco Systems, Inc. 
300 Beaver Brook Road 
Boxborough , MA - 01719 
USA 
Email: jpv@cisco.com 
 
Zafar Ali 
Cisco Systems, Inc. 
100 South Main St. #200 
Ann Arbor, MI 48104 
USA 
zali@cisco.com 
 
 
Vasseur, Ali and Sivabalan                                    8 
 

 
draft-ietf-mpls-nodeid-subobject-06.txt                        May 2005 
 
 
Siva Sivabalan  
Cisco Systems, Inc.  
2000 Innovation Drive  
Kanata, Ontario, K2K 3E8  
Canada  
msiva@cisco.com  
                  
                    
Full Copyright Statement 
 
Full Copyright Statement 
 
Copyright (C) The Internet Society (2005).  This document is subject to 
the rights, licenses and restrictions contained in BCP 78, and except 
as set forth therein, the authors retain all their rights. 
 
This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
 
























 
Vasseur, Ali and Sivabalan                                    9