Internet Engineering Task Force (IETF) JP. Vasseur, Ed.
Request for Comments: 5711 G. Swallow
Updates: 3209 Cisco Systems, Inc.
Category: Standards Track I. Minei
ISSN: 2070-1721 Juniper Networks
January 2010
Internet Engineering Task Force (IETF) JP. Vasseur, Ed.
Request for Comments: 5711 G. Swallow
Updates: 3209 Cisco Systems, Inc.
Category: Standards Track I. Minei
ISSN: 2070-1721 Juniper Networks
January 2010
Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages
发起和接收资源预留协议（RSVP）路径错误消息时的节点行为
Abstract
摘要
The aim of this document is to describe a common practice with regard to the behavior of nodes that send and receive a Resource Reservation Protocol (RSVP) Traffic Engineering (TE) Path Error messages for a preempted Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see RFC 3209.) This document does not define any new protocol extensions.
本文档的目的是描述关于发送和接收抢占多协议标签交换（MPLS）或通用MPLS（GMPLS）流量工程标签交换路径（TE LSP）的资源预留协议（RSVP）流量工程（TE）路径错误消息的节点行为的通用实践。（有关TE LSP抢占的概念，请参阅RFC 3209。）本文档未定义任何新的协议扩展。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc5711.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5711.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
2. Protocol Behavior ...............................................3
2.1. Behavior at Detecting Nodes ................................4
2.2. Behavior at Receiving Nodes ................................5
2.3. Data-Plane Behavior ........................................5
3. RSVP PathErr Messages for a Preempted TE LSP ....................5
4. Security Considerations .........................................5
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
2. Protocol Behavior ...............................................3
2.1. Behavior at Detecting Nodes ................................4
2.2. Behavior at Receiving Nodes ................................5
2.3. Data-Plane Behavior ........................................5
3. RSVP PathErr Messages for a Preempted TE LSP ....................5
4. Security Considerations .........................................5
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
The aim of this document is to describe a common practice with regard to the behavior of a node sending a Resource Reservation Protocol (RSVP) Traffic Engineering (TE) Path Error message and to the behavior of a node receiving an RSVP Path Error message for a preempted Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see [RFC3209]).
本文档的目的是描述有关发送资源预留协议（RSVP）流量工程（TE）路径错误消息的节点行为以及接收抢占多协议标签交换（MPLS）和通用MPLS（GMPLS）的RSVP路径错误消息的节点行为的通用实践流量工程标签交换路径（TE LSP）。（关于TE LSP抢占的概念，请参见[RFC3209]）。
[RFC2205] defines two RSVP error message types: PathErr and ResvErr that are generated when an error occurs. Path Error messages (PathErr) are used to report errors and travel upstream toward the head-end of the flow. Resv Error messages (ResvErr) travel downstream toward the tail-end of the flow.
[RFC2205]定义了两种RSVP错误消息类型：PathErr和ResvErr，在发生错误时生成。路径错误消息（PathErr）用于报告错误，并向上游流向流的前端。Resv错误消息（ResvErr）向下游流向流的尾端。
This document describes only PathErr message processing for the specific case of a preempted TE LSP, where the term preemption is defined in [RFC3209].
本文档仅描述抢占TE LSP特定情况下的PathErr消息处理，抢占一词在[RFC3209]中定义。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
PathErr messages are routed hop-by-hop using the path state established when a Path message is routed through the network from the head-end to its tail-end.
PathErr消息使用路径消息通过网络从前端路由到后端时建立的路径状态逐跳路由。
As stated in [RFC2205], PathErr messages do not modify the state of any node through which they pass; they are only reported to the head-end of the TE LSP (Traffic Engineering Label Switched Path).
如[RFC2205]所述，PathErr消息不会修改它们所通过的任何节点的状态；它们仅报告给TE LSP（流量工程标签交换路径）的前端。
The format of the PathErr message is defined in Section 3. of [RFC2205].
PathErr消息的格式在第3节中定义。属于[RFC2205]。
The ERROR_SPEC object includes the IP address of the node that detected the error (Error Node Address), and specifies the error through two fields. The Error Code field encodes the category of the error, for example, Policy Control Failure or Unknown object class. The Error Value field qualifies the error code to indicate the error with more precision. [RFC3209] extends RSVP as defined in [RFC2205] for the management of MPLS-TE LSPs. [RFC3209] specifies several additional conditions that trigger the sending of a RSVP PathErr message for which new error codes and error values have been defined
ERROR_SPEC对象包括检测到错误的节点的IP地址（ERROR node address），并通过两个字段指定错误。错误代码字段编码错误的类别，例如，策略控制失败或未知对象类。错误值字段限定错误代码，以更精确地指示错误。[RFC3209]扩展了[RFC2205]中定义的RSVP，用于管理MPLS-TE LSP。[RFC3209]指定触发发送RSVP PathErr消息的几个附加条件，已为其定义了新的错误代码和错误值
that extend the list defined in [RFC2205]. The exact circumstances under which a TE LSP is preempted and such PathErr messages are sent are defined in [RFC3209] and will not be repeated here.
扩展[RFC2205]中定义的列表。[RFC3209]中定义了TE LSP被抢占并发送此类PathErr消息的确切情况，此处不再重复。
Values for the Error Code and Error Value fields defined in [RFC2205], [RFC3209], and other documents are maintained in a registry by the IANA.
IANA在注册表中维护[RFC2205]、[RFC3209]和其他文档中定义的错误代码和错误值字段的值。
The error conditions fall into two categories:
错误情况分为两类：
o Fatal errors represent disruptive conditions for a TE LSP.
o 致命错误表示TE LSP的中断条件。
o Non-fatal errors are non-disruptive conditions that have occurred for this TE LSP.
o 非致命错误是此TE LSP发生的无中断情况。
PathErr messages may be used in two circumstances:
PathErr消息可用于两种情况：
o during TE LSP establishment, and
o 在TE LSP建立期间，以及
o after a TE LSP has been successfully established.
o 成功建立TE LSP后。
Nodal behavior is dependent on which combination of the four cases listed above applies. The following sections describe the expected behavior at nodes that perform a preemption action for a TE LSP (and therefore report using error PathErr messages), and at nodes that receive PathErr messages. This text is a clarification and restatement of the procedures set out in [RFC3209] and does not define any new behavior.
节点行为取决于上述四种情况的组合。以下各节描述了对TE LSP执行抢占操作的节点（因此使用错误PathErr消息进行报告）和接收PathErr消息的节点的预期行为。本文是对[RFC3209]中规定的程序的澄清和重述，未定义任何新行为。
In the case of fatal errors ("Hard Preemption"; see Section 4.7.3 of [RFC3209] ), the detecting node MUST send a PathErr message reporting the error condition, and MUST clear the corresponding Path and Resv (control plane) states. A direct implication is that the data-plane resources of such a TE LSP are also released, thus resulting in traffic disruption. It should be noted, however, that in fatal error cases, the LSP has usually already failed in the data plane, and traffic has already been disrupted. When the error arises during LSP establishment, the implications are different to when it arises on an active LSP since no traffic flows until the LSP has been fully established. In the case of non-fatal errors, the detecting node should send a PathErr message, and must not clear control plane or data plane state.
如果出现致命错误（“硬抢占”；参见[RFC3209]第4.7.3节），检测节点必须发送一条PathErr消息，报告错误情况，并且必须清除相应的路径和Resv（控制平面）状态。直接的含义是这样的TE-LSP的数据平面资源也被释放，从而导致通信中断。然而，应该注意的是，在致命错误的情况下，LSP通常已经在数据平面中失败，并且通信已经中断。当错误在LSP建立期间出现时，其含义与在活动LSP上出现时不同，因为在LSP完全建立之前没有业务流。在非致命错误的情况下，检测节点应发送PathErr消息，并且不得清除控制平面或数据平面状态。
Nodes that receive PathErr messages are all of the nodes along the path of the TE LSP upstream of the node that detected the error. This includes the head-end node. In accordance with Section 3.7.1 of [RFC2205], a node receiving a PathErr message takes no action upon it, and consequently the node must not clear Path or Resv control-plane or data-plane state. This is true regardless of whether the error condition reported by the PathErr is fatal or non-fatal. RSVP states should only be affected upon receiving a PathTear or ResvTear message, or in the event of a Path or Resv state timeout. Further discussion of the processing of these events is outside the scope of this document.
接收PathErr消息的节点是检测到错误的节点上游TE LSP路径上的所有节点。这包括头端节点。根据[RFC2205]第3.7.1节，接收PathErr消息的节点不对其采取任何行动，因此该节点不得清除路径或Resv控制平面或数据平面状态。无论PathErr报告的错误条件是致命的还是非致命的，这都是正确的。RSVP状态只应在接收到PathTear或ResvTear消息时，或在发生路径或Resv状态超时时才受影响。对这些事件处理的进一步讨论不在本文件范围内。
Note that [RFC3473] defines a Path_State_Removed flag in the ERROR_SPEC object carried on a PathErr message. This field may be set to change the behavior of upstream nodes that receive the PathErr message. When set, the flag indicates that the message sender has removed Path state (and any associated Resv and data-plane state) for the TE LSP. The message receiver should do likewise before forwarding the message, but may retain state and clear the flag before forwarding the message.
请注意，[RFC3473]在PathErr消息中携带的ERROR_SPEC对象中定义了Path_State_Removed标志。此字段可设置为更改接收PathErr消息的上游节点的行为。设置后，该标志表示消息发送方已删除TE LSP的路径状态（以及任何关联的Resv和数据平面状态）。消息接收者在转发消息之前也应该这样做，但可以在转发消息之前保留状态并清除标志。
Any node clearing either or both the Path or the Resv state of a TE LSP MUST also free up the data-plane resources allocated to the corresponding TE LSP.
清除TE LSP的路径或Resv状态之一或两者的任何节点也必须释放分配给相应TE LSP的数据平面资源。
Two Error Codes have been defined to report a preempted TE LSP:
已定义两个错误代码来报告抢占TE LSP：
o As defined in [RFC2750]: Error Code=2: "Policy Control Failure", Error Value=5: "Flow was preempted"
o 如[RFC2750]中所定义：错误代码=2：“策略控制失败”，错误值=5：“流被抢占”
o As defined in [RFC2205], Error Code=12: "Service preempted"
o 如[RFC2205]中所定义，错误代码=12：“服务被抢占”
They are both fatal errors.
它们都是致命的错误。
This document does not define any new procedures, but clarifies those defined in other documents where security considerations are already specified in [RFC3209] and [RFC3473]. This document does not raise specific security issues beyond those of existing MPLS-TE. By
本文件未定义任何新程序，但澄清了[RFC3209]和[RFC3473]中已规定安全注意事项的其他文件中定义的程序。除现有MPLS-TE的安全问题外，本文件并未提出其他具体的安全问题。通过
clarifying the procedures, this document reduces the security risk introduced by non-conformant implementations. See [SEC_FMWK] for further discussion of MPLS security issues.
本文档澄清了这些过程，从而降低了不一致实现带来的安全风险。有关MPLS安全问题的进一步讨论，请参见[SEC_FMWK]。
The authors would like to thank Carol Iturralde, Ashok Narayanan, Rom Reuther, and Reshad Rahman.
作者要感谢卡罗尔·伊图拉尔德、阿肖克·纳拉亚南、罗姆·鲁瑟和雷沙德·拉赫曼。
[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, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750]Herzog，S.，“策略控制的RSVP扩展”，RFC 2750，2000年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月。
[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月。
[SEC_FMWK] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, October 2009.
[SEC_FMWK]Fang，L.，Ed.，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2009年10月。
Authors' Addresses
作者地址
JP Vasseur (editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（编辑）思科系统公司，美国马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
乔治·斯沃诺思科系统公司，美国马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Ina Minei Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 USA
Ina Minei Juniper Networks美国加利福尼亚州桑尼维尔北马蒂尔达大道1194号，邮编94089
EMail: ina@juniper.net
EMail: ina@juniper.net