Network Working Group R. Aggarwal
Request for Comments: 5331 Juniper Networks
Category: Standards Track Y. Rekhter
Juniper Networks
E. Rosen
Cisco Systems, Inc.
August 2008
Network Working Group R. Aggarwal
Request for Comments: 5331 Juniper Networks
Category: Standards Track Y. Rekhter
Juniper Networks
E. Rosen
Cisco Systems, Inc.
August 2008
MPLS Upstream Label Assignment and Context-Specific Label Space
MPLS上游标签分配和上下文特定标签空间
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space".
RFC 3031将MPLS体系结构限制为下游分配的MPLS标签。本文档介绍了上游分配MPLS标签的概念。它描述了上游MPLS标签分配的过程，并引入了“上下文特定标签空间”的概念。
Table of Contents
目录
1. Introduction ....................................................2
2. Specification of Requirements ...................................2
3. Context-Specific Label Space ....................................2
4. Upstream Label Assignment .......................................3
4.1. Upstream-Assigned and Downstream-Assigned Labels ...........4
5. Assigning Upstream-Assigned Labels ..............................5
6. Distributing Upstream-Assigned Labels ...........................5
7. Upstream Neighbor Label Space ...................................6
8. Context Label on LANs ...........................................9
9. Usage of Upstream-Assigned Labels ..............................10
10. Security Considerations .......................................10
11. Acknowledgements ..............................................11
12. References ....................................................11
12.1. Normative References .....................................11
12.2. Informative References ...................................11
1. Introduction ....................................................2
2. Specification of Requirements ...................................2
3. Context-Specific Label Space ....................................2
4. Upstream Label Assignment .......................................3
4.1. Upstream-Assigned and Downstream-Assigned Labels ...........4
5. Assigning Upstream-Assigned Labels ..............................5
6. Distributing Upstream-Assigned Labels ...........................5
7. Upstream Neighbor Label Space ...................................6
8. Context Label on LANs ...........................................9
9. Usage of Upstream-Assigned Labels ..............................10
10. Security Considerations .......................................10
11. Acknowledgements ..............................................11
12. References ....................................................11
12.1. Normative References .....................................11
12.2. Informative References ...................................11
RFC 3031 [RFC3031] limits the MPLS architecture to downstream-assigned MPLS labels. To quote from RFC 3031:
RFC 3031[RFC3031]将MPLS体系结构限制为下游分配的MPLS标签。引用RFC 3031：
"In the MPLS architecture, the decision to bind a particular label L to a particular Forwarding Equivalence Class (FEC) F is made by the Label Switching Router (LSR) which is DOWNSTREAM with respect to that binding. The downstream LSR then informs the upstream LSR of the binding. Thus labels are "downstream-assigned", and label bindings are distributed in the "downstream to upstream" direction."
在MPLS体系结构中，将特定标签L绑定到特定转发等价类（FEC）F的决定是由标签交换路由器（LSR）做出的，该路由器相对于该绑定位于下游。然后，下游LSR将绑定通知上游LSR。因此，标签是“下游分配的”和标签绑定以“从下游到上游”的方向分布
This document introduces the notion of upstream-assigned MPLS labels to the MPLS architecture. The procedures for upstream assignment of MPLS labels are described.
本文档将向MPLS体系结构介绍上游分配MPLS标签的概念。描述了MPLS标签的上游分配过程。
RFC 3031 describes per-platform and per-interface label space. This document generalizes the latter to a "Context-Specific Label Space" and describes a "Neighbor Label Space" as an example of this. Upstream-assigned labels are always looked up in a context-specific label space.
RFC 3031描述了每个平台和每个接口标签空间。本文档将后者概括为“特定于上下文的标签空间”，并以“相邻标签空间”为例进行了描述。上游指定的标签始终在特定于上下文的标签空间中查找。
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]中所述进行解释。
RFC 3031 describes per-platform and per-interface label spaces. This document introduces the more general concept of a "Context-Specific Label Space". An LSR may maintain one or more context-specific label spaces. In general, labels MUST be looked up in the per-platform label space unless something about the context determines that a label be looked up in a particular context-specific label space.
RFC 3031描述了每个平台和每个接口标签空间。本文档介绍了“上下文特定标签空间”的更一般概念。LSR可以维护一个或多个上下文特定的标签空间。通常，必须在每个平台标签空间中查找标签，除非上下文的某些内容决定在特定上下文特定的标签空间中查找标签。
One example of a context-specific label space is the per-interface label space discussed in RFC 3031. When an MPLS packet is received over a particular interface, the top label of the packet may need to be looked up in the receiving interface's per-interface label space. In this case, the receiving interface is the context of the packet. Whether MPLS packets received over a particular interface need to have their top labels looked up in a per-interface label space depends on some characteristic or configuration of the interface.
上下文特定标签空间的一个示例是RFC 3031中讨论的每个接口标签空间。当通过特定接口接收MPLS分组时，可能需要在接收接口的每个接口标签空间中查找分组的顶部标签。在这种情况下，接收接口是数据包的上下文。通过特定接口接收的MPLS数据包是否需要在每个接口标签空间中查找其顶部标签取决于接口的某些特征或配置。
Per-interface label space [RFC3031] is an example of a context-specific label space used for downstream-assigned labels. Context-specific label spaces can also be used for upstream-assigned labels, as described below.
每个接口标签空间[RFC3031]是用于下游指定标签的上下文特定标签空间的示例。上下文特定的标签空间也可用于上游指定的标签，如下所述。
When MPLS labels are upstream-assigned, the context of an MPLS label L is provided by the LSR that assigns the label and binds the label to a FEC F for a Label Switched Path (LSP) LSP1. The LSR that assigns the label distributes the binding and context to an LSR Lr that then receives MPLS packets on LSP1 with label L. When Lr receives an MPLS packet on LSP1, it MUST be able to determine the context of this packet.
当MPLS标签被上游分配时，MPLS标签L的上下文由分配标签并将标签绑定到标签交换路径（LSP）LSP1的FEC F的LSR提供。分配标签的LSR将绑定和上下文分发给LSR Lr，然后LSR Lr在带有标签L的LSP1上接收MPLS数据包。当Lr在LSP1上接收MPLS数据包时，它必须能够确定此数据包的上下文。
An example of such a context is a tunnel over which MPLS packets on LSP1 may be received. In this case, the top label of the MPLS packet, after tunnel decapsulation, is looked up in a label space that is specific to the root of the tunnel. This does imply that Lr be able to determine the tunnel over which the packet was received. Therefore, if the tunnel is an MPLS tunnel, penultimate-hop-popping (PHP) MUST be disabled for the tunnel.
这种上下文的一个示例是可以通过其接收LSP1上的MPLS分组的隧道。在这种情况下，在隧道解除封装之后，在特定于隧道根的标签空间中查找MPLS分组的顶部标签。这确实意味着Lr能够确定接收数据包的隧道。因此，如果隧道是MPLS隧道，则必须为隧道禁用倒数第二跳弹出（PHP）。
Another example of such a context is the neighbor from which MPLS packets on LSP1 may be received. In this case, the top label of the MPLS packet, transmitted by the neighbor on LSP1, is looked up in a "Neighbor-Specific Label Space".
这种上下文的另一个示例是可以从中接收LSP1上的MPLS分组的邻居。在这种情况下，在“邻居特定标签空间”中查找由LSP1上的邻居发送的MPLS分组的顶部标签。
The above two examples are further described in Section 7.
上述两个示例将在第7节中进一步描述。
There may be other sorts of contexts as well. For instance, we define the notion of an MPLS label being used to establish a context, i.e., identify a label space. A "context label" is one that identifies a label table in which the label immediately below the context label should be looked up. A context label carried as an outermost label over a particular multi-access subnet/tunnel MUST be unique within the scope of that subnet/tunnel.
可能还有其他类型的上下文。例如，我们定义了MPLS标签用于建立上下文的概念，即标识标签空间。“上下文标签”是一种标识标签表的标签，在该表中应查找上下文标签正下方的标签。作为特定多访问子网/隧道上的最外层标签携带的上下文标签在该子网/隧道的范围内必须是唯一的。
When two MPLS LSRs are adjacent in an MPLS Label Switched Path (LSP), one of them can be termed an "upstream LSR" and the other a "downstream LSR" [RFC3031]. Consider two LSRs, Ru and Rd, that have agreed to bind Label L to a FEC F for packets sent from Ru to Rd. Then, with respect to this binding, Ru is the "upstream LSR", and Rd is the "downstream LSR"."
当两个MPLS LSR在MPLS标签交换路径（LSP）中相邻时，其中一个可称为“上游LSR”，另一个可称为“下游LSR”[RFC3031]。考虑两个LSR，RU和RD，已经同意将标签L绑定到FEC F，用于从RU到RD发送的分组。然后，对于这种绑定，RU是“上游LSR”，RD是“下游LSR”。
If the binding between L and F was made by Rd and advertised to Ru, then the label binding is known as "downstream-assigned". RFC 3031 only discusses downstream-assigned label bindings.
如果L和F之间的绑定是由Rd进行的，并公布给Ru，则标签绑定称为“下游指定”。RFC 3031仅讨论下游分配的标签绑定。
If the binding between L and F was made by Ru and advertised to Rd, then the label binding is known as "upstream-assigned".
如果L和F之间的绑定是由Ru进行的，并通告给Rd，则标签绑定称为“上游指定”。
If the binding between L and F was made by a third party, say R3, and then advertised to both Ru and Rd, we also refer to the label binding as "upstream-assigned".
如果L和F之间的绑定是由第三方（如R3）进行的，然后向Ru和Rd发布广告，我们也将标签绑定称为“上游分配”。
An important observation about upstream-assigned labels is the following. When an upstream-assigned label L is at the top of the label stack, it must be looked up by an LSR that is not the LSR that assigned and distributed the label binding for L. Therefore, an upstream-assigned label MUST always be looked up in a context-specific label space, as described in Section 7.
关于上游指定标签的一个重要观察结果如下。当上游分配的标签L位于标签堆栈的顶部时，必须由LSR查找，该LSR不是为L分配和分发标签绑定的LSR。因此，上游分配的标签必须始终在上下文特定的标签空间中查找，如第7节所述。
We do not require any coordination between the upstream label assignments and the downstream label assignments; a particular label value may be upstream-assigned to one FEC and downstream-assigned to a different FEC.
我们不需要在上游标签分配和下游标签分配之间进行任何协调；特定标签值可以上游分配给一个FEC，下游分配给不同的FEC。
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.
使用上游指定标签的功能是可选功能。除非知道下游LSR支持上游指定标签，否则不得使用上游指定标签。
One use case of upstream-assigned labels is MPLS multicast, and an example of this is provided in Section 9.
上游分配标签的一个用例是MPLS多播，第9节提供了一个例子。
It is possible that some LSRs on an LSP for FEC F distribute downstream-assigned label bindings for FEC F, while other LSRs distribute upstream-assigned label bindings. It is possible for an LSR to distribute a downstream-assigned label binding for FEC F to its upstream adjacent LSR AND distribute an upstream-assigned label binding for FEC F to its downstream adjacent LSR. When two LSRs, Ru and Rd, are adjacent on an LSP for FEC F (with Ru being the upstream neighbor and Rd the downstream neighbor), either Ru distributes an upstream-assigned label binding for F to Rd, or else Rd distributes a downstream-assigned label binding to Ru, but NOT both. Whether upstream-assigned or downstream-assigned labels are to be used for a particular FEC depends on the application using the LSP.
FEC F的LSP上的某些LSR可能为FEC F分发下游分配的标签绑定，而其他LSR则分发上游分配的标签绑定。LSR可以将用于FEC F的下游分配标签绑定分发到其上游相邻LSR，并将用于FEC F的上游分配标签绑定分发到其下游相邻LSR。当两个LSR Ru和Rd在FEC F的LSP上相邻时（Ru是上游邻居，Rd是下游邻居），Ru将F的上游分配标签绑定分发给Rd，或者Rd将下游分配标签绑定分发给Ru，但不是两者都分发。特定FEC使用上游分配标签还是下游分配标签取决于使用LSP的应用程序。
Any application that requires the use of upstream-assigned labels MUST specify that explicitly, or else it is to be assumed that downstream-assigned labels are used. An application on an LSR uses a label distribution protocol to indicate to its peer LSRs whether a particular label binding distributed by the LSR uses upstream-assigned or downstream-assigned label. Details of such procedures are outside the scope of this document. In some cases, the decision
任何需要使用上游指定标签的应用程序必须明确指定，否则将假定使用下游指定标签。LSR上的应用程序使用标签分发协议向其对等LSR指示由LSR分发的特定标签绑定是使用上游分配的标签还是下游分配的标签。此类程序的详细信息不在本文件范围内。在某些情况下，决策
as to which is used for a particular application may be made by a configuration option.
对于用于特定应用的组件，可以通过配置选项来确定。
The only requirement on an upstream LSR assigning upstream-assigned labels is that an upstream-assigned label must be unambiguous in the context-specific label space in which the downstream LSR will look it up. An upstream LSR that is the headend of multiple tunnels SHOULD, by default, assign the upstream-assigned labels, for all the LSPs carried over these tunnels, from a single label space, which is common to all those tunnels. Further, an upstream LSR that is the head of multiple tunnels SHOULD use the same IP address as the head identifier of these tunnels, provided that the head identifier of these tunnels includes an IP address. The LSR could assign the same label value to both a downstream-assigned and an upstream-assigned label. The downstream LSR always looks up upstream-assigned MPLS labels in a context-specific label space as described in Section 7.
上游LSR分配上游分配标签的唯一要求是，上游分配标签必须在特定于上下文的标签空间中明确，下游LSR将在其中查找该标签。默认情况下，作为多条隧道前端的上游LSR应从单个标签空间为通过这些隧道的所有LSP分配上游分配的标签，这对于所有这些隧道来说都是通用的。此外，作为多个隧道的头部的上游LSR应使用与这些隧道的头部标识符相同的IP地址，前提是这些隧道的头部标识符包括IP地址。LSR可以为下游分配的标签和上游分配的标签分配相同的标签值。下游LSR始终在特定于上下文的标签空间中查找上游分配的MPLS标签，如第7节所述。
An entry for the upstream-assigned labels is not created in the Incoming Label Map (ILM) [RFC3031] at the upstream LSR as these labels are not incoming labels. Instead, an upstream label is an outgoing label, with respect to the upstream LSR, for MPLS packets transmitted on the MPLS LSP in which the upstream LSR is adjacent to the downstream LSR. Hence, an upstream label is part of a Next Hop Label Forwarding Entry (NHLFE) at the upstream LSR.
上游LSR处的传入标签映射（ILM）[RFC3031]中未创建上游分配标签的条目，因为这些标签不是传入标签。相反，对于在其中上游LSR与下游LSR相邻的MPLS LSP上传输的MPLS分组，上游标签是关于上游LSR的传出标签。因此，上游标签是上游LSR处的下一跳标签转发条目（NHLFE）的一部分。
When Ru advertises a binding of label L for FEC F to Rd, it creates a NHLFE entry corresponding to L. This NHLFE entry results in imposing the label L on the MPLS label stack of the packet forwarded using the NHLFE entry. If Ru is a transit router on the LSP for FEC F, it binds the ILM for the LSP to this NHLFE. If Ru is an ingress router on the LSP for FEC F, it binds the FEC to the NHLFE entry.
当Ru播发FEC F到Rd的标签L绑定时，它创建一个与L对应的NHLFE条目。该NHLFE条目导致将标签L施加在使用NHLFE条目转发的数据包的MPLS标签堆栈上。如果Ru是用于FEC F的LSP上的传输路由器，则它将LSP的ILM绑定到此NHLFE。如果Ru是LSP上FEC F的入口路由器，它将FEC绑定到NHLFE入口。
Upstream-assigned label bindings 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支持上游分配的标签绑定，否则不得使用上游分配的标签绑定。如何知道这一点超出了本文件的范围。
MPLS upstream label assignment requires a label distribution protocol to distribute the binding from the upstream LSR to the downstream LSR. Considerations that pertain to a label distribution protocol that are described in [RFC3031] apply.
MPLS上游标签分配需要一个标签分发协议来将绑定从上游LSR分发到下游LSR。与[RFC3031]中描述的标签分发协议相关的注意事项适用。
The distribution of the upstream-assigned labels is similar to either the ordered LSP control or independent LSP control of the downstream-assigned labels. In the former case, an LSR distributes an upstream-
上游分配标签的分布类似于下游分配标签的有序LSP控制或独立LSP控制。在前一种情况下，LSR分配上游-
assigned label binding for a FEC F if it is either (a) the ingress LSR for FEC F, or (b) if it has already received an upstream label binding for that FEC from its adjacent upstream LSR for FEC F, or (c) if it has received a request for a downstream label binding from its upstream adjacent LSR. In the latter case, each LSR, upon noting that it recognizes a particular FEC, makes an independent decision to bind an upstream-assigned label to that FEC and to distribute that binding to its label distribution peers.
如果FEC F是（a）FEC F的入口LSR，或者（b）如果FEC F的相邻上游LSR已接收到该FEC的上游标签绑定，或者（c）如果FEC F的相邻上游LSR已接收到下游标签绑定请求，则为FEC F分配标签绑定。在后一种情况下，每个LSR在注意到其识别特定FEC后，做出独立的决定，将上游分配的标签绑定到该FEC，并将该绑定分发到其标签分发对等方。
If the top label of an MPLS packet being processed by LSR Rd is upstream-assigned, the label is looked up in a context-specific label space, not in a per-platform label space.
如果LSR Rd正在处理的MPLS数据包的顶部标签是上游分配的，则该标签将在特定于上下文的标签空间中查找，而不是在每个平台的标签空间中查找。
Rd uses a context-specific label space that it maintains for Ru to "reserve" MPLS labels assigned by Ru. Hence, if Ru distributes an upstream-assigned label binding L for FEC F to Rd, then Rd reserves L in the separate ILM for Ru's context-specific label space. This is the ILM that Rd uses to look up an MPLS label that is upstream-assigned by Ru. This label may be the top label on the label stack of a packet received from Ru or it may be exposed as the top label on the label stack, as a result of Rd popping one or more labels off the label stack, from such a packet.
Rd使用它为Ru维护的特定于上下文的标签空间来“保留”Ru分配的MPLS标签。因此，如果Ru将FEC F的上游分配标签绑定L分配给Rd，则Rd在单独的ILM中为Ru的上下文特定标签空间保留L。这是Rd用于查找由Ru向上游分配的MPLS标签的ILM。该标签可以是从Ru接收的分组的标签堆栈上的顶部标签，或者由于Rd从标签堆栈上弹出一个或多个标签，该标签可以作为标签堆栈上的顶部标签公开。
This implies that Rd MUST be able to determine whether the top label of an MPLS packet being processed is upstream-assigned and, if yes, the "context" of this packet. How this determination is made depends on the mechanism that is used by Ru to transmit the MPLS packet with an upstream-assigned top label L to Rd.
这意味着Rd必须能够确定正在处理的MPLS数据包的顶部标签是否是上游分配的，如果是，则确定该数据包的“上下文”。如何作出该确定取决于Ru使用的机制，该机制用于传输具有上游分配的顶标签L到Rd的MPLS分组。
If Ru transmits this packet by encapsulating it in an IP or MPLS tunnel, then the fact that L is upstream-assigned is determined by Rd by the tunnel on which the packet is received. Whether a given tunnel can be used for transmitting MPLS packets with either downstream-assigned or upstream-assigned MPLS labels, or both, depends on the tunnel type and is described in [RFC5332]. When Rd receives MPLS packets with a top label L on such a tunnel, it determines the "context" of this packet based on the tunnel on which the packet is received. There must be a mechanism for Ru to inform Rd that a particular tunnel from Ru to Rd will be used by Ru for transmitting MPLS packets with upstream-assigned MPLS labels. Such a mechanism will be provided by the label distribution protocol between Ru and Rd and will likely require extensions to existing label distribution protocols. The description of such a mechanism is outside the scope of this document.
如果Ru通过将该分组封装在IP或MPLS隧道中来发送该分组，则由Rd通过接收该分组的隧道来确定L被上游分配的事实。给定的隧道是否可用于传输具有下游分配或上游分配MPLS标签的MPLS数据包，或两者都可用，取决于隧道类型，并在[RFC5332]中进行了描述。当Rd在这样的隧道上接收到带有顶部标签L的MPLS数据包时，它根据接收数据包的隧道确定该数据包的“上下文”。Ru必须有一种机制来通知Rd，Ru将使用从Ru到Rd的特定隧道来传输具有上游分配的MPLS标签的MPLS数据包。这种机制将由Ru和Rd之间的标签分发协议提供，并且可能需要对现有标签分发协议进行扩展。对这种机制的描述不在本文件的范围之内。
Rd maintains an "Upstream Neighbor Label Space" for upstream-assigned labels, assigned by Ru. When Ru transmits MPLS packets the top label of which is upstream-assigned over IP or MPLS tunnels, then Rd MUST be able to determine the root of these IP/MPLS tunnels. Rd MUST then use a separate label space for each unique root.
Rd为Ru分配的上游分配标签维护“上游邻居标签空间”。当Ru通过IP或MPLS隧道传输其顶部标签为上游分配的MPLS数据包时，Rd必须能够确定这些IP/MPLS隧道的根。然后，Rd必须为每个唯一根使用单独的标签空间。
The root is identified by the head-end IP address of the tunnel. If the same upstream router, Ru, uses different head-end IP addresses for different tunnels, then the downstream router, Rd, MUST maintain a different Upstream Neighbor Label Space for each such head-end IP address.
根目录由隧道的前端IP地址标识。如果相同的上游路由器Ru为不同的隧道使用不同的头端IP地址，那么下游路由器Rd必须为每个这样的头端IP地址维护不同的上游邻居标签空间。
Consider the following conditions:
考虑以下条件：
1) Ru is the "root" of two tunnels, call them A and B.
1) Ru是两条隧道的“根”，称它们为A和B。
2) IP address X is an IP address of Ru.
2) IP地址X是Ru的IP地址。
3) The signaling protocol used to set up tunnel A identified A's root node as IP address X.
3) 用于设置隧道A的信令协议将A的根节点标识为IP地址X。
4) The signaling protocol used to set up tunnel B identified B's root node as IP address X.
4) 用于建立隧道B的信令协议将B的根节点标识为IP地址X。
5) Packets sent through tunnels A and B may be carrying upstream-assigned labels.
5) 通过隧道A和B发送的数据包可能携带上游分配的标签。
6) Ru is the LSR that assigned the upstream-assigned labels mentioned in condition 5.
6) Ru是分配条件5中提到的上游分配标签的LSR。
If and only if these conditions hold, then Ru MUST use the same label space when upstream-assigning labels for packets that travel through tunnel A that it uses when upstream-assigning labels for packets that travel through tunnel B.
当且仅当这些条件成立时，Ru在上游为通过隧道A的数据包分配标签时必须使用与上游为通过隧道B的数据包分配标签时相同的标签空间。
Suppose that Rd is a node that belongs to tunnels A and B, but is not the root node of either tunnel. Then Rd may assume that the same upstream-assigned label space is used on both tunnels IF AND ONLY IF the signaling protocol used to set up tunnel A identified the root node as IP address X and the signaling protocol used to set up tunnel B identified the root node as the same IP address X.
假设Rd是属于隧道a和B的节点，但不是任一隧道的根节点。然后，Rd可以假设，当且仅当用于建立隧道A的信令协议将根节点标识为IP地址X并且用于建立隧道B的信令协议将根节点标识为相同IP地址X时，在两个隧道上使用相同的上游分配的标签空间。
In addition, the protocol that is used for distributing the upstream-assigned label to be used over a particular tunnel MUST identify the "assigner" using the same IP address that is used by the protocol that sets up the tunnel to identify the root node of the tunnel. Implementors must take note of this, even if the tunnel setup
此外，用于分发要在特定隧道上使用的上游分配标签的协议必须使用与设置隧道以标识隧道根节点的协议相同的IP地址来标识“分配者”。实现者必须注意这一点，即使隧道设置
protocol is different from the protocol that is used for distributing the upstream-assigned label to be used over the tunnel.
协议不同于用于在隧道上分发要使用的上游分配标签的协议。
The precise set of procedures for identifying the IP address of the root of the tunnel depend, of course, on the protocol used to set up the tunnel. For Point-to-Point (P2P) tunnels, the intention is that the headend of the tunnel is the "root". For Point-to-Multipoint (P2MP) or Multipoint-to-Multipoint (MP2MP) tunnels, one can always identify one node as being the "root" of the tunnel.
当然，识别隧道根的IP地址的精确过程集取决于用于设置隧道的协议。对于点对点（P2P）隧道，其目的是隧道的前端是“根”。对于点对多点（P2MP）或多点对多点（MP2MP）隧道，始终可以将一个节点标识为隧道的“根”。
Some tunnels may be set up by configuration, rather than by signaling. In these cases, the IP address of the root of the tunnel must be configured.
一些隧道可以通过配置而不是通过信号来建立。在这些情况下，必须配置隧道根的IP地址。
Some tunnels may not even require configuration, e.g., a Generic Routing Encapsulation (GRE) tunnel can be "created" just by encapsulating packets and transmitting them. In such a case, the IP address of the root is considered to be the IP source address of the encapsulated packets.
一些隧道甚至可能不需要配置，例如，仅通过封装数据包并传输数据包即可“创建”通用路由封装（GRE）隧道。在这种情况下，根的IP地址被认为是封装包的IP源地址。
If the tunnel on which Rd receives MPLS packets with a top label L is an MPLS tunnel, then Rd determines a) that L is upstream-assigned and b) the context for L, from the labels above L in the label stack. Note that one or more of these labels may also be upstream-assigned labels.
如果Rd接收带有顶部标签L的MPLS数据包的隧道是MPLS隧道，则Rd根据标签堆栈中L上方的标签确定a）L是上游分配的，b）L的上下文。请注意，这些标签中的一个或多个也可能是上游指定的标签。
If the tunnel on which Rd receives MPLS packets with a top label L is an IP/GRE tunnel, then Rd determines a) that L is upstream-assigned [RFC5332] and b) the context for L, from the source address in the IP header.
如果Rd接收带有顶部标签L的MPLS数据包的隧道是IP/GRE隧道，则Rd确定a）L是上游分配的[RFC5332]，b）L的上下文来自IP报头中的源地址。
When Ru and Rd are adjacent to each other on a multi-access data link media, if Ru would transmit the packet, with top label L, by encapsulating it in a data link frame, then whether L is upstream-assigned or downstream assigned can be determined by Rd, as described in [RFC5332]. This is possible because if L is upstream-assigned, then [RFC5332] uses a different ether type in the data link frame. However, this is not sufficient for Rd to determine the context of this packet. In order for Rd to determine the context of this packet, Ru encapsulates the packet in a one-hop MPLS tunnel. This tunnel uses an MPLS context label that is assigned by Ru. Section 8 describes how the context label is assigned. Rd maintains a separate "Upstream Neighbor Label Space" for Ru. The "context" of this packet, i.e., Ru's upstream neighbor label space, in which L was reserved, is determined by Rd from the top context label and the interface on which the packet is received. The ether type in the data link frame is set to indicate that the top label is upstream-assigned. The second label in the stack is L.
当Ru和Rd在多址数据链路介质上彼此相邻时，如果Ru将通过将其封装在数据链路帧中来传输具有顶部标签L的分组，则L是上游分配的还是下游分配的可由Rd确定，如[RFC5332]中所述。这是可能的，因为如果L是上游分配的，则[RFC5332]在数据链路帧中使用不同的乙醚类型。然而，这不足以让Rd确定该数据包的上下文。为了让Rd确定该数据包的上下文，Ru将该数据包封装在一跳MPLS隧道中。此隧道使用由Ru分配的MPLS上下文标签。第8节描述了如何分配上下文标签。Rd为Ru维护单独的“上游邻居标签空间”。该分组的“上下文”，即Ru的上游邻居标签空间，其中L被保留，由Rd从顶部上下文标签和接收分组的接口确定。数据链路帧中的乙醚类型设置为指示已向上游分配顶部标签。堆栈中的第二个标签是L。
For a labeled packet with an ether type of "upstream label assignment", the top label is used as the context. The context label value is assigned by the upstream LSR and advertised to the downstream LSRs. Mechanisms for advertising the context label will be provided by the label distribution protocol between the upstream and downstream LSRs. The description of such a mechanism is outside the scope of this document.
对于乙醚类型为“上游标签分配”的标签数据包，顶部标签用作上下文。上下文标签值由上游LSR分配，并通告给下游LSR。用于广告上下文标签的机制将由上游和下游LSR之间的标签分发协议提供。对这种机制的描述不在本文件的范围之内。
The context label assigned by an LSR for use on a particular LAN interface MUST be unique across all the context labels assigned by other LSRs for use on the same LAN. When a labeled packet is received from the LAN, the context label MUST be looked up in the context of the LAN interface on which the packet is received.
LSR分配用于特定LAN接口的上下文标签在其他LSR分配用于同一LAN的所有上下文标签中必须是唯一的。当从LAN接收到带标签的数据包时，必须在接收数据包的LAN接口的上下文中查找上下文标签。
This document provides two methods that an LSR can use to choose a context label to advertise on a particular LAN.
本文档提供了两种方法，LSR可以使用这两种方法选择要在特定LAN上发布的上下文标签。
The first method requires that each LSR be provisioned with a 20-bit context label for each LAN interface on which a context label is required. It is then left to the provisioning system to make sure that an assigned context label is unique across the corresponding LAN.
第一种方法要求为每个需要上下文标签的LAN接口为每个LSR提供20位上下文标签。然后由供应系统来确保分配的上下文标签在相应的LAN中是唯一的。
The second method allows the context labels to be auto-generated, but is only applicable if each LSR on the LAN has an IPv4 address as its primary IP address for the corresponding LAN interface. (If the LAN contains LSRs that have only IPv6 addresses for the LAN interface, then the first method is used.)
第二种方法允许自动生成上下文标签，但仅当LAN上的每个LSR都有一个IPv4地址作为其对应LAN接口的主IP地址时才适用。（如果LAN包含仅具有LAN接口IPv6地址的LSR，则使用第一种方法。）
Suppose that each LAN interface is configured with a primary IPv4 address that is unique on that LAN. The host part of the IPv4 address, identified by the network mask, is unique. If the IPv4 network mask is greater than 12 bits, it is possible to map the remaining 20 bits into a unique context label value. This enables the LSRs on the LAN to automatically generate a unique context label. To ensure that auto-generated context label values do not fall into the reserved label space range [RFC3032], the value of the host part of the IPv4 address is offset with 0x10, if this value is not greater than 0xFFFEF. Values of the host part of the IPv4 address greater than 0xFFFEF are not allowed to be used as context labels.
假设每个LAN接口都配置了在该LAN上唯一的主IPv4地址。由网络掩码标识的IPv4地址的主机部分是唯一的。如果IPv4网络掩码大于12位，则可以将剩余的20位映射为唯一的上下文标签值。这使LAN上的LSR能够自动生成唯一的上下文标签。为确保自动生成的上下文标签值不属于保留标签空间范围[RFC3032]，如果该值不大于0xFFFEF，则IPv4地址的主机部分的值将偏移0x10。不允许将IPv4地址的主机部分大于0xFFFEF的值用作上下文标签。
Consider LSR Rm (downstream) connected to Ru1 (upstream) on a LAN interface and to Ru2 (upstream) on a different LAN interface. Rm could receive a context label value derived from the LAN interface from Ru1 and from Ru2. It is possible that the context label values used by Ru1 and Ru2 are the same. This would occur if the LAN
考虑在局域网接口上连接到RU1（上游）的LSR RM（下游），并在不同的LAN接口上考虑RU2（上游）。Rm可以从Ru1和Ru2接收从LAN接口派生的上下文标签值。Ru1和Ru2使用的上下文标签值可能相同。如果LAN
interfaces of both Ru1 and Ru2 are configured with a primary IPv4 address where the lowest 20 bits are equal. However, this does not create any ambiguity, as it has already been stated that the context label MUST be looked up in the context of the LAN interface on which the packet is received.
Ru1和Ru2的接口都配置有主IPv4地址，其中最低20位相等。然而，这不会产生任何歧义，因为已经说明，必须在接收数据包的LAN接口的上下文中查找上下文标签。
A typical use case of upstream-assigned labels is for MPLS multicast and is described here for illustration. This use case arises when an upstream LSR Ru is adjacent to several downstream LSRs <Rd1...Rdn> in an LSP, LSP1 AND Ru is connected to <Rd1...Rdn> via a multi-access media or tunnel, AND Ru wants to transmit a single copy of an MPLS packet on the LSP to <Rd1...Rdn>. In the case of a tunnel, Ru can distribute an upstream-assigned label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and transmit an MPLS packet, the top label of which is L, on the tunnel. In the case of a multi-access media, Ru can distribute an upstream-assigned label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and transmit an MPLS packet, the top label of which is the context label that identifies Ru, and the label immediately below is L, on the multi-access media. Each of <Rd1..Rdn> will then interpret this MPLS packet in the context of Ru and forward it appropriately. This implies that <Rd1..Rdn> MUST all be able to support an Upstream Neighbor Label Space for Ru and Ru MUST be able to determine this. The mechanisms for determining this are specific to the application that is using upstream-assigned labels and is outside the scope of this document.
上游分配标签的典型用例用于MPLS多播，此处描述用于说明。当上游LSR Ru与LSP中的多个下游LSR<Rd1…Rdn>相邻，LSP1和Ru通过多址介质或隧道连接到<Rd1…Rdn>，并且Ru想要将LSP上的MPLS分组的单个副本发送到<Rd1…Rdn>，就会出现这种用例。在隧道的情况下，Ru可以将绑定到用于LSP1的FEC的上游分配标签L分发到<Rd1..Rdn>，并在隧道上发送MPLS分组，其顶部标签为L。在多址介质的情况下，Ru可以将绑定到用于LSP1的FEC的上游分配的标签L分发到<Rd1..Rdn>，并在多址介质上发送MPLS分组，该MPLS分组的顶部标签是标识Ru的上下文标签，紧靠下面的标签是L。然后，<Rd1..Rdn>中的每一个将在Ru的上下文中解释该MPLS数据包并适当地转发它。这意味着<Rd1..Rdn>都必须能够支持Ru的上游邻居标签空间，并且Ru必须能够确定这一点。确定这一点的机制特定于使用上游指定标签的应用程序，不在本文档的范围内。
The security considerations that apply to upstream-assigned labels and context labels are no different in kind than those that apply to downstream-assigned labels.
适用于上游指定标签和上下文标签的安全注意事项与适用于下游指定标签的安全注意事项在性质上没有区别。
Note that procedures for distributing upstream-assigned labels and/or context labels are not within the scope of this document. Therefore, the security considerations that may apply to such procedures are not considered here.
请注意，分发上游指定标签和/或上下文标签的程序不在本文件的范围内。因此，此处不考虑可能适用于此类程序的安全考虑因素。
Section 8 of this document describes a procedure that enables an LSR to automatically generate a unique context label for a LAN. This procedure assumes that the IP addresses of all the LSR interfaces on the LAN will be unique in their low-order 20 bits. If two LSRs whose IP addresses have the same low-order 20 bits are placed on the LAN, other LSRs are likely to misroute packets transmitted to the LAN by either of the two LSRs in question.
本文档第8节描述了一个程序，该程序使LSR能够自动为LAN生成唯一的上下文标签。此过程假设LAN上所有LSR接口的IP地址在其低阶20位中是唯一的。如果在LAN上放置两个其IP地址具有相同低阶20位的LSR，则其他LSR可能会错误路由由所讨论的两个LSR之一传输到LAN的数据包。
More detailed discussion of security issues that are relevant in the context of MPLS and GMPLS, including security threats, related defensive techniques, and the mechanisms for detection and reporting, are discussed in "Security Framework for MPLS and GMPLS Networks [MPLS-SEC].
“MPLS和GMPLS网络安全框架[MPLS-SEC]中讨论了与MPLS和GMPLS相关的安全问题的更详细讨论，包括安全威胁、相关防御技术以及检测和报告机制。
Thanks to IJsbrand Wijnands's contribution, specifically for the text on which Section 8 is based.
感谢IJsbrand Wijnands的贡献，特别是第8节所依据的文本。
[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月。
[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月。
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encpsulations", RFC 5332, August 2008.
[RFC5332]Eckert，T.，Rosen，E.，Aggarwal，R.，和Y.Rekhter，“MPLS多播封装”，RFC 5332，2008年8月。
[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月。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2008.
[MPLS-SEC]Fang，L.，编辑，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2008年7月。
Authors' Addresses
作者地址
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
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
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.