draft-ietf-mpls-nodeid-subobject-07.txt   rfc4561.txt 
Network Working Group J.-P Vasseur (Editor) Network Working Group J.-P. Vasseur, Ed.
IETF Internet Draft Zafar Ali Request for Comments: 4561 Z. Ali
Siva Sivabalan Category: Standards Track S. Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
Proposed Status: Standard Definition of a Record Route Object (RRO) Node-Id Sub-Object
November 2005
draft-ietf-mpls-nodeid-subobject-07.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 Status of This Memo
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 This document specifies an Internet standards track protocol for the
http://www.ietf.org/ietf/1id-abstracts.txt. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html.
Vasseur et al. 1 Copyright (C) The Internet Society (2006).
Abstract Abstract
In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is In the context of MPLS TE Fast Reroute, the Merge Point (MP) address
required at the Point of Local Repair (PLR) in order to select a backup is required at the Point of Local Repair (PLR) in order to select a
tunnel intersecting a fast reroutable Traffic Engineering Label backup tunnel intersecting a fast reroutable Traffic Engineering
Switched Path (TE LSP) on a downstream Label Switching Router (LSR). Label Switched Path (TE LSP) on a downstream Label Switching Router
However, existing protocol mechanisms are not sufficient to find an MP (LSR). However, existing protocol mechanisms are not sufficient to
address in multi-domain routing networks where a domain is defined as find an MP address in multi-domain routing networks where a domain is
an IGP area or an Autonomous System. Hence, the current MPLS Fast defined as an Interior Gateway Protocol (IGP) area or an Autonomous
Reroute mechanism cannot be used in order to protect inter-domain TE System (AS). Hence, the current MPLS Fast Reroute mechanism cannot
LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous be used in order to protect inter-domain TE LSPs from a failure of an
System Border Router) respectively. This document specifies the use of Area Border Router (ABR) or Autonomous System Border Router (ASBR).
existing Route Record Object (RRO) IPv4 and IPv6 sub-objects (with a This document specifies the use of existing Record Route Object (RRO)
new flag defined) thus defining the node-id subobject in order to solve IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the
this issue. The MPLS Fast reroute mechanism mentioned in this document node-id sub-object in order to solve this issue. The MPLS Fast
refers to the "Facility backup" MPLS TE Fast Reroute method. 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 Points......................6
5. Security Considerations...................6
6. IANA Considerations.......................6
7. Intellectual Property Considerations......6
8. Acknowlegments............................7
9. References................................7
9.1 Normative References.....................7
9.2 Informative References...................7
10. Authors' addresses.......................8
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
ABR Routers: border routers used to connect two IGP areas (areas in
OSPF or levels in IS-IS)
ASBR Routers: border routers used to connect to another AS of a
different or the same Service Provider via one or more links inter-
connecting between ASs.
Backup Tunnel: the LSP that is used to backup up one of the many LSPs
in many-to-one backup.
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
Inter-area TE LSP: A TE LSP that crosses an IGP area.
LSR: Label Switching Router
LSP: Label Switched Path
Local Repair: techniques used to repair LSP tunnels quickly when a node
or link along the LSPs path fails.
PCE: Path Computation Element: an entity (component, application or
Vasseur, Ali and Sivabalan 2
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
MP: Merge Point. The LSR where one or more backup tunnels rejoin the
path of the protected LSP downstream of the potential failure.
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.
Reroutable LSP: Any LSP for with the "Local protection desired" bit is Table of Contents
set in the Flag field of the SESSION_ATTRIBUTE object of its Path
messages.
TE LSP: Traffic Engineering Label Switched Path 1. Introduction ....................................................2
2. Terminology .....................................................4
2.1. Conventions Used in This Document ..........................5
3. Signaling Node-Ids in RROs ......................................5
4. Finding Merge Point .............................................6
5. Security Considerations .........................................7
6. Acknowledgements ................................................7
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
2. Introduction 1. Introduction
MPLS Fast Reroute (FRR) ([FAST-REROUTE]) is a fast recovery local MPLS Fast Reroute (FRR) [FAST-REROUTE] is a fast recovery local
protection technique used to protect Traffic Engineering LSPs from protection technique used to protect Traffic Engineering LSPs from
link/SRLG/node failure. One or more backup tunnels are pre-established link/node/Shared Risk Link Group (SRLG) failure. One or more backup
to protect against the failure of a link/node/SRLG. In case of failure, tunnels are pre-established to protect against the failure of a
every protected TE LSP traversing the failed resource is rerouted onto link/node/SRLG. In case of failure, every protected TE LSP
the appropriate backup tunnels. traversing the failed resource is rerouted onto the appropriate
backup tunnel.
There are several requirements on the backup tunnel path that must be There are several requirements on the backup tunnel path that must be
satisfied. First, the backup tunnel must not traverse the element that satisfied. First, the backup tunnel must not traverse the element
it protects. Additionally, a primary tunnel and its associated backup that it protects. In addition, a primary tunnel and its associated
tunnel should intersect at least at two points (nodes): Point of Local backup tunnel should intersect at least at two points (nodes): Point
Repair (PLR) and Merge Point (MP). The former is the Head-end LSR of of Local Repair (PLR) and Merge Point (MP). The former is the head-
the backup tunnel and the latter is the Tail-end LSR of the backup end LSR of the backup tunnel, and the latter is the tail-end LSR of
tunnel. The PLR is where FRR is triggered when link/node/SRLG failure the backup tunnel. The PLR is where FRR is triggered when
happens. link/node/SRLG failure happens.
There are different methods for computing paths for backup tunnels at a There are different methods for computing paths for backup tunnels at
given PLR. Specifically, a user can statically configure one or more a given PLR. Specifically, a user can statically configure one or
backup tunnels at the PLR with an explicitly configured path or the PLR more backup tunnels at the PLR with an explicitly configured path, or
can be configured to automatically compute a backup path or to send a the PLR can be configured to automatically compute a backup path or
path computation request to a PCE (see [PCE-ARCH]). to send a path computation request to a PCE (see [PCE-ARCH]).
Consider the following scenario (figure 1) Consider the following scenario (Figure 1).
Assumptions: 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.
Vasseur, Ali and Sivabalan 3 - 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 - The PLR R1 reroutes any protected TE LSP traversing ABR1 onto the
backup tunnel B1 in case of ABR1's failure. 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
Figure 1: Use of Fast Reroute to protect a TE LSP against an ABR Figure 1: Use of Fast Reroute to protect a TE LSP against an ABR
failure with MPLS Traffic Engineering Fast Reroute failure with MPLS Traffic Engineering Fast Reroute
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.
existing protocol mechanisms are not sufficient to unambiguously find However, existing protocol mechanisms are not sufficient to
the MP address in a network with inter-domain TE LSP. This document unambiguously find the MP address in a network with inter-domain TE
addresses these limitations. LSP. This document addresses these limitations.
R1 needs to select an existing backup tunnel with the following R1 needs to select an existing backup tunnel with the following
properties: properties:
1. The backup tunnel intersects with the primary tunnel at the MP. 1. The backup tunnel intersects with the primary tunnel at the MP.
For the sake of illustration, in Figure 1, R1 needs to determine For the sake of illustration, in Figure 1, R1 needs to
that T1 and B1 intersect at the node R2. determine that T1 and B1 intersect at the node R2.
2. The backup tunnel satisfies the primary LSP's request with 2. The backup tunnel satisfies the primary LSP's request with
respect to the bandwidth protection request (i.e., bandwidth respect to the bandwidth protection request (i.e., bandwidth
guaranteed for the primary tunnel during failure), and the type guaranteed for the primary tunnel during failure), and the type
of protection (link or node failure), as specified in [FAST- of protection (link or node failure), as specified in
REROUTE]. [FAST-REROUTE].
One technique for the PLR to ensure that condition (1) is met consists One technique for the PLR to ensure that condition (1) is met
of examining the Record Route Object (RRO) of the primary tunnel to see consists of examining the Record Route Object (RRO) of the primary
if any of the addresses specified in the RRO corresponds to the MP. tunnel to see whether any of the addresses specified in the RRO
That said, as per [RSVP-TE], the addresses specified in the RRO IPv4 or correspond to the MP. That said, as per [RSVP-TE], the addresses
IPv6 sub-objects sent in Resv messages can be node-ids and/or interface specified in the RRO IPv4 or IPv6 sub-objects sent in Resv messages
addresses. Hence, in Figure 1, router R2 may specify interface can be node-ids and/or interface addresses. Hence, in Figure 1,
addresses in the RROs for T1 and B1. Note that these interface router R2 may specify interface addresses in the RROs for T1 and B1.
addresses are different in this example. Note that these interface 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-
can be easily solved in the case of a single IGP area. Specifically, in ids can be easily solved in the case of a single IGP area.
the case of a single IGP area, the PLR has the knowledge of all the Specifically, in the case of a single IGP area, the PLR has the
interfaces attached to the tail-end of the backup tunnel. This knowledge of all the interfaces attached to the tail-end of the
information is available in PLR's IGP topology database. Thus, the PLR backup tunnel. This information is available in PLR's IGP topology
can unambiguously determine whether a backup tunnel intersecting a database. Thus, the PLR can unambiguously determine whether a backup
protected TE LSP on a downstream node exists and can also find the MP tunnel intersecting a protected TE LSP on a downstream node exists
address regardless of how the addresses carried in the RRO IPv4 or IPv6 and can also find the MP address regardless of how the addresses
sub-objects are specified (i.e., whether using the interface addresses carried in the RRO IPv4 or IPv6 sub-objects are specified (i.e.,
or the node-ids). However, such routing information is not available in whether using the interface addresses or the node-ids). However,
the case of inter-domain environments. Hence, unambiguously making sure 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.
Vasseur, Ali and Sivabalan 4 In this document, we define extensions to and describe the use of
Resource Reservation Protocol (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-AS-TE-REQS].
that condition (1) above is met in the case of inter-domain TE LSPs is 2. Terminology
not possible with existing mechanisms.
In this document, we define extensions to and describe the use of RSVP Area Border Routers (ABRs): Border routers used to connect two
[RSVP, RSVP-TE] to solve the above-mentioned problem. Note that the Interior Gateway Protocol (IGP) areas (areas in OSPF or levels in
requirement for the support of the fast recovery technique specified in IS-IS).
[FAST-REROUTE] to inter-domain TE LSPs has been specified in [INTER-
AREA-TE-REQS] and [INTER-AREA-TE-REQS].
3. Signaling node-ids in RROs Autonomous System Border Router (ASBRs): Border routers used to
connect to another AS of a different or the same Service Provider via
one or more links inter-connecting between ASes.
Backup Tunnel: The LSP that is used to back up one of the many LSPs
in many-to-one backup.
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
Inter-area TE LSP: A TE LSP that crosses an IGP area.
LSR: Label Switching Router.
LSP: Label Switched Path.
Local Repair: Techniques used to repair TE LSPs quickly when a link,
an SRLG, or a node along the TE LSP fails.
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.
MP: Merge Point. The LSR where one or more backup tunnels rejoin the
path of the protected LSP downstream of the potential failure.
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.
Reroutable LSP: Any LSP for which the "Local Protection Desired" bit
is set in the Flag field of the SESSION_ATTRIBUTE object of its Path
messages.
TE LSP: Traffic Engineering Label Switched Path.
2.1. 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 [RFC2119].
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 sub-objects, as 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- defined in [RSVP-TE]. [RSVP-TE] defines the IPv4 and IPv6 RRO sub-
objects. Moreover, two additional flags are defined in [FAST-REROUTE]: objects. Moreover, two additional flags are defined in
the "Local Protection Available" and "Local protection in use" bits. [FAST-REROUTE]: the "Local Protection Available" and "Local
Protection in Use" bits.
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
RRO's IPv4 or IPv6 subobject is a node-id address, which refers IPv4 or IPv6 sub-object is a node-id address, which refers to the
to the "Router Address" as defined in [OSPF-TE], or "Traffic "Router Address" as defined in [OSPF-TE], or "Traffic Engineering
Engineering Router ID" as defined in [ISIS-TE]. A node MUST use Router ID" as defined in [ISIS-TE]. A node MUST use the same
the same address consistently. Once an address is used in RRO's address consistently. Once an address is used in the RRO's IPv4
IPv4 or IPv6 subobject, it SHOULD always be used for the or IPv6 sub-object, it SHOULD always be used for the lifetime of
lifetime of the LSP. the TE 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: An IPv4 or IPv6 RRO sub-object with the node-id flag set is also
called a node-id sub-object. The problem of finding an MP address in
a network with inter-domain TE LSP is solved by inserting a node-id
sub-object (an RRO "IPv4" and "IPv6" sub-object with the 0x20 flag
set) in the RRO object carried in the RSVP Resv message.
1) Add the node-id subobject in the RRO carried in an RSVP Resv message An implementation may decide to either:
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 1) Add the node-id sub-object in the RRO carried in an RSVP Resv
carried in Resv message two sub-objects: a node-id subobject and a message and, when required, also add another IPv4/IPv6 sub-object
label sub-object. If recording the interface address is required, then to record interface address.
an additional IPv4/IPv6 subobject is added.
2) Add an IPv4/IPv6 sub-object recording the interface address and, Example: an inter-domain fast reroutable TE LSP would have the
when required, add a node-id subobject in the RRO. following two sub-objects in the RRO carried in Resv message: a
node-id sub-object and a label sub-object. If recording the
interface address is required, then an additional IPv4/IPv6 sub-
object is added.
Example: an inter-domain fast reroutable TE LSP would have in the RRO or
carried in Resv message three sub-objects: an IPv4/IPv6 sub-object
Vasseur, Ali and Sivabalan 5 2) Add an IPv4/IPv6 sub-object recording the interface address and,
when required, add a node-id sub-object in the RRO.
recording interface address, a label sub-object and a node-id sub- Example: an inter-domain fast reroutable TE LSP would have the
object. following three sub-objects in the RRO carried in Resv message: 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 Note also that the node-id sub-object may have other applications
Fast Reroute backup tunnel selection. Moreover, it is RECOMMENDED that than Fast Reroute backup tunnel selection. Moreover, it is
an LSR recording a node-id address in an IPv4/IPv6 RRO sub-object also RECOMMENDED that an LSR recording a node-id address in an IPv4/IPv6
set the Node-id flag. 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: If the backup tunnel destination is the MP's node-id, then
can find the MP and suitable backup tunnel by simply comparing the a PLR can find the MP and suitable backup tunnel by simply
backup tunnel's destination address with the node-id included in the comparing the backup tunnel's destination address with the node-id
RRO of the primary tunnel. 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.
It must be noted that although the technique described in this document - Case 2: If the backup tunnel terminates at an address different
for selecting an appropriate backup tunnel using the node-id sub-object from the MP's node-id, then a node-id sub-object MUST also be
applies to the case of Inter-area and Inter-AS, in the case of Inter- included in the RRO of the backup tunnel. A PLR can find the MP
AS, the assumption is made that the MP's node-id (of the downstream and suitable backup tunnel by simply comparing the node-ids present
domain) does not overlap with any LSR's node-id present in the PLR's in the RROs of both the primary and backup tunnels.
AS.
When both IPv4 node-id and IPv6 node-id sub-objects are present, a PLR It must be noted that although the technique described in this
may use any or both of them in finding the MP address. document for selecting an appropriate backup tunnel using the node-id
sub-object applies to the case of Inter-area and Inter-AS, in the
case of Inter-AS, the assumption is made that the MP's node-id (of
the downstream domain) does not overlap with any LSR's node-id
present in the PLR's AS.
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. 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 [RSVP] and [RSVP-TE] remain relevant. considerations pertaining to [RSVP] and [RSVP-TE] remain relevant.
6. IANA considerations 6. Acknowledgements
This document does not make any request for IANA action.
7. 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.
Vasseur, Ali and Sivabalan 6
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.
8. 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, Philip Matthews. A Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, and Philip
special thank to Adrian Farrel for his thorough review of this Matthews. A special thanks to Adrian Farrel for his thorough review
document. of this document.
9. References
9.1 Normative References 7. References
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate 7.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version [RFC2119] Bradner, S., "Key words for use in RFCs to
1, Functional Specification", RFC 2205, September 1997. Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S.,
3209, December 2001. and S. Jamin, "Resource ReSerVation Protocol
(RSVP) -- Version 1 Functional Specification",
RFC 2205, September 1997.
[FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T.,
LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt. RFC 4090, Srinivasan, V., and G. Swallow, "RSVP-TE:
May 2005. Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001.
[OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF [FAST-REROUTE] Pan, P., Swallow, G., and A. Atlas, "Fast
Version 2", RFC3630. Reroute Extensions to RSVP-TE for LSP Tunnels",
RFC 4090, May 2005.
[ISIS-TE] Smit et al., "Intermediate System to Intermediate System (IS- [OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic
IS) - Extensions for Traffic Engineering (TE)IS-IS extensions for Engineering (TE) Extensions to OSPF Version 2",
Traffic Engineering", RFC3784. RFC 3630, September 2003.
9.2 Informative references [ISIS-TE] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for
Traffic Engineering (TE)", RFC 3784, June 2004.
[INTER-AREA-TE-REQS] Le Roux, Vasseur, Boyle et al., "Requirements for 7.2. Informative References
Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
Vasseur, Ali and Sivabalan 7 [INTER-AREA-TE-REQS] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle,
"Requirements for Inter-Area MPLS Traffic
Engineering", RFC 4105, June 2005.
[INTER-AS-TE-REQS] Zhang, Vasseur et al, "MPLS Inter-AS Traffic [INTER-AS-TE-REQS] Zhang, R. and J.-P. Vasseur, "MPLS Inter-
Engineering requirements", RFC 4216, November 2005. Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005.
[PCE-ARCH] Farrel, A., Vasseur JP., Ash J., "Path Computation Element [PCE-ARCH] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
(PCE) Architecture", draft-ietf-pce-architecture, work in progress. Computation Element (PCE) Based Architecture",
Work in Progress, April 2006.
10. Authors' Addresses Authors' Addresses
J.-P Vasseur (Editor) J.-P. Vasseur (Editor)
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com
EMail: jpv@cisco.com
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
100 South Main St. #200 100 South Main St. #200
Ann Arbor, MI 48104 Ann Arbor, MI 48104
USA USA
zali@cisco.com
EMail: 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
Full Copyright Statement EMail: msiva@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject to Copyright (C) The Internet Society (2006).
the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the authors retain all their rights. 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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Vasseur, Ali and Sivabalan 8 Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 61 change blocks. 
287 lines changed or deleted 251 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/