Network Working Group D. Papadimitriou
Request for Comments: 4974 Alcatel
Updates: 3473 A. Farrel
Category: Standards Track Old Dog Consulting
August 2007
Network Working Group D. Papadimitriou
Request for Comments: 4974 Alcatel
Updates: 3473 A. Farrel
Category: Standards Track Old Dog Consulting
August 2007
Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls
支持呼叫的通用MPLS（GMPLS）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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls.
在某些网络拓扑中，维护端点和关键传输点之间的关联以支持服务实例可能是有利的。这种关联称为调用。
A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs).
呼叫不提供传输用户流量的实际连接，而只是建立一种关系，通过这种关系可以进行后续连接。在通用MPLS（GMPLS）中，这种连接称为标签交换路径（LSP）。
This document specifies how GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation.
本文件规定了如何使用和扩展GMPLS资源预留协议-流量工程（RSVP-TE）信令以支持呼叫。这些机制提供完整的逻辑调用/连接分离。
The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching.
本文件中提出的机制适用于任何环境（包括多区域）和任何类型的接口：分组、第2层、时分复用、lambda或光纤交换。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Applicability to ASON ......................................4
2. Conventions Used in This document ...............................4
3. Requirements ....................................................4
3.1. Basic Call Function ........................................4
3.2. Call/Connection Separation .................................5
3.3. Call Segments ..............................................5
4. Concepts and Terms ..............................................5
4.1. What Is a Call? ............................................5
4.2. A Hierarchy of Calls, Connections, Tunnels, and LSPs .......6
4.3. Exchanging Access Link Capabilities ........................6
4.3.1. Network-Initiated Calls .............................7
4.3.2. User-Initiated Calls ................................7
4.3.3. Utilizing Call Setup ................................8
5. Protocol Extensions for Calls and Connections ...................8
5.1. Call Setup and Teardown ....................................8
5.2. Call Identification ........................................9
5.2.1. Long Form Call Identification .......................9
5.2.2. Short Form Call Identification ......................9
5.2.3. Short Form Call ID Encoding ........................10
5.3. LINK_CAPABILITY Object ....................................11
5.4. Revised Message Formats ...................................12
5.4.1. Notify Message .....................................12
5.5. ADMIN_STATUS Object .......................................13
6. Procedures in Support of Calls and Connections .................14
6.1. Call/Connection Setup Procedures ..........................14
6.2. Call Setup ................................................14
6.2.1. Accepting Call Setup ...............................16
6.2.2. Call Setup Failure and Rejection ...................16
6.3. Adding a Connections to a Call ............................17
6.3.1. Adding a Reverse Direction LSP to a Call ...........18
6.4. Call-Free Connection Setup ................................18
6.5. Call Collision ............................................18
6.6. Call/Connection Teardown ..................................19
6.6.1. Removal of a Connection from a Call ................20
6.6.2. Removal of the Last Connection from a Call .........20
6.6.3. Teardown of an "Empty" Call ........................20
6.6.4. Attempted Teardown of a Call with Existing
Connections ........................................20
6.6.5. Teardown of a Call from the Egress .................21
6.7. Control Plane Survivability ...............................21
7. Applicability of Call and Connection Procedures ................22
7.1. Network-Initiated Calls ...................................22
7.2. User-Initiated Calls ......................................23
7.3. External Call Managers ....................................23
7.3.1. Call Segments ......................................23
1. Introduction ....................................................3
1.1. Applicability to ASON ......................................4
2. Conventions Used in This document ...............................4
3. Requirements ....................................................4
3.1. Basic Call Function ........................................4
3.2. Call/Connection Separation .................................5
3.3. Call Segments ..............................................5
4. Concepts and Terms ..............................................5
4.1. What Is a Call? ............................................5
4.2. A Hierarchy of Calls, Connections, Tunnels, and LSPs .......6
4.3. Exchanging Access Link Capabilities ........................6
4.3.1. Network-Initiated Calls .............................7
4.3.2. User-Initiated Calls ................................7
4.3.3. Utilizing Call Setup ................................8
5. Protocol Extensions for Calls and Connections ...................8
5.1. Call Setup and Teardown ....................................8
5.2. Call Identification ........................................9
5.2.1. Long Form Call Identification .......................9
5.2.2. Short Form Call Identification ......................9
5.2.3. Short Form Call ID Encoding ........................10
5.3. LINK_CAPABILITY Object ....................................11
5.4. Revised Message Formats ...................................12
5.4.1. Notify Message .....................................12
5.5. ADMIN_STATUS Object .......................................13
6. Procedures in Support of Calls and Connections .................14
6.1. Call/Connection Setup Procedures ..........................14
6.2. Call Setup ................................................14
6.2.1. Accepting Call Setup ...............................16
6.2.2. Call Setup Failure and Rejection ...................16
6.3. Adding a Connections to a Call ............................17
6.3.1. Adding a Reverse Direction LSP to a Call ...........18
6.4. Call-Free Connection Setup ................................18
6.5. Call Collision ............................................18
6.6. Call/Connection Teardown ..................................19
6.6.1. Removal of a Connection from a Call ................20
6.6.2. Removal of the Last Connection from a Call .........20
6.6.3. Teardown of an "Empty" Call ........................20
6.6.4. Attempted Teardown of a Call with Existing
Connections ........................................20
6.6.5. Teardown of a Call from the Egress .................21
6.7. Control Plane Survivability ...............................21
7. Applicability of Call and Connection Procedures ................22
7.1. Network-Initiated Calls ...................................22
7.2. User-Initiated Calls ......................................23
7.3. External Call Managers ....................................23
7.3.1. Call Segments ......................................23
8. Non-Support of Call ID .........................................24
8.1. Non-Support by External Call Managers .....................24
8.2. Non-Support by Transit Node ...............................24
8.3. Non-Support by Egress Node ................................25
9. Security Considerations ........................................25
9.1. Call and Connection Security Considerations ...............25
10. IANA Considerations ...........................................26
10.1. RSVP Objects .............................................26
10.2. RSVP Error Codes and Error Values ........................27
10.3. RSVP ADMIN_STATUS Object Bits ............................27
11. Acknowledgements ..............................................27
12. References ....................................................28
12.1. Normative References .....................................28
12.2. Informative References ...................................29
8. Non-Support of Call ID .........................................24
8.1. Non-Support by External Call Managers .....................24
8.2. Non-Support by Transit Node ...............................24
8.3. Non-Support by Egress Node ................................25
9. Security Considerations ........................................25
9.1. Call and Connection Security Considerations ...............25
10. IANA Considerations ...........................................26
10.1. RSVP Objects .............................................26
10.2. RSVP Error Codes and Error Values ........................27
10.3. RSVP ADMIN_STATUS Object Bits ............................27
11. Acknowledgements ..............................................27
12. References ....................................................28
12.1. Normative References .....................................28
12.2. Informative References ...................................29
This document defines protocol procedures and extensions to support Calls within Generalized MPLS (GMPLS).
本文档定义了支持通用MPLS（GMPLS）内呼叫的协议过程和扩展。
A Call is an association between endpoints and possibly between key transit points (such as network boundaries) in support of an instance of a service. The end-to-end association is termed a "Call", and the association between two transit points or between an endpoint and a transit point is termed a "Call Segment". An entity that processes a Call or Call Segment is called a "Call Manager".
调用是端点之间的关联，也可能是支持服务实例的关键传输点（如网络边界）之间的关联。端到端关联称为“呼叫”，两个中转点之间或端点与中转点之间的关联称为“呼叫段”。处理呼叫或呼叫段的实体称为“呼叫管理器”。
A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In GMPLS, such Connections are known as Label Switched Paths (LSPs). This document does not modify Connection setup procedures defined in [RFC3473], [RFC4208], and [STITCH]. Connections set up as part of a Call follow the rules defined in these documents.
呼叫不提供传输用户流量的实际连接，而只是建立一种关系，通过这种关系可以进行后续连接。在GMPLS中，这种连接称为标签交换路径（LSP）。本文件不修改[RFC3473]、[RFC4208]和[STITCH]中定义的连接设置程序。作为呼叫的一部分设置的连接遵循这些文档中定义的规则。
A Call may be associated with zero, one, or more than one Connection, and a Connection may be associated with zero or one Call. Thus, full and logical Call/Connection separation is needed.
一个呼叫可以与零个、一个或多个连接相关联，而一个连接可以与零个或一个呼叫相关联。因此，需要完全的逻辑呼叫/连接分离。
An example of the requirements for Calls can be found in the ITU-T's Automatically Switched Optical Network (ASON) architecture [G.8080] and specific requirements for support of Calls in this context can be found in [RFC4139]. Note, however, that while the mechanisms described in this document meet the requirements stated in [RFC4139], they have wider applicability.
呼叫要求的示例可在ITU-T的自动交换光网络（ASON）架构[G.8080]中找到，在这种情况下支持呼叫的具体要求可在[RFC4139]中找到。然而，请注意，尽管本文件中描述的机制满足[RFC4139]中规定的要求，但它们具有更广泛的适用性。
The mechanisms defined in this document are equally applicable to any packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable interfaces, LSC interfaces, or FSC interfaces. The mechanisms and protocol extensions are backward compatible, and can be used for Call management where only the Call Managers need to be aware of the protocol extensions.
本文件中定义的机制同样适用于任何数据包（PSC）接口、第二层接口（L2SC）、支持TDM的接口、LSC接口或FSC接口。这些机制和协议扩展是向后兼容的，并且可以用于只有呼叫管理器需要知道协议扩展的呼叫管理。
[RFC4139] details the requirements on GMPLS signaling to satisfy the ASON architecture described in [G.8080]. The mechanisms described in this document meet the requirements for Calls as described in Sections 4.2 and 4.3 of [RFC4139] and the additional Call-related requirements in Sections 4.4, 4.7, 5, and 6 of [RFC4139].
[RFC4139]详细说明了GMPLS信令的要求，以满足[G.8080]中描述的ASON架构。本文件中描述的机制满足[RFC4139]第4.2节和第4.3节中描述的呼叫要求以及[RFC4139]第4.4节、第4.7节、第5节和第6节中与呼叫相关的附加要求。
[ASON-APPL] describes the applicability of GMPLS protocols to the ASON architecture.
[ASON-APPL]描述了GMPLS协议对ASON架构的适用性。
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]中所述进行解释。
In addition, the reader is assumed to be familiar with the terminology used in [RFC3471], [RFC3473], [RFC3477], and [RFC3945].
此外，假定读者熟悉[RFC3471]、[RFC3473]、[RFC3477]和[RFC3945]中使用的术语。
The Call concept is used to deliver the following capabilities:
呼叫概念用于提供以下功能：
- Verification and identification of the Call initiator (prior to LSP setup).
- 验证和识别呼叫发起人（在LSP设置之前）。
- Support of virtual concatenation with diverse path component LSPs.
- 支持使用不同路径组件LSP进行虚拟连接。
- Association of multiple LSPs with a single Call (note aspects related to recovery are detailed in [RFC4426] and [GMPLS-E2E]).
- 多个LSP与单个呼叫的关联（注意与恢复相关的方面详见[RFC4426]和[GMPLS-E2E]）。
- Facilitation of control plane operations by allowing an operational status change of the associated LSP.
- 通过允许相关LSP的运行状态变化，促进控制飞机运行。
Procedures and protocol extensions to support Call setup, and the association of Calls with Connections are described in Section 5 and onwards of this document.
支持呼叫设置的过程和协议扩展以及呼叫与连接的关联在本文档第5节及以后的章节中进行了描述。
Full and logical Call and Connection separation is required. That is:
需要完全和逻辑的呼叫和连接分离。即:
- It MUST be possible to establish a Connection without dependence on a Call.
- 必须能够在不依赖呼叫的情况下建立连接。
- It MUST be possible to establish a Call without any associated Connections.
- 必须能够在没有任何关联连接的情况下建立呼叫。
- It MUST be possible to associate more than one Connection with a Call.
- 必须能够将多个连接与呼叫相关联。
- Removal of the last Connection associated with a Call SHOULD NOT result in the automatic removal of the Call except as a matter of local policy at the ingress of the Call.
- 除去与呼叫相关联的最后一个连接不应导致自动除去呼叫，除非作为呼叫入口的本地策略问题。
- Signaling of a Connection associated with a Call MUST NOT require the distribution or retention of Call-related information (state) within the network.
- 与呼叫相关联的连接的信令不得要求在网络内分发或保留呼叫相关信息（状态）。
Call Segment capabilities MUST be supported.
必须支持呼叫段功能。
Procedures and (GMPLS) RSVP-TE signaling protocol extensions to support Call Segments are described in Section 7.3.1 of this document.
本文件第7.3.1节描述了支持呼叫段的程序和（GMPLS）RSVP-TE信令协议扩展。
The concept of a Call and a Connection are also discussed in the ASON architecture [G.8080] and [RFC4139]. This section is not intended as a substitute for those documents, but is a brief summary of the key terms and concepts.
ASON架构[G.8080]和[RFC4139]中也讨论了呼叫和连接的概念。本节不打算取代这些文件，而是对关键术语和概念的简要概述。
A Call is an agreement between endpoints possibly in cooperation with the nodes that provide access to the network. Call setup may include capability exchange, policy, authorization, and security.
呼叫是端点之间的协议，可能与提供网络访问的节点合作。呼叫设置可能包括功能交换、策略、授权和安全性。
A Call is used to facilitate and manage a set of Connections that provide end-to-end data services. While Connections require state to be maintained at nodes along the data path within the network, Calls do not involve the participation of transit nodes except to forward the Call management requests as transparent messages.
调用用于促进和管理一组提供端到端数据服务的连接。虽然连接要求在网络内沿数据路径的节点处维护状态，但呼叫不涉及中转节点的参与，除非将呼叫管理请求作为透明消息转发。
A Call may be established and maintained independently of the Connections that it supports.
呼叫可以独立于其支持的连接建立和维护。
Clearly, there is a hierarchical relationship between Calls and Connections. One or more Connections may be associated with a Call. A Connection may not be part of more than one Call. A Connection may, however, exist without a Call.
显然，调用和连接之间存在层次关系。一个或多个连接可能与呼叫关联。一个连接不能是多个呼叫的一部分。但是，连接可能不需要调用就存在。
In GMPLS RSVP-TE [RFC3473], a Connection is identified with a GMPLS TE Tunnel. Commonly, a Tunnel is identified with a single LSP, but it should be noted that for protection, load balancing, and many other functions, a Tunnel may be supported by multiple parallel LSPs. The following identification reproduces this hierarchy.
在GMPLS RSVP-TE[RFC3473]中，通过GMPLS TE隧道识别连接。通常，隧道由单个LSP标识，但应注意，对于保护、负载平衡和许多其他功能，隧道可能由多个并行LSP支持。以下标识复制了此层次结构。
- Call IDs are unique within the context of the pair of addresses that are the source and destination of the Call.
- 呼叫ID在作为呼叫源和目标的地址对的上下文中是唯一的。
- Tunnel IDs are unique within the context of the Session (that is the destination of the Tunnel). Applications may also find it convenient to keep the Tunnel ID unique within the context of a Call.
- 隧道ID在会话上下文（即隧道的目标）中是唯一的。应用程序还可能发现，在调用上下文中保持隧道ID的唯一性很方便。
- LSP IDs are unique within the context of a Tunnel.
- LSP ID在隧道上下文中是唯一的。
Note that the Call_ID value of zero is reserved and MUST NOT be used during LSP-independent Call establishment.
请注意，Call_ID值为零是保留的，在LSP独立呼叫建立期间不得使用。
Throughout the remainder of this document, the terms LSP and Tunnel are used interchangeably with the term Connection. The case of a Tunnel that is supported by more than one LSP is covered implicitly.
在本文件的其余部分中，术语LSP和Tunnel可与术语Connection互换使用。隐式地涵盖由多个LSP支持的隧道的情况。
In an overlay model, it is useful for the ingress node of an LSP to know the link capabilities of the link between the network and the remote overlay network. In the language of [RFC4208], the ingress node can make use of information about the link between the egress core node (CN) and the remote edge node (EN). We call this link the egress network link. This information may allow the ingress node to tailor its LSP request to fit those capabilities and to better utilize network resources with regard to those capabilities.
在覆盖模型中，LSP的入口节点了解网络和远程覆盖网络之间链路的链路能力是有用的。在[RFC4208]的语言中，入口节点可以利用关于出口核心节点（CN）和远程边缘节点（EN）之间的链路的信息。我们称此链路为出口网络链路。该信息可允许入口节点定制其LSP请求以适合这些能力并更好地利用关于这些能力的网络资源。
For example, this might be used in transparent optical networks to supply information on lambda availability on egress network links, or, where the egress CN is capable of signal regeneration, it might provide a mechanism for negotiating signal quality attributes (such
例如，这可以在透明光网络中用于提供关于出口网络链路上的lambda可用性的信息，或者，在出口CN能够信号再生的情况下，它可以提供协商信号质量属性的机制（例如
as bit error rate). Similarly, in multi-domain routing environments, it could be used to provide end-to-end selection of component links (i.e., spatial attribute negotiation) where TE links have been bundled based on technology specific attributes.
作为误码率）。类似地，在多域路由环境中，它可用于提供组件链路的端到端选择（即，空间属性协商），其中TE链路已基于特定于技术的属性进行捆绑。
In some circumstances, the Traffic Engineering Database (TED) may contain sufficient information for decisions to be made about which egress network link to use. In other circumstances, the TED might not contain this information and Call setup may provide a suitable mechanism to exchange information for this purpose. The Call-responder may use the Call parameters to select a subset of the available egress network links between the egress CN and the remote EN, and may report these links and their capabilities on the Call response so that the Call-initiator may select a suitable link.
在某些情况下，流量工程数据库（TED）可能包含足够的信息，以便决定使用哪个出口网络链路。在其他情况下，TED可能不包含此信息，并且呼叫设置可能为此目的提供适当的机制来交换信息。呼叫响应者可以使用呼叫参数来选择出口CN和远程EN之间的可用出口网络链路的子集，并且可以在呼叫响应上报告这些链路及其能力，以便呼叫发起者可以选择合适的链路。
The sections that follow indicate the cases where the TED may be used, and those where Call parameter exchange may be appropriate.
以下各节说明了TED可能使用的情况，以及调用参数交换可能适用的情况。
Network-initiated Calls arise when the ingress (and correspondingly the egress) lie within the network and there may be no need to distribute additional link capability information over and above the information distributed by the TE and GMPLS extensions to the IGP. Further, it is possible that future extensions to these IGPs will allow the distribution of more detailed information including optical impairments.
当入口（以及相应的出口）位于网络内并且可能不需要在TE和GMPLS扩展向IGP分发的信息之上分发额外的链路能力信息时，就会产生网络发起的呼叫。此外，这些IGP的未来扩展可能允许分发更详细的信息，包括光学损伤。
User-initiated Calls arise when the ingress (and correspondingly the egress) lie outside the network. Edge link information may not be visible within the core network, nor (and specifically) at other edge nodes. This may prevent an ingress from requesting suitable LSP characteristics to ensure successful LSP setup.
当入口（以及相应的出口）位于网络之外时，会出现用户发起的呼叫。边缘链路信息在核心网络内可能不可见，在其他边缘节点上也可能不可见（具体而言）。这可能会阻止入口请求合适的LSP特性，以确保LSP设置成功。
Various solutions to this problem exist, including the definition of static TE links (that is, not advertised by a routing protocol) between the CNs and ENs. Nevertheless, special procedures may be necessary to advertise to the edge nodes outside of the network information about egress network links without also advertising the information specific to the contents of the network.
该问题存在多种解决方案，包括CNs和ENs之间静态TE链路的定义（即，不通过路由协议公布）。然而，可能需要特殊过程来向网络外部的边缘节点通告关于出口网络链路的信息，而不同时通告特定于网络内容的信息。
In the future, when the requirements on the information that needs to be supported are better understood, TE extensions to EGPs may be defined to provide this function, and new rules for leaking TE information between routing instances may be used.
将来，当更好地理解对需要支持的信息的需求时，可以定义EGPs的TE扩展来提供此功能，并且可以使用路由实例之间泄漏TE信息的新规则。
When IGP and EGP solutions are not available at the User-to-Network Interface (UNI), there is still a requirement to have the knowledge of the remote edge link capabilities at the local edge nodes.
当用户到网络接口（UNI）上没有IGP和EGP解决方案时，仍然需要了解本地边缘节点的远程边缘链路能力。
The Call setup procedure provides an opportunity to discover edge link capabilities of remote edge nodes before LSP setup is attempted.
呼叫设置过程提供了在尝试LSP设置之前发现远程边缘节点的边缘链路功能的机会。
- The Call-responder can return information on one or more egress network links. The Call-responder could return a full list of the available links with information about the link capabilities, or it could filter the list to return information about only those links that might be appropriate to support the Connections needed by the Call. To do this second option, the Call-responder must determine such appropriate links from information carried in the Call request including destination of the Call, and the level of service (bandwidth, protection, etc.) required.
- 呼叫应答器可以返回一个或多个出口网络链路上的信息。呼叫响应者可以返回一个完整的可用链接列表，其中包含有关链接功能的信息，或者可以过滤该列表以仅返回有关那些可能适合支持呼叫所需连接的链接的信息。为了进行第二种选择，呼叫响应者必须根据呼叫请求中携带的信息确定此类适当的链路，包括呼叫的目的地和所需的服务水平（带宽、保护等）。
- On receiving a Call response, the Call-initiator must determine paths for the Connections (LSPs) that it will set up. The way that it does this is out of scope for this document since it is an implementation-specific, algorithmic process. However, it can take as input the information about the available egress network links as supplied in the Call response.
- 在收到呼叫响应时，呼叫发起方必须确定其将设置的连接（LSP）的路径。它这样做的方式超出了本文档的范围，因为它是一个特定于实现的算法过程。然而，它可以将呼叫响应中提供的关于可用出口网络链路的信息作为输入。
The LINK_CAPABILITY object is defined to allow this information to be exchanged. The information that is included in this object is similar to that distributed by GMPLS-capable IGPs (see [RFC4202]).
链接功能对象被定义为允许交换此信息。该对象中包含的信息与支持GMPLS的IGP发布的信息类似（参见[RFC4202]）。
This section describes the protocol extensions needed in support of Call identification and management of Calls and Connections. Procedures for the use of these protocol extensions are described in Section 6.
本节描述了支持呼叫识别和呼叫及连接管理所需的协议扩展。第6节介绍了使用这些协议扩展的程序。
Calls are established independently of Connections through the use of the Notify message. The Notify message is a targeted message and does not need to follow the path of LSPs through the network.
通过使用Notify消息，独立于连接建立呼叫。Notify消息是目标消息，不需要遵循LSP通过网络的路径。
Simultaneous Call and Connection establishment (sometimes referred to as piggybacking) is not supported.
不支持同时建立呼叫和连接（有时称为搭载）。
As soon as the concept of a Call is introduced, it is necessary to support some means of identifying the Call. This becomes particularly important when Calls and Connections are separated and Connections must contain some reference to the Call.
一旦引入呼叫的概念，就有必要支持一些识别呼叫的方法。当调用和连接被分离并且连接必须包含对调用的引用时，这一点变得尤为重要。
A Call may be identified by a sequence of bytes that may have considerable (but not arbitrary) length. A Call ID of 40 bytes would not be unreasonable. It is not the place of this document to supply rules for encoding or parsing Call IDs, but it must provide a suitable means to communicate Call IDs within the protocol. The full Call identification is referred to as the long Call ID.
调用可以通过具有相当长（但不是任意长度）的字节序列来识别。40字节的调用ID并不合理。本文档不提供编码或解析调用ID的规则，但它必须提供在协议内传递调用ID的合适方法。完整呼叫标识称为长呼叫标识。
The Call_ID is only relevant at the sender and receiver nodes. Maintenance of this information in the signaling state is not mandated at any intermediate node. Thus, no change in [RFC3473] transit implementations is required and there are no backward compatibility issues. Forward compatibility is maintained by using the existing default values to indicate that no Call processing is required.
呼叫ID仅与发送方和接收方节点相关。在任何中间节点上都不强制在信令状态下维护该信息。因此，[RFC3473]传输实现不需要更改，也不存在向后兼容性问题。前向兼容性是通过使用现有的默认值来表示不需要调用处理来维护的。
Further, the long Call ID is not required as part of the Connection (LSP) state even at the sender and receiver nodes so long as some form of correlation is available. This correlation is provided through the short Call ID.
此外，即使在发送方和接收方节点，只要某种形式的相关性可用，长呼叫ID也不需要作为连接（LSP）状态的一部分。这种相关性是通过短呼叫ID提供的。
The long Call ID is only required on the Notify message used to establish the Call. It is carried in the "Session Name" field of the SESSION_ATTRIBUTE object on the Notify message.
长呼叫ID仅在用于建立呼叫的Notify消息上需要。它在Notify消息上会话_属性对象的“会话名称”字段中携带。
A unique value per Call is inserted in the "Session Name" field by the initiator of the Call. Subsequent core nodes MAY inspect this object and MUST forward this object transparently across network interfaces until reaching the egress node. Note that the structure of this field MAY be the object of further formatting depending on the naming convention(s). However, [RFC3209] defines the "Session Name" field as a Null padded display string, so any formatting conventions for the Call ID must be limited to this scope.
每次调用的唯一值由调用的发起人插入到“会话名称”字段中。后续核心节点可能会检查此对象，并且必须在到达出口节点之前通过网络接口透明地转发此对象。请注意，此字段的结构可能是进一步格式化的对象，具体取决于命名约定。但是，[RFC3209]将“会话名称”字段定义为空的填充显示字符串，因此调用ID的任何格式约定都必须限制在此范围内。
The Connections (LSPs) associated with a Call need to carry a reference to the Call - the short Call ID. A new field is added to the signaling protocol to identify an individual LSP with the Call to which it belongs.
与呼叫相关联的连接（LSP）需要携带对呼叫的引用-短呼叫ID。信令协议中添加了一个新字段，以识别具有其所属呼叫的单个LSP。
The new field is a 16-bit identifier (unique within the context of the address pairing provided by the Tunnel_End_Point_Address and the Sender_Address of the SENDER_TEMPLATE object) that MUST be exchanged on the Notify message during Call initialization and is used on all subsequent LSP messages that are associated with the Call. This identifier is known as the short Call ID and is encoded as described in Section 5.2.3. The Call ID MUST NOT be used as part of the processing to determine the session to which an RSVP signaling message applies. This does not generate any backward compatibility issue since the reserved field of the SESSION object defined in [RFC3209] MUST NOT be examined on receipt.
新字段是一个16位标识符（在由发送方模板对象的隧道\端点\点\地址和发送方\地址提供的地址配对上下文中是唯一的），在呼叫初始化期间必须在Notify消息上交换该标识符，并在与呼叫关联的所有后续LSP消息上使用该标识符。该标识符称为短呼叫ID，并按照第5.2.3节所述进行编码。呼叫ID不得用作确定RSVP信令消息适用的会话的处理的一部分。这不会产生任何向后兼容性问题，因为在接收时不得检查[RFC3209]中定义的会话对象的保留字段。
In the unlikely case of short Call_ID exhaustion, local node policy decides upon specific actions to be taken, but might include the use of second Sender_Address. Local policy details are outside of the scope of this document.
在不太可能出现短呼叫\u ID耗尽的情况下，本地节点策略决定要采取的特定操作，但可能包括使用第二个发送方\u地址。本地政策详细信息不在本文档范围内。
The short Call ID is carried in a 16-bit field in the SESSION object carried on the Notify message used during Call setup, and on all messages during LSP setup and management. The field used was previously reserved (MUST be set to zero on transmission and ignored on receipt). This ensures backward compatibility with nodes that do not utilize Calls.
短呼叫ID包含在会话对象的16位字段中，会话对象包含在呼叫设置期间使用的Notify消息中，以及LSP设置和管理期间的所有消息中。使用的字段以前是保留的（传输时必须设置为零，接收时忽略）。这确保了与不使用调用的节点的向后兼容性。
The figure below shows the new version of the object.
下图显示了对象的新版本。
Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6)
Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv4/IPv6 Tunnel End Point Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call_ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv4/IPv6 Tunnel End Point Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call_ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209])
IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209])
Call_ID: 16 bits
呼叫识别码：16位
A 16-bit identifier used in the SESSION object that remains constant over the life of the Call. The Call_ID value MUST be set to zero when there is no corresponding Call.
会话对象中使用的16位标识符，在调用的整个生命周期内保持不变。当没有相应的调用时，调用ID值必须设置为零。
Tunnel ID: 16 bits (see [RFC3209])
隧道ID:16位（参见[RFC3209]）
Extended Tunnel ID: 32 bits/128 bits (see [RFC3209])
扩展隧道ID:32位/128位（参见[RFC3209]）
The LINK_CAPABILITY object is introduced to support link capability exchange during Call setup and MAY be included in a Notify message used for Call setup. This optional object includes the link-local capabilities of a link joining the Call-initiating node (or Call-terminating node) to the network. The specific node is indicated by the source address of the Notify message.
LINK_CAPABILITY对象用于在呼叫设置期间支持链路能力交换，并可包含在用于呼叫设置的通知消息中。此可选对象包括将呼叫发起节点（或呼叫终止节点）连接到网络的链路的链路本地功能。特定节点由通知消息的源地址指示。
The link reported can be a single link or can be a bundled link [RFC4201].
报告的链路可以是单个链路，也可以是捆绑链路[RFC4201]。
The Class Number is selected so that the nodes that do not recognize this object drop it silently. That is, the top bit is set and the next bit is clear.
选择类别编号，以便不识别此对象的节点以静默方式放置它。也就是说，上一位已设置，下一位已清除。
This object has the following format:
此对象具有以下格式：
Class-Num = 133 (form 10bbbbbb), C_Type = 1
类别编号=133（表格10BBBB），C_类型=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of the LINK_CAPABILITY object is defined as a series of variable-length data items called subobjects. The subobject format is defined in [RFC3209].
链接功能对象的内容定义为一系列称为子对象的可变长度数据项。子对象格式在[RFC3209]中定义。
The following subobjects are currently defined.
当前定义了以下子对象。
- Type 1: the link local IPv4 address of a link or a numbered bundle using the format defined in [RFC3209].
- 类型1：使用[RFC3209]中定义的格式的链路或编号包的链路本地IPv4地址。
- Type 2: the link local IPv6 address of a link or a numbered bundle using the format defined in [RFC3209].
- 类型2：使用[RFC3209]中定义的格式的链路或编号包的链路本地IPv6地址。
- Type 4: the link local identifier of an unnumbered link or bundle using the format defined in [RFC3477].
- 类型4：使用[RFC3477]中定义的格式的未编号链接或捆绑的链接本地标识符。
- Type 64: the Maximum Reservable Bandwidth corresponding to this link or bundle (see [RFC4201]).
- 类型64：对应于此链接或捆绑包的最大可保留带宽（请参见[RFC4201]）。
- Type 65: the interface switching capability descriptor (see [RFC4202]) corresponding to this link or bundle (see also [RFC4201]).
- 类型65：与此链路或捆绑包（另请参见[RFC4201]）对应的接口交换能力描述符（请参见[RFC4202]）。
Note: future revisions of this document may extend the above list.
注：本文件的未来版本可能会扩展上述列表。
A single instance of this object MAY be used to exchange capability information relating to more than one link or bundled link. In this case, the following ordering MUST be used:
此对象的单个实例可用于交换与多个链路或捆绑链路相关的能力信息。在这种情况下，必须使用以下顺序：
- each link MUST be identified by an identifier subobject (Type 1, 2, or 4)
- 每个链接必须由标识符子对象（类型1、2或4）标识
- capability subobjects (Type 64 or 65, and future subobjects) MUST be placed after the identifier subobject for the link or bundle to which they refer.
- 功能子对象（类型64或65以及将来的子对象）必须放在它们所引用的链接或捆绑的标识符子对象之后。
Multiple instances of the LINK_CAPABILITY object within the same Notify message are not supported by this specification. In the event that a Notify message contains multiple LINK_CAPABILITY objects, the receiver SHOULD process the first one as normal and SHOULD ignore subsequent instances of the object.
此规范不支持同一通知消息中链接功能对象的多个实例。如果Notify消息包含多个LINK_功能对象，则接收方应正常处理第一个对象，并应忽略该对象的后续实例。
The Notify message is enhanced to support Call establishment and teardown of Calls. See Section 6 for a description of the procedures.
Notify消息经过增强，支持建立呼叫和取消呼叫。有关程序的说明，请参见第6节。
The Notify message is modified in support of Call establishment by the optional addition of the LINK_CAPABILITY object. Further, the SESSION_ATTRIBUTE object is added to the <notify session> sequence to carry the long Call ID. The presence of the SESSION_ATTRIBUTE object MAY be used to distinguish a Notify message used for Call management, but see Section 5.5 for another mechanism. The <notify session list> MAY be used to simultaneously set up multiple Calls.
通过可选添加LINK_能力对象，修改Notify消息以支持呼叫建立。此外，SESSION_属性对象被添加到<notify SESSION>序列中，以携带长呼叫ID。SESSION_属性对象的存在可用于区分用于呼叫管理的通知消息，但另一种机制见第5.5节。<notify session list>可用于同时设置多个呼叫。
The format of the Notify Message is as follows:
通知信息的格式如下：
<Notify message> ::= <Common Header> [ <INTEGRITY> ]
[[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<notify session list>
<Notify message> ::= <Common Header> [ <INTEGRITY> ]
[[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<notify session list>
<notify session list> ::= [ <notify session list> ] <notify session>
<notify session list> ::= [ <notify session list> ] <notify session>
<notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[ <POLICY_DATA>...]
[ <LINK_CAPABILITY> ]
[ <SESSION_ATTRIBUTE> ]
[ <sender descriptor> | <flow descriptor> ]
<notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[ <POLICY_DATA>...]
[ <LINK_CAPABILITY> ]
[ <SESSION_ATTRIBUTE> ]
[ <sender descriptor> | <flow descriptor> ]
<sender descriptor> ::= see [RFC3473]
<sender descriptor> ::= see [RFC3473]
<flow descriptor> ::= see [RFC3473]
<flow descriptor> ::= see [RFC3473]
Notify messages exchanged for Call control and management purposes carry a specific new bit (the Call Management or C bit) in the ADMIN_STATUS object.
为呼叫控制和管理目的交换的Notify消息在ADMIN_STATUS对象中带有一个特定的新位（呼叫管理或C位）。
[RFC3473] indicates that the format and contents of the ADMIN_STATUS object are as defined in [RFC3471]. The new "C" bit is added for Call control as shown below.
[RFC3473]表示管理状态对象的格式和内容如[RFC3471]中所定义。如下所示，为呼叫控制添加了新的“C”位。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reflect (R): 1 bit - see [RFC3471]
Testing (T): 1 bit - see [RFC3471]
Administratively down (A): 1 bit - see [RFC3471]
Deletion in progress (D): 1 bit - see [RFC3471]
Call Management (C): 1 bit
Reflect (R): 1 bit - see [RFC3471]
Testing (T): 1 bit - see [RFC3471]
Administratively down (A): 1 bit - see [RFC3471]
Deletion in progress (D): 1 bit - see [RFC3471]
Call Management (C): 1 bit
This bit is set when the message is being used to control and manage a Call.
此位在消息用于控制和管理呼叫时设置。
The procedures for the use of the C bit are described in Section 6.
第6节介绍了C位的使用程序。
This section describes the processing steps for Call and Connection setup.
本节介绍呼叫和连接设置的处理步骤。
There are three cases considered:
考虑了三种情况：
- A Call is set up without any associated Connection. It is assumed that Connections will be added to the Call at a later time, but this is neither a requirement nor a constraint.
- 在没有任何关联连接的情况下建立呼叫。假定稍后会将连接添加到调用中，但这既不是要求也不是约束。
- A Connection may be added to an existing Call. This may happen if the Call was set up without any associated Connections, or if another Connection is added to a Call that already has one or more associated Connections.
- 可以将连接添加到现有呼叫。如果呼叫是在没有任何关联连接的情况下建立的，或者如果在已经有一个或多个关联连接的呼叫中添加了另一个连接，则可能会发生这种情况。
- A Connection may be established without any reference to a Call (see Section 6.4). This encompasses the previous LSP setup procedure.
- 可以在不参考呼叫的情况下建立连接（见第6.4节）。这包括前面的LSP设置程序。
Note that a Call MUST NOT be imposed upon a Connection that is already established. To do so would require changing the short Call ID in the SESSION object of the existing LSPs and this would constitute a change in the Session Identifier. This is not allowed by existing protocol specifications.
请注意，不能将呼叫强加给已建立的连接。为此，需要更改现有LSP会话对象中的短调用ID，这将构成会话标识符的更改。现有协议规范不允许这样做。
Call and Connection teardown procedures are described later in Section 6.6.
呼叫和连接断开程序将在后面的第6.6节中描述。
A Call is set up before, and independent of, LSP (i.e., Connection) setup.
呼叫在LSP（即连接）设置之前设置，并且独立于LSP设置。
Call setup MAY necessitate verification of the link status and link capability negotiation between the Call ingress node and the Call egress node. The procedure described below is applied only once for a Call and hence only once for the set of LSPs associated with a Call.
呼叫建立可能需要验证呼叫入口节点和呼叫出口节点之间的链路状态和链路能力协商。下面描述的过程仅对一个调用应用一次，因此仅对与一个调用相关联的一组LSP应用一次。
The Notify message (see [RFC3473]) is used to signal the Call setup request and response. The new Call Management (C) bit in the ADMIN_STATUS object is used to indicate that this Notify is managing a Call. The Notify message is sent with source and destination IPv4/IPv6 addresses set to any of the routable ingress/egress node addresses respectively.
通知消息（参见[RFC3473]）用于向呼叫设置请求和响应发送信号。ADMIN_STATUS对象中的新呼叫管理（C）位用于指示此Notify正在管理呼叫。发送通知消息时，源和目标IPv4/IPv6地址分别设置为任何可路由的入口/出口节点地址。
At least one session MUST be listed in the <notify session list> of the Notify message. In order to allow for long identification of the Call, the SESSION_ATTRIBUTE object is added as part of the <notify session list>. Note that the ERROR_SPEC object is not relevant in Call setup and MUST carry the Error Code zero ("Confirmation") to indicate that there is no error.
通知消息的<notify session list>中必须至少列出一个会话。为了允许长时间识别呼叫，会话_属性对象被添加为<notify SESSION list>的一部分。请注意，ERROR_SPEC对象在调用设置中不相关，必须带有错误代码零（“确认”），以指示没有错误。
During Call setup, the ADMIN_STATUS object is sent with the following bits set. Bits not listed MUST be set to zero.
在呼叫设置过程中，将发送ADMIN_STATUS对象，并设置以下位。未列出的位必须设置为零。
R - to cause the egress to respond C - to indicate that the Notify message is managing a Call.
R-使出口响应C-指示通知消息正在管理呼叫。
The SESSION, SESSION_ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC objects included in the <notify session> of the Notify message are built as follows.
notify消息的<notify SESSION>中包含的会话、会话\属性、发送者\模板、发送者\ TSPEC对象构建如下。
- The SESSION object includes as Tunnel_End_Point_Address any of the Call-terminating (egress) node's IPv4/IPv6 routable addresses. The Call_ID is set to a non-zero value unique within the context of the address pairing provided by the Tunnel_End_Point_Address and the Sender_Address from the SENDER_TEMPLATE object (see below). This value will be used as the short Call ID carried on all messages for LSPs associated with this Call.
- 会话对象包括任何呼叫终止（出口）节点的IPv4/IPv6可路由地址作为隧道\结束\点\地址。Call_ID设置为非零值，该值在通道_End_Point_地址和发件人_TEMPLATE对象中的发件人_地址提供的地址对上下文中是唯一的（请参见下文）。此值将用作与此呼叫关联的LSP的所有消息中携带的短呼叫ID。
Note that the Call_ID value of zero is reserved and MUST NOT be used since it will be present in SESSION objects of LSPs that are not associated with Calls. The Tunnel_ID of the SESSION object is not relevant for this procedure and SHOULD be set to zero. The Extended_Tunnel_ID of the SESSION object is not relevant for this procedure and MAY be set to zero or to an address of the ingress node.
请注意，Call_ID值为零是保留的，不能使用，因为它将出现在与调用无关的LSP的会话对象中。会话对象的隧道ID与此过程无关，应设置为零。会话对象的扩展_Tunnel_ID与此过程无关，可以设置为零或入口节点的地址。
- The SESSION_ATTRIBUTE object contains priority flags. Currently no use of these flags is envisioned, however, future work may identify value in assigning priorities to Calls; accordingly the Priority fields MAY be set to non-zero values. None of the Flags in the SESSION_ATTRIBUTE object is relevant to this process and this field SHOULD be set to zero. The Session Name field is used to carry the long Call Id as described in Section 5.
- 会话_属性对象包含优先级标志。目前还没有设想使用这些标志，但是，未来的工作可能会确定为呼叫分配优先级的价值；因此，优先级字段可以设置为非零值。会话_属性对象中的任何标志都与此进程无关，此字段应设置为零。会话名称字段用于携带长呼叫Id，如第5节所述。
- The SENDER_TEMPLATE object includes as Sender Address any of the Call-initiating (ingress) node's IPv4/IPv6 routable addresses. The LSP_ID is not relevant and SHOULD be set to zero.
- SENDER_TEMPLATE对象包括任何呼叫发起（入口）节点的IPv4/IPv6可路由地址作为发送方地址。LSP_ID不相关，应设置为零。
- The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC objects MUST be ignored upon receipt and SHOULD be set to zero when sent.
- 在接收时必须忽略插入发送方_TSPEC和FLOWSPEC对象中的带宽值，并在发送时将其设置为零。
Additionally, ingress/egress nodes that need to communicate their respective link local capabilities may include a LINK_CAPABILITY object in the Notify message.
此外，需要通信其各自链路本地能力的入口/出口节点可以在通知消息中包括链路能力对象。
The receiver of a Notify message may identify whether it is part of Call management or reporting an error by the presence or absence of the SESSION_ATTRIBUTE object in the <notify session list>. Full clarity, however, may be achieved by inspection of the new Call Management (C) bit in the ADMIN_STATUS object.
Notify消息的接收者可以通过<Notify SESSION list>中的SESSION_属性对象的存在或不存在来识别它是呼叫管理的一部分还是报告错误。但是，可以通过检查ADMIN_STATUS对象中的新呼叫管理（C）位来实现完全清晰。
Note that the POLICY_DATA object may be included in the <notify session list> and MAY be used to identify requestor credentials, account numbers, limits, quotas, etc. This object is opaque to RSVP, which simply passes it to policy control when required.
请注意，POLICY_数据对象可能包含在<notify session list>中，并可用于标识请求者凭据、帐号、限制、配额等。该对象对RSVP是不透明的，RSVP只在需要时将其传递给策略控制。
Message IDs MUST be used during Call setup.
呼叫设置期间必须使用消息ID。
A node that receives a Notify message carrying the ADMIN_STATUS object with the R and C bits set is being requested to set up a Call. The receiver MAY perform authorization and policy according to local requirements.
正在请求接收带有ADMIN_STATUS对象且设置了R和C位的Notify消息的节点设置调用。接收方可根据本地要求执行授权和策略。
If the Call is acceptable, the receiver responds with a Notify message reflecting the information from the Call request with two exceptions.
如果呼叫是可接受的，则接收方会以一条Notify消息响应，该消息反映了来自呼叫请求的信息，但有两个例外。
- The responder removes any LINK_CAPABLITY object that was received and MAY insert a LINK_CAPABILITY object that describes its own access link.
- 响应者删除接收到的任何链路能力对象，并可插入描述其自身访问链路的链路能力对象。
- The ADMIN_STATUS object is sent with only the C bit set. All other bits MUST be set to zero.
- ADMIN_状态对象仅随C位集一起发送。所有其他位必须设置为零。
The responder MUST use the Message ID object to ensure reliable delivery of the response. If no Message ID Acknowledgement is received after the configured number of retries, the responder SHOULD continue to assume that the Call was successfully established. Call liveliness procedures are covered in Section 6.7.
响应者必须使用消息ID对象来确保响应的可靠传递。如果在配置的重试次数之后没有收到消息ID确认，响应者应继续假定呼叫已成功建立。第6.7节介绍了呼叫活跃度程序。
Call setup may fail or be rejected.
呼叫设置可能失败或被拒绝。
If the Notify message can not be delivered, no Message ID acknowledgement will be received by the sender. In the event that the sender has retransmitted the Notify message a configurable number
如果无法传递通知消息，发送方将不会收到消息ID确认。如果发送方已重新传输Notify消息，则为可配置号码
of times without receiving a Message ID Acknowledgement (as described in [RFC2961]), the initiator SHOULD declare the Call failed and SHOULD send a Call teardown request (see Section 6.6).
在没有收到消息ID确认的情况下（如[RFC2961]中所述），发起方应声明呼叫失败，并应发送呼叫解除请求（见第6.6节）。
It is also possible that a Message ID Acknowledgement is received but no Call response Notify message is received. In this case, the initiator MAY re-send the Call setup request a configurable number of times (see Section 6.7) before declaring that the Call has failed. At this point, the initiator MUST send a Call teardown request (see Section 6.6).
也可能收到消息ID确认，但未收到呼叫响应通知消息。在这种情况下，发起者可以在声明呼叫失败之前重新发送呼叫设置请求一个可配置的次数（参见第6.7节）。此时，发起方必须发送呼叫解除请求（参见第6.6节）。
If the Notify message cannot be parsed or is in error, it MAY be responded to with a Notify message carrying the error code 13 ("Unknown object class") or 14 ("Unknown object C-Type") if appropriate to the error detected.
如果无法解析Notify消息或该消息出错，则可使用带有错误代码13（“未知对象类”）或14（“未知对象C类型”）的Notify消息（如果适用于检测到的错误）对其进行响应。
The Call setup MAY be rejected by the receiver because of security, authorization, or policy reasons. Suitable error codes already exist [RFC2205] and can be used in the ERROR_SPEC object included in the Notify message sent in response.
由于安全、授权或策略原因，呼叫设置可能会被接收方拒绝。合适的错误代码已经存在[RFC2205]，可以在响应中发送的Notify消息中包含的error_SPEC对象中使用。
Error response Notify messages SHOULD also use the Message ID object to achieve reliable delivery. No action should be taken on the failure to receive a Message ID Acknowledgement after the configured number of retries.
错误响应通知消息还应使用消息ID对象来实现可靠的传递。在配置的重试次数之后，如果无法接收消息ID确认，则不应采取任何操作。
Once a Call has been established, LSPs can be added to the Call. Since the short Call ID is part of the SESSION object, any LSP that has the same Call ID value in the SESSION object belongs to the same Call, and the Notify message used to establish the Call carried the same Call ID in its SESSION object.
建立呼叫后，可以将LSP添加到呼叫中。由于短呼叫ID是会话对象的一部分，因此会话对象中具有相同呼叫ID值的任何LSP都属于相同的呼叫，并且用于建立呼叫的通知消息在其会话对象中携带相同的呼叫ID。
There will be no confusion between LSPs that are associated with a Call and those which are not, since the Call ID value MUST be equal to zero for LSPs that are not associated with a Call, and MUST NOT be equal to zero for a valid Call ID.
与呼叫关联的LSP与未关联的LSP之间不会有任何混淆，因为对于未与呼叫关联的LSP，呼叫ID值必须等于零，对于有效的呼叫ID，呼叫ID值必须不等于零。
LSPs for different Calls can be distinguished because the Call ID is unique within the context of the source address (in the SENDER_TEMPLATE object) and the destination address (in the SESSION object).
可以区分不同呼叫的LSP，因为呼叫ID在源地址（在SENDER_TEMPLATE对象中）和目标地址（在SESSION对象中）的上下文中是唯一的。
Ingress and egress nodes MAY group together LSPs associated with the same Call and process them as a group according to implementation requirements. Transit nodes need not be aware of the association of multiple LSPs with the same Call.
入口和出口节点可以将与同一呼叫相关联的lsp分组在一起，并根据实现需求将它们作为一个组进行处理。传输节点不需要知道多个LSP与同一呼叫的关联。
The ingress node MAY choose to set the "Session Name" of an LSP to match the long Call ID of the associated Call.
入口节点可以选择设置LSP的“会话名称”以匹配相关呼叫的长呼叫ID。
The C bit of the ADMIN_STATUS object MUST NOT be set on LSP messages including on Notify messages that pertain to the LSP and MUST be ignored.
ADMIN_STATUS对象的C位不能在LSP消息（包括与LSP相关的通知消息）上设置，并且必须忽略。
Note that once a Call has been established, it is symmetric. That is, either end of the Call may add LSPs to the Call.
请注意，一旦建立了呼叫，它就是对称的。也就是说，呼叫的任意一端都可以向呼叫添加LSP。
Special care is needed when managing LSPs in the reverse direction since the addresses in the SESSION and SENDER_TEMPLATE are reversed. However, since the short Call ID is unique in the context of a given ingress-egress address pair, it may safely be used to associate the LSP with the Call.
在反向管理LSP时需要特别小心，因为会话和发送方模板中的地址是反向的。然而，由于短呼叫ID在给定入口-出口地址对的上下文中是唯一的，因此它可以安全地用于将LSP与呼叫相关联。
Note that since Calls are defined here to be symmetrical, the issue of potential Call ID collision arises. This is discussed in Section 6.5.
请注意，由于这里定义的调用是对称的，因此可能会出现调用ID冲突的问题。第6.5节对此进行了讨论。
It continues to be possible to set up LSPs as per [RFC3473] without associating them with a Call. If the short Call ID in the SESSION object is set to zero, there is no associated Call and the Session Name field in the SESSION_ATTRIBUTE object MUST be interpreted simply as the name of the session (see [RFC3209]).
仍然可以按照[RFC3473]设置LSP，而无需将其与呼叫关联。如果会话对象中的短调用ID设置为零，则没有关联的调用，会话_属性对象中的会话名称字段必须简单地解释为会话名称（请参见[RFC3209]）。
The C bit of the ADMIN_STATUS object MUST NOT be set on messages for LSP control, including on Notify messages that pertain to LSPs, and MUST be ignored when received on such messages.
对于LSP控制的消息，包括与LSP相关的Notify消息，不得设置ADMIN_STATUS对象的C位，并且在接收此类消息时必须忽略该位。
Since Calls are symmetrical, it is possible that both ends of a Call will attempt to establish Calls with the same long Call IDs at the same time. This is only an issue if the source and destination address pairs match. This situation can be avoided by applying some rules to the contents of the long Call ID, but such mechanisms are outside the scope of this document.
由于呼叫是对称的，因此呼叫的两端有可能同时尝试建立具有相同长呼叫ID的呼叫。只有源地址对和目标地址对匹配时，才会出现此问题。这种情况可以通过对长调用ID的内容应用一些规则来避免，但是这种机制不在本文的范围之内。
If a node that has sent a Call setup request and has not yet received a response itself receives a Call setup request with the same long Call ID and matching source/destination addresses, it SHOULD process as follows:
如果已发送呼叫设置请求但自身尚未收到响应的节点接收到具有相同长呼叫ID和匹配源/目标地址的呼叫设置请求，则其应按如下方式处理：
- If its source address is numerically greater than the remote source address, it MUST discard the received message and continue to wait for a response to its setup request.
- 如果其源地址的数值大于远程源地址，则必须丢弃接收到的消息，并继续等待对其设置请求的响应。
- If its source address is numerically smaller than the remote source address, it MUST discard state associated with the Call setup that it initiated, and MUST respond to the received Call setup.
- 如果其源地址在数字上小于远程源地址，则必须放弃与其启动的呼叫设置相关联的状态，并且必须响应接收到的呼叫设置。
If a node receives a Call setup request carrying an address pair and long Call ID that match an existing Call, the node MUST return an error message (Notify message) with the new Error Code "Call Management" and the new Error Value "Duplicate Call" in response to the new Call request, and MUST NOT make any changes to the existing Call.
如果节点接收到带有地址对和长呼叫ID（与现有呼叫匹配）的呼叫设置请求，则节点必须返回一条错误消息（通知消息），其中包含新的错误代码“呼叫管理”和新的错误值“重复呼叫”，以响应新的呼叫请求，并且不得对现有呼叫进行任何更改。
A further possibility for contention arises when short Call IDs are assigned by a pair of nodes for two distinct Calls that are set up simultaneously using different long Call IDs. In this event, a node receives a Call setup request carrying a short Call ID that matches one that it previously sent for the same address pair. The following processing MUST be followed:
当一对节点为同时使用不同长呼叫ID设置的两个不同呼叫分配短呼叫ID时，出现争用的另一种可能性。在这种情况下，节点会收到一个呼叫设置请求，其中包含一个短呼叫ID，该ID与它之前为同一地址对发送的ID相匹配。必须遵循以下处理过程：
- If the receiver's source address is numerically greater than the remote source address, the receiver returns an error (Notify message) with the new Error Code "Call Management" and the new Error Value "Call ID Contention".
- 如果接收器的源地址在数字上大于远程源地址，则接收器返回错误（通知消息），新错误代码为“呼叫管理”，新错误值为“呼叫ID争用”。
- If the receiver's source address is numerically less than the remote source address, the receiver accepts and processes the Call request. It will receive an error message sent as described above, and at that point, it selects a new short Call ID and re-sends the Call setup request.
- 如果接收方的源地址在数字上小于远程源地址，则接收方接受并处理呼叫请求。它将收到如上所述发送的错误消息，此时，它将选择一个新的短呼叫ID并重新发送呼叫设置请求。
As with Call/Connection setup, there are several cases to consider.
与调用/连接设置一样，有几种情况需要考虑。
- Removal of a Connection from a Call - Removal of the last Connection from a Call - Teardown of an "empty" Call
- 从呼叫中删除连接-从呼叫中删除最后一个连接-删除“空”呼叫
The case of tearing down an LSP that is not associated with a Call does not need to be examined as it follows exactly the procedures described in [RFC3473].
不需要检查拆卸与调用无关的LSP的情况，因为它完全遵循[RFC3473]中描述的过程。
An LSP that is associated with a Call may be deleted using the standard procedures described in [RFC3473]. No special procedures are required.
可以使用[RFC3473]中描述的标准程序删除与呼叫相关联的LSP。不需要特别程序。
Note that it is not possible to remove an LSP from a Call without deleting the LSP. It is not valid to change the short Call ID from non-zero to zero since this involves a change to the SESSION object, which is not allowed.
请注意，如果不删除LSP，则无法从呼叫中删除LSP。将短调用ID从非零更改为零是无效的，因为这涉及对会话对象的更改，这是不允许的。
When the last LSP associated with a Call is deleted, the question arises as to what happens to the Call. Since a Call may exist independently of Connections, it is not always acceptable to say that the removal of the last LSP from a Call removes the Call.
当删除与呼叫相关联的最后一个LSP时，问题是呼叫会发生什么情况。由于呼叫可能独立于连接而存在，因此说从呼叫中删除最后一个LSP会删除呼叫并不总是可以接受的。
The removal of the last LSP does not remove the Call and the procedures described in the next Section MUST be used to delete the Call.
删除最后一个LSP不会删除调用，必须使用下一节中描述的过程删除调用。
When all LSPs have been removed from a Call, the Call may be torn down or left for use by future LSPs.
当一个呼叫中的所有LSP都已删除时，该呼叫可能会被删除或留下供将来的LSP使用。
Deletion of Calls is achieved by sending a Notify message just as for Call setup, but the ADMIN_STATUS object carries the R, D, and C bits on the teardown request and the D and C bits on the teardown response. Other bits MUST be set to zero.
与呼叫设置一样，通过发送通知消息来删除呼叫，但ADMIN_STATUS对象在拆卸请求中携带R、D和C位，在拆卸响应中携带D和C位。其他位必须设置为零。
When a Notify message is sent for deleting a Call and the initiator does not receive the corresponding reflected Notify message (or possibly even the Message ID Ack), the initiator MAY retry the deletion request using the same retry procedures as used during Call establishment. If no response is received after full retry, the node deleting the Call MAY declare the Call deleted, but under such circumstances the node SHOULD avoid re-using the long or short Call IDs for at least five times the Notify refresh period.
当发送用于删除呼叫的通知消息时，发起方没有收到相应的反射通知消息（甚至可能没有收到消息ID Ack），发起方可以使用与呼叫建立期间相同的重试过程重试删除请求。如果在完全重试后未收到响应，则删除呼叫的节点可以声明呼叫已删除，但在这种情况下，节点应避免在至少五倍的通知刷新周期内重复使用长或短呼叫ID。
If a Notify request with the D bit of the ADMIN_STATUS object set is received for a Call for which LSPs still exist, the request MUST be rejected with the Error Code "Call Management" and Error Value "Connections Still Exist". The state of the Call MUST NOT be changed.
如果为LSP仍然存在的呼叫接收到具有ADMIN_STATUS对象集的D位的Notify请求，则必须拒绝该请求，错误代码为“呼叫管理”，错误值为“连接仍然存在”。呼叫的状态不得更改。
Since Calls are symmetric, they may be torn down from the ingress or egress.
因为调用是对称的，所以它们可能会从入口或出口被删除。
When the Call is "empty" (has no associated LSPs), it may be deleted by the egress sending a Notify message just as described above.
当呼叫为“空”（没有相关联的lsp）时，可以通过如上所述的出口发送通知消息来删除该呼叫。
Note that there is a possibility that both ends of a Call initiate Call deletion at the same time. In this case, the Notify message acting as teardown request MAY be interpreted by its recipient as a teardown response. But since the Notify messages acting as teardown requests carry the R bit in the ADMIN_STATUS object, they MUST be responded to anyway. If a teardown request Notify message is received for an unknown Call ID, it is, nevertheless, responded to in the affirmative.
请注意，呼叫的两端可能同时启动呼叫删除。在这种情况下，作为拆卸请求的Notify消息可能被其接收者解释为拆卸响应。但是，由于充当拆卸请求的Notify消息在ADMIN_STATUS对象中携带R位，因此无论如何都必须响应它们。如果接收到未知呼叫ID的拆卸请求通知消息，则响应为肯定。
Delivery of Notify messages is secured using Message ID Acknowledgements as described in previous sections.
如前几节所述，通知消息的传递使用消息ID确认进行保护。
Notify messages provide end-to-end communication that does not rely on constant paths through the network. Notify messages are routed according to IGP routing information. No consideration is, therefore, required for network resilience (for example, make-before-break, protection, fast re-route), although end-to-end resilience is of interest for node restart and completely disjoint networks.
Notify消息提供端到端通信，不依赖于通过网络的恒定路径。通知消息根据IGP路由信息进行路由。因此，不需要考虑网络弹性（例如，先通后断、保护、快速重路由），尽管端到端弹性对于节点重启和完全不相交的网络来说很重要。
Periodic Notify messages SHOULD be sent by the initiator and terminator of the Call to keep the Call alive and to handle ingress or egress node restart. The time period for these retransmissions is a local matter, but it is RECOMMENDED that this period should be twice the shortest refresh period of any LSP associated with the Call. When there are no LSPs associated with a Call, an LSR is RECOMMENDED to use a refresh period of no less than one minute. The Notify messages are identical to those sent as if establishing the Call for the first time, except for the LINK_CAPABILITY object, which may have changed since the Call was first established, due to, e.g., the establishment of Connections, link failures, or the addition of new component links. The current link information is useful for the establishment of subsequent Connections. A node that receives a refresh Notify message carrying the R bit in the ADMIN_STATUS object MUST respond with a Notify response. A node that receives a refresh Notify message (response or request) MAY reset its timer - thus, in normal processing, Notify refreshes involve a single exchange once per time period.
呼叫的发起方和终止方应定期发送通知消息，以保持呼叫活动并处理入口或出口节点重启。这些重传的时间段是本地事务，但建议该时间段应为与呼叫相关的任何LSP的最短刷新时间的两倍。当没有与呼叫相关联的LSP时，建议LSR使用不少于一分钟的刷新周期。Notify消息与第一次建立呼叫时发送的消息相同，但LINK_能力对象除外，该对象可能在首次建立呼叫后由于建立连接、链路故障或添加新的组件链路而发生更改。当前链接信息对于建立后续连接非常有用。接收到刷新通知消息（在ADMIN_STATUS对象中包含R位）的节点必须使用Notify响应进行响应。接收刷新通知消息（响应或请求）的节点可以重置其计时器-因此，在正常处理中，通知刷新每个时间段涉及一次单一交换。
A node (sender or receiver) that is unsure of the status of a Call MAY immediately send a Notify message as if establishing the Call for the first time.
不确定呼叫状态的节点（发送方或接收方）可以立即发送通知消息，就像第一次建立呼叫一样。
Failure to receive a refresh Notify request has no specific meaning. A node that fails to receive a refresh Notify request MAY send its own refresh Notify request to establish the status of the Call. If a node receives no response to a refresh Notify request (including no Message ID Acknowledgement), a node MAY assume that the remote node is unreachable or unavailable. It is a local policy matter whether this causes the local node to teardown associated LSPs and delete the Call.
未能接收刷新通知请求没有特定含义。未能接收刷新通知请求的节点可以发送其自己的刷新通知请求以建立呼叫的状态。如果节点没有收到对刷新通知请求的响应（包括没有消息ID确认），则节点可以假定远程节点不可访问或不可用。这是否会导致本地节点拆下关联的LSP并删除调用是本地策略的问题。
In the event that an edge node restarts without preserved state, it MAY relearn LSP state from adjacent nodes and Call state from remote nodes. If a Path or Resv message is received with a non-zero Call ID but without the C bit in the ADMIN_STATUS, and for a Call ID that is not recognized, the receiver is RECOMMENDED to assume that the Call establishment is delayed and ignore the received message. If the Call setup never materializes, the failure by the restarting node to refresh state will cause the LSPs to be torn down. Optionally, the receiver of such an LSP message for an unknown Call ID may return an error (PathErr or ResvErr message) with the error code "Call Management" and Error Value "Unknown Call ID".
如果边缘节点在没有保留状态的情况下重新启动，它可以从相邻节点重新学习LSP状态，并从远程节点调用状态。如果接收到的Path或Resv消息具有非零的呼叫ID，但在ADMIN_状态下没有C位，并且对于无法识别的呼叫ID，建议接收方假设呼叫建立延迟，并忽略接收到的消息。如果调用设置从未实现，则重新启动节点刷新状态失败将导致LSP被拆除。可选地，用于未知呼叫ID的这种LSP消息的接收器可以返回错误代码为“呼叫管理”且错误值为“未知呼叫ID”的错误（PathErr或ResvErr消息）。
This section considers the applicability of the different Call establishment procedures at the NNI and UNI reference points. This section is informative and is not intended to prescribe or prevent other options.
本节考虑了NNI和UNI参考点不同呼叫建立程序的适用性。本节仅供参考，无意规定或阻止其他选项。
Since the link properties and other traffic-engineering attributes are likely known through the IGP, the LINK_CAPABILITY object is not usually required.
由于链路属性和其他流量工程属性可能通过IGP已知，因此通常不需要链路能力对象。
In multi-domain networks, it is possible that access link properties and other traffic-engineering attributes are not known since the domains do not share this sort of information. In this case, the Call setup mechanism may include the LINK_CAPABILITY object.
在多域网络中，访问链路属性和其他流量工程属性可能未知，因为域不共享此类信息。在这种情况下，呼叫建立机制可以包括链路能力对象。
It is possible that the access link properties and other traffic-engineering attributes are not shared across the core network. In this case, the Call setup mechanism may include the LINK_CAPABILITY object.
访问链路属性和其他流量工程属性可能不在核心网络中共享。在这种情况下，呼叫建立机制可以包括链路能力对象。
Further, the first node within the network may be responsible for managing the Call. In this case, the Notify message that is used to set up the Call is addressed by the user network edge node to the first node of the core network. Moreover, neither the long Call ID nor the short Call ID is supplied (the Session Name Length is set to zero and the Call ID value is set to zero). The Notify message is passed to the first core node, which is responsible for generating the long and short Call IDs before dispatching the message to the remote Call end point (which is known from the SESSION object).
此外，网络内的第一节点可负责管理呼叫。在这种情况下，用于建立呼叫的通知消息由用户网络边缘节点寻址到核心网络的第一节点。此外，既不提供长调用ID也不提供短调用ID（会话名称长度设置为零，调用ID值设置为零）。Notify消息被传递到第一个核心节点，该节点负责在将消息分派到远程调用端点（从会话对象知道）之前生成长呼叫ID和短呼叫ID。
Further, when used in an overlay context, the first core node is allowed (see [RFC4208]) to replace the Session Name assigned by the ingress node and passed in the Path message. In the case of Call management, the first core node:
此外，当在覆盖上下文中使用时，允许第一核心节点（参见[RFC4208]）替换入口节点分配并在路径消息中传递的会话名称。在呼叫管理的情况下，第一个核心节点：
1) MAY insert a long Call ID in the Session Name of a Path message.
1) 可以在路径消息的会话名称中插入长呼叫ID。
2) MUST replace the Session Name with that originally issued by the user edge node when it returns the Resv message to the ingress node.
2) 当用户边缘节点将Resv消息返回到入口节点时，必须将会话名称替换为最初由用户边缘节点发出的名称。
Third party Call management agents may be used to apply policy and authorization at a point that is neither the initiator nor terminator of the Call. The previous example is a particular case of this, but the process and procedures are identical.
第三方呼叫管理代理可用于在既不是呼叫发起方也不是呼叫终止方的点应用策略和授权。前面的示例是这种情况的一种特殊情况，但过程和步骤是相同的。
Call Segments exist between a set of default and configured External Call Managers along a path between the ingress and egress nodes, and use the protocols described in this document.
呼叫段存在于一组默认和配置的外部呼叫管理器之间，沿着入口和出口节点之间的路径，并使用本文档中描述的协议。
The techniques that are used by a given service provider to identify which External Call Managers within its network should process a given Call are beyond the scope of this document.
给定服务提供商用于确定其网络中哪些外部呼叫经理应处理给定呼叫的技术超出了本文档的范围。
An External Call Manager uses normal IP routing to route the Notify message to the next External Call Manager. Notify messages (requests
外部呼叫管理器使用常规IP路由将Notify消息路由到下一个外部呼叫管理器。通知消息（请求）
and responses) are therefore encapsulated in IP packets that identify the sending and receiving External Call Managers, but the addresses used to identify the Call (the Sender Address in the SENDER_TEMPLATE object and the Tunnel Endpoint Address in the SESSION object) continue to identify the endpoints of the Call.
因此，和响应）封装在标识发送和接收外部呼叫管理器的IP数据包中，但用于标识呼叫的地址（发送方模板对象中的发送方地址和会话对象中的隧道端点地址）继续标识呼叫的端点。
It is important that the procedures described above operate as seamlessly as possible with legacy nodes that do not support the extensions described.
重要的是，上述过程与不支持所述扩展的遗留节点尽可能无缝地操作。
Clearly, there is no need to consider the case where the Call initiator does not support Call setup initiation.
显然，不需要考虑呼叫发起方不支持呼叫建立启动的情况。
It is unlikely that a Call initiator will be configured to send Call establishment Notify requests to an external Call manager, including the first core node, if that node does not support Call setup.
如果外部呼叫管理器（包括第一个核心节点）不支持呼叫设置，则呼叫发起方不太可能被配置为向该节点发送呼叫建立通知请求。
A node that receives an unexpected Call setup request will fall into one of the following categories.
接收到意外呼叫设置请求的节点将属于以下类别之一。
- Node does not support RSVP. The message will fail to be delivered or responded to. No Message ID Acknowledgement will be sent. The initiator will retry and then give up.
- 节点不支持RSVP。消息将无法传递或响应。不会发送消息ID确认。启动器将重试，然后放弃。
- Node supports RSVP or RSVP-TE but not GMPLS. The message will be delivered but not understood. It will be discarded. No Message ID Acknowledgement will be sent. The initiator will retry and then give up.
- 节点支持RSVP或RSVP-TE，但不支持GMPLS。消息将被传递，但不被理解。它将被丢弃。不会发送消息ID确认。启动器将重试，然后放弃。
- Node supports GMPLS but not Call management. The message will be delivered, but parsing will fail because of the presence of the SESSION_ATTRIBUTE object. A Message ID Acknowledgement may be sent before the parse fails. When the parse fails, the Notify message may be discarded in which case the initiator will retry and then give up; alternatively, a parse error may be generated and returned in a Notify message which will indicate to the initiator that Call management is not supported.
- 节点支持GMPLS，但不支持呼叫管理。消息将被传递，但由于存在SESSION_属性对象，解析将失败。可以在解析失败之前发送消息ID确认。当解析失败时，可能会丢弃Notify消息，在这种情况下，启动器将重试，然后放弃；或者，可能会生成解析错误并在通知消息中返回，该消息将向启动器指示不支持呼叫管理。
Transit nodes SHOULD NOT examine Notify messages that are not addressed to them. However, they will see short Call IDs in all messages for all LSPs associated with Calls.
传输节点不应检查未发送给它们的通知消息。但是，他们将在与呼叫相关联的所有LSP的所有消息中看到短呼叫ID。
Previous specifications state that these fields SHOULD be ignored on receipt and MUST be transmitted as zero. This might be interpreted by some implementations as meaning that the fields should be zeroed before the objects are forwarded. If this happens, LSP setup will not be possible. If either of the fields is zeroed either on the Path or the Resv message, the Resv message will reach the initiator with the field set to zero - this is an indication to the initiator that some node in the network is preventing Call management. Use of Explicit Routes may help to mitigate this issue by avoiding such nodes. Ultimately, however, it may be necessary to upgrade the offending nodes to handle these protocol extensions.
以前的规范规定，这些字段在接收时应被忽略，并且必须作为零传输。这可能被一些实现解释为意味着在转发对象之前字段应该归零。如果发生这种情况，将无法设置LSP。如果路径或Resv消息上的任一字段归零，Resv消息将到达启动器，字段设置为零-这表示启动器网络中的某个节点正在阻止呼叫管理。使用显式路由可以避免此类节点，从而有助于缓解此问题。但是，最终可能需要升级有问题的节点来处理这些协议扩展。
It is unlikely that an attempt will be made to set up a Call to a remote node that does not support Calls.
不太可能尝试设置对不支持调用的远程节点的调用。
If the egress node does not support Call management through the Notify message, it will react (as described in Section 8.1) in the same way as an External Call Manager.
如果出口节点不支持通过Notify消息进行呼叫管理，它将以与外部呼叫管理器相同的方式作出反应（如第8.1节所述）。
Please refer to each of the documents referenced in the following sections for a description of the security considerations applicable to the features that they provide.
有关适用于其提供的功能的安全注意事项的说明，请参阅以下各节中引用的每个文档。
Call setup is vulnerable to attacks both of spoofing and denial of service. Since Call setup uses Notify messages, the process can be protected by the use of the INTEGRITY object to secure those messages as described in [RFC2205] and [RFC3473]. Deployments where security is a concern SHOULD use this mechanism.
呼叫设置容易受到欺骗和拒绝服务攻击。由于呼叫设置使用Notify消息，因此可以使用INTEGRITY对象来保护这些消息，如[RFC2205]和[RFC3473]中所述。涉及安全性的部署应使用此机制。
Implementations and deployments MAY additionally protect the Call setup exchange using end-to-end security mechanisms such as those provided by IPsec (see [RFC4302] and [RFC4303]), or using RSVP security [RFC2747].
实现和部署还可以使用端到端安全机制（如IPsec提供的安全机制（请参见[RFC4302]和[RFC4303]）或使用RSVP安全机制[RFC2747]）来保护呼叫设置交换机。
Note, additionally, that it would be desirable to use the process of independent Call establishment, where the Call is set up separately from the LSPs, to apply an extra level of authentication and policy for the end-to-end LSPs above that which is available with Call-less, hop-by-hop LSP setup. However doing so will require additional work to set up security associations between the peer and the call manager that meet the requirements of [RFC4107]. The mechanism described in this document is expected to meet this use case when combined with
另外，注意，希望使用独立呼叫建立的过程（其中呼叫与LSP分开设置）来为端到端LSP应用额外级别的认证和策略，其高于无呼叫逐跳LSP设置可用的认证和策略。但是，这样做将需要额外的工作，以便在对等方和呼叫管理器之间建立符合[RFC4107]要求的安全关联。本文档中描述的机制在与
this additional work. Application of this mechanism to the authentication and policy use case prior to standardization of a security solution is inappropriate and outside the current applicability of the mechanism.
这是额外的工作。在安全解决方案标准化之前，将此机制应用于身份验证和策略用例是不合适的，并且超出了该机制当前的适用范围。
The frequency of Call establishment is application dependent and hard to generalize. Key exchange for Call-related message exchanges is therefore something that should be configured or arranged dynamically in different deployments according to the advice in [RFC4107]. Note that the remote RSVP-TE signaling relationship between Call endpoints is no different from the signaling relationship between LSRs that establish an LSP. That is, the LSRs are not necessarily IP-adjacent in the control plane in either case. Thus, key exchange should be regarded as a remote procedure, not a single hop procedure. There are several procedures for automatic remote exchange of keys, and IKEv2 [RFC4306] is particularly suggested in [RFC3473].
呼叫建立的频率取决于应用程序，难以概括。因此，呼叫相关消息交换的密钥交换应该根据[RFC4107]中的建议在不同部署中动态配置或安排。注意，呼叫端点之间的远程RSVP-TE信令关系与建立LSP的LSR之间的信令关系没有区别。也就是说，在这两种情况下，lsr在控制平面中不一定是IP相邻的。因此，密钥交换应该被视为一个远程过程，而不是一个单跳过程。有几种自动远程交换密钥的程序，[RFC3473]中特别建议使用IKEv2[RFC4306]。
A new RSVP object is introduced. IANA has made an assignment from the "RSVP Parameters" registry using the sub-registry "Class Names, Class Numbers, and Class Types".
引入了一个新的RSVP对象。IANA已使用子注册表“类名、类号和类类型”从“RSVP参数”注册表中进行分配。
o LINK_CAPABILITY object
o 链接功能对象
Class-Num = 133 (form 10bbbbbb)
类别编号=133（表格10BBBB）
The Class Number is selected so that nodes not recognizing this object drop it silently. That is, the top bit is set and the next bit is cleared.
选择类别编号，以便不识别此对象的节点以静默方式放置它。也就是说，设置顶部位，清除下一位。
C-Type = 1 (TE Link Capabilities)
C型=1（TE链路能力）
The LINK_CAPABILITY object is only defined for inclusion on Notify messages.
链接功能对象仅定义为包含在通知消息中。
Refer to Section 5.3 of this document.
参考本文件第5.3节。
IANA maintains a list of subobjects that may be carried in this object. This list is maintained in the registry entry for the LINK_CAPABILITY object as is common practice for the subobjects of other RSVP objects. For each subobject, IANA lists:
IANA维护此对象中可能包含的子对象列表。与其他RSVP对象的子对象的常见做法一样，此列表保存在链接功能对象的注册表项中。对于每个子对象，IANA列出：
- subobject type number - subobject name - reference indicating where subobject is defined.
- 子对象类型编号-子对象名称-指示子对象定义位置的参考。
The initial list of subobjects is provided in Section 5.3 of this document.
本文件第5.3节提供了子对象的初始列表。
A new RSVP Error Code and new Error Values are introduced. IANA has made assignments from the "RSVP Parameters" registry using the sub-registry "Error Codes and Globally-Defined Error Value Sub-Codes".
引入了新的RSVP错误代码和新的错误值。IANA已使用子注册表“错误代码和全局定义的错误值子代码”从“RSVP参数”注册表进行分配。
o Error Codes: - Call Management (value 32)
o 错误代码：-呼叫管理（值32）
o Error Values: - Call Management/Call ID Contention (value 1) - Call Management/Connections Still Exist (value 2) - Call Management/Unknown Call ID (value 3) - Call Management/Duplicate Call (value 4)
o 错误值：-呼叫管理/呼叫ID争用（值1）-呼叫管理/连接仍然存在（值2）-呼叫管理/未知呼叫ID（值3）-呼叫管理/重复呼叫（值4）
[GMPLS-E2E] requested that IANA manage the bits of the RSVP ADMIN_STATUS object. A new "Administrative Status Information Flags" sub-registry of the "GMPLS Signaling Parameters" registry was created.
[GMPLS-E2E]请求IANA管理RSVP ADMIN_STATUS对象的位。创建了“GMPLS信令参数”注册表的新“管理状态信息标志”子注册表。
This document defines one new bit, the C bit, to be tracked in that sub-registry. Bit number 28 has been assigned. See Section 5.5 of this document.
本文档定义了一个新的位，即C位，在该子注册表中进行跟踪。已分配位号28。见本文件第5.5节。
The authors would like to thank George Swallow, Yakov Rekhter, Lou Berger, Jerry Ash, and Kireeti Kompella for their very useful input to, and comments on, an earlier revision of this document.
作者要感谢George Swallow、Yakov Rekhter、Lou Berger、Jerry Ash和Kireeti Kompella对本文件早期修订的非常有用的投入和评论。
Thanks to Lyndon Ong and Ben Mack-Crane for lengthy discussions during and after working group last call, and to Deborah Brungard for a final, detailed review.
感谢Lyndon Ong和Ben Mack Crane在工作组最后一次电话会议期间和之后进行了长时间的讨论，并感谢Deborah Brungard进行了最后的详细审查。
Thanks to Suresh Krishnan for the GenArt review, and to Magnus Nystrom for discussions about security.
感谢Suresh Krishnan的GenArt评论，感谢Magnus Nystrom关于安全性的讨论。
Useful comments were received during IESG review from Brian Carpenter, Lars Eggert, Ted Hardie, Sam Hartman, and Russ Housley.
IESG审查期间收到了来自布赖恩·卡彭特、拉尔斯·艾格特、特德·哈迪、萨姆·哈特曼和罗斯·霍斯利的有用意见。
[GMPLS-E2E] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[GMPLS-E2E]Lang，J.，Ed.，Rekhter，Y.，Ed.，和D.Papadimitriou，Ed.，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，2007年5月。
[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月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年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月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[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月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208]Swallow，G.，Drake，J.，Ishimatsu，H.，和Y.Rekhter，“通用多协议标签交换（GMPLS）用户网络接口（UNI）：覆盖模型的资源预留协议流量工程（RSVP-TE）支持”，RFC 4208，2005年10月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006.
[RFC4426]Lang，J.，Ed.，Rajagopalan，B.，Ed.，和D.Papadimitriou，Ed.，“通用多协议标签交换（GMPLS）恢复功能规范”，RFC 4426，2006年3月。
[ASON-APPL] Drake, J., Papadimitriou, D., Farrel, A., Brungard, D., Ali, Z., Ayyangar, A., Ould-Brahim, H., and D. Fedyk, "Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON), Work in Progress, July 2005.
[ASON-APPL]Drake，J.，Papadimitriou，D.，Farrel，A.，Brungard，D.，Ali，Z.，Ayyangar，A.，Ould Brahim，H.，和D.Fedyk，“支持自动交换光网络（ASON）的通用MPLS（GMPLS）RSVP-TE信令”，正在进行中的工作，2005年7月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. Ong, "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 4139, July 2005.
[RFC4139]Papadimitriou，D.，Drake，J.，Ash，J.，Farrel，A.，和L.Ong，“自动交换光网络（ASON）的通用MPLS（GMPLS）信令使用和扩展要求”，RFC 4139，2005年7月。
[STITCH] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", Work in Progress, April 2007.
[STITCH]Ayyangar，A.，Kompella，K.，Vasseur，JP.，和A.Farrel，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，正在进行的工作，2007年4月。
For information on the availability of the following document, please see http://www.itu.int.
有关以下文档的可用性信息，请参阅http://www.itu.int.
[G.8080] ITU-T, "Architecture for the Automatically Switched Optical Network (ASON)," Recommendation G.8080/ Y.1304, November 2001 (and Revision, January 2003).
[G.8080]ITU-T，“自动交换光网络（ASON）的体系结构”，建议G.8080/Y.13042001年11月（修订版，2003年1月）。
Authors' Addresses
作者地址
John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245 EMail: John.E.Drake2@boeing.com
约翰德雷克波音卫星系统2300东帝国公路埃尔塞贡多，加利福尼亚90245电子邮件：约翰E。Drake2@boeing.com
Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA EMail: dbrungard@att.com
德博拉·布伦加德（美国电话电报公司）Rm。D1-3C22-200美国新泽西州米德尔敦S.Laurel大道07748号电子邮件：dbrungard@att.com
Zafar Ali (Cisco) 100 South Main St. #200 Ann Arbor, MI 48104, USA EMail: zali@cisco.com
Zafar Ali（思科）美国密歇根州安阿伯市南大街100号，邮编：48104电子邮件：zali@cisco.com
Arthi Ayyangar (Nuova Systems) 2600 San Tomas Expressway Santa Clara, CA 95051 EMail: arthi@nuovasystems.com
Arthi Ayangar（Nuova Systems）2600 San Tomas高速公路加利福尼亚州圣克拉拉市95051电子邮件：arthi@nuovasystems.com
Don Fedyk (Nortel Networks) 600 Technology Park Drive Billerica, MA, 01821, USA EMail: dwfedyk@nortel.com
Don Fedyk（北电网络）美国马萨诸塞州比利里卡科技园大道600号，邮编01821电子邮件：dwfedyk@nortel.com
Contact Addresses
联系地址
Dimitri Papadimitriou Alcatel-Lucent, Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel-lucent.be
Dimitri Papadimitriou Alcatel-Lucent，Fr.Wellesplein 1，B-2018比利时安特卫普电话：+32 3 240-8491电子邮件：Dimitri。papadimitriou@alcatel-朗讯
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
阿德里安·法雷尔老狗咨询电话：+44（0）1978 860944电子邮件：adrian@olddog.co.uk
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。