Internet Engineering Task Force (IETF) D. Beller
Request for Comments: 5718 Alcatel-Lucent
Category: Standards Track A. Farrel
ISSN: 2070-1721 Old Dog Consulting
January 2010
Internet Engineering Task Force (IETF) D. Beller
Request for Comments: 5718 Alcatel-Lucent
Category: Standards Track A. Farrel
ISSN: 2070-1721 Old Dog Consulting
January 2010
An In-Band Data Communication Network For the MPLS Transport Profile
用于MPLS传输配置文件的带内数据通信网络
Abstract
摘要
The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.
通用关联信道（G-ACh）已定义为伪线（PW）关联控制信道的泛化，以实现与多协议标签交换（MPLS）标签交换路径（LSP）、MPLS PWs、MPLS LSP段相关的控制/通信信道，以及相邻支持MPLS的设备之间的MPLS部分。
The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based on MPLS packet switching technology.
MPLS传输配置文件（MPLS-TP）是MPLS体系结构的配置文件，该配置文件识别MPLS工具包的元素，这些元素可被组合以基于MPLS分组交换技术构建载波级分组传输网络。
This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node.
本文件描述了G-ACh如何用于提供构成管理通信网络（MCN）和信令通信网络（SCN）一部分的基础设施。MCN和SCN统称为数据通信网络（DCN）。本文档解释了MCN和SCN消息如何被封装、携带在G-ACh上，以及如何被解复用以传送到MPLS-TP节点上的管理或信令/路由控制平面组件。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5718.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5718.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
The associated channel header (ACH) is specified in [RFC4385]. It is a packet header format for use on pseudowires (PWs) in order to identify packets used for Operations, Administration, and Maintenance (OAM) and similar functions.
相关信道头（ACH）在[RFC4385]中指定。它是一种用于伪线（PWs）的数据包头格式，用于识别用于操作、管理和维护（OAM）及类似功能的数据包。
The use of the ACH is generalized in [RFC5586] and can be applied on any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP). This is referred to as the Generic Associated Channel (G-ACh) and is intended to create a control/management communication channel associated with the LSP that can be used to carry packets used for OAM and similar functions (e.g., control/management plane messages).
ACH的使用在[RFC5586]中得到了推广，可以应用于任何多协议标签交换（MPLS）标签交换路径（LSP）。这被称为通用关联信道（G-ACh），旨在创建与LSP关联的控制/管理通信信道，该信道可用于承载用于OAM和类似功能（例如，控制/管理平面消息）的分组。
The purpose of a packet carried on the G-ACh is indicated by the value carried by the Channel Type field of the ACH and a registry of values is maintained by IANA ([RFC4446] and [RFC4385]). The ACH is referred to in this document as the G-ACh header.
G-ACh上携带的数据包的用途由ACh的信道类型字段携带的值表示，值的注册表由IANA（[RFC4446]和[RFC4385]）维护。ACH在本文件中称为G-ACH标题。
The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in [RFC5654]. MPLS-TP is the application of MPLS to construct a packet transport network. It constitutes a profile of MPLS that enables operational models typical in transport networks, which includes additional OAM, survivability, and other maintenance functions not previously supported by MPLS.
[MPLS-TP]和[RFC5654]中描述了MPLS传输配置文件（MPLS-TP）。MPLS-TP是MPLS在构建分组传输网络中的应用。它构成了MPLS的一个概要文件，支持传输网络中典型的操作模型，包括额外的OAM、生存能力和MPLS以前不支持的其他维护功能。
Label Switching Routers (LSRs) in MPLS networks may be operated using management protocols or control plane protocols. Messaging in these protocols is normally achieved using IP packets exchanged over IP-capable interfaces. However, some nodes in MPLS-TP networks may be constructed without support for direct IP encapsulation on their line-side interfaces and without access to an out-of-fiber data
MPLS网络中的标签交换路由器（LSR）可以使用管理协议或控制平面协议进行操作。这些协议中的消息传递通常使用通过支持IP的接口交换的IP数据包来实现。然而，MPLS-TP网络中的一些节点可能在其线路侧接口上不支持直接IP封装，也不访问光纤外数据
communication network. In order that such nodes can communicate using management plane or control plane protocols, channels must be provided, and the only available mechanism is to use an MPLS label.
通信网络。为了使这些节点能够使用管理平面或控制平面协议进行通信，必须提供信道，并且唯一可用的机制是使用MPLS标签。
The G-ACh provides a suitable mechanism for this purpose, and this document defines processes and procedures to allow the G-ACh to be used to build a Management Communication Network (MCN) and a Signaling Communication Network (SCN), together known as the Data Communication Network (DCN) [G.7712].
G-ACh为此目的提供了合适的机制，本文件定义了允许G-ACh用于构建管理通信网络（MCN）和信令通信网络（SCN）的过程和程序，统称为数据通信网络（DCN）[G.7712]。
It should be noted that the use of the G-ACh to provide connectivity for the DCN is intended for use only where the MPLS-TP network is not capable of encapsulating or delivering native DCN messages.
应注意，使用G-ACh为DCN提供连接仅用于MPLS-TP网络不能封装或传送本机DCN消息的情况。
The requirements presented in this section are based on those communicated to the IETF by the ITU-T.
本节中提出的要求基于ITU-T向IETF传达的要求。
1. A packet-encapsulation mechanism must be provided to support the transport of MCN and SCN packets over the G-ACh.
1. 必须提供数据包封装机制，以支持通过G-ACh传输MCN和SCN数据包。
2. The G-ACh carrying the MCN and SCN packets shall support the following application scenarios:
2. 承载MCN和SCN数据包的G-ACh应支持以下应用场景：
a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when the server layer does not provide a Management Communication Channel (MCC) or a Signalling Communication Channel (SCC)).
a. G-ACh互连两个相邻的MPLS-TP节点（当服务器层不提供管理通信信道（MCC）或信令通信信道（SCC）时使用）。
b. The G-ACh is carried by an MPLS-TP tunnel that traverses another operator's domain (the carrier's carrier scenario).
b. G-ACh由穿过另一运营商域（运营商的运营商场景）的MPLS-TP隧道承载。
3. The G-ACh shall provide two independent channels: an MCC to build the MCN and an SCC to build the SCN. The G-ACh packet header shall indicate whether the packet is an MCC or an SCC packet in order to forward it to the management or control plane application for processing. This facilitates easy demultiplexing of control and management traffic from the DCN, and enables separate or overlapping address spaces and duplicate protocol instances in the management and control planes.
3. G-ACh应提供两个独立通道：一个用于构建MCN的MCC和一个用于构建SCN的SCC。G-ACh数据包报头应指示数据包是MCC还是SCC数据包，以便将其转发给管理或控制平面应用程序进行处理。这有助于从DCN轻松分离控制和管理流量，并在管理和控制平面中启用单独或重叠的地址空间和重复的协议实例。
4. The channel-separation mechanism shall not preclude the use of separate rate limiters and traffic-shaping functions for each channel (MCC and SCC), ensuring that the flows do not exceed their assigned traffic profiles. The rate limiters and traffic shapers are outside the scope of the MCC and SCC definitions.
4. 信道分离机制不应排除对每个信道（MCC和SCC）使用单独的速率限制器和流量整形功能，以确保流量不超过其分配的流量剖面。速率限制器和流量整形器不在MCC和SCC定义的范围内。
5. The G-ACh that carries the MCC and SCC shall be capable of carrying different OSI layer 3 (network layer) PDUs. These shall include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC packet shall indicate which layer 3 PDU is contained in the payload field of the packet such that the packet can be delivered to the related layer 3 process within the management and control plane application, respectively, for further processing.
5. 承载MCC和SCC的G-ACh应能够承载不同的OSI第3层（网络层）PDU。这些应包括IPv4、IPv6和OSI PDU。MCC/SCC数据包的G-ACh报头应指示该数据包的有效载荷字段中包含的第3层PDU，以便该数据包可分别传送到管理和控制平面应用程序内的相关第3层进程以进行进一步处理。
6. The G-ACh is not required to provide specific security mechanisms. However, the management or control plane protocols that operate over the MCC or SCC are required to provide adequate security mechanisms in order to not be susceptible to security attacks.
6. G-ACh不需要提供特定的安全机制。然而，在MCC或SCC上运行的管理或控制平面协议需要提供足够的安全机制，以防受到安全攻击。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC-2119[RFC2119]中的说明进行解释。
Figure 1 depicts the format of an MCC/SCC packet that is sent on the G-ACh. The Channel Type field indicates the function of the ACH message and so, to send an MCC/SCC packet on the G-ACh, the MCC/SCC message is prepended with an ACH with the Channel Type set to indicate that the message is an MCC or SCC message. The ACH MUST NOT include the ACH TLV Header [RFC5586], meaning that no ACH TLVs can be included in the message. A two-byte Protocol Identifier (PID) field indicates the protocol type of the payload DCN message.
图1描述了在G-ACh上发送的MCC/SCC数据包的格式。信道类型字段指示ACH消息的功能，因此，为了在G-ACH上发送MCC/SCC数据包，MCC/SCC消息前面带有信道类型设置为指示消息是MCC或SCC消息的ACH。ACH不得包含ACH TLV头[RFC5586]，这意味着消息中不能包含ACH TLV。两字节协议标识符（PID）字段指示有效负载DCN消息的协议类型。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MCC/SCC Message |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MCC/SCC Message |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: G-ACh MCC/SCC Packet
图1:G-ACh MCC/SCC数据包
o The Channel Type field determines whether the message is an MCC or an SCC message. See Section 5 for the codepoint assignments.
o 通道类型字段确定消息是MCC消息还是SCC消息。有关代码点分配，请参见第5节。
o The presence of the PID field is deduced from the Channel Type value indicating MCC or SCC. The field contains an identifier of the payload protocol using the PPP protocol identifiers ([RFC1661], [RFC3818]).
o PID字段的存在是从指示MCC或SCC的通道类型值推断出来的。该字段包含使用PPP协议标识符的有效负载协议标识符（[RFC1661]、[RFC3818]）。
When the G-ACh sender receives an MCC message that is to be sent over the MCC, the sender creates the G-ACh header, sets the Channel Type field to MCC, fills in the PID to indicate the MCC layer 3 PDU type, and prepends the MCC message with the G-ACh header. The same procedure is applied when a control plane message is to be sent over the SCC. In this case, the sender sets the Channel Type field to SCC.
当G-ACh发送方接收到要通过MCC发送的MCC消息时，发送方创建G-ACh报头，将信道类型字段设置为MCC，填写PID以指示MCC第3层PDU类型，并用G-ACh报头在MCC消息前加上前缀。当通过SCC发送控制平面消息时，采用相同的程序。在这种情况下，发送方将信道类型字段设置为SCC。
If the G-ACh is associated with an MPLS section, the Generic Associated Channel Label (GAL) is added to the message as defined in [RFC5586]. The Time to Live (TTL) field MUST be set to 1, and the S-bit of the GAL MUST be set to 1.
如果G-ACh与MPLS部分关联，则按照[RFC5586]中的定义，将通用关联信道标签（GAL）添加到消息中。生存时间（TTL）字段必须设置为1，GAL的S位必须设置为1。
If the G-ACh is associated with an LSP, the GAL is added to the packet and the LSP label is pushed on top of the GAL as defined in [RFC5586]. The TTL field of the GAL MUST be set to 1, and the S-bit of the GAL MUST be set to 1.
如果G-ACh与LSP关联，则将GAL添加到数据包中，并按照[RFC5586]中的定义将LSP标签推到GAL的顶部。GAL的TTL字段必须设置为1，GAL的S位必须设置为1。
Note that packet processing for DCN packets in the G-ACh is, in common with all G-ACh MPLS packets, subject to the normal processing of the Traffic Class (TC) field of the MPLS header. This could be used to enable prioritization of different DCN packets.
注意，G-ACh中DCN分组的分组处理与所有G-ACh MPLS分组一样，受制于MPLS报头的业务类别（TC）字段的正常处理。这可用于实现不同DCN数据包的优先级。
The DCN channel MUST NOT be used to transport user traffic and SHALL only be used to carry management or control plane messages. Procedures that ensure this (such as deep packet inspection) are outside the scope of this specification.
DCN信道不得用于传输用户流量，只能用于传输管理或控制平面信息。确保这一点的程序（如深包检查）不在本规范的范围内。
When a receiver has received a packet on the G-ACh with the ACH Channel Type set to MCC or SCC, it SHALL look at the PID field. If the PID value is known by the receiver, it delivers the MCC/SCC message to the appropriate processing entity. If the PID value is unknown, the receiver SHALL silently discard the received packet, MAY increment a counter that records discarded or errored messages, and MAY log an event.
当接收器在G-ACh上接收到ACh信道类型设置为MCC或SCC的数据包时，应查看PID字段。如果接收器知道PID值，则会将MCC/SCC消息传递给相应的处理实体。如果PID值未知，接收器应默默丢弃接收到的数据包，可增加一个计数器，记录丢弃或出错的消息，并可记录事件。
It must be noted that according to [RFC5586], a receiver MUST NOT forward a GAL packet based on the GAL label as is normally the case for MPLS packets. If the GAL appears at the bottom of the label stack, it MUST be processed as described in the previous paragraph.
必须注意的是，根据[RFC5586]，接收机不得转发基于GAL标签的GAL数据包，这通常是MPLS数据包的情况。如果GAL出现在标签堆栈的底部，则必须按照上一段中的说明进行处理。
Note that there is no requirement for MPLS-TP devices to support IP or OSI forwarding in the fast (forwarding) path. Thus, if a message is received on the MCC or SCC and is not targeted to an address of the receiving MPLS-TP node, the packet might not be forwarded in the fast path. A node MAY apply layer 3 forwarding procedures in the slow or fast path and MAY discard or reject the message using the layer 3 protocol if it is unable to forward it. Thus, protocols making use of the DCN should make no assumptions about the forwarding capabilities unless they are determined a priori or through the use of a routing protocol. Furthermore, it is important that user data (i.e., data traffic) is not routed through the DCN, as this would potentially cause the traffic to be lost or delayed and might significantly congest the DCN.
请注意，不要求MPLS-TP设备支持快速（转发）路径中的IP或OSI转发。因此，如果消息是在MCC或SCC上接收的并且不是以接收MPLS-TP节点的地址为目标，则分组可能不会在快速路径中转发。节点可以在慢速或快速路径中应用第3层转发过程，如果无法转发，则可以使用第3层协议丢弃或拒绝消息。因此，使用DCN的协议不应该对转发能力进行任何假设，除非它们是预先确定的或通过使用路由协议来确定的。此外，重要的是，用户数据（即，数据通信量）不通过DCN路由，因为这可能会导致通信量丢失或延迟，并且可能会严重阻塞DCN。
Provider Edge nodes (PEs) may wish to set up PWs using a signaling protocol that uses remote adjacencies (such as LDP [RFC5036]). In the absence of an IP-based control plane network, these PEs MUST first set up an LSP tunnel across the MPLS-TP network. This tunnel can be used both to carry the PW once it has been set up and to provide a G-ACh-based DCN for control plane communications between the PEs.
提供商边缘节点（PE）可能希望使用使用使用远程邻接的信令协议（例如LDP[RFC5036]）来设置PW。在没有基于IP的控制平面网络的情况下，这些PE必须首先在MPLS-TP网络上建立LSP隧道。该隧道可用于在PW设置后承载PW，并为PEs之间的控制平面通信提供基于G-ACh的DCN。
The DCN is intended to provide connectivity between management stations and network nodes, and between pairs of network nodes, for the purpose of exchanging management plane and control plane messages.
DCN旨在提供管理站和网络节点之间以及网络节点对之间的连接，以便交换管理平面和控制平面消息。
Appendix A of [NM-REQ] describes how Control Channels (CCh) that are the links in an MPLS-TP DCN can be out-of-fiber and out-of-band, in-fiber and out-of-band, or in-band with respect to the user data carried by the MPLS-TP network. That appendix also explains how the DCN can be constructed from a mix of different types of links and how routing and forwarding can be used within the DCN to facilitate multi-hop delivery of management and control plane messages.
[NM-REQ]的附录A描述了作为MPLS-TP DCN中链路的控制信道（CCh）如何可以是光纤外和带外、光纤内和带外，或者相对于MPLS-TP网络承载的用户数据如何是带内。该附录还解释了如何从不同类型的链路混合构建DCN，以及如何在DCN内使用路由和转发来促进管理和控制平面消息的多跳传送。
The G-ACh used as described in this document allows the creation of a "data channel associated CCh" (type 6 in Appendix A of [NM-REQ]) and an "in-band CCh" (type 7 in Appendix A of [NM-REQ]). In the former case, the G-ACh is associated with an MPLS-TP section. In the latter case, the G-ACh is associated with an MPLS-TP LSP or PW and may span one or more hops in the MPLS-TP network.
本文件中所述的G-ACh允许创建“与CCh相关的数据通道”（NM-REQ附录a中的类型6）和“带内CCh”（NM-REQ附录a中的类型7）。在前一种情况下，G-ACh与MPLS-TP部分相关联。在后一种情况下，G-ACh与MPLS-TP LSP或PW相关联，并且可以跨越MPLS-TP网络中的一个或多个跳。
There is no need to create a CCh for every LSP between a pair of MPLS-TP nodes. Indeed, where the nodes are physically adjacent, the G-ACh associated with the MPLS-TP section would normally be used. Where nodes are virtually adjacent (that is, connected by LSP tunnels), one or two of the LSPs might be selected to provide the CCh and a back-up CCh.
不需要为一对MPLS-TP节点之间的每个LSP创建CCh。实际上，在节点物理上相邻的地方，通常会使用与MPLS-TP部分相关联的G-ACh。当节点实际上相邻（即，通过LSP隧道连接）时，可以选择一个或两个LSP来提供CCh和备用CCh。
The G-ACh provides a virtual link between MPLS-TP nodes and might be used to induce many forms of security attack. The MPLS data plane does not include any security mechanisms of its own; therefore, it is important that protocols using the DCN apply their own security. Protocols that operate over the MCN or SCN are REQUIRED to include adequate security mechanisms, and implementations MUST allow operators to configure the use of those mechanisms.
G-ACh在MPLS-TP节点之间提供虚拟链路，可用于引发多种形式的安全攻击。MPLS数据平面不包括其自身的任何安全机制；因此，使用DCN的协议应用其自身的安全性是很重要的。在MCN或SCN上运行的协议需要包括足够的安全机制，实现必须允许操作员配置这些机制的使用。
Channel Types for the Generic Associated Channel are allocated from the IANA PW Associated Channel Type registry defined in [RFC4446] and updated by [RFC5586].
通用关联信道的信道类型从[RFC4446]中定义的IANA PW关联信道类型注册表中分配，并由[RFC5586]更新。
IANA has allocated two further Channel Types as follows: 0x0001 Management Communication Channel (MCC) 0x0002 Signaling Communication Channel (SCC)
IANA还分配了以下两种信道类型：0x0001管理通信信道（MCC）0x0002信令通信信道（SCC）
[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月。
[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月。
[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月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月。
[G.7712] ITU-T Recommendation G.7712, "Architecture and specification of data communication network", June 2008.
[G.7712]ITU-T建议G.7712，“数据通信网络的体系结构和规范”，2008年6月。
[MPLS-TP] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "A Framework for MPLS in Transport Networks", Work in Progress, October 2009.
[MPLS-TP]Bocci，M.，Bryant，S.，Frost，D.，和L.Levrau，“传输网络中MPLS的框架”，正在进行的工作，2009年10月。
[NM-REQ] Lam, K. and S. Mansfield, "MPLS TP Network Management Requirements", Work in Progress, October 2009.
[NM-REQ]Lam，K.和S.Mansfield，“MPLS TP网络管理要求”，正在进行的工作，2009年10月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point Protocol (PPP)", BCP 88, RFC 3818, June 2004.
[RFC3818]Schryver，V.，“点到点协议（PPP）的IANA考虑因素”，BCP 88，RFC 3818，2004年6月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
The editors wish to thank Pietro Grandi, Martin Vigoureux, Kam Lam, Ben Niven-Jenkins, Francesco Fondelli, Walter Rothkegel, Shahram Davari, Liu Guoman, and Alexander Vainshtein for their contribution to this document, and the MEAD team for thorough review.
编辑们要感谢彼得罗·格兰迪、马丁·维古鲁、金林、本·尼文·詹金斯、弗朗西斯科·丰德利、沃尔特·罗斯基格尔、沙拉姆·达瓦里、刘国曼和亚历山大·范斯坦对本文件的贡献，并感谢米德团队的全面审查。
Study Group 15 of the ITU-T provided the basis for the requirements text in Section 1.1.
ITU-T第15研究组为第1.1节中的要求文本提供了基础。
Authors' Addresses
作者地址
Dieter Beller Alcatel-Lucent Germany EMail: dieter.beller@alcatel-lucent.com
Dieter Beller阿尔卡特朗讯德国电子邮件：Dieter。beller@alcatel-朗讯网
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk