draft-ietf-mpls-nodeid-subobject-06.txt   draft-ietf-mpls-nodeid-subobject-07.txt 
Internet Draft Jean-Philippe Vasseur (Editor) Network Working Group J.-P Vasseur (Editor)
MPLS WG Zafar Ali IETF Internet Draft Zafar Ali
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
Proposed Status: Standard Proposed Status: Standard
Expires: November 2005 Expires: May 2006
May 2005 November 2005
draft-ietf-mpls-nodeid-subobject-06.txt draft-ietf-mpls-nodeid-subobject-07.txt
Definition of an RRO node-id subobject Definition of an RRO node-id subobject
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at line 37 skipping to change at line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
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 et al. 1
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 is
required at the Point of Local Repair (PLR) in order to select a backup required at the Point of Local Repair (PLR) in order to select a backup
tunnel intersecting a fast reroutable Traffic Engineering Label tunnel intersecting a fast reroutable Traffic Engineering Label
Switched Path (TE LSP) on a downstream Label Switch Router (LSR). Switched Path (TE LSP) on a downstream Label Switching Router (LSR).
However, existing protocol mechanisms are not sufficient to find an MP However, existing protocol mechanisms are not sufficient to find an MP
address in multi-domain routing networks where a domain is defined as address in multi-domain routing networks where a domain is defined as
an IGP area or an Autonomous System. Hence, the current MPLS Fast 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 Reroute mechanism cannot be used in order to protect inter-domain TE
failure of an ABR (Area Border Router) or ASBR (Autonomous System LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous
Border Router) respectively. This document specifies the use of System Border Router) respectively. This document specifies the use of
existing Route Record Object (RRO) IPv4 and IPv6 sub-objects (with a 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 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 this issue. The MPLS Fast reroute mechanism mentioned in this document
document refers to the "Facility backup" MPLS TE Fast Reroute method. refers to the "Facility backup" MPLS TE Fast Reroute method.
Table of content Table of content
1. Terminology ----------------------------- 1. Terminology...............................2
2. Introduction ---------------------------- 2. Introduction..............................3
3. Signaling node-ids in RROs ------------- 3. Signaling node-ids in RROs................5
4. Finding Merge Point --------------------- 4. Finding Merge Points......................6
5. Security Considerations ----------------- 5. Security Considerations...................6
6. IANA Consideration 6. IANA Considerations.......................6
7. Intellectual Property Considerations ---- 7. Intellectual Property Considerations......6
8. Acknowledgments ------------------------- 8. Acknowlegments............................7
9. References 9. References................................7
9.1 Normative references 9.1 Normative References.....................7
9.2 Informative references 9.2 Informative References...................7
10. Authors' addresses 10. Authors' addresses.......................8
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
Bypass Tunnel: an LSP that is used to protect a set of LSPs passing ABR Routers: border routers used to connect two IGP areas (areas in
over a common facility. 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 Backup Tunnel: the LSP that is used to backup up one of the many LSPs
in many-to-one backup. in many-to-one backup.
CSPF: Constraint-based Shortest Path First. Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
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
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. Inter-area TE LSP: A TE LSP that crosses an IGP area.
LSP: An MPLS Label Switched Path LSR: Label Switching Router
LSR: Label Switch Router LSP: Label Switched Path
Local Repair: techniques used to repair LSP tunnels quickly when a node Local Repair: techniques used to repair LSP tunnels quickly when a node
or link along the LSPs path fails. 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 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 network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints (see based on a network graph and applying computational constraints.
further description in section 3).
MP: Merge Point. The LSR where detour or backup tunnels meet the MP: Merge Point. The LSR where one or more backup tunnels rejoin the
protected LSP. In case of one-to-one backup, this is where multiple path of the protected LSP downstream of the potential failure.
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 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. 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 PLR: Point of Local Repair. The head-end of a backup tunnel.
LSP.
Reroutable LSP: Any LSP for with the "Local protection desired" bit is 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 set in the Flag field of the SESSION_ATTRIBUTE object of its Path
messages. messages.
TE LSP: Traffic Engineering Label Switched Path
2. Introduction 2. 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/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, 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 every protected TE LSP traversing the failed resource is rerouted onto
the appropriate backup tunnels in tens of msecs. the appropriate backup tunnels.
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 that
it protects. Additionally, a primary tunnel and its associated backup it protects. Additionally, a primary tunnel and its associated backup
tunnel should intersect at least at two points (nodes): Point of Local 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 Repair (PLR) and Merge Point (MP). The former is the Head-end LSR of
LSR of the backup tunnel and the latter should be the tail-end LSR of the backup tunnel and the latter is the Tail-end LSR of the backup
the backup tunnel. The PLR is where FRR is triggered when tunnel. The PLR is where FRR is triggered when link/node/SRLG failure
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 an explicitly configured path or the PLR 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 can be configured to automatically compute a backup path or to send a
path computation request to a PCE. 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 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 Protection desired" bit set in the SESSION-ATTRIBUTE object or the
FAST-REROUTE object) from R0 to R3, FAST-REROUTE 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. the R1-ABR3-R2 path.
Vasseur, Ali and Sivabalan 3
- 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. 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-domain TE LSP. Note that the MP address in a network with inter-domain TE LSP. This document
although the example above was given in the context of inter-area TE addresses these limitations.
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 R1 needs to select an existing backup tunnel with the following
(and thus has a valid MP address). For the sake of illustration, properties:
Vasseur, Ali and Sivabalan 4 1. The backup tunnel intersects with the primary tunnel at the MP.
in Figure 1, R1 needs to determine that T1 and B1 share the same For the sake of illustration, in Figure 1, R1 needs to determine
MP node R2. 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 (preferably, protecting against a node failure of protection (link or node failure), as specified in [FAST-
versus a link failure), as specified in [FAST-REROUTE]. REROUTE].
A PLR can make sure that condition (1) is met by examining the Record One technique for the PLR to ensure that condition (1) is met consists
Route Object (RRO) of the primary tunnel to see if any of the addresses of examining the Record Route Object (RRO) of the primary tunnel to see
specified in the RRO is attached to the tail-end of the backup tunnel. if any of the addresses specified in the RRO corresponds to the MP.
As per [RSVP-TE], the addresses specified in the RRO IPv4 or IPv6 sub- That said, as per [RSVP-TE], the addresses specified in the RRO IPv4 or
objects sent in Resv messages can be node-ids and/or interface 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. 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 the case of a single IGP area. Specifically, in 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 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 interfaces attached to the tail-end of the backup tunnel. This
information is available in PLR's IGP topology database. Thus, the PLR information is available in PLR's IGP topology database. Thus, the PLR
can unambiguously determine whether a backup tunnel intersecting a can unambiguously determine whether a backup tunnel intersecting a
protected TE LSP on a downstream node exists and can also find the MP 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 address regardless of how the addresses carried in the RRO IPv4 or IPv6
sub-objects are specified (i.e., whether using the interface addresses sub-objects are specified (i.e., whether using the interface addresses
or the node-ids). However, such routing information is not available in or the node-ids). However, such routing information is not available in
the case of inter-domain environments. Hence, unambiguously making sure the case of inter-domain environments. Hence, unambiguously making sure
Vasseur, Ali and Sivabalan 4
that condition (1) above is met in the case of inter-domain TE LSPs is that condition (1) above is met in the case of inter-domain TE LSPs is
not possible with existing mechanisms. not possible with existing mechanisms.
In this document, 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. Note that the [RSVP, RSVP-TE] to solve the above-mentioned problem. Note that the
requirement for the support of the fast recovery technique specified in requirement for the support of the fast recovery technique specified in
[FAST-REROUTE] to inter-domain TE LSPs has been specified in [INTER- [FAST-REROUTE] to inter-domain TE LSPs has been specified in [INTER-
AREA-TE-REQS] and [INTER-AREA-TE-REQS]. AREA-TE-REQS] and [INTER-AREA-TE-REQS].
2. 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 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 [FAST-REROUTE]:
the "Local Protection Available" and "Local protection in use" bits. 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
Vasseur, Ali and Sivabalan 5
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. Once an address is used in RRO's the same address consistently. Once an address is used in RRO's
IPv4 or IPv6 subobject, it should always be used for the IPv4 or IPv6 subobject, it SHOULD always be used for the
lifetime of the LSP. lifetime of the LSP.
An IPv4 or IPv6 RRO subobject with the node-id flag set is also called 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 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 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 RRO "IPv4" and "IPv6" sub-object with the 0x20 flag set) in the RRO
object carried in the RSVP Resv message. object carried in the RSVP Resv message.
An implementation may either decide to: An implementation may either decide to:
1) Add the node-id subobject in an RSVP Resv message and, when 1) Add the node-id subobject in the RRO carried in an RSVP Resv message
required, also add another IPv4/IPv6 subobject to record interface and, when required, also add another IPv4/IPv6 subobject to record
address. interface address.
Example: an inter-domain fast reroutable TE LSP would have in the RRO 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 carried in Resv message two sub-objects: a node-id subobject and a
a label sub-object. If recording the interface address is required, label sub-object. If recording the interface address is required, then
then an additional IPv4/IPv6 subobject is added. an additional IPv4/IPv6 subobject is added.
2) Add an IPv4/IPv6 sub-object recording the interface address and, 2) Add an IPv4/IPv6 sub-object recording the interface address and,
when required, add a node-id subobject in the RRO object. when required, add a node-id subobject in the RRO.
Example: an inter-domain fast reroutable TE LSP would have in the RRO 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- carried in Resv message three sub-objects: an IPv4/IPv6 sub-object
object recording interface address, a label sub-object and a node-id
sub-object. Vasseur, Ali and Sivabalan 5
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 application than
Fast Reroute backup tunnel selection. Moreover, it is RECOMMENDED that 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 an LSR recording a node-id address in an IPv4/IPv6 RRO sub-object also
set the Node-id flag. set the Node-id flag.
3. 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
MP's node-id. Then a node-id subobject MUST also be included in the RRO 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 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.
Vasseur, Ali and Sivabalan 6 It must be noted that although the technique described in this 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 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.
4. 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.
5. IANA considerations 6. 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). This document does not make any request for IANA action.
6. Intellectual Property Considerations 7. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 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 any independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79. 78 and BCP 79.
Vasseur, Ali and Sivabalan 6
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this that may cover technology that may be required to implement this
standard. Please address the information to the IETF at ietf- standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
7. Acknowledgments 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 and Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, Philip Matthews. A
Adrian Farrel. special thank to Adrian Farrel for his thorough review of this
document.
8. References 9. References
8.1 Normative References 9.1 Normative References
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate [RFC2119]Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Vasseur, Ali and Sivabalan 7
[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 [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.
[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-07.txt. Work in LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt. RFC 4090,
progress. May 2005.
[OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF [OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF
Version 2", RFC3630. Version 2", RFC3630.
[ISIS-TE] Smit et al., "Intermediate System to Intermediate System (IS- [ISIS-TE] Smit et al., "Intermediate System to Intermediate System (IS-
IS) - Extensions for Traffic Engineering (TE)IS-IS extensions for IS) - Extensions for Traffic Engineering (TE)IS-IS extensions for
Traffic Engineering", RFC3784. Traffic Engineering", RFC3784.
8.2 Informative references 9.2 Informative references
[INTER-AREA-TE-REQS] Le Roux, Vasseur, Boyle et al., "Requirements for [INTER-AREA-TE-REQS] Le Roux, Vasseur, Boyle et al., "Requirements for
Inter-Area MPLS Traffic Engineering", draft-ietf-tewg-interarea-mpls-te- Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
req-03.txt. Work in progress.
Vasseur, Ali and Sivabalan 7
[INTER-AS-TE-REQS] Zhang, Vasseur et al, "MPLS Inter-AS Traffic [INTER-AS-TE-REQS] Zhang, Vasseur et al, "MPLS Inter-AS Traffic
Engineering requirements", draft-tewg-interas-te-req-09.txt. Work in Engineering requirements", RFC 4216, November 2005.
progress.
9. Authors' Addresses [PCE-ARCH] Farrel, A., Vasseur JP., Ash J., "Path Computation Element
(PCE) Architecture", draft-ietf-pce-architecture, work in progress.
Jean-Philippe Vasseur 10. Authors' Addresses
J.-P Vasseur (Editor)
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 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 zali@cisco.com
Vasseur, Ali and Sivabalan 8
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 Full Copyright Statement
Full Copyright Statement Full Copyright Statement
skipping to change at line 431 skipping to change at line 415
as set forth therein, the authors retain all their rights. 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 9 Vasseur, Ali and Sivabalan 8
 End of changes. 58 change blocks. 
132 lines changed or deleted 116 lines changed or added

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