RFC5143 日本語訳
5143 Synchronous Optical Network/Synchronous Digital Hierarchy(SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation.A. Malis, J. Brayley, J. Shirron, L. Martini, S. Vogelsang. February 2008. (Format: TXT=52534 bytes) (Obsoleted by RFC4842) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Malis
Request for Comments: 5143 Verizon Communications
Obsoleted by: 4842 J. Brayley
Category: Historic J. Shirron
ECI Telecom Inc.
L. Martini
Cisco Systems, Inc.
S. Vogelsang
Alcatel-Lucent
February 2008
Malisがコメントのために要求するワーキンググループA.をネットワークでつないでください: 以下による5143ベライゾンCommunications Obsoleted 4842年のJ.Brayleyカテゴリ: 2008年2月にアルカテル透明な歴史的なJ.のL.マティーニシスコシステムズのInc.S.Shirron ECI電子通信株式会社フォーゲルザング
Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)
Circuit Emulation Service over MPLS (CEM) Encapsulation
同期式光通信網/同期デジタルハイアラーキ(Sonet/SDH)サーキットエミュレーションサービスオーバーMPLS(CEM)カプセル化
Status of This Memo
このメモの状態
This memo defines a Historic Document for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにHistoric Documentを定義します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
IESG Note
IESG注意
The IESG thinks that this work is related to IETF work done in WG PWE3, but this does not prevent publishing.
IESGは、この仕事がWG PWE3で行われたIETF仕事に関連すると思いますが、これは、発行するのを防ぎません。
Abstract
要約
This document describes a historical method for encapsulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Path signals for transport across packet-switched networks (PSNs). The PSNs explicitly supported by this document include MPLS and IP. Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired.
このドキュメントはパケット交換網(PSNs)の向こう側に輸送のための同期式光通信網/同期デジタルハイアラーキ(Sonet/SDH)経路信号をカプセルに入れるための歴史的研究法を説明します。 このドキュメントによって明らかに支持されたPSNsはMPLSとIPを含んでいます。 RFC4842がこの機能性のために標準化過程プロトコルについて説明して、より古い実現がある相互運用性が望まれている時を除いて、新しい実現がこのドキュメントよりむしろRFC4842を使用しなければならないことに注意してください。
Malis, et al. Historic [Page 1] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[1ページ]RFC5143Sonet/SDHサーキットエミュレーション
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Scope ...........................................................3
4. CEM Encapsulation Format ........................................4
4.1. Transport Encapsulation ....................................6
4.1.1. MPLS Transport ......................................6
4.1.2. IP Transport ........................................7
5. CEM Operation ...................................................8
5.1. Introduction and Terminology ...............................8
5.1.1. CEM Packetizer and De-Packetizer ....................9
5.1.2. CEM DBA .............................................9
5.2. Description of Normal CEM Operation .......................10
5.3. Description of CEM Operation during DBA ...................10
5.4. Packet Synchronization ....................................11
5.4.1. Acquisition of Packet Synchronization ..............11
5.4.2. Loss of Packet Synchronization .....................11
6. SONET/SDH Maintenance Signals ..................................12
6.1. SONET/SDH to PSN ..........................................12
6.1.1. AIS-P Indication ...................................13
6.1.2. STS SPE Unequipped Indication ......................14
6.1.3. CEM-RDI ............................................14
6.2. PSN to SONET/SDH ..........................................15
6.2.1. AIS-P Indication ...................................15
6.2.2. STS SPE Unequipped Indication ......................15
7. Clocking Modes .................................................16
7.1. Synchronous ...............................................16
7.1.1. Synchronous Unstructured CEM .......................16
7.1.2. Synchronous Structured CEM .........................16
7.2. Asynchronous ..............................................17
8. CEM LSP Signaling ..............................................17
9. Security Considerations ........................................18
10. IANA Considerations ...........................................18
11. References ....................................................18
11.1. Normative References .....................................18
11.2. Informative References ...................................19
Appendix A. SONET/SDH Rates and Formats ...........................20
Appendix B. ECC-6 Definition ......................................21
1. 序論…3 2. このドキュメントで中古のコンベンション…3 3. 範囲…3 4. CEMカプセル化形式…4 4.1. カプセル化を輸送してください…6 4.1.1. MPLS輸送…6 4.1.2. IP輸送…7 5. CEM操作…8 5.1. 序論と用語…8 5.1.1. CEM Packetizerと反-Packetizer…9 5.1.2. CEM DBA…9 5.2. 通常のCEM操作の記述…10 5.3. DBAの間のCEM操作の記述…10 5.4. パケット同期…11 5.4.1. パケット同期の獲得…11 5.4.2. パケット同期の損失…11 6. Sonet/SDH維持は合図します…12 6.1. PSNへのSonet/SDH…12 6.1.1. AIS-P指示…13 6.1.2. STS SPE Unequipped指示…14 6.1.3. CEM-RDI…14 6.2. Sonet/SDHへのPSN…15 6.2.1. AIS-P指示…15 6.2.2. STS SPE Unequipped指示…15 7. モードの時間を計ります…16 7.1. 同期…16 7.1.1. 同期不統一なCEM…16 7.1.2. 同期構造化されたCEM…16 7.2. 非同期…17 8. CEM LSPシグナリング…17 9. セキュリティ問題…18 10. IANA問題…18 11. 参照…18 11.1. 標準の参照…18 11.2. 有益な参照…19 付録A.Sonet/SDHレートと形式…20 付録B.ECC-6定義…21
Malis, et al. Historic [Page 2] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[2ページ]RFC5143Sonet/SDHサーキットエミュレーション
1. Introduction
1. 序論
This document describes a historical method for encapsulating SONET/SDH Path signals for transport across packet-switched networks (PSNs).
このドキュメントはパケット交換網(PSNs)の向こう側に輸送のためのSonet/SDH Path信号をカプセルに入れるための歴史的研究法を説明します。
The native transmission system for circuit-oriented Time Division Multiplexing (TDM) signals is the Synchronous Optical Network (SONET) [T1.105], [GR-253]/Synchronous Digital Hierarchy (SDH) [G.707]. To support TDM traffic (which includes voice, data, and private leased line services), PSNs must emulate the circuit characteristics of SONET/SDH payloads. MPLS labels and a new circuit emulation header are used to encapsulate TDM signals and provide the Circuit Emulation Service over MPLS (CEM) function. The MPLS encapsulation may be further encapsulated in IP for carriage across IP PSNs [RFC4023].
サーキット指向のTime事業部Multiplexing(TDM)信号の固有の伝動装置は同期式光通信網(Sonet)[T1.105][GR-253]/同期デジタルハイアラーキ(SDH)[G.707]です。 TDM交通(声、データ、および個人的な専用線サービスを含んでいる)を支持するために、PSNsはSonet/SDHペイロードのサーキットの特性を見習わなければなりません。 MPLSラベルと新しいサーキットエミュレーションヘッダーは、MPLS(CEM)機能の上にTDM信号をカプセルに入れって、Circuit Emulation Serviceを提供するのに使用されます。 MPLSカプセル化はキャリッジのためにIP PSNs[RFC4023]の向こう側にIPでさらに要約されるかもしれません。
This document also describes an optional extension to CEM called Dynamic Bandwidth Allocation (DBA). This is a method for dynamically reducing the bandwidth utilized by emulated SONET/SDH circuits in the packet network. This bandwidth reduction is accomplished by not sending the SONET/SDH payload through the packet network under certain conditions, such as Alarm Indication Signal - Path (AIS-P) or Synchronous Transport Signal Synchronous Payload Envelope (STS SPE) Unequipped.
また、このドキュメントはDynamic Bandwidth Allocation(DBA)と呼ばれるCEMに任意の拡大について説明します。 これは、パケット網における見習われたSonet/SDHサーキットによって利用された帯域幅をダイナミックに減少させるための方法です。 この帯域幅削減はパケット網を通して一定の条件の下でSonet/SDHペイロードを送らないことによって、実行されます、Alarm Indication Signalなどのように--経路(AIS-P)かSynchronous Transport Signal Synchronous有効搭載量Envelope(STS SPE)Unequipped。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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]で説明されるように本書では解釈されることであるべきですか?
3. Scope
3. 範囲
This document describes how to provide CEM for the following digital signals:
このドキュメントは以下のディジタル信号にCEMを提供する方法を説明します:
1. SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3
1. SONET STS-1の同期ペイロード封筒(SPE)/SDH VC-3
2. STS-Nc SPE (N = 3, 12, or 48)/SDH VC-4, VC-4-4c, VC-4-16c
2. STS-Nc SPE(N=3、12、または48)/SDH VC-4、VC-4-4c、VC-4-16c
3. Unstructured SONET Emulation, where the entire SONET bit-stream
(including the transport overhead) is packetized and transported
across the PSN.
3. 不統一なSonet Emulation。(そこでは、全体のSonetビットストリーム(輸送オーバーヘッドを含んでいる)は、PSNの向こう側にpacketizedされて、輸送されます)。
For the remainder of this document, these constructs will be referred to as SONET/SDH channels.
このドキュメントの残りにおいて、これらの構造物はSonet/SDHチャンネルと呼ばれるでしょう。
Malis, et al. Historic [Page 3] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[3ページ]RFC5143Sonet/SDHサーキットエミュレーション
Other SONET/SDH signals, such as virtual tributary (VT) structured sub-rate mapping, are not explicitly discussed in this document; however, it can be extended in the future to support VT and lower speed non-SONET/SDH services. OC-192c SPE/VC-4-64c are also not included at this point, since most PSNs use OC-192c or slower trunks, and thus would not have sufficient capacity. As trunk capacities increase in the future, the scope of this document can be accordingly extended.
明らかに本書では仮想の進貢している(バーモント)構造化されたサブレートマッピングなどの他のSonet/SDH信号について議論しません。 しかしながら、バーモントと下側の速度非Sonet/SDHサービスを支持するのは将来、拡張できます。 また、OC-192c SPE/VC-4-64cはここに含まれていません、ほとんどのPSNsがOC-192cか、より遅いトランクスを使用して、その結果、十分な容量を持っていないでしょう。 トランク能力が将来増加するのに従って、それに従って、このドキュメントの範囲を広げることができます。
4. CEM Encapsulation Format
4. CEMカプセル化形式
In order to transport SONET/SDH SPEs through a packet-oriented network, the SPE is broken into fragments. A 32-bit CEM header is pre-pended to each fragment. The Basic CEM packet appears in Figure 1.
パケット指向のネットワークを通してSonet/SDH SPEsを輸送するために、断片はSPEに細かく分けられます。 32ビットのCEMヘッダーは各断片にあらかじめpendedされます。 Basic CEMパケットは図1に現れます。
+-----------------------------------+ | CEM Header | +-----------------------------------+ | | | | | SONET/SDH SPE Fragment | | | | | +-----------------------------------+
+-----------------------------------+ | CEMヘッダー| +-----------------------------------+ | | | | | Sonet/SDH SPE断片| | | | | +-----------------------------------+
Figure 1. Basic CEM Packet
図1。 基本的なCEMパケット
The 32-bit CEM header has the following format:
32ビットのCEMヘッダーには、以下の形式があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|R|Rvd| Sequence Num | Structure Pointer |N|P| ECC-6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|R|Rvd| Sequenceヌム| 構造ポインタ|N|P| ECC-6| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. CEM Header Format
図2。 CEMヘッダー形式
The above fields are defined as follows:
上の分野は以下の通り定義されます:
D-bit: This bit signals DBA Mode. It MUST be set to zero for normal operation, and it MUST be set to one if CEM is currently in DBA mode. DBA is an optional mode during which trivial SPEs are not transmitted into the packet network. See Table 1 and sections 7 and 8 for further details.
D-ビット: このビットはDBA Modeを示します。 通常の操作のためにゼロにそれを設定しなければなりません、そして、CEMが現在DBAモードであるなら、1つにそれを設定しなければなりません。 DBAは些細なSPEsがパケット網に伝えられない任意のモードです。 さらに詳しい明細についてはTable1とセクション7と8を見てください。
Note: for unstructured CEM, the D-bit MUST be set to zero.
以下に注意してください。 不統一なCEMにおいて、D-ビットをゼロに設定しなければなりません。
Malis, et al. Historic [Page 4] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[4ページ]RFC5143Sonet/SDHサーキットエミュレーション
R bit: CEM-RDI (Remote Defect Indicator). This bit is set to one to signal to the remote CEM function that a loss of packet synchronization has occurred.
Rに噛み付きました: CEM-RDI(リモート欠陥インディケータ)。 1つにこのビットが、パケット同期の損失が発生したとリモートCEM機能に合図するように設定されます。
Rvd: These bits are reserved for future use, and MUST be set to zero.
Rvd: これらのビットを今後の使用のために予約されて、ゼロに設定しなければなりません。
Sequence Number: This is a packet sequence number, which MUST continuously cycle from 0 to 1023. It SHOULD begin at zero when a CEM LSP (Label Switched Path) is created.
一連番号: これはパケット一連番号です。(その一連番号は0〜1023年まで絶え間なく循環しなければなりません)。 それ、CEM LSP(ラベルSwitched Path)が作成されるとき、SHOULDはゼロで始まります。
Structure Pointer: The Structure Pointer MUST contain the offset of the J1 byte within the CEM payload. The value is from 0 to 1,022, where 0 means the first byte after the CEM header. The Structure Pointer MUST be set to 0x3FF (1,023) if a packet does not carry the J1 byte. See [T1.105], [G.707], and [GR-253] for more information On the J1 byte and the SONET/SDH payload pointer.
ポインタを構造化してください: Structure PointerはCEMペイロードの中にJ1バイトのオフセットを含まなければなりません。 値は、0〜1,022です。(そこでは、0がCEMヘッダーの後に最初のバイトを意味します)。 (1,023) パケットがJ1バイトを運ばないなら、Structure Pointerは0x3FFに用意ができなければなりません。 [G.707]、[T1.105]を見てください。そうすれば、より多くの情報Onのための[GR-253]はJ1バイトとSonet/SDHペイロードポインタを見ます。
Note: for unstructured CEM, the Structure Pointer field MUST be
set to 0x3FF.
以下に注意してください。 不統一なCEMにおいて、Structure Pointer分野を0x3FFに設定しなければなりません。
The N and P bits: These bits indicate negative and positive pointer adjustment events. They are also used to relay SONET/SDH maintenance signals, such as AIS-P. See Table 1 and sections 7 and 8 for more details.
NとPビット: これらのビットは否定的で積極的なポインタ調整イベントを示します。 また、それらは、AIS-PなどのSonet/SDH維持信号をリレーするのに使用されます。 その他の詳細に関してTable1とセクション7と8を見てください。
Note: for unstructured CEM, the N and P bits MUST both be set to
zero.
以下に注意してください。 不統一なCEMにおいて、NとPビットをゼロにともに設定しなければなりません。
+---+---+---+----------------------------------------------+ | D | N | P | Interpretation | +---+---+---+-------------+--------------------------------+ | 0 | 0 | 0 | Normal Mode | No Ptr Adjustment | | 0 | 0 | 1 | Normal Mode | Positive Ptr Adjustment | | 0 | 1 | 0 | Normal Mode | Negative Ptr Adjustment | | 0 | 1 | 1 | Normal Mode | AIS-P | | | | | | | | 1 | 0 | 0 | DBA Mode | STS SPE Unequipped | | 1 | 0 | 1 | DBA Mode | STS SPE Unequipped Pos Ptr Adj | | 1 | 1 | 0 | DBA Mode | STS SPE Unequipped Neg Ptr Adj | | 1 | 1 | 1 | DBA Mode | AIS-P | +---+---+---+-------------+--------------------------------+
+---+---+---+----------------------------------------------+ | D| N| P| 解釈| +---+---+---+-------------+--------------------------------+ | 0 | 0 | 0 | 正規モード| Ptr調整がありません。| | 0 | 0 | 1 | 正規モード| 積極的なPtr調整| | 0 | 1 | 0 | 正規モード| 否定的Ptr調整| | 0 | 1 | 1 | 正規モード| AIS-P| | | | | | | | 1 | 0 | 0 | DBAモード| STS SPE Unequipped| | 1 | 0 | 1 | DBAモード| STS SPE Unequipped Pos Ptr Adj| | 1 | 1 | 0 | DBAモード| STS SPE Unequipped Neg Ptr Adj| | 1 | 1 | 1 | DBAモード| AIS-P| +---+---+---+-------------+--------------------------------+
Table 1. Interpretation of D, N, and P bits
1を見送ってください。 D、N、およびPビットの解釈
Malis, et al. Historic [Page 5] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[5ページ]RFC5143Sonet/SDHサーキットエミュレーション
ECC-6: An Error Correction Code to protect the CEM header. This offers the ability to correct single bit errors and detect up to two bit errors. The ECC algorithm is described in Appendix B. The ECC-6 can be optionally disabled at provisioning time. If the ECC-6 is not utilized, it MUST be set to zero.
ECC-6: CEMヘッダーを保護するError Correction Code。 これはただ一つの噛み付いている誤りを修正して、最大2ビットの誤りを検出する能力を提供します。 Appendix B.でECCアルゴリズムを説明します。任意にECC-6を時間に食糧を供給するのに無効にすることができます。 ECC-6が利用されていないなら、ゼロにそれを設定しなければなりません。
Note: Normal CEM packets are fixed in length for all of the
packets of a particular emulated TDM stream. This length is
signaled using the CEM Payload Bytes parameter defined in
[RFC4447], or is statically provisioned for each TDM stream.
Therefore, the length of each CEM packet does not need to be
carried in the CEM header.
以下に注意してください。 正常なCEMパケットは特定の見習われたTDMの流れのパケットのすべてのための長さで修理されています。 この長さは、[RFC4447]で定義されたCEM有効搭載量Bytesパラメタを使用することで合図されるか、またはそれぞれのTDMの流れのために静的に食糧を供給されます。 したがって、CEMヘッダーでそれぞれのCEMパケットの長さは運ばれる必要はありません。
Note: Setting the D-bit to 0 and the R bit to 1 violates the Best
Current Practice defined in [RFC4928] when operating on MPLS
networks. In this situation, MPLS networks could mistake a CEM
payload as the first nibble of an IPv4 packet, potentially causing
mis-ordering of packets on the pseudowire in the presence of IP
Equal Cost Multi-Path (ECMP) in the MPLS network. The use of this
CEM header preceded the use of MPLS ECMP. As stated earlier,
[RFC4842] describes the standards-track protocol for this
functionality, and it does not share this violation.
以下に注意してください。 0へのD-ビットと1へのRビットを設定すると、MPLSネットワークを経営するとき[RFC4928]で定義されたBest Current Practiceは違反されます。 この状況で、MPLSネットワークはIPv4パケットの最初の少量としてCEMペイロードを間違うことができました、MPLSネットワークにおけるIP Equal Cost Multi-経路(ECMP)の面前で潜在的にpseudowireでのパケットの誤注文を引き起こして。 このCEMヘッダーの使用はMPLS ECMPの使用に先行しました。 より早く述べられるように、[RFC4842]はこの機能性のために標準化過程プロトコルについて説明します、そして、それはこの違反を共有しません。
4.1. Transport Encapsulation
4.1. 輸送カプセル化
In principle, CEM packets can be transported over any packet-oriented network. The following sections describe specifically how CEM packets MUST be encapsulated for transport over MPLS or IP networks.
原則として、どんなパケット指向のネットワークの上でもCEMパケットを輸送できます。 以下のセクションは輸送のために明確にどうCEMパケットをカプセルに入れらなければならないかをMPLSかIPネットワークに説明します。
4.1.1. MPLS Transport
4.1.1. MPLS輸送
To transport a CEM packet over an MPLS network, an MPLS label stack MUST be pushed on top of the CEM packet.
MPLSネットワークの上でCEMパケットを輸送するために、CEMパケットの上でMPLSラベルスタックを押さなければなりません。
The last two labels prior to the CEM header are referred to as the Tunnel and Virtual Circuit (VC) labels.
CEMヘッダーの前の最後の2個のラベルがTunnelとVirtual Circuit(VC)ラベルと呼ばれます。
The VC label is required, and is the last label prior to the CEM Header. The VC label MUST be used to identify the CEM connection within the MPLS tunnel.
VCラベルは、必要であり、CEM Headerの前の最後のラベルです。 MPLSトンネルの中でCEM接続を特定するのにVCラベルを使用しなければなりません。
The optional tunnel label is immediately above the VC label on the label stack. If present, the tunnel label MUST be used to identify the MPLS LSP used to tunnel the TDM packets through the MPLS network (the tunnel LSP).
ラベルスタックの上のVCラベルのすぐ上に任意のトンネルラベルがあります。 存在しているなら、MPLSネットワーク(トンネルLSP)を通してTDMパケットにトンネルを堀るのに使用されるMPLS LSPを特定するのにトンネルラベルを使用しなければなりません。
This is similar to the label stack usage defined in [RFC4447].
これは[RFC4447]で定義されたラベルスタック用法と同様です。
Malis, et al. Historic [Page 6] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[6ページ]RFC5143Sonet/SDHサーキットエミュレーション
+-----------------------------------+ | Additional MPLS Labels (Optional) | +-----------------------------------+ | Tunnel Label (Optional) | +-----------------------------------+ | VC Label | +-----------------------------------+ | CEM Header | +-----------------------------------+ | | | | | SONET/SDH SPE Fragment | | | | | +-----------------------------------+
+-----------------------------------+ | 追加MPLSラベル(任意の)| +-----------------------------------+ | トンネルラベル(任意の)| +-----------------------------------+ | VCラベル| +-----------------------------------+ | CEMヘッダー| +-----------------------------------+ | | | | | Sonet/SDH SPE断片| | | | | +-----------------------------------+
Figure 3. Typical MPLS Transport Encapsulation
図3。 典型的なMPLS輸送カプセル化
4.1.2. IP Transport
4.1.2. IP輸送
It is highly desirable to define a single encapsulation format that will work for both IP and MPLS. Furthermore, it is desirable that the encapsulation mechanism be as efficient as possible.
IPとMPLSの両方のために働いているただ一つのカプセル化書式を定義するのは非常に望ましいです。 その上、カプセル化メカニズムができるだけ効率的であることは、望ましいです。
One way to achieve these goals is to map CEM directly onto IP by mapping the previously described MPLS packets onto IP.
これらの目標を達成する1つの方法は以前に説明されたMPLSパケットをIPに写像することによって直接IPにCEMを写像することです。
A mechanism for carrying MPLS over IP is described in [RFC4023].
IPの上までMPLSを運ぶためのメカニズムは[RFC4023]で説明されます。
Using this encapsulation scheme would result in the packet format illustrated in Figure 4.
このカプセル化計画を使用すると、図4で例証されたパケット・フォーマットはもたらされるでしょう。
Malis, et al. Historic [Page 7] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[7ページ]RFC5143Sonet/SDHサーキットエミュレーション
+-----------------------------------+ | | | IPv6/v4 Header [RFC4023] | | | +-----------------------------------+ | Tunnel Label (Optional) | +-----------------------------------+ | VC Label | +-----------------------------------+ | CEM Header | +-----------------------------------+ | | | | | SONET/SDH SPE Fragment | | | | | +-----------------------------------+
+-----------------------------------+ | | | IPv6/v4ヘッダー[RFC4023]| | | +-----------------------------------+ | トンネルラベル(任意の)| +-----------------------------------+ | VCラベル| +-----------------------------------+ | CEMヘッダー| +-----------------------------------+ | | | | | Sonet/SDH SPE断片| | | | | +-----------------------------------+
Figure 4. MPLS Transport Encapsulation
図4。 MPLS輸送カプセル化
5. CEM Operation
5. CEM操作
The following sections describe CEM operation.
以下のセクションはCEM操作について説明します。
5.1. Introduction and Terminology
5.1. 序論と用語
There are two types of CEM: structured and unstructured.
CEMの2つのタイプがあります: 構造化されていて不統一です。
Unstructured CEM packetizes the entire SONET/SDH bit-stream (including transport overhead).
全体Sonet/SDHの不統一なCEM packetizesビットストリーム(輸送オーバーヘッドを含んでいます)。
Structured CEM terminates the transport overhead and packetizes individual channels (STS-1/Nc) within the SONET/SDH frame. Because structured CEM terminates the transport overhead, structured CEM implementations SHOULD meet the generic requirements for SONET/SDH Line Terminating Equipment as defined in [T1.105], [G.707], and [GR-253].
構造化されたCEMはSonet/SDHフレームの中に輸送オーバーヘッドを終えて、独特のチャンネル(STS-1/Nc)をpacketizesします。 構造化されたCEMが輸送オーバーヘッドを終えるので、構造化されたCEM実現SHOULDは[T1.105]、[G.707]、および[GR-253]で定義されるようにSonet/SDH線Terminating Equipmentのための一般的な必要条件を満たします。
Implementations MUST support structured CEM and MAY support unstructured CEM.
実現は、構造化されたCEMを支持しなければならなくて、不統一なCEMを支持するかもしれません。
Structured CEM MUST support a normal mode of operation and MAY support an optional extension called Dynamic Bandwidth Allocation (DBA). During normal operation, SONET/SDH payloads are fragmented, pre-pended with the CEM header, the VC label, and the PSN header, and
構造化されたCEM MUSTは正常な運転モードを支持します、そして、Dynamic Bandwidth Allocation(DBA)と呼ばれる任意の拡大を支持するかもしれません。 そして通常の操作の間、Sonet/SDHペイロードがCEMヘッダー、VCラベル、およびPSNヘッダーと共に断片化されて、あらかじめpendedされている。
Malis, et al. Historic [Page 8] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[8ページ]RFC5143Sonet/SDHサーキットエミュレーション
then transmitted into the packet network. During DBA mode, only the CEM header, the VC label, and PSN header are transmitted. This is done to conserve bandwidth when meaningful user data is not present in the SPE, such as during AIS-P or STS SPE Unequipped.
そして、パケット網に伝えられます。 DBAモードの間、CEMヘッダー、VCラベル、およびPSNヘッダーだけが伝えられます。 重要な利用者データがSPEに存在していないとき、帯域幅を保存するためにこれをします、AIS-PやSTS SPE Unequippedなどのように。
5.1.1. CEM Packetizer and De-Packetizer
5.1.1. CEM Packetizerと反-Packetizer
As with all adaptation functions, CEM has two distinct components: adapting TDM SONET/SDH into a CEM packet stream, and converting the CEM packet stream back into a TDM SONET/SDH. The first function will be referred to as CEM packetizer and the second as CEM de-packetizer. This terminology is illustrated in Figure 5.
すべての適合機能のように、CEMには、2つの異なったコンポーネントがあります: CEMパケットの流れの中にTDM SONET/SDHを適合させて、CEMパケットの流れをTDM SONET/SDHに変換し返します。 最初の機能はCEM反-packetizerとしてCEM packetizerと2番目と呼ばれるでしょう。 この用語は図5で例証されます。
+------------+ +---------------+
| | | |
SONET --> | CEM | --> PSN --> | CEM | --> SONET
SDH | Packetizer | | De-Packetizer | SDH
| | | |
+------------+ +---------------+
+------------+ +---------------+ | | | | Sonet-->。| CEM| -->PSN-->。| CEM| -->Sonet SDH| Packetizer| | 反-Packetizer| SDH| | | | +------------+ +---------------+
Figure 5. CEM Terminology
図5。 CEM用語
Note: the CEM de-packetizer requires a buffering mechanism to account for delay variation in the CEM packet stream. This buffering mechanism will be generically referred to as the CEM jitter buffer.
以下に注意してください。 CEM反-packetizerは、CEMパケットの流れの遅れ変化の原因になるようにバッファリングメカニズムを必要とします。 このバッファリングメカニズムは一般的にCEMジターバッファと呼ばれるでしょう。
5.1.2. CEM DBA
5.1.2. CEM DBA
DBA is an optional mode of operation for structured CEM that only transmits the CEM header, the VC label, and PSN header into the packet network under certain circumstances, such as AIS-P or STS SPE Unequipped.
DBAはCEMヘッダー、VCラベルを伝えるだけである構造化されたCEMとAIS-PかSTS SPE Unequippedなどのある状況によるパケット網へのPSNヘッダーのための操作の任意のモードです。
If DBA is supported by a CEM implementation, the user SHOULD be able to configure if DBA will be triggered by AIS-P, STS SPE Unequipped, both, or neither on a per channel basis.
DBAはCEM実現で支持されます、ユーザSHOULD。DBAがチャンネル基礎あたりのaでAIS-P、STS SPE Unequipped、両方、またはどちらもによって引き起こされるかどうかを構成できてください。
If DBA is supported, the determination of AIS-P and STS SPE Unequipped MUST be based on the state of SONET/SDH Section, Line, and Path Overhead bytes. DBA based on pattern detection within the SPE (i.e., all zeros, 7Es, or ATM idle cells) is for further study.
DBAが支持されるなら、AIS-PとSTS SPE Unequippedの決断をSonet/SDHセクションの状態、線、およびPath Overheadバイトに基礎づけなければなりません。 さらなる研究にはSPE(すなわち、すべてのゼロ、7Es、またはATMの活動していないセル)の中でパターン検出に基づいたDBAがあります。
During AIS-P, there is no valid payload pointer, so pointer adjustments cannot occur. During STS SPE Unequipped, the SONET/SDH payload pointer is valid, and therefore pointer adjustments MUST be supported even during DBA. See Table 1 for details.
AIS-Pの間、どんな有効なペイロードポインタもないので、ポインタ調整は起こることができません。 STS SPE Unequippedの間、Sonet/SDHペイロードポインタは有効です、そして、したがって、DBAの間さえ、ポインタ調整を支持しなければなりません。 詳細に関してTable1を見てください。
Malis, et al. Historic [Page 9] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[9ページ]RFC5143Sonet/SDHサーキットエミュレーション
5.2. Description of Normal CEM Operation
5.2. 通常のCEM操作の記述
During normal operation, the CEM packetizer will receive a fixed rate byte stream from a SONET/SDH interface. When a packet's worth of data has been received from a SONET/SDH channel, the CEM header, the VC Label, and PSN header are pre-pended to the SPE fragment and the resulting CEM packet is transmitted into the packet network. Because all normal CEM packets associated with a specific SONET/SDH channel will have the same length, the transmission of CEM packets for that channel SHOULD occur at regular intervals.
通常の操作の間、CEM packetizerはSonet/SDHインタフェースから定率バイト・ストリームを受けるでしょう。 パケットのデータの価値を受け取ったとき、Sonet/SDHチャンネル、CEMヘッダー、VC Label、およびPSNから、ヘッダーはSPE断片にあらかじめpendedしています、そして、結果として起こるCEMパケットをパケット網に伝えます。 そのチャンネルSHOULDが一定の間隔を置いて起こるのでCEMパケットが関連づけたすべての標準が特定のSonet/SDHチャンネルで同じ長さ、CEMパケットのトランスミッションを持つので。
At the far-end of the packet network, the CEM de-packetizer will receive packets into a jitter buffer and then play out the received byte stream at a fixed rate onto the corresponding SONET/SDH channel. The jitter buffer SHOULD be adjustable in length to account for varying network delay behavior. The received packet rate from the packet network should be exactly balanced by the transmission rate onto the SONET/SDH channel, on average. The time over which this average is taken corresponds to the depth of the jitter buffer for a specific CEM channel.
パケット網の遠端では、CEM反-packetizerは対応するSonet/SDHチャンネルにジターバッファの中にパケットを受けて、次に、定率で容認されたバイト・ストリームを終えるでしょう。 ジターは調整可能なコネがネットワーク遅延の振舞いを変える説明する長さであったならSHOULDをバッファリングします。 パケット網からの容認されたパケットレートはまさに通信速度でSonet/SDHチャンネルとバランスをとるべきです、平均的に。 これが平均するタイム・オーバーを取ります。特定のCEMチャンネルへのジターバッファの深さに対応しています。
The CEM sequence numbers provide a mechanism to detect lost and/or mis-ordered packets. The CEM de-packetizer MUST detect lost or mis-ordered packets. The CEM de-packetizer MUST play out a programmable byte pattern in place of any dropped packets. The CEM de-packetizer MAY re-order packets received out of order. If the CEM de-packetizer does not support re-ordering, it MUST drop mis-ordered packets.
CEM一連番号は、無くなっているそして/または、誤命令されたパケットを検出するためにメカニズムを提供します。 CEM反-packetizerは無くなっているか誤命令されたパケットを検出しなければなりません。 反-packetizerがプログラマブルバイト終えなければならないCEMはどんな低下しているパケットに代わって型に基づいて作ります。 CEM反-packetizer5月の再オーダーパケットは故障していた状態で受信されました。 CEM反-packetizerが再注文を支持しないなら、それは誤命令されたパケットを落とさなければなりません。
5.3. Description of CEM Operation during DBA
5.3. DBAの間のCEM操作の記述
(Note: DBA is only applicable to structured CEM.)
(注意: DBAは単に構造化されたCEMに適切です。)
There are several issues that should be addressed by a workable CEM DBA mechanism. First, when DBA is invoked, there should be a substantial savings in bandwidth utilization in the packet network. The second issue is that the transition in and out of DBA should be tightly coordinated between the local CEM packetizer and CEM de-packetizer at the far side of the packet network. A third is that the transition in and out of DBA should be accomplished with minimal disruption to the adapted data stream.
実行可能なCEM DBAメカニズムによって記述されるべきであるいくつかの問題があります。 DBAが呼び出されるとき、まず最初に、帯域幅利用には多額の預金がパケット網にあるべきです。 第2刷はDBAとDBAからの変遷がパケット網の反対側で地方のCEM packetizerとCEM反-packetizerの間でしっかり調整されるべきであるということです。 3分の1はDBAとDBAからの変遷が適合しているデータ・ストリームの最小量の分裂で実行されるべきであるということです。
Another goal is that the reduction of CEM traffic due to DBA should not be mistaken for a fault in the packet network or vice-versa. Finally, the implementation of DBA should require minimal modifications beyond what is necessary for the nominal CEM case. The mechanism described below is a reasonable balance of these goals.
別の目標はDBAによるCEM交通の減少をパケット網における欠点に間違えるべきでないということであるか逆もまた同様です。 最終的に、DBAの実現は名目上のCEMケースに必要なことを超えて最小量の変更を必要とするべきです。 以下で説明されたメカニズムはこれらの目標の妥当なバランスです。
Malis, et al. Historic [Page 10] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[10ページ]RFC5143Sonet/SDHサーキットエミュレーション
During DBA, packets MUST be emitted at exactly the same rate as they would be during normal operation. This SHOULD be accomplished by transmitting each DBA packet after a complete packet of data has been received from the SONET/SDH channel. The only change from normal operation is that the CEM packets during DBA MUST only carry the CEM header, the VC label, and the PSN header.
DBAの間、それらが通常の操作の間あるだろうというとき、まさに同じレートでパケットを放たなければなりません。 このSHOULD、Sonet/SDHチャンネルからデータの完全なパケットを受け取った後にそれぞれのDBAパケットを伝えることによって、達成されてください。 通常の操作からの唯一の変化はDBA MUSTの間のCEMパケットがCEMヘッダー、VCラベル、およびPSNヘッダーを運ぶだけであるということです。
Because some links have a minimum supported packet size, the CEM packetizer MAY append a configurable number of bytes immediately after the CEM header to pad out the CEM packet to reach the minimum supported packet size. The value of the padding bytes is implementation specific. The D-bit MUST be set to one, to indicate that DBA is active.
いくつかのリンクには最小の支持されたパケットサイズがあるので、CEM packetizerはCEMヘッダー直後最小の支持されたパケットサイズに達するようにCEMパケットを広げるために構成可能な数のバイトを追加するかもしれません。 詰め物バイトの値は実現特有です。 D-ビットをDBAがアクティブであることを示すように1つに設定しなければなりません。
The CEM de-packetizer MUST assume that each packet received with the D-bit set represents a normal-sized packet containing an AIS-P or STS SPE Unequipped payload as noted by N and P, (see Table 1). The CEM de-packetizer MUST accept DBA packets with or without padding.
CEM反-packetizerが、D-ビットセットで受け取られた各パケットがNとPによって注意されるようにAIS-PかSTS SPE Unequippedペイロードを含む標準サイズのパケットを表すと仮定しなければならない、(Table1を見ます。) CEM反-packetizerは詰め物のあるなしにかかわらずDBAパケットを受け入れなければなりません。
This allows the CEM packetization and de-packetization logic during DBA to be similar to the nominal case. It insures that the correct SONET/SDH indication is reliably transmitted between CEM adaptation points. It minimizes the risk of under or over running the jitter buffer during the transition in and out of DBA. And, it guarantees that faults in the packet network are recognized as distinctly different from line conditioning on the SONET/SDH interfaces.
これは、DBAの間のCEM packetizationと反-packetization論理が名目上のケースと同様であることを許容します。 それは、正しいSonet/SDH指示がCEM適合ポイントの間に確かに伝えられるのを保障します。 それは下かDBAの危険を最小にします。 そして、それは、パケット網における欠点が回線調整とSonet/SDHインタフェースで明瞭に異なると認識されるのを保証します。
5.4. Packet Synchronization
5.4. パケット同期
A key component in declaring the state of a CEM service is whether or not the CEM de-packetizer is in or out of packet synchronization. The following paragraphs describe how that determination is made.
CEMサービスの状態を宣言することにおける主要なコンポーネントはCEM反-packetizerが同期かパケット同期から脱しているかどうかということです。 以下のパラグラフはどうその決断をするかを説明します。
5.4.1. Acquisition of Packet Synchronization
5.4.1. パケット同期の獲得
At startup, a CEM de-packetizer will be out of packet synchronization by default. To declare packet synchronization at startup or after a loss of packet synchronization, the CEM de-packetizer must receive a configurable number of CEM packets with sequential sequence numbers.
始動では、CEM反-packetizerはデフォルトでパケット同期から脱しているでしょう。 始動においてパケット同期の損失の後にパケット同期を宣言するために、CEM反-packetizerは連続した一連番号で構成可能な数のCEMパケットを受けなければなりません。
5.4.2. Loss of Packet Synchronization
5.4.2. パケット同期の損失
Once a CEM de-packetizer is in packet sync, it may encounter a set of events that will cause it to lose packet synchronization.
パケットの同時性にCEM反-packetizerがいったんあると、それはパケット同期がそれが失われる1セットの出来事に遭遇するかもしれません。
As discussed in section 5.2, a CEM de-packetizer MAY support the re-ordering of mis-ordered packets.
セクション5.2で議論するように、CEM反-packetizerは誤命令されたパケットの再注文を支持するかもしれません。
Malis, et al. Historic [Page 11] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[11ページ]RFC5143Sonet/SDHサーキットエミュレーション
If a CEM de-packetizer supports re-ordering, then the determination that packet synchronization has been lost cannot be made at the time the packets are received from the PSN. Instead, the determination MUST be made as the packets are being played out onto the SONET/SDH interface. This is because it is only at play-out time that the determination can be made as to whether the entire emulated SONET/SDH stream was received from the PSN.
パケット同期が決断ですが、CEM反-packetizerが、次に、再注文するのを支持するなら、失われて、PSNからパケットを受け取るとき、作ることができません。 代わりに、Sonet/SDHインタフェースにパケットを使い果たしているとき決断をしなければなりません。 これは単に外でプレーする時にPSNから全体の見習われたSonet/SDH小川を受け取ったかどうかに関して決断をすることができるからです。
If a CEM de-packetizer does not support re-ordering, a number of approaches may be used to minimize the impact of mis-ordered or lost packets on the final re-assembled SONET/SDH stream. For example, ATM Adaptation Layer 1 (AAL1) [I.363.1] uses a simple state-machine to re-order packets in a subset of possible cases. The algorithm for these state-machines is outside of the scope of CEM. However, the final determination as to whether or not to declare loss of packet synchronization MUST be based on the same criteria as for implementations that do support re-ordering.
CEM反-packetizerが再注文を支持しないなら、多くのアプローチが、最終的な組み立て直されたSonet/SDHの流れのときに誤命令されたか無くなっているパケットの衝撃を最小にするのに使用されるかもしれません。 例えば、ATM Adaptation Layer1(AAL1)[I.363.1]は、可能なケースの部分集合でパケットを再注文するのに簡単な州マシンを使用します。 これらの州マシンのためのアルゴリズムがCEMの範囲の外にあります。 しかしながら、再注文を支持する実現のようにパケット同期の損失を宣言するかどうかに関する最終的決定を同じ評価基準に基礎づけなければなりません。
Whether or not a CEM implementation supports re-ordering, the declaration of loss of packet synchronization MUST be based on the following criteria.
CEM実現が再注文を支持するか否かに関係なく、パケット同期の損失の宣言を以下の評価基準に基礎づけなければなりません。
As packets are played out towards the SONET/SDH interface, the CEM de-packetizer will encounter empty packets in the place of packets that were dropped by the PSN, or effectively dropped due to limitations of the CEM implementation. If the CEM de-packetizer encounters more than a configurable number of sequential dropped packets, the CEM de-packetizer MUST declare loss of packet synchronization.
パケットがSonet/SDHインタフェースに向かって使い果たされるとき、CEM反-packetizerはPSNによって落とされるか、または事実上、CEM実現の制限のため落とされたパケットの場所で空のパケットに遭遇するでしょう。 CEM反-packetizerが構成可能な数以上に遭遇するなら、連続した低下しているパケット、反-packetizerがそうしなければならないCEMでは、パケット同期の損失を宣言してください。
6. SONET/SDH Maintenance Signals
6. Sonet/SDH維持信号
There are several issues that must be considered in the mapping of maintenance signals between SONET/SDH and a PSN. A description of how these signals and conditions are mapped between the two domains is given below.
Sonet/SDHとPSNの間には、維持信号に関するマッピングで考えなければならないいくつかの問題があります。 これらの信号と状態が2つのドメインの間でどう写像されるかに関する記述を以下に与えます。
For clarity, the mappings are split into two groups: SONET/SDH to PSN and PSN to SONET/SDH.
明快において、マッピングは2つのグループに分けられます: PSNへのSonet/SDHとSonet/SDHへのPSN。
6.1. SONET/SDH to PSN
6.1. PSNへのSonet/SDH
The following sections describe how SONET/SDH Maintenance Signals and Alarm conditions are mapped into a Packet-Switched Network.
以下のセクションはSonet/SDH Maintenance SignalsとAlarm状態がどう写像されるかをPacketによって切り換えられたNetworkに説明します。
Malis, et al. Historic [Page 12] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[12ページ]RFC5143Sonet/SDHサーキットエミュレーション
6.1.1. AIS-P Indication
6.1.1. AIS-P指示
In a SONET/SDH network, SONET/SDH Path outages are signaled using maintenance alarms, such as Path AIS (AIS-P). In particular, AIS-P indicates that the SONET/SDH Path is not currently transmitting valid end-user data, and the SPE contains all ones.
Sonet/SDHネットワークでは、Path AISなどの維持アラーム(AIS-P)を使用することでSonet/SDH Path供給停止に合図します。 特に、AIS-Pは、Sonet/SDH Pathが現在、有効なエンドユーザデータを送っていなくて、SPEがすべてのものを含むのを示します。
It should be noted that for structured CEM, nearly every type of service-effecting section or line defect will result in an AIS-P condition.
構造化されたCEMに関して、ほとんどすべてのタイプのサービスに作用するセクションか線欠陥がAIS-P状態をもたらすことに注意されるべきです。
The SONET/SDH hierarchy is illustrated below.
Sonet/SDH階層構造は以下で例証されます。
+----------+
| PATH |
+----------+
^
|
AIS-P
|
|
+----------+
| LINE |
+ ---------+
^ ^
| |
AIS-L +------ LOP
|
|
+----------+
| SECTION |
+----------+
^ ^
| |
| |
LOS LOF
+----------+ | 経路| +----------+ ^ | AIS-P| | +----------+ | 線| + ---------+ ^ ^ | | AIS-L+------ 切り取ってください。| | +----------+ | セクション| +----------+ ^ ^ | | | | ロスLOF
Figure 6. SONET/SDH Fault Hierarchy
図6。 Sonet/SDH欠点階層構造
Should the Section Layer detect a Loss of Signal (LOS) or Loss of Frame (LOF) condition, it sends AIS-L up to the Line Layer. If the Line Layer detects AIS-L or Loss of Path (LOP), it sends AIS-P to the Path Layer.
セクションLayerがSignal(LOS)のLossかFrame(LOF)状態のLossを検出するなら、それはAIS-Lを線Layerまで送ります。 線LayerがPath(LOP)のAIS-LかLossを検出するなら、それはAIS-PをPath Layerに送ります。
In normal mode during AIS-P, structured CEM packets are generated as usual. The N and P bits MUST be set to 11 binary to signal AIS-P explicitly through the packet network. The D-bit MUST be set to zero
AIS-Pの間の正規モードでは、構造化されたCEMパケットはいつものように発生します。 NとPビットをパケット網を通して明らかにAIS-Pに合図するように11バイナリーに設定しなければなりません。 D-ビットをゼロに設定しなければなりません。
Malis, et al. Historic [Page 13] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[13ページ]RFC5143Sonet/SDHサーキットエミュレーション
to indicate that the SPE is being carried through the packet network. Normal CEM packets with the SPE fragment, CEM header, the VC label, and PSN header MUST be transmitted into the packet network.
それを示すために、SPEはパケット網を通して運ばれます。 SPEがあるCEMパケットが断片化する標準、CEMヘッダー、VCラベル、およびPSNヘッダーをパケット網に伝えなければなりません。
However, to conserve network bandwidth during AIS-P, DBA MAY be employed. If DBA has been enabled for AIS-P and AIS-P is currently occurring, the N and P bits MUST be set to 11 binary to signal AIS, and the D-bit MUST be set to one to indicate that the SPE is not being carried through the packet network. Only the CEM header, the VC label, and the PSN header MUST be transmitted into the packet network.
しかしながら、AIS-P、DBA MAYの間、ネットワーク回線容量を保存するには、使われてください。 DBAがAIS-Pのために有効にされて、AIS-Pが現在起こっているなら、NとPビットをAISに合図するように11バイナリーに設定しなければなりません、そして、D-ビットをSPEがパケット網を通して運ばれないのを示すように1つに設定しなければなりません。 CEMヘッダー、VCラベル、およびPSNヘッダーだけをパケット網に伝えなければなりません。
Also note that this differs from the outage mechanism in [RFC4447], which withdraws the VC label as a result of an endpoint outage. TDM circuit emulation requires the ability to distinguish between the de-provisioning of a circuit (which causes the VC label to be withdrawn), and temporary outages (which are signaled using AIS-P).
また、これが終点供給停止の結果、VCラベルを引っ込める[RFC4447]の供給停止メカニズムと異なっていることに注意してください。 TDMサーキットエミュレーションはサーキット(VCラベルを引っ込めさせる)、および一時的な供給停止(AIS-Pを使用することで合図される)の反-の食糧を供給することを見分ける能力を必要とします。
6.1.2. STS SPE Unequipped Indication
6.1.2. STS SPE Unequipped指示
The STS SPE Unequipped Indication is a slightly different case than AIS-P. When byte C2 of the Path Overhead (STS path signal label) is 00h and Byte B3 (STS Path BIP-8) is valid, it indicates that the STS SPE is unequipped. Note: this is typically signaled by setting the entire SPE to zeros.
STS SPE Unequipped IndicationはAIS-Pよりわずかに異なったケースです。 Path Overhead(STS経路信号ラベル)のバイトC2が00hであり、Byte B3(STS Path BIP-8)が有効であるときに、それは、STS SPEが非設備されるのを示します。 以下に注意してください。 全体のSPEをゼロに設定することによって、これは通常合図されます。
For normal structured CEM operation during STS SPE Unequipped, the N and P bits MUST be interpreted as usual. The SPE MUST be transmitted into the packet network along with the CEM header, the VC label, and PSN header, and the D-Bit MUST be set to zero.
STS SPE Unequippedの間の通常の構造化されたCEM操作において、NとPビットをいつものように解釈しなければなりません。 SPE MUSTがCEMヘッダーに伴うパケット網に伝えられて、VCラベル、PSNヘッダー、およびD-ビットはそうであるに違いありません。ゼロに、セットしました。
If DBA has been enabled for STS SPE Unequipped and the Unequipped condition is occurring on the SONET/SDH channel, the D-bit MUST be set to one to indicate DBA is active. Only the CEM header, the VC Label, and PSN header MUST be transmitted into the packet network. The N and P bits MUST be used to signal pointer adjustments as normal. See Table 1 and section 8 for details.
DBAがSTS SPE Unequippedのために有効にされて、Unequipped状態がSonet/SDHチャンネルの上に現れているなら、D-ビットをDBAがアクティブであることを示すように1つに設定しなければなりません。 CEMヘッダー、VC Label、およびPSNヘッダーだけをパケット網に伝えなければなりません。 通常のポインタ同じくらい調整に合図するのにNとPビットを使用しなければなりません。 詳細に関してTable1とセクション8を見てください。
6.1.3. CEM-RDI
6.1.3. CEM-RDI
The CEM function MUST send CEM-RDI towards the packet network during loss of packet synchronization. This MUST be accomplished by setting the R bit to one in the CEM header. This applies for both structured and unstructured CEM.
CEM機能はパケット同期の損失の間、パケット網に向かってCEM-RDIを送らなければなりません。 1つへのRビットをCEMヘッダーにはめ込むことによって、これを達成しなければなりません。 これは構造化されたものと同様に不統一なCEMに申し込みます。
Malis, et al. Historic [Page 14] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[14ページ]RFC5143Sonet/SDHサーキットエミュレーション
6.2. PSN to SONET/SDH
6.2. Sonet/SDHへのPSN
The following sections discuss how the various conditions on the packet network are converted into SONET/SDH indications.
以下のセクションはパケット網に関する様々な状態がどうSonet/SDH指摘に変換されるかを論じます。
6.2.1. AIS-P Indication
6.2.1. AIS-P指示
There are several conditions in the packet network that will cause the structured CEM de-packetization function to send an AIS-P indication onto a SONET/SDH channel.
構造化されたCEM反-packetization機能がSonet/SDHチャンネルにAIS-P指示を送るパケット網にはいくつかの状態があります。
The first of these is the receipt of structured CEM packets with the N and P bits set to one, and the D-bit set to zero. This is an explicit indication of AIS-P being received at the far-end of the packet network, with DBA disabled for AIS-P. The CEM de-packetizer MUST play out the received SPE fragment (which will incidentally be carrying all ones), and MUST configure the SONET/SDH Overhead to signal AIS-P as defined in [T1.105], [G.707], and [GR-253].
これらの1番目はNがある構造化されたCEMパケットの領収書です、そして、Pビットは1つにセットしました、そして、D-ビットはゼロにセットしました。 これはパケット網の遠端で受け取られるAIS-Pの明白なしるしです、AIS-Pのために無効にされたDBAと共に。 CEM反-packetizerは、容認されたSPE断片(偶然にすべてのものを運ぶ)を展開しなければならなくて、[T1.105]、[G.707]、および[GR-253]で定義されるようにAIS-Pに合図するためにSonet/SDH Overheadを構成しなければなりません。
The second case is the receipt of structured CEM packets with the N and P bits set to one, and the D-bit set to one. This is an explicit indication of AIS-P being received at the far-end of the packet network, with DBA enabled for AIS-P. The CEM de-packetizer MUST play out one packet's worth of all ones for each packet received, and MUST configure the SONET/SDH Overhead to signal AIS-P as defined in [T1.105], [G.707], and [GR-253].
2番目のケースはNがある構造化されたCEMパケットの領収書です、そして、Pビットは1つにセットしました、そして、D-ビットは1つにセットしました。 これはパケット網の遠端で受け取られるAIS-Pの明白なしるしです、DBAがAIS-Pのために有効にされている状態で。 CEM反-packetizerは、1つのパケットの各パケットのためのあるものが受けたすべての価値を終えなければならなくて、[T1.105]、[G.707]、および[GR-253]で定義されるようにAIS-Pに合図するためにSonet/SDH Overheadを構成しなければなりません。
A third case that will cause a structured CEM de-packetization function to send an AIS-P indication onto a SONET/SDH channel is loss of packet synchronization.
構造化されたCEM反-packetization機能がSonet/SDHチャンネルにAIS-P指示を送る3番目のケースはパケット同期の損失です。
6.2.2. STS SPE Unequipped Indication
6.2.2. STS SPE Unequipped指示
There are three conditions in the packet network that will cause the CEM function to transmit STS SPE Unequipped Indications onto the SONET/SDH channel.
CEM機能がSonet/SDHチャンネルにSTS SPE Unequipped Indicationsを伝えるパケット網には3つの状態があります。
The first, which is transparent to CEM, is the receipt of regular CEM packets that happen to be carrying an SPE that contains the appropriate Path Overhead to signal STS SPE Unequipped. This case does not require any special processing on the part of the CEM de-packetizer.
第1(CEMに透明である)はたまたま信号STS SPE Unequippedに適切なPath Overheadを含むSPEを運ぶレギュラーのCEMパケットの領収書です。 本件はCEM反-packetizer側の少しの特別な処理も必要としません。
The second case is the receipt of structured CEM packets that have the D-bit set to one to indicate that DBA is active and the N and P bits set to 00 binary, 01 binary, or 10 binary to indicate STS SPE
2番目のケースは1つにD-ビットが、DBAがアクティブであることを示すように設定させる構造化されたCEMパケットの領収書です、そして、NとPビットは、STS SPEを示すために00の2進のバイナリー、01の2進のバイナリー、または10バイナリーにセットしました。
Malis, et al. Historic [Page 15] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[15ページ]RFC5143Sonet/SDHサーキットエミュレーション
Unequipped with or without pointer adjustments. The CEM de-packetizer MUST use this information to transmit a packet of all zeros onto the SONET/SDH interface, and adjust the payload pointer as necessary.
ポインタ調整のあるなしにかかわらず、Unequippedしました。 CEM反-packetizerは、Sonet/SDHインタフェースにすべてのゼロのパケットを伝えて、必要に応じてペイロードポインタを調整するのにこの情報を使用しなければなりません。
The third case when a structured CEM de-packetizer MUST send an STS SPE Unequipped Indication towards the SONET/SDH interface is when the VC-label has been withdrawn due to de-provisioning of the circuit.
構造化されたCEM反-packetizerがSonet/SDHインタフェースに向かってSTS SPE Unequipped Indicationを送らなければならないとき、3番目のケースはVC-ラベルがサーキットの反-の食糧を供給するため引っ込められた時です。
7. Clocking Modes
7. モードの時間を計ります。
It is necessary to be able to regenerate the input service clock at the output interface. Two clocking modes are supported: synchronous and asynchronous. Selection of the clocking mode is made as part of service provisioning. Both ends of the emulated circuit must be configured with the same clocking mode.
出力インタフェースで入力サービス時計を作り直すことができるのが必要です。 2つの時計モードが支持されます: 同時であって、非同期です。 サービスの食糧を供給することの一部として時計モードの選択をします。 モードの時間を計る同じくらいで見習われたサーキットの両端を構成しなければなりません。
7.1. Synchronous
7.1. 同期
When synchronous SONET/SDH timing is available at both ends of the circuit, the issue of clock recovery becomes much simpler.
同期Sonet/SDHタイミングがサーキットの両端で利用可能であるときに、時計回復の問題ははるかに簡単になります。
7.1.1. Synchronous Unstructured CEM
7.1.1. 同期不統一なCEM
For unstructured CEM, the external clock is used to clock each bit onto the optical carrier.
不統一なCEMに関しては、外部クロックは、光学キャリヤーに各ビットの時間を計るのに使用されます。
7.1.2. Synchronous Structured CEM
7.1.2. 同期構造化されたCEM
For structured CEM, the external clock is used to clock the SONET/SDH carrier. The N and P bits are used to signal negative or positive pointer adjustment events between structured CEM endpoints.
構造化されたCEMに関しては、外部クロックは、Sonet/SDHキャリヤーの時間を計るのに使用されます。 NとPビットは、構造化されたCEM終点の間の否定しているか肯定しているポインタ調整イベントに合図するのに使用されます。
If there is a frequency offset between the frame rate of the transport overhead and that of the SONET/SDH SPE, then the alignment of the SPE shall periodically slip back or advance in time through positive or negative stuffing. The N and P bits are used to replay the pointer adjustment events and eliminate transport jitter.
輸送オーバーヘッドのフレームレートとSonet/SDH SPEのものの間で相殺された頻度があれば、SPEの整列は、肯定しているか否定している詰め物を通して定期的に悪くなるものとするか、または時間内に、進むものとします。 NとPビットは、ポインタ調整出来事を再演して、輸送ジターを排除するのに使用されます。
During a negative pointer adjustment event, the H3 byte from the SONET/SDH stream is incorporated into the CEM packet payload in order with the rest of the SPE. During a positive pointer adjustment event, the stuff byte is not included in the CEM packet payload.
否定的ポインタ調整イベントの間、Sonet/SDHの流れからのH3バイトはSPEの残りで整然としているCEMパケットペイロードに組み入れられます。 積極的なポインタ調整イベントの間、もののバイトはCEMパケットペイロードに含まれていません。
The pointer adjustment event MUST be transmitted in three consecutive packets by the packetizer. The de-packetizer MUST play out the pointer adjustment event when the first packet of the three with the N/P bits set is received.
packetizerは3つの連続したパケットでポインタ調整出来事を伝えなければなりません。 ビットが設定するN/Pがある3つのものの最初のパケットが受け取られているとき、反-packetizerはポインタ調整出来事を展開しなければなりません。
Malis, et al. Historic [Page 16] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[16ページ]RFC5143Sonet/SDHサーキットエミュレーション
The CEM de-packetizer MUST utilize the CEM sequence numbers to insure that SONET/SDH pointer adjustment events are not played any more frequently than once per every three CEM packets transmitted by the remote CEM packetizer.
CEM反-packetizerは、Sonet/SDHポインタ調整出来事がもうリモートCEM packetizerによって伝えられた3つのCEMパケットあたりの一度より頻繁にプレーされないのを保障するのにCEM一連番号を利用しなければなりません。
References [T1.105], [G.707], and [GR-253] specify that pointer adjustment events MUST be separated by three SONET/SDH frames without a pointer adjustment event. In order to relay all legal pointer adjustment events, the packet size for a specific circuit MUST be no larger than (783 * 4 * N)/3, where N is the STS-Nc multiplier.
参照[T1.105]、[G.707]、および[GR-253]は、ポインタ調整出来事なしで3個のSonet/SDHフレームでポインタ調整出来事を切り離さなければならないと指定します。 すべての法的なポインタ調整出来事をリレーするために、特定のサーキットへのパケットサイズは(783*4*N)/3より大きいはずがありません。そこでは、NがSTS-Nc乗数です。
However, some SONET/SDH equipment allows pointer adjustments to occur in back-to-back SONET/SDH frames. In order to support this possibility, the packet size for a particular circuit SHOULD be no larger than (783*N)/3, where N is the STS-Nc multiplier.
しかしながら、何らかのSonet/SDH設備で、ポインタ調整は背中合わせのSonet/SDHフレームに起こります。 ノーが(783*N)/3(NはSTS-Nc乗数である)より大きかったなら、この可能性、a特定のサーキットSHOULDへのパケットサイズを支持してください。
Since the minimum value of N is one, CEM implementations SHOULD support a minimum payload length of 783/3 or 261 bytes. Smaller payload lengths MAY be supported as an option.
Nの最小値が1であるので、CEM実現SHOULDは最低783/3バイトか261バイトのペイロード長を支持します。 よりわずかなペイロード長はオプションとして支持されるかもしれません。
7.2. Asynchronous
7.2. 非同期
If synchronous timing is not available, other methods MAY be employed to regenerate the circuit timing.
シンクロナス・タイミングが利用可能でないなら、他の方法は、サーキットタイミングを作り直すのに使われるかもしれません。
For structured CEM, the CEM packetizer SHOULD generate the N and P bits as usual. However, without external synchronization, this information is not sufficient to reliably justify the SPE within the SONET/SDH transport framing at the CEM de-packetizer. The de-packetizer MAY employ an adaptive algorithm to introduce pointer adjustment events to map the CEM SPE to the SONET/SDH transport framing. Regardless of whether the N and P bits are used by the de-packetizer as part of the adaptive clock recovery algorithm, they MUST still be used in conjunction with the D-bit to signal AIS-P, STS SPE Unequipped, and DBA.
構造化されたCEMに関しては、CEM packetizer SHOULDはNと通常通りのPビットを発生させます。 しかしながら、外部同期がなければ、この情報は、Sonet/SDH輸送の中のSPEがCEM反-packetizerで縁どるのを確かに正当化するために十分ではありません。 反-packetizerは、Sonet/SDH輸送縁どりにCEM SPEを写像するためにポインタ調整出来事を導入するのに適応型のアルゴリズムを使うかもしれません。 NとPビットが適応型の時計の一部としての反-packetizer回復アルゴリズムで使用されるかどうかにかかわらず、AIS-P、STS SPE Unequipped、およびDBAに合図するのにまだD-ビットに関連してそれらを使用しなければなりません。
For unstructured CEM, the CEM de-packetizer MAY use an adaptive clock recovery technique to regenerate the SONET/SDH transport clock.
不統一なCEMに関しては、CEM反-packetizerは、Sonet/SDH輸送時計を作り直すのに適応型の時計リカバリ技術を使用するかもしれません。
An example adaptive clock recovery method can be found in section 3.4.2 of [VTOA].
.2セクション3.4[VTOA]で例の適応型の時計回復方法を見つけることができます。
8. CEM LSP Signaling
8. CEM LSPシグナリング
For maximum network scaling in MPLS applications, CEM LSP signaling may be performed using the Label Distribution Protocol (LDP) Extended Discovery mechanism as augmented by the Pseudo-Wire id Forward Error Correction (PWid FEC) Element defined in [RFC4447]. MPLS traffic
MPLSアプリケーションを計量する最大のネットワークにおいて、CEM LSPシグナリングは、[RFC4447]で定義されたPseudo-ワイヤイドForward Error Correction(PWid FEC)要素で増大するようにLabel Distributionプロトコル(自由民主党)の拡張ディスカバリーメカニズムを使用することで実行されるかもしれません。 MPLS交通
Malis, et al. Historic [Page 17] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[17ページ]RFC5143Sonet/SDHサーキットエミュレーション
tunnels may be dedicated to CEM, or shared with other MPLS-based services. The value 0x8008 is used for the PWE3 PW Type in the PWid FEC Element in order to signify that the LSP being signaled is to carry CEM. Note that the generic control word defined in [GR-253] is not used, as its functionality is included in the CEM encapsulation header.
トンネルは、CEMに捧げられるか、または他のMPLSベースのサービスと共有されるかもしれません。 合図されるLSPがCEMを運ぶことになっているのを意味して、値0x8008はPWid FEC ElementのPWE3 PW Typeに使用されます。 [GR-253]で定義された一般的な規制単語が使用されていないことに注意してください、機能性がCEMカプセル化ヘッダーに含まれているとき。
Alternatively, static label assignment may be used, or a dedicated traffic engineered LSP may be used for each CEM service.
あるいはまた、静的なラベル課題が使用されるかもしれませんか、またはひたむきな交通の設計されたLSPはそれぞれのCEMサービスに使用されるかもしれません。
Normal CEM packets are fixed in length for all of the packets of a particular emulated TDM stream. This length is signaled using the CEM Payload Bytes parameter defined in [RFC4447], or it is statically provisioned for each CEM service.
正常なCEMパケットは特定の見習われたTDMの流れのパケットのすべてのための長さで修理されています。 この長さはCEM有効搭載量Bytesパラメタが[RFC4447]、またはそれで定義した合図された使用がそれぞれのCEMサービスのために静的に食糧を供給されるということです。
At this time, other aspects of the CEM service MUST be statically provisioned.
このとき、静的に他のCEMサービスの局面に食糧を供給しなければなりません。
9. Security Considerations
9. セキュリティ問題
The CEM encapsulation is subject to all of the general security considerations discussed in [RFC3985] and [RFC4447]. In addition, this document specifies only encapsulations, and not the protocols used to carry the encapsulated packets across the PSN. Each such protocol may have its own set of security issues, but those issues are not affected by the encapsulations specified herein. Note that the security of the transported CEM service will only be as good as the security of the PSN. This level of security may be less rigorous then that available from a native TDM service due to the inherent differences between circuit-switched and packet-switched public networks.
CEMカプセル化は[RFC3985]と[RFC4447]で議論した総合証券問題のすべてを受けることがあります。 さらに、このドキュメントはPSNの向こう側に要約のパケットを運ぶのに使用されるプロトコルではなく、カプセル化だけを指定します。 そのような各プロトコルには、それ自身の安全保障問題のセットがあるかもしれませんが、それらの問題はここに指定されたカプセル化で影響を受けません。 輸送されたCEMサービスのセキュリティが単にPSNのセキュリティと同じくらい良いことに注意してください。 このレベルのセキュリティはその時、それほどサーキットで切り換えられてパケットで切り換えられた公衆通信回線の固有の違いによるネイティブのTDMサービスによってそんなに利用可能な状態で厳しくないかもしれません。
10. IANA Considerations
10. IANA問題
IANA has already allocated the PWE3 PW Type value 0x0008 for this specification. No further actions are required.
IANAはこの仕様のために既にPWE3 PW Type値0x0008を割り当てました。 さらなる動作は全く必要ではありません。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[G.707] ITU Recommendation G.707, "Network Node Interface For The
Synchronous Digital Hierarchy", 1996.
[G.707]ITU推薦G.707、「同期デジタルハイアラーキのためのネットワーク・ノードインタフェース」、1996。
[GR-253] Telcordia Technologies, "Synchronous Optical Network
(SONET) Transport Systems: Common Generic Criteria", GR-
253-CORE, Issue 3, September 2000.
[GR-253]Telcordia技術、「同期式光通信網(Sonet)はシステムを輸送します」。 「一般的な一般的な評価基準」(GRの253コア)は3、2000年9月を発行します。
Malis, et al. Historic [Page 18] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[18ページ]RFC5143Sonet/SDHサーキットエミュレーション
[I.363.1] ITU-T, "Recommendation I.363.1, B-ISDN Adaptation Layer
Specification: Type AAL1", Appendix III, August 1996.
[I.363.1]ITU-T、「推薦I.363.1、B-ISDN適合は仕様を層にします」。 1996年8月にAAL1"、付録IIIをタイプしてください。
[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月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023] エドオースター、T.、Rekhter、Y.、およびE.ローゼン、「IPか一般ルーティングのカプセル化(GRE)でMPLSを要約する」RFC4023(2005年3月)。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]マティーニ、L.(エド)、ローゼン、E.、高架鉄道-Aawar、N.、スミス、T.、およびG.サギ、「ラベル分配を使用するPseudowireセットアップと維持が(自由民主党)について議定書の中で述べます」、RFC4447、2006年4月。
[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
"Synchronous Optical Network/Synchronous Digital
Hierarchy (SONET/SDH) Circuit Emulation over Packet
(CEP)", RFC 4842, April 2007.
[RFC4842]MalisとA.と頭とP.とコーエン、R.(エド)とD.カメレオンマン、「パケット(CEP)の上の同期式光通信網/同期デジタルハイアラーキ(Sonet/SDH)サーキットエミュレーション」RFC4842(2007年4月)。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding
Equal Cost Multipath Treatment in MPLS Networks", BCP
128, RFC 4928, June 2007.
[RFC4928]のツバメ、G.、ブライアント、S.、およびL.アンデション、「同輩を避けるのはMPLSネットワークで多重通路処理かかりました」、BCP128、RFC4928、2007年6月。
[T1.105] American National Standards Institute, "Synchronous
Optical Network (SONET) - Basic Description including
Multiplex Structure, Rates and Formats," ANSI T1.105-
1995.
[T1.105]American National Standards Institut、「同期式光通信網(Sonet)--Multiplex Structureを含む基本的な記述、RatesとFormats、」、ANSI T1.105 1995
[VTOA] ATM Forum, "Circuit Emulation Service Interoperability
Specification Version 2.0", af-vtoa-0078.000, January
1997.
[VTOA]ATM Forum、「サーキットエミュレーションは1997年1月に相互運用性仕様バージョン2インチ、af-vtoa-0078.000を調整します」。
11.2. Informative References
11.2. 有益な参照
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S.、エド、P.頭、エド、「疑似ワイヤのエミュレーションの縁から縁(PWE3)への構造」、RFC3985、3月2005日
Malis, et al. Historic [Page 19] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[19ページ]RFC5143Sonet/SDHサーキットエミュレーション
Appendix A. SONET/SDH Rates and Formats
付録A.Sonet/SDHレートと形式
For simplicity, the discussion in this section uses SONET terminology, but it applies equally to SDH as well. SDH-equivalent terminology is shown in the tables.
簡単さのために、このセクションでの議論はSonet用語を使用しますが、それは等しくまた、SDHに適用されます。 SDH同等な用語はテーブルに示されます。
The basic SONET modular signal is the synchronous transport signal-level 1 (STS-1). A number of STS-1s may be multiplexed into higher-level signals denoted as STS-N, with N synchronous payload envelopes (SPEs). The optical counterpart of the STS-N is the Optical Carrier-level N, or OC-N. Table 2 lists standard SONET line rates discussed in this document.
基本のSonetモジュールの信号は同期輸送信号レベル1(STS-1)です。 STS-NとしてN同期ペイロード封筒(SPEs)で指示されたよりハイレベルの信号に多くのSTS-1sを多重送信するかもしれません。 STS-Nの可視対照物は、Optical Carrier-レベルN、またはOC-Nです。 テーブル2は本書では議論した標準のSonetライン料率を記載します。
OC Level OC-1 OC-3 OC-12 OC-48 OC-192 SDH Term - STM-1 STM-4 STM-16 STM-64 Line Rate(Mb/s) 51.840 155.520 622.080 2,488.320 9,953.280
OCの平らなOC-1 OC-3 OC-12 OC-48 OC-192 SDH用語--STM-1 STM-4 STM-16 STM-64ライン料率(Mb/s)51.840 155.520 622.080 2,488.320 9,953.280
Table 2. Standard SONET Line Rates
2を見送ってください。 標準のSonetライン料率
Each SONET frame is 125 us and consists of nine rows. An STS-N frame has nine rows and N*90 columns. Of the N*90 columns, the first N*3 columns are transport overhead and the other N*87 columns are SPEs. A number of STS-1s may also be linked together to form a super-rate signal with only one SPE. The optical super-rate signal is denoted as OC-Nc, which has a higher payload capacity than OC-N.
そして、それぞれのSonetフレームが125である、私たち、9つの列から成ります。 STS-Nフレームには、9つの列とN*90のコラムがあります。 N*90のコラムでは、最初のN*3つのコラムが輸送オーバーヘッドです、そして、他のN*87のコラムがSPEsです。 また、多くのSTS-1sが、1SPEだけと共に超レート信号を形成するために結びつけられるかもしれません。 光学超レート信号はOC-Ncとして指示されます。(OC-NcはOC-Nより高いペイロード容量を持っています)。
The first 9-byte column of each SPE is the Path Overhead (POH) and the remaining columns form the payload capacity with fixed stuff (STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1 columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed stuff, STS-12c has three columns of fixed stuff, and so on.
それぞれのSPEの最初の9バイトのコラムはPath Overhead(POH)です、そして、残っているコラムは固定もの(STS-Nc専用)でペイロード容量を形成します。 固定もの(純粋に頭上にある)はSTS-NcのためのN/3-1のコラムです。 STS-12cには、したがって、STS-1とSTS-3cにどんな固定ものもなくて、3つのコラムの固定ものなどがあります。
The POH of an STS-1 or STS-Nc is always nine bytes in nine rows. The payload capacity of an STS-1 is 86 columns (774 bytes) per frame. The payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame. Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340 bytes per frame. As another example, the payload capacity of an STS-192c is 149,760 bytes, which is exactly 64 times larger than the STS-3c.
いつもSTS-1かSTS-NcのPOHは9つの列の9バイトです。 1フレームあたりSTS-1のペイロード容量は86のコラム(774バイト)です。 STS-Ncのペイロード容量は(N*87)です--1フレームあたり(N/3)コラム。 したがって、STS-3cのペイロード容量は*1フレームあたり9 = 2,340バイト(3*87--1)です。 別の例として、STS-192cのペイロード容量は14万9760バイトです。(そのバイトはまさにSTS-3cより64倍大きいです)。
There are 8,000 SONET frames per second. Therefore, the SPE size, (POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112 Mb/s. The SPE size of a concatenated STS-3c is 2,349 bytes per frame or 150.336 Mb/s. The payload capacity of an STS-192c is 149,760 bytes per frame, which is equivalent to 9,584.640 Mb/s. Table 3 lists the SPE and payload rates supported.
1秒あたり8,000個のSonetフレームがあります。 したがって、STS-1のSPEサイズと、(POHとペイロード容量)は783*8*8,000 = 50.112Mb/sです。 連結されたSTS-3cのSPEサイズは1フレームあたりのバイトか150.336Mb/s2,349です。 1フレームあたりSTS-192cのペイロード容量は14万9760バイトです。(それは、9,584.640Mb/sに同等です)。 テーブル3はレートが支えたSPEとペイロードを記載します。
Malis, et al. Historic [Page 20] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[20ページ]RFC5143Sonet/SDHサーキットエミュレーション
SONET STS Level STS-1 STS-3c STS-12c STS-48c STS-192c SDH VC Level - VC-4 VC-4-4c VC-4-16c VC-4-64c Payload Size(Bytes) 774 2,340 9,360 37,440 149,760 Payload Rate(Mb/s) 49.536 149.760 599.040 2,396.160 9,584.640 SPE Size(Bytes) 783 2,349 9,396 37,584 150,336 SPE Rate(Mb/s) 50.112 150.336 601.344 2,405.376 9,621.504
STS-1 STS-3c STS-12c STS-48c STS-192c SDH VCが平らにするSonet STSレベル--VC-4 VC-4-4c VC-4-16c VC-4-64c有効搭載量サイズ(バイト)774 2,340 9,360 37,440 149,760有効搭載量レート(Mb/s)49.536 149.760 599.040 2,396.160 9,584.640SPEサイズ(バイト)783 2,349 9,396 37,584 150,336SPEレート(Mb/s)50.112 150.336 601.344 2,405.376 9,621.504
Table 3. Payload Size and Rate
3を見送ってください。 有効搭載量サイズとレート
To support circuit emulation, the entire SPE of a SONET STS or SDH VC level is encapsulated into packets, using the encapsulation defined in section 5, for carriage across packet-switched networks.
サーキットエミュレーションを支持するために、SONET STSかSDH VCレベルの全体のSPEはパケットに要約されます、セクション5で定義されたカプセル化を使用して、パケット交換網の向こう側のキャリッジのために。
Appendix B. ECC-6 Definition
付録B.ECC-6定義
ECC-6 is an Error Correction Code to protect the CEM header. This provides single bit correction and the ability to detect up to two bit errors.
ECC-6はCEMヘッダーを保護するError Correction Codeです。 これはただ一つの噛み付いている修正と最大2ビットの誤りを検出する能力を提供します。
Error Correction Code:
エラー修正コード:
|---------------Header bits 0-25 -------------------| ECC-6 code|
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 0 0 0 1 0 0 0 1 1 1 1 1 0 1 0 0 0 1 0 1 1|1 0 0 0 0 0|
|1 1 1 1 0 1 0 0 0 1 0 0 1 0 0 0 0 1 0 1 1 1 1 1 1 1|0 1 0 0 0 0|
|1 0 0 0 1 1 1 1 0 0 1 0 1 1 1 0 0 0 1 1 1 1 0 0 1 1|0 0 1 0 0 0|
|0 1 0 0 1 1 1 1 0 0 0 1 1 0 0 1 1 1 1 1 0 0 1 1 0 1|0 0 0 1 0 0|
|0 0 1 0 0 0 1 0 1 1 1 1 1 1 0 0 1 1 1 1 1 0 1 0 1 0|0 0 0 0 1 0|
|0 0 0 1 0 0 0 1 1 1 1 1 0 0 1 1 0 0 1 1 0 1 1 1 1 1|0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|---------------ヘッダービット0-25-------------------| ECC-6コード| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 0 0 0 1 0 0 0 1 1 1 1 1 0 1 0 0 0 1 0 1 1|1 0 0 0 0 0| |1 1 1 1 0 1 0 0 0 1 0 0 1 0 0 0 0 1 0 1 1 1 1 1 1 1|0 1 0 0 0 0| |1 0 0 0 1 1 1 1 0 0 1 0 1 1 1 0 0 0 1 1 1 1 0 0 1 1|0 0 1 0 0 0| |0 1 0 0 1 1 1 1 0 0 0 1 1 0 0 1 1 1 1 1 0 0 1 1 0 1|0 0 0 1 0 0| |0 0 1 0 0 0 1 0 1 1 1 1 1 1 0 0 1 1 1 1 1 0 1 0 1 0|0 0 0 0 1 0| |0 0 0 1 0 0 0 1 1 1 1 1 0 0 1 1 0 0 1 1 0 1 1 1 1 1|0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. ECC-6 Check Matrix X
図7。 ECC-6チェック・マトリクスX
The ECC-6 code protects the 32-bit CEM header as follows:
ECC-6コードは以下の32ビットのCEMヘッダーを保護します:
The encoder generates the 6-bit ECC using the matrix shown in Figure 7. In brief, the encoder builds another 26 column by 6 row matrix and calculates even parity over the rows. The matrix columns represent CEM header bits 0 through 25.
エンコーダは、図7で見せられたマトリクスを使用することで6ビットのECCを発生させます。 要するに、エンコーダは、6列のマトリクスで別の26コラムを築き上げて、列に関して同等さえ計算します。 マトリクスコラムは0〜25にCEMヘッダービットを表します。
Denote each column of the ECC-6 check matrix by X[], and each column of the intermediate encoder matrix as Y[]. CEM[] denotes the CEM header and ECC[] is the error correction code that is inserted into CEM header bits 26 through 31.
Y[]としてX[]によるECC-6チェック・マトリクスに関する各コラム、および中間的エンコーダマトリクスに関する各コラムを指示してください。 CEM[]はCEMヘッダーを指示します、そして、ECC[]は26〜31にCEMヘッダービットに挿入されるエラー修正コードです。
Malis, et al. Historic [Page 21] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[21ページ]RFC5143Sonet/SDHサーキットエミュレーション
for i = 0 to 25 {
if CEM[i] = 0 {
Y[i] = 0;
} else {
Y[i] = X[i];
}
}
0〜i=25のためにCEM[i]=0である、Y[i]=0;、ほか、Y[i]=X[i]。
In other words, for each CEM header bit (i) set to one, set the resulting matrix column Y[i] according to Figure 7.
言い換えれば、図7に従って、1つに設定されたそれぞれのCEMヘッダービット(i)に結果として起こるマトリクスコラムY[i]を設定してください。
The final ECC-6 code is calculated as even parity of each row in Y (i.e., ECC[k]=CEM[25+k]=even parity of row k).
最終的なECC-6コードはYのそれぞれの列の同等としてさえ計算されます(すなわち、ECC[k]=CEM[25+k]は列kの同等とさえ等しいです)。
The receiver also uses matrix X to calculate an intermediate matrix Y' based on all 32 bits of the CEM header. Therefore, Y' is 32 columns wide and includes the ECC-6 code.
'また、受信機は中間的マトリクスYを計算するのにマトリクスXを使用すること'がCEMヘッダーのビットをすべての32に基礎づけました。 'したがって、Y'は、広く32のコラムであり、ECC-6コードを含んでいます。
for i = 0 to 31 {
if CEM[i] = 0 {
Y'[i] = 0;
} else {
Y'[i] = X[i];
}
}
0〜i=31のためにCEM[i]=0である、Y'[i]=0;、ほか、Y'[i]=X[i]。
The receiver then appends the incoming ECC-6 code to Y as column 32 (ECC[0] should align with row 0) and calculates even parity for each row. The result is a single 6-bit column Z. If all 6 bits are 0, there are no bit errors (or at least no detectable errors). Otherwise, it uses Z to perform a reverse lookup on X[] from Figure 7. If Z matches column X[i], then there is a single bit error. The receiver should invert bit CEM[i] to correct the header. If Z fails to match any column of X, then the CEM header contains more than one bit error and the CEM packet MUST be discarded.
受信機は、次に、コラム32(ECC[0]は列0に並ぶべきです)として入って来るECC-6コードをYに追加して、各列に同等さえ計算します。 結果はただ一つの6ビットのコラムZ.Ifに、すべての6ビットが0である、誤り(または、少なくとも検出可能な誤りがない)が噛み付かれないということです。 さもなければ、それは、図7からX[]に逆のルックアップを実行するのにZを使用します。 ZがコラムX[i]に合っているなら、誤りが1ビットあります。 受信機は、ヘッダーの誤りを正すためにビットCEM[i]を逆にするはずです。 ZがどんなコラムのXにも合っていないなら、CEMヘッダーは1ビット以上の誤りを含んでいます、そして、CEMパケットを捨てなければなりません。
Note that the ECC-6 code provides single-bit correction and 2-bit detection of errors within the received ECC-6 code itself.
ECC-6コードが容認されたECC-6コード自体の中で誤りの単一のビット修正と2ビットの検出を提供することに注意してください。
Malis, et al. Historic [Page 22] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[22ページ]RFC5143Sonet/SDHサーキットエミュレーション
Acknowledgments
承認
The authors would like to thank Mitri Halabi, Bob Colvin, and Ken Hsu, all formerly of Vivace Networks and Tellabs; Tom Johnson, Marlene Drost, Ed Hallman, and Dave Danenberg, all formerly of Litchfield Communications, for their contributions to the document.
作者がMitriハラビィ、ボブ・コルビン、およびケン・シューに感謝したがっている、すべて、以前、Vivace NetworksとTellabsについて。 トム・ジョンソン、マルレーヌ・ドロスト、エドHallman、そして、デーヴDanenberg、すべて、以前、ドキュメントへの彼らの貢献のためのリッチフィールドCommunicationsについて。
Authors' Addresses
作者のアドレス
Andrew G. Malis Verizon Communications 40 Sylvan Road Waltham, MA 02451 EMail: andrew.g.malis@verizon.com
ウォルサム、アンドリューG.Malisベライゾンコミュニケーション40の森のRoad MA 02451はメールされます: andrew.g.malis@verizon.com
Jeremy Brayley ECI Telecom Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 EMail: jeremy.brayley@ecitele.com
ジェレミー・Brayley ECI電子通信株式会社オメガ法人のセンター1300オメガDriveピッツバーグ、PA 15205はメールされます: jeremy.brayley@ecitele.com
John Shirron ECI Telecom Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 EMail: john.shirron@ecitele.com
ジョン・Shirron ECI電子通信株式会社オメガ法人のセンター1300オメガDriveピッツバーグ、PA 15205はメールされます: john.shirron@ecitele.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 EMail: lmartini@cisco.com
ルカマティーニシスコシステムズ, Inc.9155のEastニコルズAvenue、イングルウッド、Suite400CO 80112はメールされます: lmartini@cisco.com
Steve Vogelsang Alcatel-Lucent 600 March Road Kanata, ON K2K 2T6 Canada EMail: steve.vogelsang@alcatel-lucent.com
K2K 2T6カナダメールのスティーブ・フォーゲルザングアルカテル透明な600 3月の道路Kanata: steve.vogelsang@alcatel-lucent.com
Malis, et al. Historic [Page 23] RFC 5143 SONET/SDH Circuit Emulation over MPLS February 2008
Malis、他 MPLS2008年2月の間の歴史的な[23ページ]RFC5143Sonet/SDHサーキットエミュレーション
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Malis, et al. Historic [Page 24]
Malis、他 歴史的[24ページ]
一覧
スポンサーリンク
