[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-ayyangar-ccamp-inter-domain-rsvp-te)
00 01 02 03 04 05 06 07 RFC 5151
Network Working Group A. Farrel
Proposed Status: Standards Track Old Dog Consulting
Updates: RFC 3209, RFC 3473
Expires: July 2007 A. Ayyangar
Nuova Systems
JP. Vasseur
Cisco Systems, Inc.
January 2007
Inter domain MPLS and GMPLS Traffic Engineering - RSVP-TE extensions
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes procedures and protocol extensions for the
use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE)
signaling in Multiprotocol Label Switching Traffic Engineering
(MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and
non-packet networks to support the establishment and maintenance of
Label Switched Paths that cross domain boundaries.
For the purpose of this document, a domain is considered to be any
collection of network elements within a common realm of address space
or path computation responsibility. Examples of such domains include
Autonomous Systems, IGP routing areas, and GMPLS overlay networks.
Farrel, Ayyangar and Vasseur [Page 1]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions Used In This Document . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Signaling Overview . . . . . . . . . . . . . . . . . . . . . 4
2.1 Signaling Options . . . . . . . . . . . . . . . . . . . . 4
3. Procedures on the Domain Border Node . . . . . . . . . . . . . 5
3.1 Rules on ERO Processing . . . . . . . . . . . . . . . . . 6
3.2 LSP Setup Failure and Crankback . . . . . . . . . . . . . 8
3.3 RRO Processing Across Domains . . . . . . . . . . . . . . 8
3.4 Notify Message Processing . . . . . . . . . . . . . . . . 9
4. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . . 9
4.1 Control of Downstream Choice of Signaling Method . . . . . 9
5. Protection and Recovery of Inter-Domain TE LSPs . . . . . . . 10
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.2 Failure of Link at Domain Borders . . . . . . . . . . 11
5.1.3 Failure of a Border Node . . . . . . . . . . . . . . . 12
5.2 Protection and Recovery of GMPLS LSPs . . . . . . . . . . 12
6. Re-Optimization of Inter-Domain TE LSPs . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1 Attribute Flags for LSP_Attributes Object . . . . . . . . 15
8.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1 Normative References . . . . . . . . . . . . . . . . . . 15
10.2 Informative References . . . . . . . . . . . . . . . . . 16
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The requirements for inter-area and inter-AS Multiprotocol Label
Switching (MPLS) Traffic Engineering (TE) are stated in [RFC4105] and
[RFC4216] respectively. Many of these requirements also apply to
Generalized MPLS (GMPLS) networks. The framework for inter-domain
MPLS-TE is provided in [INTER-DOMAIN-FRAMEWORK].
This document presents procedures and extensions to Resource
Reservation Protocol Traffic Engineering (RSVP-TE) signaling for the
setup and maintenance of traffic engineered Label Switched Paths (TE
LSPs) that span multiple domains in MPLS-TE or GMPLS networks. The
signaling procedures described in this document are applicable to
MPLS-TE packet LSPs established using RSVP-TE ([RFC3209]) and all
LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as
described in [RFC3473].
Farrel, Ayyangar and Vasseur [Page 2]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
Three different signaling methods for inter-domain RSVP-TE signaling
are identified in [INTER-DOMAIN-FRAMEWORK]. Contiguous LSPs are
achieved using the procedures of [RFC3209] and [RFC3473] to create a
single end-to-end LSP that spans all domains. Nested LSPs are
established using the techniques described in [RFC4206] to carry the
end-to-end LSP in a separate tunnel across each domain. Stitched LSPs
are established using the procedures of [LSP-STITCHING] to construct
an end-to-end LSP from the concatenation of separate LSPs each
spanning a domain.
This document defines the RSVP-TE protocol extensions necessary to
control and select which of the three signaling mechanisms is used
for any one end-to-end inter-domain TE LSP.
For the purpose of this document, a domain is considered to be any
collection of network elements within a common realm of address space
or path computation responsibility. Examples of such domains include
Autonomous Systems, IGP areas, and GMPLS overlay networks
([RFC4208]).
1.1. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology
AS: Autonomous System.
ASBR: routers used to connect 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
over a common facility.
ERO: Explicit Route Object.
FA: Forwarding Adjacency.
LSR: Label Switching Router.
MP: Merge Point. The node where bypass tunnels meet the protected
LSP.
NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which
bypasses a single link of the protected LSP.
NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel,
which bypasses a single node of the protected LSP.
Farrel, Ayyangar and Vasseur [Page 3]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
PLR: Point of Local Repair. The ingress of a bypass tunnel.
RRO: Record Route Object.
TE link: Traffic Engineering link.
2. Signaling Overview
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
one of three options as described in the next section:
- contiguous LSPs
- nested LSPs
- stitched LSPs.
This document describes the RSVP-TE signaling extensions required to
control and select which of the three signaling mechanisms is used
for any one end-to-end inter-domain TE LSP.
The specific protocol extensions required to signal each LSP type are
described in other documents and are out of scope for this document.
Similarly, the routing extensions and path computation techniques
necessary for the establishment of inter-domain LSPs are out of
scope.
2.1. Signaling Options
There are three ways in which an RSVP-TE LSP could be signaled across
multiple domains:
Contiguous
A contiguous TE LSP is a single end-to-end TE LSP that is set up
across multiple domains using RSVP-TE signaling procedures
described in [RFC3209] and [RFC3473]. No additional TE LSPs are
required to create a contiguous TE LSP and the same RSVP-TE
information for the TE LSP is maintained along the entire LSP
path. In particular, the TE LSP has the same RSVP-TE session and
LSP ID at every LSR along its path.
Nesting
One or more TE LSPs may be nested within another TE LSP as
described in [RFC4206]. This technique can be used to nest one
or more inter-domain TE LSPs into an intra-domain hierarchical LSP
(H-LSP). The label stacking construct is used to achieve nesting
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
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
links from which it was created, in which case it is a Forwarding
Adjacency (FA) [RFC4206].
Farrel, Ayyangar and Vasseur [Page 4]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
Stitching
The concept of LSP stitching as well as the required signaling
procedures is described in [LSP-STITCHING]. This technique can be
used to stitch together shorter LSPs (LSP segments) to create a
single, longer LSP. The LSP segments of an inter-domain LSP may be
intra-domain LSPs or inter-domain LSPs.
The process of stitching in the data plane results in a single,
end-to-end contiguous LSP. But in the control plane each segment is
signaled as a separate LSP (with distinct RSVP sessions) and the
end-to-end LSP is signaled as yet another LSP with its own RSVP
session. Thus the control plane operation for LSP stitching is very
similar to that for nesting.
An end-to-end inter-domain TE LSP may be achieved using one or more
of the signaling techniques described. The choice is a matter of
policy for the node requesting LSP setup (the ingress) and policy for
each successive domain border node. On receipt of an LSP setup
request (RSVP-TE Path message) for an inter-domain TE LSP, the
decision of whether to signal the LSP contiguously or whether to nest
or stitch it to another TE LSP, depends on the parameters signaled
from the ingress node and on the configuration of the local node.
The stitching segment LSP or H-LSP used to cross a domain may be
pre-established or signaled dynamically based on the demand caused by
the arrival of the inter-domain TE LSP setup request.
3. Procedures on the Domain Border Node
Whether an inter-domain TE LSP is contiguous, nested, or stitched is
limited by the signaling methods supported by or configured on the
intermediate nodes, and it is usually the domain border nodes where
this restriction applies since other transit nodes are oblivious to
the mechanism in use. The ingress of the LSP may further restrict the
choice by setting parameters in the Path message when it is signaled.
When a domain border node receives the RSVP Path message for an
inter-domain TE LSP setup, it MUST carry out the following procedures
before it can forward the Path message to the next node along the
path:
1. Apply policies for the domain and the domain border node. These
policies may restrict the establishment of inter-domain TE LSPs.
In case of a policy failure, the node SHOULD fail the setup and
send a PathErr message with error code "Policy control failure"/
"Inter-domain policy failure".
2. Determine the signaling method to be used to cross the domain.
If the ingress node of the inter-domain TE LSP has specified
restrictions on the methods to be used, these MUST be adhered
Farrel, Ayyangar and Vasseur [Page 5]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
to. Within the freedom allowed by the ingress node, the domain
border node MAY choose any method according to local
configuration and policies. If no resultant signaling method is
available or allowed, the domain border node MUST send a PathErr
message an error code as described in Section 4.1.
3. Carry out ERO procedures as described in the Section 3 in
addition to the procedures in [RFC3209] and [RFC3473].
4. Perform any path computations as required to determine the path
across the domain and potentially to select the exit point from
the domain.
The path computation procedure is outside the scope of this
document. A path computation option is supplied in
[INTER-DOMAIN-PD-PATH-COMP], and another option is to use a
Path Computation Element (PCE) [RFC4655].
4a. In the case of nesting or stitching, either find an existing
intra-domain TE LSP to carry the inter-domain TE LSP or
signal a new one, depending on local policy.
In event of a path computation failure, a PathErr message SHOULD
be sent with error code "Routing Problem" using an error value
selected according to the reason for computation failure.
In the event of the receipt of a PathErr message reporting
signaling failure from within the domain or reported from a
downstream domain, the domain border node MAY apply crankback
procedures as described in Section 3.2. If crankback is not
applied, or is exhausted, the border node MUST continue with
PathErr processing as described in [RFC3209] and [RFC3473].
In the event of successful processing of a Path or Resv message,
the domain border node MUST carry out RRO procedures as described
in Section 3.3.
3.1. Rules on ERO Processing
The ERO that a domain border node receives in the Path message was
supplied by the ingress node of the TE LSP and may have been updated
by other nodes (for example, other domain border nodes) as the Path
message was propagated. The content of the ERO depends on several
factors including:
- the path computation techniques used
- the degree of TE visibility available to the nodes performing
path computation
- policy at the nodes creating/modifying the ERO.
Farrel, Ayyangar and Vasseur [Page 6]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
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
multiple hops entirely within a domain. Therefore, the discussion
that follows may be equally applied to any node within a domain
although the term 'domain border node' continues to be used for
clarity.
When a Path message reaches the domain border node, the following
rules SHOULD be used for ERO processing and for further signaling.
1. If there are any policies related to ERO processing for the
LSP, they SHOULD be applied and corresponding actions taken. For
example, there might be a policy to reject EROs that identify
nodes within the domain. In case of inter-domain LSP setup
failures due to policy failures related to ERO processing, the
node SHOULD issue a PathErr with error code "Policy control
failure"/"Inter-domain explicit route rejected".
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
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
before sending the Path message to the next hop. These
procedures SHOULD be followed for nesting or stitching of
inter-domain TE LSPs.
3. If an ERO subobject identifies a TE link formed by the
advertisement of an H-LSP or LSP segment (whether numbered or
unnumbered), contiguous signaling MUST NOT be used. The node MUST
either use nesting or stitching according to the capabilities of
the LSP that forms the TE link, the parameters signaled in 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
ERO and the parameters on the Path message, the domain border node
SHOULD send a PathErr with error code "Routing Problem"/"ERO
conflicts with inter-domain signaling method".
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
an AS number. In such cases, the ERO MUST be expanded to
determine the path to the next hop using some form of path
computation that may, itself, generate loose hops.
5. In the absence of any ERO subobjects beyond the local domain
border node, the LSP egress (the destination encoded in the RSVP
Session object) MUST be considered as the next loose hop and
rule 4 applied.
6. In the event of any other failures processing the ERO, a PathErr
message SHOULD be sent as described in [RFC3209] or [RFC3473].
Farrel, Ayyangar and Vasseur [Page 7]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
3.2. LSP Setup Failure and Crankback
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
traverses multiple domains, this PathErr will be seen successively by
each domain border node.
Domain border nodes MAY apply local policies to restrict the
propagation of information about the contents of the domain. For
example, a domain border node MAY replace the information in a
PathErr message that indicates a specific failure at a specific node
with information that report a more general error with the entire
domain. These procedures are similar to those described for the
borders of overlay networks in [RFC4208].
However:
- A domain border node MUST NOT suppress the propagation of a PathErr
message
- Nodes other than domain border nodes SHOULD NOT modify the contents
of a PathErr message
- Domain border nodes SHOULD NOT modify the contents of a PathErr
message unless domain confidentiality is a specific requirement.
Domain border nodes provide an opportunity for crankback rerouting
[CRANKBACK]. On receipt of a PathErr message generated because of an
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
by the parameters signaled on the Path message for the LSP. Such
attempts might involve the computation of alternate routes through
the domain, or the selection of different downstream domains. If a
subsequent attempt is successful, the domain border router MUST
discard the held PathErr message, but if all subsequent attempts are
unsuccessful, the domain border router MUST send the PathErr upstream
toward the ingress node. In this latter case, the domain border
router MAY change the information in the PathErr message to provide
further crankback details and information aggregation as described
in [CRANKBACK].
Crankback rerouting MAY also be used to handle the failure of LSPs
after they have been established [CRANKBACK].
3.3. RRO Processing Across Domains
[RFC3209] defines the RRO as an optional used for loop detection and
for providing information about the hops traversed by LSPs.
As described for overlay networks in [RFC4208], a domain border node
MAY filter or modify the information provided in an RRO for
confidentiality reasons according to local policy. For example, a
series of identifiers of hops within a domain MAY be replaced with
Farrel, Ayyangar and Vasseur [Page 8]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
the domain identifier (such as the AS number) or be removed entirely
leaving just the domain border nodes.
Note that a domain border router MUST NOT mask its own presence, and
MUST include itself in the RRO.
Such filtering of RRO information does not hamper the working of the
signaling protocol, but the subsequent information loss may render
management diagnostic procedures inoperable or at least make them
more complicated requiring the coordination of administrators of
multiple domains.
Similarly protocol procedures that depend on the presence of RRO
information may become inefficient. For example, the fast reroute
procedures defined in [RFC4090] use information in the RRO to
determine the labels to use and the downstream MP.
3.4. Notify Message Processing
Notify messages are introduced in [RFC3473]. They may be sent direct
rather than hop-by-hop, and so may speed the propagation of error
information. If a domain border router is interested in seeing
such messages (for example, to enable it to provide protection
switching), it is RECOMMENDED that the domain border router update
the Notify Request objects in the Path and Resv messages to show its
own address following the procedures of [RFC3473].
4. RSVP-TE Signaling Extensions
The following RSVP-TE signaling extensions are defined to enable
inter-domain LSP setup.
4.1. Control of Choice of Signaling Method
In many network environments there may be a network-wide policy that
determines which one of the three inter-domain LSP techniques is
used. In these cases, no protocol extensions are required.
However, in environments that support more than one technique, an
ingress node may wish to constrain the choice made by domain border
nodes for each inter-domain TE LSP that it originates.
[RFC4420] defines the LSP_Attributes object that can be used to
signal required attributes of an LSP. The Attributes Flags TLV
includes Boolean flags that define individual attributes.
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
nodes to using contiguous signaling.
Farrel, Ayyangar and Vasseur [Page 9]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
Contiguous LSP bit (bit number assignment in Section 8.1).
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
LSP technique is used. This flag bit is only to be used in the
Attributes Flags TLV.
When an LSR receives a Path message containing this bit set (one),
the node MUST NOT perform stitching or nesting in support of the TE
LSP being set up. When this bit is clear (zero), an intermediate node
MAY perform stitching or nesting according to local policy.
This bit MUST NOT be modified by any transit node.
An intermediate node that supports the LSP_Attributes object and the
Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit,
but cannot support contiguous TE LSPs, MUST send a Path Error message
with an error code "Routing Problem"/"Contiguous LSP type not
supported" if it receives a Path message with this bit set.
If an intermediate node receiving a Path message with the "Contiguous
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
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
SHOULD include an RRO Attributes subobject in the RRO of the
corresponding Resv message with the "Contiguous LSP" bit set to
report its behavior.
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 this "Contiguous LSP" bit, then it MUST reject
the Path message with a PathErr message as described in [RFC4420].
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
document, but may include the computation of an alternate path.
5. Protection and Recovery of Inter-Domain TE LSPs
The procedures described in Sections 3 and 4 MUST be applied to all
inter-domain TE LSPs, including bypass tunnels, detour LSPs
[RFC4090], and segment recovery LSPs [SEGMENT-PROTECTION]. This means
that these LSPs will also be subjected to ERO processing, policies,
path computation, etc.
Note also that the paths for these backup LSPs needs to be either
pre-configured, computed and signaled with the protected LSP, or
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
Farrel, Ayyangar and Vasseur [Page 10]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
TE visibility of the computation point into the subsequent domain.
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
a domain border node. In order that the backup path remains disjoint
from the protected LSP(s) the node performing the ERO expansion must
be provided with the path of the protected LSPs between the PLR and
the MP. This information can be gathered from the RROs of the
protected LSPs and is signaled in the DETOUR object for Fast Reroute
[RFC4090], and using route exclusion [EXCLUDE-ROUTE] for other
protection schemes.
5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR)
[RFC4090] describes two methods for local protection for a
packet TE LSP in case of link, SRLG, or node failure. This section
describes how these mechanisms work with the proposed signaling
solutions for inter-domain TE LSP setup.
5.1.1. Failure Within a Domain (Link or Node Failure)
The mode of operation of MPLS-TE Fast Reroute to protect a
contiguous, stitched or nested TE LSP within a domain is identical to
the existing procedures described in [RFC4090]. Note that, in the
case of nesting or stitching, the end-to-end LSP is automatically
protected by the protection operation performed on the H-LSP or
stitching segment LSP.
No protocol extensions are required.
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 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
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
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
usual to attempt to use the local (connected by the filed link)
domain border nodes as the PLR and MP.
To protect an inter-domain link with MPLS-TE Fast Reroute, a set of
backup tunnels must be configured or dynamically computed between the
PLR and MP such that they are diversely routed from the protected
inter-domain link and the protected inter-domain LSPs.
Each protected inter-domain LSP using the protected inter-domain TE
link must be assigned to an NHOP bypass tunnel that is diverse from
Farrel, Ayyangar and Vasseur [Page 11]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
the protected LSP. Such an NHOP bypass tunnel can be selected by
analyzing the RROs in the Resv messages of the available bypass
tunnels and the protected TE LSP. It may be helpful to this process
if the extensions defined in [NODE-ID] are used to clearly
distinguish nodes and links in the RROs.
5.1.3. Failure of a Border Node
Two border node failure cases exist. If the domain border falls on a
link as described in the previous section, the border node at either
end of the link may fail. Alternatively, if the border falls on a
border node (as is the case with IGP areas) that single border node
may fail.
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
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
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
downstream domain exit point in the case of the failure of the
domian entry point. Where the domain border falls at a single domain
border node, both cases will apply.
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
to fill these roles.
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
available NNHOP tunnels by examination of their RROs.
Note that where the PLR is not immediately upstream of the failed
node, error propagation time may be delayed unless some mechanism
such as [BFD-MPLS] is implemented, or unless direct reporting, such
as through the GMPLS Notify message [RFC3473] is employed.
5.2. Protection and Recovery of GMPLS LSPs
[SEGMENT-PROTECTION] describes GMPLS based segment recovery. This
allows protection against a span failure, a node failure, or failure
over any particular portion of a network used by an LSP.
The domain border failure cases described in Section 5.1 may also
occur in GMPLS networks (including packet networks) and can be
protected against using segment protection without any additional
protocol extensions.
Note that if loose hops are used in the construction of the working
and protection paths signaled for segment protection then care is
Farrel, Ayyangar and Vasseur [Page 12]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
required to keep these paths disjoint. If the paths are signaled
incrementally then route exclusion [EXCLUDE-ROUTE] may be used to
ensure that the paths are disjoint. Otherwise a coordinated path
computation technique such as that offered by cooperating Path
Computation Elements [RFC4655] can provide suitable paths.
6. Re-Optimization of Inter-Domain TE LSPs
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
the preferred path and make-before-break signaling procedures
[RFC3209] to minimize traffic disruption.
Re-optimization of an inter-domain TE LSP may require a new path in
more than one domain.
The nature of the inter-domain LSP setup mechanism defines how
re-optimization can be applied. If the LSP is contiguous then 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
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
use, the H-LSP or stitching segment may be independently re-optimized
within the domain without impacting the end-to-end LSP.
In all cases, however, the ingress LSP may wish to exert control and
coordination over the re-optimization process.
[LOOSE-REOPT] describes mechanisms that allow:
- 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
path.
- A node with a loose next hop to inform the ingress node that a
better path exists.
These mechanisms SHOULD be used for re-optimization of a contiguous
inter-domain TE LSP.
7. Security Considerations
A separate document is being prepared to examine the security aspects
of RSVP-TE signaling with special reference to multi-domain
scenarios. [INTER-DOMAIN-FRAMEWORK] provides an overview of the
requirements for security in an MPLS-TE or GMPLS multi-domain
environment.
When signaling an inter-domain RSVP-TE LSP, an operator may make use
of the security features already defined for RSVP-TE [RFC3209]. This
Farrel, Ayyangar and Vasseur [Page 13]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
may require some coordination between the domains to share the keys
(see [RFC2747] and [RFC3097]), and care is required to ensure that
the keys are changed sufficiently frequently. Note that this may
involve additional synchronization, should the domain border nodes
be protected with FRR, since the MP and PLR should also share the
key.
For an inter-domain TE LSP, especially when it traverses different
administrative or trust domains, the following mechanisms SHOULD be
provided to an operator (also see [RFC4216]):
1) A way to enforce policies and filters at the domain borders
to process the incoming inter-domain TE LSP setup requests
(Path messages) based on certain agreed trust and service
levels/contracts between domains. Various LSP attributes
such as bandwidth, priority, etc. could be part of such a
contract.
2) A way for the operator to rate-limit LSP setup requests
or error notifications from a particular domain.
3) A mechanism to allow policy-based outbound RSVP message
processing at the domain border node, which may involve
filtering or modification of certain addresses in RSVP
objects and messages.
Some examples of the policies described above are:-
A) An operator may choose to implement some kind of ERO filtering
policy on the domain border node to disallow or ignore hops
within the domain from being identified in the ERO of an
incoming Path message.
B) In order to preserve confidentiality of network topology, an
operator may choose to disallow recording of hops within the
domain in the RRO or may choose to filter out certain recorded
RRO addresses at the domain border node.
C) An operator may require the border node to modify the addresses
of certain messages like PathErr or Notify originated from hops
within the domain.
Note that the detailed specification of such policies and their
implementation are outside the scope of this document.
8. IANA Considerations
IANA is requested to make the codepoint allocations described in the
following sections.
Farrel, Ayyangar and Vasseur [Page 14]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
8.1. Attribute Flags for LSP_Attributes Object
A new bit is to be allocated from the "Attributes Flags" sub-registry
of the "RSVP TE Parameters" registry.
Path Resv RRO
Bit Name message message sub-object
---- ------------------------------- -------- -------- ----------
XX Contiguous LSP Yes No Yes
The value XX is to be defined by IANA. A value of 4 is suggested.
8.2. New Error Codes
New RSVP error codes/values are required to be allocated from the
"Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry
of the "RSVP Parameters" registry.
For the existing error code "Policy control failure" (value 2), two
new error values are suggested as follows. The values are suggested
and are for IANA determination.
103 = Inter-domain policy failure
104 = Inter-domain explicit route rejected
For the existing error code "Routing Problem" (value 24), two new
error values are suggested as follows. The values are suggested and
are for IANA determination.
21 = Contiguous LSP type not supported
22 = ERO conflicts with inter-domain signaling method
9. Acknowledgements
The authors would like to acknowledge the input and helpful comments
from Kireeti Kompella on various aspects discussed in the document.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., et al, "Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
Farrel, Ayyangar and Vasseur [Page 15]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
[RFC3473] Berger, L., et al, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol -
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC4206] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized
MPLS TE", RFC 4206, October 2005.
[RFC4420] Farrel, A., et al, "Encoding of Attributes for
Multiprotocol Label Switching (MPLS) Label Switched Path
(LSP) Establishment Using RSVP-TE", RFC 4420, February
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
Switched Path Stitching with Generalized MPLS Traffic
Engineering", draft-ietf-ccamp-lsp-stitching, (work in
progress).
10.2. Informative References
[RFC2747] Baker, F., Lindell, B., and Talwar, B., "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC3097] Braden, R., and Zhang, L., "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC4090] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", RFC 4090, May 2005.
[RFC4105] LeRoux, JL., Vasseur, JP., Boyle, J., et al, "Requirements
for Inter-Area MPLS Traffic Engineering", RFC 4105, June
2005.
[RFC4208] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the
Overlay Model", RFC 4208, October 2005.
[RFC4216] Zhang, R., et al, "MPLS Inter-Autonomous System (AS)
Traffic Engineering (TE) Requirements", RFC 4216, November
2005.
[RFC4655] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
Farrel, Ayyangar and Vasseur [Page 16]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
[BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs",
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).
[EXCLUDE-ROUTE] Lee, CY., Farrel, A., and De Cnodder, S., "Exclude
Routes - Extension to RSVP-TE",
draft-ietf-ccamp-rsvp-te-exclude-route, (work in progress).
[INTER-DOMAIN-FRAMEWORK] Farrel, A., et al, "A Framework for
Inter-Domain MPLS Traffic Engineering",
draft-ietf-ccamp-inter-domain-framework, (work in
progress).
[INTER-DOMAIN-PD-PATH-COMP] Vasseur, JP., Ayyangar, A., and
Zhang, R., "A Per-domain path computation method for
computing Inter-domain Traffic Engineering (TE) Label
Switched Paths (LSPs)",
draft-ietf-ccamp-inter-domain-pd-path-comp, (work in
progress).
[NODE-ID] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of an
RRO node-id subobject", draft-ietf-mpls-nodeid-subobject,
(work in progress).
[SEGMENT-PROTECTION] Berger, L., et al, "GMPLS Based Segment
Recovery", draft-ietf-ccamp-gmpls-segment-recovery, (work
in progress).
11. Authors' Addresses
Adrian Farrel
Old Dog Consulting
E-mail: adrian@olddog.co.uk
Arthi Ayyangar
Nuova Systems
2600 San Tomas Expressway
Santa Clara, CA 95051
US
Email: arthi@nuovasystems.com
Farrel, Ayyangar and Vasseur [Page 17]
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt January 2007
Jean Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: jpv@cisco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Farrel, Ayyangar and Vasseur [Page 18]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/