[要約] RFC 6344は、GMPLSを使用して仮想連結(VCAT)とリンク容量調整スキーム(LCAS)を操作するための標準を定義しています。このRFCの目的は、ネットワークの効率と柔軟性を向上させるために、VCATとLCASの実装と運用に関するガイドラインを提供することです。

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)

一般化されたマルチプロトコルラベルスイッチング(GMPLS)を備えた動作仮想コンダン化(VCAT)およびリンク容量調整スキーム(LCAS)

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.

このドキュメントでは、仮想連結(VCAT)層1逆マルチプレックスデータプレーンメカニズムとそのコンパニオンリンク容量調整スキーム(LCAS)をサポートする一般化されたマルチプロトコルラベルスイッチング(GMPLS)制御プレーンの要件と使用について説明します。LCAは、逆マルチプレックスグループのヒットレスダイナミックサイズ変更に使用できます。これらの手法は、光学輸送ネットワーク(OTN)、同期光ネットワーク(SONET)、同期デジタル階層(SDH)、およびプレシオクロナスデジタル階層(PDH)シグナルに適用されます。このドキュメントは、仮想連結をサポートする手順を変更することにより、RFC 4606を更新します。

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.

このドキュメントは、インターネットエンジニアリングタスクフォース(IETF)の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ(IESG)からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。

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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http://www.rfc-editor.org/info/rfc6344で取得できます。

Copyright Notice

著作権表示

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

Copyright(c)2011 IETF Trustおよび文書著者として特定された人。全著作権所有。

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.

このドキュメントは、BCP 78およびIETFドキュメント(http://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

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
1. はじめに

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

一般化されたマルチプロトコルラベルスイッチング(GMPLS)のプロトコルスイートは、同期光ネットワーク(SONET)、同期デジタル階層(SDH)、光学輸送ネットワーク(OTN)、およびプレシオクロクロナスデジタルヒエラチャイなど、さまざまなスイッチング技術の自動制御を可能にします。(PDH)。このドキュメントは、[RFC4606]に記載されている手順を更新して、追加のサポートを可能にします

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

SONET、SDH、OTN、およびPDHに標準化された仮想連結(VCAT)層1逆多重化メカニズム[ANSI-T1.105] [ITU-T-G.707] [ITU-T-G.709] [ITU-T-G.7043]技術、およびそのコンパニオンリンク容量調整スキーム(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.

VCATは、非常に高いビットレートOTNおよびSDH/SONET信号を含む、幅広い既存および新興のTDMフレーム付き信号で動作する、時間帯マルチプレックス(TDM)指向バイトストライプ逆マルチプレックスメソッドです。VCATは、サーバー信号のグループを利用して最適な信号サーバー帯域幅(サイズ)を選択し、メッシュネットワークで帯域幅を効率的に使用することを可能にします。LCAと組み合わせると、ネットワーク障害の存在下での帯域幅と高速な優雅な劣化のヒットレスダイナミックなサイズ変更をサポートできます。VCAT/LCAS機能を最大限に活用するには、同じVCATグループのメンバーである多様なルーティングされた信号のセットアップを可能にするGMPLSシグナリングへの追加の拡張が必要です。このドキュメントの範囲は、VCATグループのすべてのメンバー信号が、このドキュメントおよび関連RFCで定義されたメカニズムを使用して制御されるシナリオに限定されていることに注意してください。メンバー信号のサブセットが管理プレーンまたは独自の制御プレーンによって制御されるシナリオは、このドキュメントの範囲外です。

1.1. Conventions Used in This Document
1.1. このドキュメントで使用されている規則

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

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。

2. VCAT/LCAS Scenarios and Specific Requirements
2. VCAT/LCASシナリオと特定の要件

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.

GMPLSのVCAT/LCAのサポートには、VCAT/LCAを使用するためのキャリアのアプリケーションから導出できる特定の要件がいくつかあります。これらは次のセクションに記載されています。

2.1. VCAT/LCAS Interface Capabilities
2.1. VCAT/LCASインターフェイス機能

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.

一般に、ラベルスイッチ付きルーター(LSR)は、1つ以上のVCATグループの侵入/出口になります。VCATおよびLCASは、データプレーンインターフェイス機能です。LSRには、たとえば、LCAS対応ではないVCAT対応インターフェイスがある場合があります。同時に、VCAT対応でもLCAS対応でもないインターフェイスがある場合があります。

2.2. Member Signal Configuration Scenarios
2.2. メンバー信号構成シナリオ

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.

このセクションでは、さまざまなシナリオをリストします。ここでは、[ITU-T-G.707]用語「VCG」を使用して、VCATグループと用語「セット」と「サブセット」を参照して、グループの区画と個々のVCATグループメンバー信号を参照します。上記のように、これらのシナリオの範囲は、このドキュメントで定義されているメカニズムを使用してすべてのメンバー信号が制御されるシナリオに限定されます。

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

ここにリストされているシナリオは、「共同ルーティング」および「ダイバーリールーティング」という用語に依存します。このドキュメントのコンテキストでは、「共同ルート」とは、すべてが同じスイッチングノードのシーケンスを横断するというVCAT信号のセットを指します。さらに、隣接するノードの任意のペア間の共有の信号セットは、同様の遅延特性を持つリンクのセットを使用します。したがって、「ダイバーリールーティング」とは、「共通」と分類されていないシグナルのセットを意味します。

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.

固定、共同ルーティング:固定帯域幅VCGは、共同ルートのメンバー信号セットを介して輸送されました。これは、VCGの意図された帯域幅が変更されず、すべてのメンバー信号が同じルートに従って差動遅延を最小限に抑える場合です。ここでのアプリケーションは、クライアントレイヤーで必要な帯域幅に近い帯域幅を割り当てる機能です。

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.

固定された多様なルーティング:固定帯域幅VCGは、メンバー信号の少なくとも2つの多様なルーティングされたサブセットに輸送されました。この場合、サブセットは、ルートの少なくとも1つのリンクを介してリンクディスジョイントです。ここでのアプリケーションは、ネットワークリソースのより効率的な使用です。たとえば、必要な帯域幅がある一意のルートはありません。

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.

固定、メンバー共有:固定帯域幅VCGは、メンバー接続の分解とセットアップを必要とせずに利用可能なメンバー信号の共通プールから割り当てられたメンバー信号のセットを介して輸送されます。このドキュメントは、この「潜在的な」メンバー信号のプールが、このドキュメントで定義されているメカニズムを介して確立された場合のみをカバーしています。メンバー信号は、共同ルーティングまたは多様なルーティングを保証する必要はありません。VCATの性質により、メンバー信号は一度に1つのVCGにのみ属することができることに注意してください。別のVCGで使用するには、まず、属するVCGから信号を削除する必要があります。

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.

ダイナミック、共同ルート:動的VCG(メンバー信号の追加または除去により帯域幅を増加または減少させることができます)。ここでのアプリケーションは、動的なサイズ変更と帯域幅の回復力です。

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.

ダイナミック、ダイバーリールーティング:動的VCG(帯域幅は、メンバー信号の添加または除去により帯域幅を増加または減少させることができます)。ここでのアプリケーションは、ネットワークリソースの効率的な使用、動的なサイズ変更、および帯域幅の回復力です。

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.

ダイナミック、メンバー共有:ダイナミックバンド幅VCGは、メンバー接続の分解とセットアップを必要とせずに、利用可能なメンバー信号の共通プールから割り当てられたメンバー信号のセットを介して輸送されます。

2.3. VCAT Operation with or without LCAS
2.3. LCAの有無にかかわらずVCAT操作

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.

VCAT機能は、LCAの存在の有無にかかわらず存在する場合があります。LCAの使用は、柔軟な帯域幅サービスのプロビジョニングに有益ですが、LCASがない場合、VCATは依然として有効な手法です。したがって、VCATの動作のためのGMPLSメカニズムは、LCAが利用可能な場合とそれが利用できない場合に必要です。2つのケースのGMPLS手順は同一である必要があります。

o GMPLS signaling for LCAS-capable interfaces MUST support all scenarios described in Section 2.2 with no loss of traffic.

o LCAS対応インターフェイスのGMPLSシグナリングは、セクション2.2で説明されているすべてのシナリオをサポートする必要があります。

o GMPLS signaling for non-LCAS-capable interfaces MUST support the "fixed" scenarios described in Section 2.2.

o 非LCAS対応インターフェイスのGMPLSシグナリングは、セクション2.2で説明されている「固定」シナリオをサポートする必要があります。

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

これらの要件を提供するには、GMPLSシグナリングは、VCATエンドポイントに代わって次の情報を伝える必要があります。

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

o メンバーのタイプは、VCGがVC-3、VC-4などを含むことを信号します。

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 VCGに参加するメンバーの総数。これにより、LCASと非LCASの両方のケースの両方のエンドポイントが要求を受け入れるか拒否する情報を提供し、非LCASの場合、VCGのすべてのメンバーがいつ確立されたかを受信エンドポイントに知らせます。

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.

o VCGとその関連メンバーの識別。これにより、エンドポイントが複数のVCGを区別し、どのメンバーが特定のVCGに関連付けられるかを伝えることができる情報を提供します。

2.4. VCGs and VCG Members
2.4. VCGSおよびVCGメンバー

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メンバー(サーバー層接続)は、VCGで使用する前に設定できます。

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

o 対応するVCGが削除された後、VCGメンバー(サーバー層接続)が存在する場合があります。

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
3. VCATデータと制御プレーンの概念

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

VCAT/LCAでGMPLSを使用する場合、以下で説明する多くのコントロールおよびデータプレーンの概念を使用します。

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-これは、ネットワークを介した仮想連結リンク接続の帯域幅を提供するために使用されるデータプレーンサーバー層信号のグループです([ITU-T-G.7042])。

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

VCGメンバー - これは、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.

メンバーセット - 同じコントロールプレーン信号交換を介して設定された1人以上のVCGメンバー(または潜在的なメンバー)。メンバーセットのすべてのメンバーが同じルートに従うことに注意してください。

Data plane LSP - This is an individual VCG member.

データプレーンLSP-これは個々のVCGメンバーです。

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.

コントロールプレーンLSP-複数のデータプレーンLSPを制御できるコントロールプレーンエンティティ。ここでの目的のために、これはメンバーセットに相当します。

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

呼び出し - エンドポイントと場合によってはキートランジットポイント間の関連性を提供するための制御プレーンメカニズム。

4. VCGs Composed of a Single Member Set (One LSP)
4. 単一のメンバーセット(1つのLSP)で構成されるVCGS

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

このセクションと次のセクションでは、セクション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.

このセクションでは、既存のGMPLS手順[RFC4606]を使用して、単一のメンバーセット(固定された共同ルートアプリケーションと動的な共有アプリケーションをサポートする)で構成される単一のVCGのサポートについて説明します。このセクションは情報目的のみを目的としており、[RFC4606]を変更しないことに注意してください。既存のGMPLS手順をどのように使用するかを示すために提供されます。[RFC4606]は、単一のメンバーセットで構成されるVCGのGMPLS処理の規範的定義を提供し、このセクションとその文書[RFC4606]の間に競合が発生した場合、優先されます。

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.

既存のGMPLSシグナリングプロトコルは、単一のメンバーセットで構成されるVCGをサポートしています。仮想コンポーネントの数(NVC)フィールドを使用したセットアップは、[RFC4606]のセクション2.1で説明されています。この場合、VCGをサポートするために1つの(単一)コントロールプレーンLSPが使用されます。

There are two options for setting up the VCG, depending on policy preferences: one-shot setup and incremental setup.

ポリシーの設定に応じて、VCGをセットアップするには、ワンショットのセットアップとインクリメンタルセットアップが2つあります。

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

次のセクションでは、VC-4-7V SDH VCATグループ(STS-3C-7V SONET VCATグループに対応する)のセットアップの例に基づいて手順を説明します。3c)。

4.1. One-Shot VCG Setup
4.1. ワンショットVCGセットアップ

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:

このセクションでは、最初のLSP設立の一部としてすべてのVCGメンバーをサポートするLSPの確立について説明します。このようなLSPを確立するために、[RFC4606]で定義されたSONET/SDHトラフィックパラメーターを含むRSVP -TE(リソース予約プロトコル - トラフィックエンジニアリング)パスメッセージが送信されます。この例の場合:

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

o 基本信号は6に設定されています(VC-4/STS-3C_SPEの場合)。

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

o NVCは7(メンバーの数)に設定されています。

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

o [RFC4606]に従って、オペレーターが同一のVCATグループ(同じLSPの場合)を設定したい場合、1(たとえばn> 1)を超える乗数変換(n> 1など)を使用できます。

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 SDHまたはSONETラベルは、VCGの各メンバーに割り当てられ、連結して、TDMラベルと同じ形式の32ビットタイムスロット識別子の順序リストとして構築された単一の一般化ラベルを形成する必要があります。[RFC4606]は、ラベルの順序が、タイムスロットの物理的順序ではなく、連結するためのペイロードの順序を反映することを要求しています。

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

o 他のトラフィックパラメーター設定については、[RFC4606]を参照してください。

4.2. Incremental VCG Setup
4.2. 増分VCGセットアップ

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.

場合によっては、VCGメンバーを個別にセットアップするか、既存のグループにグループメンバーを追加することが必要または望ましい場合があります。

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.

このニーズの1つの例は、ローカルポリシーでVCATがVCATメンバーを一度に1つだけ追加できるか、逆の多重化の目的でイングレスと出口でメンバーを自動的に一致させることができないことです。シリアルまたは増分のセットアップは、この問題を解決します。

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.

インクリメンタルセットアップを達成するために、グループメンバーを追加するために反復プロセスが使用されます。反復ごとに、NVCは必要な最終値まで増加します。イテレーションの成功は、パスとRESVシグナル伝達の正常な完了で構成されています。最初は、NVC = 1で、ラベルにはタイムスロット識別子が1つだけ含まれています。

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.

次の反復のそれぞれで、NVCは(NVC 1)に設定され、もう1つのタイムスロット識別子が一般化されたラベル(パスまたはRESVメッセージ)の順序付けリストに追加されます。変更されたフィールドを含むパスメッセージを受信するノードは、フルパスメッセージを処理し、NVCの新しい値に基づいてVCATグループにコンポーネント信号を追加し、新しいラベル情報に基づいて新しいタイムスロットを切り替えます。

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

LSPに新しいラベル(新しいメンバーを識別)を追加した後、データプレーンでLCAを使用して、既存のVCATグループにエンドポイントの新しいメンバーを追加することができます。LCAS(データプレーン)シグナル伝達は[ITU-T-G.7042]で説明されています。

4.3. Procedure for VCG Reduction by Removing a Member
4.3. メンバーを削除することによるVCG削減の手順

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

コンポーネント信号を削除する手順は、セクション4.2で説明されているようにコンポーネントを追加するために使用される手順と類似しています。データプレーンでは、LCASシグナル伝達を最初に使用して、グループからコンポーネントを使用しなくなります。LCASシグナル伝達は[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.

この場合、NVC値は1によって減少し、ドロップされたコンポーネントのタイムスロット識別子は、一般化されたラベルの順序付けリストから削除されます。

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.

LCAS対応ではないインターフェイスの場合、VCGの1つのコンポーネントを削除すると、エンドポイントでメンバーが障害検出され、グループ全体の障害が発生することに注意してください。したがって、これは、LCAS対応のVCATインターフェイスのみがエンドポイントでの管理介入なしにサポートできる機能です。

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

LCAを使用する場合、コンポーネント信号の障害によりVCGメンバーをVCGから一時的に削除できることに注意してください。LCASデータプレーンシグナリングは、[ITU-T-G.7042]に記載されているように、VCGを調整するための適切なアクションを実行します。

4.4. Removing Multiple VCG Members in One Shot
4.4. 複数のVCGメンバーを1発で削除します

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.3で説明したものと似ています。この場合、NVC値は新しい値に変更され、取り壊されるコンポーネントの関連するすべてのタイムスロット識別子は、一般化されたラベルの順序付けリストから削除されます。この手順は、VCGの1つまたは複数のコンポーネントを削除するとグループ全体が取り壊されるため、管理介入なしにVCATのみのインターフェイスでもサポートされていません。

4.5. Teardown of Whole VCG
4.5. 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].

[RFC3473]で説明されている削除手順を使用して、LSP全体が単一のステップ(つまり、すべてのコンポーネントが一度に削除されます)で削除されます。

5. VCGs Composed of Multiple Member Sets (Multiple LSPs)
5. 複数のメンバーセット(複数のLSP)で構成されるVCGS

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:

複数のメンバーセットで構成されるVCGの動機は、多様なルーティングされたメンバーとVCGをサポートするための要件に由来しています。初期のGMPLS仕様は、NVCコンストラクトを使用して多様なルーティングされた信号をサポートしませんでした。[RFC4606]

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

[...]仮想連結の標準定義により、各仮想連結コンポーネントが多様なパスを越えて移動できます。GMPLS内では、仮想連結コンポーネントが同じLSPの一部である場合、同じ(コンポーネント)リンクを越えて移動する必要があります。これは、ラベルが(コンポーネント)リンクにバインドされる方法によるものです。ただし、異なるパス上のコンポーネントのルーティングは、実際には異なるLSPを確立することと同等であり、それぞれが独自のルートを持っていることに注意してください。いくつかのLSPを同じノード間で開始および終了でき、対応するコンポーネントを一緒に関連付けることができます(つまり、実質的に連結)。

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

多様にルーティングされたVCGメンバーのセットアップには、複数のVCGメンバーセット、つまり複数のコントロールプレーンLSPが必要です。

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.

複数のVCGメンバーセットを備えたVCGのサポートには、単一のVCGを使用して個別のコントロールプレーンLSPを識別し、エンドポイント間のVCG全体に関連する交換情報を識別できる必要があります。このドキュメントは、[RFC4606]で説明されている手順を更新して、[RFC4974]で説明されているコール手順と拡張機能を使用してこの機能を提供します。VCGは、データプレーン内のVCGサーバー層接続(VCGメンバー)をサポートする1つ以上のコントロール(VCATコール)を使用して、コントロールプレーンLSPを関連付けます。VCGのトリガー(管理プレーンまたはクライアントレイヤーによる)は、このドキュメントの範囲外であることに注意してください。これらの手順は、クライアントレイヤーとサーバーレイヤーの管理に関する自律性を提供します。

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.

さらに、VCG(VCG ID)およびVCATコール識別(VCATコールID)の識別をサポートすることにより、メンバー共有シナリオのサポートを提供できます。つまり、VCG IDをVCATコールIDから明示的に分離します。[RFC4974]に従って、LSP(接続)をあるコールから別のコールに移動できないことに注意してください。したがって、メンバーの共有をサポートするために、このドキュメントの手順は、あるVCGから別のVCGへの移動コールとそれに関連するLSPを移動することによりサポートを提供します。以下の図1は、これらの関係を示しています。ただし、このドキュメントで後述するように、VCAT呼び出しはVCG(接続の事前設立用)とは独立して存在する可能性があることに注意してください。

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

図1. VCG、VCAT呼び出し、コントロールプレーンLSP、およびデータプレーン接続間の概念的封じ込め関係

5.1. Signaled VCG Service Layer Information
5.1. 信号されたVCGサービスレイヤー情報

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.

このセクションでは、[RFC4974]で説明されているコール手順を使用して、VCGレベルで、つまりVCGシグナリングエンドポイント間で伝達される情報を提供します。VCG情報に対応するために、Notifyメッセージ[RFC4974]で使用するために、CALL_ATTRIBUTESオブジェクト[RFC6001]のこのドキュメントで新しいTLVが定義されています。Notifyメッセージはターゲットメッセージであり、ネットワークを介してLSPのパスをたどる必要はありません。つまり、VCATコールを確立するためのメンバーシグナリングに依存することはなく、[RFC4974]に記載されている外部コールマネージャーの使用は排除されません。

The following information is needed:

次の情報が必要です。

1. Signal type

1. 信号タイプ

2. Number of VCG members

2. VCGメンバーの数

3. LCAS requirements:

3. LCAS要件:

a. LCAS required

a. LCAが必要です

b. LCAS desired

b. LCASが望んでいます

c. LCAS not supported

c. LCAはサポートされていません

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.

4. VCG識別子 - コールIDとは別のVCGを識別するために使用されるため、メンバー共有の要件とセクション2.4の要件に従って、コールメンバーを異なるVCGで再利用できます。

5.2. CALL_ATTRIBUTES Object VCAT TLV
5.2. call_attributesオブジェクトvcat tlv

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

このドキュメントでは、CALL_ATTRIBUTESオブジェクト[RFC6001]で使用するCALL_ATTRIBUTESオブジェクトVCAT TLVを次のように定義しています。

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        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.

[RFC6001]で定義されているように、タイプ。このフィールドは2に設定する必要があります。

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

[RFC6001]で定義されている長さ。このフィールドは12に設定する必要があります。

Signal Type: 16 bits

信号タイプ:16ビット

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

信号タイプをVCGで混合することはできません。したがって、VCAT呼び出しには1つの信号タイプのみが含まれます。このフィールドは次の値をとることができ、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     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

メンバー数:16ビット

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.

このフィールドは、VCGのメンバーの総数を示さなければならない署名されていない整数です(呼び出しだけでなく)。このフィールドは、現在のメンバー数を示すために(VCGの寿命にわたって)変更する必要があります。

LCR (LCAS Required): 2 bits

LCR(LCASが必要):2ビット

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

このフィールドは、次の値をとることができ、VCGの寿命にわたって変化してはなりません。

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

Action: 8 bits

アクション:8ビット

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

このフィールドは、コールとVCGの関係を示すために使用され、次の値があります。

       Value                     Meaning
       -----    -------------------------------------------------------
         0      No VCG ID (set up call prior to VCG creation)
         1      New VCG for Call
         2      Modification of Number of Members (no change in VCG ID)
         3      Remove VCG from Call
        

VCG Identifier (ID): 16 bits

VCG識別子(ID):16ビット

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.

このフィールドには、セッション内で特定のVCGを識別するために使用される署名されていない整数が搭載されています。フィールドの価値は、VCGの生涯にわたって変化してはなりませんが、呼び出しの生涯にわたって変化する可能性があります。

5.3. Procedures for Multiple Member Sets
5.3. 複数のメンバーセットの手順

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.

複数のメンバーセットに基づくVCGの作成には、少なくとも1つのVCATレイヤーコールを確立する必要があります。VCATレイヤーコールと関連LSP(接続)は、VCAT TLVを含むCALL_ATTRIBUTESオブジェクトを含めることで、[RFC4974]で定義されている手順に従う必要があります。VCGごとの複数のVCATレイヤーコールは、メンバーセットをサポートするために必要はありませんが、特定のメンバー共有シナリオをサポートするには必要です。

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.

このセクションの残りの部分は、VCGシグナル伝達に関連する特定の手順を提供します。[RFC4974]で説明されている手順は、このセクションで説明したように修正されています。

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.

LCASがサポートされると、データプレーンは[ITU-T-G.7042]ごとにメンバーを追加または減少させます。LCASがLSP全体でサポートされていない場合、メンバーセット間のデータプレーン調整は、このドキュメントの範囲外です。

5.3.1. Setting Up a New VCAT Call and VCG Simultaneously
5.3.1. 新しいVCATコールとVCGを同時に設定します

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.

同時にVCAT呼び出しを設定し、関連するVCGでそれを識別するには、VCAT TLVを含むCALL_ATTRIBUTESオブジェクトを通話セットアップ時にNotifyメッセージに含める必要があります。VCAT TLVアクションフィールドは1に設定する必要があります。これは、これがこの呼び出しの新しいVCGであることを示しています。その後、LSPは、メンバーの数がVCAT TLVで指定された数に達するまでコールに追加する必要があります。

5.3.2. Setting Up a VCAT Call and LSPs without a VCG
5.3.2. VCGなしでVCATコールとLSPを設定する

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.

VCGのサーバー層接続を事前に確立するために、関連するVCG識別子なしでVCAT呼び出しを確立することができます。実際、メンバー共有シナリオを提供するために、関連する接続(LSP)を備えたVCAT呼び出しのプールを確立でき、これらの呼び出しの1つ以上(付随する接続を伴う)を特定のVCGに関連付けることができます(VCG ID)。複数の呼び出しは単一のVCGに関連付けられる可能性がありますが、コールには複数のVCGで使用されるメンバーが含まれていないことに注意してください。

To establish a VCAT call with no VCG association, a CALL_ATTRIBUTES object containing the VCAT TLV MUST be included at the time of call setup in the Notify message. The VCAT TLV Action field MUST be set to 0, which indicates that this is a VCAT call without an associated VCG. LSPs can then be added to the call. The Number of Members parameter in the VCAT TLV has no meaning at this point, since it reflects the intended number of members in a VCG and not in a call.

VCGアソシエーションなしでVCATコールを確立するには、vcat TLVを含むCALL_ATTRIBUTESオブジェクトをNotifyメッセージの呼び出しセットアップ時に含める必要があります。VCAT TLVアクションフィールドは0に設定する必要があります。これは、これが関連するVCGのないVCATコールであることを示します。その後、LSPをコールに追加できます。VCAT TLVのメンバーのパラメーターの数には、この時点では意味がありません。これは、VCG内の意図した数のメンバーがコールではなく反映されるためです。

5.3.3. Associating an Existing VCAT Call with a New VCG
5.3.3. 既存のVCATコールを新しい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.

それ以外の場合はVCGに関連付けられていないVCAT呼び出しは、VCGに関連付けられている場合があります。このような関連性を確立するには、VCAT TLVを含むCALL_ATTRIBUTESオブジェクトを使用して通知メッセージを送信する必要があります。TLVのアクションフィールドは1に設定する必要があり、VCG識別子フィールドはVCGに対応するように設定する必要があります。メンバーの数は、VCGに関連付けられたすべてのLSPの合計に等しくなければなりません。ノードでサポートされているVCGの総数は制限される場合があることに注意してください。したがって、VCG IDの変更を受けたメッセージを受信すると、この制限を確認する必要があります。同様に、VCG IDの変更を伴うメッセージの送信者は、エラー応答を受信するために準備する必要があります。繰り返しますが、VCGのエラーが発生すると、完全なVCGが失敗する可能性があります。

5.3.4. Removing the Association between a Call and VCG
5.3.4. コールと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.

別のVCGの呼び出しでサーバー層接続を再利用するには、最初にコールとVCGの間の現在の関連性を削除する必要があります。これを行うには、VCAT TLVを含むcall_attributesオブジェクトを使用して通知メッセージを送信する必要があります。TLVのアクションフィールドは3に設定する必要があります(呼び出しからVCGを削除)。VCG IDフィールドは無視され、任意の値に設定される場合があります。メンバーの数も無視され、任意の価値に設定される場合があります。VCGと既存のすべての呼び出しとの関連が削除されると、VCGは取り壊されたと見なされます。

5.3.5. VCG Bandwidth Modification
5.3.5. VCG帯域幅変更

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

VCGの帯域幅を増加または減少させるときに、次のケースが発生する可能性があります。

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

1. LSPは、減少の場合に追加され、VCGにすでに関連付けられているVCATコールから削除されます。

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.

2. 既存のVCATコール(および対応するLSP)はVCGに関連付けられているか、減少の場合、関連性が削除されます。増加の場合、コールはVCGとの既存の関連性を持たないはずであることに注意してください。

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

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

1. どちらの場合も、他の変更の前に、VCGに関連付けられた既存のVCAT呼び出しごとにVCAT TLVを含むCALL_ATTRIBUTESオブジェクトを使用して通知メッセージを送信する必要があります。TLVのアクションフィールドは2に設定する必要があります。VCGIDフィールドは、VCGと一致するように設定する必要があります。メンバーフィールドの数は、帯域幅の変更後にVCGに関連付けられると予想されるすべてのLSPの合計に等しくなければなりません。[RFC4974]に記載されているように、通話設定をサポートするために、通知メッセージはフォーマットおよび処理されます。通知メッセージの処理中にエラーが発生した場合、メンバーの数は変化前の値に戻り、増加は中止されます。上記のように、通信済みのメンバーの数は、通知メッセージに合図する必要があります。これらの通知メッセージの処理で遭遇する障害は、[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.

2. 既存の呼び出しがVCGの新しい数のメンバーについて正常に通知されると、帯域幅の変更を行うことができます。次のステップは、上記の2つのケースに依存します。上記の最初のケースでは、帯域幅の変化は、[RFC4974]で定義された手順ごとにVCATコールとの間、またはVCAT呼び出しとの間、または削除(減少の場合)を追加するか(減少の場合)除去することにより行われます。2番目のケースでは、セクション5.3.3で定義されている手順を増加させ、セクション5.3.4で定義した手順を減少させます。

6. Error Conditions and Codes
6. エラー条件とコード

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.

VCATコールとメンバーLSPセットアップは、さまざまな理由で拒否できます。[RFC4974]で説明されているコール手順と関連するエラーコードに加えて、以下は、このドキュメントで定義されている手順を使用している際に発生するエラー条件のリストです。これらはRSVPエラーコード39に該当します。

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

これらは、VCATコールを設定したり、VCGをVCAT呼び出しに関連付けたりするときに発生する可能性があります。

      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
        

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.

コールまたはLSP施設の障害は、VCG全体の障害として扱われ、VCGが削除されることに関連する呼び出しとLSPをトリガーする場合があります。

7. IANA Considerations
7. IANAの考慮事項
7.1. RSVP Call Attribute TLV
7.1. RSVPコール属性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は、http://www.iana.orgから入手可能な「rsvpパラメーター」レジストリの「call属性TLV」セクションで次の割り当てを行いました。

IANA has made assignments from the Call Attributes TLV [RFC6001] portions of this registry.

IANAは、このレジストリのコール属性TLV [RFC6001]部分から割り当てを行っています。

This document introduces a new Call Attributes TLV:

このドキュメントでは、新しいコール属性TLVを紹介します。

           TLV Value     Name                       Reference
           ---------     ----------------------     ---------
           4             VCAT TLV                   [RFC6344]
        
7.2. RSVP Error Codes and Error Values
7.2. RSVPエラーコードとエラー値

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

新しいRSVPエラーコードと新しいエラー値が導入されています。IANAは、サブレジストリ「エラーコードとグローバルに定義されたエラー値サブコード」を使用して、「RSVPパラメーター」レジストリから以下を割り当てました。

o Error Codes:

o エラーコード:

- VCAT Call Management (39)

- VCATコール管理(39)

o Error Values:

o エラー値:

         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
        
7.3. VCAT Elementary Signal Registry
7.3. VCAT初等信号レジストリ

IANA created a registry to track elementary signal types as defined in Section 5.2. New allocations are by "IETF Review" [RFC5226].

IANAは、セクション5.2で定義されている基本信号タイプを追跡するレジストリを作成しました。新しい割り当ては、「IETFレビュー」[RFC5226]によるものです。

IANA maintains the following information:

IANAは次の情報を維持しています。

- Value - Type (Elementary Signal) - RFC

- 値 - タイプ(初等信号)-RFC

The available range is 0 - 65535.

使用可能な範囲は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.

レジストリには、当初、このドキュメントのセクション5.2に示されている値が入力されています。値0は予約されています。その他の値は、割り当てされていないマークです。

7.4. VCAT VCG Operation Actions
7.4. VCAT VCG操作アクション

IANA created a registry to track VCAT VCG operation actions as defined in Section 5.2. New allocations are by "IETF Review" [RFC5226].

IANAは、セクション5.2で定義されているように、VCAT VCG操作アクションを追跡するレジストリを作成しました。新しい割り当ては、「IETFレビュー」[RFC5226]によるものです。

IANA maintains the following information:

IANAは次の情報を維持しています。

- Value - Meaning - RFC

- 値 - 意味-RFC

The available range is 0 - 255.

使用可能な範囲は0〜255です。

The registry has been initially populated with the values shown in Section 5.2 of this document. Other values are marked Unassigned.

レジストリには、当初、このドキュメントのセクション5.2に示されている値が入力されています。その他の値は、割り当てされていないマークです。

8. Security Considerations
8. セキュリティに関する考慮事項

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.

このドキュメントでは、[RFC3473]で最初に指定され、[RFC4974]によって変更されたように、GMPLSシグナリングのNotifyメッセージとAdmin_Statusオブジェクトの特定の使用を紹介します。新しいシグナル伝達メッセージは導入されず、制御プレーンに隣接するLSR間の関係も変化しません。傍受が発生した場合、多様にルーティングされたコントロールプレーンLSPに関連付けられたコール情報は、これらが異なるルートをとる同じVCATグループのメンバーであることを示している可能性があり、VCGコールの信頼性が向上することをインターセプターに示している可能性があります。

See [RFC5920] for additional information on GMPLS security.

GMPLSセキュリティの追加情報については、[RFC5920]を参照してください。

9. Contributors
9. 貢献者

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

ワタル・イマジュク(NTT)1-1 hikari-no-oka yokosuka kanagawa 239-0847日本

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

電話81-46-859-4315メール:imajuku.wataru@lab.ntt.co.jp

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

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

Lyndon Ong Ciena PO Box 308 Cupertino、CA 95015 USA

   Phone: +1 408 705 2978
   EMail: lyong@ciena.com
        
10. Acknowledgments
10. 謝辞

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. 参考文献
11.1. Normative References
11.1. 引用文献

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリングリソース予約プロトコルトラフィックエンジニアリング(RSVP-TE)拡張」、RFC 3473、2003年1月。

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

[RFC4606] Mannie、E。およびD. Papadimitriou、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)同期光学ネットワーク(SONET)および同期デジタル階層(SDH)コントロールの拡張機能」、RFC 4606、2006年8月。

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

[RFC4974] Papadimitriou、D。およびA. Farrel、「一般化されたMPLS(GMPLS)RSVP-TEシグナル伝達拡張機能」、RFC 4974、2007年8月。

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

[RFC6001] Papadimitriou、D.、Vigoureux、M.、Shiomoto、K.、Brungard、D。、およびJl。Le Roux、「マルチレイヤーおよびマルチリージョンネットワーク(MLN/MRN)の一般化MPLS(GMPLS)プロトコル拡張」、RFC 6001、2010年10月。

11.2. Informative References
11.2. 参考引用

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

[ANSI-T1.105] American National Standards Institute、「同期光ネットワーク(SONET) - 多重構造、レート、フォーマットを含む基本的な説明」、ANSI T1.105-2001、2001年5月。

[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.707] International Telecommunication Union、「同期デジタル階層のネットワークノードインターフェイス(SDH)」、ITU-T推奨G.707、2003年12月。

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

[ITU-T-G.709] International Telecommunication Union、「光輸送ネットワークのインターフェイス(OTN)」、ITU-T推奨G.709、2003年3月。

[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.7042] International Telecommunication Union、「仮想連結信号のリンク容量調整スキーム(LCAS)」、ITU-T推奨G.7042、2006年3月。

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

[ITU-T-G.7043] International Telecommunication Union、「プレシオクロナスデジタル階層(PDH)シグナルの仮想連合」、ITU-T推奨G.7043、2004年7月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.

[RFC5920] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。

Authors' Addresses

著者のアドレス

Greg M. Bernstein (editor) Grotto Networking Fremont, CA USA

グレッグM.バーンスタイン(編集者)洞窟ネットワーキングフリーモント、カリフォルニア州アメリカ

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

電話:(510)573-2237メール:gregb@grotto-networking.com

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

Diego Caviglia Ericssonを介して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

Richard Rabbat Google、Inc。1600 Amphitheater Parkway Mountain View、CA 94043 USA

   EMail: rabbat@alum.mit.edu
        

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

Huub Van Helvoort Huawei Technologies、Ltd。Kolkgriend 38、1356 BC Almere the Netherlands

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