Internet Engineering Task Force (IETF) X. Zhang, Ed.
Request for Comments: 8359 Huawei Technologies
Updates: 3471, 3473, 6205 V. Beeram, Ed.
Category: Standards Track Juniper Networks
ISSN: 2070-1721 I. Bryskin
Huawei Technologies
D. Ceccarelli
Ericsson
O. Gonzalez de Dios
Telefonica
March 2018
Internet Engineering Task Force (IETF) X. Zhang, Ed.
Request for Comments: 8359 Huawei Technologies
Updates: 3471, 3473, 6205 V. Beeram, Ed.
Category: Standards Track Juniper Networks
ISSN: 2070-1721 I. Bryskin
Huawei Technologies
D. Ceccarelli
Ericsson
O. Gonzalez de Dios
Telefonica
March 2018
Network-Assigned Upstream Label
网络分配上游标签
Abstract
摘要
This document discusses a Generalized Multi-Protocol Label Switching (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) mechanism that enables the network to assign an upstream label for a bidirectional Label Switched Path (LSP). This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFCs 3471, 3473, and 6205 as it defines processing for a special label value in the UPSTREAM_LABEL object.
本文讨论了一种通用多协议标签交换（GMPLS）资源预留协议，该协议具有流量工程（RSVP-TE）机制，使网络能够为双向标签交换路径（LSP）分配上游标签。如果给定节点自身没有足够的信息来分配正确的上游标签，并且需要依赖下游节点来选择适当的标签，则此功能非常有用。本文档更新了RFCs 3471、3473和6205，因为它定义了上游标签对象中特殊标签值的处理。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8359.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8359.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Unassigned Upstream Label . . . . . . . . . . . . . . . . . . 3
3.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 5
4. Use-Case: Wavelength Setup for IP over Optical Networks . . . 5
4.1. Initial Setup . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Wavelength Change . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Unassigned Upstream Label . . . . . . . . . . . . . . . . . . 3
3.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 5
4. Use-Case: Wavelength Setup for IP over Optical Networks . . . 5
4.1. Initial Setup . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Wavelength Change . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
A functional description of the Generalized Multi-Protocol Label Switching (GMPLS) signaling extensions for setting up a bidirectional Label Switched Path (LSP) is provided in [RFC3471]. The GMPLS Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) extensions for setting up a bidirectional LSP are specified in [RFC3473]. The bidirectional LSP setup is indicated by the presence of an UPSTREAM_LABEL object in the Path message. As per the existing setup procedure outlined for a bidirectional LSP, each upstream node must allocate a valid upstream label on the outgoing interface before sending the initial Path message downstream. However, there are certain scenarios (see Section 4) where it is not desirable or possible for a given node to pick the upstream label on its own.
[RFC3471]中提供了用于建立双向标签交换路径（LSP）的通用多协议标签交换（GMPLS）信令扩展的功能描述。[RFC3473]中规定了用于建立双向LSP的带有流量工程（RSVP-TE）扩展的GMPLS资源预留协议。双向LSP设置由路径消息中存在上游标签对象表示。根据为双向LSP概述的现有设置过程，每个上游节点必须在向下游发送初始路径消息之前在传出接口上分配有效的上游标签。但是，在某些情况下（见第4节），给定节点不希望或不可能自己选择上游标签。
This document defines the protocol mechanism to be used in such scenarios. This mechanism enables a given node to offload the task of assigning the upstream label for a given bidirectional LSP to nodes downstream in the network. It is meant to be used only for bidirectional LSPs that assign symmetric labels at each hop along the path of the LSP. Bidirectional Lambda Switch Capable (LSC) LSPs use symmetric lambda labels (format specified in [RFC6205]) at each hop along the path of the LSP.
本文档定义了在此类场景中使用的协议机制。该机制使得给定节点能够卸载将给定双向LSP的上游标签分配给网络中下游节点的任务。它仅用于双向LSP，该双向LSP在LSP路径上的每个跃点分配对称标签。支持双向Lambda交换机（LSC）的LSP在沿着LSP路径的每个跃点处使用对称Lambda标签（在[RFC6205]中指定的格式）。
As per the bidirectional LSP setup procedures specified in [RFC3471] and [RFC3473], the UPSTREAM_LABEL object must indicate a label that is valid for forwarding. This document updates that by allowing the UPSTREAM_LABEL object to indicate a special label that isn't valid for forwarding. As per the bidirectional LSC LSP setup procedures specified in [RFC6205], the LABEL_SET object and the UPSTREAM_LABEL object must contain the same label value. This document updates that by allowing the UPSTREAM_LABEL object to carry a special label value that is different from the one used in the LABEL_SET object.
根据[RFC3471]和[RFC3473]中规定的双向LSP设置程序，上游_标签对象必须指示可有效转发的标签。本文档通过允许上游_标签对象指示无法转发的特殊标签来更新。根据[RFC6205]中规定的双向LSC LSP设置程序，标签设置对象和上游标签对象必须包含相同的标签值。本文档通过允许上游标签对象携带与标签集对象中使用的标签值不同的特殊标签值来更新该值。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document defines a special label value -- "0xFFFFFFFF" (for a 4-octet label) -- to indicate an Unassigned Upstream Label. Similar "all-ones" patterns are expected to be used for labels of other sizes.
本文档定义了一个特殊的标签值——“0xFFFFFFFF”（对于4个八位字节的标签）——以指示未分配的上游标签。类似的“全一”模式预计将用于其他尺寸的标签。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Unassigned UPSTREAM_LABEL - "all-ones" Pattern
图1：未分配的上游_标签-“所有”模式
The presence of this value in the UPSTREAM_LABEL object of a Path message indicates that the upstream node has not assigned an upstream label on its own and has requested the downstream node to provide a label that it can use in both the forward and reverse directions.
路径消息的上游标签对象中存在该值表示上游节点未单独分配上游标签，并已请求下游节点提供其可在正向和反向使用的标签。
The presence of this value in the UPSTREAM_LABEL object of a Path message MUST also be interpreted by the receiving node as a request to mandate symmetric labels for the LSP.
接收节点还必须将Path消息的上游_标签对象中存在的该值解释为要求为LSP指定对称标签的请求。
The scope of the procedures is limited to the exchange and processing of messages between an upstream node and its immediate downstream node. The Unassigned Upstream Label is used by an upstream node when it is not in a position to pick the upstream label on its own. In such a scenario, the upstream node sends a Path message downstream with an Unassigned Upstream Label and requests the downstream node to provide a symmetric label. If the upstream node desires to make the downstream node aware of its limitations with respect to label selection, it MUST specify a list of valid labels via the LABEL_SET object as specified in [RFC3473].
程序的范围仅限于上游节点与其直接下游节点之间的消息交换和处理。当上游节点无法自行拾取上游标签时，上游节点将使用未指定的上游标签。在这种情况下，上游节点向下游发送带有未分配上游标签的路径消息，并请求下游节点提供对称标签。如果上游节点希望让下游节点了解其在标签选择方面的限制，则必须按照[RFC3473]中的规定，通过label_SET对象指定有效标签的列表。
In response, the downstream node picks an appropriate symmetric label and sends it via the LABEL object in the Resv message. The upstream node would then start using this symmetric label for both directions of the LSP. If the downstream node cannot pick the symmetric label, it MUST issue a PathErr message with a "Routing Problem/Unacceptable Label Value" indication. If the upstream node that signals an Unassigned Upstream Label receives a label with the "all-ones" pattern or any other unacceptable label in the LABEL object of the Resv message, it MUST issue a ResvErr message with a "Routing Problem/Unacceptable Label Value" indication.
作为响应，下游节点选择适当的对称标签，并通过Resv消息中的label对象发送该标签。然后，上游节点将开始对LSP的两个方向使用该对称标签。如果下游节点无法拾取对称标签，则必须发出带有“路由问题/不可接受标签值”指示的PathErr消息。如果向未分配的上游标签发送信号的上游节点在Resv消息的标签对象中接收到带有“所有一个”模式的标签或任何其他不可接受的标签，则它必须发出带有“路由问题/不可接受标签值”指示的ResvErr消息。
The upstream node will continue to signal the Unassigned Upstream Label in the Path message even after it receives an appropriate symmetric label in the Resv message. This is done to make sure that the downstream node would pick a different symmetric label if and when it needs to change the label at a later time. If the upstream node receives an unacceptable changed label, then it MUST issue a ResvErr message with a "Routing Problem/Unacceptable Label Value" indication.
即使上游节点在Resv消息中接收到适当的对称标签，它仍将继续在Path消息中向未分配的上游标签发送信号。这样做是为了确保下游节点在以后需要更改标签时会选择不同的对称标签。如果上游节点接收到不可接受的更改标签，则它必须发出带有“路由问题/不可接受标签值”指示的ResvErr消息。
+----------+ +------------+
---| Upstream |--------------------| Downstream |---
+----------+ +------------+
+----------+ +------------+
---| Upstream |--------------------| Downstream |---
+----------+ +------------+
Path
Upstream Label (Unassigned)
Label-Set (L1, L2 ... Ln)
------------------->
Path
Upstream Label (Unassigned)
Label-Set (L1, L2 ... Ln)
------------------->
Resv
Label (Assigned - L2)
<-------------------
Resv
Label (Assigned - L2)
<-------------------
Figure 2: Signaling Sequence
图2：信令序列
If the downstream node is running an implementation that doesn't support the semantics of an Unassigned UPSTREAM LABEL, it will either (a) reject the special label value and generate an error as specified in Section 3.1 of [RFC3473] or (b) accept it and treat it as a valid label.
如果下游节点运行的实现不支持未分配上游标签的语义，它将（a）拒绝特殊标签值并生成[RFC3473]第3.1节中规定的错误，或者（b）接受并将其视为有效标签。
If the behavior that is exhibited is (a), then there are no backwards compatibility concerns. If the behavior that is exhibited is (b), then the downstream node will send a label with the "all-ones" pattern in the LABEL object of the Resv message. In response, the upstream node will issue a ResvErr message with a "Routing Problem/ Unacceptable Label Value" indication.
如果显示的行为是（a），则不存在向后兼容性问题。如果显示的行为是（b），那么下游节点将在Resv消息的label对象中发送一个带有“all-one”模式的标签。作为响应，上游节点将发出带有“路由问题/不可接受标签值”指示的ResvErr消息。
Consider the network topology depicted in Figure 3. Nodes A and B are client IP routers that are connected to an optical Wavelength Division Multiplexing (WDM) transport network. F and I represent WDM nodes. The transponder sits on the router and is directly connected to the add-drop port on a WDM node.
考虑图3中描述的网络拓扑结构。节点A和B是连接到光波分复用（WDM）传输网络的客户端IP路由器。F和I表示WDM节点。转发器位于路由器上，直接连接到WDM节点上的添加/删除端口。
The optical signal originating on "Router A" is tuned to a particular wavelength. On "WDM-Node F", it gets multiplexed with optical signals at other wavelengths. Depending on the implementation of this multiplexing function, it may not be acceptable to have the router send the signal into the optical network unless it is at the appropriate wavelength. In other words, having the router send signals with a wrong wavelength may adversely impact existing optical trails. If the clients do not have full visibility into the optical network, they are not in a position to pick the correct wavelength in advance.
源自“路由器A”的光信号被调谐到特定波长。在“WDM节点F”上，它与其他波长的光信号进行多路复用。根据该多路复用功能的实现，除非信号处于适当的波长，否则可能无法接受路由器将信号发送到光网络。换句话说，让路由器发送错误波长的信号可能会对现有的光路产生不利影响。如果客户端不能完全看到光网络，则无法提前选择正确的波长。
The rest of this section examines how the protocol mechanism proposed in this document allows the optical network to select and communicate the correct wavelength to its clients.
本节的其余部分将研究本文档中提出的协议机制如何允许光网络选择正确的波长并将其传送给客户端。
+---+ /-\ /-\ +---+
| A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
+---+ \-/ \-/ +---+
+---+ /-\ /-\ +---+
| A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
+---+ \-/ \-/ +---+
Path
Upstream Label (Unassigned/0xFFFFFFFF)
--------------------->
-- ~~ -- ~~ -->
Path
-------------------->
Resv
<--------------------
<-- ~~ -- ~~ --
Resv
Label (Assigned)
<---------------------
Path
Upstream Label (Unassigned/0xFFFFFFFF)
--------------------->
-- ~~ -- ~~ -->
Path
-------------------->
Resv
<--------------------
<-- ~~ -- ~~ --
Resv
Label (Assigned)
<---------------------
Figure 3: Initial Setup Sequence
图3：初始设置顺序
Steps:
步骤：
o "Router A" does not have enough information to pick an appropriate client wavelength. It sends a Path message downstream requesting the network to assign an appropriate symmetric label for its use. Since the client wavelength is unknown, the laser is off at the ingress client.
o “路由器A”没有足够的信息来选择适当的客户端波长。它向下游发送路径消息，请求网络为其使用分配适当的对称标签。由于客户端波长未知，激光器在入口客户端关闭。
o The downstream node (Node F) receives the Path message, chooses the appropriate wavelength values, and forwards them in appropriate label fields to the egress client ("Router B").
o 下游节点（节点F）接收路径消息，选择适当的波长值，并在适当的标签字段中将它们转发给出口客户端（“路由器B”）。
o "Router B" receives the Path message, turns the laser ON and tunes it to the appropriate wavelength (received in the UPSTREAM_LABEL/ LABEL_SET of the Path) and sends a Resv message upstream.
o “路由器B”接收路径信息，打开激光器并将其调谐到适当的波长（在路径的上游标签/标签集中接收），并向上游发送Resv消息。
o The Resv message received by the ingress client carries a valid symmetric label in the LABEL object. "Router A" turns on the laser and tunes it to the wavelength specified in the network assigned symmetric LABEL.
o ingress客户端接收的Resv消息在label对象中携带有效的对称标签。“路由器A”打开激光器并将其调谐到网络指定对称标签中指定的波长。
For cases where the egress-node relies on RSVP signaling to determine exactly when to start using the LSP, implementations may choose to integrate the above sequence with any of the existing graceful setup procedures:
对于出口节点依赖RSVP信令来确定何时开始使用LSP的情况，实现可以选择将上述序列与任何现有的优雅设置过程集成：
o "ResvConf" setup procedure ([RFC2205])
o “ResvConf”设置程序（[RFC2205]）
o Two-step "ADMIN STATUS" based setup procedure ("A" bit set in the first step; "A" bit cleared when the LSP is ready for use) ([RFC3473])
o 基于两步“管理状态”的设置程序（“第一步中设置的”位；“LSP准备好使用时清除的”位）（[RFC3473]）
After the LSP is set up, the network may decide to change the wavelength for the given LSP. This could be for a variety of reasons including policy reasons, restoration within the core, preemption, etc.
在LSP建立之后，网络可以决定改变给定LSP的波长。这可能有多种原因，包括政策原因、核心内恢复、抢占等。
In such a scenario, if the ingress client receives a changed label via the LABEL object in a modified Resv message, it retunes the laser at the ingress to the new wavelength. Similarly, if the egress client receives a changed label via UPSTREAM_LABEL/LABEL_SET in a modified Path message, it retunes the laser at the egress to the new wavelength.
在这种情况下，如果入口客户端通过修改后的Resv消息中的label对象接收到更改后的标签，则其将入口处的激光器重新调谐到新波长。类似地，如果出口客户端通过修改路径消息中的上游标签/标签集接收到更改的标签，则其将出口处的激光器重新调谐到新波长。
IANA maintains the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry. IANA has added a new subregistry titled "Special Purpose Generalized Label Values". New values are assigned according to Standards Action [RFC8126].
IANA维护“通用多协议标签交换（GMPLS）信令参数”注册表。IANA增加了一个名为“特殊用途通用标签值”的新分区。根据标准行动[RFC8126]分配新值。
Special Purpose Generalized Label Values
特殊用途通用标签值
Pattern/ Label Name Applicable Reference
Value Objects
-------- ---------------- -------------- ----------
all-ones Unassigned UPSTREAM_LABEL [RFC8359]
Upstream Label
Pattern/ Label Name Applicable Reference
Value Objects
-------- ---------------- -------------- ----------
all-ones Unassigned UPSTREAM_LABEL [RFC8359]
Upstream Label
This document defines a special label value to be carried in the UPSTREAM_LABEL object of a Path message. This special label value is used to enable the function of requesting network assignment of an upstream label. The changes proposed in this document pertain to the semantics of a specific field in an existing RSVP object and the
本文档定义了一个特殊的标签值，该值将携带在路径消息的上游标签对象中。此特殊标签值用于启用请求网络分配上游标签的功能。本文档中提出的更改与现有RSVP对象和
corresponding procedures. Thus, there are no new security implications raised by this document and the security considerations discussed by [RFC3473] still apply.
相应的程序。因此，本文件没有提出新的安全含义，[RFC3473]讨论的安全注意事项仍然适用。
For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920].
有关MPLS和GMPLS相关安全问题的一般性讨论，请参阅MPLS/GMPLS安全框架[RFC5920]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源保留协议（RSVP）——版本1功能规范”，RFC 2205，DOI 10.17487/RFC2205，1997年9月<https://www.rfc-editor.org/info/rfc2205>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <https://www.rfc-editor.org/info/rfc3471>.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，DOI 10.17487/RFC3471，2003年1月<https://www.rfc-editor.org/info/rfc3471>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<https://www.rfc-editor.org/info/rfc3473>.
[RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 6205, DOI 10.17487/RFC6205, March 2011, <https://www.rfc-editor.org/info/rfc6205>.
[RFC6205]Otani，T.，Ed.和D.Li，Ed.，“Lambda交换机功能（LSC）标签交换路由器的通用标签”，RFC 6205，DOI 10.17487/RFC6205，2011年3月<https://www.rfc-editor.org/info/rfc6205>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<https://www.rfc-editor.org/info/rfc5920>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
Acknowledgements
致谢
The authors would like to thank Adrian Farrel and Chris Bowers for their inputs.
作者要感谢Adrian Farrel和Chris Bowers的投入。
Contributors
贡献者
John Drake Juniper Networks Email: jdrake@juniper.net
John Drake Juniper Networks电子邮件：jdrake@juniper.net
Gert Grammel Juniper Networks Email: ggrammel@juniper.net
Gert Grammel Juniper Networks电子邮件：ggrammel@juniper.net
Pawel Brzozowski ADVA Optical Networking Email: pbrzozowski@advaoptical.com
Pawel Brzowski ADVA光纤网络电子邮件：pbrzozowski@advaoptical.com
Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com
Zafar Ali Cisco Systems，Inc.电子邮件：zali@cisco.com
Authors' Addresses
作者地址
Xian Zhang (editor) Huawei Technologies
张贤（编辑）华为技术
Email: zhang.xian@huawei.com
Email: zhang.xian@huawei.com
Vishnu Pavan Beeram (editor) Juniper Networks
Vishnu Pavan Beeram（编辑）Juniper Networks
Email: vbeeram@juniper.net
Email: vbeeram@juniper.net
Igor Bryskin Huawei Technologies
伊戈尔·布莱斯金华为技术有限公司
Email: igor.bryskin@huawei.com
Email: igor.bryskin@huawei.com
Daniele Ceccarelli Ericsson
丹尼尔·塞卡雷利·爱立信
Email: daniele.ceccarelli@ericsson.com
Email: daniele.ceccarelli@ericsson.com
Oscar Gonzalez de Dios Telefonica
奥斯卡·冈萨雷斯
Email: ogondio@tid.es
Email: ogondio@tid.es