Network Working Group L. Martini, Ed.
Request for Comments: 4619 Cisco Systems, Inc.
Category: Standards Track C. Kawa, Ed.
Oz Communications
A. Malis, Ed.
Tellabs
September 2006
Network Working Group L. Martini, Ed.
Request for Comments: 4619 Cisco Systems, Inc.
Category: Standards Track C. Kawa, Ed.
Oz Communications
A. Malis, Ed.
Tellabs
September 2006
Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks
多协议标签交换（MPLS）网络上帧中继传输的封装方法
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
摘要
A frame relay pseudowire is a mechanism that exists between a provider's edge network nodes and that supports as faithfully as possible frame relay services over an MPLS packet switched network (PSN). This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network.
帧中继伪线是一种存在于提供商的边缘网络节点之间的机制，它通过MPLS分组交换网络（PSN）尽可能忠实地支持帧中继服务。本文档描述了通过MPLS网络传输帧中继数据包所需的详细封装。
Table of Contents
目录
1. Introduction ....................................................2
2. Specification of Requirements ...................................4
3. Co-authors ......................................................4
4. Acronyms and Abbreviations ......................................5
5. Applicability Statement .........................................5
6. General Encapsulation Method ....................................6
7. Frame Relay over MPLS PSN for the One-to-One Mode ...............7
7.1. MPLS PSN Tunnel and PW .....................................7
7.2. Packet Format over MPLS PSN ................................7
7.3. The Control Word ...........................................8
7.4. The Martini Legacy Mode Control Word .......................9
7.5. PW Packet Processing .......................................9
7.5.1. Encapsulation of Frame Relay Frames .................9
7.5.2. Setting the Sequence Number ........................10
7.6. Decapsulation of PW Packets ...............................11
7.6.1. Processing the Sequence Number .....................11
7.6.2. Processing of the Length Field by the Receiver .....11
7.7. MPLS Shim EXP Bit Values ..................................12
7.8. MPLS Shim S Bit Value .....................................12
7.9. Control Plane Details for Frame Relay Service .............12
7.9.1. Frame Relay Specific Interface Parameter Sub-TLV ...12
8. Frame Relay Port Mode ..........................................13
9. Congestion Control .............................................13
10. Security Considerations .......................................14
11. Normative References ..........................................14
12. Informative References ........................................15
1. Introduction ....................................................2
2. Specification of Requirements ...................................4
3. Co-authors ......................................................4
4. Acronyms and Abbreviations ......................................5
5. Applicability Statement .........................................5
6. General Encapsulation Method ....................................6
7. Frame Relay over MPLS PSN for the One-to-One Mode ...............7
7.1. MPLS PSN Tunnel and PW .....................................7
7.2. Packet Format over MPLS PSN ................................7
7.3. The Control Word ...........................................8
7.4. The Martini Legacy Mode Control Word .......................9
7.5. PW Packet Processing .......................................9
7.5.1. Encapsulation of Frame Relay Frames .................9
7.5.2. Setting the Sequence Number ........................10
7.6. Decapsulation of PW Packets ...............................11
7.6.1. Processing the Sequence Number .....................11
7.6.2. Processing of the Length Field by the Receiver .....11
7.7. MPLS Shim EXP Bit Values ..................................12
7.8. MPLS Shim S Bit Value .....................................12
7.9. Control Plane Details for Frame Relay Service .............12
7.9.1. Frame Relay Specific Interface Parameter Sub-TLV ...12
8. Frame Relay Port Mode ..........................................13
9. Congestion Control .............................................13
10. Security Considerations .......................................14
11. Normative References ..........................................14
12. Informative References ........................................15
In an MPLS or IP network, it is possible to use control protocols such as those specified in [RFC4447] to set up "pseudowires" (PWs) that carry the Protocol Data Units of layer 2 protocols across the network. A number of these emulated PWs may be carried in a single tunnel. The main functions required to support frame relay PW by a Provider Edge (PE) include:
在MPLS或IP网络中，可以使用[RFC4447]中指定的控制协议来建立“伪线”（PWs），在网络上传输第2层协议的协议数据单元。许多模拟PW可在单个隧道中进行。提供商边缘（PE）支持帧中继PW所需的主要功能包括：
- encapsulation of frame relay specific information in a suitable pseudowire (PW) packet;
- 将帧中继特定信息封装在适当的伪线（PW）分组中；
- transfer of a PW packet across an MPLS network for delivery to a peer PE;
- 在MPLS网络上传输PW分组以传送到对等PE；
- extraction of frame relay specific information from a PW packet by the remote peer PE;
- 由远程对等PE从PW分组提取帧中继特定信息；
- regeneration of native frame relay frames for forwarding across an egress port of the remote peer PE; and
- 再生本机帧中继帧，用于跨远程对等PE的出口端口转发；和
- execution of any other operations as required to support frame relay service.
- 执行支持帧中继服务所需的任何其他操作。
This document specifies the encapsulation for the emulated frame relay VC over an MPLS PSN. Although different layer 2 protocols require different information to be carried in this encapsulation, an attempt has been made to make the encapsulation as common as possible for all layer 2 protocols. Other layer 2 protocols are described in separate documents. [ATM] [RFC4448] [RFC4618]
本文档指定了MPLS PSN上模拟帧中继VC的封装。尽管不同的第2层协议要求在该封装中携带不同的信息，但已尝试使封装尽可能通用于所有第2层协议。其他第2层协议在单独的文档中描述。[ATM][RFC4448][RFC4618]
The following figure describes the reference models that are derived from [RFC3985] to support the frame relay PW emulated services.
下图描述了从[RFC3985]派生的用于支持帧中继PW模拟服务的参考模型。
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | (PE1) (PE2) | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Attachment Circuit (AC) Attachment Circuit (AC)
native frame relay service native frame relay service
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | (PE1) (PE2) | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Attachment Circuit (AC) Attachment Circuit (AC)
native frame relay service native frame relay service
Figure 1. PWE3 frame relay PVC interface reference configuration
图1。PWE3帧中继PVC接口参考配置
Two mapping modes can be defined between frame relay VCs and pseudowires: The first one is called "one-to-one" mapping, because there is a one-to-one correspondence between a frame relay VC and one pseudowire. The second mapping is called "many-to-one" mapping or "port mode" because multiple frame relay VCs assigned to a port are mapped to one pseudowire. The "port mode" encapsulation is identical to High-Level Data Link Control (HDLC) pseudowire encapsulation, which is described in [RFC4618].
可以在帧中继VC和伪线之间定义两种映射模式：第一种模式称为“一对一”映射，因为帧中继VC和一条伪线之间存在一对一的对应关系。第二种映射称为“多对一”映射或“端口模式”，因为分配给端口的多个帧中继vc被映射到一条伪线。“端口模式”封装与[RFC4618]中描述的高级数据链路控制（HDLC）伪线封装相同。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
Below are the definitions for the terms used throughout the document. PWE3 definitions can be found in [RFC3916, RFC3985]. This section defines terms specific to frame relay.
以下是本文件中使用的术语的定义。PWE3定义可在[RFC3916，RFC3985]中找到。本节定义了特定于帧中继的术语。
- Forward direction
- 前进方向
The forward direction is the direction taken by the frame being forwarded.
前进方向是被转发帧所采用的方向。
- Backward direction
- 反向
In frame relay, it is the direction opposite to the direction taken by a frame being forwarded (see also forward direction).
在帧中继中，它是与正在转发的帧所采取的方向相反的方向（另请参见转发方向）。
The following are co-authors of this document:
以下是本文件的共同作者：
Nasser El-Aawar Level 3 Communications, LLC Eric C. Rosen Cisco Systems Daniel Tappan Cisco Systems Thomas K. Johnson Litchfield Communications Kireeti Kompella Juniper Networks, Inc. Steve Vogelsang Laurel Networks, Inc. Vinai Sirkay Reliance Infocomm Ravi Bhat Nokia Nishit Vasavada Nokia Giles Heron Tellabs Dimitri Stratton Vlachos Mazu Networks,Inc. Chris Liljenstolpe Cable & Wireless Prayson Pate Overture Networks, Inc
Nasser El Aawar Level 3 Communications，LLC Eric C.Rosen Cisco Systems Daniel Tappan Cisco Systems Thomas K.Johnson Litchfield Communications Kireeti Kompella Juniper Networks，Inc.Steve Vogelsang Laurel Networks，Inc.Vinai Sirkay Reliance Infocomm Ravi Bhat Nokia Nishit Vasavada Nokia Giles Heron Tellabs Dimitri Stratton Vlachos Mazu Networks，Chris Liljenstolpe有线和无线Prayson-Pate序曲网络公司
BECN Backward Explicit Congestion Notification CE Customer Edge C/R Command/Response DE Discard Eligibility DLCI Data Link Connection Identifier FCS Frame Check Sequence FECN Forward Explicit Congestion Notification FR Frame Relay LSP Label Switched Path LSR Label Switching Router MPLS Multiprotocol Label Switching MTU Maximum Transfer Unit NNI Network-Network Interface PE Provider Edge PSN Packet Switched Network PW Pseudowire PWE3 Pseudowire Emulation Edge to Edge POS Packet over SONET/SDH PVC Permanent Virtual Circuit QoS Quality of Service SVC Switched Virtual Circuit UNI User-Network Interface VC Virtual Circuit
BECN向后显式拥塞通知CE客户边缘C/R命令/响应取消丢弃合格性DLCI数据链路连接标识符FCS帧检查序列FECN向前显式拥塞通知FR帧中继LSP标签交换路径LSR标签交换路由器MPLS多协议标签交换MTU最大传输单元NNI网络网络接口PE提供商边缘PSN分组交换网络PW伪线PWE3伪线仿真SONET/SDH上的边缘到边缘POS分组PVC永久虚拟电路QoS服务质量SVC交换虚拟电路单用户网络接口VC虚拟电路
Frame relay over PW service is not intended to emulate the traditional frame relay service perfectly, but it can be used for applications that need frame relay transport service.
PW上的帧中继服务并不打算完美地模拟传统的帧中继服务，但它可以用于需要帧中继传输服务的应用。
The following are notable differences between traditional frame relay service and the protocol described in this document:
以下是传统帧中继服务与本文档中描述的协议之间的显著区别：
- Frame ordering can be preserved using the OPTIONAL sequence field in the control word; however, implementations are not required to support this feature.
- 使用控制字中的可选序列字段可以保留帧顺序；但是，不需要实现来支持此功能。
- The Quality of Service model for traditional frame relay can be emulated; however, this is outside the scope of this document.
- 可以对传统的帧中继服务质量模型进行仿真；但是，这超出了本文件的范围。
- A Frame relay port mode PW does not process any frame relay status messages or alarms as described in [Q922] [Q933]
- 帧中继端口模式PW不处理[Q922][Q933]中所述的任何帧中继状态消息或警报
- The frame relay BECN and FECN bit are transparent to the MPLS network and cannot reflect the status of the MPLS network.
- 帧中继BECN和FECN位对MPLS网络是透明的，不能反映MPLS网络的状态。
- Support for frame relay SVC and Switched Permanent Virtual Circuit (SPVC) is outside the scope of this document.
- 对帧中继SVC和交换永久虚拟电路（SPVC）的支持不在本文档范围内。
- Frame relay Local Management Interface (LMI) is terminated locally in the PE connected to the frame relay attachment circuit.
- 帧中继本地管理接口（LMI）在连接到帧中继连接电路的PE中本地终止。
- The support of PVC link integrity check is outside the scope of this document.
- PVC链路完整性检查的支持不在本文件范围内。
The general frame relay pseudowire packet format for carrying frame relay information (user's payload and frame relay control information) between two PEs is shown in Figure 2.
用于在两个PE之间承载帧中继信息（用户有效负载和帧中继控制信息）的通用帧中继伪线数据包格式如图2所示。
+-------------------------------+
| |
| MPLS Transport header |
| (As required) |
+-------------------------------+
| Pseudowire (PW) Header |
+-------------------------------+
| Control Word |
+-------------------------------+
| FR Service |
| Payload |
+-------------------------------+
+-------------------------------+
| |
| MPLS Transport header |
| (As required) |
+-------------------------------+
| Pseudowire (PW) Header |
+-------------------------------+
| Control Word |
+-------------------------------+
| FR Service |
| Payload |
+-------------------------------+
Figure 2. General format of frame relay encapsulation over PSN
图2。PSN上帧中继封装的通用格式
The PW packet consists of the following fields: Control word and Payload, preceded by the MPLS Transport and pseudowire header. The meaning of the different fields is as follows:
PW数据包由以下字段组成：控制字和有效负载，前面是MPLS传输和伪线报头。不同字段的含义如下：
-i. MPLS Transport header is specific to the MPLS network. This header is used to switch the PW packet through the MPLS core.
-一,。MPLS传输头特定于MPLS网络。该报头用于通过MPLS核心交换PW数据包。
-ii. PW header contains an identifier for multiplexing PWs within an MPLS tunnel.
-二,。PW头包含用于在MPLS隧道内多路复用PW的标识符。
-iii. Control Word contains protocol control information for providing a frame relay service. Its structure is provided in the following sections.
-iii.控制字包含用于提供帧中继服务的协议控制信息。其结构在以下章节中提供。
-iv. The content of the frame relay service payload field depends on the mapping mode. In general it contains the layer 2 frame relay frame.
-iv.帧中继服务有效载荷字段的内容取决于映射模式。通常，它包含第2层帧中继帧。
MPLS label switched paths (LSPs) called "MPLS Tunnels" are used between PEs and are used within the MPLS core network to forward PW packets. An MPLS tunnel corresponds to "PSN Tunnel" of Figure 1.
称为“MPLS隧道”的MPLS标签交换路径（LSP）用于PEs之间，并在MPLS核心网络内用于转发PW数据包。MPLS隧道对应于图1中的“PSN隧道”。
Several PWs may be nested inside one MPLS tunnel. Each PW carries the traffic of a single frame relay VC. In this case, the PW header is an MPLS label called the PW label.
多个PW可以嵌套在一个MPLS隧道中。每个PW承载单个帧中继VC的通信量。在这种情况下，PW头是一个称为PW标签的MPLS标签。
For the one-to-one mapping mode for frame relay over an MPLS network, the PW packet format is as shown in Figure 3.
对于MPLS网络上的帧中继的一对一映射模式，PW数据包格式如图3所示。
+-------------------------------+
| MPLS Tunnel label(s) | n*4 octets (four octets per label)
+-------------------------------+
| PW label | 4 octets
+-------------------------------+
| Control Word |
| (See Figure 4) | 4 octets
+-------------------------------+
| Payload |
| (Frame relay frame |
| information field) | n octets
| |
+-------------------------------+
+-------------------------------+
| MPLS Tunnel label(s) | n*4 octets (four octets per label)
+-------------------------------+
| PW label | 4 octets
+-------------------------------+
| Control Word |
| (See Figure 4) | 4 octets
+-------------------------------+
| Payload |
| (Frame relay frame |
| information field) | n octets
| |
+-------------------------------+
Figure 3. Frame Relay over MPLS PSN Packet for the One-to-One Mapping
图3。用于一对一映射的MPLS PSN数据包上的帧中继
The meaning of the different fields is as follows:
不同字段的含义如下：
- MPLS Tunnel label(s)
- MPLS隧道标签
The MPLS Tunnel label(s) corresponds to the MPLS transport header of Figure 2. The label(s) is/are used by MPLS LSRs to forward a PW packet from one PE to the other.
MPLS隧道标签对应于图2的MPLS传输头。MPLS LSR使用标签将PW数据包从一个PE转发到另一个PE。
- PW Label
- PW标签
The PW label identifies one PW (i.e., one LSP) assigned to a frame relay VC in one direction. It corresponds to the PW header of Figure 2. Together the MPLS Tunnel label(s) and PW label form an MPLS label stack [RFC3032].
PW标签标识在一个方向上分配给帧中继VC的一个PW（即，一个LSP）。它对应于图2的PW标题。MPLS隧道标签和PW标签一起构成MPLS标签堆栈[RFC3032]。
- Control Word
- 控制字
The Control Word contains protocol control information. Its structure is shown in Figure 4.
控制字包含协议控制信息。其结构如图4所示。
- Payload
- 有效载荷
The payload field corresponds to X.36/X.76 frame relay frame information field with the following components removed: bit/byte stuffing, frame relay header, and FCS. It is RECOMMENDED to support a frame size of at least 1600 bytes. The maximum length of the payload field MUST be agreed upon by the two PEs. This can be achieved by using the MTU interface parameter when the PW is established. [RFC4447]
有效载荷字段对应于X.36/X.76帧中继帧信息字段，删除了以下组件：位/字节填充、帧中继报头和FCS。建议支持至少1600字节的帧大小。有效载荷字段的最大长度必须由两个PEs商定。这可以通过在建立PW时使用MTU接口参数来实现。[RFC4447]
The control word defined below is REQUIRED for frame relay one-to-one mode. The control word carries certain frame relay specific information that is necessary to regenerate the frame relay frame on the egress PE. Additionally, the control word also carries a sequence number that can be used to preserve sequentiality when carrying frame relay over an MPLS network. Its structure is as follows:
帧中继一对一模式需要以下定义的控制字。控制字携带某些帧中继特定信息，这些信息是在出口PE上重新生成帧中继帧所必需的。此外，控制字还携带序列号，该序列号可用于在通过MPLS网络携带帧中继时保持序列性。其结构如下：
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|F|B|D|C|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|F|B|D|C|FRG| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Control Word structure for the one-to-one mapping mode
图4。一对一映射模式的控制字结构
The meaning of the Control Word fields (Figure 4) is as follows (see also [X36 and X76] for frame relay bits):
控制字字段（图4）的含义如下（帧中继位另见[X36和X76]：
- Bits 0 to 3
- 位0到3
In the above diagram, the first 4 bits MUST be set to 0 to indicate PW data.
在上图中，前4位必须设置为0以指示PW数据。
- F (bit 4) FR FECN (Forward Explicit Congestion Notification) bit.
- F（位4）FR FECN（前向显式拥塞通知）位。
- B (bit 5) FR BECN (Backward Explicit Congestion Notification) bit.
- B（位5）FR BECN（向后显式拥塞通知）位。
- D (bit 6) FR DE bit (Discard Eligibility) bit.
- D（位6）FR DE位（丢弃合格性）位。
- C (bit 7) FR frame C/R (Command/Response) bit.
- C（第7位）帧前C/R（命令/响应）位。
- FRG (bits 8 and 9): These bits are defined by [RFC4623].
- FRG（位8和9）：这些位由[RFC4623]定义。
- Length (bits 10 to 15)
- 长度（第10位到第15位）
If the PW traverses a network link that requires a minimum frame size (a notable example is Ethernet), padding is required to reach its minimum frame size. If the frame's length (defined as the length of the layer 2 payload plus the length of the control word) is less than 64 octets, the length field MUST be set to the PW payload length. Otherwise, the length field MUST be set to zero. The value of the length field, if non-zero, is used to remove the padding characters by the egress PE.
如果PW通过需要最小帧大小的网络链路（一个显著的例子是以太网），则需要填充以达到其最小帧大小。如果帧的长度（定义为第2层有效负载的长度加上控制字的长度）小于64个八位字节，则必须将长度字段设置为PW有效负载长度。否则，长度字段必须设置为零。长度字段的值（如果非零）用于删除出口PE的填充字符。
- Sequence number (Bit 16 to 31)
- 序列号（第16位至第31位）
Sequence numbers provide one possible mechanism to ensure the ordered delivery of PW packets. The processing of the sequence number field is OPTIONAL. The sequence number space is a 16-bit unsigned circular space. The sequence number value 0 is used to indicate that the sequence number check algorithm is not used.
序列号提供了一种可能的机制来确保PW数据包的有序传递。序列号字段的处理是可选的。序列号空间是一个16位无符号循环空间。序号值0用于指示未使用序号检查算法。
For backward compatibility to existing implementations, the following version of the control word is defined as the "martini mode CW" for frame relay.
为了向后兼容现有实现，以下版本的控制字被定义为帧中继的“martini模式CW”。
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|B|F|D|C|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|B|F|D|C|FRG| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. Control Word structure for the frame relay martini mode
图5。帧中继martini模式的控制字结构
Note that the "B" and "F" bits are reversed.
请注意，“B”和“F”位是反向的。
This control word format is used for PW type "Frame Relay DLCI ( Martini Mode )"
此控制字格式用于PW类型的“帧中继DLCI（Martini模式）”
The encapsulation process of a frame relay frame is initiated when a PE receives a frame relay frame from one of its frame relay UNI or NNI [FRF1] [FRF2] interfaces. The PE generates the following fields
当PE从其帧中继UNI或NNI[FRF1][FRF2]接口之一接收帧中继帧时，帧中继帧的封装过程启动。PE生成以下字段
of the control word from the corresponding fields of the frame relay frame as follows:
从帧中继帧的相应字段中选择控制字，如下所示：
- Command/Response (C/R or C) bit: The C bit is copied unchanged in the PW Control Word.
- 命令/响应（C/R或C）位：在PW控制字中，C位复制不变。
- The DE bit of the frame relay frame is copied into the D bit field. However, if the D bit is not already set, it MAY be set as a result of ingress frame policing. If it is not already set by the copy operation, setting of this bit by a PE is OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1).
- 帧中继帧的DE位复制到D位字段中。但是，如果尚未设置D位，则可将其设置为入口帧监控的结果。如果复制操作尚未设置该位，则PE对此位的设置是可选的。PE不得清除该位（如果接收到的值为1，则将其设置为0）。
- The FECN bit of the frame relay frame is copied into the F bit field. However, if the F bit is not already set, it MAY be set to reflect a congestion situation detected by the PE. If it is not already set by the copy operation, setting of this bit by a PE is OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1)
- 帧中继帧的FECN位被复制到F位字段中。然而，如果尚未设置F位，则可以将其设置为反映PE检测到的拥塞情况。如果复制操作尚未设置该位，则PE对此位的设置是可选的。PE不得清除该位（如果收到的值为1，则将其设置为0）
- The BECN bit of the frame relay frame is copied into the B bit field. However, if the B bit is not already set, it MAY be set to reflect a congestion situation detected by the PE. If it is not already set by the copy operation, setting of this bit by a PE is OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1).
- 帧中继帧的BECN位被复制到B位字段中。然而，如果尚未设置B比特，则可以将其设置为反映PE检测到的拥塞情况。如果复制操作尚未设置该位，则PE对此位的设置是可选的。PE不得清除该位（如果接收到的值为1，则将其设置为0）。
- If the PW packet length (defined as the length of the payload plus the length of the control word) is less than 64 octets, the length field MUST be set to the packet's length. Otherwise, the length field MUST be set to zero.
- 如果PW数据包长度（定义为有效负载的长度加上控制字的长度）小于64个八位字节，则必须将长度字段设置为数据包的长度。否则，长度字段必须设置为零。
- The sequence number field is processed if the PW uses sequence numbers. [RFC4385]
- 如果PW使用序列号，则处理序列号字段。[RFC4385]
- The payload of the PW packet is the contents of ITU-T Recommendations X.36/X.76 [X36] [X76] frame relay frame information field stripped from any bit or byte stuffing.
- PW数据包的有效载荷是ITU-T建议X.36/X.76[X36][X76]帧中继帧信息字段的内容，该字段从任何位或字节填充中剥离。
For a given PW and a pair of routers PE1 and PE2, if PE1 supports packet sequencing, then the procedures in [RFC4385], Section 4.1, MUST be followed.
对于给定的PW和一对路由器PE1和PE2，如果PE1支持分组排序，则必须遵循[RFC4385]第4.1节中的程序。
When a PE receives a PW packet, it processes the different fields of the control word in order to decapsulate the frame relay frame for transmission to a CE on a frame relay UNI or NNI. The PE performs the following actions (not necessarily in the order shown):
当PE接收到PW分组时，它处理控制字的不同字段，以便解除帧中继帧的封装，以便传输到帧中继UNI或NNI上的CE。PE执行以下操作（不一定按所示顺序）：
- It generates the following frame relay frame header fields from the corresponding fields of the PW packet.
- 它从PW数据包的相应字段生成以下帧中继帧报头字段。
- The C/R bit MUST be copied in the frame relay header.
- 必须在帧中继头中复制C/R位。
- The D bit MUST be copied into the frame relay header DE bit.
- D位必须复制到帧中继头DE位。
- The F bit MUST be copied into the frame relay header FECN bit. If the F bit is set to zero, the FECN bit may be set to one, depending on the congestion state of the PE device in the forward direction. Changing the state of this bit by a PE is OPTIONAL.
- 必须将F位复制到帧中继头FECN位。如果F比特被设置为零，则FECN比特可以被设置为1，这取决于PE设备在前进方向上的拥塞状态。通过PE更改此位的状态是可选的。
- The B bit MUST be copied into the frame relay header BECN bit. If the B bit is set to zero, the BECN bit may be set to one, depending on the congestion state of the PE device in the backward direction. Changing the state of this bit by a PE is OPTIONAL.
- 必须将B位复制到帧中继头BECN位。如果B位被设置为零，则BECN位可以被设置为1，这取决于PE设备在向后方向上的拥塞状态。通过PE更改此位的状态是可选的。
- It processes the length and sequence field, the details of which are in the following sub-sections.
- 它处理长度和顺序字段，详细信息见以下小节。
- It copies the frame relay information field from the contents of the PW packet payload after removing any padding.
- 删除任何填充后，它从PW数据包有效负载的内容复制帧中继信息字段。
Once the above fields of a FR frame have been processed, the standard HDLC operations are performed on the frame relay frame: the HDLC header is added, any bit or byte stuffing is added as required, and the FCS is also appended to the frame. The FR frame is then queued for transmission on the selected frame relay UNI or NNI interface.
处理完FR帧的上述字段后，将在帧中继帧上执行标准HDLC操作：添加HDLC报头，根据需要添加任何位或字节填充，并将FCS附加到帧。然后，FR帧排队等待在所选帧中继UNI或NNI接口上传输。
If a router PE2 supports received sequence number processing, then the procedures in [RFC4385], Section 4.2, MUST be used.
如果路由器PE2支持接收序列号处理，则必须使用[RFC4385]第4.2节中的程序。
Any padding octet, if present, in the payload field of a PW packet received MUST be removed before forwarding the data.
在转发数据之前，必须删除接收到的PW数据包的有效负载字段中的任何填充八位组（如果存在）。
- If the Length field is set to zero, then there are no padding octets following the payload field.
- 如果长度字段设置为零，则有效负载字段后面没有填充八位字节。
- Otherwise, if the payload is longer, then the length specified in the control word padding characters are removed according to the length field.
- 否则，如果有效负载更长，则根据长度字段删除控制字填充字符中指定的长度。
If it is desired to carry Quality of Service information, the Quality of Service information SHOULD be represented in the Experimental Use Bits (EXP) field of the PW MPLS label [RFC3032]. If more than one MPLS label is imposed by the ingress LSR, the EXP field of any labels higher in the stack SHOULD also carry the same value.
如果需要携带服务质量信息，服务质量信息应在PW MPLS标签[RFC3032]的实验使用位（EXP）字段中表示。如果入口LSR施加了多个MPLS标签，则堆栈中任何较高标签的EXP字段也应具有相同的值。
The ingress LSR, PE1, MUST set the S bit of the PW label to a value of 1 to denote that the PW label is at the bottom of the stack.
入口LSR PE1必须将PW标签的S位设置为值1，以表示PW标签位于堆栈底部。
The PE MUST provide frame relay PVC status signaling to the frame relay network. If the PE detects a service-affecting condition for a particular DLCI, as defined in [Q933] Q.933, Annex A.5, sited in IA FRF1.1, the PE MUST communicate to the remote PE the status of the PW that corresponds to the frame relay DLCI status. The Egress PE SHOULD generate the corresponding errors and alarms as defined in [Q922] [Q933] on the egress Frame relay PVC.
PE必须向帧中继网络提供帧中继PVC状态信令。如果PE检测到IA FRF1.1中[Q933]Q.933附录a.5中定义的特定DLCI的服务影响条件，则PE必须向远程PE传达与帧中继DLCI状态相对应的PW状态。出口PE应产生出口帧继电器PVC上[Q922][Q933]中定义的相应错误和警报。
There are two frame relay flags to control word bit mappings described below. The legacy bit ordering scheme will be used for a PW of type 0x0001, "Frame Relay DLCI (Martini Mode)", and the new bit ordering scheme will be used for a PW of type 0x0019, "Frame Relay DLCI". The IANA allocation registry of "Pseudowire Type" is defined in [RFC4446] along with initial allocated values.
有两个帧中继标志用于控制下面描述的字位映射。旧位排序方案将用于0x0001类型的PW，“帧中继DLCI（Martini模式）”，新位排序方案将用于0x0019类型的PW，“帧中继DLCI”。[RFC4446]中定义了“伪导线类型”的IANA分配注册表以及初始分配值。
A separate document, [RFC4447], describes the PW control and maintenance protocol in detail, including generic interface parameter sub-TLVs. The interface parameter information, when applicable, MUST be used to validate that the PEs and the ingress and egress ports at the edges of the circuit have the necessary capabilities to interoperate with each other. The Interface parameter TLV is defined in [RFC4447], and the IANA registry with initial values for interface parameter sub-TLV types is defined in [RFC4446], but the frame relay specific interface parameter sub-TLV types are specified as follows:
另一份文件[RFC4447]详细描述了PW控制和维护协议，包括通用接口参数子TLV。接口参数信息（如适用）必须用于验证PEs和电路边缘的入口和出口端口是否具有相互互操作的必要能力。接口参数TLV在[RFC4447]中定义，带有接口参数子TLV类型初始值的IANA注册表在[RFC4446]中定义，但帧中继特定接口参数子TLV类型指定如下：
- 0x08 Frame Relay Header Length Sub-TLV
- 0x08帧中继头长度子TLV
An optional 16-bit value indicating the length of the FR Header, expressed in octets. This OPTIONAL interface parameter Sub-TLV can have value of 2, 3, or 4, the default being 2. If this Sub-TLV is not present, the default value of 2 is assumed.
一个可选的16位值，指示FR报头的长度，以八位字节表示。此可选接口参数Sub TLV的值可以为2、3或4，默认值为2。如果此子TLV不存在，则假定默认值为2。
The frame relay port mode PW shares the same encapsulation as the HDLC PW and is described in the respective document. [RFC4618]
帧中继端口模式PW与HDLC PW共享相同的封装，并且在相应的文档中描述。[RFC4618]
As explained in [RFC3985], the PSN carrying the PW may be subject to congestion, the characteristics of which depend on PSN type, network architecture, configuration, and loading. During congestion, the PSN may exhibit packet loss that will impact the service carried by the frame relay PW. In addition, since frame relay PWs carry a variety of services across the PSN, including but not restricted to TCP/IP, they may or may not behave in a TCP-friendly manner prescribed by [RFC2914]. In the presence of services that reduce transmission rate, frame relay PWs may thus consume more than their fair share and in that case SHOULD be halted.
如[RFC3985]中所述，承载PW的PSN可能会发生拥塞，其特征取决于PSN类型、网络架构、配置和负载。在拥塞期间，PSN可能表现出分组丢失，这将影响帧中继PW承载的服务。此外，由于帧中继PW在PSN上承载各种服务，包括但不限于TCP/IP，因此它们可能以[RFC2914]规定的TCP友好方式运行，也可能不以[RFC2914]规定的方式运行。在存在降低传输速率的服务的情况下，帧中继pw因此可能消耗超过其公平份额的能量，并且在这种情况下应该停止。
Whenever possible, frame relay PWs should be run over traffic-engineered PSNs providing bandwidth allocation and admission control mechanisms. IntServ-enabled domains providing the Guaranteed Service (GS) or DiffServ-enabled domains using EF (expedited forwarding) are examples of traffic-engineered PSNs. Such PSNs will minimize loss and delay while providing some degree of isolation of the frame relay PW's effects from neighboring streams.
只要有可能，帧中继PW应在提供带宽分配和准入控制机制的流量工程PSN上运行。提供保证服务（GS）的支持IntServ的域或使用EF（加速转发）的支持DiffServ的域是流量工程PSN的示例。这种psn将最小化丢失和延迟，同时提供帧中继PW的影响与相邻流的某种程度的隔离。
Note that when transporting frame relay, DiffServ-enabled domains may use AF (Assured Forwarding) and/or DF (Default Forwarding) instead of EF, in order to place less burden on the network and to gain additional statistical multiplexing advantage. In particular, if the Committed Information Rate (CIR) of a frame relay VC is zero, then it is equivalent to a best-effort UDP over IP stream regarding congestion: the network is free to drop frames as necessary. In this case, the "DF" Per Hop Behavior (PHB) would be appropriate in a diff-serv-TE domain. Alternatively, if the CIR of a frame relay VC is nonzero and the DE bit is zero in the FR header, then "AF31" would be appropriate to be used, and if the CIR of a frame relay VC is nonzero but the DE bit is on, then "AF32" would be appropriate [RFC3270].
注意，当传输帧中继时，启用区分服务的域可以使用AF（保证转发）和/或DF（默认转发）而不是EF，以便减轻网络负担并获得额外的统计复用优势。特别是，如果帧中继VC的提交信息速率（CIR）为零，则它相当于关于拥塞的尽力UDP over IP流：网络可以根据需要自由丢弃帧。在这种情况下，“DF”每跳行为（PHB）适用于区分服务域。或者，如果帧中继VC的CIR为非零且FR报头中的DE位为零，则“AF31”将适合使用，并且如果帧中继VC的CIR为非零但DE位为on，则“AF32”将适合使用[RFC3270]。
The PEs SHOULD monitor for congestion (by using explicit congestion notification, [VCCV], or by measuring packet loss) in order to ensure that the service using the frame relay PW may be maintained. When a
PEs应监控拥塞（通过使用显式拥塞通知[VCCV]或通过测量数据包丢失），以确保使用帧中继PW的服务可以保持。当
PE detects significant congestion while receiving the PW PDUs, the BECN bits of the frame relay frame transmitted on the same PW SHOULD be set to notify the remote PE and the remote frame relay switch of the congestion situation. In addition, the FECN bits SHOULD be set in the FR frames sent out the attachment circuit, to give the FR DTE a chance to adjust its transport layer advertised window, if possible.
PE在接收PW PDU时检测到严重拥塞，应设置在同一PW上传输的帧中继帧的BECN位，以通知远程PE和远程帧中继交换机拥塞情况。此外，FECN比特应设置在发送到连接电路的FR帧中，以使FR DTE有机会在可能的情况下调整其传输层广告窗口。
If the PW has been set up using the protocol defined in [RFC4447], then procedures specified in [RFC4447] for status notification can be used to disable packet transmission on the ingress PE from the egress PE. The PW may be restarted by manual intervention, or by automatic means after an appropriate waiting time.
如果已使用[RFC4447]中定义的协议设置PW，则[RFC4447]中指定的状态通知程序可用于禁用入口PE上来自出口PE的数据包传输。PW可通过手动干预或在适当的等待时间后通过自动方式重新启动。
PWE3 provides no means of protecting the contents or delivery of the PW packets on behalf of the native service. PWE3 may, however, leverage security mechanisms provided by the MPLS Tunnel Layer. A more detailed discussion of PW security is given in [RFC3985, RFC4447, RFC3916].
PWE3不提供代表本机服务保护PW数据包的内容或传递的方法。然而，PWE3可以利用MPLS隧道层提供的安全机制。[RFC3985、RFC4447、RFC3916]中对PW安全性进行了更详细的讨论。
[RFC4447] Martini, L., 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.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 43852006年2月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]Martini，L.，“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，2006年4月。
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of Point to Point Protocol/High-Level Data Link Control (PPP/HDLC) over Multiprotocol Label Switching (MPLS) Networks", RFC 4618, September 2006.
[RFC4618]Martini，L.，Rosen，E.，Heron，G.，和A.Malis，“多协议标签交换（MPLS）网络上点对点协议/高级数据链路控制（PPP/HDLC）传输的封装方法”，RFC 4618，2006年9月。
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006.
[RFC4623]Malis，A.和M.Townsley，“伪线仿真边到边（PWE3）碎片化和重组”，RFC 46232006年8月。
[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., et al., "Pseudo Wire Virtual Circuit Connection Verification (VCCV)", Work in Progress, October 2005.
[VCCV]Nadeau，T.，等人，“伪导线虚拟电路连接验证（VCCV）”，正在进行的工作，2005年10月。
[ATM] Martini, L., et al., "Encapsulation Methods for Transport of ATM Over MPLS Networks", Work in Progress, April 2005.
[ATM]Martini，L.等人，“通过MPLS网络传输ATM的封装方法”，正在进行的工作，2005年4月。
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]Martini，L.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，2006年4月。
[FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement, Frame Relay Forum, April 2000.
[FRF1]FRF.1.2，帧中继PVC UNI实施协议，帧中继论坛，2000年4月。
[FRF2] FRF.2.2, Frame relay PVC UNI Implementation Agreement, Frame Relay Forum, April 2002
[FRF2]FRF.2.2，帧中继PVC UNI实施协议，帧中继论坛，2002年4月
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
[RFC3916]Xiao，X.，McPherson，D.，和P.Pate，“伪线仿真边到边（PWE3）的要求”，RFC 39162004年9月。
[X36] ITU-T Recommendation X.36, Interface between a DTE and DCE for public data networks providing frame relay, Geneva, 2000.
[X36]ITU-T建议X.36，提供帧中继的公共数据网络DTE和DCE之间的接口，日内瓦，2000年。
[X76] ITU-T Recommendation X.76, Network-to-network interface between public data networks providing frame relay services, Geneva,2000
[X76]ITU-T建议X.76，提供帧中继服务的公共数据网络之间的网络对网络接口，日内瓦，2000年
[Q922] ITU-T Recommendation Q.922 Specification for Frame Mode Basic call control, ITU Geneva 1995
[Q922]ITU-T建议Q.922帧模式基本呼叫控制规范，ITU日内瓦1995
[Q933] ITU-T Recommendation Q.933 Specification for Frame Mode Basic call control, ITU Geneva 2003
[Q933]ITU-T建议Q.933帧模式基本呼叫控制规范，ITU日内瓦2003
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
Contributing Author Information
投稿人信息
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave Sunnyvale，加利福尼亚州94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT英国
EMail: giles.heron@tellabs.com
EMail: giles.heron@tellabs.com
Rao Cherukuri Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
Rao Cherukuri Juniper Networks 1194 N.Mathilda Ave Sunnyvale，加利福尼亚州94089
Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140
Dimitri Stratton Vlachos Mazu Networks，Inc.马萨诸塞州剑桥剑桥市剑桥公园大道125号，邮编：02140
EMail: d@mazunetworks.com
EMail: d@mazunetworks.com
Chris Liljenstolpe Alcatel 11600 Sallie Mae Dr. 9th Floor Reston, VA 20193
Chris Liljenstolpe Alcatel 11600 Sallie Mae博士，弗吉尼亚州雷斯顿市9楼，邮编20193
EMail: chris.liljenstolpe@alcatel.com
EMail: chris.liljenstolpe@alcatel.com
Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021
Nasser El Aawar三级通信有限责任公司，埃尔多拉多大道1025号。科罗拉多州布鲁姆菲尔德，80021
EMail: nna@level3.net
EMail: nna@level3.net
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
Eric C.Rosen Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com
Dan Tappan Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
Dan Tappan Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: tappan@cisco.com
EMail: tappan@cisco.com
Prayson Pate Overture Networks, Inc. 507 Airport Boulevard Morrisville, NC, USA 27560
Prayson Pate Overture Networks，Inc.美国北卡罗来纳州莫里斯维尔机场大道507号，邮编27560
EMail: prayson.pate@overturenetworks.com
EMail: prayson.pate@overturenetworks.com
David Sinicrope Ericsson IPI
David Sinicrope Ericsson IPI
EMail: david.sinicrope@ericsson.com
EMail: david.sinicrope@ericsson.com
Ravi Bhat Nokia
诺基亚拉维·巴特
EMail: ravi.bhat@nokia.com
EMail: ravi.bhat@nokia.com
Nishit Vasavada Nokia
尼希特瓦萨瓦达诺基亚
EMail: nishit.vasavada@nokia.com
EMail: nishit.vasavada@nokia.com
Steve Vogelsang ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205
宾夕法尼亚州匹兹堡欧米茄大道1300号Steve Vogelsang ECI电信欧米茄公司中心15205
EMail: stephen.vogelsang@ecitele.com
EMail: stephen.vogelsang@ecitele.com
Vinai Sirkay Redback Networks 300 Holger Way, San Jose, CA 95134
Vinai Sirkay Redback Networks加利福尼亚州圣何塞霍尔格路300号，邮编95134
EMail: sirkay@technologist.com
EMail: sirkay@technologist.com
Authors' Addresses
作者地址
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
Claude Kawa OZ Communications Windsor Station 1100, de la Gauchetie`re St West Montreal QC Canada H3B 2S2
克劳德·卡瓦OZ通信温莎站1100号，加拿大蒙特利尔西区戴高什蒂街QC H3B 2S2
EMail: claude.kawa@oz.com
EMail: claude.kawa@oz.com
Andrew G. Malis Tellabs 1415 West Diehl Road Naperville, IL 60563
伊利诺伊州纳珀维尔西迪尔路1415号安德鲁·G·马里斯·特拉伯斯，邮编：60563
EMail: Andy.Malis@tellabs.com
EMail: Andy.Malis@tellabs.com
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）提供。