draft-ietf-ccamp-lsp-stitching-01.txt   draft-ietf-ccamp-lsp-stitching-02.txt 
Network Working Group A. Ayyangar, Ed. Network Working Group A. Ayyangar, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Expires: January 16, 2006 JP. Vasseur Expires: March 26, 2006 JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
July 15, 2005 September 22, 2005
Label Switched Path Stitching with Generalized MPLS Traffic Engineering Label Switched Path Stitching with Generalized MPLS Traffic Engineering
draft-ietf-ccamp-lsp-stitching-01.txt draft-ietf-ccamp-lsp-stitching-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2006. This Internet-Draft will expire on March 26, 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
different Generalized Multi-Protocol Label Switching (GMPLS) Label different Generalized Multi-Protocol Label Switching (GMPLS) Label
Switched Paths (LSPs) such that in the data plane, a single end-to- Switched Paths (LSPs) such that in the data plane, a single end-to-
end (e2e) LSP is achieved and all traffic from one LSP is switched end (e2e) LSP is realized and all traffic from one LSP is switched
onto the other LSP. We will refer to this as "LSP stitching". This onto the other LSP. We will refer to this as "LSP stitching". This
document covers cases where: a) the node performing the stitching document covers cases where: a) the node performing the stitching
does not require configuration of every LSP pair to be stitched does not require configuration of every LSP pair to be stitched
together b) the node performing the stitching is not the egress of 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 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 in the data plane, but there is also a corresponding end-to-end
LSP (RSVP session) in the control plane. It might be possible to LSP (RSVP session) in the control plane.
configure a GMPLS node to switch the traffic from an LSP for which it
is the egress, to another LSP for which it is the ingress, without It may be possible to configure a GMPLS node to switch the traffic
requiring any signaling or routing extensions whatsoever, completely from an LSP for which it is the egress, to another LSP for which it
transparent to other nodes. This will also result in LSP stitching is the ingress, without requiring any signaling or routing extensions
in the data plane. However, this document does not cover this whatsoever, completely transparent to other nodes. This will also
scenario of LSP stitching. result in LSP stitching in the data plane. However, this document
does not cover this scenario of LSP stitching.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions used in this document . . . . . . . . . . . . 4 1.1 Conventions used in this document . . . . . . . . . . . . 3
2. Routing aspects . . . . . . . . . . . . . . . . . . . . . . . 5 2. Comparison with LSP Hierarchy . . . . . . . . . . . . . . . . 4
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 LSP regions and LSP stitching . . . . . . . . . . . . . . 6 3.1 Triggers for LSP segment setup . . . . . . . . . . . . . . 5
3.2 Applications . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Applications . . . . . . . . . . . . . . . . . . . . . . . 5
4. Signaling aspects . . . . . . . . . . . . . . . . . . . . . . 7 4. Routing aspects . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 RSVP-TE signaling extensions . . . . . . . . . . . . . . . 7 5. Signaling aspects . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1 Creating and preparing LSP segment for stitching . . . 7 5.1 RSVP-TE signaling extensions . . . . . . . . . . . . . . . 7
4.1.2 Stitching the e2e LSP to the LSP segment . . . . . . . 9 5.1.1 Creating and preparing LSP segment for stitching . . . 7
4.1.3 RRO Processing for e2e LSP . . . . . . . . . . . . . . 9 5.1.2 Stitching the e2e LSP to the LSP segment . . . . . . . 9
4.2 Summary of LSP Stitching procedures . . . . . . . . . . . 10 5.1.3 RRO Processing for e2e LSP . . . . . . . . . . . . . . 10
4.2.1 Example topology . . . . . . . . . . . . . . . . . . . 10 5.1.4 Teardown of LSP segment . . . . . . . . . . . . . . . 11
4.2.2 LSP segment setup . . . . . . . . . . . . . . . . . . 11 5.1.5 Teardown of e2e LSP . . . . . . . . . . . . . . . . . 11
4.2.3 Setup of e2e LSP . . . . . . . . . . . . . . . . . . . 11 5.2 Summary of LSP Stitching procedures . . . . . . . . . . . 12
4.2.4 Stitching of e2e LSP into an LSP segment . . . . . . . 11 5.2.1 Example topology . . . . . . . . . . . . . . . . . . . 12
4.2.5 Teardown of e2e LSP . . . . . . . . . . . . . . . . . 12 5.2.2 LSP segment setup . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5.2.3 Setup of e2e LSP . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5.2.4 Stitching of e2e LSP into an LSP segment . . . . . . . 13
6.1 Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 7.1 Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 15
8.1 Normative References . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8.2 Informative References . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 19
1. Introduction 1. Introduction
This document describes the mechanisms to accomplish LSP stitching in This document describes the mechanisms to accomplish LSP stitching in
the scenarios described above. the scenarios described above.
LSP hierarchy ([2]) provides signaling and routing procedures so LSP hierarchy ([2]) provides signaling and routing procedures so
that: that:
a. a GMPLS node can form a forwarding adjacency (FA) over the FA LSP 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.
b. other Label Switching Routers (LSRs) can see this FA LSP as a Also one or more LSPs can be nested into this H-LSP.
Traffic Engineering (TE) link, when needed.
c. the GMPLS node can nest one or more LSPs over the FA LSP. This
only covers LSPs in a single domain.
d. RSVP signaling for LSP setup can occur between nodes that do not b. An H-LSP may be managed and advertised (although this is not a
have routing adjacency. requirement) as a Traffic Engineering (TE) link. Advertising an
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
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
defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes
can form a forwarding adjacency (FA) over this FA-LSP. There is
usually no routing adjacency between end points of an FA. An
H-LSP may also be advertised as a TE link in a different TE
domain. In this case, the end points of the H-LSP are required
have a routing adjacency between them.
LSP stitching is a special case of LSP hierarchy. In case of LSP c. RSVP signaling for LSP setup can occur between nodes that do not
stitching, instead of an FA LSP, an "LSP segment" is created between have a routing adjacency.
two GMPLS nodes. So an LSP segment for stitching is considered to be
the moral equivalent of an FA LSP for nesting and an LSP segment TE
link is a moral equivalent of FA (FA-LSP TE link). While LSP
hierarchy allows more that one LSP to be mapped to an FA-LSP, in case
of LSP stitching, at most one LSP may be mapped to an LSP segment.
E.g. if LSP-AB is an FA-LSP between nodes A and B, then multiple
LSPs, say LSP1, LSP2, LSP3 could potentially be 'nested into' LSP-AB.
This is achieved by exchanging a unique label for each of LSP1..3
over the LSP-AB hop thereby permitting LSP1..3 to share the FA-LSP
LSP-AB. Each of LSP1..3 may reserve some bandwidth on LSP-AB. On
the other hand, if LSP-AB is an LSP segment, then at most one LSP,
say LSP1 may be 'stitched to' the LSP segment LSP-AB. No labels are
exchanged for LSP1 over the LSP-AB hop directly between nodes A and
B. 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
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
rest of this document.
Signaling and routing procedures for LSP stitching are basically A stitched TE LSP comprises of different LSP segments (S-LSPs) that
similar to that described in [2]. The LSP segment, like an FA-LSP is are connected together in the data plane in such a way that a single
treated as a TE link. Also, non-adjacent RSVP signaling defined in end-to-end LSP is realized in the data plane. In this document, we
[2]) is required to stitch an LSP to an LSP segment. So, in the define the concept of LSP stitching and detail the control plane
control plane, there is one RSVP session corresponding to the e2e LSP mechanisms and procedures to accomplish this. Where applicable,
as well as one for each LSP segment that the e2e LSP is being similarities and differences between LSP hierarchy and LSP stitching
stitched to. The creation/termination of an LSP segment may be are highlighted. Signaling extensions required for LSP stitching are
dictated by administrative control (statically provisioned) or due to also described here.
another incoming LSP request (dynamic). Triggers for dynamic
creation of an LSP segment are different from that of an FA-LSP and
will be described in detail later. In this document, where
applicable, similarities and differences in the routing and signaling
procedures between LSP hierarchy and LSP stitching are highlighted.
Additional signaling extensions required for LSP stitching are also
described here.
1.1 Conventions used in this document 1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
2. Routing aspects 2. Comparison with LSP Hierarchy
An LSP segment is created and treated like a TE link between two In case of LSP stitching, instead of an H-LSP, an "LSP segment"
GMPLS nodes whose path transits zero or more GMPLS nodes in the same (S-LSP) is created between two GMPLS nodes. An S-LSP for stitching
instance of the GMPLS control plane. These TE links may be numbered is considered to be the moral equivalent of an H-LSP for nesting. An
or unnumbered. For an unnumbered LSP segment, the assignment and S-LSP created in one layer, unlike an H-LSP, provides a data link to
handling of the local and remote link identifiers is specified in other LSPs in the same layer. Similar to an H-LSP, an S-LSP could be
[9]. Unlike an FA-LSP, a GMPLS node does not have a data plane managed and advertised, although it is not required, as a TE link,
adjacency with the end point of the LSP segment. This implies that either in the same TE domain as it was provisioned or a different
the traffic that arrives at the GMPLS node will be switched into the one. If advertised, other GMPLS nodes could used the corresponding
LSP segment contiguously with a label swap and no label is exchanged S-LSP TE link in path computation. While there is a forwarding
directly between the end nodes of the LSP segment itself. A routing adjacency between end points of an H-LSP TE link, there is no
adjacency will not be established over an LSP segment. ISIS/OSPF forwarding adjacency between end points of an S-LSP TE link. In this
may, however, flood the TE information associated with an LSP segment aspect, an H-LSP TE link more closely resembles a 'basic' TE link as
TE link, when appropriate. Mechanisms similar to that for regular TE compared to an S-LSP TE link.
links may be used to flood LSP segment TE links. Advertising or
flooding the LSP segment TE link is not a requirement for LSP
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.
The TE parameters defined for an FA in [2]) are exactly applicable to While LSP hierarchy allows more than one LSP to be mapped to an
an LSP segment TE link as well. Note that the switching capability H-LSP, in case of LSP stitching, at most one LSP may be associated
of an LSP segment TE link MUST be equal to the switching type of the with an S-LSP. E.g. if LSP-AB is an H-LSP between nodes A and B,
underlying LSP segment; i.e. no hierarchy (nesting) is possible. then multiple LSPs, say LSP1, LSP2, LSP3 could potentially be 'nested
into' LSP-AB. This is achieved by exchanging a unique label for each
of LSP1..3 over the LSP-AB hop thereby permitting LSP1..3 to share
the H-LSP LSP-AB. Each of LSP1..3 may reserve some bandwidth on
LSP-AB. On the other hand, if LSP-AB is an S-LSP, then at most one
LSP, say LSP1 may be stitched to the S-LSP LSP-AB. LSP-AB is
dedicated to LSP1 and no other LSPs can be associated with LSP-AB.
The entire bandwith on S-LSP LSP-AB is allocated to LSP1. However,
several S-LSPs MAY be bundled into a TE link ([11]), similar to
H-LSPs.
An LSP segment TE link SHOULD NOT admit more than one e2e LSP into The LSPs LSP1..3 which are either nested or stitched into another LSP
it. So, once an LSP is stitched into an LSP segment, the unreserved are termed as end-to-end (e2e) LSPs in the rest of this document.
bandwidth on the LSP segment SHOULD be set to zero. This will Routing procedures specific to LSP stitching are detailed in
prevent any more LSPs from being computed and admitted over the LSP Section 4.
segment TE link. Multiple LSP segments between the same pair of
nodes may be bundled using the concept of Link Bundling ([10]) into a Targetted (non-adjacent nodes) RSVP signaling defined in [2] is
single TE link. When any component LSP segment is allocated for an required for LSP stitching of an e2e LSP to an S-LSP. Specific
LSP, the component's unreserved bandwidth SHOULD be set to zero and extensions for LSP stitching are described later in Section 5.1.
the Minimum and Maximum LSP bandwidth of the TE link SHOULD be Therefore, in the control plane, there is one RSVP session
recalculated. corresponding to the e2e LSP as well as one for each S-LSP. The
creation and termination of an S-LSP may be dictated by
administrative control (statically provisioned) or due to another
incoming LSP request (dynamic). Triggers for dynamic creation of an
S-LSP may be different from that of an H-LSP and will be described in
detail later.
3. Usage 3. Usage
3.1 LSP regions and LSP stitching 3.1 Triggers for LSP segment setup
An LSP segment may be created either by administrative control An S-LSP may be created either by administrative control
(configuration trigger) or dynamically due to an incoming LSP (configuration trigger) or dynamically due to an incoming LSP
request. LSP Hierarchy ([2]) defines one possible trigger for request. LSP Hierarchy ([2]) defines one possible trigger for
dynamic creation of FA-LSP by introducing the notion of LSP regions dynamic creation of FA-LSP by introducing the notion of LSP regions
based on Interface Switching Capabilities. As per [2], dynamic FA- based on Interface Switching Capabilities. As per [2], dynamic FA-
LSP creation may be triggered on a node when an incoming LSP request LSP creation may be triggered on a node when an incoming LSP request
crosses region boundaries. However, this trigger MUST NOT be used crosses region boundaries. However, this trigger MUST NOT be used
for creation of LSP segment for LSP stitching as described in this for creation of S-LSP for LSP stitching as described in this
document. In case of LSP stitching, the switching capabilities of document. In case of LSP stitching, the switching capabilities of
the previous hop and the next hop TE links MUST be the same. the previous hop and the next hop TE links MUST be the same.
Therefore, local policies configured on the node SHOULD be used for Therefore, local policies configured on the node SHOULD be used for
dynamic creation of LSP segments. dynamic creation of LSP segments.
Other possible triggers for dynamic creation of both FA-LSPs and LSP Other possible triggers for dynamic creation of both H-LSPs and
segments include cases where an e2e LSP may cross domain boundaries S-LSPs include cases where an e2e LSP may cross domain boundaries or
or satisfy locally configured policies on the node as described in satisfy locally configured policies on the node as described in [8].
[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 LSP GMPLS nodes that need to associate an e2e LSP with another S-LSP of
segment of the same switching type and LSP hierarchy procedures do the same switching type and LSP hierarchy procedures do not apply.
not apply. E.g. if an e2e lambda LSP traverses an LSP segment TE E.g. if an e2e lambda LSP traverses an LSP segment TE link which is
link which is also lambda switch capable, then in this case LSP also lambda switch capable, then in this case LSP hierarchy is not
hierarchy is not possible. possible.
LSP stitching procedures could be used for inter-domain TE LSP LSP stitching procedures could be used for inter-domain TE LSP
signaling to stitch an inter-domain LSP to a local intra-domain TE signaling to stitch an inter-domain LSP to a local intra-domain TE
LSP segment ([8]). S-LSP ([8]).
LSP stitching could also be useful in networks to bypass legacy nodes LSP stitching could 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 of course data path. Note, however, that such configuration may limit the
limit the attractiveness of RSVP P2MP and should carefully be attractiveness of RSVP P2MP and should carefully be examined before
examined before deployment. deployment.
4. Signaling aspects 4. Routing aspects
The end nodes of the LSP segment do not have a routing adjacency. An S-LSP is created between two GMPLS nodes and it may traverse zero
However, they will have a signaling adjacency and will exchange RSVP or more GMPLS nodes. There is no forwarding adjacency between the
messages directly between each other. It may, in fact, be desirable end points of an S-LSP TE link. So, although in the TE topology, the
to exchange RSVP Hellos directly between the LSP segment end points end points of an S-LSP TE link are adjacent, in the data plane, these
to allow support for state recovery during Graceful Restart nodes do not have an adjacency. Hence any data plane resource
procedures as described in [4]. identifier between these nodes is also meaningless. The traffic that
arrives at the head end of the S-LSP is switched into the S-LSP
contiguously with a label swap and no label is 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
be numbered or unnumbered. For an unnumbered S-LSP TE link, the
schemes for assignment and handling of the local and remote link
identifiers as specified in [10] SHOULD be used. ISIS/OSPF may flood
the TE information associated with an S-LSP TE link, when
appropriate. Mechanisms similar to that for regular (basic) TE links
SHOULD be used to flood S-LSP TE links. Advertising or flooding the
S-LSP TE link is not a requirement for LSP stitching. Discretion
should be used when advertising an S-LSP TE link in an 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
TE domain in which it is advertised.
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
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
a routing adjacency between them.
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
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,
so no hierarchy is possible.
An S-LSP MUST NOT admit more than one e2e LSP into it. However,
multiple S-LSPs between the same pair of nodes MAY be bundled using
the concept of Link Bundling ([11]) into a single TE link. So, while
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
LSP. When any component S-LSP is allocated for an e2e 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. This will prevent more than one LSP from being
computed and admitted over an S-LSP.
5. Signaling aspects
The end nodes of an S-LSP may or may not have a routing adjacency.
However, they SHOULD have a signaling adjacency (RSVP neighbor
relationship) and will exchange RSVP messages with 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 In order to signal an e2e LSP over an LSP segment, signaling
procedures described in section 8.1.1 of [2] MUST be used. procedures described in section 8.1.1 of [2] MUST be used.
Additional signaling extensions for stitching are described in the Additional signaling extensions for stitching are described in the
next section. next section.
4.1 RSVP-TE signaling extensions 5.1 RSVP-TE signaling extensions
The signaling extensions described here MUST be used if the LSP The signaling extensions described here MUST be used for stitching an
segment is a packet LSP and an e2e packet LSP needs to be stitched to e2e packet or non-packet GMPLS LSP ([4]), to an S-LSP.
it. These extensions are optional for non-packet LSPs and SHOULD be
used if no other local mechanisms exist to automatically detect a
requirement for stitching at both the ingress and egress GMPLS nodes
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 Stitching an e2e LSP to an LSP segment involves the following two
step process : step process :
a. Creating and preparing the LSP segment for stitching by signaling a. Creating and preparing the S-LSP for stitching by signaling the
the desire to stitch between end points of the LSP segment and desire to stitch between end points of the S-LSP and
b. Stitching the e2e LSP to the LSP segment b. Stitching the e2e LSP to the S-LSP
4.1.1 Creating and preparing LSP segment for stitching 5.1.1 Creating and preparing LSP segment for stitching
If a GMPLS node desires to perform LSP stitching, then it MUST If a GMPLS node desires to perform LSP stitching, then it MUST
indicate this in the Path message for the LSP segment that it plans indicate this in the Path message for the S-LSP that it plans to use
to use for stitching. This signaling explicitly informs the egress for stitching. This signaling explicitly informs the S-LSP egress
node for the LSP segment that the ingress node is planning to perform node that the ingress node is planning to perform stitching over the
stitching over the LSP segment. This will allow the egress of the S-LSP. Since an S-LSP is not conceptually different from any other
LSP segment to allocate the correct label(s) as explained below. LSP, explicitly signaling 'LSP stitching desired' helps clarify the
data plane actions to be carried out when the S-LSP is used by some
other e2e LSP. Also, in case of packet LSPs, this is what allows the
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 were carried out at the egress node, a new flag is defined actions will be carried out at the egress node, the egress node MUST
below in the Record Route Object (RRO) Attributes subobject to signal this information back to the head-end node in the Resv, as
indicate that the LSP segment can be used for stitching. explained below.
In order to request LSP stitching on the LSP segment, we define a new In order to request LSP stitching on the S-LSP, we define a new bit
flag bit in the Attributes Flags TLV of the LSP_ATTRIBUTES object in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in
defined in [3]: [3]:
0x02 (TBD): LSP stitching desired bit - This flag will be set in the Bit Number 5 (TBD): LSP stitching desired bit - This bit SHOULD be
Attributes Flags TLV of the LSP_ATTRIBUTES object in the Path message set in the Attributes Flags TLV of the LSP_ATTRIBUTES object in the
for the LSP segment by the head-end of the LSP segment, that desires Path message for the S-LSP by the head-end of the S-LSP, that desires
LSP stitching. This flag MUST NOT be modified by any other nodes in LSP stitching. This bit MUST NOT be modified by any other nodes in
the network. the network. Nodes other than the egress of the S-LSP SHOULD ignore
this bit.
An LSP segment can only be used for stitching if appropriate label An LSP segment can be used for stitching only if the egress node of
actions were carried out at the egress node of the LSP segment. In the S-LSP is also ready to participate in stitching. In order to
order to indicate this to the head-end node of the LSP segment, the indicate this to the head-end node of the S-LSP, the following new
following new flag bit is defined in the RRO Attributes sub-object: bit is defined in the Flags field of the RRO Attributes subobject:
0x02 (TBD): LSP segment stitching ready. Bit Number 5 (TBD): LSP segment stitching ready.
If an egress node receiving a Path message, supports the If an egress node of the S-LSP receiving the Path message, supports
LSP_ATTRIBUTES object and the Attributes Flags TLV, and also the 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" bit, but cannot support the
the requested stitching behavior, then it MUST send back a PathErr requested stitching behavior, then it MUST send back a PathErr
message with an error code of "Routing Problem" and an error sub- message with an error code of "Routing Problem" and an error sub-
code=16 (TBD) "Stitching unsupported" to the head-end node of the LSP code="Stitching unsupported" (TBD) to the head-end node of the S-LSP.
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" bit set in the Flags field of received LSP_ATTRIBUTES,
also supports the desired stitching behavior, then it MUST allocate a recognizes the object, the TLV and the bit and also supports the
non-NULL label for that LSP segment in the corresponding Resv desired stitching behavior, then it MUST allocate a non-NULL label
message. Now, so that the head-end node can ensure that the correct for that S-LSP in the corresponding Resv message. Also, so that the
label actions will be carried out by the egress node and that the LSP head-end node can ensure that the correct label (forwarding) actions
segment can be used for stitching, the egress node MUST set the "LSP will be carried out by the egress node and that the S-LSP can be used
segment stitching ready" bit defined in the RRO Attribute sub-object. for stitching, the egress node MUST set the "LSP segment stitching
Also, when the egress node for the LSP segment receives a Path ready" bit defined in the Flags field of the RRO Attribute sub-
message for an e2e LSP using this LSP segment, it SHOULD first check object.
if it is also the egress for the e2e LSP. If the egress node is the
egress for both the LSP segment as well as the e2e TE LSP, and this
is a packet LSP which requires Penultimate Hop Popping (PHP), then
the node MUST send back a Resv refresh for the LSP segment with a new
label corresponding to the NULL label.
Finally, if the egress node for the LSP segment supports the Finally, if the egress node for the S-LSP supports the LSP_ATTRIBUTES
LSP_ATTRIBUTES object but does not recognize the Attributes Flags object but does not recognize the Attributes Flags TLV, or supports
TLV, or supports the TLV as well but does not recognize this the TLV as well but does not recognize this particular bit, then it
particular flag bit, then it SHOULD simply ignore the above request. SHOULD simply ignore the above request.
An ingress node requesting LSP stitching MUST examine the RRO An ingress node requesting LSP stitching MUST examine the RRO
Attributes sub-object flag corresponding to the egress node for the Attributes sub-object Flags corresponding to the egress node for the
LSP segment, to make sure that stitching actions were carried out at S-LSP, to make sure that stitching actions are carried out at the
the egress node. It MUST NOT use the LSP segment for stitching if egress node. It MUST NOT use the S-LSP for stitching if the "LSP
the "LSP segment stitching ready" flag is cleared. segment stitching ready" bit is cleared.
4.1.2 Stitching the e2e LSP to the LSP segment 5.1.1.1 Steps to support Penultimate Hop Popping
Note that this section is only applicable to packet LSPs that use
Penultimate Hop Popping (PHP) at the last hop, where the egress node
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
PHP is not desired.
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
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
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
Implicit NULL label. Note that this operation does not cause any
traffic disruption since the S-LSP is not carrying any traffic at
this time, since the e2e LSP has not yet been established.
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 LSP segment applicable trigger, it may either dynamically create an S-LSP based
based on procedures described above or it may map an e2e LSP to an on procedures described above or it may map an e2e LSP to an existing
existing LSP segment. The switching type in the Generalized Label S-LSP. The switching type in the Generalized Label Request of the
Request of the e2e LSP MUST be equal to the switching type of the LSP e2e LSP MUST be equal to the switching type of the S-LSP. Other
segment. Other constraints like ERO, bandwidth, local TE policies constraints like ERO, bandwidth, local TE policies MUST also be used
may also be used for LSP segment selection or signaling. In either for S-LSP selection or signaling. In either case, once an S-LSP has
case, once an LSP segment has been selected for an e2e LSP, the been selected for an e2e LSP, the following procedures MUST be
following procedures MUST be followed in order to stitch an e2e LSP followed in order to stitch an e2e LSP to an S-LSP.
to an LSP segment.
The GMPLS node receiving the e2e LSP setup Path message MUST use the The GMPLS node receiving the e2e LSP setup Path message MUST use the
signaling procedures described in [2] to send the Path message signaling procedures described in [2] to send the Path message to the
directly to the end point of the LSP segment. In case of a end point of the S-LSP. In this Path message, the node MUST identify
bidirectional e2e TE LSP, an Upstream Label MUST NOT be allocated and the S-LSP in the RSVP_HOP. An egress node receiving this RSVP_HOP
signaled in the Path message for the e2e LSP over the LSP segment should also be able to identify the S-LSP TE link based on the
hop. information signaled in the RSVP_HOP. If the S-LSP TE link is
numbered, then the addressing scheme as proposed in [2] SHOULD be
used to number the S-LSP TE link. If the S-LSP TE link is
unnumbered, then any of the schemes proposed in [10] SHOULD be used
to exchange S-LSP TE link identifiers between the S-LSP end points.
If the TE link is bundled, the RSVP_HOP SHOULD identify the component
link as defined in [11].
The egress node receiving this Path message MUST NOT allocate any In case of a bidirectional e2e TE LSP, an Upstream Label MUST be
Label in the Resv message for the e2e TE LSP over the LSP segment signaled in the Path message for the e2e LSP over the S-LSP hop.
hop. This Resv message is IP routed back to the previous hop However, since there is no forwarding adjacency between the S-LSP end
(ingress of the LSP segment). points, any label exchanged between them has no significance. So the
node MAY chose any label value for the Upstream Label. The label
value chosen and signaled by the node in the Upstream Label is out of
the scope of this document and is specific to the implementation on
that node. The egress node receiving this Path message MUST ignore
the Upstream Label in the Path message over the S-LSP hop.
The ingress node stitching an e2e TE LSP to an LSP segment MUST The egress node receiving this Path message MUST signal a Label in
ignore any Label object received in the Resv for the e2e TE LSP over the Resv message for the e2e TE LSP over the S-LSP hop. Again, since
the LSP segment hop. there is no forwarding adjacency between the egress and ingress S-LSP
nodes, any label exchanged between them is meaningless. So, the
egress node MAY choose any label value for the Label. The label
value chosen and signaled by the egress node is out of the scope of
this document and is specific to the implementation on the egress
node. The egress S-LSP node SHOULD also carry out data plane
operations so that traffic coming in on the S-LSP is switched over to
the e2e LSP downstream, if the egress of the e2e LSP is some other
node downstream. If the e2e LSP is bidirectional, this means setting
up label switching in both directions. The Resv message from the
egress S-LSP node is IP routed back to the previous hop (ingress of
the S-LSP). The ingress node stitching an e2e TE LSP to an S-LSP
MUST ignore the Label object received in the Resv for the e2e TE LSP
over the S-LSP hop. The S-LSP ingress node SHOULD also carry out
data plane operations so that traffic coming in on the e2e LSP is
switched into the S-LSP. It should also carry out actions to handle
traffic in the opposite direction if the e2e LSP is bidirectional.
So, the main difference between signaling an e2e LSP over an LSP Note that the label exchange procedure for LSP stitching on the S-LSP
segment instead of over an FA-LSP is that no Labels are allocated and hop, is similar to that for LSP hierarchy over the H-LSP hop. The
exchanged for the e2e LSP over the LSP segment hop. So, at most one difference is the lack of the significance of this label between the
e2e LSP is associated with one LSP segment. If a node at the head- S-LSP end points in case of stitching. Therefore, in case of
end of an LSP segment receives a Path Msg for an LSP that identifies stitching the recepients of the Label/Upstream Label MUST NOT process
the LSP segment in the ERO and the LSP segment bandwidth has already these labels. Also, at most one e2e LSP is associated with one
been allocated to some other LSP, then regular rules of RSVP-TE pre- S-LSP. If a node at the head-end of an S-LSP receives a Path Msg for
emption apply. If the LSP request over the LSP segment cannot be an e2e LSP that identifies the S-LSP in the ERO and the S-LSP
satisfied, then the node SHOULD send back a PathErr with the error bandwidth has already been allocated to some other LSP, then regular
codes as described in [5]. rules of RSVP-TE pre-emption apply to resolve contention for S-LSP
bandwidth. If the LSP request over the S-LSP cannot be satisfied,
then the node SHOULD send back a PathErr with the error codes as
described in [5].
4.1.3 RRO Processing for e2e LSP 5.1.3 RRO Processing for e2e LSP
RRO procedures for the LSP segment specific to LSP stitching are RRO procedures for the S-LSP specific to LSP stitching are already
already described in Section 4.1.1. In this section we will look at described in Section 5.1.1. In this section we will look at the RRO
the RRO processing for the e2e LSP over the LSP segment hop. processing for the e2e LSP over the S-LSP hop.
An e2e LSP traversing an LSP segment, SHOULD record in the RRO for An e2e LSP traversing an S-LSP, SHOULD record in the RRO for that
that hop, an identifier corresponding to the LSP segment TE link. hop, an identifier corresponding to the S-LSP TE link. This is
This is applicable to both Path and Resv messages over the LSP applicable to both Path and Resv messages over the S-LSP hop. If the
segment hop. If the LSP segment is numbered, then the IPv4 or IPv6 S-LSP is numbered, then the IPv4 or IPv6 address subobject ([5])
address subobject ([5]) SHOULD be used to record the LSP segment TE SHOULD be used to record the S-LSP TE link address. If the S-LSP is
link address. If the LSP segment is unnumbered, then the Unnumbered unnumbered, then the Unnumbered Interface ID subobject as described
Interface ID subobject as described in [9] SHOULD be used to record in [10] SHOULD be used to record the node's Router ID and Interface
the node's Router ID and Interface ID of the LSP segment TE link. In ID of the S-LSP TE link. In either case, the RRO subobject SHOULD
either case, the RRO subobject SHOULD identify the LSP segment TE identify the S-LSP TE link end point. Intermediate links or nodes
link end point (link or node). Intermediate links or nodes traversed traversed by the S-LSP itself SHOULD NOT be recorded in the RRO for
by the LSP segment itself SHOULD NOT be recorded in the RRO for the the e2e LSP over the S-LSP hop.
e2e LSP over the LSP segment hop.
4.2 Summary of LSP Stitching procedures 5.1.4 Teardown of LSP segment
4.2.1 Example topology S-LSP teardown follows the standard procedures defined in [5] and
[4]. This includes procedures without and with setting the
administrative status. Teardown of S-LSP may be initiated by either
the ingress, egress or any other node along the S-LSP path.
Deletion/teardown of the S-LSP SHOULD be treated as a failure event
for the e2e LSP associated with it and corresponding teardown or
recovery procedures SHOULD be triggered for the e2e LSP. In case of
S-LSP teardown for maintenance purpose, the S-LSP ingress node MAY
treat this to be equivalent to administratively shutting down a TE
link along the e2e LSP path and take corresponding actions to notify
the ingress of this event. The actual signaling procedures to handle
this event is out of the scope of this document.
5.1.5 Teardown of e2e LSP
e2e LSP teardown also follows standard procedures defined in [5] and
[4] either without or with the administrative status. Note, however,
that teardown procedures of e2e LSP and of S-LSP are independent of
each other. So, it is possible that while one LSP follows graceful
teardown with adminstrative status, the other LSP is torn down
without administrative status (using PathTear/ResvTear/PathErr with
state removal).
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 IP routed to the LSP segment egress
node with the destination IP address of the Path message set to the
address of the S-LSP 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 S-LSP. The
unreserved bandwidth on the S-LSP TE link SHOULD be re-adjusted.
Similarly, 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 S-LSP MUST propagate the ResvTear/PathErr upstream, IP
routed 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 S-LSP was statically provisioned, tearing down of an e2e LSP
MAY not result in tearing down of the S-LSP. If, however, the S-LSP
was dynamically setup due to the e2e LSP setup request, then
depending on local policy, the S-LSP MAY be torn down if no e2e LSP
is utilizing the S-LSP. Although the S-LSP may be torn down while
the e2e LSP is being torn down, it is RECOMMENDED that a delay be
introduced in tearing down the S-LSP 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.
5.2 Summary of LSP Stitching procedures
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 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 (no Upstream Label) PATH (Upstream Label)
+++++++++++++++++++++++ +++++++++++++++++++++++
++++++ +++++> ++++++ +++++>
<+++++ ++++++ <++++++ ++++++
+++++++++++++++++++++++ +++++++++++++++++++++++
RESV (no Label) RESV (Label)
4.2.2 LSP segment setup
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
use for stitching may be dictated either by configuration or
dynamically on arrival of an LSP setup request at the GMPLS node.
Successful completion of signaling procedures for the LSP segment as
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
unreserved bandwidth in the IGP and b) carry out stitching procedures
to actually stitch an e2e LSP to the LSP segment. Note that it is
not, however, required to advertise the LSP segment TE link in the
IGP in the first place. Similar to setup, tearing down the LSP
segment may also be decided either via local configuration or due to
the fact that there is no longer an e2e LSP stitched to the LSP
segment. E.g. Let us consider an LSP segment LSP-AB being setup
between two nodes A and B which may be one or more hops away. A
sends a Path message for the LSP-AB with "LSP stitching desired". If
on the egress node B, stitching procedures are successfully carried
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.3 Setup of e2e LSP
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
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
any other basic TE link in the domain will not be advertised outside
the domain. In this case, either per-domain path computation ([11])
or PCE based computation ([12]) will permit setting up e2e LSPs over
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
or ERO hops signaled for the e2e LSP may be used as a criterion for
LSP segment selection or signaling. E.g. Let us consider an e2e LSP
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.2.4 Stitching of e2e LSP into an LSP segment
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
Path message for the e2e LSP is then sent directly (IP routed) to the
LSP segment end node with the destination IP address of the Path
message set to the address of the LSP segment end node. The Router
Alert option MUST NOT be set in this case. Furthermore, when the
message arrives at the end node, RSVP TTL checks MUST be disabled.
The LSP segment MUST be identified in the IF_ID RSVP_HOP (PHOP)
object of the Path message. It is assumed that the receiver of this
Path message can identify the LSP segment based on the data interface
identification in the IF_ID RSVP_HOP. Also, if the e2e LSP is
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
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
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
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
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
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
between nodes A and B. In the data plane, this yields a series of
label swaps from R1 to R2 along LSP LSP1-2.
4.2.5 Teardown of e2e LSP 5.2.2 LSP segment setup
When an e2e LSP teardown is initiated from the head-end, and a Let us consider an S-LSP LSP-AB being setup between two nodes A and B
PathTear arrives at the GMPLS stitching node, the PathTear message which are more than one hop away. Node A sends a Path message for
like the Path message MUST be sent directly to the LSP segment egress the LSP-AB with "LSP stitching desired" set in Flags field of
node with the destination IP address of the Path message set to the LSP_ATTRIBUTES object. If the egress node B is ready to carry out
address of the LSP segment end node. Router Alert MUST be off and stitching procedures, then B will respond with "LSP segment stitching
RSVP TTL check MUST be disabled on the receiving node. PathTear will ready" set in the Flags field of the RRO Attributes subobject, in the
result in deletion of RSVP states corresponding to the e2e LSP and RRO sent in the Resv for the S-LSP. Once A receives the Resv for
freeing of label allocations and bandwidth reservations on the LSP LSP-AB and sees this bit set in the RRO, it can then use LSP-AB for
segment. The unreserved bandwidth on the LSP segment TE link SHOULD stitching. A cannot use LSP-AB for stitching if the bit is cleared
be re-adjusted. in the RRO.
Simiarly, a teardown of the e2e LSP may be initiated from the tail- 5.2.3 Setup of e2e LSP
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 Let us consider an e2e LSP LSP1-2 starting one hop before A on R1 and
applicable to stitched LSPs. ending on node R2, as shown above. If the S-LSP has been adevrtised
as a TE link in the TE domain, and R1 and A are in the same domain,
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
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
distinguished from any basic TE link on R1. If R1 and A are in
different domains, then LSP1-2 is an inter-domain LSP. In this case,
S-LSP LSP-AB, similar to any other basic TE link in the domain will
not be advertised outside the domain. R1 would use either per-domain
path computation ([12]) or PCE based computation ([13]) for LSP1-2.
If the LSP segment was statically provisioned, tearing down of an e2e 5.2.4 Stitching of e2e LSP into an LSP segment
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 When the Path message for the e2e LSP LSP1-2 arrives at node A, A
maintenance) SHOULD be treated as a failure event for the e2e LSP matches the switching type of LSP1-2 with the S-LSP LSP-AB. If the
associated with it and corresponding teardown or recovery procedures switching types are not equal, then LSP-AB cannot be used to stitch
SHOULD be triggered for the e2e LSP. LSP1-2. Once S-LSP LSP-AB to stitch LSP1-2 to has been determined
successfully, the Path message for LSP1-2 is IP routed to node B with
the IF_ID RSVP_HOP identifying the S-LSP LSP-AB. When B receives
this Path message for LSP1-2, if B is also the egress for LSP1-2, and
if this is a packet LSP requiring PHP, then B will send a Resv
refresh for LSP-AB with the NULL Label. In this case, since B is not
the egress, the Path message for LSP1-2 is propagated to R2. The
Resv for LSP1-2 from B is IP routed back to A with a Label value
chosen by B. B also sets up its data plane to swap the Label sent to
either G or H on the S-LSP with the Label received from R2. Node A
ignores the Label on receipt of the Resv message and then propagates
the Resv to R1. A also sets up its data plane to swap the Label sent
to R1 with the Label received on the S-LSP from C or D. This stitches
the e2e LSP LSP1-2 to an S-LSP LSP-AB between nodes A and B. In the
data plane, this yields a series of label swaps from R1 to R2 along
e2e LSP LSP1-2.
5. 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
associations based on receiver's IP address instead of the sending associations based on receiver's IP address instead of the 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 7. IANA Considerations
The following values have to be defined by IANA for this document. The following values have to be defined by IANA for this document.
The registry is http://www.iana.org/assignments/rsvp-parameters. The registry is http://www.iana.org/assignments/rsvp-parameters.
6.1 Attribute Flags for LSP_ATTRIBUTES object 7.1 Attribute Flags for LSP_ATTRIBUTES object
The following new flag bit is being defined for the Attributes Flags The following new bit is being defined for the Attributes Flags TLV
TLV in the LSP_ATTRIBUTES object. The numeric value should be in the LSP_ATTRIBUTES object. The numeric value should be assigned
assigned by IANA. by IANA.
LSP stitching desired bit - 0x02 (Suggested value) LSP stitching desired bit - Bit Number 5 (Suggested value)
This flag bit is only to be used in the Attributes Flags TLV on a This bit is only to be used in the Attributes Flags TLV on a Path
Path message. message.
The 'LSP stitching desired bit' has a corresponding 'LSP segment The 'LSP stitching desired bit' has a corresponding 'LSP segment
stitching ready' bit to be used in the RRO Attributes sub-object. stitching ready' bit (Bit Number 5) to be used in the RRO Attributes
sub-object.
6.2 New Error Codes 7.2 New Error Codes
The following new error sub-code is being defined under the RSVP The following new error sub-code is being defined under the RSVP
error-code "Routing Problem" (24). The numeric error sub-code value error-code "Routing Problem" (24). The numeric error sub-code value
should be assigned by IANA. should be assigned by IANA.
Stitching unsupported - sub-code 16 (Suggested value) Stitching unsupported - sub-code 23 (Suggested value)
This error code is to be used only in a RSVP PathErr. This error code is to be used only in an RSVP PathErr.
7. Acknowledgments 8. Acknowledgments
The authors would like to thank Adrian Farrel and Kireeti Kompella The authors would like to thank Adrian Farrel and Kireeti Kompella
for their comments and suggestions. The authors would also like to for their comments and suggestions. The authors would also like to
thank Dimitri Papadimitriou and Igor Bryskin for their thorough thank Dimitri Papadimitriou and Igor Bryskin for their thorough
review of the document and discussions regarding the same. review of the document and discussions regarding the same.
8. References 9. References
8.1 Normative References 9.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized [2] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08 (work in progress), MPLS TE", draft-ietf-mpls-lsp-hierarchy-08 (work in progress),
September 2002. September 2002.
[3] Farrel, A., "Encoding of Attributes for Multiprotocol Label [3] Farrel, A., "Encoding of Attributes for Multiprotocol Label
Switching (MPLS) Label Switched Path (LSP) Establishment Using Switching (MPLS) Label Switched Path (LSP) Establishment Using
skipping to change at page 17, line 32 skipping to change at page 17, line 32
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 9.2 Informative References
[7] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE [7] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE
LSPs", draft-ietf-mpls-rsvp-te-p2mp-01 (work in progress), LSPs", draft-ietf-mpls-rsvp-te-p2mp-01 (work in progress),
January 2005. January 2005.
[8] Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic [8] Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensions", Engineering - RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-00 (work in progress), draft-ietf-ccamp-inter-domain-rsvp-te-00 (work in progress),
February 2005. February 2005.
[9] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in [9] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci,
D., Li, T., and A. Conta, "MPLS Label Stack Encoding",
RFC 3032, January 2001.
[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.
[10] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in [11] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in
MPLS Traffic Engineering", draft-ietf-mpls-bundle-06 (work in MPLS Traffic Engineering", draft-ietf-mpls-bundle-06 (work in
progress), December 2004. progress), December 2004.
[11] Vasseur, J., "A Per-domain path computation method for [12] Vasseur, J., "A Per-domain path computation method for
computing Inter-domain Traffic Engineering (TE) Label Switched computing Inter-domain Traffic Engineering (TE) Label Switched
Path (LSP)", draft-vasseur-ccamp-inter-domain-pd-path-comp-00 Path (LSP)", draft-vasseur-ccamp-inter-domain-pd-path-comp-00
(work in progress), February 2005. (work in progress), February 2005.
[12] Farrel, A., "Path Computation Element (PCE) Architecture", [13] Farrel, A., "Path Computation Element (PCE) Architecture",
draft-ietf-pce-architecture-00 (work in progress), March 2005. draft-ietf-pce-architecture-00 (work in progress), March 2005.
Authors' Addresses Authors' Addresses
Arthi Ayyangar (editor) Arthi Ayyangar (editor)
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
 End of changes. 79 change blocks. 
382 lines changed or deleted 456 lines changed or added

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