One document matched: draft-bernstein-ccamp-gmpls-vcat-lcas-02.txt
Differences from draft-bernstein-ccamp-gmpls-vcat-lcas-01.txt
CCAMP Working Group G. Bernstein
Internet Draft Grotto Networking
Updates: RFC 3946 D. Caviglia
Proposed Category: Standards Track Ericsson
Expires: September 2006 R. Rabbat
Fujitsu
March 6, 2006
Operating Virtual Concatenation (VCAT) and the Link Capacity
Adjustment Scheme with Generalized Multi-Protocol Label Switching
(GMPLS)
draft-bernstein-ccamp-gmpls-vcat-lcas-02.txt
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.
This document may only be posted in an Internet-Draft.
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 September 6, 2006.
Abstract
This document describes the use of the Generalized Multi-Protocol
Label Switching (GMPLS) control plane in conjunction with the Virtual
Bernstein Expires September 6, 2006 [Page 1]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its
companion Link Capacity Adjustment Scheme (LCAS) which can be used
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.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents
1. Introduction...................................................3
2. VCAT/LCAS Scenarios and Specific Requirements..................3
2.1. Multiple VCAT Groups per GMPLS Endpoint...................4
2.2. Component Signal Configuration Requirements...............4
2.3. Discovery of Interface Capability.........................5
2.4. VCAT Operation With or Without LCAS.......................5
2.5. Incremental Construction of a VCG.........................5
3. GMPLS Mechanisms for Signaling VCAT/LCAS.......................6
3.1. Co-Routed Signals.........................................6
3.1.1. One-shot Setup of Co-Routed Signal...................6
3.1.2. Incremental Setup of Co-Routed Signal................7
3.1.3. Removing a Component Signal..........................7
3.1.4. Removing Multiple Component Signals in One Shot......8
3.1.5. Use of multiple LSPs for Co-Routed Circuits..........8
3.1.6. Teardown of Whole VCG................................8
3.2. Diversely Routed Signals..................................8
3.2.1. Association Object...................................9
3.2.1.1. Format..........................................9
3.2.2. Recap of Setup Using Diversely Routed Components....10
3.2.3. Recap of Reduction/Teardown Using Diversely Routed
Components.................................................10
3.2.4. Update and Upgrade of Existing VCAT Groups..........10
3.2.5. One LSP per Circuit.................................10
4. IANA Considerations...........................................11
5. Security Considerations.......................................11
6. Contributors..................................................12
7. Acknowledgments...............................................12
APPENDIX A: An Overview of VCAT and LCAS.........................13
A.1. VCAT Signals and Components..............................13
A.2. VCAT Capabilities and Limitations........................13
A.3. The LCAS Protocol........................................14
Bernstein Expires September 6, 2006 [Page 2]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
APPENDIX B: Carrier Perspective on VCAT/LCAS Application Areas...15
B.1. VCAT Advantages..........................................15
B.1.1. Right Sizing Bandwidth..............................15
B.1.2. Bandwidth Efficiencies in a Mesh Network............15
B.1.3. Minimizing Restoration Impact.......................15
B.1.4. Modify Component Routing............................16
B.2. LCAS Advantages..........................................16
B.2.1. Graceful Degradation................................16
B.2.2. Dynamic Adjustment..................................16
B.2.3. Painless Re-Grooming................................16
8. References....................................................18
8.1. Normative References.....................................18
8.2. Informative References...................................19
Author's Addresses...............................................19
Intellectual Property Statement..................................20
Disclaimer of Validity...........................................20
Copyright Statement..............................................21
Acknowledgment...................................................21
1. Introduction
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
for hitless dynamic resizing of the inverse multiplex group. The
reader is directed to appendix A that presents an overview of the
capabilities of VCAT and LCAS in transport networks. Further,
appendix B describes a carrier perspective on the application areas
for these technologies. We develop a set of scenarios and specific
requirements to support these scenarios in GMPLS-enabled networks.
We then describe the RSVP-TE mechanisms needed to set up co-routed
and diversely routed circuits that are members of the same VCAT group
and to resize those using LCAS. We also identify some capabilities
that would be nice to have through advertising OSPF-TE. The actual
advertisement is currently TBD.
2. VCAT/LCAS Scenarios and Specific Requirements
From the carrier application areas discussed in Appendix B, we can
derive a number of specific requirements for the support of VCAT/LCAS
in GMPLS. A number of requirements can additionally be derived from
the flexible nature of VCAT/LCAS.
Bernstein Expires September 6, 2006 [Page 3]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
2.1. Multiple VCAT Groups per GMPLS Endpoint
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 example
VCAT-capable interfaces that are not LCAS-capable. It may at the same
time have interfaces that are neither VCAT or LCAS-capable.
2.2. Component Signal Configuration Requirements
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.
o Fixed, co-routed: A fixed bandwidth VCG, transported over a co-
routed set of member signals. This is the case where the intended
bandwidth of the VCG does not change and all member signals follow
the same route and minimize differential delay. The intent here is
the capability to allocate an amount of bandwidth close to that
required at the client layer.
o Fixed, diversely routed: A fixed bandwidth VCG, transported over
at least two diversely routed subsets of member signals. In this
case, the subsets differ are link-disjoint over at least one link
of the route. The intent here is additional resilience and
graceful degradation in the case of failure (note that
differential delay may be a limiting factor).
o Dynamic, co-routed: A dynamic VCG (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.
o Dynamic, diversely routed: A dynamic VCAT group, transported over
at least two diversely routed subsets of member signals. The
intent here is dynamic resizing and resilience (but differential
delay is a limiting factor).
Bernstein Expires September 6, 2006 [Page 4]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
2.3. Discovery of Interface Capability
o Discovering VCAT: VCAT sources can only establish VCGs with VCAT
capable sinks. Hence the VCAT capabilities of a PDH, SDH, or OTN
path termination points may need to be known before the signaling
of the individual member LSPs can start.
Currently there is no support for the discovery of VCAT or LCAS a
priori, i.e., via routing information. Instead, if a network
operator tries to signal a co-routed VCAT group, if the interface
does not support it, then RFC 3946 states that the receiver node
MUST generate a PathErr message with a "Traffic Control Error/
Service unsupported" indication. If the VCAT group is made up of
diversely routed LSPs, each with carrying one element of the
group, there is no specification of the error code to be used. TBD
-- It may be useful to have a specific error code concerning "VCAT
not supported".
o 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 check a priori that an ingress
or egress is LCAS capable until after the VCG has been established
and LCAS is invoked to dynamically resize the VCG. This may be a
problem as this information may not be known until the VCG has
been put in service. TBD -- It may be useful to have this
information advertised and it may be good to have a specific error
code "LCAS not supported" in the case LCAS is used on an interface
that is not LCAS enabled.
2.4. VCAT Operation With or Without LCAS
VCAT capabilities may be present with or without the presence of
LCAS, hence GMPLS mechanisms for the establishment and removal of
VCAT groups SHALL be equally applicable in the presence or absence of
the LCAS.
2.5. Incremental Construction of a VCG
In some cases, it may not be possible to set up the VCG in one shot.
This may be the case for example when hardware cannot match the
individual members at sink and source in the inverse multiplexing
function. Therefore support for VCAT in GMPLS SHOULD allow
incremental setup of the individual members of the VCG.
Bernstein Expires September 6, 2006 [Page 5]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
3. GMPLS Mechanisms for Signaling VCAT/LCAS
We describe in this section the signaling mechanisms that already
exist in GMPLS using RSVP-TE [RFC3473] and the extensions needed,
mainly for diversely routed paths and in support of the LCAS
procedure. We also discuss the advertising of bandwidth availability
to the client layer using OSPF-TE [RFC3630], [RFC4202] and [RFC4203].
Section 3.1. is included for informational purposes only. It
describes existing procedures and was included for completeness and
for reference.
Section 3.2. describes new procedures proposed to support diversely
routed VCAT groups. When possible it reuses any applicable existing
procedures from section 3.1.
3.1. Co-Routed Signals
Note that this section is for informational purposes only.
The existing RFCs support co-routed signal setup using the NVC field
as explained in section 2.1 of RFC 3946 [RFC3946bis]. In this case,
one LSP will be set up in support of the VCAT group.
There are two options for setting up the VCAT group, depending on
hardware capability, or management preferences. We'll outline the
one-shot and incremental setup.
Let's explain the procedure based on an example of setting up an VC4-
7v in SDH (corresponding to STS-3c-7v SONET) VCAT group.
3.1.1. One-shot Setup of Co-Routed Signal
An RSVP-TE Path message is used with the following parameters.
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.
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
assigned to one LSP.
SDH and SONET labels in turn have to be defined: an explicit ordered
list of all labels (32-bit values of the Generalized Label object) in
the concatenation is given. RFC 3946 requires that the order of the
labels reflect the order of the payloads to concatenate and not the
physical order of time-slots).
Bernstein Expires September 6, 2006 [Page 6]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
When the MT field is larger than 1, the list includes labels for the
components of each of the group.
Note that full Refresh messages (using Path) carry all the
information and parameters explained above whereas Summary Refresh
messages will only carry the Message IDs. Full Path Refresh messages
are NOT end-to-end signaling messages.
3.1.2. Incremental Setup of Co-Routed Signal
In some cases, it may be necessary to set up components individually.
One example of this requirement is when the hardware that supports
VCAT can only add VCAT elements one at a time or cannot match
automatically the elements at the ingress and egress for the purposes
of inverse multiplexing. The serial or incremental setup solves this
problem.
In order to accomplish incremental setup, and for each iteration, NVC
is incremented up to the final value required. The iteration
consists of the successful completion of a Path and Resv signaling.
At first, NVC = 1 and one label is included.
At each of the next iterations, NVC is set to (NVC +1), one more
label is added to the ordered list of labels (in the Path or Resv
message). A node that receives the message that contains changed
fields will process the full Path 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 new label information.
Note that if a new upstream label is required, this label must be
added to the PATH message. If only a downstream label is required,
then the upstream label is unchanged and a downstream label is
received in the RESV message.
Following the addition of the new label to the LSP, LCAS is used in-
band to add the new label into the existing VCAT group. LCAS
signaling for this is described in [ITU-T-G.7042].
3.1.3. Removing a Component Signal
The procedure is similar to 3.1.2. The LCAS step is taken first
though as follows. First, the label to be dropped is taken out of
the group using LCAS signaling (in-band). LCAS signaling is
described in [ITU-T-G.7042].
Bernstein Expires September 6, 2006 [Page 7]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
In this case, the NVC value is decremented by 1 and a label is
removed from the ordered list. This is not supported for VCAT-only
interfaces as removing one component of the VCG will result in errors
in the inverse-multiplexing procedure of VCAT and result in the
teardown of the whole group. So, this is a feature that only LCAS-
capable VCAT interfaces can support.
3.1.4. Removing Multiple Component Signals in One Shot
The procedure is similar to 3.1.3. In this case, the NVC value is
changed to the new value and all relevant labels for the components
to be torn down are removed from the ordered list. This is also not
supported for VCAT-only interfaces as removing one component of the
VCG will tear down the whole group.
3.1.5. Use of multiple LSPs for Co-Routed Circuits
It is possible to use as many LSPs to subtend the co-routed circuits.
If this is the case, the procedure outlined in the following section
can be applied directly here. The Association object as discussed in
this section is used to indicate the VCG association type.
3.1.6. Teardown of Whole VCG
LCAS signaling is used inband to remove the labels associated with
the LSP from the group. LCAS signaling is defined in [ITU-T-G.7042].
Following the removal of the LSP from the group, the LSP is deleted
by using deletion procedures of [RFC 3473] (e.g., the deleting
ingress LSR -egress LSR respectively- sends a Path -Resv message
respectively- with Admin_Status marked for the LSP being removed).
3.2. Diversely Routed Signals
The initial GMPLS specification did not support diversely routed
signals using the NVC construct. In fact, RFC 3946 says:
[...] The standard definition for virtual concatenation allows
each virtual concatenation components to travel over diverse
paths. Within GMPLS, virtual concatenation components must
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
(component) link. Note however, that the routing of components
on different paths is indeed equivalent to establishing
different LSPs, each one having its own route. Several LSPs can
be initiated and terminated between the same nodes and their
Bernstein Expires September 6, 2006 [Page 8]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
corresponding components can then be associated together (i.e.,
virtually concatenated).
Diverse routing of signals can be a useful capability but requires
the extensions identified in this document.
3.2.1. Association Object
The feature that needs to be added is the functionality to associate
the corresponding components. For this purpose, we propose the use
of the Association Object. The association object was defined in
[E2E-RECOVERY] to associate working and recovery LSPs.
We expect a diversely routed VCG to use a number of routes R <= VCG
size, as some routes may be the same for several components. We
should then set up R LSPs. For a bin of c components using the same
route, we set up the LSP with a value NVC = c as explained in 1.B and
1.C.
To be able to associate the LSPs, the SESSION object MUST be the same
for all LSPs (also indicates that the same Tunnel ID is used for all
the LSPs). The LSP ID, however, MUST be different to distinguish
between the LSPs. The Association ID is a 16-bit value, so we can
have for one SESSION up to 2^16 associations, meaning up to 2^16
diversely routed VCAT groups and any number of co-routed LSPs.
Since we are not using this Association ID to indicate protection,
the value for the Association ID should be decided by an outside
entity. This may be the management plane. The assignment of the
Association ID is outside the scope of GMPLS but must be unique for
the same Session.
This does not preclude the use of another Association ID to indicate
the recovery, as the standard allows the use of multiple Association
objects. We need to differentiate between the association objects
used for the VCAT group and the association objects used for
recovery.
In this draft, we define a new association type to indicate that this
is a VCG association.
3.2.1.1. Format
Association Type: 16 bits
Value Type
----- ----
Bernstein Expires September 6, 2006 [Page 9]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
3 VCAT group
See [E2E-RECOVERY] for the definition of other fields and values
while noting again that the Association ID should be unique per
session.
3.2.2. Recap of Setup Using Diversely Routed Components
For every route R, use procedure outlined in 3.1.1. or 3.1.2.
depending on the capability of the equipment or general preference.
The Path message MUST include the Association object with type set to
3.
For example, we use two routes: one to carry 3 VC-4 circuits and the
other to carry 4 VC-4 circuits. This results in two associated LSPs.
Following the addition of the new LSP (i.e., RESV message is received
by the endpoint adding bandwidth), LCAS signaling is used in-band to
hitlessly add the new label into the existing group [ITU-T-G.7042].
3.2.3. Recap of Reduction/Teardown Using Diversely Routed Components
For every route R, to remove component circuits on that route, first,
LCAS signaling is used in-band to remove the labels associated with
the LSP from the group. LCAS signaling is defined in [ITU-T-G.7042].
Then, use procedures outlined in 3.1.3. or 3.1.4.
This again can only be done on LCAS-capable interfaces. If the
procedure is attempted on VCAT-only interfaces, then the whole VCG is
torn down (this is not a graceful teardown so ingress/egress initiate
a Path Tear/Resv Tear) on all routes R.
3.2.4. Update and Upgrade of Existing VCAT Groups
For existing VCAT groups, in order to allow them to participate in
diversely routed VCGs, we use the same method of changing the message
ID for the Path message of an existing LSP and adding the Association
object that will be interpreted at all intermediate and edge nodes
and that Association object will be added to the LSP information.
3.2.5. One LSP per Circuit
Similarly to in 3.2.4, one may wish to use as many LSPs as circuits.
This is supported and each LSP will be used to set up one element of
the VCG. The Association object is used to indicate the VCG
association type.
Bernstein Expires September 6, 2006 [Page 10]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
4. IANA Considerations
This document requests from IANA the assignment of a new Association
Type within the Association object. This object was defined in [E2E-
RECOVERY].
5. Security Considerations
This document introduces a new use of the Association object for GMLS
signaling [RFC3473] to associate diversely routed VCAT group members.
It does not introduce any new signaling messages, nor change the
relationship between LSRs that are adjacent in the control plane.
This association information in the event of an interception may
indicate that there members of the same VCAT group that take a
different route and may indicate to an interceptor that the network
may be more robust.
Otherwise, this document does not introduce any additional security
considerations.
Bernstein Expires September 6, 2006 [Page 11]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
6. Contributors
Wataru Imajuku (NTT)
1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847
Japan
Phone +81-46-859-4315
Email: imajuku.wataru@lab.ntt.co.jp
Julien Meuric
France Telecom
2, avenue Pierre Marzin
22307 Lannion Cedex
France
Phone: + 33 2 96 05 28 28
Email: julien.meuric@francetelecom.com
Lyndon Ong (Ciena)
PO Box 308
Cupertino, CA 95015
United States of America
Phone: +1 408 705 2978
Email: lyong@ciena.com
Huub van Helvoort (Huawei)
Kolkgriend 38, 1356 BC Almere
The Netherlands
Phone: +31 36 5315076
Email: hhelvoort@chello.nl
7. Acknowledgments
The authors would like to thank Maarten Vissers and Adrian Farrel for
extensive reviews and contributions to this draft.
Bernstein Expires September 6, 2006 [Page 12]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
APPENDIX A: An Overview of VCAT and LCAS
Virtual Concatenation (VCAT) is a standardized layer 1 inverse
multiplexing technique that can be applied to OTN [ITU-T-G.709],
SONET [ANSI-T1.105], SDH [ITU-T-G.707], and PDH [ITU-T-G.7043]
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 [BCR05], [BRS04] and [Hel05].
A.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
(X= 1... 64), VC-3-Xv and VC-4-Xv (X=1... 256).
VCAT can be applied to the following PDH signals as specified in
reference [ITU-T-G.7043]: 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 [ITU-
T-G.7043] so we shall adopt a similar notation to the SDH VCAT
signals for the permitted PDH VCAT signals that follow: DS1-Xv, E1-Xv
(X=1... 16), E3-Xv, DS3-Xv (X= 1... 8).
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 (X= 1... 256). See reference [ITU-T-G.709] for details.
A.2. VCAT Capabilities and Limitations
VCAT performs inverse multiplexing by octet/byte de-interleaving of
the encapsulated client bit stream. The main limitation of any VCAT
standard or implementation is the amount of differential delay that
can be accommodated between the component signals when they are
diversely routed. These are summarized for the different signal types
Bernstein Expires September 6, 2006 [Page 13]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
in reference [BCR05] and [Hel05] with details given in the respective
standards documents.
A.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 [BCR05] and [Hel05].
Bernstein Expires September 6, 2006 [Page 14]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
APPENDIX B: Carrier Perspective on VCAT/LCAS Application Areas
We present in this appendix a number of application areas of VCAT and
LCAS that make them valuable in the transport network.
B.1. VCAT Advantages
When used as a transport layer, SONET/SDH networks may require that
containers be grouped together to offer services with higher
bandwidth than the base elementary transport entities. While
contiguous concatenation imposes stringent constraints on the
placement of component signals and restricts sizing to specific
combinations (X= 1, 4, 16 ...), virtual concatenation offers much
more flexibility (X= 1, 2, 3 ...) in sizing and no placement
restrictions.
B.1.1. Right Sizing Bandwidth
Virtual concatenation allows the customization of the number of
components in a group, thus offering a bandwidth closer to the client
layer needs. A common example is the STS-3c-7v/VC-4-7v often used in
data transport since well fit to 1 Gbit/s traffic, whereas an STS-
48c/VC-4-16c (imposed by contiguous concatenation) would be too big
and lead to wasting bandwidth.
B.1.2. Bandwidth Efficiencies in a Mesh Network
Given an end-to-end bandwidth demand between a source and a sink and
a mesh network topology, there may be enough total bandwidth across
the network to meet the demand, but not along a single route. VCAT
has the ability to transport components of a Virtually Concatenated
Group (VCG) over different paths which can be diversely routed in the
network. In this way, a carrier increases the efficiency of the
transport network by making better use of the mesh topology of that
network.
B.1.3. Minimizing Restoration Impact
The diverse routing enabled by VCAT is a useful capability since, in
case of single failure, only a subset of the members of the VCG needs
to be recovered, which allows a higher availability than the single
route case. This means that a failure does not require recovery for
the whole VCG but only for the failed path, and a sub-part of the
total bandwidth will be easier to restore than the full pipe. This
becomes more beneficial when combined with LCAS (see below). As a
matter of fact, this is a key driver for using VCAT in a carrier's
network.
Bernstein Expires September 6, 2006 [Page 15]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
B.1.4. Modify Component Routing
In order to migrate from singly-routed transport services and
distribute circuits over multiple routes, it is also useful to
segregate a single VCG into several LSPs. Indeed, while resources may
be provisioned using a single LSP at day one, there should be a
migration path to allow the members of the VCG to be carried over
diverse routes as allowed by VCAT.
B.2. LCAS Advantages
When VCAT is used in a carrier network, enabling LCAS brings a number
of additional advantages to network operations.
B.2.1. Graceful Degradation
When a member of an LCAS-enabled VCG is faulty, the other members
keep carrying their portion (interleaved bytes) of traffic, i.e., the
portion of the traffic on the faulty member does not reach the
destination. Hence, the entire VCG is delivering errored data until
the faulty member is removed from the VCG. With LCAS the process of
removing the faulty member is automated and very fast. Note that
removing the member from carrying traffic for the group is different
from setting up or removing the member circuit. This functionality is
particularly useful when the VCG is diversely routed because some
bandwidth remains available during restoration and can be used by the
client layer with no interruption to traffic, albeit at a decreased
bit-rate.
B.2.2. Dynamic Adjustment
LCAS allows for hitless resizing of VCGs between two endpoints.
Without LCAS, the bandwidth associated with a transport service
cannot be modified without traffic disruption: a VCG needs indeed to
be re-provisioned with the necessary number of components to meet the
new demand. LCAS brings the necessary mechanisms to modify a VCG by
adding and removing some components while allowing the VCG to carry
traffic uninterrupted.
B.2.3. Painless Re-Grooming
When connections need to be rerouted due to maintenance or to make
efficient use of network resources, the process, known as re-
grooming, generally impacts user traffic. LCAS enables a hitless
method for re-grooming by first adding to VCGs additional components
that have been set up on the new desired path, then removing the old
Bernstein Expires September 6, 2006 [Page 16]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
components from the VCG and releasing the unused resources from the
network.
Bernstein Expires September 6, 2006 [Page 17]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2961] Berger, L. et ali "RSVP Refresh Overhead Reduction
Extensions" RFC 2961, April 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[RFC3946-bis] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control ", IETF draft, work in
progress, December 2005.
[RFC4202] Kompella, K. and Y. Rekhter (Eds.), "Routing
Extensions in Support of Generalized Multi-protocol
Label Switching", RFC 4202, October 2005.
[RFC4203] Kompella, K. and Y. Rekhter (Eds.), "OSPF Extensions
in Support of Generalized Multi-protocol Label
Switching", RFC 4203, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)" RFC 4206,
October 2005.
[E2E-RECOVERY] Lang, J.P., Rekhter, Y., and D. Papadimitriou (eds.),
"RSVP-TE Extensions in support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)-
based Recovery", IETF draft, work in progress, April
2005.
Bernstein Expires September 6, 2006 [Page 18]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
8.2. Informative References
[ANSI-T1.105] American National Standards Institute, "Synchronous
Optical Network (SONET) - Basic Description including
Multiplex Structure, Rates, and Formats", ANSI T1.105-
2001, May 2001.
[BCR05] 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.
[BRS04] Bernstein, G., Rajagopalan, B. and D. Saha, "Optical
Network Control: Architecture, Protocols", Addison-
Wesley, 2004.
[Hel05] Helvoort, H., "Next Generation SDH/SONET: Evolution or
Revolution?" Wiley & Sons, 2005.
[ITU-T-G.7042] International Telecommunications Union, "Link Capacity
Adjustment Scheme (LCAS) for Virtual Concatenated
Signals", ITU-T Recommendation G.7042, February 2004.
[ITU-T-G.7043] International Telecommunications Union, "Virtual
Concatenation of Plesiochronous Digital Hierarchy
(PDH) Signals", ITU-T Recommendation G.7043, July
2004.
[ITU-T-G.707] International Telecommunications Union, "Network Node
Interface for the Synchronous Digital Hierarchy
(SDH)", ITU-T Recommendation G.707, December 2003.
[ITU-T-G.709] International Telecommunications Union, "Interfaces
for the Optical Transport Network (OTN)", ITU-T
Recommendation G.709, March 2003.
Author's Addresses
Greg Bernstein
Grotto Networking
Phone: +1-510-573-2237
Email: gregb@grotto-networking.com
Bernstein Expires September 6, 2006 [Page 19]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
Diego Caviglia
Ericsson
Via A. Negrone 1/A 16153
Genoa Italy
Phone: +39 010 600 3736
Email: diego.caviglia@(marconi.com, ericsson.com)
Richard Rabbat
Fujitsu Laboratories of America
1240 East Arques Ave, MS 345
Sunnyvale, CA 94085
United States of America
Phone: +1 408-530-4537
Email: richard@us.fujitsu.com
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
Bernstein Expires September 6, 2006 [Page 20]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bernstein Expires September 6, 2006 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-23 06:49:23 |