draft-ietf-ccamp-gmpls-vcat-lcas-04.txt   draft-ietf-ccamp-gmpls-vcat-lcas-05.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: August 2008 R. Rabbat Expires: December 2008 R. Rabbat
Google Google
H. van Helvoort H. van Helvoort
Huawei Huawei
February 5, 2008 July 8, 2008
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-04.txt draft-ietf-ccamp-gmpls-vcat-lcas-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 August 5, 2008. This Internet-Draft will expire on December 8, 2008.
Abstract Abstract
This document describes requirements for, and use of, the Generalized This document describes requirements for, and use of, the Generalized
Multi-Protocol Label Switching (GMPLS) control plane in conjunction Multi-Protocol Label Switching (GMPLS) control plane in conjunction
with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing
mechanism and its companion Link Capacity Adjustment Scheme (LCAS) mechanism and its companion Link Capacity Adjustment Scheme (LCAS)
which can be used for hitless dynamic resizing of the inverse which can be used for hitless dynamic resizing of the inverse
multiplex group. These techniques apply to Optical Transport Network multiplex group. These techniques apply to Optical Transport Network
(OTN), Synchronous Optical Network (SONET), Synchronous Digital (OTN), Synchronous Optical Network (SONET), Synchronous Digital
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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...............................................3 2. Revision History...............................................3
2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03..........3 2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-04..........3
2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02..........4 2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03..........4
2.3. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........4 2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02..........4
2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........4 2.4. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........4
2.5. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........5
3. VCAT/LCAS Scenarios and Specific Requirements..................5 3. VCAT/LCAS Scenarios and Specific Requirements..................5
3.1. VCAT/LCAS Interface Capabilities..........................5 3.1. VCAT/LCAS Interface Capabilities..........................5
3.2. Member Signal Configuration Scenarios.....................5 3.2. Member Signal Configuration Scenarios.....................5
3.3. VCAT Operation With or Without LCAS.......................6 3.3. VCAT Operation With or Without LCAS.......................6
3.4. VCGs and VCG Members......................................7 3.4. VCGs and VCG Members......................................7
4. GMPLS Mechanisms in Support of VCGs............................7 4. GMPLS Mechanisms in Support of VCGs............................7
4.1. VCGs Composed of a Single Co-Signaled Member Set..........8 4.1. VCGs Composed of a Single Co-Signaled Member Set..........8
4.1.1. One-shot VCG Setup with Co-Signaled Members..........8 4.1.1. One-shot VCG Setup with Co-Signaled Members..........8
4.1.2. Incremental VCG Setup with Co-Signaled Members.......8 4.1.2. Incremental VCG Setup with Co-Signaled Members.......9
4.1.3. Procedure for VCG Reduction by Removing a Member.....9 4.1.3. Procedure for VCG Reduction by Removing a Member.....9
4.1.4. Removing Multiple VCG Members in One Shot............9 4.1.4. Removing Multiple VCG Members in One Shot...........10
4.1.5. Teardown of Whole VCG...............................10 4.1.5. Teardown of Whole VCG...............................10
4.2. VCGs Composed of Multiple Co-Signaled Member Sets........10 4.2. VCGs Composed of Multiple Co-Signaled Member Sets........10
4.2.1. Signaled VCG Layer Information......................10 4.2.1. Signaled VCG Layer Information......................11
4.3. Call Data Object.........................................11 4.3. Call Data Object.........................................11
4.4. VCAT TLV Object..........................................11 4.4. VCAT TLV Object..........................................12
4.5. Procedures for Multiple Co-signaled Member Sets..........13 4.5. Procedures for Multiple Co-signaled Member Sets..........13
4.5.1. Setting up a VCAT call and VCG......................14 4.5.1. Setting up a VCAT call and VCG......................15
4.5.2. Setting up a VCAT call + LSPs with no VCG...........14 4.5.2. Setting up a VCAT call + LSPs with no VCG...........15
4.5.3. Associating an existing VCAT call with a VCG........15 4.5.3. Associating an existing VCAT call with a VCG........15
4.5.4. Removing the association between a call and VCG.....15 4.5.4. Removing the association between a call and VCG.....16
5. Error Conditions and Codes....................................16 5. Error Conditions and Codes....................................16
6. IANA Considerations...........................................16 6. IANA Considerations...........................................16
7. Security Considerations.......................................16 7. Security Considerations.......................................17
8. Contributors..................................................17 8. Contributors..................................................17
9. Acknowledgments...............................................17 9. Acknowledgments...............................................17
10. References...................................................18 10. References...................................................19
10.1. Normative References....................................18 10.1. Normative References....................................19
10.2. Informative References..................................18 10.2. Informative References..................................19
Author's Addresses...............................................19 Author's Addresses...............................................20
Intellectual Property Statement..................................19 Intellectual Property Statement..................................20
Disclaimer of Validity...........................................20 Disclaimer of Validity...........................................21
Copyright Statement..............................................20 Copyright Statement..............................................21
Acknowledgment...................................................20 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),
Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN) Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN)
and Plesiochronous Digital Hierarchy (PDH). This document describes and Plesiochronous Digital Hierarchy (PDH). This document describes
extensions to RSVP-TE to support the Virtual Concatenation (VCAT) extensions to RSVP-TE to support the Virtual Concatenation (VCAT)
layer 1 inverse multiplexing mechanism that has been standardized for layer 1 inverse multiplexing mechanism that has been standardized for
skipping to change at page 3, line 41 skipping to change at page 3, line 42
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.
2. Revision History 2. Revision History
2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03 2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-04
o Added requirements on pre-existing members. Fixed text in section 4.1.3 on VCG Reduction to more accurately
describe LCAS and non-LCAS cases.
o Slightly modified solution for member sharing to constrain calls 2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03
to a maximum of one VCG.
o Introduced the CALL_DATA object. Added requirements on pre-existing members.
o Detailed coding of new TLV for VCAT to be included in the Slightly modified solution for member sharing to constrain calls to a
CALL_DATA object. maximum of one VCG.
o Modified and expanded procedures to deal with new requirements and 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. modified solution methodology.
o Added a list of error conditions. Added a list of error conditions.
2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02 2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02
o Grammar and punctuation fixes. Updated references with newly Grammar and punctuation fixes. Updated references with newly
published RFCs. published RFCs.
2.3. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01 2.4. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01
o Changed section 3.1 from "Multiple VCAT Groups per GMPLS endpoint" Changed section 3.1 from "Multiple VCAT Groups per GMPLS endpoint" to
to "VCAT/LCAS Interface Capability" to improve clarity. "VCAT/LCAS Interface Capability" to improve clarity.
o Changed terminology from "component" signal to "member" signal Changed terminology from "component" signal to "member" signal where
where possible (not quoted text) to avoid confusion with link possible (not quoted text) to avoid confusion with link bundle
bundle components. components.
o Added "Dynamic, member sharing" scenario. Added "Dynamic, member sharing" scenario.
o Clarified requirements with respect to scenarios and the LCAS and Clarified requirements with respect to scenarios and the LCAS and
non-LCAS cases. non-LCAS cases.
o Added text describing needed signaling information between the Added text describing needed signaling information between the VCAT
VCAT endpoints to support required scenarios. endpoints to support required scenarios.
o Added text to describe: co-signaled, co-routed, data plane LSP, Added text to describe: co-signaled, co-routed, data plane LSP,
control plane LSP and their relationship to the VCAT/LCAS control plane LSP and their relationship to the VCAT/LCAS
application. application.
o Change implementation mechanism from one based on the Association Change implementation mechanism from one based on the Association
object to one based on "Call concepts" utilizing the Notify object to one based on "Call concepts" utilizing the Notify
message. message.
2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00 2.5. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00
o Updated reference from RFC3946bis to issued RFC4606 Updated reference from RFC3946bis to issued RFC4606
o Updated section 3.2 based on discussions on the mailing list Updated section 3.2 based on discussions on the mailing list
3. VCAT/LCAS Scenarios and Specific Requirements 3. 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 3.1. VCAT/LCAS Interface Capabilities
skipping to change at page 5, line 28 skipping to change at page 5, line 34
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 3.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.
o 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 intended 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.
o Fixed, diversely routed: A fixed bandwidth VCG, transported over Fixed, diversely routed: A fixed bandwidth VCG, transported over at
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 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.
o Fixed, member sharing: A fixed bandwidth VCG, transported over a Fixed, member sharing: A fixed bandwidth VCG, transported over a set
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. teardown and setup.
o 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 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.
o Dynamic, diversely routed: A dynamic VCG (bandwidth can be Dynamic, diversely routed: A dynamic VCG (bandwidth can be increased
increased or decreased via the addition or removal of member or decreased via the addition or removal of member signals),
signals), transported over at least two diversely routed subsets transported over at least two diversely routed subsets of member
of member signals. The intent here is efficient use of network signals. The intent here is efficient use of network resources,
resources, dynamic resizing and resilience of bandwidth. dynamic resizing and resilience of bandwidth.
o Dynamic, member sharing: A dynamic bandwidth VCG, transported over Dynamic, member sharing: A dynamic bandwidth VCG, transported over a
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.
3.3. VCAT Operation With or Without LCAS 3.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.
o GMPLS signaling for LCAS-capable interfaces MUST support all GMPLS signaling for LCAS-capable interfaces MUST support all
scenarios of section 3.2. with no loss of traffic. scenarios of section 3.2. with no loss of traffic.
o GMPLS signaling for non-LCAS-capable interfaces MUST support only GMPLS signaling for non-LCAS-capable interfaces MUST support only the
the "fixed" scenarios of section 3.2. "fixed" scenarios of section 3.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:
o The type of the member signal that the VCG will contain, e.g., VC- The type of the member signal that the VCG will contain, e.g., VC-3,
3, VC-4, etc. VC-4, etc.
o The total number of member to be in the VCG. This provides the 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.
o Identification of the VCG and its associated members. This Identification of the VCG and its associated members. This provides
provides information that allows the endpoints to differentiate information that allows the endpoints to differentiate multiple
multiple VCGs and to tell what members (LSPs) to associate with a VCGs and to tell what members (LSPs) to associate with a
particular VCG. particular VCG.
3.4. VCGs and VCG Members 3.4. VCGs and VCG Members
o VCG members (server layer connections) may be set up prior to VCG members (server layer connections) may be set up prior to their
their use in a VCG. use in a VCG.
o VCG members (server layer connections) may exist after their 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.
4. GMPLS Mechanisms in Support of VCGs 4. GMPLS Mechanisms in Support of VCGs
We describe in this section the signaling mechanisms that already We describe in this section the signaling mechanisms that already
exist in GMPLS using RSVP-TE [RFC3473] and [RFC4328], and the 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. 3.
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.
1. VCG member -- This is an individual data plane signal of one of the 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.
2. Co-signaled member set -- One or more VCG members (or potential 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.
3. Co-routed member set - One or more VCG members that follow the same 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.
4. Data plane LSP -- for our purposes here, this is equivalent to an Data plane LSP -- for our purposes here, this is equivalent to an
individual VCG member. individual VCG member.
5. Control plane LSP -- A control plane entity that can control Control plane LSP -- A control plane entity that can control multiple
multiple data plane LSPs. For our purposes here this is equivalent data plane LSPs. For our purposes here this is equivalent to our
to our co-signaled member set. co-signaled member set.
Section 4.1 is included for informational purposes only. It Section 4.1 is included for informational purposes only. It
describes existing GMPLS procedures that support a single VCG describes existing GMPLS procedures that support a single VCG
composed of a single co-signaled member set. composed of a single co-signaled member set.
Section 4.2 describes new procedures to support VCGs composed of more Section 4.2 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.1.
4.1. VCGs Composed of a Single Co-Signaled Member Set 4.1. VCGs Composed of a Single Co-Signaled Member Set
Note that this section is for informational purposes only. Note that this section is for informational purposes only.
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 plane in section 2.1 of [RFC4606]. In this case, one (single) control
LSP is used in support of the VCG. plane LSP is used in support of the VCG.
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.1. One-shot VCG Setup with Co-Signaled Members
skipping to change at page 9, line 25 skipping to change at page 9, line 37
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.1.3. Procedure for VCG Reduction by Removing a Member
A VCG member can be permanently removed from the VCG either as the
result of a management command or following a temporary removal (due
to a failure).
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 list identifier for the dropped component is removed from the ordered
in the Generalized Label. list 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 errors in the inverse- component of the VCG will result in errors in the inverse-
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
to a failure of the component signal. The LCAS in-band signaling will
take appropriate actions to adjust the VCG as described in [ITU-T-
G.7042].
4.1.4. Removing Multiple VCG Members in One Shot 4.1.4. Removing Multiple VCG Members in One Shot
The procedure is similar to 4.1.3. In this case, the NVC value is The procedure is similar to 4.1.3. In this case, the NVC value is
changed to the new value and all relevant timeslot identifiers for 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.1.5. Teardown of Whole VCG
skipping to change at page 11, line 22 skipping to change at page 11, line 34
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)
d. LCAS not 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 3.4.
4.3. Call Data Object 4.3. Call Data Object
In RFC4974 the general mechanism for communicating call information In RFC4974 the general mechanism for communicating call information
via notify messages is given. In general different types of calls via Notify messages is given. In general different types of calls
will need to convey call related information during call will need to convey call related information during call
establishment and updates. We define a general CALL_DATA object for establishment and updates. We define a general CALL_DATA object for
inclusion in call related notify messages and define a specific class inclusion in call related notify messages and define a specific class
type (C-Type) for VCAT calls. type (C-Type) for VCAT calls.
4.4. VCAT TLV Object 4.4. VCAT TLV Object
For use in the CALL_DATA object (of VCAT-Call C-Type) in Notify For use in the CALL_DATA object (of VCAT-Call C-Type) in Notify
messages we define the following VCAT TLV: messages we define the following VCAT TLV:
skipping to change at page 12, line 4 skipping to change at page 12, line 17
For use in the CALL_DATA object (of VCAT-Call C-Type) in Notify For use in the CALL_DATA object (of VCAT-Call C-Type) in Notify
messages we define the following VCAT TLV: messages we define the following VCAT TLV:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Members | | Signal Type | Number of Members |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCAS Req | Action | VCG ID | | LCAS Req | Action | VCG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signal Type can take the following values and MUST never change over Signal Type can take the following values and MUST never change over
the lifetime of a VCG: the lifetime of a VCG:
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 Gbps) 11 OPU1 (i.e., 2.5 Gbit/s
12 OPU2 (i.e., 10 Gbps) 12 OPU2 (i.e., 10 Gbit/s)
13 OPU3 (i.e., 40 Gbps) 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 is a non-negative integer that indicates the total
number of members in the VCG (not just the call)and MUST be changed 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. 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 LCAS Required 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 desired (but acceptable) 2 LCAS not desired (but acceptable)
3 LCAS not acceptable
Action is used to indicate the relationship between the call and the Action is used to indicate the relationship between the call and the
VCG and takes the following values. VCG and takes 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
skipping to change at page 13, line 18 skipping to change at page 13, line 35
section 3.4. we allow the VCG Identifier within a call to be changed. 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 In this way the connections associated with a call can be dedicated
to a new VCG (allowing for a priori connection establishment and to a new VCG (allowing for a priori connection establishment and
connection persistence after a VCG has been removed). connection persistence after a VCG has been removed).
4.5. Procedures for Multiple Co-signaled Member Sets 4.5. Procedures for Multiple Co-signaled Member Sets
To establish a VCG a CALL_DATA object containing a VCAT TLV is To establish a VCG a CALL_DATA object containing a VCAT TLV is
exchanged as part of call establishment or update. A VCG can be 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 established at the same time as a new call or associated with an
existing call that currently has not VCG association. When modifying existing call that currently has no VCG association. When modifying
the bandwidth of a VCG a CALL_DATA object containing a VCAT TLV MUST the bandwidth of a VCG a CALL_DATA object containing a VCAT TLV MUST
precede any of those changes and indicate the new total number of VCG precede any of those changes and indicate the new total number of VCG
members. members.
The following mechanisms can be used to increase the bandwidth of a The following mechanisms can be used to increase the bandwidth of a
VCG. VCG.
o LSPs are added to a VCAT Call associated with a VCG (Action = 2). LSPs are added to a VCAT Call associated with a VCG (Action = 2).
o A VCG is associated with an existing VCAT call containing LSPs A VCG is associated with an existing VCAT call containing LSPs
(Action = 1). (Action = 1).
The following internal ordering is used when increasing the bandwidth The following internal ordering is used when increasing the bandwidth
of a VCG in a hitless fashion when LCAS is supported: of a VCG in a hitless fashion when LCAS is supported:
1. A CALL_DATA Object containing a VCAT TLV indicating the new number A CALL_DATA Object containing a VCAT TLV indicating the new number of
of members after the proposed increase is sent. If an error is members after the proposed increase is sent. If an error is
returned from the receiver the VCG state remains the same prior to returned from the receiver the VCG state remains the same prior to
the attempted increase. the attempted increase.
2. Either: (a) New LSPs are set up within a call associated with the 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, or (b) LSPs in an existing call are now associated with the
VCG. VCG.
3. The internal LCAS entity is instructed by the endpoints to The internal LCAS entity is instructed by the endpoints to "activate"
"activate" the new VCG member(s). the new VCG member(s).
The following mechanisms can be used to decrease the bandwidth of a The following mechanisms can be used to decrease the bandwidth of a
VCG. VCG.
o LSPs are removed from a VCAT Call associated with a VCG (Action = LSPs are removed from a VCAT Call associated with a VCG (Action = 2).
2).
o A VCG association is removed from existing VCAT call containing A VCG association is removed from existing VCAT call containing LSPs
LSPs (Action = 3). (Action = 3).
In general the following internal ordering is used when decreasing In general the following internal ordering is used when decreasing
the bandwidth of a VCG in a hitless fashion when LCAS is supported: the bandwidth of a VCG in a hitless fashion when LCAS is supported:
1. A CALL_DATA Object containing a VCAT TLV indicating the new number 1. A CALL_DATA Object containing a VCAT TLV indicating the new number
of members after the proposed decrease is sent. If an error is of members after the proposed decrease is sent. If an error is
returned from the receiver the VCG state remains the same prior to returned from the receiver the VCG state remains the same prior to
the attempted decrease. the attempted decrease.
2. The LCAS entity is instructed by the endpoints to "deactivate" the 2. The LCAS entity is instructed by the endpoints to "deactivate" the
skipping to change at page 19, line 26 skipping to change at page 20, line 26
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@(marconi.com, ericsson.com)
Richard Rabbat Richard Rabbat
Google Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043, USA
Email: richard.rabbat@gmail.com 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 Intellectual Property Statement
 End of changes. 70 change blocks. 
112 lines changed or deleted 118 lines changed or added

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