Network Working Group K. Shiomoto
Request for Comments: 4990 NTT
Category: Informational R. Papneja
Isocore
R. Rabbat
Google
September 2007
Network Working Group K. Shiomoto
Request for Comments: 4990 NTT
Category: Informational R. Papneja
Isocore
R. Rabbat
Google
September 2007
Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks
通用多协议标签交换（GMPLS）网络中地址的使用
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment.
本文件澄清了通用多协议标签交换（GMPLS）网络中地址的使用。其目的是促进支持GMPLS的标签交换路由器（LSR）的互通。本文档基于在实施、互操作性测试和部署中获得的经验。
The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules.
本文档描述了如何解释GMPLS协议中的地址和标识符字段，以及如何为特定的控制平面使用模型选择要在这些字段中设置的地址。还讨论了如何在MPLS和GMPLS流量工程（TE）管理信息库（MIB）模块中处理IPv6源和目标。
This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs.
本文件未定义新的程序或流程。每当本文件提出要求声明或建议时，均取自参考RFC中的规范性文本。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Support of Numbered and Unnumbered Links ........................5
4. Numbered Addressing .............................................6
4.1. Numbered Addresses in IGPs .................................6
4.1.1. Router Address and TE Router ID .....................6
4.1.2. Link ID and Remote Router ID ........................6
4.1.3. Local Interface IP Address ..........................7
4.1.4. Remote Interface IP Address .........................7
4.2. Numbered Addresses in RSVP-TE ..............................7
4.2.1. IP Tunnel End Point Address in Session Object .......7
4.2.2. IP Tunnel Sender Address in Sender Template Object ..8
4.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces .......8
4.2.4. Explicit Route Object (ERO) .........................9
4.2.5. Record Route Object (RRO) ...........................9
4.2.6. IP Packet Source Address ............................9
4.2.7. IP Packet Destination Address .......................9
5. Unnumbered Addressing ..........................................10
5.1. Unnumbered Addresses in IGPs ..............................10
5.1.1. Link Local/Remote Identifiers in OSPF-TE ...........10
5.1.2. Link Local/Remote Identifiers in IS-IS-TE ..........11
5.2. Unnumbered Addresses in RSVP-TE ...........................11
5.2.1. Sender and End Point Addresses .....................11
5.2.2. IF_ID RSVP_HOP Object for Unnumbered Interfaces ....11
5.2.3. Explicit Route Object (ERO) ........................11
5.2.4. Record Route Object (RRO) ..........................11
5.2.5. LSP_Tunnel Interface ID Object .....................12
5.2.6. IP Packet Addresses ................................12
6. RSVP-TE Message Content ........................................12
6.1. ERO and RRO Addresses .....................................12
6.1.1. Strict Subobject in ERO ............................12
6.1.2. Loose Subobject in ERO .............................14
6.1.3. RRO ................................................14
6.1.4. Label Record Subobject in RRO ......................15
6.2. Component Link Identification .............................15
6.3. Forwarding Destination of Path Messages with ERO ..........16
7. Topics Related to the GMPLS Control Plane ......................16
7.1. Control Channel Separation ................................16
7.1.1. Native and Tunneled Control Plane ..................16
7.2. Separation of Control and Data Plane Traffic ..............17
8. Addresses in the MPLS and GMPLS TE MIB Modules .................17
8.1. Handling IPv6 Source and Destination Addresses ............18
8.1.1. Identifying LSRs ...................................18
8.1.2. Configuring GMPLS Tunnels ..........................18
8.2. Managing and Monitoring Tunnel Table Entries ..............19
9. Security Considerations ........................................19
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Support of Numbered and Unnumbered Links ........................5
4. Numbered Addressing .............................................6
4.1. Numbered Addresses in IGPs .................................6
4.1.1. Router Address and TE Router ID .....................6
4.1.2. Link ID and Remote Router ID ........................6
4.1.3. Local Interface IP Address ..........................7
4.1.4. Remote Interface IP Address .........................7
4.2. Numbered Addresses in RSVP-TE ..............................7
4.2.1. IP Tunnel End Point Address in Session Object .......7
4.2.2. IP Tunnel Sender Address in Sender Template Object ..8
4.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces .......8
4.2.4. Explicit Route Object (ERO) .........................9
4.2.5. Record Route Object (RRO) ...........................9
4.2.6. IP Packet Source Address ............................9
4.2.7. IP Packet Destination Address .......................9
5. Unnumbered Addressing ..........................................10
5.1. Unnumbered Addresses in IGPs ..............................10
5.1.1. Link Local/Remote Identifiers in OSPF-TE ...........10
5.1.2. Link Local/Remote Identifiers in IS-IS-TE ..........11
5.2. Unnumbered Addresses in RSVP-TE ...........................11
5.2.1. Sender and End Point Addresses .....................11
5.2.2. IF_ID RSVP_HOP Object for Unnumbered Interfaces ....11
5.2.3. Explicit Route Object (ERO) ........................11
5.2.4. Record Route Object (RRO) ..........................11
5.2.5. LSP_Tunnel Interface ID Object .....................12
5.2.6. IP Packet Addresses ................................12
6. RSVP-TE Message Content ........................................12
6.1. ERO and RRO Addresses .....................................12
6.1.1. Strict Subobject in ERO ............................12
6.1.2. Loose Subobject in ERO .............................14
6.1.3. RRO ................................................14
6.1.4. Label Record Subobject in RRO ......................15
6.2. Component Link Identification .............................15
6.3. Forwarding Destination of Path Messages with ERO ..........16
7. Topics Related to the GMPLS Control Plane ......................16
7.1. Control Channel Separation ................................16
7.1.1. Native and Tunneled Control Plane ..................16
7.2. Separation of Control and Data Plane Traffic ..............17
8. Addresses in the MPLS and GMPLS TE MIB Modules .................17
8.1. Handling IPv6 Source and Destination Addresses ............18
8.1.1. Identifying LSRs ...................................18
8.1.2. Configuring GMPLS Tunnels ..........................18
8.2. Managing and Monitoring Tunnel Table Entries ..............19
9. Security Considerations ........................................19
10. Acknowledgments ...............................................20
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................21
10. Acknowledgments ...............................................20
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................21
This informational document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment.
本信息性文件澄清了通用多协议标签交换（GMPLS）[RFC3945]网络中地址的使用。其目的是促进支持GMPLS的标签交换路由器（LSR）的互通。本文档基于在实施、互操作性测试和部署中获得的经验。
The document describes how to interpret address and identifier fields within GMPLS protocols (RSVP-TE [RFC3473], GMPLS OSPF [RFC4203], and GMPLS ISIS [RFC4205]), and how to choose which addresses to set in those fields for specific control plane usage models.
本文件描述了如何解释GMPLS协议（RSVP-TE[RFC3473]、GMPLS OSPF[RFC4203]和GMPLS ISIS[RFC4205]）中的地址和标识符字段，以及如何为特定控制平面使用模型选择在这些字段中设置的地址。
This document does not define new procedures or processes and the protocol specifications listed above should be treated as definitive. Furthermore, where this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. Nothing in this document should be considered normative.
本文件未定义新的程序或流程，上述协议规范应视为最终规范。此外，如果本文件提出了要求声明或建议，则这些要求声明或建议取自参考RFC中的规范性文本。本文件中的任何内容均不应视为规范性内容。
This document also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules [RFC3812], [RFC4802].
本文档还讨论了如何在MPLS和GMPLS流量工程（TE）管理信息库（MIB）模块[RFC3812]、[RFC4802]中处理IPv6源和目标。
As described in [RFC3945], the components of a GMPLS network may be separated into a data plane and a control plane. The control plane may be further split into signaling components and routing components.
如[RFC3945]所述，GMPLS网络的组件可分为数据平面和控制平面。控制平面可进一步分为信令组件和路由组件。
A data plane switch or router is called a data plane entity. It is a node on the data plane topology graph. A data plane resource is a facility available in the data plane, such as a data plane entity (node), data link (edge), or data label (such as a lambda).
数据平面交换机或路由器称为数据平面实体。它是数据平面拓扑图上的一个节点。数据平面资源是数据平面中可用的工具，例如数据平面实体（节点）、数据链路（边缘）或数据标签（例如lambda）。
In the control plane, there are protocol speakers that are software implementations that communicate using signaling or routing protocols. These are control plane entities, and may be physically located separately from the data plane entities that they control. Further, there may be separate routing entities and signaling entities.
在控制平面中，有协议扬声器，它们是使用信令或路由协议进行通信的软件实现。这些是控制平面实体，在物理上可能与它们控制的数据平面实体分开。此外，可以存在单独的路由实体和信令实体。
GMPLS supports a control plane entity that is responsible for one or more data plane entities, and supports the separation of signaling and routing control plane entities. For the purposes of this document, it is assumed that there is a one-to-one correspondence between control plane and data plane entities. That is, each data plane switch has a unique control plane entity responsible for participating in the GMPLS signaling and routing protocols, and that each such control plane presence is responsible for a single data plane switch.
GMPLS支持负责一个或多个数据平面实体的控制平面实体，并支持信令和路由控制平面实体的分离。在本文件中，假设控制平面和数据平面实体之间存在一对一的对应关系。即，每个数据平面交换机具有负责参与GMPLS信令和路由协议的唯一控制平面实体，并且每个这样的控制平面存在负责单个数据平面交换机。
The combination of control plane and data plane entities is referred to as a Label Switching Router (LSR).
控制平面和数据平面实体的组合称为标签交换路由器（LSR）。
Note that the term 'Router ID' is used in two contexts within GMPLS. It may refer to an identifier of a participant in a routing protocol, or it may be an identifier for an LSR that participates in TE routing. These could be considered as the control plane and data plane contexts.
请注意，术语“路由器ID”在GMPLS的两个上下文中使用。它可以是指路由协议中参与者的标识符，也可以是参与TE路由的LSR的标识符。这些可以被视为控制平面和数据平面上下文。
In this document, the contexts are distinguished by the following definitions.
在本文件中，通过以下定义区分上下文。
o Loopback address: A loopback address is a stable IP address of the advertising router that is always reachable if there is any IP connectivity to it [RFC3477], [RFC3630]. Thus, for example, an IPv4 127/24 address is excluded from this definition.
o 环回地址：环回地址是广告路由器的一个稳定IP地址，如果有任何IP连接，则始终可以访问该地址[RFC3477]，[RFC3630]。因此，例如，IPv4 127/24地址不在此定义中。
o TE Router ID: A stable IP address of an LSR that is always reachable in the control plane if there is any IP connectivity to the LSR, e.g., a loopback address. The most important requirement is that the address does not become unusable if an interface on the LSR is down [RFC3477], [RFC3630].
o TE路由器ID：LSR的稳定IP地址，如果存在到LSR的任何IP连接（例如环回地址），则该地址始终可在控制平面中访问。最重要的要求是，如果LSR上的接口关闭[RFC3477]，[RFC3630]，地址不会变得不可用。
o Router ID: The OSPF protocol version 2 [RFC2328] defines the Router ID to be a 32-bit network-unique number assigned to each router running OSPF. IS-IS [RFC1195] includes a similar concept in the System ID. This document describes both concepts as the "Router ID" of the router running the routing protocol. The Router ID is not required to be a reachable IP address, although an operator may set it to a reachable IP address on the same node.
o 路由器ID:OSPF协议版本2[RFC2328]将路由器ID定义为分配给每个运行OSPF的路由器的32位网络唯一编号。IS-IS[RFC1195]在系统ID中包含类似的概念。本文档将这两个概念描述为运行路由协议的路由器的“路由器ID”。路由器ID不需要是可访问的IP地址，尽管操作员可以将其设置为同一节点上的可访问IP地址。
o TE link: "A TE link is a representation in the IS-IS/OSPF Link State advertisements and in the link state database of certain physical resources, and their properties, between two GMPLS nodes" [RFC3945].
o TE链路：“TE链路是两个GMPLS节点之间is-is/OSPF链路状态播发和某些物理资源及其属性的链路状态数据库中的表示”[RFC3945]。
o Data plane node: A vertex on the TE graph. It is a data plane switch or router. Data plane nodes are connected by TE links that
o 数据平面节点：TE图上的顶点。它是一个数据平面交换机或路由器。数据平面节点由TE链接连接，该链接
are constructed from physical data links. A data plane node is controlled through some combination of management and control plane actions. A data plane node may be under full or partial control of a control plane node.
由物理数据链接构造。数据平面节点通过管理和控制平面动作的某种组合进行控制。数据平面节点可以在控制平面节点的完全或部分控制下。
o Control plane node: A GMPLS protocol speaker. It may be part of a data plane switch or may be a separate computer. Control plane nodes are connected by control channels that are logical connection-less or connection-oriented paths in the control plane. A control plane node is responsible for controlling zero, one, or more data plane nodes.
o 控制平面节点：GMPLS协议扬声器。它可以是数据平面交换机的一部分，也可以是单独的计算机。控制平面节点由控制平面中逻辑连接较少或面向连接的路径的控制通道连接。控制平面节点负责控制零个、一个或多个数据平面节点。
o Interface ID: The Interface ID is defined in [RFC3477] and in Section 9.1 of [RFC3471].
o 接口ID:[RFC3477]和[RFC3471]第9.1节中定义了接口ID。
o Data Plane Address: This document refers to a data plane address in the context of GMPLS. It does not refer to addresses such as E.164 SAPI in Synchronous Digital Hierarchy (SDH).
o 数据平面地址：本文档是指GMPLS上下文中的数据平面地址。它不涉及同步数字体系（SDH）中的地址，如E.164 SAPI。
o Control Plane Address: An address used to identify a control plane resource including, and restricted to, control plane nodes and control channels.
o 控制平面地址：用于标识控制平面资源的地址，包括并限于控制平面节点和控制通道。
o IP Time to Live (TTL): The IPv4 TTL field or the IPv6 Hop Limit field, whichever is applicable.
o IP生存时间（TTL）：IPv4 TTL字段或IPv6跃点限制字段，以适用者为准。
o TED: Traffic Engineering Database.
o 交通工程数据库。
o LSR: Label Switching Router.
o 标签交换路由器。
o FA: Forwarding Adjacency.
o 前向邻接。
o IGP: Interior Gateway Protocol.
o IGP：内部网关协议。
The links in the control and data planes may be numbered or unnumbered [RFC3945]. That is, their end points may be assigned IP addresses, or may be assigned link IDs specific to the control plane or data plane entity at the end of the link. Implementations may decide to support numbered and/or unnumbered addressing.
控制平面和数据平面中的链路可以编号或不编号[RFC3945]。也就是说，它们的端点可以被分配IP地址，或者可以被分配特定于链路末端的控制平面或数据平面实体的链路id。实现可能决定支持编号和/或非编号寻址。
The argument for numbered addressing is that it simplifies troubleshooting. The argument for unnumbered addressing is to save on IP address resources.
编号寻址的理由是它简化了故障排除。无编号寻址的理由是节省IP地址资源。
An LSR may choose to only support its own links being configured as numbered, or may only support its own links being configured as
LSR可以选择仅支持将其自身的链路配置为编号，或者仅支持将其自身的链路配置为编号
unnumbered. But an LSR must not restrict the choice of other LSRs to use numbered or unnumbered links since this might lead to interoperablity issues. Thus, a node should be able to accept and process link advertisements containing both numbered and unnumbered addresses.
没有编号。但LSR不得限制其他LSR使用编号或非编号链接的选择，因为这可能会导致互操作性问题。因此，节点应该能够接受和处理包含编号和未编号地址的链接播发。
Numbered and unnumbered addressing is described in Sections 4 and 5 of this document, respectively.
本文件第4节和第5节分别描述了编号地址和未编号地址。
When numbered addressing is used, addresses are assigned to each node and link in both the control and data planes of the GMPLS network.
使用编号寻址时，地址分配给GMPLS网络控制平面和数据平面中的每个节点和链路。
A numbered link is identified by a network-unique identifier (e.g., an IP address).
编号链路由网络唯一标识符（例如，IP地址）标识。
In this section, we discuss numbered addressing using two Interior Gateway Protocols (IGPs) that have extensions defined for GMPLS: OSPF-TE and IS-IS-TE. The routing enhancements for GMPLS are defined in [RFC3630], [RFC3784], [RFC4202], [RFC4203], and [RFC4205].
在本节中，我们将讨论使用两个内部网关协议（IGP）进行编号寻址，这两个协议都为GMPLS定义了扩展：OSPF-TE和IS-IS-TE。GMPLS的路由增强在[RFC3630]、[RFC3784]、[RFC4202]、[RFC4203]和[RFC4205]中定义。
The IGPs define a field called the "Router Address". It is used to advertise the TE Router ID.
IGP定义了一个称为“路由器地址”的字段。它用于公布TE路由器ID。
The Router Address is advertised in OSPF-TE using the Router Address TLV structure of the TE Link State Advertisement (LSA) [RFC3630].
使用TE链路状态通告（LSA）[RFC3630]的路由器地址TLV结构在OSPF-TE中通告路由器地址。
In IS-IS-TE, this is referred to as the Traffic Engineering router ID, and is carried in the advertised Traffic Engineering router ID TLV [RFC3784].
在IS-IS-TE中，这被称为流量工程路由器ID，并在公布的流量工程路由器ID TLV[RFC3784]中携带。
In OSPF-TE [RFC3630], the Router ID of the remote end of a TE link is carried in the Link ID sub-TLV. This applies for point-to-point TE links only; multi-access links are for further study.
在OSPF-TE[RFC3630]中，TE链路的远端的路由器ID携带在链路ID子TLV中。这仅适用于点对点TE链路；多址链路有待进一步研究。
In IS-IS-TE [RFC3784], the Extended IS Reachability TLV is used to carry the System ID. This corresponds to the Router ID as described in Section 2.
在IS-IS-TE[RFC3784]中，扩展IS可达性TLV用于携带系统ID。这与第2节中描述的路由器ID相对应。
The Local Interface IP Address is advertised in:
本地接口IP地址在以下位置播发：
o the Local Interface IP Address sub-TLV in OSPF-TE [RFC3630]
o OSPF-TE[RFC3630]中的本地接口IP地址子TLV
o the IPv4 Interface Address sub-TLV in IS-IS-TE [RFC3784].
o IS-IS-TE[RFC3784]中的IPv4接口地址子TLV。
This is the ID of the local end of the numbered TE link. It must be a network-unique number (since this section is devoted to numbered addressing), but it does not need to be a routable address in the control plane.
这是编号TE链路的本地端的ID。它必须是网络唯一编号（因为本节专门讨论编号寻址），但不需要是控制平面中的可路由地址。
The Remote Interface IP Address is advertised in:
远程接口IP地址在以下位置播发：
o the Remote Interface IP Address sub-TLV in OSPF-TE [RFC3630]
o OSPF-TE[RFC3630]中的远程接口IP地址子TLV
o the IPv4 Neighbor Address sub-TLV in IS-IS-TE [RFC3784].
o IS-IS-TE[RFC3784]中的IPv4邻居地址子TLV。
This is the ID of the remote end of the numbered TE link. It must be a network-unique number (since this section is devoted to numbered addressing), but it does not need to be a routable address in the control plane
这是编号TE链路的远程端的ID。它必须是网络唯一编号（因为本节专门讨论编号寻址），但不需要是控制平面中的可路由地址
The following subsections describe the use of addresses in the GMPLS signaling protocol [RFC3209], [RFC3473].
以下小节描述了GMPLS信令协议[RFC3209]、[RFC3473]中地址的使用。
The IP tunnel end point address of the Session Object [RFC3209] is either an IPv4 or IPv6 address.
会话对象[RFC3209]的IP隧道端点地址是IPv4或IPv6地址。
The Session Object is invariant for all messages relating to the same Label Switched Path (LSP). The initiator of a Path message sets the IP tunnel end point address in the Session Object to one of:
会话对象对于与同一标签交换路径（LSP）相关的所有消息都是不变的。路径消息的发起人将会话对象中的IP隧道端点地址设置为以下地址之一：
o The TE Router ID of the egress since the TE Router ID is routable and uniquely identifies the egress node.
o 出口的TE路由器ID，因为TE路由器ID是可路由的，并且唯一地标识出口节点。
o The destination data plane address to precisely identify the interface that should be used for the final hop of the LSP. That is, the Remote Interface IP Address of the final TE link, if the ingress knows that address.
o 目标数据平面地址，用于精确标识应用于LSP最后一跳的接口。即，最终TE链路的远程接口IP地址，如果入口知道该地址。
The IP tunnel end point address in the Session Object is not required to be routable in the control plane, but should be present in the TED.
会话对象中的IP隧道端点地址不需要在控制平面中可路由，但应该存在于TED中。
The IP tunnel sender address of the Sender Template Object [RFC3209] is either an IPv4 or IPv6 address.
发送方模板对象[RFC3209]的IP隧道发送方地址是IPv4或IPv6地址。
When an LSP is being set up to support an IPv4-numbered FA, [RFC4206] recommends that the IP tunnel sender address be set to the head-end address of the TE link that is to be created so that the tail-end address can be inferred as the /31 partner address.
当LSP被设置为支持IPv4编号的FA时，[RFC4206]建议将IP隧道发送方地址设置为要创建的TE链路的前端地址，以便可以将后端地址推断为/31伙伴地址。
When an LSP is being set up that will not be used to form an FA, the IP tunnel sender address in the Sender Template Object may be set to one of:
当设置的LSP不用于形成FA时，发送方模板对象中的IP隧道发送方地址可以设置为以下地址之一：
o The TE Router ID of the ingress LSR since the TE Router ID is a unique, routable ID per node.
o 入口LSR的TE路由器ID，因为TE路由器ID是每个节点唯一的可路由ID。
o The sender data plane address (i.e., the Local Interface IP Address).
o 发送方数据平面地址（即本地接口IP地址）。
There are two addresses used in the IF_ID RSVP_HOP object.
IF_ID RSVP_HOP对象中使用了两个地址。
1. The IPv4/IPv6 Next/Previous Hop Address [RFC3473]
1. IPv4/IPv6下一个/上一个跃点地址[RFC3473]
When used in a Path or Resv messages, this address specifies the IP reachable address of the control plane interface used to send the messages, or the TE Router ID of the node that sends the message. That is, it is a routable control plane address of the sender of the message and can be used to send return messages. Note that because of data plane / control plane separation (see Section 7.1) and data plane robustness in the face of control plane faults, it may be advisable to use the TE Router ID since it is a more stable address.
在Path或Resv消息中使用时，此地址指定用于发送消息的控制平面接口的IP可访问地址，或指定发送消息的节点的TE路由器ID。也就是说，它是消息发送方的可路由控制平面地址，可用于发送返回消息。注意，由于数据平面/控制平面分离（见第7.1节）以及面对控制平面故障时的数据平面鲁棒性，建议使用TE路由器ID，因为它是一个更稳定的地址。
2. The IPv4/IPv6 address in the Value Field of the Interface_ID TLV [RFC3471]
2. 接口ID TLV[RFC3471]的值字段中的IPv4/IPv6地址
This address identifies the data channel associated with the signaling message. In all cases, the data channel is indicated by the use of the data plane local interface address at the upstream LSR, that is, at the sender of the Path message.
该地址标识与信令消息相关联的数据信道。在所有情况下，通过在上游LSR处，即在路径消息的发送方处使用数据平面本地接口地址来指示数据信道。
See Section 6.2 for a description of these fields when bundled links are used.
有关使用捆绑链接时这些字段的说明，请参见第6.2节。
The IPv4/IPv6 address in the ERO provides a data-plane identifier of an abstract node, TE node, or TE link to be part of the signaled LSP.
ERO中的IPv4/IPv6地址提供作为信号LSP一部分的抽象节点、TE节点或TE链路的数据平面标识符。
See Section 6 for a description of the use of addresses in the ERO.
有关ERO中地址使用的说明，请参见第6节。
The IPv4/IPv6 address in the RRO provides a data-plane identifier of either a TE node or a TE link that is part of an LSP that has been established or is being established.
RRO中的IPv4/IPv6地址提供作为已建立或正在建立的LSP一部分的TE节点或TE链路的数据平面标识符。
See Section 6 for a description of the use of addresses in the RRO.
有关RRO中地址使用的说明，请参见第6节。
GMPLS signaling messages are encapsulated in IP. The IP packet source address is either an IPv4 or IPv6 address and must be a reachable control plane address of the node sending the TE message. In order to provide control plane robustness, a stable IPv4 or IPv6 control plane address (for example, the TE Router ID) can be used.
GMPLS信令消息封装在IP中。IP数据包源地址是IPv4或IPv6地址，并且必须是发送TE消息的节点的可访问控制平面地址。为了提供控制平面鲁棒性，可以使用稳定的IPv4或IPv6控制平面地址（例如，TE路由器ID）。
Some implementations may use the IP source address of a received IP packet containing a Path message as the destination IP address of a packet containing the corresponding Resv message (see Section 4.2.7). Using a stable IPv4 or IPv6 address in the IP packet containing the Path message supports this situation robustly when one of the control plane interfaces is down.
一些实现可以使用包含路径消息的接收到的IP分组的IP源地址作为包含相应Resv消息的分组的目的地IP地址（参见第4.2.7节）。在包含Path消息的IP数据包中使用稳定的IPv4或IPv6地址，当其中一个控制平面接口关闭时，将有力地支持这种情况。
The IP packet destination address for an IP packet carrying a GMPLS signaling message is either an IPv4 or IPv6 address, and must be reachable in the control plane if the message is to be delivered. It must be an address of the intended next-hop recipient of the message. That is, unlike RSVP, the IP packet is not addressed to the ultimate destination (the egress).
承载GMPLS信令消息的IP数据包的IP数据包目的地地址为IPv4或IPv6地址，如果要传递消息，则必须在控制平面中可以访问该地址。它必须是消息的预期下一跳收件人的地址。也就是说，与RSVP不同，IP数据包不寻址到最终目的地（出口）。
For a Path message, a stable IPv4 or IPv6 address of the next-hop node may be used. This may be the TE Router ID of the next-hop node. A suitable address may be determined by examining the TE advertisements for the TE link that will form the next-hop data link.
对于路径消息，可以使用下一跳节点的稳定IPv4或IPv6地址。这可能是下一跳节点的TE路由器ID。可以通过检查将形成下一跳数据链路的TE链路的TE广告来确定合适的地址。
A Resv message is sent to the previous-hop node. The IPv4 or IPv6 destination of an IP packet carrying a Resv message may be any of the following:
将向上一个跃点节点发送Resv消息。承载Resv消息的IP数据包的IPv4或IPv6目标可以是以下任意一种：
o The IPv4 or IPv6 source address of the received IP packet containing the Path message.
o 接收到的包含路径消息的IP数据包的IPv4或IPv6源地址。
o A stable IPv4 or IPv6 address of the previous node found by examining the TE advertisements for the upstream data plane interface.
o 通过检查上游数据平面接口的TE播发找到的前一个节点的稳定IPv4或IPv6地址。
o The value in the received in the Next/Previous Hop Address field of the RSVP_HOP (PHOP) Object [RFC2205].
o RSVP_-Hop（PHOP）对象[RFC2205]的下一跳/上一跳地址字段中接收的值。
An unnumbered address is the combination of a network-unique node identifier and a node-unique interface identifier.
无编号地址是网络唯一节点标识符和节点唯一接口标识符的组合。
An unnumbered link is identified by the combination of the TE Router ID that is a reachable address in the control plane and a node-unique Interface ID [RFC3477].
通过TE路由器ID（控制平面中的可到达地址）和节点唯一接口ID[RFC3477]的组合来标识未编号的链路。
In this section, we consider unnumbered address advertisement using OSPF-TE and IS-IS-TE.
在本节中，我们考虑使用OSPF-TE和IS-IS-TE的无编号地址广告。
Link Local and Link Remote Identifiers are carried in OSPF using a single sub-TLV of the Link TLV [RFC4203]. They advertise the IDs of an unnumbered TE link's local and remote ends, respectively. Link Local/Remote Identifiers are numbers unique within the scopes of the advertising LSR and the LSR managing the remote end of the link respectively [RFC3477].
链路本地和链路远程标识符使用链路TLV的单个子TLV在OSPF中承载[RFC4203]。它们分别公布未编号TE链接的本地端和远程端的ID。链路本地/远程标识符是分别管理链路远程端的播发LSR和LSR范围内唯一的编号[RFC3477]。
Note that these numbers are not network-unique and therefore cannot be used as TE link end identifiers on their own. An unnumbered TE link end network-wide identifier is comprised of two elements as defined in [RFC3477]:
请注意，这些数字不是网络唯一的，因此不能单独用作TE链路端标识符。未编号的TE链路端网络范围标识符由[RFC3477]中定义的两个元素组成：
- A TE Router ID that is associated with the link local end
- 与链路本地端关联的TE路由器ID
- The link local identifier.
- 链接本地标识符。
The Link Local and Link Remote Identifiers are carried in IS-IS using a single sub-TLV of the Extended IS Reachability TLV. Link identifiers are exchanged in the Extended Local Circuit ID field of the "Point-to-Point Three-Way Adjacency" IS-IS Option type [RFC4205].
链路本地和链路远程标识符使用扩展IS可达性TLV的单个子TLV携带在IS-IS中。链路标识符在“点对点三向邻接”IS-IS选项类型[RFC4205]的扩展本地电路ID字段中交换。
The same discussion of unique identification applies here as in Section 5.1.1.
与第5.1.1节中相同的唯一标识讨论适用于此处。
We consider in this section the interface ID fields of objects used in RSVP-TE in the case of unnumbered addressing.
在本节中，我们考虑在无编号寻址情况下在RSVP TE中使用的对象的接口ID字段。
The IP Tunnel End Point Address in the RSVP Session Object and the IP Tunnel Sender Address in the RSVP Sender Template Object cannot use unnumbered addresses [RFC3209], [RFC3473].
RSVP会话对象中的IP隧道端点地址和RSVP发送方模板对象中的IP隧道发送方地址不能使用未编号的地址[RFC3209]、[RFC3473]。
The interface ID field in the IF_INDEX TLV specifies the interface of the data channel for an unnumbered interface.
IF_索引TLV中的接口ID字段为未编号的接口指定数据通道的接口。
In both Path and Resv messages, the value of the interface ID in the IF_INDEX TLV specifies the local interface ID of the associated data channel at the upstream node (the node sending the Path message and receiving the Resv message).
在Path和Resv消息中，IF_索引TLV中的接口ID值指定上游节点（发送Path消息并接收Resv消息的节点）处关联数据通道的本地接口ID。
See Section 6.2 for a description of the use bundled links.
有关使用捆绑链接的说明，请参见第6.2节。
The ERO may use an unnumbered identifier of a TE link to be part of the signaled LSP.
ERO可以使用TE链路的未编号标识符作为信号LSP的一部分。
See Section 6 for a description of the use of addresses in the ERO.
有关ERO中地址使用的说明，请参见第6节。
The RRO records the data-plane identifiers of TE nodes and TE links that are part of an LSP that has been established or is being established. TE links may be identified using unnumbered addressing.
RRO记录作为已建立或正在建立的LSP一部分的TE节点和TE链路的数据平面标识符。TE链路可以使用无编号的寻址进行标识。
See Section 6 for a description of the use of addresses in the RRO.
有关RRO中地址使用的说明，请参见第6节。
The LSP_TUNNEL_INTERFACE_ID Object includes the LSR's Router ID and Interface ID, as described in [RFC3477], to specify an unnumbered Forward Adjacency Interface ID. The Router ID of the GMPLS-capable LSR must be set to the TE Router ID.
LSP_TUNNEL_INTERFACE_ID对象包括LSR的路由器ID和接口ID，如[RFC3477]中所述，用于指定未编号的前向邻接接口ID。支持GMPLS的LSR的路由器ID必须设置为TE路由器ID。
IP packets can only be addressed to numbered addresses.
IP数据包只能寻址到编号的地址。
This section examines the use of addresses in RSVP EROs and RROs, the identification of component links, and forwarding addresses for RSVP messages.
本节检查RSVP ERO和RRO中地址的使用、组件链接的标识以及RSVP消息的转发地址。
EROs may contain strict or loose hop subobjects. These are discussed separately below. A separate section describes the use of addresses in the RRO.
ERO可能包含严格或松散的跃点子对象。下文将分别讨论这些问题。另一节介绍了RRO中地址的使用。
Implementations making limited assumptions about the content of an ERO or RRO when processing a received RSVP message may cause or experience interoperability issues. Therefore, implementations that want to ensure full interoperability need to support the receipt for processing of all ERO and RRO options applicable to their hardware capabilities.
在处理接收到的RSVP消息时，对ERO或RRO的内容进行有限的假设可能会导致或遇到互操作性问题。因此，想要确保完全互操作性的实现需要支持接收所有适用于其硬件功能的ERO和RRO选项。
Note that the phrase "receipt for processing" is intended to indicate that an LSR is not expected to look ahead in an ERO or process any subobjects that do not refer to the LSR itself or to the next hop in the ERO. An LSR is not generally expected to process an RRO except by adding its own information.
请注意，短语“处理接收”旨在表示预期LSR不会在ERO中展望未来或处理不涉及LSR本身或ERO中下一跳的任何子对象。LSR通常不会处理RRO，除非添加自己的信息。
Note also that implementations do not need to support the ERO options containing Component Link IDs if they do not support link bundling [RFC4201].
还请注意，如果不支持链接绑定，则实现不需要支持包含组件链接ID的ERO选项[RFC4201]。
ERO processing at region boundaries is described in [RFC4206].
[RFC4206]中描述了区域边界的ERO处理。
Depending on the level of control required, a subobject in the ERO includes an address that may specify an abstract node (i.e., a group of nodes), a simple abstract node (i.e., a specific node), or a specific interface of a TE link in the data plane [RFC3209].
根据所需的控制级别，ERO中的子对象包括一个地址，该地址可指定数据平面中TE链路的抽象节点（即，一组节点）、简单抽象节点（即，特定节点）或特定接口[RFC3209]。
A hop may be flagged as strict (meaning that the LSP must go directly to the identified next hop without any intervening nodes), or loose.
跳可以被标记为严格（意味着LSP必须在没有任何中间节点的情况下直接转到已识别的下一跳）或松散。
If a hop is strict, the ERO may contain any of the following.
如果跃点是严格的，ERO可能包含以下任何内容。
1. Address prefix or AS number specifying a group of nodes.
1. 指定一组节点的地址前缀或AS编号。
2. TE Router ID identifying a specific node.
2. 标识特定节点的路由器ID。
3. Link ID identifying an incoming TE link.
3. 标识传入TE链路的链路ID。
4. Link ID identifying an outgoing TE link, optionally followed by a Component Interface ID and/or one or two Labels.
4. 标识传出TE链接的链接ID，可选后跟组件接口ID和/或一个或两个标签。
5. Link ID identifying an incoming TE link, followed by a Link ID identifying an outgoing TE link, optionally followed by a Component Interface ID and/or one or two Labels.
5. 标识传入TE链路的链路ID，后跟标识传出TE链路的链路ID，可选地后跟组件接口ID和/或一个或两个标签。
6. TE Router ID identifying a specific node, followed by a Link ID identifying an outgoing TE link, optionally followed by a Component Interface ID and/or one or two Labels.
6. 标识特定节点的TE路由器ID，后跟标识传出TE链路的链路ID，可选地后跟组件接口ID和/或一个或两个标签。
7. Link ID identifying an incoming TE link, followed by a TE Router ID identifying a specific node, followed by a Link ID identifying an outgoing TE link, optionally followed by Component Interface ID and/or one or two Labels.
7. 标识传入TE链路的链路ID，后跟标识特定节点的TE路由器ID，后跟标识传出TE链路的链路ID，可选地后跟组件接口ID和/或一个或两个标签。
The label value that identifies a single unidirectional resource between two nodes may be different from the perspective of upstream and downstream nodes. This is typically the case in fiber switching because the label value is a number indicating the port/fiber. It may also be the case for lambda switching, because the label value is an index for the lambda in the hardware and may not be a globally defined value such as the wavelength in nanometers.
从上游和下游节点的角度来看，标识两个节点之间单个单向资源的标签值可能不同。这通常是光纤交换中的情况，因为标签值是指示端口/光纤的数字。lambda切换也可能是这种情况，因为标签值是硬件中lambda的索引，并且可能不是全局定义的值，例如以纳米为单位的波长。
The value of a label in any RSVP-TE object indicates the value from the perspective of the sender of the object/TLV [RFC3471]. Therefore, any label in an ERO is given using the upstream node's identification of the resource.
任何RSVP-TE对象中的标签值从对象/TLV的发送方的角度指示该值[RFC3471]。因此，ERO中的任何标签都是使用上游节点的资源标识给出的。
There are two differences between Loose and Strict subobjects.
松散子对象和严格子对象之间有两个区别。
o A subobject marked as a loose hop in an ERO must not be followed by a subobject indicating a label value [RFC3473].
o ERO中标记为松散跃点的子对象后面不得跟有指示标签值的子对象[RFC3473]。
o A subobject marked as a loose hop in an ERO should never include an identifier (i.e., address or ID) of the outgoing interface.
o ERO中标记为松散跃点的子对象不应包含传出接口的标识符（即地址或ID）。
There is no way to specify in an ERO whether a subobject identifies an incoming or outgoing TE link. Path computation must be performed by an LSR when it encounters a loose hop in order to resolve the LSP route to the identified next hop. If an interface is specified as a loose hop and is treated as an incoming interface, the path computation will select a path that enters an LSR through that interface. If the interface was intended to be used as an outgoing interface, the computed path may be unsatisfactory and the explicit route in the ERO may be impossible to resolve. Thus a loose hop that identifies an interface should always identify the incoming TE link in the data plane.
无法在ERO中指定子对象是否标识传入或传出TE链接。路径计算必须由LSR在遇到松散跳时执行，以便将LSP路由解析到已识别的下一跳。如果接口被指定为松散跃点，并被视为传入接口，则路径计算将选择通过该接口进入LSR的路径。如果接口打算用作传出接口，则计算路径可能不令人满意，并且ERO中的显式路由可能无法解析。因此，标识接口的松散跃点应始终标识数据平面中的传入TE链路。
The RRO is used on Path and Resv messages to record the path of an LSP. Each LSR adds subobjects to the RRO to record information. The information added to an RRO by a node should be the same in the Path and the Resv message although there may be some information that is not available during LSP setup.
在Path和Resv消息上使用RRO来记录LSP的路径。每个LSR向RRO添加子对象以记录信息。节点添加到RRO的信息在路径和Resv消息中应该相同，尽管可能有一些信息在LSP设置期间不可用。
One use of the RRO is to allow the operator to view the path of the LSP. At any transit node, it should be possible to construct the path of the LSP by joining together the RRO from the Path and the Resv messages.
RRO的一个用途是允许操作员查看LSP的路径。在任何传输节点上，都可以通过将路径中的RRO和Resv消息连接在一起来构造LSP的路径。
It is also important that a whole RRO on a Resv message received at an ingress LSR can be used as an ERO on a subsequent Path message to completely recreate the LSP.
同样重要的是，在入口LSR接收的Resv消息上的整个RRO可以用作后续路径消息上的ERO，以完全重新创建LSP。
Therefore, when a node adds one or more subobjects to an RRO, any of the following options is valid.
因此，当节点向RRO添加一个或多个子对象时，以下任何选项均有效。
1. TE Router ID identifying the LSR.
1. 标识LSR的TE路由器ID。
2. Link ID identifying the incoming (upstream) TE link.
2. 标识传入（上游）TE链路的链路ID。
3. Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
3. 标识传出（下游）TE链路的链路ID，可选地后跟组件接口ID和/或一个或两个标签。
4. Link ID identifying the incoming (upstream) TE link, followed by a Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
4. 标识传入（上游）TE链路的链路ID，后跟标识传出（下游）TE链路的链路ID，可选地后跟组件接口ID和/或一个或两个标签。
5. TE Router ID identifying the LSR, followed by a Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
5. 标识LSR的TE路由器ID，后跟标识出站（下游）TE链路的链路ID，可选地后跟组件接口ID和/或一个或两个标签。
6. Link ID identifying the incoming (upstream) TE link, followed by the TE Router ID identifying the LSR, followed by a Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
6. 标识传入（上游）TE链路的链路ID，后跟标识LSR的TE路由器ID，后跟标识传出（下游）TE链路的链路ID，可选地后跟组件接口ID和/或一个或两个标签。
An implementation may choose any of these options and must be prepared to receive an RRO that contains any of these options.
实现可以选择这些选项中的任何一个，并且必须准备好接收包含这些选项中任何一个的RRO。
RRO Label recording is requested by an ingress node setting the Label Recording flag in the SESSION_ATTRIBUTE object and including an RRO is included in the Path message as described in [RFC3209]. Under these circumstances, each LSR along the LSP should include label information in the RRO in the Path message if it is available.
入口节点通过设置会话_属性对象中的标签记录标志来请求RRO标签记录，并在路径消息中包括RRO，如[RFC3209]所述。在这些情况下，LSP上的每个LSR都应该在路径消息的RRO中包含标签信息（如果可用）。
As described in [RFC3209], the processing for a Resv message "mirrors that of the Path" and "The only difference is that the RRO in a Resv message records the path information in the reverse direction." This means that hops are added to the RRO in the reverse order, but the information added at each LSR is in the same order (see Sections 6.1.1, 6.1.2, and 6.1.3). Thus, when label recording is requested, labels are included in the RROs in both the Path and Resv messages.
如[RFC3209]所述，对Resv消息的处理“镜像路径的处理”和“唯一的区别是Resv消息中的RRO以相反的方向记录路径信息”。这意味着跳按相反的顺序添加到RRO，但在每个LSR中添加的信息的顺序相同（参见第6.1.1节、第6.1.2节和第6.1.3节）。因此，当要求记录标签时，标签将包含在Path和Resv消息中的RRO中。
When a bundled link [RFC4201] is used to provide a data channel, a component link identifier is specified in the Interface Identification TLV in the IF_ID RSVP_HOP Object in order to indicate which data channel from within the bundle is to be used. The Interface Identification TLV is IF_INDEX TLV (Type 3) in the case of an unnumbered component link and IPv4 TLV (Type 1) or IPv6 TLV (Type 2) in the case of a numbered component link.
当捆绑链路[RFC4201]用于提供数据信道时，在IF_ID RSVP_HOP对象中的接口标识TLV中指定组件链路标识符，以指示将使用捆绑内的哪个数据信道。对于未编号的组件链接，接口标识TLV为IF_索引TLV（类型3）；对于编号的组件链接，接口标识TLV为IPv4 TLV（类型1）或IPv6 TLV（类型2）。
The component link for the upstream data channel may differ from that for the downstream data channel in the case of a bidirectional LSP. In this case, the Interface Identification TLV specifying a downstream interface is followed by another Interface Identification TLV specifying an upstream interface.
在双向LSP的情况下，用于上游数据信道的分量链路可以不同于用于下游数据信道的分量链路。在这种情况下，指定下游接口的接口标识TLV后面跟着另一个指定上游接口的接口标识TLV。
Note that identifiers in TLVs for upstream and downstream data channels in both Path and Resv messages are specified from the viewpoint of the upstream node (the node sending the Path message and receiving the Resv message), using identifiers belonging to the node.
注意，对于Path和Resv消息中的上游和下游数据信道，TLV中的标识符是从上游节点（发送Path消息并接收Resv消息的节点）的角度使用属于该节点的标识符来指定的。
An LSR constructing an ERO may include a Link ID that identifies a bundled link. If the LSR knows the identities of the component links and wishes to exert control, it may also include component link identifiers in the ERO. Otherwise, the component link identifiers are not included in the ERO.
构造ERO的LSR可以包括标识捆绑链路的链路ID。如果LSR知道组件链路的标识并希望施加控制，则它还可以在ERO中包括组件链路标识符。否则，ERO中不包括组件链接标识符。
When a bundled link is in use, the RRO may include the Link ID that identifies the link bundle. Additionally, the RRO may include a component link identifier.
当捆绑链接正在使用时，RRO可能包括标识链接捆绑的链接ID。另外，RRO可以包括组件链接标识符。
The final destination of the Path message is the Egress node that is specified by the tunnel end point address in the Session object.
路径消息的最终目的地是由会话对象中的隧道端点地址指定的出口节点。
The Egress node must not forward the corresponding Path message downstream, even if the ERO includes the outgoing interface ID of the Egress node for Egress control [RFC4003].
出口节点不得向下游转发相应的路径消息，即使ERO包括出口控制出口节点的传出接口ID[RFC4003]。
In GMPLS, a control channel can be separated from the data channel and there is not necessarily a one-to-one association of a control channel to a data channel. Two nodes that are adjacent in the data plane may have multiple IP hops between them in the control plane.
在GMPLS中，控制信道可以与数据信道分离，并且控制信道与数据信道之间不一定存在一对一的关联。在数据平面中相邻的两个节点在控制平面中可能具有多个IP跳。
There are two broad types of separated control planes: native and tunneled. These differ primarily in the nature of encapsulation used for signaling messages, which also results in slightly different address handling with respect to the control plane address.
有两种广泛类型的分离控制平面：原生控制平面和隧道控制平面。这些主要不同之处在于用于信令消息的封装的性质，这也导致相对于控制平面地址的地址处理略有不同。
A native control plane uses IP forwarding to deliver RSVP-TE messages between protocol speakers. The message is not further encapsulated.
本机控制平面使用IP转发在协议说话人之间传递RSVP-TE消息。该消息没有进一步封装。
IP forwarding applies normal rules to the IP header. Note that an IP hop must not decrement the TTL of the received RSVP-TE message.
IP转发将常规规则应用于IP头。请注意，IP跃点不得减少接收到的RSVP-TE消息的TTL。
For the case where two adjacent nodes have multiple IP hops between them in the control plane, then as stated in Section 9 of [RFC3945],
对于控制平面中两个相邻节点之间有多个IP跃点的情况，则如[RFC3945]第9节所述，
implementations should use the mechanisms of Section 6.1.1 of [RFC4206] whether or not they use LSP Hierarchy. Note that Section 6.1.1 of [RFC4206] applies to an "FA-LSP" as stated in that section, but also to a "TE link" for the case where a normal TE link is used.
无论是否使用LSP层次结构，实现都应使用[RFC4206]第6.1.1节中的机制。注意，[RFC4206]第6.1.1节适用于该节所述的“FA-LSP”，但也适用于使用正常TE链路的情况下的“TE链路”。
With a tunneled control plane, the RSVP-TE message is packaged in an IP packet that is inserted into a tunnel such that the IP packet will traverse exactly one IP hop. Various tunneling techniques can be used including (but not limited to) IP-in-IP, Generic Routing Encapsulation (GRE), and IP in MPLS.
通过隧道控制平面，RSVP-TE消息封装在插入隧道的IP数据包中，这样IP数据包将恰好穿过一个IP跃点。可以使用各种隧道技术，包括（但不限于）IP中的IP、通用路由封装（GRE）和MPLS中的IP。
Where the tunneling mechanism includes a TTL, it should be treated as for any network message sent on that network. Implementations receiving RSVP-TE messages on the tunnel interface must not compare the RSVP-TE TTL to any other TTL (whether the IP TTL or the tunnel TTL).
如果隧道机制包括TTL，则应将其视为在该网络上发送的任何网络消息。在隧道接口上接收RSVP-TE消息的实现不得将RSVP-TE TTL与任何其他TTL（无论是IP TTL还是隧道TTL）进行比较。
It has been observed that some implementations do not support the tunneled control plane features, and it is suggested that to enable interoperability, all implementations should support at least a native control plane.
据观察，一些实现不支持隧道控制平面功能，建议为了实现互操作性，所有实现至少应支持一个本机控制平面。
Data traffic must not be transmitted through the control plane. This is crucial when attempting PSC (Packet-Switching Capable) GMPLS with separated control and data channels.
数据通信不得通过控制平面传输。在尝试使用分离的控制和数据通道的PSC（支持分组交换的）GMPLS时，这一点至关重要。
This section describes a method of defining or monitoring an LSP tunnel using the MPLS-TE-STD-MIB module [RFC3812] and GMPLS-TE-STD-MIB module [RFC4802] where the ingress and/or egress routers are identified using 128-bit IPv6 addresses. This is the case when the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects in the mplsTunnelTable [RFC3812] cannot be used to carry the tunnel end point address and Extended Tunnel Id fields from the signaled Session Object because the IPv6 variant (LSP_TUNNEL_IPv6_SESSION object) is in use.
本节描述了使用MPLS-TE-STD-MIB模块[RFC3812]和GMPLS-TE-STD-MIB模块[RFC4802]定义或监控LSP隧道的方法，其中使用128位IPv6地址识别入口和/或出口路由器。由于IPv6变体（LSP_tunnel_IPv6_Session Object）正在使用中，因此无法使用mplsTunnelTable[RFC3812]中的MPLStunneLingResslrid和MPLStunnelegressrid对象从信号会话对象中携带隧道端点地址和扩展隧道Id字段，即为这种情况。
The normative text for MIB objects for control and monitoring MPLS and GMPLS nodes is found in the RFCs referenced above. This section makes no changes to those objects, but describes how they may be used to provide the necessary function.
用于控制和监视MPLS和GMPLS节点的MIB对象的规范性文本可在上述RFC中找到。本节不更改这些对象，但描述如何使用它们来提供必要的功能。
For this feature to be used, all LSRs in the network must advertise a 32-bit value that can be used to identify the LSR. In this document, this is referred to as the 32-bit LSR ID. The 32-bit LSR ID is the OSPFv3 router ID [RFC2740] or the ISIS IPv4 TE Router ID [RFC3784]. Note that these are different from TE router ID (see Section 2).
要使用此功能，网络中的所有LSR必须公布可用于标识LSR的32位值。在本文档中，这称为32位LSR ID。32位LSR ID是OSPFv3路由器ID[RFC2740]或ISIS IPv4 TE路由器ID[RFC3784]。注意，这些与TE路由器ID不同（参见第2节）。
When setting up RSVP TE tunnels, it is common practice to copy the values of the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields in the MPLS TE MIB mplsTunnelTable [RFC3812] into the Extended Tunnel ID and IPv4 tunnel end point address fields, respectively, in the RSVP-TE LSP_TUNNEL_IPv4 SESSION object [RFC3209].
设置RSVP TE隧道时，通常的做法是将MPLS TE MIB mplsTunnelTable[RFC3812]中的MPLStunnelingResslrid和MPLStunneleResslrid字段的值分别复制到RSVP-TE LSP_Tunnel_IPv4会话对象[RFC3209]中的扩展隧道ID和IPv4隧道端点地址字段中。
This approach cannot be used when the ingress and egress routers are identified by 128-bit IPv6 addresses as the mplsTunnelIngressLSRId, and mplsTunnelEgressLSRId fields are defined to be 32-bit values [RFC3811], [RFC3812].
当入口和出口路由器由128位IPv6地址标识为MPLStunnelegresslRid，并且MPLStunnelegresslRid字段定义为32位值[RFC3811]、[RFC3812]时，无法使用此方法。
Instead, the IPv6 addresses should be configured in the mplsHopTable as the first and last hops of the mplsTunnelHopTable entries defining the explicit route for the tunnel. Note that this implies that a tunnel with IPv6 source and destination addresses must have an explicit route configured, although it should be noted that the configuration of an explicit route in this way does not imply that an explicit route will be signaled.
相反，IPv6地址应在mplsHopTable中配置为定义隧道显式路由的mplsTunnelHopTable项的第一个和最后一个跃点。请注意，这意味着具有IPv6源地址和目标地址的隧道必须配置显式路由，但应注意，以这种方式配置显式路由并不意味着将通知显式路由。
In more detail, the tunnel is configured at the ingress router as follows. See [RFC3812] for definitions of MIB table objects and for default (that is, "normal") behavior.
更详细地说，隧道在入口路由器处配置如下。有关MIB表对象的定义和默认（即“正常”）行为，请参见[RFC3812]。
The mplsTunnelIndex and mplsTunnelInstance fields are set as normal.
mplsTunnelIndex和MPLStunneLinInstance字段设置为正常。
The mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields should be set to 32-bit LSR IDs for ingress and egress LSRs, respectively.
对于入口和出口LSR，mplsTunnelIngressLSRId和mplsTunnelEgressLSRId字段应分别设置为32位LSR ID。
The mplsTunnelHopTableIndex must be set to a non-zero value. That is, an explicit route must be specified.
mplsTunnelHopTableIndex必须设置为非零值。也就是说，必须指定显式路由。
The first hop of the explicit route must have mplsTunnelHopAddrType field set to ipv6(2) and should have the mplsTunnelHopIpAddr field set to a global scope IPv6 address of the ingress router that is reachable in the control plane.
显式路由的第一个跃点必须将mplsTunnelHopAddrType字段设置为ipv6（2），并将mplsTunnelHopIpAddr字段设置为可在控制平面中访问的入口路由器的全局范围ipv6地址。
The last hop of the explicit route must have mplsTunnelHopAddrType field set to ipv6(2) and should have the mplsTunnelHopIpAddr field set to a global scope IPv6 address of the egress router that is reachable in the control plane.
显式路由的最后一个跃点必须将mplstunnelhopaddryPE字段设置为ipv6（2），并将mplsTunnelHopIpAddr字段设置为可在控制平面中访问的出口路由器的全局范围ipv6地址。
The ingress router should set the signaled values of the Extended
入口路由器应设置扩展路由器的信号值
Tunnel ID and IPv6 tunnel end point address fields, respectively, of the RSVP-TE LSP_TUNNEL_IPv6 SESSION object [RFC3209] from the mplsTunnelHopIpAddr object of the first and last hops in the configured explicit route.
来自已配置显式路由中第一个和最后一个跃点的MPLSTUNNELHOPIDDR对象的RSVP-TE LSP_Tunnel_IPv6会话对象[RFC3209]的隧道ID和IPv6隧道端点地址字段。
In addition to their use for configuring LSPs as described in Section 8.1, the TE MIB modules (MPLS-TE-STD-MIB and GMPLS-TE-STD-MIB) may be used for managing and monitoring MPLS and GMPLS TE LSPs, respectively. This function is particularly important at egress and transit LSRs.
除第8.1节所述用于配置LSP外，TE MIB模块（MPLS-TE-STD-MIB和GMPLS-TE-STD-MIB）可分别用于管理和监控MPLS和GMPLS TE LSP。该功能在出口和过境LSR处尤为重要。
For a tunnel with IPv6 source and destination addresses, an LSR implementation should return values in the mplsTunnelTable as follows (where "normal" behavior is the default taken from [RFC3812]).
对于具有IPv6源地址和目标地址的隧道，LSR实现应在mplsTunnelTable中返回如下值（其中“正常”行为是[RFC3812]中的默认值）。
The mplsTunnelIndex and mplsTunnelInstance fields are set as normal.
mplsTunnelIndex和MPLStunneLinInstance字段设置为正常。
The mplsTunnelIngressLSRId field and mplsTunnelEgressLSRId are set to 32-bit LSR IDs. That is, each transit and egress router maps from the IPv6 address in the Extended Tunnel ID field to the 32-bit LSR ID of the ingress LSR. Each transit router also maps from the IPv6 address in the IPv6 tunnel end point address field to the 32-bit LSR ID of the egress LSR.
mplsTunnelIngressLSRId字段和mplstunnelegressrid设置为32位LSR ID。也就是说，每个传输和出口路由器从扩展隧道ID字段中的IPv6地址映射到入口LSR的32位LSR ID。每个传输路由器还从IPv6隧道端点地址字段中的IPv6地址映射到出口LSR的32位LSR ID。
In the interoperability testing we conducted, the major issue we found was the use of control channels for forwarding data. This was due to the setting of both control and data plane addresses to the same value in PSC (Packet-Switching Capable) equipment. This occurred when attempting to test PSC GMPLS with separated control and data channels. What resulted instead were parallel interfaces with the same addresses. This could be avoided simply by keeping the addresses for the control and data plane separate.
在我们进行的互操作性测试中，我们发现的主要问题是使用控制通道转发数据。这是由于在PSC（支持分组交换）设备中将控制和数据平面地址设置为相同的值。这是在尝试使用分离的控制和数据通道测试PSC GMPLS时发生的。结果是具有相同地址的并行接口。这可以通过将控件和数据平面的地址分开来避免。
The following people made textual contributions to this document:
以下人员对本文件做出了文字贡献：
Alan Davey, Yumiko Kawashima, Kaori Shimizu, Thomas D. Nadeau, Ashok Narayanan, Eiji Oki, Lyndon Ong, Vijay Pandian, Hari Rakotoranto, and Adrian Farrel.
艾伦·戴维、川岛由美子、清水高丽、托马斯·纳多、阿肖克·纳拉亚南、奥基英二、林登·翁、维杰·潘迪安、哈里·拉科托兰托和阿德里安·法雷尔。
The authors would like to thank Adrian Farrel for the helpful discussions and the feedback he gave on the document. In addition, Jari Arkko, Arthi Ayyangar, Deborah Brungard, Diego Caviglia, Lisa Dusseault, Dimitri Papadimitriou, Jonathan Sadler, Hidetsugu Sugiyama, and Julien Meuric provided helpful comments and suggestions.
作者要感谢阿德里安·法雷尔（Adrian Farrel）对该文件的有益讨论和反馈。此外，贾里·阿尔科、阿尔西·艾扬加、黛博拉·布伦加德、迭戈·卡维格利亚、丽莎·杜肖奥、迪米特里·帕帕迪米特里欧、乔纳森·萨德勒、杉山秀树和朱利安·默里提供了有益的意见和建议。
Adrian Farrel edited the final revisions of this document before and after working group last call.
阿德里安·法雷尔（Adrian Farrel）在工作组上次电话会议之前和之后编辑了本文件的最终修订版。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.
[RFC3811]Nadeau，T.，Ed.，和J.Cucchiara，Ed.，“多协议标签交换（MPLS）管理的文本约定（TC）定义”，RFC 3811，2004年6月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）流量工程（TE）管理信息库（MIB）”，RFC 3812，2004年6月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
[RFC4003]Berger，L.，“出口控制的GMPLS信号程序”，RFC 4003，2005年2月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-protocol Label Switching", RFC 4203, October 2005.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换的OSPF扩展”，RFC 4203，2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有广义MPLS TE的LSP层次结构”，RFC 4206，2005年10月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740]Coltun，R.，Ferguson，D.，和J.Moy，“IPv6的OSPF”，RFC 27401999年12月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4205]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的中间系统到中间系统（IS-IS）扩展”，RFC 4205，2005年10月。
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
[RFC4802]Nadeau，T.，Ed.，和A.Farrel，Ed.，“通用多协议标签交换（GMPLS）流量工程管理信息库”，RFC 4802，2007年2月。
Authors' Addresses
作者地址
Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori Musashino, Tokyo 180-8585 Japan
Kohei Shiomoto NTT网络服务系统实验室3-9-11 Midori Musashino，东京180-8585
Phone: +81 422 59 4402
EMail: shiomoto.kohei@lab.ntt.co.jp
Phone: +81 422 59 4402
EMail: shiomoto.kohei@lab.ntt.co.jp
Richard Rabbat Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043
理查德·拉巴特谷歌公司，1600圆形剧场公园道山景，加利福尼亚州94043
Phone: +1 650-714-7618
EMail: rabbat@alum.mit.edu
Phone: +1 650-714-7618
EMail: rabbat@alum.mit.edu
Rajiv Papneja Isocore Corporation 12359 Sunrise Valley Drive, Suite 100 Reston, Virginia 20191 United States of America
Rajiv Papneja Isocore Corporation美国弗吉尼亚州雷斯顿日出谷大道12359号100室，邮编：20191
Phone: +1 703-860-9273
EMail: rpapneja@isocore.com
Phone: +1 703-860-9273
EMail: rpapneja@isocore.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.