RFC4606 日本語訳
4606 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy(SDH) Control. E. Mannie, D. Papadimitriou. August 2006. (Format: TXT=53492 bytes) (Obsoletes RFC3946) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Mannie
Request for Comments: 4606 Perceval
Obsoletes: 3946 D. Papadimitriou
Category: Standards Track Alcatel
August 2006
コメントを求めるワーキンググループE.マニーの要求をネットワークでつないでください: 4606Percevalは以下を時代遅れにします。 3946年のD.Papadimitriouカテゴリ: 標準化過程アルカテル2006年8月
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 cof this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 分配はcofされます。このメモは無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document provides minor clarification to RFC 3946.
このドキュメントは小さい方の明確化をRFC3946に供給します。
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 GMPLS signaling is used.
このドキュメントはGeneralized Multi-プロトコルLabel Switching(GMPLS)シグナリングへの仲間です。 GMPLSシグナリングが使用されているとき、それは技術特殊情報が必要とした同期式光通信網(Sonet)/同期デジタルハイアラーキ(SDH)を定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. SONET and SDH Traffic Parameters ................................3
2.1. SONET/SDH Traffic Parameters ...............................3
2.2. RSVP-TE Details ............................................9
2.3. CR-LDP Details ............................................10
3. SONET and SDH Labels ...........................................11
4. Acknowledgements ...............................................16
5. Security Considerations ........................................16
6. IANA Considerations ............................................16
Contributors ......................................................17
Appendix 1. Signal Type Values Extension for VC-3 .................20
Annex 1. Examples .................................................20
Normative References ..............................................23
1. 序論…2 2. SonetとSDH交通パラメタ…3 2.1. Sonet/SDH交通パラメタ…3 2.2. RSVP-Teの詳細…9 2.3. CR-自由民主党の詳細…10 3. SonetとSDHラベル…11 4. 承認…16 5. セキュリティ問題…16 6. IANA問題…16人の貢献者…17 付録1。 信号タイプはVC-3のために拡大を評価します…20 別館1。 例…20 標準の参照…23
Mannie & Papadimitriou Standards Track [Page 1] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[1ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
1. Introduction
1. 序論
As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS from supporting packet (Packet Switching Capable, or 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].
[RFC3945]で説明されるように、Generalized MPLS(GMPLS)はパケット(パケットSwitching Capable、またはPSC)インタフェースを支持して、4つの新しいクラスのインタフェースのサポートを含むように切り替わって、切り替わるのからMPLSを広げています: 層-2はできる(L2SC)、時分割多重(TDM)、λスイッチのできる(LSC)、およびファイバースイッチのできる(FSC)を切り換えます。 MPLSシグナリングへの拡大の機能的な記述は、新しいクラスのインタフェースを支持する必要がありました、そして、[RFC3471]に切り換えを提供します。 [RFC3473]はRSVP-TE特有の形式について説明します、そして、メカニズムは、すべての5つのクラスのインタフェースを支持する必要がありました、そして、[RFC3472]でCR自由民主党拡張子は見つけることができます。
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.
このドキュメントは同期式光通信網(Sonet)/同期デジタルハイアラーキ(SDH)に特定の詳細を提示します。 [RFC3471]に従って、SDH Sonet/特有のパラメタは交通のパラメタの特定の物でシグナリングプロトコルで運ばれます。
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 American National Standards Institute (ANSI) [T1.105] and ITU-T [G.707], as well as with that in [RFC3471], [RFC3472], and [RFC3473]. The following abbreviations are used in this document:
そのうえ、読者がAmerican National Standards Institut(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)。 通り(-N): 同期輸送信号レベルN (Sonet。) VC-n: 仮想の容器-n(SDH)。 VTn: 仮想の支流-n(Sonet)。
Mannie & Papadimitriou Standards Track [Page 2] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[2ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
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 Sonet/特有のRSVP-TE物とCR-自由民主党TLVsのために、プロトコル特有の形式はセクション2.2と2.3でそれぞれ説明されます。
These traffic parameters specify 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)信号は要求します。 完全に見え透いた信号はすべてのオーバーヘッドが中間的ノードによって変更されていないままにされるものです。 (T) すなわち、すべてがTransparencyを定義したとき、セクション2.1で定義された交通パラメタが使用されるなら、ビットは設定されるでしょうに。
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リストの例はコード化を示します。
Mannie & Papadimitriou Standards Track [Page 3] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[3ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
o) Signal Type (ST): 8 bits
o) タイプ(ST)に合図してください: 8ビット
This field indicates the type of Elementary Signal that constitutes the requested Label Switched Path (LSP). Several transforms can be applied successively on the Elementary Signal to build the Final Signal actually being requested for the LSP.
この分野は要求されたLabel Switched Path(LSP)を構成するElementary Signalのタイプを示します。 相次ぐときにLSPのために実際に要求されているFinal Signalを造るためにいくつかの変換をElementary Signalに適用できます。
Each transform application is optional and must be ignored if zero, except the Multiplier (MT), which cannot be zero and is ignored if equal to one.
ゼロであるならそれぞれの変換アプリケーションを任意であり、無視しなければなりません、Multiplier(MT)を除いて。(Multiplierはゼロであることができなく、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分野を使用するのによる)を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 a frame is requested as signal rather
than an SPE- or VC-based signal.
- 3番目に、何らかの透明(Transparency分野を使用するのによる)がフレームがSPEよりむしろ信号として要求されると任意に指定されたか、VCベースの信号であるかもしれません。
- Fourth, a multiplication (by using the Multiplier field) can be
optionally applied directly on the Elementary Signal, on the
contiguously concatenated signal obtained from the first phase, on
the virtually concatenated signal obtained from the second phase,
or on these signals combined with some transparency.
- 任意に、乗法(Multiplier分野を使用するのによる)を直接Elementary Signalに適用できます、第1段階から入手された近接して連結された信号の上で、4番目、2番目のフェーズ、または、何らかの透明に結合されたこれらの信号の上で入手された実際には連結された信号の上で。
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 transparency is requested)
8 STS-3 / STM-1 (only when transparency is requested)
9 STS-12 / STM-4 (only when transparency is requested)
10 STS-48 / STM-16 (only when transparency is requested)
11 STS-192 / STM-64 (only when transparency is requested)
12 STS-768 / STM-256 (only when transparency is requested)
値のタイプ(基本の信号)----- ------------------------ 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(透明が要求されているときだけ)
Mannie & Papadimitriou Standards Track [Page 4] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[4ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
A dedicated signal type is assigned to a SONET STS-3c SPE instead of being coded 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つの信号タイプ(任意の)を上の値に加えます。
o) Requested Contiguous Concatenation (RCC): 8 bits
o) 隣接の連結(RCC)は要求しました: 8ビット
This field is used to request the optional SONET/SDH contiguous concatenation of the Elementary Signal.
この分野は、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 is supported, and according to criteria that are out of this document's 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 labels 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が下位のビットであることに注意してください。 他の旗は拡大のために予約されます。 受け取って、使用しないなら、それらを送るとゼロに設定しなければならなくて、無視するべきです。
Mannie & Papadimitriou Standards Track [Page 5] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[5ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
See note 1 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を見てください。
o) Number of Contiguous Components (NCC): 16 bits
o) 隣接のコンポーネント(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分野で指定されるように。
Note 1: When a SONET STS-Nc SPE with N=3*X is requested, the Elementary Signal to be used must always be an STS-3c_SPE signal type, and the value of NCC must always be equal to X. This allows facilitating the interworking between SONET and SDH. In particular, it means that the contiguous concatenation of three STS-1 SPEs cannot be requested, as 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の間の織り込むことを容易にするのを許容します。 特に、3STS-1 SPEsの隣接の連結を要求できないことを意味します、この仕様に従ってSTS-3c SPE信号タイプを使用することでこのタイプに関する信号をコード化しなければならないとき。
Note 2: When a transparent STS-N/STM-N signal is requested that is 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, NCC set to 1.
注意2: 独身の近接して連結されたSTS-Nc_SPE/VC-4-Ncに制限される見え透いたSTS-N/STM-N信号が要求されているとき、信号タイプはSTS-N/STM-Nであるに違いありません、旗1があるRCC、1に設定されたNCC。
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 implies a number of contiguous components greater than or equal to 1.
NCC値はRCC分野で要求されている隣接の連結のタイプと一致しているに違いありません。 どんな隣接の連結も要求されないなら(RCC=0)、この分野は特に、無関係です。 その場合、それを送るとゼロに設定しなければならなくて、受け取ると、無視するべきです。 0と異なったRCC値は多くの隣接のコンポーネントより多くの1を含意します。
Note 3: Following these rules, when a VC-4 signal is requested, the RCC and the NCC values SHOULD be set to 0, whereas for an STS-3c SPE signal, the RCC and the NCC values SHOULD be set 1. However, if local conditions allow, since the setting of the RCC and NCC values is locally driven, the requesting upstream node MAY set the RCC and NCC values to either SDH or SONET settings without impacting the function. Moreover, the downstream node SHOULD accept the requested values if local conditions allow. If these values cannot be supported, the receiver downstream node SHOULD generate a PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, respectively).
注意3: これらの規則、VC-4信号がいつ要求されるか、そして、RCC、およびNCC値に従って、SHOULDは0に設定されますが、STS-3c SPE信号、RCCのために設定されます、そして、NCCはセットが1であったならSHOULDを評価します。 しかしながら、現地の状況であるなら、RCCとNCC値の設定が局所的に運転されるので、機能に影響を与えないで、SDHかSonetの設定のどちらかへのRCCとNCC値を上流のノードが設定するかもしれない要求に許容してください。 そのうえ、川下ノードSHOULDは現地の状況であるなら要求された値を受け入れます。許容します。 これらの値を支持できないなら、受信機川下ノードSHOULDはPathErr/NOTIFICATIONメッセージを発生させます(それぞれセクション2.2と2.3を見てください)。
o) Number of Virtual Components (NVC): 16 bits
o) 仮想のコンポーネント(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,
この分野は実際には連結されるよう要求されている信号の数を示します。 これらの信号は定義上同じタイプのすべてです。 それらは信号タイプが本書では定義されるElementary Signal SPEs/VCsです。 すなわち、VT1.5_SPE/VC-11
Mannie & Papadimitriou Standards Track [Page 6] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[6ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
VT2_SPE/VC-12, VT3_SPE, VT6_SPE/VC-2, STS-1_SPE/VC-3, or STS-3c_SPE/VC-4.
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(デフォルト値)にこの分野が、どんな仮想の連結も要求されていないのを示すように設定されます。
o) Multiplier (MT): 16 bits
o) 乗数(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 identical Elementary Signals, identical contiguously concatenated signals, or identical virtually concatenated signals. Note that all of these signals thus belong to the same LSP.
この分野はLSPのために要求されている同じ信号の数を示します。 すなわち、それはFinal Signalを形成します。 これらの信号は、同じ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 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.
シグナリングで指定されるラベルの注文で複数の実際には連結された信号の部品での区別をします。 ラベルの第一セットは最初のコンポーネントについて説明しなければならなくて(1番目に仮想であることで属す個々の信号のセットは信号を連結しました)、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 cannot be supported, the receiver node MUST generate a PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, respectively).
1つ(デフォルト値)にこの分野が、まさに信号の1つの例が要求されているのを示すように設定されます。 中間介在物と出口ノードは、LSPが設立されるノード自体とインタフェースが要求された乗数値を支えることができることを確かめなければなりません。 要求された値を支持できないなら、受信機ノードはPathErr/NOTIFICATIONメッセージを発生させなければなりません(それぞれセクション2.2と2.3を見てください)。
Zero is an invalid value. If a zero is received, the node MUST generate a PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, respectively).
ゼロは無効の値です。 ゼロが受け取られているなら、ノードはPathErr/NOTIFICATIONメッセージを発生させなければなりません(それぞれセクション2.2と2.3を見てください)。
Note 1: When a transparent STS-N/STM-N signal is requested that is 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(有効な値だけ)と等しいに違いありません。
o) Transparency (T): 32 bits
o) 透明(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 is requested.
この分野は要求されている透明のタイプを示す旗のベクトルです。 異なったタイプの透明を提供するために数個の旗を結合できます。 すべての組み合わせがどんな必ず有効であるというわけではありません。 この分野へのデフォルト値がゼロである、すなわち、透明は全く要求されていません。
Mannie & Papadimitriou Standards Track [Page 7] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[7ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
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 also that transparency is only applicable when the following signal types are used: 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 such a signal type is requested.
また、以下の信号タイプが使用されているときだけ、透明が適切であることに注意してください: 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 Label Switching Router (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 being unmodified.
透明は、LSPのもう一方の端で変更されていなくこれらのオーバーヘッドにおけるどの野原を届けなければならないかを正確に示します。 透明を要求するイングレスLabel Switching Router(LSR)は少しも変化なしで出口LSRに渡さなければならないこれらの頭上の野原を通り過ぎるでしょう。 LSRsが指す視点のイングレスと出口から、これらの分野を変更されていないとみなさなければなりません。
Transparency is applied not at the interfaces with the initiating and terminating LSRs but only between intermediate LSRs. The transparency field is used to request an LSP that supports the requested transparency type; it may also be used to set up the transparency process to be applied at each intermediate LSR.
透明は開始とLSRsを終えるとのインタフェースで適用されるのではなく、中間的LSRsだけの間で適用されます。 透明分野は要求された透明タイプを支持するLSPを要求するのに使用されます。 また、それは、それぞれの中間的LSRに適用されるために透明過程をセットアップするのに使用されるかもしれません。
The different transparency flags are as follows:
異なった透明旗は以下の通りです:
Flag 1 (bit 1): Section/Regenerator Section layer
Flag 2 (bit 2): Line/Multiplex Section layer
旗1(ビット1): セクション/再生器セクション層のFlag2(ビット2): 線/マルチプレックスセクション層
where bit 1 is the low-order bit. Other flags are reserved; they should be set to zero when sent and 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 cannot be supported, the receiver node MUST generate a PathErr/NOTIFICATION message (see Sections 2.2 and 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 Section/Regenerator Section layer transparency is used all other flags MUST be ignored.
セクション/再生器セクション層の透明は、変更されていなく全体のフレームを届けなければならないことを意味します。 これは、ポインタを調整できないのを含意します。 セクション/再生器セクション層の透明が使用されているとき、他のすべての旗を無視しなければなりません。
Mannie & Papadimitriou Standards Track [Page 8] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[8ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
Line/Multiplex Section layer transparency means that the LOH/MSOH must be delivered unmodified. This implies that pointers cannot be adjusted.
線/マルチプレックスセクション層の透明は、変更されていなくLOH/MSOHを届けなければならないことを意味します。 これは、ポインタを調整できないのを含意します。
o) Profile (P): 32 bits
o) (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 ignored when received.
どんな標準のプロフィールも、現在、定義されていてまたは伝えられるとゼロに用意ができて、受け取ると無視するこの分野SHOULDではありません。
In the future, TLV-based extensions may be created.
将来、TLVベースの拡大は作成されるかもしれません。
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 the SENDER_TSPEC object and for FLOWSPEC objects. The content of the objects is defined above, in Section 2.1. The objects have the following class and type for SONET ANSI T1.105 and SDH ITU-T G.707:
RSVP-TEに関しては、Sonet/SDH交通パラメタはSonet/SDH SENDER_TSPECで運ばれます、そして、FLOWSPECは反対します。 同じ形式はSENDER_TSPEC物とFLOWSPEC物に使用されます。 物の内容は上でセクション2.1で定義されます。 物は、以下のクラスを持って、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.
セッションにおける特定の送付者、ResvメッセージSHOULDに受け取られたFLOWSPEC物のコンテンツにおいて、対応する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]を見てください)。
Mannie & Papadimitriou Standards Track [Page 9] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[9ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
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) cannot 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のヘッダーには、以下の形式があります:
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) cannot 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) cannot be supported, the receiver node MUST generate a NOTIFICATION message with a "Resource Unavailable" status code (see [RFC3212]).
また、中間的ノードは、LSPが設立されるノード自体とインタフェースが要求されたTransparencyを支えることができることを確かめなければなりません(セクション2.1で定義されるように)。 要求された値を支持できないなら、受信機ノードは「リソース入手できません、な」ステータスコードでNOTIFICATIONメッセージを発生させなければなりません([RFC3212]を見てください)。
Mannie & Papadimitriou Standards Track [Page 10] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[10ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
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]で説明されるように、ラベルはラベルが属する「クラス」を特定しません。 これはラベルが使用されているリンクでそれとなく決定します。
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 unique label is encoded as a single 32-bit label value (as defined in this section) of the Generalized Label object (Class-Num = 16, C-Type = 2)/TLV (0x0825). 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 an integer value; i.e., the time-slot occupied by the first component signal of the concatenated signal encountered descending the tree.
隣接の連結の場合には、1個のラベルだけがLabel分野に現れます。 このユニークなラベルはGeneralized Label物(クラスヌムは16、C-タイプ=2と等しい)の/TLV(0×0825)のただ一つの32ビットのラベル値(このセクションで定義されるように)としてコード化されます。 このラベルは近接して連結された信号によって占領される中で最も低い時間帯を特定します。 最も低い時間帯で、私たちは整数値として比べると持っている中でラベル(値)最も低いものを言っています。 すなわち、木を滑降させながら遭遇する連結された信号の最初のコンポーネント信号によって占領された時間帯。
In case of virtual concatenation, the explicit ordered list of all labels in the concatenation is given. This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in this section) of the Generalized Label object (Class-Num = 16, C-Type = 2)/TLV (0x0825). 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. The standard definition for virtual concatenation allows each virtual concatenation components to travel over diverse paths. Within GMPLS, virtual concatenation components
仮想の連結の場合には、連結におけるすべてのラベルの明白な規則正しいリストを与えます。 ラベルのこの規則正しいリストはGeneralized Label物(クラスヌムは16、C-タイプ=2と等しい)の/TLV(0×0825)の32ビットのラベル値(このセクションで定義されるように)の系列としてコード化されます。 各ラベルは実際には連結された信号の部品によって占領された最初の時間帯を示します。 ラベルの注文はペイロードが(時間帯の物理的な注文でない)を連結する命令を反映しなければなりません。 上の表現は単一の(コンポーネント)リンクに残るために仮想の連結を制限します。 ANSI ITU[T1.105]/T[G.707]推薦と比べて、それはそういうものとして制限を課します。 仮想の連結のための標準定義は、さまざまの経路にわたって旅行するためにそれぞれの仮想の連結にコンポーネントを許容します。 GMPLS、仮想の連結コンポーネントの中で
Mannie & Papadimitriou Standards Track [Page 11] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[11ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
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).
それらが同じ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. This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in this section) of the Generalized Label object (Class-Num = 16, C-Type = 2)/TLV (0x0825). In case of multiplication of virtually concatenated signals, the explicit ordered list of the set of labels that take part in the Final Signal is given. 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に参加するすべてのラベルの明白な規則正しいリストを与えます。 ラベルのこの規則正しいリストはGeneralized Label物(クラスヌムは16、C-タイプ=2と等しい)の/TLV(0×0825)の32ビットのラベル値(このセクションで定義されるように)の系列としてコード化されます。 実際には連結された信号の乗法の場合には、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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is an extension of the numbering scheme defined in [G.707], Sections 7.3.7 through 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 through 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 being 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 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 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
Sonet/SDH LSPsの階層構造が使用されているとき、下層階級LSPsを運ぶのに与えられた帯域幅がある高次なLSPを使用できます。 高次なLSPがSonet/SDHの低いオーダー経路層のネットワークを通してSonet/SDHの高次な経路層のネットワーク、および下層階級LSPを通して設立されたのを覚えていてください、(また、ITU-T G.803を見てください、セクション3
Mannie & Papadimitriou Standards Track [Page 12] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[12ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
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は与えられた帯域幅(例えば、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はそうしなければなりません。
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を示します。
Mannie & Papadimitriou Standards Track [Page 13] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[13ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
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].
どんなわかりやすくないSonet/SDH信号要求にもSUKLMと呼ばれたこのセクションで定義されたラベル書式を使用しなければなりません。 すなわち、セクション2.1で定義されたすべてのTransparency(T)ビットがゼロに設定されるとき。 どんな透明な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
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
Mannie & Papadimitriou Standards Track [Page 14] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[14ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
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
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 STS-3/の中の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。
Mannie & Papadimitriou Standards Track [Page 15] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[15ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
Example 6: the label for the STS-12c SPE/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 SPE/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 a VC-3 in an STM-0 is requested, the label is S=0, U=0, K=0, L=0, M=0. When a VC-11 in a VC-3 in an STM-0 is requested, 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)で定義された規則に従わなければなりません。
4. Acknowledgements
4. 承認
Valuable comments and input were received from the CCAMP mailing list, where outstanding discussions took place.
CCAMPメーリングリストから貴重なコメントと入力を受け取りました。そこでは、傑出している議論が行われました。
The authors would like to thank Richard Rabbat for his valuable input, which lead to this revision.
作者は彼の貴重な入力のためのリチャードRabbatに感謝したがっています。(Rabbatはこの改正に通じます)。
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 defined by IANA for RFC 3946 now apply to this document.
現在RFC3946のためにIANAによって定義されている3つの値がこのドキュメントに適用されます。
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を見てください)。
Mannie & Papadimitriou Standards Track [Page 16] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[16ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
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を見る)のためのタイプ分野。
Contributors
貢献者
Contributors are listed in alphabetical order:
貢献者はアルファベット順に記載されています:
Stefan Ansorge (Alcatel) Lorenzstrasse 10 70435 Stuttgart, Germany EMail: stefan.ansorge@alcatel.de
ステファンAnsorge(アルカテル)Lorenzstrasse10 70435シュツットガルト(ドイツ)はメールされます: stefan.ansorge@alcatel.de
Peter Ashwood-Smith (Nortel) PO. Box 3511 Station C, Ottawa, ON K1Y 4H7, Canada EMail:petera@nortelnetworks.com
ピーター・Ashwood-スミス(ノーテル)PO。 箱3511の駅C、K1Y 4H7、カナダメールのオタワ: petera@nortelnetworks.com
Ayan Banerjee (Calient) 5853 Rue Ferrari San Jose, CA 95138, USA EMail: abanerjee@calient.net
フェラーリサンノゼ、バネルジー(Calient)5853Rueカリフォルニア 95138、アヤン米国はメールされます: abanerjee@calient.net
Lou Berger (Movaz) 7926 Jones Branch Drive McLean, VA 22102, USA EMail: lberger@movaz.com
ヴァージニア 22102、ルウ・バーガー(Movaz)7926ジョーンズ支店のDriveマクリーン(米国)はメールされます: lberger@movaz.com
Greg Bernstein (Ciena) 10480 Ridgeview Court Cupertino, CA 94014, USA EMail: greg@ciena.com
グレッグバーンスタイン(Ciena)10480Ridgeview法廷カルパチーノ、カリフォルニア 94014、米国はメールされます: greg@ciena.com
Angela Chiu (Celion) One Sheila Drive, Suite 2 Tinton Falls, NJ 07724-2658 EMail: angela.chiu@celion.com
アンジェラチウ(Celion)1シェイラDrive、2つのスイートTinton滝、ニュージャージー07724-2658メール: angela.chiu@celion.com
John Drake (Calient) 5853 Rue Ferrari San Jose, CA 95138, USA EMail: jdrake@calient.net
フェラーリサンノゼ、ジョンドレイク(Calient)5853Rueカリフォルニア 95138、米国はメールされます: jdrake@calient.net
Mannie & Papadimitriou Standards Track [Page 17] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[17ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
Yanhe Fan (Axiowave) 100 Nickerson Road Marlborough, MA 01752, USA EMail: yfan@axiowave.com
Yanheファン(Axiowave)100Nickerson Roadマールバラ、MA 01752、米国はメールされます: yfan@axiowave.com
Michele Fontana (Alcatel) Via Trento 30, I-20059 Vimercate, Italy EMail: michele.fontana@alcatel.it
トレント30を通したミシェルフォンタナ(アルカテル)、I-20059 Vimercate、イタリアはメールされます: michele.fontana@alcatel.it
Gert Grammel (Alcatel) Lorenzstrasse, 10 70435 Stuttgart, Germany EMail: gert.grammel@alcatel.de
ゲルトGrammel(アルカテル)Lorenzstrasse、10 70435シュツットガルト(ドイツ)メール: gert.grammel@alcatel.de
Juergen Heiles (Siemens) Hofmannstr. 51 D-81379 Munich, Germany EMail: juergen.heiles@siemens.com
ユルゲンHeiles(シーメンス)Hofmannstr。 51 D-81379ミュンヘン(ドイツ)はメールされます: juergen.heiles@siemens.com
Suresh Katukam (Cisco) 1450 N. McDowell Blvd, Petaluma, CA 94954-6515, USA EMail: suresh.katukam@cisco.com
Suresh Katukam(シスコ)1450N.マクドウェルBlvd、ペタルマ、カリフォルニア94954-6515(米国)はメールされます: suresh.katukam@cisco.com
Kireeti Kompella (Juniper) 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA EMail: kireeti@juniper.net
Kireeti Kompella(杜松)1194N.マチルダAve。 サニーベル、カリフォルニア 94089、米国はメールされます: kireeti@juniper.net
Jonathan P. Lang (Calient) 25 Castilian Goleta, CA 93117, USA EMail: jplang@calient.net
カスティリャのゴレタ、ジョナサンP.ラング(Calient)25カリフォルニア 93117、米国はメールされます: jplang@calient.net
Fong Liaw (Solas Research) EMail: fongliaw@yahoo.com
フォンLiaw(ソラスResearch)はメールします: fongliaw@yahoo.com
Zhi-Wei Lin (Lucent) 101 Crawfords Corner Rd Holmdel, NJ 07733-3030, USA EMail: zwlin@lucent.com
Zhi-ウェイ・リン(透明な)101Crawfordsが第Holmdel、ニュージャージー07733-3030(米国)メールを追い詰めます: zwlin@lucent.com
Ben Mack-Crane (Tellabs) EMail: ben.mack-crane@tellabs.com
ベンマック-クレーン(Tellabs)はメールします: ben.mack-crane@tellabs.com
Mannie & Papadimitriou Standards Track [Page 18] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[18ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
Dimitrios Pendarakis (Tellium) 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA EMail: dpendarakis@tellium.com
デーメートリオスPendarakis(Tellium)2三日月形場所、Oceanport、ニュージャージー07757-0901、P.O. Box901米国はメールされます: 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 EMail: braja@tellium.com
Bala Rajagopalan(Tellium)2三日月形場所、Oceanport、ニュージャージー07757-0901、P.O. Box901米国はメールされます: braja@tellium.com
Yakov Rekhter (Juniper) 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA EMail: yakov@juniper.net
ヤコフRekhter(杜松)1194N.マチルダAve。 サニーベル、カリフォルニア 94089、米国はメールされます: yakov@juniper.net
Debanjan Saha (Tellium) 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA EMail: dsaha@tellium.com
Debanjanシャハ(Tellium)2三日月形場所、Oceanport、ニュージャージー07757-0901、P.O. Box901米国はメールされます: dsaha@tellium.com
Vishal Sharma (Metanoia) 335 Elan Village Lane San Jose, CA 95134, USA EMail: vsharma87@yahoo.com
Laneサンノゼ、Vishalシャルマ(Metanoia)335活気村のカリフォルニア 95134、米国はメールされます: vsharma87@yahoo.com
George Swallow (Cisco) 250 Apollo Drive Chelmsford, MA 01824, USA EMail: swallow@cisco.com
ジョージツバメ(シスコ)250アポロDriveチェルムズフォード、MA 01824、米国はメールされます: swallow@cisco.com
Z. Bo Tang (Tellium) 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA EMail: btang@tellium.com
Z.棒ピリッとする味(Tellium)2三日月形場所、Oceanport、ニュージャージー07757-0901、P.O. Box901米国はメールされます: btang@tellium.com
Eve Varma (Lucent) 101 Crawfords Corner Rd Holmdel, NJ 07733-3030, USA EMail: evarma@lucent.com
イブ・バルマー(透明な)101Crawfordsが第Holmdel、ニュージャージー07733-3030(米国)メールを追い詰めます: evarma@lucent.com
Yangguang Xu (Lucent) 21-2A41, 1600 Osgood Street North Andover, MA 01845, USA EMail: xuyg@lucent.com
ノースアンドーバー、MA 01845、21-2A41、Yangguang Xu(透明な)1600オズグッド通り米国はメールされます: xuyg@lucent.com
Mannie & Papadimitriou Standards Track [Page 19] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[19ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
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. For example, 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. The objective is to help the reader to understand how the traffic parameter coding works 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 20] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[20ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
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 value
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 value 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信号は値0があるRCC、値0があるNCC、値0があるNVC、値1があるMT、およびSTM-4 Elementary Signalに適用された旗2があるTのアプリケーションで形成されます。
6. An STM-256 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 applied to
an STM-256 Elementary Signal.
6. Multiplexセクション層の透明があるSTM-256信号は値0があるRCC、値0があるNCC、値0があるNVC、値1があるMT、およびSTM-256 Elementary Signalに適用された旗2がある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のアプリケーションでSTS-3c SPE Elementary Signalに形成されます。
9. An STS-48c SPE signal is formed by the application of RCC with
value 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のアプリケーションでSTS-3c 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 21] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[21ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
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, NCC 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があるNCC、値0があるNVC、値1があるMT、およびTのアプリケーションでSTS-12 Elementary Signalに形成されます。
13. A 3 x STS-768c SPE signal is formed by the application of RCC
with value 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. A 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 22] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[22ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
Normative References
引用規格
[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月。
[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
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。
[RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi-
Protocol Label Switching (GMPLS) Signaling Constraint-
based Routed Label Distribution Protocol (CR-LDP)
Extensions", RFC 3472, January 2003.
[RFC3472]Ashwood-スミス(P.とL.バーガー)は、「ConstraintのベースのRouted Label Distributionプロトコル(CR-自由民主党)拡大に合図しながら、MultiプロトコルLabel Switching(GMPLS)を一般化しました」、RFC3472、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
[RFC3473] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] マニー、E.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)構造」、RFC3945、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月。
Mannie & Papadimitriou Standards Track [Page 23] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[23ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
Authors' Addresses
作者のアドレス
Eric Mannie Perceval Rue Tenbosch, 9 1000 Brussels Belgium
エリックマニーPerceval悔悟Tenbosch、9 1000ブリュッセルベルギー
Phone: +32-2-6409194 EMail: eric.mannie@perceval.net
以下に電話をしてください。 +32-2-6409194はメールされます: eric.mannie@perceval.net
Dimitri Papadimitriou Alcatel Copernicuslaan 50 B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルCopernicuslaan50B-2018アントウェルペン(ベルギー)
Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
以下に電話をしてください。 +32 3 240-8491 メールしてください: dimitri.papadimitriou@alcatel.be
Mannie & Papadimitriou Standards Track [Page 24] RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006
SonetのためのマニーとPapadimitriou標準化過程[24ページ]RFC4606GMPLS拡張子とSDHコントロール2006年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Mannie & Papadimitriou Standards Track [Page 25]
マニーとPapadimitriou標準化過程[25ページ]
一覧
スポンサーリンク
