draft-ietf-ccamp-inter-domain-rsvp-te-04.txt   draft-ietf-ccamp-inter-domain-rsvp-te-05.txt 
INTERNET-DRAFT A. Farrel (Editor)
Network Working Group A. Farrel Network Working Group Old Dog Consulting
Proposed Status: Standards Track Old Dog Consulting Intended Status: Standards Track
Updates: RFC 3209, RFC 3473 Updates: RFC 3209, RFC 3473 A. Ayyangar
Expires: July 2007 A. Ayyangar Expires: August 2007 Nuova Systems
Nuova Systems
JP. Vasseur JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
January 2007 February 2007
Inter domain MPLS and GMPLS Traffic Engineering - RSVP-TE extensions Inter domain Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt draft-ietf-ccamp-inter-domain-rsvp-te-05.txt
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions Used In This Document . . . . . . . . . . . . 3 1.1 Conventions Used In This Document . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Signaling Overview . . . . . . . . . . . . . . . . . . . . . 4 2. Signaling Overview . . . . . . . . . . . . . . . . . . . . . 4
2.1 Signaling Options . . . . . . . . . . . . . . . . . . . . 4 2.1 Signaling Options . . . . . . . . . . . . . . . . . . . . 4
3. Procedures on the Domain Border Node . . . . . . . . . . . . . 5 3. Procedures on the Domain Border Node . . . . . . . . . . . . . 5
3.1 Rules on ERO Processing . . . . . . . . . . . . . . . . . 6 3.1 Rules on ERO Processing . . . . . . . . . . . . . . . . . 6
3.2 LSP Setup Failure and Crankback . . . . . . . . . . . . . 8 3.2 LSP Setup Failure and Crankback . . . . . . . . . . . . . 8
3.3 RRO Processing Across Domains . . . . . . . . . . . . . . 8 3.3 RRO Processing Across Domains . . . . . . . . . . . . . . 9
3.4 Notify Message Processing . . . . . . . . . . . . . . . . 9 3.4 Notify Message Processing . . . . . . . . . . . . . . . . 9
4. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . . 9 4. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . . 10
4.1 Control of Downstream Choice of Signaling Method . . . . . 9 4.1 Control of Downstream Choice of Signaling Method . . . . . 10
5. Protection and Recovery of Inter-Domain TE LSPs . . . . . . . 10 5. Protection and Recovery of Inter-Domain TE LSPs . . . . . . . 11
5.1 Fast Recovery Support Using MPLS-TE Fast Reroute . . . . . 11 5.1 Fast Recovery Support Using MPLS-TE Fast Reroute . . . . . 11
5.1.1 Failure Within a Domain (Link or Node Failure) . . . . 11 5.1.1 Failure Within a Domain (Link or Node Failure) . . . . 12
5.1.2 Failure of Link at Domain Borders . . . . . . . . . . 11 5.1.2 Failure of Link at Domain Borders . . . . . . . . . . 12
5.1.3 Failure of a Border Node . . . . . . . . . . . . . . . 12 5.1.3 Failure of a Border Node . . . . . . . . . . . . . . . 12
5.2 Protection and Recovery of GMPLS LSPs . . . . . . . . . . 12 5.2 Protection and Recovery of GMPLS LSPs . . . . . . . . . . 13
6. Re-Optimization of Inter-Domain TE LSPs . . . . . . . . . . . 13 6. Re-Optimization of Inter-Domain TE LSPs . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8.1 Attribute Flags for LSP_Attributes Object . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 15 9.1 Attribute Flags for LSP_Attributes Object . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10.1 Normative References . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.2 Informative References . . . . . . . . . . . . . . . . . 16 11.1 Normative References . . . . . . . . . . . . . . . . . . 18
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 11.2 Informative References . . . . . . . . . . . . . . . . . 18
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The requirements for inter-area and inter-AS Multiprotocol Label The requirements for inter-area and inter-AS Multiprotocol Label
Switching (MPLS) Traffic Engineering (TE) are stated in [RFC4105] and Switching (MPLS) Traffic Engineering (TE) are stated in [RFC4105] and
[RFC4216] respectively. Many of these requirements also apply to [RFC4216] respectively. Many of these requirements also apply to
Generalized MPLS (GMPLS) networks. The framework for inter-domain Generalized MPLS (GMPLS) networks. The framework for inter-domain
MPLS-TE is provided in [INTER-DOMAIN-FRAMEWORK]. MPLS-TE is provided in [RFC4726].
This document presents procedures and extensions to Resource This document presents procedures and extensions to Resource
Reservation Protocol Traffic Engineering (RSVP-TE) signaling for the Reservation Protocol Traffic Engineering (RSVP-TE) signaling for the
setup and maintenance of traffic engineered Label Switched Paths (TE setup and maintenance of traffic engineered Label Switched Paths (TE
LSPs) that span multiple domains in MPLS-TE or GMPLS networks. The LSPs) that span multiple domains in MPLS-TE or GMPLS networks. The
signaling procedures described in this document are applicable to signaling procedures described in this document are applicable to
MPLS-TE packet LSPs established using RSVP-TE ([RFC3209]) and all MPLS-TE packet LSPs established using RSVP-TE ([RFC3209]) and all
LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as
described in [RFC3473]. described in [RFC3473].
Three different signaling methods for inter-domain RSVP-TE signaling Three different signaling methods for inter-domain RSVP-TE signaling
are identified in [INTER-DOMAIN-FRAMEWORK]. Contiguous LSPs are are identified in [RFC4726]. Contiguous LSPs are
achieved using the procedures of [RFC3209] and [RFC3473] to create a achieved using the procedures of [RFC3209] and [RFC3473] to create a
single end-to-end LSP that spans all domains. Nested LSPs are single end-to-end LSP that spans all domains. Nested LSPs are
established using the techniques described in [RFC4206] to carry the established using the techniques described in [RFC4206] to carry the
end-to-end LSP in a separate tunnel across each domain. Stitched LSPs end-to-end LSP in a separate tunnel across each domain. Stitched LSPs
are established using the procedures of [LSP-STITCHING] to construct are established using the procedures of [LSP-STITCHING] to construct
an end-to-end LSP from the concatenation of separate LSPs each an end-to-end LSP from the concatenation of separate LSPs each
spanning a domain. spanning a domain.
This document defines the RSVP-TE protocol extensions necessary to This document defines the RSVP-TE protocol extensions necessary to
control and select which of the three signaling mechanisms is used control and select which of the three signaling mechanisms is used
skipping to change at page 4, line 15 skipping to change at page 4, line 15
PLR: Point of Local Repair. The ingress of a bypass tunnel. PLR: Point of Local Repair. The ingress of a bypass tunnel.
RRO: Record Route Object. RRO: Record Route Object.
TE link: Traffic Engineering link. TE link: Traffic Engineering link.
2. Signaling Overview 2. Signaling Overview
The RSVP-TE signaling of a TE LSP within a single domain is described The RSVP-TE signaling of a TE LSP within a single domain is described
in [RFC3209] and [RFC3473]. Inter-domain TE LSPs can be supported by in [RFC3209] and [RFC3473]. Inter-domain TE LSPs can be supported by
one of three options as described in the next section: one of three options as described in [RFC4726] and set out in the
next section:
- contiguous LSPs - contiguous LSPs
- nested LSPs - nested LSPs
- stitched LSPs. - stitched LSPs.
In fact, as pointed out in [RFC4726], any combination of these three
options may be used in the course of an end-to-end inter-domain LSP.
This document describes the RSVP-TE signaling extensions required to This document describes the RSVP-TE signaling extensions required to
control and select which of the three signaling mechanisms is used control and select which of the three signaling mechanisms is used
for any one end-to-end inter-domain TE LSP. for any one end-to-end inter-domain TE LSP.
The specific protocol extensions required to signal each LSP type are The specific protocol extensions required to signal each LSP type are
described in other documents and are out of scope for this document. described in other documents and are out of scope for this document.
Similarly, the routing extensions and path computation techniques Similarly, the routing extensions and path computation techniques
necessary for the establishment of inter-domain LSPs are out of necessary for the establishment of inter-domain LSPs are out of
scope. scope.
skipping to change at page 6, line 8 skipping to change at page 6, line 14
send a PathErr message with error code "Policy control failure"/ send a PathErr message with error code "Policy control failure"/
"Inter-domain policy failure". "Inter-domain policy failure".
2. Determine the signaling method to be used to cross the domain. 2. Determine the signaling method to be used to cross the domain.
If the ingress node of the inter-domain TE LSP has specified If the ingress node of the inter-domain TE LSP has specified
restrictions on the methods to be used, these MUST be adhered restrictions on the methods to be used, these MUST be adhered
to. Within the freedom allowed by the ingress node, the domain to. Within the freedom allowed by the ingress node, the domain
border node MAY choose any method according to local border node MAY choose any method according to local
configuration and policies. If no resultant signaling method is configuration and policies. If no resultant signaling method is
available or allowed, the domain border node MUST send a PathErr available or allowed, the domain border node MUST send a PathErr
message an error code as described in Section 4.1. message with an error code as described in Section 4.1.
3. Carry out ERO procedures as described in the Section 3 in 3. Carry out ERO procedures as described in Section 3 in addition
addition to the procedures in [RFC3209] and [RFC3473]. to the procedures in [RFC3209] and [RFC3473].
4. Perform any path computations as required to determine the path 4. Perform any path computations as required to determine the path
across the domain and potentially to select the exit point from across the domain and potentially to select the exit point from
the domain. the domain.
The path computation procedure is outside the scope of this The path computation procedure is outside the scope of this
document. A path computation option is supplied in document. A path computation option is specified in
[INTER-DOMAIN-PD-PATH-COMP], and another option is to use a [INTER-DOMAIN-PD-PATH-COMP], and another option is to use a
Path Computation Element (PCE) [RFC4655]. Path Computation Element (PCE) [RFC4655].
4a. In the case of nesting or stitching, either find an existing 4a. In the case of nesting or stitching, either find an existing
intra-domain TE LSP to carry the inter-domain TE LSP or intra-domain TE LSP to carry the inter-domain TE LSP or
signal a new one, depending on local policy. signal a new one, depending on local policy.
In event of a path computation failure, a PathErr message SHOULD In event of a path computation failure, a PathErr message SHOULD
be sent with error code "Routing Problem" using an error value be sent with error code "Routing Problem" using an error value
selected according to the reason for computation failure. selected according to the reason for computation failure.
skipping to change at page 8, line 16 skipping to change at page 8, line 21
When an error occurs during LSP setup a PathErr message is sent back When an error occurs during LSP setup a PathErr message is sent back
towards the LSP ingress node to report the problem. If the LSP towards the LSP ingress node to report the problem. If the LSP
traverses multiple domains, this PathErr will be seen successively by traverses multiple domains, this PathErr will be seen successively by
each domain border node. each domain border node.
Domain border nodes MAY apply local policies to restrict the Domain border nodes MAY apply local policies to restrict the
propagation of information about the contents of the domain. For propagation of information about the contents of the domain. For
example, a domain border node MAY replace the information in a example, a domain border node MAY replace the information in a
PathErr message that indicates a specific failure at a specific node PathErr message that indicates a specific failure at a specific node
with information that report a more general error with the entire with information that reports a more general error with the entire
domain. These procedures are similar to those described for the domain. These procedures are similar to those described for the
borders of overlay networks in [RFC4208]. borders of overlay networks in [RFC4208].
However: However:
- A domain border node MUST NOT suppress the propagation of a PathErr - A domain border node MUST NOT suppress the propagation of a PathErr
message message.
- Nodes other than domain border nodes SHOULD NOT modify the contents - Nodes other than domain border nodes SHOULD NOT modify the contents
of a PathErr message of a PathErr message.
- Domain border nodes SHOULD NOT modify the contents of a PathErr - Domain border nodes SHOULD NOT modify the contents of a PathErr
message unless domain confidentiality is a specific requirement. message unless domain confidentiality is a specific requirement.
Domain border nodes provide an opportunity for crankback rerouting Domain border nodes provide an opportunity for crankback rerouting
[CRANKBACK]. On receipt of a PathErr message generated because of an [CRANKBACK]. On receipt of a PathErr message generated because of an
LSP setup failure, a domain border node MAY hold the PathErr and make LSP setup failure, a domain border node MAY hold the PathErr and make
further attempts to establish the LSP if allowed by local policy and further attempts to establish the LSP if allowed by local policy and
by the parameters signaled on the Path message for the LSP. Such by the parameters signaled on the Path message for the LSP. Such
attempts might involve the computation of alternate routes through attempts might involve the computation of alternate routes through
the domain, or the selection of different downstream domains. If a the domain, or the selection of different downstream domains. If a
skipping to change at page 9, line 31 skipping to change at page 9, line 41
3.4. Notify Message Processing 3.4. Notify Message Processing
Notify messages are introduced in [RFC3473]. They may be sent direct Notify messages are introduced in [RFC3473]. They may be sent direct
rather than hop-by-hop, and so may speed the propagation of error rather than hop-by-hop, and so may speed the propagation of error
information. If a domain border router is interested in seeing information. If a domain border router is interested in seeing
such messages (for example, to enable it to provide protection such messages (for example, to enable it to provide protection
switching), it is RECOMMENDED that the domain border router update switching), it is RECOMMENDED that the domain border router update
the Notify Request objects in the Path and Resv messages to show its the Notify Request objects in the Path and Resv messages to show its
own address following the procedures of [RFC3473]. own address following the procedures of [RFC3473].
Note that the replacement of a Notify Recipient in the Notify Request
object means that some Notify messages (for example, those intended
for delivery to the ingress LSR) may need to be examined, processed
and forwarded at domain borders. This is an obvious trade-off issue
as the ability to handle notifiable events locally (i.e. within the
domain) may or may not outweigh the cost of processing and forwarding
Notify messages beyond the domain. Observe that the cost increases
linearly with the number of domains in use.
Also note that, as described in section 8, a domain administrator may
wish to filter or modify Notify messages that are generated within a
domain in order to preserve security or confidentiality of network
information. This is most easily achieved if the Notify messages are
sent via the domain borders.
4. RSVP-TE Signaling Extensions 4. RSVP-TE Signaling Extensions
The following RSVP-TE signaling extensions are defined to enable The following RSVP-TE signaling extensions are defined to enable
inter-domain LSP setup. inter-domain LSP setup.
4.1. Control of Choice of Signaling Method 4.1. Control of Choice of Signaling Method
In many network environments there may be a network-wide policy that In many network environments there may be a network-wide policy that
determines which one of the three inter-domain LSP techniques is determines which one of the three inter-domain LSP techniques is
used. In these cases, no protocol extensions are required. used. In these cases, no protocol extensions are required.
skipping to change at page 10, line 5 skipping to change at page 10, line 28
nodes for each inter-domain TE LSP that it originates. nodes for each inter-domain TE LSP that it originates.
[RFC4420] defines the LSP_Attributes object that can be used to [RFC4420] defines the LSP_Attributes object that can be used to
signal required attributes of an LSP. The Attributes Flags TLV signal required attributes of an LSP. The Attributes Flags TLV
includes Boolean flags that define individual attributes. includes Boolean flags that define individual attributes.
This document defines a new bit in the TLV that can be set by the This document defines a new bit in the TLV that can be set by the
ingress node of an inter-domain TE LSP to restrict the intermediate ingress node of an inter-domain TE LSP to restrict the intermediate
nodes to using contiguous signaling. nodes to using contiguous signaling.
Contiguous LSP bit (bit number assignment in Section 8.1). Contiguous LSP bit (bit number assignment in Section 9.1).
This flag is set by the ingress node that originates a Path message This flag is set by the ingress node that originates a Path message
to set up an inter-domain TE LSP if it requires that the contiguous to set up an inter-domain TE LSP if it requires that the contiguous
LSP technique is used. This flag bit is only to be used in the LSP technique is used. This flag bit is only to be used in the
Attributes Flags TLV. Attributes Flags TLV.
When an LSR receives a Path message containing this bit set (one), When a domain border LSR receives a Path message containing this bit
the node MUST NOT perform stitching or nesting in support of the TE set (one), the node MUST NOT perform stitching or nesting in support
LSP being set up. When this bit is clear (zero), an intermediate node of the inter-domain TE LSP being set up. When this bit is clear
MAY perform stitching or nesting according to local policy. (zero), a domain border LSR MAY perform stitching or nesting
according to local policy.
This bit MUST NOT be modified by any transit node. This bit MUST NOT be modified by any transit node.
An intermediate node that supports the LSP_Attributes object and the An intermediate node that supports the LSP_Attributes object and the
Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit, Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit,
but cannot support contiguous TE LSPs, MUST send a Path Error message but cannot support contiguous TE LSPs, MUST send a Path Error message
with an error code "Routing Problem"/"Contiguous LSP type not with an error code "Routing Problem"/"Contiguous LSP type not
supported" if it receives a Path message with this bit set. supported" if it receives a Path message with this bit set.
If an intermediate node receiving a Path message with the "Contiguous If an intermediate node receiving a Path message with the "Contiguous
LSP" bit set in the Flags field of the LSP_Attributes, recognizes the LSP" bit set in the Flags field of the LSP_Attributes, recognizes the
object, the TLV and the bit and also supports the desired contiguous object, the TLV, and the bit and also supports the desired contiguous
LSP behavior, then it MUST signal a contiguous LSP. If the node is a LSP behavior, then it MUST signal a contiguous LSP. If the node is a
domain border node, or if the node expands a loose hop in the ERO, it domain border node, or if the node expands a loose hop in the ERO, it
SHOULD include an RRO Attributes subobject in the RRO of the MUST include an RRO Attributes subobject in the RRO of the
corresponding Resv message with the "Contiguous LSP" bit set to corresponding Resv message (if such an object is present) with the
report its behavior. "Contiguous LSP" bit set to report its behavior.
Domain border LSRs MUST support and act on the setting of the
"Contiguous LSP" flag.
However, if the intermediate node supports the LSP_Attributes object However, if the intermediate node supports the LSP_Attributes object
but does not recognize the Attributes Flags TLV, or supports the TLV but does not recognize the Attributes Flags TLV, or supports the TLV
but does not recognize this "Contiguous LSP" bit, then it MUST reject but does not recognize this "Contiguous LSP" bit, then it MUST
the Path message with a PathErr message as described in [RFC4420]. forward the object unmodified.
The choice of action by an ingress node that receives a PathErr when The choice of action by an ingress node that receives a PathErr when
requesting the use of a contiguous LSP is out of the scope of this requesting the use of a contiguous LSP is out of the scope of this
document, but may include the computation of an alternate path. document, but may include the computation of an alternate path.
5. Protection and Recovery of Inter-Domain TE LSPs 5. Protection and Recovery of Inter-Domain TE LSPs
The procedures described in Sections 3 and 4 MUST be applied to all The procedures described in Sections 3 and 4 MUST be applied to all
inter-domain TE LSPs, including bypass tunnels, detour LSPs inter-domain TE LSPs, including bypass tunnels, detour LSPs
[RFC4090], and segment recovery LSPs [SEGMENT-PROTECTION]. This means [RFC4090], and segment recovery LSPs [SEGMENT-PROTECTION]. This means
skipping to change at page 11, line 44 skipping to change at page 12, line 26
5.1.2. Failure of a Link at a Domain Borders 5.1.2. Failure of a Link at a Domain Borders
This cases arises where two domains are connected by a TE link. In This cases arises where two domains are connected by a TE link. In
this case each domain has its own domain border node, and these two this case each domain has its own domain border node, and these two
nodes are connected by the TE link. An example of this case is where nodes are connected by the TE link. An example of this case is where
the ASBRs of two ASes are connected by a TE link. the ASBRs of two ASes are connected by a TE link.
A contiguous LSP can be backed up using any PLR and MP, but if the A contiguous LSP can be backed up using any PLR and MP, but if the
LSP uses stitching or nesting in either of the connected domains, the LSP uses stitching or nesting in either of the connected domains, the
PLR and MP MUST be domain border nodes for those domains. It will be PLR and MP MUST be domain border nodes for those domains. It will be
usual to attempt to use the local (connected by the filed link) usual to attempt to use the local (connected by the failed link)
domain border nodes as the PLR and MP. domain border nodes as the PLR and MP.
To protect an inter-domain link with MPLS-TE Fast Reroute, a set of To protect an inter-domain link with MPLS-TE Fast Reroute, a set of
backup tunnels must be configured or dynamically computed between the backup tunnels must be configured or dynamically computed between the
PLR and MP such that they are diversely routed from the protected PLR and MP such that they are diversely routed from the protected
inter-domain link and the protected inter-domain LSPs. inter-domain link and the protected inter-domain LSPs.
Each protected inter-domain LSP using the protected inter-domain TE Each protected inter-domain LSP using the protected inter-domain TE
link must be assigned to an NHOP bypass tunnel that is diverse from link must be assigned to an NHOP bypass tunnel that is diverse from
the protected LSP. Such an NHOP bypass tunnel can be selected by the protected LSP. Such an NHOP bypass tunnel can be selected by
skipping to change at page 12, line 25 skipping to change at page 13, line 6
border node (as is the case with IGP areas) that single border node border node (as is the case with IGP areas) that single border node
may fail. may fail.
It can be seen that if stitching or nesting are used, the failed node It can be seen that if stitching or nesting are used, the failed node
will be the start or end (or both) or a stitching segment LSP or will be the start or end (or both) or a stitching segment LSP or
H-LSP in which case, protection must be provided to the far end of H-LSP in which case, protection must be provided to the far end of
stitching segment or H-LSP. Thus, where one of these two techniques stitching segment or H-LSP. Thus, where one of these two techniques
is in use, the PLR will be the upstream domain entry point in the is in use, the PLR will be the upstream domain entry point in the
case of the failure of the domain exit point, and the MP will be the case of the failure of the domain exit point, and the MP will be the
downstream domain exit point in the case of the failure of the downstream domain exit point in the case of the failure of the
domian entry point. Where the domain border falls at a single domain domain entry point. Where the domain border falls at a single domain
border node, both cases will apply. border node, both cases will apply.
If the contiguous LSP mechanism is in use, normal selection of the If the contiguous LSP mechanism is in use, normal selection of the
PLR and MP can be applied and any node within the domains may be used PLR and MP can be applied and any node within the domains may be used
to fill these roles. to fill these roles.
As before, selection of a suitable backup tunnel (in this case an As before, selection of a suitable backup tunnel (in this case an
NNHOP backup) must consider the paths of the backed up LSPs and the NNHOP backup) must consider the paths of the backed up LSPs and the
available NNHOP tunnels by examination of their RROs. available NNHOP tunnels by examination of their RROs.
skipping to change at page 13, line 13 skipping to change at page 13, line 44
and protection paths signaled for segment protection then care is and protection paths signaled for segment protection then care is
required to keep these paths disjoint. If the paths are signaled required to keep these paths disjoint. If the paths are signaled
incrementally then route exclusion [EXCLUDE-ROUTE] may be used to incrementally then route exclusion [EXCLUDE-ROUTE] may be used to
ensure that the paths are disjoint. Otherwise a coordinated path ensure that the paths are disjoint. Otherwise a coordinated path
computation technique such as that offered by cooperating Path computation technique such as that offered by cooperating Path
Computation Elements [RFC4655] can provide suitable paths. Computation Elements [RFC4655] can provide suitable paths.
6. Re-Optimization of Inter-Domain TE LSPs 6. Re-Optimization of Inter-Domain TE LSPs
Re-optimization of a TE LSP is the process of moving the LSP from the Re-optimization of a TE LSP is the process of moving the LSP from the
current path to a preferable path. This involves the determination of current path to a more prefered path. This involves the determination
the preferred path and make-before-break signaling procedures of the preferred path and make-before-break signaling procedures
[RFC3209] to minimize traffic disruption. [RFC3209] to minimize traffic disruption.
Re-optimization of an inter-domain TE LSP may require a new path in Re-optimization of an inter-domain TE LSP may require a new path in
more than one domain. more than one domain.
The nature of the inter-domain LSP setup mechanism defines how The nature of the inter-domain LSP setup mechanism defines how
re-optimization can be applied. If the LSP is contiguous then the re-optimization can be applied. If the LSP is contiguous then the
signaling of the make-before-break process MUST be initiated by the signaling of the make-before-break process MUST be initiated by the
ingress node as defined in [RFC3209]. But if the re-optimization is ingress node as defined in [RFC3209]. But if the re-optimization is
limited to a change in path within one domain (that is, if there is limited to a change in path within one domain (that is, if there is
no change to the domain border nodes) and nesting or stitching are in no change to the domain border nodes) and nesting or stitching are in
use, the H-LSP or stitching segment may be independently re-optimized use, the H-LSP or stitching segment may be independently re-optimized
within the domain without impacting the end-to-end LSP. within the domain without impacting the end-to-end LSP.
In all cases, however, the ingress LSP may wish to exert control and In all cases, however, the ingress LSP may wish to exert control and
coordination over the re-optimization process. coordination over the re-optimization process. For example, a transit
domain may be aware of the potential for reoptimization, but not
bother because it is not worried by the level of service being
provided across the domain. But the cummulative effect on the
end-to-end LSP may cause the head-end to worry and trigger an
end-to-end reoptimization request (of course, the transit domain may
choose to ignore the request).
[LOOSE-REOPT] describes mechanisms that allow: Another benefit to end-to-end reoptimization over per-domain
reoptimization for non-contiguous inter-domain LSPs is that
per-domain re-optimization is restricted to preserve the domain entry
and exit points (since to do otherwise would break the LSP!). But
end-to-end reoptimization is more flexible and can select new domain
border LSRs.
There may be different cost benefit analysis considerations to choose
between end-to-end reoptimization and per-domain reoptimization. The
greater the number of hops involved in the reoptimization, the higher
the risk of traffic disruption. The shorter the segment reoptimized,
the lower the chance of making a substantial improvement on the
qulaity of the end-to-end LSP. Administrative policies should be
applied in this area with care.
[RFC4736] describes mechanisms that allow:
- The ingress node to request each node with a loose next hop to - The ingress node to request each node with a loose next hop to
re-evaluate the current path in order search for a more optimal re-evaluate the current path in order to search for a more optimal
path. path.
- A node with a loose next hop to inform the ingress node that a - A node with a loose next hop to inform the ingress node that a
better path exists. better path exists.
These mechanisms SHOULD be used for re-optimization of a contiguous These mechanisms SHOULD be used for re-optimization of a contiguous
inter-domain TE LSP. inter-domain TE LSP.
7. Security Considerations Note that end-to-end reoptimization may involve a non-local
modification and that might select new entry / exit points. In this
case, we can observe that local reoptimization is more easily and
flexibly achieved using nesting or stitching. Further, the "locality
principle" (i.e., the idea of keeping information only where it is
needed) is best achieved using stitching or nesting. That said, a
contiguous LSP can easily be modified to take advantage of local
reoptimizations (as defined in [RFC4736]) even if this would require
the dissemination of information and the invocation of signaling
outside the local domain.
7. Backward Compatibility
The procedures in this document are backward compatible with esiting
deployments.
- Ingress LSRs are not required to support the extensions in this
document to provision intra-domain LSPs. The default behavior by
transit LSRs that receive a Path message that does not have the
"Contiguous LSP" bit set in the Attributes Flags TLV of the
LSP_Attribtes object or does not even have the object present is
to allow all modes of inter-domain TE LSP, so back-level ingress
LSRs are able to initiate inte-domain LSPs.
- Transit, non-border LSRs are not required to perform any special
processing and will pass the LSP_Attributes object onwards
unmodified according to the rules of [RFC2205]. Thus back-level
transit LSRs are fully supported.
- Domain border LSRs are likely to be upgraded before inter-domain
TE LSPs are allowed. This is because of the need to establish
policy, administrative, and security conrols before permitting
inter-domain LSPs to be signaled across a domain border. Thus
legacy domain border LSRs do not need to be considered.
The RRO additions in this document are fully backward compatible.
8. Security Considerations
A separate document is being prepared to examine the security aspects A separate document is being prepared to examine the security aspects
of RSVP-TE signaling with special reference to multi-domain of RSVP-TE signaling with special reference to multi-domain
scenarios. [INTER-DOMAIN-FRAMEWORK] provides an overview of the scenarios [MPLS-GMPLS-SEC]. [RFC4726] provides an overview of the
requirements for security in an MPLS-TE or GMPLS multi-domain requirements for security in an MPLS-TE or GMPLS multi-domain
environment. environment.
When signaling an inter-domain RSVP-TE LSP, an operator may make use Before electing to utilise inter-domain signaling for MPLS-TE, the
administrators of neighboring domains MUST satisfy themselves of the
existence of a suiable trust relationship between the domains. In the
absence of such a relationship, the administrators SHOULD decide not
to deploy inter-domain signaling, and SHOULD disable RSVP-TE on any
inter-domain interfaces.
When signaling an inter-domain RSVP-TE LSP, an operator MAY make use
of the security features already defined for RSVP-TE [RFC3209]. This of the security features already defined for RSVP-TE [RFC3209]. This
may require some coordination between the domains to share the keys may require some coordination between the domains to share the keys
(see [RFC2747] and [RFC3097]), and care is required to ensure that (see [RFC2747] and [RFC3097]), and care is required to ensure that
the keys are changed sufficiently frequently. Note that this may the keys are changed sufficiently frequently. Note that this may
involve additional synchronization, should the domain border nodes involve additional synchronization, should the domain border nodes
be protected with FRR, since the MP and PLR should also share the be protected with FRR, since the MP and PLR should also share the
key. key.
For an inter-domain TE LSP, especially when it traverses different For an inter-domain TE LSP, especially when it traverses different
administrative or trust domains, the following mechanisms SHOULD be administrative or trust domains, the following mechanisms SHOULD be
skipping to change at page 14, line 30 skipping to change at page 16, line 26
contract. contract.
2) A way for the operator to rate-limit LSP setup requests 2) A way for the operator to rate-limit LSP setup requests
or error notifications from a particular domain. or error notifications from a particular domain.
3) A mechanism to allow policy-based outbound RSVP message 3) A mechanism to allow policy-based outbound RSVP message
processing at the domain border node, which may involve processing at the domain border node, which may involve
filtering or modification of certain addresses in RSVP filtering or modification of certain addresses in RSVP
objects and messages. objects and messages.
Some examples of the policies described above are:- Additionally, an operator may wish to reduce the signaling
interactions between domains to improve security. For example, the
operator might not trust the neighboring domain to supply correct or
trustable restart information [RSVP-RETSART] and might ensure that
the availablity of restart function is not configured in the Hello
message exchange across the domain border. Thus, suitable
configuration MUST be provided in an RSVP-TE implementation to
enable the operator to control optional protocol features that may be
considered a security risk.
Some examples of the policies described above are as follows:
A) An operator may choose to implement some kind of ERO filtering A) An operator may choose to implement some kind of ERO filtering
policy on the domain border node to disallow or ignore hops policy on the domain border node to disallow or ignore hops
within the domain from being identified in the ERO of an within the domain from being identified in the ERO of an
incoming Path message. incoming Path message. That is, the policy is that a node
outside the domain cannot specify the path of the LSP inside the
domain. The domain border LSR can make implement this policy in
one of two ways:
- It can reject the Path message.
- It can ignore the hops in the ERO that lie within the domain.
B) In order to preserve confidentiality of network topology, an B) In order to preserve confidentiality of network topology, an
operator may choose to disallow recording of hops within the operator may choose to disallow recording of hops within the
domain in the RRO or may choose to filter out certain recorded domain in the RRO or may choose to filter out certain recorded
RRO addresses at the domain border node. RRO addresses at the domain border node.
C) An operator may require the border node to modify the addresses C) An operator may require the border node to modify the addresses
of certain messages like PathErr or Notify originated from hops of certain messages like PathErr or Notify originated from hops
within the domain. within the domain.
Note that the detailed specification of such policies and their Note that the detailed specification of such policies and their
implementation are outside the scope of this document. implementation are outside the scope of this document.
8. IANA Considerations OAM mechanisms including [BFD-MPLS] and [LSP-PING] are commonly used
to verify he connectivity of end-to-end LSPs and to trace their
paths. Where the LSPs are inter-domain LSPs, such OAM techniques MAY
require to be intercepted or modified at domain borders, or to be
passed transparently across domains. Further discussion of this topic
can be found in [INTERAS-PING] and [MPLS-GMPLS-SEC].
9. IANA Considerations
IANA is requested to make the codepoint allocations described in the IANA is requested to make the codepoint allocations described in the
following sections. following sections.
8.1. Attribute Flags for LSP_Attributes Object 9.1. Attribute Flags for LSP_Attributes Object
A new bit is to be allocated from the "Attributes Flags" sub-registry A new bit is to be allocated from the "Attributes Flags" sub-registry
of the "RSVP TE Parameters" registry. of the "RSVP TE Parameters" registry.
Path Resv RRO Path Resv RRO
Bit Name message message sub-object Bit Name message message sub-object
---- ------------------------------- -------- -------- ---------- ---- ------------------------------- -------- -------- ----------
XX Contiguous LSP Yes No Yes XX Contiguous LSP Yes No Yes
The value XX is to be defined by IANA. A value of 4 is suggested. The value XX is to be defined by IANA. A value of 4 is suggested.
8.2. New Error Codes 9.2. New Error Codes
New RSVP error codes/values are required to be allocated from the New RSVP error codes/values are required to be allocated from the
"Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry
of the "RSVP Parameters" registry. of the "RSVP Parameters" registry.
For the existing error code "Policy control failure" (value 2), two For the existing error code "Policy control failure" (value 2), two
new error values are suggested as follows. The values are suggested new error values are suggested as follows. The values are suggested
and are for IANA determination. and are for IANA determination.
103 = Inter-domain policy failure 103 = Inter-domain policy failure
104 = Inter-domain explicit route rejected 104 = Inter-domain explicit route rejected
For the existing error code "Routing Problem" (value 24), two new For the existing error code "Routing Problem" (value 24), two new
error values are suggested as follows. The values are suggested and error values are suggested as follows. The values are suggested and
are for IANA determination. are for IANA determination.
21 = Contiguous LSP type not supported 21 = Contiguous LSP type not supported
22 = ERO conflicts with inter-domain signaling method 22 = ERO conflicts with inter-domain signaling method
9. Acknowledgements 10. Acknowledgements
The authors would like to acknowledge the input and helpful comments The authors would like to acknowledge the input and helpful comments
from Kireeti Kompella on various aspects discussed in the document. from Kireeti Kompella on various aspects discussed in the document.
Deborah Brungard and Dimitri Papdimitriou provided thorough reviews.
10. References 11. References
10.1. Normative References 11.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.
[RFC3209] Awduche, D., et al, "Extensions to RSVP for LSP Tunnels", [RFC3209] Awduche, D., et al, "Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001. RFC 3209, December 2001.
[RFC3473] Berger, L., et al, "Generalized Multi-Protocol Label [RFC3473] Berger, L., et al, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol - Switching (GMPLS) Signaling Resource ReserVation Protocol -
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003. January 2003.
[RFC4206] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized [RFC4206] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized
MPLS TE", RFC 4206, October 2005. MPLS TE", RFC 4206, October 2005.
[RFC4420] Farrel, A., et al, "Encoding of Attributes for [RFC4420] Farrel, A., et al, "Encoding of Attributes for
Multiprotocol Label Switching (MPLS) Label Switched Path Multiprotocol Label Switching (MPLS) Label Switched Path
(LSP) Establishment Using RSVP-TE", RFC 4420, February (LSP) Establishment Using RSVP-TE", RFC 4420, February
2006. 2006.
[LOOSE-REOPT] Vasseur, JP., et al, "Reoptimization of Multiprotocol
Label Switching (MPLS) Traffic Engineering (TE) loosely
routed Label Switch Path (LSP)",
draft-ietf-ccamp-loose-path-reopt, (work in progress).
[LSP-STITCHING] Ayyangar, A., Kompella, K., and Vasseur, JP., "Label [LSP-STITCHING] Ayyangar, A., Kompella, K., and Vasseur, JP., "Label
Switched Path Stitching with Generalized MPLS Traffic Switched Path Stitching with Generalized MPLS Traffic
Engineering", draft-ietf-ccamp-lsp-stitching, (work in Engineering", draft-ietf-ccamp-lsp-stitching, (work in
progress). progress).
10.2. Informative References 11.2. Informative References
[RFC2747] Baker, F., Lindell, B., and Talwar, B., "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and Talwar, B., "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC3097] Braden, R., and Zhang, L., "RSVP Cryptographic [RFC3097] Braden, R., and Zhang, L., "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC 3097,
April 2001. April 2001.
[RFC4090] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE [RFC4090] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", RFC 4090, May 2005. for LSP Tunnels", RFC 4090, May 2005.
skipping to change at page 17, line 5 skipping to change at page 19, line 15
[RFC4208] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the [RFC4208] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the
Overlay Model", RFC 4208, October 2005. Overlay Model", RFC 4208, October 2005.
[RFC4216] Zhang, R., et al, "MPLS Inter-Autonomous System (AS) [RFC4216] Zhang, R., et al, "MPLS Inter-Autonomous System (AS)
Traffic Engineering (TE) Requirements", RFC 4216, November Traffic Engineering (TE) Requirements", RFC 4216, November
2005. 2005.
[RFC4655] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation [RFC4655] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, Arthi, "A
Framework for Inter-Domain Multiprotocol Label Switching
Traffic Engineering", RFC 4726, November 2006.
[RFC4736] Vasseur, JP., et al, "Reoptimization of Multiprotocol Label
Switching (MPLS) Traffic Engineering (TE) Loosely Routed
Label Switched Path (LSP)", RFC 4736, November 2006.
[BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs", [BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs",
draft-ietf-bfd-mpls, (work in progress). draft-ietf-bfd-mpls, (work in progress).
[CRANKBACK] Farrel, A., et al, "Crankback Signaling Extensions for [CRANKBACK] Farrel, A., et al, "Crankback Signaling Extensions for
MPLS and GMPLS RSVP-TE", draft-ietf-ccamp-crankback, (work MPLS and GMPLS RSVP-TE", draft-ietf-ccamp-crankback, (work
in progress). in progress).
[EXCLUDE-ROUTE] Lee, CY., Farrel, A., and De Cnodder, S., "Exclude [EXCLUDE-ROUTE] Lee, CY., Farrel, A., and De Cnodder, S., "Exclude
Routes - Extension to RSVP-TE", Routes - Extension to RSVP-TE",
draft-ietf-ccamp-rsvp-te-exclude-route, (work in progress). draft-ietf-ccamp-rsvp-te-exclude-route, (work in progress).
[INTER-DOMAIN-FRAMEWORK] Farrel, A., et al, "A Framework for [INTERAS-PING] Nadeau, T., and Swallow, G., "Detecting MPLS Data
Inter-Domain MPLS Traffic Engineering", Plane Failures in Inter-AS and inter-provider Scenarios",
draft-ietf-ccamp-inter-domain-framework, (work in draft-nadeau-mpls-interas-lspping, work in progress.
progress).
[INTER-DOMAIN-PD-PATH-COMP] Vasseur, JP., Ayyangar, A., and [INTER-DOMAIN-PD-PATH-COMP] Vasseur, JP., Ayyangar, A., and
Zhang, R., "A Per-domain path computation method for Zhang, R., "A Per-domain path computation method for
computing Inter-domain Traffic Engineering (TE) Label computing Inter-domain Traffic Engineering (TE) Label
Switched Paths (LSPs)", Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-
draft-ietf-ccamp-inter-domain-pd-path-comp, (work in path-comp, (work in progress).
progress).
[MPLS-GMPLS-SEC] Luyuan Fang, et al., "Security Framework for MPLS
and GMPLS Networks", draft-fang-mpls-gmpls-security-
framework, work in progress.
[NODE-ID] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of an [NODE-ID] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of an
RRO node-id subobject", draft-ietf-mpls-nodeid-subobject, RRO node-id subobject", draft-ietf-mpls-nodeid-subobject,
(work in progress). (work in progress).
[RSVP-RESTART] Satyanarayana, A., and Rahman, R., "Extensions to
GMPLS RSVP Graceful Restart", draft-ietf-ccamp-rsvp-
restart-ext, work in progress.
[SEGMENT-PROTECTION] Berger, L., et al, "GMPLS Based Segment [SEGMENT-PROTECTION] Berger, L., et al, "GMPLS Based Segment
Recovery", draft-ietf-ccamp-gmpls-segment-recovery, (work Recovery", draft-ietf-ccamp-gmpls-segment-recovery, (work
in progress). in progress).
11. Authors' Addresses 12. Authors' Addresses
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
E-mail: adrian@olddog.co.uk E-mail: adrian@olddog.co.uk
Arthi Ayyangar Arthi Ayyangar
Nuova Systems Nuova Systems
2600 San Tomas Expressway 2600 San Tomas Expressway
Santa Clara, CA 95051 Santa Clara, CA 95051
 End of changes. 51 change blocks. 
78 lines changed or deleted 203 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/