RFC4328 日本語訳
4328 Generalized Multi-Protocol Label Switching (GMPLS) SignalingExtensions for G.709 Optical Transport Networks Control. D.Papadimitriou, Ed.. January 2006. (Format: TXT=52145 bytes) (Updates RFC3471) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Papadimitriou, Ed. Request for Comments: 4328 Alcatel Updates: 3471 January 2006 Category: Standards Track
ワーキンググループD.Papadimitriou、エドをネットワークでつないでください。コメントのために以下を要求してください。 4328のアルカテルアップデート: 3471 2006年1月のカテゴリ: 標準化過程
Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Extensions for G.709 Optical Transport Networks Control
G.709の光の転送ネットワークコントロールのための一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング拡大
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments.
このドキュメントはGeneralized Multi-プロトコルLabel Switching(GMPLS)シグナリングドキュメントへの仲間です。 それはコントロールOptical Transport Networks(OTN)に合図するGMPLSを広げるのに必要である技術特殊情報について説明します。 また、それはいわゆるプレOTN開発を含んでいます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. GMPLS Extensions for G.709 - Overview ...........................3
3. Generalized Label Request .......................................4
3.1. Common Part ................................................5
3.1.1. LSP Encoding Type ...................................5
3.1.2. Switching Type ......................................6
3.1.3. Generalized-PID (G-PID) .............................6
3.2. G.709 Traffic Parameters ...................................8
3.2.1. Signal Type (ST) ....................................8
3.2.2. Number of Multiplexed Components (NMC) ..............9
3.2.3. Number of Virtual Components (NVC) .................10
3.2.4. Multiplier (MT) ....................................10
3.2.5. Reserved Fields ....................................10
4. Generalized Label ..............................................10
4.1. ODUk Label Space ..........................................11
4.2. Label Distribution Rules ..................................13
1. 序論…2 1.1. このドキュメントで中古のコンベンション…3 2. G.709のためのGMPLS拡張子--、概観…3 3. ラベル要求を広めます…4 3.1. 一般的な部分…5 3.1.1. タイプをコード化するLSP…5 3.1.2. 切り換えタイプ…6 3.1.3. 一般化されたPID(G-PID)…6 3.2. G.709交通パラメタ…8 3.2.1. タイプ(ST)に合図してください…8 3.2.2. 多重送信されたコンポーネント(NMC)の数…9 3.2.3. 仮想のコンポーネント(NVC)の数…10 3.2.4. 乗数(MT)…10 3.2.5. 分野を予約します…10 4. ラベルを一般化します…10 4.1. ODUkはスペースをラベルします…11 4.2. 規則と分配をラベルしてください…13
Papadimitriou Standards Track [Page 1] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[1ページ]RFC4328GMPLS
4.3. Optical Channel Label Space ...............................14
5. Examples .......................................................14
6. RSVP-TE Signaling Protocol Extensions ..........................16
7. Security Considerations ........................................16
8. IANA Considerations ............................................16
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
11. Contributors ..................................................19
Appendix A. Abbreviations .........................................21
Appendix B. G.709 Indexes .........................................22
4.3. 光学チャンネルラベルスペース…14 5. 例…14 6. RSVP-Teシグナリングは拡大について議定書の中で述べます…16 7. セキュリティ問題…16 8. IANA問題…16 9. 承認…18 10. 参照…18 10.1. 標準の参照…18 10.2. 有益な参照…19 11. 貢献者…19 付録A.略語…21 付録B.G.709は索引をつけます…22
1. Introduction
1. 序論
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends MPLS from supporting Packet Switching Capable (PSC) interfaces and switching to include support of four new classes of interfaces and switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM), Lambda Switch (LSC), and Fiber-Switch (FSC) Capable. A functional description of the extensions to MPLS signaling that are needed to support these new classes of interfaces and switching is provided in [RFC3471]. [RFC3473] describes the RSVP-TE-specific formats and mechanisms needed to support all four classes of interfaces.
一般化されたMulti-プロトコルLabel Switching(GMPLS)[RFC3945]はPacket Switching Capable(PSC)インタフェースを支持して、4つの新しいクラスのインタフェースのサポートを含むように切り替わって、切り替わるのからMPLSを広げています: できる層-2の切り換え(L2SC)、時分割多重(TDM)、λスイッチ(LSC)、およびファイバースイッチ(FSC)。 これらの新しいクラスのインタフェースを支持するのに必要であるMPLSシグナリングと切り換えへの拡大の機能的な記述を[RFC3471]に提供します。 [RFC3473]はRSVP-TE特有の形式とすべての4つのクラスのインタフェースを支持するのが必要であるメカニズムについて説明します。
This document presents the technology details that are specific to G.709 Optical Transport Networks (OTN) as specified in the ITU-T G.709 recommendation [ITUT-G709] (and referenced documents), including pre-OTN developments. Per [RFC3471], G.709 technology- specific parameters are carried through the signaling protocol in dedicated traffic parameter objects.
このドキュメントはITU-T G.709推薦[ITUT-G709](そして、参照をつけられたドキュメント)における指定されるとしてのG.709 Optical Transport Networks(OTN)に特定の技術の詳細を提示します、プレOTN開発を含んでいて。 [RFC3471]に従って、G.709技術特定のパラメタは専用交通パラメタ物でシグナリングプロトコルを通して運ばれます。
The G.709 traffic parameters defined hereafter (see Section 3.2) MUST be used when the label is encoded as defined in this document. Moreover, the label MUST be encoded as defined in Section 4 when these G.709 traffic parameters are used.
ラベルが本書では定義されるようにコード化されるとき、今後(セクション3.2を見る)定義されたG.709交通パラメタを使用しなければなりません。 そのうえ、これらのG.709交通パラメタが使用されているとき、セクション4で定義されるようにラベルをコード化しなければなりません。
In the context of this memo, by pre-OTN developments, one refers to Optical Channel, Digital Wrapper and Forward Error Correction (FEC) solutions that are not fully G.709 compliant. Details concerning pre-OTN Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) based solutions including Section/Regenerator Section overhead (SOH/RSOH) and Line/Multiplex Section overhead (LOH/MSOH) transparency are covered in [RFC3946].
このメモの文脈では、プレOTN開発で、人はOptical Channel(完全にG.709対応であるというわけではないDigital WrapperとForward Error Correction(FEC)解決策)について言及します。 セクション/再生器セクションオーバーヘッド(SOH/RSOH)と線/マルチプレックスセクションオーバーヘッド(LOH/MSOH)透明を含むプレOTN同期式光通信網(Sonet)/同期デジタルハイアラーキの(SDH)ベースのソリューションに関する詳細は[RFC3946]でカバーされています。
Papadimitriou Standards Track [Page 2] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[2ページ]RFC4328GMPLS
*** Note on ITU-T G.709 Recommendation ***
*** ITU-T G.709で推薦***に注意してください。
The views on the ITU-T G.709 OTN Recommendation presented in this document are intentionally restricted to the GMPLS perspective within the IETF CCAMP WG context. Hence, the objective of this document is not to replicate the content of the ITU-T OTN recommendations. Therefore, readers interested in more details concerning the corresponding technologies are strongly invited to consult the corresponding ITU-T documents (also referenced in this memo).
本書では寄贈されたITU-T G.709 OTN Recommendationに関する意見は故意にIETF CCAMP WG文脈の中のGMPLS見解に制限されます。 したがって、このドキュメントの目的はITU-T OTN推薦の内容を模写しないことです。 したがって、対応する技術に関してその他の詳細に興味を持っている読者が対応するITU-Tドキュメント(また、このメモでは、参照をつけられる)を参照するよう強く誘われています。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
In addition, the reader is assumed to be familiar with the terminology used in ITU-T [ITUT-G709], as well as [RFC3471] and [RFC3473]. Abbreviations used in this document are detailed in Appendix 1.
さらに、読者がITU-T[ITUT-G709]で使用される用語によく知られさせると思われます、[RFC3471]と[RFC3473]と同様に。 本書では使用される略語はAppendix1で詳細です。
2. GMPLS Extensions for G.709 - Overview
2. G.709のためのGMPLS拡張子--概観
[ITUT-G709] defines several networking layers constituting the optical transport hierarchy:
[ITUT-G709]は光学輸送階層構造を構成する数個のネットワーク層を定義します:
- with full functionality:
. Optical Transmission Section (OTS)
. Optical Multiplex Section (OMS)
. Optical Channel (OCh)
- with reduced functionality:
. Optical Physical Section (OPS)
. Optical Channel with reduced functionality (OChr)
- 完全な機能性で: . 光学Transmissionセクション(OTS) 光学Multiplexセクション(OMS) 減少している機能性がある光学Channel(OCh): . 光学Physicalセクション(OPS) 減少している機能性がある光学Channel(OChr)
It also defines two layers constituting the digital transport hierarchy:
また、それはデジタル輸送階層構造を構成する2つの層を定義します:
- Optical Channel Transport Unit (OTUk) - Optical Channel Data Unit (ODUk)
- 光学チャンネルトランスポート・ユニット(OTUk)--光学チャンネルデータ単位(ODUk)
However, only the OCh and the ODUk layers are defined as switching layers. Both OCh (but not OChr) and ODUk layers include the overhead for supervision and management. The OCh overhead is transported in a non-associated manner (also referred to as the non-associated overhead naOH) in the Optical Transport Module (OTM) Overhead Signal (OOS), together with the OTS and OMS non-associated overhead. The OOS is transported via a dedicated wavelength, referred to as the Optical Supervisory Channel (OSC). It should be noticed that the
しかしながら、OChとODUk層だけが層を切り換えると定義されます。 OCh(しかし、OChrでない)とODUk層の両方が指揮と管理のためのオーバーヘッドを含んでいます。 OChオーバーヘッドはOptical Transport Module(OTM)の頭上のSignal(OOS)で非関連している方法で輸送されます(また、頭上で非関連しているnaOHと呼ばれます)、OTSとOMSの非関連しているオーバーヘッドと共に。 OOSはOptical Supervisory Channel(OSC)と呼ばれたひたむきな波長で輸送されます。 それが気付かれるべきである、それ
Papadimitriou Standards Track [Page 3] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[3ページ]RFC4328GMPLS
naOH is only functionally specified and as such, it is open to vendor-specific solutions. The ODUk overhead is transported in an associated manner as part of the digital ODUk frame.
naOHは機能上指定されるだけです、そして、そういうものとして、それは業者特有の解決策に開かれています。 ODUkオーバーヘッドはデジタルODUkフレームの一部として関連方法で輸送されます。
As described in [ITUT-G709], in addition to the support of ODUk mapping into OTUk (k = 1, 2, 3), G.709 supports ODUk multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into an ODUk (k > j) signal, in particular:
[ITUT-G709](k=1、2、3)をOTUkに写像するODUkのサポートに加えて説明されるように、G.709はODUkマルチプレクシングを支持します。 それはODUk(k>j)への(j=1、2)が特に合図するODUjのマルチプレクシングについて言及します:
- ODU1 into ODU2 multiplexing
- ODU1 into ODU3 multiplexing
- ODU2 into ODU3 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing
- ODU2マルチプレクシングへのODU1--ODU3へのODU2が多重送信して、多重送信するODU3へのODU1--ODU3マルチプレクシングへのODU1とODU2
Adapting GMPLS to control G.709 OTN can be achieved by creating:
以下を作成することによって、G.709 OTNを制御するためにGMPLSを適合させるのを達成できます。
- a Digital Path layer, by extending the previously defined
"Digital Wrapper" in [RFC3471] corresponding to the ODUk
(digital) path layer.
- an Optical Path layer, by extending the "Lambda" concept (defined
in [RFC3471]) to the OCh (optical) path layer.
- a label space structure, by considering a tree whose root is an
OTUk signal and leaves the ODUj signals (k >= j); enabling the
identification of the exact position of a particular ODUj signal
in an ODUk multiplexing structure.
- ODUkの(デジタル)の経路層に対応する[RFC3471]で以前に定義された「デジタル包装紙」を広げるのによるDigital Path層。 - 「λ」概念([RFC3471]では、定義される)についてOChの(光学)の経路層に敷衍するのによるOptical Path層。 - ラベルスペース構造、考えることによって、根の木はOTUk信号であり、ODUj信号を残します(k>はjと等しいです)。 ODUkマルチプレクシング構造の特定のODUj信号の正確な位置の識別を可能にします。
Thus, the GMPLS signaling extensions for G.709 need to cover the Generalized Label Request, the Generalized Label as well as the specific technology dependent objects included in the so-called traffic parameters as specified in [RFC3946] for SONET/SDH networks. Moreover, because multiplexing in the digital domain (such as ODUk multiplexing) has been specified in the amended version of the G.709 ITU-T recommendation (October 2001), this document also proposes a label space definition suitable for that purpose. Notice also that one uses the G.709 ODUk (i.e., Digital Path) and OCh (i.e., Optical Path) layers directly in order to define the corresponding label spaces.
したがって、G.709のために拡大に合図するGMPLSは、Generalized Label Request(Sonet/SDHネットワークのための[RFC3946]の指定されるとしてのいわゆる交通パラメタに依存する物を含んでいる独自技術と同様にGeneralized Label)を覆う必要があります。 そのうえ、デジタルドメイン(ODUkマルチプレクシングなどの)で多重送信するのがG.709 ITU-T推薦(2001年10月)の修正されたバージョンで指定されたので、また、このドキュメントはその目的に適したラベル宇宙定義を提案します。 また、1つが対応するラベル空間を定義するのに直接G.709 ODUk(すなわち、Digital Path)とOCh(すなわち、Optical Path)層を使用するのに注意してください。
3. Generalized Label Request
3. 一般化されたラベル要求
The Generalized Label Request, as defined in [RFC3471], includes a common part (i.e., used for any switching technology) and a technology dependent part (i.e., the traffic parameters). In this section, both parts are extended to accommodate GMPLS Signaling to the G.709 transport plane recommendation (see [ITUT-G709]).
[RFC3471]で定義されるGeneralized Label Requestは一般的な部分(すなわち、どんな切り換え技術のためにも、使用される)と技術に依存する部分(すなわち、交通パラメタ)を含んでいます。 このセクションでは、両方の部品は、G.709輸送機推薦にGMPLS Signalingを収容するために広げられます([ITUT-G709]を見てください)。
Papadimitriou Standards Track [Page 4] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[4ページ]RFC4328GMPLS
3.1. Common Part
3.1. 一般的な部分
As defined in [RFC3471], the LSP Encoding Type, the Switching Type and the Generalized Protocol Identifier (Generalized-PID) constitute the common part of the Generalized Label Request. The encoding of the RSVP-TE GENERALIZED_LABEL_REQUEST object is specified in [RFC3473] Section 2.1.
[RFC3471]で定義されるように、LSP Encoding Type、Switching Type、およびGeneralizedプロトコルIdentifier(一般化されたPID)はGeneralized Label Requestの一般的な部分を構成します。 RSVP-TE GENERALIZED_LABEL_REQUEST物のコード化は[RFC3473]セクション2.1で指定されます。
As mentioned above, this document extends the LSP Encoding Type, the Switching Type, and G-PID (Generalized-PID) values to accommodate G.709 Recommendation [ITUT-G709].
以上のように、このドキュメントはLSP Encoding Type、Switching Type、およびG.709 Recommendation[ITUT-G709]を収容するG-PID(一般化されたPID)値を広げています。
3.1.1. LSP Encoding Type
3.1.1. タイプをコード化するLSP
Because G.709 Recommendation defines two networking layers (ODUk layers and OCh layer), the LSP Encoding Type code-points can reflect these two layers defined in [RFC3471] Section 3.1 as "Digital Wrapper" and "Lambda" code. The LSP Encoding Type is specified per networking layer or, more precisely, per group of functional networking layers: the ODUk layers and the OCh layer.
G.709 Recommendationが2つのネットワーク層を定義するので(ODUk層とOChは層にします)、LSP Encoding Typeコード・ポイントは[RFC3471]セクション3.1で「デジタル包装紙」と「λ」コードと定義されたこれらの2つの層を反映できます。 LSP Encoding Typeはネットワーク層か、よりまさに機能的なネットワーク層のグループ単位で指定されます: ODUk層とOChは層にします。
Therefore, an additional LSP Encoding Type code-point for the G.709 Digital Path layer is defined; it enlarges the existing "Digital Wrapper" code-point defined in [RFC3471]. The former MUST be generated when the interface or tunnel on which the traffic will be transmitted supports G.709 compliant Digital Path layer encoding. The latter MUST only be used for non-G.709 compliant Digital Wrapper layer(s) encoding. A transit or an egress node (receiving a Path message containing a GENERALIZED_LABEL_REQUEST object) MUST generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication, if the requested LSP Encoding Type cannot be supported on the corresponding incoming interface.
したがって、G.709Digital Path層のための追加LSP Encoding Typeコード・ポイントは定義されます。 それは[RFC3471]で定義された既存の「デジタル包装紙」コード・ポイントを拡大します。 交通が送られるインタフェースかトンネルがG.709対応することのDigital Path層のコード化を支持するとき、前者は発生しなければなりません。 非G.709の言いなりになっているDigital Wrapper層のコード化に後者を使用するだけでよいです。 トランジットか出口ノード(GENERALIZED_LABEL_REQUEST物を含むPathメッセージを受け取る)がPathErrメッセージを発生させなければなりません、「ルート設定の問題/サポートされないコード化」指示で、対応する入って来るインタフェースで要求されたLSP Encoding Typeを支持できないなら。
In the same way, an additional LSP Encoding Type code-point for the G.709 Optical Channel layer is defined; it enlarges the existing "Lambda" code-point defined in [RFC3471]. The former MUST be generated when the interface or tunnel on which the traffic will be transmitted supports G.709-compliant Optical Channel layer encoding. The latter MUST only be used for non-G.709 compliant Lambda layer(s) encoding. A transit or an egress node (receiving a Path message that contains a GENERALIZED_LABEL_REQUEST object) MUST generate a PathErr message with a "Routing problem/Unsupported Encoding" indication, if the requested LSP Encoding Type cannot be supported on the corresponding incoming interface.
同様に、G.709 Optical Channel層のための追加LSP Encoding Typeコード・ポイントは定義されます。 それは[RFC3471]で定義された既存の「λ」コード・ポイントを拡大します。 交通が送られるインタフェースかトンネルがG.709対応することのOptical Channel層のコード化を支持するとき、前者は発生しなければなりません。 非G.709の言いなりになっているLambda層のコード化に後者を使用するだけでよいです。 トランジットか出口ノード(GENERALIZED_LABEL_REQUEST物を含むPathメッセージを受け取る)が「ルート設定の問題/サポートされないコード化」指示でPathErrメッセージを発生させなければなりません、対応する入って来るインタフェースで要求されたLSP Encoding Typeを支持できないなら。
Papadimitriou Standards Track [Page 5] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[5ページ]RFC4328GMPLS
Consequently, the following additional code-points for the LSP Encoding Type are defined:
その結果、LSP Encoding Typeのための以下の追加コード・ポイントは定義されます:
Value Type
----- ----
12 G.709 ODUk (Digital Path)
13 G.709 Optical Channel
値のタイプ----- ---- 12 G.709 ODUk(デジタル経路)の13のG.709の光学チャンネル
Moreover, the code-point for the G.709 Optical Channel (OCh) layer will indicate the requested capability of an end-system to use the G.709 non-associated overhead (naOH), i.e., the OTM Overhead Signal (OOS) multiplexed into the OTM-n.m interface signal.
そのうえ、G.709 Optical Channel(OCh)層のためのコード・ポイントはエンドシステムがG.709の非関連しているオーバーヘッド(naOH)を使用する要求された能力を示すでしょう、すなわち、(OOS)が多重送信したOTM Overhead Signal、OTM-n.、m、インタフェース信号。
3.1.2. Switching Type
3.1.2. 切り換えタイプ
The Switching Type indicates the type of switching that should be performed at the termination of a particular link (see [RFC4202]).
Switching Typeは特定のリンクの終了のときに実行されるべきである切り換えのタイプを示します([RFC4202]を見てください)。
No additional Switching Type values are to be considered in order to accommodate G.709 switching types, because an ODUk switching (and thus LSPs) belongs to the TDM class, while an OCh switching (and thus LSPs) belong to the Lambda class (i.e., LSC).
どんな追加Switching Type値もG.709切り換えタイプに対応するために考えられないことです、ODUkの切り換え(そして、その結果、LSPs)がTDMのクラスに属すので、OChの切り換え(そして、その結果、LSPs)はLambdaのクラス(すなわち、LSC)に属しますが。
Intermediate and egress nodes MUST verify that the value indicated in the Switching Type field is supported on the corresponding incoming interface. If the requested value can not be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication.
中間介在物と出口ノードは、Switching Type分野で示された値が対応する入って来るインタフェースで支持されることを確かめなければなりません。 要求された値を支持できないなら、ノードは「ルート設定の問題/切り換えタイプ」指示でPathErrメッセージを発生させなければなりません。
3.1.3. Generalized-PID (G-PID)
3.1.3. 一般化されたPID(G-PID)
The G-PID (16 bits field), as defined in [RFC3471], identifies the payload carried by an LSP, i.e., an identifier of the client layer of that LSP. This identifier is used by the endpoints of the G.709 LSP.
[RFC3471]で定義されるG-PID(16ビットの分野)はLSP(すなわち、そのLSPのクライアント層に関する識別子)によって運ばれたペイロードを特定します。 この識別子はG.709 LSPの終点によって使用されます。
The G-PID can take one of the following values when the client payload is transported over the Digital Path layer, in addition to the payload identifiers defined in [RFC3471]:
クライアントペイロードがDigital Path層の上で輸送されるとき、G-PIDは以下の値の1つを取ることができます、[RFC3471]で定義されたペイロード識別子に加えて:
- CBRa: asynchronous Constant Bit Rate (i.e., mapping of STM-16/OC-
48, STM-64/OC-192 and STM-256/OC-768)
- CBRb: bit synchronous Constant Bit Rate (i.e., mapping of STM-
16/OC-48, STM-64/OC-192 and STM-256/OC-768)
- ATM: mapping at 2.5, 10 and 40 Gbps
- BSOT: non-specific client Bit Stream with Octet Timing (i.e.,
Mapping of 2.5, 10 and 40 Gbps Bit Stream)
- BSNT: non-specific client Bit Stream without Octet Timing (i.e.,
Mapping of 2.5, 10 and 40 Gbps Bit Stream)
- CBRa: 非同期なConstant Bit Rate(すなわち、STM-16/OC48、STM-64/OC-192、およびSTM-256/OC-768に関するマッピング)--、CBRb: ビットの同期Constant Bit Rate(すなわち、STM16/OC-48、STM-64/OC-192、およびSTM-256/OC-768に関するマッピング)--、ATM: 2.5、10、および40Gbpsのマッピング--、BSOT: Octet Timing(すなわち、2.5のMapping、10、および40Gbps Bit Stream)と特定されないクライアントBit Stream--、BSNT: Octet Timingのない特定されないクライアントBit Stream(すなわち、2.5に関するマッピング、10と40Gbpsビットストリーム)
Papadimitriou Standards Track [Page 6] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[6ページ]RFC4328GMPLS
- ODUk: transport of Digital Paths at 2.5, 10 and 40 Gbps - ESCON: Enterprise Systems Connection - FICON: Fiber Connection
- ODUk: 2.5、10歳のDigital Pathsと40Gbpsの輸送--、ESCON: エンタープライズシステム接続--、FICON: ファイバー接続
The G-PID can take one of the following values when the client payload is transported over the Optical Channel layer, in addition to the payload identifiers defined in [RFC3471]:
クライアントペイロードがOptical Channel層の上で輸送されるとき、G-PIDは以下の値の1つを取ることができます、[RFC3471]で定義されたペイロード識別子に加えて:
- CBR: Constant Bit Rate (i.e., mapping of STM-16/OC-48, STM-64/OC-
192 and STM-256/OC-768)
- OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps
- CBR: 一定のBit Rate(すなわち、STM-16/OC-48、STM-64/OC192、およびSTM-256/OC-768に関するマッピング)--、OTUk/OTUkV: 2.5、10、および40GbpsのDigitalセクションの輸送
Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are encapsulated through the Generic Framing Procedure (GFP), as described in ITU-T G.7041, dedicated G-PID values are defined.
また、イーサネットMAC/PHYやIP/PPPなどのクライアントペイロードがITU-T G.7041で説明されるようにGeneric Framing Procedure(GFP)を通して要約されるとき、ひたむきなG-PID値は定義されます。
In order to include pre-OTN developments, the G-PID field can take one of the values (currently defined in [RFC3471]) when the following client payloads are transported over a so-called lambda LSP:
以下のクライアントペイロードがいわゆるλLSPの上で輸送されるとき、プレOTN開発を含むように、G-PID分野は値(現在、[RFC3471]で定義される)の1つを取ることができます:
- Ethernet PHY (1 Gbps and 10 Gbps) - Fiber Channel
- イーサネットPHY(1Gbpsと10Gbps)--ファイバーチャネル
The following table summarizes the G-PID with respect to the LSP Encoding Type:
以下のテーブルはLSP Encoding Typeに関してG-PIDをまとめます:
Value G-PID Type LSP Encoding Type
----- ---------- -----------------
47 G.709 ODUj G.709 ODUk (with k > j)
48 G.709 OTUk(v) G.709 OCh
ODUk mapped into OTUk(v)
49 CBR/CBRa G.709 ODUk, G.709 OCh
50 CBRb G.709 ODUk
51 BSOT G.709 ODUk
52 BSNT G.709 ODUk
53 IP/PPP (GFP) G.709 ODUk (and SDH)
54 Ethernet MAC (framed GFP) G.709 ODUk (and SDH)
55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH)
56 ESCON G.709 ODUk, Lambda, Fiber
57 FICON G.709 ODUk, Lambda, Fiber
58 Fiber Channel G.709 ODUk, Lambda, Fiber
値のG-PIDはタイプをコード化するLSPをタイプします。----- ---------- ----------------- 47 G.709 ODUj G.709 ODUk(k>jと)48G.709 OTUk(v) G.709 OCh ODUkは49CBR/CBRa G.709 ODUkをOTUk(v)に写像しました、G.709 OCh50CBRb G.709 ODUk51BSOT G.709 ODUk52BSNT G.709 ODUk53IP/PPP(GFP)G.709 ODUk(そして、SDH)54イーサネットMAC(GFPを縁どっている)G.709 ODUk(そして、SDH)55イーサネットPHY(透明なGFP)G.709 ODUk(そして、SDH)56ESCON G.709 ODUk、Lambda、Fiber57FICON G.709 ODUk、Lambda、Fiber58Fiber Channel G.709 ODUk、Lambda、Fiber
Note: Values 49 and 50 include mapping of SDH.
以下に注意してください。 49と50が写像するのを含むSDHの値。
Papadimitriou Standards Track [Page 7] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[7ページ]RFC4328GMPLS
The following table summarizes the update of the G-PID values defined in [RFC3471]:
以下のテーブルは[RFC3471]で定義されたG-PID値のアップデートをまとめます:
Value G-PID Type LSP Encoding Type
----- ---------- -----------------
32 ATM Mapping SDH, G.709 ODUk
33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber
34 Sonet/SDH G.709 OCh, Lambda, Fiber
35 Reserved (SONET Dep.) G.709 OCh, Lambda, Fiber
値のG-PIDはタイプをコード化するLSPをタイプします。----- ---------- ----------------- 32 気圧マッピングSDH、G.709 ODUk33イーサネットPHY SDH、G.709 OCh、λ、ファイバー34Sonet/SDH G.709 OCh、λ、ファイバー35は(Sonet Dep)を予約しました。 G.709 OCh、λ、ファイバー
3.2. G.709 Traffic Parameters
3.2. G.709交通パラメタ
When G.709 Digital Path Layer or G.709 Optical Channel Layer is specified in the LSP Encoding Type field, the information referred to as technology dependent (or simply traffic parameters) is carried additionally to the one included in the Generalized Label Request.
G.709DigitalのPath LayerかG.709 Optical Channel LayerがLSP Encoding Type分野で指定されるとき、技術と依存していた状態で(または、単に交通パラメタ)呼ばれた情報はさらに、Generalized Label Requestにものを含んでいるまで運ばれます。
The G.709 traffic parameters are defined as follows:
G.709交通パラメタは以下の通り定義されます:
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 | Reserved | NMC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 信号タイプ| 予約されます。| NMC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NVC| 乗数(MT)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this frame, NMC stands for Number of Multiplexed Components, NVC for Number of Virtual Components, and MT for Multiplier. Each of these fields is tailored to support G.709 LSP requests.
このフレームでは、NMCはMultiplexed ComponentsのNumber、Virtual ComponentsのNumberのためのNVC、およびMultiplierのためのMTを表します。 それぞれのこれらの分野は、G.709 LSP要求を支持するために合わせます。
The RSVP-TE encoding of the G.709 traffic-parameters is detailed in Section 6.
G.709交通パラメタのRSVP-TEコード化はセクション6で詳細です。
3.2.1. Signal Type (ST)
3.2.1. 信号タイプ(ST)
This field (8 bits) indicates the type of G.709 Elementary Signal that comprises the requested LSP. The permitted values are:
この分野(8ビット)は要求されたLSPを包括するG.709 Elementary Signalのタイプを示します。 受入れられた値は以下の通りです。
Value Type
----- ----
0 Not significant
1 ODU1 (i.e., 2.5 Gbps)
2 ODU2 (i.e., 10 Gbps)
3 ODU3 (i.e., 40 Gbps)
4 Reserved (for future use)
値のタイプ----- ---- 0 重要な1ODU1(すなわち、2.5Gbps)の2ODU2(すなわち、10Gbps)3ODU3(すなわち、40Gbps)4Reservedでない(今後の使用のための)
Papadimitriou Standards Track [Page 8] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[8ページ]RFC4328GMPLS
5 Reserved (for future use)
6 OCh at 2.5 Gbps
7 OCh at 10 Gbps
8 OCh at 40 Gbps
9-255 Reserved (for future use)
5が2.5Gbpsで6OChを予約した、(今後の使用のために)10歳の7OCh、40Gbps9-255のReservedのGbps8OCh(今後の使用のための)
The value of the Signal Type field depends on LSP Encoding Type value defined in Section 3.1.1 and [RFC3471]:
Signal Type分野の値を3.1.1と[RFC3471]にセクションで定義されたLSP Encoding Type値に依存します:
- if the LSP Encoding Type value is the G.709 Digital Path layer,
then the valid values are the ODUk signals (k = 1, 2 or 3).
- if the LSP Encoding Type value is the G.709 Optical Channel
layer, then the valid values are the OCh at 2.5, 10, or 40 Gbps.
- if the LSP Encoding Type is "Lambda" (which includes the pre-OTN
Optical Channel layer) then the valid value is irrelevant (Signal
Type = 0).
- if the LSP Encoding Type is "Digital Wrapper", then the valid
value is irrelevant (Signal Type = 0).
- LSP Encoding Type値がG.709Digital Path層であるなら、有効値はODUk信号(k=1、2または3)です。 - LSP Encoding Type値がG.709 Optical Channel層であるなら、有効値は2.5、10、または40GbpsのOChです。 - LSP Encoding Typeが「λ」(プレOTN Optical Channel層を含んでいる)であるなら、有効値は無関係です(信号Type=0)。 - LSP Encoding Typeが「デジタル包装紙」であるなら、有効値は無関係です(信号Type=0)。
Several transforms can be sequentially applied on the Elementary Signal to build the Final Signal that is actually requested for the LSP. Each transform application is optional and must be ignored if zero; this does not include the Multiplier (MT), which cannot be zero and must be ignored if equal to one. Transforms must be applied strictly in the following order:
LSPのために実際に要求されているFinal Signalを造るためにいくつかの変換をElementary Signalに連続して適用できます。 ゼロであるならそれぞれの変換アプリケーションを任意であり、無視しなければなりません。 これをMultiplier(MT)を含まないで、1つと等しいなら、無視しなければなりません。(Multiplierはゼロであるはずがありません)。 以下のオーダーで厳密に変換を適用しなければなりません:
- First, virtual concatenation (by using the NVC field) can be
optionally applied directly on the Elementary Signal to form a
Composed Signal
- Second, a multiplication (by using the Multiplier field) can be
optionally applied, either directly on the Elementary Signal, or
on the virtually concatenated signal obtained from the first
phase. The resulting signal is referred to as Final Signal.
- まず最初に、Composed Signalを形成するために、任意に、仮想の連結(NVC分野を使用するのによる)を直接Elementary Signalに適用できます--2番目に、任意に、Elementary Signalの直接上、または、第1段階から入手された実際には連結された信号の上に乗法(Multiplier分野を使用するのによる)を適用できます。 結果として起こる信号はFinal Signalと呼ばれます。
3.2.2. Number of Multiplexed Components (NMC)
3.2.2. 多重送信されたコンポーネントの数(NMC)
The NMC field (16 bits) indicates the number of ODU tributary slots used by an ODUj when multiplexed into an ODUk (k > j) for the requested LSP. This field is not applicable when an ODUk is mapped into an OTUk and irrelevant at the Optical Channel layer. In both cases, it MUST be set to zero (NMC = 0) when sent and should be ignored when received.
NMC分野(16ビット)は要求されたLSPのためにODUk(k>j)に多重送信するとODUjが使用したODUの進貢しているスロットの数を示します。 ODUkがOTUkに写像されていてOptical Channel層で無関係であるときに、この分野は適切ではありません。 どちらの場合も、それを送ると(NMC=0)のゼロを合わせるように設定しなければならなくて、受け取ると、無視するべきです。
When applied at the Digital Path layer, in particular for ODU2 connections multiplexed into one ODU3 payload, the NMC field specifies the number of individual tributary slots (NMC = 4) that constitute the requested connection. These components are still processed within the context of a single connection entity. For all
特に1個のODU3ペイロードに多重送信されたODU2接続のためにDigital Path層に適用されると、NMC分野は要求された接続を構成する個々の進貢しているスロット(NMC=4)の数を指定します。 これらのコンポーネントは単独結合実体の文脈の中でまだ加工処理されています。 すべてのために
Papadimitriou Standards Track [Page 9] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[9ページ]RFC4328GMPLS
other currently defined multiplexing cases (see Section 2), the NMC field is set to 1.
他の現在定義されたマルチプレクシングケース(セクション2を見る)であり、NMC分野は1に設定されます。
3.2.3. Number of Virtual Components (NVC)
3.2.3. 仮想のコンポーネントの数(NVC)
The NVC field (16 bits) is dedicated to ODUk virtual concatenation (i.e., ODUk Inverse Multiplexing) purposes. It indicates the number of ODU1, ODU2, or ODU3 Elementary Signals that are requested to be virtually concatenated to form an ODUk-Xv signal. By definition, these signals MUST be of the same type.
NVC野原(16ビット)はODUkの仮想の連結(すなわち、ODUk Inverse Multiplexing)目的に捧げられます。 それはODUk-Xv信号を形成するために実際には連結されるよう要求されているODU1、ODU2、またはODU3 Elementary Signalsの数を示します。 定義上、同じタイプにはこれらの信号があるに違いありません。
This field is set to 0 (default value) to indicate that no virtual concatenation is requested.
0(デフォルト値)にこの分野が、どんな仮想の連結も要求されていないのを示すように設定されます。
Note that the current usage of this field only applies for G.709 ODUk LSPs, i.e., values greater than zero, are only acceptable for ODUk Signal Types. Therefore, it MUST be set to zero (NVC = 0), and should be ignored when received, when a G.709 OCh LSP is requested.
ODUk Signal Typesだけにおいて、すなわち、この分野の現在の用法がG.709 ODUk LSPsに申し込むだけであるというメモ、ゼロより大きい値は許容できます。 したがって、それを(NVC=0)のゼロを合わせるように設定しなければならなくて、受け取ると、無視するべきです、G.709 OCh LSPが要求されているとき。
3.2.4. Multiplier (MT)
3.2.4. 乗数(MT)
The Multiplier field (16 bits) indicates the number of identical Elementary Signals or Composed Signals that are requested for the LSP, i.e., that form the Final Signal. A Composed Signal is the resulting signal from the application of the NMC and NVC fields to an elementary Signal Type. GMPLS signaling currently implies that all the Composed Signals must be part of the same LSP.
Multiplier分野(16ビット)はFinal Signalを形成するすなわちLSPのために要求されている同じElementary SignalsかComposed Signalsの数を示します。 NMCとNVC分野の適用から基本のSignal TypeまでComposed Signalは結果として起こる信号です。 現在合図するGMPLSは、すべてのComposed Signalsが同じLSPの一部であるに違いないことを含意します。
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 message (see Section 6).
1つ(デフォルト値)にこの分野が、まさに信号の1つの例が要求されているのを示すように設定されます。 中間介在物と出口ノードは、LSPが設立されるノード自体とインタフェースが要求された乗数値を支えることができることを確かめなければなりません。 要求された値を支持できないなら、受信機ノードはPathErrメッセージを発生させなければなりません(セクション6を見てください)。
Zero is an invalid value for the MT field. If received, the node MUST generate a PathErr message (see Section 6).
ゼロはMT分野への無効の値です。 受け取るなら、ノードはPathErrメッセージを発生させなければなりません(セクション6を見てください)。
3.2.5. Reserved Fields
3.2.5. 予約された分野
The reserved fields (8 bits in row 1 and 32 bits in row 3) are dedicated for future use. Reserved bits SHOULD be set to zero when sent and MUST be ignored when received.
予約された野原(列1の8ビットと列3の32ビット)は今後の使用のために捧げられます。 予約されたビットSHOULDは送るとゼロに用意ができて、受け取ると、無視しなければなりません。
4. Generalized Label
4. 一般化されたラベル
This section describes the Generalized Label value space for Digital Paths and Optical Channels. The Generalized Label is defined in
このセクションはDigital PathsとOptical ChannelsのためにGeneralized Label値のスペースについて説明します。 Generalized Labelは中で定義されます。
Papadimitriou Standards Track [Page 10] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[10ページ]RFC4328GMPLS
[RFC3471]. The format of the corresponding RSVP-TE GENERALIZED_LABEL object is specified in [RFC3473] Section 2.3.
[RFC3471。] 対応するRSVP-TE GENERALIZED_LABEL物の形式は[RFC3473]セクション2.3で指定されます。
The label distribution rules detailed in Section 4.2 follow (when applicable) the ones defined in [RFC3946].
セクション4.2で詳細なラベル分配規則は[RFC3946]で定義されたものに続きます(適切であるときに)。
4.1. ODUk Label Space
4.1. ODUkラベルスペース
At the Digital Path layer (i.e., ODUk layers), G.709 defines three different client payload bit rates. An Optical Data Unit (ODU) frame has been defined for each of these bit rates. ODUk refers to the frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps), or 3 (for 40 Gbps).
Digital Path層(すなわち、ODUk層)では、G.709は3つの異なったクライアントペイロードビット伝送速度を定義します。 Optical Data Unit(ODU)フレームはそれぞれのこれらのビット伝送速度のために定義されました。 ODUkはkが1と等しいところの(2.5Gbpsのために)2(10Gbpsのための)、または3(40Gbpsのための)のビット伝送速度kでフレームについて言及します。
In addition to the support of ODUk mapping into OTUk, the G.709 label space supports the sub-levels of ODUk multiplexing. ODUk multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk (k > j), in particular:
OTUkへのODUkマッピングのサポートに加えて、G.709ラベルスペースはODUkマルチプレクシングのサブレベルを支持します。 ODUkマルチプレクシングはODUj(j=1、2)のマルチプレクシングをODUk(k>j)と特に呼びます:
- ODU1 into ODU2 multiplexing
- ODU1 into ODU3 multiplexing
- ODU2 into ODU3 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing
- ODU2マルチプレクシングへのODU1--ODU3へのODU2が多重送信して、多重送信するODU3へのODU1--ODU3マルチプレクシングへのODU1とODU2
More precisely, ODUj into ODUk multiplexing (k > j) is defined when an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e., an ODTUG constituted by ODU tributary slots) that is mapped into an OPUk. The resulting OPUk is mapped into an ODUk, and the ODUk is mapped into an OTUk.
OPUkに写像されるODUk Tributary Unit Group(すなわち、ODUの進貢しているスロットによって構成されたODTUG)にODUjを多重送信するとき、より正確に、(k>j)を多重送信するODUkへのODUjを定義します。 結果として起こるOPUkはODUkに写像されます、そして、ODUkはOTUkに写像されます。
Therefore, the label space structure is a tree whose root is an OTUk signal and whose leaves are the ODUj signals (k >= j) that can be transported via the tributary slots and switched between these slots. A G.709 Digital Path layer label identifies the exact position of a particular ODUj signal in an ODUk multiplexing structure.
したがって、ラベルスペース構造は根がOTUk信号であり、葉が進貢しているスロットを通して輸送して、これらのスロットの間に切り換えることができるODUj信号(k>はjと等しい)である木です。 G.709Digital Path層のラベルはODUkマルチプレクシング構造で特定のODUj信号の正確な位置を特定します。
The G.709 Digital Path Layer label or ODUk label has the following format:
G.709Digital Path LayerラベルかODUkラベルには、以下の形式があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | t3 | t2 |t1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| t3| t2|t1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved bits MUST be set to zero when sent and SHOULD be ignored when received.
予約されて、ビットは、送られたいつのゼロを合わせるかセットとSHOULDであるに違いありません。無視されて、いつが受信されたかということになってください。
Papadimitriou Standards Track [Page 11] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[11ページ]RFC4328GMPLS
The specification of the fields t1, t2, and t3 self-consistently characterizes the ODUk label space. The value space for the t1, t2, and t3 fields is defined as follows:
分野t1、t2、および一貫してt3自己の仕様はODUkラベルスペースを特徴付けます。 t1、t2、およびt3分野への値のスペースは以下の通り定義されます:
1. t1 (1-bit):
- t1=1 indicates an ODU1 signal.
- t1 is not significant for the other ODUk signal types (i.e.,
t1 value MUST be set to 0 and ignored).
1. t1(1ビット): - t1=1はODU1信号を示します。 - 他のODUk信号タイプには、t1は重要ではありません(すなわち、t1値を0に設定されて、無視しなければなりません)。
2. t2 (3-bit):
- t2=1 indicates an ODU2 signal that is not further sub-
divided.
- t2=[2..5] indicates the tributary slot (t2th-2) used by the
ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2).
- t2 is not significant for an ODU3 (i.e., t2 value MUST be
set to 0 and ignored).
2. t2(3ビット): - t2=1はさらにサブ分割されなかったODU2信号を示します。 - t2=[2 .5]はODU2(OPU2を通した)に写像されたODTUG2でODU1によって使用された進貢しているスロット(t第2-2)を示します。 - ODU3には、t2は重要ではありません(すなわち、t2値を0に設定されて、無視しなければなりません)。
3. t3 (6-bit):
- t3=1 indicates an ODU3 signal that is not further sub-
divided.
- t3=[2..17] indicates the tributary slot (t3th-1) used by the
ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3).
- t3=[18..33] indicates the tributary slot (t3th-17) used by
the ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3).
3. t3(6ビット): - t3=1はさらにサブ分割されなかったODU3信号を示します。 - t3=[2 .17]はODU3(OPU3を通した)に写像されたODTUG3でODU1によって使用された進貢しているスロット(t第3-1)を示します。 - t3=[18 .33]はODU3(OPU3を通した)に写像されたODTUG3でODU2によって使用された進貢しているスロット(t第3-17)を示します。
Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required to identify the 4 tributary slots used by the ODU2; these tributary time slots have to be allocated in ascending order.
以下に注意してください。 ODU3マルチプレクシングへのODU2の場合には、4個のラベルがODU2によって使用された4つの進貢しているスロットを特定するのに必要です。 昇順にこれらの進貢している時間帯を割り当てなければなりません。
If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j > i), the corresponding ODUk signal ODU[i] is directly mapped into the corresponding OTUk signal (k=i). This is referred to as the mapping of an ODUk signal into an OTUk of the same order. Therefore, the numbering starts at 1; zero is used to indicate a non-significant field. A label field equal to zero is an invalid value.
ラベルサブ分野値のt[i]が1(i、1、2またはj=3)とt[j]=0(j>i)と等しいなら、対応するODUk信号ODU[i]は直接対応するOTUk信号(k=i)に写像されます。 これは同次のOTUkへのODUk信号に関するマッピングと呼ばれます。 したがって、付番は1時に始まります。 ゼロは、非重要な分野を示すのに使用されます。 ゼロに合わせるために等しいラベルフィールドは無効の値です。
Examples:
例:
- t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1
- t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2
- t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3
- t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot
of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2
- t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot
of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3
- t3=0、t2=0、t1=1はOTU1に写像されたODU1を示します--t3=0、t2=1、t1=0はOTU2に写像されたODU2を示します--t3=1、t2=0、t1=0はOTU3に写像されたODU3を示します--t3=0、t2=3、t1=0はOTU2に写像されたODU2(OPU2を通した)に写像されたODTUG2の2番目の進貢しているスロットでODU1を示します--t3=5、t2=0、t1=0はOTU3に写像されたODU3(OPU3を通した)に写像されたODTUG3の4番目の進貢しているスロットでODU1を示します。
Papadimitriou Standards Track [Page 12] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[12ページ]RFC4328GMPLS
4.2. Label Distribution Rules
4.2. ラベル分配規則
In case of ODUk in OTUk mapping, only one label can appear in the Generalized Label. The unique label is encoded as a single 32-bit label value (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2).
OTUkマッピングのODUkの場合には、1個のラベルしかGeneralized Labelに現れることができません。 ユニークなラベルはGENERALIZED_LABEL物のただ一つの32ビットのラベル値(セクション4.1で定義されるように)としてコード化されます(クラスヌムは16、C-タイプ=2と等しいです)。
In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered list of the labels in the multiplex is given (this list can be restricted to only one label when NMC = 1). Each label indicates a component (ODUj tributary slot) of the multiplexed signal. The order of the labels must reflect the order of the ODUj into the multiplex (not the physical order of tributary slots). This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2).
ODUk(k>j)マルチプレクシングにおけるODUjの場合には、マルチプレックスのラベルの明白な規則正しいリストを与えます(NMC=1であるのに、このリストは1個のラベルだけに制限される場合があります)。 各ラベルは多重送信された信号の部品(ODUjの進貢しているスロット)を示します。 ラベルの注文はマルチプレックス(進貢しているスロットの物理的な注文でない)にODUjの注文を反映しなければなりません。 ラベルのこの規則正しいリストはGENERALIZED_LABEL物の32ビットのラベル値(セクション4.1で定義されるように)の系列としてコード化されます(クラスヌムは16、C-タイプ=2と等しいです)。
In case of ODUk virtual concatenation, the explicit ordered list of all labels in the concatenation is given. Each label indicates a component of the virtually concatenated signal. The order of the labels must reflect the order of the ODUk to concatenate (not the physical order of time-slots). This representation limits virtual concatenation to remain within a single (component) link. In case of multiplexed virtually concatenated signals, the first set of labels indicates the components (ODUj tributary slots) of the first virtually concatenated signal, the second set of labels indicates the components (ODUj tributary slots) of the second virtually concatenated signal, and so on. This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of ODUk virtual concatenation, the number of label values is determined by the NVC value. Multiplexed ODUk virtual concatenation additionally uses the NMC value to determine the number of labels per set (equal in size).
ODUkの仮想の連結の場合には、連結におけるすべてのラベルの明白な規則正しいリストを与えます。 各ラベルは実際には連結された信号の部品を示します。 ラベルの注文はODUkが(時間帯の物理的な注文でない)を連結する命令を反映しなければなりません。 この表現は、単一の(コンポーネント)リンクに残るために仮想の連結を制限します。 多重送信された実際には連結された信号の場合には、ラベルの第一セットは最初の実際には連結された信号の部品(ODUjの進貢しているスロット)を示して、2番目のセットのラベルは2番目の実際には連結された信号の部品(ODUjの進貢しているスロット)などを示します。 ラベルのこの規則正しいリストはGENERALIZED_LABEL物の32ビットのラベル値(セクション4.1で定義されるように)の系列としてコード化されます(クラスヌムは16、C-タイプ=2と等しいです)。 ODUkの仮想の連結の場合には、ラベル値の数はNVC値によって測定されます。 多重送信されたODUk仮想の連結は、セット(サイズで等しい)あたりのラベルの数を測定するのにさらに、NMC値を使用します。
In case of multiplication (i.e., when using the MT field), the explicit ordered list of all labels taking part in the composed signal is given. The above representation limits multiplication to remain within a single (component) link. In case of multiplication of multiplexed virtually concatenated signals, the first set of labels indicates the components of the first multiplexed virtually concatenated signal, the second set of labels indicates components of the second multiplexed virtually concatenated signal, and so on. This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of multiplication of (equal) ODUk virtual concatenated signals, the number of label values per signal is determined by the NVC value. Multiplication of multiplexed
乗法(すなわち、MT分野を使用するとき)の場合には、落ち着いた信号に参加するすべてのラベルの明白な規則正しいリストを与えます。 上の表現は、単一の(コンポーネント)リンクに残るために乗法を制限します。 多重送信された実際には連結された信号の乗法の場合には、ラベルの第一セットは最初の多重送信された実際には連結された信号の部品を示して、2番目のセットのラベルは2番目の多重送信された実際には連結された信号の部品などを示します。 ラベルのこの規則正しいリストはGENERALIZED_LABEL物の32ビットのラベル値(セクション4.1で定義されるように)の系列としてコード化されます(クラスヌムは16、C-タイプ=2と等しいです)。 (等しい)ODUkの仮想の連結された信号の乗法の場合には、1信号あたりのラベル値の数はNVC値によって測定されます。 多重送信されることの乗法
Papadimitriou Standards Track [Page 13] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[13ページ]RFC4328GMPLS
(equal) ODUk virtual concatenation additionally uses the NMC value to determine the number of labels per set (equal in size).
(等しい)のODUk仮想の連結は、セット(サイズで等しい)あたりのラベルの数を測定するのにさらに、NMC値を使用します。
4.3. Optical Channel Label Space
4.3. 光学チャンネルラベルスペース
At the Optical Channel layer, the label space must be consistently defined as a flat space whose values reflect the local assignment of OCh identifiers that correspond to the OTM-n.m sub-interface signals (m = 1, 2 or 3). Note that these identifiers do not cover OChr because the corresponding Connection Function (OChr-CF) between OTM- nr.m/OTM-0r.m is not defined in [ITUT-G798].
Optical Channel層では、一貫して値がそれが相当するOCh識別子のローカルの課題を反映するa平坦なスペースとラベルスペースを定義しなければならない、OTM-n.、m、サブインタフェース信号(1、2またはm=3)。 OTM- nr.m/OTM-0r.mの間の対応するConnection Function(OChr-CF)が[ITUT-G798]で定義されないのでこれらの識別子がOChrを覆わないことに注意してください。
The OCh label space values are defined by either absolute values (i.e., channel identifiers or Channel ID, also referred to as wavelength identifiers) or relative values (channel spacing, also referred to as inter-wavelength spacing). The latter is strictly confined to a per-port label space, whereas the former could be defined as a local or a global (per node) label space. Such an OCh label space is applicable to both OTN Optical Channel layer and pre- OTN Optical Channel layer.
絶対値(また、波長識別子と呼ばれたすなわち、チャンネル識別子かChannel ID)か相対的価値(また、相互波長スペースと呼ばれたチャンネルスペース)のどちらかによってOChラベルスペース値は定義されます。 後者は厳密に1ポートあたり1つのラベルスペースに閉じ込められましたが、地方のスペースかグローバルな(1ノードあたりの)ラベルスペースと前者を定義できました。 そのようなOChラベルスペースはOTN Optical Channelが層にする両方に適切です、そして、プレOTN Optical Channelは層にします。
Optical Channel label encoding (and distribution) rules are defined in [RFC3471]. They MUST be used for the Upstream Label, the Suggested Label, and the Generalized Label.
光学Channelラベルコード化(そして、分配)規則は[RFC3471]で定義されます。 Upstream Label、Suggested Label、およびGeneralized Labelにそれらを使用しなければなりません。
5. Examples
5. 例
The following examples are given in order to illustrate the processing described in the previous sections of this document.
以下の例は、このドキュメントの前項で説明された処理を例証するために出されます。
1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is
directly transported in an OTU1 (OTU2 or OTU3), the upstream node
requests results simply in an ODU1 (ODU2 or ODU3) signal request.
1. 以下を写像するOTUkのODUk 1つのODU1(ODU2かODU3)信号がOTU1(OTU2かOTU3)で直接輸送されるとき、上流のノードは単にODU1(ODU2かODU3)信号要求における結果を要求します。
In such conditions, the downstream node has to return a unique
label because the ODU1 (ODU2 or ODU3) is directly mapped into the
corresponding OTU1 (OTU2 or OTU3). Because a single ODUk signal
is requested (Signal Type = 1, 2 or 3), the downstream node has to
return a single ODUk label, which can be, for instance, one of the
following when the Signal Type = 1:
そのような状態で、ODU1(ODU2かODU3)が直接対応するOTU1(OTU2かOTU3)に写像されるので、川下のノードはユニークなラベルを返さなければなりません。 ただ一つのODUk信号が要求されているので(1、2または信号Type=3)、川下のノードは単一のODUkラベルを返さなければなりません:(例えば、Signal Type=1であるのに、ラベルは以下の1つであるかもしれません)。
- t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1
- t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2
- t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3
- t3=0、t2=0、独身のODU1を示すt1=1がOTU1(t3=0、t2=1、OTU2に写像された独身のODU2を示すt1=0)にt3=1を写像しました、t2=0、t1=0がOTU3に写像された独身のODU3を示して
2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed
into the payload of a structured ODU2 (or ODU3), the upstream node
requests results simply in an ODU1 signal request.
2. 以下を多重送信する(k>1)ODUkへのODU1 構造化されたODU2(または、ODU3)のペイロードに1ODU1を多重送信するとき、上流のノードは単にODU1信号要求における結果を要求します。
Papadimitriou Standards Track [Page 14] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[14ページ]RFC4328GMPLS
In such conditions, the downstream node has to return a unique
label because the ODU1 is multiplexed into one ODTUG2 (or ODTUG3).
The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or
OPU3) and then mapped into the corresponding OTU2 (or OTU3).
Because a single ODU1 multiplexed signal is requested (Signal Type
= 1 and NMC = 1), the downstream node has to return a single ODU1
label, which can take, for instance, one of the following values:
そのような状態で、川下のノードは、1ODTUG2(または、ODTUG3)にODU1を多重送信するので、ユニークなラベルを返さなければなりません。 後者は、次に、OPU2(または、OPU3)を通してODU2(または、ODU3)に写像されて、次に、対応するOTU2(または、OTU3)に写像されます。 独身のODU1が多重送信したので、信号は要求されていて(信号Typeは1とNMC=1と等しいです)、川下のノードは例えば、取ることができる単一のODU1ラベルを返さなければなりません、以下の値の1つ:
- t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2
- t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3
- t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3
- t3=0、t2=4、t1=0はODTUG2の第3TSでODU1を示します--t3=2、t2=0、t1=0はODTUG3の最初のTSでODU1を示します--t3=7、t2=0、t1=0はODTUG3の第6TSでODU1を示します。
3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is
multiplexed into the payload of a structured ODU3, the upstream
node requests results simply in an ODU2 signal request.
3. 以下を多重送信するODU3へのODU2 1不統一なODU2を構造化されたODU3のペイロードに多重送信するとき、上流のノードは単にODU2信号要求における結果を要求します。
In such conditions, the downstream node has to return four labels
since the ODU2 is multiplexed into one ODTUG3. The latter is
mapped into an ODU3 (via OPU3) and then mapped into an OTU3.
Since an ODU2 multiplexed signal is requested (Signal Type = 2,
and NMC = 4), the downstream node has to return four ODU labels
which can take for instance the following values:
そのような状態で、川下のノードは、1ODTUG3にODU2を多重送信するので、4個のラベルを返さなければなりません。 後者は、ODU3(OPU3を通した)に写像されて、次に、OTU3に写像されます。 ODU2が多重送信したので、信号は要求されていて(信号Typeは2、およびNMC=4と等しいです)、川下のノードは例えば以下の値を取ることができる4個のODUラベルを返さなければなりません:
- t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3)
- t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3)
- t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3)
- t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3)
- t3=18、t2=0、t1=0(最初に、ODTUG3の最初のTSのODU2の一部)--t3=22、t2=0、t1=0(ODTUG3の第5TSのODU2の第二部)--t3=23、t2=0、t1=0(ODTUG3の第6TSのODU2の3番目の一部)--t3=26、t2=0、t1=0(ODTUG3の第9TSのODU2の4番目の一部)
4. When a single OCh signal of 40 Gbps is requested (Signal Type =
8), the downstream node must return a single wavelength label as
specified in [RFC3471].
4. 40Gbpsのただ一つのOCh信号が要求されているとき(信号Type=8)、川下のノードは[RFC3471]の指定されるとしての単一の波長ラベルを返さなければなりません。
5. When requesting multiple ODUk LSP (i.e., with a multiplier (MT)
value > 1), an explicit list of labels is returned to the
requestor node.
5. 複数のODUk LSP(すなわち、乗数(MT)値の>1と)を要求するとき、ラベルの明白なリストを要請者ノードに返します。
When the downstream node receives a request for a 4 x ODU1 signal
(Signal Type = 1, NMC = 1 and MT = 4) multiplexed into an ODU3, it
returns an ordered list of four labels to the upstream node: the
first ODU1 label corresponds to the first signal of the LSP, the
second ODU1 label corresponds to the second signal of the LSP,
etc. For instance, the corresponding labels can take the
following values:
川下のノードがODU3に多重送信された4x ODU1信号(信号Typeは1、NMC=1、およびMT=4と等しい)に関する要求を受け取るとき、4個のラベルの規則正しいリストを上流のノードに返します: 最初のODU1ラベルはLSPの最初の信号に対応している、2番目のODU1ラベルはLSPに関する二次信号などに対応しています。 例えば、対応するラベルは以下の値を取ることができます:
- First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3)
- Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3)
- Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3)
- Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3)
- 最初のODU1: t3=2、t2=0、t1=0(最初に、ODTUG3のTSの)--第2ODU1: t3=10、t2=0、t1=0(ODTUG3の第9TSの)--第3ODU1: t3=7、t2=0、t1=0(ODTUG3の第6TSの)--第4ODU1: t3=6、t2=0、t1=0(ODTUG3の第5TSの)
Papadimitriou Standards Track [Page 15] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[15ページ]RFC4328GMPLS
6. RSVP-TE Signaling Protocol Extensions
6. RSVP-Teシグナリングプロトコル拡大
This section specifies the [RFC3473] protocol extensions needed to accommodate G.709 traffic parameters.
このセクションはG.709交通パラメタに対応するのに必要である[RFC3473]プロトコル拡大を指定します。
The G.709 traffic parameters are carried in the G.709 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 3.2. The objects have the following class and type for G.709:
G.709交通パラメタはG.709 SENDER_TSPECとFLOWSPEC物で運ばれます。 同じ形式はSENDER_TSPEC物とFLOWSPEC物に使用されます。 物の内容は上でセクション3.2で定義されます。 物は、以下のクラスを持って、G.709のためにタイプされます:
- G.709 SENDER_TSPEC Object: Class = 12, C-Type = 5 - G.709 FLOWSPEC Object: Class = 9, C-Type = 5
- G.709送付者_TSPECは反対します: クラスは12、C-タイプ=5と等しいです--G.709 FLOWSPECは反対します: クラスは9、C-タイプ=5と等しいです。
There is no Adspec associated with the G.709 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].
G.709 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, NMC, and NVC values (as defined in Section 3.2). 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が設立されるインタフェースが要求されたSignal Type、NMC、およびNVC値を支えることができることを確かめなければなりません(セクション3.2で定義されるように)。 要求された値を支持できないなら、受信機ノードは「交通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]を見てください)。
7. Security Considerations
7. セキュリティ問題
This document introduces no new security considerations to [RFC3473].
このドキュメントはどんな新しいセキュリティ問題も[RFC3473]に紹介しません。
8. IANA Considerations
8. IANA問題
Two values have been defined by IANA for this document:
2つの値がこのドキュメントのためにIANAによって定義されました:
Two RSVP C-Types in registry:
登録の2つのRSVP C-タイプ:
http://www.iana.org/assignments/rsvp-parameters
http://www.iana.org/assignments/rsvp-parameters
Papadimitriou Standards Track [Page 16] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[16ページ]RFC4328GMPLS
- A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5 - see
Section 6.
- G.709 SENDER_TSPEC物: クラスは12、C-タイプ=5と等しいです--セクション6を見てください。
- A G.709 FLOWSPEC object: Class = 9, C-Type = 5 - see
Section 6.
- G.709 FLOWSPEC物: クラスは9、C-タイプ=5と等しいです--セクション6を見てください。
IANA will also track the code-point spaces extended and/or updated by this document. For this purpose, the following new registry entries have been added in the newly requested registry entry: http://www.iana.org/assignments/gmpls-sig-parameters
また、IANAはこのドキュメントによって広げられる、そして/または、アップデートされたコード・ポイント空間を追跡するでしょう。 このために、以下の新しい登録エントリーは新たに要求された登録エントリーで加えられます: http://www.iana.org/assignments/gmpls-sig-parameters
- LSP Encoding Type:
Name: LSP Encoding Type
Format: 8-bit number
Values:
[1..11] defined in [RFC3471]
12 defined in Section 3.1.1
13 defined in Section 3.1.1
Allocation Policy:
[0..239] Assigned by IANA via IETF Standards Track RFC
Action.
[240..255] Assigned temporarily for Experimental Usage.
These will not be registered with IANA
- タイプをコード化するLSP: 以下を命名してください。 タイプをコード化するLSPが以下をフォーマットします。 8ビットの数のValues: [1 .11] セクション3.1.1Allocation Policyで定義されたセクション3.1.1 13で定義された[RFC3471]12で定義される: [0 .239] IETF Standards Track RFC Actionを通してIANAによって割り当てられます。 [240 .255] Experimental Usageのために一時割り当てられます。 これらはIANAに登録されないでしょう。
- Switching Type:
Name: Switching Type
Format: 8-bit number
Values: defined in [RFC3471]
Allocation Policy:
[0..255] Assigned by IANA via IETF Standards Track RFC
Action.
- 切り換えタイプ: 以下を命名してください。 切り換えタイプ形式: 8ビットの数のValues: [RFC3471]配分Policyで定義される: [0 .255] IETF Standards Track RFC Actionを通してIANAによって割り当てられます。
- Generalized PID (G-PID):
Name: G-PID
Format: 16-bit number
Values:
[0..31] defined in [RFC3471]
[32..35] defined in [RFC3471] and updated by Section
3.1.3
[36..46] defined in [RFC3471]
[47..58] defined in Section 3.1.3
Allocation Policy:
[0..31743] Assigned by IANA via IETF Standards Track RFC
Action.
[31744..32767] Assigned temporarily for Experimental Usage
- 一般化されたPID(G-PID): 以下を命名してください。 G-PID形式: 16ビットの数のValues: [0 .31] セクション3.1.3Allocation Policyで定義された[RFC3471][47 .58]で定義されていた状態で[RFC3471]で定義されて、セクション3.1.3[36 .46]アップデートされた[RFC3471][32 .35]で定義される: [0 .31743] IETF Standards Track RFC Actionを通してIANAによって割り当てられます。 Experimental Usageのために一時割り当てられます[31744 .32767]。
Papadimitriou Standards Track [Page 17] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[17ページ]RFC4328GMPLS
[32768..65535] Not assigned. Before any assignments can be
made in this range, there MUST be a Standards
Track RFC that specifies IANA Considerations
that covers the range being assigned.
[32768 .65535] 割り当てられません。 この範囲でどんな課題もすることができる前に、割り当てられる範囲をカバーするIANA Considerationsを指定するStandards Track RFCがあるに違いありません。
Note: per [RFC3471], Section 3.1.1, standard Ethertype values are used as G-PIDs for packet and Ethernet LSPs.
以下に注意してください。 [RFC3471]に従って、セクション3.1はパケットとイーサネットLSPsにG-PIDsとして使用されます.1、標準のEthertypeが、評価する。
9. Acknowledgements
9. 承認
The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot, Massimo Canali, Germano Gasparini, and Fong Liaw for their constructive comments and inputs as well as James Fu, Siva Sankaranarayanan, and Yangguang Xu for their useful feedback. Many thanks to Adrian Farrel for having thoroughly reviewed this document.
作者がジェームス・フーと同様に彼らの建設的なコメントと入力についてジーン-ループ川のFerrant、マチューGarnot、マッシモ・カナリ、Germanoガスパリーニ、およびフォンLiawに感謝したがっていて、シバがサンカラナラヤナンであり、Yangguangはそれらの役に立つフィードバックのためのシューです。 エードリアン・ファレルにこのドキュメントを徹底的に再検討してくださいといってくださってありがとうございますこと。
This document incorporates (upon agreement) material and ideas from a work in progress, "Common Label and Label Request Specification for Automatic Switched Transport Network", by Zhi Lin.
このドキュメントは処理中の作業、「一般的なラベルとラベルは自動切り換えられた転送ネットワークのための仕様を要求すること」から材料と考えを組み込みます(協定のときに)、Zhiリンで。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[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月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、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月。
[RFC3946] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 3946, October
2004.
[RFC3946]マニー(E.とD.Papadimitriou)は、「同期式光通信網(Sonet)と同期デジタルハイアラーキ(SDH)コントロールのためのマルチプロトコルラベルの切り換え(GMPLS)拡大を一般化しました」、RFC3946、2004年10月。
Papadimitriou Standards Track [Page 18] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[18ページ]RFC4328GMPLS
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4202, September 2005.
[RFC4202] エドKompella、K.、エドY.Rekhter、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)を支持して拡大を発送すること」でのRFC4202(2005年9月)。
10.2. Informative References
10.2. 有益な参照
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] マニー、E.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)構造」、RFC3945、2004年10月。
For information on the availability of the following documents, please see http://www.itu.int
以下のドキュメントの有用性の情報に関しては、 http://www.itu.int を見てください。
[ITUT-G709] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation (and Amendment 1), February
2001 (October 2001).
[ITUT-G709]ITU-T、「光学転送ネットワークのためのインタフェース(OTN)」、G.709推薦(そして、修正1)、2001(2001年10月)年2月。
[ITUT-G798] ITU-T, "Characteristics of Optical Transport Network
Hierarchy Equipment Functional Blocks," G.798
Recommendation, October 2001.
[ITUT-G798]ITU-T、「光学転送ネットワーク階層構造設備機能ブロックの特性」、G.798推薦、2001年10月。
11. Contributors
11. 貢献者
Alberto Bellato (Alcatel) Via Trento 30, I-20059 Vimercate, Italy EMail: alberto.bellato@alcatel.it
トレント30、I-20059 Vimercate、イタリア経由でアルベルトBellato(アルカテル)はメールします: alberto.bellato@alcatel.it
Sudheer Dharanikota (Consult) EMail: sudheer@ieee.org
Sudheer Dharanikota(相談する)はメールします: sudheer@ieee.org
Michele Fontana (Alcatel) Via Trento 30, I-20059 Vimercate, Italy EMail: michele.fontana@alcatel.it
トレント30を通したミシェルフォンタナ(アルカテル)、I-20059 Vimercate、イタリアはメールされます: michele.fontana@alcatel.it
Nasir Ghani (Sorrento Networks) 9990 Mesa Rim Road, San Diego, CA 92121, USA EMail: nghani@sorrentonet.com
ナーシルGhani(ソレントネットワーク)9990メサ縁の道路、サンディエゴ、カリフォルニア 92121、米国はメールされます: nghani@sorrentonet.com
Gert Grammel (Alcatel) Lorenzstrasse, 10, 70435 Stuttgart, Germany EMail: gert.grammel@alcatel.de
ゲルトGrammel(アルカテル)Lorenzstrasse、10、70435シュツットガルト(ドイツ)メール: gert.grammel@alcatel.de
Papadimitriou Standards Track [Page 19] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[19ページ]RFC4328GMPLS
Dan Guo (Turin Networks) 1415 N. McDowell Blvd, Petaluma, CA 94954, USA EMail: dguo@turinnetworks.com
ダン・クオ(トリノネットワーク)1415N.マクドウェルBlvd、ペタルマ、カリフォルニア 94954、米国はメールされます: dguo@turinnetworks.com
Juergen Heiles (Siemens) Hofmannstr. 51, D-81379 Munich, Germany EMail: juergen.heiles@siemens.com
ユルゲンHeiles(シーメンス)Hofmannstr。 51 D-81379ミュンヘン(ドイツ)はメールされます: juergen.heiles@siemens.com
Jim Jones (Alcatel) 3400 W. Plano Parkway, Plano, TX 75075, USA EMail: jim.d.jones@alcatel.com
プラノパークウェイ、ジムジョーンズ(アルカテル)3400W.プラノ、テキサス 75075、米国はメールされます: jim.d.jones@alcatel.com
Zhi-Wei Lin (Lucent) 101 Crawfords Corner Rd, Rm 3C-512 Holmdel, New Jersey 07733-3030, USA EMail: zwlin@lucent.com
Zhi-ウェイ・リン(透明な)101Crawfordsが追い詰める、Rm3C512Holmdel、ニュージャージー07733-3030(米国)は以下を第メールします。 zwlin@lucent.com
Eric Mannie (Consult) EMail: eric_mannie@hotmail.com
エリック・マニー(相談する)EMail: eric_mannie@hotmail.com
Maarten Vissers (Alcatel) Lorenzstrasse, 10, 70435 Stuttgart, Germany EMail: maarten.vissers@alcalel.de
Maarten Vissers(アルカテル)Lorenzstrasse、10、70435シュツットガルト(ドイツ)メール: maarten.vissers@alcalel.de
Yong Xue (WorldCom) 22001 Loudoun County Parkway, Ashburn, VA 20147, USA EMail: yong.xue@wcom.com
ヤング・シュー(ワールドコム)22001LoudounカウンティーのParkway、Ashburn、ヴァージニア 20147、米国はメールされます: yong.xue@wcom.com
Papadimitriou Standards Track [Page 20] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[20ページ]RFC4328GMPLS
Appendix A. Abbreviations
付録A.略語
BSNT Bit Stream without Octet Timing BSOT Bit Stream with Octet Timing CBR Constant Bit Rate ESCON Enterprise Systems Connection FC Fiber Channel FEC Forward Error Correction FICON Fiber Connection FSC Fiber Switch Capable GCC General Communication Channel GFP Generic Framing Procedure LSC Lambda Switch Capable LSP Label Switched Path MS Multiplex Section naOH non-associated Overhead NMC Number of Multiplexed Components NVC Number of Virtual Components OCC Optical Channel Carrier OCG Optical Carrier Group OCh Optical Channel (with full functionality) OChr Optical Channel (with reduced functionality) ODTUG Optical Date Tributary Unit Group ODU Optical Channel Data Unit OH Overhead OMS Optical Multiplex Section OMU Optical Multiplex Unit OOS OTM Overhead Signal OPS Optical Physical Section OPU Optical Channel Payload Unit OSC Optical Supervisory Channel OTH Optical Transport Hierarchy OTM Optical Transport Module OTN Optical Transport Network OTS Optical Transmission Section OTU Optical Channel Transport Unit OTUkV Functionally Standardized OTUk PPP Point to Point Protocol PSC Packet Switch Capable RES Reserved RS Regenerator Section TTI Trail Trace Identifier TDM Time Division Multiplex
Virtual Components OCC Optical Channel Carrier OCG Optical Carrier GroupのMultiplexed Components NVC NumberのOctet Timing CBR Constant Bit Rate ESCONエンタープライズSystems Connection FC Fiber Channel FEC Forward Error Correction FICON Fiber Connection FSC Fiber Switch Capable GCC司令官のMSのMultiplexのセクションのnaOHの非関連しているCommunication Channel GFP Generic Framing Procedure LSC Lambda Switch Capable LSP Label Switched Path Overhead NMC NumberとOctet Timing BSOT Bit StreamのないBSNT Bit Stream; OCh Optical Channel(完全な機能性がある)OChr Optical Channel(減少している機能性がある)ODTUG Optical Date Tributary Unit Group ODU Optical Channel Data Unit OH Overhead OMS Optical MultiplexセクションOMU Optical Multiplex Unit OOS OTM Overhead Signal OPS Optical PhysicalセクションOPU Optical Channel有効搭載量Unit OSC Optical Supervisory Channel OTH Optical Transport Hierarchy OTM Optical Transport Module OTN Optical Transport Network OTS Optical TransmissionセクションOTU Optical Channel Transport Unit OTUkVはできる予約されたOTUkのTTI道の跡の識別子TDM pppポイント・ツー・ポイントプロトコルPSCパケット交換機RES RS再生器セクション時分割多重を機能上標準化しました。
Papadimitriou Standards Track [Page 21] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[21ページ]RFC4328GMPLS
Appendix B. G.709 Indexes
付録B.G.709インデックス
- Index k: The index "k" is used to represent a supported bit rate and the different versions of OPUk, ODUk and OTUk. k=1 represents an approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s and k = 4 an approximate bit rate of 160 Gbit/s (under definition). The exact bit-rate values are in kbits/s:
- インデックスk: k=2は、インデックス「k」が支持されたビット伝送速度を表すのに使用されて、OPUk、ODUk、およびOTUk. k=1の異なった見解が2.5Gbit/sの大体のビット伝送速度を表すと10Gbit/s、k=3の大体のビット伝送速度に40Gbit/sとk=4の大体のビット伝送速度に160Gbit/s(定義中の)の大体のビット伝送速度に表します。 正確なビット伝送速度値がkbits/sにあります:
. OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322
. OPU: k=1: 2 488 320.000、k=2: 9 995 276.962、k=3: 40 150 519.322
. ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983
. ODU: k=1: 2 498 775.126、k=2: 10 037 273.924、k=3: 40 319 218.983
. OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559
. OTU: k=1: 2 666 057.143、k=2: 10 709 225.316、k=3: 43 018 413.559
- Index m: The index "m" is used to represent the bit rate or set of bit rates supported on the interface. This is a one or more digit "k", where each "k" represents a particular bit rate. The valid values for m are (1, 2, 3, 12, 23, 123).
- mに索引をつけてください: インデックス「m」は、インタフェースで支持されたビット伝送速度のビット伝送速度かセットを表すのに使用されます。 これは各「k」が特定のビット伝送速度を表す複数のケタ「k」です。 m有効値は(1、2、3、12、23、123)です。
- Index n: The index "n" is used to represent the order of the OTM, OTS, OMS, OPS, OCG and OMU. This index represents the maximum number of wavelengths that can be supported at the lowest bit rate supported on the wavelength. It is possible that a reduced number of higher bit rate wavelengths are supported. The case n=0 represents a single channel without a specific wavelength assigned to the channel.
- インデックスn: インデックス「n」は、OTM、OTS、OMS、OPS、OCG、およびOMUの注文を表すのに使用されます。 このインデックスは波長で支持される中で最も低いビット伝送速度で支持できる波長の最大数を表します。 減少している数の、より高いビット伝送速度波長が支持されるのは、可能です。 ケースn=0はチャンネルに割り当てられた特定の波長なしで単独のチャンネルの代理をします。
- Index r: The index "r", if present, is used to indicate a reduced functionality OTM, OCG, OCC and OCh (non-associated overhead is not supported). Note that for n=0 the index r is not required as it implies always reduced functionality.
- インデックスr: 存在しているなら、インデックス「r」は、減少している機能性のOTM、OCG、OCC、およびOChを示すのに使用されます(非関連しているオーバーヘッドは支持されません)。 いつも減少している機能性を含意するとき、n=0に関して、インデックスrは必要でないことに注意してください。
Editor's Address
エディタのアドレス
Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1, B-2018 Antwerpen, Belgium
フランシスWellesplein1、ディミトリPapadimitriou(アルカテル)B-2018アントウェルペン(ベルギー)
Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
以下に電話をしてください。 +32 3 240-8491 メールしてください: dimitri.papadimitriou@alcatel.be
Papadimitriou Standards Track [Page 22] RFC 4328 GMPLS Signaling Extensions for G.709 January 2006
2006年1月にG.709のために拡大に合図するPapadimitriou標準化過程[22ページ]RFC4328GMPLS
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)によって提供されます。
Papadimitriou Standards Track [Page 23]
Papadimitriou標準化過程[23ページ]
一覧
スポンサーリンク
