[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-bernstein-ccamp-gmpls-vcat-lcas) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 6344

CCAMP Working Group                                  G. Bernstein (ed.)
Internet Draft                                        Grotto Networking
Updates: 4606                                               D. Caviglia
Category: Standards Track                                      Ericsson
Expires: September 2011                                       R. Rabbat
                                                                 Google
                                                        H. van Helvoort
                                                                 Huawei
                                                          March 9, 2011


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



                  draft-ietf-ccamp-gmpls-vcat-lcas-11.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on September 9, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Bernstein             Expires September 9, 2011                [Page 1]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


   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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Abstract

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

Conventions used in this document

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

Table of Contents


   1. Introduction...................................................3
   2. VCAT/LCAS Scenarios and Specific Requirements..................4
      2.1. VCAT/LCAS Interface Capabilities..........................4
      2.2. Member Signal Configuration Scenarios.....................4
      2.3. VCAT Operation With or Without LCAS.......................5
      2.4. VCGs and VCG Members......................................6
   3. VCAT Data and Control Plane Concepts...........................6
   4. VCGs Composed of a Single Member Set (One LSP).................7
      4.1. One-shot VCG Setup........................................7
      4.2. Incremental VCG Setup.....................................8
      4.3. Procedure for VCG Reduction by Removing a Member..........8
      4.4. Removing Multiple VCG Members in One Shot.................9
      4.5. Teardown of Whole VCG.....................................9
   5. VCGs Composed of Multiple Member Sets (Multiple LSPs)..........9
      5.1. Signaled VCG Service Layer Information...................10


Bernstein             Expires September 9, 2011                [Page 2]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


      5.2. CALL ATTRIBUTES Object VCAT TLV..........................11
      5.3. Procedures for Multiple Member Sets......................13
         5.3.1. Setting up a new VCAT call and VCG Simultaneously...13
         5.3.2. Setting up a VCAT call + LSPs without a VCG.........13
         5.3.3. Associating an existing VCAT call with a new VCG....14
         5.3.4. Removing the association between a call and VCG.....14
         5.3.5. VCG Bandwidth modification..........................14
   6. Error Conditions and Codes....................................15
   7. IANA Considerations...........................................16
      7.1. RSVP CALL_ATTRIBUTE TLV..................................16
      7.2. RSVP Error Codes and Error Values........................16
   8. Security Considerations.......................................17
   9. Contributors..................................................18
   10. Acknowledgments..............................................18
   11. References...................................................19
      11.1. Normative References....................................19
      11.2. Informative References..................................19
   Author's Addresses...............................................20
   Intellectual Property Statement..................................21
   Disclaimer of Validity...........................................21
   Acknowledgment...................................................21

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)[ANSI-
   T1.105], Synchronous Digital Hierarchy (SDH)[ITU-T-G.707], Optical
   Transport Network (OTN)[ITU-T-G.709] and Plesiochronous Digital
   Hierarchy (PDH)[ITU-T-G.704]. This document updates the procedures of
   [RFC4606] to allow supporting additional applications of the Virtual
   Concatenation (VCAT) layer 1 inverse multiplexing mechanism that has
   been standardized for SONET, SDH, OTN and PDH [ITU-T-G.707, ITU-T-
   G.709, and ITU-T-G.7043] technologies along with its companion Link
   Capacity Adjustment Scheme (LCAS) [ITU-T-G.7042].

   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. VCAT enables
   the selection of an optimal signal server bandwidth (size) utilizing
   a group of server signals and provides for efficient use of bandwidth
   in a mesh network. When combined with LCAS, hitless dynamic resizing
   of bandwidth and fast graceful degradation in the presence of network
   faults can be supported. To take full advantage of VCAT/LCAS
   functionality, additional extensions to GMPLS signaling are needed
   that enable the setup of diversely routed signals that are members of
   the same VCAT group. Note that the scope of this document is limited


Bernstein             Expires September 9, 2011                [Page 3]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


   to scenarios where all member signals of a VCAT group are controlled
   using mechanisms defined in this document and related RFCs. Scenarios
   where a subset of member signals are controlled by a management plane
   or a proprietary control plane are outside the scope of this
   document.

2. 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'
   applications for the use of VCAT/LCAS.  These are set out in the
   following section.



2.1. VCAT/LCAS Interface Capabilities

   In general, an LSR can be ingress/egress of one or more VCAT groups.
   VCAT and LCAS are data plane 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-capable.

2.2. Member Signal Configuration Scenarios

   We list in this section the different scenarios.  Here we use the
   [ITU-T-G.707] term "VCG" to refer to the VCAT group and the
   terminology "set" and "subset" to refer to the subdivision of the
   group and the individual VCAT group member signals. As noted above,
   the scope of these scenarios is limited to scenarios where all member
   signals are controlled using mechanisms defined in this document.

   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 application
      here is the capability to allocate an amount of bandwidth close to
      that required at the client layer.

   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 application here is more efficient use of network
      resources, e.g., no unique route has the required bandwidth.





Bernstein             Expires September 9, 2011                [Page 4]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


   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. This document only covers the case where this
      pool of "potential" member signals has been established via
      mechanisms defined in this document. Note that by the nature of
      VCAT, a member signal can only belong to one VCG at a time. To be
      used in a different VCG, a signal must first be removed from any
      VCG to which it may belong.

   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 application here
      is dynamic resizing and resilience of bandwidth.

   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 application here is efficient use of network
      resources, dynamic resizing and resilience of bandwidth.

   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.

2.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 in the provisioning of flexible
   bandwidth 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 identical.

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

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

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

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


Bernstein             Expires September 9, 2011                [Page 5]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


     .   The total number of members to be in the VCG. This provides the
       endpoints in both the LCAS and non-LCAS case with information on
       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.

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

2.4. VCGs and VCG Members

   The signaling solution SHOULD provide a mechanism to support these
      scenarios:

     .   VCG members (server layer connections) may be set up prior to
       their use in a VCG.

     .   VCG members (server layer connections) may exist after their
       corresponding VCG has been removed.

   However, it is not required that any arbitrarily created server layer
   connection be supported in the above scenarios, i.e., connections
   established without following the procedures of this document.

3. VCAT Data and Control Plane Concepts

   When utilizing GMPLS with VCAT/LCAS, we use a number of control and
   data plane concepts described below.

  VCG -- This is the group of data plane server layer signals used to
     provide the bandwidth for the virtual concatenation link connection
     through a network ([G7042]).

  VCG member -- This is an individual data plane server layer signal
     that belongs to a VCG ([G7042]).

  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 member set follow the same route.

  Data plane LSP -- This is an individual VCG member.

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


Bernstein             Expires September 9, 2011                [Page 6]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


  Call - A control plane mechanism for providing association between
     endpoints and possibly key transit points.


4. VCGs Composed of a Single Member Set (One LSP)

   In this section and the next section, we will describe the procedures
   for supporting the applications described in Section 2.

   This section describes the support of a single VCG composed of a
   single member set (in support of the fixed, co-routed application and
   the dynamic, co-routed application) using existing GMPLS procedures
   [RFC4606]. Note that this section is included for informational
   purposes only.

   The existing GMPLS signaling protocols support a VCG composed of a
   single 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 policy
   preferences: one-shot setup and incremental setup.

   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) which is composed of 7 virtually concatenated VC-4s
   (or STS-3c).

4.1. One-shot VCG Setup

   This section describes establishment of an LSP that supports all VCG
   members as part of the initial LSP establishment. To establish such
   an LSP, an RSVP-TE Path message is sent containing the SONET/SDH
   Traffic Parameters defined in [RFC4606]. In the case of this example:

     . Elementary signal is set to 6 (for VC-4/STS-3c_SPE).

     . NVC is set to 7 (number of members).

     . Per [RFC4606] a Multiplier Transform greater than 1 (say N>1)
        may be used if the operator wants to set up N identical VCAT
        groups (for the same LSP).







Bernstein             Expires September 9, 2011                [Page 7]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


     . SDH or SONET labels 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.

     . Refer to [RFC4606] for other traffic parameter settings.

4.2. Incremental VCG Setup

   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 local policy requires that VCAT
   can only add VCAT members one at a time or cannot automatically match
   the members 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.  A successful 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 (identifying the new member)
   to the LSP, in the data plane, LCAS may be used to add the new member
   at the end points into the existing VCAT group.  LCAS (data plane)
   signaling is described in [ITU-T-G.7042].

4.3. Procedure for VCG Reduction by Removing a Member

   The procedure to remove a component signal is similar to that used to
   add components as described in Section 4. 2.  In the data plane, LCAS
   signaling is used 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


Bernstein             Expires September 9, 2011                [Page 8]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


   list in the Generalized Label.

   Note that for interfaces that are not LCAS-capable, removing one
   component of the VCG will result in failure detection of the member
   at the end point and failure of the whole group (per ITU-T
   definition).  So, this is a feature that only LCAS-capable VCAT
   interfaces can support without management intervention at the end
   points.

   Note if using LCAS, a VCG member can be temporary removed from the
   VCG due to a failure of the component signal. The LCAS data plane
   signaling will take appropriate actions to adjust the VCG as
   described in [ITU-T-G.7042].

4.4. Removing Multiple VCG Members in One Shot

   The procedure is similar to 4.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.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].

5. VCGs Composed of Multiple Member Sets (Multiple LSPs)

   The motivation for VCGs composed of multiple 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.  [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).



Bernstein             Expires September 9, 2011                [Page 9]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


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

   The support of a VCG with multiple VCG members sets requires being
   able to identify separate sets of control plane LSPs with a single
   VCG and exchange information pertaining to the VCG as a whole between
   the endpoints. This document updates the procedures of [RFC4606] to
   provide this capability by using the call procedures and extensions
   described in [RFC4974]. The VCG makes use of one or more calls (VCAT
   calls) to associate control plane LSPs in support of VCG server layer
   connections (VCG members) in the data plane. Note, the trigger for
   the VCG (by management plane or client layer) is outside the scope of
   this document. These procedures provide for autonomy of the client
   layer and server layer with respect to their management.

   In addition, by supporting the identification of a VCG (VCG ID) and
   VCAT call identification (VCAT Call ID), support can be provided for
   the member sharing scenarios, i.e. by explicitly separating the VCG
   ID from the VCAT call ID. Note that per [RFC4974], LSPs (connections)
   cannot be moved from one call to another, hence to support member
   sharing, the procedures in this document provide support by moving
   call(s) and their associated LSPs from one VCG to another. Figure 1
   below illustrates these relationships, however, note, VCAT calls can
   exist independently of a VCG (for connection pre-establishment) as
   will be described later in this document.

    +-------+      +-------------+      +-------+      +------------+
    |       |1    n|             |1    n|       |1    n| Data Plane |
    |  VCG  |<>----|  VCAT Call  |<>----|  LSP  |<>----| Connection |
    |       |      |             |      |       |      |(co-routed) |
    +-------+      +-------------+      +-------+      +------------+
    Figure 1 Figure 1. Conceptual containment relationship between VCG,
        VCAT calls, control plane LSPs, and data plane connections.

5.1. Signaled VCG Service Layer Information

   In this section, we provide a list of information that will be
   communicated at the VCG level, i.e., between the VCG signaling
   endpoints using the call procedures of [RFC4974].  To accommodate the
   VCG information, a new TLV is defined in this document for the CALL
   ATTRIBUTES Object [RFC6001] for use in the Notify message [RFC4974].
   The Notify message is a targeted message and does not need to follow
   the path of LSPs through the network i.e. there is no dependency on
   the member signaling for establishing the VCAT call and does not
   preclude the use of external call managers as described in [RFC4974].

   The following information is needed:


Bernstein             Expires September 9, 2011               [Page 10]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


     1. Signal Type

     2. Number of VCG Members

     3. LCAS requirements:

          a. LCAS required

          b. LCAS desired

          c. LCAS not supported

     4. VCG Identifier - Used to identify a particular VCG separately
        from the call ID so that call members can be reused with
        different VCGs per the requirements for member sharing and the
        requirements of section 2.4.

5.2. CALL ATTRIBUTES Object VCAT TLV

   This document defines a CALL_ATTRIBUTES object VCAT TLV for use in
   the CALL_ATTRIBUTES object [RFC6001] as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Type = TBA             |     Length = 12               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Signal Type                   |      Number of Members        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | LCAS Req      |  Action       |            VCG ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type, as defined in [RFC6001].  This field MUST be set to  TBA (by
   IANA).

   Length, as defined in [RFC6001].  This field MUST be set to 12.

   Signal Type: 16 bits

     The signal types can never be mixed in a VCG (per ITU-T definition)
     and hence a VCAT call contains only one signal type. This field can
     take the following values and MUST never change over the lifetime
     of a VCG [ANSI-T1-105, ITU-T-G.707, ITU-T-G.709, ITU-T-G.7043]:





Bernstein             Expires September 9, 2011               [Page 11]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


      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     ODU1 (i.e., 2.5 Gbit/s
       12     ODU2 (i.e., 10  Gbit/s)
       13     ODU3 (i.e., 40  Gbit/s)
       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: 16 bits

     This field is an unsigned integer that MUST indicate the total
     number of members in the VCG (not just the call).  This field MUST
     be changed (over the life of the VCG) to indicate the current
     number of members.



   LCAS Required: 8 bits

     This field can take the following values and MUST NOT change over
     the life of a VCG:


      Value                Meaning
      -----    ---------------------------------
      0        LCAS required
      1        LCAS desired
      2        LCAS not supported

   Action: 8 bits

     This field is used to indicate the relationship between the call
     and the VCG and has the following values.









Bernstein             Expires September 9, 2011               [Page 12]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


      Value                Meaning
      -----    ---------------------------------
      0        No VCG ID (set up call prior to VCG creation)
      1        New VCG for Call
      2        Modification of number of members (No Change in VCG ID)
      3        Remove VCG from Call


   VCG Identifier (ID): 16 bit

     This field carries an unsigned integer that is used to identify a
     particular VCG within a session. The value of the field MUST NOT
     change over the lifetime of a VCG but MAY change over the lifetime
     of a call.

5.3. Procedures for Multiple Member Sets

   The creation of a VCG based on multiple member sets requires the
   establishment of at least one VCAT layer call. VCAT layer calls and
   related LSPs (connections) MUST follow the procedures as defined in
   [RFC4974] with the addition of the inclusion of a CALL_ATTRIBUTES
   object containing the VCAT TLV. Multiple VCAT layer calls per VCG are
   not required to support member sets, but are needed to support
   certain member sharing scenario.

   The remainder of this section provides specific procedures related to
   VCG signaling.  The procedures of [RFC4974] are only modified as
   discussed in this section.

   When LCAS is supported, the data plane will add or decrease the
   members per [G7042]. When LCAS is not supported across LSPs, the data
   plane coordination across member sets, is outside the scope of this
   document.

5.3.1. Setting up a new VCAT call and VCG Simultaneously

   To simultaneously set up a VCAT call and identify it with an
   associated VCG, a CALL_ATTRIBUTES object containing the VCAT TLV
   MUSTbe included in the Notify message at the time of call setup.  The
   VCAT TLV Action field MUST be set to 1, which indicates that this is
   a new VCG for this call.  LSPs MUST then be added to the call until
   the number of members reaches the number specified in the VCAT TLV.

5.3.2. Setting up a VCAT call + LSPs without a VCG

   To provide for pre-establishment of the server layer connections for
   a VCG a VCAT call MAY be established without an associated VCG


Bernstein             Expires September 9, 2011               [Page 13]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


   identifier. In fact, to provide for the member sharing scenario, a
   pool of VCAT calls with associated connections (LSPs) can be
   established, and 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 a call MUST NOT contain members used in more than one VCG.

   To establish a VCAT call with no VCG association, a CALL_ATTRIBUTES
   object containing the VCAT TLV MUST be included at the time of call
   setup in the Notify message.  The VCAT TLV Action field MUST be set
   to 0, which indicates that this is a VCAT call without an associated
   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.

5.3.3. Associating an existing VCAT call with a new VCG

   A VCAT call that is not otherwise associated with a VCG may be
   associated with a VCG.  To establish such an association a Notify
   message MUST be sent with a CALL_ATTRIBUTES object containing a VCAT
   TLV. The TLV's Action field MUST be set to 1, the VCG Identifier
   field MUST be set to correspond to the VCG.  The number of members
   field MUST equal the sum of all LSPs associated with the VCG. Note
   that the total number of VCGs supported by a node 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 with a change in
   VCG ID MUST be prepared to receive an error response. Again, any
   error in a VCG may result in the failure of the complete VCG.

5.3.4. Removing the association between a call and VCG

   To reuse the server layer connections in a call in another VCG, the
   current association between the call and a VCG MUST first be removed.
   To do this, a Notify message MUST be sent with a CALL_ATTRIBUTES
   object containing a VCAT TLV.  The Action field of the TLV MUST be
   set to 3 (Remove VCG from Call). The VCG ID field is ignored and MAY
   be set to any value. The number of members field is also ignored and
   MAY be set to any value. When the association between a VCG and all
   existing calls has been removed then the VCG is considered torn down.

5.3.5. VCG Bandwidth modification

   The following cases may occur when increasing or decreasing the
   bandwidth of a VCG:

     1. LSPs are added to or, in the case of a decrease, removed from a
       VCAT Call already associated with a VCG.


Bernstein             Expires September 9, 2011               [Page 14]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


     2. An existing VCAT call, and corresponding LSPs, is associated
       with a VCG or, in the case of a decrease, has its association
       removed. Note that in the increase case, the call MUST NOT have
       any existing association with a VCG.

   The following sequence SHOULD be used when modifying the bandwidth of
   a VCG:

  1.   In both cases, prior to any other change, a Notify message MUST
  be sent with a CALL_ATTRIBUTES object containing a VCAT TLV for each
  of the existing VCAT calls associated with the VCG.  The Action field
  of the TLV MUST be set to 2. The VCG ID field MUST be set to match
  the VCG.  The number of members field MUST equal the sum of all LSPs
  that are anticipated to be associated with the VCG after the
  bandwidth change. The Notify message is otherwise formatted and
  processed as defined under Call Establishment in [RFC4974]. If an
  error is encountered while processing any of the Notify messages, the
  number of members is reverted to the pre-change value and the
  increase is aborted.  The reverted number of members MUST be signaled
  in a Notify message as described above.  Failures encountered in
  processing these Notify messages are handled per [RFC4974].

   2.  Once the existing calls have successfully been notified of the
   new number of members in the VCG, the bandwidth change can be made.
   The next step is dependent on the two cases defined above. In the
   first case defined above, the bandwidth change is made by adding (in
   the case of increase) or removing (in the case of a decrease) LSPs to
   the VCAT call per the procedures defined in [RFC4974]. In the second
   case, the same procedure defined in Section 5.3.3. is followed for an
   increase, and the procedure defined in Section 5.3.4. is followed for
   a decrease.





6. Error Conditions and Codes

   VCAT Call and member LSP setup can be denied for various reasons. In
   addition to the call procedures and related error codes described in
   [RFC4974], below is a list of error conditions that can be
   encountered during the procedures as defined in this document. These
   fall under RSVP error code TBA.

   These can occur when setting up a VCAT call or associating a VCG with
   a VCAT call.



Bernstein             Expires September 9, 2011               [Page 15]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


   Error                                  Value
   ------------------------------------   --------
   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


   Any failure in call or LSP establishment MUST be treated as a failure
   of the VCG as a whole and MAY trigger the calls and LSPs associated
   with the VCG being deleted.

7. IANA Considerations

7.1. RSVP CALL_ATTRIBUTE TLV

   IANA has made the following assignments in the "Class Names, Class
   Numbers, and Class Types" section of the "RSVP PARAMETERS" registry
   located at http://www.iana.org/assignments/rsvp-parameters.
   We request that IANA make assignments from the CALL_ATTRIBUTES TLV
   [RFC6001] portions of this registry.

     This document introduces a new CALL_ATTRIBUTES TLV

          TLV Value  Name                       Reference
          ---------  ----------------------     ---------
          TBD (2)    VCAT_TLV                   This I-D


7.2. RSVP Error Codes and Error Values

   A new RSVP Error Code and new Error Values are introduced.  We
   request IANA make assignments from the "RSVP Parameters" registry
   using the sub-registry "Error Codes and Globally-Defined Error Value
   Sub-Codes".

      o  Error Codes:

         - VCAT Call Management (value TBD)

      o  Error Values:







Bernstein             Expires September 9, 2011               [Page 16]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


            Meaning                                Value
            ------------------------------------   --------
            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


8. 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 these
   are members of the same VCAT group that take a different route, and
   may indicate to an interceptor that the VCG call desires increased
   reliability.





























Bernstein             Expires September 9, 2011               [Page 17]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


9. Contributors

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

   Phone +81-46-859-4315
   Email: imajuku.wataru@lab.ntt.co.jp

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

   Phone: + 33 2 96 05 28 28
   Email: julien.meuric@orange-ft.com

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

   Phone: +1 408 705 2978
   Email: lyong@ciena.com


10. 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.















Bernstein             Expires September 9, 2011               [Page 18]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


11. References

11.1. Normative References

   [RFC6001]      Papadimitriou, D., Vigoureux M., Shiomoto, K.
                  Brungard, D., Le Roux, JL., "Generalized Multi-
                  Protocol Label Switching (GMPLS) Protocol Extensions
                  for Multi-Layer and Multi-Region Networks (MLN/MRN)",
                  October, 2010.

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  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.

   [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
                  2005.

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

11.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.

   [G7042]        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
                  2004.






Bernstein             Expires September 9, 2011               [Page 19]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


   [ITU-T-G.704]  International Telecommunications Union, " Synchronous
                  frame structures used at 1544, 6312, 2048, 8448 and 44
                  736 kbit/s hierarchical levels", ITU-T Recommendation
                  G.704, October 1998.

   [ITU-T-G.707]  International Telecommunications Union, "Network Node
                  Interface for the Synchronous Digital Hierarchy
                  (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 M. Bernstein (ed.)
   Grotto Networking
   Fremont California, USA

   Phone: (510) 573-2237
   Email: gregb@grotto-networking.com


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

   Phone: +39 010 600 3736
   Email: diego.caviglia@(marconi.com, ericsson.com)


   Richard Rabbat
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA 94043, USA

   Email: rabbat@alum.mit.edu


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

   Phone:   +31 36 5315076
   Email:   hhelvoort@huawei.com


Bernstein             Expires September 9, 2011               [Page 20]


Internet-Draft    Operating VCAT and LCAS with GMPLS         March 2011


Intellectual Property Statement

   The IETF Trust takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology
   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

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

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

Disclaimer of Validity

   All IETF Documents and the information contained therein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Acknowledgment














Bernstein             Expires September 9, 2011               [Page 21]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/