[要約] RFC 4385は、MPLS PSN上で使用するためのPseudowire Emulation Edge-to-Edge（PWE3）制御ワードに関する仕様です。このRFCの目的は、PWE3トンネルでのフレームの識別と制御を可能にするための制御ワードの使用方法を定義することです。
Network Working Group S. Bryant
Request for Comments: 4385 G. Swallow
Category: Standards Track L. Martini
Cisco Systems
D. McPherson
Arbor Networks
February 2006
Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN
PseudowireエミュレーションEdge-to-Edge（PWE3）MPLS PSNを介して使用する単語を制御する
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes the preferred design of a Pseudowire Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated Channel Header. The design of these fields is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload.
このドキュメントでは、MPLSパケットスイッチネットワークで使用される擬似ワイヤーエミュレーションエッジツーエッジ（PWE3）制御単語の優先設計と、擬似ワイヤー関連チャネルヘッダーについて説明します。これらのフィールドの設計は、MPLSラベルスイッチングルーターをMPLSペイロード検査を実行しても、PWE3ペイロードをIPペイロードと混同しないように選択されます。
The standard MPLS encapsulations have no explicit protocol identifier. In order for a pseudowire (PW) [RFC3985] to operate correctly over an MPLS packet switched network (PSN) that performs MPLS payload inspection, a PW packet must not appear to a label switching router (LSR) as if it were an IP packet [BCP]. An example of an LSR that performs MPLS payload inspection is one that is performing equal-cost multiple-path load-balancing (ECMP) [RFC2992]. If ECMP were performed on PW packets, the packets in the PW may not all follow the same path through the PSN. This may result in misordered packet delivery to the egress PE. The inability to ensure that all packets belonging to a PW follow the same path may also prevent the PW Operations and Management (OAM) [VCCV] mechanism from correctly monitoring the PW.
標準のMPLSカプセルには、明示的なプロトコル識別子がありません。擬似具体（PW）[RFC3985]がMPLSペイロード検査を実行するMPLSパケットスイッチネットワーク（PSN）を介して正しく動作するためには、PWパケットがIPパケットであるかのようにラベルスイッチングルーター（LSR）に表示されてはなりません。[BCP]。MPLSペイロード検査を実施するLSRの例は、等しいマルチパスロードバランス（ECMP）[RFC2992]を実行しているLSRです。PWパケットでECMPが実行された場合、PWのパケットはすべてPSNを介して同じパスをたどるとは限りません。これにより、出口PEへの誤った順序パケット配信が発生する可能性があります。PWに属するすべてのパケットが同じパスに従うことを保証できないことで、PWの操作と管理（OAM）[VCCV]メカニズムがPWを正しく監視するのを防ぐことができます。
This document specifies how the PW control word is used to distinguish a PW payload from an IP payload carried over an MPLS PSN. It then describes the preferred design of a PW Control Word to be use over an MPLS PSN, and the Pseudowire Associated Channel Header.
このドキュメントは、PW制御ワードを使用して、MPLS PSNに掲載されたIPペイロードとPWペイロードを区別する方法を指定します。次に、MPLS PSNおよびPseudowire関連チャネルヘッダーで使用するPW制御ワードの好ましい設計について説明します。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
A PW that is carried over an MPLS PSN that uses the contents of the MPLS payload to select the ECMP path may be subjected to packet misordering [BCP]. In cases where the application using the PW is sensitive to packet misordering, or where packet misordering will disrupt the operation of the PW, it is necessary to prevent the PW being subjected to ECMP.
MPLSペイロードのコンテンツを使用してECMPパスを選択するMPLS PSNを搭載しているPWは、パケット誤用[BCP]にかけられる場合があります。PWを使用したアプリケーションがパケットの誤用に敏感である場合、またはパケットの誤った順序がPWの動作を破壊する場合、PWがECMPにさらされるのを防ぐ必要があります。
All IP packets [RFC791] [RFC2460] start with a version number that is checked by LSRs performing MPLS payload inspection. To prevent the incorrect processing of packets carried within a PW, PW packets carried over an MPLS PSN MUST NOT start with the value 4 (IPv4) or the value 6 (IPv6) in the first nibble [BCP], as those are assumed to carry normal IP payloads.
すべてのIPパケット[RFC791] [RFC2460]は、MPLSペイロード検査を実行するLSRによってチェックされるバージョン番号から始まります。PW内で運ばれるパケットの誤った処理を防ぐために、MPLS PSNを搭載したPWパケットは、最初のニブル[BCP]の値4（IPv4）または値6（IPv6）から開始してはなりません。通常のIPペイロード。
This document defines a PW header and two general formats of that header. These two formats are the PW MPLS Control Word (PWMCW), which is used for data passing across the PW, and a PW Associated Channel Header (PWACH), which can be used for functions such as OAM.
このドキュメントでは、そのヘッダーのPWヘッダーと2つの一般的な形式を定義します。これらの2つの形式は、PWを通過するデータに使用されるPW MPLSコントロールワード（PWMCW）と、OAMなどの関数に使用できるPW関連チャネルヘッダー（PWACH）です。
If the first nibble of a PW packet carried over an MPLS PSN has a value of 0, this indicates that the packet starts with a PWMCW. If the first nibble of a packet carried over an MPLS PSN has a value of 1, it starts with a PWACH. The use of any other first nibble value for a PW packet carried over an MPLS PSN is deprecated.
PWパケットの最初のニブルがMPLS PSNを搭載している場合、値は0の場合、これはパケットがPWMCWで始まることを示します。MPLS PSNを搭載したパケットの最初のニブルの値は1の場合、PWACHから始まります。MPLS PSNを介して運ばれたPWパケットの他の最初のニブル値の使用は非推奨です。
If a PW is sensitive to packet misordering and is being carried over an MPLS PSN that uses the contents of the MPLS payload to select the ECMP path, it MUST employ a mechanism that prevents packet misordering. A suitable mechanism is the PWMCW described in Section 3 for data, and the PWACH described in Section 5 for channel-associated traffic.
PWがパケットの誤用に敏感であり、MPLSペイロードの内容を使用してECMPパスを選択するMPLS PSNの上に運ばれている場合、パケットの誤整合を防ぐメカニズムを使用する必要があります。適切なメカニズムは、データのセクション3で説明されているPWMCWと、チャネル関連トラフィックのセクション5で説明されているPWACHです。
The PWMCW or the PWACH MUST immediately follow the bottom of the MPLS label stack.
PWMCWまたはPWACHは、MPLSラベルスタックの底部をすぐにたどる必要があります。
The Generic PW MPLS Control Word (PWMCW) is shown in Figure 1.
一般的なPW MPLS制御ワード（PWMCW）を図1に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Specified by PW Encapsulation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Generic PW MPLS Control Word
図1：一般的なPW MPLS制御ワード
The PW set-up protocol or configuration mechanism determines whether a PW uses a PWMCW. Bits 0..3 differ from the first four bits of an IP packet [BCP] and hence provide the necessary MPLS payload discrimination.
PWセットアッププロトコルまたは構成メカニズムは、PWがPWMCWを使用するかどうかを決定します。ビット0..3は、IPパケット[BCP]の最初の4ビットとは異なるため、必要なMPLSペイロード差別を提供します。
When a PWMCW is used, it MUST adhere to the Generic format illustrated in Figure 1 above. To provide consistency between the designs of different types of PW, it SHOULD also use the following preferred format:
PWMCWを使用する場合、上記の図1に示す一般的な形式を順守する必要があります。さまざまな種類のPWの設計間で一貫性を提供するには、次の優先形式も使用する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Flags |FRG| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Preferred PW MPLS Control Word
図2：優先されるPW MPLS制御ワード
The meaning of the fields of the Preferred PW MPLS Control Word (Figure 2) is as follows:
優先されたPW MPLS制御ワード（図2）のフィールドの意味は次のとおりです。
Flags (bits 4 to 7):
フラグ（ビット4〜7）：
These bits MAY be used by for per-payload signaling. Their semantics MUST be defined in the PW specification.
これらのビットは、給与ごとのシグナル伝達に使用できます。それらのセマンティクスは、PW仕様で定義する必要があります。
FRG (bits 8 and 9):
frg（ビット8および9）：
These bits are used when fragmenting a PW payload. Their use is described in [FRAG], which is currently a work in progress. When the PW is of a type that will never need payload fragmentation, these bits may be used as general purpose flags.
これらのビットは、PWペイロードを断片化するときに使用されます。それらの使用は、現在進行中の作業である[frag]で説明されています。PWがペイロードの断片化を必要としないタイプの場合、これらのビットは汎用フラグとして使用できます。
Length (bits 10 to 15):
長さ（ビット10〜15）：
When the PSN path between the PEs includes an Ethernet segment, the PW packet arriving at the CE-bound PE from the PSN may include padding appended by the Ethernet Data Link Layer. The CE-bound PE uses the length field to determine the size of the padding added by the PSN, and hence extract the PW payload from the PW packet.
PES間のPSNパスにイーサネットセグメントが含まれている場合、PSNからCEバウンドPEに到着するPWパケットには、イーサネットデータリンクレイヤーによって追加されたパディングが含まれる場合があります。CEバウンドPEは、長さフィールドを使用してPSNによって追加されたパディングのサイズを決定するため、PWパケットからPWペイロードを抽出します。
If the MPLS payload is less than 64 bytes, the length field MUST be set to the length of the PW payload plus the length of the PWMCW. Otherwise it MUST be set to zero.
MPLSペイロードが64バイト未満の場合、長さフィールドはPWペイロードの長さとPWMCWの長さに設定する必要があります。それ以外の場合は、ゼロに設定する必要があります。
Sequence number (Bit 16 to 31):
シーケンス番号（ビット16〜31）：
The sequence number implements the sequencing function [RFC3985]. The use of this field is described in Section 4.
シーケンス番号は、シーケンス関数[RFC3985]を実装します。このフィールドの使用については、セクション4で説明します。
The sequence number mechanism is PW specific. The PW encapsulation specification MAY define a sequence number mechanism to be used, or it may indicate that the mechanism described here is to be used. A pseudo-code description of this mechanism is given in the non-normative Appendix.
シーケンス番号メカニズムはPW固有です。PWカプセル化仕様は、使用するシーケンス番号メカニズムを定義する場合があります。または、ここで説明するメカニズムが使用されることを示している場合があります。このメカニズムの擬似コードの説明は、非規範的な付録に記載されています。
The sequence number mechanism described here uses a circular unsigned 16-bit number space that excludes the value zero.
ここで説明するシーケンス番号メカニズムは、値ゼロを除外する円形の署名されていない16ビット番号スペースを使用します。
For a given PW, and a pair of routers PE1 and PE2, if PE1 supports packet sequencing and packet sequencing is enabled for the PW, then the following procedures MUST be used:
特定のPWとルーターのペアPE1とPE2の場合、PE1がパケットシーケンスをサポートし、PWに対してパケットシーケンスを有効にする場合、次の手順を使用する必要があります。
o The initial packet transmitted on the PW MUST be sent with sequence number one.
o PWに送信された最初のパケットは、シーケンスナンバー1で送信する必要があります。
o Subsequent packets MUST increment the sequence number by one for each packet.
o 後続のパケットは、パケットごとにシーケンス番号を1つずつ増分する必要があります。
o The sequence number that follows 65535 (maximum unsigned 16-bit number) is one.
o 65535に続くシーケンス番号（最大署名されていない16ビット数）は1です。
If the transmitting router PE1 does not support sequence number processing, or packet sequencing is disabled, then the sequence number field in the control word MUST be set to zero for all packets transmitted on the PW.
送信ルーターPE1がシーケンス番号処理をサポートしていない場合、またはパケットシーケンスが無効になっている場合、PWに送信されるすべてのパケットについて、コントロールワードのシーケンス番号フィールドをゼロに設定する必要があります。
If a router PE2 supports receive sequence number processing, and packet sequencing is enabled for this PW, then the following procedure is used:
ルーターPE2が受信シーケンス番号処理をサポートし、このPWでパケットシーケンスが有効になっている場合、次の手順が使用されます。
When a PW is initially set up, the "expected sequence number" associated with it MUST be initialized to one.
PWが最初にセットアップされる場合、それに関連付けられた「予想されるシーケンス番号」は1つに初期化する必要があります。
When a packet is received on that PW, the sequence number SHOULD be processed as follows:
そのPWでパケットを受信した場合、シーケンス番号は次のように処理する必要があります。
o If the sequence number on the packet is zero, the sequence integrity of the packets cannot be determined. In this case, the received packet is considered to be in order.
o パケットのシーケンス番号がゼロの場合、パケットのシーケンスの整合性を決定できません。この場合、受信したパケットは順調であると見なされます。
o Otherwise if the packet sequence number equals the expected sequence number, the packet is in order.
o それ以外の場合、パケットシーケンス番号が予想されるシーケンス番号に等しい場合、パケットは順調です。
o Otherwise if the packet sequence number is greater than the expected sequence number, and the packet sequence number minus the expected sequence number is less than 32768, the packet is within the allowed receive sequence number window. The implementation MAY treat the packet as in order.
o それ以外の場合は、パケットシーケンス番号が予想されるシーケンス番号よりも大きく、パケットシーケンス番号を引いた場合、予想シーケンス番号が32768未満の場合、パケットは許可された受信シーケンス番号ウィンドウ内にあります。実装は、パケットを順番に扱う場合があります。
o Otherwise if the packet sequence number is less than the expected sequence number and the expected sequence number minus the packet sequence number is greater than or equal to 32768, the packet is within the allowed receive sequence number window. The implementation MAY treat the packet as in order.
o それ以外の場合、パケットシーケンス番号が予想されるシーケンス番号よりも少なく、予想されるシーケンス番号を引いたマイナスパケットシーケンス番号が32768以上の場合、パケットは許可された受信シーケンス番号ウィンドウ内にあります。実装は、パケットを順番に扱う場合があります。
o Otherwise the packet is out of order.
o それ以外の場合は、パケットが故障していません。
If the packet is found to be in order, it MAY be delivered immediately.
パケットが順調であることが判明した場合、すぐに配信される場合があります。
If the packet sequence number was not zero, then the expected sequence number is set to the packet sequence number plus one. The expected sequence number that follows 65535 (maximum unsigned 16-bit number) is one.
パケットシーケンス番号がゼロでない場合、予想されるシーケンス番号はパケットシーケンス番号と1に設定されます。65535に続く予想されるシーケンス番号（最大署名されていない16ビット数）は1です。
Packets that are received out of order MAY either be dropped or reordered. The choice between dropping or reordering an out-of-sequence packet is at the discretion of the receiver.
順番に受信されたパケットは、ドロップされるか、並べ替えることができます。ドロップまたは並べ替えパケットを並べ替えるかの選択は、受信者の裁量にあります。
If a PE negotiated not to use receive sequence number processing, and it received a non-zero sequence number, then it SHOULD send a PW status message indicating a receive fault, and disable the PW.
PEが受信シーケンス番号処理を使用しないと交渉し、ゼロ以外のシーケンス番号を受信した場合、受信障害を示すPWステータスメッセージを送信し、PWを無効にする必要があります。
For some PW features, an associated channel is required. An associated channel is a channel that is multiplexed in the PW with user traffic, and thus follows the same path through the PSN as user traffic. Note that the use of the term "channel" is not a "PW channel type" as used in subsection 5.1.2 of [RFC3985].
一部のPW機能には、関連するチャネルが必要です。関連するチャネルは、ユーザートラフィックを使用してPWで多重化されるチャネルであり、したがって、ユーザートラフィックと同じパスを通過します。「チャネル」という用語の使用は、[RFC3985]のサブセクション5.1.2で使用される「PWチャネルタイプ」ではないことに注意してください。
When MPLS is used as the PSN, the PW Associated Channel (PWAC) is identified by the following header:
MPLSをPSNとして使用すると、PW関連チャネル（PWAC）が次のヘッダーによって識別されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PW Associated Channel Header
図3：PW関連チャネルヘッダー
The meanings of the fields in the PW Associated Channel Header (PWACH) (Figure 3) are:
PW関連チャネルヘッダー（PWACH）のフィールドの意味（図3）は次のとおりです。
Version:
バージョン：
This is the version number of the PWACH. This specification defines version 0.
これはPWACHのバージョン番号です。この仕様はバージョン0を定義します。
Reserved:
予約済み：
MUST be sent as 0, and ignored on reception.
0として送信され、レセプションでは無視する必要があります。
Channel Type:
チャネルタイプ：
The PW Associated Channel Type is defined in the IANA PW Associated Channel Type registry [IANA].
PW関連チャネルタイプは、IANA PW関連チャネルタイプレジストリ[IANA]で定義されています。
Bits 0..3 MUST be 0001. This allows the packet to be distinguished from an IP packet [BCP] and from a PW data packet.
ビット0..3は0001でなければなりません。これにより、パケットをIPパケット[BCP]およびPWデータパケットから区別できます。
IANA has set up a registry of "Pseudowire Associated Channel Types". These are 16-bit values. Registry entries are assigned by using the "IETF Consensus" policy defined in [RFC2434]. The value 0x21 indicates that the Associated Channel carries an IPv4 packet. The value 0x57 indicates that the Associated Channel carries an IPv6 packet.
IANAは、「Pseudowire関連チャネルタイプ」のレジストリを設定しました。これらは16ビット値です。レジストリエントリは、[RFC2434]で定義されている「IETFコンセンサス」ポリシーを使用して割り当てられます。値0x21は、関連するチャネルにIPv4パケットが含まれていることを示します。値0x57は、関連するチャネルにIPv6パケットが含まれていることを示します。
An application using a PW Associated Channel must be aware that the channel can potentially be misused. Any application using the Associated Channel MUST therefore fully consider the resultant security issues, and provide mechanisms to prevent an attacker from using this as a mechanism to disrupt the operation of the PW or the PE, and to stop this channel from being used as a conduit to deliver packets elsewhere. The selection of a suitable security mechanism for an application using a PW Associated Channel is outside the scope of this document.
PW関連チャネルを使用するアプリケーションは、チャネルが誤用される可能性があることに注意する必要があります。したがって、関連するチャネルを使用するアプリケーションは、結果のセキュリティの問題を完全に考慮し、攻撃者がPWまたはPEの動作を妨害するメカニズムとして使用することを防ぎ、このチャネルが導管として使用されるのを止めるメカニズムを提供する必要があります。他の場所にパケットを配信するため。PW関連チャネルを使用したアプリケーションに適したセキュリティメカニズムの選択は、このドキュメントの範囲外です。
If a PW has been configured to operate without a CW, the PW Associated Channel Type mechanism described in the document MUST NOT be used. This is to prevent user payloads being fabricated in such a way that they mimic the PW Associated Channel Header, and thereby provide a method of attacking the application that is using the Associated Channel.
PWがCWなしで動作するように構成されている場合、ドキュメントで説明されているPW関連チャネルタイプのメカニズムを使用してはなりません。これは、ユーザーのペイロードがPW関連チャネルヘッダーを模倣するように製造され、それによって関連するチャネルを使用しているアプリケーションを攻撃する方法を提供するためです。
The authors wish to thank David Allan, Thomas Nadeau, Yaakov Stein, and Mark Townsley for their input to this work.
著者は、この作業への意見について、デビッド・アラン、トーマス・ナドー、ヤコフ・スタイン、マーク・タウンズリーに感謝したいと考えています。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[BCP] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", Work in Progress, September 2005.
[BCP] Swallow、G.、Bryant、S。、およびL. Andersson、「MPLSネットワークでの等しいコストマルチパス治療を避ける」、2005年9月、進行中の作業。
[FRAG] Malis, A. and M. Townsley, "PWE3 Fragmentation and Reassembly", Work in Progress, November 2005.
[frag] Malis、A。and M. Townsley、「PWE3の断片化と再組み立て」、2005年11月、進行中の作業。
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", Work in Progress, November 2005.
[Iana] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）のIANAの割り当て」、2005年11月、進行中の作業。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000.
[RFC2992] Hopps、C。、「等コストのマルチパスアルゴリズムの分析」、RFC 2992、2000年11月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[VCCV] Nadeau, T. and R. Aggarwal, "Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, August 2005.
[VCCV] Nadeau、T。およびR. Aggarwal、「Pseudowire仮想回路接続検証（VCCV）」、2005年8月、進行中の作業。
Appendix. Sequence Number Processing
付録。シーケンス番号処理
This appendix is non-normative.
この付録は非規範的です。
This appendix provides a pseudo-code description of the sequence number processing mechanism described in Section 4.2.
この付録は、セクション4.2で説明したシーケンス番号処理メカニズムの擬似コードの説明を提供します。
unsigned16 RECEIVED /* packet sequence number
unsigned16 EXPECTED = 1 /* expected sequence number
/* initialized to one
boolean sequencingDisabled
boolean dropOutOfOrder /* policy on in-window out of sequence
/* packets
updateExpected()
begin
EXPECTED := RECEIVED + 1;
/* Because EXPECTED is an unsigned16 it will wrap
/* from 65535 to 0
/* zero is skipped
if (EXPECTED = 0)
EXPECTED := 1;
return;
end;
On receipt of a PW packet from PSN:
begin
if (RECEIVED = 0) then begin
processPacket();
return;
end;
if (sequencingDisabled) then begin
/* A packet was received with non-zero sequence number, but
/* sequencing is disabled
indicateReceiveFault();
disablePW();
return;
end;
/* The received sequence is the expected sequence number
if ((RECEIVED = EXPECTED) then begin
/* packet is in order
processPacket();
updateExpected();
return;
end;
/* Test for received sequence number is greater than
/* the expected sequence number and is within the
/* allowed receive sequence number window
if ((RECEIVED > EXPECTED) and
((RECEIVED - EXPECTED) < 32768) then begin
/* packet is in the window, but there are late/missing
/* packets
if (dropOutOfOrder) then begin
/* policy is to receive immediately, dropping
/* out of sequence packets
processPacket();
updateExpected();
return;
end else begin
/* policy is to wait for late packets
processMissingPackets();
return;
end;
end;
/* Test for the received sequence is less than the
/* expected sequence number and is within the allowed
/* receive sequence number window
if ((RECEIVED < EXPECTED) and
((EXPECTED - RECEIVED) >= 32768) then begin
/* packet is in the window, but there are late/missing
/* packets
if (dropOutOfOrder) then begin
/* policy is to receive immediately, dropping
/* out of sequence packets
processPacket();
updateExpected();
return;
end else begin
/* policy is to wait for late packets
processMissingPackets();
return;
end;
end;
/* Received packet was outside the allowed receive
/* sequence number window
processOutOfWindow();
end;
Authors' Addresses
著者のアドレス
Stewart Bryant Cisco Systems, 250, Longwater, Green Park, Reading, RG2 6GB, United Kingdom.
スチュワートブライアントシスコシステム、250、ロングウォーター、グリーンパーク、リーディング、RG2 6GB、イギリス。
EMail: stbryant@cisco.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719
George Swallow Cisco Systems、Inc。1414 Massachusetts Ave Boxborough、MA 01719
EMail: swallow@cisco.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
Luca Martini Cisco Systems、Inc。9155 East Nichols Avenue、Suite 400 Englewood、Co、80112
EMail: lmartini@cisco.com
Danny McPherson Arbor Networks, Inc.
Danny McPherson Arbor Networks、Inc。
EMail: danny@arbor.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。