IETF Internet Draft Arthi Ayyangar(Editor)
Proposed Status: Standards Track Juniper Networks
Expires: January 2005
Jean-Philippe Vasseur(Editor)
Cisco Systems, Inc.
July 2004
Inter domain MPLS Traffic Engineering - RSVP-TE extensions
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes extensions to Generalized Multi-Protocol Label
Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering
(RSVP-TE) signaling required to support mechanisms for the establishment
and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths
(LSPs), both packet and non-packet, that traverse multiple domains. For
the purpose of this document, a domain is considered to be any
collection of network elements within a common realm of address space or
path computation responsibility. Examples of such domains include
Autonomous Systems, IGP areas and GMPLS overlay networks.
Ayyangar and Vasseur [Page 1]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
1. Introduction
The requirements for inter-area and inter-AS MPLS Traffic Engineering
have been developed by the Traffic Engineering Working Group and have
been stated in [INTER-AREA_REQS] and [INTER-AS-REQS] respectively.
The framework for inter-domain MPLS Traffic Engineering has been
provided in [INTER-DOMAIN-FRAMEWORK].
This document presents the RSVP-TE signaling extensions for the setup
and maintenance of TE LSPs that span multiple domains. The signaling
procedures described in this document are applicable to both packet
LSPs ([RSVP-TE]) and non-packet LSPs that use RSVP-TE GMPLS
extensions as described in [RSVP-GMPLS]. Three different signaling
methods along with the corresponding RSVP-TE extensions and
procedures are proposed in this document.
For the purpose of this document, a domain is considered to be any
collection of network elements within a common realm of address space
or path computation responsibility. Examples of such domains include
Autonomous Systems, IGP areas and GMPLS overlay networks ([GMPLS-
OVERLAY]).
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology
ASBR: routers used to connect together ASes of a different or the
same Service Provider via one or more Inter-AS links.
Bypass Tunnel: an LSP that is used to protect a set of LSPs passing
over a common facility.
ERO: Explicit Route Object
FA-LSP - Forwarding Adjacency LSP
LSP: MPLS Label Switched Path
LSR: Label Switch Router
MP: Merge Point. The LSR where bypass tunnels meet the protected LSP.
NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which
bypasses a single link of the protected LSP.
Ayyangar and Vasseur [Page 2]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel,
which bypasses a single node of the protected LSP.
PLR: Point of Local Repair. The head-end 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
TE LSP: Traffic Engineering Label Switched Path
TED: MPLS Traffic Engineering Database
2. Signaling overview
The RSVP-TE signaling of a TE LSP within a single domain is described
in [RSVP-TE]. This document focuses on the RSVP-TE signaling
extensions required for inter-domain TE LSP setup and maintenance.
Any other extensions that may be needed for routing or path
computation are outside the scope of this document.
2.1. Signaling options
There are three ways in which an RSVP-TE LSP could be signaled across
multiple domains:
Contiguous - A contiguous TE LSP is a single end-to-end TE LSP that
is setup across multiple domains using RSVP-TE signaling procedures
described in [RSVP-TE]. No additional TE LSPs are required to signal
a contiguous TE LSP and the same RSVP-TE information for the TE LSP
is maintained along the entire LSP path.
Stitching - A stitched TE LSP is a TE LSP made up of 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 the data plane. In the
control plane, however, the different LSP segments are signaled as
distinct RSVP sessions which are independent from the inter-domain TE
LSP. Signaling procedures described in [LSP-HIERARCHY] are used to
stitch an inter-domain TE LSP to a local LSP segment. Additional
signaling extenstions may be required for stitching of packet LSPs.
This is described in section 3.
Nesting - Nesting one or more TE LSPs into another TE LSP is
Ayyangar and Vasseur [Page 3]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
described in [LSP-HIERARCHY]. This technique can also be used to nest
one or more inter-domain TE LSPs into an intra-domain FA-LSP. While
similar to stitching in the control plane, in the data plane, nesting
allows for one or more inter-domain LSPs to be transported over a
single intra-domain FA-LSP using the label stacking construct.
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
or stitch it to another TE LSP, depends on the signaled TE LSP
characteristics or the local LSR configuration, when not explicitly
signaled. Also, the TE LSP segment or FA-LSP within the domain may
either be pre-configured or signaled dynamically based on the arrival
of the inter-domain TE LSP setup request.
2.2. Procedures on the boundary LSR
Whether an inter-domain TE LSP is contiguous, nested or stitched is
determined mostly by the signaling method supported by or configured
on the intermediate LSRs, usually the domain boundary LSRs that the
inter-domain TE LSP traverses through. It may also depend on certain
parameters signaled by the head-end LSR for the inter-domain TE LSP.
When a boundary LSR receives the RSVP Path message for an inter-
domain TE LSP setup, it MUST carry out the following procedures
before it can forward the Path message to the next hop LSR,
- apply any locally configured policies
- determine the signaling method to be used based on any desired
characteristics signaled by the head-end LSR of the inter-domain TE
LSP or if the signaling method is not explicitly signaled, then
determine the signaling method based on local configuration, policies
- depending on the signaling method, carry out any specific ERO
procedures, as applicable, as described in the next section
- based on the signaling method to be used, determine the next
hop LSR to forward the RSVP Path message
- 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
- perform any path computations if required. The path computation
procedure itself is outside the scope of this document. The various
path computation options are addressed in [INTER-DOMAIN-PATH-COMP]
- in case of any failures (admission control, policy, signaling;
etc), originate corresponding error notifications
2.3. Rules on ERO processing
The ERO that a domain boundary LSR receives in the Path message for
an inter-domain TE LSP will be dependent on several factors such as
the level of visibility that the head-end LSR of the inter-domain TE
LSP has into other domains, the path computation techniques applied
Ayyangar and Vasseur [Page 4]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
at the head-end LSR, policy agreements between two domains; etc.
Eventually, when the ERO reaches a domain boundary LSR, the 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 present,
then they may originate and terminate on domain boundary LSRs. There
could also be FA-LSPs and LSP segments that may originate and
terminate at other nodes in the domain. In general, these ERO
processing rules are also applicable to non-boundary nodes that may
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
be taken. E.g. if there exists a policy to reject LSP setup request
containing ERO with sub-objects identifying nodes within the domain,
then a PathErr with the appropriate error code should be sent back
- Section 8.2 of [LSP-HIERARCHY] describes how an LSR at the
edge of a region (domain) processes the ERO in the incoming Path
message and uses this ERO, to either find an existing FA-LSP or
signal a new FA-LSP using the ERO hops. This also includes adjusting
the ERO before sending the Path message to the next hop LSR. These
procedures SHOULD also be followed for nesting or stitching of inter-
domain TE LSPs to FA-LSPs or LSP segments respectively. While the
domain boundaries are tied to link switching capabilities in [LSP-
HIERARCHY], these procedures are also applicable to other domain
boundary LSRs in the context of this document. E.g. in case of a path
computation domain, you have reached the boundary when the ERO hop is
no longer reachable via the TE database (TED).
- In case of any failure in processing the ERO hop(s), a Path
Error message with appropriate error code ([RSVP-TE]) SHOULD be
generated.
2.4. LSP setup failure and crankback
In case of any setup failures along the path due to policy or
admission control or other reasons, a corresponding Path Error SHOULD
be generated and sent upstream. The propagation of Path Error
upstream may be limited to within the domain or it may be sent all
the way upstream to the head-end LSR of the inter-domain TE LSP. This
depends not only on local configuration and ability of a boundary LSR
to do local crankback, but also on any specific parameters requested
by the head-end LSR itself for that LSP. In certain cases, it may be
desirable for the head-end LSR to exert some control on the ability
for the boundaries LSRs to make use of crankback. See [CRANKBACK] for
the definition of those bits. When crankback is allowed, the domain
boundary LSR can either decide to forward the Path Error message
upstream to the head-end LSR of the inter-domain TE LSP or try to
select another egress boundary LSR (which is also referred to as
crankback). When crankback is not allowed or if the LSR has not been
configured to do a crankback, then a boundary LSR, when receiving a
Ayyangar and Vasseur [Page 5]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
Path Error message from a downstream boundary LSR MUST propagate the
Path Error message up to the head-end LSR of the inter-domain TE LSP.
3. RSVP-TE signaling extensions
The following RSVP-TE signaling extensions are introduced in this
document.
3.1. Control of downstream choice of signaling method
In certain mixed environments with different techniques (contiguous,
stitched or nested TE LSPs), a head-end LSR of the inter-domain TE
LSP may wish to signal its requirement regarding the signaling method
used at the domain boundaries.
[LSP-ATTRIBUTES] defines the format of the Attributes Flags TLV
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
LSR of the inter-domain TE LSP to restrict the signaling method used
by the domain boundary LSRs to be contiguous.
0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end LSR
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 a boundary LSR 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, a
boundary LSR may decide to perform stitching or nesting. A mid-point
LSR not supporting contiguous TE LSP MUST send a Path Error message
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.
3.2. Stitching of packet LSPs
This section only applies to an inter-domain packet LSP being
stitched to another intra-domain packet LSP. Also this signaling is
applicable only to the local intra-domain LSP segment. If a domain
boundary LSR desires to perform LSP stitching of a packet LSP, then
it MUST indicate this in the Path message for the intra-domain LSP
segment. This signaling is needed so that the egress LSR for the LSP
segment knows in advance, how the ingress for the LSP segment plans
to map traffic onto the LSP segment. This will allow it to allocate
the correct label(s) as explained below. Also, so that the head-end
LSR can ensure that correct stitching actions were carried out at the
egress LSR, a new flag is defined below in the RRO subobject to
Ayyangar and Vasseur [Page 6]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
indicate that the LSP segment can be used for stitching.
In order to request LSP stitching, we define a new flag bit in the
Attributes Flags TLV of the LSP_ATTRIBUTES object defined in [LSP-
ATTRIBUTES]:
0x02 (TBD): LSP stitching desired bit - This flag will be set in the
Attributes Flags TLV of the LSP_ATTRIBUTES object in the Path message
for the local intra-domain LSP segment by the head-end LSR of the LSP
segment (boundary LSR) that desires LSP stitching. This flag MUST not
be modified by any other LSRs in that domain.
An intra-domain LSP segment can only be used for stitching if
appropriate label actions were carried out at the egress LSR of the
LSP segment. In order to indicate this to the head-end LSR of the LSP
segment, the following new flag bit is defined in the RRO Attributes
sub-object: 0x02 (TBD): LSP segment stitching ready
If an egress LSR receiving a Path message, supports the
LSP_ATTRIBUTES object and the Attributes Flags TLV, and also
recognizes the "LSP stitching desired" flag bit, but cannot support
the requested stitching behavior, then it MUST send back a PathErr
message with an error code of "Routing Problem" and an error sub-
code=16 (TBD) "Stitching unsupported" to the head-end LSR of the
intra-domain LSP segment.
If an egress LSR receiving a Path message with the "LSP stitching
desired" flag set, recognizes the object, the TLV and the flag and
also supports the desired stitching behavior, then it MUST allocate a
non-NULL label for that LSP segment in the corresponding Resv
message. Now, so that the head-end LSR can ensure that the correct
label actions will be carried out by the egress LSR and that the LSP
segment can be used for stitching, the egress LSR MUST set the "LSP
segment stitching ready" bit defined in the RRO Attribute sub-object.
Also, when the egress LSR for the LSP segment receives a Path message
for an inter-domain LSP using this LSP segment, it SHOULD first check
if it is also the egress for the inter-domain TE LSP. If the egress
LSR is the egress for both the intra-domain LSP segment as well as
the inter-domain TE LSP, and it requires Penultimate Hop Popping
(PHP), then the LSR MUST send back a Resv refresh for the intra-
domain LSP segment with a new label corresponding to the NULL label.
The egress LSR MUST always allocate a NULL label in the Resv message
for the inter-domain TE LSP.
Finally, if the egress LSR for the intra-domain LSP segment 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 flag bit, then it SHOULD simply ignore the above request.
Ayyangar and Vasseur [Page 7]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
An ingress LSR requesting stitching MUST examine the RRO Attributes
sub-object flag corresponding to the egress LSR for the intra-domain
LSP segment, to make sure that stitching actions were carried out at
the egress LSR. It MUST NOT use the LSP segment for stitching if the
"LSP segment stitching ready" flag is cleared.
An ingress LSR stitching an inter-domain LSP to an LSP segment MUST
ignore any Label received in the Resv for the inter-domain TE LSP.
4. Example
4.1. Example topology
In this document, we will consider the following example topology for
inter-domain TE LSPs setup and maintenance. In this example, a domain
is an Autonomous system (AS).
<-- 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(LSR to LSR)=============>
4.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
Ayyangar and Vasseur [Page 8]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
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.
4.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 LSR for AS-2, for the different
signaling methods.
Contiguous:-
The head-end LSR, 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
Ayyangar and Vasseur [Page 9]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
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
segment with ERO hops link[ASBR4-R3](strict)-link[R3-ASBR7](strict)
or it may compute a new path for the FA-LSP or LSP segment using the
above hops. In either case, the ERO hops for the FA-LSP or LSP
segment MUST be the same as the signaled strict hops in that domain.
Now, suppose, we have a path p3, as a set of strict node hops
crossing AS-2 as defined below,
R0-X1-ASBR1(loose)-ASBR4(strict)-ASBR7(strict)-ASBR9(loose)-R6
In this case, the ERO nexthop at ASBR4 is ASBR7(strict). In this
case, ASBR4 will try to find or compute a FA-LSP or LSP segment
directly to ASBR7.
The main difference between processing of p1 and p3 for nesting or
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
Ayyangar and Vasseur [Page 10]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
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.
5. Fast Recovery support using MPLS TE Fast Reroute
[FAST-REROUTE] describes two methods for local protection for a TE
LSP in case of link, SRLG or node failure. This section describes how
these mechanisms work with the proposed signaling solutions for
inter-domain TE LSP setup.
5.1. Failure within a domain (link or node failure)
The mode of operation of MPLS TE Fast Reroute to protect a
contiguous, stitched or nested TE LSP within a domain is identical to
the existing procedures described in [FAST-REROUTE]. In case of
nested or stitched inter-domain TE LSPs, protecting the intra-domain
TE FA-LSP or LSP segment will automatically protect the traffic on
the inter-domain TE LSP. No new extensions are required for any of
the signaling methods.
5.2. Failure of link at domain boundaries
The procedures for doing link protection of the link at domain
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
backup tunnels must be configured or dynamically computed between the
two domain boundary nodes diversely routed from the protected inter-
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
LSP over a non-TE enabled region.
For each protected inter-domain TE LSP traversing the protected link,
a NHOP backup must be selected by a PLR (i.e domain exit boundary
router), when the TE LSP is first set up. This requires for the PLR
to select a bypass tunnel terminating at the NHOP. Finding the NHOP
bypass tunnel of an inter-AS LSP can be achieved by analyzing the
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-
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
Ayyangar and Vasseur [Page 11]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
suboject that specifies a node-id address.
Example: The ASBR1-ASBR4 link is protected by the backup tunnel B1
that follows the ASBR1-ASBR2-ASBR4 path
5.3. Failure of a 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
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
achieved by analyzing the content of the RRO object received in the
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 FA-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.
Let us again consider the example topology of section 4.1. The
protected inter-domain TE LSP is an inter-AS TE LSP from R0 to R6
with path p1. Also, for nesting or stitching, let us assume that the
end-points of the FA-LSP or LSP segment in AS-2 are ASBR4 and ASBR7.
This gives rise to the following two scenarios for node protection:
5.3.1. Protecting the boundary LSR 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.
Ayyangar and Vasseur [Page 12]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
5.3.2. Protecting the boundary LSR 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 sticthed at
ASBR4 into an intra-domain TE FA-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.
6. Re-optimization of inter-domain TE LSPs
Re-optimization of a TE LSP is the process of moving the LSP from the
current path to a more prefered path. This usually involves
computation of the new prefered path and make-before-break signaling
procedures [RSVP-TE], to minimize traffic disruption. The path
computation procedures involved in re-optimization of an inter-domain
TE LSP are covered in [INTER-DOMAIN-PATH-COMP].
In the context of an inter-domain TE LSP, since the LSP traverses
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
policies and configuration at domain boundaries (or other nodes), one
may either always want the head-end LSR 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 head-end LSR to trigger on every LSR whose next hop is
a loose hop the re-evaluation of the current path in order to detect
a potentially more optimal path. This is done via explicit signaling
request: the head-end LSR sets the "ERO Expansion request" bit of the
SESSION-ATTRIBUTE object carried in the RSVP Path message.
- An LSR whose next hop is a loose-hop to signal to the head-
end LSR that a better path exists. This is performed by sending an
RSVP Path Error 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 LSR or spontaneously by any LSR having
detected a more optimal path.
The above mechanisms SHOULD be used for a contiguous inter-domain TE
LSP to allow the head-end LSR of the inter-domain TE LSP to initiate
Ayyangar and Vasseur [Page 13]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
make-before-break procedures. For nested or stitched TE LSPs, it is
possible to re-optimize the local FA-LSP or LSP segment without
involving the head-end LSR of the inter-domain TE LSP. This will
automatically re-route the traffic for the inter-domain TE LSP along
the new path, within the domain. Such local re-optimizations,
including parameters for re-optimization can be controlled by local
policy or configuration in that domain.
7. Security Considerations
When signaling an inter-domain RSVP-TE LSP, an operator may make use
of the already defined security features related to RSVP-TE
(authentication). This may require some coordination between the
domains to share the keys (see RFC 2747 and RFC 3097).
8. IANA Considerations
The following values have to be defined by IANA for this document.
The registry is, http://www.iana.org/assignments/rsvp-parameters.
8.1. Attribute Flags for LSP_ATTRIBUTES object
The following two new flag bits are being defined for the Attributes
Flags TLV in the LSP_ATTRIBUTES object. The numeric values should be
assigned by IANA.
Contiguous LSP bit - 0x01 (Suggested value)
LSP stitching desired bit - 0x02 (Suggested value)
Both these flag bits are only to be used in the Attributes Flags TLV
on a Path message.
The 'LSP stitching desired bit' has a corresponding 'LSP segment
stitching ready' bit to be used in the RRO Attributes sub-object.
8.2. New Error Codes
The following two new error sub-codes are being defined under the
RSVP error-code "Routing Problem" (24). The numeric error sub-code
values should be assigned by IANA.
Contiguous LSP type not supported - sub-code 17 (Suggested value)
Stitching unsupported - sub-code 16 (Suggested value)
Ayyangar and Vasseur [Page 14]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
These error codes are to be used only in a RSVP PathErr.
9. Acknowledgements
The authors would like to acknowledge the input and helpful comments
from Adrian Farrel on various aspects discussed in the document.
10. Intellectual Property Consideration
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
10.1. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Ayyangar and Vasseur [Page 15]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
11. References
11.1. Normative References
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF", RFC 3630 (Updates RFC 2370), September 2003.
[ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic
Engineering", RFC 3784
[INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering
requirements", (work in progress).
[INTER-AREA-TE-REQS] LeRoux JL, Vasseur JP, Boyle J. et al,
"Requirements for support of Inter-Area MPLS Traffic Engineering",
(work in progress).
[INTER-DOMAIN-FRAMEWORK] Farrel A. et al, "A Framework for Inter-
Domain MPLS Traffic Engineering", (work in progress).
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.
[RSVP-GMPLS] L. Berger, et al, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[LSP-HIERARCHY] Kompella K., Rekhter Y., "LSP Hierarchy with
Generalized MPLS TE", (work in progress).
[INTER-DOMAIN-PATH-COMP] Vasseur JP., Ayyangar A., Zhang R., "Inter-
domain MPLS Traffic Engineering LSP path computation methods", (work
in progress).
[CRANKBACK] Farrel A. et al, "Crankback Signaling Extensions for MPLS
Signaling", (work in progress).
[LSP-ATTRIBUTES] Farrel A. et al, "Encoding of Attributes for
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
Establishment Using RSVP-TE", (work in progress).
[FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", (work in progress)
[NODE-ID] Vasseur, Ali and Sivabalan, "Definition of an RRO node-id
subobject", (work in progress).
[LOOSE-REOPT] Vasseur JP. et al, "Reoptimization of an explicit
Ayyangar and Vasseur [Page 16]
draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt July 2004
loosely routed MPLS TE paths", (work in progress).
11.2. Informative References
[GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay
Model", (work in progress).
12. Author Information
Arthi Ayyangar
Juniper Networks, Inc.
1194 N.Mathilda Ave
Sunnyvale, CA 94089
USA
e-mail: arthi@juniper.net
Jean Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
e-mail: jpv@cisco.com
13. Full Copyright Notice
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Ayyangar and Vasseur [Page 17]