RFC3946 日本語訳
3946 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy(SDH) Control. E. Mannie, D. Papadimitriou. October 2004. (Format: TXT=52205 bytes) (Obsoleted by RFC4606) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Mannie
Request for Comments: 3946 Consultant
Category: Standards Track D. Papadimitriou
Alcatel
October 2004
コメントを求めるワーキンググループE.マニーの要求をネットワークでつないでください: 3946年のコンサルタントカテゴリ: 標準化過程D.Papadimitriouアルカテル2004年10月
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
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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-プロトコル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
1. 序論… 2 2. SonetとSDH交通パラメタ… 2 2.1. Sonet/SDH交通パラメタ… 3 2.2. RSVP-Teの詳細… 9 2.3. CR-自由民主党の詳細… 9 3. SonetとSDHラベル… 10 4. 承認… 15 5. セキュリティ問題… 16 6. IANA問題… 16 7. 参照… 16 7.1. 標準の参照… 16 付録1--信号タイプはVC-3のために拡大を評価します… 18 1--例を付加してください… 18人の貢献者… 21人の作者のアドレス… 25 完全な著作権宣言文… 26
Mannie & Papadimitriou Standards Track [Page 1] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[1ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
1. Introduction
1. 序論
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]で説明されるように、Generalized MPLS(GMPLS)はパケット(パケットSwitching Capable--PSC)インタフェースを支持して、4つの新しいクラスのインタフェースのサポートを含むように切り替わって、切り替わるのからMPLSを広げています: 層-2はできる(L2SC)、時分割多重(TDM)、λスイッチのできる(LSC)、およびファイバースイッチのできる(FSC)を切り換えます。 MPLSシグナリングへの拡大の機能的な記述は、新しいクラスのインタフェースを支持する必要がありました、そして、[RFC3471]に切り換えを提供します。 [RFC3473]はRSVP-TEの特定の形式について説明します、そして、メカニズムは、すべての5つのクラスのインタフェースを支持する必要がありました、そして、[RFC3472]でCR自由民主党拡張子は見つけることができます。 このドキュメントは同期式光通信網(Sonet)/同期デジタルハイアラーキ(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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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]、[RFC3471]と同様にITU-T[G.707]、[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)。 通り(-N): 同期輸送信号レベルN (Sonet。) VC-n: 仮想の容器-n(SDH)。 VTn: 仮想の支流-n(Sonet)。
2. SONET and SDH Traffic Parameters
2. SonetとSDH交通パラメタ
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交通パラメタを定義します。 プロトコルの特定の形式であり、SDH特有のRSVP-TE物とCR Sonet/自由民主党に関して、TLVsはセクション2.2と2.3でそれぞれ説明されます。
Mannie & Papadimitriou Standards Track [Page 2] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[2ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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]に1人の基底集合の能力を指定します。 他のドキュメントは将来、さらにこのセットの能力を高めるかもしれません。 例えば、PDH ITU-Tの上のSDH G.832かサブSTM-0 ITUのT G.708インタフェースに合図するのを定義できました。
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を見る)定義された交通パラメタを使用しなければなりません。 また、セクション/RSか線/MSのオーバーヘッドの透明なSTS-1/STM-0の1つを要求するとき、それらを使用しなければなりません、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.
完全に透明なSTS-1/STM-0に[RFC3471]で定義された交通パラメタとラベルコード化(セクション3.2)を使用しなければなりません、STS-3*N/STM-N。(N=1、4、16、64、256)信号は要求します。 完全に見え透いた信号はすべてのオーバーヘッドが中間的ノードによって変更されていないままにされるものです、すなわち、セクション2.1で定義された交通パラメタが使用されるならすべての定義されたTransparency(T)ビットが設定されるとき。
2.1. SONET/SDH Traffic Parameters
2.1. Sonet/SDH交通パラメタ
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 信号タイプ| RCC| NCC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NVC| 乗数(MT)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 透明(T)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | プロフィール(p)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Annex 1 lists examples of SONET and SDH signal coding.
SonetとSDHに関する別館1リストの例はコード化を示します。
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を包括するElementary Signalのタイプを示します。 相次ぐときにLSPのために実際に要求されているFinal Signalを造るためにいくつかの変換をElementary Signalに適用できます。
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.
ゼロであるならそれぞれの変換アプリケーションを任意であり、無視しなければなりません、ゼロであることができなく、1つと等しいなら無視されるMultiplier(MT)を除いて。
Mannie & Papadimitriou Standards Track [Page 3] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[3ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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分野を使用するのによる)をElementary Signalに適用できます、近接して連結された信号をもたらして。
- Second, virtual concatenation (by using the NVC field) can be
optionally applied on the Elementary Signal resulting in a
virtually concatenated signal.
- 2番目に、任意に、仮想の連結(NVC分野を使用するのによる)を実際には連結された信号をもたらすElementary Signalに適用できます。
- 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よりむしろ信号が信号を基礎づけてフレームを要求するとき、3番目に、任意に、何らかの透明(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番目に、任意に、Elementary Signalの直接上、または、第1段階から入手された近接して連結された信号の上、または、2番目のフェーズから入手された実際には連結された信号の上、または、何らかの透明に結合されたこれらの信号の上に乗法(Multiplier分野を使用するのによる)を適用できます。
Permitted Signal Type values for SONET/SDH are:
Sonet/SDHのための受入れられたSignal Type値は以下の通りです。
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)
値のタイプ(基本の信号)----- ------------------------ 1 VT1.5 SPE / VC-11 2VT2 SPE / VC-12 3VT3 SPE4VT6 SPE/VC-2 5 STS-1 SPE/VC-3 6 STS-3c SPE/VC-4 7 STS-1/STM-0(透明を要求するときだけ)8STS-3 / STM-1(透明を要求するときだけ)9STS-12 / STM-4(透明を要求するときだけ)10STS-48 / STM-16(透明を要求するときだけ)11STS-192 / STM-64(透明を要求するときだけ)12STS-768 / STM-256(透明を要求するときだけ)
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.
ひたむきな信号タイプは3STS-1 SPEsの隣接の連結としてそれをコード化することの代わりにSonet STS-3c 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.
この分野は、Elementary Signalの任意のSonet/SDHの隣接の連結を要求するのに使用されます。
Mannie & Papadimitriou Standards Track [Page 4] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[4ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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.
同時に1個以上の旗を受ける川下のノードは特定のタイプの隣接の連結を選びます、支持されて、これが使い果たされた評価基準に基づいているいずれか範囲を記録するなら。 分野によって示された連結タイプのいずれも支えない川下のノードは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.
ゼロに全体の分野が、隣接の連結が全く(デフォルト値)要求されていないのを示すように設定されます。 非ゼロ磁場は、何らかの隣接の連結が要求されているのを示します。
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 SPEsの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.
この分野は連結されるよう要求されている同じSonet SPEs/SDH VCs(すなわち、Elementary Signal)の数を示します、RCC分野で指定されるように。
Mannie & Papadimitriou Standards Track [Page 5] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[5ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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を要求するとき、いつも使用へのElementary SignalはSTS-3c_SPE信号タイプであるに違いありません、そして、NCCの値はいつもX.と等しいに違いありません。Thisは、また、SonetとSDHの間の織り込むことを容易にするのを許容します。 この仕様に従ってこのタイプに関する信号がSTS-3c SPEがタイプに合図するコード化された使用であるに違いないので、特に、それは、3STS-1 SPEsの隣接の連結を要求できないことを意味します。
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.
この分野は実際には連結されるよう要求されている信号の数を示します。 これらの信号は定義上同じタイプのすべてです。 それらは、信号タイプがすなわち、このドキュメント、VT1.5_SPE/VC-11で定義されるElementary Signal SPEs/VCs、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.
この分野はFinal Signalを形成するすなわちLSPのために要求されている同じ信号の数を示します。 これらの信号は、同じElementary Signalsか、同じ近接して連結された信号か同じ実際には連結された信号のどちらかであるかもしれません。 その結果、これらのすべての信号が同じ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
シグナリングで指定されるラベルの注文で複数の実際には連結された信号の部品での区別をします。 ラベルの第一セットが最初のコンポーネントについて説明しなければならない、(1番目に属す個々の信号のセット
Mannie & Papadimitriou Standards Track [Page 6] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[6ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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が設立されるノード自体とインタフェースが要求された乗数値を支えることができることを確かめなければなりません。 要求された値を支持できないなら、受信機ノードは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場合では、これらはセクションOverhead(SOH)、および線Overhead(LOH)の分野です。 SDH場合では、これらは、RegeneratorセクションOverheadの分野(RSOH)と、Multiplexセクションオーバーヘッド(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.
また、以下のSignal Typesを使用するときだけ、透明が適切であることに注意してください: 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に渡さなければならないこれらの頭上の野原を通り過ぎるでしょう。 LSRsが指す視点のイングレスと出口から、これらの分野を変更されないとみなさなければなりません。
Mannie & Papadimitriou Standards Track [Page 7] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[7ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
Transparency is not applied at the interfaces with the initiating and terminating LSRs, but is only applied between intermediate LSRs.
透明は、開始とLSRsを終えるとのインタフェースで適用されませんが、中間的LSRsの間で適用されるだけです。
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が設立されるノード自体とインタフェースが要求された透明を支えることができることを確かめなければなりません。 要求された旗を支えることができないなら、受信機ノードは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.
ゼロへのセットが伝えられた時とSHOULDであったなら、どんな標準のプロフィールも、現在、定義されていてまたはこの分野SHOULDではありません。無視されて、いつが受信されたかということになってください。
In the future TLV based extensions may be created.
将来、TLVのベースの拡張子は作成されるかもしれません。
Mannie & Papadimitriou Standards Track [Page 8] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[8ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
2.2. RSVP-TE Details
2.2. RSVP-Teの詳細
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
Sonet/SDH SENDER_TSPECは反対します: クラスは4Sonet/SDH FLOWSPEC12、C-タイプ=物と等しいです: クラスは9、C-タイプ=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が省略されるか、またはDefault Characterization Parameters司令官とGuaranteed Service断片がある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.
FLOWSPEC物のコンテンツがResvメッセージSHOULDで受信されたセッションにおける特定の送付者にとって、対応するPathメッセージに受け取られたSENDER_TSPEC物のコンテンツと同じにしてください。 物が合っていないなら、「交通Control Error/悪いFlowspec値」誤りSHOULDが発生している状態で、ResvErrメッセージです。
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が設立されるノード自体とインタフェースが要求されたSignal Type、RCC、NCC、NVC、およびMultiplierを支えることができることを確かめなければなりません(セクション2.1で定義されるように)。 要求された値を支持できないなら、受信機ノードは「交通Control Error/サービスサポートされない」指示で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]).
さらに、aゼロ値でMT野原を受け取るなら、ノードは「交通Control Error/悪い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が設立されるノード自体とインタフェースが要求されたTransparencyを支えることができることを確かめなければなりません(セクション2.1で定義されるように)。 要求された値を支持できないなら、受信機ノードは「交通Control Error/サービスサポートされない」指示でPathErrメッセージを発生させなければなりません([RFC2205]を見てください)。
2.3. CR-LDP Details
2.3. CR-自由民主党の詳細
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-自由民主党に関しては、Sonet/SDH交通パラメタはSonet/SDH Traffic Parameters TLVで運ばれます。 TLVの内容は上でセクション2.1で定義されます。 TLVのヘッダーには、以下の形式があります:
Mannie & Papadimitriou Standards Track [Page 9] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[9ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type field for the SONET/SDH Traffic Parameters TLV is: 0x0838.
Sonet/SDH Traffic Parameters TLVのためのタイプ分野は以下の通りです。 0×0838。
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が設立されるノード自体とインタフェースが要求されたSignal Type、RCC、NCC、NVC、およびMultiplierを支えることができることを確かめなければなりません(セクション2.1で定義されるように)。 要求された値を支持できないなら、受信機ノードは「リソース入手できません、な」ステータスコードで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]).
さらに、aゼロ値で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が設立されるノード自体とインタフェースが要求されたTransparencyを支えることができることを確かめなければなりません(セクション2.1で定義されるように)。 要求された値を支持できないなら、受信機ノードは「リソース入手できません、な」ステータスコードでNOTIFICATIONメッセージを発生させなければなりません([RFC3212]を見てください)。
3. SONET and SDH Labels
3. SonetとSDHラベル
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]あたりのGeneralized Labelと[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]で説明されるように、ラベルはラベルが属する「クラス」を特定しません。 これはラベルが使用されているリンクでそれとなく決定します。
Mannie & Papadimitriou Standards Track [Page 10] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[10ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
In case of signal concatenation or multiplication, a list of labels can appear in the Label field of a Generalized Label.
信号連結か乗法の場合には、ラベルのリストはGeneralized Labelの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個のラベルだけがLabel分野に現れます。 このラベルは近接して連結された信号によって占領される中で最も低い時間帯を特定します。 最も低い時間帯で、私たちは整数値(すなわち、木を滑降させるとき遭遇する連結された信号の最初のコンポーネント信号によって占領された時間帯)として比べると持っている中でラベル(値)最も低いものを言っています。
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 ITU[T1.105]/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の一部であるなら同じ(コンポーネント)リンクの上に移動しなければなりません。 これはラベルが(コンポーネント)リンクに縛られる方法のためです。 しかしながら、注意、本当に、異なった経路のコンポーネントのルーティングは異なったLSPs(それ自身のルートを持っているそれぞれ)を設立するのに同等です。 同じノードの間で数個のLSPsを開始して、終えることができます、そして、次に、それらの対応するコンポーネントは一緒に(すなわち、実際には連結される)関連づけることができます。
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.
乗法(すなわち、乗数変換を使用する)の場合には、Final Signalに参加するすべてのラベルの明白な規則正しいリストを与えます。 実際には連結された信号の乗法の場合には、ラベルの第一セットは最初の実際には連結された信号によって占領された時間帯を示して、2番目のセットのラベルは2番目の実際には連結された信号などによって占領された時間帯を示します。 上の表現は、単一の(コンポーネント)リンクに残るために乗法を制限します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mannie & Papadimitriou Standards Track [Page 11] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[11ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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.
これによるナンバリングスキームの拡大が[G.707]セクション7.3の.7〜7.3ですなわち、.13、(K、L、M)付番を定義したということです。 より高いオーダーナンバリングスキームが[G.707]セクション7.3の.1〜7.3で.6を定義したというメモはここで使用されません。
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時に始まって、ゼロは、非重要であるか無視された分野を示すのに使用されます。
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 LSPsの階層構造が使用されているとき、下層階級LSPsを運ぶのに与えられた帯域幅がある、より高いオーダーLSPを使用できます。 ここで、より高いオーダーLSPがSonet/SDHの、より高いオーダー経路層のネットワークと下側のオーダーLSPを通して設立されたのを覚えていてください、Sonet/SDH下層階級経路層のネットワークを通して(また、ITU-T G.803を見てください、対応する定義のためのセクション3)。 このような関係においては、より高いオーダーSonet/SDH LSPは与えられた帯域幅(例えば、VC-3)との「仮想のリンク」として振る舞います、また、それはForwarding Adjacencyとして使用されるかもしれません。 そのより高いオーダーLSPを通して下側のオーダーSonet/SDH 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.
例えば、下層階級LSPsを運ぶのにVC-3 LSPを使用できます。 その場合、下層階級LSPsのためにVC-3 LSPの2つの端の間に割り当てられるラベルは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. 8月1日に-S=1>NはSTS-N/STM-Nマルチプレックスの中の特定のSTS-3/のインデックスです。 SONET STS-N(N>1)とSDH STM-N(N>0)だけに、Sは重要です。 0であり、STS-1とSTM-0のために無視されて、Sはそうしなければなりません。
Mannie & Papadimitriou Standards Track [Page 12] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[12ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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. 8月1日に-U=1>3はSTS-3/の中の特定のSTS-1_SPE/VC-3のインデックスです。 SONET STS-N(N>1)とSDH STM-N(N>0)だけに、Uは重要です。 0であり、STS-1とSTM-0のために無視されて、Uはそうしなければなりません。
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のインデックスです。 TUG-3で構造化されたSDH VC-4だけに、Kは重要です。 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の中の特定のバーモント_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はバーモント_Group/TUG-2の中の特定のVT1.5_SPE/VC-11、VT2_SPE/VC-12またはVT3_SPEのインデックスです。 1M=>2が対応するバーモントGroupの中に特定のVT3 SPEを示して、VT3の同等物が全くSDHと共にないので、これらの値はSDHに使用されてはいけません。 3M=>5が対応するバーモント_Group/TUG-2の中に特定のVT2_SPE/VC-12を示します。 6M=>9が対応するバーモント_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].
すなわち、セクション2.1で定義されたすべてのTransparency(T)ビットがゼロに設定されると、どんなわかりやすくないSonet/SDH信号要求においても、SUKLMと呼ばれたこのセクションで定義されたラベル書式は使用されているに違いありません。 どんな透明なSTS-1/STM-0/STS-3*N/STM-N、も(N=1、4、16、64、256)信号要求は[RFC3471]で定義されるようにラベル形式を使用しなければなりません。
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
S SDH Sonet------------------------------------------------ 0 他の他の1つの最初の8月-1最初のSTS-3 2 2番目の8月-1 2番目のSTS-3 3 3番目の8月-1 3番目のSTS-第3 4 4 8月-第1 4STS-3: : : N n番目の8月-1n番目のSTS-3
Mannie & Papadimitriou Standards Track [Page 13] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[13ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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
U SDH8月-1Sonet通り-3------------------------------------------------- 0 2番目のSTS-1 SPE3 3番目の2番目の最初のVC-3STS-1 SPE2VC-3VC-3第3他の他の1つの最初の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
K SDH VC-4--------------- 0 他の1つの最初のTUG-3 2 2番目のTUG-3 3第3TUG-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
L SDH強い引き-3SDH VC-3Sonet通り-1SPE------------------------------------------------- 0 2番目のTUG-2 6番目のTUG-2 6番目のVTG7 7番目の6番目の5番目の4番目の3番目のTUG-2TUG-2最初の最初のVTG2TUG-2 2番目のTUG-2 2番目のVTG3TUG-2 3番目のTUG-2 3番目のVTG4TUG-2 4番目のTUG-2 4番目のVTG5TUG-2 5番目のTUG-2 5番目のVTG6TUG-2 7番目のTUG-2第7他の他の他の1つの最初の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
M SDH強い引き-2Sonet VTG------------------------------------------------- 0 他の他の1つ--最初のVT3 SPE2--2番目のVT1.5 SPE9 4番目の3番目の3番目の2番目の2番目の3番目の3番目の2番目の2番目の最初の最初の最初の最初のVT3 SPE3のVC-11VT1.5 SPE8VC-11VC-11VC-12VT2 SPE4VC-12VT2 SPE5VC-12VT2 SPE6VC-11VT1.5 SPE7第4VT1.5 SPE
Mannie & Papadimitriou Standards Track [Page 14] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[14ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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: 8月1日に-Sth STS-3/の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: Sth8月-1のVC-4の中のKth-1 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: 8月1日に-Sth STS-3/の中の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: 8月1日に-Sth STS-3/の中のUth-1 STS-1_SPE/VC-3のLth-1バーモントGroup/TUG-2のVT6/VC-2のためのラベルは以下の通りです。 S>0、U>0、K=0、L>0、M=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: 8月1日に-Sth STS3/の中のUth-1 STS-1_SPE/VC-3の中のLth-1バーモントGroup/TUG-2における第3VT1.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: 8月1日に-最初のtimeslotとして第9STS-3/を使用する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の値は、分野コード化規則に従ってゼロに合わせるために等しくなければなりません。 例えば、U=0、STM-0でVC-3を要求して、ラベルがS=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.
以下に注意してください。 いつaセクション/RSの、または、線/MS透明なSTS-1/STM-0/STS3*N/STM-N(N=1、4、16、64、256)信号は要求されていて、SUKLMは形式をラベルして、コード化は適切でなく、ラベルコード化は[RFC3471]セクション3.2で定義された規則に従わなければならないか。
4. Acknowledgments
4. 承認
Valuable comments and input were received from the CCAMP mailing list where outstanding discussions took place.
傑出している議論が行われたCCAMPメーリングリストから貴重なコメントと入力を受け取りました。
Mannie & Papadimitriou Standards Track [Page 15] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[15ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
5. Security Considerations
5. セキュリティ問題
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で説明されて、CR-自由民主党についてRSVP-TEと[RFC3212]に[RFC3209]について言及します。
6. IANA Considerations
6. IANA問題
Three values have been defined by IANA for this document:
3つの値がこのドキュメントのためにIANAによって定義されました:
Two RSVP C-Types in registry:
http://www.iana.org/assignments/rsvp-parameters
登録の2つのRSVP C-タイプ: 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-タイプ=4と等しいです(セクション2.2を見てください)。
- A SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (see section
2.2).
- Sonet/SDH FLOWSPEC物: クラスは9、C-タイプ=4と等しいです(セクション2.2を見てください)。
One LDP TLV Type in registry:
http://www.iana.org/assignments/ldp-namespaces
登録の1自由民主党TLV Type: http://www.iana.org/assignments/ldp-namespaces
- A type field for the SONET/SDH Traffic Parameters TLV (see section
2.3).
- Sonet/SDH Traffic Parameters TLV(セクション2.3を見る)のためのタイプ分野。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[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] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、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.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
Mannie & Papadimitriou Standards Track [Page 16] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[16ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
[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.、アンデション、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、オースター、T.、フェルドマン、N.、Fredette、A.、Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.、およびA.Malis、「自由民主党を使用して、規制ベースのLSPはセットアップします」、RFC3212、2002年1月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(MPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(MPLS)のシグナリングの機能的な記述」、RFC3471、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-スミス、P.、およびL.バーガー、「マルチプロトコルで一般化されて、切り換え(MPLS)をシグナリングとラベルしてください--規制ベースの発送されたラベル分配プロトコル(CR-自由民主党)拡大」、RFC3472、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]バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(MPLS)シグナリング--資源予約は交通工学(RSVP-Te)拡大について議定書の中で述べます」、RFC3473、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] エドマニー、E.、RFC3945、「一般化されたMultiprotocolラベルは(GMPLS)構造を切り換えること」での10月2004日
[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月。
Mannie & Papadimitriou Standards Track [Page 17] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[17ページ]RFC3946GMPLS拡張子は2004年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:
この付録は以下の任意の追加Signal Type値をセクション2.1のSignal Type分野と定義します:
Value Type
----- ---------------------
20 "VC-3 via AU-3 at the end"
値のタイプ----- --------------------- 20 「終わりのAU-3を通したVC-3」
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]推薦によると、TUG-2でSDHマルチプレックスのTU3/TUG-3/VC-4/AU-4ブランチにおけるVC-3を構造化できないで、しかしながら、AU-3ブランチにおけるVC-3があることができます。 必要なら、さらに、2つのブランチの間にVC-3を切り換えることができました。
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.
LSR(例えば、VC-3推進隣接番組を形成する)のイングレスインタフェースでVC-3サーキットを終えることができました。 このLSRは次に、このVC-3が「反-マルチプレックス」に欲しく、内部の下位のLSPsを切り換えることができました。 単に実現理由で、LSRがAU-3ブランチでVC-3を受けるなら、これは可能であるかもしれません。 例えば、逆多重化の前に内部的にTU-3ブランチからAU-3ブランチに入って来るインタフェースを切り換えることができないLSRと次に、スイッチ織物で内容を切り換えるために。
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.
その場合、TU-3ブランチの代わりにAU-3ブランチへの終わりにVC-3 LSPを終えなければならないのを示すのは役に立ちます。
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」信号タイプを使用することによって、達成されます。 例えば、終わりから二番目のLSRは、どんなブランチでも外向的なインタフェースのAU-3ブランチに受け取られた入って来るVC-3を目的地LSRに切り換えるのにこの情報を使用できます。
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.
上に述べられているように、信号タイプはFinal Signalsを入手するために連続した連結、乗法、および透明変換を適用できるElementary Signalsです。
Mannie & Papadimitriou Standards Track [Page 18] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[18ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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で値0があるRCC、値0があるNCC、値0があるNVC、値1があるMT、およびTのアプリケーションでVC-4 Elementary Signalに形成されます。
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で値0があるRCC、値0があるNCC、値7(7つのコンポーネントの仮想の連結)があるNVC、値1があるMT、およびTのアプリケーションでVC-4 Elementary Signalに形成されます。
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信号は値0で旗1(標準の隣接の連結)があるRCC、値16があるNCC、値0があるNVC、値1があるMT、およびTのアプリケーションでVC-4 Elementary Signalに形成されます。
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. Multiplexセクション層の透明があるSTM-16信号は旗2で値0があるRCC、値0があるNCC、値0があるNVC、値1があるMT、およびTのアプリケーションでSTM-16 Elementary Signalに形成されます。
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. Multiplexセクション層の透明があるSTM-4信号はSTM-4 Elementary Signalに適用された旗2で旗0があるRCC、値0があるNCC、値0があるNVC、値1があるMT、およびTのアプリケーションで形成されます。
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. Multiplexセクション層の透明があるSTM-256信号はSTM-256 Elementary Signalに適用された旗2で旗0があるRCC、値0があるNCC、値0があるNVC、値1があるMT、およびTのアプリケーションで形成されます。
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で値0があるRCC、値0があるNCC、値0があるNVC、値1があるMT、およびTのアプリケーションでSTS-1 SPE Elementary Signalに形成されます。
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信号は値0で値1(標準の隣接の連結)があるRCC、値1があるNCC、値0があるNVC、値1があるMT、およびTのアプリケーションでSTS3c SPE Elementary Signalに形成されます。
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信号は値0で旗1(標準の隣接の連結)があるRCC、値16があるNCC、値0があるNVC、値1があるMT、およびTのアプリケーションでSTS3c SPE Elementary Signalに形成されます。
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で値0があるRCC、値3(3つのコンポーネントの仮想の連結)があるNVC、値1があるMT、およびTのアプリケーションでSTS-1 SPE Elementary Signalに形成されます。
Mannie & Papadimitriou Standards Track [Page 19] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[19ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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信号は値0で値1があるRCC、値1があるNCC、値9(9STS-3cの仮想の連結)があるNVC、値1があるMT、およびTのアプリケーションでSTS-3c SPE Elementary Signalに形成されます。
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信号は旗1で値0があるRCC、値0があるNVC、値1があるMT、およびTのアプリケーションでSTS-12 Elementary Signalに形成されます。
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. 3x STS-768c SPE信号は値0で旗1があるRCC、値256があるNCC、値0があるNVC、値3があるMT、およびTのアプリケーションでSTS-3c SPE Elementary Signalに形成されます。
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で値0があるRCC、値13があるNVC、値5があるMT、およびTのアプリケーションでVC-4 Elementary Signalに形成されます。
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
RCC NCC NVC第MT Tに合図してください。-------------------------------------------------------- VC-4 6 0 0 0 1 0 VC-4-7v6 0 0 7 1 0VC-4-16c6 1 16 0 1 0STM-16 MSの透明な10 0 0 0 1 2STM-4 MSの透明な9 0 0 0 1 2STM-256 MSの透明な12 0 0 0 1 2STS-1 SPE5 0 0 0 1 0STS-3c SPE6 1 1 0 1 0STS-48c SPE6 1 16 0 1 0STS-1-3v SPE5 0 0 3 1 0STS-3c-9v SPE6 1 1 9 1 0のSTS-12のセクションの透明な9 0 0 0 1 1 3x STS-768c SPE6 1 256 0 3 0 5x VC-4-13v6 0 0 13、5 0
Mannie & Papadimitriou Standards Track [Page 20] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[20ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
Contributors
貢献者
Contributors are listed by alphabetical order:
貢献者はアルファベット順で記載されています:
Stefan Ansorge (Alcatel) Lorenzstrasse 10 70435 Stuttgart, Germany
ステファンAnsorge(アルカテル)Lorenzstrasse10 70435シュツットガルト(ドイツ)
EMail: stefan.ansorge@alcatel.de
メール: stefan.ansorge@alcatel.de
Peter Ashwood-Smith (Nortel) PO. Box 3511 Station C, Ottawa, ON K1Y 4H7, Canada
ピーター・Ashwood-スミス(ノーテル)PO。 箱3511の駅C、K1Y 4H7、カナダのオタワ
EMail:petera@nortelnetworks.com
メール: petera@nortelnetworks.com
Ayan Banerjee (Calient) 5853 Rue Ferrari San Jose, CA 95138, USA
フェラーリサンノゼ、バネルジー(Calient)5853Rueカリフォルニア 95138、アヤン米国
EMail: abanerjee@calient.net
メール: abanerjee@calient.net
Lou Berger (Movaz) 7926 Jones Branch Drive McLean, VA 22102, USA
ヴァージニア 22102、ルウ・バーガー(Movaz)7926ジョーンズ支店のDriveマクリーン(米国)
EMail: lberger@movaz.com
メール: lberger@movaz.com
Greg Bernstein (Ciena) 10480 Ridgeview Court Cupertino, CA 94014, USA
グレッグバーンスタイン(Ciena)10480Ridgeview法廷カルパチーノ、カリフォルニア 94014、米国
EMail: greg@ciena.com
メール: greg@ciena.com
Angela Chiu (Celion) One Sheila Drive, Suite 2 Tinton Falls, NJ 07724-2658
アンジェラチウ(Celion)1シェイラDrive、2つのスイートTinton滝、ニュージャージー07724-2658
EMail: angela.chiu@celion.com
メール: angela.chiu@celion.com
Mannie & Papadimitriou Standards Track [Page 21] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[21ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
John Drake (Calient) 5853 Rue Ferrari San Jose, CA 95138, USA
フェラーリサンノゼ、ジョンドレイク(Calient)5853Rueカリフォルニア 95138、米国
EMail: jdrake@calient.net
メール: jdrake@calient.net
Yanhe Fan (Axiowave) 100 Nickerson Road Marlborough, MA 01752, USA
Yanheファン(Axiowave)100Nickerson Roadマールバラ、MA 01752、米国
EMail: yfan@axiowave.com
メール: yfan@axiowave.com
Michele Fontana (Alcatel) Via Trento 30, I-20059 Vimercate, Italy
トレント30、I-20059 Vimercate、イタリア経由でミシェルフォンタナ(アルカテル)
EMail: michele.fontana@alcatel.it
メール: michele.fontana@alcatel.it
Gert Grammel (Alcatel) Lorenzstrasse, 10 70435 Stuttgart, Germany
Lorenzstrasse、ゲルトGrammel(アルカテル)10 70435シュツットガルト(ドイツ)
EMail: gert.grammel@alcatel.de
メール: gert.grammel@alcatel.de
Juergen Heiles (Siemens) Hofmannstr. 51 D-81379 Munich, Germany
ユルゲンHeiles(シーメンス)Hofmannstr。 51 D-81379ミュンヘン(ドイツ)
EMail: juergen.heiles@siemens.com
メール: juergen.heiles@siemens.com
Suresh Katukam (Cisco) 1450 N. McDowell Blvd, Petaluma, CA 94954-6515, USA
Suresh Katukam(シスコ)1450N.マクドウェルBlvd、ペタルマ、カリフォルニア94954-6515(米国)
EMail: suresh.katukam@cisco.com
メール: suresh.katukam@cisco.com
Kireeti Kompella (Juniper) 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
Kireeti Kompella(杜松)1194N.マチルダAve。 サニーベル、カリフォルニア 94089、米国
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
Mannie & Papadimitriou Standards Track [Page 22] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[22ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
Jonathan P. Lang (Calient) 25 Castilian Goleta, CA 93117, USA
カスティリャのゴレタ、ジョナサンP.ラング(Calient)25カリフォルニア 93117、米国
EMail: jplang@calient.net
メール: jplang@calient.net
Fong Liaw (Solas Research)
フォンLiaw(ソラスResearch)
EMail: fongliaw@yahoo.com
メール: fongliaw@yahoo.com
Zhi-Wei Lin (Lucent) 101 Crawfords Corner Rd Holmdel, NJ 07733-3030, USA
Zhi-ウェイ・リン(透明な)101Crawfordsが第Holmdel、ニュージャージー07733-3030(米国)を追い詰めます。
EMail: zwlin@lucent.com
メール: zwlin@lucent.com
Ben Mack-Crane (Tellabs)
ベンマック-クレーン(Tellabs)
EMail: ben.mack-crane@tellabs.com
メール: ben.mack-crane@tellabs.com
Dimitrios Pendarakis (Tellium) 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
デーメートリオスPendarakis(Tellium)2三日月形場所、Oceanport、ニュージャージー07757-0901、P.O. Box901米国
EMail: dpendarakis@tellium.com
メール: dpendarakis@tellium.com
Mike Raftelis (White Rock) 18111 Preston Road Dallas, TX 75252, USA
ダラス、テキサス 75252、マイクRaftelis(ホワイトロック)18111プレストン・ロード米国
Bala Rajagopalan (Tellium) 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
Bala Rajagopalan(Tellium)2三日月形場所、Oceanport、ニュージャージー07757-0901、P.O. Box901米国
EMail: braja@tellium.com
メール: braja@tellium.com
Mannie & Papadimitriou Standards Track [Page 23] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[23ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
Yakov Rekhter (Juniper) 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
ヤコフRekhter(杜松)1194N.マチルダAve。 サニーベル、カリフォルニア 94089、米国
EMail: yakov@juniper.net
メール: yakov@juniper.net
Debanjan Saha (Tellium) 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
Debanjanシャハ(Tellium)2三日月形場所、Oceanport、ニュージャージー07757-0901、P.O. Box901米国
EMail: dsaha@tellium.com
メール: dsaha@tellium.com
Vishal Sharma (Metanoia) 335 Elan Village Lane San Jose, CA 95134, USA
Laneサンノゼ、Vishalシャルマ(Metanoia)335活気村のカリフォルニア 95134、米国
EMail: vsharma87@yahoo.com
メール: vsharma87@yahoo.com
George Swallow (Cisco) 250 Apollo Drive Chelmsford, MA 01824, USA
ジョージツバメ(シスコ)250アポロDriveチェルムズフォード、MA 01824、米国
EMail: swallow@cisco.com
メール: swallow@cisco.com
Z. Bo Tang (Tellium) 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
Z.棒ピリッとする味(Tellium)2三日月形場所、Oceanport、ニュージャージー07757-0901、P.O. Box901米国
EMail: btang@tellium.com
メール: btang@tellium.com
Eve Varma (Lucent) 101 Crawfords Corner Rd Holmdel, NJ 07733-3030, USA
イブ・バルマー(透明な)101Crawfordsが第Holmdel、ニュージャージー07733-3030(米国)を追い詰めます。
EMail: evarma@lucent.com
メール: evarma@lucent.com
Yangguang Xu (Lucent) 21-2A41, 1600 Osgood Street North Andover, MA 01845, USA
ノースアンドーバー、MA 01845、21-2A41、Yangguang Xu(透明な)1600オズグッド通り米国
EMail: xuyg@lucent.com
メール: xuyg@lucent.com
Mannie & Papadimitriou Standards Track [Page 24] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[24ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
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
エリックマニー(コンサルタント)アベニューde la Folle Chanson、2B-1050ブリュッセル(ベルギー)電話: +32 2 648-5023 モバイル: +32 (0)495-221775
EMail: eric_mannie@hotmail.com
メール: eric_mannie@hotmail.com
Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491
フランシスWellesplein1、ディミトリPapadimitriou(アルカテル)B-2018アントウェルペン(ベルギー)は以下に電話をします。 +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
メール: dimitri.papadimitriou@alcatel.be
Mannie & Papadimitriou Standards Track [Page 25] RFC 3946 GMPLS Extensions for SONET/SDH Control October 2004
Sonet/SDHのためのマニーとPapadimitriou標準化過程[25ページ]RFC3946GMPLS拡張子は2004年10月に制御されます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Mannie & Papadimitriou Standards Track [Page 26]
マニーとPapadimitriou標準化過程[26ページ]
一覧
スポンサーリンク
