summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6344.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6344.txt')
-rw-r--r--doc/rfc/rfc6344.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc6344.txt b/doc/rfc/rfc6344.txt
new file mode 100644
index 0000000..59b8d89
--- /dev/null
+++ b/doc/rfc/rfc6344.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+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:
+
+ - 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:
+
+ - Value
+ - Type (Elementary Signal)
+ - 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:
+
+ - Value
+ - Meaning
+ - 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]
+