draft-ietf-ccamp-inter-domain-rsvp-te-01.txt   draft-ietf-ccamp-inter-domain-rsvp-te-02.txt 
IETF Internet Draft Arthi Ayyangar(Editor) IETF Internet Draft Arthi Ayyangar(Editor)
Proposed Status: Standards Track Juniper Networks Proposed Status: Standards Track Juniper Networks
Expires: January 2006 Expires: April 2006
Jean-Philippe Vasseur(Editor) Jean-Philippe Vasseur(Editor)
Cisco Systems, Inc. Cisco Systems, Inc.
July 2005 October 2005
Inter domain GMPLS Traffic Engineering - RSVP-TE extensions Inter domain GMPLS Traffic Engineering - RSVP-TE extensions
draft-ietf-ccamp-inter-domain-rsvp-te-01.txt draft-ietf-ccamp-inter-domain-rsvp-te-02.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 38 skipping to change at page 1, line 38
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 January 18, 2006. This Internet-Draft will expire on April 3, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document describes extensions to Generalized Multi-Protocol Label This document describes extensions to Generalized Multi-Protocol Label
Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering
(RSVP-TE) signaling required to support mechanisms for the establishment (RSVP-TE) signaling required to support mechanisms for the establishment
and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths
(LSPs), both packet and non-packet, that traverse multiple domains. For (LSPs), both packet and non-packet, that traverse multiple domains. 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 or collection of network elements within a common realm of address space or
path computation responsibility. Examples of such domains include path computation responsibility. Examples of such domains include
Autonomous Systems, IGP areas and GMPLS overlay networks. Autonomous Systems, IGP areas and GMPLS overlay networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 boundary node . . . . . . . . . . . . 5
3.1 Rules on ERO processing . . . . . . . . . . . . . . . . . 6
3.2 LSP setup failure and crankback . . . . . . . . . . . . . 8
3.3 RRO processing across domains . . . . . . . . . . . . . . 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 . . . . . . . 11
5.1 Fast Recovery support using MPLS TE Fast Reroute . . . . . 11
5.1.1 Failure within a domain (link or node failure) . . . . 11
5.1.2 Failure of link at domain boundaries . . . . . . . . . 11
5.1.3 Failure of a boundary node . . . . . . . . . . . . . . 12
5.2 Protection and recovery of GMPLS LSPs . . . . . . . . . . 13
6. Re-optimization of inter-domain TE LSPs . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1 Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 15
8.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1 Normative References . . . . . . . . . . . . . . . . . . 16
10.2 Informative References . . . . . . . . . . . . . . . . . 17
Appendix 1: Examples . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
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 MPLS Traffic Engineering
have been developed by the Traffic Engineering Working Group and have have been developed by the Traffic Engineering Working Group and have
been stated in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS] been stated in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS]
respectively. Many of these requirements also apply to GMPLS respectively. Many of these requirements also apply to GMPLS
networks. The framework for inter-domain GMPLS Traffic Engineering networks. The framework for inter-domain GMPLS Traffic Engineering
has been 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 the RSVP-TE signaling extensions for the setup
and maintenance of TE LSPs that span multiple domains. The signaling and maintenance of TE LSPs that span multiple domains. The signaling
procedures described in this document are applicable to both packet procedures described in this document are applicable to both MPLS
LSPs ([RSVP-TE]) and non-packet LSPs that use RSVP-TE GMPLS packet LSPs ([RSVP-TE]) and all LSPs that use RSVP-TE GMPLS
extensions as described in [RSVP-GMPLS]. Three different signaling extensions as described in [RSVP-GMPLS]. Three different signaling
methods along with the corresponding RSVP-TE extensions and methods along with the corresponding RSVP-TE extensions and
procedures are proposed in this document. procedures are proposed in this document.
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 ([GMPLS-
OVERLAY]). OVERLAY]).
skipping to change at page 2, line 50 skipping to change at page 3, line 44
1.2. Terminology 1.2. Terminology
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
FA: Forwarding Adjacency H-LSP: Hierarchical LSP
FA-LSP: Forwarding Adjacency LSP FA-LSP: Forwarding Adjacency LSP
LSP: MPLS Label Switched Path LSP: MPLS Label Switched Path
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.
skipping to change at page 3, line 29 skipping to change at page 4, line 23
Protected LSP: an LSP is said to be protected at a given hop if it 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 has one or multiple associated backup tunnels originating at that
hop. hop.
RRO - Record Route Object RRO - Record Route Object
TE: Traffic Engineering TE: Traffic Engineering
TE LSP: Traffic Engineering Label Switched Path TE LSP: Traffic Engineering Label Switched Path
TE-link: Traffic Engineering link TE link: Traffic Engineering link
TED: MPLS Traffic Engineering Database TED: MPLS Traffic Engineering Database
2. Signaling overview 2. Signaling overview
The RSVP-TE signaling of a TE LSP within a single domain is described The RSVP-TE signaling of a TE LSP within a single domain is described
in [RSVP-TE] and [RSVP-GMPLS]. This document focuses on the RSVP-TE in [RSVP-TE] and [RSVP-GMPLS]. This document focuses on the RSVP-TE
signaling extensions required for inter-domain TE LSP setup and signaling extensions required for inter-domain TE LSP setup and
maintenance. Any other extensions that may be needed for routing or maintenance. Any other extensions that may be needed for routing or
path computation are outside the scope of this document. path computation are outside the scope of this document.
skipping to change at page 4, line 6 skipping to change at page 4, line 47
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 - A contiguous TE LSP is a single end-to-end TE LSP that
is setup across multiple domains using RSVP-TE signaling procedures is setup across multiple domains using RSVP-TE signaling procedures
described in [RSVP-TE]and [RSVP-GMPLS]. No additional TE LSPs are described in [RSVP-TE]and [RSVP-GMPLS]. No additional TE LSPs are
required to signal a contiguous TE LSP and the same RSVP-TE required to signal a contiguous TE LSP and the same RSVP-TE
information for the TE LSP is maintained along the entire LSP path. information for the TE LSP is maintained along the entire LSP path.
Nesting - Nesting one or more TE LSPs into another TE LSP is Nesting - Nesting one or more TE LSPs into another TE LSP is
described in [LSP-HIERARCHY]. This technique can also be used to nest described in [LSP-HIERARCHY]. This technique can be used to nest one
one or more inter-domain TE LSPs into an intra-domain FA-LSP. While or more inter-domain TE LSPs into an intra-domain hierarchical LSP
similar to stitching in the control plane, in the data plane, nesting (H-LSP). Label stacking construct may be used to achieve nesting,
allows for one or more inter-domain LSPs to be transported over a when appropriate, say in packet networks. In the rest of this
single intra-domain FA-LSP using the label stacking construct. document, the term H-LSP is used to refer to an LSP that allows
nesting of other LSPs into it and that may or may not be advertised
as a TE link. Furthermore, an H-LSP may or may not be an FA-LSP [LSP-
HIERARCHY].
Stitching - The concept of LSP stitching as well as the required Stitching - The concept of LSP stitching as well as the required
signaling procedures are described in [LSP-STITCHING]. This technique signaling procedures is described in [LSP-STITCHING]. This technique
can be used to stitch an inter-domain TE LSP to an intra-domain LSP can be used to stitch an inter-domain TE LSP to an intra-domain LSP
segment. A inter-domain stitched TE LSP is a TE LSP made up of segment. A inter-domain stitched TE LSP is a TE LSP made up of
different TE LSP segments within each domain which are "stitched" different TE LSP segments within each domain which are "stitched"
together in the data plane so that an end-to-end LSP is achieved in together in the data plane so that an end-to-end LSP is achieved in
the data plane. In the control plane, however, the different LSP the data plane. In the control plane, however, the different LSP
segments are signaled as distinct RSVP sessions which are independent segments are signaled as distinct RSVP sessions which are independent
from the RSVP session for the inter-domain LSP. 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 On receipt of an LSP setup request 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 signaled TE LSP
characteristics or the local node configuration, when not explicitly characteristics from the head-end node or the local node
signaled. Also, the TE LSP segment or FA-LSP within the domain may configuration, when not explicitly signaled. Also, the TE LSP segment
either be pre-configured or signaled dynamically based on the arrival or H-LSP within the domain may either be pre-configured or signaled
of the inter-domain TE LSP setup request. dynamically based on the arrival of the inter-domain TE LSP setup
request.
3. Procedures on the domain boundary node 3. Procedures on the domain boundary node
Whether an inter-domain TE LSP is contiguous, nested or stitched is Whether an inter-domain TE LSP is contiguous, nested or stitched is
determined mostly by the signaling method supported by or configured determined mostly by the signaling method supported by or configured
on the intermediate nodes, usually the domain boundary nodes that the on the intermediate nodes, usually the domain boundary nodes that the
inter-domain TE LSP traverses through. It may also depend on certain inter-domain TE LSP traverses. It also depends on certain parameters
parameters signaled by the head-end node for the inter-domain TE LSP. 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 When a domain boundary 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 hop node, before it can forward the Path message to the next node along the
- apply any locally configured policies path:
- determine the signaling method to be used based on any desired
characteristics signaled by the head-end node of the inter-domain TE 1. Apply any locally configured policies. In case of a policy
LSP or if the signaling method is not explicitly signaled, then failure, the node SHOULD fail the setup of the LSP and
determine the signaling method based on local configuration and originate a PathErr with error code=2 ("Policy control
policies failure") and error sub-code="Inter-domain policy failure"
- depending on the signaling method, carry out any specific ERO (TBD).
procedures, as applicable, as described in the next section
- based on the signaling method to be used, determine the next 2. Determine the signaling method to be used. The head-end node
hop node to forward the RSVP Path message of the inter-domain TE LSP may have explicitly specified a
- in case of nesting or stitching, either find an existing intra- signaling method or if the signaling method is not explicitly
domain TE LSP to carry the inter-domain TE LSP or signal a new one, signaled, then the node MAY determine the signaling method
depending on local policy based on local configuration and policies. If the desired
- perform any path computations if required. The path computation signaling method signaled by the head-end cannot be supported
procedure itself is outside the scope of this document. One such path at this node for some reason, then a PathErr message as
computation optionis addressed in [INTER-DOMAIN-PD-PATH-COMP]. described in Section 4.1 MUST be generated.
Another option is to use PCE based path computation scheme
- in case of any failures (admission control, policy, signaling; 3. Carry out ERO procedures as described in the next section in
etc), originate corresponding error notifications addition to the procedures in [RSVP-TE] and [RSVP-GMPLS].
4. Perform any path computations as required (say for ERO
expansion). The path computation procedure itself is outside
the scope of this document. One such path computation option is
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
intra-domain TE LSP to carry the inter-domain TE LSP or
signal a new one, depending on local policy.
4b. In case of a path computation failure, a PathErr SHOULD be
generated as described in [INTER-DOMAIN-PD-PATH-COMP].
5. In case of any other RSVP signaling failures, procedures as
described in [RSVP-TE] and [RSVP-GMPLS] SHOULD be followed.
Follow procedures related to LSP setup failure and crankback
as described in Section 3.2, where applicable.
6. Carry out RRO procedures as described in Section 3.3, if
applicable.
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 boundary node receives in the Path message for
an inter-domain TE LSP will be dependent on several factors such as an inter-domain TE LSP will be dependent on several factors such as
the level of visibility that the head-end node of the inter-domain TE the level of visibility that the head-end node of the inter-domain TE
LSP has into other domains, the path computation techniques applied LSP has into other domains, the path computation techniques applied
at the head-end node, policy agreements between two domains; etc. at the head-end node, policy agreements between two domains; etc.
Eventually, when the ERO reaches a domain boundary node, the Eventually, when the ERO reaches a domain boundary node, the
following rules SHOULD be used for ERO processing and signaling. following rules SHOULD be used for ERO processing and signaling.
Within a domain, there may be no FA-LSPs or LSP segments. If they are Within a domain, there may be no H-LSPs or LSP segments. If they are
present, then they may originate and terminate on domain boundary present, then they may originate and terminate on domain boundary
nodes. There could also be FA-LSPs and LSP segments that may nodes. There could also be H-LSPs and LSP segments that may originate
originate and terminate at other nodes in the domain. In general, and terminate at other nodes in the domain. In general, these ERO
these ERO processing rules are also applicable to non-boundary nodes processing rules are also applicable to non-boundary nodes that may
that may participate in signaling the inter-domain TE LSP. participate in signaling the inter-domain TE LSP.
- If there are any policies related to ERO processing for
certain LSPs, they SHOULD be applied and corresponding actions should 1. If there are any policies related to ERO processing for the
be taken. E.g. if there exists a policy to reject LSP setup request LSP, they SHOULD be applied and corresponding actions should be
containing ERO with sub-objects identifying nodes within the domain, taken. E.g. there could exist a policy to reject inter-domain
then a PathErr with the appropriate error code should be sent back LSP setup request containing an ERO with subobjects identifying
- Section 8.2 of [LSP-HIERARCHY] describes how a node at the nodes within the domain. In case of inter-domain LSP setup
edge of a region (domain) processes the ERO in the incoming Path failures due to policy failures related to ERO processing, the
message and uses this ERO, to either find an existing FA-LSP or node SHOULD issue a PathErr with error code=2 ("Policy control
signal a new FA-LSP using the ERO hops. This also includes adjusting failure") and error sub-code="Inter-domain explicit route
the ERO before sending the Path message to the next hop node. These rejected" (TBD).
procedures SHOULD also be followed for nesting or stitching of inter-
domain TE LSPs to FA-LSPs or LSP segments respectively. While the 2. Section 8.2 of [LSP-HIERARCHY] describes how a node at the
domain boundaries are tied to link switching capabilities in [LSP- edge of a region (domain) processes the ERO in the incoming
HIERARCHY], these procedures are also applicable to other domain Path message and uses this ERO, to either find an existing H-LSP
boundary nodes in the context of this document. E.g. in case of a or signal a new H-LSP using the ERO hops. This also includes
path computation domain, you have reached the boundary when the ERO adjusting the ERO before sending the Path message to the next
hop is no longer reachable via the TE database (TED). hop node. These procedures SHOULD also be followed for nesting
- In case of any failure in processing the ERO hop(s), a Path or stitching of inter-domain TE LSPs to H-LSPs or LSP segments
Error message with appropriate error code ([RSVP-TE]) SHOULD be respectively. While the domain boundaries are tied to link
generated. 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
LSP segment within the domain, either numbered or unnumbered,
then a contiguous LSP MUST NOT be signaled. The node MUST either
nest or stitch the inter-domain TE LSP to the local H-LSP or LSP
segment. If, however, the head-end node for the inter-domain LSP
has requested that the inter-domain TE LSP be contiguous, then
this is a conflict and a PathErr with error code=24 ("Routing
Problem") and error sub-code="ERO conflicts with inter-domain
signaling method" (TBD) SHOULD be issued.
4. In the absence of any ERO subobjects, the LSP destination in
the SESSION object SHOULD be considered as the next loose hop.
A node may also receive an ERO with explicit IPv4, IPv6 or AS
number loose hops. In such cases, a path computation to expand
this loose hop SHOULD be carried out. Path computation as
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
PathErr message with appropriate error codes as described in
[RSVP-TE] or [RSVP-GMPLS] SHOULD be generated.
3.2. LSP setup failure and crankback 3.2. LSP setup failure and crankback
In case of any setup failures along the path due to policy or In case of any setup failures along the path due to policy or
admission control or other reasons, a corresponding Path Error SHOULD admission control or other reasons, a corresponding
be generated and sent upstream. The propagation of Path Error PathErr/ResvErr/Notify is generated and sent upstream and/or
upstream may be limited to within the domain or it may be sent all downstream. An ERROR_SPEC comprises of information regarding the
the way upstream to the head-end node of the inter-domain TE LSP. point of failure (network element) and details about the failure
This depends not only on local configuration and ability of a itself. When an LSP traverses multiple domains, a failure could be
boundary node to do local crankback, but also on any specific generated in any domain along the path and an error notification may
parameters requested by the head-end node itself for that LSP. In need to be propagated across multiple domains. So, an error
certain cases, it may be desirable for the head-end node to exert notification message itself may be subjected to policies as it
some control on the ability for the boundary nodes to make use of traverses domain boundaries and a boundary node MAY modify domain
crankback. See [CRANKBACK] for the definition of those bits. When specific information carried in the error message. E.g. the error
crankback is allowed, the domain boundary node can either decide to node address in the RSVP ERROR_SPEC or IF_ID ERROR_SPEC or the
forward the Path Error message upstream to the head-end node of the Interface Identifier in IF_ID ERROR_SPEC may be modified at the
inter-domain TE LSP or try to select another egress boundary node. boundary node for confidentiality reasons. Nodes other than domain
When crankback is not allowed or if the node has not been configured boundary nodes SHOULD NOT modify ERROR_SPEC contents. It is also
to do a crankback, then a boundary node, when receiving a Path Error RECOMMENDED that such a policy be implemented only on domain boundary
message from a downstream boundary node MUST propagate the Path Error nodes for inter-domain LSPs where preserving confidentiality is a
message up to the head-end node of the inter-domain TE LSP. requirement.
Also, in case of an inter-domain LSP setup failure, there may be
cases when the error is not propagated all the way upstream to the
head-end node. A PathErr may be intercepted by a boundary node in the
domain in which the error is generated (or any other node along the
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
ability of a boundary node to do local crankback re-routing, but also
on any specific parameters requested by the head-end node itself for
that LSP. In certain cases, it may be desirable for the head-end node
to exert some control on whether crankback re-routing at intermediate
nodes is desirable or not. Procedures and extensions described in
[CRANKBACK] should be followed for crankback re-routing. When
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
addition to a PathErr/ResvErr message, to expedite error
notification, if a Notify Request has been received in the
corresponding Path/Resv message. This is also applicable to inter-
domain TE LSPs which implement [RSVP-GMPLS]. However, since PathErr
and Notify need not follow the same path, their recepient nodes could
be different. This has certain implications on crankback re-routing.
Procedures and recommendations in [CRANKBACK] should be followed for
Notify message processing for crankback re-routing.
3.3. RRO processing across domains
[RSVP-TE] defines the RECORD_ROUTE object (RRO) as an optional
object, which is primarily used for loop detection and for providing
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
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 4. RSVP-TE signaling extensions
The following RSVP-TE signaling extensions are introduced in this The following RSVP-TE signaling extensions are introduced in this
document. document.
4.1. Control of downstream choice of signaling method 4.1. Control of downstream choice of signaling method
In certain mixed environments with different techniques (contiguous, In certain mixed environments with different techniques (contiguous,
stitched or nested TE LSPs), a head-end node of the inter-domain TE stitched or nested TE LSPs), a head-end node of the inter-domain TE
LSP may wish to signal its requirement regarding the signaling method LSP may wish to signal its requirement regarding the signaling method
used at the domain boundaries. used at an intermediate node along the path.
[LSP-ATTRIBUTES] defines the format of the Attributes Flags TLV [LSP-ATTRIBUTES] defines the format of the Attributes Flags TLV
included in the LSP_ATTRIBUTES object carried in an RSVP Path included in the LSP_ATTRIBUTES object carried in an RSVP Path
message. The following bit in the Flags TLV is used by the head-end message. The following bit in the Flags TLV is used by the head-end
node of the inter-domain TE LSP to restrict the signaling method used node of the inter-domain TE LSP to restrict the signaling method used
by the domain boundary nodes to be contiguous. by the intermediate nodes to be contiguous.
0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end Bit Number 4 (TBD): Contiguous LSP bit - this flag is set by the
node that originates the inter-domain TE LSP if it desires a 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, contiguous end-to-end TE LSP (in the control & data plane). When set,
this indicates that a boundary node MUST not perform any stitching or this indicates that an intermediate node MUST NOT perform any
nesting on the TE LSP and the TE LSP MUST be routed as any other TE stitching or nesting on the TE LSP and the TE LSP MUST be routed as
LSP (it must be contiguous end to end). When this bit is cleared, a any other TE LSP (it must be contiguous end to end). When this bit is
boundary node may decide to perform stitching or nesting. A mid-point cleared, an intermediate node MAY decide to perform stitching or
node not supporting contiguous TE LSP MUST send a Path Error message nesting. This bit MUST NOT be modified by any downstream node.
upstream with an error code of "Routing Problem" and error sub-
code=17 (TBD) (Contiguous LSP type not supported). This bit MUST not
be modified by any downstream node.
5. Example
5.1. Example topology
In this document, we will consider the following example topology for
inter-domain TE LSPs setup and maintenance. Note, however, that
inter-domain TE LSP setup across other domains covered by this
document will also follow similar signaling procedures. In this
example, a domain is an Autonomous system (AS).
<-- AS-1 ---> <--- AS-2 ---> <-- AS-3 --> c
<---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 ================>
5.1.1. Assumptions
- Three interconnected ASes, respectively AS1, AS2, and AS3. 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.
- A protected inter-AS TE LSP T1 originated at R0 in AS1 and
terminating at R6 in AS3 with following possible paths:
LSP hops: R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6
o p1 - a set of loose node hops crossing AS-2
R0-X1-ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R6
o p2 - a set of strict interface hops crossing AS-2
R0-X1-ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict)
-link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R6
- A set of backup tunnels:
o B1 from ASBR1 to ASBR4 following the path ASBR1-ASBR2-ASBR4 and
protecting against a failure of the ASBR1-ASBR4 link
o B2 from ASBR1 to R3 following the path
ASBR1-ASBR2-ASBR3-ASBR6-ASBR5-R3 and protecting against a failure of
the ASBR4 node.
o B3 from ASBR1 to ASBR7 following the path
ASBR1-ASBR2-ASBR3-ASBR6-ASBR7 and protecting against a failure of the
ASBR4 node.
o B4 from R3 to ASBR9 following the path R3-R4-ASBR8-ASBR10-ASBR9 and
protecting against a failure of the ASBR7 node.
o B5 from ASBR4 to ASBR9 following the path ASBR4-ASBR8-ASBR10-ASBR9
and protecting against a failure of the ASBR7 node.
5.2. Setup Operation
Let us consider an inter-AS TE LSP setup from R0 to R6, with example
paths p1, p2 each. 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 may then directly forward the Path message to the next hop in
the ERO.
Nesting and Stitching:-
When the Path message for the inter-AS TE LSP from R0 to R6, 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
upto ASBR7 to find an existing FA-LSP in case of nesting or LSP
segment in case of stitching, that satisfies the TE constraints. If
there are no existing FA-LSPs or LSP segments and ASBR4 is capable of
seting up the FA-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 FA-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 FA-LSP
(nesting) or LSP segment (stitching) that satisfies the constraints
or it may compute a path for the FA-LSP or LSP segment upto ASBR7 or
some other intermediate node in AS-2.
In case of path p2, ASBR4 may either select an existing FA-LSP or LSP An intermdediate node that supports the LSP_ATTRIBUTES object and the
segment with ERO hops link[ASBR4-R3](strict)-link[R3-ASBR7](strict) Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit,
or it may compute a new path for the FA-LSP or LSP segment using the but cannot support contiguous TE LSP MUST send a Path Error message
above hops. In either case, the ERO hops for the FA-LSP or LSP upstream with an error code=24 ("Routing Problem") and error sub-
segment MUST be the same as the signaled strict hops in that domain. code="Contiguous LSP type not supported" (TBD).
Now, suppose, we have a path p3, as a set of strict node hops If an intermediate node receiving a Path message with the "Contiguous
crossing AS-2 as defined below, 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 and MUST set the
"Contiguous LSP signaled" bit in the Flags field of the RRO
Attributes subobject in the corresponding Resv message.
R0-X1-ASBR1(loose)-ASBR4(strict)-ASBR7(strict)-ASBR9(loose)-R6 However, if the intermediate node supports the LSP_ATTRIBUTES object
but does not recognize the Attributes Flags TLV, or supports the TLV
as well, but does not recognize this particular bit, then it SHOULD
simply ignore the above request. It MAY signal any type of LSP in
this case. The "Contiguous LSP signaled" bit in the Flags field of
the RRO Attributes SHOULD NOT be set.
In this case, the ERO nexthop at ASBR4 is ASBR7(strict). In this An ingress node for an inter-domain LSP requesting a contiguous LSP
case, ASBR4 will try to find or compute a FA-LSP or LSP segment SHOULD examine the RRO Attributes subobject Flags to determine if the
directly to ASBR7. LSP was indeed signaled contiguous end to end. If the "Contiguous LSP
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.
The main difference between processing of p1 and p3 for nesting or 5. Protection and recovery of inter-domain TE LSPs
stitching is that in case of p1, since the ERO nexthop is a loose
hop, ASBR4 need not find a FA-LSP or LSP segment directly from ASBR4
to ASBR7. So, there could be multiple FA-LSPs or LSP segments between
ASBR4 and ASBR7. On the other hand, for path p3, since ASBR7 is a
strict hop, ASBR4 MUST find or signal a FA-LSP or LSP segment that
connects ASBR4 and ASBR7.
6. Protection and recovery of inter-domain TE LSPs The procedures described in Section 3 MUST be applied to all inter-
domain TE LSPs, including bypass tunnels, detour LSPs [FAST-REROUTE]
or segment recovery LSPs [SEGMENT-PROTECTION] that may cross domains.
This means that these LSPs will also be subjected to ERO processing,
policies, path computation; etc. Also, note that the explicit route
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.
6.1. Fast Recovery support using MPLS TE Fast Reroute 5.1. Fast Recovery support using MPLS TE Fast Reroute (FRR)
[FAST-REROUTE] describes two methods for local protection for a [FAST-REROUTE] describes two methods for local protection for a
packet TE LSP in case of link, SRLG or node failure. This section 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.
6.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 [FAST-REROUTE]. In case of
nested or stitched inter-domain TE LSPs, protecting the intra-domain nested or stitched inter-domain TE LSPs, protecting the intra-domain
TE FA-LSP or LSP segment will automatically protect the traffic on TE H-LSP or LSP segment will automatically protect the traffic on the
the inter-domain TE LSP. No new extensions are required for any of inter-domain TE LSP. No new extensions are required for any of the
the signaling methods. signaling methods.
6.1.2. Failure of link at domain boundaries 5.1.2. Failure of link at domain boundaries
The procedures for doing link protection of the link at domain The procedures for doing link protection of the link at domain
boundaries is the same for contiguous, nested and stitched TE LSPs. 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 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- two domain boundary nodes diversely routed from the protected inter-
domain link. The region connecting two domains may not be TE enabled. domain link. The region connecting two domains may not be TE enabled.
In this case, an implementation will have to support the set up of TE In this case, an implementation will have to support the set up of TE
LSP over a non-TE enabled region. LSP over a non-TE enabled region.
skipping to change at page 11, line 6 skipping to change at page 12, line 20
content of the RRO object received in the RSVP Resv message of both content of the RRO object received in the RSVP Resv message of both
the bypass tunnel and the protected TE LSP(s). As defined in [RSVP- the bypass tunnel and the protected TE LSP(s). As defined in [RSVP-
TE], the addresses specified in the RRO IPv4 subobjects can be node- TE], the addresses specified in the RRO IPv4 subobjects can be node-
ids and/or interface addresses (with specific recommendation to use ids and/or interface addresses (with specific recommendation to use
the interface address of the outgoing Path messages). The PLR may or the interface address of the outgoing Path messages). The PLR may or
may not have sufficient topology information to find where the backup may not have sufficient topology information to find where the backup
tunnel intersects the protected TE LSP based on the RRO. [NODE-ID] tunnel intersects the protected TE LSP based on the RRO. [NODE-ID]
proposes a solution to this issue, defining an additional RRO IPv4 proposes a solution to this issue, defining an additional RRO IPv4
suboject that specifies a node-id address. suboject that specifies a node-id address.
Example: The ASBR1-ASBR4 link is protected by the backup tunnel B1 5.1.3. Failure of a boundary node
that follows the ASBR1-ASBR2-ASBR4 path
6.1.3. Failure of a boundary node
For each protected inter-domain TE LSP traversing the boundary node For each protected inter-domain TE LSP traversing the boundary node
to be protected, a NNHOP backup must be selected by the PLR. This to be protected, a NNHOP backup must be selected by the PLR. This
requires the PLR to setup a bypass tunnel terminating at the NNHOP. requires the PLR to setup a bypass tunnel terminating at the NNHOP.
Finding the NNHOP bypass tunnel of an inter-domain TE LSP can be Finding the NNHOP bypass tunnel of an inter-domain TE LSP can be
achieved by analyzing the content of the RRO object received in the achieved by analyzing the content of the RRO object received in the
RSVP Resv message of both the bypass tunnel and the protected TE RSVP Resv message of both the bypass tunnel and the protected TE
LSP(s) (see [NODE-ID]). The main difference with node protection, LSP(s) (see [NODE-ID]). The main difference with node protection,
between a protected contiguous inter-domain TE LSP and a protected 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) 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. 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 However, in case of a nested or stitched TE-LSP the PLR and MP can
only be the end-points of the FA-LSP or LSP segment. The consequence 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 is that the backup path is likely to be longer and if bandwidth
protection is desired, for instance, ([FAST-REROUTE]) more resources protection is desired, for instance, ([FAST-REROUTE]) more resources
may be reserved in the domain than necessary. may be reserved in the domain than necessary. Note, however, that
even for a contiguous LSP, there may be cases where the addresses
Let us again consider the example topology of section 4.1. The within the domain could have been masked in the RRO for
protected inter-domain TE LSP is an inter-AS TE LSP from R0 to R6 confidentiality reasons, in which case, the RRO for the contiguous
with path p1. Also, for nesting or stitching, let us assume that the LSP may only contain boundary nodes, and so the MP can only be a
end-points of the FA-LSP or LSP segment in AS-2 are ASBR4 and ASBR7. boundary node.
This gives rise to the following two scenarios for node protection:
Protecting the boundary node at the entry to a domain :-
Example: protecting against the failure of ASBR4
If the inter-AS TE LSP in this example, is a contiguous LSP, then the
PLR is ASBR1 and the NNHOP (MP) could be R3 or any other intermediate
node along the LSP path. A backup tunnel B2 may be used to protect
the inter-AS TE LSP against failure of ASBR4.
If the inter-AS TE LSP in this example, is nested or sticthed at
ASBR4 into an intra-domain TE FA-LSP or LSP segment between ASBR4 and
ASBR7, then the PLR is ASBR1 and the NNHOP (MP) is ASBR7. A backup
tunnel B3 may be used to protect the inter-AS TE LSP against failure
of ASBR4.
Protecting the boundary node at the exit of a domain :-
Example: protecting against failure of ASBR7.
If the inter-AS TE LSP in this example, is a contiguous LSP, then the Also, while a contiguous LSP does allow backup LSPs to terminate
PLR could be R3 and the NNHOP (MP) is ASBR9. A backup tunnel B4 may inside the domain, there could be policies which may reject an LSP
be used to protect the inter-AS TE LSP against failure of ASBR7. that originates in another domain from carrying addresses in ERO that
are local to this domain. In these cases, the backup LSP cannot
terminate inside the domain and must terminate only at the boundary
node.
If the inter-AS TE LSP in this example, is nested or sticthed at In case of stitching or nesting, when the node to be protected is the
ASBR4 into an intra-domain TE FA-LSP or LSP segment between ASBR4 and H-LSP/S-LSP tail-end node, the PLR is not immediately upstream of
ASBR7, then the PLR is ASBR4 and the NNHOP (MP) is ASBR9. A backup this node. Hence, the failure detection time on failure of H-LSP/S-
tunnel B5 may be used to protect the inter-AS TE LSP against failure LSP tail-end node is bound to be longer than that in the case where
of ASBR7. 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.
6.2. Protection and recovery of GMPLS LSPs 5.2. Protection and recovery of GMPLS LSPs
[E2E-RECOVERY] describes the signaling extensions to support end-to- [SEGMENT-PROTECTION] describes GMPLS based segment recovery. This
end GMPLS LSP recovery. Signaling methods defined above for inter- allows protection against a span failure, a node failure, or failure
domain RSVP-TE LSPs also apply to recovery LSPs signaled for end-to- over any particular portion of a network used by an LSP. The
end protection of inter-domain GMPLS LSPs. Any other protection scenarios described above for MPLS Fast reroute also apply to segment
mechanisms that are developed for GMPLS LSPs SHOULD also take into protection. No new extensions are needed for segment protection of
account inter-domain considerations. 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].
7. Re-optimization of inter-domain TE LSPs 6. Re-optimization of inter-domain TE LSPs
Re-optimization of a TE LSP is the process of moving the LSP from the Re-optimization of a TE LSP is the process of moving the LSP from the
current path to a more prefered path. This usually involves current path to a more prefered path. This usually involves
computation of the new prefered path and make-before-break signaling computation of the new prefered path and make-before-break signaling
procedures [RSVP-TE], to minimize traffic disruption. The path procedures [RSVP-TE], to minimize traffic disruption. The path
computation procedures involved in re-optimization of an inter-domain computation procedures involved in re-optimization of an inter-domain
TE LSP are covered in [INTER-DOMAIN-PD-PATH-COMP]. 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 In the context of an inter-domain TE LSP, since the LSP traverses
multiple domains, re-optimization may be required in one or more multiple domains, re-optimization may be required in one or more
domains at a time. Again, depending on the nature of the LSP and/or domains at a time. Again, depending on the nature of the LSP and/or
policies and configuration at domain boundaries (or other nodes), one policies and configuration at domain boundaries (or other nodes), one
may either always want the head-end node of the inter-domain TE LSP 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 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 head-end initiate the make-before-break process or one may want to
restrict local re-optimizations with the domain. restrict local re-optimizations with the domain.
[LOOSE-REOPT] describes mechanisms that allow, [LOOSE-REOPT] describes mechanisms that allow,
- The head-end node to trigger on every node whose next hop
is a loose hop the re-evaluation of the current path in order to o The head-end node to trigger on every node whose next hop is
detect a potentially more optimal path. This is done via explicit a loose hop the re-evaluation of the current path in order to
signaling request: the head-end node sets the "ERO Expansion request" detect a potentially more optimal path. This is done via
bit of the SESSION-ATTRIBUTE object carried in the RSVP Path message. explicit signaling request: the head-end node sets the
- A node whose next hop is a loose-hop to signal to the head- "ERO Expansion request" bit of the SESSION-ATTRIBUTE object
end node that a better path exists. This is performed by sending an carried in the RSVP Path message.
RSVP Path Error Notify message (ERROR-CODE = 25), sub-code 6 (Better
path exists). This indication may either be sent in response to a o A node whose next hop is a loose-hop to signal to the head-end
query sent by the head-end node or spontaneously by any node having node that a better path exists. This is performed by sending an
detected a more optimal path. 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 above mechanisms SHOULD be used for a contiguous inter-domain TE
LSP to allow the head-end node of the inter-domain TE LSP to initiate LSP to allow the head-end node of the inter-domain TE LSP to initiate
make-before-break procedures. For nested or stitched TE LSPs, it is make-before-break procedures. For nested or stitched TE LSPs, it is
possible to re-optimize the local FA-LSP or LSP segment without 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 involving the head-end node of the inter-domain TE LSP. This will
automatically re-route the traffic for the inter-domain TE LSP along automatically re-route the traffic for the inter-domain TE LSP along
the new path, within the domain. Such local re-optimizations, the new path, within the domain. Such local re-optimizations,
including parameters for re-optimization can be controlled by local including parameters for re-optimization can be controlled by local
policy or configuration in that domain. policy or configuration in that domain.
8. Security Considerations 7. Security Considerations
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 already defined security features related to RSVP-TE
(authentication). This may require some coordination between the (authentication). This may require some coordination between the
domains to share the keys (see RFC 2747 and RFC 3097). Note that this domains to share the keys (see RFC 2747 and RFC 3097). Note that this
may involve additional synchronization, should the domain boundary may involve additional synchronization, should the domain boundary
LSR be protected with MPLS TE Fast Reroute, since the merge point LSR be protected with MPLS TE Fast Reroute, since the merge point
should also share the key. 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 (also see
[INTER-AREA-TE-REQS]) SHOULD be provided to an operator :- 1) a way [INTER-AS-TE-REQS]) SHOULD be provided to an operator :-
to enforce policies and filters at the domain boundaries to process
the incoming LSP setup requests (Path messages) based on certain 1) a way to enforce policies and filters at the domain boundaries
agreed trust and service levels between domains. 2) a way for the to process the incoming inter-domain TE LSP setup requests
operator to rate limit LSP setup requests or error notifications from (Path messages) based on certain agreed trust and service
a particular domain. 3) a mechanism to allow policy-based outbound levels/contracts between domains. Various LSP attributes
RSVP message processing at the domain boundary LSR, which may involve such as bandwidth, priority; etc could be part of such a
filtering or modification of certain addresses in RSVP objects and contract.
messages.
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 boundary LSR, which may involve
filtering or modification of certain addresses in RSVP
objects and messages.
Some examples of the policies described above are:-
1) An operator may choose to implement some kind of ERO filtering
policy on the domain boundary LSR to disallow or ignore hops
within the domain being identified in the ERO of an incoming
Path message.
2) In order to preserve confidentiality, 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 boundary LSR.
Some examples of the policies described above are:- 1) An operator
may choose to implement some kind of ERO filtering policy on the
domain boundary LSR to disallow or ignore hops within the domain
being identified in the ERO of an incoming Path message. 2) In order
to preserve confidentiality, 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 boundary LSR.
3) An operator may require the boundary LSR to modify the addresses 3) An operator may require the boundary LSR 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 mechanisms (local
implementation) is outside the scope of this document. implementation) is outside the scope of this document.
9. IANA Considerations 8. IANA Considerations
The following values have to be defined by IANA for this document. The following values have to be defined by IANA for this document.
The registry is, http://www.iana.org/assignments/rsvp-parameters. The registry is, http://www.iana.org/assignments/rsvp-parameters.
9.1. Attribute Flags for LSP_ATTRIBUTES object 8.1. Attribute Flags for LSP_ATTRIBUTES object
The following new flag bit is being defined for the Attributes Flags The following new flag bit is being defined for the Attributes Flags
TLV in the LSP_ATTRIBUTES object. The numeric value should be TLV in the LSP_ATTRIBUTES object. The numeric value should be
assigned by IANA. assigned by IANA.
Contiguous LSP bit - 0x01 (Suggested value) Contiguous LSP bit - Bit Number 4 (Suggested value)
This flag bit is only to be used in the Attributes Flags TLV on a This flag bit is only to be used in the Attributes Flags TLV on a
Path message. Path message.
9.2. New Error Codes The "Contiguous LSP" bit has a corresponding "Contiguous LSP
signaled" bit (Bit Number 4) to be used in the RRO Attributes sub-
object.
The following new error sub-code is being defined under the RSVP 8.2. New Error Codes
The following new error sub-codes are being defined under the RSVP
error-code "Routing Problem" (24). The numeric error sub-code value error-code "Routing Problem" (24). The numeric error sub-code value
should be assigned by IANA. should be assigned by IANA. Suggested values are,
Contiguous LSP type not supported - sub-code 17 (Suggested value) 1. Contiguous LSP type not supported - sub-code 21
This error code is to be used only in a RSVP PathErr. 2. ERO conflicts with inter-domain signaling method - sub-code 22
10. Acknowledgements These error codes are to be used only in a RSVP PathErr.
The following new error sub-codes are being defined under the RSVP
error-code "Policy control failure" (2). The numeric error sub-code
value should be assigned by IANA. Suggested values are,
1. Inter-domain policy failure - sub-code 102
2. Inter-domain explicit route rejected - sub-code 103
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 Adrian Farrel on various aspects discussed in the document.
11. References 10. References
11.1. Normative References 10.1. Normative References
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF", RFC 3630 (Updates RFC 2370), September 2003. Extensions to OSPF", RFC 3630 (Updates RFC 2370), September 2003.
[ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic
Engineering", RFC 3784 Engineering", RFC 3784
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001. 3209, December 2001.
skipping to change at page 15, line 22 skipping to change at page 17, line 13
[LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with [LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with
Generalized MPLS TE", (work in progress). Generalized MPLS TE", (work in progress).
[CRANKBACK] Farrel A. et al, "Crankback Signaling Extensions for MPLS [CRANKBACK] Farrel A. et al, "Crankback Signaling Extensions for MPLS
Signaling", (work in progress). Signaling", (work in progress).
[LSP-ATTRIBUTES] Farrel A. et al, "Encoding of Attributes for [LSP-ATTRIBUTES] Farrel A. et al, "Encoding of Attributes for
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
Establishment Using RSVP-TE", (work in progress). Establishment Using RSVP-TE", (work in progress).
[FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 10.2. Informative References
for LSP Tunnels", (work in progress)
[NODE-ID] Vasseur, Ali and Sivabalan, "Definition of an RRO node-id
subobject", (work in progress).
[E2E-RECOVERY] J.P. Lang et al, "RSVP-TE Extensions in support of
End-to-End GMPLS-based Recovery", (work in progress).
11.2. Informative References
[INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering
requirements", (work in progress). requirements", (work in progress).
[INTER-AREA-TE-REQS] LeRoux JL, Vasseur JP, Boyle J. et al, [INTER-AREA-TE-REQS] LeRoux JL, Vasseur JP, Boyle J. et al,
"Requirements for support of Inter-Area MPLS Traffic Engineering", "Requirements for support of Inter-Area MPLS Traffic Engineering",
(work in progress). (work in progress).
[INTER-DOMAIN-FRAMEWORK] Farrel A. et al, "A Framework for Inter- [INTER-DOMAIN-FRAMEWORK] Farrel A. et al, "A Framework for Inter-
Domain MPLS Traffic Engineering", (work in progress). Domain MPLS Traffic Engineering", (work in progress).
[INTER-DOMAIN-PD-PATH-COMP] Vasseur JP., Ayyangar A., Zhang R., "A [INTER-DOMAIN-PD-PATH-COMP] Vasseur JP., Ayyangar A., Zhang R., "A
Per-domain path computation method for computing Inter-domain Traffic Per-domain path computation method for computing Inter-domain Traffic
Engineering Label Switched Path", (work in progress). 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 RSVP Support for the Overlay [GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay
Model", (work in progress). Model", (work in progress).
[RSVP-UNNUM] Kompella K., Rekhter Y., "Signalling Unnumbered Links in [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC for LSP Tunnels", RFC 4090, May 2005.
3477, January 2003.
[BUNDLING] Kompella K., Rekhter Y., "Link Bundling in MPLS Traffic [NODE-ID] Vasseur, Ali and Sivabalan, "Definition of an RRO node-id
Engineering", (work in progress). subobject", (work in progress).
[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 [LOOSE-REOPT] Vasseur JP. et al, "Reoptimization of an explicit
loosely routed MPLS TE paths", (work in progress). 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,
link[R3-R4](strict)-link[R4-ASBR8](strict)-ASBR9(loose) and
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,
ASBR4-ASBR8(loose)-ASBR9(loose) and protecting against a
failure of the ASBR7 node. B5 may involve loose hop expansion
on ASBR8.
Note that in addition to the ERO for backup tunnels, additional
information regarding node/link to exclude may need to be signaled as
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
with path p1. Also, for nesting or stitching, let us assume that the
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 :-
Example: protecting against the failure of ASBR4
If the inter-AS TE LSP in this example, is a contiguous LSP, then the
PLR is ASBR1 and the NNHOP (MP) could be R3 or any other intermediate
node along the LSP path, if this information can be gleaned from the
RRO. A backup tunnel B2 may be used to protect the inter-AS TE LSP
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
ASBR4 into an intra-domain TE H-LSP or LSP segment between ASBR4 and
ASBR7, then the PLR is ASBR1 and the NNHOP (MP) is ASBR7. A backup
tunnel B3 may be used to protect the inter-AS TE LSP against failure
of ASBR4.
Protecting the boundary node at the exit of a domain :-
Example: protecting against failure of ASBR7.
If the inter-AS TE LSP in this example, is a contiguous LSP, then the
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
ASBR4 into an intra-domain TE H-LSP or LSP segment between ASBR4 and
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 Author's addresses
Arthi Ayyangar Arthi Ayyangar
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
e-mail: arthi@juniper.net e-mail: arthi@juniper.net
Jean Philippe Vasseur Jean Philippe Vasseur
 End of changes. 61 change blocks. 
341 lines changed or deleted 628 lines changed or added

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