Network Working Group S. Bryant
Request for Comments: 4385 G. Swallow
Category: Standards Track L. Martini
Cisco Systems
D. McPherson
Arbor Networks
February 2006
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
用于MPLS PSN的伪线仿真边到边（PWE3）控制字
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标签交换路由器不会将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分组在标签交换路由器（LSR）看来不能像是IP分组[BCP]。执行MPLS有效负载检查的LSR的一个示例是执行等成本多路径负载平衡（ECMP）[RFC2992]。如果对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控制字来区分PW有效负载和通过MPLS PSN承载的IP有效负载。然后描述将在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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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标题和该标题的两种通用格式。这两种格式是PW MPLS控制字（PWMCW），用于通过PW传递数据，以及PW关联通道头（PWACH），可用于OAM等功能。
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对数据包错序敏感，并且正在通过使用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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]的前四位，因此提供必要的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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 后续数据包必须为每个数据包增加一个序列号。
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.
如果包序列号不是零，则预期序列号被设置为包序列号加上一。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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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已经建立了一个“伪线相关通道类型”的注册表。这些是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.
作者希望感谢David Allan、Thomas Nadeau、Yaakov Stein和Mark Townsley对这项工作的贡献。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年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.和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.，“伪线边到边仿真（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，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[VCCV] Nadeau, T. and R. Aggarwal, "Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, August 2005.
[VCCV]Nadeau，T.和R.Aggarwal，“伪线虚拟电路连接验证（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
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;
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;
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;
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;
/* 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 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
/* 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;
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;
/* 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.
Stewart Bryant Cisco Systems，英国雷丁市格林公园朗沃特250号，RG2 6GB。
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719
George Swallow Cisco Systems，Inc.马萨诸塞州Boxborough大道1414号，邮编01719
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
卢卡·马蒂尼·思科系统公司，地址：科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室，邮编：80112
EMail: lmartini@cisco.com
EMail: lmartini@cisco.com
Danny McPherson Arbor Networks, Inc.
丹尼·麦克弗森阿伯网络公司。
EMail: danny@arbor.net
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。