draft-ietf-ccamp-gmpls-vcat-lcas-08.txt   draft-ietf-ccamp-gmpls-vcat-lcas-09.txt 
CCAMP Working Group G. Bernstein (ed.) CCAMP Working Group G. Bernstein (ed.)
Internet Draft Grotto Networking Internet Draft Grotto Networking
Updates: RFC 3946 D. Caviglia Updates: RFC 3946 D. Caviglia
Category: Standards Track Ericsson Category: Standards Track Ericsson
Expires: January 2010 R. Rabbat Expires: July 2010 R. Rabbat
Google Google
H. van Helvoort H. van Helvoort
Huawei Huawei
July 29, 2009 January 11, 2010
Operating Virtual Concatenation (VCAT) and the Link Capacity Operating Virtual Concatenation (VCAT) and the Link Capacity
Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label
Switching (GMPLS) Switching (GMPLS)
draft-ietf-ccamp-gmpls-vcat-lcas-08.txt draft-ietf-ccamp-gmpls-vcat-lcas-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 29, 2010. This Internet-Draft will expire on July 11, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
skipping to change at page 2, line 27 skipping to change at page 2, line 27
Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction......................................... 3
2. Revision History...............................................4 2. VCAT/LCAS Scenarios and Specific Requirements ............. 4
2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-07..........4 2.1. VCAT/LCAS Interface Capabilities.................... 4
2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-05 and -06..4 2.2. Member Signal Configuration Scenarios................ 4
2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-04..........4 2.3. VCAT Operation With or Without LCAS.................. 5
2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03..........4 2.4. VCGs and VCG Members.............................. 6
2.5. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02..........4 3. VCAT Data and Control Plane Concepts..................... 6
2.6. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........4 4. VCGs Composed of a Single Co-Signaled Member Set (One LSP)... 7
2.7. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........5 4.1. One-shot VCG Setup with Co-Signaled Members........... 7
3. VCAT/LCAS Scenarios and Specific Requirements..................5 4.2. Incremental VCG Setup with Co-Signaled Members......... 7
3.1. VCAT/LCAS Interface Capabilities..........................5 4.3. Procedure for VCG Reduction by Removing a Member....... 8
3.2. Member Signal Configuration Scenarios.....................6 4.4. Removing Multiple VCG Members in One Shot............. 9
3.3. VCAT Operation With or Without LCAS.......................6 4.5. Teardown of Whole VCG............................. 9
3.4. VCGs and VCG Members......................................7 5. VCGs Composed of Multiple Co-Signaled Member Sets(Multiple LSPs)9
4. GMPLS Mechanisms in Support of VCGs............................7 5.1. Signaled VCG Service Layer Information.............. 10
4.1. VCGs Composed of a Single Co-Signaled Member Set..........8 5.2. VCAT TLV....................................... 11
4.1.1. One-shot VCG Setup with Co-Signaled Members..........9 5.3. Procedures for Multiple Co-signaled Member Sets....... 13
4.1.2. Incremental VCG Setup with Co-Signaled Members.......9 5.3.1. Setting up a new VCAT call and VCG Simultaneously. 13
4.1.3. Procedure for VCG Reduction by Removing a Member....10 5.3.2. Setting up a VCAT call + LSPs without a VCG...... 13
4.1.4. Removing Multiple VCG Members in One Shot...........10 5.3.3. Associating an existing VCAT call with a new VCG.. 14
4.1.5. Teardown of Whole VCG...............................10 5.3.4. Removing the association between a call and VCG... 14
4.2. VCGs Composed of Multiple Co-Signaled Member Sets........10 5.3.5. VCG Bandwidth modification.................... 14
4.2.1. Signaled VCG Layer Information......................11 6. Error Conditions and Codes............................ 15
7. IANA Considerations.................................. 16
4.3. Use of the CALL_ATTRIBUTES Object........................12 7.1. RSVP CALL_ATTRIBUTE TLV .......................... 16
4.4. VCAT CALL_ATTRIBUTES TLV Object..........................12 7.2. RSVP Error Codes and Error Values.................. 16
4.5. Procedures for Multiple Co-signaled Member Sets..........13 8. Security Considerations............................... 17
4.5.1. Setting up a VCAT call and VCG......................15 9. Contributors........................................ 18
4.5.2. Setting up a VCAT call + LSPs with no VCG...........15 10. Acknowledgments.................................... 18
4.5.3. Associating an existing VCAT call with a VCG........15 11. References ........................................ 19
4.5.4. Removing the association between a call and VCG.....16 11.1. Normative References............................ 19
5. Error Conditions and Codes....................................16 11.2. Informative References .......................... 19
6. IANA Considerations...........................................16 Author's Addresses..................................... 20
7. Security Considerations.......................................17 Intellectual Property Statement .......................... 21
8. Contributors..................................................18 Disclaimer of Validity.................................. 21
9. Acknowledgments...............................................18 Acknowledgment ........................................ 21
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
Acknowledgment...................................................21
1. Introduction 1. Introduction
The Generalized Multi-Protocol Label Switching (GMPLS) suite of The Generalized Multi-Protocol Label Switching (GMPLS) suite of
protocols allows for the automated control of different switching protocols allows for the automated control of different switching
technologies including Synchronous Optical Network (SONET), technologies including Synchronous Optical Network (SONET)[ANSI-
Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN) T1.105], Synchronous Digital Hierarchy (SDH)[ITU-T-G.707], Optical
and Plesiochronous Digital Hierarchy (PDH). This document describes Transport Network (OTN)[ITU-T-G.709] and Plesiochronous Digital
extensions to RSVP-TE to support the Virtual Concatenation (VCAT) Hierarchy (PDH)[ITU-T-G.704]. This document describes extensions to
layer 1 inverse multiplexing mechanism that has been standardized for RSVP-TE to support the Virtual Concatenation (VCAT) layer 1 inverse
SONET, SDH, OTN and PDH technologies along with its companion Link multiplexing mechanism that has been standardized for SONET, SDH, OTN
Capacity Adjustment Scheme (LCAS). and PDH [ITU-T-G.7043] technologies along with its companion Link
Capacity Adjustment Scheme (LCAS) [ITU-T-G.7042].
VCAT is a TDM oriented byte striping inverse multiplexing method that VCAT is a TDM oriented byte striping inverse multiplexing method that
works with a wide range of existing and emerging TDM framed signals, works with a wide range of existing and emerging TDM framed signals,
including very high bit rate OTN and SDH/SONET signals. Other than including very high bit rate OTN and SDH/SONET signals. Other than
member signal skew compensation this layer 1 inverse multiplexing member signal skew compensation this layer 1 inverse multiplexing
mechanism adds minimal additional signal delay. VCAT enables the mechanism adds minimal additional signal delay. VCAT enables the
selection of an optimal signal bandwidth (size), extraction of selection of an optimal signal bandwidth (size), extraction of
bandwidth from a mesh network, and, when combined with LCAS, hitless bandwidth from a mesh network, and, when combined with LCAS, hitless
dynamic resizing of bandwidth and fast graceful degradation in the dynamic resizing of bandwidth and fast graceful degradation in the
presence of network faults. To take full advantage of VCAT/LCAS presence of network faults. To take full advantage of VCAT/LCAS
functionality extensions to GMPLS signaling are given that enable the functionality extensions to GMPLS signaling are given that enable the
setup of diversely routed circuits that are members of the same VCAT setup of diversely routed circuits that are members of the same VCAT
group. group. Note that the scope of the document is limited to scenarios
where all member signals of a VCAT group are controlled using
2. Revision History mechanisms defined in this document and related RFCs. Scenarios where
a subset of member signals are controlled by a mangement plane or
2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-07 proprietary control plane are outside the scope of this document.
None. Needed to refresh the expired draft.
2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-05 and -06
Used the CALL_ATTRIBUTES Object from [MLN-Ext] rather than defining a
new CALL_DATA object.
2.3. 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.4. 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.5. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02
Grammar and punctuation fixes. Updated references with newly
published RFCs.
2.6. 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.
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.7. 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 2. VCAT/LCAS Scenarios and Specific Requirements
There are a number of specific requirements for the support of There are a number of specific requirements for the support of
VCAT/LCAS in GMPLS that can be derived from the carriers' VCAT/LCAS in GMPLS that can be derived from the carriers'
application-specific demands for the use of VCAT/LCAS and from the application-specific demands for the use of VCAT/LCAS and from the
flexible nature of VCAT/LCAS. These are set out in the following flexible nature of VCAT/LCAS. These are set out in the following
section. section.
3.1. VCAT/LCAS Interface Capabilities 2.1. VCAT/LCAS Interface Capabilities
In general, an LSR can be ingress/egress of one or more VCAT groups. In general, an LSR can be ingress/egress of one or more VCAT groups.
VCAT and LCAS are interface capabilities. An LSR may have, for VCAT and LCAS are interface capabilities. An LSR may have, for
example, VCAT-capable interfaces that are not LCAS-capable. It may example, VCAT-capable interfaces that are not LCAS-capable. It may
at the same time have interfaces that are neither VCAT nor LCAS- at the same time have interfaces that are neither VCAT nor LCAS-
capable. capable.
3.2. Member Signal Configuration Scenarios 2.2. Member Signal Configuration Scenarios
We list in this section the different scenarios. Here we use the We list in this section the different scenarios. Here we use the
term "VCG" to refer to the entire VCAT group and the terminology term "VCG" to refer to the entire VCAT group and the terminology
"set" and "subset" to refer to the collection of potential VCAT group "set" and "subset" to refer to the collection of potential VCAT group
member signals. member signals. It should be noted that the scope of these scenarios
is limited to situations where all member signals are controlled
using mechanisms defined in this document.
Fixed, co-routed: A fixed bandwidth VCG, transported over a co-routed o Fixed, co-routed: A fixed bandwidth VCG, transported over a co-
set of member signals. This is the case where the intended routed set of member signals. This is the case where the intended
bandwidth of the VCG does not change and all member signals follow bandwidth of the VCG does not change and all member signals follow
the same route to minimize differential delay. The intent here is the same route to minimize differential delay. The intent here is
the capability to allocate an amount of bandwidth close to that the capability to allocate an amount of bandwidth close to that
required at the client layer. required at the client layer.
Fixed, diversely routed: A fixed bandwidth VCG, transported over at o Fixed, diversely routed: A fixed bandwidth VCG, transported over
least two diversely routed subsets of member signals. In this at least two diversely routed subsets of member signals. In this
case, the subsets are link-disjoint over at least one link of the case, the subsets are link-disjoint over at least one link of the
route. The intent here is more efficient use of network route. The intent here is more efficient use of network
resources, e.g., no unique route has the required bandwidth. resources, e.g., no unique route has the required bandwidth.
Fixed, member sharing: A fixed bandwidth VCG, transported over a set o Fixed, member sharing: A fixed bandwidth VCG, transported over a
of member signals that are allocated from a common pool of set of member signals that are allocated from a common pool of
available member signals without requiring member connection available member signals without requiring member connection
teardown and setup. teardown and setup. This document only covers the case where this
pool of "potential" member signals has been established via
mechanisms defined in this document. Note that by the nature of
VCAT a member signal can only belong to one VCG at a time. To be
used in a different VCG a signal must first be removed from any
VCG to which it may belong.
Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or o Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or
decreased via the addition or removal of member signals), decreased via the addition or removal of member signals),
transported over a co-routed set of members. The intent here is transported over a co-routed set of members. The intent here is
dynamic resizing and resilience of bandwidth. dynamic resizing and resilience of bandwidth.
Dynamic, diversely routed: A dynamic VCG (bandwidth can be increased o Dynamic, diversely routed: A dynamic VCG (bandwidth can be
or decreased via the addition or removal of member signals), increased or decreased via the addition or removal of member
transported over at least two diversely routed subsets of member signals), transported over at least two diversely routed subsets
signals. The intent here is efficient use of network resources, of member signals. The intent here is efficient use of network
dynamic resizing and resilience of bandwidth. resources, dynamic resizing and resilience of bandwidth.
Dynamic, member sharing: A dynamic bandwidth VCG, transported over a o Dynamic, member sharing: A dynamic bandwidth VCG, transported over
set of member signals that are allocated from a common pool of a set of member signals that are allocated from a common pool of
available member signals without requiring member connection available member signals without requiring member connection
teardown and setup. teardown and setup.
3.3. VCAT Operation With or Without LCAS 2.3. VCAT Operation With or Without LCAS
VCAT capabilities may be present with or without the presence of VCAT capabilities may be present with or without the presence of
LCAS. The use of LCAS is beneficial to the provision of services, LCAS. The use of LCAS is beneficial to the provision of services,
but in the absence of LCAS, VCAT is still a valid technique. but in the absence of LCAS, VCAT is still a valid technique.
Therefore GMPLS mechanisms for the operation of VCAT are REQUIRED for Therefore GMPLS mechanisms for the operation of VCAT are REQUIRED for
both the case where LCAS is available and the case where it is not both the case where LCAS is available and the case where it is not
available. The GMPLS procedures for the two cases SHOULD be available. The GMPLS procedures for the two cases SHOULD be
identical. identical.
GMPLS signaling for LCAS-capable interfaces MUST support all o GMPLS signaling for LCAS-capable interfaces MUST support all
scenarios of section 3.2. with no loss of traffic. scenarios of section 2.2. with no loss of traffic.
GMPLS signaling for non-LCAS-capable interfaces MUST support only the o GMPLS signaling for non-LCAS-capable interfaces MUST support only
"fixed" scenarios of section 3.2. the "fixed" scenarios of section 2.2.
To provide for these requirements GMPLS signaling MUST carry the To provide for these requirements GMPLS signaling MUST carry the
following information on behalf of the VCAT endpoints: following information on behalf of the VCAT endpoints:
The type of the member signal that the VCG will contain, e.g., VC-3, oThe type of the member signal that the VCG will contain, e.g.,
VC-4, etc. VC-3, VC-4, etc.
The total number of members to be in the VCG. This provides the oThe total number of members to be in the VCG. This provides the
endpoints in both the LCAS and non-LCAS case with information on endpoints in both the LCAS and non-LCAS case with information
which to accept or reject the request, and in the non-LCAS case on which to accept or reject the request, and in the non-LCAS
will let the receiving endpoint know when all members of the VCG case will let the receiving endpoint know when all members of
have been established. the VCG have been established.
Identification of the VCG and its associated members. This provides oIdentification of the VCG and its associated members. This
information that allows the endpoints to differentiate multiple provides information that allows the endpoints to
VCGs and to tell what members (LSPs) to associate with a differentiate multiple VCGs and to tell what members (LSPs)
particular VCG. to associate with a particular VCG.
3.4. VCGs and VCG Members 2.4. VCGs and VCG Members
VCG members (server layer connections) may be set up prior to their o VCG members (server layer connections) may be set up prior to
use in a VCG. their use in a VCG.
VCG members (server layer connections) may exist after their o VCG members (server layer connections) may exist after their
corresponding VCG has been removed. corresponding VCG has been removed.
The signaling solution SHOULD provide a mechanism to support the The signaling solution SHOULD provide a mechanism to support the
previous scenarios. However, it is not required that arbitrarily previous scenarios. However, it is not required that arbitrarily
created server layer connections be supported in the above scenarios. created server layer connections be supported in the above scenarios,
i.e., connections established without following the procedures of
this document.
4. GMPLS Mechanisms in Support of VCGs 3. VCAT Data and Control Plane Concepts
We describe in this section the signaling mechanisms that already In the next two sections we describe the signaling mechanisms that
exist in GMPLS using RSVP-TE [RFC3473] and [RFC4328], and the already exist in GMPLS using RSVP-TE [RFC3473] and [RFC4328], and the
extensions needed to completely support the requirements of section extensions needed to completely support the requirements of section
3. 2.
When utilizing GMPLS with VCAT/LCAS we utilize a number of control When utilizing GMPLS with VCAT/LCAS we utilize a number of control
and data plane concepts that we describe below. and data plane concepts that we describe below.
VCG member -- This is an individual data plane signal of one of the 1. VCG member -- This is an individual data plane signal of one of the
permitted SDH, SONET, OTN or PDH signal types. permitted SDH, SONET, OTN or PDH signal types.
Co-signaled member set -- One or more VCG members (or potential 2. Co-signaled member set -- One or more VCG members (or potential
members) set up via the same control plane signaling exchange. Note members) set up via the same control plane signaling exchange. Note
that all members in a co-signaled set follow the same route. 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 3. Co-routed member set - One or more VCG members that follow the same
route. Although VCG members may follow the same path, this does not route. Although VCG members may follow the same path, this does not
imply that they were co-signaled. imply that they were co-signaled.
Data plane LSP -- for our purposes here, this is equivalent to an 4. Data plane LSP -- for our purposes here, this is equivalent to an
individual VCG member. individual VCG member.
Control plane LSP -- A control plane entity that can control multiple 5. Control plane LSP -- A control plane entity that can control
data plane LSPs. For our purposes here this is equivalent to our multiple data plane LSPs. For our purposes here this is equivalent
co-signaled member set. to our co-signaled member set.
Section 4.1 is included for informational purposes only. It Section 4. is included for informational purposes only. It describes
describes existing GMPLS procedures that support a single VCG existing GMPLS procedures that support a single VCG composed of a
composed of a single co-signaled member set. single co-signaled member set.
Section 4.2 describes new procedures to support VCGs composed of more Section 5. describes new procedures to support VCGs composed of more
than one co-signaled member sets. This includes the important than one co-signaled member sets. This includes the important
application of a VCG composed of diversely routed members. Where application of a VCG composed of diversely routed members. Where
possible it reuses applicable existing procedures from section 4.1. possible it reuses applicable existing procedures from section 4.
4.1. VCGs Composed of a Single Co-Signaled Member Set
Note that this section is for informational purposes only. 4. VCGs Composed of a Single Co-Signaled Member Set (One LSP)
The existing GMPLS signaling protocols support a VCG composed of a The existing GMPLS signaling protocols support a VCG composed of a
single co-signaled member set. Setup using the NVC field is explained single co-signaled member set. Setup using the NVC field is explained
in section 2.1 of [RFC4606]. In this case, one (single) control in section 2.1 of [RFC4606]. In this case, one (single) control
plane LSP is used in support of the VCG. plane LSP is used in support of the VCG. As such, this section does
not define or modify and procedures and is only included for
informative purposes.
There are two options for setting up the VCG, depending on hardware There are two options for setting up the VCG, depending on hardware
capability, or management preferences: one-shot setup and incremental capability, or management preferences: one-shot setup and incremental
setup. setup.
The following sections explain the procedure based on an example of The following sections explain the procedure based on an example of
setting up a VC-4-7v SDH VCAT group (corresponding to an STS-3c-7v setting up a VC-4-7v SDH VCAT group (corresponding to an STS-3c-7v
SONET VCAT group). SONET VCAT group).
4.1.1. One-shot VCG Setup with Co-Signaled Members 4.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 This section describes establishment of an LSP that supports all VCG
chosen (6 for VC-4/STS-3c_SPE). The value of NVC is then set to 7. members as part of the initial LSP establishment. To establish such
and LSP, an RSVP-TE Path message is used with the following
parameters.
A Multiplier Transform greater than 1 (say N>1) is used if the The traffic parameter's elementary signal is chosen (6 for VC-4/STS-
operator wants to set up N VCAT groups that will belong to, and be 3c_SPE). The value of NVC is then set to 7.
assigned to, one LSP.
SDH or SONET labels in turn have to be assigned for each member of SDH or SONET labels in turn have to be assigned for each member of
the VCG and concatenated to form a single Generalized Label the VCG and concatenated to form a single Generalized Label
constructed as an ordered list of 32-bit timeslot identifiers of the constructed as an ordered list of 32-bit timeslot identifiers of the
same format as TDM labels. [RFC4606] requires that the order of the same format as TDM labels. [RFC4606] requires that the order of the
labels reflect the order of the payloads to concatenate, and not the labels reflect the order of the payloads to concatenate, and not the
physical order of time-slots. physical order of time-slots.
4.1.2. Incremental VCG Setup with Co-Signaled Members 4.2. Incremental VCG Setup with Co-Signaled Members
In some cases, it may be necessary or desirable to set up the VCG In some cases, it may be necessary or desirable to set up the VCG
members individually, or to add group members to an existing group. members individually, or to add group members to an existing group.
One example of this need is when the hardware that supports VCAT can One example of this need is when the hardware that supports VCAT can
only add VCAT elements one at a time or cannot automatically match only add VCAT elements one at a time or cannot automatically match
the elements at the ingress and egress for the purposes of inverse the elements at the ingress and egress for the purposes of inverse
multiplexing. Serial or incremental setup solves this problem. multiplexing. Serial or incremental setup solves this problem.
In order to accomplish incremental setup an iterative process is used In order to accomplish incremental setup an iterative process is used
skipping to change at page 10, line 5 skipping to change at page 8, line 28
Label (in the Path or Resv message). A node that receives a Path Label (in the Path or Resv message). A node that receives a Path
message that contains changed fields will process the full Path message that contains changed fields will process the full Path
message and, based on the new value of NVC, it will add a component message and, based on the new value of NVC, it will add a component
signal to the VCAT group, and switch the new timeslot based on the signal to the VCAT group, and switch the new timeslot based on the
new label information. new label information.
Following the addition of the new label to the LSP, LCAS may be used Following the addition of the new label to the LSP, LCAS may be used
in-band to add the new label into the existing VCAT group. LCAS in-band to add the new label into the existing VCAT group. LCAS
signaling for this function is described in [ITU-T-G.7042]. signaling for this function is described in [ITU-T-G.7042].
4.1.3. Procedure for VCG Reduction by Removing a Member 4.3. Procedure for VCG Reduction by Removing a Member
The procedure to remove a component signal is similar to that used to The procedure to remove a component signal is similar to that used to
add components as described in Section 4.1.2. The LCAS in-band add components as described in Section 4.1.2. The LCAS in-band
signaling step is taken first to take the component out of service signaling step is taken first to take the component out of service
from the group. LCAS signaling is described in [ITU-T-G.7042]. from the group. LCAS signaling is described in [ITU-T-G.7042].
In this case, the NVC value is decremented by 1 and the timeslot In this case, the NVC value is decremented by 1 and the timeslot
identifier for the dropped component is removed from the ordered identifier for the dropped component is removed from the ordered
list in the Generalized Label. list in the Generalized Label.
skipping to change at page 10, line 28 skipping to change at page 9, line 5
multiplexing procedure of VCAT and result in the teardown of the multiplexing procedure of VCAT and result in the teardown of the
whole group. So, this is a feature that only LCAS-capable VCAT whole group. So, this is a feature that only LCAS-capable VCAT
interfaces can support without management intervention at the end interfaces can support without management intervention at the end
points. points.
Note also that a VCG member can be temporary removed from the VCG due 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 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- take appropriate actions to adjust the VCG as described in [ITU-T-
G.7042]. G.7042].
4.1.4. Removing Multiple VCG Members in One Shot 4.4. Removing Multiple VCG Members in One Shot
The procedure is similar to 4.1.3. In this case, the NVC value is The procedure is similar to 4.3. In this case, the NVC value is
changed to the new value and all relevant timeslot identifiers for changed to the new value and all relevant timeslot identifiers for
the components to be torn down are removed from the ordered list in the components to be torn down are removed from the ordered list in
the Generalized Label. This procedure is also not supported for the Generalized Label. This procedure is also not supported for
VCAT-only interfaces without management intervention as removing one VCAT-only interfaces without management intervention as removing one
or more components of the VCG will tear down the whole group. or more components of the VCG will tear down the whole group.
4.1.5. Teardown of Whole VCG 4.5. Teardown of Whole VCG
The entire LSP is deleted in a single step (i.e., all components are The entire LSP is deleted in a single step (i.e., all components are
removed in one go) using deletion procedures of [RFC3473]. removed in one go) using deletion procedures of [RFC3473].
4.2. VCGs Composed of Multiple Co-Signaled Member Sets 5. VCGs Composed of Multiple Co-Signaled Member Sets(Multiple LSPs)
The motivation for 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 comes from the requirement to support VCGs with diversely routed
members. The initial GMPLS specification did not support diversely members. The initial GMPLS specification did not support diversely
routed signals using the NVC construct. In fact, [RFC4606] says: routed signals using the NVC construct. In fact, [RFC4606] says:
[...] The standard definition for virtual concatenation allows [...] The standard definition for virtual concatenation allows
each virtual concatenation components to travel over diverse each virtual concatenation components to travel over diverse
paths. Within GMPLS, virtual concatenation components must paths. Within GMPLS, virtual concatenation components must
travel over the same (component) link if they are part of the travel over the same (component) link if they are part of the
skipping to change at page 11, line 16 skipping to change at page 9, line 41
(component) link. Note however, that the routing of components (component) link. Note however, that the routing of components
on different paths is indeed equivalent to establishing on different paths is indeed equivalent to establishing
different LSPs, each one having its own route. Several LSPs different LSPs, each one having its own route. Several LSPs
can be initiated and terminated between the same nodes and can be initiated and terminated between the same nodes and
their corresponding components can then be associated together their corresponding components can then be associated together
(i.e., virtually concatenated). (i.e., virtually concatenated).
The setup of diversely routed VCG members requires multiple co- The setup of diversely routed VCG members requires multiple co-
signaled VCG member sets, i.e., multiple control plane LSPs. signaled VCG member sets, i.e., multiple control plane LSPs.
To support a VCG with multiple co-signaled VCG members sets requires The support of a VCG with multiple co-signaled VCG members sets
being able to identify separate control plane LSPs with a single VCG requires being able to identify separate sets of control plane LSPs
and exchange information pertaining to the VCG as a whole. This is with a single VCG and exchange information pertaining to the VCG as a
very similar to the "Call" concept described in [RFC4974]. We can whole. This is provided by using the call procedures and extensions
think of our VCAT/LCAS connection, e.g., our VCG, as a higher layer described in [RFC4974]. The VCG is a higher layer service that makes
service that makes use of multiple lower layer (server) connections use of one or more calls (VCAT calls) to associate control plane LSPs
that are controlled by one or more control plane LSPs. in support of VCG server layer connections (VCG members) in the data
plane. Note, the trigger for the VCG (by management plane or client
layer) is outside the scope of this document.
4.2.1. Signaled VCG Layer Information In addition, by supporting the identification of a VCG and VCAT call
identification, support can be provided for the member sharing
scenarios, i.e. by explicitly separating the VCG ID from the VCAT
call ID. Note that per [RFC4974], LSPs (connections) cannot be moved
from one call to another, hence to support member sharing, the
procedures in this document provide support by moving call(s) and
their associated LSPs from one VCG to another. Figure 1 below
illustrates these relationships, however, note, VCAT calls can exist
independently of a VCG (for connection pre-establishment) as will be
described later in this document.
When a VCG is composed of multiple co-signaled member sets, none of +-------+ +-------------+ +-------+ +------------+
the control plane LSP's signaling information can contain information | |1 n| |1 n| |1 n| Data Plane |
pertinent to the entire VCG. In this section we give a list of | VCG |<>----| VCAT Call |<>----| LSP |<>----| Connection |
information that should be communicated at what we define as the VCG | | | | | | |(co-routed) |
Call layer, i.e., between the VCG signaling endpoints. To +-------+ +-------------+ +-------+ +------------+
accommodate this information additional objects or TLVs are Figure 1 Figure 1. Conceptual containment relationship between VCG,
VCAT calls, control plane LSPs, and data plane connections.
5.1. Signaled VCG Service Layer Information
In this section, we provide a list of information that will be
communicated at the VCG level, i.e., between the VCG signaling
endpoints. When a VCG is composed of multiple co-signaled member
sets, none of the individual LSP's control plane signaling
information can contain information pertinent to the entire VCG. To
accommodate this information, additional objects or TLVs are
incorporated into the Notify message as it is described for use in incorporated into the Notify message as it is described for use in
call signaling in [RFC4974]. call signaling in [RFC4974]. The Notify message is a targeted message
and does not need to follow the path of LSPs through the network i.e.
there is no dependency on the member signaling for establishing the
VCAT call and does not preclude the use of external call managers as
described in [RFC4974].
VCG Call setup information signaled via the Notify message with the VCG Call setup is signaled with a new CALL_ATTRIBUTES object TLV
Call management bit (C-bit) set: containing the following information:
1. Signal Type 1. Signal Type
2. Number of VCG Members 2. Number of VCG Members
3. LCAS requirements: 3. LCAS requirements:
a. LCAS required a. LCAS required
b. LCAS desired b. LCAS desired
skipping to change at page 11, line 47 skipping to change at page 11, line 4
1. Signal Type 1. Signal Type
2. Number of VCG Members 2. Number of VCG Members
3. LCAS requirements: 3. LCAS requirements:
a. LCAS required a. LCAS required
b. LCAS desired b. LCAS desired
c. LCAS not desired (but acceptable) c. LCAS not desired (but acceptable)
4. VCG Identifier - Used to identify a particular VCG separately 4. VCG Identifier - Used to identify a particular VCG separately
from the call ID so that call members can be reused with from the call ID so that call members can be reused with
different VCGs per the requirements for member sharing and the different VCGs per the requirements for member sharing and the
requirements of section 3.4. requirements of section 2.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
4.4. VCAT CALL_ATTRIBUTES TLV Object 5.2. VCAT TLV
For use in the CALL_ATTRIBUTES object in Notify messages we define In RFC4974 the general mechanisms and procedures for communicating
the following VCAT related TLV: call information via Notify messages is defined. In [MLN-Ext] the
CALL_ATTRIBUTES object is defined for the conveyance of call related
information during call establishment and updates. We define a new
CALL_ATTRIBUTES object VCAT TLV for use in the CALL_ATTRIBUTES object
as follows:
0 1 2 3 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 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 | | Type = TBA | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Members | | Signal Type | Number of Members |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCAS Req | Action | VCG ID | | LCAS Req | Action | VCG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where Type is TBD, and the Length = 12 bytes. Type, as defined in [MLN-Ext]. This field MUST be set to TBA (by
IANA).
Signal Type can take the following values and MUST never change over Length, as defined in [MLN-Ext]. This field MUST be set to 12.
the lifetime of a VCG:
Signal Type: 16 bits
This field can take the following values and MUST never change over
the lifetime of a VCG [ANSI-T1-105, ITU-T-G.707, ITU-T-G.709, ITU-
T-G.7043]:
Value Type (Elementary Signal) Value Type (Elementary Signal)
----- ------------------------ ----- ------------------------
1 VT1.5 SPE / VC-11 1 VT1.5 SPE / VC-11
2 VT2 SPE / VC-12 2 VT2 SPE / VC-12
3 STS-1 SPE / VC-3 3 STS-1 SPE / VC-3
4 STS-3c SPE / VC-4 4 STS-3c SPE / VC-4
11 OPU1 (i.e., 2.5 Gbit/s 11 OPU1 (i.e., 2.5 Gbit/s
12 OPU2 (i.e., 10 Gbit/s) 12 OPU2 (i.e., 10 Gbit/s)
13 OPU3 (i.e., 40 Gbit/s) 13 OPU3 (i.e., 40 Gbit/s)
21 T1 (i.e., 1.544 Mbps) 21 T1 (i.e., 1.544 Mbps)
22 E1 (i.e., 2.048 Mbps) 22 E1 (i.e., 2.048 Mbps)
23 E3 (i.e., 34.368 Mbps) 23 E3 (i.e., 34.368 Mbps)
24 T3 (i.e., 44.736 Mbps) 24 T3 (i.e., 44.736 Mbps)
Number of Members is a non-negative integer that indicates the total Number of Members: 16 bits
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 This field is an unsigned integer that MUST indicate the total
the life of a VCG: number of members in the VCG (not just the call). This field MUST
be changed (over the life of the VCG) to indicate the current
number of members.
LCAS Required: 8 bits
This field can take the following values and MUST NOT change over
the life of a VCG:
Value Meaning Value Meaning
----- --------------------------------- ----- ---------------------------------
0 LCAS required 0 LCAS required
1 LCAS desired 1 LCAS desired
2 LCAS not desired (but acceptable) 2 LCAS not desired (but acceptable)
Action is used to indicate the relationship between the call and the Action: 8 bits
VCG and takes the following values.
This field is used to indicate the relationship between the call
and the VCG and has the following values.
Value Meaning Value Meaning
----- --------------------------------- ----- ---------------------------------
0 No VCG ID (set up call prior to VCG creation) 0 No VCG ID (set up call prior to VCG creation)
1 New VCG for Call 1 New VCG for Call
2 No Change in VCG ID (number of members may have changed) 2 No Change in VCG ID (number of members may have changed)
3 Remove VCG from Call 3 Remove VCG from Call
VCG ID: A 16 bit non-negative integer used to identify a particular VCG Identifier (ID): 16 bit
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_ATTRIBUTES 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_ATTRIBUTES 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).
The following internal ordering is used when increasing the bandwidth
of a VCG in a hitless fashion when LCAS is supported:
A CALL_ATTRIBUTES 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" This field carries an unsigned integer that is used to identify a
the new VCG member(s). particular VCG within a session. The value of the field MUST NOT
change over the lifetime of a VCG but MAY change over the lifetime
of a call.
The following mechanisms can be used to decrease the bandwidth of a 5.3. Procedures for Multiple Co-signaled Member Sets
VCG.
LSPs are removed from a VCAT Call associated with a VCG (Action = 2). The creation of a VCG based on multiple co-signaled member sets
requires the establishment of at least one VCAT layer call. VCAT
layer calls and related LSPs (connections) MUST follow the the
Procedures in Support of Calls and Connections as defined in
[RFC4974] with the addition of the inclusion of a CALL_ATTRIBUTES
object containing the VCAT TLV. Multiple VCAT layer calls per VCG are
not required to support co-signaled member sets, but are needed to
support certain member sharing scenario.
A VCG association is removed from existing VCAT call containing LSPs The remainder of this section provides specific procedures related to
(Action = 3). VCG signaling. The procedures of [RFC4974] are only modified as
discussed in this section.
In general the following internal ordering is used when decreasing 5.3.1. Setting up a new VCAT call and VCG Simultaneously
the bandwidth of a VCG in a hitless fashion when LCAS is supported:
1. A CALL_ATTRIBUTES Object containing a VCAT TLV indicating the new To simultaneously set up a VCAT call and identify it with an
number of members after the proposed decrease is sent. If an error associated VCG, a CALL_ATTRIBUTES object containing the VCAT TLV MUST
is returned from the receiver the VCG state remains the same prior be included at the time of call setup. The VCAT TLV Action field
to the attempted decrease. MUST be set to 1, which indicates that this is a new VCG for this
call. LSPs MUST then be added to the call until the number of
members reaches the number specified in the VCAT TLV.
2. The LCAS entity is instructed by the endpoints to "deactivate" the 5.3.2. Setting up a VCAT call + LSPs without a VCG
members to be removed from the VCG.
3. Either: (a) An LSP is removed from a call associated with a VCG; To provide for pre-establishment of the server layer connections for
or (b) All the LSPs of a call are removed from the VCG when the a VCG a VCAT call MAY be established without an associated VCG
association between the VCG and VCAT call is removed. identifier. In fact, to provide for the member sharing scenario, a
pool of VCAT calls with associated connections (LSPs) can be
established, and 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 a call MUST NOT contain members used in more than one VCG.
Note that when LCAS is not used or unavailable the VCG will be in an To establish a VCAT call with no VCG association, a CALL_ATTRIBUTES
unknown state between the time the VCG call level information is object containing the VCAT TLV MUST be included at the time of call
updated and the actual data plane LSPs are added or removed. Note setup. The VCAT TLV Action field MUST be set to 0, which indicates
that the incremental setup procedure of section 4.1.2. can be applied that this is a VCAT call without an associated VCG. LSPs can then be
to any of the above procedures. 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. Note that signal types can never
be mixed in a VCG and hence a VCAT call contains only one signal
type.
4.5.1. Setting up a VCAT call and VCG 5.3.3. Associating an existing VCAT call with a new VCG
Arguably the most common operation will be simultaneously setting up A VCAT call that is not otherwise associated with a VCG may be
a VCAT call and its associated VCG at the same time. To do this when associated with a VCG. To establish such an association a Notify
one sets up a new VCAT call in the VCAT TLV one sets Action = 1 message MUST be sent with a CALL_ATTRIBUTES object containing a VCAT
indicating that this is a new VCG for this call. LSPs would then be TLV. The TLV's Action field MUST be set to 1 the VCG Identifier field
added to the call until the number of members reaches the number MUST be set to correspond to the VCG. The number of members field
specified in the VCAT TLV. MUST equal the sum of all LSPs associated with the VCG. The Notify
message is otherwise formatted and processed as defined under Call
Establishment in [RFC4974]. 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 VCG ID this limit should be
checked. Likewise the sender of a message with a change in VCG ID
MUST be prepared to receive an error response. Again, any error in a
VCG may result in the failure of the complete VCG.
Note that any other bandwidth modifications to the VCG whether up or 5.3.4. Removing the association between a call and VCG
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 reuse the server layer connections in a call in another VCG, the
current association between the call and a VCG MUST first be removed.
To do this, a Notify message MUST be sent with a CALL_ATTRIBUTES
object containing a VCAT TLV. The Action field of the TLV MUST be
set to 3 (Remove VCG from Call). The VCG ID field is ignored and MAY
be set to any value. The number of members field is also ignored and
MAY be set to any value. When the association between a VCG and all
existing calls has been removed then the VCG is considered torn down.
The Notify message is otherwise formatted and processed as defined
under Call Establishment in [RFC4974].
To provide for pre-establishment of the server layer connections for 5.3.5. VCG Bandwidth modification
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 The following cases may occur when increasing or decreasing the
new VCAT call in the VCAT TLV one sets Action = 0 indicating that bandwidth of a VCG:
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 1. LSPs are added to or, in the case of a decrease, removed from a
VCAT Call already associated with a VCG.
Given a VCAT call without an associated VCG such as that set up in 2. An existing VCAT call, and corresponding LSPs, is associated
section 4.5.2. one associates it with a VCG as follows. In the VCAT with a VCG or, in the case of a decrease, has its association
call a new notify message is sent with a CALL_ATTRIBUTES object with removed. Note that in the increase case, the call MUST NOT have
a VCAT TLV with Action = 1, a VCG ID, and the correct number of VCG any existing association with a 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 The following internal ordering SHOULD be used when modifying the
may be limited and hence on reception of any message with a change of bandwidth of a VCG in a hitless fashion when LCAS is supported:
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 1. In both cases, prior to any other change, a Notify message MUST
be sent with a CALL_ATTRIBUTES object containing a VCAT TLV for each
of the existing VCAT calls associated with the VCG. The Action field
of the TLV MUST be set to 2. The VCG ID field MUST be set to match
the VCG. The number of members field MUST equal the sum of all LSPs
that are anticipated to be associated with the VCG after the
bandwidth change. The Notify message is otherwise formatted and
processed as defined under Call Establishment in [RFC4974]. If an
error is encountered while processing any of the Notify messages, the
number of members is reverted to the pre-change value and the
increase is aborted. The reverted number of members MUST be signaled
in a Notify message as described above. Any failures encountered in
processing these Notify messages are ignored.
To reuse the server layer connections in a call in another VCG one 2. Once the existing calls have successfully been notified of the
first needs to remove the current association between the call and a new number of members in the VCG, the bandwidth change can be made.
VCG. To do this, in the VCAT call a new notify message is sent with In the case of a decrease, the internal LCAS entity at the endpoints
a CALL_ATTRIBUTES object with a VCAT TLV with Action = 3, a VCG ID, MUST "deactivate" the VCG member(s). The next step is dependent on
and the correct number of VCG members specified based on removing all the two cases defined above. In the first case defined above, the
of the calls data plane LSPs from the VCG as members. When the bandwidth change is made by adding (in the case of increase) or
association between a VCG and all existing calls has been removed removing (in the case of a decrease) LSPs to the VCAT call per the
then the VCG is considered torn down. procedures defined in [RFC4974]. In the second case, the same
procedure defined in Section 5.3.3. is followed for an increase, and
the procedure defined in Section 5.3.4. is followed for an decrease.
In the case of an increase, after the bandwidth change is
successfully made, the internal LCAS entity at the endpoints MUST
"activate" the new VCG member(s).
5. Error Conditions and Codes 6. Error Conditions and Codes
VCAT Call and member LSP setup can be denied for various reasons. VCAT Call and member LSP setup can be denied for various reasons. In
Below is a list of error conditions that can be encountered during addition to the call procedures and related error codes described in
these procedures. These fall under RSVP error code TBD. [RFC4974], below is a list of error conditions that can be
encountered during the procedures as defined in this document. These
fall under RSVP error code TBA.
These can occur when setting up a VCAT call or associating a VCG with These can occur when setting up a VCAT call or associating a VCG with
a VCAT call. a VCAT call.
Error Subcode Error Value
------------------------------------ -------- ------------------------------------ --------
VCG signal type not Supported 1 VCG signal type not Supported 1
LCAS option not supported 2 LCAS option not supported 2
Max number of VCGs exceeded 3 Max number of VCGs exceeded 3
Max number of VCG members exceeded 4 Max number of VCG members exceeded 4
LSP Type incompatible with VCAT call 5 LSP Type incompatible with VCAT call 5
6. IANA Considerations Any failure in call or LSP establishment MUST be treated as a failure
of the VCG as a whole and MAY trigger the calls and LSPs associated
with the VCG being deleted.
This document requests from IANA the assignment of a new TLV for the 7. IANA Considerations
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.
7. Security Considerations 7.1. RSVP CALL_ATTRIBUTE TLV
IANA has made the following assignments in the "Class Names, Class
Numbers, and Class Types" section of the "RSVP PARAMETERS" registry
located at http://www.iana.org/assignments/rsvp-parameters.
We request that IANA make assignments from the CALL_ATTRIBUTES TLV
[MLN-Ext] portions of this registry.
This document introduces a new CALL_ATTRIBUTES TLV
TLV Value Name Reference
--------- ---------------------- ---------
TBD (2) VCAT_TLV [This I-D]
7.2. RSVP Error Codes and Error Values
A new RSVP Error Code and new Error Values are introduced. We
request IANA make assignments from the "RSVP Parameters" registry
using the sub-registry "Error Codes and Globally-Defined Error Value
Sub-Codes".
o Error Codes:
- VCAT Call Management (value TBD)
o Error Values:
Meaning Value
------------------------------------ --------
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
8. Security Considerations
This document introduces a specific use of the Notify message and This document introduces a specific use of the Notify message and
admin status object for GMPLS signaling as originally specified in admin status object for GMPLS signaling as originally specified in
[RFC4974]. It does not introduce any new signaling messages, nor [RFC4974]. It does not introduce any new signaling messages, nor
change the relationship between LSRs that are adjacent in the control change the relationship between LSRs that are adjacent in the control
plane. The call information associated with diversely routed control plane. The call information associated with diversely routed control
plane LSPs, in the event of an interception may indicate that there 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 are members of the same VCAT group that take a different route and
may indicate to an interceptor that the VCG call desires increased may indicate to an interceptor that the VCG call desires increased
reliability. reliability.
Otherwise, this document does not introduce any additional security 9. Contributors
considerations.
8. Contributors
Wataru Imajuku (NTT) Wataru Imajuku (NTT)
1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847 1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847
Japan Japan
Phone +81-46-859-4315 Phone +81-46-859-4315
Email: imajuku.wataru@lab.ntt.co.jp Email: imajuku.wataru@lab.ntt.co.jp
Julien Meuric Julien Meuric
France Telecom France Telecom
skipping to change at page 18, line 32 skipping to change at page 18, line 32
Lyndon Ong Lyndon Ong
Ciena Ciena
PO Box 308 PO Box 308
Cupertino, CA 95015 Cupertino, CA 95015
United States of America United States of America
Phone: +1 408 705 2978 Phone: +1 408 705 2978
Email: lyong@ciena.com Email: lyong@ciena.com
9. Acknowledgments 10. Acknowledgments
The authors would like to thank Adrian Farrel, Maarten Vissers, The authors would like to thank Adrian Farrel, Maarten Vissers,
Trevor Wilson, Evelyne Roch, Vijay Pandian, Fred Gruman, Dan Li, Trevor Wilson, Evelyne Roch, Vijay Pandian, Fred Gruman, Dan Li,
Stephen Shew, Jonathan Saddler and Dieter Beller for extensive Stephen Shew, Jonathan Saddler and Dieter Beller for extensive
reviews and contributions to this draft. reviews and contributions to this draft.
10. References 11. References
10.1. Normative References 11.1. Normative References
[MLN-Ext] Papadimitriou, D., Vigoureux M., Shiomoto, K. [MLN-Ext] Papadimitriou, D., Vigoureux M., Shiomoto, K.
Brungard, D., Le Roux, JL., "Generalized Multi- Brungard, D., Le Roux, JL., "Generalized Multi-
Protocol Label Switching (GMPLS) Protocol Extensions Protocol Label Switching (GMPLS) Protocol Extensions
for Multi-Layer and Multi-Region Networks (MLN/MRN)", for Multi-Layer and Multi-Region Networks (MLN/MRN)",
work in progress: draft-ietf-ccamp-gmpls-mln- work in progress: draft-ietf-ccamp-gmpls-mln-
extensions-03.txt, October, 2008. extensions-09.txt, October, 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label [RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol
skipping to change at page 19, line 39 skipping to change at page 19, line 39
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, December Digital Hierarchy (SDH) Control", RFC 4606, December
2005. 2005.
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS
(GMPLS) RSVP-TE Signaling Extensions in Support of (GMPLS) RSVP-TE Signaling Extensions in Support of
Calls", RFC 4974, August 2007. Calls", RFC 4974, August 2007.
10.2. Informative References 11.2. Informative References
[ANSI-T1.105] American National Standards Institute, "Synchronous [ANSI-T1.105] American National Standards Institute, "Synchronous
Optical Network (SONET) - Basic Description including Optical Network (SONET) - Basic Description including
Multiplex Structure, Rates, and Formats", ANSI T1.105- Multiplex Structure, Rates, and Formats", ANSI T1.105-
2001, May 2001. 2001, May 2001.
[ITU-T-G.7042] International Telecommunications Union, "Link Capacity [ITU-T-G.7042] International Telecommunications Union, "Link Capacity
Adjustment Scheme (LCAS) for Virtual Concatenated Adjustment Scheme (LCAS) for Virtual Concatenated
Signals", ITU-T Recommendation G.7042, March 2006. Signals", ITU-T Recommendation G.7042, March 2006.
[ITU-T-G.7043] International Telecommunications Union, "Virtual [ITU-T-G.7043] International Telecommunications Union, "Virtual
Concatenation of Plesiochronous Digital Hierarchy Concatenation of Plesiochronous Digital Hierarchy
(PDH) Signals", ITU-T Recommendation G.7043, July (PDH) Signals", ITU-T Recommendation G.7043, July
2004. 2004.
[ITU-T-G.704] International Telecommunications Union, " Synchronous
frame structures used at 1544, 6312, 2048, 8448 and 44
736 kbit/s hierarchical levels", ITU-T Recommendation
G.704, October 1998.
[ITU-T-G.707] International Telecommunications Union, "Network Node [ITU-T-G.707] International Telecommunications Union, "Network Node
Interface for the Synchronous Digital Hierarchy Interface for the Synchronous Digital Hierarchy
(SDH)", ITU-T Recommendation G.707, December 2003. (SDH)", ITU-T Recommendation G.707, December 2003.
[ITU-T-G.709] International Telecommunications Union, "Interfaces [ITU-T-G.709] International Telecommunications Union, "Interfaces
for the Optical Transport Network (OTN)", ITU-T for the Optical Transport Network (OTN)", ITU-T
Recommendation G.709, March 2003. Recommendation G.709, March 2003.
Author's Addresses Author's Addresses
 End of changes. 100 change blocks. 
371 lines changed or deleted 372 lines changed or added

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