draft-ietf-ccamp-gmpls-vcat-lcas-06.txt   draft-ietf-ccamp-gmpls-vcat-lcas-07.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: May 2009 R. Rabbat Expires: June 2009 R. Rabbat
Google Google
H. van Helvoort H. van Helvoort
Huawei Huawei
November 17, 2008 December 18, 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-06.txt
draft-ietf-ccamp-gmpls-vcat-lcas-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance with the
any applicable patent or other IPR claims of which he or she is provisions of BCP 78 and BCP 79.
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 17, 2009. This Internet-Draft will expire on June 18, 2009.
Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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 25 skipping to change at page 2, line 29
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...............................................4
2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-05..........3 2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-05 and -06..4
2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-04..........4 2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-04..........4
2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03..........4 2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03..........4
2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02..........4 2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02..........4
2.5. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........4 2.5. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........4
2.6. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........5 2.6. 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.......9 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...........10 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......................11 4.2.1. Signaled VCG Layer Information......................11
4.3. Use of the CALL_ATTRIBUTES Object........................11 4.3. Use of the CALL_ATTRIBUTES Object........................12
4.4. VCAT CALL_ATTRIBUTES TLV Object..........................12 4.4. VCAT CALL_ATTRIBUTES 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......................15 4.5.1. Setting up a VCAT call and VCG......................15
4.5.2. Setting up a VCAT call + LSPs with no VCG...........15 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.....16 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.......................................17 7. Security Considerations.......................................17
8. Contributors..................................................17 8. Contributors..................................................17
9. Acknowledgments...............................................17 9. Acknowledgments...............................................17
10. References...................................................19 10. References...................................................19
10.1. Normative References....................................19 10.1. Normative References....................................19
10.2. Informative References..................................19 10.2. Informative References..................................19
Author's Addresses...............................................20 Author's Addresses...............................................20
Intellectual Property Statement..................................21 Intellectual Property Statement..................................21
Disclaimer of Validity...........................................21 Disclaimer of Validity...........................................21
Copyright Statement..............................................21
Acknowledgment...................................................21 Acknowledgment...................................................21
1. Introduction 1. Introduction
The Generalized Multi-Protocol Label Switching (GMPLS) suite of The Generalized Multi-Protocol Label Switching (GMPLS) suite of
protocols allows for the automated control of different switching protocols allows for the automated control of different switching
technologies including Synchronous Optical Network (SONET), technologies including Synchronous Optical Network (SONET),
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)
skipping to change at page 3, line 47 skipping to change at page 4, line 7
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-05 2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-05 and -06
Used the CALL_ATTRIBUTES Object from [MLN-Ext] rather than defining a Used the CALL_ATTRIBUTES Object from [MLN-Ext] rather than defining a
new CALL_DATA object. new CALL_DATA object.
2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-04 2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-04
Fixed text in section 4.1.3 on VCG Reduction to more accurately Fixed text in section 4.1.3 on VCG Reduction to more accurately
describe LCAS and non-LCAS cases. describe LCAS and non-LCAS cases.
2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03 2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03
skipping to change at page 13, line 32 skipping to change at page 13, line 35
VCG within a session. This number MUST NOT change over the lifetime VCG within a session. This number MUST NOT change over the lifetime
of a VCG but can change over the lifetime of a call. To support the of a VCG but can change over the lifetime of a call. To support the
member sharing scenario of section 3.2. and the requirements of member sharing scenario of section 3.2. and the requirements of
section 3.4. we allow the VCG Identifier within a call to be changed. 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_ATTRIBUTES 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 no 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_ATTRIBUTES object containing a VCAT TLV
precede any of those changes and indicate the new total number of VCG MUST precede any of those changes and indicate the new total number
members. of VCG 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.
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).
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:
A CALL_DATA Object containing a VCAT TLV indicating the new number of A CALL_ATTRIBUTES Object containing a VCAT TLV indicating the new
members after the proposed increase is sent. If an error is number of members after the proposed increase is sent. If an error
returned from the receiver the VCG state remains the same prior to is returned from the receiver the VCG state remains the same prior
the attempted increase. to the attempted increase.
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.
The internal LCAS entity is instructed by the endpoints to "activate" The internal LCAS entity is instructed by the endpoints to "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.
LSPs are removed from a VCAT Call associated with a VCG (Action = 2). LSPs are removed from a VCAT Call associated with a VCG (Action = 2).
A VCG association is removed from existing VCAT call containing LSPs A VCG association is removed from existing VCAT call containing 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_ATTRIBUTES Object containing a VCAT TLV indicating the new
of members after the proposed decrease is sent. If an error is number of members after the proposed decrease is sent. If an error
returned from the receiver the VCG state remains the same prior to is returned from the receiver the VCG state remains the same prior
the attempted decrease. to 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
members to be removed from the VCG. members to be removed from the VCG.
3. Either: (a) An LSP is removed from a call associated with a VCG; 3. Either: (a) An LSP is removed from a call associated with a VCG;
or (b) All the LSPs of a call are removed from the VCG when the or (b) All the LSPs of a call are removed from the VCG when the
association between the VCG and VCAT call is removed. association between the VCG and VCAT call is removed.
Note that when LCAS is not used or unavailable the VCG will be in an Note that when LCAS is not used or unavailable the VCG will be in an
unknown state between the time the VCG call level information is unknown state between the time the VCG call level information is
skipping to change at page 15, line 43 skipping to change at page 15, line 45
has no meaning at this point since it reflects the intended number of has no meaning at this point since it reflects the intended number of
members in a VCG and not in a call. A call will know via the members in a VCG and not in a call. A call will know via the
containment hierarchy about its associated data plane LSPs. However, containment hierarchy about its associated data plane LSPs. However,
the signal type does matter since signal types can never be mixed in the signal type does matter since signal types can never be mixed in
a VCG and hence a VCAT call should only contain one signal type. a VCG and hence a VCAT call should only contain one signal type.
4.5.3. Associating an existing VCAT call with a VCG 4.5.3. Associating an existing VCAT call with a VCG
Given a VCAT call without an associated VCG such as that set up in Given a VCAT call without an associated VCG such as that set up in
section 4.5.2. one associates it with a VCG as follows. In the VCAT section 4.5.2. one associates it with a VCG as follows. In the VCAT
call a new notify message is sent with a CALL_DATA object with a VCAT call a new notify message is sent with a CALL_ATTRIBUTES object with
TLV with Action = 1, a VCG ID, and the correct number of VCG members a VCAT TLV with Action = 1, a VCG ID, and the correct number of VCG
specified based on adding all of the calls data plane LSPs to the VCG members specified based on adding all of the calls data plane LSPs to
as members. the VCG as members.
Note that the total number of VCGs supported by a piece of equipment Note that the total number of VCGs supported by a piece of equipment
may be limited and hence on reception of any message with a change of may be limited and hence on reception of any message with a change of
VCG ID this limit should be checked. Likewise the sender of a message VCG ID this limit should be checked. Likewise the sender of a message
with a change in VCG ID should be prepared to receive an error with a change in VCG ID should be prepared to receive an error
response. To take a particular VCG out of service, rather than just response. To take a particular VCG out of service, rather than just
removing all its member, a special flag element is included. removing all its member, a special flag element is included.
4.5.4. Removing the association between a call and VCG 4.5.4. Removing the association between a call and VCG
To reuse the server layer connections in a call in another VCG one To reuse the server layer connections in a call in another VCG one
first needs to remove the current association between the call and a first needs to remove the current association between the call and a
VCG. To do this, in the VCAT call a new notify message is sent with VCG. To do this, in the VCAT call a new notify message is sent with
a CALL_DATA object with a VCAT TLV with Action = 3, a VCG ID, and the a CALL_ATTRIBUTES object with a VCAT TLV with Action = 3, a VCG ID,
correct number of VCG members specified based on removing all of the and the correct number of VCG members specified based on removing all
calls data plane LSPs from the VCG as members. When the association of the calls data plane LSPs from the VCG as members. When the
between a VCG and all existing calls has been removed then the VCG is association between a VCG and all existing calls has been removed
considered torn down. then the VCG is considered torn down.
5. Error Conditions and Codes 5. Error Conditions and Codes
VCAT Call and member LSP setup can be denied for various reasons. VCAT Call and member LSP setup can be denied for various reasons.
Below is a list of error conditions that can be encountered during Below is a list of error conditions that can be encountered during
these procedures. These fall under RSVP error code TBD. these procedures. These fall under RSVP error code TBD.
These can occur when setting up a VCAT call or associating a VCG with These can occur when setting up a VCAT call or associating a VCG with
a VCAT call. a VCAT call.
skipping to change at page 21, line 7 skipping to change at page 21, line 7
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
The IETF takes no position regarding the validity or scope of any The IETF Trust takes no position regarding the validity or scope of
Intellectual Property Rights or other rights that might be claimed to any Intellectual Property Rights or other rights that might be
pertain to the implementation or use of the technology described in claimed to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in any IETF Document or the extent to which any license
might or might not be available; nor does it represent that it has under such rights might or might not be available; nor does it
made any independent effort to identify any such rights. Information represent that it has made any independent effort to identify any
on the procedures with respect to rights in RFC documents can be such rights.
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of Intellectual Property disclosures made to the IETF
assurances of licenses to be made available, or the result of an Secretariat and any assurances of licenses to be made available, or
attempt made to obtain a general license or permission for the use of the result of an attempt made to obtain a general license or
such proprietary rights by implementers or users of this permission for the use of such proprietary rights by implementers or
specification can be obtained from the IETF on-line IPR repository at users of this specification can be obtained from the IETF on-line IPR
http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at any standard or specification contained in an IETF Document. Please
ietf-ipr@ietf.org. address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an All IETF Documents and the information contained therein are provided
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 19 change blocks. 
66 lines changed or deleted 67 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/