CCAMP working Group G. Bernstein
Internet-Draft Grotto Networking
Expires: April 14, 2006 D. Caviglia
Marconi
R. Rabbat
Fujitsu
October 11, 2005
Operating Virtual concatenation (VCAT) and the Link Capacity Adjustment
Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)
draft-bernstein-ccamp-gmpls-vcat-lcas-01
Status of this Memo
By submitting this Internet-Draft, each author represents that 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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the use of the Generalized Multi-Protocol
Label Switching (GMPLS) control plane in conjunction with the Virtual
Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its
companion Link Capacity Adjustment Scheme (LCAS) which can be used
Bernstein, et al. Expires April 14, 2006 [Page 1]
Internet-Draft GMPLS, VCAT and LCAS October 2005
for hitless dynamic resizing of the inverse multiplex group. These
techniques apply to the Optical Transport Network (OTN), Synchronous
Optical Network (SONET), Synchronous Digital Hierarchy (SDH) and
Plesiochronous Digital Hierarchy (PDH) signals.
Table of Contents
1. Overview of VCAT and LCAS . . . . . . . . . . . . . . . . . . 3
1.1. VCAT signals and components . . . . . . . . . . . . . . . 3
1.2. VCAT Capabilities and Limitations . . . . . . . . . . . . 3
1.3. The LCAS Protocol . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement and Current Support . . . . . . . . . . . . 5
2.1. Discovery of Enabled End Systems . . . . . . . . . . . . . 5
2.2. Client to End Point Mappings . . . . . . . . . . . . . . . 5
2.3. VCAT configuration without LCAS . . . . . . . . . . . . . 6
2.4. VCAT configuration with LCAS . . . . . . . . . . . . . . . 7
2.5. Component Signal Configuration Scenarios . . . . . . . . . 8
3. Possible Extensions to GMPLS to support additional
VCAT/LCAS scenarios . . . . . . . . . . . . . . . . . . . . . 10
3.1. Mechanisms for Discovery of VCAT/LCAS . . . . . . . . . . 10
3.2. Mechanism to Support Multiple Client to End Point
Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Support for Component Signal Configuration Scenarios . . . 10
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Bernstein, et al. Expires April 14, 2006 [Page 2]
Internet-Draft GMPLS, VCAT and LCAS October 2005
1. Overview of VCAT and LCAS
Virtual Concatenation (VCAT) is a standardized layer 1 inverse
multiplexing technique that can be applied to OTN [6], SONET [3], SDH
[2], and PDH [5] component signals. By inverse multiplexing we mean
a method that combines multiple links at a particular layer into an
aggregate link to achieve a commensurate increase in available
bandwidth on that aggregate link. More formally, VCAT essentially
combines the payload bandwidth of multiple path layer network signals
(or trails) to support a single client (e.g. Ethernet) layer link.
For a more detailed introduction see [1].
1.1. VCAT signals and components
In the following we will use SDH terminology rather than both SONET
and SDH terminology. In SDH Virtual Concatenation (VCAT) can be
applied to the following component time division multiplex (TDM)
signals referred to as Virtual Containers (VCs): VC-11, VC-12, VC-2,
VC-3, and VC-4
Only like component signals can be aggregated into a VCAT group.
These groups are respectively known as: VC-11-Xv, VC-12-Xv, VC-2-Xv,
VC-3-Xv, and VC-4-Xv. In the previous designations X is an integer
running from 1 to a value N dependent upon the component type. See
[2] for details.
VCAT can be applied to the following PDH signals as specified in
reference [5]: DS1,E1, E3, DS3. Similar to the SONET/SDH case these
component signals can only be combined with like signals to produce
aggregates. For some reason the virtual concatenation groups of the
PDH signals were not given unique designations in [5] so we shall
adopt a similar notation to the SDH VCAT signals for the permitted
PDH VCAT signals that follow: DS1-Xv, E1-Xv, E3-Xv, DS3-Xv.
Concatenation in the optical transport network (OTN) is realized by
means of virtual concatenation of Optical Channel Payload Unit (OPU)
signals. OPUk signals (k=1, 2, 3) can be concatenated into OPUk-Xv
aggregates with X= 1,..., 256. See reference [6] for details.
1.2. VCAT Capabilities and Limitations
VCAT performs inverse multiplexing by octet/byte de-interleaving of
the encapsulated client bit stream. Hence the main limitation of any
VCAT standard or implementation is the ammount of differential delay
that can be accomodated between the component signals. These are
summarized for the different signal types in reference [1] with
details given in the respective standards documents.
Bernstein, et al. Expires April 14, 2006 [Page 3]
Internet-Draft GMPLS, VCAT and LCAS October 2005
1.3. The LCAS Protocol
The Link Capacity Adjustment Scheme for VCAT signals is a protocol
for dynamically and hitlessly changing (i.e., increasing and
decreasing) the capacity of a VCAT group. LCAS also provides
survivability capabilities, automatically decreasing the capacity if
a member of the VCAT group experiences a failure in the network, and
increasing the capacity when the network fault is repaired. LCAS,
itself, provides a mechanism for interworking between LCAS and non-
LCAS VCAT end points. VCAT does not require LCAS for its operation.
LCAS functionality does not overlap or conflict with GMPLS' routing
or signaling functionality for the establishment of component links
or entire VCAT groups. LCAS instead is used to control whether a
particular component signal is actually put into service carrying
traffic for the VCAT group.
LCAS provides for graceful degradation of failed links by having the
sink end report back the receive status of all member components. In
the case of a reported member failure, the source end will stop using
the component and the source end will send an LCAS message to the
sink end that it is not transmitting data on that component. The
worst case notification times are summarized in [1].
Bernstein, et al. Expires April 14, 2006 [Page 4]
Internet-Draft GMPLS, VCAT and LCAS October 2005
2. Problem Statement and Current Support
In this section we list a number of VCAT/LCAS usage scenarios and
their current level of support. We will evaluate the applicability
of GMPLS to these scenarios and for those scenarios that GMPLS does
not currently support we describe possible GMPLS extensions in
Section 3. Note the term "component" signal in the text is used as a
simplified notion to the more formal concepts of VC-n, ODUk, and PDH
termination function as well as VC-n, ODUk and PDH path/trail.
2.1. Discovery of Enabled End Systems
Discovering VCAT: VCAT sources can only communicate with VCAT capable
sinks. Hence the VCAT capabilities of a PDH, SDH, or OTN path
termination points need to be known.
Currently no support for discovery of VCAT or LCAS apriori, i.e.,
via routing information. Support for "discovery" of VCAT
capability at connection establishment time via signaling, i.e.,
we can request VCAT connection and if the end system cannot
support it,it would refuse the connection. TBD -- is there a
specific error code concerning "VCAT not supported".
Discovering LCAS: LCAS offers additional functionality between VCAT
capable sources and sinks. Hence the LCAS capabilities of VCAT
enabled path termination points can be useful to know in advance
of component signal setup.
Currently there is no mechanism to ask for an LCAS enabled end
point nor is there a way to find out if the other end is LCAS
enabled until after the connection is established. This is a
problem if we specifically want hitless dynamic resizing or fast
graceful degradation for a VCAT group.
2.2. Client to End Point Mappings
Fixed Client to End point Mapping: Per client signal there is a
VC-n-Xv circuit in which the X VC-n termination points are
dedicated to this client signal. At any point in time, Y out of X
VC-n termination points may be set up to carry client traffic.
For example when VCAT is deployed on a Router, the VCAT group
connects directly to one STM-N interface port (in absence of a HO
or LO switch fabric in the router). The transport network will
then split the VCAT group into two or more subgroups of
components, each being routed via diverse routes.
Bernstein, et al. Expires April 14, 2006 [Page 5]
Internet-Draft GMPLS, VCAT and LCAS October 2005
Variable Client to End point Mapping: For a set of M client signals
there are M VC-n-Xv VCAT endpoints sharing a set of N (N>M) VC-n
termination points. Typically MxX > N (example: M=10, X=7, N=64);
i.e. there is a kind of overbooking. Implication: must be able to
accommodate multiple different sized VCAT groups at an
"interface". For example an STM-64 interface can support many
different VC-4-Xv groups.
Implications: In both these cases we can have more than one VCAT
group per GMPLS link. In general it is the responsibility of the
signaling entity at the source and destination ends to choose the
appropriate VC-n termination points for the VCAT group and in the
case of "variable client mapping" to perform needed internal
configuration. However multiple VCAT groups per GMPLS link or
GMPLS addressed entity introduces an unresolvable ambiguity when
disjoint connections are set up or dynamic resizing is applied
since there is currently no "VCAT group identifier" in GMPLS
signaling.
2.3. VCAT configuration without LCAS
Base Configuration: For VCAT to operate the sink end needs to be
informed of how many components are in the VCAT group. It has no
other way of knowing if it is currently receiving all components
intended to be in the group.
Fixed sized co-routed groups are supported with current GMPLS
signaling. Disjointly routed groups are not currently supported.
Group Resizing: Additions or removals of components from a VCAT group
without are not hitless, that is data loss will occur while the
source and sink become synchronized as to the number of members in
the group.
Currently not supported within GMPLS. In particular, with each
addition or removal of a component the sink end point needs to be
told the expected number of components in the group.
Failure Conditions: Failure of a component must detected external to
VCAT system. The entire group is rendered inoperable until source
takes the failed component out of service and sink end is notified
to take component out of service.
Currently not supported within GMPLS. The source needs to be told
what component has failed and remove it from service, then the
sink must be told to also remove it from service.
Bernstein, et al. Expires April 14, 2006 [Page 6]
Internet-Draft GMPLS, VCAT and LCAS October 2005
2.4. VCAT configuration with LCAS
Base Configuration: Sink end (and source end) are first configured
with the value of "Y" (the number of components), and more
specifically which of the X (e.g. VC-n) access points (and thus
(VC-n) termination functions) are allocated to the VCAT group with
Y (VC-n) components. LCAS then detects automatically which of
those Y (VC-n) components is carrying actual traffic and puts them
into service for the group.
Currently both co-routed and disjointly routed VCAT groups can be
supported if there is no VCAT group ambiguity.
Component Addition: When a new component signal has to be added to a
VCAT group the following procedure applies.
1. Configure the adaptation source/sink functions and change the
number of components, Y, to Y+1 by identifying which of the
X-Y (e.g. VC-n) access points currently outside the group is
added to the group;
2. The new component is created, e.g., the cross-connections are
establish along the components path.
3. As soon as LCAS protocol information exchange is finished,
i.e., the state NORM is reached, client traffic is sent on the
added component.
This procedure does not affect the already established LCAS
members, that is, client traffic is not sent on the new component
until the LCAS procedure is complete;
This can be supported within GMPLS if, after GMPLS has
successfully established a potential new component, the source end
LCAS is (internally) told to add it to the group.
Component Removal: When a component is removed the following
procedure applies:
1. LCAS protocol is used to remove the component from the group,
that is, incoming traffic client data is transmitted on the
other VCAT component(s) to assure that the procedure is not
traffic affecting
2. Configure the adaptation source/sink functions and change the
number of components Y to Y-1; i.e. remove the VC-n access
point from the group.
Bernstein, et al. Expires April 14, 2006 [Page 7]
Internet-Draft GMPLS, VCAT and LCAS October 2005
3. The component connection can be, if needed, removed from the
transport network.
This can be supported within GMPLS if, before GMPLS tears down a
component, LCAS is told (local to source end) to remove the
component from service in the group.
Component Failure: When a component fails, the LCAS sink detects the
failure (how this is done is outside the scope of this ID) and
informs the source of this failure via the member status (MST)
information. The source then:
1. Takes the failed component out of service and if necessary
rearranges the sequencing of the VCAT group.
2. Informs the sink about the component removed from service and
any re-arranging of the VCAT group.
When the failed component is repaired, LCAS can automatically add
the repaired component back to the group, or alternatively a new
component can be added to bring the group back to its original
size. Note that component failure is not hitless, but note the
fast notification times of [BernDiegoRabbat].
Currently supported since no action required of GMPLS.
2.5. Component Signal Configuration Scenarios
Here we use the term "group" 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 all assesments of
whether a scenario is curretly supported assumes either (a) a single
VCAT group per GMPLS addressable entity, or (b) a mechanism is in
place to disambiguate multiple VCAT groups (see Section 2.2).
Fixed, Co-routed: A fixed bandwidth VCAT group, transported over a
co-routed set of member signals. This is the case where the
intended bandwidth of the VCAT group does not change and all
member signals follow a similar route. The intent here is the
capability to allocate the "right" amount of bandwidth.
Currently supported in GMPLS.
Fixed, Disjoint: A fixed bandwidth VCAT group, transported over at
least two disjointly routed subsets of member signals. The intent
here is additional resilience and graceful degradation in the case
of failure.
Bernstein, et al. Expires April 14, 2006 [Page 8]
Internet-Draft GMPLS, VCAT and LCAS October 2005
If LCAS is present this scenario is supported under GMPLS. Not
supported without LCAS since we need two-way communications of
some type between source and sink to coordinate which members are
to be used in the group in a failure scenario.
Dynamic, Co-routed: A dynamic VCAT group (bandwidth can be increased
or decreased via the addition or removal of member signals),
transported over a co-routed set of members. Intent here is
dynamic sizing of bandwidth.
If LCAS present this scenario is currently supported by GMPLS.
Implications: LCAS is needed for hitless resizing. Note before
LCAS can do its part of getting traffic over the modified VCAT
group, the two VCAT/LCAS endpoints need to be configured (Y -> Y+1
or Y -> Y-1); this requires either "communication" between the two
endpoints (when one of the endpoints is configured by call/
connection controller, or simple communication of the call/
connection controller with both endpoints. Without LCAS we still
need two way communications between source and sink to coordinate
which members are used in the group and changes will not be
hitless.
Dynamic, Disjoint: A dynamic VCAT group, transported over at least
two disjointly routed subsets of member signals. Intent here is
dynamic resizing and resilience.
Currently support and implications similar to the "dynamic, co-
routed" and "fixed, disjoint" cases.
Shared Pool: Two or more VCAT groups between the same source and sink
who desire to share a pool of component signals between them.
Each VCAT group may have a dedicated set of members, and may also
obtain additional members from a "common pool" of components.
Note that at any given point in time a component signal can belong
to at most one VCAT group. The intent here is to allow dynamic
resizing of VCAT groups via the sharing of a pool of established
component signals without requiring complete circuit provisioning,
i.e., only the group membership of the component signal would
change.
Currently not supported by GMPLS. Implications: a communications
mechanism between source and sink to indicate during a "change"
which group a component should now belong.
Bernstein, et al. Expires April 14, 2006 [Page 9]
Internet-Draft GMPLS, VCAT and LCAS October 2005
3. Possible Extensions to GMPLS to support additional VCAT/LCAS
scenarios
Here we look at what might be reasonable to add to GMPLS to support
the interest scenarios of Section 2 that were not currently covered.
3.1. Mechanisms for Discovery of VCAT/LCAS
Would like to get both VCAT and LCAS capability of end systems via
routing...
Would like to be able to specifically ask for LCAS capability via
signaling...
3.2. Mechanism to Support Multiple Client to End Point Mappings
This is a very important capability and it is very similar to one
that is being proposed in the end-to-end signaling for recovery I-D.
In particular the ASSOCIATION object. Note, however, since there is
a rather high probability that at some point we might use VCAT/LCAS
with GMPLS based protection we would really need an ASSOCIATION
object type specific to VCAT. Association objects are not unique and
therefore adding a new type to the Association object would make it a
good candidate to support this requirement.
3.3. Support for Component Signal Configuration Scenarios
TBD based on analysis of use of admin-status object. If the admin-
status object is sufficient we will detail its use in this
application since it is currently an optional object.
4. References
[1] Bernstein, G., Caviglia, D., and R. Rabbat, "VCAT/LCAS in a
Clamshell", To Be Published available at http://
www.grotto-networking.com/pages/VCAT-in-a-Clamshell-DRAFT.pdf,
October 2005.
[2] International Telecommunications Union, "Network node interface
for the synchronous digital hierarchy (SDH)", ITU-
T Recommendation G.707, December 2003.
[3] American National Standards Institute, "Synchronous Optical
Network (SONET) - Basic Description including Multiplex
Structure, Rates, and Formats", ANSI T1.105-2001, 2001.
[4] "Link capacity adjustment scheme (LCAS) for virtual concatenated
signals", ITU-T Recommendation G.7042, February 2004.
Bernstein, et al. Expires April 14, 2006 [Page 10]
Internet-Draft GMPLS, VCAT and LCAS October 2005
[5] "Virtual concatenation of plesiochronous digital hierarchy (PDH)
signals", ITU-T Recommendation G.7043, July 2004.
[6] "Interfaces for the Optical Transport Network (OTN)", ITU-
T Recommendation G.709, March 2003.
[7] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
August 1996.
[8] "Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks
- Specific requirements - Part 3: Carrier sense multiple access
with collision detection (CSMA/CD) access method and physical
layer specifications", IEEE Standard 802.3, March 2002.
[9] Bernstein, G., Rajagopalan, B., and D. Saha, "Optical Network
Control: Archtecture, Protocols", Addison-Wesley, 2004.
Bernstein, et al. Expires April 14, 2006 [Page 11]
Internet-Draft GMPLS, VCAT and LCAS October 2005
Appendix A. Acknowledgements
The authors would like to thank Maarten Vissers for extensive reviews
and contributions to this draft.
Bernstein, et al. Expires April 14, 2006 [Page 12]
Internet-Draft GMPLS, VCAT and LCAS October 2005
Authors' Addresses
Greg Bernstein
Grotto Networking
Phone: +1 510 573 2237
Email: gregb@grotto-networking.com
Diego Caviglia
Marconi
Email: Diego.Caviglia@marconi.com
Richard Rabbat
Fujitsu
Phone: +1 408 530 4537
Email: richard@us.fujitsu.com
Bernstein, et al. Expires April 14, 2006 [Page 13]
Internet-Draft GMPLS, VCAT and LCAS October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bernstein, et al. Expires April 14, 2006 [Page 14]