分类： 系统运维
2007-09-26 00:10:57
2.3. Service Classes
This document does not restrict the type of Integrated Service
requests for reservations. However, an implementation SHOULD support
the Controlled-Load service [4] and the Null Service [16].
//本文档不限制预留的集成服务请求类型。可是，一个实现应支持Null Service[6]
//和Controlled-Load service [4]。
2.4. Reservation Styles
//预留类型
The receiver node can select from among a set of possible reservation
styles for each session, and each RSVP session must have a particular
style. Senders have no influence on the choice of reservation style.
The receiver can choose different reservation styles for different
LSPs.
//末节点可以为会话选择预留类型类型，而且每个会话必须有一个特定预留类型。
//首节点不影响预留方式的选择。末额点可以为不同的LSP选择不同的预留类型。
An RSVP session can result in one or more LSPs, depending on the
reservation style chosen.
//一个会话根据预留类型可以产生一个或多个LSP。(预留类型是针对会话的)
Some reservation styles, such as FF, dedicate a particular
reservation to an individual sender node. Other reservation styles,
such as WF and SE, can share a reservation among several sender
nodes. The following sections discuss the different reservation
styles and their advantages and disadvantages. A more detailed
discussion of reservation styles can be found in [1].
//某些预留类型，如FF(固定)，为每个sender创建一个单独的预留。其他类型，
//如WF和SE，可以使多个sender共享一个预留。一下章节讨论不同预留类型及
//他们的优势和劣势。预留类型的更详细描述可以参考[1]。
2.4.1. Fixed Filter (FF) Style
The Fixed Filter (FF) reservation style creates a distinct
reservation for traffic from each sender that is not shared by other
senders. This style is common for applications in which traffic from
each sender is likely to be concurrent and independent. The total
amount of reserved bandwidth on a link for sessions using FF is the
sum of the reservations for the individual senders.
//固定预留方式为每个sender创建一个预留，而且不与其他sender共享。该
//方式通常用于每个sender的流量可能是并发和互相独立的。使用FF方式，一条
//链路上为会话预留的总带宽，是为哥哥sender预留的带宽的总和。
Because each sender has its own reservation, a unique label is
assigned to each sender. This can result in a point-to-point LSP
between every sender/receiver pair.
//每个发送者有它独有的预留，因此每个发送者分配一个唯一的标签。这形成
//一种发送者和接收者之间的点对点的LSP。
Awduche, et al. Standards Track [Page 10]
RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
2.4.2. Wildcard Filter (WF) Style
With the Wildcard Filter (WF) reservation style, a single shared
reservation is used for all senders to a session. The total
reservation on a link remains the same regardless of the number of
senders.
//在通配预留方式，为一个会话，值有一个预留被多个发送者共享，不论发
//送者数量，链路上总的预留的带宽总保持相等。
A single multipoint-to-point label-switched-path is created for all
senders to the session. On links that senders to the session share,
a single label value is allocated to the session. If there is only
one sender, the LSP looks like a normal point-to-point connection.
When multiple senders are present, a multipoint-to-point LSP (a
reversed tree) is created.
//会话为所有的发送者将创建一个多点到点的LSP。会话中多个发送节点共享
//的链路上，只会分配一个标签给该会话。如果只有一个发送者，该LSP就像
//一个普通的点到点连接。当存在多个发送者，将创建一个多点到点的LSP(
//预留树)。
This style is useful for applications in which not all senders send
traffic at the same time. A phone conference, for example, is an
application where not all speakers talk at the same time. If,
however, all senders send simultaneously, then there is no means of
getting the proper reservations made. Either the reserved bandwidth
on links close to the destination will be less than what is required
or then the reserved bandwidth on links close to some senders will be
greater than what is required. This restricts the applicability of
WF for traffic engineering purposes.
//该预留方式常用在不是所有的发送者的应用程序同时发送信息。比如：电话
//会议，是一种并非所有与会者同时发言的应用。如果所有sender同时发送数
//据，那么就没办法获取合适的预留。靠近接收者的预留链路带宽小于实际需
//求量，靠近发送者的预留链路带宽大于实际需求量。以上限制了WF方式在流
//量工程方面的适用性。
Furthermore, because of the merging rules of WF, EXPLICIT_ROUTE
objects cannot be used with WF reservations. As a result of this
issue and the lack of applicability to traffic engineering, use of WF
is not considered in this document.
//此外，因为WF方式的合并规则，WF方式下不能使用EXPLICIT_ROUTE对象。因
//为这个原因以及在流量工程应用方面的缺陷。因此方本文档不考虑WF方式。
2.4.3. Shared Explicit (SE) Style
The Shared Explicit (SE) style allows a receiver to explicitly
specify the senders to be included in a reservation. There is a
single reservation on a link for all the senders listed. Because
each sender is explicitly listed in the Resv message, different
labels may be assigned to different senders, thereby creating
separate LSPs.
//在显示共享方式，接收者可以显示的包含一些指定的发送者到一个预留
//中。在同一条链路上，所有的发送者只有一个预留。因为所有的发送者在
//Resv消息中显示的指定，不同的发送者将分配不同的标签，即创建多个相
//互可区分的LSP。
SE style reservations can be provided using multipoint-to-point
label-switched-path or LSP per sender. Multipoint-to-point LSPs may
be used when path messages do not carry the EXPLICIT_ROUTE object, or
when Path messages have identical EXPLICIT_ROUTE objects. In either
of these cases a common label may be assigned.
//显示共享预留方式可以使用多点到点LSP，或者每个sender使用一个LSP。当
//Path消息中未携带EXPLICIT_ROUTE，将使用多点到点LSP，否则每个发送者
//使用一个LSP。所有情况下一个普通标签被分配。
Awduche, et al. Standards Track [Page 11]
RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
Path messages from different senders can each carry their own ERO,
and the paths taken by the senders can converge and diverge at any
point in the network topology. When Path messages have differing
EXPLICIT_ROUTE objects, separate LSPs for each EXPLICIT_ROUTE object
must be established.
//来自不同sender的Path可以携带独自的ERO对象，而且在网络拓扑中，不同
//发送者发出的Path消息可能在任何节点交汇，当Path消息携带不同的
//EXPLICIT_ROUTE对象，不同的EXPLICIT_ROUTE对象将导致创建不同的LSP。
2.5. Rerouting Traffic Engineered Tunnels
One of the requirements for Traffic Engineering is the capability to
reroute an established TE tunnel under a number of conditions, based
on administrative policy. For example, in some contexts, an
administrative policy may dictate that a given TE tunnel is to be
rerouted when a more "optimal" route becomes available. Another
important context when TE tunnel reroute is usually required is upon
failure of a resource along the TE tunnel's established path. Under
some policies, it may also be necessary to return the TE tunnel to
its original path when the failed resource becomes re-activated.
//流量工程(TE)的一个需求是能够在某些条件下基于管理策略重路由一个创建好
//的TE tunnel。例如：一个管理策略可能指明，在更优路径可用的情况下，指定
//的TE tunnel可以被重路由。另外一个重要的情况就是，在TE tunnel的路径上，
//如果发生资源故障，通常该TE tunnel需要被重路由。在某些策略下，当发生故
//障的资源恢复后，需要把TE tunnel返回到其原始路径。
In general, it is highly desirable not to disrupt traffic, or
adversely impact network operations while TE tunnel rerouting is in
progress. This adaptive and smooth rerouting requirement
necessitates establishing a new LSP tunnel and transferring traffic
from the old LSP tunnel onto it before tearing down the old LSP
tunnel. This concept is called "make-before-break." A problem can
arise because the old and new LSP tunnels might compete with each
other for resources on network segments which they have in common.
Depending on availability of resources, this competition can cause
Admission Control to prevent the new LSP tunnel from being
established. An advantage of using RSVP to establish LSP tunnels is
that it solves this problem very elegantly.
//通常，TE tunnel重路由过程中，必须保证不中断业务，或者对网络操作造
//成影响。该平滑的重路由需求迫使在删除旧LSP之前，需要创建新的LSP，并
//把流量倒到新的LSP上，这个概念称为“make-before-break”。这将导致一个
//新的问题，因为新、旧LSP会在它们共有的网络资源上互相竞争。受可用资源
//的限制，该竞争可能导致准入控制阻止新的LSP的创建。使用RSVP创建LSP可
//以很轻松的解决该问题。
To support make-before-break in a smooth fashion, it is necessary
that on links that are common to the old and new LSPs, resources used
by the old LSP tunnel should not be released before traffic is
transitioned to the new LSP tunnel, and reservations should not be
counted twice because this might cause Admission Control to reject
the new LSP tunnel.
//为了支持“make-before-break”平滑方式，在新LSP和老LSP共有的链路上，在
//流量被切换到新LSP之前，老LSP的的资源将不能释放掉，而且预留不能计算两
//次，否则将准入控制可能拒绝新LSP的建立。
A similar situation can arise when one wants to increase the
bandwidth of a TE tunnel. The new reservation will be for the full
amount needed, but the actual allocation needed is only the delta
between the new and old bandwidth. If policy is being applied to
PATH messages by intermediate nodes, then a PATH message requesting
too much bandwidth will be rejected. In this situation simply
increasing the bandwidth request without changing the
SENDER_TEMPLATE, could result in a tunnel being torn down, depending
upon local policy.
//当需要增加TE tunnel的带宽时，会导致一个类似的问题发生，新的预留希望
//有它需要的全部带宽，但是实际可以分配的带宽在旧和新的预留带宽之间。
//如果中间节点接受该PATH消息，那么在本节点PATH消息请求过多的带宽被拒绝，
//这种情况下，不改变SENDER_TEMPLATE而去增加带宽，会导致在某些本地策略
//下，LSP隧道被删除掉。
Awduche, et al. Standards Track [Page 12]
RFC 3209 Extensions to RSVP for LSP Tunnels December 2001
The combination of the LSP_TUNNEL SESSION object and the SE
reservation style naturally accommodates smooth transitions in
bandwidth and routing. The idea is that the old and new LSP tunnels
share resources along links which they have in common. The
LSP_TUNNEL SESSION object is used to narrow the scope of the RSVP
session to the particular TE tunnel in question. To uniquely
identify a TE tunnel, we use the combination of the destination IP
address (an address of the node which is the egress of the tunnel), a
Tunnel ID, and the tunnel ingress node's IP address, which is placed
in the Extended Tunnel ID field.
//LSP_TUNNEL SESSION对象和SE预留方式天生的适应平滑的带宽增加和重路由。
//主要思想是老的和新的LSP隧道共享他们共同使用的链路资源。LSP_TUNNEL
//SESSION对象用于对一个特定的TE tunnel限制RSVP的会话的范围，我们使用
//目的地址(隧道的末节点地址)，TUNNEL ID，和Extended Tunnel ID字段的
//首节点地址的三元组，来唯一的确定一个TE tunnel。
During the reroute or bandwidth-increase operation, the tunnel
ingress needs to appear as two different senders to the RSVP session.
This is achieved by the inclusion of the "LSP ID", which is carried
in the SENDER_TEMPLATE and FILTER_SPEC objects. Since the semantics
of these objects are changed, a new C-Types are assigned.
//在重路由或但款增加的操作过程中，隧道的首节点需要出现两次，作为该会
//话的两个不同的sender。这通过和在SENDER_TEMPLATE(FILTER_SPEC)中的
//LSP ID一起完成。因为该对象的语义变了，需要赋一个新的C-Type值。
To effect a reroute, the ingress node picks a new LSP ID and forms a
new SENDER_TEMPLATE. The ingress node then creates a new ERO to
define the new path. Thereafter the node sends a new Path Message
using the original SESSION object and the new SENDER_TEMPLATE and
ERO. It continues to use the old LSP and refresh the old Path
message. On links that are not held in common, the new Path message
is treated as a conventional new LSP tunnel setup. On links held in
common, the shared SESSION object and SE style allow the LSP to be
established sharing resources with the old LSP. Once the ingress
node receives a Resv message for the new LSP, it can transition
traffic to it and tear down the old LSP.
//重路由，首节点产生一个新的LSP ID，且构造一个新的SENDER_TEMPLATE。
//首节点创建新的ERO以指定新路径。此后，首节点发送一个使用老的SESSION
//新的SENDER_TEMPLATE、ERO对象的新的PATH消息。在非共有的链路上，新的
//PATH消息被当作一个常规的LSP创建。在共有的链路上，共同的SESSION对象
//和SE方式允许LSP与老LSP共享资源的方式创建。当首节点收到新LSP的RESV
//消息，它可以把流量倒换到新的LSP上，且删除老的LSP。
To effect a bandwidth-increase, a new Path Message with a new LSP_ID
can be used to attempt a larger bandwidth reservation while the
current LSP_ID continues to be refreshed to ensure that the
reservation is not lost if the larger reservation fails.
//带宽增加，一个携带新的LSP_ID的PATH消息用于尝试增加带宽的预留，此
//时，老的LSP_ID将一直在刷新以保证在增加带宽失败时老LSP不被删除。
