GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6344

Internet Engineering Task Force (IETF) G. Bernstein, Ed. Request for Comments: 6344 Grotto Networking Updates: 4606 D. Caviglia Category: Standards Track Ericsson ISSN: 2070-1721 R. Rabbat

                                                                Google
                                                       H. van Helvoort
                                                                Huawei
                                                           August 2011
             Operating Virtual Concatenation (VCAT) and
             the Link Capacity Adjustment Scheme (LCAS)
      with Generalized Multi-Protocol Label Switching (GMPLS)

Abstract

 This document describes requirements for, and the 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).  LCAS 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 RFC 4606 by making
 modifications to the procedures for supporting virtual concatenation.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6344.

Bernstein, et al. Standards Track [Page 1] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  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.

Bernstein, et al. Standards Track [Page 2] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

Table of Contents

 1. Introduction ....................................................3
    1.1. Conventions Used in This Document ..........................4
 2. VCAT/LCAS Scenarios and Specific Requirements ...................4
    2.1. VCAT/LCAS Interface Capabilities ...........................4
    2.2. Member Signal Configuration Scenarios ......................5
    2.3. VCAT Operation with or without LCAS ........................6
    2.4. VCGs and VCG Members .......................................7
 3. VCAT Data and Control Plane Concepts ............................7
 4. VCGs Composed of a Single Member Set (One LSP) ..................8
    4.1. One-Shot VCG Setup .........................................8
    4.2. Incremental VCG Setup ......................................9
    4.3. Procedure for VCG Reduction by Removing a Member ...........9
    4.4. Removing Multiple VCG Members in One Shot .................10
    4.5. Teardown of Whole VCG .....................................10
 5. VCGs Composed of Multiple Member Sets (Multiple LSPs) ..........10
    5.1. Signaled VCG Service Layer Information ....................11
    5.2. CALL_ATTRIBUTES Object VCAT TLV ...........................12
    5.3. Procedures for Multiple Member Sets .......................14
         5.3.1. Setting Up a New VCAT Call and VCG Simultaneously ..14
         5.3.2. Setting Up a VCAT Call and LSPs without a VCG ......14
         5.3.3. Associating an Existing VCAT Call with a New VCG ...15
         5.3.4. Removing the Association between a Call and VCG ....15
         5.3.5. VCG Bandwidth Modification .........................15
 6. Error Conditions and Codes .....................................16
 7. IANA Considerations ............................................17
    7.1. RSVP Call Attribute TLV ...................................17
    7.2. RSVP Error Codes and Error Values .........................17
    7.3. VCAT Elementary Signal Registry ...........................18
    7.4. VCAT VCG Operation Actions ................................18
 8. Security Considerations ........................................18
 9. Contributors ...................................................19
 10. Acknowledgments ...............................................19
 11. References ....................................................19
    11.1. Normative References .....................................19
    11.2. Informative References ...................................20

1. Introduction

 The Generalized Multi-Protocol Label Switching (GMPLS) suite of
 protocols allows for the automated control of different switching
 technologies, including the Synchronous Optical Network (SONET),
 Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN),
 and Plesiochronous Digital Hierarchy (PDH).  This document updates
 the procedures described in [RFC4606] to allow supporting additional

Bernstein, et al. Standards Track [Page 3] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

 applications of the Virtual Concatenation (VCAT) layer 1 inverse
 multiplexing mechanism that has been standardized for SONET, SDH,
 OTN, and PDH [ANSI-T1.105] [ITU-T-G.707] [ITU-T-G.709] [ITU-T-G.7043]
 technologies, along with its companion Link Capacity Adjustment
 Scheme (LCAS) [ITU-T-G.7042].
 VCAT is a time-division multiplexing (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 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.

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

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, a label switched router (LSR) can be an 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-capable nor LCAS-capable.

Bernstein, et al. Standards Track [Page 4] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

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.
 The scenarios listed here are dependent on the terms "co-routed" and
 "diversely routed".  In the context of this document, "co-routed"
 refers to a set of VCAT signals that all traverse the same sequence
 of switching nodes.  Furthermore, a co-routed set of signals between
 any pair of adjacent nodes utilizes a set of links that have similar
 delay characteristics.  Thus, "diversely routed" means a set of
 signals that are not classed as "co-routed".
 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.
 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.  Member signals need not be
    co-routed or be guaranteed to be diversely routed.  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.

Bernstein, et al. Standards Track [Page 5] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

 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.
 o  GMPLS signaling for LCAS-capable interfaces MUST support all
    scenarios described in Section 2.2 with no loss of traffic.
 o  GMPLS signaling for non-LCAS-capable interfaces MUST support the
    "fixed" scenarios described in Section 2.2.
 To provide for these requirements, GMPLS signaling MUST carry the
 following information on behalf of the VCAT endpoints:
 o  The type of the member signal that the VCG will contain, e.g.,
    VC-3, VC-4, etc.
 o  The total number of 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.
 o  Identification of the VCG and its associated members.  This
    provides information that allows the endpoints to differentiate
    multiple VCGs and to tell what member, label switched paths
    (LSPs), to associate with a particular VCG.

Bernstein, et al. Standards Track [Page 6] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

2.4. VCGs and VCG Members

 The signaling solution SHOULD provide a mechanism to support these
 scenarios:
 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.
 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 described in 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 ([ITU-T-G.7042]).
 VCG member - This is an individual data plane server-layer signal
    that belongs to a VCG ([ITU-T-G.7042]).
 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.
 Call - A control plane mechanism for providing association between
    endpoints and possibly key transit points.

Bernstein, et al. Standards Track [Page 7] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

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 and does not modify [RFC4606].  It is provided to show
 how the existing GMPLS procedures may be used.  [RFC4606] provides
 the normative definition for GMPLS processing of VCGs composed of a
 single member set, and in the event of any conflict between this
 section and that document, [RFC4606] takes precedence.
 The existing GMPLS signaling protocols support a VCG composed of a
 single member set.  Setup using the Number of Virtual Components
 (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 (Resource Reservation Protocol - Traffic
 Engineering) Path message is sent containing the SONET/SDH traffic
 parameters defined in [RFC4606].  In the case of this example:
 o  Elementary signal is set to 6 (for VC-4/STS-3c_SPE).
 o  NVC is set to 7 (number of members).
 o  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, et al. Standards Track [Page 8] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

 o  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 timeslots.
 o  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), and 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 endpoints 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 list
 in the Generalized Label.

Bernstein, et al. Standards Track [Page 9] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

 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 endpoint and failure of the whole group.  So, this is a
 feature that only LCAS-capable VCAT interfaces can support without
 management intervention at the endpoints.
 Note that if using LCAS, a VCG member can be temporarily 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 that described in Section 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 the deletion procedures described in
 [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 component 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 VCG
 member sets, i.e., multiple control plane LSPs.

Bernstein, et al. Standards Track [Page 10] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

 The support of a VCG with multiple VCG member 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 described in
 [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 that
 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 that 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.  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 information that will be communicated at
 the VCG level, i.e., between the VCG signaling endpoints using the
 call procedures described in [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 the use of external call managers as described in [RFC4974] is
 not precluded.

Bernstein, et al. Standards Track [Page 11] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

 The following information is needed:
 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 = 4               |     Length = 12               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Signal Type                   |      Number of Members        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |LCR| Reserved  |  Action       |               VCG ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type, as defined in [RFC6001].  This field MUST be set to 2.
 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; 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, et al. Standards Track [Page 12] RFC 6344 Operating VCAT and LCAS with GMPLS August 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.
 LCR (LCAS Required): 2 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:
     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

Bernstein, et al. Standards Track [Page 13] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

 VCG Identifier (ID): 16 bits
    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 scenarios.
 The remainder of this section provides specific procedures related to
 VCG signaling.  The procedures described in [RFC4974] are only
 modified as discussed in this section.
 When LCAS is supported, the data plane will add or decrease the
 members per [ITU-T-G.7042].  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 MUST
 be 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 and 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
 identifier.  In fact, to provide for the member-sharing scenarios, 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.

Bernstein, et al. Standards Track [Page 14] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

 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, and 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; 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 of 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.
 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 case of an increase, the call MUST NOT have any
    existing association with a VCG.

Bernstein, et al. Standards Track [Page 15] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

 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 to support call establishment as described
    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 an increase) or removing (in the case of a
    decrease) LSPs to or from the VCAT call per the procedures defined
    in [RFC4974].  In the second case, the 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 while using the procedures defined in this document.
 These fall under RSVP error code 39.
 These can occur when setting up a VCAT call or associating a VCG with
 a VCAT call.
    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
    Unknown LCR (LCAS required) value            6
    Unknown or unsupported ACTION                7

Bernstein, et al. Standards Track [Page 16] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

 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 "Call Attributes TLV"
 section of the "RSVP PARAMETERS" registry available from
 http://www.iana.org.
 IANA has made assignments from the Call Attributes TLV [RFC6001]
 portions of this registry.
 This document introduces a new Call Attributes TLV:
         TLV Value     Name                       Reference
         ---------     ----------------------     ---------
         4             VCAT TLV                   [RFC6344]

7.2. RSVP Error Codes and Error Values

 A new RSVP Error Code and new Error Values are introduced.  IANA
 assigned the following from the "RSVP Parameters" registry using the
 sub-registry "Error Codes and Globally-Defined Error Value
 Sub-Codes".
 o  Error Codes:
  1. VCAT Call Management (39)
 o  Error Values:
       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
       Unknown LCR (LCAS required) value            6
       Unknown or unsupported ACTION                7

Bernstein, et al. Standards Track [Page 17] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

7.3. VCAT Elementary Signal Registry

 IANA created a registry to track elementary signal types as defined
 in Section 5.2.  New allocations are by "IETF Review" [RFC5226].
 IANA maintains the following information:
  1. Value
  2. Type (Elementary Signal)
  3. RFC
 The available range is 0 - 65535.
 The registry has been initially populated with the values shown in
 Section 5.2 of this document.  Value 0 is Reserved.  Other values are
 marked Unassigned.

7.4. VCAT VCG Operation Actions

 IANA created a registry to track VCAT VCG operation actions as
 defined in Section 5.2.  New allocations are by "IETF Review"
 [RFC5226].
 IANA maintains the following information:
  1. Value
  2. Meaning
  3. RFC
 The available range is 0 - 255.
 The registry has been initially populated with the values shown in
 Section 5.2 of this document.  Other values are marked Unassigned.

8. Security Considerations

 This document introduces a specific use of the Notify message and
 ADMIN_STATUS object for GMPLS signaling as originally specified in
 [RFC3473] and as modified by [RFC4974].  It does not introduce any
 new signaling messages, nor does it 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.
 See [RFC5920] for additional information on GMPLS security.

Bernstein, et al. Standards Track [Page 18] RFC 6344 Operating VCAT and LCAS with GMPLS August 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
 USA
 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 document.

11. References

11.1. Normative References

 [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3473]      Berger, L., Ed., "Generalized Multi-Protocol Label
                Switching (GMPLS) Signaling Resource ReserVation
                Protocol-Traffic Engineering (RSVP-TE) Extensions",
                RFC 3473, January 2003.

Bernstein, et al. Standards Track [Page 19] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

 [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,
                August 2006.
 [RFC4974]      Papadimitriou, D. and A. Farrel, "Generalized MPLS
                (GMPLS) RSVP-TE Signaling Extensions in Support of
                Calls", RFC 4974, August 2007.
 [RFC6001]      Papadimitriou, D., Vigoureux, M., Shiomoto, K.,
                Brungard, D., and JL. Le Roux, "Generalized MPLS
                (GMPLS) Protocol Extensions for Multi-Layer and Multi-
                Region Networks (MLN/MRN)", RFC 6001, October 2010.

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.707]  International Telecommunication Union, "Network Node
                Interface for the Synchronous Digital Hierarchy
                (SDH)", ITU-T Recommendation G.707, December 2003.
 [ITU-T-G.709]  International Telecommunication Union, "Interfaces for
                the Optical Transport Network (OTN)", ITU-T
                Recommendation G.709, March 2003.
 [ITU-T-G.7042] International Telecommunication Union, "Link Capacity
                Adjustment Scheme (LCAS) for Virtual Concatenated
                Signals", ITU-T Recommendation G.7042, March 2006.
 [ITU-T-G.7043] International Telecommunication Union, "Virtual
                Concatenation of Plesiochronous Digital Hierarchy
                (PDH) Signals", ITU-T Recommendation G.7043,
                July 2004.
 [RFC5226]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                an IANA Considerations Section in RFCs", BCP 26,
                RFC 5226, May 2008.
 [RFC5920]      Fang, L., Ed., "Security Framework for MPLS and GMPLS
                Networks", RFC 5920, July 2010.

Bernstein, et al. Standards Track [Page 20] RFC 6344 Operating VCAT and LCAS with GMPLS August 2011

Authors' Addresses

 Greg M. Bernstein (editor)
 Grotto Networking
 Fremont, CA
 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@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, et al. Standards Track [Page 21]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6344.txt · Last modified: 2011/08/19 16:13 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki