CCAMP Working Group                                  G. Bernstein (ed.)
Internet Draft                                        Grotto Networking
Updates: RFC 3946                                           D. Caviglia
Category: Standards Track                                      Ericsson
Expires: January July 2010                                            R. Rabbat
                                                                 Google
                                                        H. van Helvoort
                                                                 Huawei
                                                          July 29, 2009
                                                       January 11, 2010

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

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

                 draft-ietf-ccamp-gmpls-vcat-lcas-09.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 January 29, July 11, 2010.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   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",
   "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 Introduction......................................... 3
   2. Revision History...............................................4
      2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-07..........4
      2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-05 and -06..4
      2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-04..........4
      2.4. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-03..........4
      2.5. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02..........4
      2.6. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........4
      2.7. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........5
   3. VCAT/LCAS Scenarios and Specific Requirements..................5
      3.1. Requirements ............. 4
      2.1. VCAT/LCAS Interface Capabilities..........................5
      3.2. Capabilities.................... 4
      2.2. Member Signal Configuration Scenarios.....................6
      3.3. Scenarios................ 4
      2.3. VCAT Operation With or Without LCAS.......................6
      3.4. LCAS.................. 5
      2.4. VCGs and VCG Members......................................7 Members.............................. 6
   3. VCAT Data and Control Plane Concepts..................... 6
   4. GMPLS Mechanisms in Support of VCGs............................7
      4.1. VCGs Composed of a Single Co-Signaled Member Set..........8
         4.1.1. Set (One LSP)... 7
      4.1. One-shot VCG Setup with Co-Signaled Members..........9
         4.1.2. Members........... 7
      4.2. Incremental VCG Setup with Co-Signaled Members.......9
         4.1.3. Members......... 7
      4.3. Procedure for VCG Reduction by Removing a Member....10
         4.1.4. Member....... 8
      4.4. Removing Multiple VCG Members in One Shot...........10
         4.1.5. Shot............. 9
      4.5. Teardown of Whole VCG...............................10
      4.2. VCG............................. 9
   5. VCGs Composed of Multiple Co-Signaled Member Sets........10
         4.2.1. Sets(Multiple LSPs)9
      5.1. Signaled VCG Service Layer Information......................11

      4.3. Use of the CALL_ATTRIBUTES Object........................12
      4.4. Information.............. 10
      5.2. VCAT CALL_ATTRIBUTES TLV Object..........................12
      4.5. TLV....................................... 11
      5.3. Procedures for Multiple Co-signaled Member Sets..........13
         4.5.1. Sets....... 13
         5.3.1. Setting up a new VCAT call and VCG......................15
         4.5.2. VCG Simultaneously. 13
         5.3.2. Setting up a VCAT call + LSPs with no VCG...........15
         4.5.3. without a VCG...... 13
         5.3.3. Associating an existing VCAT call with a VCG........15
         4.5.4. new VCG.. 14
         5.3.4. Removing the association between a call and VCG.....16
   5. VCG... 14
         5.3.5. VCG Bandwidth modification.................... 14
   6. Error Conditions and Codes....................................16
   6. IANA Considerations...........................................16 Codes............................ 15
   7. Security Considerations.......................................17 IANA Considerations.................................. 16
      7.1. RSVP CALL_ATTRIBUTE TLV .......................... 16
      7.2. RSVP Error Codes and Error Values.................. 16
   8. Contributors..................................................18 Security Considerations............................... 17
   9. Acknowledgments...............................................18 Contributors........................................ 18
   10. References...................................................19
      10.1. Acknowledgments.................................... 18
   11. References ........................................ 19
      11.1. Normative References....................................19
      10.2. References............................ 19
      11.2. Informative References..................................19 References .......................... 19
   Author's Addresses...............................................20 Addresses..................................... 20
   Intellectual Property Statement..................................21 Statement .......................... 21
   Disclaimer of Validity...........................................21
   Acknowledgment...................................................21 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), (SONET)[ANSI-
   T1.105], Synchronous Digital Hierarchy (SDH), (SDH)[ITU-T-G.707], Optical
   Transport Network (OTN) (OTN)[ITU-T-G.709] and Plesiochronous Digital
   Hierarchy (PDH). (PDH)[ITU-T-G.704]. 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 [ITU-T-G.7043] technologies along with its companion Link
   Capacity Adjustment Scheme (LCAS). (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. 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
   group.

2. Revision History

2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-07

   None. Needed to refresh Note that the expired draft.

2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-05 and -06

   Used scope of the CALL_ATTRIBUTES Object from [MLN-Ext] rather than defining a
   new CALL_DATA object.

2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-04

   Fixed text in section 4.1.3 on VCG Reduction document is limited to more accurately
   describe LCAS and non-LCAS cases.

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

   Added requirements on pre-existing members.

   Slightly modified solution for scenarios
   where all member sharing to constrain calls to a
      maximum of one VCG.

   Introduced the CALL_DATA object.

   Detailed coding signals of new TLV for a VCAT to be included group are controlled using
   mechanisms defined in the CALL_DATA
      object.

   Modified and expanded procedures to deal with new requirements and
      modified solution methodology.

   Added a list of error conditions.

2.5. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02

   Grammar this document and punctuation fixes. Updated references with newly
      published related RFCs.

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

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

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

   Added "Dynamic,
   a subset of member sharing" scenario.

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

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

   Added text to describe: co-signaled, co-routed, data signals are controlled by a mangement plane LSP, or
   proprietary control plane LSP and their relationship to are outside the VCAT/LCAS
      application.

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

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

   Updated reference from RFC3946bis to issued RFC4606

   Updated section 3.2 based on discussions on the mailing list

3. 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'
   application-specific demands for the use of VCAT/LCAS and from the
   flexible nature of VCAT/LCAS.  These are set out in the following
   section.

3.1.

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

3.2.

2.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. It should be noted that the scope of these scenarios
   is limited to situations where all member signals are controlled
   using mechanisms defined in this document.

   o  Fixed, co-routed: A fixed bandwidth VCG, transported over a co-routed 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. 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.

   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.

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

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

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

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

   The

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

   The

        oThe 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

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

2.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 scenarios,
   i.e., connections established without following the procedures of VCGs

   We describe in
   this section document.

3. VCAT Data and Control Plane Concepts

   In the next two sections we describe 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
   3.
   2.

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

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

   Note that this section is for informational purposes only. (One LSP)

   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. As such, this section does
   not define or modify and procedures and is only included for
   informative purposes.

   There are two options for setting up the VCG, depending on hardware
   capability, or management 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).

4.1.1.

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

   An

   This section describes establishment of an LSP that supports all VCG
   members as part of the initial LSP establishment. To establish such
   and LSP, an RSVP-TE Path message is used with the following
   parameters.

   With regards to the

   The traffic parameters, the parameter's elementary signal is chosen (6 for VC-4/STS-3c_SPE). 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.

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

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

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

4.1.4.

4.4. Removing Multiple VCG Members in One Shot

   The procedure is similar to 4.1.3. 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.1.5.

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

4.2.

5. VCGs Composed of Multiple Co-Signaled Member Sets Sets(Multiple LSPs)

   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

   The support of a VCG with multiple co-signaled 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. This is
   very similar to provided by using the "Call" concept call procedures and extensions
   described in [RFC4974]. We can
   think of our VCAT/LCAS connection, e.g., our VCG, as The VCG is a higher layer service that makes
   use of multiple lower one or more calls (VCAT calls) to associate control plane LSPs
   in support of VCG server layer (server) 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.

   In addition, by supporting the identification of a VCG and VCAT call
   identification, support can be provided for the member sharing
   scenarios, i.e. by explicitly separating the VCG ID from the VCAT
   call ID. Note that are controlled 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 or more 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.

4.2.1. 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.  When a VCG is composed of multiple co-signaled member
   sets, none of the individual LSP's 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 information, additional objects or TLVs are
   incorporated into the Notify message as it is described for use in
   call signaling in [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].

   VCG Call setup information is signaled via the Notify message with the
   Call management bit (C-bit) set: a new CALL_ATTRIBUTES object TLV
   containing the following information:

     1. Signal Type

     2. Number of VCG Members

     3. LCAS requirements:

          a. LCAS required

          b. LCAS desired
          c. LCAS not desired (but acceptable)

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

4.3. Use of the CALL_ATTRIBUTES Object 2.4.

5.2. VCAT TLV

   In RFC4974 the general mechanism mechanisms and procedures for communicating
   call information via Notify messages is given. defined. In [MLN-Ext] the
   CALL_ATTRIBUTES object is introduce defined for the conveyance of call related
   information during call establishment and updates. We define a new

4.4. VCAT
   CALL_ATTRIBUTES object VCAT TLV Object

   For for use in the CALL_ATTRIBUTES object in Notify messages we define
   the following VCAT related TLV:
   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 = TBD TBA             |     Length = 12               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Signal Type                   |      Number of Members        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | LCAS Req      |  Action       |            VCG ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where Type is TBD, and the Length = 12 bytes.

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

   Length, as defined in [MLN-Ext].  This field MUST be set to 12.

   Signal Type Type: 16 bits

     This field can take the following values and MUST never change over
     the lifetime of a VCG: VCG [ANSI-T1-105, ITU-T-G.707, ITU-T-G.709, ITU-
     T-G.7043]:

      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 Gbit/s
       12     OPU2 (i.e., 10  Gbit/s)
       13     OPU3 (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 Members: 16 bits

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

   LCAS Required 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 desired (but acceptable)

   Action

   Action: 8 bits

     This field is used to indicate the relationship between the call
     and the VCG and takes has 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 Identifier (ID): 16 bit non-negative

     This field carries an unsigned integer that is used to identify a
     particular VCG within a session. This number The value of the field MUST NOT
     change over the lifetime of a VCG but can MAY 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.

5.3. Procedures for Multiple Co-signaled Member Sets

   To establish

   The creation of a VCG a CALL_ATTRIBUTES object containing a VCAT TLV is
   exchanged as part of call based on multiple co-signaled member sets
   requires the establishment or update. A VCG can be
   established of at least one VCAT layer call. VCAT
   layer calls and related LSPs (connections) MUST follow the same time the
   Procedures in Support of Calls and Connections as a new call or associated defined in
   [RFC4974] with an
   existing call that currently has no VCG association. When modifying the bandwidth addition of the inclusion of a VCG a CALL_ATTRIBUTES
   object containing a VCAT TLV
   MUST precede any of those changes and indicate the new total number
   of VCAT TLV. Multiple VCAT layer calls per VCG members.

   The following mechanisms can be used to increase the bandwidth of a
   VCG.

   LSPs are added
   not required to support co-signaled member sets, but are needed to
   support certain member sharing scenario.

   The remainder of this section provides specific procedures related to a VCAT Call associated with a VCG (Action = 2).

   A
   VCG is associated with an existing VCAT call containing LSPs
      (Action = 1). signaling.  The following internal ordering is used when increasing the bandwidth procedures of [RFC4974] are only modified as
   discussed in this section.

5.3.1. Setting up a new VCAT call and VCG in Simultaneously

   To simultaneously set up a VCAT call and identify it with an
   associated VCG, a hitless fashion when LCAS is supported:

   A CALL_ATTRIBUTES Object object containing a the VCAT TLV indicating MUST
   be included 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 after the proposed increase is sent. If an error
      is returned from reaches the receiver number specified in the VCAT TLV.

5.3.2. Setting up a VCAT call + LSPs without a VCG state remains the same prior
      to

   To provide for pre-establishment of the attempted increase.

   Either: (a) New LSPs are set up within server layer connections for
   a VCG a VCAT call MAY be established without an associated with VCG
   identifier. In fact, to provide for the
      VCG, member sharing scenario, a
   pool of VCAT calls with associated connections (LSPs) can be
   established, and then one or (b) LSPs in an existing call are now more of these calls (with accompanying
   connections) can be associated with a particular VCG (via the
      VCG.

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

   The following mechanisms
   ID). Note that multiple calls can be used to decrease the bandwidth of a
   VCG.

   LSPs are removed from a VCAT Call associated with a single VCG (Action = 2).

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

   In general the following internal ordering is used when decreasing
   the bandwidth of MUST NOT contain members used in more than one VCG.

   To establish a VCAT call with no VCG in association, a hitless fashion when LCAS is supported:

   1. A CALL_ATTRIBUTES Object
   object containing a the VCAT TLV indicating MUST be included at the new
      number time 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. call
   setup.  The LCAS entity is instructed by the endpoints to "deactivate" the
      members to VCAT TLV Action field MUST be removed from the VCG.

   3. Either: (a) An LSP set to 0, which indicates
   that this is removed from a VCAT call without an associated with a VCG;
      or (b) All the VCG.  LSPs of a call are removed from the VCG when can then be
   added to the
      association between call. The number of members parameter in the VCG and VCAT call is removed.

   Note that when LCAS is not used or unavailable TLV
   has no meaning at this point since it reflects the VCG will be intended number of
   members in an
   unknown state between the time the a VCG call level information is
   updated and the actual data plane LSPs are added or removed. not in a call. Note that the incremental setup procedure of section 4.1.2. signal types can never
   be applied
   to any of the above procedures.

4.5.1. Setting up mixed in a VCAT call and VCG

   Arguably the most common operation will be simultaneously setting up and hence a VCAT call and its associated VCG at the same time. To do this when contains only one sets up signal
   type.

5.3.3. Associating an existing VCAT call with a new VCG

   A VCAT call in the 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 one sets
   TLV. The TLV's Action = field MUST be set to 1
   indicating that this is a new the VCG for this call.  LSPs would then Identifier field
   MUST be
   added set to correspond to the call until the VCG.  The number of members reaches field
   MUST equal the number
   specified in sum of all LSPs associated with the VCAT TLV. VCG. The Notify
   message is otherwise formatted and processed as defined under Call
   Establishment in [RFC4974]. Note that any other bandwidth modifications to the total number of VCGs
   supported by a piece of equipment may be limited and hence on
   reception of any message with a change of VCG whether up or
   down will require ID this limit should be
   checked. Likewise the sender of a new VCAT call message with a change in VCG ID
   MUST be prepared to receive an appropriately
   modified TLV reflecting error response. Again, any error in a
   VCG may result in the new number failure of members.

4.5.2. Setting up the complete VCG.

5.3.4. Removing the association between a VCAT call + LSPs with no and VCG

   To provide for pre-establishment of reuse the server layer connections for
   a VCG one can establish in 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 in another VCG, the VCG ID). Note that multiple calls can be associated with
   current association between the call and a
   single VCG but that no call contains members used in more than one
   VCG. MUST first be removed.
   To establish do this, a VCAT call Notify message MUST be sent with no VCG association when one sets up a
   new VCAT call in the CALL_ATTRIBUTES
   object containing a VCAT TLV one sets TLV.  The Action = 0 indicating that
   this field of the TLV MUST be
   set to 3 (Remove VCG from Call). The VCG ID field is a VCAT call without an associated VCG.  LSPs can then ignored and MAY
   be
   added set to the call. any value. The number of members parameter in field is also ignored and
   MAY be set to any value. When the VCAT TLV association between a VCG and all
   existing calls has no meaning at this point since it reflects been removed then the intended number of
   members in a VCG is considered torn down.
   The Notify message is otherwise formatted and not processed as defined
   under Call Establishment in a call.  A call will know via the
   containment hierarchy about its associated data plane LSPs. However, [RFC4974].

5.3.5. VCG Bandwidth modification

   The following cases may occur when increasing or decreasing the signal type does matter since signal types can never be mixed
   bandwidth of a VCG:

     1. LSPs are added to or, in the case of a VCG and hence decrease, removed from a
       VCAT call should only contain one signal type.

4.5.3. Associating an Call already associated with a VCG.

     2. An existing VCAT call call, and corresponding LSPs, is associated
       with a VCG

   Given or, in the case of a VCAT call without an associated VCG such as decrease, has its association
       removed. Note that set up in
   section 4.5.2. one associates it the increase case, the call MUST NOT have
       any existing association with a VCG.

   The following internal ordering SHOULD be used when modifying the
   bandwidth of a VCG as follows. in a hitless fashion when LCAS is supported:

  1.   In the VCAT
   call both cases, prior to any other change, a new notify Notify message is MUST
  be sent with a CALL_ATTRIBUTES object with containing a VCAT TLV with Action = 1, a 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, and ID field MUST be set to match
  the correct VCG.  The number of VCG members specified based on adding all of field MUST equal the calls data plane 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 members.

   Note that defined under Call Establishment in [RFC4974]. If an
  error is encountered while processing any of the Notify messages, the total
  number of VCGs supported by a piece of equipment
   may be limited members is reverted to the pre-change value and hence on reception the
  increase is aborted.  The reverted number of any message with members MUST be signaled
  in a change Notify message as described above.  Any failures encountered in
  processing these Notify messages are ignored.

   2.  Once the existing calls have successfully been notified of
   VCG ID this limit should be checked. Likewise the sender
   new number of a message
   with a change members in VCG ID should the VCG, the bandwidth change can be prepared to receive an error
   response. To take a particular VCG out made.
   In the case of service, rather than just
   removing all its member, a special flag element is included.

4.5.4. Removing decrease, the association between a call and VCG

   To reuse internal LCAS entity at the endpoints
   MUST "deactivate" the server layer connections in a call in another VCG one member(s). The next step is dependent on
   the two cases defined above. In the first needs to remove case defined above, the current association between
   bandwidth change is made by adding (in the call and case of increase) or
   removing (in the case of a
   VCG.  To do this, in decrease) LSPs to the VCAT call a new notify message is sent with
   a CALL_ATTRIBUTES object with a VCAT TLV with Action = 3, a VCG ID, 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 correct number of VCG members specified based on removing all procedure defined in Section 5.3.4. is followed for an decrease.
   In the case of an increase, after the calls data plane LSPs from bandwidth change is
   successfully made, the VCG as members. When internal LCAS entity at the
   association between a VCG and all existing calls has been removed
   then endpoints MUST
   "activate" the new VCG is considered torn down.

5. member(s).

6. Error Conditions and Codes

   VCAT Call and member LSP setup can be denied for various reasons.
   Below 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
   these procedures. the procedures as defined in this document.  These
   fall under RSVP error code TBD. TBA.

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

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

6.

   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

   This document requests from

7.1. RSVP CALL_ATTRIBUTE TLV

   IANA has made the following assignments in the assignment "Class Names, Class
   Numbers, and Class Types" section of a new TLV for the
   CALL_ATTRIBUTES Object "RSVP PARAMETERS" registry
   located at http://www.iana.org/assignments/rsvp-parameters.
   We request that IANA make assignments from [MLN-Ext]. Within this VCAT the CALL_ATTRIBUTES TLV are a set
   [MLN-Ext] portions of code points for permissible signal types. In addition, we request 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 for use with VCAT call Error Code and define a 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:

            Meaning                                Value
            ------------------------------------   --------
            VCG signal type not Supported             1
            LCAS option not supported                 2
            Max number of
   corresponding error sub-codes.

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

   Otherwise, this document does not introduce any additional security
   considerations.

8.

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

9.

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.

10.

11. References

10.1.

11.1. Normative References

   [MLN-Ext]      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)",
                  work in progress: draft-ietf-ccamp-gmpls-mln-
                  extensions-03.txt,
                  extensions-09.txt, October, 2008. 2009.

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

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

10.2.

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.

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

   [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

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