分类： 系统运维
2007-09-17 22:14:54
Network Working Group D. Awduche
Request for Comments: 3209 Movaz Networks, Inc.
Category: Standards Track L. Berger
D. Gan
Juniper Networks, Inc.
T. Li
Procket Networks, Inc.
V. Srinivasan
Cosine Communications, Inc.
G. Swallow
Cisco Systems, Inc.
December 2001
RSVP-TE: Extensions to RSVP for LSP Tunnels
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.
//本文档作用，如何获取版本的最新状态。如何如何。
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes the use of RSVP (Resource Reservation
Protocol), including all the necessary extensions, to establish
label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).
Since the flow along an LSP is completely identified by the label
applied at the ingress node of the path, these paths may be treated
as tunnels. A key application of LSP tunnels is traffic engineering
with MPLS as specified in RFC 2702.
//本文档描述通过使用RSVP，包含一些必要的扩展，在MPLS网络中创建LSP。
//当顺着LSP的流量仅通过首节点分配的标签区分时，该LSP即是一个隧道。
//LSP隧道的关键应用是RFC2702描述的MPLS流量工程。
We propose several additional objects that extend RSVP, allowing the
establishment of explicitly routed label switched paths using RSVP as
a signaling protocol. The result is the instantiation of label-
switched tunnels which can be automatically routed away from network
failures, congestion, and bottlenecks.
//我们计划添加一些新的对象以扩展RSVP，允许使用RSVP作为信令协议创建一个
//显示路由LSP。这可以使创建的LSP可以自动的绕开网络故障，拥塞和瓶颈。
Awduche, et al. Standards Track [Page 1]
RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Contents
1 Introduction .......................................... 3
1.1 Background ............................................. 4
1.2 Terminology ............................................ 6
2 Overview .............................................. 7
2.1 LSP Tunnels and Traffic Engineered Tunnels ............. 7
2.2 Operation of LSP Tunnels ............................... 8
2.3 Service Classes ........................................ 10
2.4 Reservation Styles ..................................... 10
2.4.1 Fixed Filter (FF) Style ................................ 10
2.4.2 Wildcard Filter (WF) Style ............................. 11
2.4.3 Shared Explicit (SE) Style ............................. 11
2.5 Rerouting Traffic Engineered Tunnels ................... 12
2.6 Path MTU ............................................... 13
3 LSP Tunnel related Message Formats ..................... 15
3.1 Path Message ........................................... 15
3.2 Resv Message ........................................... 16
4 LSP Tunnel related Objects ............................. 17
4.1 Label Object ........................................... 17
4.1.1 Handling Label Objects in Resv messages ................ 17
4.1.2 Non-support of the Label Object ........................ 19
4.2 Label Request Object ................................... 19
4.2.1 Label Request without Label Range ...................... 19
4.2.2 Label Request with ATM Label Range ..................... 20
4.2.3 Label Request with Frame Relay Label Range ............. 21
4.2.4 Handling of LABEL_REQUEST .............................. 22
4.2.5 Non-support of the Label Request Object ................ 23
4.3 Explicit Route Object .................................. 23
4.3.1 Applicability .......................................... 24
4.3.2 Semantics of the Explicit Route Object ................. 24
4.3.3 Subobjects ............................................. 25
4.3.4 Processing of the Explicit Route Object ................ 28
4.3.5 Loops .................................................. 30
4.3.6 Forward Compatibility .................................. 30
4.3.7 Non-support of the Explicit Route Object ............... 31
4.4 Record Route Object .................................... 31
4.4.1 Subobjects ............................................. 31
4.4.2 Applicability .......................................... 34
4.4.3 Processing RRO ......................................... 35
4.4.4 Loop Detection ......................................... 36
4.4.5 Forward Compatibility .................................. 37
4.4.6 Non-support of RRO ..................................... 37
4.5 Error Codes for ERO and RRO ............................ 37
4.6 Session, Sender Template, and Filter Spec Objects ...... 38
4.6.1 Session Object ......................................... 39
4.6.2 Sender Template Object ................................. 40
4.6.3 Filter Specification Object ............................ 42
Awduche, et al. Standards Track [Page 2]
RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
4.6.4 Reroute and Bandwidth Increase Procedure ............... 42
4.7 Session Attribute Object ............................... 43
4.7.1 Format without resource affinities ..................... 43
4.7.2 Format with resource affinities ........................ 45
4.7.3 Procedures applying to both C-Types .................... 46
4.7.4 Resource Affinity Procedures .......................... 48
5 Hello Extension ........................................ 49
5.1 Hello Message Format ................................... 50
5.2 HELLO Object formats ................................... 51
5.2.1 HELLO REQUEST object ................................... 51
5.2.2 HELLO ACK object ....................................... 51
5.3 Hello Message Usage .................................... 52
5.4 Multi-Link Considerations .............................. 53
5.5 Compatibility .......................................... 54
6 Security Considerations ................................ 54
7 IANA Considerations .................................... 54
7.1 Message Types .......................................... 55
7.2 Class Numbers and C-Types .............................. 55
7.3 Error Codes and Globally-Defined Error Value Sub-Codes . 57
7.4 Subobject Definitions .................................. 57
8 Intellectual Property Considerations ................... 58
9 Acknowledgments ........................................ 58
10 References ............................................. 58
11 Authors' Addresses ..................................... 60
12 Full Copyright Statement ............................... 61
1. Introduction
Section 2.9 of the MPLS architecture [2] defines a label distribution
protocol as a set of procedures by which one Label Switched Router
(LSR) informs another of the meaning of labels used to forward
traffic between and through them. The MPLS architecture does not
assume a single label distribution protocol. This document is a
specification of extensions to RSVP for establishing label switched
paths (LSPs) in MPLS networks.
//一个LSR通告其他LSR一些标签，这些标签用于在LSR之间转发流量。[2]的
//2.9章节通过描述以上处理过程，定义一个标签分配协议。MPLS架构不单指
//一个独立的标签分配协议。该文档着重描述对RSVP的扩展以在MPLS网络中
//建立标签交换路径(LSPs)。
Several of the new features described in this document were motivated
by the requirements for traffic engineering over MPLS (see [3]). In
particular, the extended RSVP protocol supports the instantiation of
explicitly routed LSPs, with or without resource reservations. It
also supports smooth rerouting of LSPs, preemption, and loop
detection.
//本文档描述的几个新特性由[3]所推动。特别的，扩展的RSVP协议支持显示路
//由LSP的实现，预留或不预留资源。同时支持对LSP的平滑(无损?)重路由，
//抢占，和环路检测。
The LSPs created with RSVP can be used to carry the "Traffic Trunks"
described in [3]. The LSP which carries a traffic trunk and a
traffic trunk are distinct though closely related concepts. For
example, two LSPs between the same source and destination could be
load shared to carry a single traffic trunk. Conversely several
//RSVP创建的LSPs可以用于运送[3]中描述的"Trunks"。运送Tranks的LSP与
//Trank虽然概念很具有相关性，但却是截然不同。例如，在同一原宿之间的
//2个LSPs运送同一个Trank时可以共享负载。
Awduche, et al. Standards Track [Page 3]
RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
traffic trunks could be carried in the same LSP if, for instance, the
LSP were capable of carrying several service classes. The
applicability of these extensions is discussed further in [10].
//反过来，多个Tranks可以被同一个LSP运送，例如，LSP能够运送多个服务等级。
//这些扩展的应用在[10]中讨论。
Since the traffic that flows along a label-switched path is defined
by the label applied at the ingress node of the LSP, these paths can
be treated as tunnels, tunneling below normal IP routing and
filtering mechanisms. When an LSP is used in this way we refer to it
as an LSP tunnel.
//根据LSP的首节点申请的标签，流量顺着标签交换路径转发，这种路径可以称
//为隧道，隧道在IP路由和过滤机制的下层。当一个LSP起这样的作用时，我们
//称之为LSP隧道。
LSP tunnels allow the implementation of a variety of policies related
to network performance optimization. For example, LSP tunnels can be
automatically or manually routed away from network failures,
congestion, and bottlenecks. Furthermore, multiple parallel LSP
tunnels can be established between two nodes, and traffic between the
two nodes can be mapped onto the LSP tunnels according to local
policy. Although traffic engineering (that is, performance
optimization of operational networks) is expected to be an important
application of this specification, the extended RSVP protocol can be
used in a much wider context.
//LSP隧道可以执行一系列与网络性能优化有关的策略。例如，LSP隧道可以自动
//或人工的避开网络故障、拥塞和瓶颈。此外，可以在两个节点间建立多个并行
//的LSP隧道，且这两个节点之间的流量可以根据本地策略映射到这些LSP隧道上。
//扩展的RSVP协议可以应用在更广的范围，虽然流量工程(网络性能优化)是一个
//重要的应用。
The purpose of this document is to describe the use of RSVP to
establish LSP tunnels. The intent is to fully describe all the
objects, packet formats, and procedures required to realize
interoperable implementations. A few new objects are also defined
that enhance management and diagnostics of LSP tunnels.
//本文档的意图是描述使用RSVP建立LSP隧道。充分的描述所有的对象，包
//格式，和实现可互操作的处理流程需求。为增前管理和诊断LSP隧道，本
//文档新定义了一些对象。
The document also describes a means of rapid node failure detection
via a new HELLO message.
//本文档还描述了通过HELLO消息，快速检测节点失效的办法。
All objects and messages described in this specification are optional
with respect to RSVP. This document discusses what happens when an
object described here is not supported by a node.
//对于RSVP而言，本文档所描述的所有对象和消息都是可选的。当一节点收到
//一个本文描述的对象，但其不支持该对象时，本文亦有讨论。
Throughout this document, the discussion will be restricted to
unicast label switched paths. Multicast LSPs are left for further
study.
//本文所有的讨论，只限于单播LSP。多播LSP留在后续学习。
1.1. Background
//背景
Hosts and routers that support both RSVP [1] and Multi-Protocol Label
Switching [2] can associate labels with RSVP flows. When MPLS and
RSVP are combined, the definition of a flow can be made more
flexible. Once a label switched path (LSP) is established, the
traffic through the path is defined by the label applied at the
ingress node of the LSP. The mapping of label to traffic can be
accomplished using a number of different criteria. The set of
packets that are assigned the same label value by a specific node are
//支持RSVP和MPLS的主机和路由器可以把标签和RSVP业务流关联起来。当MPLS和
//RSVP相结合，业务流的定义可以更加的灵活。当标签交换路径(LSP)被建立，
//根据LSP的首节点分配的标签，流量可以穿过整个路径。标签和流量的映射
//可以使用一系列不同的标准完成。同一节点，一批打上相同标签的包被认为
Awduche, et al. Standards Track [Page 4]
RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
said to belong to the same forwarding equivalence class (FEC) (see
[2]), and effectively define the "RSVP flow." When traffic is mapped
onto a label-switched path in this way, we call the LSP an "LSP
Tunnel". When labels are associated with traffic flows, it becomes
possible for a router to identify the appropriate reservation state
for a packet based on the packet's label value.
//属于同一个等价转发类(FEC)，这就是"RSVP业务流"。当流量通过该方式被映射
//到lsp上，我们成该LSP为"LSP隧道"。当标签与流量关联，路由器基于包的标签
//值为一个包确定合适的预留状态将变为可能。
The signaling protocol model uses downstream-on-demand label
distribution. A request to bind labels to a specific LSP tunnel is
initiated by an ingress node through the RSVP Path message. For this
purpose, the RSVP Path message is augmented with a LABEL_REQUEST
object. Labels are allocated downstream and distributed (propagated
upstream) by means of the RSVP Resv message. For this purpose, the
RSVP Resv message is extended with a special LABEL object. The
procedures for label allocation, distribution, binding, and stacking
are described in subsequent sections of this document.
//信令协议模块使用下游标签分配策略。为一个LSP隧道绑定一个标签的请求，
//是首节点通过PATH消息发起的。因此，PATH消息扩展了LABEL_REQUEST对象。
//标签在下游分配且通过RSVP RESV消息向上游传递。因此，RESV消息扩展了
//LABEL对象。标签分配、传递、绑定，标签栈在本文的后续章节讨论。
The signaling protocol model also supports explicit routing
capability. This is accomplished by incorporating a simple
EXPLICIT_ROUTE object into RSVP Path messages. The EXPLICIT_ROUTE
object encapsulates a concatenation of hops which constitutes the
explicitly routed path. Using this object, the paths taken by
label-switched RSVP-MPLS flows can be pre-determined, independent of
conventional IP routing. The explicitly routed path can be
administratively specified, or automatically computed by a suitable
entity based on QoS and policy requirements, taking into
consideration the prevailing network state. In general, path
computation can be control-driven or data-driven. The mechanisms,
processes, and algorithms used to compute explicitly routed paths are
beyond the scope of this specification.
//信令协议模块支持显示路由功能。该功能通过增加一个EXPLICIT_ROUTE对象
//到PATH消息中完成。EXPLICIT_ROUTE对象携带组成显示路由的一些列HOPs。
//通过该对象，标签交换的路径可以独立于常规的IP路由协议而预先定制。
//显示路由可以人为指定，或者由支持QoS和策略需求的实体自动计算，****
//通常，路由计算可以控制驱动或数据驱动。计算显示路由的机制、流程和算
//法超出了本文的讨论范围。
One useful application of explicit routing is traffic engineering.
Using explicitly routed LSPs, a node at the ingress edge of an MPLS
domain can control the path through which traffic traverses from
itself, through the MPLS network, to an egress node. Explicit
routing can be used to optimize the utilization of network resources
and enhance traffic oriented performance characteristics.
//显示路由的一个有益的应用是流量工程。使用显示路由，位于MPLS域的首节
//点可以控制流量经过该域到末节点的路由。显示路由可以用于优化网络资源
//的使用，且可以增强面向流量的特性。
The concept of explicitly routed label switched paths can be
generalized through the notion of abstract nodes. An abstract node
is a group of nodes whose internal topology is opaque to the ingress
node of the LSP. An abstract node is said to be simple if it
contains only one physical node. Using this concept of abstraction,
an explicitly routed LSP can be specified as a sequence of IP
prefixes or a sequence of Autonomous Systems.
//显示路由LSP可以穿过抽象节点。抽象节点就是内部拓扑对LSP首节点一不透明
//的一组节点。最简单的，一个物理节点就是一个抽象节点。使用这个概念，
//显示路由LSP可以被一堆IP前缀或自治域(AS)所指定。
Awduche, et al. Standards Track [Page 5]
RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
The signaling protocol model supports the specification of an
explicit path as a sequence of strict and loose routes. The
combination of abstract nodes, and strict and loose routes
significantly enhances the flexibility of path definitions.
//信令协议支持一堆严格和松散的路由作为显示路由。抽象节点和严格
//松散路由互相组合，可以增强定义路由的灵活性。
An advantage of using RSVP to establish LSP tunnels is that it
enables the allocation of resources along the path. For example,
bandwidth can be allocated to an LSP tunnel using standard RSVP
reservations and Integrated Services service classes [4].
//使用RSVP创建LSP隧道的优势是它能够在路径上分配资源。例如，使用
//标准的RSVP预留，带宽可以分配给一个LSP隧道。
While resource reservations are useful, they are not mandatory.
Indeed, an LSP can be instantiated without any resource reservations
whatsoever. Such LSPs without resource reservations can be used, for
example, to carry best effort traffic. They can also be used in many
other contexts, including implementation of fall-back and recovery
policies under fault conditions, and so forth.
//资源预留很游泳，但是不是强制的，一个LSP可以没有任何预留的资源。这种
//没有预留资源的LSP可以用于传送尽力而为的流量。另外，还有一些其他应用
//场景，****，等等。
1.2. Terminology
//术语
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 [6].
The reader is assumed to be familiar with the terminology in [1], [2]
and [3].
Abstract Node
A group of nodes whose internal topology is opaque to the ingress
node of the LSP. An abstract node is said to be simple if it
contains only one physical node.
Explicitly Routed LSP
An LSP whose path is established by a means other than normal IP
routing.
Label Switched Path
The path created by the concatenation of one or more label
switched hops, allowing a packet to be forwarded by swapping
labels from an MPLS node to another MPLS node. For a more precise
definition see [2].
LSP
A Label Switched Path
Awduche, et al. Standards Track [Page 6]
RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
LSP Tunnel
An LSP which is used to tunnel below normal IP routing and/or
filtering mechanisms.
Traffic Engineered Tunnel (TE Tunnel)
A set of one or more LSP Tunnels which carries a traffic trunk.
Traffic Trunk
A set of flows aggregated by their service class and then placed
on an LSP or set of LSPs called a traffic engineered tunnel. For
further discussion see [3].
2. Overview
2.1. LSP Tunnels and Traffic Engineered Tunnels
According to [1], "RSVP defines a 'session' to be a data flow with a
particular destination and transport-layer protocol." However, when
RSVP and MPLS are combined, a flow or session can be defined with
greater flexibility and generality. The ingress node of an LSP can
use a variety of means to determine which packets are assigned a
particular label. Once a label is assigned to a set of packets, the
label effectively defines the "flow" through the LSP. We refer to
such an LSP as an "LSP tunnel" because the traffic through it is
opaque to intermediate nodes along the label switched path.
//RSVP通过一个目的地和传输层协议号来定义一个"会话"，用以描述一个数据
//流。另外，当RSVP和MPLS结合，数据流(或会话)可以定义的更加灵活和通用。
//LSP的首节点可以使用一些方法检测哪些包应该打上特定的标签。当标签被
//打在一些包上，该标签有效的定义通过该LSP的"flow"。我们称该类LSP为LSP
//隧道。因为流量经过该LSP对该LSP上的中间接点是不透明的。
New RSVP SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects, called
LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 have been defined to support the
LSP tunnel feature. The semantics of these objects, from the
perspective of a node along the label switched path, is that traffic
belonging to the LSP tunnel is identified solely on the basis of
packets arriving from the PHOP or "previous hop" (see [1]) with the
particular label value(s) assigned by this node to upstream senders
to the session. In fact, the IPv4(v6) that appears in the object
name only denotes that the destination address is an IPv4(v6)
address. When we refer to these objects generically, we use the
qualifier LSP_TUNNEL.
//新定义了LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6类型SENDER_TEMPLATE对象,
//FILTER_SPEC,SESSION用于支持LSP隧道特性。之所以这样称呼这些对象
//(IPv4,IPv6后缀), 是因为经LSP隧道运送的流量仅仅靠从PHOP收到的具有特定
//标签的包来确定(该标签由本节点分配传递给会话的上游节点)。其实，对象
//名的IPv4(IPv6)仅仅表明目的地址是一个IPv4(IPv6)地址。通常，我们简称
//那些对象为LSP_TUNNEL。
In some applications it is useful to associate sets of LSP tunnels.
This can be useful during reroute operations or to spread a traffic
trunk over multiple paths. In the traffic engineering application
such sets are called traffic engineered tunnels (TE tunnels). To
enable the identification and association of such LSP tunnels, two
identifiers are carried. A tunnel ID is part of the SESSION object.
The SESSION object uniquely defines a traffic engineered tunnel. The
//在某些应用场景，关联一组LSP隧道很有用。重路由操作或把一个trunk放在
//多个路径上传播。在流量工程应用中，这些组称为TE tunnel。为了区分和
//关联这种LSP隧道，需要传递2个标识符。SESSION对象的一部分tunnel ID。
//SESSION对象唯一的确定一个TE tunnel。
Awduche, et al. Standards Track [Page 7]
RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID. The
SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION
object uniquely identifies an LSP tunnel
//SENDER_TEMPLATE(path消息携带)和FILTER_SPEC(resv消息携带)对象携带
//LSP_ID。SENDER_TEMPLATE对象和SESSION对象唯一的确定一个LSP tunnel。
2.2. Operation of LSP Tunnels
This section summarizes some of the features supported by RSVP as
extended by this document related to the operation of LSP tunnels.
These include: (1) the capability to establish LSP tunnels with or
without QoS requirements, (2) the capability to dynamically reroute
an established LSP tunnel, (3) the capability to observe the actual
route traversed by an established LSP tunnel, (4) the capability to
identify and diagnose LSP tunnels, (5) the capability to preempt an
established LSP tunnel under administrative policy control, and (6)
the capability to perform downstream-on-demand label allocation,
distribution, and binding. In the following paragraphs, these
features are briefly described. More detailed descriptions can be
found in subsequent sections of this document.
//本小节概述扩展RSVP的特性，以及相关对LSP隧道的处理方法。包括：(1)
//建立有/无Qos属性的LSP隧道,(2)动态重路由一个LSP隧道,(3)获取LSP隧道
//的实际路由,(4)区分和诊断LSP隧道,(5)在管理状态控制下抢占一个已创建
//LSP,(6)下游标签分配和绑定等功能。本章节的后续部分只是一个简单的描
//述。本文档的后续章节将对以上功能进行详细的描述。
To create an LSP tunnel, the first MPLS node on the path -- that is,
the sender node with respect to the path -- creates an RSVP Path
message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and
inserts a LABEL_REQUEST object into the Path message. The
LABEL_REQUEST object indicates that a label binding for this path is
requested and also provides an indication of the network layer
protocol that is to be carried over this path. The reason for this
is that the network layer protocol sent down an LSP cannot be assumed
to be IP and cannot be deduced from the L2 header, which simply
identifies the higher layer protocol as MPLS.
//为了创建一个LSP隧道,路径上的第一个MPLS节点(该path的sender节点)创建
//一个RSVP PATH消息，该PATH携带一个会话类型为LSP_TUNNEL_IPv4(6)的
//LABEL_REQUEST对象。该对象表明请求为该路径绑定一个标签，同时提供一个
//该路径运送的数据包的网络层协议号。 携带协议号的原因是不能假定该协议
//为IP，而且不能通过L2头部推测出来，因为L2头部通常表明协议号为MPLS。
If the sender node has knowledge of a route that has high likelihood
of meeting the tunnel's QoS requirements, or that makes efficient use
of network resources, or that satisfies some policy criteria, the
node can decide to use the route for some or all of its sessions. To
do this, the sender node adds an EXPLICIT_ROUTE object to the RSVP
Path message. The EXPLICIT_ROUTE object specifies the route as a
sequence of abstract nodes.
//如果sender节点发现一个路由很可能有Qos需求，或需要更有效的使用网络资
//源，或满足一些策略标准，该节点可以决定部分或者全部会话使用该路由。
//为了实现该功能，sender节点在PATH消息中添加一个EXPLICIT_ROUTE对象。
//该对象通过一堆抽象节点详细的描述该路由。
If, after a session has been successfully established, the sender
node discovers a better route, the sender can dynamically reroute the
session by simply changing the EXPLICIT_ROUTE object. If problems
are encountered with an EXPLICIT_ROUTE object, either because it
causes a routing loop or because some intermediate routers do not
support it, the sender node is notified.
//当会话建立成功，sender节点发现一个更优路由，sender可以通过修改对象
//EXPLICT_OBJECT动态的重路由。如果EXPLICT_ROUTE对象有误，或形成路由
//环路，或某些中间节点不支持该对象，sender节点需要被通告。
By adding a RECORD_ROUTE object to the Path message, the sender node
can receive information about the actual route that the LSP tunnel
traverses. The sender node can also use this object to request
//通过在PATH消息中添加RECORD_ROUTE对象，sender节点可以收到LSP隧道
//经过的实际路由。
Awduche, et al. Standards Track [Page 8]
RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
notification from the network concerning changes to the routing path.
The RECORD_ROUTE object is analogous to a path vector, and hence can
be used for loop detection.
//同样，sender节点可以要求被通知，如果路由改变了通过该对象告知sender。
//该对象与路由向量相似，因此可以用于环路检测。
Finally, a SESSION_ATTRIBUTE object can be added to Path messages to
aid in session identification and diagnostics. Additional control
information, such as setup and hold priorities, resource affinities
(see [3]), and local-protection, are also included in this object.
//最后，PTAH消息中可以添加SESSION_ATTRIBUTE对象，有助于会话的区分和
//诊断。该对象还包括额外的控制信息，如创建和保持属性，资源亲和属性，
//和本地保护属性。
Routers along the path may use the setup and hold priorities along
with SENDER_TSPEC and any POLICY_DATA objects contained in Path
messages as input to policy control. For instance, in the traffic
engineering application, it is very useful to use the Path message as
a means of verifying that bandwidth exists at a particular priority
along an entire path before preempting any lower priority
reservations. If a Path message is allowed to progress when there
are insufficient resources, then there is a danger that lower
priority reservations downstream of this point will unnecessarily be
preempted in a futile attempt to service this request.
//该路径上的路由器使用Path中的SENDER_TSPEC或POLICY_DATA对象中携带的
//优先级，执行准入控制策略。例如，在流量工程应用中，在抢占任何低优先
//级预留前，PATH消息可以用于校验整个路径上在某个优先级上是否有足够的
//带宽。如果没有足够资源时，允许该PATH消息，那么处于本节点下游的低优
//先级LSP没必要为处理该请求而被抢占，这是很危险的。
When the EXPLICIT_ROUTE object (ERO) is present, the Path message is
forwarded towards its destination along a path specified by the ERO.
Each node along the path records the ERO in its path state block.
Nodes may also modify the ERO before forwarding the Path message. In
this case the modified ERO SHOULD be stored in the path state block
in addition to the received ERO.
//当存在ERO对象时，PATH消息将沿着ERO指定的路径转发到目的地。路径上的
//每个节点把ERO记录在它的PSB中。节点也可能在转发PATH之前修改ERO。此时
//修改后的ERO需要存储在PSB中。
The LABEL_REQUEST object requests intermediate routers and receiver
nodes to provide a label binding for the session. If a node is
incapable of providing a label binding, it sends a PathErr message
with an "unknown object class" error. If the LABEL_REQUEST object is
not supported end to end, the sender node will be notified by the
first node which does not provide this support.
//LABEL_REQUEST对象请求中间节点和末节点提供一个标签绑定，如果一个节点
//不能提供标签绑定，它将发送一个"unknown object class"错误码的PATHERR。
//如果多个节点不支持LABEL_REQUEST对象，第一个不支持的节点就应该通告
//Sender节点(不转发该PATH消息，而是发送PATHERR消息)。
The destination node of a label-switched path responds to a
LABEL_REQUEST by including a LABEL object in its response RSVP Resv
message. The LABEL object is inserted in the filter spec list
immediately following the filter spec to which it pertains.
//为了响应LABEL_REQUEST对象，LSP的末节点应答包含LABEL对象的RESV消息。
//LABEL内嵌其所属的并紧跟在的filter spec后面的filter spec list中。
The Resv message is sent back upstream towards the sender, following
the path state created by the Path message, in reverse order. Note
that if the path state was created by use of an ERO, then the Resv
message will follow the reverse path of the ERO.
//RESV消息顺着PATH消息创建的PSB往上游发给sender，与PATH顺序相反。如果
//PSB是通过ERO创建的，那么RESV消息将顺着ERO相反方向往上发。
Each node that receives a Resv message containing a LABEL object uses
that label for outgoing traffic associated with this LSP tunnel. If
the node is not the sender, it allocates a new label and places that
label in the corresponding LABEL object of the Resv message which it
//收到包含LABEL对象的RESV消息的节点，使用该标签作为LSP隧道的出标签。
//如果非sender节点，它分配一个新标签，并把该标签填到发往上游的RESV的
Awduche, et al. Standards Track [Page 9]
RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
sends upstream to the PHOP. The label sent upstream in the LABEL
object is the label which this node will use to identify incoming
traffic associated with this LSP tunnel. This label also serves as
shorthand for the Filter Spec. The node can now update its "Incoming
Label Map" (ILM), which is used to map incoming labeled packets to a
"Next Hop Label Forwarding Entry" (NHLFE), see [2].
//LABEL对象中。该标签是本节点用于区分与该LSP隧道相关的流量。该标签也
//是Filter Spec的简化描述。此时，节点可以更新本地的"Incoming Label Map"
//该ILM用于把收到的标签包映射到下一跳标签转发entry。
When the Resv message propagates upstream to the sender node, a
label-switched path is effectively established.
//当RESV消息传播到sender，一个LSP被创建。
