Jean Philippe
Internet Draft                           Jean-Philippe Vasseur (Editor)
MPLS WG                                                       Zafar Ali
                                                         Siva Sivabalan
                                                    Cisco Systems, Inc.

IETF Internet Draft

Proposed Status: Standard
Expires: July, November 2005
                                                     January,
                                                               May 2005

              draft-ietf-mpls-nodeid-subobject-05.txt

              draft-ietf-mpls-nodeid-subobject-06.txt

              Definition of an RRO node-id subobject

Status of this Memo

By submitting this Internet-Draft, I certify each author represents that any
applicable patent or other IPR claims of which I am he or she is aware
have been or will be disclosed, and any of which I become he or she becomes
aware will be disclosed, in accordance with RFC 3668.

Working 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

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 LSP Label
Switched Path (TE LSP) on a downstream LSR. Label Switch Router (LSR).
However, existing protocol mechanisms are not sufficient to find an MP
address in multi-areas or multi-domain routing
networks. 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-area or inter-AS inter-domain TE LSPs from a
failure of an ABR (Area Border Router) or ASBR (Autonomous System
Border Router) respectively. Such functionality has been listed as a clear requirement
in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS]. This document specifies the use of
existing RRO Route Record Object (RRO) IPv4 and IPv6 subobjects sub-objects (with a
new flag defined) to define 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
2. Introduction ---------------------------- 3
3. Signaling node-ids in RROs -------------- 5 -------------
4. Finding Merge Point --------------------- 6
5. Security Considerations ----------------- 6
6. IANA Consideration
7. Intellectual Property Considerations ---- 6
7.
8. Acknowledgments ------------------------- 7
8.
9. References ------------------------------ 7
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

LSR - Label Switch Router

LSP - An MPLS Label Switched Path

PCS - Path Computation Server (may be any kind of LSR (ABR, ...)
      or a centralized path computation server

PCC - Path Computation Client (any head-end LSR) requesting a path
      computation of the Path Computation Server.

Local Repair - Techniques used to repair LSP tunnels quickly
               when a node or link along the LSPs path fails.

Protected LSP - An LSP is said to be protected at a given hop if

Vasseur, Ali and Sivabalan                                    2
                it has one or multiple associated backup tunnels
                originating at that hop.

Bypass Tunnel - An Tunnel: an LSP that is used to protect a set of LSPs passing
over a common facility.

Backup Tunnel - The Tunnel: the LSP that is used to backup up one of the many LSPs
in many-to-one backup.

PLR - Point of Local Repair. The

CSPF: Constraint-based Shortest Path First.

Inter-area TE LSP: TE LSP whose head-end of a backup tunnel or
      a detour LSP.

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.

Reroutable LSP - Any LSP for with and tail-end LSR do not
reside within the "Local protection desired"
                 bit is set same IGP area or whose head-end LSR and tail-end LSR

Vasseur, Ali and Sivabalan                                    2

are both in the Flag field of same IGP area although the
                 SESSION_ATTRIBUTE object of its Path messages. 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

every protected TE LSP traversing the failed resource is rerouted onto
the appropriate backup tunnels in 10s tens of msecs.

There are a couple of several requirements on the backup tunnel path. At least,
a path that must be
satisfied. First, the backup tunnel should must not pass through 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, 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, PLR with explicit an explicitly configured path or the PLR
can be

Vasseur, Ali and Sivabalan                                    3 configured to automatically compute a backup path or to send a
path computation request to a PCS (which can be an LSR or an off-line tool). PCE.

Consider the following scenario (figure 1)

Assumptions:
- A multi-area network made of three areas: 0, 1 and 2. 2,
- A fast reroutable TE LSP T1 (TE LSP signaled with the "local
Protection desired" bit set in the SESSION-ATTRIBUTE object or the FRR
FAST-REROUTE object) from R0 to R3 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      /
                        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-area or inter-AS traffic
engineering (although inter-domain TE LSP. Note that
although the example above was given in the context of
multi-area networks, inter-area TE
LSPs, a similar reasoning applies to the case of inter-AS TE LSP spanning
multiple ASes). LSP. This
document addresses these limitations.

R1 needs to ensure the following:

  1. Backup The backup tunnel intersects with the primary tunnel at the MP
     (and thus has a valid MP address), e.g., address). For the sake of illustration,

Vasseur, Ali and Sivabalan                                    4
     in Figure 1, R1 needs to determine that T1 and B1 share the same
     MP node R2, R2.

  2. Backup 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
subobjects 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.

Vasseur, Ali and Sivabalan                                    4

The problem of finding the MP using the interface addresses or node-ids
can be easily solved in the case of a single area (OSPF_)/level (IS-IS). IGP area. Specifically, in
the case of a single area/level, 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 contained carried in the RRO IPv4 or IPv6 subobjects
sub-objects are specified (i.e., whether using the interface addresses
or the node IDs). node-ids). However, such routing information is not available in multi-area and inter-AS traffic engineering
the case of inter-domain environments. Hence, unambiguously making sure
that condition (1) above is met with
inter-area TE and inter-AS traffic-engineering 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.

3. 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 subobjects, sub-objects, as
defined in [RSVP-TE].[RSVP-TE] [RSVP-TE]. [RSVP-TE] defines the IPv4 and IPv6 RRO subobjects
along with sub-
objects. Moreover, two additional flags (namely are defined in [FAST-REROUTE]:
the "Local Protection Available" and "Local protection in use" bits). Moreover, other bits have been
specified in [FAST-REROUTE] and [SOFT-PREEMPTION]. bits.

In this document, we define the following new flag:

Node-id: 0x20

Vasseur, Ali and Sivabalan                                    5
      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. In other words, once 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-area or inter-AS traffic engineering inter-domain TE LSP is solved by inserting a node-id subobject (an
RRO "IPv4" and "IPv6" sub-object with the 0x20 flag set). 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.

Vasseur, Ali and Sivabalan                                    5

Example: a an inter-domain fast reroutable TE LSP would have in the RRO
object carried in Resv message two subobjects: sub-objects: a node-id subobject and
a label
subobject. sub-object. If recording the interface address is required,
then an additional IPv4/IPv6 subobject is added.

2) Add an IPv4/IPv6 subobject sub-object recording the interface address and,
when required, add a node-id subobject in the RRO object.

Example: an inter-area/inter-AS inter-domain fast reroutable TE LSP would have in the RRO
object carried in Resv message three subobjects: sub-objects: an IPv4/IPv6
subobject sub-
object recording interface address, a label subobject sub-object and a node-id
subobject.
sub-object.

Note also, also that the node-id subobject 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.

4.

3.     Finding Merge Point

Two cases should be considered:

- case 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 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

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.

5.

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
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; neither nor does it represent that it has made
any independent effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation RFC documents can be found in BCP-11. BCP
78 and BCP 79.

Copies of claims of
rights IPR disclosures made available for publication to the IETF Secretariat and any
assurances of licenses to

Vasseur, Ali and Sivabalan                                    6 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
implementors implementers or users of this specification
can be obtained from the IETF Secretariat. 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
which
that may cover technology that may be required to practice implement this
standard. Please address the information to the IETF Executive
Director.

The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this document.
For more information consult the online list of claimed rights. 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,

[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3667] Bradner,

Vasseur, Ali and Sivabalan                                    7

[RFC3667]Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004.

[RFC3668] Bradner,

[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.

Informative references

[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.

Vasseur, Ali and Sivabalan                                    7

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.

[INTER-DOMAIN-SIG] Ayyangar and Vasseur, "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensions", draft-ayyangar-ccamp-inter-domain-
rsvp-te-01.txt. Work in progress.

[LOOSE-PATH-REOPT] Vasseur et al. "Reoptimization of MPLS
Traffic Engineering loosely routed LSP", <draft-ietf-ccamp-loose-path-
reopt-00.txt>. Work in progress.

[SOFT-PREEMPTION] Meyer, Maddux, Vasseur, Villamizar and Birjandi. "MPLS
Traffic Engineering Soft preemption", draft-ietf-mpls-soft-preemption-
03.txt. Work in progress.

9.     Authors' Addresses:

Jean Philippe 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

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

Vasseur, Ali and Sivabalan                                    8
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