Internet Engineering Task Force (IETF) D. Frost
Request for Comments: 7213 Blue Sun
Category: Standards Track S. Bryant
ISSN: 2070-1721 Cisco Systems
M. Bocci
Alcatel-Lucent
June 2014
Internet Engineering Task Force (IETF) D. Frost
Request for Comments: 7213 Blue Sun
Category: Standards Track S. Bryant
ISSN: 2070-1721 Cisco Systems
M. Bocci
Alcatel-Lucent
June 2014
MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing
MPLS传输配置文件（MPLS-TP）下一跳以太网寻址
Abstract
摘要
The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets.
MPLS传输配置文件（MPLS-TP）是一组适用于分组交换传输网络的构建和运行的MPLS协议功能。本文档介绍了承载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/rfc7213.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7213.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 MPLS Transport Profile (MPLS-TP) [RFC5921] is the set of protocol functions that meet the requirements [RFC5654] for the application of MPLS to the construction and operation of packet-switched transport networks. The MPLS-TP data plane consists of those MPLS-TP functions concerned with the encapsulation and forwarding of MPLS-TP packets and is described in [RFC5960].
MPLS传输配置文件（MPLS-TP）[RFC5921]是一组协议功能，满足将MPLS应用于分组交换传输网络的构建和运行的要求[RFC5654]。MPLS-TP数据平面由与MPLS-TP数据包的封装和转发有关的MPLS-TP功能组成，并在[RFC5960]中进行了描述。
This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. Since MPLS-TP packets are MPLS packets, existing procedures ([RFC3032], [RFC5332]) for the encapsulation of MPLS packets over Ethernet apply. Because IP functionality is optional in an MPLS-TP network, IP-based protocols for Media Access Control (MAC) address learning, such as the Address Resolution Protocol (ARP) [RFC826] and IPv6 Neighbor Discovery [RFC4861], may not be available. This document specifies the options for the determination and selection of the next-hop Ethernet MAC address when MPLS-TP is used between nodes that do not have an IP data plane.
本文档介绍了承载MPLS-TP数据包的以太网帧的链路层寻址注意事项。由于MPLS-TP数据包是MPLS数据包，因此适用于通过以太网封装MPLS数据包的现有程序（[RFC3032]、[RFC5332]）。由于IP功能在MPLS-TP网络中是可选的，因此基于IP的媒体访问控制（MAC）地址学习协议（如地址解析协议（ARP）[RFC826]和IPv6邻居发现[RFC4861]）可能不可用。本文档规定了在没有IP数据平面的节点之间使用MPLS-TP时，用于确定和选择下一跳以太网MAC地址的选项。
Term Definition
------- ---------------------------
ARP Address Resolution Protocol
G-ACh Generic Associated Channel
LSP Label Switched Path
LSR Label Switching Router
MAC Media Access Control
MPLS-TP MPLS Transport Profile
Term Definition
------- ---------------------------
ARP Address Resolution Protocol
G-ACh Generic Associated Channel
LSP Label Switched Path
LSR Label Switching Router
MAC Media Access Control
MPLS-TP MPLS Transport Profile
Additional definitions and terminology can be found in [RFC5960] and [RFC5654].
其他定义和术语可在[RFC5960]和[RFC5654]中找到。
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]中所述进行解释。
When two MPLS-TP nodes are connected by a point-to-point Ethernet link, the question arises as to what destination Ethernet Media Access Control (MAC) address should be specified in Ethernet frames transmitted to the peer node over the link. The problem of determining this address does not arise in IP/MPLS networks because
当两个MPLS-TP节点通过点对点以太网链路连接时，会出现一个问题，即在通过链路传输到对等节点的以太网帧中应指定哪个目标以太网媒体访问控制（MAC）地址。在IP/MPLS网络中不会出现确定此地址的问题，因为
of the presence of the Ethernet Address Resolution Protocol (commonly referred to as the Address Resolution Protocol and shortened to ARP) [RFC826] or IPv6 Neighbor Discovery (ND) protocol [RFC4861], which allow the unicast MAC address of the peer device to be learned dynamically.
以太网地址解析协议（通常称为地址解析协议，简称为ARP）[RFC826]或IPv6邻居发现（ND）协议[RFC4861]的存在，允许动态学习对等设备的单播MAC地址。
If existing mechanisms are available in an MPLS-TP network to determine the destination unicast MAC addresses of peer nodes, for example, if the network also happens to be an IP/MPLS network, or if the Link Layer Discovery Protocol (LLDP) [LLDP] is in use, these methods SHOULD be used. If ARP, ND, and LLDP are not available, and both peers implement the procedures in Section 4 of this document, then the GAP mechanism described in this memo SHOULD be used. The remainder of this section discusses alternative options that might be employed when none of the preceding mechanisms for learning MAC addresses are available.
如果MPLS-TP网络中存在确定对等节点的目标单播MAC地址的现有机制，例如，如果网络恰好也是IP/MPLS网络，或者如果正在使用链路层发现协议（LLDP）[LLDP]，则应使用这些方法。如果ARP、ND和LLDP不可用，且两个对等方均实施本文件第4节中的程序，则应使用本备忘录中描述的差距机制。本节的其余部分将讨论在上述学习MAC地址的机制均不可用时可能采用的替代选项。
One common approach is for each node to be statically configured with the MAC address of its peer. However, static MAC address configuration can present an administrative burden and lead to operational problems. For example, replacement of an Ethernet interface to resolve a hardware fault when this approach is used requires that the peer node be manually reconfigured with the new MAC address. This is especially problematic if the peer is operated by another provider.
一种常见的方法是使用对等节点的MAC地址静态配置每个节点。但是，静态MAC地址配置可能会带来管理负担，并导致操作问题。例如，当使用此方法时，替换以太网接口以解决硬件故障需要使用新MAC地址手动重新配置对等节点。如果对等方由另一个提供商操作，则问题尤其严重。
Another approach that may be considered is to use the Ethernet broadcast address FF-FF-FF-FF-FF-FF as the destination MAC address in frames carrying MPLS-TP packets over a link that is known to be point-to-point. This may, however, lead to excessive frame distribution and processing at the Ethernet layer. Broadcast traffic may also be treated specially by some devices, and this may not be desirable for MPLS-TP data frames.
可以考虑的另一种方法是在通过已知为点到点的链路承载MPLS-TP分组的帧中使用以太网广播地址FF-FF-FF-FF-FF-FF作为目的MAC地址。然而，这可能导致以太网层的帧分布和处理过多。广播业务还可以由一些设备进行特殊处理，这对于MPLS-TP数据帧来说可能是不可取的。
In view of the above considerations, this document recommends that, if a non-negotiated address is to be used, both nodes are configured to use as a destination MAC address an Ethernet multicast address reserved for MPLS-TP for use over point-to-point links. The address allocated for this purpose by the Internet Assigned Numbers Authority (IANA) is 01-00-5E-90-00-00. An MPLS-TP implementation MUST default to passing to the MPLS sub-system any MPLS packets received from a point-to-point Ethernet link with this destination MAC address.
鉴于上述考虑，本文件建议，如果要使用非协商地址，则两个节点都被配置为使用为MPLS-TP保留的以太网多播地址作为目标MAC地址，以便在点到点链路上使用。互联网分配号码管理局（IANA）为此目的分配的地址为01-00-5E-90-00-00。MPLS-TP实现必须默认将从具有此目标MAC地址的点到点以太网链路接收的任何MPLS数据包传递给MPLS子系统。
The use of broadcast or multicast addressing for the purpose described in this section, i.e., as a placeholder for the unknown unicast MAC address of the destination, is applicable only when the attached Ethernet link is known to be point-to-point. If a link is not known to be point-to-point, these forms of broadcast or multicast
仅当所连接的以太网链路已知为点对点时，才可将广播或多播寻址用于本节所述目的，即作为目的地未知单播MAC地址的占位符。如果不知道链路是点对点的，则这些形式的广播或多播
addressing MUST NOT be used. Thus, the implementation MUST provide a means for the operator to declare that a link is point-to-point if it supports these addressing modes. Moreover, the operator is cautioned that it is not always clear whether a given link is, or will remain, strictly point-to-point, particularly when the link is supplied by an external provider; point-to-point declarations therefore need to be used with care. Because of these caveats, it is RECOMMENDED that implementations support the procedures in Section 4 so that unicast addressing can be used.
不得使用寻址。因此，如果链路支持这些寻址模式，则实现必须为操作员提供一种方法来声明链路是点对点的。此外，运营商应注意，并不总是清楚给定链路是否是或将保持严格的点对点，特别是当链路由外部提供商提供时；因此，需要谨慎使用点对点声明。由于这些注意事项，建议实现支持第4节中的过程，以便可以使用单播寻址。
When a multipoint Ethernet link serves as a section [RFC5960] for a point-to-multipoint MPLS-TP LSP, and multicast destination MAC addressing at the Ethernet layer is used for the LSP, the addressing and encapsulation procedures specified in [RFC5332] SHALL be used.
当多点以太网链路用作点对多点MPLS-TP LSP的[RFC5960]部分，且LSP使用以太网层的多播目的地MAC寻址时，应使用[RFC5332]中规定的寻址和封装程序。
When a multipoint Ethernet link (that is, a link that is not known to be point-to-point) serves as a section for a point-to-point MPLS-TP LSP, unicast destination MAC addresses MUST be used for Ethernet frames carrying packets of the LSP. According to the discussion in the previous section, this implies the use of either static MAC address configuration or a protocol that enables peer MAC address discovery.
当多点以太网链路（即，不知道是点到点的链路）用作点到点MPLS-TP LSP的部分时，单播目的地MAC地址必须用于承载LSP的分组的以太网帧。根据上一节中的讨论，这意味着使用静态MAC地址配置或启用对等MAC地址发现的协议。
The G-ACh Advertisement Protocol (GAP) [RFC7212] provides a simple means of informing listeners on a link of the sender's capabilities and configuration. When used for this purpose on an Ethernet link, GAP messages are multicast to the address 01-00-5e-80-00-0d (see Section 7 of [RFC7212]). If these messages contain the unicast MAC address of the sender, then listeners can learn this address and use it in the future when transmitting frames containing MPLS-TP packets. Since the GAP does not rely on IP, this provides a means of unicast MAC discovery for MPLS-TP nodes without IP support.
G-ACh播发协议（GAP）[RFC7212]提供了一种简单的方法，将发送方的能力和配置通知链路上的侦听器。当在以太网链路上用于此目的时，GAP消息多播到地址01-00-5e-80-00-0d（见[RFC7212]第7节）。如果这些消息包含发送方的单播MAC地址，则侦听器可以了解该地址，并在将来传输包含MPLS-TP数据包的帧时使用该地址。由于GAP不依赖于IP，这为不支持IP的MPLS-TP节点提供了一种单播MAC发现方法。
This document defines a new GAP application "Ethernet Interface Parameters" (0x0001) to support the advertisement of Ethernet-specific parameters associated with the sending interface. The following Type-Length-Value (TLV) objects are defined for this application; the TLV format is as defined in [RFC7212]:
本文档定义了一个新的GAP应用程序“Ethernet Interface Parameters”（0x0001），以支持公布与发送接口相关联的特定于以太网的参数。为此应用程序定义了以下类型长度值（TLV）对象：；TLV格式如[RFC7212]中所定义：
Source MAC Address (type = 0, length = 8): The Value of this object is an EUI-64 [EUI-64] unicast MAC address assigned to one of the interfaces of the sender that is connected to this data link. The IEEE-defined mapping from 48-bit MAC addresses to EUI-64 form is used.
源MAC地址（类型=0，长度=8）：此对象的值是分配给连接到此数据链路的发送方的一个接口的EUI-64[EUI-64]单播MAC地址。使用IEEE定义的从48位MAC地址到EUI-64格式的映射。
Maximum Frame Size (MFS) (type = 1, length = 4): The Value of this object is a 32-bit unsigned integer encoded in network byte order that specifies the maximum frame size in octets of an Ethernet Frame that can be sent over the sending interface. Where MAC address learning occurs by some other means, this TLV group MAY be used to advertise only the MFS. If multiple advertisements are made for the same parameter, use of these advertisements is undefined.
最大帧大小（MFS）（类型=1，长度=4）：此对象的值是一个以网络字节顺序编码的32位无符号整数，用于指定可通过发送接口发送的以太网帧的最大帧大小（以八位字节为单位）。在通过某些其他方式进行MAC地址学习的情况下，该TLV组可仅用于通告MFS。如果为同一参数制作了多个播发，则这些播发的使用未定义。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Reserved | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address in EUI-64 Format |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Reserved | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address in EUI-64 Format |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source MAC Address Object Format
源MAC地址对象格式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Reserved | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Frame Size (MFS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Reserved | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Frame Size (MFS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MFS Object Format
MFS对象格式
Per [RFC7212], MAC address discovery information needs to be periodically retransmitted and is to be retained by a receiver based on the period of time indicated by the associated Lifetime field. To expedite the initialization of a link, it is RECOMMENDED that a node that has been reconfigured, rebooted, or is aware that it has been disconnected from its peer send a GAP Ethernet Interface Parameters message, and that it issue a GAP Request message for the Ethernet Interface Parameters of its peers, at the earliest opportunity.
根据[RFC7212]，MAC地址发现信息需要周期性地重新传输，并由接收机根据相关生存期字段指示的时间段保留。为了加快链路的初始化，建议已重新配置、重新启动或知道已与其对等方断开连接的节点尽早发送GAP Ethernet Interface Parameters消息，并为其对等方的Ethernet Interface Parameters发出GAP Request消息。
When the MAC address in the received Source MAC Address TLV changes, the new MAC address MUST be used (see Section 5.2 of [RFC7212]).
当接收到的源MAC地址TLV中的MAC地址发生变化时，必须使用新的MAC地址（见[RFC7212]第5.2节）。
If a minimum MFS is configured for a link and the MFS advertised by the peer is lower than that minimum, the operator MUST be notified of the MFS mismatch. Under these circumstances, the operator may choose to configure the LSR to shut down the link, thereby triggering a
如果为链路配置了最小MFS，并且对等方公布的MFS低于该最小值，则必须将MFS不匹配通知操作员。在这些情况下，操作员可选择配置LSR以关闭链路，从而触发故障
fault and causing the end-to-end path to be repaired. Alternatively, the operator may choose to configure the LSR to leave the link up so that an OAM message can be used to verify the actual MFS.
故障并导致端到端路径被修复。或者，操作员可以选择配置LSR以保持链路接通，以便可以使用OAM消息来验证实际MFS。
A peer node could cease transmission of G-ACh advertisements, or cease to include a Source MAC Address TLV in advertisements, or cease to be connected, any of which will cause the TLV lifetime to expire. After the Source MAC Address TLV lifetime has expired, this MAC Address MUST NOT be used as the peer MAC address. The node MUST return to selecting MAC addresses as though no advertisements were received, using the method configured for this eventuality.
对等节点可以停止G-ACh播发的传输，或者停止在播发中包括源MAC地址TLV，或者停止连接，任何这些都将导致TLV生存期到期。源MAC地址TLV生存期到期后，此MAC地址不得用作对等MAC地址。节点必须使用为此事件配置的方法返回选择MAC地址，就像没有收到广告一样。
The values sent and received by this protocol MUST be made accessible for inspection by network operators, and where local configuration is updated by received information, it MUST be clear why the configured value has been changed. If the received values change, the new values MUST be used and the change made visible to the network operators.
此协议发送和接收的值必须可供网络运营商检查，如果本地配置由接收到的信息更新，则必须清楚配置值更改的原因。如果收到的值发生变化，则必须使用新值，并使网络运营商能够看到这些变化。
The Ethernet address and associated parameters advertised for an interface SHOULD be persistent across restarts. In the event of a system restart, any data that has been retained as a consequence of prior Ethernet Interface Parameters advertisements from GAP peers MUST be discarded; this prevents incorrect operation on the basis of stale data.
为接口播发的以太网地址和相关参数应在重启期间保持不变。在系统重新启动的情况下，必须丢弃由于来自GAP对等方的先前以太网接口参数广告而保留的任何数据；这可以防止基于过时数据的错误操作。
Where the link changes to a new type, i.e., from point-to-point to point-to-multipoint, the network operator SHOULD be informed. If the new link type is incompatible with the Ethernet addressing method in use, the system MUST take the action that is configured under those circumstances.
如果链路更改为新类型，即从点对点到点对多点，则应通知网络运营商。如果新链路类型与正在使用的以太网寻址方法不兼容，则系统必须采取在这些情况下配置的操作。
The use of broadcast or multicast Ethernet destination MAC addresses for frames carrying MPLS-TP data packets can potentially result in such frames being distributed to devices other than the intended destination node or nodes when the Ethernet link is not point-to-point. The operator should take care to ensure that MPLS-TP nodes are aware of the Ethernet link type (point-to-point or multipoint). In the case of multipoint links, the operator should either ensure that no devices are attached to the link that are not authorized to receive the frames or take steps to mitigate the possibility of excessive frame distribution (for example, by configuring the Ethernet switch to appropriately restrict the delivery of multicast frames to authorized ports).
当以太网链路不是点对点时，对承载MPLS-TP数据分组的帧使用广播或多播以太网目的地MAC地址可能导致将此类帧分发到预期目的地节点以外的设备。操作员应注意确保MPLS-TP节点知道以太网链路类型（点对点或多点）。在多点链路的情况下，操作员应确保没有未经授权接收帧的设备连接到链路，或采取措施减轻过度帧分布的可能性（例如，通过配置以太网交换机来适当限制多播帧向授权端口的传送）。
An attacker could disrupt communications by modifying the Source MAC Address or the MFS values; however, this is mitigated by the use of cryptographic authentication as described in [RFC7212], which also describes other considerations applicable to the GAP protocol. Visibility into the contents of either of the TLVs could provide information that is useful for an attacker. This is best addressed by physical security of the links.
攻击者可以通过修改源MAC地址或MFS值来中断通信；然而，如[RFC7212]中所述，这通过使用加密身份验证得以缓解，其中还描述了适用于GAP协议的其他注意事项。对任一TLV内容的可见性都可以为攻击者提供有用的信息。这最好通过链接的物理安全性来解决。
IANA has allocated an Ethernet multicast address from the "IANA Multicast 48-bit MAC Addresses" address block in the "Ethernet Numbers" registry for use by MPLS-TP LSRs over point-to-point links as described in Section 2. The allocated address is 01-00-5E-90-00-00. IANA has updated the reference to point to the RFC number assigned to this document.
IANA已从“Ethernet Number”注册表中的“IANA multicast 48位MAC Addresses”地址块中分配了一个以太网多播地址，供MPLS-TP LSR在点到点链路上使用，如第2节所述。分配的地址是01-00-5E-90-00-00。IANA已更新参考，以指向分配给本文件的RFC编号。
IANA has allocated a new Application ID in the "G-ACh Advertisement Protocol Application Registry", as follows:
IANA已在“G-ACh广告协议应用程序注册表”中分配了一个新的应用程序ID，如下所示：
Application ID Description Reference
-------------- ----------------------------- ---------
0x0001 Ethernet Interface Parameters This RFC
Application ID Description Reference
-------------- ----------------------------- ---------
0x0001 Ethernet Interface Parameters This RFC
IANA has created a new registry, "G-ACh Advertisement Protocol: Ethernet Interface Parameters" within the "Generic Associated Channel (G-ACh) Parameters" registry with fields and initial allocations as follows:
IANA在“通用关联通道（G-ACh）参数”注册表中创建了一个新的注册表“G-ACh广告协议：以太网接口参数”，其字段和初始分配如下：
Type Name Type ID Reference
------------------ ------- ---------
Source MAC Address 0 This RFC
Maximum Frame Size 1 This RFC
Type Name Type ID Reference
------------------ ------- ---------
Source MAC Address 0 This RFC
Maximum Frame Size 1 This RFC
The range of the Type ID field is 0 - 255.
类型ID字段的范围为0-255。
The allocation policy for this registry is IETF Review or IESG Approval.
此注册表的分配策略为IETF审查或IESG批准。
We thank Adrian Farrel for his valuable review comments on this document.
我们感谢阿德里安·法雷尔对本文件的宝贵评论。
[EUI-64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", March 1997, <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>.
[EUI-64]IEEE，“64位全局标识符（EUI-64）注册机构指南”，1997年3月<http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>。
[LLDP] IEEE, "Station and Media Access Control Connectivity Discovery", IEEE 802.1AB, September 2009.
[LLDP]IEEE，“站点和媒体访问控制连接发现”，IEEE 802.1AB，2009年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332]Eckert，T.，Rosen，E.，Aggarwal，R.，和Y.Rekhter，“MPLS多播封装”，RFC 5332，2008年8月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Brungard，D.，Betts，M.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC5960]Frost，D.，Bryant，S.，和M.Bocci，“MPLS传输配置文件数据平面架构”，RFC 59602010年8月。
[RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic Associated Channel (G-ACh) Advertisement Protocol", RFC 7212, June 2014.
[RFC7212]Frost，D.，Bryant，S.，和M.Bocci，“MPLS通用关联信道（G-ACh）广告协议”，RFC 72122014年6月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]Bocci，M.，Bryant，S.，Frost，D.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
Authors' Addresses
作者地址
Dan Frost Blue Sun
丹弗罗斯特蓝色太阳
EMail: frost@mm.st
EMail: frost@mm.st
Stewart Bryant Cisco Systems
思科系统公司
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Matthew Bocci Alcatel-Lucent
马修·博奇·阿尔卡特·朗讯
EMail: matthew.bocci@alcatel-lucent.com
EMail: matthew.bocci@alcatel-lucent.com