Network Working Group T. Eckert
Request for Comments: 5332 E. Rosen, Ed.
Category: Standards Track Cisco Systems, Inc.
Updates: 3032, 4023 R. Aggarwal
Y. Rekhter
Juniper Networks, Inc.
August 2008
Network Working Group T. Eckert
Request for Comments: 5332 E. Rosen, Ed.
Category: Standards Track Cisco Systems, Inc.
Updates: 3032, 4023 R. Aggarwal
Y. Rekhter
Juniper Networks, Inc.
August 2008
MPLS Multicast Encapsulations
多播封装
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the "multicast codepoint") is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label".
RFC 3032为MPLS建立了两个数据链路层码点，用于区分数据链路层帧是否承载MPLS单播或MPLS多播分组。但是，从未部署过这种用法。本规范通过重新定义这两个代码点的含义来更新RFC 3032。这两个代码点现在都可以用来承载多播数据包。第二个代码点（以前称为“多播代码点”）现在仅在多址介质上使用，这意味着“以下标签堆栈的顶部标签是上游分配的标签”。
RFC 3032 does not specify the destination address to be placed in the "MAC DA" (Medium Access Layer Destination Address) field of an ethernet frame that carries an MPLS multicast packet. This document provides that specification.
RFC 3032没有指定要放置在承载MPLS多播分组的以太网帧的“MAC DA”（介质访问层目的地地址）字段中的目的地地址。本文件提供了该规范。
This document updates RFC 3032 and RFC 4023.
本文档更新了RFC 3032和RFC 4023。
Table of Contents
目录
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Upstream-Assigned vs. Downstream-Assigned .......................3
4. Ethernet Codepoints .............................................6
5. PPP Protocol Field ..............................................6
6. GRE Protocol Type ...............................................6
7. IP Protocol Number ..............................................7
8. Ethernet MAC DA for Multicast MPLS ..............................7
9. IANA Considerations .............................................8
10. Security Considerations ........................................8
11. Normative References ...........................................9
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Upstream-Assigned vs. Downstream-Assigned .......................3
4. Ethernet Codepoints .............................................6
5. PPP Protocol Field ..............................................6
6. GRE Protocol Type ...............................................6
7. IP Protocol Number ..............................................7
8. Ethernet MAC DA for Multicast MPLS ..............................7
9. IANA Considerations .............................................8
10. Security Considerations ........................................8
11. Normative References ...........................................9
RFC 3031 [RFC3031] defines the "Next Hop Label Forwarding Entry" (NHLFE). The NHLFE for a particular label maps the label into a next hop (among other things). When an MPLS packet is received, its top label is mapped to an NHLFE, and the packet is sent to the next hop specified by the NHLFE.
RFC 3031[RFC3031]定义了“下一跳标签转发条目”（NHLFE）。特定标签的NHLFE将标签映射到下一跳（以及其他内容）。当接收到MPLS数据包时，其顶部标签被映射到NHLFE，并且该数据包被发送到NHLFE指定的下一跳。
We define a particular MPLS label to be a "multicast label" in a particular context if the NHLFE to which it is mapped, in that context, specifies a set of next hops, with the semantics that the packet is to be replicated and a copy of the packet sent to each of the specified next hops. Note that this definition accommodates the case where the set of next hops contains a single member. What makes a label a multicast label in a particular context is the semantics attached to the set, i.e., the intention to replicate the packet and transmit to all members of the set if the set has more than one member.
我们将特定MPLS标签定义为特定上下文中的“多播标签”，如果该标签在该上下文中映射到的NHLFE指定了一组下一个跃点，其语义是要复制该数据包，并将该数据包的副本发送到每个指定的下一个跃点。请注意，此定义适用于下一跳集包含单个成员的情况。使标签在特定上下文中成为多播标签的是附加到集合的语义，即，如果集合有多个成员，则复制数据包并传输到集合的所有成员的意图。
RFC 3032 [RFC3032] established two data link layer codepoints for MPLS: one to indicate that the data link layer frame is carrying an MPLS unicast packet, and the other to indicate that the data link layer frame is carrying an MPLS multicast packet. The term "multicast packet" is not precisely defined in RFC 3032, though one may presume that the "multicast" codepoint is intended to identify the packet's top label as a multicast label. However, the multicast codepoint has never been deployed, and further development of the procedures for MPLS multicast have shown that, while there is a need for two codepoints, the use of the two codepoints is not properly captured by RFC 3032.
RFC 3032[RFC3032]为MPLS建立了两个数据链路层代码点：一个用于指示数据链路层帧正在承载MPLS单播分组，另一个用于指示数据链路层帧正在承载MPLS多播分组。术语“多播分组”未在RFC 3032中精确定义，尽管可以假定“多播”码点旨在将分组的顶部标签标识为多播标签。然而，多播码点从未被部署，并且MPLS多播过程的进一步发展已经表明，虽然需要两个码点，但RFC 3032没有正确捕获这两个码点的使用。
In particular, there is no need for the codepoint to indicate whether the top MPLS label is a multicast label. When the receiver of an MPLS packet looks up the top label, the NHLFE will specify whether or not the label is a multicast label.
特别地，不需要代码点来指示顶部MPLS标签是否是多播标签。当MPLS数据包的接收器查找顶部标签时，NHLFE将指定该标签是否为多播标签。
This document updates RFC 3032 and RFC 4023 by re-specifying the use of the codepoints. The old use of the "multicast codepoint", as specified in those two RFCs, is hereby deprecated.
本文档通过重新指定代码点的使用来更新RFC 3032和RFC 4023。在这两个RFC中指定的“多播代码点”的旧用法在此被弃用。
Note that an implementation that does MPLS multicast according to RFC 3032 and/or 4023 will be unable to interoperate with implementations that do MPLS multicast according to this document. There may be some deployed platforms that support the deprecated use of the codepoints, but those platforms do not support the control plane mechanisms to support MPLS multicast. The absence of the control plane will prevent a system that implements the deprecated use of codepoints from attempting to interoperate with a system that uses the codepoints as specified herein. (If an MPLS multicast control plane were to be implemented on a platform that only supports the deprecated codepoint, interoperability problems such as black holes and/or misrouting would arise. This does not seem like a potential problem in practice.)
请注意，根据RFC 3032和/或4023进行MPLS多播的实现将无法与根据本文档进行MPLS多播的实现进行互操作。可能有一些已部署的平台支持不推荐使用的代码点，但这些平台不支持支持MPLS多播的控制平面机制。缺少控制平面将阻止实现不推荐使用的代码点的系统尝试与使用此处指定的代码点的系统进行互操作。（如果MPLS多播控制平面要在只支持不推荐使用的代码点的平台上实施，则会出现互操作性问题，如黑洞和/或错误路由。这在实践中似乎不是一个潜在问题。）
While RFC 3032 allows an MPLS packet to be carried in an ethernet multicast frame, it fails to specify how the Medium Access Layer Destination Address (MAC DA) field is to be set in that case. This document provides that specification.
尽管RFC 3032允许在以太网多播帧中携带MPLS分组，但它无法指定在这种情况下如何设置媒体接入层目的地地址（MAC DA）字段。本文件提供了该规范。
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]中所述进行解释。
Suppose a labeled packet P is sent from Label Switching Router (LSR) R1 to LSR R2, where R1 puts label L on the packet's label stack, and R2 has to look up label L in order to determine the corresponding Forwarding Equivalence Class (FEC), call it F.
假设从标签交换路由器（LSR）R1向LSR R2发送带标签的数据包P，其中R1将标签L放在数据包的标签堆栈上，R2必须查找标签L以确定相应的转发等价类（FEC），将其称为F。
If the binding between L and F was made by R2 and advertised to R1, then the label binding is known as "downstream-assigned". RFC 3031 only discusses downstream-assigned label bindings.
如果L和F之间的绑定是由R2进行的，并公布给R1，则标签绑定称为“下游指定”。RFC 3031仅讨论下游分配的标签绑定。
If the binding between L and F was made by R1 and advertised to R2, then the label binding is known as "upstream-assigned".
如果L和F之间的绑定由R1进行，并通告给R2，则标签绑定称为“上游指定”。
If the binding between L and F was made by a third party, say R3, and then advertised to both R1 and R2, we also refer to the label binding as "upstream-assigned".
如果L和F之间的绑定是由第三方（如R3）进行的，然后向R1和R2公布，我们也将标签绑定称为“上游分配”。
Upstream-assigned labels are not required to come from the same "label space" as downstream-assigned labels. See Section 3.14 of [RFC3031] and especially [RFC5331] for a discussion of the notion of "label space". The procedures for properly interpreting an upstream-assigned label are given in [RFC5331].
上游指定的标签不需要与下游指定的标签来自同一“标签空间”。有关“标签空间”概念的讨论，请参见[RFC3031]第3.14节，尤其是[RFC5331]。[RFC5331]中给出了正确解释上游指定标签的程序。
If Ru and Rd are LSP adjacencies, then they transmit an MPLS packet to each other through one of the following mechanisms:
如果Ru和Rd是LSP邻接，则它们通过以下机制之一相互传输MPLS数据包：
1. by putting the MPLS packet in a data link layer frame and transmitting the frame,
1. 通过将MPLS分组置于数据链路层帧中并发送该帧，
2. by transmitting the MPLS packet through an MPLS tunnel, i.e., by pushing an additional label (or labels) onto the label stack, and then invoking mechanism 1, or
2. 通过MPLS隧道传输MPLS数据包，即，将附加标签推到标签堆栈上，然后调用机制1，或
3. by transmitting the MPLS packet through an IP-based tunnel (e.g., via RFC 4023 [RFC4023]), and then invoking mechanisms 1 and/or 2.
3. 通过基于IP的隧道（例如，经由RFC4023[RFC4023]）传输MPLS分组，然后调用机制1和/或2。
In short, an MPLS packet is transmitted through a data link, through an MPLS tunnel, or through an IP tunnel. In any of those cases, when the packet emerges through the tunnel, the downstream LSR must know whether the label that now appears at the top of the label stack has an upstream-assigned label binding or a downstream-assigned label binding. For convenience, we will speak of a label with an upstream-assigned label binding as an "upstream-assigned label".
简言之，MPLS分组通过数据链路、MPLS隧道或IP隧道传输。在这些情况中的任何一种情况下，当数据包通过隧道出现时，下游LSR必须知道现在出现在标签堆栈顶部的标签是具有上游分配的标签绑定还是具有下游分配的标签绑定。为了方便起见，我们将上游指定标签绑定的标签称为“上游指定标签”。
Under certain conditions, specified below, multicast labels MAY be upstream-assigned. The ability to use upstream-assigned labels is an OPTIONAL feature. Upstream-assigned labels MUST NOT be used unless it is known that the downstream LSR supports them. How this is known is outside the scope of this document.
在下面指定的某些条件下，可以向上游分配多播标签。使用上游指定标签的功能是可选功能。除非知道下游LSR支持上游指定标签，否则不得使用上游指定标签。如何知道这一点超出了本文件的范围。
This document makes no changes to the procedures regarding unicast labels.
本文档不更改有关单播标签的程序。
We discuss three different types of data link or tunnel:
我们讨论三种不同类型的数据链路或隧道：
- Point-to-Point. A point-to-point data link or tunnel associates two systems, such that transmissions on that link or tunnel made by one are received by the other, and only by the other.
- 点对点。点对点数据链路或隧道将两个系统关联起来，使得一个系统在该链路或隧道上进行的传输由另一个系统接收，并且仅由另一个系统接收。
For a given direction of a given point-to-point data link or tunnel, the following MUST be the case: either every MPLS packet will carry an upstream-assigned label, or else every MPLS packet will carry a downstream-assigned label. The procedures for determining whether upstream-assigned or downstream-assigned labels are being used are outside the scope of this specification. However, in the absence of any other information, the use of downstream-assigned labels MUST be presumed by default.
对于给定点到点数据链路或隧道的给定方向，必须满足以下条件：每个MPLS数据包将携带上游分配的标签，或者每个MPLS数据包将携带下游分配的标签。确定是否使用上游指定标签或下游指定标签的程序不在本规范范围内。但是，在没有任何其他信息的情况下，默认情况下必须假定使用下游指定的标签。
- Point-to-Multipoint. A point-to-multipoint link or tunnel associates n systems, such that only one of them can transmit onto the link or tunnel, and the transmissions may be received by the other n-1 systems.
- 点对多点。点对多点链路或隧道与n个系统相关联，使得其中只有一个可以传输到链路或隧道上，并且传输可以由其他n-1系统接收。
The top labels (before applying the data link or tunnel encapsulation) of all MPLS packets that are transmitted on a particular point-to-multipoint data link or tunnel MUST be of the same type; either all upstream-assigned or all downstream-assigned. This means that all the receivers on the MPLS or IP tunnel must know a priori whether upstream-assigned or downstream-assigned labels are being used in the tunnel. How this is known is outside the scope of this document.
在特定点对多点数据链路或隧道上传输的所有MPLS数据包的顶部标签（在应用数据链路或隧道封装之前）必须为相同类型；所有上游分配或所有下游分配。这意味着MPLS或IP隧道上的所有接收器必须事先知道隧道中使用的是上游分配的标签还是下游分配的标签。如何知道这一点超出了本文件的范围。
- Multipoint-to-Multipoint. A multipoint-to-multipoint link or tunnel associates n systems, such that any of them can transmit on the link or tunnel, and the transmissions may be received by the other n-1 systems.
- 多点对多点。多点对多点链路或隧道与n个系统关联，使得它们中的任何一个都可以在链路或隧道上传输，并且传输可以由其他n-1系统接收。
If MPLS packets are transmitted on a particular multipoint-to-multipoint link or tunnel, one of the following scenarios applies:
如果在特定的多点到多点链路或隧道上传输MPLS数据包，则适用以下情形之一：
1. It is known (by methods outside the scope of this document) that the top label of every MPLS packet on the link or tunnel is downstream-assigned.
1. 已知（通过本文档范围之外的方法）链路或隧道上每个MPLS数据包的顶部标签都是下游分配的。
2. It is known (by methods outside the scope of this document) that the top label of every MPLS packet on the link or tunnel is upstream-assigned.
2. 已知（通过本文档范围之外的方法）链路或隧道上每个MPLS数据包的顶部标签都是上游分配的。
3. Some MPLS packets on the link may have upstream-assigned top labels while some may have downstream-assigned top labels.
3. 链路上的一些MPLS数据包可能具有上游分配的顶部标签，而一些可能具有下游分配的顶部标签。
If (and only if) the third scenario applies, the data link or tunnel encapsulation MUST provide a codepoint that specifies whether the top label of the encapsulated MPLS packet is upstream-assigned or downstream-assigned. If a particular type of data link or tunnel does not provide such a codepoint, then the third scenario MUST NOT be used.
如果（且仅当）第三种情况适用，则数据链路或隧道封装必须提供一个代码点，该代码点指定被封装MPLS数据包的顶部标签是上游分配的还是下游分配的。如果特定类型的数据链路或隧道不提供这样的代码点，则不得使用第三种方案。
The remainder of this document specifies procedures for setting the data link layer codepoints and address fields.
本文档的其余部分指定了设置数据链路层代码点和地址字段的步骤。
Ethernet is an example of a multipoint-to-multipoint data link.
以太网是多点到多点数据链路的一个示例。
Ethertype 0x8847 is used whenever a unicast ethernet frame carries an MPLS packet.
只要单播以太网帧携带MPLS数据包，就会使用以太网类型0x8847。
Ethertype 0x8847 is also used whenever a multicast ethernet frame carries an MPLS packet, EXCEPT for the case where the top label of the MPLS packet has been upstream-assigned.
Ethertype 0x8847也可在多播以太网帧携带MPLS数据包时使用，但MPLS数据包的顶部标签已被上游分配的情况除外。
Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", is to be used only when an MPLS packet whose top label is upstream-assigned is carried in a multicast ethernet frame.
Ethertype 0x8848（以前称为“MPLS多播码点”）仅在多播以太网帧中承载其上标签为上游分配的MPLS数据包时使用。
PPP is an example of a point-to-point data link. When a PPP frame is carrying an MPLS packet, the PPP Protocol field is always set to 0x0281.
PPP是点对点数据链路的一个示例。当PPP帧承载MPLS数据包时，PPP协议字段始终设置为0x0281。
RFC 4023 is modified as described below.
RFC 4023修改如下所述。
If the IP destination address of the Generic Routing Encapsulation (GRE) is a unicast IP address, then the ethertype value 0x8847 MUST be used in all cases for the MPLS-in-GRE encapsulation.
如果通用路由封装（GRE）的IP目标地址是单播IP地址，则在所有情况下，必须为GRE封装中的MPLS使用ethertype值0x8847。
If the IP destination address of the GRE encapsulation is a multicast IP address, then:
如果GRE封装的IP目标地址是多播IP地址，则：
- the ethertype value 0x8847 MUST be used when the top label of the encapsulated MPLS packet is downstream-assigned,
- 当封装的MPLS数据包的顶部标签被下游分配时，必须使用ethertype值0x8847，
- the ethertype value 0x8848 MUST be used when the top label of the encapsulated MPLS packet is upstream-assigned.
- 当向上游分配封装的MPLS数据包的顶部标签时，必须使用ethertype值0x8848。
Through procedures that are outside the scope of this specification, it may be known that if the destination address of a GRE packet is a multicast IP address, then the top label of the GRE payload is upstream-assigned. In such a case, the occurrence of the 8847 codepoint in a GRE packet with a multicast destination IP address MUST be considered an error, and the packet MUST be discarded.
Through procedures that are outside the scope of this specification, it may be known that if the destination address of a GRE packet is a multicast IP address, then the top label of the GRE payload is upstream-assigned. In such a case, the occurrence of the 8847 codepoint in a GRE packet with a multicast destination IP address MUST be considered an error, and the packet MUST be discarded.translate error, please retry
RFC 4023 is modified as follows: the IPv4 Protocol Number field or the IPv6 Next Header field is always set to 137, whether or not the encapsulated MPLS packet is an MPLS multicast packet.
RFC 4023修改如下：无论封装的MPLS数据包是否为MPLS多播数据包，IPv4协议编号字段或IPv6下一报头字段始终设置为137。
If the IP destination address of the IP encapsulation is an IP multicast address, the IP tunnel may be considered to be a point-to-multipoint tunnel or a multipoint-to-multipoint tunnel. In either case, either all encapsulated MPLS packets in the particular tunnel have a downstream-assigned label at the top of the stack, or all encapsulated MPLS packets in that tunnel have an upstream-assigned label at the top of the stack. The means by which this is determined for a particular tunnel is outside the scope of this specification.
如果IP封装的IP目的地地址是IP多播地址，则IP隧道可被视为点对多点隧道或多点对多点隧道。在这两种情况下，或者特定隧道中的所有封装MPLS数据包在堆栈顶部具有下游分配的标签，或者该隧道中的所有封装MPLS数据包在堆栈顶部具有上游分配的标签。确定特定隧道的方法不在本规范范围内。
When an LSR transmits a multicast MPLS packet in a multicast ethernet frame, it MUST set the MAC Destination Address to the value 01-00-5e-8v-wx-yz, where vwxyz is a 20-bit (five-nibble) value set as follows:
当LSR在多播以太网帧中传输多播MPLS数据包时，它必须将MAC目标地址设置为值01-00-5e-8v-wx-yz，其中vwxyz是一个20位（五个半字节）的值，设置如下：
1. vwxyz MAY be set to 0,
1. vwxyz可以设置为0，
2. vwxyz MAY be set to the value of one of the MPLS labels on the packet's label stack.
2. vwxyz可以设置为数据包标签堆栈上的一个MPLS标签的值。
Which of these procedures is the default procedure in any particular LSR is implementation-dependent. However, LSRs using the two different procedures MUST interoperate. That is, an LSR MUST NOT filter packets for which vwxyz has been set to zero, and it MUST NOT indiscriminately filter all packets for which vwxyz has not been set to zero.
这些过程中的哪一个是任何特定LSR中的默认过程取决于实现。但是，使用两个不同过程的LSR必须互操作。也就是说，LSR不能过滤vwxyz已设置为零的数据包，也不能不加区别地过滤vwxyz未设置为零的所有数据包。
If an LSR follows the procedure of setting vwxyz to the value of one of the MPLS labels on the packet's label stack, and if that label stack contains two or more labels, then by default, vwxyz MUST be set to the value of the second MPLS label on the packet's label stack. By "the second label", we mean the label that is in the label stack entry that immediately follows the topmost label stack entry. The LSR MAY, if configured to do so, allow a label other than the second
如果LSR遵循将vwxyz设置为数据包标签堆栈上的一个MPLS标签的值的过程，并且如果该标签堆栈包含两个或多个标签，则默认情况下，vwxyz必须设置为数据包标签堆栈上的第二个MPLS标签的值。“第二个标签”是指标签堆栈条目中紧跟在最顶部标签堆栈条目之后的标签。如果配置为这样做，LSR可以允许第二个标签以外的标签
to be used for this purpose. If the MPLS packet has only one label, the value of that label will be used instead of the value of the (non-existent) second label.
用于此目的。如果MPLS数据包只有一个标签，则将使用该标签的值，而不是（不存在的）第二个标签的值。
It is expected that the LSR will follow the procedures of [RFC5331], pushing on two labels, with the topmost label being a "context label" that is the same for all MPLS packets being transmitted by the LSR onto the ethernet, but with the second label being different for different LSPs. Thus, if the MAC DA value is a function of the second label, more of the LSP-specific information about the packet appears in the MAC DA field. This can be used to filter multicast packets with "unexpected" non-zero values of vwxyz. Further discussion of such filtering or its uses is outside the scope of this document.
预计LSR将遵循[RFC5331]的程序，推上两个标签，最上面的标签是“上下文标签”，对于LSR传输到以太网上的所有MPLS数据包来说，上下文标签是相同的，但是对于不同的LSP，第二个标签是不同的。因此，如果MAC DA值是第二标签的函数，则关于分组的更多LSP特定信息出现在MAC DA字段中。这可用于过滤具有“意外”非零值vwxyz的多播数据包。对此类过滤或其用途的进一步讨论不在本文件范围内。
The use of ethernet and/or IP broadcast addresses (as distinguished from multicast addresses) does not fall within the scope of this specification.
以太网和/或IP广播地址（区别于多播地址）的使用不属于本规范的范围。
IANA already owns the set of ethernet multicast addresses in the range 01-00-5e-00-00-00 to 01-00-5e-ff-ff-ff. Addresses in the range 01-00-5e-00-00-00 to 01-00-5e-7f-ff-ff are already reserved for use when an ethernet multicast frame carries an IP multicast packet.
IANA已经拥有范围为01-00-5e-00-00-00到01-00-5e-ff-ff-ff的以太网多播地址集。范围为01-00-5e-00-00-00至01-00-5e-7f-ff-ff的地址已保留，以供以太网多播帧承载IP多播数据包时使用。
IANA has reserved ethernet addresses in the range 01-00-5e-80-00-00 to 01-00-5e-8f-ff-ff for use when an ethernet multicast frame carries an MPLS multicast packet. Addresses in this range are valid when used with ethertype 8847 or 8848.
IANA保留了范围为01-00-5e-80-00-00至01-00-5e-8f-ff-ff的以太网地址，以便在以太网多播帧承载MPLS多播数据包时使用。当与ethertype 8847或8848一起使用时，此范围内的地址有效。
As this document modifies the usage of ethertypes 8847 and 8848, IANA has changed the description of these ethertypes as follows. Ethertype 8847 is defined as "MPLS", as defined in RFC 3032 and in this document. Ethertype 8848 is defined as "MPLS with upstream-assigned label", as defined in this document.
由于本文档修改了ethertypes 8847和8848的用法，IANA将这些ethertypes的描述更改如下。Ethertype 8847定义为“MPLS”，如RFC 3032和本文档中所定义。Ethertype 8848定义为“具有上游分配标签的MPLS”，如本文件所述。
The security considerations of RFC 3032 and RFC 4023 apply.
RFC 3032和RFC 4023的安全注意事项适用。
Malicious changing of the codepoint may result in loss or misrouting of packets. However, altering the codepoint without also altering the label does not result in a predictable effect.
恶意更改代码点可能导致数据包丢失或路由错误。但是，在不改变标签的情况下改变代码点不会产生可预测的效果。
Malicious alteration of the MAC DA on an ethernet can result in packets being received by a third party, rather than by the intended recipient.
恶意更改以太网上的MAC DA可能导致数据包被第三方接收，而不是被预期的接收者接收。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[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月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，编辑，“在IP或通用路由封装（GRE）中封装MPLS”，RFC4023，2005年3月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 53312008年8月。
Authors' Addresses
作者地址
Toerless Eckert Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
加利福尼亚州圣何塞塔斯曼大道170号埃克特思科系统有限公司，邮编：95134
EMail: eckert@cisco.com
EMail: eckert@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
Eric C.Rosen Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089
Rahul Aggarwal Juniper Networks加利福尼亚州桑尼维尔北马蒂尔达大道1194号，邮编94089
EMail: rahul@juniper.net
EMail: rahul@juniper.net
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089
加利福尼亚州桑尼维尔北马蒂尔达大道1194号雅科夫·雷克特·朱尼珀网络公司，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.