draft-ietf-ccamp-inter-domain-rsvp-te-03.txt   draft-ietf-ccamp-inter-domain-rsvp-te-04.txt 
IETF Internet Draft Arthi Ayyangar(Editor) Network Working Group A. Farrel
Proposed Status: Standards Track Juniper Networks Proposed Status: Standards Track Old Dog Consulting
Expires: September 2006 Updates: RFC 3209, RFC 3473
Jean-Philippe Vasseur(Editor) Expires: July 2007 A. Ayyangar
Nuova Systems
JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
Inter domain GMPLS Traffic Engineering - RSVP-TE extensions January 2007
draft-ietf-ccamp-inter-domain-rsvp-te-03.txt Inter domain MPLS and GMPLS Traffic Engineering - RSVP-TE extensions
draft-ietf-ccamp-inter-domain-rsvp-te-04.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 1, line 36 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract Abstract
This document describes extensions to Generalized Multi-Protocol Label This document describes procedures and protocol extensions for the
Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE)
(RSVP-TE) signaling required to support mechanisms for the establishment signaling in Multiprotocol Label Switching Traffic Engineering
and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths (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.
(LSPs), both packet and non-packet, that traverse multiple domains. For For the purpose of this document, a domain is considered to be any
the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space
collection of network elements within a common realm of address space or or path computation responsibility. Examples of such domains include
path computation responsibility. Examples of such domains include Autonomous Systems, IGP routing areas, and GMPLS overlay networks.
Autonomous Systems, IGP areas and GMPLS overlay networks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 boundary 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 . . . . . . . . . . . . . . 9 3.3 RRO Processing Across Domains . . . . . . . . . . . . . . 8
4. RSVP-TE signaling extensions . . . . . . . . . . . . . . . . . 9 3.4 Notify Message Processing . . . . . . . . . . . . . . . . 9
4.1 Control of downstream choice of signaling method . . . . . 9 4. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . . 9
5. Protection and recovery of inter-domain TE LSPs . . . . . . . 11 4.1 Control of Downstream Choice of Signaling Method . . . . . 9
5.1 Fast Recovery support using MPLS TE Fast Reroute . . . . . 11 5. Protection and Recovery of Inter-Domain TE LSPs . . . . . . . 10
5.1.1 Failure within a domain (link or node failure) . . . . 11 5.1 Fast Recovery Support Using MPLS-TE Fast Reroute . . . . . 11
5.1.2 Failure of link at domain boundaries . . . . . . . . . 11 5.1.1 Failure Within a Domain (Link or Node Failure) . . . . 11
5.1.3 Failure of a boundary node . . . . . . . . . . . . . . 12 5.1.2 Failure of Link at Domain Borders . . . . . . . . . . 11
5.2 Protection and recovery of GMPLS LSPs . . . . . . . . . . 13 5.1.3 Failure of a Border Node . . . . . . . . . . . . . . . 12
6. Re-optimization of inter-domain TE LSPs . . . . . . . . . . . 13 5.2 Protection and Recovery of GMPLS LSPs . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Re-Optimization of Inter-Domain TE LSPs . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.1 Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 16 8.1 Attribute Flags for LSP_Attributes Object . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10.1 Normative References . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.2 Informative References . . . . . . . . . . . . . . . . . 17 10.1 Normative References . . . . . . . . . . . . . . . . . . 15
Appendix 1: Examples . . . . . . . . . . . . . . . . . . . . . . 18 10.2 Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 23
1. Introduction 1. Introduction
The requirements for inter-area and inter-AS MPLS Traffic Engineering The requirements for inter-area and inter-AS Multiprotocol Label
have been developed by the Traffic Engineering Working Group and have Switching (MPLS) Traffic Engineering (TE) are stated in [RFC4105] and
been stated in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS] [RFC4216] respectively. Many of these requirements also apply to
respectively. Many of these requirements also apply to GMPLS Generalized MPLS (GMPLS) networks. The framework for inter-domain
networks. The framework for inter-domain GMPLS Traffic Engineering MPLS-TE is provided in [INTER-DOMAIN-FRAMEWORK].
has been provided in [INTER-DOMAIN-FRAMEWORK].
This document presents the RSVP-TE signaling extensions for the setup This document presents procedures and extensions to Resource
and maintenance of TE LSPs that span multiple domains. The signaling Reservation Protocol Traffic Engineering (RSVP-TE) signaling for the
procedures described in this document are applicable to both MPLS setup and maintenance of traffic engineered Label Switched Paths (TE
packet LSPs ([RSVP-TE]) and all LSPs that use RSVP-TE GMPLS LSPs) that span multiple domains in MPLS-TE or GMPLS networks. The
extensions as described in [RSVP-GMPLS]. Three different signaling signaling procedures described in this document are applicable to
methods along with the corresponding RSVP-TE extensions and MPLS-TE packet LSPs established using RSVP-TE ([RFC3209]) and all
procedures are proposed in this document. LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as
described in [RFC3473].
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 For the purpose of this document, a domain is considered to be any
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 areas and GMPLS overlay networks ([GMPLS- Autonomous Systems, IGP areas, and GMPLS overlay networks
OVERLAY]). ([RFC4208]).
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.
ASBR: routers used to connect together ASes of a different or the ASBR: routers used to connect together ASes of a different or the
same Service Provider via one or more Inter-AS links. 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.
H-LSP: Hierarchical LSP
FA-LSP: Forwarding Adjacency LSP FA: Forwarding Adjacency.
LSP: MPLS Label Switched Path 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.
NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which
bypasses a single link of the protected LSP. bypasses a single link of the protected LSP.
NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel, NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel,
which bypasses a single node of the protected LSP. which bypasses a single node of the protected LSP.
PLR: Point of Local Repair. The head-end of a bypass tunnel. PLR: Point of Local Repair. The ingress of a bypass tunnel.
Protected LSP: an LSP is said to be protected at a given hop if it
has one or multiple associated backup tunnels originating at that
hop.
RRO - Record Route Object
TE: Traffic Engineering RRO: Record Route Object.
TE LSP: Traffic Engineering Label Switched Path TE link: Traffic Engineering link.
TE link: Traffic Engineering link 2. Signaling Overview
TED: MPLS Traffic Engineering Database 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.
2. Signaling overview 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 RSVP-TE signaling of a TE LSP within a single domain is described The specific protocol extensions required to signal each LSP type are
in [RSVP-TE] and [RSVP-GMPLS]. This document focuses on the RSVP-TE described in other documents and are out of scope for this document.
signaling extensions required for inter-domain TE LSP setup and Similarly, the routing extensions and path computation techniques
maintenance. Any other extensions that may be needed for routing or necessary for the establishment of inter-domain LSPs are out of
path computation are outside the scope of this document. scope.
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 - A contiguous TE LSP is a single end-to-end TE LSP that Contiguous
is setup across multiple domains using RSVP-TE signaling procedures A contiguous TE LSP is a single end-to-end TE LSP that is set up
described in [RSVP-TE] and [RSVP-GMPLS]. No additional TE LSPs are across multiple domains using RSVP-TE signaling procedures
required to signal a contiguous TE LSP and the same RSVP-TE described in [RFC3209] and [RFC3473]. No additional TE LSPs are
information for the TE LSP is maintained along the entire LSP path. 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 - Nesting one or more TE LSPs into another TE LSP is Nesting
described in [LSP-HIERARCHY]. This technique can be used to nest one 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 or more inter-domain TE LSPs into an intra-domain hierarchical LSP
(H-LSP). Label stacking construct may be used to achieve nesting, (H-LSP). The label stacking construct is used to achieve nesting
when appropriate, say in packet networks. In the rest of this in packet networks. In the rest of this document, the term H-LSP
document, the term H-LSP is used to refer to an LSP that allows is used to refer to an LSP that allows other LSPs to be nested
nesting of other LSPs into it and that may or may not be advertised within it. An H-LSP may be advertised as a TE link within the same
as a TE link. Furthermore, an H-LSP may or may not be an FA-LSP [LSP- instance of the routing protocol as was used to advertise the TE
HIERARCHY]. links from which it was created, in which case it is a Forwarding
Adjacency (FA) [RFC4206].
Stitching - The concept of LSP stitching as well as the required Stitching
signaling procedures is described in [LSP-STITCHING]. This technique The concept of LSP stitching as well as the required signaling
can be used to stitch an inter-domain TE LSP to an intra-domain LSP procedures is described in [LSP-STITCHING]. This technique can be
segment. A inter-domain stitched TE LSP is a TE LSP made up of used to stitch together shorter LSPs (LSP segments) to create a
different TE LSP segments within each domain which are "stitched" single, longer LSP. The LSP segments of an inter-domain LSP may be
together in the data plane so that an end-to-end LSP is achieved in intra-domain LSPs or inter-domain LSPs.
the data plane. In the control plane, however, the different LSP
segments are signaled as distinct RSVP sessions which are independent
from the RSVP session for the inter-domain LSP. While stitching is
similar to nesting in the control plane, in the data plane, stitching
allows for only one inter-domain LSP to be associated with any one
intra-domain LSP, and does not require the use of label stacks.
On receipt of an LSP setup request for an inter-domain TE LSP, the 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 decision of whether to signal the LSP contiguously or whether to nest
or stitch it to another TE LSP, depends on the signaled TE LSP or stitch it to another TE LSP, depends on the parameters signaled
characteristics from the head-end node or the local node from the ingress node and on the configuration of the local node.
configuration, when not explicitly signaled. Also, the TE LSP segment
or H-LSP within the domain may either be pre-configured or signaled
dynamically based on the arrival of the inter-domain TE LSP setup
request.
3. Procedures on the domain boundary 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.
Whether an inter-domain TE LSP is contiguous, nested or stitched is 3. Procedures on the Domain Border Node
determined mostly by the signaling method supported by or configured
on the intermediate nodes, usually the domain boundary nodes that the
inter-domain TE LSP traverses. It also depends on certain parameters
that may be signaled by the head-end node for the inter-domain TE
LSP.
When a domain boundary node receives the RSVP Path message for an 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 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 before it can forward the Path message to the next node along the
path: path:
1. Apply any locally configured policies. In case of a policy 1. Apply policies for the domain and the domain border node. These
failure, the node SHOULD fail the setup of the LSP and policies may restrict the establishment of inter-domain TE LSPs.
originate a PathErr with error code=2 ("Policy control In case of a policy failure, the node SHOULD fail the setup and
failure") and error sub-code="Inter-domain policy failure" send a PathErr message with error code "Policy control failure"/
(TBD). "Inter-domain policy failure".
2. Determine the signaling method to be used. The head-end node 2. Determine the signaling method to be used to cross the domain.
of the inter-domain TE LSP may have explicitly specified a If the ingress node of the inter-domain TE LSP has specified
signaling method or if the signaling method is not explicitly restrictions on the methods to be used, these MUST be adhered
signaled, then the node MAY determine the signaling method to. Within the freedom allowed by the ingress node, the domain
based on local configuration and policies. If the desired border node MAY choose any method according to local
signaling method signaled by the head-end cannot be supported configuration and policies. If no resultant signaling method is
at this node for some reason, then a PathErr message as available or allowed, the domain border node MUST send a PathErr
described in Section 4.1 MUST be generated. message an error code as described in Section 4.1.
3. Carry out ERO procedures as described in the next section in 3. Carry out ERO procedures as described in the Section 3 in
addition to the procedures in [RSVP-TE] and [RSVP-GMPLS]. addition to the procedures in [RFC3209] and [RFC3473].
4. Perform any path computations as required (say for ERO 4. Perform any path computations as required to determine the path
expansion). The path computation procedure itself is outside across the domain and potentially to select the exit point from
the scope of this document. One such path computation option is the domain.
addressed in [INTER-DOMAIN-PD-PATH-COMP]. Another option is to
use a Path Computation Element (PCE) ([PCE]) for path
computation. Path computation may itself involve determining the
exit point from the TE domain ([INTER-DOMAIN-PD-PATH-COMP]).
4a. In case of nesting or stitching, either find an existing 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 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.
4b. In case of a path computation failure, a PathErr SHOULD be In event of a path computation failure, a PathErr message SHOULD
generated as described in [INTER-DOMAIN-PD-PATH-COMP]. be sent with error code "Routing Problem" using an error value
selected according to the reason for computation failure.
5. In case of any other RSVP signaling failures, procedures as In the event of the receipt of a PathErr message reporting
described in [RSVP-TE] and [RSVP-GMPLS] SHOULD be followed. signaling failure from within the domain or reported from a
Follow procedures related to LSP setup failure and crankback downstream domain, the domain border node MAY apply crankback
as described in Section 3.2, where applicable. 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].
6. Carry out RRO procedures as described in Section 3.3, if In the event of successful processing of a Path or Resv message,
applicable. the domain border node MUST carry out RRO procedures as described
in Section 3.3.
3.1. Rules on ERO processing 3.1. Rules on ERO Processing
The ERO that a domain boundary node receives in the Path message for The ERO that a domain border node receives in the Path message was
an inter-domain TE LSP will be dependent on several factors such as supplied by the ingress node of the TE LSP and may have been updated
the level of visibility that the head-end node of the inter-domain TE by other nodes (for example, other domain border nodes) as the Path
LSP has into other domains, the path computation techniques applied message was propagated. The content of the ERO depends on several
at the head-end node, policy agreements between two domains; etc. factors including:
Eventually, when the ERO reaches a domain boundary node, the
following rules SHOULD be used for ERO processing and signaling. - the path computation techniques used
Within a domain, there may be no H-LSPs or LSP segments. If they are - the degree of TE visibility available to the nodes performing
present, then they may originate and terminate on domain boundary path computation
nodes. There could also be H-LSPs and LSP segments that may originate - policy at the nodes creating/modifying the ERO.
and terminate at other nodes in the domain. In general, these ERO
processing rules are also applicable to non-boundary nodes that may In general, H-LSPs and LSP segments are used between domain border
participate in signaling the inter-domain TE LSP. 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 1. If there are any policies related to ERO processing for the
LSP, they SHOULD be applied and corresponding actions should be LSP, they SHOULD be applied and corresponding actions taken. For
taken. E.g. there could exist a policy to reject inter-domain example, there might be a policy to reject EROs that identify
LSP setup request containing an ERO with subobjects identifying
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=2 ("Policy control node SHOULD issue a PathErr with error code "Policy control
failure") and error sub-code="Inter-domain explicit route failure"/"Inter-domain explicit route rejected".
rejected" (TBD).
2. Section 8.2 of [LSP-HIERARCHY] describes how a node at the 2. Section 8.2 of [RFC4206] describes how a node at the edge of a
edge of a region (domain) processes the ERO in the incoming region processes the ERO in the incoming Path message and uses
Path message and uses this ERO, to either find an existing H-LSP this ERO, to either find an existing H-LSP or signal a new H-LSP
or signal a new H-LSP using the ERO hops. This also includes using the ERO hops. This process includes adjusting the ERO
adjusting the ERO before sending the Path message to the next before sending the Path message to the next hop. These
hop node. These procedures SHOULD also be followed for nesting procedures SHOULD be followed for nesting or stitching of
or stitching of inter-domain TE LSPs to H-LSPs or LSP segments inter-domain TE LSPs.
respectively. While the domain boundaries are tied to link
switching capabilities in [LSP-HIERARCHY], these procedures are
also applicable to other domain boundary nodes in the context
of this document.
3. If the ERO subobject identifies a TE link formed by a H-LSP or 3. If an ERO subobject identifies a TE link formed by the
LSP segment within the domain, either numbered or unnumbered, advertisement of an H-LSP or LSP segment (whether numbered or
then a contiguous LSP MUST NOT be signaled. The node MUST either unnumbered), contiguous signaling MUST NOT be used. The node MUST
nest or stitch the inter-domain TE LSP to the local H-LSP or LSP either use nesting or stitching according to the capabilities of
segment. If, however, the head-end node for the inter-domain LSP the LSP that forms the TE link, the parameters signaled in the
has requested that the inter-domain TE LSP be contiguous, then Path message, and local policy. If there is a conflict between the
this is a conflict and a PathErr with error code=24 ("Routing capabilities of the LSP that forms the TE link indicated in the
Problem") and error sub-code="ERO conflicts with inter-domain ERO and the parameters on the Path message, the domain border node
signaling method" (TBD) SHOULD be issued. SHOULD send a PathErr with error code "Routing Problem"/"ERO
conflicts with inter-domain signaling method".
4. In the absence of any ERO subobjects, the LSP destination in 4. An ERO in a Path message received by a domain border node may
the SESSION object SHOULD be considered as the next loose hop. have a loose hop as the next hop. This may be an IP address or
A node may also receive an ERO with explicit IPv4, IPv6 or AS an AS number. In such cases, the ERO MUST be expanded to
number loose hops. In such cases, a path computation to expand determine the path to the next hop using some form of path
this loose hop SHOULD be carried out. Path computation as computation that may, itself, generate loose hops.
described in [INTER-DOMAIN-PD-PATH-COMP] or using a PCE should
be used to expand the ERO in these cases and to determine the
intermediate hops.
5. In case of any other failures in processing the ERO hop(s), a 5. In the absence of any ERO subobjects beyond the local domain
PathErr message with appropriate error codes as described in border node, the LSP egress (the destination encoded in the RSVP
[RSVP-TE] or [RSVP-GMPLS] SHOULD be generated. Session object) MUST be considered as the next loose hop and
rule 4 applied.
3.2. LSP setup failure and crankback 6. In the event of any other failures processing the ERO, a PathErr
message SHOULD be sent as described in [RFC3209] or [RFC3473].
In case of any setup failures along the path due to policy or 3.2. LSP Setup Failure and Crankback
admission control or other reasons, a corresponding
PathErr/ResvErr/Notify is generated and sent upstream and/or
downstream. An ERROR_SPEC comprises of information regarding the
point of failure (network element) and details about the failure
itself. When an LSP traverses multiple domains, a failure could be
generated in any domain along the path and an error notification may
need to be propagated across multiple domains. So, an error
notification message itself may be subjected to policies as it
traverses domain boundaries and a boundary node MAY modify domain
specific information carried in the error message. E.g. the error
node address in the RSVP ERROR_SPEC or IF_ID ERROR_SPEC or the
Interface Identifier in IF_ID ERROR_SPEC may be modified at the
boundary node for confidentiality reasons. Nodes other than domain
boundary nodes SHOULD NOT modify ERROR_SPEC contents. It is also
RECOMMENDED that such a policy be implemented only on domain boundary
nodes for inter-domain LSPs where preserving confidentiality is a
requirement.
Also, in case of an inter-domain LSP setup failure, there may be When an error occurs during LSP setup a PathErr message is sent back
cases when the error is not propagated all the way upstream to the towards the LSP ingress node to report the problem. If the LSP
head-end node. A PathErr may be intercepted by a boundary node in the traverses multiple domains, this PathErr will be seen successively by
domain in which the error is generated (or any other node along the each domain border node.
path) and this node may attempt to find an alternate path. Finding
an alternate path means finding a new path downstream to the node
performing re-routing and avoiding the failed network elements. This
may involve finding a path within the domain experiencing the failure
or it may mean finding new boundary node(s) or new downstream domain.
Crankback re-routing depends not only on local configuration and Domain border nodes MAY apply local policies to restrict the
ability of a boundary node to do local crankback re-routing, but also propagation of information about the contents of the domain. For
on any specific parameters requested by the head-end node itself for example, a domain border node MAY replace the information in a
that LSP. In certain cases, it may be desirable for the head-end node PathErr message that indicates a specific failure at a specific node
to exert some control on whether crankback re-routing at intermediate with information that report a more general error with the entire
nodes is desirable or not. Procedures and extensions described in domain. These procedures are similar to those described for the
[CRANKBACK] should be followed for crankback re-routing. When borders of overlay networks in [RFC4208].
crankback re-routing is allowed, a node along the TE LSP path may
either decide to forward the PathErr message upstream towards the
head-end node of the inter-domain TE LSP or try to determine an
alternate path around the failure. When crankback re-routing is not
allowed or if the node cannot perform crankback re-routing, then, on
receiving a PathErr message, the node should propagate the PathErr
message upstream.
[RSVP-GMPLS] allows nodes to generate a targeted Notify message in However:
addition to a PathErr/ResvErr message, to expedite error - A domain border node MUST NOT suppress the propagation of a PathErr
notification, if a Notify Request has been received in the message
corresponding Path/Resv message. This is also applicable to inter- - Nodes other than domain border nodes SHOULD NOT modify the contents
domain TE LSPs which implement [RSVP-GMPLS]. However, since PathErr of a PathErr message
and Notify need not follow the same path, their recepient nodes could - Domain border nodes SHOULD NOT modify the contents of a PathErr
be different. This has certain implications on crankback re-routing. message unless domain confidentiality is a specific requirement.
Procedures and recommendations in [CRANKBACK] should be followed for
Notify message processing for crankback re-routing.
3.3. RRO processing across domains 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].
[RSVP-TE] defines the RECORD_ROUTE object (RRO) as an optional Crankback rerouting MAY also be used to handle the failure of LSPs
object, which is primarily used for loop detection and for providing after they have been established [CRANKBACK].
information about the hops traversed by LSPs. [FAST-REROUTE] also
uses the RRO to record labels and determine MP. The address or ID
recorded in the RRO usually represents a link/interface. This
information by itself may not be useful enough when LSPs traverse
domains. [NODE-ID] defines extensions which allows a node to record
its node ID in the RRO, to provide an additional context for the link
address/ID.
Note that there may also be cases while traversing administrative 3.3. RRO Processing Across Domains
domain boundaries, where a network may not wish to expose its
internal addresses/IDs to preserve confidentiality. In such cases RRO
MAY be subjected to policies, filtering and modifications at domain
boundaries. Internal network element identities may be masked off and
replaced with boundary information or AS information, by domain
boundary entities. This is not expected to hamper the working of the
signaling protocol. This does, however, result in information loss,
thereby leading to inefficient paths or procedures that depend on RRO
information.
4. RSVP-TE signaling extensions [RFC3209] defines the RRO as an optional used for loop detection and
for providing information about the hops traversed by LSPs.
The following RSVP-TE signaling extensions are introduced in this As described for overlay networks in [RFC4208], a domain border node
document. 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
the domain identifier (such as the AS number) or be removed entirely
leaving just the domain border nodes.
4.1. Control of downstream choice of signaling method Note that a domain border router MUST NOT mask its own presence, and
MUST include itself in the RRO.
In certain mixed environments with different techniques (contiguous, Such filtering of RRO information does not hamper the working of the
stitched or nested TE LSPs), a head-end node of the inter-domain TE signaling protocol, but the subsequent information loss may render
LSP may wish to signal its requirement regarding the signaling method management diagnostic procedures inoperable or at least make them
used at an intermediate node along the path. more complicated requiring the coordination of administrators of
multiple domains.
[LSP-ATTRIBUTES] defines the format of the Attributes Flags TLV Similarly protocol procedures that depend on the presence of RRO
included in the LSP_ATTRIBUTES object carried in an RSVP Path information may become inefficient. For example, the fast reroute
message. The following bit in the Flags TLV is used by the head-end procedures defined in [RFC4090] use information in the RRO to
node of the inter-domain TE LSP to restrict the signaling method used determine the labels to use and the downstream MP.
by the intermediate nodes to be contiguous.
Bit Number 4 (TBD): Contiguous LSP bit - this flag is set by the 3.4. Notify Message Processing
head-end node that originates the inter-domain TE LSP if it desires a
contiguous end-to-end TE LSP (in the control & data plane). When set,
this indicates that an intermediate node MUST NOT perform any
stitching or nesting on the TE LSP and the TE LSP MUST be routed as
any other TE LSP (it must be contiguous end to end). When this bit is
cleared, an intermediate node MAY decide to perform stitching or
nesting. This bit MUST NOT be modified by any downstream node.
An intermdediate node that supports the LSP_ATTRIBUTES object and the 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.
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, Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit,
but cannot support contiguous TE LSP MUST send a Path Error message but cannot support contiguous TE LSPs, MUST send a Path Error message
upstream with an error code=24 ("Routing Problem") and error sub- with an error code "Routing Problem"/"Contiguous LSP type not
code="Contiguous LSP type not supported" (TBD). 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 and MUST set the LSP behavior, then it MUST signal a contiguous LSP. If the node is a
"Contiguous LSP signaled" bit in the Flags field of the RRO domain border node, or if the node expands a loose hop in the ERO, it
Attributes subobject in the corresponding Resv message. 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 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
as well, but does not recognize this particular bit, then it SHOULD but does not recognize this "Contiguous LSP" bit, then it MUST reject
simply ignore the above request. It MAY signal any type of LSP in the Path message with a PathErr message as described in [RFC4420].
this case. The "Contiguous LSP signaled" bit in the Flags field of
the RRO Attributes SHOULD NOT be set.
An ingress node for an inter-domain LSP requesting a contiguous LSP The choice of action by an ingress node that receives a PathErr when
SHOULD examine the RRO Attributes subobject Flags to determine if the requesting the use of a contiguous LSP is out of the scope of this
LSP was indeed signaled contiguous end to end. If the "Contiguous LSP document, but may include the computation of an alternate path.
signaled" bit is cleared, the head end may take appropriate actions
such as restricting the type of traffic that gets mapped to this LSP,
tearing down the LSP, or rerouting the LSP around the nodes that do
not support the contiguous signaling; etc. Choice of action to be
taken is upto the implementation on the ingress node and it is out of
the scope of this document to recommend any particular action.
5. Protection and recovery of inter-domain TE LSPs 5. Protection and Recovery of Inter-Domain TE LSPs
The procedures described in Section 3 MUST be applied to all inter- The procedures described in Sections 3 and 4 MUST be applied to all
domain TE LSPs, including bypass tunnels, detour LSPs [FAST-REROUTE] inter-domain TE LSPs, including bypass tunnels, detour LSPs
or segment recovery LSPs [SEGMENT-PROTECTION] that may cross domains. [RFC4090], and segment recovery LSPs [SEGMENT-PROTECTION]. This means
This means that these LSPs will also be subjected to ERO processing, that these LSPs will also be subjected to ERO processing, policies,
policies, path computation; etc. Also, note that the explicit route path computation, etc.
for these backup LSPs needs to be either configured or computed at
the PLR. Just like any inter-domain TE LSP, depending on the
visibility into the subsequent domain, the ERO may comprise of strict
and/or loose hops. So, if there are loose hops, backup LSPs would
also need to undergo loose hop expansion at nodes other than the PLR.
So, the PLR in this case needs to signal the node or link that needs
to be excluded for backup computation to other downstream nodes along
the backup path. It is also possible that some protection schemes
already signal this information in the DETOUR object([FAST-REROUTE]).
However, the mechanisms for signaling this are out of scope of this
document. [EXCLUDE-ROUTE] discusses one such solution to achieve
this.
5.1. Fast Recovery support using MPLS TE Fast Reroute (FRR) 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
TE visibility of the computation point into the subsequent domain.
[FAST-REROUTE] describes two methods for local protection for a If loose hops are required created in the path of the backup LSP, ERO
packet TE LSP in case of link, SRLG or node failure. This section 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 describes how these mechanisms work with the proposed signaling
solutions for inter-domain TE LSP setup. solutions for inter-domain TE LSP setup.
5.1.1. Failure within a domain (link or node failure) 5.1.1. Failure Within a Domain (Link or Node Failure)
The mode of operation of MPLS TE Fast Reroute to protect a The mode of operation of MPLS-TE Fast Reroute to protect a
contiguous, stitched or nested TE LSP within a domain is identical to contiguous, stitched or nested TE LSP within a domain is identical to
the existing procedures described in [FAST-REROUTE]. In case of the existing procedures described in [RFC4090]. Note that, in the
nested or stitched inter-domain TE LSPs, protecting the intra-domain case of nesting or stitching, the end-to-end LSP is automatically
TE H-LSP or LSP segment will automatically protect the traffic on the protected by the protection operation performed on the H-LSP or
inter-domain TE LSP. No new extensions are required for any of the stitching segment LSP.
signaling methods.
5.1.2. Failure of link at domain boundaries No protocol extensions are required.
The procedures for doing link protection of the link at domain 5.1.2. Failure of a Link at a Domain Borders
boundaries is the same for contiguous, nested and stitched TE LSPs.
To protect an inter-domain link with MPLS TE Fast Reroute, a set of 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 backup tunnels must be configured or dynamically computed between the
two domain boundary nodes diversely routed from the protected inter- PLR and MP such that they are diversely routed from the protected
domain link. The region connecting two domains may not be TE enabled. inter-domain link and the protected inter-domain LSPs.
In this case, an implementation will have to support the set up of TE
LSP over a non-TE enabled region.
For each protected inter-domain TE LSP traversing the protected link, Each protected inter-domain LSP using the protected inter-domain TE
a NHOP backup must be selected by a PLR (i.e domain exit boundary link must be assigned to an NHOP bypass tunnel that is diverse from
router), when the TE LSP is first set up. This requires for the PLR the protected LSP. Such an NHOP bypass tunnel can be selected by
to select a bypass tunnel terminating at the NHOP. Finding the NHOP analyzing the RROs in the Resv messages of the available bypass
bypass tunnel of an inter-AS LSP can be achieved by analyzing the tunnels and the protected TE LSP. It may be helpful to this process
content of the RRO object received in the RSVP Resv message of both if the extensions defined in [NODE-ID] are used to clearly
the bypass tunnel and the protected TE LSP(s). As defined in [RSVP- distinguish nodes and links in the RROs.
TE], the addresses specified in the RRO IPv4 subobjects can be node-
ids and/or interface addresses (with specific recommendation to use
the interface address of the outgoing Path messages). The PLR may or
may not have sufficient topology information to find where the backup
tunnel intersects the protected TE LSP based on the RRO. [NODE-ID]
proposes a solution to this issue, defining an additional RRO IPv4
suboject that specifies a node-id address.
5.1.3. Failure of a boundary node 5.1.3. Failure of a Border Node
For each protected inter-domain TE LSP traversing the boundary node Two border node failure cases exist. If the domain border falls on a
to be protected, a NNHOP backup must be selected by the PLR. This link as described in the previous section, the border node at either
requires the PLR to setup a bypass tunnel terminating at the NNHOP. end of the link may fail. Alternatively, if the border falls on a
Finding the NNHOP bypass tunnel of an inter-domain TE LSP can be border node (as is the case with IGP areas) that single border node
achieved by analyzing the content of the RRO object received in the may fail.
RSVP Resv message of both the bypass tunnel and the protected TE
LSP(s) (see [NODE-ID]). The main difference with node protection,
between a protected contiguous inter-domain TE LSP and a protected
nested or stitched inter-domain TE LSP is that the PLR and NNHOP (MP)
in case of a contiguous TE-LSP could be any node within the domain.
However, in case of a nested or stitched TE-LSP the PLR and MP can
only be the end-points of the H-LSP or LSP segment. The consequence
is that the backup path is likely to be longer and if bandwidth
protection is desired, for instance, ([FAST-REROUTE]) more resources
may be reserved in the domain than necessary. Note, however, that
even for a contiguous LSP, there may be cases where the addresses
within the domain could have been masked in the RRO for
confidentiality reasons, in which case, the RRO for the contiguous
LSP may only contain boundary nodes, and so the MP can only be a
boundary node.
Also, while a contiguous LSP does allow backup LSPs to terminate It can be seen that if stitching or nesting are used, the failed node
inside the domain, there could be policies which may reject an LSP will be the start or end (or both) or a stitching segment LSP or
that originates in another domain from carrying addresses in ERO that H-LSP in which case, protection must be provided to the far end of
are local to this domain. In these cases, the backup LSP cannot stitching segment or H-LSP. Thus, where one of these two techniques
terminate inside the domain and must terminate only at the boundary is in use, the PLR will be the upstream domain entry point in the
node. 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.
In case of stitching or nesting, when the node to be protected is the If the contiguous LSP mechanism is in use, normal selection of the
H-LSP/S-LSP tail-end node, the PLR is not immediately upstream of PLR and MP can be applied and any node within the domains may be used
this node. Hence, the failure detection time on failure of H-LSP/S- to fill these roles.
LSP tail-end node is bound to be longer than that in the case where
PLR is immediately upstream of the node to be protected. In such
cases, it is RECOMMENDED that the PLR rely on methods proposed in
[BFD-MPLS] to rapidly detect H-LSP/S-LSP tail-end node failure. This
would help in fast recovery.
5.2. Protection and recovery of GMPLS LSPs 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 [SEGMENT-PROTECTION] describes GMPLS based segment recovery. This
allows protection against a span failure, a node failure, or failure allows protection against a span failure, a node failure, or failure
over any particular portion of a network used by an LSP. The over any particular portion of a network used by an LSP.
scenarios described above for MPLS Fast reroute also apply to segment
protection. No new extensions are needed for segment protection of
LSPs that span multiple domains. However, in the inter-domain LSP
case, it may not always be possible for the upstream node (outside a
domain) to identify end-points of segment recovery LSP in another
domain. Even if this was somehow determined, SERO and SRRO in the
recovery LSP MUST be subjected to ERO and RRO processing rules as
described above, so policy could disallow explicit control of LSP
segment recovery inside the domain by a node outside the domain.
This is treated as a Segment Protection failure and error handling as
described in Section 4.2.1 of [SEGMENT-PROTECTION].
6. Re-optimization of inter-domain TE LSPs 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
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 Re-optimization of a TE LSP is the process of moving the LSP from the
current path to a more prefered path. This usually involves current path to a preferable path. This involves the determination of
computation of the new prefered path and make-before-break signaling the preferred path and make-before-break signaling procedures
procedures [RSVP-TE], to minimize traffic disruption. The path [RFC3209] to minimize traffic disruption.
computation procedures involved in re-optimization of an inter-domain
TE LSP are covered in [INTER-DOMAIN-PD-PATH-COMP]. Another option is
to use PCE-based mechanisms ([PCE]) for re-optimization.
In the context of an inter-domain TE LSP, since the LSP traverses Re-optimization of an inter-domain TE LSP may require a new path in
multiple domains, re-optimization may be required in one or more more than one domain.
domains at a time. Again, depending on the nature of the LSP and/or
policies and configuration at domain boundaries (or other nodes), one
may either always want the head-end node of the inter-domain TE LSP
to be notified of any local need for re-optimizations and let the
head-end initiate the make-before-break process or one may want to
restrict local re-optimizations with the domain.
[LOOSE-REOPT] describes mechanisms that allow, 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.
o The head-end node to trigger on every node whose next hop is In all cases, however, the ingress LSP may wish to exert control and
a loose hop the re-evaluation of the current path in order to coordination over the re-optimization process.
detect a potentially more optimal path. This is done via
explicit signaling request: the head-end node sets the
"ERO Expansion request" bit of the SESSION-ATTRIBUTE object
carried in the RSVP Path message.
o A node whose next hop is a loose-hop to signal to the head-end [LOOSE-REOPT] describes mechanisms that allow:
node that a better path exists. This is performed by sending an
RSVP PathErr Notify message (error-code = 25), sub-code=6 (Better
path exists). This indication may either be sent in response to
a query sent by the head-end node or spontaneously by any node
having detected a more optimal path.
The above mechanisms SHOULD be used for a contiguous inter-domain TE - The ingress node to request each node with a loose next hop to
LSP to allow the head-end node of the inter-domain TE LSP to initiate re-evaluate the current path in order search for a more optimal
make-before-break procedures. For nested or stitched TE LSPs, it is path.
possible to re-optimize the local H-LSP or LSP segment without
involving the head-end node of the inter-domain TE LSP. This will - A node with a loose next hop to inform the ingress node that a
automatically re-route the traffic for the inter-domain TE LSP along better path exists.
the new path, within the domain. Such local re-optimizations,
including parameters for re-optimization can be controlled by local These mechanisms SHOULD be used for re-optimization of a contiguous
policy or configuration in that domain. inter-domain TE LSP.
7. Security Considerations 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 When signaling an inter-domain RSVP-TE LSP, an operator may make use
of the already defined security features related to RSVP-TE of the security features already defined for RSVP-TE [RFC3209]. This
(authentication). This may require some coordination between the may require some coordination between the domains to share the keys
domains to share the keys (see RFC 2747 and RFC 3097). Note that this (see [RFC2747] and [RFC3097]), and care is required to ensure that
may involve additional synchronization, should the domain boundary the keys are changed sufficiently frequently. Note that this may
LSR be protected with MPLS TE Fast Reroute, since the merge point involve additional synchronization, should the domain border nodes
should also share the key. 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 For an inter-domain TE LSP, especially when it traverses different
administrative or trust domains, the following mechanisms (also see administrative or trust domains, the following mechanisms SHOULD be
[INTER-AS-TE-REQS]) SHOULD be provided to an operator :- provided to an operator (also see [RFC4216]):
1) a way to enforce policies and filters at the domain boundaries 1) A way to enforce policies and filters at the domain borders
to process the incoming inter-domain TE LSP setup requests to process the incoming inter-domain TE LSP setup requests
(Path messages) based on certain agreed trust and service (Path messages) based on certain agreed trust and service
levels/contracts between domains. Various LSP attributes levels/contracts between domains. Various LSP attributes
such as bandwidth, priority; etc could be part of such a such as bandwidth, priority, etc. could be part of such a
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 boundary LSR, 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:- Some examples of the policies described above are:-
1) 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 boundary LSR to disallow or ignore hops policy on the domain border node to disallow or ignore hops
within the domain being identified in the ERO of an incoming within the domain from being identified in the ERO of an
Path message. incoming Path message.
2) In order to preserve confidentiality, an operator may choose B) In order to preserve confidentiality of network topology, an
to disallow recording of hops within the domain in the RRO or operator may choose to disallow recording of hops within the
may choose to filter out certain recorded RRO addresses at the domain in the RRO or may choose to filter out certain recorded
domain boundary LSR. RRO addresses at the domain border node.
3) An operator may require the boundary LSR 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 mechanisms (local Note that the detailed specification of such policies and their
implementation) is outside the scope of this document. implementation are outside the scope of this document.
8. IANA Considerations 8. IANA Considerations
The following values have to be defined by IANA for this document. IANA is requested to make the codepoint allocations described in the
The registry is, http://www.iana.org/assignments/rsvp-parameters. following sections.
8.1. Attribute Flags for LSP_ATTRIBUTES object
The following new flag bit is being defined for the Attributes Flags 8.1. Attribute Flags for LSP_Attributes Object
TLV in the LSP_ATTRIBUTES object. The numeric value should be
assigned by IANA.
Contiguous LSP bit - Bit Number 4 (Suggested value) A new bit is to be allocated from the "Attributes Flags" sub-registry
of the "RSVP TE Parameters" registry.
This flag bit is only to be used in the Attributes Flags TLV on a Path Resv RRO
Path message. Bit Name message message sub-object
---- ------------------------------- -------- -------- ----------
XX Contiguous LSP Yes No Yes
The "Contiguous LSP" bit has a corresponding "Contiguous LSP The value XX is to be defined by IANA. A value of 4 is suggested.
signaled" bit (Bit Number 4) to be used in the RRO Attributes sub-
object.
8.2. New Error Codes 8.2. New Error Codes
The following new error sub-codes are being defined under the RSVP New RSVP error codes/values are required to be allocated from the
error-code "Routing Problem" (24). The numeric error sub-code value "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry
should be assigned by IANA. Suggested values are, of the "RSVP Parameters" registry.
1. Contiguous LSP type not supported - sub-code 21
2. ERO conflicts with inter-domain signaling method - sub-code 22
These error codes are to be used only in a RSVP PathErr. 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.
The following new error sub-codes are being defined under the RSVP 103 = Inter-domain policy failure
error-code "Policy control failure" (2). The numeric error sub-code 104 = Inter-domain explicit route rejected
value should be assigned by IANA. Suggested values are,
1. Inter-domain policy failure - sub-code 102 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.
2. Inter-domain explicit route rejected - sub-code 103 21 = Contiguous LSP type not supported
22 = ERO conflicts with inter-domain signaling method
9. Acknowledgements 9. Acknowledgements
The authors would like to acknowledge the input and helpful comments The authors would like to acknowledge the input and helpful comments
from Adrian Farrel on various aspects discussed in the document. from Kireeti Kompella on various aspects discussed in the document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Extensions to OSPF", RFC 3630 (Updates RFC 2370), September 2003. Requirement Levels", BCP 14, RFC 2119, March 1997.
[ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic
Engineering", RFC 3784
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC [RFC3209] Awduche, D., et al, "Extensions to RSVP for LSP Tunnels",
3209, December 2001. RFC 3209, December 2001.
[RSVP-GMPLS] L. Berger, et al, "Generalized Multi-Protocol Label [RFC3473] Berger, L., et al, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Switching (GMPLS) Signaling Resource ReserVation Protocol -
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[LSP-HIERARCHY] Kompella K., Rekhter Y., "LSP Hierarchy with [RFC4206] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized
Generalized MPLS TE", RFC 4206, October 2005. MPLS TE", RFC 4206, October 2005.
[LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with [RFC4420] Farrel, A., et al, "Encoding of Attributes for
Generalized MPLS TE", (work in progress). Multiprotocol Label Switching (MPLS) Label Switched Path
(LSP) Establishment Using RSVP-TE", RFC 4420, February
2006.
[CRANKBACK] Farrel A. et al, "Crankback Signaling Extensions for MPLS [LOOSE-REOPT] Vasseur, JP., et al, "Reoptimization of Multiprotocol
Signaling", (work in progress). Label Switching (MPLS) Traffic Engineering (TE) loosely
routed Label Switch Path (LSP)",
draft-ietf-ccamp-loose-path-reopt, (work in progress).
[LSP-ATTRIBUTES] Farrel A. et al, "Encoding of Attributes for [LSP-STITCHING] Ayyangar, A., Kompella, K., and Vasseur, JP., "Label
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Switched Path Stitching with Generalized MPLS Traffic
Establishment Using RSVP-TE", RFC 4420, February 2006. Engineering", draft-ietf-ccamp-lsp-stitching, (work in
progress).
10.2. Informative References 10.2. Informative References
[INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering [RFC2747] Baker, F., Lindell, B., and Talwar, B., "RSVP Cryptographic
requirements", RFC 4216, November 2005. Authentication", RFC 2747, January 2000.
[INTER-AREA-TE-REQS] LeRoux JL, Vasseur JP, Boyle J. et al,
"Requirements for support of Inter-Area MPLS Traffic Engineering",
RFC 4105, June 2005.
[INTER-DOMAIN-FRAMEWORK] Farrel A. et al, "A Framework for Inter-
Domain MPLS Traffic Engineering", (work in progress).
[INTER-DOMAIN-PD-PATH-COMP] Vasseur JP., Ayyangar A., Zhang R., "A
Per-domain path computation method for computing Inter-domain Traffic
Engineering Label Switched Path", (work in progress).
[PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation
Element (PCE) Architecture", draft-ietf-pce-architecture, work in
progress.
[GMPLS-OVERLAY] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the [RFC3097] Braden, R., and Zhang, L., "RSVP Cryptographic
Overlay Model", RFC 4208, October 2005. Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[FAST-REROUTE] 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.
[NODE-ID] Vasseur, Ali and Sivabalan, "Definition of an RRO node-id [RFC4105] LeRoux, JL., Vasseur, JP., Boyle, J., et al, "Requirements
subobject", (work in progress). for Inter-Area MPLS Traffic Engineering", RFC 4105, June
2005.
[SEGMENT-PROTECTION] L. Berger et al, "GMPLS Based Segment Recovery",
(work in progress).
[BFD-MPLS] R. Aggarwal et al, "BFD For MPLS LSPs", (work in
progress).
[LOOSE-REOPT] Vasseur JP. et al, "Reoptimization of an explicit
loosely routed MPLS TE paths", (work in progress).
Appendix 1: Examples
This Appendix provides some examples to illustrate the inter-domain
signaling procedures described in this document. We consider one
example topology which covers inter-domain TE LSP signaling across
Autonomous systems. Inter-domain TE LSP signaling across other
domains covered by this document are also meant to follow similar
signaling procedures, but are not covered here.
<-- AS-1 ---> <--- AS-2 ---> <-- AS-3 -->
<---BGP---> <---BGP-->
CE1---R0----X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
| | | | / | / | / | | |
| | +-ASBR2----/ ASBR5 | / | | |
| | | | | / | | |
R1--R2----ASBR3------ASBR6--R4---ASBR8----ASBR10----R7---CE2
<================ Inter-AS TE LSP ================>
1.1 Assumptions
- Three interconnected ASes, respectively AS-1, AS-2, and AS-3.
Note that AS3 might be AS1 in some scenarios described in
[INTER-AS-TE-REQS].
- The various ASBRs are BGP peers, without any IGP running on the
single hop link interconnecting the ASBRs
- Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE
extensions (see [OSPF-TE] and [ISIS-TE]). In other words, the ASes
are TE enabled. Note that each AS can run a different IGP.
- Each AS can be made of several areas. In this case, the TE LSP will
rely on the inter-area TE techniques to compute and set up a TE LSP
traversing multiple IGP areas. For the sake of simplicity, each
routing domain will be considered as single area in this document,
but the solutions described in this document does not prevent the
use of multi-area techniques. In fact, these inter-domain solutions
are equally applicable to inter-area TE.
- An inter-AS TE LSP T1 originated at R0 in AS1 and terminating
at R7 in AS3 with following possible explicit paths:
o p1 - path defined by ERO with a set of loose node hops crossing
AS-2, ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R7(loose)
o p2 - path defined by ERO containing a set of strict interface hops
crossing AS-2,
ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict)
-link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R7(loose)
o p3 - path defined by ERO containing a set of AS number hops
crossing AS-2,
ASBR1(loose)-link[ASBR1-ASBR4](strict)-AS3(loose)-R7(loose)
- The explicit paths (EROs) may have been configured and/or computed
at the head-end node using any of the path computation schemes.
1.2 ERO processing
Let us consider an inter-AS TE LSP setup from R0 to R7, with example
paths p1, p2. In this example, we will examine the behavior on node
ASBR4 which is the boundary node for AS-2, for the different
signaling methods.
Contiguous:-
The head-end node, R0, that desires to setup an end-to-end contiguous
TE LSP, MAY originate a Path message with LSP_ATTRIBUTES object with
the "Contiguous LSP" bit set in the Attributes Flags TLV.
For path p1, additional computation to expand the loose hops may be
required at various hops along the LSP path. When the Path message
arrives at ASBR4, it may carry out a path computation or use some
other means to find the intermediate hops to reach ASBR7. It may then
adjust the outgoing ERO and forward the Path message through the
intermediate hops in AS-2 to ASBR7.
For path p2, the ERO next hop points to a node within the domain.
ASBR4 will then directly forward the Path message to the next hop in
the ERO.
For path p3, the ERO nexthop is a loose hop pointing to the
subsequent AS number. In this case, ASBR4 will perform path
computation to determine the intermediate hops to reach AS-3. It may
adjust the ERO based on the computation results. In this case either
ASBR7 or ASBR8 may be chosen as the exit points from AS-2.
Similarly, either ASBR9 or ASBR10 may be chosen as entry points into
AS-3.
Nesting and Stitching:-
When the Path message for the inter-AS TE LSP from R0 to R7, reaches
ASBR4, ASBR4 SHOULD first determine from the ERO hops, the boundary
node to the domain along the path. In this example, the domain
boundary node for all paths is ASBR7. It SHOULD then use the ERO hops
up to ASBR7 to find an existing H-LSP in case of nesting or LSP
segment in case of stitching, that satisfies the TE constraints. If
there are no existing H-LSPs or LSP segments and ASBR4 is capable of
setting up the H-LSP or LSP segment on demand, it SHOULD do so using
the ERO hops in the Path message of the inter-domain TE LSP. In
either case, ASBR4 will adjust the ERO in the inter-domain TE LSP and
will forward the Path message directly to the end-point of the H-LSP
or LSP segment using the procedures described in [LSP-HIERARCHY].
In case of path p1, since there are no ERO hops between ASBR4 and
ASBR7, and ASBR7 hop is loose, ASBR4 may select any existing H-LSP
(nesting) or LSP segment (stitching) that satisfies the constraints
or it may compute a path for the H-LSP or LSP segment up to ASBR7 or
some other intermediate node in AS-2.
In case of path p2, ASBR4 may either select an existing H-LSP or LSP
segment with ERO hops link[ASBR4-R3](strict)-link[R3-ASBR7](strict)
or it may compute a new path for the H-LSP or LSP segment using the
above hops. In either case, the ERO hops for the H-LSP or LSP segment
MUST be the same as the signaled strict hops in that domain.
Processing of path p3 is similar to p1 except that exit points from
AS-2 and entry points into AS-3 are determined as part of path
computation.
Now, suppose, we have a path p4, defined by an ERO comprising a set
of strict node hops crossing AS-2 as shown below,
ASBR1(loose)-ASBR4(loose)-ASBR7(strict)-ASBR9(loose)-R7(loose)
In this case, the ERO nexthop at ASBR4 is ASBR7(strict). In this
case, ASBR4 will try to find or compute a H-LSP or LSP segment
directly to ASBR7.
The main difference between processing of p1 and p4 for nesting or
stitching is that in case of p1, since the ERO nexthop is a loose
hop, ASBR4 need not find a H-LSP or LSP segment directly from ASBR4
to ASBR7. So, there could be multiple H-LSPs or LSP segments between
ASBR4 and ASBR7 terminating and originating on other nodes. On the
other hand, for path p4, since the ERO hop to ASBR7 is a strict hop,
ASBR4 MUST find or signal a H-LSP or LSP segment that directly
connects ASBR4 and ASBR7.
1.3 Examples of local protection with MPLS FRR -
Let us again consider the example topology above and assume that the
TE LSP is now protected. Let us consider the following backup tunnels
in the above example,
o B1 from ASBR1 to ASBR4 following the path
link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR4](strict) and
protecting against a failure of the ASBR1-ASBR4 link
o B2 from ASBR1 to R3 following the path defined by ERO,
link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR3](strict)-
link[ASBR3-ASBR6](strict)-link[ASBR6-ASBR5](strict)-R3(strict)
and protecting against a failure of the ASBR4 node.
o B3 from ASBR1 to ASBR7 following the path defined by ERO,
link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR3](strict)-
link[ASBR3-ASBR6](strict)-ASBR7(loose) and protecting against
a failure of the ASBR4 node. In this case B3 will need additional
path computation (loose hop expansion) on ASBR6.
o B4 from R3 to ASBR9 following the path defined by ERO, [RFC4208] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the
link[R3-R4](strict)-link[R4-ASBR8](strict)-ASBR9(loose) and Overlay Model", RFC 4208, October 2005.
protecting against a failure of the ASBR7 node. B4 may involve
loose hop expansion on ASBR8.
o B5 from ASBR4 to ASBR9 following the path defined by ERO, [RFC4216] Zhang, R., et al, "MPLS Inter-Autonomous System (AS)
ASBR4-ASBR8(loose)-ASBR9(loose) and protecting against a Traffic Engineering (TE) Requirements", RFC 4216, November
failure of the ASBR7 node. B5 may involve loose hop expansion 2005.
on ASBR8.
Note that in addition to the ERO for backup tunnels, additional [RFC4655] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation
information regarding node/link to exclude may need to be signaled as Element (PCE)-Based Architecture", RFC 4655, August 2006.
well if backup tunnel setup involves path computation at nodes other
than PLR (say for loose hop expansion).
The protected inter-domain TE LSP is an inter-AS TE LSP from R0 to R7 [BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs",
with path p1. Also, for nesting or stitching, let us assume that the draft-ietf-bfd-mpls, (work in progress).
end-points of the H-LSP or LSP segment in AS-2 are ASBR4 and ASBR7.
This gives rise to the following two scenarios for node protection:
Protecting the boundary node at the entry to a domain :- [CRANKBACK] Farrel, A., et al, "Crankback Signaling Extensions for
MPLS and GMPLS RSVP-TE", draft-ietf-ccamp-crankback, (work
in progress).
Example: protecting against the failure of ASBR4 [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).
If the inter-AS TE LSP in this example, is a contiguous LSP, then the [INTER-DOMAIN-FRAMEWORK] Farrel, A., et al, "A Framework for
PLR is ASBR1 and the NNHOP (MP) could be R3 or any other intermediate Inter-Domain MPLS Traffic Engineering",
node along the LSP path, if this information can be gleaned from the draft-ietf-ccamp-inter-domain-framework, (work in
RRO. A backup tunnel B2 may be used to protect the inter-AS TE LSP progress).
against failure of ASBR4. However, as explained in Section 5.1.3 if
RRO information related to R3 has been masked off or if there are
restrictions on terminating the backup tunnel inside AS-2, then B2
cannot be used. In this case B3 may be used to protect the LSP
against failure of ASBR4.
If the inter-AS TE LSP in this example, is nested or stitched at [INTER-DOMAIN-PD-PATH-COMP] Vasseur, JP., Ayyangar, A., and
ASBR4 into an intra-domain TE H-LSP or LSP segment between ASBR4 and Zhang, R., "A Per-domain path computation method for
ASBR7, then the PLR is ASBR1 and the NNHOP (MP) is ASBR7. A backup computing Inter-domain Traffic Engineering (TE) Label
tunnel B3 may be used to protect the inter-AS TE LSP against failure Switched Paths (LSPs)",
of ASBR4. draft-ietf-ccamp-inter-domain-pd-path-comp, (work in
progress).
Protecting the boundary node at the exit of a domain :- [NODE-ID] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of an
RRO node-id subobject", draft-ietf-mpls-nodeid-subobject,
(work in progress).
Example: protecting against failure of ASBR7. [SEGMENT-PROTECTION] Berger, L., et al, "GMPLS Based Segment
Recovery", draft-ietf-ccamp-gmpls-segment-recovery, (work
in progress).
If the inter-AS TE LSP in this example, is a contiguous LSP, then the 11. Authors' Addresses
PLR could be R3 and the NNHOP (MP) is ASBR9. A backup tunnel B4 may
be used to protect the inter-AS TE LSP against failure of ASBR7.
If the inter-AS TE LSP in this example, is nested or stitched at Adrian Farrel
ASBR4 into an intra-domain TE H-LSP or LSP segment between ASBR4 and Old Dog Consulting
ASBR7, then the PLR is ASBR4 and the NNHOP (MP) is ASBR9. A backup
tunnel B5 may be used to protect the inter-AS TE LSP against failure
of ASBR7.
Author's addresses E-mail: adrian@olddog.co.uk
Arthi Ayyangar Arthi Ayyangar
Juniper Networks, Inc. Nuova Systems
1194 N.Mathilda Ave 2600 San Tomas Expressway
Sunnyvale, CA 94089 Santa Clara, CA 95051
USA US
e-mail: arthi@juniper.net
Email: arthi@nuovasystems.com
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
e-mail: jpv@cisco.com
Email: jpv@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 23, line 33 skipping to change at page 18, line 40
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the This document is subject to the rights, licenses and restrictions
Internet Society. contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
 End of changes. 147 change blocks. 
778 lines changed or deleted 613 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/