Internet Engineering Task Force (IETF) K. Shiomoto
Request for Comments: 6383 NTT
Category: Informational A. Farrel
ISSN: 2070-1721 Old Dog Consulting
September 2011
Internet Engineering Task Force (IETF) K. Shiomoto
Request for Comments: 6383 NTT
Category: Informational A. Farrel
ISSN: 2070-1721 Old Dog Consulting
September 2011
Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE
关于何时开始在使用RSVP-TE建立的标签交换路径上安全发送数据的建议
Abstract
摘要
The Resource Reservation Protocol (RSVP) has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and link to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives.
资源预留协议（RSVP）已扩展到支持多协议标签交换（MPLS）和通用MPLS（GMPLS）网络中的流量工程（TE）。该协议允许信令交换建立标签交换路径（LSP），该路径穿过节点和链路以提供端到端数据路径。在处理信令消息时，每个节点都使用“交叉连接”信息进行编程。交叉连接信息指示节点如何转发其接收的数据。
End points of an LSP need to know when it is safe to start sending data so that it is not misdelivered, and so that safety issues specific to optical data-plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages.
LSP的端点需要知道何时开始发送数据是安全的，这样数据就不会误发，从而满足光数据平面技术特有的安全问题。类似地，沿着LSP路径的所有标签交换路由器需要知道何时相对于发送和接收控制平面消息对其数据平面进行编程。
This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices.
本文件澄清并总结了RSVP-TE协议交换与单向和双向LSP的LSP交叉连接编程的关系。本文件未定义任何新程序或协议扩展，完全遵循提供规范性参考的文件。本文件中的澄清也可用于帮助解释MPLS-TE和GMPLS设备的LSP建立性能数据。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6383.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6383.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
The Resource Reservation Protocol (RSVP) [RFC2205] has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks [RFC3209] [RFC3473]. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and links to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives. In some technologies this requires configuration of physical devices, while in others it may involve the exchange of commands between different components of the node. The nature of a cross-connect is described further in Section 1.1.1.
资源预留协议（RSVP）[RFC2205]已经扩展到支持多协议标签交换（MPLS）和通用MPLS（GMPLS）网络中的流量工程（TE）[RFC3209][RFC3473]。该协议允许信令交换建立标签交换路径（LSP），该路径穿过节点和链路以提供端到端数据路径。在处理信令消息时，每个节点都使用“交叉连接”信息进行编程。交叉连接信息指示节点如何转发其接收的数据。在某些技术中，这需要配置物理设备，而在另一些技术中，这可能涉及节点不同组件之间的命令交换。交叉连接的性质在第1.1.1节中进一步描述。
End points of an LSP need to know when it is safe to start sending data. In this context "safe" has two meanings. The first issue is that the sender needs to know that the data path has been fully established, setting up the cross-connects and removing any old, incorrect forwarding instructions, so that data will be delivered to the intended destination. The other meaning of "safe" is that in optical technologies, lasers must not be turned on until the correct cross-connects have been put in place to ensure that service personnel are not put at risk.
LSP的端点需要知道何时开始发送数据是安全的。在这种情况下，“安全”有两种含义。第一个问题是，发送方需要知道数据路径已完全建立，设置交叉连接并删除任何旧的、不正确的转发指令，以便将数据发送到预期目的地。“安全”的另一个含义是，在光学技术中，在正确的交叉连接到位之前，不得开启激光器，以确保服务人员不会处于危险之中。
Similarly, all Label Switching Routers (LSRs) along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages.
类似地，沿着LSP路径的所有标签交换路由器（lsr）需要知道何时相对于发送和接收控制平面消息对其数据平面进行编程。
This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. Bidirectional LSPs, it should be noted, are supported only in GMPLS. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references.
本文件澄清并总结了RSVP-TE协议交换与单向和双向LSP的LSP交叉连接编程的关系。应该注意的是，双向LSP仅在GMPLS中受支持。本文件未定义任何新程序或协议扩展，完全遵循提供规范性参考的文件。
The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices. For example, the dynamic provisioning performance metrics set out in [RFC5814] need to be understood in the context of LSP setup times and not in terms of control message exchange times that are actually only a component of the whole LSP establishment process.
本文件中的澄清也可用于帮助解释MPLS-TE和GMPLS设备的LSP建立性能数据。例如，[RFC5814]中规定的动态供应性能指标需要在LSP设置时间的上下文中理解，而不是在控制消息交换时间的上下文中理解，控制消息交换时间实际上只是整个LSP建立过程的一个组成部分。
Implementations could significantly benefit from this document definitively identifying any LSR to forward the Path or Resv message [RFC3473] before programming its cross-connect, thereby exploiting pipelining (i.e., doing one action in the background while another is progressing) to try to minimize the total time to set up the LSP. However, while this document gives advice and identifies the issues to be considered, it is not possible to make definitive statements about how much pipelining is safe, since a node cannot "know" much without first probing the network (for example, with protocol extensions) which would defeat the point of pipelining. Due to the number of variables introduced by path length, and other node behavior, ingress might be limited to a very pessimistic view for safety. Furthermore, it seems unlikely that an implementation would necessarily give a full and frank description of how long it takes to program and stabilize its cross-connects. Nevertheless, this document identifies the issues and opportunities for pipelining in GMPLS systems.
在编程交叉连接之前，本文档明确识别任何LSR以转发路径或Resv消息[RFC3473]，从而利用流水线（即，在后台执行一个操作，而另一个操作正在进行）来尽量减少设置LSP的总时间，这将大大有助于实现。然而，尽管本文档给出了建议并确定了要考虑的问题，但不可能对管道的安全程度做出明确的陈述，因为节点在不首先探测网络（例如，使用协议扩展）的情况下无法“知道”太多，这将破坏管道点。由于路径长度和其他节点行为引入的变量数量，入口可能被限制在非常悲观的安全视图内。此外，一个实现似乎不太可能对编程和稳定交叉连接所需的时间进行完整而坦率的描述。然而，本文件确定了GMPLS系统中管道的问题和机会。
It is assumed that the reader is familiar with the basic message flows of RSVP-TE as used in MPLS-TE and GMPLS. Refer to [RFC2205], [RFC3209], [RFC3471], and [RFC3473] for more details.
假设读者熟悉MPLS-TE和GMPLS中使用的RSVP-TE的基本消息流。有关更多详细信息，请参阅[RFC2205]、[RFC3209]、[RFC3471]和[RFC3473]。
In the context of this document, the concept of a "cross-connection" should be taken to imply the data forwarding instructions installed (that is, "programmed") at a network node (or "switch").
在本文件的上下文中，“交叉连接”的概念应理解为在网络节点（或“交换机”）上安装（即“编程”）的数据转发指令。
In packet MPLS networks, this is often referred to as the Incoming Label Map (ILM) and Next Hop Label Forwarding Entry (NHLFE) [RFC3031] which are sometimes considered together as entries in the Label Forwarding Information Base (LFIB) [RFC4221]. Where there is
在分组MPLS网络中，这通常被称为传入标签映射（ILM）和下一跳标签转发条目（NHLFE）[RFC3031]，它们有时被视为标签转发信息库（LFIB）[RFC4221]中的条目。哪里有
admission control and resource reservation associated with the data forwarding path (such as the allocation of data buffers) [RFC3209], this can be treated as part of the cross-connect programming process since the LSP will not be available to forward data in the manner agreed to during the signaling protocol exchange until the resources are correctly allocated and reserved.
与数据转发路径相关联的许可控制和资源保留（例如数据缓冲区的分配）[RFC3209]，这可以被视为交叉连接编程过程的一部分，因为在正确分配和保留资源之前，LSP将无法以信令协议交换期间商定的方式转发数据。
In non-packet networks (such as time-division multiplexing, or optical switching networks), the cross-connect concept may be an electronic cross-connect array or a transparent optical device (such as a microelectromechanical system (MEMS)). In all cases, however, the concept applies to the instructions that are programmed into the forwarding plane (that is, the data plane) so that incoming data for the LSP on one port can be correctly handled and forwarded out of another port.
在非分组网络（例如时分复用或光交换网络）中，交叉连接概念可以是电子交叉连接阵列或透明光学设备（例如微电子机械系统（MEMS））。然而，在所有情况下，该概念适用于编程到转发平面（即数据平面）中的指令，以便一个端口上LSP的传入数据可以正确处理并从另一个端口转发出去。
[RFC3209] describes the RSVP-TE signaling and processing for MPLS-TE packet-based networks. LSPs in these networks are unidirectional by definition (there are no bidirectional capabilities in [RFC3209]).
[RFC3209]描述了基于MPLS-TE分组网络的RSVP-TE信令和处理。根据定义，这些网络中的LSP是单向的（在[RFC3209]中没有双向功能）。
Section 4.1.1.1 of [RFC3209] describes a node's process prior to sending a Resv message to its upstream neighbor.
[RFC3209]第4.1.1.1节描述了向其上游邻居发送Resv消息之前的节点过程。
The node then sends the new LABEL object as part of the Resv message to the previous hop. The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message.
然后，节点将新标签对象作为Resv消息的一部分发送到上一个跃点。在发送Resv消息之前，节点应准备转发带有指定标签的数据包。
This means that the cross-connect should be in place to support traffic that may arrive at the node before the node sends the Resv. This is clearly advisable because the upstream LSRs might otherwise complete their cross-connections more rapidly and encourage the ingress to start transmitting data with the risk that the node that sent the Resv "early" would be unable to forward the data it received and would be forced to drop it, or might accidentally send it along the wrong LSP because of stale cross-connect information.
这意味着交叉连接应该到位，以支持可能在节点发送Resv之前到达节点的流量。这显然是可取的，因为上游lsr可能以其他方式更快地完成其交叉连接，并鼓励入口开始传输数据，其风险是发送Resv“早”的节点将无法转发其接收的数据，并将被迫丢弃该数据，或者可能由于过时的交叉连接信息而意外地将其发送到错误的LSP。
The use of "SHOULD" [RFC2119] in this text indicates that an implementation could be constructed that sends a Resv before it is ready to receive and forward data. This might be done simply because the internal construction of the node means that the control-plane components cannot easily tell when the cross-connection has been installed. Alternatively, it might arise because the implementation is aware that it will be slow and does not wish to hold up the establishment of the LSP. In this latter case, the implementation is choosing to pipeline the cross-connect programming with the protocol
在本文中使用“应该”[RFC2119]表示可以构造一个实现，在准备接收和转发数据之前发送Resv。这可能仅仅是因为节点的内部构造意味着控制平面组件无法轻松判断何时安装了交叉连接。或者，它可能会出现，因为实施过程中意识到它会很慢，并且不希望阻碍LSP的建立。在后一种情况下，实现选择将交叉连接编程与协议进行管道化
exchange taking a gamble that there will be other upstream LSRs that may also take some time to process, and it will in any case be some time before the ingress actually starts to send data. It should be noted that, as well as the risks described in the previous paragraph, a node that behaves like this must include a mechanism to report a failure to chase the Resv message (using a PathErr) in the event that the pipelined cross-connect processing fails.
exchange正在冒险，可能会有其他上游LSR也需要一些时间来处理，而且在任何情况下，在入口实际开始发送数据之前都需要一段时间。应该注意的是，除了上一段中描述的风险外，行为类似于此的节点必须包括一种机制，以便在管道交叉连接处理失败时报告跟踪Resv消息的失败（使用PathErr）。
GMPLS [RFC3945] extends RSVP-TE signaling for use in networks of different technologies [RFC3471] [RFC3473]. This means that RSVP-TE signaling may be used in MPLS packet switching networks, as well as layer two networks (Ethernet, Frame Relay, ATM), time-division multiplexing networks (Time Division Multiplexer (TDM), i.e., Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH)), Wavelength Division Multiplexing (WDM) networks, and fiber switched network.
GMPLS[RFC3945]扩展了RSVP-TE信令，用于不同技术的网络[RFC3471][RFC3473]。这意味着RSVP-TE信令可用于MPLS分组交换网络，以及第二层网络（以太网、帧中继、ATM）、时分复用网络（时分复用器（TDM），即同步光网络（SONET）和同步数字体系（SDH））、波分复用（WDM）网络，光纤交换网络。
The introduction of these other technologies, specifically the optical technologies, brings about the second definition of the "safe" commencement of data transmission as described in Section 1. That is, there is a physical safety issue that means that the lasers should not be enabled until the cross-connects are correctly in place.
这些其他技术，特别是光学技术的引入，带来了第1节所述的数据传输“安全”开始的第二个定义。也就是说，存在物理安全问题，这意味着在交叉连接正确就位之前，不应启用激光器。
GMPLS supports unidirectional and bidirectional LSPs. These are split into separate sections for discussion. The processing rules are inherited from [RFC3209] unless they are specifically modified by [RFC3471] and [RFC3473].
GMPLS支持单向和双向LSP。这些内容分为单独的部分进行讨论。处理规则从[RFC3209]继承，除非[RFC3471]和[RFC3473]专门修改。
Unidirectional LSP processing would be the same as that described in Section 2 except for the use of the Suggested_Label object defined in [RFC3473]. This object allows an upstream LSR to 'suggest' to its downstream neighbor the label that should be used for forward-direction data by including the object on a Path message. The purpose of this object is to help the downstream LSR in its choice of label, but it also makes it possible for the upstream LSR to 'pipeline' programming its cross-connect with the RSVP-TE signaling exchanges. That means that the cross-connect might be in place before the signaling has completed (i.e., before a Resv message carrying a Label object has been received at the upstream LSR).
除了使用[RFC3473]中定义的建议_标签对象外，单向LSP处理与第2节中描述的相同。此对象允许上游LSR通过将对象包含在路径消息中，向其下游邻居“建议”应用于正向数据的标签。该目标的目的是帮助下游LSR选择标签，但也使上游LSR能够“管道”编程其与RSVP-TE信令交换的交叉连接。这意味着交叉连接可能在信令完成之前就位（即，在上游LSR处接收到携带标签对象的Resv消息之前）。
We need to know when it is safe to start sending data. There are three sources of information.
我们需要知道何时开始发送数据是安全的。有三个信息来源。
- Section 3.4 of [RFC3471] states:
- [RFC3471]第3.4节规定：
In particular, an ingress node should not transmit data traffic on a suggested label until the downstream node passes a label upstream.
特别是，入口节点不应在建议的标签上传输数据流量，直到下游节点通过上游标签。
The implication here is that an ingress node may (safely) start to transmit data when it receives a label in a Resv message.
这里的含义是，入口节点可以（安全地）在接收到Resv消息中的标签时开始传输数据。
- Section 2.5 of [RFC3473] states:
- [RFC3473]第2.5节规定：
Furthermore, an ingress node SHOULD NOT transmit data traffic using a suggested label until the downstream node passes a corresponding label upstream.
此外，入口节点不应使用建议的标签发送数据流量，直到下游节点通过相应的上游标签。
This is a confirmation of the first source.
这是对第一个来源的确认。
- Section 4.1.1.1 of [RFC3209] states:
- [RFC3209]第4.1.1.1节规定：
The node then sends the new LABEL object as part of the Resv message to the previous hop. The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message.
然后，节点将新标签对象作为Resv消息的一部分发送到上一个跃点。在发送Resv消息之前，节点应准备转发带有指定标签的数据包。
In this text, the word "prior" is very important. It means that the cross-connect must be in place for forward traffic before the Resv is sent. In other words, each of the transit nodes and the egress node must finish making their cross-connects before they send the Resv message to their upstream neighbors.
在本文中，“优先”一词非常重要。这意味着在发送Resv之前，必须为转发流量建立交叉连接。换句话说，每个中转节点和出口节点必须在向其上游邻居发送Resv消息之前完成交叉连接。
Thus, as in Section 2, we can deduce that the ingress must not start to transmit traffic until it has both received a Resv and has programmed its own cross-connect.
因此，如第2节所述，我们可以推断，入口必须在接收到Resv并对其自身的交叉连接进行编程之前，才能开始传输流量。
A bidirectional LSP is established with one signaling exchange of a Path message from ingress to egress, and a Resv from egress to ingress. The LSP itself is comprised of two sets of forwarding state, one providing a path from the ingress to the egress (the forwards data path), and one from the egress to the ingress (the reverse data path).
通过从入口到出口的路径消息和从出口到入口的Resv的一次信令交换来建立双向LSP。LSP本身由两组转发状态组成，一组提供从入口到出口的路径（转发数据路径），另一组提供从出口到入口的路径（反向数据路径）。
The processing for the forwards direction data path is exactly as described for a unidirectional LSP in Section 3.1.
正向数据路径的处理与第3.1节中对单向LSP的描述完全相同。
For the reverse direction data flow, an Upstream_Label object is carried in the Path message from each LSR to its downstream neighbor. The Upstream_Label object tells the downstream LSR which label to use for data being sent to the upstream LSR (that is, reverse direction data). The use of the label is confirmed by the downstream LSR when it sends a Resv message. Note that there is no explicit confirmation of the label in the Resv message, but if the label was not acceptable to the downstream LSR, it would return a PathErr message instead.
对于反向数据流，在从每个LSR到其下游邻居的路径消息中携带上游_标签对象。上游标签对象告诉下游LSR将哪个标签用于发送到上游LSR的数据（即反向数据）。下游LSR在发送Resv消息时确认标签的使用。请注意，Resv消息中没有对标签的明确确认，但如果下游LSR不接受标签，它将返回PathErr消息。
The upstream LSR must decide when to send the Path message relative to when it programs its cross-connect. That is:
上游LSR必须决定何时发送路径消息，相对于其编程交叉连接的时间。即:
- Should it program the cross-connect before it sends the Path message;
- 是否应在发送路径消息之前对交叉连接进行编程；
- Can it overlap the programming with the exchange of messages; or
- 它是否可以将编程与消息交换重叠；或
- Must it wait until it receives a Resv from its downstream neighbor?
- 它必须等到收到下游邻居的Resv吗？
The defining reference is Section 3.1 of [RFC3473]:
定义参考是[RFC3473]的第3.1节：
The Upstream_Label object MUST indicate a label that is valid for forwarding at the time the Path message is sent.
上游标签对象必须指示在发送路径消息时可有效转发的标签。
In this text, "valid for forwarding" should be taken to mean that it is safe for the LSR that sends the Path message to receive data, and that the LSR will forward data correctly. The text does not mean that the label is "acceptable for use" (i.e., the label is available to be cross-connected).
在本文中，“有效转发”应表示发送路径消息的LSR可以安全地接收数据，并且LSR将正确转发数据。文本并不意味着标签“可接受使用”（即标签可交叉连接）。
This point is clarified later in Section 3.1 of [RFC3473]:
[RFC3473]的第3.1节对这一点进行了澄清：
Terminator nodes process Path messages as usual, with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator.
终止节点像往常一样处理路径消息，但上游标签可立即用于将与LSP上游相关联的数据通信量传输到启动器。
This is a clear statement that when a Path message has been fully processed by an egress node, it is completely safe to transmit data toward the ingress (i.e., reverse direction data).
这是一个明确的声明，即当出口节点已完全处理路径消息时，向入口传输数据（即反向数据）是完全安全的。
From this we can deduce several things:
由此我们可以推断出几件事：
- An LSR must not wait to receive a Resv message before it programs the cross-connect for the reverse direction data. It must be ready to receive data from the moment that the egress completes processing the Path message that it receives (i.e., before it sends a Resv back upstream).
- LSR在为反向数据编程交叉连接之前，不得等待接收Resv消息。它必须准备好从出口完成处理它接收的路径消息的那一刻（即，在它向上游发送Resv之前）开始接收数据。
- An LSR may expect to start receiving reverse direction data as soon as it sends a Path message for a bidirectional LSP.
- 一旦LSR发送双向LSP的路径消息，它就可以期望开始接收反向数据。
- An LSR may make some assumptions about the time lag between sending a Path message and the message reaching and being processed by the egress. It may take advantage of this time lag to pipeline programming the cross-connect.
- LSR可以对发送路径消息和消息到达出口并由出口处理之间的时间间隔做出一些假设。它可以利用这个时间延迟来对交叉连接进行管道编程。
The ResvConf message is used in standard RSVP [RFC2205] to let the ingress confirm to the egress that the Resv has been successfully received, and what bandwidth has been reserved. In RSVP-TE [RFC3209] and GMPLS [RFC3473], it is not expected that bandwidth will be modified along the path of the LSP, so the purpose of the ResvConf is reduced to a confirmation that the LSP has been successfully established.
在标准RSVP[RFC2205]中使用ResvConf消息，让入口向出口确认Resv已成功接收，以及保留了什么带宽。在RSVP-TE[RFC3209]和GMPLS[RFC3473]中，预计带宽不会沿着LSP的路径进行修改，因此ResvConf的目的减少为确认LSP已成功建立。
The egress may request that a ResvConf be sent by including a Resv_Confirm object in the Resv message that it sends. When the ingress receives the Resv message and sees the Resv_Confirm object, it can respond with a ResvConf message.
出口可以通过在其发送的Resv消息中包括Resv_确认对象来请求发送ResvConf。当入口接收到Resv消息并看到Resv_确认对象时，它可以使用ResvConf消息进行响应。
It should be clear that this mechanism might provide a doubly secure way for the egress to ensure that the reverse direction data path is safely in place before transmitting data. That is, if the egress waits until it receives a ResvConf message, it can be sure that the whole LSP is in place.
应该清楚的是，该机制可能为出口提供双重安全方式，以确保在传输数据之前反向数据路径安全就位。也就是说，如果出口等待直到接收到ResvConf消息，则可以确保整个LSP都已就位。
However, this mechanism is excessive given the definitions presented in Section 3.2.2, and would delay LSP setup by one end-to-end message propagation cycle. It should be noted as well that the generation and of the ResvConf message is not guaranteed. Furthermore, many (if not most) GMPLS implementations neither request nor send ResvConf messages. Therefore, egress reliance on the receipt of a ResvConf as a way of knowing that it is safe to start transmitting reverse direction data is not recommended.
然而，鉴于第3.2.2节中给出的定义，这种机制是过度的，并且会将LSP设置延迟一个端到端消息传播周期。还应注意的是，ResvConf消息的生成和发送不受保证。此外，许多（如果不是大多数的话）GMPLS实现既不请求也不发送ResvConf消息。因此，不建议将出口依赖于ResvConf的接收作为知道开始传输反向数据是安全的一种方式。
GMPLS offers an additional tool for ensuring safety of the LSP. The Administrative Status information is defined in Section 8 of [RFC3471] and is carried in the Admin_Status Object defined in Section 7 of [RFC3473].
GMPLS为确保LSP的安全提供了额外的工具。管理状态信息在[RFC3471]的第8节中定义，并包含在[RFC3473]的第7节中定义的管理状态对象中。
This object allows an ingress to set up an LSP in "Administratively Down" state. This state means that [RFC3471]:
此对象允许入口在“管理关闭”状态下设置LSP。此状态表示[RFC3471]：
... the local actions related to the "administratively down" state should be taken.
... 应采取与“行政关闭”状态相关的地方行动。
In this state, it is assumed that the LSP exists (i.e., the cross-connects are all in place), but no data is transmitted (i.e., in optical systems, the lasers are off).
在此状态下，假设存在LSP（即交叉连接全部就位），但不传输数据（即，在光学系统中，激光器关闭）。
Additionally, the Admin_Status object allows the LSP to be put into "Testing" state. This state means ([RFC3471]) that:
此外，Admin_Status对象允许LSP进入“测试”状态。该状态表示（[RFC3471]）：
... the local actions related to the "testing" mode should be taken.
... 应采取与“测试”模式相关的本地措施。
This state allows the connectivity of the LSP to be tested without actually exchanging user data. For example, in an optical system, it would be possible to run a data continuity test (using some external coordination of errors). In a packet network, a connection verification exchange (such as the in-band Virtual Circuit Connectivity Verification described in Section 5.1.1 of [RFC5085]) could be used. Once connectivity has been verified, the LSP could be put into active mode and the exchange of user data could commence.
此状态允许在不实际交换用户数据的情况下测试LSP的连接性。例如，在光学系统中，可以运行数据连续性测试（使用一些外部误差协调）。在分组网络中，可以使用连接验证交换（如[RFC5085]第5.1.1节所述的带内虚拟电路连接验证）。一旦连接得到验证，LSP就可以进入活动模式，并开始用户数据交换。
These processes may be considered particularly important in systems where the control-plane processors are physically distinct from the data-plane cross-connects (for example, where there is a communication protocol operating between the control-plane processor and the data-plane switch) in which case the successful completion of control-plane signaling cannot necessarily be taken as evidence of correct data-plane programming.
在控制平面处理器在物理上不同于数据平面交叉连接的系统中（例如，在控制平面处理器和数据平面交换机之间存在通信协议的情况下），这些过程可能被认为是特别重要的在这种情况下，控制平面信令的成功完成不一定是正确数据平面编程的证据。
The ability of LSRs to handle and propagate control-plane messages and to program cross-connects varies considerably from device to device according to switching technology, control-plane connectivity, and implementation. These factors influence how quickly an LSP can be established.
根据交换技术、控制平面连接和实现，LSR处理和传播控制平面消息以及编程交叉连接的能力因设备而异。这些因素会影响LSP的建立速度。
Different applications have different requirements for the speed of setup of LSPs, and this may be particularly important in recovery scenarios. It is important for service providers considering the deployment of MPLS-TE or GMPLS equipment to have a good benchmark for the performance of the equipment. Similarly, it is important for equipment vendors to be compared on a level playing field.
不同的应用程序对LSP的设置速度有不同的要求，这在恢复场景中可能特别重要。对于考虑部署MPLS-TE或GMPLS设备的服务提供商来说，重要的是要有一个良好的设备性能基准。同样，在公平竞争的环境中比较设备供应商也很重要。
In order to provide a basis for comparison, [RFC5814] defines a series of performance metrics to evaluate dynamic LSP provisioning performance in MPLS-TE/GMPLS networks. Any use of such metrics must be careful to understand what is being measured, bearing in mind that it is not enough to know that the control-plane message has been processed and forwarded: the cross-connect must be put in place before the LSP can be used. Thus, care must be taken to ensure that devices are correctly conforming to the procedures clarified in Section 2 of this document, and not simply forwarding control-plane messages with the intent to program the cross-connects in the background.
为了提供比较依据，[RFC5814]定义了一系列性能指标，以评估MPLS-TE/GMPLS网络中的动态LSP供应性能。使用此类指标时必须小心，以了解所测量的内容，记住，仅知道控制平面消息已被处理和转发是不够的：必须在使用LSP之前建立交叉连接。因此，必须注意确保设备正确符合本文件第2节中阐明的程序，而不仅仅是为了在后台编程交叉连接而转发控制平面消息。
This document does not define any network behavior and does not introduce or seek to solve any security issues.
本文档未定义任何网络行为，也未介绍或试图解决任何安全问题。
It may be noted that a clear understanding of when to start sending data may reduce the risk of data being accidentally delivered to the wrong place or individuals being hurt.
可能需要注意的是，清楚地了解何时开始发送数据可能会降低数据意外发送到错误位置或个人受到伤害的风险。
Thanks to Weiqiang Sun, Olufemi Komolafe, Daniel King, and Stewart Bryant for their review and comments.
感谢孙维强、科莫拉菲、丹尼尔·金和斯图尔特·布莱恩特的评论和评论。
[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月。
[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月。
[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月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[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月。
[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", RFC 4221, November 2005.
[RFC4221]Nadeau，T.，Srinivasan，C.，和A.Farrel，“多协议标签交换（MPLS）管理概述”，RFC 42212005年11月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]Nadeau，T.，Ed.，和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[RFC5814] Sun, W., Ed., and G. Zhang, Ed., "Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks", RFC 5814, March 2010.
[RFC5814]Sun，W.，Ed.，和G.Zhang，Ed.，“广义MPLS网络中的标签交换路径（LSP）动态资源调配性能指标”，RFC 5814，2010年3月。
Authors' Addresses
作者地址
Kohei Shiomoto NTT Service Integration Laboratories 3-9-11 Midori Musashino, Tokyo 180-8585 Japan Phone: +81 422 59 4402 EMail: shiomoto.kohei@lab.ntt.co.jp
Kohei Shiomoto NTT服务集成实验室3-9-11 Midori Musashino，东京180-8585日本电话：+81 422 59 4402电子邮件：Shiomoto。kohei@lab.ntt.co.jp
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk