draft-ietf-mpls-nodeid-subobject-01.txt   draft-ietf-mpls-nodeid-subobject-02.txt 
Jean Philippe Vasseur
Jean Philippe Vasseur (Editor)
Zafar Ali Zafar Ali
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
IETF Internet Draft IETF Internet Draft
Expires: November, 2003 Expires: July, 2004
May, 2003 January, 2004
draft-ietf-mpls-nodeid-subobject-01.txt draft-ietf-mpls-nodeid-subobject-02.txt
Definition of an RRO node-id subobject Definition of an RRO node-id subobject
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are provisions of Section 10 of RFC2026. Internet-Drafts are
Working documents of the Internet Engineering Task Force (IETF), its Working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at line 36 skipping to change at line 37
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Vasseur, Ali and Sivabalan 1 Vasseur, Ali and Sivabalan 1
Abstract Abstract
In the context of MPLS TE Fast Reroute ([FAST-REROUTE]), the Merge In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is
Point (MP) address is required at the Point of Local Repair (PLR) in required at the Point of Local Repair (PLR) in order to select a backup
order to select a backup tunnel intersecting a fast reroutable Traffic tunnel intersecting a fast reroutable Traffic Engineering LSP on a
Engineering LSP on a downstream LSR. However, existing protocol downstream LSR. However, existing protocol mechanisms are not
mechanisms are not sufficient to find an MP address in multi-areas or sufficient to find an MP address in multi-areas or multi-domain routing
multi-domain routing networks. Hence, the current MPLS Fast Reroute networks. Hence, the current MPLS Fast Reroute mechanism cannot be used
mechanism cannot be used to protect inter-area or inter-AS TE LSPs from to protect inter-area or inter-AS TE LSPs from a failure of an ABR
a failure of an ABR (Area Border Router) or ASBR (Autonomous System (Area Border Router) or ASBR (Autonomous System Border Router)
Border Router) respectively. This document specifies the use of respectively. This document specifies the use of existing RRO IPv4 and
existing RRO IPv4 and IPv6 subobjects (with a new flag defined) to IPv6 subobjects (with a new flag defined) to define the node-id
define the node-id subobject in order to solve this issue. Note that subobject in order to solve this issue. Note that the MPLS Fast reroute
the MPLS Fast reroute mechanism mentioned in this draft refers to the mechanism mentioned in this document refers to the "Facility backup"
"Facility backup" MPLS TE Fast Reroute method. MPLS TE Fast Reroute method.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [i]. document are to be interpreted as described in RFC-2119 [i].
1. Terminology 1. Terminology
LSR - Label Switch Router LSR - Label Switch Router
skipping to change at line 135 skipping to change at line 136
backup tunnel, and the latter should be the tail-end LSR of the backup 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 tunnel. The PLR is where FRR is triggered when link/node/SRLG failure
happens. happens.
There are different methods for computing paths for backup tunnels at a There are different methods for computing paths for backup tunnels at a
given PLR. Specifically, a user can statically configure one or more given PLR. Specifically, a user can statically configure one or more
backup tunnels at the PLR, with explicit path or the PLR can be backup tunnels at the PLR, with explicit path or the PLR can be
configured to automatically compute a backup path or to send a path 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). computation request to a PCS (which can be an LSR or an off-line tool).
Vasseur, Ali and Sivabalan 3
Consider the following scenario: Consider the following scenario:
Vasseur, Ali and Sivabalan 3
Assumptions: Assumptions:
- A multi-area network made of three areas: 0, 1 and 2. - A multi-area network made of three areas: 0, 1 and 2.
- A fast reroutable TE LSP T1 (TE LSP signaled with the "local - A fast reroutable TE LSP T1 (TE LSP signaled with the "local
Protection desired" bit set in the SESSION-ATTRIBUTE object or the FRR Protection desired" bit set in the SESSION-ATTRIBUTE object or the FRR
object) from R0 to R3 object) from R0 to R3
- A backup tunnel B1 from R1 to R2, not traversing ABR1, and following - A backup tunnel B1 from R1 to R2, not traversing ABR1, and following
the R1-ABR3-R2 path. R1 reroutes any protected TE LSP traversing ABR1 the R1-ABR3-R2 path. R1 reroutes any protected TE LSP traversing ABR1
onto the backup tunnel B1 in case of ABR1's failure. onto the backup tunnel B1 in case of ABR1's failure.
<--- area 1 --><---area 0---><---area 2---> <--- area 1 --><---area 0---><---area 2--->
R0-----R1-ABR1--R2------ABR2--------R3 R0-----R1-ABR1--R2------ABR2--------R3
\ / \ /
\ ABR3 / \ ABR3 /
When T1 is first signaled, the PLR R1 needs to dynamically select an When T1 is first signaled, the PLR R1 needs to dynamically select an
appropriate backup tunnel intersecting T1 on a downstream LSR. However, appropriate backup tunnel intersecting T1 on a downstream LSR. However,
existing protocol mechanisms are not sufficient to unambiguously find existing protocol mechanisms are not sufficient to unambiguously find
the MP address in a network with inter-area or inter-AS traffic the MP address in a network with inter-area or inter-AS traffic
engineering (although the example above was given in the context of engineering (although the example above was given in the context of
multi-area networks, a similar reasoning applies to TE LSP spanning multi-area networks, a similar reasoning applies to TE LSP spanning
multiple ASes). This draft addresses these limitations. multiple ASes). This document addresses these limitations.
R1 needs to ensure the following: R1 needs to ensure the following:
1. Backup tunnel intersects with the primary tunnel at the MP (and 1. Backup tunnel intersects with the primary tunnel at the MP (and
thus has a valid MP address), e.g., in Figure 1, R1 needs to thus has a valid MP address), e.g., in Figure 1, R1 needs to
determine that T1 and B1 share the same MP node R2, determine that T1 and B1 share the same MP node R2,
2. Backup tunnel satisfies the primary LSP's request with respect to 2. Backup tunnel satisfies the primary LSP's request with respect to
the bandwidth protection request (i.e., bandwidth guaranteed for the bandwidth protection request (i.e., bandwidth guaranteed for
the primary tunnel during failure), and the type of protection the primary tunnel during failure), and the type of protection
skipping to change at line 188 skipping to change at line 189
addresses . Hence, in Figure 1, router R2 may specify interface addresses . Hence, in Figure 1, router R2 may specify interface
addresses in the RROs for T1 and B1. Note that these interface addresses in the RROs for T1 and B1. Note that these interface
addresses are different in this example. addresses are different in this example.
The problem of finding the MP using the interface addresses or node-ids The problem of finding the MP using the interface addresses or node-ids
can be easily solved in a single area (OSPF_)/level (IS-IS). can be easily solved in a single area (OSPF_)/level (IS-IS).
Specifically, in the case of single area/level, the PLR has the Specifically, in the case of single area/level, the PLR has the
knowledge of all the interfaces attached to the tail-end of the backup knowledge of all the interfaces attached to the tail-end of the backup
tunnel. This information is available in PLR's IGP topology database. tunnel. This information is available in PLR's IGP topology database.
Thus, the PLR can determine whether a backup tunnel intersecting a Thus, the PLR can determine whether a backup tunnel intersecting a
protected TE LSP on a downstream node exists and can also find the MP
Vasseur, Ali and Sivabalan 4 Vasseur, Ali and Sivabalan 4
protected TE LSP on a downstream node exists and can also find the MP
address regardless of how the addresses contained in the RRO IPv4 or address regardless of how the addresses contained in the RRO IPv4 or
IPv6 subobjects are specified (i.e., whether using the interface IPv6 subobjects are specified (i.e., whether using the interface
addresses or the node IDs). However, such routing information is not addresses or the node IDs). However, such routing information is not
available in multi-area and inter-AS trafficengineering environments. available in multi-area and inter-AS trafficengineering environments.
Hence, unambiguously making sure that condition (1) above is met with Hence, unambiguously making sure that condition (1) above is met with
inter-area TE and inter-AS traffic-engineering TE LSPs is not possible inter-area TE and inter-AS traffic-engineering TE LSPs is not possible
with existing mechanisms. with existing mechanisms.
In this draft, we define extensions to and describe the use of RSVP In this document, we define extensions to and describe the use of RSVP
[RSVP, RSVP-TE] to solve the above-mentioned problem. [RSVP, RSVP-TE] to solve the above-mentioned problem.
3. Signaling node-ids in RROs 3. Signaling node-ids in RROs
As mentioned above, the limitation that we need to address is the As mentioned above, the limitation that we need to address is the
generality of the contents of the RRO IPv4 and IPv6 subobjects, as generality of the contents of the RRO IPv4 and IPv6 subobjects, as
defined in [RSVP-TE]. defined in [RSVP-TE].[RFC3209] defines the IPv4 and IPv6 RRO subobjects
along with two flags (namely the ôLocal Protection Availableö and
The IPv4 and IPv6 RRO subobjects are currently defined in [RSVP-TE] and ôLocal protection in useö bits). Moreover, other bits have been
have the following flags defined: specified in [FAST-REROUTE] and [SOFT-PREEMPTION].
Local protection available: 0x01
Indicates that the link downstream of this node is protected
via a local repair mechanism, which can be either one-to-one
or facility backup.
Local protection in use: 0x02
Indicates that a local repair mechanism is in use to maintain
this tunnel (usually in the face of an outage of the link it
was previously routed over, or an outage of the neighboring
node).
Bandwidth protection: 0x04
The PLR will set this when the protected LSP has a backup path
which is guaranteed to provide the desired bandwidth specified
in the FAST_REROUTE object or the bandwidth of the protected
LSP, if no FAST_REROUTE object was included. The PLR may set
this whenever the desired bandwidth is guaranteed; the PLR
MUST set this flag when the desired bandwidth is guaranteed
and the "bandwidth protection desired" flag was set in the
SESSION_ATTRIBUTE object. If the requested bandwidth is not
guaranteed, the PLR MUST NOT set this flag.
Node protection: 0x08
The PLR will set this when the protected LSP has a backup path
which provides protection against a failure of the next LSR
Vasseur, Ali and Sivabalan 5
along the protected LSP. The PLR may set this whenever node
protection is provided by the protected LSP's backup path; the
PLR MUST set this flag when the node protection is provided
and the "node protection desired" flag was set in the
SESSION_ATTRIBUTE object. If node protection is not provided,
the PLR MUST NOT set this flag. Thus, if a PLR could only
setup a link-protection backup path, the "Local protection
available" bit will be set but the "Node protection" bit will
be cleared.
Preemption pending: 0x10
The preempting node sets this flag if a pending preemption is
in progress for the TE LSP. This indicates to the HE of this
LSP that it must be re-routed as soon as possible using a make
before break.
In this document, we define the following new flag: In this document, we define the following new flag:
Node-id: 0x20 Node-id: 0x20
When set, this indicates that the address specified in the When set, this indicates that the address specified in the
RRO's IPv4 or IPv6 subobject is a node-id address, which refers RRO's IPv4 or IPv6 subobject is a node-id address, which refers
to the "Router Address" as defined in [OSPF-TE], or "Traffic to the "Router Address" as defined in [OSPF-TE], or "Traffic
Engineering Router ID" as defined in [ISIS-TE]. A node MUST use Engineering Router ID" as defined in [ISIS-TE]. A node MUST use
the same address consistently. In other words, once an address the same address consistently. In other words, once an address
skipping to change at line 289 skipping to change at line 243
Option 1: add the node-id subobject in an RSVP Resv message and, when Option 1: add the node-id subobject in an RSVP Resv message and, when
required, also add another IPv4/IPv6 subobject to record interface required, also add another IPv4/IPv6 subobject to record interface
address. address.
Example: a fast reroutable TE LSP would have in the RRO object carried Example: a fast reroutable TE LSP would have in the RRO object carried
in Resv message two subobjects: a node-id subobject and a label in Resv message two subobjects: a node-id subobject and a label
subobject. If recording the interface address is required, then an subobject. If recording the interface address is required, then an
additional IPv4/IPv6 subobject is added. additional IPv4/IPv6 subobject is added.
Vasseur, Ali and Sivabalan 5
Option 2: add an IPv4/IPv6 subobject recording the interface address Option 2: add an IPv4/IPv6 subobject recording the interface address
and, when required, add a node-id subobject in the RRO object. and, when required, add a node-id subobject in the RRO object.
Example: an inter-area/inter-AS fast reroutable TE LSP would have in Example: an inter-area/inter-AS fast reroutable TE LSP would have in
the RRO object carried in Resv message three subobjects: an IPv4/IPv6 the RRO object carried in Resv message three subobjects: an IPv4/IPv6
Vasseur, Ali and Sivabalan 6
subobject recording interface address, a label subobject and a node-id subobject recording interface address, a label subobject and a node-id
subobject. subobject.
Note also, that the node-id subobject may have other application than Note also, that the node-id subobject may have other application than
Fast Reroute backup tunnel selection. 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. Finding Merge Point 4. Finding Merge Point
Two cases should be considered: Two cases should be considered:
- case 1: the backup tunnel destination is the MP's node-id. Then a PLR - 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 can find the MP and suitable backup tunnel by simply comparing the
backup tunnel's destination address with the node-id included in the backup tunnel's destination address with the node-id included in the
RRO of the primary tunnel. RRO of the primary tunnel.
- case 2: the backup tunnel terminates at an address different than the - case 2: the backup tunnel terminates at an address different than the
skipping to change at line 323 skipping to change at line 278
object of the backup tunnel. A PLR can find the MP and suitable backup 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 tunnel by simply comparing the node-ids present in the RRO objects of
both the primary and backup tunnels. both the primary and backup tunnels.
When both IPv4 node-id and IPv6 node-id sub-objects are present, a PLR 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. may use any or both of them in finding the MP address.
5. Security Considerations 5. Security Considerations
This document does not introduce new security issues. The security This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RSVP] remain considerations pertaining to [RSVP] and [RSVP-TE] remain relevant.
relevant.
6. Intellectual Property Considerations 6. Intellectual Property Considerations
Cisco Systems may have intellectual property rights claimed in regard The IETF takes no position regarding the validity or scope of any
to some of the specification contained in this document intellectual property 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 does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication 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
Vasseur, Ali and Sivabalan 6
implementors or users of this specification can be obtained from the
IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice 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.
7. Acknowledgments 7. Acknowledgments
We would like to acknowledge input and helpful comments from Carol We would like to acknowledge input and helpful comments from Carol
Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen and Philip Matthews. Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, Philip Matthews and
Adrian Farrel.
Normative References
References
[RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version [RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version
1, Functional Specification", RFC 2205, September 1997. 1, Functional Specification", RFC 2205, September 1997.
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001. 3209, December 2001.
Vasseur, Ali and Sivabalan 7
[FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt, May 2003. LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, June 2003.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-
09.txt(work in progress).
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", [OSPF-TE] Katz et al., ôTraffic Engineering (TE) Extensions to OSPF
draft-ietf-isis-traffic-04.txt (work in progress) Version 2ö, RFC3630.
[MULTI-AREA-TE] Kompella at all,"Multi-area MPLS Traffic Engineering", [ISIS-TE] Smit et al., IS-IS extensions for Traffic Engineering,
draft-kompella-mpls-multiarea-te-03.txt, June 2002. draft-ietf-isis-traffic-05.txt, work in progress.
[LOOSE-PATH-REOPT] Vasseur and Ikejiri, "Reoptimization of an explicit Informative references
loosely routed MPLS TE paths", draft-vasseur-mpls-loose-path-reopt-
01.txt, February 2003, Work in Progress.
[INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering
requirements", draft-tewg-interas-te-req-02.txt (work in progress). requirements", draft-tewg-interas-te-req-05.txt, work in progress.
[INTER-AS-TE] Vasseur and Zhang, "MPLS Inter-AS Traffic Engineering", [INTER-AS-TE] Vasseur and Zhang, "MPLS Inter-AS Traffic Engineering",
draft-vasseur-mpls-inter-as-te-00.txt, February 2003, work in progress. draft-vasseur-mpls-inter-as-te-01.txt, work in progress.
[MULTI-AREA-TE] Kompella et al,"Multi-area MPLS Traffic Engineering",
draft-kompella-mpls-multiarea-te-03.txt, work in progress.
[LOOSE-PATH-REOPT] Vasseur, JP., Ikejiri, Y., "Reoptimization of MPLS
Vasseur, Ali and Sivabalan 7
Traffic Engineering loosely routed explicit LSP path", <draft-vasseur-
mpls-loose-path-reopt-02.txt>, Internet Draft, work in progress.
Authors' Address: Authors' Address:
Jean Philippe Vasseur Jean Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
skipping to change at line 391 skipping to change at line 373
USA USA
zali@cisco.com zali@cisco.com
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada Canada
msiva@cisco.com msiva@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it 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. This document and the information
contained herein is provided on an "AS IS" basis and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
Vasseur, Ali and Sivabalan 8 Vasseur, Ali and Sivabalan 8
DISCLAIMS 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
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/