draft-ietf-ccamp-lsp-stitching-00.txt   draft-ietf-ccamp-lsp-stitching-01.txt 
Network Working Group A. Ayyangar, Ed. Network Working Group A. Ayyangar, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Expires: October 3, 2005 JP. Vasseur Expires: January 16, 2006 JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
April 2005 July 15, 2005
Label Switched Path Stitching with Generalized MPLS Traffic Label Switched Path Stitching with Generalized MPLS Traffic Engineering
Engineering draft-ietf-ccamp-lsp-stitching-01.txt
draft-ietf-ccamp-lsp-stitching-00
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 October 3, 2005. This Internet-Draft will expire on January 16, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
In certain scenarios, there may be a need to combine together two In certain scenarios, there may be a need to combine together two
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 Switched Paths (LSPs) such that in the data plane, a single end-to-
end-to-end (e2e) LSP is achieved and all traffic from one LSP is end (e2e) LSP is achieved and all traffic from one LSP is switched
switched onto the other LSP. We will refer to this as "LSP onto the other LSP. We will refer to this as "LSP stitching". This
stitching". This document covers cases where: a) the node performing document covers cases where: a) the node performing the stitching
the stitching does not require configuration of every LSP pair to be does not require configuration of every LSP pair to be stitched
stitched together b) the node performing the stitching is not the together b) the node performing the stitching is not the egress of
egress of any of the LSPs c) LSP stitching not only results in an any of the LSPs c) LSP stitching not only results in an end-to-end
end-to-end LSP in the data plane, but there is also a corresponding LSP in the data plane, but there is also a corresponding end-to-end
end-to-end LSP (RSVP session) in the control plane. It might be LSP (RSVP session) in the control plane. It might be possible to
possible to configure a GMPLS node to switch the traffic from an LSP configure a GMPLS node to switch the traffic from an LSP for which it
for which it is the egress, to another LSP for which it is the is the egress, to another LSP for which it is the ingress, without
ingress, without requiring any signaling or routing extensions requiring any signaling or routing extensions whatsoever, completely
whatsoever, completely transparent to other nodes. This will also transparent to other nodes. This will also result in LSP stitching
result in LSP stitching in the data plane. However, this document in the data plane. However, this document does not cover this
does not cover this scenario of LSP stitching. scenario of LSP stitching.
This document describes the mechanisms to accomplish LSP stitching in
the scenarios described above.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions used in this document . . . . . . . . . . . . 5 1.1 Conventions used in this document . . . . . . . . . . . . 4
2. Routing aspects . . . . . . . . . . . . . . . . . . . . . . . 6 2. Routing aspects . . . . . . . . . . . . . . . . . . . . . . . 5
3. Signaling aspects . . . . . . . . . . . . . . . . . . . . . . 7 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 RSVP-TE signaling extensions . . . . . . . . . . . . . . . 7 3.1 LSP regions and LSP stitching . . . . . . . . . . . . . . 6
4. Summary of LSP Stitching procedures . . . . . . . . . . . . . 10 3.2 Applications . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 LSP segment setup . . . . . . . . . . . . . . . . . . . . 10 4. Signaling aspects . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Setup of e2e LSP . . . . . . . . . . . . . . . . . . . . . 10 4.1 RSVP-TE signaling extensions . . . . . . . . . . . . . . . 7
4.3 Stitching of e2e LSP into an LSP segment . . . . . . . . . 10 4.1.1 Creating and preparing LSP segment for stitching . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4.1.2 Stitching the e2e LSP to the LSP segment . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4.1.3 RRO Processing for e2e LSP . . . . . . . . . . . . . . 9
6.1 Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 13 4.2 Summary of LSP Stitching procedures . . . . . . . . . . . 10
6.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 13 4.2.1 Example topology . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2 LSP segment setup . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.3 Setup of e2e LSP . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . 15 4.2.4 Stitching of e2e LSP into an LSP segment . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . 15 4.2.5 Teardown of e2e LSP . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1 Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 15
6.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1 Normative References . . . . . . . . . . . . . . . . . . . 17
8.2 Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
1. Introduction 1. Introduction
This document describes the mechanisms to accomplish LSP stitching in
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 GMPLS node can form a forwarding adjacency (FA) over the FA LSP a. a GMPLS node can form a forwarding adjacency (FA) over the FA LSP
b. other Label Switching Routers (LSRs) can see this FA LSP as a b. other Label Switching Routers (LSRs) can see this FA LSP as a
Traffic Engineering (TE) link Traffic Engineering (TE) link, when needed.
c. the GMPLS node can nest one or more LSPs over the FA LSP. This c. the GMPLS node can nest one or more LSPs over the FA LSP. This
covers intra-domain LSPs only. only covers LSPs in a single domain.
d. RSVP signaling for LSP setup can occur between nodes that do not d. RSVP signaling for LSP setup can occur between nodes that do not
have routing adjacency. have routing adjacency.
LSP stitching is a special case of LSP hierarchy. In case of LSP LSP stitching is a special case of LSP hierarchy. In case of LSP
stitching, instead of an FA LSP, we will create an "LSP segment" stitching, instead of an FA LSP, an "LSP segment" is created between
between two GMPLS nodes. So an LSP segment for stitching is two GMPLS nodes. So an LSP segment for stitching is considered to be
considered to be the moral equivalent of an FA LSP for nesting. the moral equivalent of an FA LSP for nesting and an LSP segment TE
While LSP hierarchy allows more that one LSP to be admitted into the link is a moral equivalent of FA (FA-LSP TE link). While LSP
FA-LSP, in case of LSP stitching, the desired switching type of the hierarchy allows more that one LSP to be mapped to an FA-LSP, in case
LSP and the switching capability of the LSP segment are such that at of LSP stitching, at most one LSP may be mapped to an LSP segment.
most one LSP may be admitted into an LSP segment. E.g. if LSP-AB is E.g. if LSP-AB is an FA-LSP between nodes A and B, then multiple
an FA-LSP between nodes A and B, then multiple LSPs, say LSP1, LSP2, LSPs, say LSP1, LSP2, LSP3 could potentially be 'nested into' LSP-AB.
LSP3 could potentially be 'nested into' LSP-AB. This is achieved by This is achieved by exchanging a unique label for each of LSP1..3
exchanging a unique label for each of LSP1..3 over the LSP-AB hop over the LSP-AB hop thereby permitting LSP1..3 to share the FA-LSP
thereby permitting LSP1..3 to share the FA-LSP LSP-AB. Each of LSP-AB. Each of LSP1..3 may reserve some bandwidth on LSP-AB. On
LSP1..3 may reserve some bandwidth on LSP-AB. On the other hand, if the other hand, if LSP-AB is an LSP segment, then at most one LSP,
LSP-AB is an LSP segment, then at most one LSP, say LSP1 may be say LSP1 may be 'stitched to' the LSP segment LSP-AB. No labels are
'stitched to' the LSP segment LSP-AB. No labels are exchanged for exchanged for LSP1 over the LSP-AB hop directly between nodes A and
LSP1 over the LSP-AB hop (i.e. between A and B directly). B. Therefore LSP-AB is dedicated to LSP1 and no other LSPs can be
Therefore, LSP-AB is dedicated to LSP1 and no other LSPs can be associated with LSP-AB. The entire bandwith on LSP segment LSP-AB is
associated with LSP-AB. The LSPs LSP1..3 which are either nested or allocated to LSP1. The LSPs LSP1..3 which are either nested or
stitched into another LSP are termed as end-to-end (e2e) LSPs in the stitched into another LSP are termed as end-to-end (e2e) LSPs in the
rest of this document. rest of this document.
Signaling and routing procedures for LSP stitching are basically Signaling and routing procedures for LSP stitching are basically
similar to that described in [2]). The LSP segment will be seen seen similar to that described in [2]. The LSP segment, like an FA-LSP is
as a TE link by all nodes in the network. Also, non-adjacent RSVP treated as a TE link. Also, non-adjacent RSVP signaling defined in
signaling defined in [2]) will still be required to stitch an LSP to [2]) is required to stitch an LSP to an LSP segment. So, in the
an LSP segment. So, in the control plane, there is one RSVP session control plane, there is one RSVP session corresponding to the e2e LSP
corresponding to the e2e LSP as well as one for each LSP segment that as well as one for each LSP segment that the e2e LSP is being
the e2e LSP is being stitched to. An LSP segment may be created stitched to. The creation/termination of an LSP segment may be
either via a configuration trigger or dynamically due to an incoming dictated by administrative control (statically provisioned) or due to
LSP request. In this document we will highlight, where applicable, another incoming LSP request (dynamic). Triggers for dynamic
similarities and differences in the routing and signaling procedures creation of an LSP segment are different from that of an FA-LSP and
between LSP hierarchy and LSP stitching. Additional signaling will be described in detail later. In this document, where
extensions required for LSP stitching are also described here. applicable, similarities and differences in the routing and signaling
procedures between LSP hierarchy and LSP stitching are highlighted.
LSP stitching SHOULD be used when the switching types (capabilities) Additional signaling extensions required for LSP stitching are also
of the LSP and the LSP segment are such that LSP hierarchy as described here.
described in [2]) is not possible. E.g. if the e2e LSP is a lambda
LSP and the LSP segment is also a lambda LSP, then in this case LSP
hierarchy is not possible. LSP stitching could also be useful in
networks to bypass legacy nodes which may not have certain new
capabilities in the control plane and/or data plane. E.g. one
suggested usage in case of P2MP RSVP LSPs ([7]) is the use of LSP
stitching to stitch a P2MP RSVP LSP to an LSP segment between P2MP
capable LSRs in the network. The LSP segment would traverse legacy
LSRs that may be incapable of acting as P2MP branch points, thereby
shielding them from the P2MP control and data path. LSP stitching
procedures could also be used for inter-domain TE LSP signaling to
stitch an inter-domain LSP to a local intra-domain TE LSP segment
([8]).
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. Routing aspects 2. Routing aspects
An LSP segment is similar to an FA-LSP in that, an LSP segment like An LSP segment is created and treated like a TE link between two
an FA-LSP is created and treated like a TE link between two GMPLS GMPLS nodes whose path transits zero or more GMPLS nodes in the same
nodes whose path transits zero or more GMPLS nodes in the same
instance of the GMPLS control plane. These TE links may be numbered instance of the GMPLS control plane. These TE links may be numbered
or unnumbered. For an unnumbered LSP segment, the assignment and or unnumbered. For an unnumbered LSP segment, the assignment and
handling of the local and remote link identifiers is specified in handling of the local and remote link identifiers is specified in
[9]. Unlike an FA-LSP, a GMPLS node does not have a data plane [9]. Unlike an FA-LSP, a GMPLS node does not have a data plane
adjacency with the end point of the LSP segment. This implies that adjacency with the end point of the LSP segment. This implies that
the traffic that arrives at the GMPLS node will be switched into the the traffic that arrives at the GMPLS node will be switched into the
LSP segment contiguously with a label swap and no label is exchanged LSP segment contiguously with a label swap and no label is exchanged
directly between the end nodes of the LSP segment itself. Also, a directly between the end nodes of the LSP segment itself. A routing
routing adjacency will not be established over an LSP segment. adjacency will not be established over an LSP segment. ISIS/OSPF
ISIS/OSPF may, however, flood the TE information associated with an may, however, flood the TE information associated with an LSP segment
LSP segment, which will exist in the TE database (TED) and can then TE link, when appropriate. Mechanisms similar to that for regular TE
be used for path computation by other GMPLS nodes in the network. links may be used to flood LSP segment TE links. Advertising or
The TE parameters defined for an FA in [2]) are also applicable to an flooding the LSP segment TE link is not a requirement for LSP
LSP segment TE link. stitching. Discretion should be used when advertising an LSP segment
TE link in IGP. If advertised, this TE information will exist in the
TE database (TED) and can then be used for path computation by other
GMPLS nodes in the network.
Note that, while an FA-LSP TE link can admit zero or more LSPs over The TE parameters defined for an FA in [2]) are exactly applicable to
it, an LSP segment can admit at most one LSP over it. So, once an an LSP segment TE link as well. Note that the switching capability
LSP is stitched into an LSP segment, the unreserved bandwidth on the of an LSP segment TE link MUST be equal to the switching type of the
LSP segment is set to zero. This prevents any more LSPs from being underlying LSP segment; i.e. no hierarchy (nesting) is possible.
computed and admitted over the LSP segment TE link. Multiple LSP
segments between the same pair of nodes may be bundled using the
concept of Link Bundling ([10]) into a single TE link. When any
component LSP segment is allocated for an LSP, the component's
unreserved bandwidth MUST be set to zero and the Minimum and Maximum
LSP bandwidth of the TE link SHOULD be recalculated.
3. Signaling aspects An LSP segment TE link SHOULD NOT admit more than one e2e LSP into
it. So, once an LSP is stitched into an LSP segment, the unreserved
bandwidth on the LSP segment SHOULD be set to zero. This will
prevent any more LSPs from being computed and admitted over the LSP
segment TE link. Multiple LSP segments between the same pair of
nodes may be bundled using the concept of Link Bundling ([10]) into a
single TE link. When any component LSP segment is allocated for an
LSP, the component's unreserved bandwidth SHOULD be set to zero and
the Minimum and Maximum LSP bandwidth of the TE link SHOULD be
recalculated.
In general, the trigger for the creation or termination of an LSP 3. Usage
segment may be either mechanisms which are outside of GMPLS
(configuration of LSP segment on the stitching node) or mechanisms
within GMPLS (arrival of an LSP setup request with appropriate
switching type on the stitching node).
Although not adjacent in routing, the end nodes of the LSP segment 3.1 LSP regions and LSP stitching
will have a signaling adjacency and will exchange RSVP messages
directly between each other. When an RSVP-TE LSP is signaled over an
LSP segment, the Path message MUST contain an IF_ID RSVP_HOP object
[4] and the data interface identification MUST identify the LSP
segment. For the purpose of ERO and RRO as well, an LSP segment is
treated exactly like an FA.
The main difference between signaling an LSP over an LSP segment An LSP segment may be created either by administrative control
instead of over an FA-LSP is that no Labels are allocated and (configuration trigger) or dynamically due to an incoming LSP
exchanged for the e2e LSP over the LSP segment hop. So, at most one request. LSP Hierarchy ([2]) defines one possible trigger for
e2e LSP is associated with one LSP segment. If a node at the dynamic creation of FA-LSP by introducing the notion of LSP regions
head-end of an LSP segment receives a Path Msg for an LSP that based on Interface Switching Capabilities. As per [2], dynamic FA-
identifies the LSP segment in the ERO and the LSP segment bandwidth LSP creation may be triggered on a node when an incoming LSP request
has already been allocated to some other LSP, then regular rules of crosses region boundaries. However, this trigger MUST NOT be used
RSVP-TE pre-emption apply. If the LSP request over the LSP segment for creation of LSP segment for LSP stitching as described in this
cannot be satisfied, then the node SHOULD send back a PathErr with document. In case of LSP stitching, the switching capabilities of
the error codes as described in [5]. the previous hop and the next hop TE links MUST be the same.
Therefore, local policies configured on the node SHOULD be used for
dynamic creation of LSP segments.
Other possible triggers for dynamic creation of both FA-LSPs and LSP
segments include cases where an e2e LSP may cross domain boundaries
or satisfy locally configured policies on the node as described in
[8].
3.2 Applications
LSP stitching procedures described in this document are applicable to
GMPLS nodes that need to associate an e2e LSP with another LSP
segment of 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 also lambda switch capable, then in this case LSP
hierarchy is not possible.
LSP stitching procedures could be used for inter-domain TE LSP
signaling to stitch an inter-domain LSP to a local intra-domain TE
LSP segment ([8]).
LSP stitching could also be useful in networks to bypass legacy nodes
which may not have certain new capabilities in the control plane
and/or data plane. E.g. one suggested usage in case of P2MP RSVP
LSPs ([7]) is the use of LSP stitching to stitch a P2MP RSVP LSP to
an LSP segment between P2MP capable LSRs in the network. The LSP
segment would traverse legacy LSRs that may be incapable of acting as
P2MP branch points, thereby shielding them from the P2MP control and
data path. Note, however, that such configuration may of course
limit the attractiveness of RSVP P2MP and should carefully be
examined before deployment.
4. Signaling aspects
The end nodes of the LSP segment do not have a routing adjacency.
However, they will have a signaling adjacency and will exchange RSVP
messages directly between each other. It may, in fact, be desirable
to exchange RSVP Hellos directly between the LSP segment end points
to allow support for state recovery during Graceful Restart
procedures as described in [4].
In order to signal an e2e LSP over an LSP segment, signaling
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.
3.1 RSVP-TE signaling extensions 4.1 RSVP-TE signaling extensions
The signaling extensions described here MUST be used if the LSP The signaling extensions described here MUST be used if the LSP
segment is a packet LSP and an e2e packet LSP may be stitched to it. segment is a packet LSP and an e2e packet LSP needs to be stitched to
These extensions are optional for non-packet LSPs and SHOULD be used it. These extensions are optional for non-packet LSPs and SHOULD be
if no other local mechanisms exist to automatically detect a used if no other local mechanisms exist to automatically detect a
requirement for stitching at both the ingress and egress nodes of the requirement for stitching at both the ingress and egress GMPLS nodes
LSP segment. of the LSP segment. In cases where such mechanisms exist on these
nodes and there is no need to signal "stitching" explicitly, the
nodes MAY simply follow LSP hierarchy signaling procedures, but
instead of nesting, they will stitch the LSPs in the data plane.
Stitching an e2e LSP to an LSP segment involves the following two
step process :
a. Creating and preparing the LSP segment for stitching by signaling
the desire to stitch between end points of the LSP segment and
b. Stitching the e2e LSP to the LSP segment
4.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 LSP segment that it plans indicate this in the Path message for the LSP segment that it plans
to use for stitching. This signaling explicitly informs the egress to use for stitching. This signaling explicitly informs the egress
node for the LSP segment that the ingress node is planning to perform node for the LSP segment that the ingress node is planning to perform
stitching over the LSP segment. This will allow the egress of the stitching over the LSP segment. This will allow the egress of the
LSP segment to allocate the correct label(s) as explained below. LSP segment to allocate the correct label(s) as explained below.
Also, so that the head-end node can ensure that correct stitching Also, so that the head-end node can ensure that correct stitching
actions were carried out at the egress node, a new flag is defined actions were carried out at the egress node, a new flag is defined
below in the RRO subobject to indicate that the LSP segment can be below in the Record Route Object (RRO) Attributes subobject to
used for stitching. indicate that the LSP segment can be used for stitching.
In order to request LSP stitching on the LSP segment, we define a new In order to request LSP stitching on the LSP segment, we define a new
flag bit in the Attributes Flags TLV of the LSP_ATTRIBUTES object flag bit in the Attributes Flags TLV of the LSP_ATTRIBUTES object
defined in [3]: defined in [3]:
0x02 (TBD): LSP stitching desired bit - This flag will be set in the 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 Attributes Flags TLV of the LSP_ATTRIBUTES object in the Path message
for the LSP segment by the head-end of the LSP segment, that desires for the LSP segment by the head-end of the LSP segment, that desires
LSP stitching. This flag MUST not be modified by any other nodes in LSP stitching. This flag MUST NOT be modified by any other nodes in
the network. the network.
An LSP segment can only be used for stitching if appropriate label An LSP segment can only be used for stitching if appropriate label
actions were carried out at the egress node of the LSP segment. In actions were carried out at the egress node of the LSP segment. In
order to indicate this to the head-end node of the LSP segment, the order to indicate this to the head-end node of the LSP segment, the
following new flag bit is defined in the RRO Attributes sub-object: following new flag bit is defined in the RRO Attributes sub-object:
0x02 (TBD): LSP segment stitching ready. 0x02 (TBD): LSP segment stitching ready.
If an egress node receiving a Path message, supports the If an egress node receiving a Path message, supports the
LSP_ATTRIBUTES object and the Attributes Flags TLV, and also LSP_ATTRIBUTES object and the Attributes Flags TLV, and also
recognizes the "LSP stitching desired" flag bit, but cannot support recognizes the "LSP stitching desired" flag bit, but cannot support
the requested stitching behavior, then it MUST send back a PathErr the requested stitching behavior, then it MUST send back a PathErr
message with an error code of "Routing Problem" and an error message with an error code of "Routing Problem" and an error sub-
sub-code=16 (TBD) "Stitching unsupported" to the head-end node of the code=16 (TBD) "Stitching unsupported" to the head-end node of the LSP
LSP segment. segment.
If an egress node receiving a Path message with the "LSP stitching If an egress node receiving a Path message with the "LSP stitching
desired" flag set, recognizes the object, the TLV and the flag and desired" flag set, recognizes the object, the TLV and the flag and
also supports the desired stitching behavior, then it MUST allocate a also supports the desired stitching behavior, then it MUST allocate a
non-NULL label for that LSP segment in the corresponding Resv non-NULL label for that LSP segment in the corresponding Resv
message. Now, so that the head-end node can ensure that the correct message. Now, so that the head-end node can ensure that the correct
label actions will be carried out by the egress node and that the LSP label actions will be carried out by the egress node and that the LSP
segment can be used for stitching, the egress node MUST set the "LSP segment can be used for stitching, the egress node MUST set the "LSP
segment stitching ready" bit defined in the RRO Attribute sub-object. segment stitching ready" bit defined in the RRO Attribute sub-object.
Also, when the egress node for the LSP segment receives a Path Also, when the egress node for the LSP segment receives a Path
skipping to change at page 9, line 9 skipping to change at page 9, line 7
LSP_ATTRIBUTES object but does not recognize the Attributes Flags LSP_ATTRIBUTES object but does not recognize the Attributes Flags
TLV, or supports the TLV as well but does not recognize this TLV, or supports the TLV as well but does not recognize this
particular flag bit, then it SHOULD simply ignore the above request. particular flag bit, then it 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 flag corresponding to the egress node for the Attributes sub-object flag corresponding to the egress node for the
LSP segment, to make sure that stitching actions were carried out at LSP segment, to make sure that stitching actions were carried out at
the egress node. It MUST NOT use the LSP segment for stitching if the egress node. It MUST NOT use the LSP segment for stitching if
the "LSP segment stitching ready" flag is cleared. the "LSP segment stitching ready" flag is cleared.
The egress node MUST not allocate any Label in the Resv message for 4.1.2 Stitching the e2e LSP to the LSP segment
the e2e TE LSP. Similarly, in case of bidirectional e2e TE LSP, no
Upstream Label is allocated over the LSP segment in the corresponding
Path message. An ingress node stitching an e2e TE LSP to an LSP
segment MUST ignore any Label object received in the Resv for the e2e
TE LSP.
4. Summary of LSP Stitching procedures When a GMPLS node receives an e2e LSP request, depending on the
applicable trigger it may either dynamically create an LSP segment
based on procedures described above or it may map an e2e LSP to an
existing LSP segment. The switching type in the Generalized Label
Request of the e2e LSP MUST be equal to the switching type of the LSP
segment. Other constraints like ERO, bandwidth, local TE policies
may also be used for LSP segment selection or signaling. In either
case, once an LSP segment has been selected for an e2e LSP, the
following procedures MUST be followed in order to stitch an e2e LSP
to an LSP segment.
4.1 LSP segment setup The GMPLS node receiving the e2e LSP setup Path message MUST use the
signaling procedures described in [2] to send the Path message
directly to the end point of the LSP segment. In case of a
bidirectional e2e TE LSP, an Upstream Label MUST NOT be allocated and
signaled in the Path message for the e2e LSP over the LSP segment
hop.
The egress node receiving this Path message MUST NOT allocate any
Label in the Resv message for the e2e TE LSP over the LSP segment
hop. This Resv message is IP routed back to the previous hop
(ingress of the LSP segment).
The ingress node stitching an e2e TE LSP to an LSP segment MUST
ignore any Label object received in the Resv for the e2e TE LSP over
the LSP segment hop.
So, the main difference between signaling an e2e LSP over an LSP
segment instead of over an FA-LSP is that no Labels are allocated and
exchanged for the e2e LSP over the LSP segment hop. So, at most one
e2e LSP is associated with one LSP segment. If a node at the head-
end of an LSP segment receives a Path Msg for an LSP that identifies
the LSP segment in the ERO and the LSP segment bandwidth has already
been allocated to some other LSP, then regular rules of RSVP-TE pre-
emption apply. If the LSP request over the LSP segment cannot be
satisfied, then the node SHOULD send back a PathErr with the error
codes as described in [5].
4.1.3 RRO Processing for e2e LSP
RRO procedures for the LSP segment specific to LSP stitching are
already described in Section 4.1.1. In this section we will look at
the RRO processing for the e2e LSP over the LSP segment hop.
An e2e LSP traversing an LSP segment, SHOULD record in the RRO for
that hop, an identifier corresponding to the LSP segment TE link.
This is applicable to both Path and Resv messages over the LSP
segment hop. If the LSP segment is numbered, then the IPv4 or IPv6
address subobject ([5]) SHOULD be used to record the LSP segment TE
link address. If the LSP segment is unnumbered, then the Unnumbered
Interface ID subobject as described in [9] SHOULD be used to record
the node's Router ID and Interface ID of the LSP segment TE link. In
either case, the RRO subobject SHOULD identify the LSP segment TE
link end point (link or node). Intermediate links or nodes traversed
by the LSP segment itself SHOULD NOT be recorded in the RRO for the
e2e LSP over the LSP segment hop.
4.2 Summary of LSP Stitching procedures
4.2.1 Example topology
The following topology will be used for the purpose of examples
quoted in the following sections.
e2e LSP
++++++++++++++++++++++++++++++++++> (LSP1-2)
LSP segment
=====================> (LSP-AB)
C --- E --- G
/|\ | / |\
/ | \ | / | \
R1 ---- A \ | \ | / | / B --- R2
\| \ |/ |/
D --- F --- H
PATH
======================> (LSP stitching desired)
RESV
<====================== (LSP segment stitching ready)
PATH (no Upstream Label)
+++++++++++++++++++++++
++++++ +++++>
<+++++ ++++++
+++++++++++++++++++++++
RESV (no Label)
4.2.2 LSP segment setup
A GMPLS node that originates an LSP segment may decide to use this A GMPLS node that originates an LSP segment may decide to use this
LSP segment for stitching. The creation of this LSP segment and its LSP segment for stitching. The creation of this LSP segment and its
use for stitching may be dictated either by configuration or use for stitching may be dictated either by configuration or
dynamically on arrival of an LSP setup request at the GMPLS node. dynamically on arrival of an LSP setup request at the GMPLS node.
Successful completion of signaling procedures for the LSP segment as Successful completion of signaling procedures for the LSP segment as
described in Section 3.1 will allow the GMPLS node to : a) advertise described in Section 4.1 will allow the GMPLS node to : a) advertise
this LSP segment as a TE link with the bandwidth of the LSP as the this LSP segment as a TE link with the bandwidth of the LSP as the
unreserved bandwidth in the IGP and b) carry out stitching procedures unreserved bandwidth in the IGP and b) carry out stitching procedures
to actually stitch an e2e LSP to the LSP segment. Similar to setup, to actually stitch an e2e LSP to the LSP segment. Note that it is
tearing down the LSP segment may also be decided either via local not, however, required to advertise the LSP segment TE link in the
configuration or due to the fact that there is no longer an e2e LSP IGP in the first place. Similar to setup, tearing down the LSP
stitched to the LSP segment. E.g. Let us consider an LSP segment segment may also be decided either via local configuration or due to
LSP-AB being setup between two nodes A and B. A sends a Path message the fact that there is no longer an e2e LSP stitched to the LSP
for the LSP-AB with "LSP stitching desired". If on the egress node segment. E.g. Let us consider an LSP segment LSP-AB being setup
B, stitching procedures are successfully carried out, then B will set between two nodes A and B which may be one or more hops away. A
the "LSP segment stitching ready" in the RRO sent in the Resv. Once sends a Path message for the LSP-AB with "LSP stitching desired". If
A receives the Resv for LSP-AB and sees this bit set in the RRO, it on the egress node B, stitching procedures are successfully carried
can then use LSP-AB for stitching. out, then B will set the "LSP segment stitching ready" in the RRO
sent in the Resv. Once A receives the Resv for LSP-AB and sees this
bit set in the RRO, it can then use LSP-AB for stitching.
4.2 Setup of e2e LSP 4.2.3 Setup of e2e LSP
Other nodes in the network (in the same domain) trying to setup an Other nodes in the network (in the same domain) trying to setup an
e2e LSP across the network may see the LSP segment as a TE link in e2e LSP across the network may see the LSP segment as a TE link in
their TE databases and may compute a path over this TE link. In case their TE databases and may compute a path over this TE link. In case
of an inter-domain e2e LSP, however, the LSP segment TE link, like of an inter-domain e2e LSP, however, the LSP segment TE link, like
any other basic TE link in the domain will probably not be advertised any other basic TE link in the domain will not be advertised outside
outside the domain. In this case, either per-domain path computation the domain. In this case, either per-domain path computation ([11])
([11]) or PCE based computation will permit setting up e2e LSPs over or PCE based computation ([12]) will permit setting up e2e LSPs over
LSP segments in other domains. The LSP segment TE link may be LSP segments in other domains. The LSP segment TE link may itself be
identified as an ERO hop in the Path message of the e2e LSP message. identified as an ERO hop in the Path message of the e2e LSP message
E.g. Let us consider an e2e LSP LSP1-2 starting one hop before A on or ERO hops signaled for the e2e LSP may be used as a criterion for
R1 and ending on node R2. R1 may compute a path for LSP1-2 over the LSP segment selection or signaling. E.g. Let us consider an e2e LSP
LSP segment LSP-AB and identify the LSP-AB hop in the ERO. LSP1-2 starting one hop before A on R1 and ending on node R2, as
shown above. R1 may compute a path for LSP1-2 over the LSP segment
LSP-AB and identify the LSP-AB hop in the ERO or R1 may compute hops
between A and B and A may use these ERO hops for LSP segment
selection or signaling a new LSP segment.
4.3 Stitching of e2e LSP into an LSP segment 4.2.4 Stitching of e2e LSP into an LSP segment
When the Path message for an e2e LSP arrives at the GMPLS stitching When the Path message for an e2e LSP arrives at the GMPLS stitching
node, the LSP segment to stitch the e2e LSP to is determined. The node, the LSP segment to stitch the e2e LSP to is determined. The
Path message for the e2e LSP is then sent directly to the LSP segment Path message for the e2e LSP is then sent directly (IP routed) to the
end node with the destination IP address of the Path message set to LSP segment end node with the destination IP address of the Path
the address of the LSP segment end node. The Router Alert option message set to the address of the LSP segment end node. The Router
MUST not be set in this case. Furthermore, when the message arrives Alert option MUST NOT be set in this case. Furthermore, when the
at the end node, RSVP TTL checks MUST be disabled. The LSP segment message arrives at the end node, RSVP TTL checks MUST be disabled.
MUST be identified in the IF_ID RSVP_HOP (PHOP) object of the Path The LSP segment MUST be identified in the IF_ID RSVP_HOP (PHOP)
message. It is assumed that the receiver of this Path message can object of the Path message. It is assumed that the receiver of this
identify the LSP segment based on the data interface identification Path message can identify the LSP segment based on the data interface
in the IF_ID RSVP_HOP. When the Resv is sent back for the e2e LSP, identification in the IF_ID RSVP_HOP. Also, if the e2e LSP is
no Label is allocated on the LSP segment hop. E.g. When the Path bidirectional, an Upstream Label MUST NOT be allocated/signaled in
the Path message. When the Resv is sent back for the e2e LSP, a
Label MUST NOT be allocated on the LSP segment hop. When the Resv is
received and propagated further upstream (when applicable), the e2e
LSP has been stitched to the LSP segment. E.g. When the Path
message for the e2e LSP LSP1-2 arrives at node A, and the LSP segment message for the e2e LSP LSP1-2 arrives at node A, and the LSP segment
LSP-AB to stitch LSP1-2 to has been identified (either based on LSP-AB to stitch LSP1-2 to has been identified (either based on
explicit hop in ERO or due to local decision), then Path message for explicit hop in ERO or due to local decision), then Path message for
LSP1-2 is sent directly to node B with the IF_ID RSVP_HOP identifying LSP1-2 is sent directly to node B with the IF_ID RSVP_HOP identifying
the LSP segment LSP-AB. When B receives this Path message for the LSP segment LSP-AB. When B receives this Path message for
LSP1-2, if B is also the egress for LSP1-2, and if this is a packet 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 refresh for LSP-AB with LSP requiring PHP, then B will send a Resv refresh for LSP-AB with
the NULL Label. If B is not the egress, then Path message for LSP1-2 the NULL Label. If B is not the egress, then Path message for LSP1-2
is propagated to R2. The Resv for LSP1-2 is sent back from B is propagated to R2. The Resv for LSP1-2 is sent back from B
directly to A with no Label in it. Node A then propagates the Resv directly to A with no Label in it. Node A then propagates the Resv
to R1. This stitches an e2e LSP LSP1-2 to an LSP segment LSP-AB to R1. This stitches an e2e LSP LSP1-2 to an LSP segment LSP-AB
between nodes A and B. In the data plane, this yields a series of between nodes A and B. In the data plane, this yields a series of
label swaps from R1 to R2 along LSP LSP1-2. label swaps from R1 to R2 along LSP LSP1-2.
4.2.5 Teardown of e2e LSP
When an e2e LSP teardown is initiated from the head-end, and a
PathTear arrives at the GMPLS stitching node, the PathTear message
like the Path message MUST be sent directly to the LSP segment egress
node with the destination IP address of the Path message set to the
address of the LSP segment end node. Router Alert MUST be off and
RSVP TTL check MUST be disabled on the receiving node. PathTear will
result in deletion of RSVP states corresponding to the e2e LSP and
freeing of label allocations and bandwidth reservations on the LSP
segment. The unreserved bandwidth on the LSP segment TE link SHOULD
be re-adjusted.
Simiarly, a teardown of the e2e LSP may be initiated from the tail-
end either using a ResvTear or a PathErr with state removal. The
egress of the LSP segment MUST propagate the ResvTear/PathErr
upstream directly to the ingress of the LSP segment.
Graceful LSP teardown using ADMIN_STATUS as described in [4] is also
applicable to stitched LSPs.
If the LSP segment was statically provisioned, tearing down of an e2e
LSP MAY not result in tearing down of the LSP segment. If, however,
the LSP segment was dynamically setup due to the e2e LSP setup
request, then depending on local policy, the LSP segment MAY be torn
down if no e2e LSP is utilizing the LSP segment. Although the LSP
segment may be torn down while the e2e LSP is being torn down, it is
RECOMMENDED that a delay be introduced in tearing down the LSP
segment once the e2e LSP teardown is complete, in order to reduce the
simultaneous generation of RSVP errors and teardown messages due to
multiple events. The delay interval may be set based on local
implementation. The recommended interval is 30 seconds.
Also, deletion/teardown of the LSP segment (due to some failure or
maintenance) SHOULD be treated as a failure event for the e2e LSP
associated with it and corresponding teardown or recovery procedures
SHOULD be triggered for the e2e LSP.
5. Security Considerations 5. Security Considerations
Similar to [2]), this document permits that the control interface Similar to [2], this document permits that the control interface over
over which RSVP messages are sent or received need not be the same as which RSVP messages are sent or received need not be the same as the
the data interface which the message identifies for switching data interface which the message identifies for switching traffic.
traffic. Also, the 'sending interface' and 'receiving interface' may Also, the 'sending interface' and 'receiving interface' may change as
change as routing changes. So, these cannot be used to establish routing changes. So, these cannot be used to establish security
security association between neighbors. Mechanisms described in [6] association between neighbors. Mechanisms described in [6] should be
should be re-examined and may need to be altered to define new re-examined and may need to be altered to define new security
security associations based on receiver's IP address instead of the associations based on receiver's IP address instead of the sending
sending and receiving interfaces. Also, this document allows the IP and receiving interfaces. Also, this document allows the IP
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.
6. IANA Considerations 6. 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.
skipping to change at page 14, line 8 skipping to change at page 16, line 8
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 16 (Suggested value) Stitching unsupported - sub-code 16 (Suggested value)
This error code is to be used only in a RSVP PathErr. This error code is to be used only in a RSVP PathErr.
7. Acknowledgments 7. 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. for their comments and suggestions. The authors would also like to
thank Dimitri Papadimitriou and Igor Bryskin for their thorough
review of the document and discussions regarding the same.
8. References 8. References
8.1 Normative References 8.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, "LSP Hierarchy with Generalized
MPLS TE", Internet-Draft draft-ietf-mpls-lsp-hierarchy-08, MPLS TE", draft-ietf-mpls-lsp-hierarchy-08 (work in progress),
September 2002. September 2002.
[3] Farrel, A., Papadimitriou, D. and J. Vasseur, "Encoding of [3] Farrel, A., "Encoding of Attributes for Multiprotocol Label
Attributes for Multiprotocol Label Switching (MPLS) Label Switching (MPLS) Label Switched Path (LSP) Establishment Using
Switched Path (LSP) Establishment Using RSVP-TE", RSVP-TE", draft-ietf-mpls-rsvpte-attributes-05 (work in
Internet-Draft draft-ietf-mpls-rsvpte-attributes-04, July 2004. progress), May 2005.
[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.
8.2 Informative References 8.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", Internet-Draft draft-ietf-mpls-rsvp-te-p2mp-01, January LSPs", draft-ietf-mpls-rsvp-te-p2mp-01 (work in progress),
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",
Internet-Draft draft-ietf-ccamp-inter-domain-rsvp-te-00, draft-ietf-ccamp-inter-domain-rsvp-te-00 (work in progress),
February 2005. February 2005.
[9] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in [9] 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.
[10] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS [10] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in
Traffic Engineering", Internet-Draft draft-ietf-mpls-bundle-06, MPLS Traffic Engineering", draft-ietf-mpls-bundle-06 (work in
December 2004. progress), December 2004.
[11] Vasseur, J., "A Per-domain path computation method for [11] 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)", Path (LSP)", draft-vasseur-ccamp-inter-domain-pd-path-comp-00
. (work in progress), February 2005.
[12] Farrel, A., "Path Computation Element (PCE) Architecture",
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
US US
Email: arthi@juniper.net Email: arthi@juniper.net
 End of changes. 

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