draft-ietf-ccamp-lsp-stitching-05.txt   draft-ietf-ccamp-lsp-stitching-06.txt 
Network Working Group A. Ayyangar Network Working Group A. Ayyangar
Internet-Draft Nuova Systems Internet-Draft Nuova Systems
Intended status: Standards Track K. Kompella Intended status: Standards Track K. Kompella
Expires: September 2007 Juniper Networks Expires: October 2007 Juniper Networks
JP. Vasseur JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
A. Farrel A. Farrel
Old Dog Consulting Old Dog Consulting
Label Switched Path Stitching with Generalized Multiprotocol Label Switched Path Stitching with Generalized Multiprotocol
Label Switching Traffic Engineering (GMPLS TE) Label Switching Traffic Engineering (GMPLS TE)
draft-ietf-ccamp-lsp-stitching-05.txt draft-ietf-ccamp-lsp-stitching-06.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 41 skipping to change at page 2, line 5
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 1, 2007. This Internet-Draft will expire on September 1, 2007.
Copyright Notice
Copyright (C) The Internet Society (2007).
Abstract Abstract
In certain scenarios, there may be a need to combine together several In certain scenarios, there may be a need to combine together several
Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Generalized Multi-Protocol Label Switching (GMPLS) Label Switched
Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and
all traffic from one constituent LSP is switched onto the next LSP. all traffic from one constituent LSP is switched onto the next LSP.
We will refer to this as "LSP stitching", the key requirement being We will refer to this as "LSP stitching", the key requirement being
that a constituent LSP not be allocated to more than one e2e LSP. that a constituent LSP not be allocated to more than one e2e LSP.
The constituent LSPs will be referred to as "LSP segments" (S-LSPs). The constituent LSPs will be referred to as "LSP segments" (S-LSPs).
skipping to change at page 4, line 14 skipping to change at page 4, line 14
1. Introduction 1. Introduction
A stitched Generalized Multiprotocol Label Switching (GMPLS) Traffic A stitched Generalized Multiprotocol Label Switching (GMPLS) Traffic
Engineering (TE) Label Switched Path (LSP) is built from a set of Engineering (TE) Label Switched Path (LSP) is built from a set of
different LSP segments (S-LSPs) that are connected together in the different LSP segments (S-LSPs) that are connected together in the
data plane in such a way that a single end-to-end LSP is realized in data plane in such a way that a single end-to-end LSP is realized in
the data plane. In this document, we define the concept of LSP the data plane. In this document, we define the concept of LSP
stitching and detail the control plane mechanisms and procedures stitching and detail the control plane mechanisms and procedures
(routing and signaling) to accomplish this. Where applicable, (routing and signaling) to accomplish this. Where applicable,
similarities and differences between LSP hierarchy [2] and LSP similarities and differences between LSP hierarchy [RFC4206] and LSP
stitching are highlighted. Signaling extensions required for LSP stitching are highlighted. Signaling extensions required for LSP
stitching are also described here. stitching are also described here.
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, and such that the operation is completely transparent to whatsoever, and such that the operation is completely transparent to
other nodes. This results in LSP stitching in the data plane, but other nodes. This results in LSP stitching in the data plane, but
requires management intervention at the node where the stitching is requires management intervention at the node where the stitching is
performed. With the mechanism described in this document, the node performed. With the mechanism described in this document, the node
performing the stitching does not require configuration of the pair performing the stitching does not require configuration of the pair
of S-LSPs to be stitched together. Also, LSP stitching as defined of S-LSPs to be stitched together. Also, LSP stitching as defined
here results in an end-to-end LSP both in the control and data here results in an end-to-end LSP both in the control and data
planes. planes.
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 [RFC2119].
2. Comparison with LSP Hierarchy 2. Comparison with LSP Hierarchy
LSP hierarchy ([2]) provides signaling and routing procedures so LSP hierarchy ([RFC4206]) provides signaling and routing procedures
that: so 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 appear as a data link to LSPs in higher layers. in one layer can appear as a data link to LSPs in higher layers.
As such, one or more LSPs in a higher layer can traverse this As such, one or more LSPs in a higher layer can traverse this
H-LSP as a single hop; we call this "nesting". 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
H-LSP may also be advertised as a TE link in a different TE 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 domain. In this case, the end points of the H-LSP are required
have a routing adjacency between them. have a routing adjacency between them.
c. RSVP signaling ([4], [5]) for LSP setup can occur between nodes c. RSVP signaling ([RFC3473], [RFC3209]) for LSP setup can occur
that do not have a routing adjacency. between nodes that do not have a routing adjacency.
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 so advertised, other Generalized Multiprotocol Label one. If so advertised, other Generalized Multiprotocol Label
Switching (GMPLS) nodes can use the corresponding S-LSP TE link in Switching (GMPLS) nodes can use the corresponding S-LSP TE link in
skipping to change at page 5, line 38 skipping to change at page 5, line 38
with an S-LSP. Thus, 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, and LSP3 can potentially be then multiple LSPs, say LSP1, LSP2, and LSP3 can potentially be
'nested into' LSP-AB. This is achieved by exchanging a unique label 'nested into' LSP-AB. This is achieved by exchanging a unique label
for each of LSP1..3 over the LSP-AB hop, thereby separating the data for each of LSP1..3 over the LSP-AB hop, thereby separating the data
corresponding to each of LSP1..3 while traversing the H-LSP LSP-AB. corresponding to each of LSP1..3 while traversing the H-LSP LSP-AB.
Each of LSP1..3 may reserve some bandwidth on LSP-AB. On the other 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 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 then dedicated to LSP1 and stitched to the S-LSP LSP-AB. LSP-AB is then dedicated to LSP1 and
no other LSPs can be associated with LSP-AB. The entire bandwith on no other LSPs can be associated with LSP-AB. The entire bandwith on
S-LSP LSP-AB is allocated to LSP1. However, similar to H-LSPs, S-LSP LSP-AB is allocated to LSP1. However, similar to H-LSPs,
several S-LSPs may be bundled into a TE link ([11]). several S-LSPs may be bundled into a TE link ([RFC4201]).
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 e2e LSPs in the rest of this document. Routing are termed as e2e LSPs in the rest of this document. Routing
procedures specific to LSP stitching are detailed in Section 4. procedures specific to LSP stitching are detailed in Section 4.
Targetted (non-adjacent) RSVP signaling defined in [2] is required Targetted (non-adjacent) RSVP signaling defined in [RFC4206] is
for LSP stitching of an e2e LSP to an S-LSP. Specific extensions for required for LSP stitching of an e2e LSP to an S-LSP. Specific
LSP stitching are described later in Section 5.1. Therefore, in the extensions for LSP stitching are described later in Section 5.1.
control plane, there is one RSVP session corresponding to the e2e LSP Therefore, in the control plane, there is one RSVP session
as well as one for each S-LSP. The creation and termination of an corresponding to the e2e LSP as well as one for each S-LSP. The
S-LSP may be dictated by administrative control (statically creation and termination of an S-LSP may be dictated by
provisioned) or due to another incoming LSP request (dynamic). administrative control (statically provisioned) or due to another
Triggers for dynamic creation of an S-LSP may be different from that incoming LSP request (dynamic). Triggers for dynamic creation of an
of an H-LSP and will be described in detail later. S-LSP may be different from that of an H-LSP and will be described in
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 ([RFC4206]) 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 [RFC4206], dynamic
LSP creation may be triggered on a node when an incoming LSP request FA-LSP creation may be triggered on a node when an incoming LSP
crosses region boundaries. However, this trigger MUST NOT be used request crosses region boundaries. However, this trigger MUST NOT be
for creation of S-LSP for LSP stitching as described in this used for creation of S-LSP for LSP stitching as described in this
document. In case of LSP stitching, the switching capabilities of document. In case of LSP stitching, the switching capabilities of
the previous hop and the next hop TE links MUST be the same. the previous hop and the next hop TE links MUST be the same.
Therefore, local policies configured on the node SHOULD be used for Therefore, local policies configured on the node SHOULD be used for
dynamic creation of LSP segments. dynamic creation of LSP segments.
Other possible triggers for dynamic creation of both H-LSPs and Other possible triggers for dynamic creation of both H-LSPs and
S-LSPs include cases where an e2e LSP may cross domain boundaries or S-LSPs include cases where an e2e LSP may cross domain boundaries or
satisfy locally configured policies on the node as described in [8]. satisfy locally configured policies on the node as described in
[RSVP-INTER].
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 LSP hierarchy is not possible; in also lambda switch capable, then LSP hierarchy is not possible; in
this case, LSP switching may be an option. this case, LSP switching may be an option.
LSP stitching procedures can be used for inter-domain TE LSP LSP stitching procedures can be used for inter-domain TE LSP
signaling to stitch an inter-domain e2e LSP to a local intra-domain signaling to stitch an inter-domain e2e LSP to a local intra-domain
TE S-LSP ([18] and [8]). TE S-LSP ([RFC4726] and [RSVP-INTER]).
LSP stitching may 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 the case of and/or data plane. E.g., one suggested usage in the case of
point-to-multipoint (P2MP) RSVP LSPs ([7]) is the use of LSP point-to-multipoint (P2MP) RSVP LSPs ([RSVP-P2MP]) is the use of LSP
stitching to stitch a P2MP RSVP LSP to an LSP segment between P2MP stitching to stitch a P2MP RSVP LSP to an LSP segment between P2MP
capable Label Switching Routers (LSRs) in the network. The LSP capable Label Switching Routers (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
skipping to change at page 7, line 20 skipping to change at page 7, line 20
topology, the end points of an S-LSP TE link are adjacent, in the topology, the end points of an S-LSP TE link are adjacent, in the
data plane, these nodes do not have an adjacency. Hence any data data plane, these nodes do not have an adjacency. Hence any data
plane resource identifier between these nodes is also meaningless. plane resource identifier between these nodes is also meaningless.
The traffic that arrives at the head end of the S-LSP is switched 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 into the S-LSP contiguously with a label swap and no label is
associated directly 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. When appropriate, identifiers as specified in [RFC3477] SHOULD be used. When
the TE information associated with an S-LSP TE link MAY be flooded appropriate, the TE information associated with an S-LSP TE link MAY
via ISIS-TE [13] or OSPF-TE [12]. Mechanisms similar to that for be flooded via ISIS-TE [RFC4205] or OSPF-TE [RFC4203]. Mechanisms
regular (basic) TE links SHOULD be used to flood S-LSP TE links. similar to that for regular (basic) TE links SHOULD be used to flood
Advertising or flooding the S-LSP TE link is not a requirement for S-LSP TE links. Advertising or flooding the S-LSP TE link is not a
LSP stitching. If advertised, this TE information will exist in the requirement for LSP stitching. If advertised, this TE information
TE database (TED) and can then be used for path computation by other will exist in the TE database (TED) and can then be used for path
GMPLS nodes in the TE domain in which it is advertised. When so computation by other GMPLS nodes in the TE domain in which it is
advertising S-LSPs, one should keep in mind that these add to the advertised. When so advertising S-LSPs, one should keep in mind that
size and complexity of the link-state database. 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 [RFC4206] SHOULD be used for
S-LSP TE link as well. The switching capability of an S-LSP TE link an S-LSP TE link as well. The switching capability of an S-LSP TE
MUST be equal to the switching type of the underlying S-LSP; i.e. an link MUST be equal to the switching type of the underlying S-LSP;
S-LSP TE link provides a data link to other LSPs in the same layer, i.e. an S-LSP TE link provides a data link to other LSPs in the same
so no hierarchy is possible. layer, so no hierarchy is possible.
An S-LSP MUST NOT admit more than one e2e LSP into it. If an S-LSP An S-LSP MUST NOT admit more than one e2e LSP into it. If an S-LSP
is allocated to an e2e LSP, the unreserved bandwidth SHOULD be set to is allocated to an e2e LSP, the unreserved bandwidth SHOULD be set to
zero to prevent further e2e LSPs being admitted into the S-LSP. zero to prevent further e2e LSPs being admitted into the S-LSP.
Multiple S-LSPs between the same pair of nodes MAY be bundled using Multiple S-LSPs between the same pair of nodes MAY be bundled using
the concept of Link Bundling ([11]) into a single TE link. In this the concept of Link Bundling ([RFC4201]) into a single TE link. In
case, each component S-LSP may be allocated to at most one e2e LSP. this case, each component S-LSP may be allocated to at most one e2e
When any component S-LSP is allocated for an e2e LSP, the component's LSP. When any component S-LSP is allocated for an e2e LSP, the
unreserved bandwidth SHOULD be set to zero and the Minimum and component's unreserved bandwidth SHOULD be set to zero and the
Maximum LSP bandwidth of the TE link SHOULD be recalculated. This Minimum and Maximum LSP bandwidth of the TE link SHOULD be
will prevent more than one LSP from being computed and admitted over recalculated. This will prevent more than one LSP from being
an S-LSP. 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 [RFC3473].
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 [RFC4206] MUST be used.
Additional signaling extensions for stitching are described in the Additional signaling extensions for stitching are described in the
next section. next section.
5.1. RSVP-TE Signaling Extensions 5.1. RSVP-TE Signaling Extensions
The signaling extensions described here MUST be used for stitching an The signaling extensions described here MUST be used for stitching an
e2e packet or non-packet GMPLS LSP ([4]), to an S-LSP. e2e packet or non-packet GMPLS LSP ([RFC3473]), 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:
1. 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
2. stitching the e2e LSP to the S-LSP. 2. stitching the e2e LSP to the S-LSP.
5.1.1. Creating and Preparing an LSP Segment for Stitching 5.1.1. Creating and Preparing an LSP Segment for Stitching
skipping to change at page 8, line 50 skipping to change at page 8, line 50
plane actions to be carried out when the S-LSP is used by some other 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 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]: [RFC4420]:
LSP stitching desired bit - This bit SHOULD be set in the Attributes LSP stitching desired bit - This bit SHOULD be set in the Attributes
Flags TLV of the LSP_ATTRIBUTES object in the Path message for the Flags TLV of the LSP_ATTRIBUTES object in the Path message for the
S-LSP by the head-end of the S-LSP, that desires LSP stitching. This S-LSP by the head-end of the S-LSP, that desires LSP stitching. This
bit MUST NOT be modified by any other nodes in the network. Nodes bit MUST NOT be modified by any other nodes in the network. Nodes
other than the egress of the S-LSP SHOULD ignore this bit. The bit other than the egress of the S-LSP SHOULD ignore this bit. The bit
number for this flag is defined in Section 7.1. number for this flag is defined in Section 7.1.
An LSP segment can be used for stitching only if the egress node of An LSP segment can be used for stitching only if the egress node of
the S-LSP is also ready to participate in stitching. In order to the S-LSP is also ready to participate in stitching. In order to
skipping to change at page 9, line 49 skipping to change at page 9, line 49
An ingress node requesting LSP stitching MUST examine the RRO An ingress node requesting LSP stitching MUST examine the RRO
Attributes sub-object Flags corresponding to the egress node for the Attributes sub-object Flags corresponding to the egress node for the
S-LSP, to make sure that stitching actions are carried out at the S-LSP, to make sure that stitching actions are carried out at the
egress node. It MUST NOT use the S-LSP for stitching if the "LSP egress node. It MUST NOT use the S-LSP for stitching if the "LSP
segment stitching ready" bit is cleared. segment stitching ready" bit is cleared.
5.1.1.1. Steps to Support Penultimate Hop Popping 5.1.1.1. Steps to Support Penultimate Hop Popping
Note that this section is only applicable to packet LSPs that use Note that this section is only applicable to packet LSPs that use
Penultimate Hop Popping (PHP) at the last hop, where the egress node Penultimate Hop Popping (PHP) at the last hop, where the egress node
distributes the Implicit NULL Label ([9]) in the Resv Label. These distributes the Implicit NULL Label ([RFC3032]) in the Resv Label.
steps MUST NOT be used for a non-packet LSP and for packet LSPs where These steps MUST NOT be used for a non-packet LSP and for packet LSPs
PHP is not desired. where 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 or Explicit NULL label. Note that this operation does not Implicit or Explicit NULL label. Note that this operation does not
cause any traffic disruption since the S-LSP is not carrying any 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. traffic at this time, since the e2e LSP has not yet been established.
skipping to change at page 10, line 35 skipping to change at page 10, line 35
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 the explicit path encoded in the Explicit Route constraints like the explicit path encoded in the Explicit Route
object (ERO), bandwidth, local TE policies MUST also be used for object (ERO), bandwidth, local TE policies MUST also be used for
S-LSP selection or signaling. In either case, once an S-LSP has been S-LSP selection or signaling. In either case, once an S-LSP has been
selected for an e2e LSP, the following procedures MUST be followed in selected for an e2e LSP, the following procedures MUST be followed in
order to stitch an e2e LSP to an S-LSP. order to stitch an e2e LSP to an S-LSP.
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 to the signaling procedures described in [RFC4206] to send the Path message
end point of the S-LSP. In this Path message, the node MUST identify to the end point of the S-LSP. In this Path message, the node MUST
the S-LSP in the RSVP_HOP. An egress node receiving this RSVP_HOP identify the S-LSP in the RSVP_HOP. An egress node receiving this
should also be able to identify the S-LSP TE link based on the RSVP_HOP should also be able to identify the S-LSP TE link based on
information signaled in the RSVP_HOP. If the S-LSP TE link is the information signaled in the RSVP_HOP. If the S-LSP TE link is
numbered, then the addressing scheme as proposed in [2] SHOULD be numbered, then the addressing scheme as proposed in [RFC4206] SHOULD
used to number the S-LSP TE link. If the S-LSP TE link is 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 unnumbered, then any of the schemes proposed in [RFC3477] SHOULD be
to exchange S-LSP TE link identifiers between the S-LSP end points. used to exchange S-LSP TE link identifiers between the S-LSP end
If the TE link is bundled, the RSVP_HOP SHOULD identify the component points. If the TE link is bundled, the RSVP_HOP SHOULD identify the
link as defined in [11]. component link as defined in [RFC4201].
In case of a bidirectional e2e TE LSP, an Upstream Label MUST be In case of a bidirectional e2e TE LSP, an Upstream Label MUST be
signaled in the Path message for the e2e LSP over the S-LSP hop. signaled in the Path message for the e2e LSP over the S-LSP hop.
However, since there is no forwarding adjacency between the S-LSP end However, since there is no forwarding adjacency between the S-LSP end
points, any label exchanged between them has no significance. So the points, any label exchanged between them has no significance. So the
node MAY chose any label value for the Upstream Label. The label 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 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 the scope of this document and is specific to the implementation on
that node. The egress node receiving this Path message MUST ignore that node. The egress node receiving this Path message MUST ignore
the Upstream Label in the Path message over the S-LSP hop. the Upstream Label in the Path message over the S-LSP hop.
skipping to change at page 11, line 38 skipping to change at page 11, line 38
difference is the lack of the significance of this label between the difference is the lack of the significance of this label between the
S-LSP end points in case of stitching. Therefore, in case of S-LSP end points in case of stitching. Therefore, in case of
stitching the recepients of the Label/Upstream Label MUST NOT process stitching the recepients of the Label/Upstream Label MUST NOT process
these labels. Also, at most one e2e LSP is associated with one these labels. Also, at most one e2e LSP is associated with one
S-LSP. If a node at the head-end of an S-LSP receives a Path Msg for S-LSP. If a node at the head-end of an S-LSP receives a Path Msg for
an e2e LSP that identifies the S-LSP in the ERO and the S-LSP an e2e LSP that identifies the S-LSP in the ERO and the S-LSP
bandwidth has already been allocated to some other LSP, then regular bandwidth has already been allocated to some other LSP, then regular
rules of RSVP-TE pre-emption apply to resolve contention for S-LSP rules of RSVP-TE pre-emption apply to resolve contention for S-LSP
bandwidth. If the LSP request over the S-LSP cannot be satisfied, bandwidth. If the LSP request over the S-LSP cannot be satisfied,
then the node SHOULD send back a PathErr with the error codes as then the node SHOULD send back a PathErr with the error codes as
described in [5]. described in [RFC3209].
5.1.3. RRO Processing for e2e LSPs 5.1.3. RRO Processing for e2e LSPs
RRO procedures for the S-LSP specific to LSP stitching are already RRO procedures for the S-LSP specific to LSP stitching are already
described in Section 5.1.1. In this section we will look at the RRO described in Section 5.1.1. In this section we will look at the RRO
processing for the e2e LSP over the S-LSP hop. processing for the e2e LSP over the S-LSP hop.
An e2e LSP traversing an S-LSP, SHOULD record in the RRO for that An e2e LSP traversing an S-LSP, SHOULD record in the RRO for that
hop, an identifier corresponding to the S-LSP TE link. This is hop, an identifier corresponding to the S-LSP TE link. This is
applicable to both Path and Resv messages over the S-LSP hop. If the applicable to both Path and Resv messages over the S-LSP hop. If the
S-LSP is numbered, then the IPv4 or IPv6 address subobject ([5]) S-LSP is numbered, then the IPv4 or IPv6 address subobject
SHOULD be used to record the S-LSP TE link address. If the S-LSP is ([RFC3209]) SHOULD be used to record the S-LSP TE link address. If
unnumbered, then the Unnumbered Interface ID subobject as described the S-LSP is unnumbered, then the Unnumbered Interface ID subobject
in [10] SHOULD be used to record the node's Router ID and Interface as described in [RFC3477] SHOULD be used to record the node's Router
ID of the S-LSP TE link. In either case, the RRO subobject SHOULD ID and Interface ID of the S-LSP TE link. In either case, the RRO
identify the S-LSP TE link end point. Intermediate links or nodes subobject SHOULD identify the S-LSP TE link end point. Intermediate
traversed by the S-LSP itself SHOULD NOT be recorded in the RRO for links or nodes traversed by the S-LSP itself SHOULD NOT be recorded
the e2e LSP over the S-LSP hop. in the RRO for the e2e LSP over the S-LSP hop.
5.1.4. Teardown of LSP Segments 5.1.4. Teardown of LSP Segments
S-LSP teardown follows the standard procedures defined in [5] and S-LSP teardown follows the standard procedures defined in [RFC3209]
[4]. This includes procedures without and with setting the and [RFC3473]. This includes procedures without and with setting the
administrative status. Teardown of S-LSP may be initiated by either administrative status. Teardown of S-LSP may be initiated by either
the ingress, egress or any other node along the S-LSP path. the ingress, egress or any other node along the S-LSP path.
Deletion/teardown of the S-LSP SHOULD be treated as a failure event Deletion/teardown of the S-LSP SHOULD be treated as a failure event
for the e2e LSP associated with it and corresponding teardown or for the e2e LSP associated with it and corresponding teardown or
recovery procedures SHOULD be triggered for the e2e LSP. In case of recovery procedures SHOULD be triggered for the e2e LSP. In case of
S-LSP teardown for maintenance purpose, the S-LSP ingress node MAY S-LSP teardown for maintenance purpose, the S-LSP ingress node MAY
treat this to be equivalent to administratively shutting down a TE treat this to be equivalent to administratively shutting down a TE
link along the e2e LSP path and take corresponding actions to notify link along the e2e LSP path and take corresponding actions to notify
the ingress of this event. The actual signaling procedures to handle the ingress of this event. The actual signaling procedures to handle
this event is out of the scope of this document. this event is out of the scope of this document.
5.1.5. Teardown of e2e LSPs 5.1.5. Teardown of e2e LSPs
e2e LSP teardown also follows standard procedures defined in [5] and e2e LSP teardown also follows standard procedures defined in
[4] either without or with the administrative status. Note, however, [RFC3209] and [RFC3473] either without or with the administrative
that teardown procedures of e2e LSP and of S-LSP are independent of status. Note, however, that teardown procedures of e2e LSP and of
each other. So, it is possible that while one LSP follows graceful S-LSP are independent of each other. So, it is possible that while
teardown with adminstrative status, the other LSP is torn down one LSP follows graceful teardown with adminstrative status, the
without administrative status (using PathTear/ResvTear/PathErr with other LSP is torn down without administrative status (using
state removal). PathTear/ResvTear/PathErr with state removal).
When an e2e LSP teardown is initiated from the head-end, and a When an e2e LSP teardown is initiated from the head-end, and a
PathTear arrives at the GMPLS stitching node, the PathTear message PathTear arrives at the GMPLS stitching node, the PathTear message
like the Path message MUST be IP routed to the LSP segment egress 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 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 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 check MUST be disabled on the receiving node. PathTear will result
in deletion of RSVP states corresponding to the e2e LSP and freeing in deletion of RSVP states corresponding to the e2e LSP and freeing
of label allocations and bandwidth reservations on the S-LSP. The of label allocations and bandwidth reservations on the S-LSP. The
unreserved bandwidth on the S-LSP TE link SHOULD be re-adjusted. 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- 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 end either using a ResvTear or a PathErr with state removal. The
egress of the S-LSP MUST propagate the ResvTear/PathErr upstream, IP egress of the S-LSP MUST propagate the ResvTear/PathErr upstream, IP
routed to the ingress of the LSP segment. routed to the ingress of the LSP segment.
Graceful LSP teardown using ADMIN_STATUS as described in [4] is also Graceful LSP teardown using ADMIN_STATUS as described in [RFC3473] is
applicable to stitched LSPs. also applicable to stitched LSPs.
If the S-LSP was statically provisioned, tearing down of an e2e LSP 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 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 was dynamically setup due to the e2e LSP setup request, then
depending on local policy, the S-LSP MAY be torn down if no e2e LSP depending on local policy, the S-LSP MAY be torn down if no e2e LSP
is utilizing the S-LSP. Although the S-LSP may be torn down while is utilizing the S-LSP. Although the S-LSP may be torn down while
the e2e LSP is being torn down, it is RECOMMENDED that a delay be the e2e LSP is being torn down, it is RECOMMENDED that a delay be
introduced in tearing down the S-LSP once the e2e LSP teardown is introduced in tearing down the S-LSP once the e2e LSP teardown is
complete, in order to reduce the simultaneous generation of RSVP complete, in order to reduce the simultaneous generation of RSVP
errors and teardown messages due to multiple events. The delay errors and teardown messages due to multiple events. The delay
skipping to change at page 14, line 20 skipping to change at page 14, line 20
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 advertised 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. If R1 and A are in different domains, then signaling a new S-LSP. If R1 and A are in different domains, then
LSP1-2 is an inter-domain LSP. In this case, S-LSP LSP-AB, similar 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 to any other basic TE link in the domain will not be advertised
outside the domain. R1 would use either per-domain path computation outside the domain. R1 would use either per-domain path computation
([14]) or PCE based computation ([15]) for LSP1-2. ([PD-PATH]) or PCE based computation ([RFC4655]) for LSP1-2.
5.2.4. Stitching of an e2e LSP into an LSP Segment 5.2.4. Stitching of an 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 the S-LSP LSP-AB to which LSP1-2 will be stitched has LSP1-2. Once the S-LSP LSP-AB to which LSP1-2 will be stitched has
been determined, the Path message for LSP1-2 is sent (via IP routing, been determined, the Path message for LSP1-2 is sent (via IP routing,
if needed) to node B with the IF_ID RSVP_HOP identifying the S-LSP if needed) 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 LSP-AB. When B receives this Path message for LSP1-2, if B is also
skipping to change at page 14, line 47 skipping to change at page 14, line 47
R2. Node A ignores the Label on receipt of the Resv message and then 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 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. 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 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 and B. In the data plane, this yields a series of label swaps from R1
to R2 along e2e LSP LSP1-2. to R2 along e2e LSP LSP1-2.
6. Security Considerations 6. Security Considerations
From a security point of view, the changes introduced in this From a security point of view, the changes introduced in this
document model the changes introduced by [2]. That is, the control document model the changes introduced by [RFC4206]. That is, the
interface over which RSVP messages are sent or received need not be control interface over which RSVP messages are sent or received need
the same as the data interface which the message identifies for not be the same as the data interface which the message identifies
switching traffic. But the capability for this function was for switching traffic. But the capability for this function was
introduced in [4] to support the concept of out-of-fiber control introduced in [RFC3473] to support the concept of out-of-fiber
channels, so there is nothing new in this concept for signaling or control channels, so there is nothing new in this concept for
security. signaling or security.
The application of this facility means that the "sending interface" The application of this facility means that the "sending interface"
or "receiving interface" may change as routing changes. So, these or "receiving interface" may change as routing changes. So, these
interfaces cannot be used to establish security association between interfaces cannot be used to establish security association between
neighbors, and security associations MUST be bound to the neighbors, and security associations MUST be bound to the
communicating neighbors themselves. communicating neighbors themselves.
[6] provides a solution to this issue: in Section 2.1, under "Key [RFC2747] provides a solution to this issue: in Section 2.1, under
Identifier", an IP address is a valid identifier for the sending (and "Key Identifier", an IP address is a valid identifier for the sending
by analogy, receiving) interface. Since RSVP messages for a given (and by analogy, receiving) interface. Since RSVP messages for a
LSP are sent to an IP address that identifies the next/previous hop given LSP are sent to an IP address that identifies the next/previous
for the LSP, one can replace all occurrences of 'sending [receiving] hop for the LSP, one can replace all occurrences of 'sending
interface' with 'receiver's [sender's] IP address' (respectively). [receiving] interface' with 'receiver's [sender's] IP address'
For example, in Section 4, third paragraph, instead of: (respectively). For example, in Section 4, third paragraph, instead
of:
"Each sender SHOULD have distinct security associations (and keys) "Each sender SHOULD have distinct security associations (and keys)
per secured sending interface (or LIH). ... At the sender, per secured sending interface (or LIH). ... At the sender,
security association selection is based on the interface through security association selection is based on the interface through
which the message is sent." which the message is sent."
it should read: it should read:
"Each sender SHOULD have distinct security associations (and keys) "Each sender SHOULD have distinct security associations (and keys)
per secured receiver's IP address. ... At the sender, security per secured receiver's IP address. ... At the sender, security
association selection is based on the IP address to which the association selection is based on the IP address to which the
message is sent." message is sent."
Thus the mechanisms of [6] can be used unchanged to establish Thus the mechanisms of [RFC2747] can be used unchanged to establish
security associations between control plane neighbors. security associations between control plane neighbors.
This document allows the IP destination address of Path and PathTear This document allows the IP destination address of Path and PathTear
messages to be the IP address of a nexthop node (receiver's address) messages to be the IP address of a nexthop node (receiver's address)
instead of the RSVP session destination address. This means that the instead of the RSVP session destination address. This means that the
use of the IPsec Authentication Header (AH) (ruled out in [6] because use of the IPsec Authentication Header (AH) (ruled out in [RFC2747]
RSVP messages were encapsulated in IP packets addressed to the because RSVP messages were encapsulated in IP packets addressed to
ultimate destination of the Path or PathTear messages) is now the ultimate destination of the Path or PathTear messages) is now
perfectly applicable, and standard IPsec procedures can be used to perfectly applicable, and standard IPsec procedures can be used to
secure the message exchanges. secure the message exchanges.
An analysis of GMPLS security issues can be found in [16]. An analysis of GMPLS security issues can be found in [MPLS-SEC].
7. IANA Considerations 7. IANA Considerations
IANA is requested to make the following codepoint allocations for IANA is requested to make the following codepoint allocations for
this document. this document.
7.1. Attribute Flags for LSP_ATTRIBUTES Object 7.1. Attribute Flags for LSP_ATTRIBUTES Object
The "RSVP TE Parameters" registry includes the "Attributes Flags" The "RSVP TE Parameters" registry includes the "Attributes Flags"
sub-registry. sub-registry.
skipping to change at page 17, line 9 skipping to change at page 17, line 9
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Dimitri Papadimitriou and Igor The authors would like to thank Dimitri Papadimitriou and Igor
Bryskin for their thorough review of the document and discussions Bryskin for their thorough review of the document and discussions
regarding the same. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Hierarchy with Generalized Multi-Protocol Label Switching Authentication", RFC 2747, January 2000.
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[3] Farrel, A., Papadimitriou, D., Vasseur, J., and A. Ayyangar, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
"Encoding of Attributes for Multiprotocol Label Switching (MPLS) and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Label Switched Path (LSP) Establishment Using Resource Tunnels", RFC 3209, December 2001.
ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420,
February 2006.
[4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
Signaling Resource ReserVation Protocol-Traffic Engineering (GMPLS) Signaling Resource ReserVation Protocol-Traffic
(RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[5] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", Hierarchy with Generalized Multi-Protocol Label Switching
RFC 3209, December 2001. (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[6] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and
Authentication", RFC 2747, January 2000. A. Ayyangar, "Encoding of Attributes for Multiprotocol
Label Switching (MPLS) Label Switched Path (LSP)
Establishment Using Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4420, February 2006.
9.2. Informative References 9.2. Informative References
[7] Aggarwal, R., "Extensions to RSVP-TE for Point-to-Multipoint TE [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
LSPs", draft-ietf-mpls-rsvp-te-p2mp, work in progress. Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[8] Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Engineering - RSVP-TE extensions", Links in Resource ReSerVation Protocol - Traffic
draft-ietf-ccamp-inter-domain-rsvp-te, work in progress. Engineering (RSVP-TE)", RFC 3477, January 2003.
[9] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
D., Li, T., and A. Conta, "MPLS Label Stack Encoding", in MPLS Traffic Engineering (TE)", RFC 4201, October
RFC 3032, January 2001. 2005.
[10] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 3477, January 2003. RFC 4203, October 2005.
[11] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to
MPLS Traffic Engineering (TE)", RFC 4201, October 2005. Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4205, October 2005.
[12] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of [RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based
Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, Architecture", RFC 4655, August 2006.
October 2005.
[13] Kompella, K. and Y. Rekhter, "Intermediate System to [RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, Arthi, "A
Intermediate System (IS-IS) Extensions in Support of Framework for Inter-Domain Multiprotocol Label Switching
Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, Traffic Engineering", RFC 4726, November 2006.
October 2005.
[14] Vasseur, J., "A Per-domain path computation method for [RSVP-P2MP] Aggarwal, R., "Extensions to RSVP-TE for Point-to-
establishing Inter-domain Traffic Engineering (TE) Label Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp, work
Switched Paths (LSPs)", in progress.
draft-ietf-ccamp-inter-domain-pd-path-comp, work in progress.
[15] Farrel, A., "A Path Computation Element (PCE)-Based [RSVP-INTER] Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic
Architecture", RFC 4655, August 2006. Engineering - RSVP-TE extensions", draft-ietf-ccamp-
inter-domain-rsvp-te, work in progress.
[16] Fang, L., et al., "Security Framework for MPLS and GMPLS [PD-PATH] Vasseur, J., "A Per-domain path computation method for
Networks", draft-fang-mpls-gmpls-security-framework, work in establishing Inter-domain Traffic Engineering (TE)
progress. Label Switched Paths (LSPs)", draft-ietf-ccamp-inter-
domain-pd-path-comp, work in progress.
[17] Farrel, A., Vasseur, J.P., and Ayyangar, Arthi, "A Framework [MPLS-SEC] Fang, L., et al., "Security Framework for MPLS and GMPLS
for Inter-Domain Multiprotocol Label Switching Traffic Networks", draft-fang-mpls-gmpls-security-framework,
Engineering", RFC 4726, November 2006. work in progress.
10. Authors' Addresses 10. Authors' Addresses
Arthi Ayyangar Arthi Ayyangar
Nuova Systems Nuova Systems
2600 San Tomas Expressway 2600 San Tomas Expressway
Santa Clara, CA 95051 Santa Clara, CA 95051
Email: arthi@nuovasystems.com Email: arthi@nuovasystems.com
Kireeti Kompella Kireeti Kompella
 End of changes. 51 change blocks. 
160 lines changed or deleted 161 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/