[要約] RFC 3946は、GMPLSを使用してSONETおよびSDH制御を拡張するための規格です。このRFCの目的は、SONETおよびSDHネットワークの制御を効率化し、柔軟性を向上させることです。
Network Working Group E. Mannie
Request for Comments: 3946 Consultant
Category: Standards Track D. Papadimitriou
Alcatel
October 2004
Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
同期光ネットワーク (SONET) および同期デジタル階層 (SDH) 制御用の汎用マルチプロトコル ラベル スイッチング (GMPLS) 拡張
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネット コミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めます。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1) を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
Abstract
概要
This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling.
この文書は、Generalized Multi-Protocol Label Switching (GMPLS) シグナリングの補足です。これは、GMPLS シグナリングを使用するときに必要な同期光ネットワーク (SONET)/同期デジタル階層 (SDH) テクノロジー固有の情報を定義します。
Table of Contents
目次
1. Introduction ................................................. 2
2. SONET and SDH Traffic Parameters ............................. 2
2.1. SONET/SDH Traffic Parameters ........................... 3
2.2. RSVP-TE Details ........................................ 9
2.3. CR-LDP Details ......................................... 9
3. SONET and SDH Labels ......................................... 10
4. Acknowledgments .............................................. 15
5. Security Considerations ...................................... 16
6. IANA Considerations .......................................... 16
7. References ................................................... 16
7.1. Normative References ................................... 16
Appendix 1 - Signal Type Values Extension for VC-3 ............... 18
Annex 1 - Examples ............................................... 18
Contributors ..................................................... 21
Authors' Addresses ............................................... 25
Full Copyright Statement ......................................... 26
As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS from supporting packet (Packet Switching Capable - PSC) interfaces and switching to include support of four new classes of interfaces and switching: Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC). A functional description of the extensions to MPLS signaling needed to support the new classes of interfaces and switching is provided in [RFC3471]. [RFC3473] describes RSVP-TE specific formats and mechanisms needed to support all five classes of interfaces, and CR-LDP extensions can be found in [RFC3472]. This document presents details that are specific to Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH). Per [RFC3471], SONET/SDH specific parameters are carried in the signaling protocol in traffic parameter specific objects.
[RFC3945] で説明されているように、汎用 MPLS (GMPLS) は、パケット (パケット交換機能 - PSC) インターフェイスとスイッチングのサポートから MPLS を拡張し、次の 4 つの新しいクラスのインターフェイスとスイッチングのサポートを含めます。分割多重 (TDM)、ラムダ スイッチ対応 (LSC)、およびファイバー スイッチ対応 (FSC)。新しいクラスのインターフェイスとスイッチングをサポートするために必要な MPLS シグナリングの拡張の機能説明は、[RFC3471] で提供されています。[RFC3473] では、5 つのクラスのインターフェイスすべてをサポートするために必要な RSVP-TE 固有のフォーマットとメカニズムが説明されており、CR-LDP 拡張機能は [RFC3472] で見つけることができます。このドキュメントでは、Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) に固有の詳細を説明します。[RFC3471] に従って、SONET/SDH 固有のパラメータは、トラフィック パラメータ固有のオブジェクト内のシグナリング プロトコルで伝送されます。
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 [RFC2119].
この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。[RFC2119] に記載されているように解釈されます。
Moreover, the reader is assumed to be familiar with the terminology in ANSI [T1.105], ITU-T [G.707] as well as [RFC3471], [RFC3472], and [RFC3473]. The following abbreviations are used in this document:
さらに、読者は ANSI [T1.105]、ITU-T [G.707]、および [RFC3471]、[RFC3472]、[RFC3473] の用語に精通しているものと想定されます。このドキュメントでは次の略語が使用されています。
DCC: Data Communications Channel. LOVC: Lower Order Virtual Container HOVC: Higher Order Virtual Container MS: Multiplex Section. MSOH: Multiplex Section overhead. POH: Path overhead. RS: Regenerator Section. RSOH: Regenerator section overhead. SDH: Synchronous digital hierarchy. SOH: Section overhead. SONET: Synchronous Optical Network. SPE: Synchronous Payload Envelope. STM(-N): Synchronous Transport Module (-N) (SDH). STS(-N): Synchronous Transport Signal-Level N (SONET). VC-n: Virtual Container-n (SDH). VTn: Virtual Tributary-n (SONET).
DCC: データ通信チャネル。LOVC: 下位仮想コンテナ HOVC: 上位仮想コンテナ MS: マルチプレックスセクション。MSOH: マルチプレックス セクションのオーバーヘッド。POH: パスのオーバーヘッド。RS: 再生器セクション。RSOH: 再生セクションのオーバーヘッド。SDH: 同期デジタル階層。SOH: セクションのオーバーヘッド。SONET: 同期光ネットワーク。SPE: 同期ペイロード エンベロープ。STM(-N): 同期トランスポート モジュール (-N) (SDH)。STS(-N): 同期トランスポート信号レベル N (SONET)。VC-n: 仮想コンテナ-n (SDH)。VTn: 仮想トリビュタリ-n (SONET)。
This section defines the GMPLS traffic parameters for SONET/SDH. The protocol specific formats, for the SONET/SDH-specific RSVP-TE objects and CR-LDP TLVs are described in sections 2.2 and 2.3 respectively.
このセクションでは、SONET/SDH の GMPLS トラフィック パラメータを定義します。SONET/SDH 固有の RSVP-TE オブジェクトと CR-LDP TLV のプロトコル固有の形式については、それぞれセクション 2.2 と 2.3 で説明します。
These traffic parameters specify indeed a base set of capabilities for SONET ANSI [T1.105] and SDH ITU-T [G.707] such as concatenation and transparency. Other documents may further enhance this set of capabilities in the future. For instance, signaling for SDH over PDH ITU-T G.832 or sub-STM-0 ITU-T G.708 interfaces could be defined.
これらのトラフィック パラメータは、確かに、連結や透過性など、SONET ANSI [T1.105] および SDH ITU-T [G.707] の基本機能セットを指定します。将来的には、他のドキュメントによってこの一連の機能がさらに強化される可能性があります。たとえば、PDH ITU-T G.832 またはサブ STM-0 ITU-T G.708 インターフェイス上の SDH のシグナリングを定義できます。
The traffic parameters defined hereafter (see Section 2.1) MUST be used when the label is encoded as SUKLM as defined in this memo (see Section 3). They MUST also be used when requesting one of Section/RS or Line/MS overhead transparent STS-1/STM-0, STS-3*N/STM-N (N=1, 4, 16, 64, 256) signals.
ラベルがこのメモで定義されているように SUKLM としてエンコードされている場合 (セクション 3 を参照)、今後定義されるトラフィック パラメータ (セクション 2.1 を参照) を使用しなければなりません (MUST)。これらは、セクション/RS またはライン/MS オーバーヘッド透過 STS-1/STM-0、STS-3*N/STM-N (N=1、4、16、64、256) 信号のいずれかを要求するときにも使用しなければなりません。
The traffic parameters and label encoding defined in [RFC3471], Section 3.2, MUST be used for fully transparent STS-1/STM-0, STS-3*N/STM-N (N=1, 4, 16, 64, 256) signal requests. A fully transparent signal is one for which all overhead is left unmodified by intermediate nodes, i.e., when all defined Transparency (T) bits would be set if the traffic parameters defined in section 2.1 were used.
[RFC3471] セクション 3.2 で定義されているトラフィック パラメータとラベル エンコーディングは、完全に透過的な STS-1/STM-0、STS-3*N/STM-N (N=1、4、16、64、256) に使用しなければなりません (MUST)。) シグナルリクエスト。完全に透明な信号とは、すべてのオーバーヘッドが中間ノードによって変更されない信号です。つまり、セクション 2.1 で定義されたトラフィック パラメータが使用された場合に、定義されたすべての透明性 (T) ビットが設定される場合です。
The traffic parameters for SONET/SDH are organized as follows:
SONET/SDH のトラフィック パラメータは次のように構成されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | RCC | NCC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transparency (T) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile (P) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Annex 1 lists examples of SONET and SDH signal coding.
付録 1 に、SONET および SDH 信号コーディングの例を示します。
Signal Type (ST): 8 bits
信号タイプ(ST): 8ビット
This field indicates the type of Elementary Signal that comprises the requested LSP. Several transforms can be applied successively on the Elementary Signal to build the Final Signal being actually requested for the LSP.
このフィールドは、要求された LSP を構成する基本信号のタイプを示します。いくつかの変換を基本信号に連続的に適用して、LSP に対して実際に要求される最終信号を構築できます。
Each transform application is optional and must be ignored if zero, except the Multiplier (MT) that cannot be zero and is ignored if equal to one.
各変換アプリケーションはオプションであり、ゼロの場合は無視する必要があります。ただし、乗数 (MT) はゼロにすることができず、1 の場合は無視されます。
Transforms must be applied strictly in the following order:
変換は厳密に次の順序で適用する必要があります。
- First, contiguous concatenation (by using the RCC and NCC fields) can be optionally applied on the Elementary Signal, resulting in a contiguously concatenated signal.
- まず、連続連結 (RCC および NCC フィールドを使用) を基本信号にオプションで適用することができ、その結果、連続連結信号が得られます。
- Second, virtual concatenation (by using the NVC field) can be optionally applied on the Elementary Signal resulting in a virtually concatenated signal.
- 第 2 に、(NVC フィールドを使用した) 仮想連結を基本信号にオプションで適用することができ、その結果、仮想的に連結された信号が得られます。
- Third, some transparency (by using the Transparency field) can be optionally specified when requesting a frame as signal rather than an SPE or VC based signal.
- 第三に、SPE または VC ベースの信号ではなく信号としてフレームを要求するときに、ある程度の透明性 (Transparency フィールドを使用することによる) をオプションで指定できます。
- Fourth, a multiplication (by using the Multiplier field) can be optionally applied either directly on the Elementary Signal, or on the contiguously concatenated signal obtained from the first phase, or on the virtually concatenated signal obtained from the second phase, or on these signals combined with some transparency.
- 第 4 に、(Multiplier フィールドを使用した) 乗算は、基本信号に直接、または最初のフェーズから取得された連続的に連結された信号、または 2 番目のフェーズから取得された仮想的に連結された信号、またはこれらの信号にオプションで適用できます。ある程度の透明感を兼ね備えています。
Permitted Signal Type values for SONET/SDH are:
SONET/SDH で許可される信号タイプの値は次のとおりです。
Value Type (Elementary Signal)
----- ------------------------
1 VT1.5 SPE / VC-11
2 VT2 SPE / VC-12
3 VT3 SPE
4 VT6 SPE / VC-2
5 STS-1 SPE / VC-3
6 STS-3c SPE / VC-4
7 STS-1 / STM-0 (only when requesting transparency)
8 STS-3 / STM-1 (only when requesting transparency)
9 STS-12 / STM-4 (only when requesting transparency)
10 STS-48 / STM-16 (only when requesting transparency)
11 STS-192 / STM-64 (only when requesting transparency)
12 STS-768 / STM-256 (only when requesting transparency)
A dedicated signal type is assigned to a SONET STS-3c SPE instead of coding it as a contiguous concatenation of three STS-1 SPEs. This is done in order to provide easy interworking between SONET and SDH signaling.
SONET STS-3c SPE は、3 つの STS-1 SPE の連続連結としてコーディングされるのではなく、専用の信号タイプが割り当てられます。これは、SONET と SDH シグナリング間の相互作用を容易にするために行われます。
Appendix 1 adds one signal type (optional) to the above values.
付録 1 では、上記の値に 1 つの信号タイプ (オプション) が追加されます。
Requested Contiguous Concatenation (RCC): 8 bits
要求された連続連結 (RCC): 8 ビット
This field is used to request the optional SONET/SDH contiguous concatenation of the Elementary Signal.
このフィールドは、基本信号のオプションの SONET/SDH 連続連結を要求するために使用されます。
This field is a vector of flags. Each flag indicates the support of a particular type of contiguous concatenation. Several flags can be set at the same time to indicate a choice.
このフィールドはフラグのベクトルです。各フラグは、特定のタイプの連続連結のサポートを示します。選択を示すために、複数のフラグを同時に設定できます。
These flags allow an upstream node to indicate to a downstream node the different types of contiguous concatenation that it supports. However, the downstream node decides which one to use according to its own rules.
これらのフラグにより、上流ノードは、サポートするさまざまなタイプの連続連結を下流ノードに示すことができます。ただし、下流ノードは独自のルールに従ってどちらを使用するかを決定します。
A downstream node receiving simultaneously more than one flag chooses a particular type of contiguous concatenation, if any supported, and based on criteria that are out of this document scope. A downstream node that doesn't support any of the concatenation types indicated by the field must refuse the LSP request. In particular, it must refuse the LSP request if it doesn't support contiguous concatenation at all.
複数のフラグを同時に受信した下流ノードは、サポートされている場合は、この文書の範囲外の基準に基づいて、特定のタイプの連続連結を選択します。フィールドで示された連結タイプをサポートしないダウンストリーム ノードは、LSP リクエストを拒否する必要があります。特に、連続連結をまったくサポートしていない場合は、LSP リクエストを拒否する必要があります。
When several flags have been set, the upstream node retrieves the (single) type of contiguous concatenation the downstream node has selected by looking at the position indicated by the first label and the number of label(s) as returned by the downstream node (see also Section 3).
複数のフラグが設定されている場合、上流ノードは、最初のラベルで示される位置と、下流ノードから返されたラベルの数を確認することによって、下流ノードが選択した (単一の) タイプの連続連結を取得します (「セクション 3 も参照)。
The entire field is set to zero to indicate that no contiguous concatenation is requested at all (default value). A non-zero field indicates that some contiguous concatenation is requested.
連続した連結がまったく要求されないことを示すために、フィールド全体が 0 に設定されます (デフォルト値)。ゼロ以外のフィールドは、何らかの連続した連結が要求されていることを示します。
The following flag is defined:
次のフラグが定義されています。
Flag 1 (bit 1): Standard contiguous concatenation.
フラグ 1 (ビット 1): 標準の連続連結。
Flag 1 indicates that the standard SONET/SDH contiguous concatenation as defined in [T1.105]/[G.707] is supported. Note that bit 1 is the low order bit. Other flags are reserved for extensions, if not used they must be set to zero when sent, and should be ignored when received.
フラグ 1 は、[T1.105]/[G.707] で定義されている標準の SONET/SDH 連続連結がサポートされていることを示します。ビット 1 が下位ビットであることに注意してください。他のフラグは拡張用に予約されており、使用しない場合は送信時にゼロに設定する必要があり、受信時に無視する必要があります。
See note 1 hereafter in the section on the NCC about the SONET contiguous concatenation of STS-1 SPEs when the number of components is a multiple of three.
コンポーネントの数が 3 の倍数である場合の STS-1 SPE の SONET 連続連結については、NCC に関するセクションの注 1 を参照してください。
Number of Contiguous Components (NCC): 16 bits
連続コンポーネント数 (NCC): 16 ビット
This field indicates the number of identical SONET SPEs/SDH VCs (i.e., Elementary Signal) that are requested to be concatenated, as specified in the RCC field.
このフィールドは、RCC フィールドで指定されているように、連結が要求される同一の SONET SPE/SDH VC (つまりエレメンタリ シグナル) の数を示します。
Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the Elementary Signal to use must always be an STS-3c_SPE signal type and the value of NCC must always be equal to X. This allows also facilitating the interworking between SONET and SDH. In particular, it means that the contiguous concatenation of three STS-1 SPEs can not be requested because according to this specification, this type of signal must be coded using the STS-3c SPE signal type.
注 1: N=3*X で SONET STS-Nc SPE を要求する場合、使用する基本信号は常に STS-3c_SPE 信号タイプである必要があり、NCC の値は常に X に等しい必要があります。これにより、インターワーキングも容易になります。SONET と SDH の間。特に、この仕様によれば、このタイプの信号は STS-3c SPE 信号タイプを使用してコーディングする必要があるため、3 つの STS-1 SPE の連続連結は要求できないことを意味します。
Note 2: when requesting a transparent STS-N/STM-N signal limited to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc, the signal type must be STS-N/STM-N, RCC with flag 1 and NCC set to 1.
注 2: 単一の連続連結 STS-Nc_SPE/VC-4-Nc に限定された透過 STS-N/STM-N 信号を要求する場合、信号タイプは STS-N/STM-N、フラグ 1 付きの RCC、および NCC である必要があります。1に設定します。
The NCC value must be consistent with the type of contiguous concatenation being requested in the RCC field. In particular, this field is irrelevant if no contiguous concatenation is requested (RCC = 0), in that case it must be set to zero when sent, and should be ignored when received. A RCC value different from 0 must imply a number of contiguous components greater than 1.
NCC 値は、RCC フィールドで要求されている連続連結のタイプと一致している必要があります。特に、連続した連結が要求されていない場合 (RCC = 0)、このフィールドは無関係です。その場合、送信時にゼロに設定する必要があり、受信時に無視する必要があります。0 以外の RCC 値は、1 より大きい連続コンポーネントの数を意味する必要があります。
Number of Virtual Components (NVC): 16 bits
仮想コンポーネント (NVC) の数: 16 ビット
This field indicates the number of signals that are requested to be virtually concatenated. These signals are all of the same type by definition. They are Elementary Signal SPEs/VCs for which signal types are defined in this document, i.e., VT1.5_SPE/VC-11, VT2_SPE/VC-12, VT3_SPE, VT6_SPE/VC-2, STS-1_SPE/VC-3 or STS-3c_SPE/VC-4.
このフィールドは、仮想連結が要求される信号の数を示します。これらの信号は定義上、すべて同じタイプです。これらは、このドキュメントで信号タイプが定義されている基本信号 SPE/VC です。つまり、VT1.5_SPE/VC-11、VT2_SPE/VC-12、VT3_SPE、VT6_SPE/VC-2、STS-1_SPE/VC-3、または STS です。-3c_SPE/VC-4。
This field is set to 0 (default value) to indicate that no virtual concatenation is requested.
このフィールドは 0 (デフォルト値) に設定され、仮想連結が要求されないことを示します。
Multiplier (MT): 16 bits
乗算器(MT): 16ビット
This field indicates the number of identical signals that are requested for the LSP, i.e., that form the Final Signal. These signals can be either identical Elementary Signals, or identical contiguously concatenated signals, or identical virtually concatenated signals. Note that all these signals belong thus to the same LSP.
このフィールドは、LSP に対して要求される、つまり最終信号を形成する同一の信号の数を示します。これらの信号は、同一の基本信号、同一の連続的に連結された信号、または同一の仮想的に連結された信号のいずれかにすることができます。したがって、これらの信号はすべて同じ LSP に属していることに注意してください。
The distinction between the components of multiple virtually concatenated signals is done via the order of the labels that are specified in the signaling. The first set of labels must describe the first component (set of individual signals belonging to the first virtual concatenated signal), the second set must describe the second component (set of individual signals belonging to the second virtual concatenated signal) and so on.
仮想的に連結された複数の信号のコンポーネント間の区別は、シグナリングで指定されたラベルの順序によって行われます。最初のラベルのセットは最初のコンポーネント (最初の仮想連結信号に属する個々の信号のセット) を記述し、2 番目のラベルのセットは 2 番目のコンポーネント (2 番目の仮想連結信号に属する個々の信号のセット) を記述する必要があります。
This field is set to one (default value) to indicate that exactly one instance of a signal is being requested. Intermediate and egress nodes MUST verify that the node itself and the interfaces on which the LSP will be established can support the requested multiplier value. If the requested values can not be supported, the receiver node MUST generate a PathErr/NOTIFICATION message (see Section 2.2/2.3, respectively).
このフィールドは 1 (デフォルト値) に設定され、信号のインスタンスが 1 つだけ要求されていることを示します。中間ノードと出口ノードは、ノード自体と LSP が確立されるインターフェイスが要求された乗数の値をサポートできることを検証しなければなりません (MUST)。要求された値がサポートできない場合、受信ノードは PathErr/NOTIFICATION メッセージを生成しなければなりません (それぞれセクション 2.2/2.3 を参照)。
Zero is an invalid value. If received, the node MUST generate a PathErr/NOTIFICATION message (see Section 2.2/2.3, respectively).
ゼロは無効な値です。受信した場合、ノードは PathErr/NOTIFICATION メッセージを生成しなければなりません (それぞれセクション 2.2/2.3 を参照)。
Note 1: when requesting a transparent STS-N/STM-N signal limited to a single contiguously concatenated STS-Nc-SPE/VC-4-Nc, the multiplier field MUST be equal to 1 (only valid value).
注 1: 単一の連続的に連結された STS-Nc-SPE/VC-4-Nc に限定された透過的な STS-N/STM-N 信号を要求する場合、乗数フィールドは 1 (有効な値のみ) に等しくなければなりません。
Transparency (T): 32 bits
透明度(T): 32ビット
This field is a vector of flags that indicates the type of transparency being requested. Several flags can be combined to provide different types of transparency. Not all combinations are necessarily valid. The default value for this field is zero, i.e., no transparency requested.
このフィールドは、要求されている透明度のタイプを示すフラグのベクトルです。いくつかのフラグを組み合わせて、さまざまな種類の透明度を提供できます。すべての組み合わせが必ずしも有効であるとは限りません。このフィールドのデフォルト値はゼロです。つまり、透明性は要求されません。
Transparency, as defined from the point of view of this signaling specification, is only applicable to the fields in the SONET/SDH frame overheads. In the SONET case, these are the fields in the Section Overhead (SOH), and the Line Overhead (LOH). In the SDH case, these are the fields in the Regenerator Section Overhead (RSOH), the Multiplex Section overhead (MSOH), and the pointer fields between the two. With SONET, the pointer fields are part of the LOH.
このシグナリング仕様の観点から定義される透明性は、SONET/SDH フレーム オーバーヘッドのフィールドにのみ適用されます。SONET の場合、これらはセクション オーバーヘッド (SOH) およびライン オーバーヘッド (LOH) のフィールドです。SDH の場合、これらは、Regenerator Section Overhead (RSOH)、Multiplex Section Overhead (MSOH) のフィールド、および 2 つの間のポインタ フィールドです。SONET では、ポインタ フィールドは LOH の一部です。
Note as well that transparency is only applicable when using the following Signal Types: STS-1/STM-0, STS-3/STM-1, STS-12/STM-4, STS-48/STM-16, STS-192/STM-64 and STS-768/STM-256. At least one transparency type must be specified when requesting such a signal type.
また、透過性は次の信号タイプを使用する場合にのみ適用されることにも注意してください: STS-1/STM-0、STS-3/STM-1、STS-12/STM-4、STS-48/STM-16、STS-192/STM-64 および STS-768/STM-256。このような信号タイプを要求する場合は、少なくとも 1 つの透明度タイプを指定する必要があります。
Transparency indicates precisely which fields in these overheads must be delivered unmodified at the other end of the LSP. An ingress LSR requesting transparency will pass these overhead fields that must be delivered to the egress LSR without any change. From the ingress and egress LSRs point of views, these fields must be seen as unmodified.
透明性は、これらのオーバーヘッドのどのフィールドを変更せずに LSP の他端に配信する必要があるかを正確に示します。透過性を要求する入力 LSR は、変更せずに出力 LSR に配信する必要があるこれらのオーバーヘッド フィールドを渡します。入力および出力 LSR の観点からは、これらのフィールドは変更されていないと見なす必要があります。
Transparency is not applied at the interfaces with the initiating and terminating LSRs, but is only applied between intermediate LSRs.
透過性は、開始 LSR と終了 LSR とのインターフェイスでは適用されず、中間 LSR 間にのみ適用されます。
The transparency field is used to request an LSP that supports the requested transparency type; it may also be used to setup the transparency process to be applied at each intermediate LSR.
透明度フィールドは、要求された透明度タイプをサポートする LSP を要求するために使用されます。また、各中間 LSR で適用される透明プロセスを設定するために使用することもできます。
The different transparency flags are the following:
さまざまな透明度フラグは次のとおりです。
Flag 1 (bit 1): Section/Regenerator Section layer. Flag 2 (bit 2): Line/Multiplex Section layer.
フラグ 1 (ビット 1): セクション/リジェネレータ セクション層。フラグ 2 (ビット 2): ライン/多重セクション層。
Where bit 1 is the low order bit. Other flags are reserved, they should be set to zero when sent, and should be ignored when received. A flag is set to one to indicate that the corresponding transparency is requested.
ここで、ビット 1 は下位ビットです。他のフラグは予約されており、送信時にはゼロに設定され、受信時には無視される必要があります。フラグが 1 に設定され、対応する透明度が要求されていることを示します。
Intermediate and egress nodes MUST verify that the node itself and the interfaces on which the LSP will be established can support the requested transparency. If the requested flags can not be supported, the receiver node MUST generate a PathErr/NOTIFICATION message (see Section 2.2/2.3, respectively).
中間ノードと出力ノードは、ノード自体と LSP が確立されるインターフェイスが要求された透過性をサポートできることを検証しなければなりません (MUST)。要求されたフラグがサポートできない場合、受信ノードは PathErr/NOTIFICATION メッセージを生成しなければなりません (それぞれセクション 2.2/2.3 を参照)。
Section/Regenerator Section layer transparency means that the entire frames must be delivered unmodified. This implies that pointers cannot be adjusted. When using Section/Regenerator Section layer transparency all other flags MUST be ignored.
セクション/リジェネレータ セクション層の透明性は、フレーム全体が変更されずに配信される必要があることを意味します。これは、ポインターを調整できないことを意味します。セクション/リジェネレーターセクションレイヤーの透明性を使用する場合、他のすべてのフラグを無視する必要があります。
Line/Multiplex Section layer transparency means that the LOH/MSOH must be delivered unmodified. This implies that pointers cannot be adjusted.
ライン/多重セクション層の透明性は、LOH/MSOH が変更されずに配信される必要があることを意味します。これは、ポインターを調整できないことを意味します。
Profile (P): 32 bits
プロファイル（P）：32ビット
This field is intended to indicate particular capabilities that must be supported for the LSP, for example monitoring capabilities.
このフィールドは、モニタリング機能など、LSP でサポートする必要がある特定の機能を示すことを目的としています。
No standard profile is currently defined and this field SHOULD be set to zero when transmitted and SHOULD be ignored when received.
現在、標準プロファイルは定義されておらず、このフィールドは送信時にゼロに設定されるべきであり、受信時に無視されるべきです。
In the future TLV based extensions may be created.
将来的には、TLV ベースの拡張機能が作成される可能性があります。
For RSVP-TE, the SONET/SDH traffic parameters are carried in the SONET/SDH SENDER_TSPEC and FLOWSPEC objects. The same format is used both for SENDER_TSPEC object and FLOWSPEC objects. The content of the objects is defined above in Section 2.1. The objects have the following class and type:
RSVP-TE の場合、SONET/SDH トラフィック パラメータは SONET/SDH SENDER_TSPEC および FLOWSPEC オブジェクトで伝送されます。SENDER_TSPEC オブジェクトと FLOWSPEC オブジェクトの両方に同じ形式が使用されます。オブジェクトの内容は上記のセクション 2.1 で定義されています。オブジェクトには次のクラスとタイプがあります。
For SONET ANSI T1.105 and SDH ITU-T G.707:
SONET ANSI T1.105 および SDH ITU-T G.707 の場合:
SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4
SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4
There is no Adspec associated with the SONET/SDH SENDER_TSPEC. Either the Adspec is omitted or an int-serv Adspec with the Default General Characterization Parameters and Guaranteed Service fragment is used, see [RFC2210].
SONET/SDH SENDER_TSPEC に関連付けられた Adspec はありません。Adspec が省略されるか、デフォルトの一般特性パラメータと保証サービスフラグメントを備えた int-serv Adspec が使用されます。[RFC2210] を参照してください。
For a particular sender in a session the contents of the FLOWSPEC object received in a Resv message SHOULD be identical to the contents of the SENDER_TSPEC object received in the corresponding Path message. If the objects do not match, a ResvErr message with a "Traffic Control Error/Bad Flowspec value" error SHOULD be generated.
セッション内の特定の送信者の場合、Resv メッセージで受信した FLOWSPEC オブジェクトの内容は、対応する Path メッセージで受信した SENDER_TSPEC オブジェクトの内容と同一である必要があります (SHOULD)。オブジェクトが一致しない場合、「トラフィック制御エラー/不正なフロースペック値」エラーを含む ResvErr メッセージが生成されるべきです (SHOULD)。
Intermediate and egress nodes MUST verify that the node itself and the interfaces on which the LSP will be established can support the requested Signal Type, RCC, NCC, NVC and Multiplier (as defined in Section 2.1). If the requested value(s) can not be supported, the receiver node MUST generate a PathErr message with a "Traffic Control Error/ Service unsupported" indication (see [RFC2205]).
中間ノードと出口ノードは、ノード自体と LSP が確立されるインターフェースが、要求された信号タイプ、RCC、NCC、NVC、乗算器 (セクション 2.1 で定義) をサポートできることを検証しなければなりません (MUST)。要求された値がサポートできない場合、受信ノードは「トラフィック制御エラー/サービスがサポートされていない」ことを示す PathErr メッセージを生成しなければなりません ([RFC2205] を参照)。
In addition, if the MT field is received with a zero value, the node MUST generate a PathErr message with a "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]).
さらに、MT フィールドがゼロ値で受信された場合、ノードは「トラフィック制御エラー/不正な Tspec 値」を示す PathErr メッセージを生成しなければなりません ([RFC2205] を参照)。
Intermediate nodes MUST also verify that the node itself and the interfaces on which the LSP will be established can support the requested Transparency (as defined in Section 2.1). If the requested value(s) can not be supported, the receiver node MUST generate a PathErr message with a "Traffic Control Error/Service unsupported" indication (see [RFC2205]).
中間ノードは、ノード自体と LSP が確立されるインターフェースが要求された透明性 (セクション 2.1 で定義) をサポートできることも検証しなければなりません (MUST)。要求された値がサポートできない場合、受信ノードは「トラフィック制御エラー/サービスがサポートされていない」ことを示す PathErr メッセージを生成しなければなりません ([RFC2205] を参照)。
For CR-LDP, the SONET/SDH traffic parameters are carried in the SONET/SDH Traffic Parameters TLV. The content of the TLV is defined above in Section 2.1. The header of the TLV has the following format:
CR-LDP の場合、SONET/SDH トラフィック パラメータは SONET/SDH トラフィック パラメータ TLV で伝送されます。TLV の内容は上記のセクション 2.1 で定義されています。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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type field for the SONET/SDH Traffic Parameters TLV is: 0x0838.
SONET/SDH トラフィック パラメータ TLV のタイプ フィールドは 0x0838 です。
Intermediate and egress nodes MUST verify that the node itself and the interfaces on which the LSP will be established can support the requested Signal Type, RCC, NCC, NVC and Multiplier (as defined in Section 2.1). If the requested value(s) can not be supported, the receiver node MUST generate a NOTIFICATION message with a "Resource Unavailable" status code (see [RFC3212]).
中間ノードと出口ノードは、ノード自体と LSP が確立されるインターフェースが、要求された信号タイプ、RCC、NCC、NVC、乗算器 (セクション 2.1 で定義) をサポートできることを検証しなければなりません (MUST)。要求された値がサポートできない場合、受信ノードは「リソース使用不可」ステータス コードを含む NOTIFICATION メッセージを生成しなければなりません ([RFC3212] を参照)。
In addition, if the MT field is received with a zero value, the node MUST generate a NOTIFICATION message with a "Resource Unavailable" status code (see [RFC3212]).
さらに、MT フィールドがゼロ値で受信された場合、ノードは「リソース使用不可」ステータス コードを含む NOTIFICATION メッセージを生成しなければなりません ([RFC3212] を参照)。
Intermediate nodes MUST also verify that the node itself and the interfaces on which the LSP will be established can support the requested Transparency (as defined in Section 2.1). If the requested value(s) can not be supported, the receiver node MUST generate a NOTIFICATION message with a "Resource Unavailable" status code (see [RFC3212]).
中間ノードは、ノード自体と LSP が確立されるインターフェースが要求された透明性 (セクション 2.1 で定義) をサポートできることも検証しなければなりません (MUST)。要求された値がサポートできない場合、受信ノードは「リソース使用不可」ステータス コードを含む NOTIFICATION メッセージを生成しなければなりません ([RFC3212] を参照)。
SONET and SDH each define a multiplexing structure. Both structures are trees whose roots are respectively an STS-N or an STM-N; and whose leaves are the signals that can be transported via the time-slots and switched between time-slots within an ingress port and time-slots within an egress port, i.e., a VTx SPE, an STS-x SPE or a VC-x. A SONET/SDH label will identify the exact position (i.e., first time-slot) of a particular VTx SPE, STS-x SPE or VC-x signal in a multiplexing structure. SONET and SDH labels are carried in the Generalized Label per [RFC3473] and [RFC3472].
SONET と SDH はそれぞれ多重化構造を定義します。どちらの構造もツリーであり、そのルートはそれぞれ STS-N または STM-N です。そのリーフは、タイムスロットを介して転送され、入力ポート内のタイムスロットと出力ポート内のタイムスロット（つまり、VTx SPE、STS-x SPE、または VC-x）間で切り替えられる信号です。。SONET/SDH ラベルは、多重化構造内の特定の VTx SPE、STS-x SPE、または VC-x 信号の正確な位置 (つまり、最初のタイムスロット) を識別します。SONET および SDH ラベルは、[RFC3473] および [RFC3472] に従って一般化ラベルで伝送されます。
Note that by time-slots we mean the time-slots as they appear logically and sequentially in the multiplex, not as they appear after any possible interleaving.
タイムスロットとは、可能なインターリーブ後に現れるタイムスロットではなく、マルチプレックス内で論理的かつ順次に現れるタイムスロットを意味することに注意してください。
These multiplexing structures will be used as naming trees to create unique multiplex entry names or labels. The same format of label is used for SONET and SDH. As explained in [RFC3471], a label does not identify the "class" to which the label belongs. This is implicitly determined by the link on which the label is used.
これらの多重化構造は、一意の多重化エントリ名またはラベルを作成するための命名ツリーとして使用されます。SONET と SDH では同じ形式のラベルが使用されます。[RFC3471] で説明されているように、ラベルはそのラベルが属する「クラス」を識別しません。これは、ラベルが使用されるリンクによって暗黙的に決定されます。
In case of signal concatenation or multiplication, a list of labels can appear in the Label field of a Generalized Label.
信号の連結または乗算の場合、ラベルのリストが一般化ラベルのラベル フィールドに表示されます。
In case of contiguous concatenation, only one label appears in the Label field. This label identifies the lowest time-slot occupied by the contiguously concatenated signal. By lowest time-slot we mean the one having the lowest label (value) when compared as integer values, i.e., the time-slot occupied by the first component signal of the concatenated signal encountered when descending the tree.
連続連結の場合、「ラベル」フィールドにはラベルが 1 つだけ表示されます。このラベルは、連続的に連結された信号によって占有される最も低いタイムスロットを識別します。最も低いタイムスロットとは、整数値として比較したときに最も低いラベル (値) を持つタイムスロット、つまり、ツリーを下降するときに遭遇する連結信号の最初のコンポーネント信号が占めるタイムスロットを意味します。
In case of virtual concatenation, the explicit ordered list of all labels in the concatenation is given. Each label indicates the first time-slot occupied by a component of the virtually concatenated signal. The order of the labels must reflect the order of the payloads to concatenate (not the physical order of time-slots). The above representation limits virtual concatenation to remain within a single (component) link; it imposes as such a restriction compared to the ANSI [T1.105]/ITU-T [G.707] recommendations.
仮想連結の場合、連結内のすべてのラベルの明示的な順序付きリストが与えられます。各ラベルは、仮想的に連結された信号のコンポーネントが占める最初のタイムスロットを示します。ラベルの順序は、連結するペイロードの順序を反映する必要があります (タイムスロットの物理的な順序ではありません)。上記の表現では、仮想連結が単一 (コンポーネント) リンク内に留まるように制限されています。これは、ANSI [T1.105]/ITU-T [G.707] 勧告と比較して、そのような制限を課します。
The standard definition for virtual concatenation allows each virtual concatenation components to travel over diverse paths. Within GMPLS, virtual concatenation components must travel over the same (component) link if they are part of the same LSP. This is due to the way that labels are bound to a (component) link. Note however, that the routing of components on different paths is indeed equivalent to establishing different LSPs, each one having its own route. Several LSPs can be initiated and terminated between the same nodes and their corresponding components can then be associated together (i.e., virtually concatenated).
仮想連結の標準定義では、各仮想連結コンポーネントがさまざまなパスを通過できるようになります。GMPLS 内では、仮想連結コンポーネントが同じ LSP の一部である場合、それらは同じ (コンポーネント) リンク上を移動する必要があります。これは、ラベルが (コンポーネント) リンクにバインドされる方法に起因します。ただし、異なるパス上のコンポーネントのルーティングは、実際には、それぞれが独自のルートを持つ異なる LSP を確立することと同等であることに注意してください。複数の LSP を同じノード間で開始および終了することができ、それらの対応するコンポーネントを互いに関連付けることができます (つまり、仮想的に連結できます)。
In case of multiplication (i.e., using the multiplier transform), the explicit ordered list of all labels that take part in the Final Signal is given. In case of multiplication of virtually concatenated signals, the first set of labels indicates the time-slots occupied by the first virtually concatenated signal, the second set of labels indicates the time-slots occupied by the second virtually concatenated signal, and so on. The above representation limits multiplication to remain within a single (component) link.
乗算の場合 (つまり、乗数変換を使用する場合)、最終信号に含まれるすべてのラベルの明示的な順序付きリストが与えられます。仮想連結信号を乗算する場合、最初のラベルのセットは最初の仮想連結信号が占めるタイムスロットを示し、2 番目のラベルのセットは 2 番目の仮想連結信号が占めるタイムスロットを示し、以下同様になります。上記の表現では、乗算が 1 つの (コンポーネント) リンク内にとどまるように制限されます。
The format of the label for SONET and/or SDH TDM-LSR link is:
SONET および/または SDH TDM-LSR リンクのラベルの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S | U | K | L | M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is an extension of the numbering scheme defined in [G.707]
sections 7.3.7 to 7.3.13, i.e., the (K, L, M) numbering. Note that
the higher order numbering scheme defined in [G.707] sections 7.3.1
to 7.3.6 is not used here.
Each letter indicates a possible branch number starting at the parent node in the multiplex structure. Branches are considered as numbered in increasing order, starting from the top of the multiplexing structure. The numbering starts at 1, zero is used to indicate a non-significant or ignored field.
各文字は、多重構造内の親ノードから始まる可能な分岐番号を示します。ブランチには、多重化構造の最上位から昇順に番号が付けられていると見なされます。番号付けは 1 から始まり、0 は重要でないフィールドまたは無視されるフィールドを示すために使用されます。
When a field is not significant or ignored in a particular context it MUST be set to zero when transmitted, and MUST be ignored when received.
フィールドが重要ではない場合、または特定のコンテキストで無視される場合、送信時にはゼロに設定しなければならず、受信時には無視しなければなりません。
When a hierarchy of SONET/SDH LSPs is used, a higher order LSP with a given bandwidth can be used to carry lower order LSPs. Remember here that a higher order LSP is established through a SONET/SDH higher order path layer network and a lower order LSP, through a SONET/SDH lower order path layer network (see also ITU-T G.803, Section 3 for the corresponding definitions). In this context, the higher order SONET/SDH LSP behaves as a "virtual link" with a given bandwidth (e.g., VC-3), it may also be used as a Forwarding Adjacency. A lower order SONET/SDH LSP can be established through that higher order LSP. Since a label is local to a (virtual) link, the highest part of that label (i.e., the S, U and K fields) is non-significant and is set to zero, i.e., the label is "0,0,0,L,M". Similarly, if the structure of the lower order LSP is unknown or not relevant, the lowest part of that label (i.e., the L and M fields) is non-significant and is set to zero, i.e., the label is "S,U,K,0,0".
SONET/SDH LSP の階層が使用される場合、特定の帯域幅を持つ上位の LSP を使用して、下位の LSP を伝送できます。ここで、上位 LSP は SONET/SDH 上位パス層ネットワークを通じて確立され、下位 LSP は SONET/SDH 下位パス層ネットワークを通じて確立されることに注意してください (対応するものについては、ITU-T G.803、セクション 3 も参照)定義）。このコンテキストでは、上位の SONET/SDH LSP は、特定の帯域幅 (VC-3 など) を持つ「仮想リンク」として動作し、転送隣接として使用することもできます。下位の SONET/SDH LSP は、その上位の LSP を通じて確立できます。ラベルは (仮想) リンクに対してローカルであるため、そのラベルの最上位部分 (つまり、S、U、および K フィールド) は重要ではなく、ゼロに設定されます。つまり、ラベルは「0,0,0」です。、L、M」。同様に、下位 LSP の構造が不明であるか関連性がない場合、そのラベルの最下位部分 (L および M フィールド) は重要ではなく、ゼロに設定されます。つまり、ラベルは "S,U" になります。,K,0,0"。
For instance, a VC-3 LSP can be used to carry lower order LSPs. In that case the labels allocated between the two ends of the VC-3 LSP for the lower order LSPs will have S, U and K set to zero, i.e., non-significant, while L and M will be used to indicate the signal allocated in that VC-3.
たとえば、VC-3 LSP を使用して、下位 LSP を伝送できます。その場合、下位 LSP の VC-3 LSP の両端間に割り当てられたラベルの S、U、K はゼロ、つまり非有意に設定され、L と M は割り当てられた信号を示すために使用されます。そのVC-3で。
In case of tunneling such as VC-4 containing VC-3 containing VC-12/VC-11 where the SUKLM structure is not adequate to represent the full signal structure, a hierarchical approach must be used, i.e., per layer network signaling.
SUKLM 構造が完全な信号構造を表すのに適切ではない、VC-12/VC-11 を含む VC-3 を含む VC-4 などのトンネリングの場合、階層的アプローチ、つまりレイヤ ネットワーク シグナリングごとを使用する必要があります。
The possible values of S, U, K, L and M are defined as follows:
S、U、K、L、および M の可能な値は次のように定義されます。
1. S=1->N is the index of a particular STS-3/AUG-1 inside an STS-N/STM-N multiplex. S is only significant for SONET STS-N (N>1) and SDH STM-N (N>0). S must be 0 and ignored for STS-1 and STM-0.
1. S=1->N は、STS-N/STM-N マルチプレックス内の特定の STS-3/AUG-1 のインデックスです。S は、SONET STS-N (N>1) および SDH STM-N (N>0) に対してのみ重要です。STS-1 および STM-0 では S は 0 でなければならず、無視されます。
2. U=1->3 is the index of a particular STS-1_SPE/VC-3 within an STS-3/AUG-1. U is only significant for SONET STS-N (N>1) and SDH STM-N (N>0). U must be 0 and ignored for STS-1 and STM-0.
2. U=1->3 は、STS-3/AUG-1 内の特定の STS-1_SPE/VC-3 のインデックスです。U は、SONET STS-N (N>1) および SDH STM-N (N>0) に対してのみ重要です。U は 0 でなければならず、STS-1 および STM-0 では無視されます。
3. K=1->3 is the index of a particular TUG-3 within a VC-4. K is only significant for an SDH VC-4 structured in TUG-3s. K must be 0 and ignored in all other cases.
3. K=1->3 は、VC-4 内の特定の TUG-3 のインデックスです。K は、TUG-3 で構造化された SDH VC-4 に対してのみ重要です。K は 0 でなければならず、それ以外の場合はすべて無視されます。
4. L=1->7 is the index of a particular VT_Group/TUG-2 within an STS-1_SPE/TUG-3 or VC-3. L must be 0 and ignored in all other cases.
4. L=1->7 は、STS-1_SPE/TUG-3 または VC-3 内の特定の VT_Group/TUG-2 のインデックスです。L は 0 でなければならず、それ以外の場合はすべて無視されます。
5. M is the index of a particular VT1.5_SPE/VC-11, VT2_SPE/VC-12 or VT3_SPE within a VT_Group/TUG-2. M=1->2 indicates a specific VT3 SPE inside the corresponding VT Group, these values MUST NOT be used for SDH since there is no equivalent of VT3 with SDH. M=3->5 indicates a specific VT2_SPE/VC-12 inside the corresponding VT_Group/TUG-2. M=6->9 indicates a specific VT1.5_SPE/VC-11 inside the corresponding VT_Group/TUG-2.
5. M は、VT_Group/TUG-2 内の特定の VT1.5_SPE/VC-11、VT2_SPE/VC-12、または VT3_SPE のインデックスです。M=1->2 は、対応する VT グループ内の特定の VT3 SPE を示します。SDH には VT3 に相当するものが存在しないため、これらの値を SDH に使用してはなりません (MUST NOT)。M=3->5 は、対応する VT_Group/TUG-2 内の特定の VT2_SPE/VC-12 を示します。M=6->9 は、対応する VT_Group/TUG-2 内の特定の VT1.5_SPE/VC-11 を示します。
Note that a label always has to be interpreted according the SONET/SDH traffic parameters, i.e., a label by itself does not allow knowing which signal is being requested (a label is context sensitive).
ラベルは常に SONET/SDH トラフィック パラメータに従って解釈される必要があることに注意してください。つまり、ラベルだけではどの信号が要求されているかを知ることはできません (ラベルはコンテキストに依存します)。
The label format defined in this section, referred to as SUKLM, MUST be used for any SONET/SDH signal requests that are not transparent i.e., when all Transparency (T) bits defined in section 2.1 are set to zero. Any transparent STS-1/STM-0/STS-3*N/STM-N (N=1, 4, 16, 64, 256) signal request MUST use a label format as defined in [RFC3471].
SUKLM と呼ばれる、このセクションで定義されたラベル形式は、透過的でない SONET/SDH 信号リクエスト、つまりセクション 2.1 で定義されたすべての透過性 (T) ビットが 0 に設定されている場合に使用しなければなりません (MUST)。透過的な STS-1/STM-0/STS-3*N/STM-N (N=1、4、16、64、256) 信号リクエストは、[RFC3471] で定義されているラベル形式を使用しなければなりません (MUST)。
The S encoding is summarized in the following table:
S エンコーディングを次の表にまとめます。
S SDH SONET
------------------------------------------------
0 other other
1 1st AUG-1 1st STS-3
2 2nd AUG-1 2nd STS-3
3 3rd AUG-1 3rd STS-3
4 4rd AUG-1 4rd STS-3
: : :
N Nth AUG-1 Nth STS-3
The U encoding is summarized in the following table:
U エンコーディングを次の表にまとめます。
U SDH AUG-1 SONET STS-3
-------------------------------------------------
0 other other
1 1st VC-3 1st STS-1 SPE
2 2nd VC-3 2nd STS-1 SPE
3 3rd VC-3 3rd STS-1 SPE
The K encoding is summarized in the following table:
K エンコーディングを次の表にまとめます。
K SDH VC-4
---------------
0 other
1 1st TUG-3
2 2nd TUG-3
3 3rd TUG-3
The L encoding is summarized in the following table:
L エンコーディングを次の表にまとめます。
L SDH TUG-3 SDH VC-3 SONET STS-1 SPE
-------------------------------------------------
0 other other other
1 1st TUG-2 1st TUG-2 1st VTG
2 2nd TUG-2 2nd TUG-2 2nd VTG
3 3rd TUG-2 3rd TUG-2 3rd VTG
4 4th TUG-2 4th TUG-2 4th VTG
5 5th TUG-2 5th TUG-2 5th VTG
6 6th TUG-2 6th TUG-2 6th VTG
7 7th TUG-2 7th TUG-2 7th VTG
The M encoding is summarized in the following table:
M エンコーディングを次の表にまとめます。
M SDH TUG-2 SONET VTG
-------------------------------------------------
0 other other
1 - 1st VT3 SPE
2 - 2nd VT3 SPE
3 1st VC-12 1st VT2 SPE
4 2nd VC-12 2nd VT2 SPE
5 3rd VC-12 3rd VT2 SPE
6 1st VC-11 1st VT1.5 SPE
7 2nd VC-11 2nd VT1.5 SPE
8 3rd VC-11 3rd VT1.5 SPE
9 4th VC-11 4th VT1.5 SPE
Examples of labels:
ラベルの例:
Example 1: the label for the STS-3c_SPE/VC-4 in the Sth STS-3/AUG-1 is: S>0, U=0, K=0, L=0, M=0.
例 1: Sth STS-3/AUG-1 内の STS-3c_SPE/VC-4 のラベルは、S>0、U=0、K=0、L=0、M=0 です。
Example 2: the label for the VC-3 within the Kth-1 TUG-3 within the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0.
例 2: S 番目の AUG-1 の VC-4 内の K 番目の TUG-3 内の VC-3 のラベルは次のとおりです: S>0、U=0、K>0、L=0、M=0。
Example 3: the label for the Uth-1 STS-1_SPE/VC-3 within the Sth STS-3/AUG-1 is: S>0, U>0, K=0, L=0, M=0.
例 3: Sth STS-3/AUG-1 内の Uth-1 STS-1_SPE/VC-3 のラベルは、S>0、U>0、K=0、L=0、M=0 です。
Example 4: the label for the VT6/VC-2 in the Lth-1 VT Group/TUG-2 in the Uth-1 STS-1_SPE/VC-3 within the Sth STS-3/AUG-1 is: S>0, U>0, K=0, L>0, M=0.
例 4: Sth STS-3/AUG-1 内の Uth-1 STS-1_SPE/VC-3 の Lth-1 VT グループ/TUG-2 の VT6/VC-2 のラベルは次のとおりです。 S>0、Ｕ＞０、Ｋ＝０、Ｌ＞０、Ｍ＝０。
Example 5: the label for the 3rd VT1.5_SPE/VC-11 in the Lth-1 VT Group/TUG-2 within the Uth-1 STS-1_SPE/VC-3 within the Sth STS-3/AUG-1 is: S>0, U>0, K=0, L>0, M=8.
例 5: Sth STS-3/AUG-1 内の Uth-1 STS-1_SPE/VC-3 内の Lth-1 VT グループ/TUG-2 の 3 番目の VT1.5_SPE/VC-11 のラベルは次のとおりです。S>0、U>0、K=0、L>0、M=8。
Example 6: the label for the STS-12c/VC-4-4c which uses the 9th STS-3/AUG-1 as its first timeslot is: S=9, U=0, K=0, L=0, M=0.
例 6: 9 番目の STS-3/AUG-1 を最初のタイムスロットとして使用する STS-12c/VC-4-4c のラベルは次のとおりです: S=9、U=0、K=0、L=0、M=0。
In case of contiguous concatenation, the label that is used is the lowest label (value) of the contiguously concatenated signal as explained before. The higher part of the label indicates where the signal starts and the lowest part is not significant.
連続連結の場合、使用されるラベルは、前述したように、連続連結された信号の最も低いラベル（値）です。ラベルの上部は信号の開始位置を示し、下部は重要ではありません。
In case of STM-0/STS-1, the values of S, U and K must be equal to zero according to the field coding rules. For instance, when requesting a VC-3 in an STM-0 the label is S=0, U=0, K=0, L=0, M=0. When requesting a VC-11 in a VC-3 in an STM-0 the label is S=0, U=0, K=0, L>0, M=6..9.
STM-0/STS-1 の場合、フィールドコーディング規則に従って、S、U、および K の値はゼロに等しくなければなりません。たとえば、STM-0 で VC-3 を要求する場合、ラベルは S=0、U=0、K=0、L=0、M=0 になります。STM-0 の VC-3 で VC-11 を要求する場合、ラベルは S=0、U=0、K=0、L>0、M=6..9 です。
Note: when a Section/RS or Line/MS transparent STS-1/STM-0/STS-3*N/STM-N (N=1, 4, 16, 64, 256) signal is requested, the SUKLM label format and encoding is not applicable and the label encoding MUST follow the rules defined in [RFC3471] Section 3.2.
注: セクション/RS またはライン/MS トランスペアレント STS-1/STM-0/STS-3*N/STM-N (N=1、4、16、64、256) 信号が要求される場合、SUKLM ラベル フォーマットエンコーディングは適用されず、ラベルのエンコーディングは [RFC3471] セクション 3.2 で定義された規則に従わなければなりません (MUST)。
Valuable comments and input were received from the CCAMP mailing list where outstanding discussions took place.
優れた議論が行われた CCAMP メーリング リストから、貴重なコメントや意見が寄せられました。
This document introduces no new security considerations to either [RFC3473] or [RFC3472]. GMPLS security is described in section 11 of [RFC3471] and refers to [RFC3209] for RSVP-TE and to [RFC3212] for CR-LDP.
この文書は、[RFC3473] または [RFC3472] に対して新しいセキュリティに関する考慮事項を導入しません。GMPLS セキュリティは [RFC3471] のセクション 11 で説明されており、RSVP-TE については [RFC3209]、CR-LDP については [RFC3212] を参照しています。
Three values have been defined by IANA for this document:
この文書に対して IANA によって 3 つの値が定義されています。
Two RSVP C-Types in registry: http://www.iana.org/assignments/rsvp-parameters
レジストリ内の 2 つの RSVP C-Type: http://www.iana.org/assignments/rsvp-parameters
- A SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 (see section 2.2).
- SONET/SDH SENDER_TSPEC オブジェクト: クラス = 12、C-Type = 4 (セクション 2.2 を参照)。
- A SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (see section 2.2).
- SONET/SDH FLOWSPEC オブジェクト: クラス = 9、C-Type = 4 (セクション 2.2 を参照)。
One LDP TLV Type in registry: http://www.iana.org/assignments/ldp-namespaces
レジストリ内の 1 つのLDP TLV タイプ: http://www.iana.org/assignments/ldp-namespaces
- A type field for the SONET/SDH Traffic Parameters TLV (see section 2.3).
- SONET/SDH トラフィック パラメータ TLV のタイプ フィールド (セクション 2.3 を参照)。
[G.707] ITU-T Recommendation G.707, "Network Node Interface for the Synchronous Digital Hierarchy", October 2000.
[G.707] ITU-T 勧告 G.707、「同期デジタル階層のためのネットワーク ノード インターフェイス」、2000 年 10 月。
[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 月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden, R.、Zhang, L.、Berson, S.、Herzog, S.、および S. Jamin、「リソース予約プロトコル (RSVP) -- バージョン 1 機能仕様」、RFC 2205、1997 年 9 月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski, J.、「IETF 統合サービスでの RSVP の使用」、RFC 2210、1997 年 9 月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche, D.、Berger, L.、Gan, D.、Li, T.、Srinivasan, V.、および G. Swallow、「RSVP-TE: LSP トンネルのための RSVP の拡張」、RFC 3209、12 月2001年。
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3212] Jamoussi、B.、Andersson、L.、Callon、R.、Dantu、R.、Wu、L.、Doolan、P.、Worster、T.、Feldman、N.、Fredette、A.、Girish、M.、Gray、E.、Heinanen、J.、Kilty、T.、および A. Malis、「LDP を使用した制約ベースの LSP セットアップ」、RFC 3212、2002 年 1 月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (MPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger, L.、「Generalized Multi-Protocol Label Switching (MPLS) Signaling Functional description」、RFC 3471、2003 年 1 月。
[RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi-Protocol Label Switching (MPLS) Signaling - Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3472] Ashwood-Smith、P.、および L. Berger、「汎用マルチプロトコル ラベル スイッチング (MPLS) シグナリング - 制約ベースのルーテッド ラベル配布プロトコル (CR-LDP) 拡張」、RFC 3472、2003 年 1 月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (MPLS) Signaling - Resource ReserVation Protocol Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger, L.、「Generalized Multi-Protocol Label Switching (MPLS) Signaling - Resource Reservation Protocol Traffic Engineering (RSVP-TE) Extensions」、RFC 3473、2003 年 1 月。
[RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie, E. 編、「Generalized Multiprotocol Label Switching (GMPLS) Architecture」、RFC 3945、2004 年 10 月。
[T1.105] "Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, and Formats", ANSI T1.105, October 2000.
[T1.105] 「同期光ネットワーク (SONET): 多重構造、レート、およびフォーマットを含む基本的な説明」、ANSI T1.105、2000 年 10 月。
Appendix 1 - Signal Type Values Extension for VC-3
付録 1 - VC-3 の信号タイプ値の拡張
This appendix defines the following optional additional Signal Type value for the Signal Type field of section 2.1:
この付録では、セクション 2.1 の [信号タイプ] フィールドに対して、次のオプションの追加の信号タイプ値を定義します。
Value Type
----- ---------------------
20 "VC-3 via AU-3 at the end"
According to the ITU-T [G.707] recommendation a VC-3 in the TU-3/TUG-3/VC-4/AU-4 branch of the SDH multiplex cannot be structured in TUG-2s, however a VC-3 in the AU-3 branch can be. In addition, a VC-3 could be switched between the two branches if required.
ITU-T [G.707] 勧告によると、SDH マルチプレックスの TU-3/TUG-3/VC-4/AU-4 ブランチの VC-3 は TUG-2 で構成できませんが、VC-33 AU-3 分岐が可能です。さらに、必要に応じて VC-3 を 2 つのブランチ間で切り替えることができます。
A VC-3 circuit could be terminated on an ingress interface of an LSR (e.g., forming a VC-3 forwarding adjacency). This LSR could then want to demultiplex this VC-3 and switch internal low order LSPs. For implementation reasons, this could be only possible if the LSR receives the VC-3 in the AU-3 branch. E.g., for an LSR not able to switch internally from a TU-3 branch to an AU-3 branch on its incoming interface before demultiplexing and then switching the content with its switch fabric.
VC-3 回線は、LSR の入力インターフェイスで終端される可能性があります（たとえば、VC-3 転送隣接関係の形成）。この LSR は、この VC-3 を逆多重化し、内部の下位 LSP を切り替えることができます。実装上の理由により、これは LSR が AU-3 ブランチで VC-3 を受信する場合にのみ可能になります。たとえば、LSR の場合、逆多重化してスイッチ ファブリックでコンテンツを切り替える前に、着信インターフェイスで TU-3 ブランチから AU-3 ブランチに内部的に切り替えることができません。
In that case it is useful to indicate that the VC-3 LSP must be terminated at the end in the AU-3 branch instead of the TU-3 branch.
その場合、VC-3 LSP を TU-3 ブランチではなく AU-3 ブランチの終端で終端する必要があることを示すと便利です。
This is achieved by using the "VC-3 via AU-3 at the end" signal type. This information can be used, for instance, by the penultimate LSR to switch an incoming VC-3 received in any branch to the AU-3 branch on the outgoing interface to the destination LSR.
これは、「最後に AU-3 を経由する VC-3」信号タイプを使用することで実現されます。この情報は、たとえば、最後から 2 番目の LSR が、任意のブランチで受信した着信 VC-3 を、宛先 LSR への発信インターフェイス上の AU-3 ブランチに切り替えるために使用できます。
The "VC-3 via AU-3 at the end" signal type does not imply that the VC-3 must be switched via the AU-3 branch at some other places in the network. The VC-3 signal type just indicates that a VC-3 in any branch is suitable.
「最後に AU-3 経由の VC-3」信号タイプは、ネットワーク内の他の場所で AU-3 ブランチを介して VC-3 を切り替える必要があることを意味するものではありません。VC-3 信号タイプは、どのブランチでも VC-3 が適切であることを示しているだけです。
Annex 1 - Examples
付録 1 - 例
This annex defines examples of SONET and SDH signal coding. Their objective is to help the reader to understand how works the traffic parameter coding and not to give examples of typical SONET or SDH signals.
この付録では、SONET および SDH 信号コーディングの例を定義します。その目的は、トラフィック パラメータのコーディングがどのように機能するかを読者が理解できるようにすることであり、典型的な SONET または SDH 信号の例を示すことではありません。
As stated above, signal types are Elementary Signals to which successive concatenation, multiplication and transparency transforms can be applied to obtain Final Signals.
上で述べたように、信号タイプは基本信号であり、これに連続的な連結、乗算、透明度変換を適用して最終信号を取得できます。
1. A VC-4 signal is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1 and T with value 0 to a VC-4 Elementary Signal.
1. VC-4 信号は、値 0 の RCC、値 0 の NCC、値 0 の NVC、値 1 の MT、および値 0 の T を VC-4 基本信号に適用することによって形成されます。
2. A VC-4-7v signal is formed by the application of RCC with value 0, NCC with value 0, NVC with value 7 (virtual concatenation of 7 components), MT with value 1 and T with value 0 to a VC-4 Elementary Signal.
2. VC-4-7v 信号は、値 0 の RCC、値 0 の NCC、値 7 の NVC (7 つのコンポーネントの仮想連結)、値 1 の MT、および値 0 の T を VC-4 エレメンタリーに適用することによって形成されます。信号。
3. A VC-4-16c signal is formed by the application of RCC with flag 1 (standard contiguous concatenation), NCC with value 16, NVC with value 0, MT with value 1 and T with value 0 to a VC-4 Elementary Signal.
3. VC-4-16c 信号は、フラグ 1 の RCC (標準の連続連結)、値 16 の NCC、値 0 の NVC、値 1 の MT、および値 0 の T を VC-4 基本信号に適用することによって形成されます。
4. An STM-16 signal with Multiplex Section layer transparency is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1 and T with flag 2 to an STM-16 Elementary Signal.
4. 多重セクション層透過性を持つ STM-16 信号は、値 0 の RCC、値 0 の NCC、値 0 の NVC、値 1 の MT、およびフラグ 2 の T を STM-16 基本信号に適用することによって形成されます。
5. An STM-4 signal with Multiplex Section layer transparency is formed by the application of RCC with flag 0, NCC with value 0, NVC with value 0, MT with value 1 and T with flag 2 applied to an STM-4 Elementary Signal.
5. 多重セクション層透過性を備えた STM-4 信号は、フラグ 0 の RCC、値 0 の NCC、値 0 の NVC、値 1 の MT、およびフラグ 2 の T を STM-4 基本信号に適用することによって形成されます。
6. An STM-256 signal with Multiplex Section layer transparency is formed by the application of RCC with flag 0, NCC with value 0, NVC with value 0, MT with value 1 and T with flag 2 applied to an STM-256 Elementary Signal.
6. 多重セクション層透過性を備えた STM-256 信号は、フラグ 0 の RCC、値 0 の NCC、値 0 の NVC、値 1 の MT、およびフラグ 2 の T を STM-256 基本信号に適用することによって形成されます。
7. An STS-1 SPE signal is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1 and T with value 0 to an STS-1 SPE Elementary Signal.
7. STS-1 SPE 信号は、値 0 の RCC、値 0 の NCC、値 0 の NVC、値 1 の MT、および値 0 の T を STS-1 SPE 基本信号に適用することによって形成されます。
8. An STS-3c SPE signal is formed by the application of RCC with value 1 (standard contiguous concatenation), NCC with value 1, NVC with value 0, MT with value 1 and T with value 0 to an STS-3c SPE Elementary Signal.
8. STS-3c SPE 信号は、値 1 の RCC (標準の連続連結)、値 1 の NCC、値 0 の NVC、値 1 の MT、および値 0 の T を STS-3c SPE 基本信号に適用することによって形成されます。
9. An STS-48c SPE signal is formed by the application of RCC with flag 1 (standard contiguous concatenation), NCC with value 16, NVC with value 0, MT with value 1 and T with value 0 to an STS-3c SPE Elementary Signal.
9. STS-48c SPE 信号は、フラグ 1 の RCC (標準の連続連結)、値 16 の NCC、値 0 の NVC、値 1 の MT、および値 0 の T を STS-3c SPE 基本信号に適用することによって形成されます。
10. An STS-1-3v SPE signal is formed by the application of RCC with value 0, NVC with value 3 (virtual concatenation of 3 components), MT with value 1 and T with value 0 to an STS-1 SPE Elementary Signal.
10. STS-1-3v SPE 信号は、値 0 の RCC、値 3 の NVC (3 コンポーネントの仮想連結)、値 1 の MT、および値 0 の T を STS-1 SPE 基本信号に適用することによって形成されます。
11. An STS-3c-9v SPE signal is formed by the application of RCC with value 1, NCC with value 1, NVC with value 9 (virtual concatenation of 9 STS-3c), MT with value 1 and T with value 0 to an STS-3c SPE Elementary Signal.
11. STS-3c-9v SPE 信号は、値 1 の RCC、値 1 の NCC、値 9 の NVC (9 台の STS-3c の仮想連結)、値 1 の MT、および値 0 の T を STS に適用することによって形成されます。-3c SPE 基本信号。
12. An STS-12 signal with Section layer (full) transparency is formed by the application of RCC with value 0, NVC with value 0, MT with value 1 and T with flag 1 to an STS-12 Elementary Signal.
12. セクション層 (完全) 透過性を持つ STS-12 信号は、値 0 の RCC、値 0 の NVC、値 1 の MT、およびフラグ 1 の T を STS-12 基本信号に適用することによって形成されます。
13. 3 x STS-768c SPE signal is formed by the application of RCC with flag 1, NCC with value 256, NVC with value 0, MT with value 3, and T with value 0 to an STS-3c SPE Elementary Signal.
13. 3 x STS-768c SPE 信号は、フラグ 1 の RCC、値 256 の NCC、値 0 の NVC、値 3 の MT、および値 0 の T を STS-3c SPE 基本信号に適用することによって形成されます。
14. 5 x VC-4-13v composed signal is formed by the application of RCC with value 0, NVC with value 13, MT with value 5 and T with value 0 to a VC-4 Elementary Signal.
14. 5 x VC-4-13v 合成信号は、値 0 の RCC、値 13 の NVC、値 5 の MT、および値 0 の T を VC-4 基本信号に適用することによって形成されます。
The encoding of these examples is summarized in the following table:
これらの例のエンコーディングを次の表にまとめます。
Signal ST RCC NCC NVC MT T
--------------------------------------------------------
VC-4 6 0 0 0 1 0
VC-4-7v 6 0 0 7 1 0
VC-4-16c 6 1 16 0 1 0
STM-16 MS transparent 10 0 0 0 1 2
STM-4 MS transparent 9 0 0 0 1 2
STM-256 MS transparent 12 0 0 0 1 2
STS-1 SPE 5 0 0 0 1 0
STS-3c SPE 6 1 1 0 1 0
STS-48c SPE 6 1 16 0 1 0
STS-1-3v SPE 5 0 0 3 1 0
STS-3c-9v SPE 6 1 1 9 1 0
STS-12 Section transparent 9 0 0 0 1 1
3 x STS-768c SPE 6 1 256 0 3 0
5 x VC-4-13v 6 0 0 13 5 0
Contributors
貢献者
Contributors are listed by alphabetical order:
貢献者はアルファベット順にリストされています。
Stefan Ansorge (Alcatel) Lorenzstrasse 10 70435 Stuttgart, Germany
Stefan Ansorge (Alcatel) Lorenzstrasse 10 70435 シュトゥットガルト、ドイツ
EMail: stefan.ansorge@alcatel.de
Peter Ashwood-Smith (Nortel) PO. Box 3511 Station C, Ottawa, ON K1Y 4H7, Canada
ピーター・アシュウッド・スミス (ノーテル) PO。Box 3511 Station C、オタワ、ON K1Y 4H7、カナダ
EMail:petera@nortelnetworks.com
メール:petera@nortelnetworks.com
Ayan Banerjee (Calient) 5853 Rue Ferrari San Jose, CA 95138, USA
アヤン・バナジー（カリエント）5853 Rue Ferrari San Jose、CA 95138、USA
EMail: abanerjee@calient.net
Lou Berger (Movaz) 7926 Jones Branch Drive McLean, VA 22102, USA
Lou Berger (Movaz) 7926 Jones Branch Drive McLean, VA 22102, USA
EMail: lberger@movaz.com
Greg Bernstein (Ciena) 10480 Ridgeview Court Cupertino, CA 94014, USA
グレッグ・バーンスタイン (シエナ) 10480 Ridgeview Court Cupertino, CA 94014, USA
EMail: greg@ciena.com
Angela Chiu (Celion) One Sheila Drive, Suite 2 Tinton Falls, NJ 07724-2658
Angela Chiu (Celion) One Sheila Drive, Suite 2 Tinton Falls, NJ 07724-2658
EMail: angela.chiu@celion.com
John Drake (Calient)
5853 Rue Ferrari
San Jose, CA 95138, USA
EMail: jdrake@calient.net
Yanhe Fan (Axiowave) 100 Nickerson Road Marlborough, MA 01752, USA
Yanhe Fan (Axiowave) 100 Nickerson Road Marlborough, MA 01752, USA
EMail: yfan@axiowave.com
Michele Fontana (Alcatel) Via Trento 30, I-20059 Vimercate, Italy
ミケーレ フォンタナ (アルカテル) Via Trento 30, I-20059 Vimercate, Italy
EMail: michele.fontana@alcatel.it
Gert Grammel (Alcatel) Lorenzstrasse, 10 70435 Stuttgart, Germany
Gert Grammel (Alcatel) Lorenzstrasse, 10 70435 シュトゥットガルト, ドイツ
EMail: gert.grammel@alcatel.de
Juergen Heiles (Siemens) Hofmannstr. 51 D-81379 Munich, Germany
ユルゲン・ハイルス (シーメンス) Hofmannstr.51 D-81379 ミュンヘン、ドイツ
EMail: juergen.heiles@siemens.com
Suresh Katukam (Cisco) 1450 N. McDowell Blvd, Petaluma, CA 94954-6515, USA
Suresh Katukam (Cisco) 1450 N. McDowell Blvd、ペタルマ、CA 94954-6515、米国
EMail: suresh.katukam@cisco.com
Kireeti Kompella (Juniper) 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
Kireeti Kompella (ジュニパー) 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
EMail: kireeti@juniper.net
Jonathan P. Lang (Calient)
25 Castilian
Goleta, CA 93117, USA
EMail: jplang@calient.net
Fong Liaw (Solas Research)
フォン・リャウ (Solas Research)
EMail: fongliaw@yahoo.com
Zhi-Wei Lin (Lucent) 101 Crawfords Corner Rd Holmdel, NJ 07733-3030, USA
Zhi-Wei Lin (Lucent) 101 Crawfords Corner Rd Holmdel, NJ 07733-3030, USA
EMail: zwlin@lucent.com
Ben Mack-Crane (Tellabs)
ベン・マッククレーン (Tellabs)
EMail: ben.mack-crane@tellabs.com
Dimitrios Pendarakis (Tellium) 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
ディミトリオス・ペンダラキス (テリウム) 2 Crescent Place, P.O.Box 901 オーシャンポート、ニュージャージー州 07757-0901、米国
EMail: dpendarakis@tellium.com
Mike Raftelis (White Rock) 18111 Preston Road Dallas, TX 75252, USA
マイク・ラフテリス (ホワイト・ロック) 18111 Preston Road Dallas, TX 75252, USA
Bala Rajagopalan (Tellium) 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
Bala Rajagopalan (Tellium) 2 Crescent Place, P.O.Box 901 オーシャンポート、ニュージャージー州 07757-0901、米国
EMail: braja@tellium.com
Yakov Rekhter (Juniper)
1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA
EMail: yakov@juniper.net
Debanjan Saha (Tellium) 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
デバンジャン サハ (テリウム) 2 Crescent Place, P.O.Box 901 オーシャンポート、ニュージャージー州 07757-0901、米国
EMail: dsaha@tellium.com
Vishal Sharma (Metanoia) 335 Elan Village Lane San Jose, CA 95134, USA
ヴィシャール シャルマ (メタノイア) 335 Elan Village Lane San Jose, CA 95134, USA
EMail: vsharma87@yahoo.com
George Swallow (Cisco) 250 Apollo Drive Chelmsford, MA 01824, USA
George Swallow (Cisco) 250 Apollo Drive Chelmsford, MA 01824, USA
EMail: swallow@cisco.com
Z. Bo Tang (Tellium) 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
Z. Bo Tang (Tellium) 2 Crescent Place、P.O.Box 901 オーシャンポート、ニュージャージー州 07757-0901、米国
EMail: btang@tellium.com
Eve Varma (Lucent) 101 Crawfords Corner Rd Holmdel, NJ 07733-3030, USA
Eve Varma (Lucent) 101 Crawfords Corner Rd Holmdel、NJ 07733-3030、USA
EMail: evarma@lucent.com
Yangguang Xu (Lucent) 21-2A41, 1600 Osgood Street North Andover, MA 01845, USA
Yangguang Xu (Lucent) 21-2A41、1600 Osgood Street North Andover、MA 01845、USA
EMail: xuyg@lucent.com
Authors' Addresses
著者の住所
Eric Mannie (Consultant) Avenue de la Folle Chanson, 2 B-1050 Brussels, Belgium Phone: +32 2 648-5023 Mobile: +32 (0)495-221775
Eric Mannie (コンサルタント) Avenue de la Folle Chanson, 2 B-1050 Brussels, Belgium 電話: 32 2 648-5023 携帯電話: 32 (0)495-221775
EMail: eric_mannie@hotmail.com
Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491
Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1, B-2018 Antwerpen, Belgium 電話: 32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、かかる権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、BCP 78 および BCP 79 に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/ipr) から入手してください。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、利害関係者に対し、この規格の実装に必要とされる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について注意を喚起するよう呼びかけています。情報は IETF (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。