draft-ietf-ccamp-inter-domain-rsvp-te-06.txt   draft-ietf-ccamp-inter-domain-rsvp-te-07.txt 
INTERNET-DRAFT A. Farrel (Editor) INTERNET-DRAFT A. Farrel (Editor)
Network Working Group Old Dog Consulting Network Working Group Old Dog Consulting
Intended Status: Standards Track Intended Status: Standards Track
Updates: RFC 3209, RFC 3473 A. Ayyangar Updates: RFC 3209, RFC 3473 A. Ayyangar
Expires: October 2007 Nuova Systems Expires: March 2008 Juniper Networks
JP. Vasseur JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
September 2007
Inter domain Multiprotocol Label Switching (MPLS) and Inter domain Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions
draft-ietf-ccamp-inter-domain-rsvp-te-06.txt draft-ietf-ccamp-inter-domain-rsvp-te-07.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 11 skipping to change at page 2, line 11
collection of network elements within a common realm of address space collection of network elements within a common realm of address space
or path computation responsibility. Examples of such domains include or path computation responsibility. Examples of such domains include
Autonomous Systems, IGP routing areas, and GMPLS overlay networks. Autonomous Systems, IGP routing areas, and GMPLS overlay networks.
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 . . . . . . . . . . . . . . . . . . . . 5
3. Procedures on the Domain Border Node . . . . . . . . . . . . . 5 3. Procedures on the Domain Border Node . . . . . . . . . . . . . 6
3.1 Rules on ERO Processing . . . . . . . . . . . . . . . . . 6 3.1 Rules on ERO Processing . . . . . . . . . . . . . . . . . 7
3.2 LSP Setup Failure and Crankback . . . . . . . . . . . . . 8 3.2 LSP Setup Failure and Crankback . . . . . . . . . . . . . 9
3.3 RRO Processing Across Domains . . . . . . . . . . . . . . 9 3.3 RRO Processing Across Domains . . . . . . . . . . . . . . 10
3.4 Notify Message Processing . . . . . . . . . . . . . . . . 9 3.4 Notify Message Processing . . . . . . . . . . . . . . . . 10
4. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . . 10 4. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . . 11
4.1 Control of Downstream Choice of Signaling Method . . . . . 10 4.1 Control of Downstream Choice of Signaling Method . . . . . 11
5. Protection and Recovery of Inter-Domain TE LSPs . . . . . . . 11 5. Protection and Recovery of Inter-Domain TE LSPs . . . . . . . 12
5.1 Fast Recovery Support Using MPLS-TE Fast Reroute . . . . . 11 5.1 Fast Recovery Support Using MPLS-TE Fast Reroute . . . . . 12
5.1.1 Failure Within a Domain (Link or Node Failure) . . . . 12 5.1.1 Failure Within a Domain (Link or Node Failure) . . . . 13
5.1.2 Failure of Link at Domain Borders . . . . . . . . . . 12 5.1.2 Failure of Link at Domain Borders . . . . . . . . . . 13
5.1.3 Failure of a Border Node . . . . . . . . . . . . . . . 12 5.1.3 Failure of a Border Node . . . . . . . . . . . . . . . 13
5.2 Protection and Recovery of GMPLS LSPs . . . . . . . . . . 13 5.2 Protection and Recovery of GMPLS LSPs . . . . . . . . . . 14
6. Re-Optimization of Inter-Domain TE LSPs . . . . . . . . . . . 13 6. Re-Optimization of Inter-Domain TE LSPs . . . . . . . . . . . 14
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1 Attribute Flags for LSP_Attributes Object . . . . . . . . 17 9.1 Attribute Flags for LSP_Attributes Object . . . . . . . . 18
9.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 17 9.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1 Normative References . . . . . . . . . . . . . . . . . . 18 11.1 Normative References . . . . . . . . . . . . . . . . . . 19
11.2 Informative References . . . . . . . . . . . . . . . . . 18 11.2 Informative References . . . . . . . . . . . . . . . . . 20
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
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 [RFC4726]. MPLS-TE is provided in [RFC4726].
This document presents procedures and extensions to Resource This document presents procedures and extensions to Resource
skipping to change at page 3, line 35 skipping to change at page 3, line 35
1.1. Conventions Used In This Document 1.1. 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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
AS: Autonomous System. AS: Autonomous System.
ASBR: routers used to connect together ASes of a different or the ASBR: Autonmous System Border Router. A router used to connect
same Service Provider via one or more Inter-AS links. together ASes of a different or the same Service Provider via one or
more Inter-AS links.
Bypass Tunnel: an LSP that is used to protect a set of LSPs passing Bypass Tunnel: An LSP that is used to protect a set of LSPs passing
over a common facility. over a common facility.
ERO: Explicit Route Object. ERO: Explicit Route Object.
FA: Forwarding Adjacency. FA: Forwarding Adjacency.
LSR: Label Switching Router. LSR: Label Switching Router.
MP: Merge Point. The node where bypass tunnels meet the protected MP: Merge Point. The node where bypass tunnels meet the protected
LSP. LSP.
skipping to change at page 4, line 24 skipping to change at page 4, line 27
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 [RFC4726] and set out in the one of three options as described in [RFC4726] and set out in the
next section: 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 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. options may be used in the course of an end-to-end inter-domain LSP.
That is, the options should be considered as per-domain transit
options so that an end-to-end inter-domain LSP that starts in domain
A, transits domains B, C and D, and ends in domain E might use an LSP
that runs contiguously from the ingress in domain A, through domain B
to the border with domain C. Domain C might be transited using the
nested LSP option to reach the border with domain D, and domain D
might be transited using the stitched LSP option to reach the border
with domain E, from where a normal LSP runs to the egress.
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 which of the three signaling mechanisms is used and to select
for any one end-to-end inter-domain TE LSP. which of the three signaling mechanisms is used.
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. An implementation of a transit LSR is unaware of the options
for inter-domain TE LSPs since it sees only TE LSPs. An
implementation of a domain border LSR has to decide what mechanisms
of inter-domain TE LSP support to include, but must in any case
support contiguous inter-domain TE LSPs since this is the default
mode of operation for RSVP-TE. Failure to support either or both of
nested LSPs or stitched LSPs, restricts the operators options, but
does not prevent the establishment of inter-domain TE LSPs.
2.1. Signaling Options 2.1. Signaling Options
There are three ways in which an RSVP-TE LSP could be signaled across There are three ways in which an RSVP-TE LSP could be signaled across
multiple domains: multiple domains:
Contiguous Contiguous
A contiguous TE LSP is a single end-to-end TE LSP that is set up A contiguous TE LSP is a single TE LSP that is set up across
across multiple domains using RSVP-TE signaling procedures multiple domains using RSVP-TE signaling procedures described in
described in [RFC3209] and [RFC3473]. No additional TE LSPs are [RFC3209] and [RFC3473]. No additional TE LSPs are required to
required to create a contiguous TE LSP and the same RSVP-TE create a contiguous TE LSP and the same RSVP-TE information for
information for the TE LSP is maintained along the entire LSP the TE LSP is maintained along the entire LSP path. In particular,
path. In particular, the TE LSP has the same RSVP-TE session and the TE LSP has the same RSVP-TE session and LSP ID at every LSR
LSP ID at every LSR along its path. along its path.
Nesting Nesting
One or more TE LSPs may be nested within another TE LSP as One or more TE LSPs may be nested within another TE LSP as
described in [RFC4206]. This technique can be used to nest one described in [RFC4206]. This technique can be used to nest one
or more inter-domain TE LSPs into an intra-domain hierarchical LSP or more inter-domain TE LSPs into an intra-domain hierarchical LSP
(H-LSP). The label stacking construct is used to achieve nesting (H-LSP). The label stacking construct is used to achieve nesting
in packet networks. In the rest of this document, the term H-LSP in packet networks. In the rest of this document, the term H-LSP
is used to refer to an LSP that allows other LSPs to be nested is used to refer to an LSP that allows other LSPs to be nested
within it. An H-LSP may be advertised as a TE link within the same within it. An H-LSP may be advertised as a TE link within the same
instance of the routing protocol as was used to advertise the TE instance of the routing protocol as was used to advertise the TE
skipping to change at page 6, line 16 skipping to change at page 6, line 38
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 with an error code as described in Section 4.1. message with an error code as described in Section 4.1.
Thus, for example, an ingress may request a contiguous LSP
because it wishes to exert maximal control over the LSP's path
and to control when re-optimization takes place. But the
operator of a transit domain may decide (for example) that only
LSP stitching is allowed for exactly the reason that it gives
the operator the chance to reoptimize their own domain under
their own control. In this case, the policy applied at the entry
to the transit domain will result in the return of a PathErr
message and the ingress has a choice to:
- find another path avoiding the transit domain
- relax his requirements
- fail to provide the service.
3. Carry out ERO procedures as described in Section 3 in addition 3. Carry out ERO procedures as described in Section 3 in 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 specified 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. A
domain border node MAY opt so silently discard the Path message
in this case as described in Section 8.
In the event of the receipt of a PathErr message reporting In the event of the receipt of a PathErr message reporting
signaling failure from within the domain or reported from a signaling failure from within the domain or reported from a
downstream domain, the domain border node MAY apply crankback downstream domain, the domain border node MAY apply crankback
procedures as described in Section 3.2. If crankback is not procedures as described in Section 3.2. If crankback is not
applied, or is exhausted, the border node MUST continue with applied, or is exhausted, the border node MUST continue with
PathErr processing as described in [RFC3209] and [RFC3473]. PathErr processing as described in [RFC3209] and [RFC3473].
In the event of successful processing of a Path or Resv message, In the event of successful processing of a Path or Resv message,
the domain border node MUST carry out RRO procedures as described the domain border node MUST carry out RRO procedures as described
skipping to change at page 7, line 18 skipping to change at page 8, line 6
- policy at the nodes creating/modifying the ERO. - policy at the nodes creating/modifying the ERO.
In general, H-LSPs and LSP segments are used between domain border In general, H-LSPs and LSP segments are used between domain border
nodes, but there is no restriction on the use of such LSPs to span nodes, but there is no restriction on the use of such LSPs to span
multiple hops entirely within a domain. Therefore, the discussion multiple hops entirely within a domain. Therefore, the discussion
that follows may be equally applied to any node within a domain that follows may be equally applied to any node within a domain
although the term 'domain border node' continues to be used for although the term 'domain border node' continues to be used for
clarity. clarity.
When a Path message reaches the domain border node, the following When a Path message reaches the domain border node, the following
rules SHOULD be used for ERO processing and for further signaling. rules apply for ERO processing and for further signaling.
1. If there are any policies related to ERO processing for the 1. If there are any policies related to ERO processing for the
LSP, they SHOULD be applied and corresponding actions taken. For LSP, they MUST be applied and corresponding actions taken. For
example, there might be a policy to reject EROs that identify example, there might be a policy to reject EROs that identify
nodes within the domain. In case of inter-domain LSP setup nodes within the domain. In case of inter-domain LSP setup
failures due to policy failures related to ERO processing, the failures due to policy failures related to ERO processing, the
node SHOULD issue a PathErr with error code "Policy control node SHOULD issue a PathErr with error code "Policy control
failure"/"Inter-domain explicit route rejected". failure"/"Inter-domain explicit route rejected", but MAY be
configured to silently discard the Path message or to return a
different error code for security reasons.
2. Section 8.2 of [RFC4206] describes how a node at the edge of a 2. Section 8.2 of [RFC4206] describes how a node at the edge of a
region processes the ERO in the incoming Path message and uses region processes the ERO in the incoming Path message and uses
this ERO, to either find an existing H-LSP or signal a new H-LSP this ERO, to either find an existing H-LSP or signal a new H-LSP
using the ERO hops. This process includes adjusting the ERO using the ERO hops. This process includes adjusting the ERO
before sending the Path message to the next hop. These before sending the Path message to the next hop. These
procedures SHOULD be followed for nesting or stitching of procedures MUST be followed for nesting or stitching of
inter-domain TE LSPs. inter-domain TE LSPs.
3. If an ERO subobject identifies a TE link formed by the 3. If an ERO subobject identifies a TE link formed by the
advertisement of an H-LSP or LSP segment (whether numbered or advertisement of an H-LSP or LSP segment (whether numbered or
unnumbered), contiguous signaling MUST NOT be used. The node MUST unnumbered), contiguous signaling MUST NOT be used. The node MUST
either use nesting or stitching according to the capabilities of either use nesting or stitching according to the capabilities of
the LSP that forms the TE link, the parameters signaled in the the LSP that forms the TE link, the parameters signaled in the
Path message, and local policy. If there is a conflict between the Path message, and local policy. If there is a conflict between the
capabilities of the LSP that forms the TE link indicated in the capabilities of the LSP that forms the TE link indicated in the
ERO and the parameters on the Path message, the domain border node ERO and the parameters on the Path message, the domain border node
SHOULD send a PathErr with error code "Routing Problem"/"ERO SHOULD send a PathErr with error code "Routing Problem"/"ERO
conflicts with inter-domain signaling method". conflicts with inter-domain signaling method", but MAY be
configured to silently discard the Path message or to return a
different error code for security reasons.
4. An ERO in a Path message received by a domain border node may 4. An ERO in a Path message received by a domain border node may
have a loose hop as the next hop. This may be an IP address or have a loose hop as the next hop. This may be an IP address or
an AS number. In such cases, the ERO MUST be expanded to an AS number. In such cases, the ERO MUST be expanded to
determine the path to the next hop using some form of path determine the path to the next hop using some form of path
computation that may, itself, generate loose hops. computation that may, itself, generate loose hops.
5. In the absence of any ERO subobjects beyond the local domain 5. In the absence of any ERO subobjects beyond the local domain
border node, the LSP egress (the destination encoded in the RSVP border node, the LSP egress (the destination encoded in the RSVP
Session object) MUST be considered as the next loose hop and Session object) MUST be considered as the next loose hop and
rule 4 applied. rule 4 applied.
6. In the event of any other failures processing the ERO, a PathErr 6. In the event of any other failures processing the ERO, a PathErr
message SHOULD be sent as described in [RFC3209] or [RFC3473]. message SHOULD be sent as described in [RFC3209] or [RFC3473], but
a domain border router MAY be configured to silently discard the
Path message or to return a different error code for security
reasons.
3.2. LSP Setup Failure and Crankback 3.2. LSP Setup Failure and Crankback
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 reports 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 except to attempt rerouting as described below.
- 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 [RFC4920]. 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
subsequent attempt is successful, the domain border router MUST subsequent attempt is successful, the domain border router MUST
discard the held PathErr message, but if all subsequent attempts are discard the held PathErr message, but if all subsequent attempts are
unsuccessful, the domain border router MUST send the PathErr upstream unsuccessful, the domain border router MUST send the PathErr upstream
toward the ingress node. In this latter case, the domain border toward the ingress node. In this latter case, the domain border
router MAY change the information in the PathErr message to provide router MAY change the information in the PathErr message to provide
further crankback details and information aggregation as described further crankback details and information aggregation as described
in [CRANKBACK]. in [RFC4920].
Crankback rerouting MAY also be used to handle the failure of LSPs Crankback rerouting MAY also be used to handle the failure of LSPs
after they have been established [CRANKBACK]. after they have been established [RFC4920].
3.3. RRO Processing Across Domains 3.3. RRO Processing Across Domains
[RFC3209] defines the RRO as an optional used for loop detection and [RFC3209] defines the RRO as an optional used for loop detection and
for providing information about the hops traversed by LSPs. for providing information about the hops traversed by LSPs.
As described for overlay networks in [RFC4208], a domain border node As described for overlay networks in [RFC4208], a domain border node
MAY filter or modify the information provided in an RRO for MAY filter or modify the information provided in an RRO for
confidentiality reasons according to local policy. For example, a confidentiality reasons according to local policy. For example, a
series of identifiers of hops within a domain MAY be replaced with series of identifiers of hops within a domain MAY be replaced with
skipping to change at page 11, line 24 skipping to change at page 12, line 24
forward the object unmodified. 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 [RFC4873]. This means that these
that these LSPs will also be subjected to ERO processing, policies, LSPs will also be subjected to ERO processing, policies, path
path computation, etc. computation, etc.
Note also that the paths for these backup LSPs needs to be either Note also that the paths for these backup LSPs needs to be either
pre-configured, computed and signaled with the protected LSP, or pre-configured, computed and signaled with the protected LSP, or
computed on-demand at the PLR. Just as with any inter-domain TE LSP, computed on-demand at the PLR. Just as with any inter-domain TE LSP,
the ERO may comprise of strict or loose hops, and will depend on the the ERO may comprise of strict or loose hops, and will depend on the
TE visibility of the computation point into the subsequent domain. TE visibility of the computation point into the subsequent domain.
If loose hops are required created in the path of the backup LSP, ERO If loose hops are required created in the path of the backup LSP, ERO
expansion will be required at some point along the path: probably at expansion will be required at some point along the path: probably at
a domain border node. In order that the backup path remains disjoint a domain border node. In order that the backup path remains disjoint
skipping to change at page 13, line 24 skipping to change at page 14, line 24
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.
Note that where the PLR is not immediately upstream of the failed Note that where the PLR is not immediately upstream of the failed
node, error propagation time may be delayed unless some mechanism node, error propagation time may be delayed unless some mechanism
such as [BFD-MPLS] is implemented, or unless direct reporting, such such as [BFD-MPLS] is implemented, or unless direct reporting, such
as through the GMPLS Notify message [RFC3473] is employed. as through the GMPLS Notify message [RFC3473] is employed.
5.2. Protection and Recovery of GMPLS LSPs 5.2. Protection and Recovery of GMPLS LSPs
[SEGMENT-PROTECTION] describes GMPLS based segment recovery. This [RFC4873] describes GMPLS based segment recovery. This allows
allows protection against a span failure, a node failure, or failure protection against a span failure, a node failure, or failure over
over any particular portion of a network used by an LSP. any particular portion of a network used by an LSP.
The domain border failure cases described in Section 5.1 may also The domain border failure cases described in Section 5.1 may also
occur in GMPLS networks (including packet networks) and can be occur in GMPLS networks (including packet networks) and can be
protected against using segment protection without any additional protected against using segment protection without any additional
protocol extensions. protocol extensions.
Note that if loose hops are used in the construction of the working Note that if loose hops are used in the construction of the working
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 [RFC4874] may be used to ensure incrementally then route exclusion [RFC4874] may be used to ensure
skipping to change at page 14, line 10 skipping to change at page 15, line 10
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 LSR may wish to exert control and
coordination over the re-optimization process. For example, a transit coordination over the re-optimization process. For example, a transit
domain may be aware of the potential for reoptimization, but not domain may be aware of the potential for reoptimization, but not
bother because it is not worried by the level of service being bother because it is not worried by the level of service being
provided across the domain. But the cummulative effect on the 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 LSP may cause the head-end to worry and trigger an
end-to-end reoptimization request (of course, the transit domain may end-to-end reoptimization request (of course, the transit domain may
choose to ignore the request). choose to ignore the request).
Another benefit to end-to-end reoptimization over per-domain Another benefit to end-to-end reoptimization over per-domain
reoptimization for non-contiguous inter-domain LSPs is that reoptimization for non-contiguous inter-domain LSPs is that
skipping to change at page 15, line 9 skipping to change at page 16, line 9
flexibly achieved using nesting or stitching. Further, the "locality flexibly achieved using nesting or stitching. Further, the "locality
principle" (i.e., the idea of keeping information only where it is principle" (i.e., the idea of keeping information only where it is
needed) is best achieved using stitching or nesting. That said, a needed) is best achieved using stitching or nesting. That said, a
contiguous LSP can easily be modified to take advantage of local contiguous LSP can easily be modified to take advantage of local
reoptimizations (as defined in [RFC4736]) even if this would require reoptimizations (as defined in [RFC4736]) even if this would require
the dissemination of information and the invocation of signaling the dissemination of information and the invocation of signaling
outside the local domain. outside the local domain.
7. Backward Compatibility 7. Backward Compatibility
The procedures in this document are backward compatible with esiting The procedures in this document are backward compatible with existing
deployments. deployments.
- Ingress LSRs are not required to support the extensions in this - Ingress LSRs are not required to support the extensions in this
document to provision intra-domain LSPs. The default behavior by document to provision intra-domain LSPs. The default behavior by
transit LSRs that receive a Path message that does not have the transit LSRs that receive a Path message that does not have the
"Contiguous LSP" bit set in the Attributes Flags TLV of the "Contiguous LSP" bit set in the Attributes Flags TLV of the
LSP_Attribtes object or does not even have the object present is 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 to allow all modes of inter-domain TE LSP, so back-level ingress
LSRs are able to initiate inte-domain LSPs. LSRs are able to initiate inter-domain LSPs.
- Transit, non-border LSRs are not required to perform any special - Transit, non-border LSRs are not required to perform any special
processing and will pass the LSP_Attributes object onwards processing and will pass the LSP_Attributes object onwards
unmodified according to the rules of [RFC2205]. Thus back-level unmodified according to the rules of [RFC2205]. Thus back-level
transit LSRs are fully supported. transit LSRs are fully supported.
- Domain border LSRs are likely to be upgraded before inter-domain - Domain border LSRs will need to be upgraded before inter-domain
TE LSPs are allowed. This is because of the need to establish TE LSPs are allowed. This is because of the need to establish
policy, administrative, and security conrols before permitting policy, administrative, and security controls before permitting
inter-domain LSPs to be signaled across a domain border. Thus inter-domain LSPs to be signaled across a domain border. Thus
legacy domain border LSRs do not need to be considered. legacy domain border LSRs do not need to be considered.
The RRO additions in this document are fully backward compatible. The RRO additions in this document are fully backward compatible.
8. Security Considerations 8. Security Considerations
RSVP does not currently provide for automated key management.
[RFC4107] states a requirement for mandatory automated key management
under certain situations. There is work starting in the IETF to
define improved authentication including automated key management for
RSVP. Implementations and deployments of RSVP should pay attention to
any capabilities and requirements that are outputs from this ongoing
work.
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 [MPLS-GMPLS-SEC]. [RFC4726] 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.
Before electing to utilise inter-domain signaling for MPLS-TE, the Before electing to utilise inter-domain signaling for MPLS-TE, the
administrators of neighboring domains MUST satisfy themselves of the administrators of neighboring domains MUST satisfy themselves of the
existence of a suiable trust relationship between the domains. In the existence of a suitable trust relationship between the domains. In
absence of such a relationship, the administrators SHOULD decide not the absence of such a relationship, the administrators SHOULD decide
to deploy inter-domain signaling, and SHOULD disable RSVP-TE on any not to deploy inter-domain signaling, and SHOULD disable RSVP-TE on
inter-domain interfaces. any inter-domain interfaces.
When signaling an inter-domain RSVP-TE LSP, an operator MAY make use 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.
skipping to change at page 17, line 7 skipping to change at page 18, line 18
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.
D) In the event of a path computation failure, an operator may
require the border node to silently discard the Path message
instead of returning a PathErr. This is because a Path message
could be interpretted as a network probe, and a PathErr provides
information about the network capabilities and policies.
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.
OAM mechanisms including [BFD-MPLS] and [RFC4379] are commonly used OAM mechanisms including [BFD-MPLS] and [RFC4379] are commonly used
to verify he connectivity of end-to-end LSPs and to trace their 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 paths. Where the LSPs are inter-domain LSPs, such OAM techniques MAY
require to be intercepted or modified at domain borders, or to be require to be intercepted or modified at domain borders, or to be
passed transparently across domains. Further discussion of this topic passed transparently across domains. Further discussion of this topic
can be found in [INTERAS-PING] and [MPLS-GMPLS-SEC]. can be found in [INTERAS-PING] and [MPLS-GMPLS-SEC].
skipping to change at page 18, line 11 skipping to change at page 19, line 31
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
10. 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. Deborah Brungard and Dimitri Papdimitriou provided thorough reviews.
Thanks to Sam Hartman for detailed discussions of the security
considerations.
11. References 11. References
11.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.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1, "Resource ReSerVation Protocol (RSVP) -- Version 1,
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
skipping to change at page 19, line 9 skipping to change at page 20, line 31
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.
[RFC4105] LeRoux, JL., Vasseur, JP., Boyle, J., et al, "Requirements [RFC4105] LeRoux, JL., Vasseur, JP., Boyle, J., et al, "Requirements
for Inter-Area MPLS Traffic Engineering", RFC 4105, June for Inter-Area MPLS Traffic Engineering", RFC 4105, June
2005. 2005.
[RFC4107] Bellovin, S. and Housley, R., "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[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.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
[RFC4561] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of a [RFC4561] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of a
Record Route Object (RRO) Node-Id Sub-Object", RFC 4561, Record Route Object (RRO) Node-Id Sub-Object", RFC 4561,
June 2006. June 2006.
[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 [RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, A., "A
Framework for Inter-Domain Multiprotocol Label Switching Framework for Inter-Domain Multiprotocol Label Switching
Traffic Engineering", RFC 4726, November 2006. Traffic Engineering", RFC 4726, November 2006.
[RFC4736] Vasseur, JP., et al, "Reoptimization of Multiprotocol Label [RFC4736] Vasseur, JP., et al, "Reoptimization of Multiprotocol Label
Switching (MPLS) Traffic Engineering (TE) Loosely Routed Switching (MPLS) Traffic Engineering (TE) Loosely Routed
Label Switched Path (LSP)", RFC 4736, November 2006. Label Switched Path (LSP)", RFC 4736, November 2006.
[RFC4873] Berger, L., et al, "GMPLS Based Segment Recovery",
RFC 4873, May 2007.
[RFC4874] Lee, CY., Farrel, A., and De Cnodder, S., "Exclude Routes - [RFC4874] Lee, CY., Farrel, A., and De Cnodder, S., "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007. Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4920] Farrel, A., et al, "Crankback Signaling Extensions for
MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[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
MPLS and GMPLS RSVP-TE", draft-ietf-ccamp-crankback, (work
in progress).
[INTERAS-PING] Nadeau, T., and Swallow, G., "Detecting MPLS Data [INTERAS-PING] Nadeau, T., and Swallow, G., "Detecting MPLS Data
Plane Failures in Inter-AS and inter-provider Scenarios", Plane Failures in Inter-AS and inter-provider Scenarios",
draft-nadeau-mpls-interas-lspping, work in progress. draft-nadeau-mpls-interas-lspping, work in 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)", draft-ietf-ccamp-inter-domain-pd- Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-
path-comp, (work in progress). path-comp, (work in progress).
[MPLS-GMPLS-SEC] Luyuan Fang, et al., "Security Framework for MPLS [MPLS-GMPLS-SEC] Luyuan Fang, et al., "Security Framework for MPLS
and GMPLS Networks", draft-fang-mpls-gmpls-security- and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-
framework, work in progress. security-framework, work in progress.
[RSVP-RESTART] Satyanarayana, A., and Rahman, R., "Extensions to [RSVP-RESTART] Satyanarayana, A., and Rahman, R., "Extensions to
GMPLS RSVP Graceful Restart", draft-ietf-ccamp-rsvp- GMPLS RSVP Graceful Restart", draft-ietf-ccamp-rsvp-
restart-ext, work in progress. restart-ext, work in progress.
[SEGMENT-PROTECTION] Berger, L., et al, "GMPLS Based Segment
Recovery", draft-ietf-ccamp-gmpls-segment-recovery, (work
in progress).
12. 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 Juniper Networks, Inc.
2600 San Tomas Expressway 1194 N.Mathilda Ave
Santa Clara, CA 95051 Sunnyvale, CA 94089
US USA
Email: arthi@nuovasystems.com
E-mail: arthi@juniper.net
Jean Philippe Vasseur Jean Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Intellectual Property Statement Intellectual Property Statement
 End of changes. 42 change blocks. 
83 lines changed or deleted 140 lines changed or added

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