draft-ietf-ccamp-gmpls-vcat-lcas-03.txt   draft-ietf-ccamp-gmpls-vcat-lcas-04.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: April 2008 R. Rabbat Expires: August 2008 R. Rabbat
Google Google
H. van Helvoort H. van Helvoort
Huawei Huawei
October 3, 2007 February 5, 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-03.txt draft-ietf-ccamp-gmpls-vcat-lcas-04.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 October 3, 2007. This Internet-Draft will expire on August 5, 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-02..........3 2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03..........3
2.2. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........3 2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02..........4
2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........4 2.3. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........4
3. VCAT/LCAS Scenarios and Specific Requirements..................4 2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........4
3.1. VCAT/LCAS Interface Capabilities..........................4 3. VCAT/LCAS Scenarios and Specific Requirements..................5
3.2. Member Signal Configuration Scenarios.....................4 3.1. VCAT/LCAS Interface Capabilities..........................5
3.3. VCAT Operation With or Without LCAS.......................5 3.2. Member Signal Configuration Scenarios.....................5
4. GMPLS Mechanisms in Support of VCGs............................6 3.3. VCAT Operation With or Without LCAS.......................6
4.1. VCGs Composed of a Single Co-Signaled Member Set..........7 3.4. VCGs and VCG Members......................................7
4.1.1. One-shot VCG Setup with Co-Signaled Members..........7 4. GMPLS Mechanisms in Support of VCGs............................7
4.1. VCGs Composed of a Single Co-Signaled Member Set..........8
4.1.1. One-shot VCG Setup with Co-Signaled Members..........8
4.1.2. Incremental VCG Setup with Co-Signaled Members.......8 4.1.2. Incremental VCG Setup with Co-Signaled Members.......8
4.1.3. Procedure for VCG Reduction by Removing a Member.....8 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............9
4.1.5. Teardown of Whole VCG................................9 4.1.5. Teardown of Whole VCG...............................10
4.2. VCGs Composed of Multiple Co-Signaled Member Sets.........9 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......................10
4.2.2. Procedures for VCG Control with Multiple Co-signaled 4.3. Call Data Object.........................................11
Member Sets................................................10 4.4. VCAT TLV Object..........................................11
4.3. Member Sharing -- Multiple VCGs per Call.................11 4.5. Procedures for Multiple Co-signaled Member Sets..........13
5. IANA Considerations...........................................13 4.5.1. Setting up a VCAT call and VCG......................14
6. Security Considerations.......................................13 4.5.2. Setting up a VCAT call + LSPs with no VCG...........14
7. Contributors..................................................14 4.5.3. Associating an existing VCAT call with a VCG........15
8. Acknowledgments...............................................14 4.5.4. Removing the association between a call and VCG.....15
9. References....................................................15 5. Error Conditions and Codes....................................16
9.1. Normative References.....................................15 6. IANA Considerations...........................................16
9.2. Informative References...................................15 7. Security Considerations.......................................16
Author's Addresses...............................................16 8. Contributors..................................................17
Intellectual Property Statement..................................16 9. Acknowledgments...............................................17
Disclaimer of Validity...........................................17 10. References...................................................18
Copyright Statement..............................................17 10.1. Normative References....................................18
Acknowledgment...................................................17 10.2. Informative References..................................18
Author's Addresses...............................................19
Intellectual Property Statement..................................19
Disclaimer of Validity...........................................20
Copyright Statement..............................................20
Acknowledgment...................................................20
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 34 skipping to change at page 3, line 41
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-02 2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03
o Added requirements on pre-existing members.
o Slightly modified solution for member sharing to constrain calls
to a maximum of one VCG.
o Introduced the CALL_DATA object.
o Detailed coding of new TLV for VCAT to be included in the
CALL_DATA object.
o Modified and expanded procedures to deal with new requirements and
modified solution methodology.
o Added a list of error conditions.
2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02
o Grammar and punctuation fixes. Updated references with newly o Grammar and punctuation fixes. Updated references with newly
published RFCs. published RFCs.
2.2. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01 2.3. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01
o Changed section 3.1 from "Multiple VCAT Groups per GMPLS endpoint" o Changed section 3.1 from "Multiple VCAT Groups per GMPLS endpoint"
to "VCAT/LCAS Interface Capability" to improve clarity. to "VCAT/LCAS Interface Capability" to improve clarity.
o Changed terminology from "component" signal to "member" signal o Changed terminology from "component" signal to "member" signal
where possible (not quoted text) to avoid confusion with link where possible (not quoted text) to avoid confusion with link
bundle components. bundle components.
o Added "Dynamic, member sharing" scenario. o Added "Dynamic, member sharing" scenario.
skipping to change at page 4, line 19 skipping to change at page 4, line 43
VCAT endpoints to support required scenarios. VCAT endpoints to support required scenarios.
o Added text to describe: co-signaled, co-routed, data plane LSP, o 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 o 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.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00 2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00
o Updated reference from RFC3946bis to issued RFC4606 o Updated reference from RFC3946bis to issued RFC4606
o Updated section 3.2 based on discussions on the mailing list o 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
skipping to change at page 6, line 25 skipping to change at page 7, line 5
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 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 (LSPs) to associate with a multiple VCGs and to tell what members (LSPs) to associate with a
particular VCG. particular VCG.
3.4. VCGs and VCG Members
o VCG members (server layer connections) may be set up prior to
their use in a VCG.
o VCG members (server layer connections) may exist after their
corresponding VCG has been removed.
The signaling solution SHOULD provide a mechanism to support the
previous scenarios. However, it is not required that arbitrarily
created server layer connections be supported in the above scenarios.
4. GMPLS Mechanisms in Support of VCGs 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 the extensions needed to exist in GMPLS using RSVP-TE [RFC3473] and [RFC4328], and the
completely support the requirements of section 3. extensions needed to completely support the requirements of section
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 1. VCG member -- This is an individual data plane signal of one of the
permitted SDH, SONET, OTN or PDH signal types. permitted SDH, SONET, OTN or PDH signal types.
2. Co-signaled member set -- One or more VCG members (or potential 2. Co-signaled member set -- One or more VCG members (or potential
members) set up via the same control plane signaling exchange. Note members) set up via the same control plane signaling exchange. Note
that all members in a co-signaled set follow the same route. that all members in a co-signaled set follow the same route.
skipping to change at page 10, line 12 skipping to change at page 10, line 49
service that makes use of multiple lower layer (server) connections service that makes use of multiple lower layer (server) connections
that are controlled by one or more control plane LSPs. that are controlled by one or more control plane LSPs.
4.2.1. Signaled VCG Layer Information 4.2.1. Signaled VCG Layer Information
When a VCG is composed of multiple co-signaled member sets, none of When a VCG is composed of multiple co-signaled member sets, none of
the control plane LSP's signaling information can contain information the control plane LSP's signaling information can contain information
pertinent to the entire VCG. In this section we give a list of pertinent to the entire VCG. In this section we give a list of
information that should be communicated at what we define as the VCG information that should be communicated at what we define as the VCG
Call layer, i.e., between the VCG signaling endpoints. To Call layer, i.e., between the VCG signaling endpoints. To
accommodate this information additional objects or TLVs would need to accommodate this information additional objects or TLVs are
be incorporated into the Notify message as it is described for use in incorporated into the Notify message as it is described for use in
call signaling in [RFC4974]. call signaling in [RFC4974].
VCG Call setup information signaled via the Notify message with the VCG Call setup information signaled via the Notify message with the
Call management bit (C-bit) set: Call management bit (C-bit) set:
1. Signal Type 1. Signal Type
2. Number of VCG Members 2. Number of VCG Members
3. LCAS requirements: 3. LCAS requirements:
a. LCAS required a. LCAS required
b. LCAS desired b. LCAS desired
c. LCAS not desired (but acceptable) c. LCAS not desired (but acceptable)
d. LCAS not acceptable d. LCAS not acceptable
4. Maximum Number of VCGs per Call-- This is a hook to support the 4. VCG Identifier - Used to identify a particular VCG separately
member sharing scenario. In the non-member sharing case the from the call ID so that call members can be reused with
value is one. different VCGs per the requirements for member sharing and the
requirements of section 3.4.
4.2.2. Procedures for VCG Control with Multiple Co-signaled Member Sets 4.3. Call Data Object
This section deals only with the case of one VCG per (VCG) Call. To In RFC4974 the general mechanism for communicating call information
establish a VCG, the information of section 4.2.1. is exchanged and via notify messages is given. In general different types of calls
agreed upon with the corresponding VCG signaling endpoint. Since only will need to convey call related information during call
one VCG is being signaled by this call, all control plane LSPs used establishment and updates. We define a general CALL_DATA object for
with this call establish members for this VCG and there is no inclusion in call related notify messages and define a specific class
ambiguity as to which VCG a potential member belongs. Procedures for type (C-Type) for VCAT calls.
addition and removal of bandwidth are the same as the single co-
signaled case except that a VCG Call layer message should precede any
of those changes and indicate the new total number of VCG members.
In general the following order is used to establish and increase the 4.4. VCAT TLV Object
bandwidth in a VCG:
1. VCG Call layer information is conveyed. Note that during a For use in the CALL_DATA object (of VCAT-Call C-Type) in Notify
"bandwidth" change only the total number of VCG members is messages we define the following VCAT TLV:
allowed to change.
2. Control Plane LSPs are used to add data plane LSPs (members) to 0 1 2 3
the VCG. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCAS Req | Action | VCG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signal Type can take the following values and MUST never change over
the lifetime of a VCG:
3. If LCAS is supported on this VCG call it should be instructed by Value Type (Elementary Signal)
the endpoints to "activate" the member. ----- ------------------------
1 VT1.5 SPE / VC-11
2 VT2 SPE / VC-12
3 STS-1 SPE / VC-3
4 STS-3c SPE / VC-4
11 OPU1 (i.e., 2.5 Gbps)
12 OPU2 (i.e., 10 Gbps)
13 OPU3 (i.e., 40 Gbps)
21 T1 (i.e., 1.544 Mbps)
22 E1 (i.e., 2.048 Mbps)
23 E3 (i.e., 34.368 Mbps)
24 T3 (i.e., 44.736 Mbps)
In general the following order is used when decreasing the bandwidth Number of Members is a non-negative integer that indicates the total
in a VCG: 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.
1. VCG Call layer information is conveyed concerning the decreased LCAS Required can take the following values and MUST NOT change over
number of VCG members. the life of a VCG:
2. If LCAS is supported on this VCG call it should be instructed by Value Meaning
the endpoints to "deactivate" the members to be removed. ----- ---------------------------------
0 LCAS required
1 LCAS desired
2 LCAS not desired (but acceptable)
3 LCAS not acceptable
3. Existing control plane LSPs are used to remove the data plane Action is used to indicate the relationship between the call and the
LSPs (members). VCG and takes the following values.
Value Meaning
----- ---------------------------------
0 No VCG ID (set up call prior to VCG creation)
1 New VCG for Call
2 No Change in VCG ID (number of members may have changed)
3 Remove VCG from Call
VCG ID: A 16 bit non-negative integer used to identify a particular
VCG within a session. This number MUST NOT change over the lifetime
of a VCG but can change over the lifetime of a call. To support the
member sharing scenario of section 3.2. and the requirements of
section 3.4. we allow the VCG Identifier within a call to be changed.
In this way the connections associated with a call can be dedicated
to a new VCG (allowing for a priori connection establishment and
connection persistence after a VCG has been removed).
4.5. Procedures for Multiple Co-signaled Member Sets
To establish a VCG a CALL_DATA object containing a VCAT TLV is
exchanged as part of call establishment or update. A VCG can be
established at the same time as a new call or associated with an
existing call that currently has not VCG association. When modifying
the bandwidth of a VCG a CALL_DATA object containing a VCAT TLV MUST
precede any of those changes and indicate the new total number of VCG
members.
The following mechanisms can be used to increase the bandwidth of a
VCG.
o 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
(Action = 1).
The following internal ordering is used when increasing the bandwidth
of a VCG in a hitless fashion when LCAS is supported:
1. A CALL_DATA Object containing a VCAT TLV indicating the new number
of members after the proposed increase is sent. If an error is
returned from the receiver the VCG state remains the same prior to
the attempted increase.
2. 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.
3. The internal LCAS entity is instructed by the endpoints to
"activate" the new VCG member(s).
The following mechanisms can be used to decrease the bandwidth of a
VCG.
o LSPs are removed from a VCAT Call associated with a VCG (Action =
2).
o A VCG association is removed from existing VCAT call containing
LSPs (Action = 3).
In general the following internal ordering is used when decreasing
the bandwidth of a VCG in a hitless fashion when LCAS is supported:
1. A CALL_DATA Object containing a VCAT TLV indicating the new number
of members after the proposed decrease is sent. If an error is
returned from the receiver the VCG state remains the same prior to
the attempted decrease.
2. The LCAS entity is instructed by the endpoints to "deactivate" the
members to be removed from the VCG.
3. Either: (a) An LSP is removed from a call associated with a VCG;
or (b) All the LSPs of a call are removed from the VCG when the
association between the VCG and VCAT call is removed.
Note that when LCAS is not used or unavailable the VCG will be in an 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
updated and the actual data plane LSPs are added or removed. updated and the actual data plane LSPs are added or removed. Note
that the incremental setup procedure of section 4.1.2. can be applied
to any of the above procedures.
4.3. Member Sharing -- Multiple VCGs per Call 4.5.1. Setting up a VCAT call and VCG
To support the member sharing scenario of section 3.2. we allow Arguably the most common operation will be simultaneously setting up
multiple VCGs within the context of the VCG Call defined here. This a VCAT call and its associated VCG at the same time. To do this when
is partially due to the requirement in reference [RFC4974] that LSPs one sets up a new VCAT call in the VCAT TLV one sets Action = 1
are associated with a single call over their lifetime. Hence we indicating that this is a new VCG for this call. LSPs would then be
propose using the VCG Call mechanism previously described to added to the call until the number of members reaches the number
establish the common member pool for all the VCGs to be included in specified in the VCAT TLV.
the scope of this particular VCG Call. Note that the maximum number
of VCGs per call is a key parameter to call acceptance or rejection
since VCAT equipment typically puts limits on the total number of
VCGs that can be simultaneously supported.
To assign a data plane LSP to be a member of a particular VCG or to Note that any other bandwidth modifications to the VCG whether up or
remove a data plane LSP from being a member of a particular VCG, down will require a new VCAT call message with an appropriately
requires additional VCG layer communications. LCAS [ITU-T-G.7042] modified TLV reflecting the new number of members.
cannot provide such signaling since it does not to provide a way to
indicate which VCG out of multiple between a source and destination a
member should belong. In particular, although, it seems that LCAS'
Group Identification (GID) bit should be useful for this purpose
reference [ITU-T-G.7042] specifically states:
"The GID provides the receiver with a means of 4.5.2. Setting up a VCAT call + LSPs with no VCG
verifying that all the arriving members originated
from one transmitter. The contents are pseudo-
random, but the receiver is not required to
synchronize with the incoming stream."
In the following we sketch the outline of such a high level VCG layer To provide for pre-establishment of the server layer connections for
signaling procedure that could make use of the Notify message as in a VCG one can establish a VCAT call without an associated VCG. In
reference [RFC4974]. addition, to provide for member sharing a pool of calls with
connections can be established, then one or more of these calls (with
accompanying connections) can be associated with a particular VCG
(via the VCG ID). Note that multiple calls can be associated with a
single VCG but that no call contains members used in more than one
VCG.
After the VCG call has been established, a signaling endpoint of the To establish a VCAT call with no VCG association when one sets up a
VCG call for would then: new VCAT call in the VCAT TLV one sets Action = 0 indicating that
this is a VCAT call without an associated VCG. LSPs can then be
added to the call. The number of members parameter in the VCAT TLV
has no meaning at this point since it reflects the intended number of
members in a VCG and not in a call. A call will know via the
containment hierarchy about its associated data plane LSPs. However,
the signal type does matter since signal types can never be mixed in
a VCG and hence a VCAT call should only contain one signal type.
1. Choose an identifier for each VCG that will use member signals 4.5.3. Associating an existing VCAT call with a VCG
from the common pool. Note that these identifiers only need to
be unique with in the context of the VCG Call.
2. Assign member signals from the common pool to each of the VCG Given a VCAT call without an associated VCG such as that set up in
utilizing the previously defined VCG IDs. Member signals are section 4.5.2. one associates it with a VCG as follows. In the VCAT
identified by their tunnel id, LSP id, and label ordinal (labels call a new notify message is sent with a CALL_DATA object with a VCAT
for control plane LSPs with multiple members are strictly TLV with Action = 1, a VCG ID, and the correct number of VCG members
ordered so we can specify an individual signal from its label specified based on adding all of the calls data plane LSPs to the VCG
order). Similarly for removing a member signal from a VCG and as members.
returning it to the common pool.
3. Coordinate with LCAS in that a member signal is first added to a Note that the total number of VCGs supported by a piece of equipment
VCG from the pool before LCAS is notified to "activate" that may be limited and hence on reception of any message with a change of
signal in the VCG. Similarly LCAS is notified to "deactivate" a VCG ID this limit should be checked. Likewise the sender of a message
member signal prior to removing it from the VCG and returning it with a change in VCG ID should be prepared to receive an error
to the pool. response. To take a particular VCG out of service, rather than just
removing all its member, a special flag element is included.
4. Note that before any LSPs or members of an LSP can be removed 4.5.4. Removing the association between a call and VCG
from the (overall) VCG Call, the originator must ensure that
signals have been removed from any of the VCGs. This is the
situation where the entire pool size is lowered.
The exact objects and formats to carry this information is to be To reuse the server layer connections in a call in another VCG one
determined. Once again the Notify mechanism would be appropriate first needs to remove the current association between the call and a
since this is information to be transferred between the VCG Call VCG. To do this, in the VCAT call a new notify message is sent with
endpoints and is not relevant to the intermediate switches. a CALL_DATA object with a VCAT TLV with Action = 3, a VCG ID, and the
correct number of VCG members specified based on removing all of the
calls data plane LSPs from the VCG as members. When the association
between a VCG and all existing calls has been removed then the VCG is
considered torn down.
5. IANA Considerations 5. Error Conditions and Codes
This document requests from IANA the assignment of ... (Don't know VCAT Call and member LSP setup can be denied for various reasons.
yet what we may want) Below is a list of error conditions that can be encountered during
these procedures. These fall under RSVP error code TBD.
6. Security Considerations These can occur when setting up a VCAT call or associating a VCG with
a VCAT call.
Error Subcode
------------------------------------ --------
VCG signal type not Supported 1
LCAS option not supported 2
Max number of VCGs exceeded 3
Max number of VCG members exceeded 4
LSP Type incompatible with VCAT call 5
6. IANA Considerations
This document requests from IANA the assignment of a new RSVP-TE
Object for CALL_DATA and a C-Type within that class for a VCAT call.
Within this VCAT C-Type are a set of code points for permissible
signal types. In addition, we request a new RSVP error code for use
with VCAT call and define a number of corresponding error sub-codes.
7. Security Considerations
This document introduces a specific use of the Notify message and This document introduces a specific use of the Notify message and
admin status object for GMPLS signaling as originally specified in admin status object for GMPLS signaling as originally specified in
[RFC4974]. It does not introduce any new signaling messages, nor [RFC4974]. It does not introduce any new signaling messages, nor
change the relationship between LSRs that are adjacent in the control change the relationship between LSRs that are adjacent in the control
plane. The call information associated with diversely routed control plane. The call information associated with diversely routed control
plane LSPs, in the event of an interception may indicate that there plane LSPs, in the event of an interception may indicate that there
are members of the same VCAT group that take a different route and are members of the same VCAT group that take a different route and
may indicate to an interceptor that the VCG call desires increased may indicate to an interceptor that the VCG call desires increased
reliability. reliability.
Otherwise, this document does not introduce any additional security Otherwise, this document does not introduce any additional security
considerations. considerations.
7. Contributors 8. Contributors
Wataru Imajuku (NTT) Wataru Imajuku (NTT)
1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847 1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847
Japan Japan
Phone +81-46-859-4315 Phone +81-46-859-4315
Email: imajuku.wataru@lab.ntt.co.jp Email: imajuku.wataru@lab.ntt.co.jp
Julien Meuric Julien Meuric
France Telecom France Telecom
skipping to change at page 14, line 32 skipping to change at page 17, line 32
Lyndon Ong Lyndon Ong
Ciena Ciena
PO Box 308 PO Box 308
Cupertino, CA 95015 Cupertino, CA 95015
United States of America United States of America
Phone: +1 408 705 2978 Phone: +1 408 705 2978
Email: lyong@ciena.com Email: lyong@ciena.com
8. Acknowledgments 9. Acknowledgments
The authors would like to thank Adrian Farrel, Maarten Vissers, The authors would like to thank Adrian Farrel, Maarten Vissers,
Trevor Wilson, Evelyne Roch, Vijay Pandian, Fred Gruman, Dan Li, Trevor Wilson, Evelyne Roch, Vijay Pandian, Fred Gruman, Dan Li,
Stephen Shew, Jonathan Saddler and Dieter Beller for extensive Stephen Shew, Jonathan Saddler and Dieter Beller for extensive
reviews and contributions to this draft. reviews and contributions to this draft.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label [RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Extensions for G.709
Optical Transport Networks Control", RFC 4328, January
2006.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, December Digital Hierarchy (SDH) Control", RFC 4606, December
2005. 2005.
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS
(GMPLS) RSVP-TE Signaling Extensions in Support of (GMPLS) RSVP-TE Signaling Extensions in Support of
Calls", RFC 4974, August 2007. Calls", RFC 4974, August 2007.
9.2. Informative References 10.2. Informative References
[ANSI-T1.105] American National Standards Institute, "Synchronous [ANSI-T1.105] American National Standards Institute, "Synchronous
Optical Network (SONET) - Basic Description including Optical Network (SONET) - Basic Description including
Multiplex Structure, Rates, and Formats", ANSI T1.105- Multiplex Structure, Rates, and Formats", ANSI T1.105-
2001, May 2001. 2001, May 2001.
[ITU-T-G.7042] International Telecommunications Union, "Link Capacity [ITU-T-G.7042] International Telecommunications Union, "Link Capacity
Adjustment Scheme (LCAS) for Virtual Concatenated Adjustment Scheme (LCAS) for Virtual Concatenated
Signals", ITU-T Recommendation G.7042, March 2006. Signals", ITU-T Recommendation G.7042, March 2006.
skipping to change at page 17, line 25 skipping to change at page 20, line 30
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. 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. 47 change blocks. 
132 lines changed or deleted 285 lines changed or added

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