draft-ietf-ccamp-lsp-stitching-03.txt   draft-ietf-ccamp-lsp-stitching-04.txt 
Network Working Group A. Ayyangar, Ed. Network Working Group A. Ayyangar, Ed.
Internet-Draft Juniper Networks Internet-Draft Nuova Systems
Expires: September 6, 2006 JP. Vasseur Intended status: Standards Track K. Kompella, Ed.
Expires: June 5, 2007 Juniper Networks
JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
March 5, 2006 December 2, 2006
Label Switched Path Stitching with Generalized MPLS Traffic Engineering Label Switched Path Stitching with Generalized MPLS Traffic Engineering
draft-ietf-ccamp-lsp-stitching-03.txt draft-ietf-ccamp-lsp-stitching-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2006. This Internet-Draft will expire on June 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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 several
different Generalized Multi-Protocol Label Switching (GMPLS) Label Generalized Multi-Protocol Label Switching (GMPLS) Label Switched
Switched Paths (LSPs) such that in the data plane, a single end-to- Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and
end (e2e) LSP is realized and all traffic from one LSP is switched all traffic from one constituent LSP is switched onto the next LSP.
onto the other LSP. We will refer to this as "LSP stitching". This We will refer to this as "LSP stitching", the key requirement being
document covers cases where: a) the node performing the stitching that a constituent LSP not be allocated to more than one e2e LSP.
does not require configuration of every LSP pair to be stitched The constituent LSPs will be referred to as "LSP segments" (S-LSPs).
together b) the node performing the stitching is not the egress of
any of the LSPs c) LSP stitching not only results in an end-to-end
LSP in the data plane, but there is also a corresponding end-to-end
LSP (RSVP session) in the control plane.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 4
2. Comparison with LSP Hierarchy . . . . . . . . . . . . . . . . 4 2. Comparison with LSP Hierarchy . . . . . . . . . . . . . . . . 5
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Triggers for LSP segment setup . . . . . . . . . . . . . . 5 3.1. Triggers for LSP segment setup . . . . . . . . . . . . . . 6
3.2. Applications . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Applications . . . . . . . . . . . . . . . . . . . . . . . 6
4. Routing aspects . . . . . . . . . . . . . . . . . . . . . . . 6 4. Routing aspects . . . . . . . . . . . . . . . . . . . . . . . 7
5. Signaling aspects . . . . . . . . . . . . . . . . . . . . . . 7 5. Signaling aspects . . . . . . . . . . . . . . . . . . . . . . 9
5.1. RSVP-TE signaling extensions . . . . . . . . . . . . . . . 7 5.1. RSVP-TE signaling extensions . . . . . . . . . . . . . . . 9
5.1.1. Creating and preparing LSP segment for stitching . . . 7 5.1.1. Creating and preparing LSP segment for stitching . . . 9
5.1.2. Stitching the e2e LSP to the LSP segment . . . . . . . 9 5.1.2. Stitching the e2e LSP to the LSP segment . . . . . . . 11
5.1.3. RRO Processing for e2e LSP . . . . . . . . . . . . . . 10 5.1.3. RRO Processing for e2e LSP . . . . . . . . . . . . . . 12
5.1.4. Teardown of LSP segment . . . . . . . . . . . . . . . 11 5.1.4. Teardown of LSP segment . . . . . . . . . . . . . . . 13
5.1.5. Teardown of e2e LSP . . . . . . . . . . . . . . . . . 11 5.1.5. Teardown of e2e LSP . . . . . . . . . . . . . . . . . 13
5.2. Summary of LSP Stitching procedures . . . . . . . . . . . 12 5.2. Summary of LSP Stitching procedures . . . . . . . . . . . 14
5.2.1. Example topology . . . . . . . . . . . . . . . . . . . 12 5.2.1. Example topology . . . . . . . . . . . . . . . . . . . 14
5.2.2. LSP segment setup . . . . . . . . . . . . . . . . . . 12 5.2.2. LSP segment setup . . . . . . . . . . . . . . . . . . 15
5.2.3. Setup of e2e LSP . . . . . . . . . . . . . . . . . . . 13 5.2.3. Setup of e2e LSP . . . . . . . . . . . . . . . . . . . 15
5.2.4. Stitching of e2e LSP into an LSP segment . . . . . . . 13 5.2.4. Stitching of e2e LSP into an LSP segment . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 15 7.1. Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 17
7.2. New Error Codes . . . . . . . . . . . . . . . . . . . . . 15 7.2. New Error Codes . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22
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 control (routing and signaling) and data planes, contrasting
stitching with LSP hierarchy ([2]) as is meaningful. With the
mechanism described here, the node performing the stitching does not
require configuration of the pair of LSPs to be stitched together.
Also, LSP stitching as defined here results in an end-to-end LSP both
in the control and data planes.
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
in one layer can provide a data link to LSPs in higher layers. in one layer can appear as a data link to LSPs in higher layers.
Also one or more LSPs can be nested into this H-LSP. As such, one or more LSPs in a higher layer can traverse this
H-LSP as a single hop; we call this "nesting".
b. An H-LSP may be managed and advertised (although this is not a b. An H-LSP may be managed and advertised (although this is not a
requirement) as a Traffic Engineering (TE) link. Advertising an requirement) as a Traffic Engineering (TE) link. Advertising an
H-LSP as a TE link allows other nodes in the TE domain in which H-LSP as a TE link allows other nodes in the TE domain in which
it is advertised to use this H-LSP in path computation. If the it is advertised to use this H-LSP in path computation. If the
H-LSP TE link is advertised in the same instance of control plane H-LSP TE link is advertised in the same instance of control plane
(TE domain) in which the H-LSP was provisioned, it is then (TE domain) in which the H-LSP was provisioned, it is then
defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes
can form a forwarding adjacency (FA) over this FA-LSP. There is can form a forwarding adjacency (FA) over this FA-LSP. There is
usually no routing adjacency between end points of an FA. An usually no routing adjacency between end points of an FA. An
skipping to change at page 4, line 14 skipping to change at page 5, line 14
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
S-LSP created in one layer, unlike an H-LSP, provides a data link to S-LSP created in one layer, unlike an H-LSP, provides a data link to
other LSPs in the same layer. Similar to an H-LSP, an S-LSP could be other LSPs in the same layer. Similar to an H-LSP, an S-LSP could be
managed and advertised, although it is not required, as a TE link, managed and advertised, although it is not required, as a TE link,
either in the same TE domain as it was provisioned or a different either in the same TE domain as it was provisioned or a different
one. If advertised, other GMPLS nodes could used the corresponding one. If so advertised, other GMPLS nodes can use the corresponding
S-LSP TE link in path computation. While there is a forwarding S-LSP TE link in path computation. While there is a forwarding
adjacency between end points of an H-LSP TE link, there is no adjacency between end points of an H-LSP TE link, there is no
forwarding adjacency between end points of an S-LSP TE link. In this forwarding adjacency between end points of an S-LSP TE link. In this
aspect, an H-LSP TE link more closely resembles a 'basic' TE link as aspect, an H-LSP TE link more closely resembles a 'basic' TE link as
compared to an S-LSP TE link. compared to an S-LSP TE link.
While LSP hierarchy allows more than one LSP to be mapped to an While LSP hierarchy allows more than one LSP to be mapped to an
H-LSP, in case of LSP stitching, at most one LSP may be associated H-LSP, in case of LSP stitching, at most one LSP may be associated
with an S-LSP. E.g. if LSP-AB is an H-LSP between nodes A and B, with an S-LSP. Thus, if LSP-AB is an H-LSP between nodes A and B,
then multiple LSPs, say LSP1, LSP2, LSP3 could potentially be 'nested then multiple LSPs, say LSP1, LSP2, and LSP3 can potentially be
into' LSP-AB. This is achieved by exchanging a unique label for each 'nested into' LSP-AB. This is achieved by exchanging a unique label
of LSP1..3 over the LSP-AB hop thereby permitting LSP1..3 to share for each of LSP1..3 over the LSP-AB hop, thereby separating the data
the H-LSP LSP-AB. Each of LSP1..3 may reserve some bandwidth on corresponding to each of LSP1..3 while traversing the H-LSP LSP-AB.
LSP-AB. On the other hand, if LSP-AB is an S-LSP, then at most one Each of LSP1..3 may reserve some bandwidth on LSP-AB. On the other
LSP, say LSP1 may be stitched to the S-LSP LSP-AB. LSP-AB is hand, if LSP-AB is an S-LSP, then at most one LSP, say LSP1, may be
dedicated to LSP1 and no other LSPs can be associated with LSP-AB. stitched to the S-LSP LSP-AB. LSP-AB is then dedicated to LSP1 and
The entire bandwith on S-LSP LSP-AB is allocated to LSP1. However, no other LSPs can be associated with LSP-AB. The entire bandwith on
several S-LSPs MAY be bundled into a TE link ([11]), similar to S-LSP LSP-AB is allocated to LSP1. However, similar to H-LSPs,
H-LSPs. several S-LSPs may be bundled into a TE link ([11]).
The LSPs LSP1..3 which are either nested or stitched into another LSP The LSPs LSP1..3 which are either nested or stitched into another LSP
are termed as end-to-end (e2e) LSPs in the rest of this document. are termed as end-to-end (e2e) LSPs in the rest of this document.
Routing procedures specific to LSP stitching are detailed in Routing procedures specific to LSP stitching are detailed in
Section 4. Section 4.
Targetted (non-adjacent nodes) RSVP signaling defined in [2] is Targetted (non-adjacent) RSVP signaling defined in [2] is required
required for LSP stitching of an e2e LSP to an S-LSP. Specific for LSP stitching of an e2e LSP to an S-LSP. Specific extensions for
extensions for LSP stitching are described later in Section 5.1. LSP stitching are described later in Section 5.1. Therefore, in the
Therefore, 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 S-LSP. The as well as one for each S-LSP. The creation and termination of an
creation and termination of an S-LSP may be dictated by S-LSP may be dictated by administrative control (statically
administrative control (statically provisioned) or due to another provisioned) or due to another incoming LSP request (dynamic).
incoming LSP request (dynamic). Triggers for dynamic creation of an Triggers for dynamic creation of an S-LSP may be different from that
S-LSP may be different from that of an H-LSP and will be described in 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-
skipping to change at page 5, line 31 skipping to change at page 6, line 31
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 LSP hierarchy is not possible; in
possible. this case, LSP switching may be an option.
LSP stitching procedures could be used for inter-domain TE LSP LSP stitching procedures can 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 e2e LSP to a local intra-domain
S-LSP ([8]). TE S-LSP ([8]).
LSP stitching could also be useful in networks to bypass legacy nodes LSP stitching may also be useful in networks to bypass legacy nodes
which may not have certain new capabilities in the control plane 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 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 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 an LSP segment between P2MP capable LSRs in the network. The LSP
segment would traverse legacy LSRs that may be incapable of acting as segment would traverse legacy LSRs that may be incapable of acting as
P2MP branch points, thereby shielding them from the P2MP control and P2MP branch points, thereby shielding them from the P2MP control and
data path. Note, however, that such configuration may limit the data path. Note, however, that such configuration may limit the
attractiveness of RSVP P2MP and should carefully be examined before attractiveness of RSVP P2MP and should carefully be examined before
deployment. deployment.
4. Routing aspects 4. Routing aspects
An S-LSP is created between two GMPLS nodes and it may traverse zero An S-LSP is created between two GMPLS nodes and it may traverse zero
or more GMPLS nodes. There is no forwarding adjacency between the or more intermediate GMPLS nodes. There is no forwarding adjacency
end points of an S-LSP TE link. So, although in the TE topology, the between the end points of an S-LSP TE link. So, although in the TE
end points of an S-LSP TE link are adjacent, in the data plane, these topology, the end points of an S-LSP TE link are adjacent, in the
nodes do not have an adjacency. Hence any data plane resource data plane, these nodes do not have an adjacency. Hence any data
identifier between these nodes is also meaningless. The traffic that plane resource identifier between these nodes is also meaningless.
arrives at the head end of the S-LSP is switched into the S-LSP The traffic that arrives at the head end of the S-LSP is switched
contiguously with a label swap and no label is associated directly into the S-LSP contiguously with a label swap and no label is
between the end nodes of the S-LSP itself. associated directly between the end nodes of the S-LSP itself.
An S-LSP MAY be treated and managed as a TE link. This TE link MAY An S-LSP MAY be treated and managed as a TE link. This TE link MAY
be numbered or unnumbered. For an unnumbered S-LSP TE link, the be numbered or unnumbered. For an unnumbered S-LSP TE link, the
schemes for assignment and handling of the local and remote link schemes for assignment and handling of the local and remote link
identifiers as specified in [10] SHOULD be used. ISIS/OSPF may flood identifiers as specified in [10] SHOULD be used. When appropriate,
the TE information associated with an S-LSP TE link, when the TE information associated with an S-LSP TE link MAY be flooded
appropriate. Mechanisms similar to that for regular (basic) TE links via ISIS-TE [13] or OSPF-TE [12]. Mechanisms similar to that for
SHOULD be used to flood S-LSP TE links. Advertising or flooding the regular (basic) TE links SHOULD be used to flood S-LSP TE links.
S-LSP TE link is not a requirement for LSP stitching. Discretion Advertising or flooding the S-LSP TE link is not a requirement for
should be used when advertising an S-LSP TE link in an IGP. If LSP stitching. If advertised, this TE information will exist in the
advertised, this TE information will exist in the TE database (TED) TE database (TED) and can then be used for path computation by other
and can then be used for path computation by other GMPLS nodes in the GMPLS nodes in the TE domain in which it is advertised. When so
TE domain in which it is advertised. advertising S-LSPs, one should keep in mind that these add to the
size and complexity of the link-state database.
If an S-LSP is advertised as a TE link in the same TE domain in which If an S-LSP is advertised as a TE link in the same TE domain in which
it was provisioned, there is no need for a routing adjacency between it was provisioned, there is no need for a routing adjacency between
end points of this S-LSP TE link. If an S-LSP TE link is advertised end points of this S-LSP TE link. If an S-LSP TE link is advertised
in a different TE domain, the end points of that TE link SHOULD have in a different TE domain, the end points of that TE link SHOULD have
a routing adjacency between them. a routing adjacency between them.
The TE parameters defined for an FA in [2] SHOULD be used for an The TE parameters defined for an FA in [2] SHOULD be used for an
S-LSP TE link as well. The switching capability of an S-LSP TE link S-LSP TE link as well. The switching capability of an S-LSP TE link
MUST be equal to the switching type of the underlying S-LSP; i.e. an MUST be equal to the switching type of the underlying S-LSP; i.e. an
S-LSP TE link provides a data link to other LSPs in the same layer, S-LSP TE link provides a data link to other LSPs in the same layer,
so no hierarchy is possible. so no hierarchy is possible.
An S-LSP MUST NOT admit more than one e2e LSP into it. However, An S-LSP MUST NOT admit more than one e2e LSP into it. If an S-LSP
multiple S-LSPs between the same pair of nodes MAY be bundled using is allocated to an e2e LSP, the unreserved bandwidth SHOULD be set to
the concept of Link Bundling ([11]) into a single TE link. So, while zero to prevent further e2e LSPs being admitted into the S-LSP.
an S-LSP can have exactly one e2e LSP associated with it, a bundled
TE link comprising of multiple S-LSPs, MAY admit more than one e2e Multiple S-LSPs between the same pair of nodes MAY be bundled using
LSP. When any component S-LSP is allocated for an e2e LSP, the the concept of Link Bundling ([11]) into a single TE link. In this
component's unreserved bandwidth SHOULD be set to zero and the case, each component S-LSP may be allocated to at most one e2e LSP.
Minimum and Maximum LSP bandwidth of the TE link SHOULD be When any component S-LSP is allocated for an e2e LSP, the component's
recalculated. This will prevent more than one LSP from being unreserved bandwidth SHOULD be set to zero and the Minimum and
computed and admitted over an S-LSP. Maximum LSP bandwidth of the TE link SHOULD be recalculated. This
will prevent more than one LSP from being computed and admitted over
an S-LSP.
5. Signaling aspects 5. Signaling aspects
The end nodes of an S-LSP may or may not have a routing adjacency. The end nodes of an S-LSP may or may not have a routing adjacency.
However, they SHOULD have a signaling adjacency (RSVP neighbor However, they SHOULD have a signaling adjacency (RSVP neighbor
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].
skipping to change at page 7, line 27 skipping to change at page 9, line 27
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 1. 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 2. 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 create an S-LSP, i.e., one to be used for
indicate this in the Path message for the S-LSP that it plans to use stitching, then it MUST indicate this in the Path message for the
for stitching. This signaling explicitly informs the S-LSP egress S-LSP. This signaling explicitly informs the S-LSP egress node that
node that the ingress node is planning to perform stitching over the the ingress node is planning to perform stitching over the S-LSP.
S-LSP. Since an S-LSP is not conceptually different from any other Since an S-LSP is not conceptually different from any other LSP,
LSP, explicitly signaling 'LSP stitching desired' helps clarify the explicitly signaling 'LSP stitching desired' helps clarify the data
data plane actions to be carried out when the S-LSP is used by some plane actions to be carried out when the S-LSP is used by some other
other e2e LSP. Also, in case of packet LSPs, this is what allows the 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.
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 will be carried out at the egress node, the egress node MUST actions will be carried out at the egress node, the egress node MUST
signal this information back to the head-end node in the Resv, as signal this information back to the head-end node in the Resv, as
explained below. explained below.
In order to request LSP stitching on the S-LSP, we define a new bit In order to request LSP stitching on the S-LSP, we define a new bit
in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in
[3]: [3]:
skipping to change at page 9, line 11 skipping to change at page 11, line 11
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 or Explicit NULL label. Note that this operation does not
traffic disruption since the S-LSP is not carrying any traffic at cause any traffic disruption since the S-LSP is not carrying any
this time, since the e2e LSP has not yet been established. traffic at this time, since the e2e LSP has not yet been established.
If the e2e LSP and the S-LSP are bidirectional, the ingress of the
e2e LSP SHOULD first check whether it is also the ingress of the
S-LSP. If so, it SHOULD re-issue the Path message for the S-LSP with
an implicit or explicit NULL upstream label; and only then proceed
with the signaling of the e2e LSP.
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
skipping to change at page 12, line 19 skipping to change at page 14, line 26
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
/|\ | / |\ /|\ | / |\
/ | \ | / | \ / | \ | / | \
R1 ---- A \ | \ | / | / B --- R2 R1 ---- A \ | \ | / | / B --- R2
\| \ |/ |/ \| \ |/ |/
D --- F --- H D --- F --- H
PATH PATH
======================> (LSP stitching desired) ====================> (LSP stitching desired)
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 advertised
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. If R1 and A are in different domains, then
distinguished from any basic TE link on R1. If R1 and A are in LSP1-2 is an inter-domain LSP. In this case, S-LSP LSP-AB, similar
different domains, then LSP1-2 is an inter-domain LSP. In this case, to any other basic TE link in the domain will not be advertised
S-LSP LSP-AB, similar to any other basic TE link in the domain will outside the domain. R1 would use either per-domain path computation
not be advertised outside the domain. R1 would use either per-domain ([14]) or PCE based computation ([15]) 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 the S-LSP LSP-AB to which LSP1-2 will be stitched has
successfully, the Path message for LSP1-2 is IP routed to node B with been determined, the Path message for LSP1-2 is sent (via IP routing,
the IF_ID RSVP_HOP identifying the S-LSP LSP-AB. When B receives if needed) to node B with the IF_ID RSVP_HOP identifying the S-LSP
this Path message for LSP1-2, if B is also the egress for LSP1-2, and LSP-AB. When B receives this Path message for LSP1-2, if B is also
if this is a packet LSP requiring PHP, then B will send a Resv the egress for LSP1-2, and if this is a packet LSP requiring PHP,
refresh for LSP-AB with the NULL Label. In this case, since B is not then B will send a Resv refresh for LSP-AB with the NULL Label. In
the egress, the Path message for LSP1-2 is propagated to R2. The this case, since B is not the egress, the Path message for LSP1-2 is
Resv for LSP1-2 from B is IP routed back to A with a Label value propagated to R2. The Resv for LSP1-2 from B is sent back to A with
chosen by B. B also sets up its data plane to swap the Label sent to a Label value chosen by B. B also sets up its data plane to swap the
either G or H on the S-LSP with the Label received from R2. Node A Label sent to either G or H on the S-LSP with the Label received from
ignores the Label on receipt of the Resv message and then propagates R2. Node A ignores the Label on receipt of the Resv message and then
the Resv to R1. A also sets up its data plane to swap the Label sent propagates the Resv to R1. A also sets up its data plane to swap the
to R1 with the Label received on the S-LSP from C or D. This stitches Label sent to R1 with the Label received on the S-LSP from C or D.
the e2e LSP LSP1-2 to an S-LSP LSP-AB between nodes A and B. In the This stitches the e2e LSP LSP1-2 to an S-LSP LSP-AB between nodes A
data plane, this yields a series of label swaps from R1 to R2 along and B. In the data plane, this yields a series of label swaps from R1
e2e LSP LSP1-2. to R2 along e2e LSP LSP1-2.
6. Security Considerations 6. Security Considerations
Similar to [2], this document permits that the control interface over Similar to [2], this document permits that the control interface over
which RSVP messages are sent or received need not be the same as the which RSVP messages are sent or received need not be the same as the
data interface which the message identifies for switching traffic. data interface which the message identifies for switching traffic.
Also, the 'sending interface' and 'receiving interface' may change as Also, the 'sending interface' and 'receiving interface' may change as
routing changes. So, these cannot be used to establish security routing changes. So, these cannot be used to establish security
association between neighbors. Mechanisms described in [6] should be association between neighbors. Mechanisms described in [6] should be
re-examined and may need to be altered to define new security re-examined and may need to be altered to define new security
skipping to change at page 16, line 7 skipping to change at page 18, line 7
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 for his comments and
for their comments and suggestions. The authors would also like to suggestions. The authors would also like to thank Dimitri
thank Dimitri Papadimitriou and Igor Bryskin for their thorough Papadimitriou and Igor Bryskin for their thorough review of the
review of the document and discussions regarding the same. 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, "Label Switched Paths (LSP) [2] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
skipping to change at page 17, line 35 skipping to change at page 19, line 35
[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-06 (work in progress),
January 2005. August 2006.
[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-03 (work in progress),
February 2005. March 2006.
[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 (TE)", RFC 4201, October 2005. MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[12] Vasseur, J., "A Per-domain path computation method for [12] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of
computing Inter-domain Traffic Engineering (TE) Label Switched Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203,
Path (LSP)", draft-ietf-ccamp-inter-domain-pd-path-comp-00 October 2005.
(work in progress), April 2005.
[13] Farrel, A., "Path Computation Element (PCE) Architecture", [13] Kompella, K. and Y. Rekhter, "Intermediate System to
draft-ietf-pce-architecture-00 (work in progress), March 2005. Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205,
October 2005.
[14] Vasseur, J., "A Per-domain path computation method for
establishing Inter-domain Traffic Engineering (TE) Label
Switched Paths (LSPs)",
draft-ietf-ccamp-inter-domain-pd-path-comp-03 (work in
progress), August 2006.
[15] Farrel, A., "A Path Computation Element (PCE) Based
Architecture", draft-ietf-pce-architecture-05 (work in
progress), April 2006.
Authors' Addresses Authors' Addresses
Arthi Ayyangar (editor) Arthi Ayyangar (editor)
Nuova Systems
2600 San Tomas Expressway
Santa Clara, CA 95051
US
Email: arthi@nuovasystems.com
Kireeti Kompella (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: kireeti@juniper.net
Jean Philippe Vasseur Jean Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
US US
Email: jpv@cisco.com Email: jpv@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 20, line 29 skipping to change at page 22, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 40 change blocks. 
183 lines changed or deleted 213 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/