CCAMP Working Group G. Bernstein (ed.)
Internet Draft Grotto Networking
Updates: RFC 3946 D. Caviglia
Category: Standards Track Ericsson
Expires: May 2009 R. Rabbat
Google
H. van Helvoort
Huawei
November 17, 2008
Operating Virtual Concatenation (VCAT) and the Link Capacity
Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label
Switching (GMPLS)
draft-ietf-ccamp-gmpls-vcat-lcas-06.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.
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 January 17, 2009.
Bernstein Expires May 17, 2009 [Page 1]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
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 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. Revision History...............................................3
2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-05..........3
2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-04..........4
2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03..........4
2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02..........4
2.5. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........4
2.6. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........5
3. VCAT/LCAS Scenarios and Specific Requirements..................5
3.1. VCAT/LCAS Interface Capabilities..........................5
3.2. Member Signal Configuration Scenarios.....................5
3.3. VCAT Operation With or Without LCAS.......................6
3.4. VCGs and VCG Members......................................7
4. GMPLS Mechanisms in Support of VCGs............................7
4.1. VCGs Composed of a Single Co-Signaled Member Set..........8
4.1.1. One-shot VCG Setup with Co-Signaled Members..........8
4.1.2. Incremental VCG Setup with Co-Signaled Members.......9
4.1.3. Procedure for VCG Reduction by Removing a Member.....9
4.1.4. Removing Multiple VCG Members in One Shot...........10
4.1.5. Teardown of Whole VCG...............................10
4.2. VCGs Composed of Multiple Co-Signaled Member Sets........10
4.2.1. Signaled VCG Layer Information......................11
4.3. Use of the CALL_ATTRIBUTES Object........................11
4.4. VCAT CALL_ATTRIBUTES TLV Object..........................12
4.5. Procedures for Multiple Co-signaled Member Sets..........13
4.5.1. Setting up a VCAT call and VCG......................15
4.5.2. Setting up a VCAT call + LSPs with no VCG...........15
Bernstein Expires May 17, 2009 [Page 2]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
4.5.3. Associating an existing VCAT call with a VCG........15
4.5.4. Removing the association between a call and VCG.....16
5. Error Conditions and Codes....................................16
6. IANA Considerations...........................................16
7. Security Considerations.......................................17
8. Contributors..................................................17
9. Acknowledgments...............................................17
10. References...................................................19
10.1. Normative References....................................19
10.2. Informative References..................................19
Author's Addresses...............................................20
Intellectual Property Statement..................................21
Disclaimer of Validity...........................................21
Copyright Statement..............................................21
Acknowledgment...................................................21
1. Introduction
The Generalized Multi-Protocol Label Switching (GMPLS) suite of
protocols allows for the automated control of different switching
technologies including Synchronous Optical Network (SONET),
Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN)
and Plesiochronous Digital Hierarchy (PDH). This document describes
extensions to RSVP-TE to support the Virtual Concatenation (VCAT)
layer 1 inverse multiplexing mechanism that has been standardized for
SONET, SDH, OTN and PDH technologies along with its companion Link
Capacity Adjustment Scheme (LCAS).
VCAT is a TDM oriented byte striping inverse multiplexing method that
works with a wide range of existing and emerging TDM framed signals,
including very high bit rate OTN and SDH/SONET signals. Other than
member signal skew compensation this layer 1 inverse multiplexing
mechanism adds minimal additional signal delay. VCAT enables the
selection of an optimal signal bandwidth (size), extraction of
bandwidth from a mesh network, and, when combined with LCAS, hitless
dynamic resizing of bandwidth and fast graceful degradation in the
presence of network faults. To take full advantage of VCAT/LCAS
functionality extensions to GMPLS signaling are given that enable the
setup of diversely routed circuits that are members of the same VCAT
group.
2. Revision History
2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-05
Used the CALL_ATTRIBUTES Object from [MLN-Ext] rather than defining a
new CALL_DATA object.
Bernstein Expires May 17, 2009 [Page 3]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-04
Fixed text in section 4.1.3 on VCG Reduction to more accurately
describe LCAS and non-LCAS cases.
2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03
Added requirements on pre-existing members.
Slightly modified solution for member sharing to constrain calls to a
maximum of one VCG.
Introduced the CALL_DATA object.
Detailed coding of new TLV for VCAT to be included in the CALL_DATA
object.
Modified and expanded procedures to deal with new requirements and
modified solution methodology.
Added a list of error conditions.
2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02
Grammar and punctuation fixes. Updated references with newly
published RFCs.
2.5. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01
Changed section 3.1 from "Multiple VCAT Groups per GMPLS endpoint" to
"VCAT/LCAS Interface Capability" to improve clarity.
Changed terminology from "component" signal to "member" signal where
possible (not quoted text) to avoid confusion with link bundle
components.
Added "Dynamic, member sharing" scenario.
Clarified requirements with respect to scenarios and the LCAS and
non-LCAS cases.
Added text describing needed signaling information between the VCAT
endpoints to support required scenarios.
Bernstein Expires May 17, 2009 [Page 4]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
Added text to describe: co-signaled, co-routed, data plane LSP,
control plane LSP and their relationship to the VCAT/LCAS
application.
Change implementation mechanism from one based on the Association
object to one based on "Call concepts" utilizing the Notify
message.
2.6. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00
Updated reference from RFC3946bis to issued RFC4606
Updated section 3.2 based on discussions on the mailing list
3. VCAT/LCAS Scenarios and Specific Requirements
There are a number of specific requirements for the support of
VCAT/LCAS in GMPLS that can be derived from the carriers'
application-specific demands for the use of VCAT/LCAS and from the
flexible nature of VCAT/LCAS. These are set out in the following
section.
3.1. VCAT/LCAS Interface Capabilities
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. Member Signal Configuration Scenarios
We list in this section the different scenarios. 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.
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 to minimize differential delay. The intent here is
the capability to allocate an amount of bandwidth close to that
required at the client layer.
Bernstein Expires May 17, 2009 [Page 5]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
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, e.g., no unique route has the required bandwidth.
Fixed, member sharing: A fixed bandwidth VCG, transported over a set
of member signals that are allocated from a common pool of
available member signals without requiring member connection
teardown and setup.
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. The intent here is
dynamic resizing and resilience of bandwidth.
Dynamic, diversely routed: A dynamic VCG (bandwidth can be increased
or decreased via the addition or removal of member signals),
transported over at least two diversely routed subsets of member
signals. The intent here is efficient use of network resources,
dynamic resizing and resilience of bandwidth.
Dynamic, member sharing: A dynamic bandwidth VCG, transported over a
set of member signals that are allocated from a common pool of
available member signals without requiring member connection
teardown and setup.
3.3. VCAT Operation With or Without LCAS
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.
GMPLS signaling for LCAS-capable interfaces MUST support all
scenarios of section 3.2. with no loss of traffic.
GMPLS signaling for non-LCAS-capable interfaces MUST support only the
"fixed" scenarios of section 3.2.
To provide for these requirements GMPLS signaling MUST carry the
following information on behalf of the VCAT endpoints:
Bernstein Expires May 17, 2009 [Page 6]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
The type of the member signal that the VCG will contain, e.g., VC-3,
VC-4, etc.
The total number of members to be in the VCG. This provides the
endpoints in both the LCAS and non-LCAS case with information on
which to accept or reject the request, and in the non-LCAS case
will let the receiving endpoint know when all members of the VCG
have been established.
Identification of the VCG and its associated members. This provides
information that allows the endpoints to differentiate multiple
VCGs and to tell what members (LSPs) to associate with a
particular VCG.
3.4. VCGs and VCG Members
VCG members (server layer connections) may be set up prior to their
use in a VCG.
VCG members (server layer connections) may exist after their
corresponding VCG has been removed.
The signaling solution SHOULD provide a mechanism to support the
previous scenarios. However, it is not required that arbitrarily
created server layer connections be supported in the above scenarios.
4. GMPLS Mechanisms in Support of VCGs
We describe in this section the signaling mechanisms that already
exist in GMPLS using RSVP-TE [RFC3473] and [RFC4328], and the
extensions needed to completely support the requirements of section
3.
When utilizing GMPLS with VCAT/LCAS we utilize a number of control
and data plane concepts that we describe below.
VCG member -- This is an individual data plane signal of one of the
permitted SDH, SONET, OTN or PDH signal types.
Co-signaled member set -- One or more VCG members (or potential
members) set up via the same control plane signaling exchange. Note
that all members in a co-signaled set follow the same route.
Co-routed member set - One or more VCG members that follow the same
route. Although VCG members may follow the same path, this does not
imply that they were co-signaled.
Bernstein Expires May 17, 2009 [Page 7]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
Data plane LSP -- for our purposes here, this is equivalent to an
individual VCG member.
Control plane LSP -- A control plane entity that can control multiple
data plane LSPs. For our purposes here this is equivalent to our
co-signaled member set.
Section 4.1 is included for informational purposes only. It
describes existing GMPLS procedures that support a single VCG
composed of a single co-signaled member set.
Section 4.2 describes new procedures to support VCGs composed of more
than one co-signaled member sets. This includes the important
application of a VCG composed of diversely routed members. Where
possible it reuses applicable existing procedures from section 4.1.
4.1. VCGs Composed of a Single Co-Signaled Member Set
Note that this section is for informational purposes only.
The existing GMPLS signaling protocols support a VCG composed of a
single co-signaled member set. Setup using the NVC field is explained
in section 2.1 of [RFC4606]. In this case, one (single) control
plane LSP is used in support of the VCG.
There are two options for setting up the VCG, depending on hardware
capability, or management preferences: one-shot setup and incremental
setup.
The following sections explain the procedure based on an example of
setting up a VC-4-7v SDH VCAT group (corresponding to an STS-3c-7v
SONET VCAT group).
4.1.1. One-shot VCG Setup with Co-Signaled Members
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
Bernstein Expires May 17, 2009 [Page 8]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
constructed as an ordered list of 32-bit timeslot identifiers of the
same format as TDM labels. [RFC4606] requires that the order of the
labels reflect the order of the payloads to concatenate, and not the
physical order of time-slots.
4.1.2. Incremental VCG Setup with Co-Signaled Members
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 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
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. Procedure for VCG Reduction by Removing a Member
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 service
from the group. LCAS signaling is described in [ITU-T-G.7042].
In this case, the NVC value is decremented by 1 and the timeslot
identifier for the dropped component is removed from the ordered
list in the Generalized Label.
Note that for interfaces that are not LCAS-capable, removing one
component of the VCG will result in errors in the inverse-
multiplexing procedure of VCAT and result in the teardown of the
Bernstein Expires May 17, 2009 [Page 9]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
whole group. So, this is a feature that only LCAS-capable VCAT
interfaces can support without management intervention at the end
points.
Note also that a VCG member can be temporary removed from the VCG due
to a failure of the component signal. The LCAS in-band signaling will
take appropriate actions to adjust the VCG as described in [ITU-T-
G.7042].
4.1.4. Removing Multiple VCG Members in One Shot
The procedure is similar to 4.1.3. In this case, the NVC value is
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 procedure is also not supported for
VCAT-only interfaces without management intervention as removing one
or more components of the VCG will tear down the whole group.
4.1.5. 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 [RFC3473].
4.2. VCGs Composed of Multiple Co-Signaled Member Sets
The motivation for VCGs composed of multiple co-signaled member sets
comes from the requirement to support VCGs with diversely routed
members. The initial GMPLS specification did not support diversely
routed signals using the NVC construct. In fact, [RFC4606] says:
[...] The standard definition for virtual concatenation allows
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).
The setup of diversely routed VCG members requires multiple co-
signaled VCG member sets, i.e., multiple control plane LSPs.
To support a VCG with multiple co-signaled VCG members sets requires
being able to identify separate control plane LSPs with a single VCG
Bernstein Expires May 17, 2009 [Page 10]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
and exchange information pertaining to the VCG as a whole. This is
very similar to the "Call" concept described in [RFC4974]. We can
think of our VCAT/LCAS connection, e.g., our VCG, as a higher layer
service that makes use of multiple lower layer (server) connections
that are controlled by one or more control plane LSPs.
4.2.1. Signaled VCG Layer Information
When a VCG is composed of multiple co-signaled member sets, none of
the control plane LSP's signaling information can contain information
pertinent to the entire VCG. In this section we give a list of
information that should be communicated at what we define as the VCG
Call layer, i.e., between the VCG signaling endpoints. To
accommodate this information additional objects or TLVs are
incorporated into the Notify message as it is described for use in
call signaling in [RFC4974].
VCG Call setup information signaled via the Notify message with the
Call management bit (C-bit) set:
1. Signal Type
2. Number of VCG Members
3. LCAS requirements:
a. LCAS required
b. LCAS desired
c. LCAS not desired (but acceptable)
4. VCG Identifier - Used to identify a particular VCG separately
from the call ID so that call members can be reused with
different VCGs per the requirements for member sharing and the
requirements of section 3.4.
4.3. Use of the CALL_ATTRIBUTES Object
In RFC4974 the general mechanism for communicating call information
via Notify messages is given. In [MLN-Ext] the CALL_ATTRIBUTES object
is introduce for the conveyance of call related information during
call establishment and updates. We define a new
Bernstein Expires May 17, 2009 [Page 11]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
4.4. VCAT CALL_ATTRIBUTES TLV Object
For use in the CALL_ATTRIBUTES object in Notify messages we define
the following VCAT related TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Members |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCAS Req | Action | VCG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where Type is TBD, and the Length = 12 bytes.
Signal Type can take the following values and MUST never change over
the lifetime of a VCG:
Value Type (Elementary Signal)
----- ------------------------
1 VT1.5 SPE / VC-11
2 VT2 SPE / VC-12
3 STS-1 SPE / VC-3
4 STS-3c SPE / VC-4
11 OPU1 (i.e., 2.5 Gbit/s
12 OPU2 (i.e., 10 Gbit/s)
13 OPU3 (i.e., 40 Gbit/s)
21 T1 (i.e., 1.544 Mbps)
22 E1 (i.e., 2.048 Mbps)
23 E3 (i.e., 34.368 Mbps)
24 T3 (i.e., 44.736 Mbps)
Number of Members is a non-negative integer that indicates the total
number of members in the VCG (not just the call)and MUST be changed
over the life of the VCG to indicate the current number of members.
LCAS Required can take the following values and MUST NOT change over
the life of a VCG:
Bernstein Expires May 17, 2009 [Page 12]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
Value Meaning
----- ---------------------------------
0 LCAS required
1 LCAS desired
2 LCAS not desired (but acceptable)
Action is used to indicate the relationship between the call and the
VCG and takes the following values.
Value Meaning
----- ---------------------------------
0 No VCG ID (set up call prior to VCG creation)
1 New VCG for Call
2 No Change in VCG ID (number of members may have changed)
3 Remove VCG from Call
VCG ID: A 16 bit non-negative integer used to identify a particular
VCG within a session. This number MUST NOT change over the lifetime
of a VCG but can change over the lifetime of a call. To support the
member sharing scenario of section 3.2. and the requirements of
section 3.4. we allow the VCG Identifier within a call to be changed.
In this way the connections associated with a call can be dedicated
to a new VCG (allowing for a priori connection establishment and
connection persistence after a VCG has been removed).
4.5. Procedures for Multiple Co-signaled Member Sets
To establish a VCG a CALL_DATA object containing a VCAT TLV is
exchanged as part of call establishment or update. A VCG can be
established at the same time as a new call or associated with an
existing call that currently has no VCG association. When modifying
the bandwidth of a VCG a CALL_DATA object containing a VCAT TLV MUST
precede any of those changes and indicate the new total number of VCG
members.
The following mechanisms can be used to increase the bandwidth of a
VCG.
LSPs are added to a VCAT Call associated with a VCG (Action = 2).
A VCG is associated with an existing VCAT call containing LSPs
(Action = 1).
Bernstein Expires May 17, 2009 [Page 13]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
The following internal ordering is used when increasing the bandwidth
of a VCG in a hitless fashion when LCAS is supported:
A CALL_DATA Object containing a VCAT TLV indicating the new number of
members after the proposed increase is sent. If an error is
returned from the receiver the VCG state remains the same prior to
the attempted increase.
Either: (a) New LSPs are set up within a call associated with the
VCG, or (b) LSPs in an existing call are now associated with the
VCG.
The internal LCAS entity is instructed by the endpoints to "activate"
the new VCG member(s).
The following mechanisms can be used to decrease the bandwidth of a
VCG.
LSPs are removed from a VCAT Call associated with a VCG (Action = 2).
A VCG association is removed from existing VCAT call containing LSPs
(Action = 3).
In general the following internal ordering is used when decreasing
the bandwidth of a VCG in a hitless fashion when LCAS is supported:
1. A CALL_DATA Object containing a VCAT TLV indicating the new number
of members after the proposed decrease is sent. If an error is
returned from the receiver the VCG state remains the same prior to
the attempted decrease.
2. The LCAS entity is instructed by the endpoints to "deactivate" the
members to be removed from the VCG.
3. Either: (a) An LSP is removed from a call associated with a VCG;
or (b) All the LSPs of a call are removed from the VCG when the
association between the VCG and VCAT call is removed.
Note that when LCAS is not used or unavailable the VCG will be in an
unknown state between the time the VCG call level information is
updated and the actual data plane LSPs are added or removed. Note
that the incremental setup procedure of section 4.1.2. can be applied
to any of the above procedures.
Bernstein Expires May 17, 2009 [Page 14]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
4.5.1. Setting up a VCAT call and VCG
Arguably the most common operation will be simultaneously setting up
a VCAT call and its associated VCG at the same time. To do this when
one sets up a new VCAT call in the VCAT TLV one sets Action = 1
indicating that this is a new VCG for this call. LSPs would then be
added to the call until the number of members reaches the number
specified in the VCAT TLV.
Note that any other bandwidth modifications to the VCG whether up or
down will require a new VCAT call message with an appropriately
modified TLV reflecting the new number of members.
4.5.2. Setting up a VCAT call + LSPs with no VCG
To provide for pre-establishment of the server layer connections for
a VCG one can establish a VCAT call without an associated VCG. In
addition, to provide for member sharing a pool of calls with
connections can be established, then one or more of these calls (with
accompanying connections) can be associated with a particular VCG
(via the VCG ID). Note that multiple calls can be associated with a
single VCG but that no call contains members used in more than one
VCG.
To establish a VCAT call with no VCG association when one sets up a
new VCAT call in the VCAT TLV one sets Action = 0 indicating that
this is a VCAT call without an associated VCG. LSPs can then be
added to the call. The number of members parameter in the VCAT TLV
has no meaning at this point since it reflects the intended number of
members in a VCG and not in a call. A call will know via the
containment hierarchy about its associated data plane LSPs. However,
the signal type does matter since signal types can never be mixed in
a VCG and hence a VCAT call should only contain one signal type.
4.5.3. Associating an existing VCAT call with a VCG
Given a VCAT call without an associated VCG such as that set up in
section 4.5.2. one associates it with a VCG as follows. In the VCAT
call a new notify message is sent with a CALL_DATA object with a VCAT
TLV with Action = 1, a VCG ID, and the correct number of VCG members
specified based on adding all of the calls data plane LSPs to the VCG
as members.
Note that the total number of VCGs supported by a piece of equipment
may be limited and hence on reception of any message with a change of
Bernstein Expires May 17, 2009 [Page 15]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
VCG ID this limit should be checked. Likewise the sender of a message
with a change in VCG ID should be prepared to receive an error
response. To take a particular VCG out of service, rather than just
removing all its member, a special flag element is included.
4.5.4. Removing the association between a call and VCG
To reuse the server layer connections in a call in another VCG one
first needs to remove the current association between the call and a
VCG. To do this, in the VCAT call a new notify message is sent with
a CALL_DATA object with a VCAT TLV with Action = 3, a VCG ID, and the
correct number of VCG members specified based on removing all of the
calls data plane LSPs from the VCG as members. When the association
between a VCG and all existing calls has been removed then the VCG is
considered torn down.
5. Error Conditions and Codes
VCAT Call and member LSP setup can be denied for various reasons.
Below is a list of error conditions that can be encountered during
these procedures. These fall under RSVP error code TBD.
These can occur when setting up a VCAT call or associating a VCG with
a VCAT call.
Error Subcode
------------------------------------ --------
VCG signal type not Supported 1
LCAS option not supported 2
Max number of VCGs exceeded 3
Max number of VCG members exceeded 4
LSP Type incompatible with VCAT call 5
6. IANA Considerations
This document requests from IANA the assignment of a new TLV for the
CALL_ATTRIBUTES Object from [MLN-Ext]. Within this VCAT TLV are a set
of code points for permissible signal types. In addition, we request
a new RSVP error code for use with VCAT call and define a number of
corresponding error sub-codes.
Bernstein Expires May 17, 2009 [Page 16]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
7. Security Considerations
This document introduces a specific use of the Notify message and
admin status object for GMPLS signaling as originally specified in
[RFC4974]. It does not introduce any new signaling messages, nor
change the relationship between LSRs that are adjacent in the control
plane. The call information associated with diversely routed control
plane LSPs, in the event of an interception may indicate that there
are members of the same VCAT group that take a different route and
may indicate to an interceptor that the VCG call desires increased
reliability.
Otherwise, this document does not introduce any additional security
considerations.
8. 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@orange-ft.com
Lyndon Ong
Ciena
PO Box 308
Cupertino, CA 95015
United States of America
Phone: +1 408 705 2978
Email: lyong@ciena.com
9. Acknowledgments
The authors would like to thank Adrian Farrel, Maarten Vissers,
Trevor Wilson, Evelyne Roch, Vijay Pandian, Fred Gruman, Dan Li,
Bernstein Expires May 17, 2009 [Page 17]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
Stephen Shew, Jonathan Saddler and Dieter Beller for extensive
reviews and contributions to this draft.
Bernstein Expires May 17, 2009 [Page 18]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
10. References
10.1. Normative References
[MLN-Ext] Papadimitriou, D., Vigoureux M., Shiomoto, K.
Brungard, D., Le Roux, JL., "Generalized Multi-
Protocol Label Switching (GMPLS) Protocol Extensions
for Multi-Layer and Multi-Region Networks (MLN/MRN)",
work in progress: draft-ietf-ccamp-gmpls-mln-
extensions-03.txt, October, 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Extensions for G.709
Optical Transport Networks Control", RFC 4328, January
2006.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, December
2005.
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS
(GMPLS) RSVP-TE Signaling Extensions in Support of
Calls", RFC 4974, August 2007.
10.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.
[ITU-T-G.7042] International Telecommunications Union, "Link Capacity
Adjustment Scheme (LCAS) for Virtual Concatenated
Signals", ITU-T Recommendation G.7042, March 2006.
Bernstein Expires May 17, 2009 [Page 19]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
[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 M. Bernstein (ed.)
Grotto Networking
Fremont California, USA
Phone: (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
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043, USA
Email: rabbat@alum.mit.edu
Huub van Helvoort
Huawei Technologies, Ltd.
Kolkgriend 38, 1356 BC Almere
The Netherlands
Phone: +31 36 5315076
Email: hhelvoort@huawei.com
Bernstein Expires May 17, 2009 [Page 20]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
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, THE IETF TRUST 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 IETF Trust (2008).
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 May 17, 2009 [Page 21]
Internet-Draft Operating VCAT and LCAS with GMPLS November 2008
Bernstein Expires May 17, 2009 [Page 22]