draft-ietf-ccamp-gmpls-vcat-lcas-01.txt   draft-ietf-ccamp-gmpls-vcat-lcas-02.txt 
CCAMP Working Group G. Bernstein CCAMP Working Group G. Bernstein (ed.)
Internet Draft Grotto Networking Internet Draft Grotto Networking
Updates: RFC 3946 D. Caviglia Updates: RFC 3946 D. Caviglia
Category: Standards Track Ericsson Category: Standards Track Ericsson
Expires: April 2007 R. Rabbat (ed.) Expires: September 2007 R. Rabbat
Fujitsu Google
H. van Helvoort H. van Helvoort
Huawei Huawei
October 20, 2006 March 30, 2007
Operating Virtual Concatenation (VCAT) and the Link Capacity Operating Virtual Concatenation (VCAT) and the Link Capacity
Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label
Switching (GMPLS) Switching (GMPLS)
draft-ietf-ccamp-gmpls-vcat-lcas-01.txt draft-ietf-ccamp-gmpls-vcat-lcas-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any 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 aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 April 20, 2007. This Internet-Draft will expire on September 30, 2007.
Abstract Abstract
This document describes requirements for, and use of, the Generalized This document describes requirements for, and use of, the Generalized
Multi-Protocol Label Switching (GMPLS) control plane in conjunction Multi-Protocol Label Switching (GMPLS) control plane in conjunction
with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing
mechanism and its companion Link Capacity Adjustment Scheme (LCAS) mechanism and its companion Link Capacity Adjustment Scheme (LCAS)
which can be used for hitless dynamic resizing of the inverse which can be used for hitless dynamic resizing of the inverse
multiplex group. These techniques apply to the Optical Transport multiplex group. These techniques apply to the Optical Transport
Network (OTN), Synchronous Optical Network (SONET), Synchronous Network (OTN), Synchronous Optical Network (SONET), Synchronous
skipping to change at page 2, line 21 skipping to change at page 2, line 21
Conventions used in this document 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 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Changes from draft-bernstein-ccamp-gmpls-vcat-lcas-03..........3 2. Revision History...............................................3
3. VCAT/LCAS Scenarios and Specific Requirements..................3 2.1. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........3
3.1. Multiple VCAT Groups per GMPLS Endpoint...................3 2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........4
3.2. Component Signal Configuration Requirements...............3 3. VCAT/LCAS Scenarios and Specific Requirements..................4
3.3. VCAT Operation With or Without LCAS.......................4 3.1. VCAT/LCAS Interface Capabilities..........................4
4. GMPLS Mechanisms for Signaling VCAT/LCAS.......................4 3.2. Member Signal Configuration Scenarios.....................4
4.1. Co-Routed Signals.........................................5 3.3. VCAT Operation With or Without LCAS.......................5
4.1.1. One-shot Setup of Co-Routed Signal...................5 4. GMPLS Mechanisms in Support of VCGs............................6
4.1.2. Incremental Setup of Co-Routed Signal................5 4.1. VCGs Composed of a Single Co-Signaled Member Set..........7
4.1.3. Removing a Component Signal..........................6 4.1.1. One-shot VCG Setup with Co-Signaled Members..........7
4.1.4. Removing Multiple Component Signals in One Shot......6 4.1.2. Incremental VCG Setup with Co-Signaled Members.......7
4.1.5. Use of multiple LSPs for Co-Routed Signals...........7 4.1.3. Procedure for VCG Reduction by Removing a Member.....8
4.1.6. Teardown of Whole VCG................................7 4.1.4. Removing Multiple VCG Members in One Shot............8
4.2. Diversely Routed Signals..................................7 4.1.5. Teardown of Whole VCG................................9
4.2.1. Associating Diversely Routed Signals.................7 4.2. VCGs Composed of Multiple Co-Signaled Member Sets.........9
4.2.2. Procedures for VCG Setup Using Diversely Routed 4.2.1. Signaled VCG Layer Information.......................9
Components..................................................8 4.2.2. Procedures for VCG Control with Multiple Co-signaled
4.2.3. Procedures for VCG Reduction/Teardown Using Diversely Member Sets................................................10
Routed Components...........................................9 4.3. Member Sharing -- Multiple VCGs per Call.................11
4.2.4. Update of Already Established LSPs...................9 5. IANA Considerations...........................................12
4.2.5. One LSP per Circuit..................................9 6. Security Considerations.......................................12
5. IANA Considerations...........................................10 7. Contributors..................................................13
6. Security Considerations.......................................10 8. Acknowledgments...............................................13
7. Contributors..................................................11 9. References....................................................14
8. Acknowledgments...............................................11 9.1. Normative References.....................................14
9. References....................................................12 9.2. Informative References...................................14
9.1. Normative References.....................................12 Author's Addresses...............................................15
9.2. Informative References...................................12 Intellectual Property Statement..................................15
Author's Addresses...............................................13 Disclaimer of Validity...........................................16
Intellectual Property Statement..................................14 Copyright Statement..............................................16
Disclaimer of Validity...........................................14 Acknowledgment...................................................16
Copyright Statement..............................................14
Acknowledgment...................................................15
1. Introduction 1. Introduction
The Generalized Multi-Protocol Label Switching (GMPLS) suite of The Generalized Multi-Protocol Label Switching (GMPLS) suite of
protocols allows the automated control of different switching protocols allows the automated control of different switching
technologies including SONET/SDH. technologies including SONET/SDH and OTN. This document describes
extensions to RSVP-TE to support the Virtual Concatenation (VCAT)
layer 1 inverse multiplexing mechanism that has been standardized for
SONET, SDH, OTN and PDH technologies along with its companion Link
Capacity Adjustment Scheme (LCAS).
This document describes extensions to RSVP-TE to support the Virtual VCAT is a TDM oriented byte striping inverse multiplexing method that
Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its works with a wide range of existing and emerging TDM framed signals,
companion Link Capacity Adjustment Scheme (LCAS). These extensions including very high bit rate OTN and SDH/SONET signals. Other than
enable the setup of diversely routed circuits that are members of the member signal skew compensation layer 1 inverse multiplexing
same VCAT group. mechanism add minimal additional signal delay. VCAT permits the
selection of an optimal signals size, extracting bandwidth from mesh
networks and when combined with LCAS hitless dynamic resizing of
bandwidth and fast graceful degradation in the presence of network
faults. To take full advantage of VCAT/LCAS functionality extensions
to GMPLS signaling are given that enable the setup of diversely
routed circuits that are members of the same VCAT group.
2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00 2. Revision History
2.1. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01
o Changed section 3.1 from "Multiple VCAT Groups per GMPLS endpoint"
to "Multiple VCAT Groups per Interface" to improve clarity.
o Changed terminology from "component" signal to "member" signal
where possible (not quoted text) to avoid confusion with link
bundle components.
o Added "Dynamic, member sharing" scenario.
o Clarified requirements with respect to scenarios and the LCAS and
non-LCAS cases.
o Added text describing needed signaling information between the
VCAT endpoints to support required scenarios.
o Added text to describe: co-signaled, co-routed, data plane LSP,
control plane LSP and their relationship to the VCAT/LCAS
application.
o Change implementation mechanism from one based on the Association
object to one based on "Call concepts" utilizing the Notify
message.
2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00
o Updated reference from RFC3946bis to issued RFC4606 o Updated reference from RFC3946bis to issued RFC4606
o Updated section 3.2 based on discussions on the mailing list o Updated section 3.2 based on discussions on the mailing list
3. VCAT/LCAS Scenarios and Specific Requirements 3. VCAT/LCAS Scenarios and Specific Requirements
There are a number of specific requirements for the support of There are a number of specific requirements for the support of
VCAT/LCAS in GMPLS that can be derived from the carriers' VCAT/LCAS in GMPLS that can be derived from the carriers'
application-specific demands for the use of VCAT/LCAS and from the application-specific demands for the use of VCAT/LCAS and from the
flexible nature of VCAT/LCAS. These are set out in the following flexible nature of VCAT/LCAS. These are set out in the following
section. section.
3.1. Multiple VCAT Groups per GMPLS Endpoint 3.1. VCAT/LCAS Interface Capabilities
In general, an LSR can be ingress/egress of one or more VCAT groups. In general, an LSR can be ingress/egress of one or more VCAT groups.
VCAT and LCAS are interface capabilities. An LSR may have, for VCAT and LCAS are interface capabilities. An LSR may have, for
example, VCAT-capable interfaces that are not LCAS-capable. It may example, VCAT-capable interfaces that are not LCAS-capable. It may
at the same time have interfaces that are neither VCAT nor LCAS- at the same time have interfaces that are neither VCAT nor LCAS-
capable. capable.
3.2. Component Signal Configuration Requirements 3.2. Member Signal Configuration Scenarios
We list in this section the different scenarios that SHOULD be
supported. Here we use the term "VCG" to refer to the entire VCAT
group and the terminology "set" and "subset" to refer to the
collection of potential VCAT group member signals.
Note that LCAS-capable interfaces can support all scenarios with no We list in this section the different scenarios. Here we use the
loss of traffic. term "VCG" to refer to the entire VCAT group and the terminology
"set" and "subset" to refer to the collection of potential VCAT group
member signals.
o Fixed, co-routed: A fixed bandwidth VCG, transported over a co- o Fixed, co-routed: A fixed bandwidth VCG, transported over a co-
routed set of member signals. This is the case where the intended routed set of member signals. This is the case where the intended
bandwidth of the VCG does not change and all member signals follow bandwidth of the VCG does not change and all member signals follow
the same route and minimize differential delay. The intent here the same route and minimize differential delay. The intent here
is the capability to allocate an amount of bandwidth close to that is the capability to allocate an amount of bandwidth close to that
required at the client layer. required at the client layer.
o Fixed, diversely routed: A fixed bandwidth VCG, transported over o Fixed, diversely routed: A fixed bandwidth VCG, transported over
at least two diversely routed subsets of member signals. In this at least two diversely routed subsets of member signals. In this
case, the subsets are link-disjoint over at least one link of the case, the subsets are link-disjoint over at least one link of the
route. The intent here is more efficient use of network resources route. The intent here is more efficient use of network resources
(no unique route has the required bandwidth). (no unique route has the required bandwidth).
o Fixed, member sharing: A fixed bandwidth VCG, transported over a
set of member signals that are allocated from a common pool of
available member signals without requiring member connection
teardown and setup.
o Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or o Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or
decreased via the addition or removal of member signals), decreased via the addition or removal of member signals),
transported over a co-routed set of members. The intent here is transported over a co-routed set of members. The intent here is
dynamic resizing and resilience of bandwidth. dynamic resizing and resilience of bandwidth.
o Dynamic, diversely routed: A dynamic VCG (bandwidth can be o Dynamic, diversely routed: A dynamic VCG (bandwidth can be
increased or decreased via the addition or removal of member increased or decreased via the addition or removal of member
signals), transported over at least two diversely routed subsets signals), transported over at least two diversely routed subsets
of member signals. The intent here is efficient use of network of member signals. The intent here is efficient use of network
resources, dynamic resizing and resilience of bandwidth. resources, dynamic resizing and resilience of bandwidth.
o Dynamic, member sharing: A dynamic bandwidth VCG, transported over
a set of member signals that are allocated from a common pool of
available member signals without requiring member connection
teardown and setup.
3.3. VCAT Operation With or Without LCAS 3.3. VCAT Operation With or Without LCAS
VCAT capabilities may be present with or without the presence of VCAT capabilities may be present with or without the presence of
LCAS. The use of LCAS is beneficial to the provision of services, LCAS. The use of LCAS is beneficial to the provision of services,
but in the absence of LCAS, VCAT is still a valid technique. but in the absence of LCAS, VCAT is still a valid technique.
Therefore GMPLS mechanisms for the operation of VCAT are REQUIRED for Therefore GMPLS mechanisms for the operation of VCAT are REQUIRED for
both the case where LCAS is available and the case where it is not both the case where LCAS is available and the case where it is not
available. The GMPLS procedures for the two cases SHOULD be available. The GMPLS procedures for the two cases SHOULD be
identical. identical.
4. GMPLS Mechanisms for Signaling VCAT/LCAS o GMPLS signaling for LCAS-capable interfaces MUST support all
scenarios of section 3.2. with no loss of traffic.
o GMPLS signaling for non-LCAS-capable interfaces MUST support only
the "fixed" scenarios of section 3.2.
To provide for these requirements GMPLS signaling MUST carry the
following information on behalf of the VCAT endpoints:
o The type of the member signal that the VCG will contain, e.g., VC-
3, VC-4, etc.
o The total number of member to be in the VCG. This provides the
endpoints in both the LCAS and non-LCAS case with information on
which to accept or reject the request, and in the non-LCAS case
will let the receiving endpoint know when all members of the VCG
have been established.
o Identification of the VCG and its associated members. This
provides information that allows the endpoints to differentiate
multiple VCGs and to tell what members (LSPs) to associate with a
particular VCG.
4. GMPLS Mechanisms in Support of VCGs
We describe in this section the signaling mechanisms that already We describe in this section the signaling mechanisms that already
exist in GMPLS using RSVP-TE [RFC3473] and the extensions needed, for exist in GMPLS using RSVP-TE [RFC3473] and the extensions needed to
diversely routed paths and in support of the LCAS procedure. completely support the requirements of section 3.
When utilizing GMPLS with VCAT/LCAS we utilize a number of control
and data plane concepts that we describe below.
1. VCG member -- This is an individual data plane signal of one of the
permitted SDH, SONET, OTN or PDH signal types.
2. Co-signaled member set -- One or more VCG members (or potential
members) set up via the same control plane signaling exchange. Note
that all members in a co-signaled set follow the same route.
3. Co-routed member set - One or more VCG members that follow the same
route. Although VCG members may follow the same path, this does not
imply that they we co-signaled.
4. Data plane LSP -- for our purposes here this is equivalent to an
individual VCG member.
5. Control plane LSP -- A control plane entity that can control
multiple data plane LSPs. For our purposes here this is equivalent
to our co-signaled member set.
Section 4.1 is included for informational purposes only. It Section 4.1 is included for informational purposes only. It
describes existing procedures and makes no changes. describes existing GMPLS procedures that support a single VCG
composed of a single co-signaled member set.
Section 4.2 describes new procedures to support diversely routed VCAT Section 4.2 describes new procedures to support VCGs composed of more
groups. Where possible it reuses applicable existing procedures from that one co-signaled member sets. This includes the important
section 4.1. application of a VCG composed of diversely routed members. Where
possible it reuses applicable existing procedures from section 4.1.
4.1. Co-Routed Signals 4.1. VCGs Composed of a Single Co-Signaled Member Set
Note that this section is for informational purposes only. Note that this section is for informational purposes only.
The existing signaling protocols support co-routed signal setup using The existing signaling GMPLS signaling protocols support a VCG
the NVC field as explained in section 2.1 of [RFC4606]. In this composed of a single co-signaled member set. Setup using the NVC
case, one single LSP is set up in support of the VCAT group. field as explained in section 2.1 of [RFC4606]. In this case, one
single control plane LSP is used in support of the VCG.
There are two options for setting up the VCAT group, depending on There are two options for setting up the VCG, depending on hardware
hardware capability, or management preferences: one-shot setup and capability, or management preferences: one-shot setup and incremental
incremental setup. setup.
The following sections explain the procedure based on an example of The following sections explain the procedure based on an example of
setting up a VC-4-7v SDH VCAT group (corresponding to an STS-3c-7v setting up a VC-4-7v SDH VCAT group (corresponding to an STS-3c-7v
SONET VCAT group). SONET VCAT group).
4.1.1. One-shot Setup of Co-Routed Signal 4.1.1. One-shot VCG Setup with Co-Signaled Members
An RSVP-TE Path message is used with the following parameters. An RSVP-TE Path message is used with the following parameters.
With regards to the traffic parameters, the elementary signal is With regards to the traffic parameters, the elementary signal is
chosen (6 for VC-4/STS-3c_SPE). The value of NVC is then set to 7. chosen (6 for VC-4/STS-3c_SPE). The value of NVC is then set to 7.
A Multiplier Transform greater than 1 (say N>1) is used if the A Multiplier Transform greater than 1 (say N>1) is used if the
operator wants to set up N VCAT groups that will belong to, and be operator wants to set up N VCAT groups that will belong to, and be
assigned to, one LSP. assigned to, one LSP.
SDH or SONET labels in turn have to be assigned for each member of SDH or SONET labels in turn have to be assigned for each member of
the VCG and concatenated to form a single Generalized Label the VCG and concatenated to form a single Generalized Label
constructed as an ordered list of 32-bit timeslot identifiers of the constructed as an ordered list of 32-bit timeslot identifiers of the
same format as TDM labels. [RFC4606] requires that the order of the same format as TDM labels. [RFC4606] requires that the order of the
labels reflect the order of the payloads to concatenate, and not the labels reflect the order of the payloads to concatenate, and not the
physical order of time-slots. physical order of time-slots.
4.1.2. Incremental Setup of Co-Routed Signal 4.1.2. Incremental VCG Setup with Co-Signaled Members
In some cases, it may be necessary or desirable to set up the VCG In some cases, it may be necessary or desirable to set up the VCG
members individually, or to add group members to an existing group. members individually, or to add group members to an existing group.
One example of this need is when the hardware that supports VCAT can One example of this need is when the hardware that supports VCAT can
only add VCAT elements one at a time or cannot automatically match only add VCAT elements one at a time or cannot automatically match
the elements at the ingress and egress for the purposes of inverse the elements at the ingress and egress for the purposes of inverse
multiplexing. Serial or incremental setup solves this problem. multiplexing. Serial or incremental setup solves this problem.
In order to accomplish incremental setup an iterative process is used In order to accomplish incremental setup an iterative process is used
skipping to change at page 6, line 23 skipping to change at page 8, line 20
Label (in the Path or Resv message). A node that receives a Path Label (in the Path or Resv message). A node that receives a Path
message that contains changed fields will process the full Path message that contains changed fields will process the full Path
message and, based on the new value of NVC, it will add a component message and, based on the new value of NVC, it will add a component
signal to the VCAT group, and switch the new timeslot based on the signal to the VCAT group, and switch the new timeslot based on the
new label information. new label information.
Following the addition of the new label to the LSP, LCAS may be used Following the addition of the new label to the LSP, LCAS may be used
in-band to add the new label into the existing VCAT group. LCAS in-band to add the new label into the existing VCAT group. LCAS
signaling for this function is described in [ITU-T-G.7042]. signaling for this function is described in [ITU-T-G.7042].
4.1.3. Procedure for VCG Reduction by Removing a Component Signal 4.1.3. Procedure for VCG Reduction by Removing a Member
A VCG member can be permanently removed from the VCG either as the A VCG member can be permanently removed from the VCG either as the
result of a management command or following a temporary removal (due result of a management command or following a temporary removal (due
to a failure). to a failure).
The procedure to remove a component signal is similar to that used to The procedure to remove a component signal is similar to that used to
add components as described in Section 4.1.2. The LCAS in-band add components as described in Section 4.1.2. The LCAS in-band
signaling step is taken first to take the component out of the group. signaling step is taken first to take the component out of service
LCAS signaling is described in [ITU-T-G.7042]. from the group. LCAS signaling is described in [ITU-T-G.7042].
In this case, the NVC value is decremented by 1 and the timeslot In this case, the NVC value is decremented by 1 and the timeslot
identifier for the dropped component is removed from the ordered list identifier for the dropped component is removed from the ordered list
in the Generalized Label. in the Generalized Label.
Note that for interfaces that are not LCAS-capable, removing one Note that for interfaces that are not LCAS-capable, removing one
component of the VCG will result in errors in the inverse- component of the VCG will result in errors in the inverse-
multiplexing procedure of VCAT and result in the teardown of the multiplexing procedure of VCAT and result in the teardown of the
whole group. So, this is a feature that only LCAS-capable VCAT whole group. So, this is a feature that only LCAS-capable VCAT
interfaces can support without management intervention at the end interfaces can support without management intervention at the end
points. points.
4.1.4. Removing Multiple Component Signals in One Shot 4.1.4. Removing Multiple VCG Members in One Shot
The procedure is similar to 4.1.3. In this case, the NVC value is The procedure is similar to 4.1.3. In this case, the NVC value is
changed to the new value and all relevant timeslot identifiers for changed to the new value and all relevant timeslot identifiers for
the components to be torn down are removed from the ordered list in the components to be torn down are removed from the ordered list in
the Generalized Label. This procedure is also not supported for the Generalized Label. This procedure is also not supported for
VCAT-only interfaces without management intervention as removing one VCAT-only interfaces without management intervention as removing one
or more components of the VCG will tear down the whole group. or more components of the VCG will tear down the whole group.
4.1.5. Use of multiple LSPs for Co-Routed Signals 4.1.5. Teardown of Whole VCG
Co-routed signals may also be supported by distinct LSPs signaled
separately using exactly the techniques described for diversely
routed signals in Section 4.2.
4.1.6. Teardown of Whole VCG
The entire LSP is deleted in a single step (i.e., all components are The entire LSP is deleted in a single step (i.e., all components are
removed in one go) using deletion procedures of [RFC3473]. removed in one go) using deletion procedures of [RFC3473].
4.2. Diversely Routed Signals 4.2. VCGs Composed of Multiple Co-Signaled Member Sets
The initial GMPLS specification did not support diversely routed The motivation for VCGs composed of multiple co-signaled member sets
signals using the NVC construct. In fact, [RFC4606] says: comes from the requirement to support VCGs with diversely routed
members. The initial GMPLS specification did not support diversely
routed signals using the NVC construct. In fact, [RFC4606] says:
[...] The standard definition for virtual concatenation allows [...] The standard definition for virtual concatenation allows
each virtual concatenation components to travel over diverse each virtual concatenation components to travel over diverse
paths. Within GMPLS, virtual concatenation components must paths. Within GMPLS, virtual concatenation components must
travel over the same (component) link if they are part of the travel over the same (component) link if they are part of the
same LSP. This is due to the way that labels are bound to a same LSP. This is due to the way that labels are bound to a
(component) link. Note however, that the routing of components (component) link. Note however, that the routing of components
on different paths is indeed equivalent to establishing on different paths is indeed equivalent to establishing
different LSPs, each one having its own route. Several LSPs different LSPs, each one having its own route. Several LSPs
can be initiated and terminated between the same nodes and can be initiated and terminated between the same nodes and
their corresponding components can then be associated together their corresponding components can then be associated together
(i.e., virtually concatenated). (i.e., virtually concatenated).
Diverse routing of signals can be a useful capability but requires The setup of diversely routed VCG members requires multiple co-
the extensions identified in this document. signaled VCG member sets, i.e., multiple control plane LSPs.
4.2.1. Associating Diversely Routed Signals To support a VCG with multiple co-signaled VCG members sets requires
being able to identify separate control plane LSPs with a single VCG
and exchange information pertaining to the VCG as a whole. This is
very similar to the "Call" concept described in [CallDraft]. We can
think of our VCAT/LCAS connection, e.g., our VCG, as a higher layer
service that makes use of multiple lower layer (server) connections
that are controlled by one or more control plane LSPs.
The feature that needs to be added is the functionality to associate 4.2.1. Signaled VCG Layer Information
the components of the same VCG. For this purpose, we use the
Association Object that was defined in [E2E-RECOVERY] to associate
working and recovery LSPs.
A diversely routed VCG uses a number of routes R <= VCG size, as some When a VCG is composed of multiple co-signaled member sets, none of
routes may be the same for several components. A number of LSPs, L the control plane LSP's signaling information can contain information
(VCG >= L >= R) are used with each LSP establishing at least one pertinent to the entire VCG. In this section we give a list of
component of the VCG, and at most all of the co-routed members of the information that should be communicated at what we define as the VCG
group. For a set of c components using the same route, we set up the Call layer, i.e., between the VCG signaling endpoints. To
LSP with NVC = c exactly as explained in section 4.1.1. Therefore, accommodate this information additional objects or TLVs would need to
the association of group members or of sub-groups to form the VCG be incorporated into the Notify message as it is described for use in
requires the association of the LSPs used to establish the group call signaling in [CallDraft].
members.
To be able to distinguish the LSPs in the VCG each must have a unique VCG Call setup information signaled via the Notify message with the
identifier. LSPs are identified by the combination of Session and Call management bit (C-bit) set:
Sender Template fields. It is common practice when make-before-break
[RFC3209] is supported to allow LSPs with the same Session, but
different Sender Templates (specifically with different LSP IDs) to
share resources. Since resource sharing between VCG members must not
be allowed (because we want each LSP to contribute capacity to the
VCG), but since we want to continue to support make-before-break for
each group member, it is necessary to distinguish the LSPs in the VCG
by varying the fields in the Session object. Specifically, a
different Tunnel ID is used to identify each LSP in the VCG.
Thus, VCG members cannot be associated through the Session object, 1. Signal Type
and the Association object is used instead.
The assignment of the Association ID is outside the scope of GMPLS 2. Number of VCG Members
but MUST be unique for each VCAT group.
Note that the use of the Association object to associate members of a 3. LCAS requirements:
VCG does not preclude the use of another instance of the object with
a different Association ID to indicate the association of working and
recovery LSPs, as [E2E-RECOVERY] allows the use of multiple
Association objects. We differentiate between the Association
objects used for the VCAT group and other Association objects through
the definition of a new association type to indicate that this is a
VCG association.
Association Type: 16 bits a. LCAS required
Value Type b. LCAS desired
----- ----
3 VCAT group c. LCAS not desired (but acceptable)
See [E2E-RECOVERY] for the definition of other fields and values of d. LCAS not acceptable
the Association object.
4.2.2. Procedures for VCG Setup Using Diversely Routed Components 4. Maximum Number of VCGs per Call-- This is a hook to support the
member sharing scenario. In the non-member sharing case the
value is one.
For every route R, use the procedure outlined in section 4.1.1 or 4.2.2. Procedures for VCG Control with Multiple Co-signaled Member Sets
4.1.2 depending on the capability of the equipment or local policy.
The Path message MUST include the Association object with type set to
3, and each Path message MUST use the same Association ID.
Following the addition of each new LSP (i.e., once the RESV message This section deals only with the case of one VCG per (VCG) Call. To
has been received by the ingress LSR), LCAS signaling is used in-band establish a VCG, the information of section 4.2.1. is exchanged and
to hitlessly add the new label into the existing group [ITU-T- agreed upon with the corresponding VCG signaling endpoint. Since only
G.7042]. one VCG is being signaled by this call, all control plane LSPs used
with this call establish members for this VCG and there is no
ambiguity as to which VCG a potential member belongs. Procedures for
addition and removal of bandwidth are the same as the single co-
signaled case except that a VCG Call layer message should precede any
of those changes and indicate the new total number of VCG members.
4.2.3. Procedures for VCG Reduction/Teardown Using Diversely Routed In general the following order is used to establish and increase the
Components bandwidth in a VCG:
To remove the component circuits on any route, LCAS in-band signaling 1. VCG Call layer information is conveyed. Note that during a
is used to remove the labels associated with the LSP from the group. "bandwidth" change only the total number of VCG members is
LCAS signaling is defined in [ITU-T-G.7042]. allowed to change.
In addition, the procedures outlined in section 4.1.3 or 4.1.4 are 2. Control Plane LSPs are used to add data plane LSPs (members) to
used to tear down the unwanted LSP. the VCG.
Again, this can only be done on LCAS-capable interfaces. If the 3. If LCAS is supported on this VCG call it should be instructed by
procedure is attempted on VCAT-only interfaces, then the whole VCG is the endpoints to "activate" the member.
torn down (this is not a graceful teardown so ingress/egress initiate
a Path Tear/Resv Tear) on all routes.
4.2.4. Update of Already Established LSPs In general the following order is used when decreasing the bandwidth
in a VCG:
Established co-routed VCAT groups currently do not support the 1. VCG Call layer information is conveyed concerning the decreased
Association object. If a co-routed VCAT Group size is to be number of VCG members.
increased with new diversely routed members, we use the LSP
modification procedure described in [RFC2205]. An Association object
is added to the Path message for the existing LSP(s). That
Association object can then be used to set up new diversely routed
group members.
The same applies to SONET/SDH LSPs. An operator may decide to use an 2. If LCAS is supported on this VCG call it should be instructed by
already cross-connected SONET/SDH LSP for diversely-routed VCAT. In the endpoints to "deactivate" the members to be removed.
this case the modification procedure described in [RFC2205] is used
as well.
4.2.5. One LSP per Circuit 3. Existing control plane LSPs are used to remove the data plane
LSPs (members).
These procedures can support the use of as many LSPs as there are Note that when LCAS is not used or unavailable the VCG will be in an
circuits in the VCG. This can be done when each circuit is unknown state between the time the VCG call level information is
separately routed, or when some of the circuits are co-routed, and updated and the actual data plane LSPs are added or removed.
each LSP will be used to set up one element of the VCG. The
Association object is used to indicate the VCG association.
5. IANA Considerations 4.3. Member Sharing -- Multiple VCGs per Call
This document requests from IANA the assignment of a new Association To support the member sharing scenario of section 3.2. we allow
Type within the Association object. This object was defined in [E2E- multiple VCGs within the context of the VCG Call defined here. This
RECOVERY]. is partially due to the requirement in reference [CallDraft] that
LSPs are associated with a single call over their lifetime. Hence we
propose using the VCG Call mechanism previously described to
establish the common member pool for all the VCGs to be included in
the scope of this particular VCG Call. Note that the maximum number
of VCGs per call is a key parameter to call acceptance or rejection
since VCAT equipment typically puts limits on the total number of
VCGs that can be simultaneously supported.
The value 3 "VCAT group" is suggested in section 4.2.1. To assign a data plane LSP to be a member of a particular VCG or to
remove a data plane LSP from being a member of a particular VCG,
requires additional VCG layer communications. LCAS [ITU-T-G.7042]
cannot provide such signaling since it does not to provide a way to
indicate which VCG out of multiple between a source and destination a
member should belong. In particular, although, it seems that LCAS'
Group Identification (GID) bit should be useful for this purpose
reference [ITU-T-G.7042] specifically states:
"The GID provides the receiver with a means of
verifying that all the arriving members originated
from one transmitter. The contents are pseudo-
random, but the receiver is not required to
synchronize with the incoming stream."
In the following we sketch the outline of such a high level VCG layer
signaling procedure that could make use of the Notify message as in
reference [CallDraft].
After the VCG call has been established, a signaling endpoint of the
VCG call for would then:
1. Choose an identifier for each VCG that will use member signals
from the common pool. Note that these identifiers only need to
be unique with in the context of the VCG Call.
2. Assign member signals from the common pool to each of the VCG
utilizing the previously defined VCG IDs. Member signals are
identified by their tunnel id, LSP id, and label ordinal (labels
for control plane LSPs with multiple members are strictly
ordered so we can specify an individual signal from its label
order). Similarly for removing a member signal from a VCG and
returning it to the common pool.
3. Coordinate with LCAS in that a member signal is first added to a
VCG from the pool before LCAS is notified to "activate" that
signal in the VCG. Similarly LCAS is notified to "deactivate" a
member signal prior to removing it from the VCG and returning it
to the pool.
4. Note that before any LSPs or members of an LSP can be removed
from the (overall) VCG Call, the originator must ensure that
signals have been removed from any of the VCGs. This is the
situation where the entire pool size is lowered.
The exact objects and formats to carry this information is to be
determined. Once again the Notify mechanism would be appropriate
since this is information to be transferred between the VCG Call
endpoints and is not relevant to the intermediate switches.
5. IANA Considerations
This document requests from IANA the assignment of ... (Don't know
yet what we may want)
6. Security Considerations 6. Security Considerations
This document introduces a new use of the Association object for This document introduces a specific use of the Notify message and
GMPLS signaling [RFC3473] to associate diversely routed VCAT group admin status object for GMPLS signaling as originally specified in
members. It does not introduce any new signaling messages, nor [CallDraft]. It does not introduce any new signaling messages, nor
change the relationship between LSRs that are adjacent in the control change the relationship between LSRs that are adjacent in the control
plane. This association information in the event of an interception plane. The call information associated with diversely routed control
may indicate that there are members of the same VCAT group that take plane LSPs, in the event of an interception may indicate that there
a different route and may indicate to an interceptor that the network are members of the same VCAT group that take a different route and
may be more robust. may indicate to an interceptor that the VCG call desires increased
reliability.
Otherwise, this document does not introduce any additional security Otherwise, this document does not introduce any additional security
considerations. considerations.
7. Contributors 7. Contributors
Wataru Imajuku (NTT) Wataru Imajuku (NTT)
1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847 1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847
Japan Japan
skipping to change at page 11, line 34 skipping to change at page 13, line 41
Ciena Ciena
PO Box 308 PO Box 308
Cupertino, CA 95015 Cupertino, CA 95015
United States of America United States of America
Phone: +1 408 705 2978 Phone: +1 408 705 2978
Email: lyong@ciena.com Email: lyong@ciena.com
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Maarten Vissers, Trevor Wilson and The authors would like to thank Adrian Farrel, Maarten Vissers,
Adrian Farrel for extensive reviews and contributions to this draft. Trevor Wilson, Evelyne Roch, Vijay Pandian, Fred Gruman, Dan Li,
Stephen Shew, Jonathan Saddler and Dieter Beller for extensive
reviews and contributions to this draft.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1, Functional Specification", RFC 2205,
September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label [RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, December Digital Hierarchy (SDH) Control", RFC 4606, December
2005. 2005.
[E2E-RECOVERY] Lang, J.P., Rekhter, Y., and D. Papadimitriou (eds.), [CallDraft] D. Papadimitriou and A. Farrel, "Generalized MPLS
"RSVP-TE Extensions in support of End-to-End (GMPLS) RSVP-TE Signaling Extensions in support of
Generalized Multi-Protocol Label Switching (GMPLS)- Calls", draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt,
based Recovery", IETF draft, work in progress, April January, 2007.
2005.
9.2. Informative References 9.2. Informative References
[ANSI-T1.105] American National Standards Institute, "Synchronous [ANSI-T1.105] American National Standards Institute, "Synchronous
Optical Network (SONET) - Basic Description including Optical Network (SONET) - Basic Description including
Multiplex Structure, Rates, and Formats", ANSI T1.105- Multiplex Structure, Rates, and Formats", ANSI T1.105-
2001, May 2001. 2001, May 2001.
[ITU-T-G.7042] International Telecommunications Union, "Link Capacity [ITU-T-G.7042] International Telecommunications Union, "Link Capacity
Adjustment Scheme (LCAS) for Virtual Concatenated Adjustment Scheme (LCAS) for Virtual Concatenated
skipping to change at page 13, line 35 skipping to change at page 15, line 22
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Via A. Negrone 1/A 16153 Via A. Negrone 1/A 16153
Genoa Italy Genoa Italy
Phone: +39 010 600 3736 Phone: +39 010 600 3736
Email: diego.caviglia@(marconi.com, ericsson.com) Email: diego.caviglia@(marconi.com, ericsson.com)
Richard Rabbat Richard Rabbat
Fujitsu Laboratories of America Google
1240 East Arques Ave, MS 345
Sunnyvale, CA 94085 Email: richard.rabbat@gmail.com
United States of America
Phone: +1 408-530-4537
Email: richard@us.fujitsu.com
Huub van Helvoort Huub van Helvoort
Huawei Technologies, Ltd. Huawei Technologies, Ltd.
Kolkgriend 38, 1356 BC Almere Kolkgriend 38, 1356 BC Almere
The Netherlands The Netherlands
Phone: +31 36 5315076 Phone: +31 36 5315076
Email: hhelvoort@huawei.com Email: hhelvoort@huawei.com
Intellectual Property Statement Intellectual Property Statement
skipping to change at page 14, line 40 skipping to change at page 16, line 17
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 65 change blocks. 
207 lines changed or deleted 318 lines changed or added

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