One document matched: draft-bernstein-ccamp-gmpls-vcat-lcas-03.txt
Differences from draft-bernstein-ccamp-gmpls-vcat-lcas-02.txt
CCAMP Working Group G. Bernstein
Internet Draft Grotto Networking
Updates: RFC 3946 D. Caviglia
Proposed Category: Standards Track Ericsson
Expires: December 2006 R. Rabbat
Fujitsu
H. van Helvoort
Huawei
June 25, 2006
Operating Virtual Concatenation (VCAT) and the Link Capacity
Adjustment Scheme with Generalized Multi-Protocol Label Switching
(GMPLS)
draft-bernstein-ccamp-gmpls-vcat-lcas-03.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 December 25, 2006.
Bernstein Expires December 25, 2006 [Page 1]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
Abstract
This document describes requirements for, and 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. 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. Changes from draft-bernstein-ccamp-gmpls-vcat-lcas-02..........3
3. VCAT/LCAS Scenarios and Specific Requirements..................4
3.1. Multiple VCAT Groups per GMPLS Endpoint...................4
3.2. Component Signal Configuration Requirements...............4
3.3. VCAT Operation With or Without LCAS.......................5
4. GMPLS Mechanisms for Signaling VCAT/LCAS.......................5
4.1. Co-Routed Signals.........................................5
4.1.1. One-shot Setup of Co-Routed Signal...................6
4.1.2. Incremental Setup of Co-Routed Signal................6
4.1.3. Removing a Component Signal..........................7
4.1.4. Removing Multiple Component Signals in One Shot......7
4.1.5. Use of multiple LSPs for Co-Routed Signals...........7
4.1.6. Teardown of Whole VCG................................7
4.2. Diversely Routed Signals..................................8
4.2.1. Associating Diversely Routed Signals.................8
4.2.1.1. Format..........................................9
4.2.2. Recap of Setup Using Diversely Routed Components.....9
4.2.3. Recap of Reduction/Teardown Using Diversely Routed
Components.................................................10
4.2.4. Update and Upgrade of Existing VCAT Groups..........10
4.2.5. One LSP per Circuit.................................10
5. IANA Considerations...........................................10
6. Security Considerations.......................................10
7. Contributors..................................................11
8. Acknowledgments...............................................11
Bernstein Expires December 25, 2006 [Page 2]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
APPENDIX A: An Overview of VCAT and LCAS.........................12
A.1. VCAT Signals and Components..............................12
A.2. VCAT Capabilities and Limitations........................12
A.3. The LCAS Protocol........................................13
APPENDIX B: Carrier Perspective on VCAT/LCAS Application Areas...14
B.1. VCAT Advantages..........................................14
B.1.1. Right Sizing Bandwidth..............................14
B.1.2. Bandwidth Efficiencies in a Mesh Network............14
B.1.3. Minimizing Restoration Impact.......................14
B.1.4. Modify Component Routing............................15
B.2. LCAS Advantages..........................................15
B.2.1. Graceful Degradation................................15
B.2.2. Dynamic Adjustment..................................15
B.2.3. Painless Re-Grooming................................15
9. References....................................................17
9.1. Normative References.....................................17
9.2. Informative References...................................17
Author's Addresses...............................................18
Intellectual Property Statement..................................19
Disclaimer of Validity...........................................19
Copyright Statement..............................................19
Acknowledgment...................................................20
1. Introduction
This document describes requirements for, and 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 as well as diversely routed circuits that
are members of the same VCAT group and to resize those using LCAS.
2. Changes from draft-bernstein-ccamp-gmpls-vcat-lcas-02
o Added one more author (Huub)
Bernstein Expires December 25, 2006 [Page 3]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
o Dropped section 3.3 about advertising VCAT and LCAS capability.
This change is due to the amount of information that would need to
be advertised. VCAT capability at the interface comprises a lot
of information, which make advertising not very scalable. For
example, a node could perform an adaptation using two interfaces
lying on different line cards but that's not necessarily always
the case. This update to the draft expects the use of the NMS in
selecting the right destinations.
o Removed references to OSPF-TE
3. 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.
3.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 nor LCAS-
capable.
3.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 are link-disjoint over at least one link of the
route. The intent here is more efficient use of network resources
(no unique route has the required bandwidth), and additional
resilience and graceful degradation in the case of failure (note
that differential delay may be a limiting factor).
Bernstein Expires December 25, 2006 [Page 4]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
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 may be a limiting factor).
3.3. VCAT Operation With or Without LCAS
VCAT capabilities may be present with or without the presence of
LCAS. The use of LCAS is beneficial to the provision of services,
but in the absence of LCAS, VCAT is still a valid technique.
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
available. The GMPLS procedures for the two cases SHOULD be
identical.
4. 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, for
diversely routed paths and in support of the LCAS procedure.
Section 4.1 is included for informational purposes only. It
describes existing procedures and makes not changes.
Section 4.2 describes new procedures proposed to support diversely
routed VCAT groups. Where possible it reuses applicable existing
procedures from section 4.1.
4.1. Co-Routed Signals
Note that this section is for informational purposes only.
The existing signaling protocols support co-routed signal setup using
the NVC field as explained in section 2.1 of RFC 3946 [RFC3946bis].
In this case, one single LSP is 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: one-shot setup and
incremental setup.
Bernstein Expires December 25, 2006 [Page 5]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
The following sections explain the procedure based on an example of
setting up a VC4-7v SDH VCAT group (corresponding to an STS-3c-7v
SONET VCAT group).
4.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 or SONET labels in turn have to be assigned for each member of
the VCG and concatenated to form a single Generalized Label
constructed as an ordered list of 32-bit timeslot identifiers of the
same format as TDM labels. 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.
When the MT field is larger than 1, the list includes labels for the
components of each of the group.
4.1.2. Incremental Setup of Co-Routed Signal
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.
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
the elements at the ingress and egress for the purposes of inverse
multiplexing. Serial or incremental setup solves this problem.
In order to accomplish incremental setup an iterative process is used
to add group members. 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 the
label includes just one timeslot identifier
At each of the next iterations, NVC is set to (NVC +1), one more
timeslot identifier is added to the ordered list in the Generalized
Label (in the Path or Resv message). A node that receives a 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
Bernstein Expires December 25, 2006 [Page 6]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
signal to the VCAT group, and switch the new timeslot based on the
new label information.
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
signaling for this function is described in [ITU-T-G.7042].
4.1.3. Removing a Component Signal
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
signaling step is taken first to take the component out of the group.
LCAS signaling is described in [ITU-T-G.7042].
In this case, the NVC value is decremented by 1 and the timeslot
identifier for the dropped component is removed from the ordered list
in the Generalized Label. This function is not supported without
management intervention 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 without management intervention at the end
points.
4.1.4. Removing Multiple Component Signals in One Shot
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
the components to be torn down are removed from the ordered list in
the Generalized Label. This is also not supported for VCAT-only
interfaces without management intervention as removing one component
of the VCG will tear down the whole group.
4.1.5. Use of multiple LSPs for Co-Routed Signals
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
removed in one go) using deletion procedures of [RFC 3473].
Bernstein Expires December 25, 2006 [Page 7]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
4.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 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.
4.2.1. Associating Diversely Routed Signals
The feature that needs to be added is the functionality to associate
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
routes may be the same for several components. A number of LSPs, L
(L >= R) are used with each LSP establishing at least one component
of the VCG, and at most all of the co-routed members of the group.
For a set of c components using the same route, we set up the LSP
with NVC = c exactly as explained in section 4.1.1. Therefore, the
association of group members or of sub-groups to form the VCG
requires the association of the LSPs used to establish the group
members.
To be able to associate the LSPs, the Session object MUST be the same
for all LSPs (this also indicates that the same Tunnel ID is used for
all the LSPs). The LSP ID, however, MUST be different for each LSP
to distinguish between the LSPs. However, since there are
potentially many reasons for multiple LSPs within a single session
(for example, end-to-end protection, make-before-break, etc.) a
mechanism to identify the association of a subset LSPs is needed.
Bernstein Expires December 25, 2006 [Page 8]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
The Association ID in the Association object 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.
Note that 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.
4.2.1.1. Format
Association Type: 16 bits
Value Type
----- ----
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.
4.2.2. Recap of Setup Using Diversely Routed Components
For every route R, use procedure outlined in 4.1.1 or 4.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].
Bernstein Expires December 25, 2006 [Page 9]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
4.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 4.1.3 or 4.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.
4.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.
4.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.
5. 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].
6. 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 December 25, 2006 [Page 10]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
7. 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
8. Acknowledgments
The authors would like to thank Maarten Vissers and Adrian Farrel for
extensive reviews and contributions to this draft.
Bernstein Expires December 25, 2006 [Page 11]
Internet-Draft Operating VCAT and LCAS with GMPLS June 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 [BCRH06], [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
Bernstein Expires December 25, 2006 [Page 12]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
types in reference [BCRH06] 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 [BCRH06] and [Hel05].
Bernstein Expires December 25, 2006 [Page 13]
Internet-Draft Operating VCAT and LCAS with GMPLS June 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 December 25, 2006 [Page 14]
Internet-Draft Operating VCAT and LCAS with GMPLS June 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 December 25, 2006 [Page 15]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
components from the VCG and releasing the unused resources from the
network.
Bernstein Expires December 25, 2006 [Page 16]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
9. References
9.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.
[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.
[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.
9.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.
[BCRH06] Bernstein, G., Caviglia, D., R. Rabbat and H. van
Helvoort, "VCAT/LCAS in a Clamshell", IEEE
Communications Magazine, May 2006.
[BRS04] Bernstein, G., Rajagopalan, B. and D. Saha, "Optical
Network Control: Architecture, Protocols", Addison-
Wesley, 2004.
Bernstein Expires December 25, 2006 [Page 17]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
[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
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
Bernstein Expires December 25, 2006 [Page 18]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006
Huub van Helvoort
Huawei
Kolkgriend 38, 1356 BC Almere
The Netherlands
Phone: +31 36 5315076
Email: hhelvoort@chello.nl
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 (2006).
Bernstein Expires December 25, 2006 [Page 19]
Internet-Draft Operating VCAT and LCAS with GMPLS June 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 December 25, 2006 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 01:10:57 |