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
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).
著作権（C）インターネット協会（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ラベルがIPペイロードとPWE3ペイロードを混同しないように、これらのフィールドのデザインが選択されています。
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カプセル化は、明示的なプロトコル識別子を持っていません。それがIPパケットであるかのようにMPLSパケットの上に正しく動作する疑似回線（PW）[RFC3985]のためのためにMPLSペイロード検査を行うネットワーク（PSN）を切り替え、PWパケットはラベルスイッチングルータ（LSR）に現れてはなりません[BCP]。 MPLSペイロードの検査を実行するLSRの例としては、等コストマルチパスロードバランシング（ECMP）[RFC2992]を実行しているものです。 ECMPはPWパケット上で実行された場合は、PW内のパケットは、すべてのPSNを通して同じパスをたどるないかもしれません。これは、出口PEへmisorderedパケット配信をもたらすことができます。 PWに属するすべてのパケットが同じ経路に従うことを保証することができないことも正しくPWを監視からPW運用および管理（OAM）[VCCV]メカニズムを防止することができます。
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、および擬似回線関連するチャンネルヘッダーの上に使用すること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.
ECMP経路を選択するMPLSペイロードの内容を使用した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ヘッダ及びそのヘッダの二つの一般的なフォーマットを定義します。これら二つのフォーマットは、OAMなどの機能のために使用することができるPW横切るデータのために使用されるPW MPLS制御ワード（PWMCW）、及び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.
MPLS PSNの上まで運ばPWパケットの最初のニブルが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がパケット誤った順序に敏感であり、ECMP経路を選択するために、MPLSペイロードの内容を使用した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を使用するかどうかを判断します。ビット[BCP] IPパケットの最初の4ビットは異なる、従って、必要なMPLSペイロード識別を提供0..3。
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.
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.
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.
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.
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:
PE1がパケット順序付けをサポートし、パケットの順序は、PWのために有効になっている場合は与えられたPW、およびルータPE1とPE2のペアについては、次の手順を使用しなければなりません。
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.
パケットシーケンス番号が期待シーケンス番号よりも大きい場合、パケットシーケンス番号マイナス期待シーケンス番号が32768未満である場合、Oそうでない場合、パケットは受信許可シーケンス番号のウィンドウの範囲内です。実装では、順序のようにパケットを処理するかもしれません。
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.
パケットシーケンス番号が期待シーケンス番号と期待シーケンス番号マイナスパケットのシーケンス番号は32768以上である未満である場合、Oそうでない場合、パケットは受信許可シーケンス番号のウィンドウの範囲内です。実装では、順序のようにパケットを処理するかもしれません。
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に多重化されるチャネルであり、したがって、ユーザトラフィックとしてPSNを通して同じ経路をたどります。 [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.
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].
Bits 0..3 MUST be 0001. This allows the packet to be distinguished from an IP packet [BCP] and from a PW data packet.
0001ここでなければなりません0..3ビットは、パケットが[BCP] IPパケットから、および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は、「擬似回線関連するチャネルタイプ」のレジストリを設定しています。これらは、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.
作者はこの作品への入力のためのデビッド・アラン、トーマスナドー、Yaakovのスタイン、マークTownsleyに感謝したいです。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、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]、G.、ブライアント、S.、およびL.アンダーソン、 "MPLSネットワークにおけるイコールコストマルチパス治療の回避"、進歩、2005年9月の作業を飲み込みます。
[FRAG] Malis, A. and M. Townsley, "PWE3 Fragmentation and Reassembly", Work in Progress, November 2005.
[FRAG] Malis、A.およびM. Townsley、 "PWE3断片化と再アセンブリ"、進歩、2005年11月に働いています。
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", Work in Progress, November 2005.
[IANA]マティーニ、L.、進歩、2005年11月に "エッジエミュレーション（PWE3）への擬似回線EdgeのIANAの割り当て"、仕事。
[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]ブライアント、S.とP.パテ、 "疑似ワイヤーエミュレーション端から端まで（PWE3）アーキテクチャ"、RFC 3985、2005年3月。
[VCCV] Nadeau, T. and R. Aggarwal, "Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, August 2005.
[VCCV]ナドー、T.、およびR.アガルワル、 "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、Longwater、グリーンパーク、読書、RG2 6ギガバイト、イギリス。
EMail: stbryant@cisco.com
メールアドレス：stbryant@cisco.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719
ジョージツバメシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719
EMail: swallow@cisco.com
メールアドレス：swallow@cisco.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
ルカ・マティーニシスコシステムズ株式会社9155東ニコルズアベニュー、スイート400イングルウッド、CO、80112
EMail: lmartini@cisco.com
メールアドレス：lmartini@cisco.com
Danny McPherson Arbor Networks, Inc.
ダニー・マクファーソンアーバーネットワークス株式会社
EMail: danny@arbor.net
メールアドレス：danny@arbor.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。