[要約] 要約:RFC 5143は、MPLS(Multi-Protocol Label Switching)を介したSONET/SDH回路エミュレーションサービス(CEM)のカプセル化に関する規格です。 目的:このRFCの目的は、SONET/SDH回路をMPLSネットワーク上でエミュレートするためのカプセル化方法を提供することです。

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
        

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.

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には、MPLとIPが含まれます。RFC 4842は、この機能の標準トラックプロトコルを説明しており、新しい実装は、古い実装との相互運用性が必要な場合を除き、このドキュメントではなくRFC 4842を使用する必要があることに注意してください。

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. Introduction
1. はじめに

This document describes a historical method for encapsulating SONET/SDH Path signals for transport across packet-switched networks (PSNs).

このドキュメントでは、パケットスイッチネットワーク(PSNS)を横切る輸送のためのSONET/SDHパス信号をカプセル化するための履歴方法について説明します。

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].

回路指向の時刻分割多重化(TDM)信号のネイティブトランスミッションシステムは、同期光ネットワーク(SONET)[T1.105]、[GR-253]/同期デジタル階層(SDH)[G.707]です。TDMトラフィック(音声、データ、プライベートリースラインサービスを含む)をサポートするには、PSNSはSONET/SDHペイロードの回路特性をエミュレートする必要があります。MPLSラベルと新しい回路エミュレーションヘッダーは、TDM信号をカプセル化し、MPLS(CEM)関数を介した回路エミュレーションサービスを提供するために使用されます。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.

このドキュメントでは、動的帯域幅割り当て(DBA)と呼ばれるCEMのオプションの拡張機能についても説明しています。これは、パケットネットワーク内のエミュレートされたSONET/SDH回路によって使用される帯域幅を動的に削減する方法です。この帯域幅の削減は、アラーム表示信号 - パス(AIS -P)または同期輸送信号同期ペイロードエンベロープ(STS SPE)などの特定の条件下でパケットネットワークを介してSONET/SDHペイロードを送信しないことで実現されます。

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].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.

For the remainder of this document, these constructs will be referred to as SONET/SDH channels.

このドキュメントの残りの部分では、これらのコンストラクトはSONET/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.

仮想支流(VT)構造化されたサブレートマッピングなどの他のSONET/SDH信号については、このドキュメントでは明示的に説明していません。ただし、VTおよびより低い速度の非ソネット/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 SPEをパケット指向のネットワークを介して輸送するために、SPEはフラグメントに分割されます。32ビットのCEMヘッダーは、各フラグメントにプリペンドされています。基本的なCEMパケットが図1に表示されます。

   +-----------------------------------+
   |            CEM Header             |
   +-----------------------------------+
   |                                   |
   |                                   |
   |        SONET/SDH SPE Fragment     |
   |                                   |
   |                                   |
   +-----------------------------------+
        

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   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

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モードを信号します。通常の動作の場合はゼロに設定する必要があり、CEMが現在DBAモードにある場合は1に設定する必要があります。DBAは、些細なSPEがパケットネットワークに送信されないオプションモードです。詳細については、表1とセクション7および8を参照してください。

Note: for unstructured CEM, the D-bit MUST be set to zero.

注:非構造化されたCEMの場合、Dビットをゼロに設定する必要があります。

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(リモート欠陥インジケーター)。このビットは、パケット同期の損失が発生したことをリモートCEM関数に信号するために1に設定されています。

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まで継続的にサイクリングする必要があります。CEMLSP(ラベルスイッチ付きパス)が作成されたときにゼロから始まる必要があります。

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.

構造ポインター:構造ポインターには、CEMペイロード内のJ1バイトのオフセットを含める必要があります。値は0〜1,022で、0はCEMヘッダーの後の最初のバイトを意味します。パケットがJ1バイトを運ばない場合、構造ポインターを0x3ff(1,023)に設定する必要があります。J1バイトとSONET/SDHペイロードポインターの詳細については、[T1.105]、[G.707]、および[GR-253]を参照してください。

Note: for unstructured CEM, the Structure Pointer field MUST be set to 0x3FF.

注:構造化されていないCEMの場合、構造ポインターフィールドは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メンテナンス信号を中継するためにも使用されます。詳細については、表1とセクション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                          |
   +---+---+---+-------------+--------------------------------+
        

Table 1. Interpretation of D, N, and P bits 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.

表1. D、N、およびP BITS ECC-6の解釈:CEMヘッダーを保護するためのエラー修正コード。これにより、シングルビットエラーを修正し、最大2つのビットエラーを検出できます。ECCアルゴリズムは付録Bで説明しています。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ペイロードバイトパラメーターを使用して信号されるか、各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.

注:Dビットを0に設定し、Rビットを1に設定すると、MPLSネットワークで操作する際に[RFC4928]で定義された最良の現在のプラクティスに違反します。この状況では、MPLSネットワークは、CEMペイロードをIPv4パケットの最初のニブルと間違え、MPLSネットワークのIP等コストマルチパス(ECMP)の存在下で擬似ワイヤーでパケットを誤って注文する可能性があります。この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パケットは、パケット指向のネットワーク上で輸送できます。次のセクションでは、MPLSまたはIPネットワークを介した輸送のためにCEMパケットをカプセル化する方法を具体的に説明しています。

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パケットを輸送するには、MPLSラベルスタックをCEMパケットの上に押し込む必要があります。

The last two labels prior to the CEM header are referred to as the Tunnel and Virtual Circuit (VC) labels.

CEMヘッダーの前の最後の2つのラベルは、トンネルおよび仮想回路(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ヘッダーの前の最後のラベルです。VCラベルは、MPLSトンネル内のCEM接続を識別するために使用する必要があります。

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]で定義されているラベルスタック使用量に似ています。

   +-----------------------------------+
   | Additional MPLS Labels (Optional) |
   +-----------------------------------+
   |       Tunnel Label (Optional)     |
   +-----------------------------------+
   |             VC Label              |
   +-----------------------------------+
   |            CEM Header             |
   +-----------------------------------+
   |                                   |
   |                                   |
   |       SONET/SDH SPE Fragment      |
   |                                   |
   |                                   |
   +-----------------------------------+
        

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にマッピングして、CEMをIPに直接マッピングすることです。

A mechanism for carrying MPLS over IP is described in [RFC4023].

MPLSをIPに携帯するメカニズムは[RFC4023]に記載されています。

Using this encapsulation scheme would result in the packet format illustrated in Figure 4.

このカプセル化スキームを使用すると、図4に示されているパケット形式が表示されます。

   +-----------------------------------+
   |                                   |
   |    IPv6/v4 Header [RFC4023]       |
   |                                   |
   +-----------------------------------+
   |      Tunnel Label (Optional)      |
   +-----------------------------------+
   |             VC Label              |
   +-----------------------------------+
   |            CEM Header             |
   +-----------------------------------+
   |                                   |
   |                                   |
   |       SONET/SDH SPE Fragment      |
   |                                   |
   |                                   |
   +-----------------------------------+
        

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).

非構造化されたCEMは、SONET/SDHビットストリーム全体(輸送オーバーヘッドを含む)全体をパケット化します。

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)をパケット化します。構造化されたCEMが輸送オーバーヘッドを終了するため、構造化されたCEM実装は、[T1.105]、[G.707]、および[GR-253]で定義されているSONET/SDHライン終端機器の一般的な要件を満たす必要があります。

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 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.

構造化されたCEMは、通常の動作モードをサポートする必要があり、動的帯域幅割り当て(DBA)と呼ばれるオプションの拡張機能をサポートする場合があります。通常の操作中、SONET/SDHペイロードは断片化され、CEMヘッダー、VCラベル、およびPSNヘッダーで事前に塗装され、パケットネットワークに送信されます。DBAモード中に、CEMヘッダー、VCラベル、およびPSNヘッダーのみが送信されます。これは、AIS-PやSTS SPEの装備中など、意味のあるユーザーデータがSPEに存在しない場合に帯域幅を節約するために行われます。

5.1.1. CEM Packetizer and De-Packetizer
5.1.1. CEMパケット装置とパックタイザー

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つの異なるコンポーネントがあります。TDMSONET/SDHをCEMパケットストリームに適応させ、CEMパケットストリームをTDM SONET/SDHに戻すことです。最初の関数はCEMパックタイザーと呼ばれ、2番目はCEM de-packetizerと呼ばれます。この用語を図5に示します。

             +------------+              +---------------+
             |            |              |               |
   SONET --> |    CEM     | --> PSN  --> |      CEM      | --> SONET
    SDH      | Packetizer |              | De-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 de-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は、AIS-PやSTS SPEの装備などの特定の状況下で、CEMヘッダー、VCラベル、PSNヘッダーのみをパケットネットワークに送信する構造化されたCEMのオプションの動作モードです。

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実装によってサポートされている場合、ユーザーはDBAがAIS-P、STS SPEの両方、または両方のチャネルベースでトリガーされるかどうかを構成できる必要があります。

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の装備の決定は、SONET/SDHセクション、ライン、およびパスオーバーヘッドバイトの状態に基づいている必要があります。SPE内のパターン検出に基づくDBA(つまり、すべてのゼロ、7ES、またはATMアイドルセル)は、さらなる研究のためです。

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の装備中は、SONET/SDHペイロードポインターが有効であるため、DBA中でもポインター調整をサポートする必要があります。詳細については、表1を参照してください。

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パケットはSONET/SDHインターフェイスから固定レートバイトストリームを受け取ります。SONET/SDHチャネルからパケットのデータを受け取った場合、CEMヘッダー、VCラベル、およびPSNヘッダーがSPEフラグメントにプリペートされ、結果のCEMパケットがパケットネットワークに送信されます。特定のSONET/SDHチャネルに関連付けられたすべての通常のCEMパケットは同じ長さであるため、そのチャネルの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 de-Packetizerはパケットをジッターバッファーに受け取り、対応するSONET/SDHチャネルに固定レートで受信バイトストリームを再生します。ジッターバッファーは、さまざまなネットワーク遅延動作を考慮して、長さが調整可能である必要があります。パケットネットワークからの受信したパケットレートは、平均して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 de-packetizerは、紛失または誤った順序パケットを検出する必要があります。CEM de-packetizerは、ドロップされたパケットの代わりにプログラム可能なバイトパターンを再生する必要があります。CEM de-packetizerは、受信したパケットを順不同で再注文する場合があります。CEM de-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の内外での遷移を、パケットネットワークの向こう側にあるローカルCEMパケット装置とCEMデパックテザーとの間で緊密に調整する必要があることです。3番目は、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.

もう1つの目標は、DBAによるCEMトラフィックの削減が、パケットネットワークの障害や逆と間違えられてはならないということです。最後に、DBAの実装には、名目CEMケースに必要なものを超える最小限の変更が必要になります。以下で説明するメカニズムは、これらの目標の合理的なバランスです。

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の間、パケットは通常の操作中とまったく同じ速度で放出する必要があります。これは、SONET/SDHチャネルからデータの完全なパケットが受信された後、各DBAパケットを送信することで実現する必要があります。通常の操作からの唯一の変更は、DBA中の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パケットはCEMヘッダーの直後に構成可能な数のバイト数を追加してCEMパケットをパッドアウトして、サポートされている最小パケットサイズに到達する場合があります。パディングバイトの値は実装固有です。DBAがアクティブであることを示すために、Dビットを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 de-packetizerは、Dビットセットで受信した各パケットが、NおよびPで記載されているようにAIS-PまたはSTS SPE未装備のペイロードを含む通常のサイズのパケットを表すと想定する必要があります(表1を参照)。CEM de-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パケット化と脱パケット化ロジックは、名目上のケースと同様になります。正しい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デパックテッターがパケットの同期内外であるかどうかです。次の段落では、その決定がどのように行われるかを説明しています。

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 de-Packetizerはデフォルトでパケットの同期から外れます。スタートアップ時またはパケットの同期を失った後にパケットの同期を宣言するには、CEM de-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 de-packetizerがパケット同期すると、パケットの同期を失う原因となる一連のイベントに遭遇する可能性があります。

As discussed in section 5.2, a CEM de-packetizer MAY support the re-ordering of mis-ordered packets.

セクション5.2で説明したように、CEM de-packetizerは、誤った順序パケットの再注文をサポートする場合があります。

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 de-packetizerが再注文をサポートする場合、パケットがPSNから受信された時点でパケットの同期が失われたという決定を下すことはできません。代わりに、パケットがSONET/SDHインターフェイスに再生されているため、決定を下す必要があります。これは、エミュレートされたSONET/SDHストリーム全体がPSNから受信されたかどうかを決定できるのは、プレイアウトの時だけであるためです。

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 de-Packetizerが再注文をサポートしていない場合、最終的な再組み立てされたSonet/SDHストリームに対する誤った秩序化または失われたパケットの影響を最小限に抑えるために、多くのアプローチを使用することができます。たとえば、ATM適応層1(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.

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つのグループに分割されます:SONET/SDHからPSN、SONET/SDHからPSN。

6.1. SONET/SDH to PSN
6.1. SONET/SDHからPSN

The following sections describe how SONET/SDH Maintenance Signals and Alarm conditions are mapped into a Packet-Switched Network.

次のセクションでは、SONET/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ネットワークでは、SONET/SDHパスの停止は、PATH AIS(AIS-P)などのメンテナンスアラームを使用してシグナル伝えられます。特に、AIS-Pは、SONET/SDHパスが現在有効なエンドユーザーデータを送信していないことを示しており、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.

The SONET/SDH hierarchy is illustrated below.

SONET/SDH階層を以下に示します。

                              +----------+
                              |   PATH   |
                              +----------+
                                   ^
                                   |
                                 AIS-P
                                   |
                                   |
                              +----------+
                              |   LINE   |
                              + ---------+
                                 ^     ^
                                 |     |
                               AIS-L   +------ LOP
                                 |
                                 |
                              +----------+
                              | SECTION  |
                              +----------+
                                 ^    ^
                                 |    |
                                 |    |
                                LOS  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.

セクション層が信号の損失(LOS)またはフレームの損失(LOF)条件を検出した場合、AIS-Lをラインレイヤーに送信します。ラインレイヤーがAIS-Lまたはパスの損失(LOP)を検出すると、AIS-Pをパス層に送信します。

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 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.

AIS-Pの通常モードでは、通常どおり構造化されたCEMパケットが生成されます。NおよびPビットは、パケットネットワークを介してAIS-Pを明示的に信号を送るために11バイナリに設定する必要があります。SPEがパケットネットワークを介して運ばれていることを示すために、D-BITをゼロに設定する必要があります。SPEフラグメント、CEMヘッダー、VCラベル、およびPSNヘッダーを備えた通常のCEMパケットをパケットネットワークに送信する必要があります。

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が採用される場合があります。AIS-PでDBAが有効になっており、AIS-Pが現在発生している場合、NおよびPビットを11バイナリに設定してAISを信号し、D-BITを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).

また、これは[RFC4447]の停止メカニズムとは異なることに注意してください。これは、エンドポイントの停止の結果としてVCラベルを引き出します。TDM回路エミュレーションには、回路の脱プロビジョン(VCラベルが引き出される)と一時的な停止(AIS-Pを使用してシグナル伝達される)を区別する機能が必要です。

6.1.2. STS SPE Unequipped Indication
6.1.2. sts spe未装備の兆候

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未装備の兆候は、AIS-Pとわずかに異なるケースです。パスオーバーヘッド(STSパス信号ラベル)のバイトC2が00Hで、BYTE B3(STS PATH BIP-8)が有効である場合、STS SPEが装備されていないことを示します。注:これは通常、SPE全体をZerosに設定することにより通知されます。

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未装備中の通常の構造化されたCEM操作の場合、NおよびPビットは通常どおり解釈する必要があります。SPEは、CEMヘッダー、VCラベル、およびPSNヘッダーとともにパケットネットワークに送信する必要があり、D-BITはゼロに設定する必要があります。

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.

STS SPEの装備でDBAが有効になり、SONET/SDHチャネルで装備されていない状態が発生している場合、DBAがアクティブであることを示すためにDビットを1つに設定する必要があります。CEMヘッダー、VCラベル、およびPSNヘッダーのみをパケットネットワークに送信する必要があります。NおよびPビットは、通常どおりポインター調整を信号するために使用する必要があります。詳細については、表1とセクション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関数は、パケットの同期を失ったときにPacketネットワークにCEM-RDIを送信する必要があります。これは、RビットをCEMヘッダーの1つに設定することで実現する必要があります。これは、構造化されたCEMと非構造化CEMの両方に適用されます。

6.2. PSN to SONET/SDH
6.2. PSNからSONET/SDHへ

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脱パケット化関数がSOIS-P適応症をSONET/SDHチャネルに送信するようにするいくつかの条件があります。

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].

これらの最初のものは、nとpビットが1に設定された構造化されたCEMパケットの受領、dビットがゼロに設定されていることです。これは、Packetネットワークの遠端でAIS-Pが受信されたことを明確に示しており、DBAはAIS-Pを無効にしています。CEM de-packetizerは、受信したSPEフラグメント(偶然すべてのものを運ぶ)を再生し、[T1.105]、[G.707]で定義されているようにAIS-Pを信号にするようにSONET/SDHオーバーヘッドを構成する必要があります。および[GR-253]。

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およびPビットを1つに設定した構造化されたCEMパケットの受領、Dビットは1に設定されています。これは、AIS-PがAIS-Pを有効にして、パケットネットワークの遠端でAIS-Pが受信されることを明確に示しています。CEM de-packetizerは、受信した各パケットに対してすべてのパケットの1つの価値を再生する必要があり、[T1.105]、[G.707]、および[GRで定義されているようにAIS-Pを信号にするようにSONET/SDHオーバーヘッドを構成する必要があります。-253]。

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脱パケット関数を引き起こす3番目のケースは、SONET/SDHチャネルにAIS-Pの表示を送信します。パケット同期の喪失です。

6.2.2. STS SPE Unequipped Indication
6.2.2. sts spe未装備の兆候

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関数がSTS SPE未装備の適応症をSONET/SDHチャネルに送信する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.

CEMに透過的な最初のものは、SPEを備えていないSTSを信号するための適切なパスオーバーヘッドを含むSPEを運ぶことができる通常のCEMパケットの受領です。このケースでは、CEM de-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 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.

2番目のケースは、DBAがアクティブであることを示すためにDビットが1に設定されている構造化されたCEMパケットの受領と、00バイナリ、01バイナリ、または10バイナリに設定されているnおよびpビットがspe spe spe in rediteを示す10バイナリに設定したことです。ポインター調整。CEM de-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 de-PacketizerがSONET/SDHインターフェイスに向けてSTS SPE未装備の適応症を送信する必要がある場合の3番目のケースは、回路の除去によりVC-Labelが撤回された場合です。

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.

ポインター調整イベントは、パケットの3つの連続したパケットに送信する必要があります。de-packetizerは、N/Pビットセットを使用した3つの最初のパケットが受信されたときに、ポインター調整イベントを再生する必要があります。

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 de-packetizerは、CEMシーケンス番号を利用して、SONET/SDHポインター調整イベントが、リモートCEMパケット化装置によって送信される3つのCEMパケットごとに1回以上プレイされないことを保証する必要があります。

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乗数です。

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実装は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パケットは通常どおりNとPビットを生成する必要があります。ただし、外部同期がなければ、この情報は、CEMデパッケタイザーでのSONET/SDH輸送フレーミング内のSPEを確実に正当化するのに十分ではありません。パケット装置は、適応型アルゴリズムを採用してポインター調整イベントを導入して、CEM SPEをSONET/SDHトランスポートフレーミングにマッピングすることができます。NとPビットが適応クロックリカバリアルゴリズムの一部としてdeパケット化装置によって使用されるかどうかに関係なく、それらはまだDビットと併用して、AIS-P、STS SPE未装備、およびDBAを信号する必要があります。

For unstructured CEM, the CEM de-packetizer MAY use an adaptive clock recovery technique to regenerate the SONET/SDH transport clock.

構造化されていないCEMの場合、CEM de-Packetizerは、SONET/SDH輸送クロックを再生するために適応型クロックリカバリテクニックを使用する場合があります。

An example adaptive clock recovery method can be found in section 3.4.2 of [VTOA].

適応クロック回復方法の例は、[VTOA]のセクション3.4.2に記載されています。

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 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.

MPLSアプリケーションでの最大ネットワークスケーリングの場合、[RFC4447]で定義された擬似ワイヤIDフォワードエラー補正(PWID FEC)要素によって増強されるように、ラベル分布プロトコル(LDP)拡張発見メカニズムを使用してCEM LSPシグナル伝達を実行できます。MPLSトラフィックトンネルは、CEM専用、または他のMPLSベースのサービスと共有される場合があります。値0x8008は、PWID FEC要素のPWE3 PWタイプに使用され、LSPがCEMを運ぶことであることを示すために使用されます。[GR-253]で定義された一般的なコントロールワードは使用されていないことに注意してください。その機能はCEMカプセル化ヘッダーに含まれているためです。

Alternatively, static label assignment may be used, or a dedicated traffic engineered LSP may be used for each CEM service.

あるいは、静的ラベルの割り当てを使用するか、各CEMサービスに専用のトラフィックエンジニアリングLSPを使用する場合があります。

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ストリームのすべてのパケットに対して長さが固定されています。この長さは、[RFC4447]で定義されたCEMペイロードバイトパラメーターを使用してシグナル伝達されるか、各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タイプ値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 Technologies、「同期光学ネットワーク(SONET)輸送システム:一般的な一般的な基準」、GR-253コア、2000年9月、第3号。

[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適応層の仕様:タイプAAL1」、付録III、1996年8月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.

[RFC4023] Worster、T.、Rekhter、Y.、およびE. Rosen、ed。、「IPまたは汎用ルーティングカプセル化(GRE)のMPLのカプセル化」、RFC 4023、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] Martini、L.、Ed。、Ed。、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「擬似ワイヤー分布プロトコル(LDP)を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、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.、Pate、P.、Cohen、R.、Ed。、およびD. Zelig、「同期光学ネットワーク/同期デジタル階層(SONET/SDH)回路エミュレーション(CEP)(CEP)(CEP)(CEP)(CEP)(CEP))、RFC 4842、2007年4月。

[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.

[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 Institute、「同期光ネットワーク(SONET) - マルチプレックス構造、レート、フォーマットを含む基本的な説明」、ANSI T1.105- 1995。

[VTOA] ATM Forum, "Circuit Emulation Service Interoperability Specification Version 2.0", af-vtoa-0078.000, January 1997.

[VTOA] ATMフォーラム、「サーキットエミュレーションサービスの相互運用性仕様バージョン2.0」、AF-VTOA-0078.000、1997年1月。

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] Bryant、S.、ed。、およびP. Pate、ed。、「Pseudo Wire Emulation Edge-to-Edge(PWE3)アーキテクチャ」、RFC 3985、2005年3月。

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.

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-1は、n同期ペイロードエンベロープ(SPE)を使用して、STS-Nとして示される高レベルの信号に多重化される場合があります。STS-Nの光学的対応物は、光学キャリアレベルn、またはOC-Nです。表2に、このドキュメントで説明した標準のソネットラインレートを示します。

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.2800

Table 2. Standard SONET Line Rates

表2.標準のソネットラインレート

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.

各ソネットフレームは125米国で、9列で構成されています。STS-Nフレームには9列とn*90の列があります。n*90列のうち、最初のn*3列は輸送オーバーヘッドであり、他のn*87列はSPEです。また、多くのSTS-1をリンクして、1つのSPEのみで超レート信号を形成することもできます。光学的スーパーレート信号は、OC-Nよりもペイロード容量が高いOC-NCとして示されます。

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バイトの列は、パスオーバーヘッド(POH)であり、残りの列は固定されたもの(STS-NCのみ)でペイロード容量を形成します。純粋に頭上の固定されたものは、STS-NCのn/3-1列です。したがって、STS-1とSTS-3Cには固定されたものがなく、STS-12Cには固定されたものの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バイトです。STS-1のペイロード容量は、フレームあたり86列(774バイト)です。STS-NCのペイロード容量は(n*87) - (n/3)フレームあたりの列です。したがって、STS -3Cのペイロード容量は(3*87-1)*9 = 2,340バイトあたり2,340バイトです。別の例として、STS-192Cのペイロード容量は149,760バイトで、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個のソネットフレームがあります。したがって、STS-1のSPEサイズ(POHとペイロード容量)は783*8*8,000 = 50.112 MB/sです。連結されたSTS-3CのSPEサイズは、フレームあたり2,349バイトまたは150.336 MB/sです。STS-192Cのペイロード容量は、フレームあたり149,760バイトで、これは9,584.640 MB/sに相当します。表3に、サポートされているSPEおよびペイロードレートを示します。

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

SONET STSレベルSTS-1 STS-3C STS-12C STS-48C STS-192C SDH VCレベル-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.640 SPEサイズ(バイト)783 2,349 9,396 37,584

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ヘッダーを保護するためのエラー修正コードです。これにより、単一のビット修正と、最大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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

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列を構築し、行上のパリティを計算します。マトリックス列は、CEMヘッダービット0〜25を表します。

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.

ECC-6の各列をx []で確認するマトリックスをチェックし、中間エンコーダーマトリックスの各列をy []として示します。CEM []はCEMヘッダーを示し、ECC []はCEMヘッダービット26〜31に挿入されるエラー修正コードです。

   for i = 0 to 25 {
        if CEM[i] = 0 {
                Y[i] = 0;
        } else {
                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.

言い換えれば、各CEMヘッダービット(i)について1つに設定し、結果のマトリックス列y [i]を図7に従って設定します。

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.

受信機はまた、Matrix Xを使用して、CEMヘッダーの32ビットすべてに基づいて中間マトリックスY 'を計算します。したがって、y 'は幅32列で、ECC-6コードが含まれます。

   for i = 0 to 31 {
        if CEM[i] = 0 {
                Y'[i] = 0;
        } else {
                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です。6ビットすべてが0の場合、少しエラーがありません(または少なくとも検出可能なエラーはありません)。それ以外の場合、zを使用して図7からx []で逆ルックアップを実行します。zが列x [i]に一致する場合、ビットエラーがあります。レシーバーは、ヘッダーを修正するためにビットCEM [i]を反転させる必要があります。zがxの列に一致しない場合、CEMヘッダーには複数のビットエラーが含まれ、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ビット検出を提供し、2ビットのエラーを検出することに注意してください。

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.

著者は、以前はVivace Networks and TellabsのMitri Halabi、Bob Colvin、Ken Hsuに感謝したいと思います。トム・ジョンソン、マレーネ・ドロスト、エド・ホールマン、デイブ・ダネンバーグ、以前はリッチフィールド・コミュニケーションズのドキュメントへの貢献について。

Authors' Addresses

著者のアドレス

Andrew G. Malis Verizon Communications 40 Sylvan Road Waltham, MA 02451 EMail: andrew.g.malis@verizon.com

Andrew G. Malis Verizon Communications 40 Sylvan Road Waltham、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

Jeremy Brayley ECI Telecom Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh、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

John Shirron ECI Telecom Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh、PA 15205メール:john.shirron@ecitele.com

Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 EMail: lmartini@cisco.com

Luca Martini Cisco Systems、Inc。9155 East Nichols Avenue、Suite 400 Englewood、Co、80112メール:lmartini@cisco.com

Steve Vogelsang Alcatel-Lucent 600 March Road Kanata, ON K2K 2T6 Canada EMail: steve.vogelsang@alcatel-lucent.com

Steve Vogelsang Alcatel-Lucent 600 March Road Kanata、on K2K 2T6カナダメール:steve.vogelsang@alcatel-lucent.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2008).

著作権(c)The IETF Trust(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.

この文書は、BCP 78および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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。