Network Working Group L. Martini, Ed.
Request for Comments: 4906 E. Rosen, Ed.
Category: Historic Cisco Systems, Inc.
N. El-Aawar, Ed.
Level 3 Communications, LLC
June 2007
Network Working Group L. Martini, Ed.
Request for Comments: 4906 E. Rosen, Ed.
Category: Historic Cisco Systems, Inc.
N. El-Aawar, Ed.
Level 3 Communications, LLC
June 2007
Transport of Layer 2 Frames Over MPLS
通过MPLS传输第2层帧
Status of This Memo
关于下段备忘
This memo defines a Historic Document for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
此备忘录定义了互联网社区的历史文档。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents.
本文档描述了传输第2层协议（如帧中继、异步传输模式（ATM）适配层5（AAL5）和以太网）的协议数据单元（PDU）以及跨MPLS网络提供同步光网络（SONET）电路仿真服务的方法。本文件描述了所谓的“马提尼草案”协议，该协议已被RFC 4447和相关文件中描述的伪线仿真边到边工作组规范所取代。
Table of Contents
目录
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. Special Note ....................................................3
4. Tunnel Labels and Virtual Circuit (VC) Labels ...................4
5. Protocol-Specific Details .......................................5
5.1. Frame Relay ................................................5
5.2. ATM ........................................................6
5.2.1. ATM AAL5 VCC Transport ..............................6
5.2.2. ATM Transparent Cell Transport ......................6
5.2.3. ATM VCC and VPC Cell Transport ......................6
5.2.4. OAM Cell Support ....................................6
5.2.5. ILMI Support ........................................7
5.3. Ethernet VLAN ..............................................7
5.4. Ethernet ...................................................8
5.5. HDLC .......................................................8
5.6. PPP ........................................................8
6. LDP .............................................................8
6.1. Interface Parameters Field ................................10
6.2. C Bit Handling Procedures .................................12
6.2.1. VC Types for Which the Control Word is REQUIRED ....12
6.2.2. VC Types for Which the Control Word is NOT
Mandatory ..........................................12
6.2.3. Status Codes .......................................15
6.3. LDP Label Withdrawal Procedures ...........................15
6.4. Sequencing Considerations .................................15
6.4.1. Label Mapping Advertisements .......................15
6.4.2. Label Mapping Release ..............................16
7. IANA Considerations ............................................16
8. Security Considerations ........................................16
9. Normative References ...........................................17
10. Informative References ........................................18
11. Co-Authors ....................................................18
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. Special Note ....................................................3
4. Tunnel Labels and Virtual Circuit (VC) Labels ...................4
5. Protocol-Specific Details .......................................5
5.1. Frame Relay ................................................5
5.2. ATM ........................................................6
5.2.1. ATM AAL5 VCC Transport ..............................6
5.2.2. ATM Transparent Cell Transport ......................6
5.2.3. ATM VCC and VPC Cell Transport ......................6
5.2.4. OAM Cell Support ....................................6
5.2.5. ILMI Support ........................................7
5.3. Ethernet VLAN ..............................................7
5.4. Ethernet ...................................................8
5.5. HDLC .......................................................8
5.6. PPP ........................................................8
6. LDP .............................................................8
6.1. Interface Parameters Field ................................10
6.2. C Bit Handling Procedures .................................12
6.2.1. VC Types for Which the Control Word is REQUIRED ....12
6.2.2. VC Types for Which the Control Word is NOT
Mandatory ..........................................12
6.2.3. Status Codes .......................................15
6.3. LDP Label Withdrawal Procedures ...........................15
6.4. Sequencing Considerations .................................15
6.4.1. Label Mapping Advertisements .......................15
6.4.2. Label Mapping Release ..............................16
7. IANA Considerations ............................................16
8. Security Considerations ........................................16
9. Normative References ...........................................17
10. Informative References ........................................18
11. Co-Authors ....................................................18
In an MPLS network, it is possible to carry the Protocol Data Units (PDUs) of layer 2 protocols by prepending an MPLS label stack to these PDUs. This document specifies the necessary label distribution procedures for accomplishing this using the encapsulation methods in [RFC4905]. We restrict discussion to the case of point-to-point transport. Quality of service (QoS)-related issues are not discussed in this document. This document describes methods for transporting a number of protocols; in some cases, transporting a particular protocol may have several modes of operation. Each of these protocols and/or modes may be implemented independently.
在MPLS网络中，通过向第2层协议的协议数据单元（PDU）预先添加MPLS标签堆栈，可以承载这些PDU。本文件规定了使用[RFC4905]中的封装方法实现此目的所需的标签分发程序。我们只讨论点到点传输的情况。本文档不讨论与服务质量（QoS）相关的问题。本文件描述了传输多个协议的方法；在某些情况下，传输特定协议可能有多种操作模式。这些协议和/或模式中的每一个都可以独立地实现。
An accompanying document [CEM] also describes a method for transporting time division multiplexed (TDM) digital signals (TDM circuit emulation) over a packet-oriented MPLS network. The transmission system for circuit-oriented TDM signals is the Synchronous Optical Network (SONET) [ANSI.T1.105] / Synchronous Digital Hierarchy (SDH) [ITU.G.707]. To support TDM traffic, which includes voice, data, and private leased line service, the MPLS network must emulate the circuit characteristics of SONET/SDH payloads. MPLS labels and a new circuit emulation header are used to encapsulate TDM signals and provide the Circuit Emulation Service over MPLS (CEM).
随附文档[CEM]还描述了一种用于在面向分组的MPLS网络上传输时分复用（TDM）数字信号（TDM电路仿真）的方法。面向电路的TDM信号传输系统是同步光网络（SONET）[ANSI.T1.105]/同步数字体系（SDH）[ITU.G.707]。为了支持TDM业务，包括语音、数据和专用专线服务，MPLS网络必须模拟SONET/SDH有效负载的电路特性。MPLS标签和新的电路仿真报头用于封装TDM信号，并通过MPLS（CEM）提供电路仿真服务。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document describes the so-called "draft-martini" protocol, which is used in many deployed implementations. This document and its contents have since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications: [RFC4447], [RFC4385], [RFC4448], [RFC4717], [RFC4618], [RFC4619], [RFC4553], [RFC4842], and related documents. This document serves as a documentation of current implementations, and MUST NOT be used for new implementations. The PWE3 Label Distribution Protocol (LDP) control document [RFC4447], which is backward compatible with this document, MUST be used for all new implementations of this protocol.
本文档描述了所谓的“draft martini”协议，该协议用于许多已部署的实现中。本文件及其内容已被伪线仿真边到边工作组规范[RFC4447]、[RFC4385]、[RFC4448]、[RFC4717]、[RFC4618]、[RFC4619]、[RFC4553]、[RFC4842]和相关文件所取代。本文档作为当前实施的文档，不得用于新的实施。与本文件向后兼容的PWE3标签分发协议（LDP）控制文件[RFC4447]必须用于本协议的所有新实现。
Suppose it is desired to transport layer 2 PDUs from ingress Label Switching Router (LSR) R1 to egress LSR R2, across an intervening MPLS network. We assume that there is a Label Switched Path (LSP) from R1 to R2. That is, we assume that R1 can cause a packet to be delivered to R2 by pushing some label onto the packet and sending the result to one of its adjacencies. Call this label the "tunnel label", and the corresponding LSP the "tunnel LSP".
假设需要通过介入MPLS网络将第2层pdu从入口标签交换路由器（LSR）R1传输到出口LSR R2。我们假设有一条从R1到R2的标签交换路径（LSP）。也就是说，我们假设R1可以通过将某个标签推到数据包上并将结果发送到其相邻的一个位置，从而将数据包传递给R2。将此标签称为“隧道标签”，相应的LSP称为“隧道LSP”。
The tunnel LSP merely gets packets from R1 to R2; the corresponding label doesn't tell R2 what to do with the payload. In fact, if penultimate hop popping is used, R2 may never even see the corresponding label. (If R1 itself is the penultimate hop, a tunnel label may not even get pushed on.) Thus, if the payload is not an IP packet, there must be a label, which becomes visible to R2, that tells R2 how to treat the received packet. Call this label the "VC label".
隧道LSP仅从R1到R2获取数据包；相应的标签没有告诉R2如何处理有效负载。事实上，如果使用倒数第二跳弹出，R2甚至可能永远看不到相应的标签。（如果R1本身是倒数第二个跃点，则隧道标签甚至可能不会被推上。）因此，如果有效负载不是IP数据包，则必须有一个标签，该标签对R2可见，告诉R2如何处理接收到的数据包。将此标签称为“VC标签”。
So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on its label stack, and then (if R1 is not adjacent to R2) pushes on a tunnel label. The tunnel label gets the MPLS packet from R1 to R2; the VC label is not visible until the MPLS packet reaches R2. R2's disposition of the packet is based on the VC label.
因此，当R1向R2发送第2层PDU时，它首先在其标签堆栈上推送一个VC标签，然后（如果R1与R2不相邻）推送一个隧道标签。隧道标签获取从R1到R2的MPLS数据包；在MPLS数据包到达R2之前，VC标签不可见。R2对数据包的处理基于VC标签。
Note that the tunnel could be a Generic Routing Encapsulation (GRE)- encapsulated MPLS tunnel between R1 and R2. In this case, R1 would be adjacent to R2, and only the VC label would be used, and the intervening network need only carry IP packets.
注意，隧道可以是R1和R2之间的通用路由封装（GRE）封装MPLS隧道。在这种情况下，R1将与R2相邻，并且只使用VC标签，并且中间网络只需要携带IP数据包。
If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, the VC label will generally correspond to a particular ATM VC at R2. That is, R2 needs to be able to infer from the VC label the outgoing interface and the VPI/VCI (Virtual Path Identifier / Virtual Circuit Identifier) value for the AAL5 PDU. If the payload is a Frame Relay PDU, then R2 needs to be able to infer from the VC label the outgoing interface and the DLCI (Data Link Connection Identifier) value. If the payload is an Ethernet frame, then R2 needs to be able to infer from the VC label the outgoing interface, and perhaps the VLAN identifier. This process is unidirectional, and will be repeated independently for bidirectional operation. It is REQUIRED to assign the same VC ID, and VC type for a given circuit in both directions. The group ID (see below) MUST NOT be required to match in both directions. The transported frame MAY be modified when it reaches the egress router. If the header of the transported layer 2 frame is modified, this MUST be done at the egress LSR only.
如果MPLS分组的有效载荷是例如ATM AAL5 PDU，则VC标签通常对应于R2处的特定ATM VC。也就是说，R2需要能够从VC标签推断AAL5 PDU的输出接口和VPI/VCI（虚拟路径标识符/虚拟电路标识符）值。如果有效载荷是帧中继PDU，则R2需要能够从VC标签推断出输出接口和DLCI（数据链路连接标识符）值。如果有效负载是以太网帧，那么R2需要能够从VC标签推断出输出接口，可能还有VLAN标识符。此过程是单向的，将独立重复以进行双向操作。要求在两个方向上为给定电路分配相同的VC ID和VC类型。组ID（见下文）不必在两个方向上都匹配。传输的帧可以在到达出口路由器时被修改。如果传输的第2层帧的报头被修改，则这必须仅在出口LSR处完成。
Note that the VC label must always be at the bottom of the label stack, and the tunnel label, if present, must be immediately above the VC label. Of course, as the packet is transported across the MPLS network, additional labels may be pushed on (and then popped off) as needed. Even R1 itself may push on additional labels above the tunnel label. If R1 and R2 are directly adjacent LSRs, then it may not be necessary to use a tunnel label at all.
请注意，VC标签必须始终位于标签堆栈的底部，隧道标签（如果存在）必须位于VC标签的正上方。当然，当数据包通过MPLS网络传输时，可能会根据需要推上（然后弹出）附加标签。甚至R1本身也可能在通道标签上方推上其他标签。如果R1和R2是直接相邻的LSR，则可能根本不需要使用隧道标签。
This document does not specify a method for distributing the tunnel label or any other labels that may appear above the VC label on the stack. Any acceptable method of MPLS label distribution will do.
本文档未指定分发隧道标签或堆栈上VC标签上方可能出现的任何其他标签的方法。任何可接受的MPLS标签分发方法都可以。
This document does specify a method for assigning and distributing the VC label. Static label assignment MAY be used, and implementations SHOULD provide support for this. When signaling is used, the VC label MUST be distributed from R2 to R1 using LDP in the downstream unsolicited mode; this requires that an LDP session be created between R1 and R2. It should be noted that this LDP session is not necessarily transported along the same path as the Layer 2 PDUs [RFC3036]. In addition, when using LDP to distribute the VC label, liberal label retention mode SHOULD be used. However, as required in [RFC3036], the label request operation (mainly used by conservative label retention mode) MUST be implemented. VC labels MUST be allocated from the per-platform label space.
本文档确实指定了分配和分发VC标签的方法。可以使用静态标签分配，实现应该为此提供支持。当使用信令时，VC标签必须在下游非请求模式下使用LDP从R2分配到R1；这需要在R1和R2之间创建LDP会话。应注意，该LDP会话不一定沿着与第2层PDU[RFC3036]相同的路径传输。此外，当使用LDP分发VC标签时，应使用自由标签保留模式。但是，根据[RFC3036]中的要求，必须执行标签请求操作（主要由保守的标签保留模式使用）。必须从每个平台标签空间分配VC标签。
Note that this technique allows an unbounded number of layer 2 "VCs" to be carried together in a single "tunnel". Thus, it scales quite well in the network backbone.
请注意，该技术允许在单个“隧道”中携带无限数量的第2层“VCs”。因此，它在网络主干中的扩展性相当好。
While this document currently defines the emulation of Frame Relay and ATM Permanent Virtual Circuit (PVC) services, it specifically does not preclude future enhancements to support switched service (Switched Virtual Circuit (SVC) and Switched Permanent Virtual Circuit (SPVC)) emulation.
虽然本文档目前定义了帧中继和ATM永久虚拟电路（PVC）服务的仿真，但它并不排除将来支持交换服务（交换虚拟电路（SVC）和交换永久虚拟电路（SPVC））仿真的增强功能。
The Frame Relay PDUs are encapsulated according to the procedures defined in [RFC4905]. The MPLS edge LSR MUST provide Frame Relay PVC status signaling to the Frame Relay network. If the MPLS edge LSR detects a service affecting condition, as defined in [Q.933] Annex A.5 cited in Implementation Agreement FRF.1.1, it MUST withdraw the label that corresponds to the frame relay DLCI. The egress LSR SHOULD generate the corresponding errors and alarms as defined in [Q.933] on the egress Frame relay VC.
帧中继PDU根据[RFC4905]中定义的程序进行封装。MPLS边缘LSR必须向帧中继网络提供帧中继PVC状态信令。如果MPLS边缘LSR检测到服务影响条件，如实施协议FRF.1.1中引用的[Q.933]附录a.5中所定义，则其必须撤销与帧中继DLCI相对应的标签。出口LSR应在出口帧继电器VC上生成[Q.933]中定义的相应错误和警报。
ATM AAL5 Common Part Convergence Sublayer - Service Data Units (CPCS-SDUs) are encapsulated according to [RFC4905] ATM AAL5 CPCS-SDU mode. This mode allows the transport of ATM AAL5 CSPS-SDUs traveling on a particular ATM PVC across the MPLS network to another ATM PVC.
ATM AAL5公共部分汇聚子层-业务数据单元（CPCS SDU）根据[RFC4905]ATM AAL5 CPCS-SDU模式进行封装。此模式允许通过MPLS网络将在特定ATM PVC上运行的ATM AAL5 CSP SDU传输到另一个ATM PVC。
This mode is similar to the Ethernet port mode. Every cell that is received at the ingress ATM port on the ingress LSR, R1, is encapsulated according to [RFC4905], ATM cell mode, and sent across the LSP to the egress LSR, R2. This mode allows an ATM port to be connected to only one other ATM port. [RFC4905] allows for grouping of multiple cells into a single MPLS frame. Grouping of ATM cells is OPTIONAL for transmission at the ingress LSR, R1. If the Egress LSR R2 supports cell concatenation, the ingress LSR, R1, should only concatenate cells up to the "Maximum Number of concatenated ATM cells" parameter received as part of the FEC element.
此模式类似于以太网端口模式。在入口LSR R1上的入口ATM端口处接收的每个信元根据[RFC4905]ATM信元模式进行封装，并通过LSP发送到出口LSR R2。此模式允许ATM端口仅连接到另一个ATM端口。[RFC4905]允许将多个小区分组到单个MPLS帧中。ATM信元分组对于入口LSR R1处的传输是可选的。如果出口LSR R2支持信元级联，则入口LSR R1应仅级联作为FEC元素的一部分接收的最大级联ATM信元数参数以下的信元。
This mode is similar to the ATM AAL5 Virtual Channel Connection (VCC) transport except that cells are transported. Every cell that is received on a pre-defined ATM PVC or ATM Permanent Virtual Path (PVP), at the ingress ATM port on the ingress LSR, R1, is encapsulated according to [RFC4905], ATM cell mode, and sent across the LSP to the egress LSR R2. Grouping of ATM cells is OPTIONAL for transmission at the ingress LSR, R1. If the egress LSR R2 supports cell concatenation, the ingress LSR, R1, MUST only concatenate cells up to the "Maximum Number of concatenated ATM cells in a frame" parameter received as part of the FEC element.
此模式类似于ATM AAL5虚拟通道连接（VCC）传输，只是传输信元。在入口LSR R1上的入口ATM端口处，在预定义的ATM PVC或ATM永久虚拟路径（PVP）上接收的每个信元根据[RFC4905]ATM信元模式进行封装，并通过LSP发送到出口LSR R2。ATM信元分组对于入口LSR R1处的传输是可选的。如果出口LSR R2支持信元级联，则入口LSR R1必须仅级联作为FEC元素的一部分接收的“帧中级联的ATM信元的最大数目”参数以下的信元。
Operations and Management (OAM) cells MAY be transported on the VC LSP. When the LSR is operating in AAL5 CPCS-SDU transport mode, if it does not support transport of ATM cells, the LSR MUST discard incoming MPLS frames on an ATM VC LSP that contain a VC label with the T bit set [RFC4905]. When operating in AAL5 SDU transport mode, an LSR that supports transport of OAM cells using the T bit defined in [RFC4905], or an LSR operating in any of the three cell transport modes, MUST follow the procedures outlined in [FAST] Section 8 for mode 0 only, in addition to the applicable procedures specified in [ITU.G.707].
操作和管理（OAM）单元可以在VC LSP上传输。当LSR在AAL5 CPCS-SDU传输模式下运行时，如果它不支持ATM信元的传输，则LSR必须丢弃ATM VC LSP上包含设置了T位的VC标签的传入MPLS帧[RFC4905]。在AAL5 SDU传输模式下运行时，支持使用[RFC4905]中定义的T位传输OAM小区的LSR，或在三种小区传输模式中的任何一种模式下运行的LSR，除了[ITU.G.707]中规定的适用程序外，必须遵循[FAST]第8节中针对模式0概述的程序。
AN LSR that does not support transport of OAM cells across an LSP MAY provide OAM support on ATM PVCs using the following procedures:
不支持跨LSP传输OAM信元的LSR可以使用以下过程在ATM PVC上提供OAM支持：
A pair of LSRs MAY emulate a bidirectional ATM VC by two unidirectional LSPs. If an F5 end-to-end OAM cell is received from a ATM VC, by either LSR that is transporting this ATM VC, with a loopback indication value of 1, and the LSR has a label mapping for the ATM VC, then the LSR MUST decrement the loopback indication value and loop back the cell on the ATM VC. Otherwise, the loopback cell MUST be discarded by the LSR.
一对LSR可以通过两个单向LSP模拟双向ATM VC。如果通过传输此ATM VC的任一LSR接收到来自ATM VC的F5端到端OAM信元，且回送指示值为1，且LSR具有ATM VC的标签映射，则LSR必须减小回送指示值并在ATM VC上回送信元。否则，LSR必须丢弃环回单元。
The ingress LSR, R1, may also optionally be configured to periodically generate F5 end-to-end loopback OAM cells on a VC. If the LSR fails to receive a response to an F5 end-to-end loopback OAM cell for a pre-defined period of time it MUST withdraw the label mapping for the VC.
入口LSR R1还可以可选地配置为在VC上周期性地生成F5端到端环回OAM单元。如果LSR在预定义的时间段内未能接收到对F5端到端环回OAM单元的响应，则必须撤销VC的标签映射。
If an ingress LSR, R1, receives an AIS (Alarm Indication Signal) F5 OAM cell, or R1 fails to receive a pre-defined number of the End-to-End loop OAM cells, or a physical interface goes down, it MUST withdraw the label mappings for all VCs associated with the failure. When a VC label mapping is withdrawn, the egress LSR, R2, MUST generate AIS F5 OAM cells on the VC associated with the withdrawn label mapping. In this mode it is very useful to apply a unique group ID to each interface. In the case where a physical interface goes down, a wild card label withdraw can be sent to all LDP neighbors, greatly reducing the signaling response time.
如果入口LSR R1接收到AIS（报警指示信号）F5 OAM单元，或者R1未能接收到预定义数量的端到端环路OAM单元，或者物理接口出现故障，则必须撤销与故障相关的所有VCs的标签映射。当撤销VC标签映射时，出口LSR R2必须在与撤销的标签映射相关联的VC上生成AIS F5 OAM单元。在此模式下，将唯一的组ID应用于每个接口非常有用。在物理接口中断的情况下，可以向所有LDP邻居发送通配符标签撤回，从而大大缩短信令响应时间。
An MPLS edge LSR MAY provide an ATM Integrated Local Management Interface (ILMI) to the ATM edge switch. If an ingress LSR receives an ILMI message indicating that the ATM edge switch has deleted a VC, or if the physical interface goes down, it MUST withdraw the label mappings for all VCs associated with the failure. When a VC label mapping is withdrawn, the egress LSR SHOULD notify its client of this failure by deleting the VC using ILMI.
MPLS边缘LSR可向ATM边缘交换机提供ATM集成本地管理接口（ILMI）。如果入口LSR接收到一条ILMI消息，指示ATM边缘交换机已删除一个VC，或者如果物理接口关闭，则必须撤销与故障相关的所有VC的标签映射。当撤销VC标签映射时，出口LSR应通过使用ILMI删除VC来通知其客户端此失败。
The Ethernet frame will be encapsulated according to the procedures in [RFC4905]. It should be noted that if the VLAN identifier is modified by the egress LSR, according to the procedures outlined above, the Ethernet spanning tree protocol might fail to work properly. If the LSR detects a failure on the Ethernet physical
以太网帧将按照[RFC4905]中的程序进行封装。应当注意，如果出口LSR根据上述步骤修改VLAN标识符，则以太网生成树协议可能无法正常工作。如果LSR检测到以太网物理层出现故障
port, or the port is administratively disabled, it MUST withdraw the label mappings for all VCs associated with the port.
端口，或者该端口已被管理禁用，则必须撤消与该端口关联的所有VCs的标签映射。
The Ethernet frame will be encapsulated according to the procedures in [RFC4905]. If the LSR detects a failure on the Ethernet physical port, or the port is administratively disabled, the corresponding VC label mapping MUST be withdrawn.
以太网帧将按照[RFC4905]中的程序进行封装。如果LSR在以太网物理端口上检测到故障，或者该端口被管理禁用，则必须撤销相应的VC标签映射。
HDLC (High-Level Data Link Control) frames are encapsulated according to the procedures in [RFC4905]. If the MPLS edge LSR detects that the physical link has failed, or the port is administratively disabled, it MUST withdraw the label mapping that corresponds to the HDLC link.
HDLC（高级数据链路控制）帧按照[RFC4905]中的程序进行封装。如果MPLS边缘LSR检测到物理链路出现故障，或者端口被管理性禁用，则必须撤消与HDLC链路对应的标签映射。
PPP frames are encapsulated according to the procedures in [RFC4905]. If the MPLS edge LSR detects that the physical link has failed, or the port is administratively disabled, it MUST withdraw the label mapping that corresponds to the PPP link.
PPP帧按照[RFC4905]中的程序进行封装。如果MPLS边缘LSR检测到物理链路出现故障，或者端口被管理性禁用，则必须撤回与PPP链路对应的标签映射。
The VC label bindings are distributed using the LDP downstream unsolicited mode described in [RFC3036]. The LSRs will establish an LDP session using the Extended Discovery mechanism described in sections 2.4.2 and 2.5 of [RFC3036]; for this purpose, a new type of FEC element is defined. The FEC element type is 128. Only a single VC FEC element MUST be advertised per LDP VC label. The Virtual Circuit FEC element is defined as follows:
VC标签绑定使用[RFC3036]中所述的LDP下游非请求模式分发。LSR将使用[RFC3036]第2.4.2和2.5节所述的扩展发现机制建立LDP会话；为此，定义了一种新型FEC元件。FEC元素类型为128。每个LDP VC标签只能播发一个VC FEC元素。虚拟电路FEC元件定义如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC tlv |C| VC Type |VC info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface parameters |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC tlv |C| VC Type |VC info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface parameters |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- VC Type
- VC型
A 15-bit quantity containing a value that represents the type of VC. Assigned values are:
包含代表VC类型的值的15位量。指定值为：
VC Type Description
VC类型说明
0x0001 Frame Relay DLCI 0x0002 ATM AAL5 VCC transport 0x0003 ATM transparent cell transport 0x0004 Ethernet VLAN 0x0005 Ethernet 0x0006 HDLC 0x0007 PPP 0x8008 CEM [CEM] 0x0009 ATM VCC cell transport 0x000A ATM VPC cell transport
0x0001帧中继DLCI 0x0002 ATM AAL5 VCC传输0x0003 ATM透明信元传输0x0004以太网VLAN 0x0005以太网0x0006 HDLC 0x0007 PPP 0x8008 CEM[CEM]0x0009 ATM VCC信元传输0x000A ATM VPC信元传输
- Control word bit (C)
- 控制字位（C）
The highest order bit (C) of the VC type is used to flag the presence of a control word (defined in [RFC4905]) as follows:
VC类型的最高阶位（C）用于标记控制字（在[RFC4905]中定义）的存在，如下所示：
bit 15 = 1 control word present on this VC. bit 15 = 0 no control word present on this VC.
位15=此VC上存在1个控制字。位15=0此VC上不存在控制字。
Please see Section 6.2, "C Bit Handling Procedures", for further explanation.
请参阅第6.2节“C位处理程序”，了解更多说明。
- VC information length
- 信息长度
Length of the VC ID field and the interface parameters field in octets. If this value is 0, then it references all VCs using the specified group ID, and there is no VC ID present, nor any interface parameters.
VC ID字段和接口参数字段的长度（以八位字节为单位）。如果此值为0，则它使用指定的组ID引用所有VCs，并且不存在VC ID，也不存在任何接口参数。
- Group ID
- 组ID
An arbitrary 32-bit value, which represents a group of VCs that is used to create groups in the VC space. The group ID is intended to be used as a port index, or a virtual tunnel index. To simplify configuration, a particular VC ID at ingress could be part of the virtual tunnel for transport to the egress router. The group ID is very useful to send wild card label withdrawals to remote LSRs upon physical port failure.
任意32位值，表示用于在VC空间中创建组的一组VC。组ID将用作端口索引或虚拟隧道索引。为了简化配置，入口的特定VC ID可以是虚拟通道的一部分，用于传输到出口路由器。组ID对于在物理端口发生故障时向远程LSR发送通配符标签取款非常有用。
- VC ID
- VC ID
A non-zero 32-bit connection ID that, together with the VC type, identifies a particular VC.
一个非零32位连接ID，与VC类型一起标识特定的VC。
- Interface parameters
- 界面参数
This variable length field is used to provide interface-specific parameters, such as interface MTU.
此可变长度字段用于提供特定于接口的参数，如接口MTU。
This field specifies interface-specific parameters. When applicable, it MUST be used to validate that the LSRs, and the ingress and egress ports at the edges of the circuit, have the necessary capabilities to interoperate with each other. The field structure is defined as follows:
此字段指定特定于接口的参数。适用时，必须使用它来验证LSR以及电路边缘的入口和出口端口是否具有相互互操作的必要能力。字段结构定义如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The parameter ID is defined as follows:
参数ID的定义如下：
Parameter ID Length Description
参数ID长度描述
0x01 4 Interface MTU in octets. 0x02 4 Maximum Number of concatenated ATM cells. 0x03 up to 82 Optional Interface Description string. 0x04 4 CEM [CEM] Payload Bytes. 0x05 4 CEM options.
0x01 4以八位字节为单位的接口MTU。0x02 4连接的ATM信元的最大数量。0x03最多82个可选接口描述字符串。0x04 4 CEM[CEM]有效负载字节。0x05 4 CEM选项。
The Length field is defined as the length of the interface parameter including the Parameter ID and Length field itself. Processing of the interface parameters should continue when encountering unknown interface parameters, and they MUST be silently ignored.
长度字段定义为接口参数的长度，包括参数ID和长度字段本身。当遇到未知的接口参数时，接口参数的处理应该继续进行，并且必须默默地忽略它们。
- Interface MTU
- 接口MTU
A 2-octet value indicating the MTU in octets. This is the Maximum Transmission Unit, excluding encapsulation overhead, of the egress packet interface that will be transmitting the decapsulated PDU that is received from the MPLS network. This
以八位字节表示MTU的2位八位字节值。这是将要传输从MPLS网络接收的解封装PDU的出口分组接口的最大传输单元，不包括封装开销。这
parameter is applicable only to VC types 1, 2, 4, 5, 6, and 7, and is REQUIRED for these VC types. If this parameter does not match in both directions of a specific VC, that VC MUST NOT be enabled.
参数仅适用于VC类型1、2、4、5、6和7，并且对于这些VC类型是必需的。如果此参数在特定VC的两个方向上不匹配，则不得启用该VC。
- Maximum Number of concatenated ATM cells
- 级联ATM信元的最大数目
A 2-octet value specifying the maximum number of concatenated ATM cells that can be processed as a single PDU by the egress LSR. An ingress LSR transmitting concatenated cells on this VC can concatenate a number of cells up to the value of this parameter, but MUST NOT exceed it. This parameter is applicable only to VC types 3, 9, and 0x0a, and is REQUIRED for these VC types. This parameter does not need to match in both directions of a specific VC.
2个八位组的值，指定出口LSR可以作为单个PDU处理的级联ATM信元的最大数量。在此VC上传输级联单元的入口LSR可以级联多个单元，最多可达此参数的值，但不得超过此值。此参数仅适用于VC类型3、9和0x0a，并且是这些VC类型所必需的。此参数不需要在特定VC的两个方向上都匹配。
- Optional Interface Description string
- 可选接口描述字符串
This arbitrary, OPTIONAL interface description string can be used to send an administrative description text string to the remote LSR. This parameter is OPTIONAL, and is applicable to all VC types. The interface description parameter string length is variable, and can be from 0 to 80 octets.
此任意、可选的接口描述字符串可用于向远程LSR发送管理描述文本字符串。此参数是可选的，适用于所有VC类型。接口描述参数字符串长度是可变的，可以是0到80个八位字节。
- Payload Bytes
- 有效负载字节
A 2-octet value indicating the number of TDM payload octets contained in all packets on the CEM stream from 48 to 1,023 octets. All of the packets in a given CEM stream have the same number of payload bytes. Note that there is a possibility that the packet size may exceed the Synchronous Payload Envelope (SPE) size in the case of an STS-1 SPE, which could cause two pointers to be needed in the CEM header, since the payload may contain two J1 bytes for consecutive SPEs. For this reason, the number of payload bytes must be less than or equal to 783 for STS-1 SPEs.
2个八位字节值，表示CEM流上所有数据包中包含的TDM有效负载八位字节数，从48个八位字节到1023个八位字节。给定CEM流中的所有数据包具有相同数量的有效负载字节。请注意，在STS-1 SPE的情况下，数据包大小可能会超过同步有效负载信封（SPE）大小，这可能导致CEM报头中需要两个指针，因为对于连续SPE，有效负载可能包含两个J1字节。因此，对于STS-1 SPE，有效负载字节数必须小于或等于783。
- CEM Options
- CEM选项
An optional 16-bit value of CEM flags. See [CEM] for the definition of the bit values.
CEM标志的可选16位值。有关位值的定义，请参见[CEM]。
The Label Mapping messages which are sent in order to set up these VCs MUST have c=1. When a Label Mapping message for a VC of one of these types is received, and c=0, a Label Release MUST be sent, with an "Illegal C-bit" status code. In this case, the VC will not come up.
为设置这些VCs而发送的标签映射消息必须具有c=1。当收到这些类型之一的VC的标签映射消息，且c=0时，必须发送标签释放，并带有“非法c位”状态代码。在这种情况下，VC不会出现。
If a system is capable of sending and receiving the control word on VC types for which the control word is not mandatory, then each such VC endpoint MUST be configurable with a parameter that specifies whether the use of the control word is PREFERRED or NOT PREFERRED. For each VC, there MUST be a default value of this parameter. This specification does NOT state what the default value should be.
如果系统能够在控制字不是强制的VC类型上发送和接收控制字，则每个这样的VC端点必须可以配置一个参数，该参数指定是否首选使用控制字。对于每个VC，必须有此参数的默认值。此规范没有说明默认值应该是什么。
If a system is NOT capable of sending and receiving the control word on VC types for which the control word is not mandatory, then it behaves exactly as if it were configured for the use of the control word to be NOT PREFERRED.
如果系统不能在VC类型上发送和接收控制字，而控制字不是强制的，那么它的行为就如同它被配置为不首选使用控制字一样。
If a Label Mapping message for the VC has already been received, but no Label Mapping message for the VC has yet been sent, then the procedure is the following:
如果已收到VC的标签映射消息，但尚未发送VC的标签映射消息，则程序如下：
-i. If the received Label Mapping message has c=0, send a Label Mapping message with c=0, and the control word is not used.
-一,。如果收到的标签映射消息的c=0，则发送c=0的标签映射消息，并且不使用控制字。
-ii. If the received Label Mapping message has c=1, and the VC is locally configured such that the use of the control word is preferred, then send a Label Mapping message with c=1, and the control word is used.
-二,。如果收到的标签映射消息的c=1，并且VC在本地配置为首选使用控制字，则发送c=1的标签映射消息，并使用控制字。
-iii. If the received Label Mapping message has c=1, and the VC is locally configured such that the use of the control word is not preferred or the control word is not supported, then act as if no Label Mapping message for the VC had been received (i.e., proceed to the next paragraph).
-iii.如果接收到的标签映射消息的c=1，并且VC在本地配置为不首选使用控制字或不支持控制字，那么就如同没有接收到VC的标签映射消息一样（即，继续下一段）。
If a Label Mapping message for the VC has not already been received (or if the received Label Mapping message had c=1, and either local configuration says that the use of the control word is not preferred or the control word is not supported), then send a Label Mapping message in which the c bit is set to correspond to the locally configured preference for use of the control word. (That is, set c=1
如果尚未收到VC的标签映射消息（或者如果收到的标签映射消息的c=1，并且本地配置表示不首选使用控制字或不支持控制字），然后发送标签映射消息，其中c位设置为与本地配置的首选项相对应，以使用控制字。（即，设置c=1
if locally configured to prefer the control word, set c=0 if locally configured to prefer not to use the control word or if the control word is not supported).
如果本地配置为首选控制字，则如果本地配置为首选不使用控制字或不支持控制字，则设置c=0）。
The next action depends on what control message is next received for that VC. The possibilities are:
下一个操作取决于下一个接收到的VC控制消息。可能性是：
-i. A Label Mapping message with the same c bit value as specified in the Label Mapping message that was sent. VC setup is now complete, and the control word is used if c=1 but not used if c=0.
-一,。具有与发送的标签映射消息中指定的相同c位值的标签映射消息。VC设置现已完成，如果c=1，则使用控制字，如果c=0，则不使用控制字。
-ii. A Label Mapping message with c=1, but the Label Mapping message that was sent has c=0. In this case, ignore the received Label Mapping message, and continue to wait for the next control message for the VC.
-二,。c=1的标签映射消息，但发送的标签映射消息的c=0。在这种情况下，忽略收到的标签映射消息，并继续等待VC的下一条控制消息。
-iii. A Label Mapping message with c=0, but the Label Mapping message that was sent has c=1. In this case, send a Label Withdraw message with a "Wrong C-bit" status code, followed by a Label Mapping message that has c=0. VC setup is now complete, and the control word is not used.
-iii.c=0的标签映射消息，但发送的标签映射消息的c=1。在这种情况下，发送一条带有“错误C位”状态代码的标签撤销消息，然后发送一条C=0的标签映射消息。VC设置现在已完成，并且未使用控制字。
-iv. A Label Withdraw message with the "Wrong C-bit" status code. Treat as a normal Label Withdraw, but do not respond. Continue to wait for the next control message for the VC.
-iv.带有“错误C位”状态代码的标签撤销信息。视为正常标签，但不响应。继续等待VC的下一条控制消息。
If, at any time after a Label Mapping message has been received, a corresponding Label Withdraw or Release is received, the action taken is the same as for any Label Withdraw or Release that might be received at any time.
如果在收到标签映射消息后的任何时间，收到相应的标签撤回或释放，则所采取的操作与可能在任何时间收到的任何标签撤回或释放的操作相同。
If both endpoints prefer the use of the control word, this procedure will cause it to be used. If either endpoint prefers not to use the control word, or does not support the control word, this procedure will cause it not to be used. If one endpoint prefers to use the control word but the other does not, the one that prefers not to use it is has no extra protocol to execute; it just waits for a Label Mapping message that has c=0.
如果两个端点都喜欢使用控制字，则此过程将使用该控制字。如果任一端点不喜欢使用控制字，或不支持该控制字，则此过程将导致不使用该控制字。如果一个端点喜欢使用控制字，而另一个不喜欢，则不喜欢使用控制字的端点没有额外的协议可执行；它只等待c=0的标签映射消息。
The following diagram illustrates the above procedures:
下图说明了上述步骤：
------------------
Y | Received Label | N
-------| Mapping Msg? |--------------
| ------------------ |
| |
-------------- |
| | |
| | |
------- ------- |
| C=0 | | C=1 | |
------- ------- |
| | |
| | |
| ---------------- |
| | Control Word | N |
| | Capable? |----------- |
| ---------------- | |
| Y | | |
| | | |
| ---------------- | |
| | Control Word | N | |
| | Preferred? |---- | |
| ---------------- | | |
| Y | | | |
| | | | ----------------
| | | | | Control Word |
| | | | | Preferred? |
| | | | ----------------
| | | | N | Y |
| | | | | |
Send Send Send Send Send Send
C=0 C=1 C=0 C=0 C=0 C=1
| | | |
----------------------------------
| If receive the same as sent, |
| VC setup is complete. If not: |
----------------------------------
| | | |
------------------- -----------
| Receive | | Receive |
| C=1 | | C=0 |
------------------- -----------
| |
Wait for the Send
next message Wrong C-Bit
|
Send Label Mapping
Message with C=0
------------------
Y | Received Label | N
-------| Mapping Msg? |--------------
| ------------------ |
| |
-------------- |
| | |
| | |
------- ------- |
| C=0 | | C=1 | |
------- ------- |
| | |
| | |
| ---------------- |
| | Control Word | N |
| | Capable? |----------- |
| ---------------- | |
| Y | | |
| | | |
| ---------------- | |
| | Control Word | N | |
| | Preferred? |---- | |
| ---------------- | | |
| Y | | | |
| | | | ----------------
| | | | | Control Word |
| | | | | Preferred? |
| | | | ----------------
| | | | N | Y |
| | | | | |
Send Send Send Send Send Send
C=0 C=1 C=0 C=0 C=0 C=1
| | | |
----------------------------------
| If receive the same as sent, |
| VC setup is complete. If not: |
----------------------------------
| | | |
------------------- -----------
| Receive | | Receive |
| C=1 | | C=0 |
------------------- -----------
| |
Wait for the Send
next message Wrong C-Bit
|
Send Label Mapping
Message with C=0
RFC 3036 has a range of Status Code values, which are assigned by IANA on a First Come, First Served basis. These are in the range 0x20000000-0x3effffff. The following new status codes are defined:
RFC 3036有一系列状态代码值，由IANA根据先到先得原则分配。这些在0x20000000-0x3EFFFFF范围内。定义了以下新的状态代码：
0x20000001 "Illegal C-Bit" 0x20000002 "Wrong C-Bit"
0x2000001“非法C位”0x2000002“错误C位”
As mentioned above, the Group ID field can be used to withdraw all VC labels associated with a particular group ID. This procedure is OPTIONAL, and if it is implemented, the LDP label withdraw message should be as follows: the VC information length field is set to 0, the VC ID field is not present, and the interface parameters field is not present. For the purpose of this document, this is called the "wild card withdraw procedure", and all LSRs implementing this design are REQUIRED to accept such a withdraw message, but are not required to send it.
如上所述，组ID字段可用于提取与特定组ID关联的所有VC标签。此过程是可选的，如果实现，LDP标签提取消息应如下所示：VC信息长度字段设置为0，VC ID字段不存在，并且接口参数字段不存在。在本文件中，这称为“通配符撤销程序”，所有实施此设计的LSR都需要接受此类撤销消息，但不需要发送该消息。
The interface parameters field MUST NOT be present in any LDP VC label withdrawal message or release message. A wild card release message MUST include only the group ID. A Label Release message initiated from the imposition router must always include the VC ID.
接口参数字段不得出现在任何LDP VC标签撤销消息或发布消息中。通配符释放消息必须仅包含组ID。从强制路由器启动的标签释放消息必须始终包含VC ID。
In the case where the router considers the sequence number field in the control word, it is important to note the following when advertising labels.
在路由器考虑控制字中的序列号字段的情况下，在广告标签时注意以下事项很重要。
After a label has been withdrawn by the disposition router and/or released by the imposition router, care must be taken to not re-advertise (reuse) the released label until the disposition router can be reasonably certain that old packets containing the released label no longer persist in the MPLS network.
在处置路由器撤回标签和/或强制路由器释放标签后，必须注意不要重新公布（重用）已释放的标签，直到处置路由器能够合理地确定包含已释放标签的旧数据包不再存在于MPLS网络中。
This precaution is required to prevent the imposition router from restarting packet forwarding with sequence number of 1 when it receives the same label mapping if there are still older packets persisting in the network with sequence number between 1 and 32768. For example, if there is a packet with sequence number=n where n is in the interval[1,32768] traveling through the network, it would be possible for the disposition router to receive that packet after it re-advertises the label. Since the label has been released by the
如果网络中仍然存在序列号介于1和32768之间的旧数据包，则需要此预防措施来防止强制路由器在接收到相同的标签映射时重新启动序列号为1的数据包转发。例如，如果存在序列号为n的分组，其中n在通过网络的间隔[132768]内，则处置路由器可能在其重新播发标签之后接收该分组。由于该标签已由
imposition router, the disposition router SHOULD be expecting the next packet to arrive with sequence number of 1. Receipt of a packet with sequence number equal to n will result in n packets potentially being rejected by the disposition router until the imposition router imposes a sequence number of n+1 into a packet. Possible methods to avoid this are for the disposition router to always advertise a different VC label, or for the disposition router to wait for a sufficient time before attempting to re-advertise a recently released label. This is only an issue when sequence number processing at the disposition router is enabled.
强制路由器，处置路由器应该期望下一个数据包以序列号1到达。接收序列号等于n的数据包将导致n个数据包可能被处置路由器拒绝，直到强制路由器将序列号n+1施加到数据包中。避免这种情况的可能方法是，处置路由器始终播发不同的VC标签，或者在尝试重新播发最近发布的标签之前，处置路由器等待足够的时间。只有在处置路由器上启用序列号处理时，这才是一个问题。
In situations where the imposition router wants to restart forwarding of packets with sequence number 1, the router shall 1) send a label mapping release to the disposition router, and 2) send a label mapping request to the disposition router. When sequencing is supported, advertisement of a VC label in response to a label mapping request MUST also consider the issues discussed in Section 6.4.1.
在强制路由器希望重新发送序列号为1的数据包的情况下，路由器应1）向处置路由器发送标签映射释放，2）向处置路由器发送标签映射请求。当支持测序时，响应标签映射请求的VC标签的广告也必须考虑6.4.1节中讨论的问题。
As specified in this document, a Virtual Circuit FEC element contains the VC Type field. VC Type value 0 is reserved. VC Type values 1 through 10 are defined in this document. VC Type values 11 through 63 are to be assigned by IANA using the "IETF Consensus" policy defined in RFC 2434. VC Type values 64 through 127 are to be assigned by IANA, using the "First Come First Served" policy defined in RFC 2434. VC Type values 128 through 32767 are vendor-specific, and values in this range are not to be assigned by IANA.
如本文档所述，虚拟电路FEC元素包含VC类型字段。VC类型值0是保留的。本文件中定义了VC类型值1至10。IANA将使用RFC 2434中定义的“IETF共识”策略分配VC类型值11至63。使用RFC 2434中定义的“先到先得”策略，IANA将分配VC类型值64到127。VC类型值128到32767是特定于供应商的，此范围内的值不由IANA分配。
As specified in this document, a Virtual Circuit FEC element contains the Interface Parameters field, which is a list of one or more parameters, and each parameter is identified by the Parameter ID field. Parameter ID value 0 is reserved. Parameter ID values 1 through 5 are defined in this document. Parameter ID values 6 through 63 are to be assigned by IANA using the "IETF Consensus" policy defined in RFC 2434. Parameter ID values 64 through 127 are to be assigned by IANA, using the "First Come First Served" policy defined in RFC 2434. Parameter ID values 128 through 255 are vendor-specific, and values in this range are not to be assigned by IANA.
如本文件所述，虚拟电路FEC元件包含接口参数字段，该字段是一个或多个参数的列表，每个参数由参数ID字段标识。保留参数ID值0。本文档中定义了参数ID值1到5。IANA将使用RFC 2434中定义的“IETF共识”策略分配参数ID值6至63。IANA将使用RFC 2434中定义的“先到先得”策略分配参数ID值64到127。参数ID值128到255是特定于供应商的，此范围内的值不由IANA分配。
This document does not affect the underlying security issues of MPLS, described in [RFC3032]. More detailed security considerations are also described in Section 8 of [RFC4447].
本文档不影响[RFC3032]中描述的MPLS的底层安全问题。[RFC4447]的第8节还描述了更详细的安全注意事项。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Ed.，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月。
[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC 4842, April 2007.
[RFC4842]Malis，A.，Pate，P.，Cohen，R.，Ed.，和D.Zelig，“同步光网络/同步数字体系（SONET/SDH）分组电路仿真（CEP）”，RFC 4842，2007年4月。
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553]Vainstein，A.，Ed.，和YJ。Stein，Ed.“数据包上的结构不可知时分复用（TDM）（SAToP）”，RFC4553，2006年6月。
[RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006.
[RFC4619]Martini，L.，Ed.，Kawa，C.，Ed.，和A.Malis，Ed.，“多协议标签交换（MPLS）网络上帧中继传输的封装方法”，RFC 4619，2006年9月。
[RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, December 2006.
[RFC4717]Martini，L.，Jayakumar，J.，Bocci，M.，El-Aawar，N.，Brayley，J.，和G.Koleyni，“MPLS网络上异步传输模式（ATM）传输的封装方法”，RFC 47172006年12月。
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[RFC4618]Martini，L.，Rosen，E.，Heron，G.，和A.Malis，“通过MPLS网络传输PPP/高级数据链路控制（HDLC）的封装方法”，RFC 4618，2006年9月。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，2006年4月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.，和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[Q.933] ITU-T Recommendation Q.933, and Q.922 Specification for Frame Mode Basic call control, ITU Geneva 1995.
[Q.933]ITU-T建议Q.933和Q.922帧模式基本呼叫控制规范，ITU日内瓦1995。
[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月。
[ANSI.T1.105] American National Standards Institute, "Synchronous Optical Network Formats," ANSI T1.105-1995.
[ANSI.T1.105]美国国家标准协会，“同步光网络格式”，ANSI T1.105-1995。
[ITU.G.707] ITU Recommendation G.707, "Network Node Interface For The Synchronous Digital Hierarchy", 1996.
[ITU.G.707]ITU建议G.707，“同步数字体系的网络节点接口”，1996年。
[RFC4905] Martini, L., Ed., Rosen, E., Ed., and N. El-Aawar, Ed., "Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks", RFC 4905, June 2007.
[RFC4905]Martini，L.，Ed.，Rosen，E.，Ed.，和N.El Aawar，Ed.，“MPLS网络上传输第2层帧的封装方法”，RFC 4905，2007年6月。
[CEM] Malis, A., Brayley, J., Vogelsang., S., Shirron, J., and L. Martini, "SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation", Work in Progress, June 2007.
[CEM]Malis，A.，Brayley，J.，Vogelsang.，S.，Shirron，J.，和L.Martini，“基于MPLS（CEM）封装的SONET/SDH电路仿真服务”，正在进行的工作，2007年6月。
[FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport (FAST)", af-fbatm-0151.000, July 2000.
[FAST]ATM论坛，“基于帧的SONET/SDH传输ATM（FAST）”，af-fbatm-0151.000，2000年7月。
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK EMail: giles.heron@tellabs.com
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT英国电子邮件：Giles。heron@tellabs.com
Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140 EMail: d@mazunetworks.com
Dimitri Stratton Vlachos Mazu Networks，Inc.马萨诸塞州剑桥市剑桥公园大道125号邮编：02140电子邮件：d@mazunetworks.com
Dan Tappan Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 EMail: tappan@cisco.com
Dan Tappan Cisco Systems，Inc.马萨诸塞州切姆斯福德阿波罗大道250号邮编01824电子邮件：tappan@cisco.com
Jayakumar Jayakumar, Cisco Systems Inc. 225, E.Tasman, MS-SJ3/3, San Jose, CA 95134 EMail: jjayakum@cisco.com
Jayakumar Jayakumar，思科系统公司225，E.塔斯曼，MS-SJ3/3，加利福尼亚州圣何塞，邮编95134电子邮件：jjayakum@cisco.com
Alex Hamilton, Cisco Systems Inc. 285 W. Tasman, MS-SJCI/3/4, San Jose, CA 95134 EMail: tahamilt@cisco.com
亚历克斯·汉密尔顿，思科系统公司285 W.塔斯曼，MS-SJCI/3/4，加利福尼亚州圣何塞95134电子邮件：tahamilt@cisco.com
Steve Vogelsang Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 EMail: sjv@laurelnetworks.com
Steve Vogelsang Laurel Networks，Inc.宾夕法尼亚州匹兹堡欧米茄大道1300号欧米茄企业中心15205电子邮件：sjv@laurelnetworks.com
John Shirron Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 EMail: jshirron@laurelnetworks.com
John Shirron Laurel Networks，Inc.宾夕法尼亚州匹兹堡欧米茄大道1300号欧米茄企业中心15205电子邮件：jshirron@laurelnetworks.com
Toby Smith Network Appliance, Inc. 800 Cranberry Woods Drive Suite 300 Cranberry Township, PA 16066 EMail: tob@netapp.com
Toby Smith Network Appliance，Inc.宾夕法尼亚州蔓越莓镇800蔓越莓树林大道300号套房16066电子邮件：tob@netapp.com
Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134 EMail: Andy.Malis@tellabs.com
Andrew G.Malis Tellabs 90 Rio Robles博士加利福尼亚州圣何塞95134电子邮件：Andy。Malis@tellabs.com
Vinai Sirkay Reliance Infocomm Dhirubai Ambani Knowledge City Navi Mumbai 400 709 India EMail: vinai@sirkay.com
Vinai Sirkay Reliance Infocomm Dhirubai Ambani知识城纳维孟买400 709印度电子邮件：vinai@sirkay.com
Vasile Radoaca Nortel Networks 600 Technology Park Billerica MA 01821 EMail: vasile@nortelnetworks.com
Vasile Radoaca Nortel Networks 600科技园Billerica MA 01821电子邮件：vasile@nortelnetworks.com
Chris Liljenstolpe Alcatel 11600 Sallie Mae Dr. 9th Floor Reston, VA 20193 EMail: chris.liljenstolpe@alcatel.com
Chris Liljenstolpe Alcatel 11600 Sallie Mae博士，弗吉尼亚州雷斯顿市9楼，邮编20193电子邮件：Chris。liljenstolpe@alcatel.com
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089 EMail: dcooper@gblx.net
Dave Cooper Global Crossing 960加利福尼亚州桑尼维尔哈姆林法院94089电子邮件：dcooper@gblx.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: kireeti@juniper.net
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave Sunnyvale，CA 94089电子邮件：kireeti@juniper.net
Authors' Addresses
作者地址
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 EMail: lmartini@cisco.com
Luca Martini Cisco Systems，Inc.地址：科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室，邮编：80112电子邮件：lmartini@cisco.com
Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO 80021 EMail: nna@level3.net
Nasser El Aawar三级通信有限责任公司，埃尔多拉多大道1025号。美国科罗拉多州布鲁姆菲尔德80021电子邮件：nna@level3.net
Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 EMail: erosen@cisco.com
Eric Rosen Cisco Systems，Inc.马萨诸塞州切姆斯福德阿波罗大道250号邮编01824电子邮件：erosen@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。