draft-ietf-ccamp-gmpls-vcat-lcas-13.txt   rfc6344.txt 
CCAMP Working Group G. Bernstein (ed.)
Internet Draft Grotto Networking
Updates: 4606 (if approved) D. Caviglia
Category: Standards Track Ericsson
Expires: November 2011 R. Rabbat
Google
H. van Helvoort
Huawei
May 4, 2011
Operating Virtual Concatenation (VCAT) and the Link Capacity Internet Engineering Task Force (IETF) G. Bernstein, Ed.
Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Request for Comments: 6344 Grotto Networking
Switching (GMPLS) Updates: 4606 D. Caviglia
Category: Standards Track Ericsson
draft-ietf-ccamp-gmpls-vcat-lcas-13.txt ISSN: 2070-1721 R. Rabbat
Google
H. van Helvoort
Huawei
August 2011
Status of this Memo Operating Virtual Concatenation (VCAT) and
the Link Capacity Adjustment Scheme (LCAS)
with Generalized Multi-Protocol Label Switching (GMPLS)
This Internet-Draft is submitted to IETF in full conformance with Abstract
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document describes requirements for, and the use of, the
Task Force (IETF), its areas, and its working groups. Note that Generalized Multi-Protocol Label Switching (GMPLS) control plane in
other groups may also distribute working documents as Internet- support of the Virtual Concatenation (VCAT) layer 1 inverse
Drafts. multiplexing data plane mechanism and its companion Link Capacity
Adjustment Scheme (LCAS). LCAS 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. This document updates RFC 4606 by making
modifications to the procedures for supporting virtual concatenation.
Internet-Drafts are draft documents valid for a maximum of six Status of This Memo
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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 4, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6344.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
This document describes requirements for, and use of, the
Generalized Multi-Protocol Label Switching (GMPLS) control plane in
support of the Virtual Concatenation (VCAT) layer 1 inverse
multiplexing data plane 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. This document updates RFC 4606 by
making modifications to the procedures for supporting virtual
concatenation.
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 Table of Contents
1. Introduction...................................................3 1. Introduction ....................................................3
2. VCAT/LCAS Scenarios and Specific Requirements..................4 1.1. Conventions Used in This Document ..........................4
2.1. VCAT/LCAS Interface Capabilities..........................4 2. VCAT/LCAS Scenarios and Specific Requirements ...................4
2.2. Member Signal Configuration Scenarios.....................4 2.1. VCAT/LCAS Interface Capabilities ...........................4
2.3. VCAT Operation With or Without LCAS.......................5 2.2. Member Signal Configuration Scenarios ......................5
2.4. VCGs and VCG Members......................................6 2.3. VCAT Operation with or without LCAS ........................6
3. VCAT Data and Control Plane Concepts...........................6 2.4. VCGs and VCG Members .......................................7
4. VCGs Composed of a Single Member Set (One LSP).................7 3. VCAT Data and Control Plane Concepts ............................7
4.1. One-shot VCG Setup........................................8 4. VCGs Composed of a Single Member Set (One LSP) ..................8
4.2. Incremental VCG Setup.....................................8 4.1. One-Shot VCG Setup .........................................8
4.3. Procedure for VCG Reduction by Removing a Member..........9 4.2. Incremental VCG Setup ......................................9
4.4. Removing Multiple VCG Members in One Shot.................9 4.3. Procedure for VCG Reduction by Removing a Member ...........9
4.5. Teardown of Whole VCG.....................................9 4.4. Removing Multiple VCG Members in One Shot .................10
5. VCGs Composed of Multiple Member Sets (Multiple LSPs).........10 4.5. Teardown of Whole VCG .....................................10
5.1. Signaled VCG Service Layer Information...................11 5. VCGs Composed of Multiple Member Sets (Multiple LSPs) ..........10
5.2. CALL ATTRIBUTES Object VCAT TLV..........................11 5.1. Signaled VCG Service Layer Information ....................11
5.3. Procedures for Multiple Member Sets......................13 5.2. CALL_ATTRIBUTES Object VCAT TLV ...........................12
5.3.1. Setting up a new VCAT call and VCG Simultaneously...14 5.3. Procedures for Multiple Member Sets .......................14
5.3.2. Setting up a VCAT call + LSPs without a VCG.........14 5.3.1. Setting Up a New VCAT Call and VCG Simultaneously ..14
5.3.3. Associating an existing VCAT call with a new VCG....14 5.3.2. Setting Up a VCAT Call and LSPs without a VCG ......14
5.3.4. Removing the association between a call and VCG.....15 5.3.3. Associating an Existing VCAT Call with a New VCG ...15
5.3.5. VCG Bandwidth modification..........................15 5.3.4. Removing the Association between a Call and VCG ....15
6. Error Conditions and Codes....................................16 5.3.5. VCG Bandwidth Modification .........................15
7. IANA Considerations...........................................16 6. Error Conditions and Codes .....................................16
7.1. RSVP CALL_ATTRIBUTE TLV..................................16 7. IANA Considerations ............................................17
7.2. RSVP Error Codes and Error Values........................17 7.1. RSVP Call Attribute TLV ...................................17
8. Security Considerations.......................................18 7.2. RSVP Error Codes and Error Values .........................17
9. Contributors..................................................19 7.3. VCAT Elementary Signal Registry ...........................18
10. Acknowledgments..............................................19 7.4. VCAT VCG Operation Actions ................................18
11. References...................................................20 8. Security Considerations ........................................18
11.1. Normative References....................................20 9. Contributors ...................................................19
11.2. Informative References..................................20 10. Acknowledgments ...............................................19
Authors' Addresses...............................................21 11. References ....................................................19
Intellectual Property Statement..................................22 11.1. Normative References .....................................19
Disclaimer of Validity...........................................22 11.2. Informative References ...................................20
Acknowledgment.........................Error! Bookmark not defined.
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)[ANSI- technologies, including the Synchronous Optical Network (SONET),
T1.105], Synchronous Digital Hierarchy (SDH)[ITU-T-G.707], Optical Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN),
Transport Network (OTN)[ITU-T-G.709] and Plesiochronous Digital and Plesiochronous Digital Hierarchy (PDH). This document updates
Hierarchy (PDH)[ITU-T-G.704]. This document updates the procedures the procedures described in [RFC4606] to allow supporting additional
of [RFC4606] to allow supporting additional applications of the applications of the Virtual Concatenation (VCAT) layer 1 inverse
Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism multiplexing mechanism that has been standardized for SONET, SDH,
that has been standardized for SONET, SDH, OTN and PDH [ITU-T-G.707, OTN, and PDH [ANSI-T1.105] [ITU-T-G.707] [ITU-T-G.709] [ITU-T-G.7043]
ITU-T-G.709, and ITU-T-G.7043] technologies along with its companion technologies, along with its companion Link Capacity Adjustment
Link Capacity Adjustment Scheme (LCAS) [ITU-T-G.7042]. Scheme (LCAS) [ITU-T-G.7042].
VCAT is a time division multiplexing (TDM) oriented byte striping VCAT is a time-division multiplexing (TDM)-oriented byte striping
inverse multiplexing method that works with a wide range of existing inverse multiplexing method that works with a wide range of existing
and emerging TDM framed signals, including very high bit rate OTN and emerging TDM framed signals, including very-high-bit-rate OTN and
and SDH/SONET signals. VCAT enables the selection of an optimal SDH/SONET signals. VCAT enables the selection of an optimal signal
signal server bandwidth (size) utilizing a group of server signals server bandwidth (size) utilizing a group of server signals and
and provides for efficient use of bandwidth in a mesh network. When provides for efficient use of bandwidth in a mesh network. When
combined with LCAS, hitless dynamic resizing of bandwidth and fast combined with LCAS, hitless dynamic resizing of bandwidth and fast
graceful degradation in the presence of network faults can be graceful degradation in the presence of network faults can be
supported. To take full advantage of VCAT/LCAS functionality, supported. To take full advantage of VCAT/LCAS functionality,
additional extensions to GMPLS signaling are needed that enable the additional extensions to GMPLS signaling are needed that enable the
setup of diversely routed signals that are members of the same VCAT setup of diversely routed signals that are members of the same VCAT
group. Note that the scope of this document is limited to scenarios group. Note that the scope of this document is limited to scenarios
where all member signals of a VCAT group are controlled using where all member signals of a VCAT group are controlled using
mechanisms defined in this document and related RFCs. Scenarios mechanisms defined in this document and related RFCs. Scenarios
where a subset of member signals are controlled by a management where a subset of member signals are controlled by a management plane
plane or a proprietary control plane are outside the scope of this or a proprietary control plane are outside the scope of this
document. document.
2. VCAT/LCAS Scenarios and Specific Requirements 1.1. 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].
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'
applications for the use of VCAT/LCAS. These are set out in the applications for the use of VCAT/LCAS. These are set out in the
following section. following section.
2.1. VCAT/LCAS Interface Capabilities 2.1. VCAT/LCAS Interface Capabilities
In general, an label switched router (LSR) can be ingress/egress of In general, a label switched router (LSR) can be an ingress/egress of
one or more VCAT groups. VCAT and LCAS are data plane interface one or more VCAT groups. VCAT and LCAS are data plane interface
capabilities. An LSR may have, for example, VCAT-capable interfaces 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 not LCAS-capable. It may at the same time have interfaces
that are neither VCAT nor LCAS-capable. that are neither VCAT-capable nor LCAS-capable.
2.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
[ITU-T-G.707] term "VCG" to refer to the VCAT group and the [ITU-T-G.707] term "VCG" to refer to the VCAT group and the
terminology "set" and "subset" to refer to the subdivision of the terminology "set" and "subset" to refer to the subdivision of the
group and the individual VCAT group member signals. As noted above, group and the individual VCAT group member signals. As noted above,
the scope of these scenarios is limited to scenarios where all the scope of these scenarios is limited to scenarios where all member
member signals are controlled using mechanisms defined in this signals are controlled using mechanisms defined in this document.
document.
The scenarios listed here are dependent on the terms "co-routed" and The scenarios listed here are dependent on the terms "co-routed" and
"diversely routed". In the context of this document, "co-routed" "diversely routed". In the context of this document, "co-routed"
refers to a set of VCAT signals that all traverse the same sequence refers to a set of VCAT signals that all traverse the same sequence
of switching nodes. Furthermore, a co-routed set of signals between of switching nodes. Furthermore, a co-routed set of signals between
any pair of adjacent nodes utilize a set of links that have similar any pair of adjacent nodes utilizes a set of links that have similar
delay characteristics. Thus, "diversely routed" means a set of delay characteristics. Thus, "diversely routed" means a set of
signals that are not classed as "co-routed". signals that are not classed as "co-routed".
Fixed, co-routed: A fixed bandwidth VCG, transported over a co- Fixed, co-routed: A fixed-bandwidth VCG, transported over a co-routed
routed set of member signals. This is the case where the set of member signals. This is the case where the intended
intended bandwidth of the VCG does not change and all member bandwidth of the VCG does not change and all member signals follow
signals follow the same route to minimize differential delay. the same route to minimize differential delay. The application
The application here is the capability to allocate an amount of here is the capability to allocate an amount of bandwidth close to
bandwidth close to that required at the client layer. that required at the client layer.
Fixed, diversely routed: A fixed bandwidth VCG, transported over at Fixed, diversely routed: A fixed-bandwidth VCG, transported over at
least two diversely routed subsets of member signals. In this 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 application here is more efficient use of network route. The application 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 Fixed, member sharing: A fixed-bandwidth VCG, transported over a set
of member signals that are allocated from a common pool of 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. This document only covers the case where this teardown and setup. This document only covers the case where this
pool of "potential" member signals has been established via pool of "potential" member signals has been established via
mechanisms defined in this document. Member signals need not be mechanisms defined in this document. Member signals need not be
co-routed or be guaranteed to be diversely routed. Note that by co-routed or be guaranteed to be diversely routed. Note that by
the nature of VCAT, a member signal can only belong to one VCG at 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 a time. To be used in a different VCG, a signal must first be
removed from any VCG to which it may belong. removed from any VCG to which it may belong.
Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or 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 application transported over a co-routed set of members. The application here
here is dynamic resizing and resilience of bandwidth. is dynamic resizing and resilience of bandwidth.
Dynamic, diversely routed: A dynamic VCG (bandwidth can be increased Dynamic, diversely routed: A dynamic VCG (bandwidth can be increased
or decreased via the addition or removal of member signals), or decreased via the addition or removal of member signals),
transported over at least two diversely routed subsets of member transported over at least two diversely routed subsets of member
signals. The application here is efficient use of network signals. The application here is efficient use of network
resources, dynamic resizing and resilience of bandwidth. resources, dynamic resizing, and resilience of bandwidth.
Dynamic, member sharing: A dynamic bandwidth VCG, transported over a Dynamic, member sharing: A dynamic-bandwidth VCG, transported over a
set 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.
2.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 in the provisioning of flexible LCAS. The use of LCAS is beneficial in the provisioning of flexible
bandwidth services, but in the absence of LCAS, VCAT is still a bandwidth services, but in the absence of LCAS, VCAT is still a valid
valid technique. Therefore GMPLS mechanisms for the operation of technique. Therefore, GMPLS mechanisms for the operation of VCAT are
VCAT are REQUIRED for both the case where LCAS is available and the REQUIRED for both the case where LCAS is available and the case where
case where it is not available. The GMPLS procedures for the two it is not available. The GMPLS procedures for the two cases SHOULD
cases SHOULD be identical. be identical.
. GMPLS signaling for LCAS-capable interfaces MUST support all o GMPLS signaling for LCAS-capable interfaces MUST support all
scenarios of section 2.2. with no loss of traffic. scenarios described in Section 2.2 with no loss of traffic.
. GMPLS signaling for non-LCAS-capable interfaces MUST support o GMPLS signaling for non-LCAS-capable interfaces MUST support the
the "fixed" scenarios of section 2.2. "fixed" scenarios described in 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., o The type of the member signal that the VCG will contain, e.g.,
VC-3, VC-4, etc. VC-3, VC-4, etc.
. The total number of members to be in the VCG. This provides the o 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 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 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 will let the receiving endpoint know when all members of the VCG
have been established. have been established.
. Identification of the VCG and its associated members. This o Identification of the VCG and its associated members. This
provides information that allows the endpoints to differentiate provides information that allows the endpoints to differentiate
multiple VCGs and to tell what members - label switched paths multiple VCGs and to tell what member, label switched paths
(LSPs)- to associate with a particular VCG. (LSPs), to associate with a particular VCG.
2.4. VCGs and VCG Members 2.4. VCGs and VCG Members
The signaling solution SHOULD provide a mechanism to support these The signaling solution SHOULD provide a mechanism to support these
scenarios: scenarios:
. VCG members (server layer connections) may be set up prior to o VCG members (server-layer connections) may be set up prior to
their 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.
However, it is not required that any arbitrarily created server However, it is not required that any arbitrarily created server-layer
layer connection be supported in the above scenarios, i.e., connection be supported in the above scenarios, i.e., connections
connections established without following the procedures of this established without following the procedures described in this
document. document.
3. VCAT Data and Control Plane Concepts 3. VCAT Data and Control Plane Concepts
When utilizing GMPLS with VCAT/LCAS, we use a number of control and When utilizing GMPLS with VCAT/LCAS, we use a number of control and
data plane concepts described below. data plane concepts described below.
VCG -- This is the group of data plane server layer signals used to VCG - This is the group of data plane server-layer signals used to
provide the bandwidth for the virtual concatenation link provide the bandwidth for the virtual concatenation link
connection through a network ([G7042]). connection through a network ([ITU-T-G.7042]).
VCG member -- This is an individual data plane server layer signal VCG member - This is an individual data plane server-layer signal
that belongs to a VCG ([G7042]). that belongs to a VCG ([ITU-T-G.7042]).
Member set -- One or more VCG members (or potential members) set up Member set - One or more VCG members (or potential members) set up
via the same control plane signaling exchange. Note that all via the same control plane signaling exchange. Note that all
members in a member set follow the same route. members in a member set follow the same route.
Data plane LSP -- This is an individual VCG member. Data plane LSP - This is an individual VCG member.
Control plane LSP -- A control plane entity that can control multiple Control plane LSP - A control plane entity that can control multiple
data plane LSPs. For our purposes here, this is equivalent to the data plane LSPs. For our purposes here, this is equivalent to the
member set. member set.
Call - A control plane mechanism for providing association between Call - A control plane mechanism for providing association between
endpoints and possibly key transit points. endpoints and possibly key transit points.
4. VCGs Composed of a Single Member Set (One LSP) 4. VCGs Composed of a Single Member Set (One LSP)
In this section and the next section, we will describe the In this section and the next section, we will describe the procedures
procedures for supporting the applications described in Section 2. for supporting the applications described in Section 2.
This section describes the support of a single VCG composed of a This section describes the support of a single VCG composed of a
single member set (in support of the fixed, co-routed application single member set (in support of the fixed, co-routed application and
and the dynamic, co-routed application) using existing GMPLS the dynamic, co-routed application) using existing GMPLS procedures
procedures [RFC4606]. Note that this section is included for [RFC4606]. Note that this section is included for informational
informational purposes only and does not modify [RFC4606]. It is purposes only and does not modify [RFC4606]. It is provided to show
provided to show how the existing GMPLS procedures may be used. how the existing GMPLS procedures may be used. [RFC4606] provides
[RFC4606] provides the normative definition for GMPLS processing of the normative definition for GMPLS processing of VCGs composed of a
VCGs composed of a single member set, and in the event of any single member set, and in the event of any conflict between this
conflict between this section and that document, [RFC4606] takes section and that document, [RFC4606] takes precedence.
precedence.
The existing GMPLS signaling protocols support a VCG composed of a The existing GMPLS signaling protocols support a VCG composed of a
single member set. Setup using the number of virtual components single member set. Setup using the Number of Virtual Components
(NVC) field is explained in section 2.1 of [RFC4606]. In this case, (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. one (single) control plane LSP is used in support of the VCG.
There are two options for setting up the VCG, depending on policy There are two options for setting up the VCG, depending on policy
preferences: one-shot setup and incremental setup. preferences: one-shot setup and incremental 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) which is composed of 7 virtually concatenated VC- SONET VCAT group), which is composed of 7 virtually concatenated
4s (or STS-3c). VC-4s (or STS-3c).
4.1. One-shot VCG Setup 4.1. One-Shot VCG Setup
This section describes establishment of an LSP that supports all VCG This section describes establishment of an LSP that supports all VCG
members as part of the initial LSP establishment. To establish such members as part of the initial LSP establishment. To establish such
an LSP, an RSVP-TE Path message is sent containing the SONET/SDH an LSP, an RSVP-TE (Resource Reservation Protocol - Traffic
Traffic Parameters defined in [RFC4606]. In the case of this Engineering) Path message is sent containing the SONET/SDH traffic
example: parameters defined in [RFC4606]. In the case of this example:
. Elementary signal is set to 6 (for VC-4/STS-3c_SPE). o Elementary signal is set to 6 (for VC-4/STS-3c_SPE).
. NVC is set to 7 (number of members). o NVC is set to 7 (number of members).
. Per [RFC4606] a Multiplier Transform greater than 1 (say N>1) o Per [RFC4606], a Multiplier Transform greater than 1 (say N > 1)
may be used if the operator wants to set up N identical VCAT may be used if the operator wants to set up N identical VCAT
groups (for the same LSP). groups (for the same LSP).
. SDH or SONET labels have to be assigned for each member of the o SDH or SONET labels have to be assigned for each member of the VCG
VCG and concatenated to form a single Generalized Label and concatenated to form a single Generalized Label constructed as
constructed as an ordered list of 32-bit timeslot identifiers an ordered list of 32-bit timeslot identifiers of the same format
of the same format as TDM labels. [RFC4606] requires that the as TDM labels. [RFC4606] requires that the order of the labels
order of the labels reflect the order of the payloads to reflect the order of the payloads to concatenate, and not the
concatenate, and not the physical order of time-slots. physical order of timeslots.
. Refer to [RFC4606] for other traffic parameter settings. o Refer to [RFC4606] for other traffic parameter settings.
4.2. Incremental VCG Setup 4.2. Incremental VCG Setup
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 local policy requires that VCAT One example of this need is when the local policy requires that VCAT
can only add VCAT members one at a time or cannot automatically can only add VCAT members one at a time or cannot automatically match
match the members at the ingress and egress for the purposes of the members at the ingress and egress for the purposes of inverse
inverse multiplexing. Serial or incremental setup solves this multiplexing. Serial or incremental setup solves this problem.
problem.
In order to accomplish incremental setup, an iterative process is In order to accomplish incremental setup, an iterative process is
used to add group members. For each iteration, NVC is incremented used to add group members. For each iteration, NVC is incremented up
up to the final value required. A successful iteration consists of to the final value required. A successful iteration consists of the
the successful completion of Path and Resv signaling. At first, NVC successful completion of Path and Resv signaling. At first, NVC = 1,
= 1 and the label includes just one timeslot identifier and the label includes just one timeslot identifier.
At each of the next iterations, NVC is set to (NVC +1), one more At each of the next iterations, NVC is set to (NVC + 1), and one more
timeslot identifier is added to the ordered list in the Generalized timeslot identifier is added to the ordered list in the Generalized
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 (identifying the new member) Following the addition of the new label (identifying the new member)
to the LSP, in the data plane, LCAS may be used to add the new to the LSP, in the data plane, LCAS may be used to add the new member
member at the end points into the existing VCAT group. LCAS (data at the endpoints into the existing VCAT group. LCAS (data plane)
plane) signaling is described in [ITU-T-G.7042]. signaling is described in [ITU-T-G.7042].
4.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 The procedure to remove a component signal is similar to that used to
to add components as described in Section 4. 2. In the data plane, add components as described in Section 4.2. In the data plane, LCAS
LCAS signaling is used first to take the component out of service signaling is used first to take the component out of service from the
from the group. LCAS signaling is described in [ITU-T-G.7042]. 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
list in the Generalized Label. in the Generalized Label.
Note that for interfaces that are not LCAS-capable, removing one Note that for interfaces that are not LCAS-capable, removing one
component of the VCG will result in failure detection of the member component of the VCG will result in failure detection of the member
at the end point and failure of the whole group (per ITU-T at the endpoint and failure of the whole group. So, this is a
definition). So, this is a feature that only LCAS-capable VCAT feature that only LCAS-capable VCAT interfaces can support without
interfaces can support without management intervention at the end management intervention at the endpoints.
points.
Note if using LCAS, a VCG member can be temporarily removed from the Note that if using LCAS, a VCG member can be temporarily removed from
VCG due to a failure of the component signal. The LCAS data plane the VCG due to a failure of the component signal. The LCAS data
signaling will take appropriate actions to adjust the VCG as plane signaling will take appropriate actions to adjust the VCG as
described in [ITU-T-G.7042]. described in [ITU-T-G.7042].
4.4. Removing Multiple VCG Members in One Shot 4.4. Removing Multiple VCG Members in One Shot
The procedure is similar to 4.3. In this case, the NVC value is The procedure is similar to that described in Section 4.3. In this
changed to the new value and all relevant timeslot identifiers for case, the NVC value is changed to the new value, and all relevant
the components to be torn down are removed from the ordered list in timeslot identifiers for the components to be torn down are removed
the Generalized Label. This procedure is also not supported for from the ordered list in the Generalized Label. This procedure is
VCAT-only interfaces without management intervention as removing one also not supported for VCAT-only interfaces without management
or more components of the VCG will tear down the whole group. intervention, as removing one or more components of the VCG will tear
down the whole group.
4.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 the deletion procedures described in
[RFC3473].
5. VCGs Composed of Multiple Member Sets (Multiple LSPs) 5. VCGs Composed of Multiple Member Sets (Multiple LSPs)
The motivation for VCGs composed of multiple member sets comes from The motivation for VCGs composed of multiple member sets comes from
the requirement to support VCGs with diversely routed members. The the requirement to support VCGs with diversely routed members. The
initial GMPLS specification did not support diversely routed signals initial GMPLS specification did not support diversely routed signals
using the NVC construct. [RFC4606] says: using the NVC construct. [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 component to travel over diverse paths.
paths. Within GMPLS, virtual concatenation components must Within GMPLS, virtual concatenation components must travel over
travel over the same (component) link if they are part of the the same (component) link if they are part of the same LSP. This
same LSP. This is due to the way that labels are bound to a is due to the way that labels are bound to a (component) link.
(component) link. Note however, that the routing of Note, however, that the routing of components on different paths
components on different paths is indeed equivalent to is indeed equivalent to establishing different LSPs, each one
establishing different LSPs, each one having its own route. having its own route. Several LSPs can be initiated and
Several LSPs can be initiated and terminated between the same terminated between the same nodes, and their corresponding
nodes and their corresponding components can then be components can then be associated together (i.e., virtually
associated together (i.e., virtually concatenated). concatenated).
The setup of diversely routed VCG members requires multiple VCG The setup of diversely routed VCG members requires multiple VCG
member sets, i.e., multiple control plane LSPs. member sets, i.e., multiple control plane LSPs.
The support of a VCG with multiple VCG members sets requires being The support of a VCG with multiple VCG member sets requires being
able to identify separate sets of control plane LSPs with a single able to identify separate sets of control plane LSPs with a single
VCG and exchange information pertaining to the VCG as a whole VCG and exchange information pertaining to the VCG as a whole between
between the endpoints. This document updates the procedures of the endpoints. This document updates the procedures described in
[RFC4606] to provide this capability by using the call procedures [RFC4606] to provide this capability by using the call procedures and
and extensions described in [RFC4974]. The VCG makes use of one or extensions described in [RFC4974]. The VCG makes use of one or more
more calls (VCAT calls) to associate control plane LSPs in support calls (VCAT calls) to associate control plane LSPs in support of VCG
of VCG server layer connections (VCG members) in the data plane. server-layer connections (VCG members) in the data plane. Note that
Note, the trigger for the VCG (by management plane or client layer) the trigger for the VCG (by management plane or client layer) is
is outside the scope of this document. These procedures provide for outside the scope of this document. These procedures provide for
autonomy of the client layer and server layer with respect to their autonomy of the client layer and server layer with respect to their
management. management.
In addition, by supporting the identification of a VCG (VCG ID) and In addition, by supporting the identification of a VCG (VCG ID) and
VCAT call identification (VCAT Call ID), support can be provided for VCAT call identification (VCAT Call ID), support can be provided for
the member sharing scenarios, i.e. by explicitly separating the VCG the member-sharing scenarios, i.e., by explicitly separating the VCG
ID from the VCAT call ID. Note that per [RFC4974], LSPs ID from the VCAT call ID. Note that per [RFC4974], LSPs
(connections) cannot be moved from one call to another, hence to (connections) cannot be moved from one call to another; hence, to
support member sharing, the procedures in this document provide support member sharing, the procedures in this document provide
support by moving call(s) and their associated LSPs from one VCG to support by moving call(s) and their associated LSPs from one VCG to
another. Figure 1 below illustrates these relationships, however, another. Figure 1 below illustrates these relationships; however,
note, VCAT calls can exist independently of a VCG (for connection note that VCAT calls can exist independently of a VCG (for connection
pre-establishment) as will be described later in this document. pre-establishment), as will be described later in this document.
+-------+ +-------------+ +-------+ +------------+ +-------+ +-------------+ +-------+ +------------+
| |1 n| |1 n| |1 n| Data Plane | | |1 n| |1 n| |1 n| Data Plane |
| VCG |<>----| VCAT Call |<>----| LSP |<>----| Connection | | VCG |<>----| VCAT Call |<>----| LSP |<>----| Connection |
| | | | | | |(co-routed) | | | | | | | |(co-routed) |
+-------+ +-------------+ +-------+ +------------+ +-------+ +-------------+ +-------+ +------------+
. Conceptual containment relationship between VCG, VCAT
calls, control plane LSPs, and data plane connections.
5.1. Signaled VCG Service Layer Information Figure 1. Conceptual Containment Relationship between VCG, VCAT
Calls, Control Plane LSPs, and Data Plane Connections
In this section, we provide a list of information that will be 5.1. Signaled VCG Service Layer Information
communicated at the VCG level, i.e., between the VCG signaling
endpoints using the call procedures of [RFC4974]. To accommodate In this section, we provide information that will be communicated at
the VCG information, a new TLV is defined in this document for the the VCG level, i.e., between the VCG signaling endpoints using the
CALL ATTRIBUTES Object [RFC6001] for use in the Notify message call procedures described in [RFC4974]. To accommodate the VCG
[RFC4974]. The Notify message is a targeted message and does not information, a new TLV is defined in this document for the
need to follow the path of LSPs through the network i.e. there is no CALL_ATTRIBUTES object [RFC6001] for use in the Notify message
dependency on the member signaling for establishing the VCAT call [RFC4974]. The Notify message is a targeted message and does not
and does not preclude the use of external call managers as described need to follow the path of LSPs through the network; i.e., there is
in [RFC4974]. no dependency on the member signaling for establishing the VCAT call,
and the use of external call managers as described in [RFC4974] is
not precluded.
The following information is needed: The following information is needed:
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 supported c. LCAS not supported
4. VCG Identifier - Used to identify a particular VCG separately 4. VCG Identifier - Used to identify a particular VCG separately from
from the call ID so that call members can be reused with the call ID so that call members can be reused with different VCGs
different VCGs per the requirements for member sharing and the per the requirements for member sharing and the requirements of
requirements of section 2.4. Section 2.4.
5.2. CALL ATTRIBUTES Object VCAT TLV 5.2. CALL_ATTRIBUTES Object VCAT TLV
This document defines a CALL_ATTRIBUTES object VCAT TLV for use in This document defines a CALL_ATTRIBUTES object VCAT TLV for use in
the CALL_ATTRIBUTES object [RFC6001] as follows: the CALL_ATTRIBUTES object [RFC6001] 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 = TBA | Length = 12 | | Type = 4 | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Members | | Signal Type | Number of Members |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LCR| Reserved | Action | VCG ID | |LCR| Reserved | Action | VCG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type, as defined in [RFC6001]. This field MUST be set to TBA (by Type, as defined in [RFC6001]. This field MUST be set to 2.
IANA).
Length, as defined in [RFC6001]. This field MUST be set to 12. Length, as defined in [RFC6001]. This field MUST be set to 12.
Signal Type: 16 bits Signal Type: 16 bits
The signal types can never be mixed in a VCG (per ITU-T The signal types can never be mixed in a VCG; hence, a VCAT call
definition) and hence a VCAT call contains only one signal type. contains only one signal type. This field can take the following
This field can take the following values and MUST never change values and MUST never change over the lifetime of a VCG
over the lifetime of a VCG [ANSI-T1-105, ITU-T-G.707, ITU-T-G.709, [ANSI-T1.105] [ITU-T-G.707] [ITU-T-G.709] [ITU-T-G.7043]:
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 ODU1 (i.e., 2.5 Gbit/s 11 ODU1 (i.e., 2.5 Gbit/s)
12 ODU2 (i.e., 10 Gbit/s) 12 ODU2 (i.e., 10 Gbit/s)
13 ODU3 (i.e., 40 Gbit/s) 13 ODU3 (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: 16 bits Number of Members: 16 bits
This field is an unsigned integer that MUST indicate the total This field is an unsigned integer that MUST indicate the total
number of members in the VCG (not just the call). This field MUST 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 be changed (over the life of the VCG) to indicate the current
number of members. number of members.
LCR (LCAS Required): 2 bits LCR (LCAS Required): 2 bits
This field can take the following values and MUST NOT change over This field can take the following values and MUST NOT change over
the life of a VCG: the life of a VCG:
Value Meaning Value Meaning
----- --------------------------------- ----- ------------------
0 LCAS required 0 LCAS required
1 LCAS desired 1 LCAS desired
2 LCAS not supported 2 LCAS not supported
Action: 8 bits Action: 8 bits
This field is used to indicate the relationship between the call This field is used to indicate the relationship between the call
and the VCG and has the following values. 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 Modification of number of members (No Change in VCG ID) 2 Modification of Number of Members (no change in VCG ID)
3 Remove VCG from Call 3 Remove VCG from Call
VCG Identifier (ID): 16 bit VCG Identifier (ID): 16 bits
This field carries an unsigned integer that is used to identify a This field carries an unsigned integer that is used to identify a
particular VCG within a session. The value of the field MUST NOT 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 change over the lifetime of a VCG but MAY change over the lifetime
of a call. of a call.
5.3. Procedures for Multiple Member Sets 5.3. Procedures for Multiple Member Sets
The creation of a VCG based on multiple member sets requires the The creation of a VCG based on multiple member sets requires the
establishment of at least one VCAT layer call. VCAT layer calls and establishment of at least one VCAT-layer call. VCAT-layer calls and
related LSPs (connections) MUST follow the procedures as defined in related LSPs (connections) MUST follow the procedures as defined in
[RFC4974] with the addition of the inclusion of a CALL_ATTRIBUTES [RFC4974], with the addition of the inclusion of a CALL_ATTRIBUTES
object containing the VCAT TLV. Multiple VCAT layer calls per VCG object containing the VCAT TLV. Multiple VCAT layer calls per VCG
are not required to support member sets, but are needed to support are not required to support member sets, but are needed to support
certain member sharing scenario. certain member-sharing scenarios.
The remainder of this section provides specific procedures related The remainder of this section provides specific procedures related to
to VCG signaling. The procedures of [RFC4974] are only modified as VCG signaling. The procedures described in [RFC4974] are only
discussed in this section. modified as discussed in this section.
When LCAS is supported, the data plane will add or decrease the When LCAS is supported, the data plane will add or decrease the
members per [G7042]. When LCAS is not supported across LSPs, the members per [ITU-T-G.7042]. When LCAS is not supported across LSPs,
data plane coordination across member sets, is outside the scope of the data plane coordination across member sets is outside the scope
this document. of this document.
5.3.1. Setting up a new VCAT call and VCG Simultaneously 5.3.1. Setting Up a New VCAT Call and VCG Simultaneously
To simultaneously set up a VCAT call and identify it with an To simultaneously set up a VCAT call and identify it with an
associated VCG, a CALL_ATTRIBUTES object containing the VCAT TLV associated VCG, a CALL_ATTRIBUTES object containing the VCAT TLV MUST
MUSTbe included in the Notify message at the time of call setup. be included in the Notify message at the time of call setup. The
The VCAT TLV Action field MUST be set to 1, which indicates that VCAT TLV Action field MUST be set to 1, which indicates that this is
this is a new VCG for this call. LSPs MUST then be added to the a new VCG for this call. LSPs MUST then be added to the call until
call until the number of members reaches the number specified in the the number of members reaches the number specified in the VCAT TLV.
VCAT TLV.
5.3.2. Setting up a VCAT call + LSPs without a VCG 5.3.2. Setting Up a VCAT Call and LSPs without a VCG
To provide for pre-establishment of the server layer connections for To provide for pre-establishment of the server-layer connections for
a VCG a VCAT call MAY be established without an associated VCG a VCG, a VCAT call MAY be established without an associated VCG
identifier. In fact, to provide for the member sharing scenario, a identifier. In fact, to provide for the member-sharing scenarios, a
pool of VCAT calls with associated connections (LSPs) can be pool of VCAT calls with associated connections (LSPs) can be
established, and then one or more of these calls (with accompanying established, and then one or more of these calls (with accompanying
connections) can be associated with a particular VCG (via the VCG connections) can be associated with a particular VCG (via the VCG
ID). Note that multiple calls can be associated with a single 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. but that a call MUST NOT contain members used in more than one VCG.
To establish a VCAT call with no VCG association, a CALL_ATTRIBUTES To establish a VCAT call with no VCG association, a CALL_ATTRIBUTES
object containing the VCAT TLV MUST be included at the time of call object containing the VCAT TLV MUST be included at the time of call
setup in the Notify message. The VCAT TLV Action field MUST be set setup in the Notify message. The VCAT TLV Action field MUST be set
to 0, which indicates that this is a VCAT call without an associated to 0, which indicates that this is a VCAT call without an associated
VCG. LSPs can then be added to the call. The number of members 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 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. reflects the intended number of members in a VCG and not in a call.
5.3.3. Associating an existing VCAT call with a new VCG 5.3.3. Associating an Existing VCAT Call with a New VCG
A VCAT call that is not otherwise associated with a VCG may be A VCAT call that is not otherwise associated with a VCG may be
associated with a VCG. To establish such an association a Notify associated with a VCG. To establish such an association, a Notify
message MUST be sent with a CALL_ATTRIBUTES object containing a VCAT message MUST be sent with a CALL_ATTRIBUTES object containing a
TLV. The TLV's Action field MUST be set to 1, the VCG Identifier VCAT TLV. The TLV's Action field MUST be set to 1, and the VCG
field MUST be set to correspond to the VCG. The number of members Identifier field MUST be set to correspond to the VCG. The Number of
field MUST equal the sum of all LSPs associated with the VCG. Note Members field MUST equal the sum of all LSPs associated with the VCG.
that the total number of VCGs supported by a node may be limited and Note that the total number of VCGs supported by a node may be
hence on reception of any message with a change of VCG ID this limit limited; hence, on reception of any message with a change of VCG ID,
should be checked. Likewise the sender of a message with a change in this limit should be checked. Likewise, the sender of a message with
VCG ID MUST be prepared to receive an error response. Again, any a change of VCG ID MUST be prepared to receive an error response.
error in a VCG may result in the failure of the complete VCG. Again, any error in a VCG may result in the failure of the
complete VCG.
5.3.4. Removing the association between a call and VCG 5.3.4. Removing the Association between a Call and VCG
To reuse the server layer connections in a call in another VCG, the To reuse the server-layer connections in a call in another VCG, the
current association between the call and a VCG MUST first be current association between the call and a VCG MUST first be removed.
removed. To do this, a Notify message MUST be sent with a To do this, a Notify message MUST be sent with a CALL_ATTRIBUTES
CALL_ATTRIBUTES object containing a VCAT TLV. The Action field of object containing a VCAT TLV. The Action field of the TLV MUST be
the TLV MUST be set to 3 (Remove VCG from Call). The VCG ID field is set to 3 (Remove VCG from Call). The VCG ID field is ignored and MAY
ignored and MAY be set to any value. The number of members field is be set to any value. The Number of Members field is also ignored and
also ignored and MAY be set to any value. When the association MAY be set to any value. When the association between a VCG and all
between a VCG and all existing calls has been removed then the VCG existing calls has been removed, then the VCG is considered torn
is considered torn down. down.
5.3.5. VCG Bandwidth modification 5.3.5. VCG Bandwidth Modification
The following cases may occur when increasing or decreasing the The following cases may occur when increasing or decreasing the
bandwidth of a VCG: bandwidth of a VCG:
1. LSPs are added to or, in the case of a decrease, removed from a 1. LSPs are added to or, in the case of a decrease, removed from a
VCAT Call already associated with a VCG. VCAT call already associated with a VCG.
2. An existing VCAT call, and corresponding LSPs, is associated 2. An existing VCAT call (and corresponding LSPs) is associated with
with a VCG or, in the case of a decrease, has its association a VCG or, in the case of a decrease, has its association removed.
removed. Note that in the increase case, the call MUST NOT have Note that in the case of an increase, the call MUST NOT have any
any existing association with a VCG. existing association with a VCG.
The following sequence SHOULD be used when modifying the bandwidth The following sequence SHOULD be used when modifying the bandwidth of
of a VCG: a VCG:
1. In both cases, prior to any other change, a Notify message MUST 1. In both cases, prior to any other change, a Notify message MUST be
be sent with a CALL_ATTRIBUTES object containing a VCAT TLV for each 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 existing VCAT calls associated with the VCG. The Action
of the TLV MUST be set to 2. The VCG ID field MUST be set to match field of the TLV MUST be set to 2. The VCG ID field MUST be set
the VCG. The number of members field MUST equal the sum of all LSPs to match the VCG. The Number of Members field MUST equal the sum
that are anticipated to be associated with the VCG after the of all LSPs that are anticipated to be associated with the VCG
bandwidth change. The Notify message is otherwise formatted and after the bandwidth change. The Notify message is otherwise
processed as defined under Call Establishment in [RFC4974]. If an formatted and processed to support call establishment as described
error is encountered while processing any of the Notify messages, the in [RFC4974]. If an error is encountered while processing any of
number of members is reverted to the pre-change value and the the Notify messages, the number of members is reverted to the
increase is aborted. The reverted number of members MUST be signaled pre-change value, and the increase is aborted. The reverted
in a Notify message as described above. Failures encountered in number of members MUST be signaled in a Notify message as
processing these Notify messages are handled per [RFC4974]. described above. Failures encountered in processing these Notify
messages are handled per [RFC4974].
2. Once the existing calls have successfully been notified of the 2. Once the existing calls have successfully been notified of the new
new number of members in the VCG, the bandwidth change can be made. number of members in the VCG, the bandwidth change can be made.
The next step is dependent on the two cases defined above. In the The next step is dependent on the two cases defined above. In the
first case defined above, the bandwidth change is made by adding (in first case defined above, the bandwidth change is made by adding
the case of increase) or removing (in the case of a decrease) LSPs (in the case of an increase) or removing (in the case of a
to the VCAT call per the procedures defined in [RFC4974]. In the decrease) LSPs to or from the VCAT call per the procedures defined
second case, the same procedure defined in Section 5.3.3. is in [RFC4974]. In the second case, the procedure defined in
followed for an increase, and the procedure defined in Section Section 5.3.3 is followed for an increase, and the procedure
5.3.4. is followed for a decrease. defined in Section 5.3.4 is followed for a decrease.
6. Error Conditions and Codes 6. Error Conditions and Codes
VCAT Call and member LSP setup can be denied for various reasons. In VCAT call and member LSP setup can be denied for various reasons. In
addition to the call procedures and related error codes described in addition to the call procedures and related error codes described in
[RFC4974], below is a list of error conditions that can be [RFC4974], below is a list of error conditions that can be
encountered during the procedures as defined in this document. These encountered while using the procedures defined in this document.
fall under RSVP error code TBA. These fall under RSVP error code 39.
These can occur when setting up a VCAT call or associating a VCG These can occur when setting up a VCAT call or associating a VCG with
with a VCAT call. a VCAT call.
Error Value 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
Unknown LCR (LCAS required) value 6 Unknown LCR (LCAS required) value 6
Unknown or unsupported ACTION 7 Unknown or unsupported ACTION 7
Any failure in call or LSP establishment MUST be treated as a Any failure in call or LSP establishment MUST be treated as a failure
failure of the VCG as a whole and MAY trigger the calls and LSPs of the VCG as a whole and MAY trigger the calls and LSPs associated
associated with the VCG being deleted. with the VCG being deleted.
7. IANA Considerations 7. IANA Considerations
7.1. RSVP CALL_ATTRIBUTE TLV 7.1. RSVP Call Attribute TLV
IANA has made the following assignments in the "Class Names, Class IANA has made the following assignments in the "Call Attributes TLV"
Numbers, and Class Types" section of the "RSVP PARAMETERS" registry section of the "RSVP PARAMETERS" registry available from
located at http://www.iana.org/assignments/rsvp-parameters. http://www.iana.org.
We request that IANA make assignments from the CALL_ATTRIBUTES TLV IANA has made assignments from the Call Attributes TLV [RFC6001]
[RFC6001] portions of this registry. portions of this registry.
This document introduces a new CALL_ATTRIBUTES TLV This document introduces a new Call Attributes TLV:
TLV Value Name Reference TLV Value Name Reference
--------- ---------------------- --------- --------- ---------------------- ---------
TBD VCAT_TLV This I-D 4 VCAT TLV [RFC6344]
7.2. RSVP Error Codes and Error Values 7.2. RSVP Error Codes and Error Values
A new RSVP Error Code and new Error Values are introduced. We A new RSVP Error Code and new Error Values are introduced. IANA
request IANA make assignments from the "RSVP Parameters" registry assigned the following from the "RSVP Parameters" registry using the
using the sub-registry "Error Codes and Globally-Defined Error Value sub-registry "Error Codes and Globally-Defined Error Value
Sub-Codes". Sub-Codes".
o Error Codes: o Error Codes:
- VCAT Call Management (value TBD) - VCAT Call Management (39)
o Error Values: o Error Values:
Meaning Value Meaning 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
Unknown LCR (LCAS required) value 6 Unknown LCR (LCAS required) value 6
Unknown or unsupported ACTION 7 Unknown or unsupported ACTION 7
7.3. VCAT Elementary Signal Registry 7.3. VCAT Elementary Signal Registry
IANA is requested to create a registry to track elementary signal IANA created a registry to track elementary signal types as defined
types as defined in Section 5.2. New allocations are by "IETF in Section 5.2. New allocations are by "IETF Review" [RFC5226].
Review" [RFC5226].
IANA is requested to track: IANA maintains the following information:
- Value - Value
- Type (Elementary Signal) - Type (Elementary Signal)
- RFC - RFC
The available range is 0 - 65535
The registry should be initially populated with the values shown in The available range is 0 - 65535.
Section 5.2 of this document. Value 0 should be marked as Reserved.
Other values should be marked Unassigned.
7.4. VCAT VCG Operation Actions The registry has been initially populated with the values shown in
Section 5.2 of this document. Value 0 is Reserved. Other values are
marked Unassigned.
IANA is requested to create a registry to track VCAT VCG operation 7.4. VCAT VCG Operation Actions
actions as defined in Section 5.2. New allocations are by "IETF
Review" [RFC5226].
IANA is requested to track: IANA created a registry to track VCAT VCG operation actions as
defined in Section 5.2. New allocations are by "IETF Review"
[RFC5226].
- Value IANA maintains the following information:
- Meaning
- RFC
The available range is 0 - 255 - Value
- Meaning
- RFC
The registry should be initially populated with the values shown in The available range is 0 - 255.
Section 5.2 of this document. Other values should be marked
Unassigned.
8. Security Considerations The registry has been initially populated with the values shown in
Section 5.2 of this document. Other values are marked Unassigned.
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 [RFC3473] and as modified by [RFC4974]. It does not introduce any
change the relationship between LSRs that are adjacent in the new signaling messages, nor does it change the relationship between
control plane. The call information associated with diversely LSRs that are adjacent in the control plane. The call information
routed control plane LSPs, in the event of an interception, may associated with diversely routed control plane LSPs, in the event of
indicate that these are members of the same VCAT group that take a an interception, may indicate that these are members of the same VCAT
different route, and may indicate to an interceptor that the VCG group that take a different route, and may indicate to an interceptor
call desires increased reliability. that the VCG call desires increased reliability.
See [RFC5920] for additional information on GMPLS security. See [RFC5920] for additional information on GMPLS security.
9. Contributors 9. 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
2, avenue Pierre Marzin 2, avenue Pierre Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
Phone: + 33 2 96 05 28 28 Phone: +33 2 96 05 28 28
Email: julien.meuric@orange-ft.com EMail: julien.meuric@orange-ft.com
Lyndon Ong Lyndon Ong
Ciena Ciena
PO Box 308 PO Box 308
Cupertino, CA 95015 Cupertino, CA 95015
United States of America USA
Phone: +1 408 705 2978 Phone: +1 408 705 2978
Email: lyong@ciena.com EMail: lyong@ciena.com
10. 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 document.
11. References
11.1. Normative References 11. References
[RFC6001] Papadimitriou, D., Vigoureux M., Shiomoto, K. 11.1. Normative References
Brungard, D., Le Roux, JL., "Generalized Multi-
Protocol Label Switching (GMPLS) Protocol Extensions
for Multi-Layer and Multi-Region Networks (MLN/MRN)",
October, 2010.
[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., Ed., "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.
[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,
2005. August 2006.
[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.
11.2. Informative References [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K.,
Brungard, D., and JL. Le Roux, "Generalized MPLS
(GMPLS) Protocol Extensions for Multi-Layer and Multi-
Region Networks (MLN/MRN)", RFC 6001, October 2010.
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 Multiplex Structure, Rates, and Formats", ANSI
T1.105-2001, May 2001. T1.105-2001, May 2001.
[G7042] International Telecommunications Union, "Link [ITU-T-G.707] International Telecommunication Union, "Network Node
Capacity Adjustment Scheme (LCAS) for Virtual
Concatenated Signals", ITU-T Recommendation G.7042,
March 2006.
[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.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
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 Telecommunication Union, "Interfaces for
for the Optical Transport Network (OTN)", ITU-T the Optical Transport Network (OTN)", ITU-T
Recommendation G.709, March 2003. Recommendation G.709, March 2003.
[RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS [ITU-T-G.7042] International Telecommunication Union, "Link Capacity
Networks", July 2010. Adjustment Scheme (LCAS) for Virtual Concatenated
Signals", ITU-T Recommendation G.7042, March 2006.
[RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an [ITU-T-G.7043] International Telecommunication Union, "Virtual
IANA Considerations Section in RFCs", May 2008. Concatenation of Plesiochronous Digital Hierarchy
(PDH) Signals", ITU-T Recommendation G.7043,
July 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
Authors' Addresses Authors' Addresses
Greg M. Bernstein (ed.) Greg M. Bernstein (editor)
Grotto Networking Grotto Networking
Fremont California, USA Fremont, CA
USA
Phone: (510) 573-2237 Phone: (510) 573-2237
Email: gregb@grotto-networking.com EMail: gregb@grotto-networking.com
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Via A. Negrone 1/A 16153 Via A. Negrone 1/A 16153
Genoa Italy Genoa Italy
Phone: +39 010 600 3736 Phone: +39 010 600 3736
Email: diego.caviglia@(marconi.com, ericsson.com) EMail: diego.caviglia@ericsson.com
Richard Rabbat Richard Rabbat
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043, USA Mountain View, CA 94043
USA
EMail: rabbat@alum.mit.edu
Email: rabbat@alum.mit.edu
Huub van Helvoort Huub van Helvoort
Huawei Technologies, Ltd. Huawei Technologies, Ltd.
Kolkgriend 38, 1356 BC Almere Kolkgriend 38, 1356 BC Almere
The Netherlands The Netherlands
Phone: +31 36 5315076 Phone: +31 36 5315076
Email: hhelvoort@huawei.com EMail: hhelvoort@huawei.com
Intellectual Property Statement
The IETF Trust 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 any IETF 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.
Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
 End of changes. 185 change blocks. 
566 lines changed or deleted 548 lines changed or added

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