CCAMP Working Group                                  G. Bernstein (ed.)
Internet Draft                                        Grotto Networking
Updates: RFC 3946                                           D. Caviglia
Category: Standards Track                                      Ericsson
Expires: April August 2008                                          R. Rabbat
                                                        H. van Helvoort
                                                        October 3, 2007
                                                       February 5, 2008

       Operating Virtual Concatenation (VCAT) and the Link Capacity
      Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label
                             Switching (GMPLS)

Status of this Memo

   By submitting this Internet-Draft, each author represents that
   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
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on October 3, 2007. August 5, 2008.


   This document describes requirements for, and use of, the Generalized
   Multi-Protocol Label Switching (GMPLS) control plane in conjunction
   with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing
   mechanism and its companion Link Capacity Adjustment Scheme (LCAS)
   which can be used for hitless dynamic resizing of the inverse
   multiplex group.  These techniques apply to Optical Transport Network
   (OTN), Synchronous Optical Network (SONET), Synchronous Digital
   Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [RFC2119].

Table of Contents

   1. Introduction...................................................3
   2. Revision History...............................................3
      2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02..........3 draft-ietf-ccamp-gmpls-vcat-lcas-03..........3
      2.2. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........3 draft-ietf-ccamp-gmpls-vcat-lcas-02..........4
      2.3. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........4
      2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........4
   3. VCAT/LCAS Scenarios and Specific Requirements..................4 Requirements..................5
      3.1. VCAT/LCAS Interface Capabilities..........................4 Capabilities..........................5
      3.2. Member Signal Configuration Scenarios.....................4 Scenarios.....................5
      3.3. VCAT Operation With or Without LCAS.......................5 LCAS.......................6
      3.4. VCGs and VCG Members......................................7
   4. GMPLS Mechanisms in Support of VCGs............................6 VCGs............................7
      4.1. VCGs Composed of a Single Co-Signaled Member Set..........7 Set..........8
         4.1.1. One-shot VCG Setup with Co-Signaled Members..........7 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 Member.....9
         4.1.4. Removing Multiple VCG Members in One Shot............9
         4.1.5. Teardown of Whole VCG................................9 VCG...............................10
      4.2. VCGs Composed of Multiple Co-Signaled Member Sets.........9 Sets........10
         4.2.1. Signaled VCG Layer Information......................10
      4.3. Call Data Object.........................................11
      4.4. VCAT TLV Object..........................................11
      4.5. Procedures for VCG Control with Multiple Co-signaled Member Sets................................................10
      4.3. Member Sharing -- Multiple VCGs per Call.................11 Sets..........13
         4.5.1. Setting up a VCAT call and VCG......................14
         4.5.2. Setting up a VCAT call + LSPs with no VCG...........14
         4.5.3. Associating an existing VCAT call with a VCG........15
         4.5.4. Removing the association between a call and VCG.....15
   5. IANA Considerations...........................................13 Error Conditions and Codes....................................16
   6. Security Considerations.......................................13 IANA Considerations...........................................16
   7. Contributors..................................................14 Security Considerations.......................................16
   8. Acknowledgments...............................................14 Contributors..................................................17
   9. References....................................................15
      9.1. Acknowledgments...............................................17
   10. References...................................................18
      10.1. Normative References.....................................15
      9.2. References....................................18
      10.2. Informative References...................................15 References..................................18
   Author's Addresses...............................................16 Addresses...............................................19
   Intellectual Property Statement..................................16 Statement..................................19
   Disclaimer of Validity...........................................17 Validity...........................................20
   Copyright Statement..............................................17
   Acknowledgment...................................................17 Statement..............................................20

1. Introduction

   The Generalized Multi-Protocol Label Switching (GMPLS) suite of
   protocols allows for the automated control of different switching
   technologies including Synchronous Optical Network (SONET),
   Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN)
   and Plesiochronous Digital Hierarchy (PDH). This document describes
   extensions to RSVP-TE to support the Virtual Concatenation (VCAT)
   layer 1 inverse multiplexing mechanism that has been standardized for
   SONET, SDH, OTN and PDH technologies along with its companion Link
   Capacity Adjustment Scheme (LCAS).

   VCAT is a TDM oriented byte striping inverse multiplexing method that
   works with a wide range of existing and emerging TDM framed signals,
   including very high bit rate OTN and SDH/SONET signals. Other than
   member signal skew compensation this layer 1 inverse multiplexing
   mechanism adds minimal additional signal delay. VCAT enables the
   selection of an optimal signal bandwidth (size), extraction of
   bandwidth from a mesh network, and, when combined with LCAS, hitless
   dynamic resizing of bandwidth and fast graceful degradation in the
   presence of network faults. To take full advantage of VCAT/LCAS
   functionality extensions to GMPLS signaling are given that enable the
   setup of diversely routed circuits that are members of the same VCAT

2. Revision History

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
      published RFCs.


2.3. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01

   o  Changed section 3.1 from "Multiple VCAT Groups per GMPLS endpoint"
      to "VCAT/LCAS Interface Capability" to improve clarity.

   o  Changed terminology from "component" signal to "member" signal
      where possible (not quoted text) to avoid confusion with link
      bundle components.

   o  Added "Dynamic, member sharing" scenario.

   o  Clarified requirements with respect to scenarios and the LCAS and
      non-LCAS cases.

   o  Added text describing needed signaling information between the
      VCAT endpoints to support required scenarios.

   o  Added text to describe: co-signaled, co-routed, data plane LSP,
      control plane LSP and their relationship to the VCAT/LCAS

   o  Change implementation mechanism from one based on the Association
      object to one based on "Call concepts" utilizing the Notify


2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00

   o  Updated reference from RFC3946bis to issued RFC4606

   o  Updated section 3.2 based on discussions on the mailing list

3. VCAT/LCAS Scenarios and Specific Requirements

   There are a number of specific requirements for the support of
   VCAT/LCAS in GMPLS that can be derived from the carriers'
   application-specific demands for the use of VCAT/LCAS and from the
   flexible nature of VCAT/LCAS.  These are set out in the following

3.1. VCAT/LCAS Interface Capabilities

   In general, an LSR can be ingress/egress of one or more VCAT groups.
   VCAT and LCAS are interface capabilities.  An LSR may have, for
   example, VCAT-capable interfaces that are not LCAS-capable.  It may
   at the same time have interfaces that are neither VCAT nor LCAS-

3.2. Member Signal Configuration Scenarios

   We list in this section the different scenarios.  Here we use the
   term "VCG" to refer to the entire VCAT group and the terminology
   "set" and "subset" to refer to the collection of potential VCAT group
   member signals.

   o  Fixed, co-routed: A fixed bandwidth VCG, transported over a co-
      routed set of member signals.  This is the case where the intended
      bandwidth of the VCG does not change and all member signals follow
      the same route to minimize differential delay.  The intent here is
      the capability to allocate an amount of bandwidth close to that
      required at the client layer.

   o  Fixed, diversely routed: A fixed bandwidth VCG, transported over
      at least two diversely routed subsets of member signals.  In this
      case, the subsets are link-disjoint over at least one link of the
      route.  The intent here is more efficient use of network
      resources, e.g., no unique route has the required bandwidth.

   o  Fixed, member sharing: A fixed bandwidth VCG, transported over a
      set of member signals that are allocated from a common pool of
      available member signals without requiring member connection
      teardown and setup.

   o  Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or
      decreased via the addition or removal of member signals),
      transported over a co-routed set of members.  The intent here is
      dynamic resizing and resilience of bandwidth.

   o  Dynamic, diversely routed: A dynamic VCG (bandwidth can be
      increased or decreased via the addition or removal of member
      signals), transported over at least two diversely routed subsets
      of member signals.  The intent here is efficient use of network
      resources, dynamic resizing and resilience of bandwidth.

   o  Dynamic, member sharing: A dynamic bandwidth VCG, transported over
      a set of member signals that are allocated from a common pool of
      available member signals without requiring member connection
      teardown and setup.

3.3. VCAT Operation With or Without LCAS

   VCAT capabilities may be present with or without the presence of
   LCAS.  The use of LCAS is beneficial to the provision of services,
   but in the absence of LCAS, VCAT is still a valid technique.
   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
   available.  The GMPLS procedures for the two cases SHOULD be

   o  GMPLS signaling for LCAS-capable interfaces MUST support all
      scenarios of section 3.2. with no loss of traffic.

   o  GMPLS signaling for non-LCAS-capable interfaces MUST support only
      the "fixed" scenarios of section 3.2.

   To provide for these requirements GMPLS signaling MUST carry the
   following information on behalf of the VCAT endpoints:

   o  The type of the member signal that the VCG will contain, e.g., VC-
      3, VC-4, etc.

   o  The total number of member to be in the VCG. This provides the
      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
      will let the receiving endpoint know when all members of the VCG
      have been established.

   o  Identification of the VCG and its associated members. This
      provides information that allows the endpoints to differentiate
      multiple VCGs and to tell what members (LSPs) to associate with a
      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

   We describe in this section the signaling mechanisms that already
   exist in GMPLS using RSVP-TE [RFC3473] and [RFC4328], and the
   extensions needed to completely support the requirements of section

   When utilizing GMPLS with VCAT/LCAS we utilize a number of control
   and data plane concepts that we describe below.

  1. VCG member -- This is an individual data plane signal of one of the
     permitted SDH, SONET, OTN or PDH signal types.

  2. Co-signaled member set -- One or more VCG members (or potential
     members) set up via the same control plane signaling exchange. Note
     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
     route. Although VCG members may follow the same path, this does not
     imply that they were co-signaled.

  4. Data plane LSP -- for our purposes here, this is equivalent to an
     individual VCG member.

  5. Control plane LSP -- A control plane entity that can control
     multiple data plane LSPs. For our purposes here this is equivalent
     to our co-signaled member set.

   Section 4.1 is included for informational purposes only.  It
   describes existing GMPLS procedures that support a single VCG
   composed of a single co-signaled member set.

   Section 4.2 describes new procedures to support VCGs composed of more
   than one co-signaled member sets. This includes the important
   application of a VCG composed of diversely routed members.  Where
   possible it reuses applicable existing procedures from section 4.1.

4.1. VCGs Composed of a Single Co-Signaled Member Set

   Note that this section is for informational purposes only.

   The existing GMPLS signaling protocols support a VCG composed of a
   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
   LSP is used in support of the VCG.

   There are two options for setting up the VCG, depending on hardware
   capability, or management preferences: one-shot setup and incremental

   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
   SONET VCAT group).

4.1.1. One-shot VCG Setup with Co-Signaled Members

   An RSVP-TE Path message is used with the following parameters.

   With regards to the traffic parameters, the elementary signal is
   chosen (6 for VC-4/STS-3c_SPE).  The value of NVC is then set to 7.

   A Multiplier Transform greater than 1 (say N>1) is used if the
   operator wants to set up N VCAT groups that will belong to, and be
   assigned to, one LSP.

   SDH or SONET labels in turn have to be assigned for each member of
   the VCG and concatenated to form a single Generalized Label
   constructed as an ordered list of 32-bit timeslot identifiers of the
   same format as TDM labels.  [RFC4606] requires that the order of the
   labels reflect the order of the payloads to concatenate, and not the
   physical order of time-slots.

4.1.2. Incremental VCG Setup with Co-Signaled Members

   In some cases, it may be necessary or desirable to set up the VCG
   members individually, or to add group members to an existing group.

   One example of this need is when the hardware that supports VCAT can
   only add VCAT elements one at a time or cannot automatically match
   the elements at the ingress and egress for the purposes of inverse
   multiplexing.  Serial or incremental setup solves this problem.

   In order to accomplish incremental setup an iterative process is used
   to add group members.  For each iteration, NVC is incremented up to
   the final value required.  The iteration consists of the successful
   completion of Path and Resv signaling.  At first, NVC = 1 and the
   label includes just one timeslot identifier

   At each of the next iterations, NVC is set to (NVC +1), one more
   timeslot identifier is added to the ordered list in the Generalized
   Label (in the Path or Resv message).  A node that receives a Path
   message that contains changed fields will process the full Path
   message and, based on the new value of NVC, it will add a component
   signal to the VCAT group, and switch the new timeslot based on the
   new label information.

   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
   signaling for this function is described in [ITU-T-G.7042].

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
   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
   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
   identifier for the dropped component is removed from the ordered list
   in the Generalized Label.

   Note that for interfaces that are not LCAS-capable, removing one
   component of the VCG will result in errors in the inverse-
   multiplexing procedure of VCAT and result in the teardown of the
   whole group.  So, this is a feature that only LCAS-capable VCAT
   interfaces can support without management intervention at the end

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
   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 Generalized Label.  This procedure is also not supported for
   VCAT-only interfaces without management intervention as removing one
   or more components of the VCG will tear down the whole group.

4.1.5. Teardown of Whole VCG

   The entire LSP is deleted in a single step (i.e., all components are
   removed in one go) using deletion procedures of [RFC3473].

4.2. VCGs Composed of Multiple Co-Signaled Member Sets

   The motivation for VCGs composed of multiple co-signaled member sets
   comes from the requirement to support VCGs with diversely routed
   members. The initial GMPLS specification did not support diversely
   routed signals using the NVC construct.  In fact, [RFC4606] says:

         [...] The standard definition for virtual concatenation allows
         each virtual concatenation components to travel over diverse
         paths.  Within GMPLS, virtual concatenation components must
         travel over the same (component) link if they are part of the
         same LSP.  This is due to the way that labels are bound to a
         (component) link.  Note however, that the routing of components
         on different paths is indeed equivalent to establishing
         different LSPs, each one having its own route.  Several LSPs
         can be initiated and terminated between the same nodes and
         their corresponding components can then be associated together
         (i.e., virtually concatenated).

   The setup of diversely routed VCG members requires multiple co-
   signaled VCG member sets, i.e., multiple control plane LSPs.

   To support a VCG with multiple co-signaled VCG members sets requires
   being able to identify separate control plane LSPs with a single VCG
   and exchange information pertaining to the VCG as a whole. This is
   very similar to the "Call" concept described in [RFC4974]. We can
   think of our VCAT/LCAS connection, e.g., our VCG, as a higher layer
   service that makes use of multiple lower layer (server) connections
   that are controlled by one or more control plane LSPs.

4.2.1. Signaled VCG Layer Information

   When a VCG is composed of multiple co-signaled member sets, none of
   the control plane LSP's signaling information can contain information
   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
   Call layer, i.e., between the VCG signaling endpoints.  To
   accommodate this information additional objects or TLVs would need to
   be are
   incorporated into the Notify message as it is described for use in
   call signaling in [RFC4974].

   VCG Call setup information signaled via the Notify message with the
   Call management bit (C-bit) set:

     1. Signal Type

     2. Number of VCG Members

     3. LCAS requirements:

          a. LCAS required

          b. LCAS desired

          c. LCAS not desired (but acceptable)

          d. LCAS not acceptable

     4. Maximum Number of VCG Identifier - Used to identify a particular VCG separately
        from the call ID so that call members can be reused with
        different VCGs per Call-- This is a hook to support the requirements for member sharing scenario. In the non-member sharing case the
        value is one.

4.2.2. Procedures for VCG Control with Multiple Co-signaled Member Sets

   This section deals only with and the case
        requirements of one VCG per (VCG) Call. To
   establish a VCG, section 3.4.

4.3. Call Data Object

   In RFC4974 the general mechanism for communicating call information of section 4.2.1.
   via notify messages is exchanged given. In general different types of calls
   will need to convey call related information during call
   establishment and
   agreed upon with the corresponding VCG signaling endpoint. Since only
   one VCG is being signaled by this call, all control plane LSPs used
   with this call establish members updates. We define a general CALL_DATA object for this VCG
   inclusion in call related notify messages and there is no
   ambiguity as to which VCG define a potential member belongs. Procedures specific class
   type (C-Type) for
   addition and removal of bandwidth are the same as VCAT calls.

4.4. VCAT TLV Object

   For use in the single co-
   signaled case except that a VCG Call layer message should precede any
   of those changes and indicate CALL_DATA object (of VCAT-Call C-Type) in Notify
   messages we define the new total number following VCAT TLV:

       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
      | Signal Type                   |      Number of VCG members.

   In general Members        |
      | LCAS Req      |  Action       |            VCG ID             |
   Signal Type can take the following order is used to establish values and increase MUST never change over
   bandwidth in lifetime of a VCG:

     1. VCG Call layer information

      Value  Type (Elementary Signal)
      -----  ------------------------
        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)

   Number of Members is conveyed. Note that during a
        "bandwidth" change only non-negative integer that indicates the total
   number of VCG members is
        allowed to change.

     2. Control Plane LSPs are used to add data plane LSPs (members) to in the VCG.

     3. If LCAS is supported on this VCG call it should (not just the call)and MUST be instructed by changed
   over the endpoints life of the VCG to "activate" indicate the member.

   In general current number of members.

   LCAS Required can take the following order is used when decreasing values and MUST NOT change over
   the bandwidth
   in life of a VCG:

     1. VCG Call layer information is conveyed concerning the decreased
        number of VCG members.

     2. If

      Value                Meaning
      -----    ---------------------------------
      0        LCAS required
      1        LCAS desired
      2        LCAS not desired (but acceptable)
      3        LCAS not acceptable

   Action is supported on this VCG used to indicate the relationship between the call it should be instructed by and the endpoints to "deactivate"
   VCG and takes the members following values.

      Value                Meaning
      -----    ---------------------------------
      0        No VCG ID (set up call prior to be removed.

     3. Existing control plane LSPs are 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 remove the data plane
        LSPs (members).

   Note that when LCAS is not used or unavailable the identify a particular
   VCG will be in an
   unknown state between the time within a session. This number MUST NOT change over the lifetime
   of a VCG call level information is
   updated and but can change over the actual data plane LSPs are added or removed.

4.3. Member Sharing -- Multiple VCGs per Call lifetime of a call. To support the
   member sharing scenario of section 3.2. we allow
   multiple VCGs within and the context requirements of
   section 3.4. we allow the VCG Call defined here. This
   is partially due Identifier within a call to be changed.
   In this way the requirement in reference [RFC4974] that LSPs
   are connections associated with a single call over their lifetime. Hence we
   propose using the VCG Call mechanism previously described can be dedicated
   establish the common member pool a new VCG (allowing for all the VCGs to be included in
   the scope of this particular a priori connection establishment and
   connection persistence after a VCG Call. Note that the maximum number 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 VCGs per call is establishment or update. A VCG can be
   established at the same time as a key parameter to new call acceptance or rejection
   since 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 equipment typically puts limits on TLV MUST
   precede any of those changes and indicate the new total number of
   VCGs that VCG

   The following mechanisms can be simultaneously supported.

   To assign a data plane LSP used to be a member increase the bandwidth of a particular VCG or

   o  LSPs are added to
   remove a data plane LSP from being VCAT Call associated with a member 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 particular VCG,
   requires additional VCG layer communications. in a hitless fashion when LCAS [ITU-T-G.7042]
   cannot provide such signaling since it does not 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 provide
      the attempted increase.

   2. Either: (a) New LSPs are set up within a way call associated with the
      VCG, or (b) LSPs in an existing call are now associated with the

   3. The internal LCAS entity is instructed by the endpoints to
   indicate which
      "activate" the new VCG out member(s).

   The following mechanisms can be used to decrease the bandwidth of multiple between a source and destination

   o  LSPs are removed from a
   member should belong. VCAT Call associated with a VCG (Action =

   o  A VCG association is removed from existing VCAT call containing
      LSPs (Action = 3).

   In particular, although, it seems 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 LCAS'
   Group Identification (GID) bit should when LCAS is not used or unavailable the VCG will be in an
   unknown state between the time the VCG call level information is
   updated and the actual data plane LSPs are added or removed. Note
   that the incremental setup procedure of section 4.1.2. can be useful applied
   to any of the above procedures.

4.5.1. Setting up a VCAT call and VCG

   Arguably the most common operation will be simultaneously setting up
   a VCAT call and its associated VCG at the same time. To do this when
   one sets up a new VCAT call in the VCAT TLV one sets Action = 1
   indicating that this is a new VCG for this purpose
   reference [ITU-T-G.7042] specifically states:

          "The GID provides call.  LSPs would then be
   added to the receiver call until the number of members reaches the number
   specified in the VCAT TLV.

   Note that any other bandwidth modifications to the VCG whether up or
   down will require a new VCAT call message with an appropriately
   modified TLV reflecting the new number of members.

4.5.2. Setting up a means VCAT call + LSPs with no VCG

   To provide for pre-establishment of
          verifying that all the arriving members originated
          from server layer connections for
   a VCG one transmitter. The contents are pseudo-
          random, can establish a VCAT call without an associated VCG. In
   addition, to provide for member sharing a pool of calls with
   connections can be established, then one or more of these calls (with
   accompanying connections) can be associated with a particular VCG
   (via the VCG ID). Note that multiple calls can be associated with a
   single VCG but that no call contains members used in more than one

   To establish a VCAT call with no VCG association when one sets up a
   new VCAT call in the receiver VCAT TLV one sets Action = 0 indicating that
   this is not required a VCAT call without an associated VCG.  LSPs can then be
   added to
          synchronize with the incoming stream."

   In call. The number of members parameter in the following we sketch VCAT TLV
   has no meaning at this point since it reflects the outline intended number of such
   members in a high level VCG layer
   signaling procedure that could make use of the Notify message as and not in
   reference [RFC4974].

   After 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 has been established, should only contain one signal type.

4.5.3. Associating an existing VCAT call with a signaling endpoint of the VCG

   Given a VCAT call for would then:

     1. Choose without an identifier for each associated VCG such as that will use member signals
        from set up in
   section 4.5.2. one associates it with a VCG as follows. In the common pool. Note that these identifiers only need to
        be unique VCAT
   call a new notify message is sent with in a CALL_DATA object with a VCAT
   TLV with Action = 1, a VCG ID, and the context correct number of the VCG Call.

     2. Assign member signals from members
   specified based on adding all of the common pool calls data plane LSPs to each of the VCG
   as members.

   Note that the previously defined VCG IDs.  Member signals are
        identified total number of VCGs supported by their tunnel id, LSP id, a piece of equipment
   may be limited and label ordinal (labels
        for control plane LSPs hence on reception of any message with multiple members are strictly
        ordered so we can specify a change of
   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 individual signal from its label
        order). Similarly for error
   response. To take a particular VCG out of service, rather than just
   removing all its member, a member signal from special flag element is included.

4.5.4. Removing the association between a VCG call and
        returning it to VCG

   To reuse the common pool.

     3. Coordinate with LCAS server layer connections in that a member signal is call in another VCG one
   first added needs to a
        VCG from remove the pool before LCAS is notified to "activate" that
        signal in current association between the call and a
   VCG. Similarly LCAS  To do this, in the VCAT call a new notify message is notified to "deactivate" sent with
   a CALL_DATA object with a VCAT TLV with Action = 3, a
        member signal prior to removing it from the VCG ID, and returning it
        to the pool.

     4. Note that before any LSPs or
   correct number of VCG members specified based on removing all of an LSP can be removed the
   calls data plane LSPs from the (overall) VCG Call, as members. When the originator must ensure that
        signals have association
   between a VCG and all existing calls has been removed from any of the VCGs. This is the
        situation where then the entire pool size VCG is lowered.

   The exact objects
   considered torn down.

5. Error Conditions and formats to carry this information is to be
   determined. Once again the Notify mechanism would Codes

   VCAT Call and member LSP setup can be appropriate
   since this denied for various reasons.
   Below is information to a list of error conditions that can be transferred between the encountered during
   these procedures.  These fall under RSVP error code TBD.

   These can occur when setting up a VCAT call or associating a VCG Call
   endpoints and is with
   a VCAT call.

   Error                                  Subcode
   ------------------------------------   --------
   VCG signal type not relevant to the intermediate switches.

5. 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 ... (Don't know
   yet what 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 may want)

6. 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
   admin status object for GMPLS signaling as originally specified in
   [RFC4974].  It does not introduce any new signaling messages, nor
   change the relationship between LSRs that are adjacent in the control
   plane.  The call information associated with diversely routed control
   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
   may indicate to an interceptor that the VCG call desires increased

   Otherwise, this document does not introduce any additional security


8. Contributors

   Wataru Imajuku (NTT)
   1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847

   Phone +81-46-859-4315

   Julien Meuric
   France Telecom
   2, avenue Pierre Marzin
   22307 Lannion Cedex

   Phone: + 33 2 96 05 28 28

   Lyndon Ong
   PO Box 308
   Cupertino, CA 95015
   United States of America

   Phone: +1 408 705 2978


9. Acknowledgments

   The authors would like to thank Adrian Farrel, Maarten Vissers,
   Trevor Wilson, Evelyne Roch, Vijay Pandian, Fred Gruman, Dan Li,
   Stephen Shew, Jonathan Saddler and Dieter Beller for extensive
   reviews and contributions to this draft.


10. References


10.1. Normative References

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3473]      Berger, L., "Generalized Multi-Protocol Label
                  Switching (GMPLS) Signaling Resource ReserVation
                  Protocol-Traffic Engineering (RSVP-TE) Extensions",
                  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

   [RFC4606]      Mannie, E. and D. Papadimitriou, "Generalized Multi-
                  Protocol Label Switching (GMPLS) Extensions for
                  Synchronous Optical Network (SONET) and Synchronous
                  Digital Hierarchy (SDH) Control", RFC 4606, December

   [RFC4974]      Papadimitriou, D. and A. Farrel, "Generalized MPLS
                  (GMPLS) RSVP-TE Signaling Extensions in Support of
                  Calls", RFC 4974, August 2007.


10.2. Informative References

   [ANSI-T1.105]  American National Standards Institute, "Synchronous
                  Optical Network (SONET) - Basic Description including
                  Multiplex Structure, Rates, and Formats", ANSI T1.105-
                  2001, May 2001.

   [ITU-T-G.7042] International Telecommunications Union, "Link Capacity
                  Adjustment Scheme (LCAS) for Virtual Concatenated
                  Signals", ITU-T Recommendation G.7042, March 2006.

   [ITU-T-G.7043] International Telecommunications Union, "Virtual
                  Concatenation of Plesiochronous Digital Hierarchy
                  (PDH) Signals", ITU-T Recommendation G.7043, July

   [ITU-T-G.707]  International Telecommunications Union, "Network Node
                  Interface for the Synchronous Digital Hierarchy
                  (SDH)", ITU-T Recommendation G.707, December 2003.

   [ITU-T-G.709]  International Telecommunications Union, "Interfaces
                  for the Optical Transport Network (OTN)", ITU-T
                  Recommendation G.709, March 2003.

Author's Addresses

   Greg Bernstein
   Grotto Networking

   Phone: +1-510-573-2237

   Diego Caviglia
   Via A. Negrone 1/A 16153
   Genoa Italy

   Phone: +39 010 600 3736
   Email: diego.caviglia@(,

   Richard Rabbat


   Huub van Helvoort
   Huawei Technologies, Ltd.
   Kolkgriend 38, 1356 BC Almere
   The Netherlands

   Phone:   +31 36 5315076

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The IETF Trust (2007). (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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.