draft-ietf-ccamp-lsp-stitching-02.txt   draft-ietf-ccamp-lsp-stitching-03.txt 
Network Working Group A. Ayyangar, Ed. Network Working Group A. Ayyangar, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Expires: March 26, 2006 JP. Vasseur Expires: September 6, 2006 JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
September 22, 2005 March 5, 2006
Label Switched Path Stitching with Generalized MPLS Traffic Engineering Label Switched Path Stitching with Generalized MPLS Traffic Engineering
draft-ietf-ccamp-lsp-stitching-02.txt draft-ietf-ccamp-lsp-stitching-03.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 35 skipping to change at page 1, line 35
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 March 26, 2006. This Internet-Draft will expire on September 6, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
In certain scenarios, there may be a need to combine together In certain scenarios, there may be a need to combine together
different Generalized Multi-Protocol Label Switching (GMPLS) Label different Generalized Multi-Protocol Label Switching (GMPLS) Label
Switched Paths (LSPs) such that in the data plane, a single end-to- Switched Paths (LSPs) such that in the data plane, a single end-to-
end (e2e) LSP is realized and all traffic from one LSP is switched end (e2e) LSP is realized and all traffic from one LSP is switched
onto the other LSP. We will refer to this as "LSP stitching". This onto the other LSP. We will refer to this as "LSP stitching". This
document covers cases where: a) the node performing the stitching document covers cases where: a) the node performing the stitching
does not require configuration of every LSP pair to be stitched does not require configuration of every LSP pair to be stitched
skipping to change at page 2, line 19 skipping to change at page 2, line 19
It may be possible to configure a GMPLS node to switch the traffic It may be possible to configure a GMPLS node to switch the traffic
from an LSP for which it is the egress, to another LSP for which it from an LSP for which it is the egress, to another LSP for which it
is the ingress, without requiring any signaling or routing extensions is the ingress, without requiring any signaling or routing extensions
whatsoever, completely transparent to other nodes. This will also whatsoever, completely transparent to other nodes. This will also
result in LSP stitching in the data plane. However, this document result in LSP stitching in the data plane. However, this document
does not cover this scenario of LSP stitching. does not cover this scenario of LSP stitching.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
2. Comparison with LSP Hierarchy . . . . . . . . . . . . . . . . 4 2. Comparison with LSP Hierarchy . . . . . . . . . . . . . . . . 4
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Triggers for LSP segment setup . . . . . . . . . . . . . . 5 3.1. Triggers for LSP segment setup . . . . . . . . . . . . . . 5
3.2 Applications . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Applications . . . . . . . . . . . . . . . . . . . . . . . 5
4. Routing aspects . . . . . . . . . . . . . . . . . . . . . . . 6 4. Routing aspects . . . . . . . . . . . . . . . . . . . . . . . 6
5. Signaling aspects . . . . . . . . . . . . . . . . . . . . . . 7 5. Signaling aspects . . . . . . . . . . . . . . . . . . . . . . 7
5.1 RSVP-TE signaling extensions . . . . . . . . . . . . . . . 7 5.1. RSVP-TE signaling extensions . . . . . . . . . . . . . . . 7
5.1.1 Creating and preparing LSP segment for stitching . . . 7 5.1.1. Creating and preparing LSP segment for stitching . . . 7
5.1.2 Stitching the e2e LSP to the LSP segment . . . . . . . 9 5.1.2. Stitching the e2e LSP to the LSP segment . . . . . . . 9
5.1.3 RRO Processing for e2e LSP . . . . . . . . . . . . . . 10 5.1.3. RRO Processing for e2e LSP . . . . . . . . . . . . . . 10
5.1.4 Teardown of LSP segment . . . . . . . . . . . . . . . 11 5.1.4. Teardown of LSP segment . . . . . . . . . . . . . . . 11
5.1.5 Teardown of e2e LSP . . . . . . . . . . . . . . . . . 11 5.1.5. Teardown of e2e LSP . . . . . . . . . . . . . . . . . 11
5.2 Summary of LSP Stitching procedures . . . . . . . . . . . 12 5.2. Summary of LSP Stitching procedures . . . . . . . . . . . 12
5.2.1 Example topology . . . . . . . . . . . . . . . . . . . 12 5.2.1. Example topology . . . . . . . . . . . . . . . . . . . 12
5.2.2 LSP segment setup . . . . . . . . . . . . . . . . . . 12 5.2.2. LSP segment setup . . . . . . . . . . . . . . . . . . 12
5.2.3 Setup of e2e LSP . . . . . . . . . . . . . . . . . . . 13 5.2.3. Setup of e2e LSP . . . . . . . . . . . . . . . . . . . 13
5.2.4 Stitching of e2e LSP into an LSP segment . . . . . . . 13 5.2.4. Stitching of e2e LSP into an LSP segment . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1 Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 15 7.1. Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 15
7.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 15 7.2. New Error Codes . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
This document describes the mechanisms to accomplish LSP stitching in This document describes the mechanisms to accomplish LSP stitching in
the scenarios described above. the scenarios described above.
LSP hierarchy ([2]) provides signaling and routing procedures so LSP hierarchy ([2]) provides signaling and routing procedures so
that: that:
a. A Hierarchical LSP (H-LSP) can be created. Such an LSP created a. A Hierarchical LSP (H-LSP) can be created. Such an LSP created
skipping to change at page 3, line 42 skipping to change at page 3, line 42
A stitched TE LSP comprises of different LSP segments (S-LSPs) that A stitched TE LSP comprises of different LSP segments (S-LSPs) that
are connected together in the data plane in such a way that a single are connected together in the data plane in such a way that a single
end-to-end LSP is realized in the data plane. In this document, we end-to-end LSP is realized in the data plane. In this document, we
define the concept of LSP stitching and detail the control plane define the concept of LSP stitching and detail the control plane
mechanisms and procedures to accomplish this. Where applicable, mechanisms and procedures to accomplish this. Where applicable,
similarities and differences between LSP hierarchy and LSP stitching similarities and differences between LSP hierarchy and LSP stitching
are highlighted. Signaling extensions required for LSP stitching are are highlighted. Signaling extensions required for LSP stitching are
also described here. also described here.
1.1 Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
2. Comparison with LSP Hierarchy 2. Comparison with LSP Hierarchy
In case of LSP stitching, instead of an H-LSP, an "LSP segment" In case of LSP stitching, instead of an H-LSP, an "LSP segment"
(S-LSP) is created between two GMPLS nodes. An S-LSP for stitching (S-LSP) is created between two GMPLS nodes. An S-LSP for stitching
is considered to be the moral equivalent of an H-LSP for nesting. An is considered to be the moral equivalent of an H-LSP for nesting. An
skipping to change at page 5, line 7 skipping to change at page 5, line 7
Therefore, in the control plane, there is one RSVP session Therefore, in the control plane, there is one RSVP session
corresponding to the e2e LSP as well as one for each S-LSP. The corresponding to the e2e LSP as well as one for each S-LSP. The
creation and termination of an S-LSP may be dictated by creation and termination of an S-LSP may be dictated by
administrative control (statically provisioned) or due to another administrative control (statically provisioned) or due to another
incoming LSP request (dynamic). Triggers for dynamic creation of an incoming LSP request (dynamic). Triggers for dynamic creation of an
S-LSP may be different from that of an H-LSP and will be described in S-LSP may be different from that of an H-LSP and will be described in
detail later. detail later.
3. Usage 3. Usage
3.1 Triggers for LSP segment setup 3.1. Triggers for LSP segment setup
An S-LSP may be created either by administrative control An S-LSP may be created either by administrative control
(configuration trigger) or dynamically due to an incoming LSP (configuration trigger) or dynamically due to an incoming LSP
request. LSP Hierarchy ([2]) defines one possible trigger for request. LSP Hierarchy ([2]) defines one possible trigger for
dynamic creation of FA-LSP by introducing the notion of LSP regions dynamic creation of FA-LSP by introducing the notion of LSP regions
based on Interface Switching Capabilities. As per [2], dynamic FA- based on Interface Switching Capabilities. As per [2], dynamic FA-
LSP creation may be triggered on a node when an incoming LSP request LSP creation may be triggered on a node when an incoming LSP request
crosses region boundaries. However, this trigger MUST NOT be used crosses region boundaries. However, this trigger MUST NOT be used
for creation of S-LSP for LSP stitching as described in this for creation of S-LSP for LSP stitching as described in this
document. In case of LSP stitching, the switching capabilities of document. In case of LSP stitching, the switching capabilities of
the previous hop and the next hop TE links MUST be the same. the previous hop and the next hop TE links MUST be the same.
Therefore, local policies configured on the node SHOULD be used for Therefore, local policies configured on the node SHOULD be used for
dynamic creation of LSP segments. dynamic creation of LSP segments.
Other possible triggers for dynamic creation of both H-LSPs and Other possible triggers for dynamic creation of both H-LSPs and
S-LSPs include cases where an e2e LSP may cross domain boundaries or S-LSPs include cases where an e2e LSP may cross domain boundaries or
satisfy locally configured policies on the node as described in [8]. satisfy locally configured policies on the node as described in [8].
3.2 Applications 3.2. Applications
LSP stitching procedures described in this document are applicable to LSP stitching procedures described in this document are applicable to
GMPLS nodes that need to associate an e2e LSP with another S-LSP of GMPLS nodes that need to associate an e2e LSP with another S-LSP of
the same switching type and LSP hierarchy procedures do not apply. the same switching type and LSP hierarchy procedures do not apply.
E.g. if an e2e lambda LSP traverses an LSP segment TE link which is E.g. if an e2e lambda LSP traverses an LSP segment TE link which is
also lambda switch capable, then in this case LSP hierarchy is not also lambda switch capable, then in this case LSP hierarchy is not
possible. possible.
LSP stitching procedures could be used for inter-domain TE LSP LSP stitching procedures could be used for inter-domain TE LSP
signaling to stitch an inter-domain LSP to a local intra-domain TE signaling to stitch an inter-domain LSP to a local intra-domain TE
skipping to change at page 7, line 19 skipping to change at page 7, line 19
relationship) and will exchange RSVP messages with each other. It relationship) and will exchange RSVP messages with each other. It
may, in fact, be desirable to exchange RSVP Hellos directly between may, in fact, be desirable to exchange RSVP Hellos directly between
the LSP segment end points to allow support for state recovery during the LSP segment end points to allow support for state recovery during
Graceful Restart procedures as described in [4]. Graceful Restart procedures as described in [4].
In order to signal an e2e LSP over an LSP segment, signaling In order to signal an e2e LSP over an LSP segment, signaling
procedures described in section 8.1.1 of [2] MUST be used. procedures described in section 8.1.1 of [2] MUST be used.
Additional signaling extensions for stitching are described in the Additional signaling extensions for stitching are described in the
next section. next section.
5.1 RSVP-TE signaling extensions 5.1. RSVP-TE signaling extensions
The signaling extensions described here MUST be used for stitching an The signaling extensions described here MUST be used for stitching an
e2e packet or non-packet GMPLS LSP ([4]), to an S-LSP. e2e packet or non-packet GMPLS LSP ([4]), to an S-LSP.
Stitching an e2e LSP to an LSP segment involves the following two Stitching an e2e LSP to an LSP segment involves the following two
step process: step process:
a. Creating and preparing the S-LSP for stitching by signaling the a. Creating and preparing the S-LSP for stitching by signaling the
desire to stitch between end points of the S-LSP and desire to stitch between end points of the S-LSP and
b. Stitching the e2e LSP to the S-LSP b. Stitching the e2e LSP to the S-LSP
5.1.1 Creating and preparing LSP segment for stitching 5.1.1. Creating and preparing LSP segment for stitching
If a GMPLS node desires to perform LSP stitching, then it MUST If a GMPLS node desires to perform LSP stitching, then it MUST
indicate this in the Path message for the S-LSP that it plans to use indicate this in the Path message for the S-LSP that it plans to use
for stitching. This signaling explicitly informs the S-LSP egress for stitching. This signaling explicitly informs the S-LSP egress
node that the ingress node is planning to perform stitching over the node that the ingress node is planning to perform stitching over the
S-LSP. Since an S-LSP is not conceptually different from any other S-LSP. Since an S-LSP is not conceptually different from any other
LSP, explicitly signaling 'LSP stitching desired' helps clarify the LSP, explicitly signaling 'LSP stitching desired' helps clarify the
data plane actions to be carried out when the S-LSP is used by some data plane actions to be carried out when the S-LSP is used by some
other e2e LSP. Also, in case of packet LSPs, this is what allows the other e2e LSP. Also, in case of packet LSPs, this is what allows the
egress of the S-LSP to carry out label allocation as explained below. egress of the S-LSP to carry out label allocation as explained below.
skipping to change at page 8, line 47 skipping to change at page 8, line 45
object but does not recognize the Attributes Flags TLV, or supports object but does not recognize the Attributes Flags TLV, or supports
the TLV as well but does not recognize this particular bit, then it the TLV as well but does not recognize this particular bit, then it
SHOULD simply ignore the above request. SHOULD simply ignore the above request.
An ingress node requesting LSP stitching MUST examine the RRO An ingress node requesting LSP stitching MUST examine the RRO
Attributes sub-object Flags corresponding to the egress node for the Attributes sub-object Flags corresponding to the egress node for the
S-LSP, to make sure that stitching actions are carried out at the S-LSP, to make sure that stitching actions are carried out at the
egress node. It MUST NOT use the S-LSP for stitching if the "LSP egress node. It MUST NOT use the S-LSP for stitching if the "LSP
segment stitching ready" bit is cleared. segment stitching ready" bit is cleared.
5.1.1.1 Steps to support Penultimate Hop Popping 5.1.1.1. Steps to support Penultimate Hop Popping
Note that this section is only applicable to packet LSPs that use Note that this section is only applicable to packet LSPs that use
Penultimate Hop Popping (PHP) at the last hop, where the egress node Penultimate Hop Popping (PHP) at the last hop, where the egress node
distributes the Implicit NULL Label ([9]) in the Resv Label. These distributes the Implicit NULL Label ([9]) in the Resv Label. These
steps MUST NOT be used for a non-packet LSP and for packet LSPs where steps MUST NOT be used for a non-packet LSP and for packet LSPs where
PHP is not desired. PHP is not desired.
When the egress node of an S-LSP receives a Path message for an e2e When the egress node of an S-LSP receives a Path message for an e2e
LSP using this S-LSP and this is a packet LSP, it SHOULD first check LSP using this S-LSP and this is a packet LSP, it SHOULD first check
if it is also the egress for the e2e LSP. If the egress node is the if it is also the egress for the e2e LSP. If the egress node is the
egress for both the S-LSP as well as the e2e TE LSP, and this is a egress for both the S-LSP as well as the e2e TE LSP, and this is a
packet LSP which requires PHP, then the node MUST send back a Resv packet LSP which requires PHP, then the node MUST send back a Resv
trigger message for the S-LSP with a new label corresponding to the trigger message for the S-LSP with a new label corresponding to the
Implicit NULL label. Note that this operation does not cause any Implicit NULL label. Note that this operation does not cause any
traffic disruption since the S-LSP is not carrying any traffic at traffic disruption since the S-LSP is not carrying any traffic at
this time, since the e2e LSP has not yet been established. this time, since the e2e LSP has not yet been established.
5.1.2 Stitching the e2e LSP to the LSP segment 5.1.2. Stitching the e2e LSP to the LSP segment
When a GMPLS node receives an e2e LSP request, depending on the When a GMPLS node receives an e2e LSP request, depending on the
applicable trigger, it may either dynamically create an S-LSP based applicable trigger, it may either dynamically create an S-LSP based
on procedures described above or it may map an e2e LSP to an existing on procedures described above or it may map an e2e LSP to an existing
S-LSP. The switching type in the Generalized Label Request of the S-LSP. The switching type in the Generalized Label Request of the
e2e LSP MUST be equal to the switching type of the S-LSP. Other e2e LSP MUST be equal to the switching type of the S-LSP. Other
constraints like ERO, bandwidth, local TE policies MUST also be used constraints like ERO, bandwidth, local TE policies MUST also be used
for S-LSP selection or signaling. In either case, once an S-LSP has for S-LSP selection or signaling. In either case, once an S-LSP has
been selected for an e2e LSP, the following procedures MUST be been selected for an e2e LSP, the following procedures MUST be
followed in order to stitch an e2e LSP to an S-LSP. followed in order to stitch an e2e LSP to an S-LSP.
skipping to change at page 10, line 37 skipping to change at page 10, line 35
stitching the recepients of the Label/Upstream Label MUST NOT process stitching the recepients of the Label/Upstream Label MUST NOT process
these labels. Also, at most one e2e LSP is associated with one these labels. Also, at most one e2e LSP is associated with one
S-LSP. If a node at the head-end of an S-LSP receives a Path Msg for S-LSP. If a node at the head-end of an S-LSP receives a Path Msg for
an e2e LSP that identifies the S-LSP in the ERO and the S-LSP an e2e LSP that identifies the S-LSP in the ERO and the S-LSP
bandwidth has already been allocated to some other LSP, then regular bandwidth has already been allocated to some other LSP, then regular
rules of RSVP-TE pre-emption apply to resolve contention for S-LSP rules of RSVP-TE pre-emption apply to resolve contention for S-LSP
bandwidth. If the LSP request over the S-LSP cannot be satisfied, bandwidth. If the LSP request over the S-LSP cannot be satisfied,
then the node SHOULD send back a PathErr with the error codes as then the node SHOULD send back a PathErr with the error codes as
described in [5]. described in [5].
5.1.3 RRO Processing for e2e LSP 5.1.3. RRO Processing for e2e LSP
RRO procedures for the S-LSP specific to LSP stitching are already RRO procedures for the S-LSP specific to LSP stitching are already
described in Section 5.1.1. In this section we will look at the RRO described in Section 5.1.1. In this section we will look at the RRO
processing for the e2e LSP over the S-LSP hop. processing for the e2e LSP over the S-LSP hop.
An e2e LSP traversing an S-LSP, SHOULD record in the RRO for that An e2e LSP traversing an S-LSP, SHOULD record in the RRO for that
hop, an identifier corresponding to the S-LSP TE link. This is hop, an identifier corresponding to the S-LSP TE link. This is
applicable to both Path and Resv messages over the S-LSP hop. If the applicable to both Path and Resv messages over the S-LSP hop. If the
S-LSP is numbered, then the IPv4 or IPv6 address subobject ([5]) S-LSP is numbered, then the IPv4 or IPv6 address subobject ([5])
SHOULD be used to record the S-LSP TE link address. If the S-LSP is SHOULD be used to record the S-LSP TE link address. If the S-LSP is
unnumbered, then the Unnumbered Interface ID subobject as described unnumbered, then the Unnumbered Interface ID subobject as described
in [10] SHOULD be used to record the node's Router ID and Interface in [10] SHOULD be used to record the node's Router ID and Interface
ID of the S-LSP TE link. In either case, the RRO subobject SHOULD ID of the S-LSP TE link. In either case, the RRO subobject SHOULD
identify the S-LSP TE link end point. Intermediate links or nodes identify the S-LSP TE link end point. Intermediate links or nodes
traversed by the S-LSP itself SHOULD NOT be recorded in the RRO for traversed by the S-LSP itself SHOULD NOT be recorded in the RRO for
the e2e LSP over the S-LSP hop. the e2e LSP over the S-LSP hop.
5.1.4 Teardown of LSP segment 5.1.4. Teardown of LSP segment
S-LSP teardown follows the standard procedures defined in [5] and S-LSP teardown follows the standard procedures defined in [5] and
[4]. This includes procedures without and with setting the [4]. This includes procedures without and with setting the
administrative status. Teardown of S-LSP may be initiated by either administrative status. Teardown of S-LSP may be initiated by either
the ingress, egress or any other node along the S-LSP path. the ingress, egress or any other node along the S-LSP path.
Deletion/teardown of the S-LSP SHOULD be treated as a failure event Deletion/teardown of the S-LSP SHOULD be treated as a failure event
for the e2e LSP associated with it and corresponding teardown or for the e2e LSP associated with it and corresponding teardown or
recovery procedures SHOULD be triggered for the e2e LSP. In case of recovery procedures SHOULD be triggered for the e2e LSP. In case of
S-LSP teardown for maintenance purpose, the S-LSP ingress node MAY S-LSP teardown for maintenance purpose, the S-LSP ingress node MAY
treat this to be equivalent to administratively shutting down a TE treat this to be equivalent to administratively shutting down a TE
link along the e2e LSP path and take corresponding actions to notify link along the e2e LSP path and take corresponding actions to notify
the ingress of this event. The actual signaling procedures to handle the ingress of this event. The actual signaling procedures to handle
this event is out of the scope of this document. this event is out of the scope of this document.
5.1.5 Teardown of e2e LSP 5.1.5. Teardown of e2e LSP
e2e LSP teardown also follows standard procedures defined in [5] and e2e LSP teardown also follows standard procedures defined in [5] and
[4] either without or with the administrative status. Note, however, [4] either without or with the administrative status. Note, however,
that teardown procedures of e2e LSP and of S-LSP are independent of that teardown procedures of e2e LSP and of S-LSP are independent of
each other. So, it is possible that while one LSP follows graceful each other. So, it is possible that while one LSP follows graceful
teardown with adminstrative status, the other LSP is torn down teardown with adminstrative status, the other LSP is torn down
without administrative status (using PathTear/ResvTear/PathErr with without administrative status (using PathTear/ResvTear/PathErr with
state removal). state removal).
When an e2e LSP teardown is initiated from the head-end, and a When an e2e LSP teardown is initiated from the head-end, and a
skipping to change at page 12, line 14 skipping to change at page 12, line 11
was dynamically setup due to the e2e LSP setup request, then was dynamically setup due to the e2e LSP setup request, then
depending on local policy, the S-LSP MAY be torn down if no e2e LSP depending on local policy, the S-LSP MAY be torn down if no e2e LSP
is utilizing the S-LSP. Although the S-LSP may be torn down while is utilizing the S-LSP. Although the S-LSP may be torn down while
the e2e LSP is being torn down, it is RECOMMENDED that a delay be the e2e LSP is being torn down, it is RECOMMENDED that a delay be
introduced in tearing down the S-LSP once the e2e LSP teardown is introduced in tearing down the S-LSP once the e2e LSP teardown is
complete, in order to reduce the simultaneous generation of RSVP complete, in order to reduce the simultaneous generation of RSVP
errors and teardown messages due to multiple events. The delay errors and teardown messages due to multiple events. The delay
interval may be set based on local implementation. The RECOMMENDED interval may be set based on local implementation. The RECOMMENDED
interval is 30 seconds. interval is 30 seconds.
5.2 Summary of LSP Stitching procedures 5.2. Summary of LSP Stitching procedures
5.2.1 Example topology 5.2.1. Example topology
The following topology will be used for the purpose of examples The following topology will be used for the purpose of examples
quoted in the following sections. quoted in the following sections.
e2e LSP e2e LSP
++++++++++++++++++++++++++++++++++> (LSP1-2) ++++++++++++++++++++++++++++++++++> (LSP1-2)
LSP segment (S-LSP) LSP segment (S-LSP)
=====================> (LSP-AB) =====================> (LSP-AB)
C --- E --- G C --- E --- G
skipping to change at page 12, line 45 skipping to change at page 12, line 42
RESV RESV
<====================== (LSP segment stitching ready) <====================== (LSP segment stitching ready)
PATH (Upstream Label) PATH (Upstream Label)
+++++++++++++++++++++++ +++++++++++++++++++++++
++++++ +++++> ++++++ +++++>
<++++++ ++++++ <++++++ ++++++
+++++++++++++++++++++++ +++++++++++++++++++++++
RESV (Label) RESV (Label)
5.2.2 LSP segment setup 5.2.2. LSP segment setup
Let us consider an S-LSP LSP-AB being setup between two nodes A and B Let us consider an S-LSP LSP-AB being setup between two nodes A and B
which are more than one hop away. Node A sends a Path message for which are more than one hop away. Node A sends a Path message for
the LSP-AB with "LSP stitching desired" set in Flags field of the LSP-AB with "LSP stitching desired" set in Flags field of
LSP_ATTRIBUTES object. If the egress node B is ready to carry out LSP_ATTRIBUTES object. If the egress node B is ready to carry out
stitching procedures, then B will respond with "LSP segment stitching stitching procedures, then B will respond with "LSP segment stitching
ready" set in the Flags field of the RRO Attributes subobject, in the ready" set in the Flags field of the RRO Attributes subobject, in the
RRO sent in the Resv for the S-LSP. Once A receives the Resv for RRO sent in the Resv for the S-LSP. Once A receives the Resv for
LSP-AB and sees this bit set in the RRO, it can then use LSP-AB for LSP-AB and sees this bit set in the RRO, it can then use LSP-AB for
stitching. A cannot use LSP-AB for stitching if the bit is cleared stitching. A cannot use LSP-AB for stitching if the bit is cleared
in the RRO. in the RRO.
5.2.3 Setup of e2e LSP 5.2.3. Setup of e2e LSP
Let us consider an e2e LSP LSP1-2 starting one hop before A on R1 and Let us consider an e2e LSP LSP1-2 starting one hop before A on R1 and
ending on node R2, as shown above. If the S-LSP has been adevrtised ending on node R2, as shown above. If the S-LSP has been adevrtised
as a TE link in the TE domain, and R1 and A are in the same domain, as a TE link in the TE domain, and R1 and A are in the same domain,
then R1 may compute a path for LSP1-2 over the S-LSP LSP-AB and then R1 may compute a path for LSP1-2 over the S-LSP LSP-AB and
identify the LSP-AB hop in the ERO. If not, R1 may compute hops identify the LSP-AB hop in the ERO. If not, R1 may compute hops
between A and B and A may use these ERO hops for S-LSP selection or between A and B and A may use these ERO hops for S-LSP selection or
signaling a new S-LSP. Also, an S-LSP TE link cannot be signaling a new S-LSP. Also, an S-LSP TE link cannot be
distinguished from any basic TE link on R1. If R1 and A are in distinguished from any basic TE link on R1. If R1 and A are in
different domains, then LSP1-2 is an inter-domain LSP. In this case, different domains, then LSP1-2 is an inter-domain LSP. In this case,
S-LSP LSP-AB, similar to any other basic TE link in the domain will S-LSP LSP-AB, similar to any other basic TE link in the domain will
not be advertised outside the domain. R1 would use either per-domain not be advertised outside the domain. R1 would use either per-domain
path computation ([12]) or PCE based computation ([13]) for LSP1-2. path computation ([12]) or PCE based computation ([13]) for LSP1-2.
5.2.4 Stitching of e2e LSP into an LSP segment 5.2.4. Stitching of e2e LSP into an LSP segment
When the Path message for the e2e LSP LSP1-2 arrives at node A, A When the Path message for the e2e LSP LSP1-2 arrives at node A, A
matches the switching type of LSP1-2 with the S-LSP LSP-AB. If the matches the switching type of LSP1-2 with the S-LSP LSP-AB. If the
switching types are not equal, then LSP-AB cannot be used to stitch switching types are not equal, then LSP-AB cannot be used to stitch
LSP1-2. Once S-LSP LSP-AB to stitch LSP1-2 to has been determined LSP1-2. Once S-LSP LSP-AB to stitch LSP1-2 to has been determined
successfully, the Path message for LSP1-2 is IP routed to node B with successfully, the Path message for LSP1-2 is IP routed to node B with
the IF_ID RSVP_HOP identifying the S-LSP LSP-AB. When B receives the IF_ID RSVP_HOP identifying the S-LSP LSP-AB. When B receives
this Path message for LSP1-2, if B is also the egress for LSP1-2, and this Path message for LSP1-2, if B is also the egress for LSP1-2, and
if this is a packet LSP requiring PHP, then B will send a Resv if this is a packet LSP requiring PHP, then B will send a Resv
refresh for LSP-AB with the NULL Label. In this case, since B is not refresh for LSP-AB with the NULL Label. In this case, since B is not
skipping to change at page 15, line 10 skipping to change at page 15, line 10
destination address of Path and PathTear messages to be the IP destination address of Path and PathTear messages to be the IP
address of a nexthop node (receiver's address) instead of the RSVP address of a nexthop node (receiver's address) instead of the RSVP
session destination address. So, [6] should be revisited to check if session destination address. So, [6] should be revisited to check if
IPSec AH is now a viable means of securing RSVP-TE messages. IPSec AH is now a viable means of securing RSVP-TE messages.
7. IANA Considerations 7. 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.
7.1 Attribute Flags for LSP_ATTRIBUTES object 7.1. Attribute Flags for LSP_ATTRIBUTES object
The following new bit is being defined for the Attributes Flags TLV The following new bit is being defined for the Attributes Flags TLV
in the LSP_ATTRIBUTES object. The numeric value should be assigned in the LSP_ATTRIBUTES object. The numeric value should be assigned
by IANA. by IANA.
LSP stitching desired bit - Bit Number 5 (Suggested value) LSP stitching desired bit - Bit Number 5 (Suggested value)
This bit is only to be used in the Attributes Flags TLV on a Path This bit is only to be used in the Attributes Flags TLV on a Path
message. message.
The 'LSP stitching desired bit' has a corresponding 'LSP segment The 'LSP stitching desired bit' has a corresponding 'LSP segment
stitching ready' bit (Bit Number 5) to be used in the RRO Attributes stitching ready' bit (Bit Number 5) to be used in the RRO Attributes
sub-object. sub-object.
7.2 New Error Codes 7.2. New Error Codes
The following new error sub-code is being defined under the RSVP The following new error sub-code is 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.
Stitching unsupported - sub-code 23 (Suggested value) Stitching unsupported - sub-code 23 (Suggested value)
This error code is to be used only in an RSVP PathErr. This error code is to be used only in an RSVP PathErr.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Adrian Farrel and Kireeti Kompella The authors would like to thank Adrian Farrel and Kireeti Kompella
for their comments and suggestions. The authors would also like to for their comments and suggestions. The authors would also like to
thank Dimitri Papadimitriou and Igor Bryskin for their thorough thank Dimitri Papadimitriou and Igor Bryskin for their thorough
review of the document and discussions regarding the same. review of the document and discussions regarding the same.
9. References 9. References
9.1 Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized [2] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08 (work in progress), Hierarchy with Generalized Multi-Protocol Label Switching
September 2002. (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[3] Farrel, A., "Encoding of Attributes for Multiprotocol Label [3] Farrel, A., Papadimitriou, D., Vasseur, J., and A. Ayyangar,
Switching (MPLS) Label Switched Path (LSP) Establishment Using "Encoding of Attributes for Multiprotocol Label Switching (MPLS)
RSVP-TE", draft-ietf-mpls-rsvpte-attributes-05 (work in Label Switched Path (LSP) Establishment Using Resource
progress), May 2005. ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420,
February 2006.
[4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) [4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic Engineering Signaling Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensions", RFC 3473, January 2003. (RSVP-TE) Extensions", RFC 3473, January 2003.
[5] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. [5] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001. RFC 3209, December 2001.
[6] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [6] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
9.2 Informative References 9.2. Informative References
[7] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE [7] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE
LSPs", draft-ietf-mpls-rsvp-te-p2mp-01 (work in progress), LSPs", draft-ietf-mpls-rsvp-te-p2mp-01 (work in progress),
January 2005. January 2005.
[8] Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic [8] Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensions", Engineering - RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-00 (work in progress), draft-ietf-ccamp-inter-domain-rsvp-te-00 (work in progress),
February 2005. February 2005.
[9] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, [9] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci,
D., Li, T., and A. Conta, "MPLS Label Stack Encoding", D., Li, T., and A. Conta, "MPLS Label Stack Encoding",
RFC 3032, January 2001. RFC 3032, January 2001.
[10] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in [10] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in
Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)",
RFC 3477, January 2003. RFC 3477, January 2003.
[11] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in [11] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in
MPLS Traffic Engineering", draft-ietf-mpls-bundle-06 (work in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
progress), December 2004.
[12] Vasseur, J., "A Per-domain path computation method for [12] Vasseur, J., "A Per-domain path computation method for
computing Inter-domain Traffic Engineering (TE) Label Switched computing Inter-domain Traffic Engineering (TE) Label Switched
Path (LSP)", draft-vasseur-ccamp-inter-domain-pd-path-comp-00 Path (LSP)", draft-ietf-ccamp-inter-domain-pd-path-comp-00
(work in progress), February 2005. (work in progress), April 2005.
[13] Farrel, A., "Path Computation Element (PCE) Architecture", [13] Farrel, A., "Path Computation Element (PCE) Architecture",
draft-ietf-pce-architecture-00 (work in progress), March 2005. draft-ietf-pce-architecture-00 (work in progress), March 2005.
Authors' Addresses Authors' Addresses
Arthi Ayyangar (editor) Arthi Ayyangar (editor)
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
skipping to change at page 19, line 41 skipping to change at page 20, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 34 change blocks. 
56 lines changed or deleted 56 lines changed or added

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