Network Working Group G. Swallow
Request for Comments: 4208 Cisco Systems, Inc
Category: Standards Track J. Drake
Boeing
H. Ishimatsu
G1M Co., Ltd.
Y. Rekhter
Juniper Networks, Inc
October 2005
Network Working Group G. Swallow
Request for Comments: 4208 Cisco Systems, Inc
Category: Standards Track J. Drake
Boeing
H. Ishimatsu
G1M Co., Ltd.
Y. Rekhter
Juniper Networks, Inc
October 2005
Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model
通用多协议标签交换（GMPLS）用户网络接口（UNI）：覆盖模型的资源预留协议流量工程（RSVP-TE）支持
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model.
广义多协议标签交换（GMPLS）定义了用于在各种交换技术中创建标签交换路径（LSP）的路由和信令协议。这些协议可用于支持许多部署场景。本备忘录阐述了GMPLS在覆盖模型中的应用。
Table of Contents
目录
1. Introduction ....................................................2
1.1. GMPLS User-Network Interface (GMPLS UNI) ...................4
2. Addressing ......................................................5
3. ERO Processing ..................................................6
3.1. Path Message without ERO ...................................6
3.2. Path Message with ERO ......................................6
3.3. Explicit Label Control .....................................7
4. RRO Processing ..................................................7
5. Notification ....................................................7
6. Connection Deletion .............................................8
6.1. Alarm-Free Connection Deletion .............................8
6.2. Connection Deletion with PathErr ...........................8
7. VPN Connections .................................................9
8. Security Considerations ........................................10
9. Acknowledgments ................................................10
10. References ....................................................10
10.1. Normative References .....................................10
10.2. Informational References .................................10
1. Introduction ....................................................2
1.1. GMPLS User-Network Interface (GMPLS UNI) ...................4
2. Addressing ......................................................5
3. ERO Processing ..................................................6
3.1. Path Message without ERO ...................................6
3.2. Path Message with ERO ......................................6
3.3. Explicit Label Control .....................................7
4. RRO Processing ..................................................7
5. Notification ....................................................7
6. Connection Deletion .............................................8
6.1. Alarm-Free Connection Deletion .............................8
6.2. Connection Deletion with PathErr ...........................8
7. VPN Connections .................................................9
8. Security Considerations ........................................10
9. Acknowledgments ................................................10
10. References ....................................................10
10.1. Normative References .....................................10
10.2. Informational References .................................10
Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various transport technologies. These protocols can be used to support a number of deployment scenarios. In a peer model, edge-nodes support both a routing and a signaling protocol. The protocol interactions between an edge-node and a core-node are the same as between two core-nodes. In the overlay model, the core-nodes act more as a closed system. The edge-nodes do not participate in the routing protocol instance that runs among the core nodes; in particular, the edge-nodes are unaware of the topology of the core-nodes. There may, however, be a routing protocol interaction between a core-node and an edge-node for the exchange of reachability information to other edge-nodes.
广义多协议标签交换（GMPLS）定义了用于在各种传输技术中创建标签交换路径（LSP）的路由和信令协议。这些协议可用于支持许多部署场景。在对等模型中，边缘节点支持路由和信令协议。边缘节点和核心节点之间的协议交互与两个核心节点之间的协议交互相同。在覆盖模型中，核心节点更像一个封闭系统。边缘节点不参与在核心节点之间运行的路由协议实例；特别是，边缘节点不知道核心节点的拓扑结构。然而，核心节点和边缘节点之间可能存在路由协议交互，用于向其他边缘节点交换可达性信息。
Overlay Overlay
Network +----------------------------------+ Network
+---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | |
| -+ EN +-+-----+--+ CN +----+ CN +----+ CN +---+-----+-+ EN +- |
| | | | +--+--| | | | | | | | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ |
| | | | | | | | | |
+---------+ | | | | | | +---------+
| | | | | |
+---------+ | | | | | | +---------+
| | | | +--+--+ | +--+--+ | | |
| +----+ | | | | | +-------+ | | | +----+ |
| | +-+--+ | | CN +---------------+ CN | | | | | |
| -+ EN +-+-----+--+ | | +---+-----+-+ EN +- |
| | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ |
| | +----------------------------------+ | |
+---------+ Core Network +---------+
Overlay Overlay
Network Network
Overlay Overlay
Network +----------------------------------+ Network
+---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | |
| -+ EN +-+-----+--+ CN +----+ CN +----+ CN +---+-----+-+ EN +- |
| | | | +--+--| | | | | | | | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ |
| | | | | | | | | |
+---------+ | | | | | | +---------+
| | | | | |
+---------+ | | | | | | +---------+
| | | | +--+--+ | +--+--+ | | |
| +----+ | | | | | +-------+ | | | +----+ |
| | +-+--+ | | CN +---------------+ CN | | | | | |
| -+ EN +-+-----+--+ | | +---+-----+-+ EN +- |
| | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ |
| | +----------------------------------+ | |
+---------+ Core Network +---------+
Overlay Overlay
Network Network
Legend: EN - Edge Node CN - Core Node
图例：EN-边缘节点CN-核心节点
Figure 1: Overlay Reference Model
图1：覆盖参考模型
Figure 1 shows a reference network. The core network is represented by the large box in the center. It contains five core-nodes marked 'CN'. The four boxes around the edge marked "Overlay Network" represent four islands of a single overlay network. Only the nodes of this network with TE links into the core network are shown. These nodes are called edge-nodes; the terminology is in respect to the core network, not the overlay network. Note that each box marked "Overlay Network" could contain many other nodes. Such nodes are not shown; they do not participate directly in the signaling described in this document. Only the edge-nodes can signal to set up links across the core to other edge-nodes.
图1显示了一个参考网络。核心网络由中心的大方框表示。它包含五个标记为“CN”的核心节点。标记为“覆盖网络”的边缘周围的四个框表示单个覆盖网络的四个孤岛。仅显示该网络中与核心网络相连的节点。这些节点称为边缘节点；术语是关于核心网络，而不是覆盖网络。请注意，每个标记为“覆盖网络”的框可能包含许多其他节点。未显示此类节点；他们不直接参与本文件中描述的信号。只有边缘节点可以发出信号，以建立跨核心到其他边缘节点的链接。
How a link between edge-nodes is requested and triggered is out of the scope of this document, as is precisely how that link is used by the Overlay Network. One possibility is that the edge-nodes will inform the other nodes of the overlay network of the existence of the link, possibly using a forwarding adjacency as described in [MPLS-HIER]. Note that this contrasts with a forwarding adjacency that is provided by the core network as a link between core-nodes.
如何请求和触发边缘节点之间的链接不在本文档的范围内，覆盖网络如何使用该链接也不在本文档的范围内。一种可能性是边缘节点将通知覆盖网络的其他节点链路的存在，可能使用[MPLS-HIER]中描述的转发邻接。注意，这与核心网络作为核心节点之间的链路提供的转发邻接形成对比。
In the overlay model, there may be restrictions on what may be signaled between an edge-node and a core-node. This memo addresses the application of GMPLS to the overlay model. Specifically, it addresses RSVP-TE procedures between an edge-node and a core-node in the overlay model. All signaling procedures are identical to the GMPLS extensions specified in [RFC3473], except as noted in this document.
在覆盖模型中，可能对边缘节点和核心节点之间的信号传递有限制。本备忘录阐述了GMPLS在覆盖模型中的应用。具体而言，它解决了覆盖模型中边缘节点和核心节点之间的RSVP-TE过程。除本文件另有说明外，所有信号程序均与[RFC3473]中规定的GMPLS扩展相同。
This document primarily addresses interactions between an edge-node and it's adjacent (at the data plane) core-node; out-of-band and non-adjacent signaling capabilities may mean that signaling messages are delivered on a longer path. Except where noted, the term core-node refers to the node immediately adjacent to an edge-node across a particular data plane interface. The term core-nodes, however, refers to all nodes in the core.
本文档主要讨论边缘节点与其相邻（在数据平面上）核心节点之间的交互；带外和非相邻信令能力可能意味着信令消息在更长的路径上传送。除非另有说明，否则术语核心节点是指在特定数据平面接口上紧邻边缘节点的节点。然而，术语核心节点指的是核心中的所有节点。
Realization of a single or multiple instance of the UNI is implementation dependent at both the CN and EN so long as it meets the functional requirements for robustness, security, and privacy detailed in Section 7.
UNI的单个或多个实例的实现取决于CN和EN的实现，只要它满足第7节详述的健壮性、安全性和隐私性的功能要求。
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]中所述进行解释。
Readers are assumed to be familiar with the terminology introduced in [RFC3031], [GMPLS-ARCH], and [RFC3471].
假定读者熟悉[RFC3031]、[GMPLS-ARCH]和[RFC3471]中介绍的术语。
One can apply the GMPLS Overlay model at the User-Network Interface (UNI) reference point defined in the Automatically Switched Optical Network (ASON) [G.8080]. Consider the case where the 'Core Network' in Figure 1 is a Service Provider network, and the Edge Nodes are 'user' devices. The interface between an EN and a CN is the UNI reference point, and to support the ASON model, one must define signaling across the UNI.
可以在自动交换光网络（ASON）[G.8080]中定义的用户网络接口（UNI）参考点处应用GMPLS覆盖模型。考虑图1中的“核心网络”是服务提供者网络的情况，并且边缘节点是“用户”设备。EN和CN之间的接口是UNI参考点，为了支持ASON模型，必须定义UNI上的信令。
The extensions described in this memo provide mechanisms for UNI signaling that are compatible with GMPLS signaling [RFC3471, RFC3473]. Moreover, these mechanisms for UNI signaling are in line with the RSVP model; namely, there is a single end-to-end RSVP session for the user connection. The first and last hops constitute the UNI, and the RSVP session carries the user parameters end-to-end. This obviates the need to map (or carry) user parameters to (in) the format expected by the network-to-network interface (NNI) used within the Service Provider network. This in turn means that the UNI and NNI can be independent of one another, which is a requirement of the
本备忘录中描述的扩展提供了与GMPLS信令兼容的UNI信令机制[RFC3471，RFC3473]。此外，这些UNI信号机制符合RSVP模型；也就是说，用户连接只有一个端到端RSVP会话。第一跳和最后一跳构成UNI，RSVP会话端到端携带用户参数。这样就无需将用户参数映射（或携带）到服务提供商网络中使用的网络到网络接口（NNI）所期望的格式。这反过来意味着UNI和NNI可以彼此独立，这是
ASON architecture. However, in the case that the UNI and NNI are both GMPLS RSVP-based, the methodology specified in this memo allows for a single RSVP session to instantiate both UNI and NNI signaling, if so desired, and if allowed by Service Provider policy.
ASON架构。但是，如果UNI和NNI都是基于GMPLS RSVP的，本备忘录中规定的方法允许单个RSVP会话实例化UNI和NNI信令（如果需要），并且如果服务提供商政策允许。
Addresses for edge-nodes in the overlay model are drawn from the same address space as the edge-nodes use to address their adjacent core-nodes. This may be the same address space as used by the core-nodes to communicate among themselves, or it may be a VPN space supported by the core-nodes as an overlay.
覆盖模型中边缘节点的地址从边缘节点用于寻址其相邻核心节点的相同地址空间中绘制。这可能是与核心节点用于在它们之间通信的地址空间相同的地址空间，也可能是核心节点作为覆盖支持的VPN空间。
To be more specific, an edge-node and its attached core-node must share the same address space that is used by GMPLS to signal between the edge-nodes across the core network. A set of <edge-node, core-node> tuples share the same address space if the edge-nodes in the set could establish LSPs (through the core-nodes) among themselves without address mapping or translation (note that edge-nodes in the set may be a subset of all the edge-nodes). The address space used by the core-nodes to communicate among themselves may, but need not, be shared with the address space used by any of the <edge-node, core-node> tuples. This does not imply a mandatory 1:1 mapping between a set of LSPs and a given addressing space.
更具体地说，边缘节点及其连接的核心节点必须共享GMPLS用于在核心网络的边缘节点之间发送信号的相同地址空间。一组<edge node，core node>元组共享相同的地址空间，前提是集合中的边缘节点可以（通过核心节点）在它们之间建立LSP，而无需地址映射或转换（请注意，集合中的边缘节点可能是所有边缘节点的子集）。核心节点用于在它们之间通信的地址空间可以但不必与<edge node，core node>元组中的任何元组使用的地址空间共享。这并不意味着一组LSP和给定寻址空间之间必须有1:1的映射。
When multiple overlay networks are supported by a single core network, one or more address spaces may be used according to privacy requirements. This may be achieved without varying the core-node addresses since it is the <edge-node, core-node> tuple that constitutes address space membership.
当单个核心网络支持多个覆盖网络时，可根据隐私要求使用一个或多个地址空间。这可以在不改变核心节点地址的情况下实现，因为构成地址空间成员身份的是<edge node，core node>元组。
An edge-node is identified by either a single IP address representing its Node-ID, or by one or more numbered TE links that connect the edge-node to the core-nodes. Core-nodes are assumed to be ignorant of any other addresses associated with an edge-node (i.e., addresses that are not used in signaling connections through the GMPLS core).
边缘节点由表示其节点ID的单个IP地址或将边缘节点连接到核心节点的一个或多个编号的TE链路标识。假设核心节点不知道与边缘节点相关联的任何其他地址（即，在通过GMPLS核心的信令连接中未使用的地址）。
An edge-node need only know its own address, an address of the adjacent core-node, and know (or be able to resolve) the address of any other edge-node to which it wishes to connect, as well as (of course) the addresses used in the overlay network island of which it is a part.
边缘节点只需要知道自己的地址、相邻核心节点的地址，并知道（或能够解析）它希望连接到的任何其他边缘节点的地址，以及（当然）它所属的覆盖网络岛中使用的地址。
A core-node need only know (and track) the addresses on interfaces between that core-node and its attached edge-nodes, as well as the Node IDs of those edge-nodes. In addition, a core-node needs to know the interface addresses and Node IDs of other edge-nodes to which an attached edge-node is permitted to connect.
核心节点只需要知道（并跟踪）该核心节点与其连接的边缘节点之间接口上的地址，以及这些边缘节点的节点ID。此外，核心节点需要知道允许连接的边缘节点连接到的其他边缘节点的接口地址和节点ID。
When forming a SENDER_TEMPLATE, the ingress edge-node includes either its Node-ID or the address of one of its numbered TE links. In the latter case the connection will only be made over this interface.
当形成发送者_模板时，入口边缘节点包括其节点ID或其编号TE链路之一的地址。在后一种情况下，只能通过该接口进行连接。
When forming a SESSION_OBJECT, the ingress edge-node includes either the Node-ID of the egress edge-device or the address of one of the egress' numbered TE links. In the latter case the connection will only be made over this interface. The Extended_Tunnel_ID of the SESSION Object is set to either zero or to an address of the ingress edge-device.
当形成会话_对象时，入口边缘节点包括出口边缘设备的节点ID或出口的编号TE链路之一的地址。在后一种情况下，只能通过该接口进行连接。会话对象的扩展_Tunnel_ID设置为零或入口边缘设备的地址。
Links may be either numbered or unnumbered. Further, links may be bundled or unbundled. See [GMPLS-ARCH], [RFC3471], [BUNDLE], and [RFC3477].
链接可以编号，也可以不编号。此外，链接可以是捆绑的或非捆绑的。参见[GMPLS-ARCH]、[RFC3471]、[BUNDLE]和[RFC3477]。
An edge-node MAY include an ERO. A core-node MAY reject a Path message that contains an ERO. Such behavior is controlled by (hopefully consistent) configuration. If a core-node rejects a Path message due to the presence of an ERO, it SHOULD return a PathErr message with an error code of "Unknown object class" toward the sender as described in [RFC3209]. This causes the path setup to fail.
边缘节点可以包括ERO。核心节点可以拒绝包含ERO的路径消息。这种行为由配置控制（希望是一致的）。如果核心节点由于ERO的存在而拒绝Path消息，则应按照[RFC3209]中的说明，向发送方返回错误代码为“未知对象类”的PathErr消息。这会导致路径设置失败。
Further, a core-node MAY accept EROs that only include the ingress edge-node, the ingress core-node, the egress core-node, and the egress edge-node. This is to support explicit label control on the edge-node interface; see below. If a core-node rejects a Path message due to the presence of an ERO that is not of the permitted format, it SHOULD return a PathErr message with an error code of Bad Explicit Route Object as defined in [RFC3209].
此外，核心节点可以接受仅包括入口边缘节点、入口核心节点、出口核心节点和出口边缘节点的ero。这是为了在边缘节点接口上支持显式标签控制；见下文。如果核心节点由于存在不符合允许格式的ERO而拒绝Path消息，则应返回PathErr消息，其中错误代码为[RFC3209]中定义的错误显式路由对象。
When a core-node receives a Path message from an edge-node that contains no ERO, it MUST calculate a route to the destination and include that route in an ERO, before forwarding the PATH message. One exception would be if the egress edge-node were also adjacent to this core-node. If no route can be found, the core-node SHOULD return a PathErr message with an error code and value of 24,5 - "No route available toward destination".
当核心节点从不包含ERO的边缘节点接收到路径消息时，它必须在转发路径消息之前计算到目的地的路由并将该路由包括在ERO中。一个例外是，如果出口边缘节点也与该核心节点相邻。如果找不到路由，则核心节点应返回一条PathErr消息，该消息的错误代码和值为24,5-“没有通向目标的可用路由”。
When a core-node receives a Path message from an edge-node that contains an ERO, it SHOULD verify the route against its topology database before forwarding the PATH message. If the route is not
当核心节点从包含ERO的边缘节点接收到路径消息时，它应该在转发路径消息之前根据其拓扑数据库验证路由。如果路线不是
viable (according to topology, currently available resources, or local policy), then a PathErr message with an error code and value of 24,5 - "No route available toward destination" should be returned.
可行（根据拓扑、当前可用资源或本地策略），则应返回错误代码和值为24,5的PathErr消息-“没有通往目的地的可用路由”。
In order to support explicit label control and full identification of the egress link, an ingress edge-node may include this information in the ERO that it passes to its neighboring core-node. In the case that no other ERO is supplied, this explicit control information is provided as the only hop of the ERO and is encoded by setting the first subobject of the ERO to the node-ID of the egress core-node with the L-bit set; following this subobject are all other subobjects necessary to identify the link and labels as they would normally appear.
为了支持出口链路的显式标签控制和完全标识，入口边缘节点可以在其传递给其相邻核心节点的ERO中包括该信息。在没有提供其他ERO的情况下，该显式控制信息作为ERO的唯一跳提供，并且通过将ERO的第一子对象设置为具有L比特集的出口核心节点的节点ID来编码；此子对象之后是标识链接和标签所需的所有其他子对象，它们通常会显示。
The same rules apply to the presence of the explicit control subobjects as the last hop in the ERO, if a fuller ERO is supplied by the ingress edge-node to its neighbor core-node; but in this case the L-bit MAY be clear.
如果入口边缘节点向其相邻核心节点提供更完整的ERO，则相同的规则适用于与ERO中的最后一跳相同的显式控制子对象的存在；但在这种情况下，L位可能是清晰的。
This process is described in [RFC3473] and [EXPLICIT].
[RFC3473]和[EXPLICIT]中描述了该过程。
An edge-node MAY include an RRO. A core-node MAY remove the RRO from the Path message before forwarding it. Further, the core-node may remove the RRO from a Resv message before forwarding it to the edge-node. Such behavior is controlled by (hopefully consistent) configuration.
边缘节点可以包括RRO。核心节点可以在转发路径消息之前将其删除。此外，核心节点可以在将Resv消息转发到边缘节点之前从Resv消息中移除RRO。这种行为由配置控制（希望是一致的）。
Further, a core-node MAY edit the RRO in a Resv message such that it includes only the subobjects from the egress core-node through the egress edge-node. This is to allow the ingress node to be aware of the selected link and labels on at the far end of the connection.
此外，核心节点可以编辑Resv消息中的RRO，使得其仅包括从出口核心节点到出口边缘节点的子对象。这是为了让入口节点知道连接远端的所选链路和标签。
An edge-node MAY include a NOTIFY_REQUEST object in both the Path and Resv messages it generates. Core-nodes may send Notify messages to edge-nodes that have included the NOTIFY_REQUEST object.
边缘节点可以在其生成的Path和Resv消息中包括NOTIFY_请求对象。核心节点可以向包含Notify_请求对象的边缘节点发送Notify消息。
A core-node MAY remove a NOTIFY_REQUEST object from a Path or Resv message received from an edge-node before forwarding it.
在转发之前，核心节点可以从从边缘节点接收的路径或Resv消息中移除NOTIFY_请求对象。
If no NOTIFY_REQUEST object is present in the Path or Resv received from an edge-node, the core-node adjacent to the edge-node may include a NOTIFY_REQUEST object and set its value to its own address.
如果从边缘节点接收的路径或Resv中不存在NOTIFY_请求对象，则与边缘节点相邻的核心节点可以包括NOTIFY_请求对象，并将其值设置为其自己的地址。
In either of the above cases, the core-node SHOULD NOT send Notify messages to the edge-node.
在上述任一情况下，核心节点不应向边缘节点发送通知消息。
When a core-node receives a NOTIFY_REQUEST object from an edge-node, it MAY update the Notify Node Address with its own address before forwarding it. In this case, when Notify messages are received, they MAY be selectively (based on local policy) forwarded to the edge-node.
当核心节点从边缘节点接收到NOTIFY_请求对象时，它可以在转发之前用自己的地址更新NOTIFY节点地址。在这种情况下，当接收到通知消息时，它们可以选择性地（基于本地策略）转发到边缘节点。
RSVP-TE currently deletes connections using either a single pass PathTear message, or a ResvTear and PathTear message combination. Upon receipt of the PathTear message, a node deletes the connection state and forwards the message. In optical networks, however, it is possible that the deletion of a connection (e.g., removal of the cross-connect) in a node may cause the connection to be perceived as failed in downstream nodes (e.g., loss of frame, loss of light, etc.). This may in turn lead to management alarms and perhaps the triggering of restoration/protection for the connection.
RSVP-TE当前使用单个pass PathTear消息或ResvTear和PathTear消息组合删除连接。在收到PathTear消息后，节点将删除连接状态并转发消息。然而，在光网络中，节点中连接的删除（例如，交叉连接的移除）可能导致下游节点中的连接被视为失败（例如，帧丢失、光丢失等）。这可能反过来导致管理报警，并可能触发连接的恢复/保护。
To address this issue, the graceful connection deletion procedure SHOULD be followed. Under this procedure, an ADMIN_STATUS object MUST be sent in a Path or Resv message along the connection's path to inform all nodes en route to the intended deletion, prior to the actual deletion of the connection. The procedure is described in [RFC3473].
要解决此问题，应遵循正常连接删除过程。在此过程中，在实际删除连接之前，必须沿连接的路径以路径或Resv消息的形式发送ADMIN_STATUS对象，以通知正在进行预期删除的所有节点。[RFC3473]中描述了该程序。
If an ingress core-node receives a PathTear without having first seen an ADMIN_STATUS object informing it that the connection is about to be deleted, it MAY pause the PathTear and first send a Path message with an ADMIN_STATUS object to inform all downstream LSRs that the connection is about to be deleted. When the Resv is received echoing the ADMIN_STATUS or using a timer as described in [RFC3473], the ingress core-node MUST forward the PathTear.
如果入口核心节点在没有首先看到ADMIN_状态对象通知其连接即将被删除的情况下接收到Path催泪弹，它可能会暂停Path催泪弹并首先发送带有ADMIN_状态对象的Path消息，以通知所有下游LSR连接即将被删除。当接收到回复ADMIN_状态或使用[RFC3473]中所述的计时器的Resv时，入口核心节点必须转发路径撕裂。
[RFC3473] introduces the Path_State_Removed flag to a PathErr message to indicate that the sender has removed all state associated with the LSP and does not need to see a PathTear. A core-node next to an edge-node MAY map between teardown using ResvTear/PathTear and PathErr with Path_state_Removed.
[RFC3473]在PathErr消息中引入Path_State_Removed标志，以指示发送方已删除与LSP关联的所有状态，并且不需要查看PathTrail。边缘节点旁边的核心节点可以使用ResvTear/PathTear在拆卸和移除路径状态的PathErr之间映射。
A core-node next to an edge-node receiving a ResvTear from its downstream neighbor MAY respond with a PathTear and send a PathErr with Path_State_Removed further upstream.
从其下游邻居接收ResvTear的边缘节点旁边的核心节点可以使用PathTear进行响应，并发送路径_State _进一步向上游移除的PathErr。
Note, however, that a core-node next to an edge-node receiving a PathErr with Path_State_Removed from its downstream neighbor MUST NOT retain Path state and send a ResvTear further upstream because that would imply that Path state further downstream had also been retained.
然而，请注意，接收路径_状态_从下游邻居移除的PathErr的边缘节点旁边的核心节点不得保留路径状态并向更上游发送ResvTear，因为这意味着更下游的路径状态也已保留。
As stated in the addressing section above, the extensions in this document are designed to be compatible with the support of VPNs. Since the core network may be some technology other than GMPLS, no mandatory means of mapping core connections to access connections is specified. However, when GMPLS is used for the core network, it is RECOMMENDED that the following procedure based on [MPLS-HIER] is followed.
如上寻址部分所述，本文档中的扩展旨在与VPN支持兼容。由于核心网络可能是GMPLS以外的一些技术，因此没有规定将核心连接映射到访问连接的强制性方法。但是，当核心网络使用GMPLS时，建议遵循以下基于[MPLS-HIER]的程序。
The VPN connection is modeled as being three hops. One for each access link and one hop across the core network.
VPN连接被建模为三个跃点。每个接入链路一个，跨核心网络一个跃点。
The VPN connection is established using a two-step procedure. When a Path message is received at a core-node on an interface that is part of a VPN, the Path message is held until a core connection is established.
VPN连接使用两步程序建立。当在作为VPN一部分的接口上的核心节点上接收到路径消息时，将保留该路径消息，直到建立核心连接为止。
The connection across the core is setup as a separate signaling exchange between the core-nodes, using the address space of the core nodes. While this exchange is in progress, the original Path message is held at the ingress core-node. Once the exchange for the core connection is complete, this connection is used in the VPN connection as if it were a single link. This is signaled by including an IF_ID RSVP_HOP object (defined in [RFC3473]) using the procedures defined in [MPLS-HIER].
使用核心节点的地址空间，将整个核心的连接设置为核心节点之间的单独信令交换。在交换过程中，原始路径消息保存在入口核心节点。核心连接的交换完成后，此连接将在VPN连接中使用，就像它是单个链路一样。这是通过使用[MPLS-HIER]中定义的过程包含IF_ID RSVP_HOP对象（在[RFC3473]中定义）来表示的。
The original Path message is then forwarded within the VPN addressing realm to the core-node attached to the destination edge-node. Many ways of accomplishing this are available, including IP and GRE tunnels and BGP/MPLS VPNs. Specifying a particular means is beyond the scope of this document.
原始路径消息随后在VPN寻址域内转发到连接到目标边缘节点的核心节点。实现这一点的方法有很多，包括IP和GRE隧道以及BGP/MPLS VPN。指定特定方法超出了本文件的范围。
The trust model between the core and edge-nodes is different than the one described in [RFC3473], as the core is permitted to hide its topology from the edge-nodes, and the core is permitted to restrict the actions of edge-nodes by filtering out specific RSVP objects.
核心和边缘节点之间的信任模型不同于[RFC3473]中所述的信任模型，因为允许核心对边缘节点隐藏其拓扑，并且允许核心通过过滤掉特定的RSVP对象来限制边缘节点的动作。
The authors would like to thank Kireeti Kompella, Jonathan Lang, Dimitri Papadimitriou, Dimitrios Pendarakis, Bala Rajagopalan, and Adrian Farrel for their comments and input. Thanks for thorough final reviews from Loa Andersson and Dimitri Papadimitriou.
作者感谢Kireeti Kompella、Jonathan Lang、Dimitri Papadimitriou、Dimitrios Pendarakis、Bala Rajagopalan和Adrian Farrel的评论和意见。感谢Loa Andersson和Dimitri Papadimitriou的全面总结。
Adrian Farrel edited the last two revisions of this document to incorporate comments from Working Group last call and from AD review.
阿德里安·法雷尔（Adrian Farrel）编辑了本文件的最后两次修订，以纳入工作组上次电话会议和广告审查的意见。
[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月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[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月。
[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月。
[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月。
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[BUNDLE]Kompella，K.，Rekhter，Y.，和Berger，L.，“MPLS流量工程（TE）中的链路捆绑”，RFC 4201，2005年10月。
[EXPLICIT] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
[明确]Berger，L.，“出口控制的GMPLS信号程序”，RFC 4003，2005年2月。
[GMPLS-ARCH] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[GMPLS-ARCH]Mannie，E.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[MPLS-HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[MPLS-HIER]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)," November 2001 (and Revision, January 2003). For information on the availability of this document, please see http://www.itu.int.
[G.8080]ITU-T Rec.G.8080/Y.1304，“自动交换光网络（ASON）的体系结构”，2001年11月（修订版，2003年1月）。有关本文档可用性的信息，请参见http://www.itu.int.
Authors' Addresses
作者地址
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave, Boxborough, MA 01719
乔治·斯沃诺思科系统公司，地址：马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
Phone: +1 978 936 1398
EMail: swallow@cisco.com
Phone: +1 978 936 1398
EMail: swallow@cisco.com
John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245
约翰德雷克波音卫星系统2300东帝国公路埃尔塞贡多，加利福尼亚州90245
Phone: +1 412 370-3108
EMail: John.E.Drake2@boeing.com
Phone: +1 412 370-3108
EMail: John.E.Drake2@boeing.com
Hirokazu Ishimatsu G1M Co., Ltd. Nishinippori Start up Office 214, 5-37-5 Nishinippori, Arakawaku, Tokyo 116-0013, Japan
Hirokazu Ishimatsu G1M株式会社日本东京116-0013荒川县西宁坡里5-37-5号西宁坡里创业办公室214
Phone: +81 3 3891 8320
EMail: hirokazu.ishimatsu@g1m.jp
Phone: +81 3 3891 8320
EMail: hirokazu.ishimatsu@g1m.jp
Yakov Rekhter Juniper Networks, Inc.
雅科夫·雷克特·朱尼珀网络公司。
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。