Network Working Group R. Yavatkar
Request for Comments: 2814 Intel
Category: Standards Track D. Hoffman
Teledesic
Y. Bernet
Microsoft
F. Baker
Cisco
M. Speer
Sun Microsystems
May 2000
Network Working Group R. Yavatkar
Request for Comments: 2814 Intel
Category: Standards Track D. Hoffman
Teledesic
Y. Bernet
Microsoft
F. Baker
Cisco
M. Speer
Sun Microsystems
May 2000
SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks
SBM（子网带宽管理器）：IEEE 802风格网络上基于RSVP的准入控制协议
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 Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes a signaling method and protocol for RSVP-based admission control over IEEE 802-style LANs. The protocol is designed to work both with the current generation of IEEE 802 LANs as well as with the recent work completed by the IEEE 802.1 committee.
本文档描述了IEEE 802风格局域网上基于RSVP的准入控制的信令方法和协议。该协议设计用于当前一代IEEE 802局域网以及IEEE 802.1委员会最近完成的工作。
New extensions to the Internet architecture and service models have been defined for an integrated services Internet [RFC-1633, RFC-2205, RFC-2210] so that applications can request specific qualities or levels of service from an internetwork in addition to the current IP best-effort service. These extensions include RSVP, a resource reservation setup protocol, and definition of new service classes to be supported by Integrated Services routers. RSVP and service class definitions are largely independent of the underlying networking technologies and it is necessary to define the mapping of RSVP and Integrated Services specifications onto specific subnetwork technologies. For example, a definition of service mappings and
已为综合服务互联网[RFC-1633、RFC-2205、RFC-2210]定义了对互联网体系结构和服务模型的新扩展，以便除了当前IP尽力而为服务外，应用程序还可以从互联网请求特定质量或级别的服务。这些扩展包括RSVP，一种资源预留设置协议，以及由集成服务路由器支持的新服务类的定义。RSVP和服务类定义在很大程度上独立于底层网络技术，有必要定义RSVP和集成服务规范到特定子网络技术的映射。例如，服务映射的定义和
reservation setup protocols is needed for specific link-layer technologies such as shared and switched IEEE-802-style LAN technologies.
特定链路层技术（如共享和交换IEEE-802-style LAN技术）需要预约设置协议。
This document defines SBM, a signaling protocol for RSVP-based admission control over IEEE 802-style networks. SBM provides a method for mapping an internet-level setup protocol such as RSVP onto IEEE 802 style networks. In particular, it describes the operation of RSVP-enabled hosts/routers and link layer devices (switches, bridges) to support reservation of LAN resources for RSVP-enabled data flows. A framework for providing Integrated Services over shared and switched IEEE-802-style LAN technologies and a definition of service mappings have been described in separate documents [RFC-FRAME, RFC-MAP].
本文档定义了SBM，一种用于IEEE 802风格网络上基于RSVP的准入控制的信令协议。SBM提供了一种将诸如RSVP之类的internet级设置协议映射到IEEE 802风格网络的方法。特别是，它描述了支持RSVP的主机/路由器和链路层设备（交换机、网桥）的操作，以支持为支持RSVP的数据流保留LAN资源。在单独的文档[RFC-FRAME，RFC-MAP]中描述了通过共享和交换IEEE-802-style LAN技术提供集成服务的框架和服务映射的定义。
The SBM (Subnet Bandwidth Manager) protocol and its use for admission control and bandwidth management in IEEE 802 level-2 networks is based on the following architectural goals and assumptions:
SBM（子网带宽管理器）协议及其在IEEE 802 2级网络中用于准入控制和带宽管理的用途基于以下体系结构目标和假设：
I. Even though the current trend is towards increased use of switched LAN topologies consisting of newer switches that support the priority queuing mechanisms specified by IEEE 802.1p, we assume that the LAN technologies will continue to be a mix of legacy shared/ switched LAN segments and newer switched segments based on IEEE 802.1p specification. Therefore, we specify a signaling protocol for managing bandwidth over both legacy and newer LAN topologies and that takes advantage of the additional functionality (such as an explicit support for different traffic classes or integrated service classes) as it becomes available in the new generation of switches, hubs, or bridges. As a result, the SBM protocol would allow for a range of LAN bandwidth management solutions that vary from one that exercises purely administrative control (over the amount of bandwidth consumed by RSVP-enabled traffic flows) to one that requires cooperation (and enforcement) from all the end-systems or switches in a IEEE 802 LAN.
I.尽管目前的趋势是越来越多地使用由支持IEEE 802.1p规定的优先级排队机制的较新交换机组成的交换式LAN拓扑，我们假设LAN技术将继续是传统共享/交换LAN段和基于IEEE 802.1p规范的较新交换段的混合。因此，我们指定了一种信令协议，用于在传统和较新的LAN拓扑上管理带宽，并利用新一代交换机、集线器或网桥中提供的附加功能（例如明确支持不同的流量类别或集成服务类别）。因此，SBM协议将允许一系列LAN带宽管理解决方案，从纯行政控制（通过启用RSVP的通信流消耗的带宽量）到需要IEEE 802 LAN中所有终端系统或交换机的合作（和实施）不等。
II. This document specifies only a signaling method and protocol for LAN-based admission control over RSVP flows. We do not define here any traffic control mechanisms for the link layer; the protocol is designed to use any such mechanisms defined by IEEE 802. In addition, we assume that the Layer 3 end-systems (e.g., a host or a router) will exercise traffic control by policing Integrated Services traffic flows to ensure that each flow stays within its traffic specifications stipulated in an earlier reservation request submitted for admission control. This then
二,。本文件仅规定了RSVP流上基于LAN的准入控制的信令方法和协议。我们这里没有为链路层定义任何流量控制机制；该协议旨在使用IEEE 802定义的任何此类机制。此外，我们假设第3层终端系统（例如，主机或路由器）将通过监控综合服务流量来实施流量控制，以确保每个流量保持在先前提交用于许可控制的预订请求中规定的流量规格内。那么这个
allows a system using SBM admission control combined with per flow shaping at end systems and IEEE-defined traffic control at link layer to realize some approximation of Controlled Load (and even Guaranteed) services over IEEE 802-style LANs.
允许系统使用SBM准入控制，结合终端系统的每流成形和链路层IEEE定义的流量控制，在IEEE 802风格的LAN上实现受控负载（甚至保证）服务的近似。
III. In the absence of any link-layer traffic control or priority queuing mechanisms in the underlying LAN (such as a shared LAN segment), the SBM-based admission control mechanism only limits the total amount of traffic load imposed by RSVP-enabled flows on a shared LAN. In such an environment, no traffic flow separation mechanism exists to protect the RSVP-enabled flows from the best-effort traffic on the same shared media and that raises the question of the utility of such a mechanism outside a topology consisting only of 802.1p-compliant switches. However, we assume that the SBM-based admission control mechanism will still serve a useful purpose in a legacy, shared LAN topology for two reasons. First, assuming that all the nodes that generate Integrated Services traffic flows utilize the SBM-based admission control procedure to request reservation of resources before sending any traffic, the mechanism will restrict the total amount of traffic generated by Integrated Services flows within the bounds desired by a LAN administrator (see discussion of the NonResvSendLimit parameter in Appendix C). Second, the best-effort traffic generated by the TCP/IP-based traffic sources is generally rate adaptive (using a TCP-style "slow start" congestion avoidance mechanism or a feedback-based rate adaptation mechanism used by audio/video streams based on RTP/RTCP protocols) and adapts to stay within the available network bandwidth. Thus, the combination of admission control and rate adaptation should avoid persistent traffic congestion. This does not, however, guarantee that non-Integrated-Services traffic will not interfere with the Integrated Services traffic in the absence of traffic control support in the underlying LAN infrastructure.
三、 在底层LAN（如共享LAN段）中没有任何链路层流量控制或优先级排队机制的情况下，基于SBM的准入控制机制仅限制共享LAN上启用RSVP的流施加的流量负载总量。在这样的环境中，不存在流量分离机制来保护启用RSVP的流量不受相同共享介质上的尽力而为流量的影响，这就提出了在仅包含802.1p兼容交换机的拓扑结构之外使用这种机制的问题。然而，基于两个原因，我们假设基于SBM的准入控制机制在传统的共享LAN拓扑结构中仍然有用。首先，假设生成综合业务流量的所有节点在发送任何流量之前利用基于SBM的准入控制过程请求资源预留，该机制将综合业务流量生成的总流量限制在LAN管理员期望的范围内（参见附录C中对NonRessendLimit参数的讨论）。其次，基于TCP/IP的流量源生成的尽力而为的流量通常是速率自适应的（使用TCP风格的“慢启动”拥塞避免机制或基于RTP/RTCP协议的音频/视频流使用的基于反馈的速率自适应机制）和适应以保持在可用网络带宽内。因此，接纳控制和速率适应的组合应避免持续的流量拥塞。但是，这并不能保证在底层没有流量控制支持的情况下，非集成服务流量不会干扰集成服务流量英兰基础设施。
The rest of this document provides a detailed description of the SBM-based admission control procedure(s) for IEEE 802 LAN technologies. The document is organized as follows:
本文档的其余部分详细描述了IEEE 802 LAN技术中基于SBM的准入控制程序。该文件的组织如下：
* Section 4 first defines the various terms used in the document and then provides an overview of the admission control procedure with an example of its application to a sample network.
* 第4节首先定义了文件中使用的各种术语，然后概述了准入控制程序及其在样本网络中的应用示例。
* Section 5 describes the rules for processing and forwarding PATH (and PATH_TEAR) messages at DSBMs (Designated Subnet Bandwidth Managers), SBMs, and DSBM clients.
* 第5节描述了在DSBMs（指定子网带宽管理器）、SBM和DSBM客户端处理和转发路径（和路径撕裂）消息的规则。
* Section 6 addresses the inter-operability issues when a DSBM may operate in the absence of RSVP signaling at Layer 3 or when another signaling protocol (such as SNMP) is used to reserve resources on a LAN segment.
* 第6节讨论了当DSBM可能在第3层没有RSVP信令的情况下运行，或者当使用另一个信令协议（如SNMP）在LAN段上保留资源时的互操作性问题。
* Appendix A describes the details of the DSBM election algorithm used for electing a designated SBM on a LAN segment when more than one SBM is present. It also describes how DSBM clients discover the presence of a DSBM on a managed segment.
* 附录A描述了当存在多个SBM时，用于在LAN段上选择指定SBM的DSBM选择算法的详细信息。它还描述了DSBM客户端如何发现托管段上存在DSBM。
* Appendix B specifies the formats of SBM-specific messages used and the formats of new RSVP objects needed for the SBM operation.
* 附录B规定了使用的SBM特定消息的格式以及SBM操作所需的新RSVP对象的格式。
* Appendix C describes usage of the DSBM to distribute configuration information to senders on a managed segment.
* 附录C描述了如何使用DSBM将配置信息分发给受管段上的发送方。
- Link Layer or Layer 2 or L2: We refer to data-link layer technologies such as IEEE 802.3/Ethernet as L2 or layer 2.
- 链路层或第2层或L2层：我们将数据链路层技术（如IEEE 802.3/以太网）称为L2层或第2层。
- Link Layer Domain or Layer 2 domain or L2 domain: a set of nodes and links interconnected without passing through a L3 forwarding function. One or more IP subnets can be overlaid on a L2 domain.
- 链路层域或第2层域或L2域：不通过L3转发功能而互连的一组节点和链路。一个或多个IP子网可以覆盖在L2域上。
- Layer 2 or L2 devices: We refer to devices that only implement Layer 2 functionality as Layer 2 or L2 devices. These include 802.1D bridges or switches.
- 第2层或第2层设备：我们将仅实现第2层功能的设备称为第2层或第2层设备。这些包括802.1D网桥或交换机。
- Internetwork Layer or Layer 3 or L3: Layer 3 of the ISO 7 layer model. This document is primarily concerned with networks that use the Internet Protocol (IP) at this layer.
- 网络层或第3层或L3层：ISO 7层模型的第3层。本文档主要涉及在该层使用Internet协议（IP）的网络。
- Layer 3 Device or L3 Device or End-Station: these include hosts and routers that use L3 and higher layer protocols or application programs that need to make resource reservations.
- 第3层设备或L3设备或终端站：包括使用L3和更高层协议的主机和路由器，或需要进行资源预留的应用程序。
- Segment: A L2 physical segment that is shared by one or more senders. Examples of segments include (a) a shared Ethernet or Token-Ring wire resolving contention for media access using CSMA or token passing ("shared L2 segment"), (b) a half duplex link between two stations or switches, (c) one direction of a switched full-duplex link.
- 段：一个或多个发送方共享的二级物理段。段的示例包括（a）使用CSMA或令牌传递解决媒体访问争用的共享以太网或令牌环线（“共享L2段”），（b）两个站或交换机之间的半双工链路，（c）交换全双工链路的一个方向。
- Managed segment: A managed segment is a segment with a DSBM present and responsible for exercising admission control over requests for resource reservation. A managed segment includes those interconnected parts of a shared LAN that are not separated by DSBMs.
- 托管段：托管段是存在DSBM的段，负责对资源预留请求实施准入控制。受管网段包括共享LAN中未被DSBMs分隔的互连部分。
- Traffic Class: An aggregation of data flows which are given similar service within a switched network.
- 流量类别：交换网络中提供类似服务的数据流的集合。
- User_priority: User_priority is a value associated with the transmission and reception of all frames in the IEEE 802 service model: it is supplied by the sender that is using the MAC service. It is provided along with the data to a receiver using the MAC service. It may or may not be actually carried over the network: Token-Ring/802.5 carries this value (encoded in its FC octet), basic Ethernet/802.3 does not, 802.12 may or may not depending on the frame format in use. 802.1p defines a consistent way to carry this value over the bridged network on Ethernet, Token Ring, Demand-Priority, FDDI or other MAC-layer media using an extended frame format. The usage of user_priority is fully described in section 2.5 of 802.1D [IEEE8021D] and 802.1p [IEEE8021P] "Support of the Internal Layer Service by Specific MAC Procedures".
- User_priority：User_priority是与IEEE 802服务模型中所有帧的传输和接收相关联的值：它由使用MAC服务的发送方提供。它与数据一起提供给使用MAC服务的接收器。它可能通过网络传输，也可能不通过网络传输：令牌环/802.5传输该值（在其FC八位字节中编码），基本以太网/802.3不传输，802.12可能传输，也可能不传输，具体取决于使用的帧格式。802.1p定义了在以太网、令牌环、请求优先级、FDDI或其他MAC层介质上使用扩展帧格式通过桥接网络传输此值的一致方式。802.1D[IEEE8021D]和802.1p[IEEE8021P]“通过特定MAC程序支持内部层服务”的第2.5节详细描述了用户_优先级的使用。
- Subnet: used in this memo to indicate a group of L3 devices sharing a common L3 network address prefix along with the set of segments making up the L2 domain in which they are located.
- 子网：在本备忘录中用于表示共享公共三级网络地址前缀的一组三级设备，以及组成它们所在二级域的一组段。
- Bridge/Switch: a layer 2 forwarding device as defined by IEEE 802.1D. The terms bridge and switch are used synonymously in this document.
- 网桥/交换机：IEEE 802.1D定义的第2层转发设备。术语桥接器和交换机在本文档中同义使用。
- DSBM: Designated SBM (DSBM) is a protocol entity that resides in a L2 or L3 device and manages resources on a L2 segment. At most one DSBM exists for each L2 segment.
- DSBM：指定SBM（DSBM）是驻留在二级或三级设备中并管理二级网段上资源的协议实体。每个L2段最多存在一个DSBM。
- SBM: the SBM is a protocol entity that resides in a L2 or L3 device and is capable of managing resources on a segment. However, only a DSBM manages the resources for a managed segment. When more than one SBM exists on a segment, one of the SBMs is elected to be the DSBM.
- SBM：SBM是驻留在L2或L3设备中的协议实体，能够管理段上的资源。但是，只有DSBM管理受管段的资源。当一个段上存在多个SBM时，选择其中一个SBM作为DSBM。
- Extended segment: An extended segment includes those parts of a network which are members of the same IP subnet and therefore are not separated by any layer 3 devices. Several managed segments, interconnected by layer 2 devices, constitute an extended segment.
- 扩展段：扩展段包括属于同一IP子网的网络部分，因此不被任何第3层设备分隔。由第2层设备互连的多个受管段构成扩展段。
- Managed L2 domain: An L2 domain consisting of managed segments is referred to as a managed L2 domain to distinguish it from a L2 domain with no DSBMs present for exercising admission control over resources at segments in the L2 domain.
- 托管L2域：由托管段组成的L2域称为托管L2域，以区别于不存在DSBMs的L2域，用于对L2域中段的资源执行准入控制。
- DSBM clients: These are entities that transmit traffic onto a managed segment and use the services of a DSBM for the managed segment for admission control over a LAN segment. Only the layer 3 or higher layer entities on L3 devices such as hosts and routers are expected to send traffic that requires resource reservations, and, therefore, DSBM clients are L3 entities.
- DSBM客户端：这些实体将流量传输到受管网段，并使用DSBM为受管网段提供的服务对LAN网段进行准入控制。只有L3设备（如主机和路由器）上的第3层或更高层实体才能发送需要资源保留的通信量，因此，DSBM客户端是L3实体。
- SBM transparent devices: A "SBM transparent" device is unaware of SBMs or DSBMs (though it may or may not be RSVP aware) and, therefore, does not participate in the SBM-based admission control procedure over a managed segment. Such a device uses standard forwarding rules appropriate for the device and is transparent with respect to SBM. An example of such a L2 device is a legacy switch that does not participate in resource reservation.
- SBM透明设备：“SBM透明”设备不知道SBM或DSBMs（尽管它可能知道也可能不知道RSVP），因此不参与管理段上基于SBM的准入控制过程。这样的设备使用适合于该设备的标准转发规则，并且对于SBM是透明的。此类L2设备的一个示例是不参与资源保留的传统交换机。
- Layer 3 and layer 2 addresses: We refer to layer 3 addresses of L3/L2 devices as "L3 addresses" and layer 2 addresses as "L2 addresses". This convention will be used in the rest of the document to distinguish between Layer 3 and layer 2 addresses used to refer to RSVP next hop (NHOP) and previous hop (PHOP) devices. For example, in conventional RSVP message processing, RSVP_HOP object in a PATH message carries the L3 address of the previous hop device. We will refer to the address contained in the RSVP_HOP object as the RSVP_HOP_L3 address and the corresponding MAC address of the previous hop device will be referred to as the RSVP_HOP_L2 address.
- 第3层和第2层地址：我们将L3/L2设备的第3层地址称为“L3地址”，将第2层地址称为“L2地址”。本文档的其余部分将使用此约定来区分用于指代RSVP下一跳（NHOP）和前一跳（PHOP）设备的第3层和第2层地址。例如，在传统的RSVP消息处理中，路径消息中的RSVP_HOP对象携带前一跳设备的L3地址。我们将RSVP_HOP对象中包含的地址称为RSVP_HOP_L3地址，前一跳设备的相应MAC地址称为RSVP_HOP_L2地址。
A protocol entity called "Designated SBM" (DSBM) exists for each managed segment and is responsible for admission control over the resource reservation requests originating from the DSBM clients in that segment. Given a segment, one or more SBMs may exist on the segment. For example, many SBM-capable devices may be attached to a shared L2 segment whereas two SBM-capable switches may share a half-duplex switched segment. In that case, a single DSBM is elected for the segment. The procedure for dynamically electing the DSBM is described in Appendix A. The only other approved method for specifying a DSBM for a managed segment is static configuration at SBM-capable devices.
每个托管段都有一个称为“指定SBM”（DSBM）的协议实体，负责对该段中DSBM客户端发出的资源预留请求进行准入控制。给定一个段，该段上可能存在一个或多个SBM。例如，许多支持SBM的设备可以连接到共享L2段，而两个支持SBM的交换机可以共享半双工交换段。在这种情况下，将为该段选择一个DSBM。附录A中描述了动态选择DSBM的程序。为受管段指定DSBM的唯一其他经批准的方法是在支持SBM的设备上进行静态配置。
The presence of a DSBM makes the segment a "managed segment". Sometimes, two or more L2 segments may be interconnected by SBM transparent devices. In that case, a single DSBM will manage the resources for those segments treating the collection of such segments as a single managed segment for the purpose of admission control.
DSBM的存在使该段成为“托管段”。有时，两个或多个L2段可由SBM透明设备互连。在这种情况下，单个DSBM将管理这些段的资源，并将这些段的集合视为用于许可控制的单个受管段。
Figure 1 - An Example of a Managed Segment.
图1-托管段的示例。
+-------+ +-----+ +------+ +-----+ +--------+
|Router | | Host| | DSBM | | Host| | Router |
| R2 | | C | +------+ | B | | R3 |
+-------+ +-----+ / +-----+ +--------+
| | / | |
| | / | |
==============================================================LAN
| |
| |
+------+ +-------+
| Host | | Router|
| A | | R1 |
+------+ +-------+
+-------+ +-----+ +------+ +-----+ +--------+
|Router | | Host| | DSBM | | Host| | Router |
| R2 | | C | +------+ | B | | R3 |
+-------+ +-----+ / +-----+ +--------+
| | / | |
| | / | |
==============================================================LAN
| |
| |
+------+ +-------+
| Host | | Router|
| A | | R1 |
+------+ +-------+
Figure 1 shows an example of a managed segment in a L2 domain that interconnects a set of hosts and routers. For the purpose of this discussion, we ignore the actual physical topology of the L2 domain (assume it is a shared L2 segment and a single managed segment represents the entire L2 domain). A single SBM device is designated to be the DSBM for the managed segment. We will provide examples of operation of the DSBM over switched and shared segments later in the document.
图1显示了L2域中互连一组主机和路由器的托管段的示例。在本讨论中，我们忽略了L2域的实际物理拓扑（假设它是一个共享L2段，单个托管段代表整个L2域）。单个SBM设备被指定为受管段的DSBM。我们将在本文件后面提供DSBM在交换和共享段上的操作示例。
The basic DSBM-based admission control procedure works as follows:
基于DSBM的基本准入控制程序的工作原理如下：
1. DSBM Initialization: As part of its initial configuration, DSBM obtains information such as the limits on fraction of available resources that can be reserved on each managed segment under its control. For instance, bandwidth is one such resource. Even though methods such as auto-negotiation of link speeds and knowledge of link topology allow discovery of link capacity, the configuration may be necessary to limit the fraction of link capacity that can be reserved on a link. Configuration is likely to be static with the current L2/L3 devices. Future work may allow for dynamic discovery of this information. This document does not specify the configuration mechanism.
1. DSBM初始化：作为其初始配置的一部分，DSBM获取信息，例如在其控制下的每个受管段上可以保留的可用资源部分的限制。例如，带宽就是这样一种资源。尽管诸如链路速度的自动协商和链路拓扑知识等方法允许发现链路容量，但可能需要进行配置以限制链路上可保留的链路容量部分。当前L2/L3设备的配置可能是静态的。未来的工作可能允许动态发现这些信息。本文档未指定配置机制。
2. DSBM Client Initialization: For each interface attached, a DSBM client determines whether a DSBM exists on the interface. The procedure for discovering and verifying the existence of the DSBM for an attached segment is described in Appendix A. If the client itself is capable of serving as the DSBM on the segment, it may choose to participate in the election to become the DSBM. At the start, a DSBM client first verifies that a DSBM exists in its L2 domain so that it can communicate with the DSBM for admission control purposes.
2. DSBM客户端初始化：对于每个连接的接口，DSBM客户端确定接口上是否存在DSBM。附录A中描述了发现和验证所连接网段是否存在DSBM的程序。如果客户端本身能够充当网段上的DSBM，则可以选择参与成为DSBM的选择。开始时，DSBM客户机首先验证DSBM是否存在于其L2域中，以便它可以与DSBM通信以进行准入控制。
In the case of a full-duplex segment, an election may not be necessary as the SBM at each end will typically act as the DSBM for outgoing traffic in each direction.
在全双工段的情况下，可能不需要进行选择，因为每一端的SBM通常将充当每个方向上传出业务的DSBM。
3. DSBM-based Admission Control: To request reservation of resources (e.g., LAN bandwidth in a L2 domain), DSBM clients (RSVP-capable L3 devices such as hosts and routers) follow the following steps:
3. 基于DSBM的准入控制：为了请求资源预留（例如，L2域中的LAN带宽），DSBM客户端（支持RSVP的L3设备，如主机和路由器）遵循以下步骤：
a) When a DSBM client sends or forwards a RSVP PATH message over an interface attached to a managed segment, it sends the PATH message to the segment's DSBM instead of sending it to the RSVP session destination address (as is done in conventional RSVP processing). After processing (and possibly updating an ADSPEC), the DSBM will forward the PATH message toward its destination address. As part of its processing, the DSBM builds and maintains a PATH state for the session and notes the previous L2/L3 hop that sent it the PATH message.
a) 当DSBM客户端通过连接到受管网段的接口发送或转发RSVP PATH消息时，它会将PATH消息发送到网段的DSBM，而不是发送到RSVP会话目标地址（在传统RSVP处理中是这样做的）。在处理（并可能更新ADSPEC）后，DSBM将PATH消息转发到其目标地址。作为其处理的一部分，DSBM构建并维护会话的路径状态，并记录向其发送路径消息的前一个L2/L3跃点。
Let us consider the managed segment in Figure 1. Assume that a sender to a RSVP session (session address specifies the IP address of host A on the managed segment in Figure 1) resides outside the L2 domain of the managed segment and sends a PATH message that arrives at router R1 which is on the path towards host A.
让我们考虑图1中的托管段。假设RSVP会话的发送方（会话地址在图1中指定托管段上主机a的IP地址）位于托管段的L2域之外，并发送一条路径消息，该消息到达路由器R1，路由器R1位于通向主机a的路径上。
DSBM client on Router R1 forwards the PATH message from the sender to the DSBM. The DSBM processes the PATH message and forwards the PATH message towards the RSVP receiver (Detailed message processing and forwarding rules are described in Section 5). In the process, the DSBM builds the PATH state, remembers the router R1 (its L2 and l3 addresses) as the previous hop for the session, puts its own L2 and L3 addresses in the PHOP objects (see explanation later), and effectively inserts itself as an intermediate node between the sender (or R1 in Figure 1) and the receiver (host A) on the managed segment.
路由器R1上的DSBM客户端将路径消息从发送方转发到DSBM。DSBM处理路径消息并将路径消息转发给RSVP接收器（第5节描述了详细的消息处理和转发规则）。在此过程中，DSBM构建路径状态，将路由器R1（其L2和l3地址）记住为会话的前一个跃点，将其自己的L2和l3地址放入PHOP对象中（请参见后面的解释），并有效地将自身作为发送方（或图1中的R1）和接收方（主机A）之间的中间节点插入在托管段上。
b) When an application on host A wishes to make a reservation for the RSVP session, host A follows the standard RSVP message processing rules and sends a RSVP RESV message to the previous hop L2/L3 address (the DSBMs address) obtained from the PHOP object(s) in the previously received PATH message.
b) 当主机A上的应用程序希望为RSVP会话进行预订时，主机A遵循标准RSVP消息处理规则，并将RSVP RESV消息发送到先前接收到的PATH消息中从PHOP对象获得的上一个跃点L2/L3地址（DSBMs地址）。
c) The DSBM processes the RSVP RESV message based on the bandwidth available and returns an RESV_ERR message to the requester (host A) if the request cannot be granted. If sufficient resources are available and the reservation request is granted, the DSBM forwards the RESV message towards the PHOP(s) based on its local PATH state for the session. The DSBM merges reservation requests for the same session as and when possible using the rules similar to those used in the conventional RSVP processing (except for an additional criterion described in Section 5.8).
c) DSBM根据可用带宽处理RSVP RESV消息，如果请求无法被批准，则向请求者（主机A）返回RESV_ERR消息。如果有足够的资源可用，并且允许了保留请求，则DSBM根据会话的本地路径状态将RESV消息转发给PHOP。DSBM尽可能使用与传统RSVP处理中使用的规则类似的规则（第5.8节中描述的附加标准除外）合并同一会话的保留请求。
d) If the L2 domain contains more than one managed segment, the requester (host A) and the forwarder (router R1) may be separated by more than one managed segment. In that case, the original PATH message would propagate through many DSBMs (one for each managed segment on the path from R1 to A) setting up PATH state at each DSBM. Therefore, the RESV message would propagate hop-by-hop in reverse through the intermediate DSBMs and eventually reach the original forwarder (router R1) on the L2 domain if admission control at all DSBMs succeeds.
d) 如果L2域包含多个托管段，则请求者（主机A）和转发器（路由器R1）可以由多个托管段分隔。在这种情况下，原始路径消息将通过许多DSBM传播（从R1到A的路径上的每个托管段一个），在每个DSBM上设置路径状态。因此，如果所有DSBMs的准入控制成功，RESV消息将通过中间DSBMs反向逐跳传播，并最终到达L2域上的原始转发器（路由器R1）。
(D)SBMs and DSBM clients implement minor additions to the standard RSVP protocol. These are summarized in this section. A detailed description of the message processing and forwarding rules follows in section 5.
（D） SBMs和DSBM客户端对标准RSVP协议进行了少量添加。本节对这些问题进行了总结。第5节详细介绍了消息处理和转发规则。
Normal RSVP forwarding rules apply at a DSBM client when it is not forwarding an outgoing PATH message over a managed segment. However, outgoing PATH messages on a managed segment are sent to the DSBM for the corresponding managed segment (Section 5.2 describes how the PATH messages are sent to the DSBM on a managed segment).
当DSBM客户端不通过托管段转发传出路径消息时，正常的RSVP转发规则适用于DSBM客户端。但是，托管段上的传出路径消息会发送到相应托管段的DSBM（第5.2节描述了如何将路径消息发送到托管段上的DSBM）。
In conventional RSVP processing over point-to-point links, RSVP nodes (hosts/routers) use RSVP_HOP object (NHOP and PHOP info) to keep track of the next hop (downstream node in the path of data packets in a traffic flow) and the previous hop (upstream nodes with respect to
在点到点链路上的传统RSVP处理中，RSVP节点（主机/路由器）使用RSVP_-HOP对象（NHOP和PHOP信息）来跟踪下一跳（业务流中数据包路径中的下游节点）和前一跳（相对于网络的上游节点）
the data flow) nodes on the path between a sender and a receiver. Routers along the path of a PATH message forward the message towards the destination address based on the L3 routing (packet forwarding) tables.
数据流（data flow）节点位于发送方和接收方之间的路径上。路径消息路径上的路由器根据L3路由（数据包转发）表将消息转发到目标地址。
For example, consider the L2 domain in Figure 1. Assume that both the sender (some host X) and the receiver (some host Y) in a RSVP session reside outside the L2 domain shown in the Figure, but PATH messages from the sender to its receiver pass through the routers in the L2 domain using it as a transit subnet. Assume that the PATH message from the sender X arrives at the router R1. R1 uses its local routing information to decide which next hop router (either router R2 or router R3) to use to forward the PATH message towards host Y. However, when the path traverses a managed L2 domain, we require the PATH and RESV messages to go through a DSBM for each managed segment. Such a L2 domain may span many managed segments (and DSBMs) and, typically, SBM protocol entities on L2 devices (such as a switch) will serve as the DSBMs for the managed segments in a switched topology. When R1 forwards the PATH message to the DSBM (an L2 device), the DSBM may not have the L3 routing information necessary to select the egress router (between R2 and R3) before forwarding the PATH message. To ensure correct operation and routing of RSVP messages, we must provide additional forwarding information to DSBMs.
例如，考虑图1中的L2域。假设RSVP会话中的发送方（某个主机X）和接收方（某个主机Y）都位于图中所示的L2域之外，但从发送方到其接收方的路径消息将通过L2域中的路由器作为传输子网。假设来自发送方X的路径消息到达路由器R1。R1使用其本地路由信息来决定使用哪个下一跳路由器（路由器R2或路由器R3）将路径消息转发到主机Y。但是，当路径穿过托管L2域时，我们要求路径和RESV消息通过每个托管段的DSBM。这样的L2域可以跨越许多托管段（和DSBM），并且通常，L2设备（例如交换机）上的SBM协议实体将用作交换拓扑中托管段的DSBMs。当R1将路径消息转发给DSBM（L2设备）时，DSBM可能没有在转发路径消息之前选择出口路由器（R2和R3之间）所需的L3路由信息。为了确保RSVP消息的正确操作和路由，我们必须向DSBMs提供额外的转发信息。
For this purpose, we introduce new RSVP objects called LAN_NHOP address objects that keep track of the next L3 hop as the PATH message traverses an L2 domain between two L3 entities (RSVP PHOP and NHOP nodes).
为此，我们引入了称为LAN_NHOP地址对象的新RSVP对象，当路径消息穿过两个L3实体（RSVP PHOP和NHOP节点）之间的L2域时，这些对象跟踪下一个L3跳。
When a DSBM client (a host or a router acting as the originator of a PATH message) sends out a PATH message to the DSBM, it must include LAN_NHOP information in the message. In the case of a unicast destination, the LAN_NHOP address specifies the destination address (if the destination is local to its L2 domain) or the address of the next hop router towards the destination. In our example of an RSVP session involving the sender X and receiver Y with L2 domain in Figure 1 acting as the transit subnet, R1 is the ingress node that receives the PATH message. R1 first determines that R2 is the next hop router (or the egress node in the L2 domain for the session address) and then inserts a LAN_NHOP object that specifies R2's IP address. When a DSBM receives a PATH message, it can now look at the address in the LAN_NHOP object and forward the PATH message towards the egress node after processing the PATH message. However, we expect the L2 devices (such as switches) to act as DSBMs on the path within the L2 domain and it may not be reasonable to expect these devices to have an ARP capability to determine the MAC address (we
当DSBM客户端（作为PATH消息发端的主机或路由器）向DSBM发送PATH消息时，它必须在消息中包含LAN_NHOP信息。在单播目的地的情况下，LAN_NHOP地址指定目的地地址（如果目的地是其L2域的本地）或朝向目的地的下一跳路由器的地址。在我们的RSVP会话示例中，包括发送方X和接收方Y，图1中的L2域充当传输子网，R1是接收路径消息的入口节点。R1首先确定R2是下一跳路由器（或L2域中会话地址的出口节点），然后插入指定R2 IP地址的LAN_NHOP对象。当DSBM接收到路径消息时，它现在可以查看LAN_NHOP对象中的地址，并在处理路径消息后将路径消息转发到出口节点。然而，我们期望L2设备（如交换机）在L2域内的路径上充当DSBMs，并且期望这些设备具有ARP能力来确定MAC地址（我们
call it L2ADDR for Layer 2 address) corresponding to the IP address in the LAN_NHOP object.
将其称为L2ADDR（第2层地址），对应于LAN_NHOP对象中的IP地址。
Therefore, we require that the LAN_NHOP information (generated by the L3 device) include both the IP address (LAN_NHOP_L3 address) and the corresponding MAC address (LAN_NHOP_L2 address ) for the next L3 hop over the L2 domain. The LAN_NHOP_L3 address is used by SBM protocol entities on L3 devices to forward the PATH message towards its destination whereas the L2 address is used by the SBM protocol entities on L2 devices to determine how to forward the PATH message towards the L3 NHOP (egress point from the L2 domain). The exact format of the LAN_NHOP information and relevant objects is described later in Appendix B.
因此，我们要求LAN_NHOP信息（由L3设备生成）包括L2域上下一个L3跃点的IP地址（LAN_NHOP_L3地址）和相应的MAC地址（LAN_NHOP_L2地址）。L3设备上的SBM协议实体使用LAN_NHOP_L3地址将路径消息转发到其目的地，而L2设备上的SBM协议实体使用L2地址确定如何将路径消息转发到L3 NHOP（L2域的出口点）。LAN_NHOP信息和相关对象的确切格式将在附录B中描述。
- When a DSBM receives a RSVP PATH message, it processes the PATH message according to the PATH processing rules described in the RSVP specification. In particular, the DSBM retrieves the IP address of the previous hop from the RSVP_HOP object in the PATH message and stores the PHOP address in its PATH state. It then forwards the PATH message with the PHOP (RSVP_HOP) object modified to reflect its own IP address (RSVP_HOP_L3 address). Thus, the DSBM inserts itself as an intermediate hop in the chain of nodes in the path between two L3 nodes across the L2 domain.
- 当DSBM收到RSVP PATH消息时，它根据RSVP规范中描述的路径处理规则处理路径消息。具体而言，DSBM从PATH消息中的RSVP_hop对象检索上一跳的IP地址，并将PHOP地址存储在其PATH状态中。然后，它转发路径消息，修改PHOP（RSVP_-HOP）对象以反映其自己的IP地址（RSVP_-HOP_-L3地址）。因此，DSBM将自己作为中间跳插入L2域中两个L3节点之间路径中的节点链中。
- The PATH state in a DSBM is used for forwarding subsequent RESV messages as per the standard RSVP message processing rules. When the DSBM receives a RESV message, it processes the message and forwards it to appropriate PHOP(s) based on its PATH state.
- DSBM中的路径状态用于根据标准RSVP消息处理规则转发后续RESV消息。当DSBM接收到RESV消息时，它会处理该消息并根据其路径状态将其转发给相应的PHOP。
- Because a DSBM inserts itself as a hop between two RSVP nodes in the path of a RSVP flow, all RSVP related messages (such as PATH, PATH_TEAR, RESV, RESV_CONF, RESV_TEAR, and RESV_ERR) now flow through the DSBM. In particular, a PATH_TEAR message is routed exactly through the intermediate DSBM(s) as its corresponding PATH message and the local PATH state is first cleaned up at each intermediate hop before the PATH_TEAR message gets forwarded.
- 由于DSBM在RSVP流的路径中的两个RSVP节点之间插入自身作为跳，因此所有与RSVP相关的消息（如path、path_TEAR、RESV、RESV_CONF、RESV_TEAR和RESV_ERR）现在都流经DSBM。具体地说，路径撕裂消息作为其对应的路径消息准确地通过中间DSBM路由，并且在路径撕裂消息被转发之前，首先在每个中间跳清除本地路径状态。
- So far, we have described how the PATH message propagates through the L2 domain establishing PATH state at each DSBM along the managed segments in the path. The layer 2 address (LAN_NHOP_L2 address) in the LAN_NHOP object should be used by the L2 devices along the path to decide how to forward the PATH message toward the next L3 hop. Such devices will apply the standard IEEE 802.1D forwarding rules (e.g., send it on a single port based on its filtering database, or flood it on all ports active in the spanning tree if the L2 address does not appear in the filtering
- 到目前为止，我们已经描述了路径消息如何通过L2域传播，在每个DSBM上沿着路径中的受管段建立路径状态。LAN_NHOP对象中的第2层地址（LAN_NHOP_L2地址）应由沿路径的二级设备使用，以决定如何将路径消息转发到下一个三级跳。此类设备将应用标准IEEE 802.1D转发规则（例如，基于其筛选数据库在单个端口上发送，或者如果L2地址未出现在筛选数据库中，则在生成树中的所有活动端口上泛洪发送）
database) to the LAN_NHOP_L2 address as are applied normally to data packets destined to the address.
数据库）发送到LAN_NHOP_L2地址，通常应用于发送到该地址的数据包。
4.2.2.5 Including Both Layer-2 and Layer-3 Addresses in the RSVP_HOP Objects
4.2.2.5 在RSVP_-HOP对象中包括第2层和第3层地址
In the conventional RSVP message processing, the PATH state established along the nodes on a path is used to route the RESV message from a receiver to a sender in an RSVP session. As each intermediate node builds the path state, it remembers the previous hop (stores the PHOP IP address available in the RSVP_HOP object of an incoming message) that sent it the PATH message and, when the RESV message arrives, the intermediate node simply uses the stored PHOP address to forward the RESV after processing it successfully.
在传统的RSVP消息处理中，沿路径上的节点建立的路径状态用于在RSVP会话中将RESV消息从接收方路由到发送方。当每个中间节点构建路径状态时，它会记住向其发送路径消息的前一个跃点（存储传入消息的RSVP_-hop对象中可用的PHOP IP地址），并且当RESV消息到达时，中间节点只需在成功处理后使用存储的PHOP地址转发RESV。
In our case, we expect the SBM entities residing at L2 devices to act as DSBMs (and, therefore, intermediate RSVP hops in an L2 domain) along the path between a sender (PHOP) and receiver (NHOP). Thus, when a RESV message arrives at a DSBM, it must use the stored PHOP IP address to forward the RESV message to its previous hop. However, it may not be reasonable to expect the L2 devices to have an ARP cache or the ARP capability to map the PHOP IP address to its corresponding L2 address before forwarding the RESV message.
在我们的例子中，我们期望驻留在L2设备上的SBM实体沿着发送方（PHOP）和接收方（NHOP）之间的路径充当DSBMs（因此，L2域中的中间RSVP跳）。因此，当RESV消息到达DSBM时，它必须使用存储的PHOP IP地址将RESV消息转发到其上一跳。然而，在转发RESV消息之前，期望二级设备具有ARP缓存或ARP能力将PHOP IP地址映射到其相应的二级地址可能是不合理的。
To obviate the need for such address mapping at L2 devices, we use a RSVP_HOP_L2 object in the PATH message. The RSVP_HOP_L2 object includes the Layer 2 address (L2ADDR) of the previous hop and complements the L3 address information included in the RSVP_HOP object (RSVP_HOP_L3 address).
为了避免在L2设备上进行这种地址映射，我们在PATH消息中使用RSVP_HOP_L2对象。RSVP_-HOP_L2对象包含前一个跃点的第2层地址（L2ADDR），并补充RSVP_-HOP对象（RSVP_-HOP_-L3地址）中包含的L3地址信息。
When a L3 device constructs and forwards a PATH message over a managed segment, it includes its IP address (IP address of the interface over which PATH is sent) in the RSVP_HOP object and adds a RSVP_HOP_L2 object that includes the corresponding L2 address for the interface. When a device in the L2 domain receives such a PATH message, it remembers the addresses in the RSVP_HOP and RSVP_HOP_L2 objects in its PATH state and then overwrites the RSVP_HOP and RSVP_HOP_L2 objects with its own addresses before forwarding the PATH message over a managed segment.
当L3设备在托管段上构造并转发路径消息时，它将其IP地址（发送路径的接口的IP地址）包含在RSVP_-HOP对象中，并添加一个RSVP_-HOP_-L2对象，该对象包含接口的相应L2地址。当L2域中的设备接收到这样的路径消息时，它会记住处于其路径状态的RSVP_-HOP和RSVP_-HOP_L2对象中的地址，然后在通过托管段转发路径消息之前用自己的地址覆盖RSVP_-HOP和RSVP_-HOP_L2对象。
The exact format of RSVP_HOP_L2 object is specified in Appendix B.
RSVP_HOP_L2对象的确切格式在附录B中规定。
When an RSVP session address is a multicast address and a SBM, DSBM, and DSBM clients share the same L2 segment (a shared segment), it is possible for a SBM or a DSBM client to receive one or more copies of a PATH message that it forwarded earlier when a DSBM on the same wire
当RSVP会话地址为多播地址且SBM、DSBM和DSBM客户端共享同一L2段（共享段）时，SBM或DSBM客户端可能会接收其在DSBM位于同一线路上时先前转发的路径消息的一个或多个副本
forwards it (See Section 5.7 for an example of such a case). To facilitate detection of such loops, we use a new RSVP object called the LAN_LOOPBACK object. DSBM clients or SBMs (but not the DSBMs reflecting a PATH message onto the interface over which it arrived earlier) must overwrite (or add if the PATH message does NOT already include a LAN_LOOPBACK object) the LAN_LOOPBACK object in the PATH message with their own unicast IP address.
转发（参见第5.7节了解此类情况的示例）。为了便于检测这种循环，我们使用了一个新的RSVP对象，称为LAN_LOOPBACK对象。DSBM客户端或SBM（但不是将路径消息反映到其先前到达的接口上的DSBMs）必须使用其自己的单播IP地址覆盖（或添加，如果路径消息尚未包含LAN_环回对象）路径消息中的LAN_环回对象。
Now, a SBM or a DSBM client can easily detect and discard the duplicates by checking the contents of the LAN_LOOPBACK object (a duplicate PATH message will list a device's own interface address in the LAN_LOOPBACK object). Appendix B specifies the exact format of the LAN_LOOPBACK object.
现在，SBM或DSBM客户端可以通过检查LAN_环回对象的内容轻松地检测和丢弃重复项（重复路径消息将在LAN_环回对象中列出设备自己的接口地址）。附录B规定了LAN_环回对象的确切格式。
The model proposed by the Integrated Services working group requires isolation of traffic flows from each other during their transit across a network. The motivation for traffic flow separation is to provide Integrated Services flows protection from misbehaving flows and other best-effort traffic that share the same path. The basic IEEE 802.3/Ethernet networks do not provide any notion of traffic classes to discriminate among different flows that request different services. However, IEEE 802.1p defines a way for switches to differentiate among several "user_priority" values encoded in packets representing different traffic classes (see [IEEE802Q, IEEE8021p] for further details). The user_priority values can be encoded either in native LAN packets (e.g., in IEEE 802.5's FC octet) or by using an encapsulation above the MAC layer (e.g., in the case of Ethernet, the user_priority value assigned to each packet will be carried in the frame header using the new, extended frame format defined by IEEE 802.1Q [IEEE8021Q]. IEEE, however, makes no recommendations about how a sender or network should use the user_priority values. An accompanying document makes recommendations on the usage of the user_priority values (see [RFC-MAP] for details).
综合服务工作组提出的模型要求交通流在网络传输期间相互隔离。交通流分离的动机是提供综合服务流保护，防止行为不端的流量和共享同一路径的其他尽力而为的流量。基本的IEEE 802.3/Ethernet网络不提供任何流量类别的概念来区分请求不同服务的不同流。然而，IEEE 802.1p为交换机定义了一种方法，用于区分编码在代表不同流量类别的数据包中的几个“用户优先级”值（有关更多详细信息，请参见[IEEE802Q，IEEE8021p]）。用户_优先级值可以在本机LAN分组（例如，在IEEE 802.5的FC八位字节中）或通过使用MAC层上的封装（例如，在以太网的情况下，分配给每个分组的用户_优先级值将使用IEEE 802.1Q[IEEE8021Q]定义的新的扩展帧格式在帧报头中携带）但是，IEEE未就发送方或网络应如何使用用户优先级值提出建议。随附的文档对用户优先级值的使用提出了建议（有关详细信息，请参阅[RFC-MAP]）。
Under the Integrated Services model, L3 (or higher) entities that transmit traffic flows onto a L2 segment should perform per-flow policing to ensure that the flows do not exceed their traffic specification as specified during admission control. In addition, L3 devices may label the frames in such flows with a user_priority value to identify their service class.
在综合服务模型下，将流量传输到L2段的L3（或更高级别）实体应执行每个流量的监控，以确保流量不会超过准入控制期间规定的流量规格。此外，L3设备可以使用用户优先级值来标记此类流中的帧，以标识其服务类别。
For the purpose of this discussion, we will refer to the user_priority value carried in the extended frame header as the "traffic class" of a packet. Under the ISSLL model, the L3 entities, that send traffic and that use the SBM protocol, may select the appropriate traffic class of outgoing packets [RFC-MAP]. This
为了便于讨论，我们将扩展帧报头中携带的用户_优先级值称为数据包的“通信量类别”。在ISSLL模型下，发送流量并使用SBM协议的L3实体可以选择传出数据包的适当流量类别[RFC-MAP]。这
selection may be overridden by DSBM devices, in the following manner. once a sender sends a PATH message, downstream DSBMs will insert a new traffic class object (TCLASS object) in the PATH message that travels to the next L3 device (L3 NHOP for the PATH message). To some extent, the TCLASS object contents are treated like the ADSPEC object in the RSVP PATH messages. The L3 device that receives the PATH message must remove and store the TCLASS object as part of its PATH state for the session. Later, when the same L3 device needs to forward a RSVP RESV message towards the original sender, it must include the TCLASS object in the RESV message. When the RESV message arrives at the original sender, the sender must use the user_priority value from the TCLASS object to override its selection for the traffic class marked in outgoing packets.
DSBM设备可通过以下方式覆盖选择。发送方发送路径消息后，下游DSBMs将在路径消息中插入一个新的流量类对象（TCLASS对象），该对象将传输到下一个三级设备（路径消息的三级NHOP）。在某种程度上，TCLASS对象内容被视为RSVP PATH消息中的ADSPEC对象。接收路径消息的L3设备必须删除TCLASS对象并将其存储为会话的路径状态的一部分。稍后，当同一L3设备需要向原始发送方转发RSVP RESV消息时，它必须在RESV消息中包含TCLASS对象。当RESV消息到达原始发送方时，发送方必须使用TCLASS对象中的user_priority值来覆盖其对传出数据包中标记的流量类的选择。
The format of the TCLASS object is specified in Appendix B. Note that TCLASS and other SBM-specific objects are carried in a RSVP message in addition to all the other, normal RSVP objects per RFC 2205.
TCLASS对象的格式在附录B中有规定。请注意，除了RFC 2205规定的所有其他正常RSVP对象外，TCLASS和其他SBM特定对象还包含在RSVP消息中。
In summary, use of TCLASS objects requires following additions to the conventional RSVP message processing at DSBMs, SBMs, and DSBM clients:
总之，使用TCLASS对象需要在DSBMs、SBMs和DSBM客户机上对传统RSVP消息处理进行以下补充：
* When a DSBM receives a PATH message over a managed segment and the PATH message does not include a TCLASS object, the DSBM MAY add a TCLASS object to the PATH message before forwarding it. The DSBM determines the appropriate user_priority value for the TCLASS object. A mechanism for selecting the appropriate user_priority value is described in an accompanying document [RFC-MAP].
* 当DSBM通过受管段接收到PATH消息且该PATH消息不包括TCLASS对象时，DSBM可在转发该PATH消息之前将TCLASS对象添加到该消息中。DSBM为TCLASS对象确定适当的用户优先级值。随附文档[RFC-MAP]中描述了选择适当用户优先级值的机制。
* When SBM or DSBM receives a PATH message with a TCLASS object over a managed segment in a L2 domain and needs to forward it over a managed segment in the same L2 domain, it will store it in its path state and typically forward the message without changing the contents of the TCLASS object. However, if the DSBM/SBM cannot support the service class represented by the user_priority value specified by the TCLASS object in the PATH message, it may change the priority value in the TCLASS to a semantically "lower" service value to reflect its capability and store the changed TCLASS value in its path state.
* 当SBM或DSBM通过L2域中的托管段接收到带有TCLASS对象的PATH消息，并且需要通过同一L2域中的托管段转发该消息时，它将以其路径状态存储该消息，并且通常在不更改TCLASS对象内容的情况下转发该消息。然而，如果DSBM/SBM不能支持由路径消息中的TCLASS对象指定的用户优先级值表示的服务类，则它可以将TCLASS中的优先级值更改为语义上“较低”的服务值，以反映其能力，并将更改后的TCLASS值存储在其路径状态中。
[NOTE: An accompanying document defines the int-serv mappings over IEEE 802 networks [RFC-MAP] provides a precise definition of user_priority values and describes how the user_priority values are compared to determine "lower" of the two values or the "lowest" among all the user_priority values.]
[注：随附文件定义了IEEE 802网络上的int serv映射[RFC-MAP]提供了用户_优先级值的精确定义，并描述了如何比较用户_优先级值以确定两个值中的“较低”或所有用户_优先级值中的“最低”。]
* When a DSBM receives a RESV message with a TCLASS object, it may use the traffic class information (in addition to the usual flowspec information in the RSVP message) for its own admission control for the managed segment.
* 当DSBM接收到带有TCLASS对象的RESV消息时，它可以使用流量类别信息（除了RSVP消息中的通常flowspec信息之外）来对受管段进行自己的准入控制。
Note that this document does not specify the actual algorithm or policy used for admission control. At one extreme, a DSBM may use per-flow reservation request as specified by the flowspec for a fine grain admission control. At the other extreme, a DSBM may only consider the traffic class information for a very coarse-grain admission control based on some static allocation of link capacity for each traffic class. Any combination of the options represented by these two extremes may also be used.
请注意，本文档未指定用于准入控制的实际算法或策略。在一个极端情况下，DSBM可以按照flowspec的规定使用每个流量预留请求进行细粒度准入控制。在另一极端，DSBM只能考虑基于每个交通类的链路容量的静态分配的非常粗粒度接纳控制的业务类别信息。也可以使用这两个极端所代表的选项的任何组合。
* When a DSBM (at an L2 or L3) device receives a RESV message without a TCLASS object and it needs to forward the RESV message over a managed segment within the same L2 domain, it should first check its path state and check whether it has stored a TCLASS value. If so, it should include the TCLASS object in the outgoing RESV message after performing its own admission control. If no TCLASS value is stored, it must forward the RESV message without inserting a TCLASS object.
* 当DSBM（在二级或三级）设备接收到没有TCLASS对象的RESV消息，并且需要通过同一二级域内的托管段转发RESV消息时，它应该首先检查其路径状态并检查是否存储了TCLASS值。如果是这样，它应该在执行自己的许可控制后，在传出的RESV消息中包含TCLASS对象。如果未存储TCLASS值，则必须转发RESV消息，而不插入TCLASS对象。
* When a DSBM client (residing at an L3 device such as a host or an edge router) receives the TCLASS object in a PATH message that it accepts over an interface, it should store the TCLASS object as part of its PATH state for the interface. Later, when the client forwards a RESV message for the same session on the interface, the client must include the TCLASS object (unchanged from what was received in the previous PATH message) in the RESV message it forwards over the interface.
* 当DSBM客户端（位于L3设备（如主机或边缘路由器）通过接口接收路径消息中的TCLASS对象时，它应将TCLASS对象存储为接口路径状态的一部分。稍后，当客户机在接口上转发同一会话的RESV消息时，客户机必须在其通过接口转发的RESV消息中包含TCLASS对象（与前一路径消息中接收到的对象相同）。
* When a DSBM client receives a TCLASS object in an incoming RESV message over a managed segment and local admission control succeeds for the session for the outgoing interface over the managed segment, the client must pass the user_priority value in the TCLASS object to its local packet classifier. This will ensure that the data packets in the admitted RSVP flow that are subsequently forwarded over the outgoing interface will contain the appropriate value encoded in their frame header.
* 当DSBM客户机通过托管段接收到传入RESV消息中的TCLASS对象，并且本地准入控制通过托管段成功进行传出接口的会话时，客户机必须将TCLASS对象中的用户_优先级值传递给其本地数据包分类器。这将确保随后通过传出接口转发的已接纳RSVP流中的数据包将包含在其帧头中编码的适当值。
* When an L3 device receives a PATH or RESV message over a managed segment in one L2 domain and it needs to forward the PATH/RESV message over an interface outside that domain, the L3 device must remove the TCLASS object (along with LAN_NHOP, RSVP_HOP_L2, and LAN_LOOPBACK objects in the case of the PATH message) before forwarding the PATH/RESV message. If the outgoing interface is on a separate L2 domain, these objects may be regenerated according to the processing rules applicable to that interface.
* 当L3设备通过一个L2域中的受管段接收到PATH或RESV消息，并且需要通过该域外的接口转发PATH/RESV消息时，L3设备必须删除TCLASS对象（对于PATH消息，还必须删除LAN_NHOP、RSVP_HOP_L2和LAN_环回对象）在转发路径/RESV消息之前。如果传出接口位于单独的L2域上，则可以根据适用于该接口的处理规则重新生成这些对象。
* An L2 device may have several interfaces with attached segments that are part of the same L2 domain. A switch in a L2 domain is an example of such a device. A device which has several interfaces may contain a SBM protocol entity that acts in different capacities on each interface. For example, a SBM protocol entity could act as a SBM on interface A, and act as a DSBM on interface B.
* 一个二级设备可能有多个与属于同一二级域的连接段的接口。L2域中的交换机就是此类设备的一个示例。具有多个接口的设备可能包含一个SBM协议实体，该实体在每个接口上以不同的容量运行。例如，SBM协议实体可以在接口a上充当SBM，在接口B上充当DSBM。
* A SBM protocol entity on a layer 3 device can be a DSBM client, and SBM, a DSBM, or none of the above (SBM transparent). Non-transparent L3 devices can implement any combination of these roles simultaneously. DSBM clients always reside at L3 devices.
* 第3层设备上的SBM协议实体可以是DSBM客户端，也可以是SBM、DSBM或以上任何一种（SBM透明）。不透明的L3设备可以同时实现这些角色的任意组合。DSBM客户端始终驻留在L3设备上。
* A SBM protocol entity residing at a layer 2 device can be a SBM, a DSBM or none of the above (SBM transparent). A layer 2 device will never host a DSBM client.
* 驻留在第2层设备上的SBM协议实体可以是SBM、DSBM或以上任何一种（SBM透明）。第2层设备永远不会承载DSBM客户端。
As stated earlier, we require that the DSBM clients forward the RSVP PATH messages to their DSBMs in a L2 domain before they reach the next L3 hop in the path. RSVP PATH messages are addressed, according to RFC-2205, to their destination address (which can be either an IP unicast or multicast address). When a L2 device hosts a DSBM, a simple-to-implement mechanism must be provided for the device to capture an incoming PATH message and hand it over to the local DSBM agent without requiring the L2 device to snoop for L3 RSVP messages.
如前所述，我们要求DSBM客户端在到达路径中的下一个三级跃点之前，将RSVP PATH消息转发到二级域中的DSBMs。根据RFC-2205，RSVP路径消息被寻址到其目的地址（可以是IP单播或多播地址）。当二级设备承载DSBM时，必须为设备提供一种易于实现的机制，以捕获传入的路径消息并将其移交给本地DSBM代理，而无需二级设备嗅探三级RSVP消息。
In addition, DSBM clients need to know how to address SBM messages to the DSBM. For the ease of operation and to allow dynamic DSBM-client binding, it should be possible to easily detect and address the existing DSBM on a managed segment.
此外，DSBM客户端需要知道如何将SBM消息寻址到DSBM。为了便于操作并允许动态DSBM客户端绑定，应该可以轻松地检测和寻址托管段上的现有DSBM。
To facilitate dynamic DSBM-client binding as well as to enable easy detection and capture of PATH messages at L2 devices, we require that a DSBM be addressed using a logical address rather than a physical address. We make use of reserved IP multicast address(es) for the purpose of communication with a DSBM. In particular, we require that when a DSBM client or a SBM forwards a PATH message over a managed segment, it is addressed to a reserved IP multicast address. Thus, a DSBM on a L2 device needs to be configured in a way to make it easy to intercept the PATH message and forward it to the local SBM protocol entity. For example, this may involve simply adding a static entry in the device's filtering database (FDB) for the corresponding MAC multicast address to ensure the PATH messages get intercepted and are not forwarded further without the DSBM intervention.
为了促进动态DSBM客户机绑定以及在L2设备上轻松检测和捕获路径消息，我们要求使用逻辑地址而不是物理地址对DSBM进行寻址。我们利用保留的IP多播地址（es）与DSBM通信。特别是，我们要求当DSBM客户机或SBM通过托管段转发路径消息时，将其寻址到保留的IP多播地址。因此，L2设备上的DSBM需要以一种方式进行配置，以便于拦截PATH消息并将其转发到本地SBM协议实体。例如，这可能涉及简单地在设备的过滤数据库（FDB）中为相应的MAC多播地址添加静态条目，以确保路径消息被截获，并且在没有DSBM干预的情况下不会进一步转发。
Similarly, a DSBM always sends the PATH messages over a managed segment using a reserved IP multicast address and, thus, the SBMs or DSBM clients on the managed segments must simply be configured to intercept messages addressed to the reserved multicast address on the appropriate interfaces to easily receive PATH messages.
类似地，DSBM始终使用保留的IP多播地址通过受管段发送路径消息，因此，受管段上的SBMs或DSBM客户端必须简单地配置为在适当的接口上截获寻址到保留多播地址的消息，以便轻松接收路径消息。
RSVP RESV messages continue to be unicast to the previous hop address stored as part of the PATH state at each intermediate hop.
RSVP RESV消息继续单播到作为每个中间跃点的路径状态的一部分存储的上一个跃点地址。
We define use of two reserved IP multicast addresses. We call these the "AllSBM Address" and the "DSBMLogicalAddress". These are chosen from the range of local multicast addresses, such that:
我们定义了两个保留IP多播地址的使用。我们称之为“AllSBM地址”和“DSBMLogicalAddress”。从本地多播地址范围中选择这些地址，以便：
* They are not passed through layer 3 devices.
* 它们不会通过第3层设备。
* They are passed transparently through layer 2 devices which are SBM transparent.
* 它们透明地通过SBM透明的第2层设备。
* They are configured in the permanent database of layer 2 devices which host SBMs or DSBMs, such that they are directed to the SBM management entity in these devices. This obviates the need for these devices to explicitly snoop for SBM related control packets.
* 它们在承载SBM或DSBMs的第2层设备的永久数据库中配置，以便将它们定向到这些设备中的SBM管理实体。这就避免了这些设备显式嗅探SBM相关控制数据包的需要。
* The two reserved addresses are 224.0.0.16 (DSBMLogicalAddress) and 224.0.0.17 (AllSBMAddress).
* 两个保留地址分别为224.0.0.16（DSBMLogicalAddress）和224.0.0.17（AllSBMAddress）。
These addresses are used as described in the following table:
这些地址按下表所述使用：
Type DSBMLogicaladdress AllSBMAddress
类型DSBMLogicalAddressAllsBMAddress
DSBM * Sends PATH messages * Monitors this address to detect Client to this address the presence of a DSBM
DSBM*发送路径消息*监视此地址以检测此地址的客户端是否存在DSBM
* Monitors this address to receive PATH messages forwarded by the DSBM
* 监视此地址以接收DSBM转发的路径消息
SBM * Sends PATH messages * Monitors and sends on this to this address address to participate in election of the DSBM * Monitors this address to receive PATH messages forwarded by the DSBM
SBM*发送路径消息*监视并将其发送到此地址，以参与DSBM的选择*监视此地址以接收DSBM转发的路径消息
DSBM * Monitors this address * Monitors and sends on this for PATH messages to participate in election directed to it of the DSBM * Sends PATH messages to this address
DSBM*监视此地址*在此路径上监视并发送消息，以便参与定向到它的选择。DSBM*将路径消息发送到此地址
The L2 or MAC addresses corresponding to IP multicast addresses are computed algorithmically using a reserved L2 address block (the high order 24-bits are 00:00:5e). The Assigned Numbers RFC [RFC-1700] gives additional details.
使用保留的L2地址块（高阶24位为00:00:5e），通过算法计算与IP多播地址对应的L2或MAC地址。分配的编号RFC[RFC-1700]提供了更多详细信息。
As stated earlier, DSBMs or DSBM clients residing at a L3 device must include a LAN_NHOP_L2 address in the LAN_NHOP information so that L2 devices along the path of a PATH message do not need to separately determine the mapping between the LAN_NHOP_L3 address in the LAN_NHOP object and its corresponding L2 address (for example, using ARP).
如前所述，驻留在L3设备上的DSBMs或DSBM客户端必须在LAN_NHOP_L2地址中包含LAN_NHOP_L2地址，以便沿路径消息路径的L2设备不需要单独确定LAN_NHOP对象中的LAN_NHOP_L3地址与其对应的L2地址之间的映射（例如，使用ARP）。
For the purpose of such mapping at L3 devices, we assume a mapping function called "map_address" that performs the necessary mapping:
为了在L3设备上进行此类映射，我们假设一个名为“map_address”的映射函数，该函数执行必要的映射：
L2ADDR object = map_addr(L3Addr)
L2ADDR对象=映射地址（L3Addr）
We do not specify how the function is implemented; the implementation may simply involve access to the local ARP cache entry or may require performing an ARP function. The function returns a L2ADDR object that need not be interpreted by an L3 device and can be treated as an opaque object. The format of the L2ADDR object is specified in Appendix B.
我们不指定如何实现该功能；实现可能仅仅涉及对本地ARP缓存项的访问，或者可能需要执行ARP功能。该函数返回一个L2ADDR对象，该对象不需要由L3设备解释，并且可以被视为不透明对象。L2ADDR对象的格式见附录B。
We assume that the DSBMs, DSBM clients, and SBMs use only raw IP for encapsulating RSVP messages that are forwarded onto a L2 domain. Thus, when a SBM protocol entity on a L3 device forwards a RSVP message onto a L2 segment, it will only use RAW IP encapsulation.
我们假设DSBMs、DSBM客户端和SBM仅使用原始IP封装转发到L2域的RSVP消息。因此，当L3设备上的SBM协议实体将RSVP消息转发到L2段时，它将只使用原始IP封装。
The message processing and forwarding rules will be described in the context of the sample network illustrated in Figure 2.
消息处理和转发规则将在图2所示的示例网络上下文中描述。
Figure 2 - A sample network or L2 domain consisting of switched and shared L2 segments
图2-由交换和共享L2段组成的示例网络或L2域
..........
.
+------+ . +------+ seg A +------+ seg C +------+ seg D +------+
| H1 |_______| R1 |_________| S1 |_________| S2 |_______| H2 |
| | . | | | | | | | |
+------+ . +------+ +------+ +------+ +------+
. | /
1.0.0.0 . | /
. |___ /
. seg B | / seg E
.......... | /
2.0.0.0 | /
+-----------+
| S3 |
| |
+-----------+
|
|
|
|
seg F | .................
------------------------------ .
| | | .
+------+ +------+ +------+ . +------+
| H3 | | H4 | | R2 |____________| H5 |
| | | | | | . | |
+------+ +------+ +------+ . +------+
.
. 3.0.0.0
.................
..........
.
+------+ . +------+ seg A +------+ seg C +------+ seg D +------+
| H1 |_______| R1 |_________| S1 |_________| S2 |_______| H2 |
| | . | | | | | | | |
+------+ . +------+ +------+ +------+ +------+
. | /
1.0.0.0 . | /
. |___ /
. seg B | / seg E
.......... | /
2.0.0.0 | /
+-----------+
| S3 |
| |
+-----------+
|
|
|
|
seg F | .................
------------------------------ .
| | | .
+------+ +------+ +------+ . +------+
| H3 | | H4 | | R2 |____________| H5 |
| | | | | | . | |
+------+ +------+ +------+ . +------+
.
. 3.0.0.0
.................
Figure 2 illustrates a sample network topology consisting of three IP subnets (1.0.0.0, 2.0.0.0, and 3.0.0.0) interconnected using two routers. The subnet 2.0.0.0 is an example of a L2 domain consisting of switches, hosts, and routers interconnected using switched segments and a shared L2 segment. The sample network contains the following devices:
图2显示了一个示例网络拓扑，由三个IP子网（1.0.0.0、2.0.0.0和3.0.0.0）组成，使用两个路由器互连。子网2.0.0.0是L2域的一个示例，它由交换机、主机和路由器组成，这些交换机、主机和路由器使用交换段和共享L2段互连。示例网络包含以下设备：
Device Type SBM Type
设备类型SBM类型
H1, H5 Host (layer 3) SBM Transparent H2-H4 Host (layer 3) DSBM Client R1 Router (layer 3) SBM R2 Router (layer 3) DSBM for segment F S1 Switch (layer 2) DSBM for segments A, B S2 Switch (layer 2) DSBM for segments C, D, E S3 Switch (layer 2) SBM
H1、H5主机（第3层）SBM透明H2-H4主机（第3层）DSBM客户端R1路由器（第3层）SBM R2路由器（第3层）DSBM用于段F S1交换机（第2层）DSBM用于段A、B S2交换机（第2层）DSBM用于段C、D、E S3交换机（第2层）SBM
The following paragraphs describe the rules, which each of these devices should use to forward PATH messages (rules apply to PATH_TEAR messages as well). They are described in the context of the general network illustrated above. While the examples do not address every scenario, they do address most of the interesting scenarios. Exceptions can be discussed separately.
以下段落描述了这些设备中的每一个应用于转发路径消息的规则（规则也适用于路径消息）。它们在上述一般网络的上下文中描述。虽然这些示例并不是针对每个场景，但它们确实针对了大多数有趣的场景。例外情况可以单独讨论。
The forwarding rules are applied to received PATH messages (routers and switches) or originating PATH messages (hosts), as follows:
转发规则应用于接收的路径消息（路由器和交换机）或原始路径消息（主机），如下所示：
1. Determine the interface(s) on which to forward the PATH message using standard forwarding rules:
1. 使用标准转发规则确定要在其上转发路径消息的接口：
* If there is a LAN_LOOPBACK object in the PATH message, and it carries the address of this device, silently discard the message. (See the section below on "Additional notes on forwarding the PATH message onto a managed segment).
* 如果PATH消息中存在LAN_环回对象，并且该对象携带该设备的地址，则会自动丢弃该消息。（请参阅下面关于“将PATH消息转发到托管段的其他注意事项”的部分）。
* Layer 3 devices use the RSVP session address and perform a routing lookup to determine the forwarding interface(s).
* 第3层设备使用RSVP会话地址并执行路由查找以确定转发接口。
* Layer 2 devices use the LAN_NHOP_L2 address in the LAN_NHOP information and MAC forwarding tables to determine the forwarding interface(s). (See the section below on "Additional notes on forwarding the PATH message onto a managed segment")
* 第2层设备使用LAN_NHOP_L2地址在LAN_NHOP信息和MAC转发表中确定转发接口。（请参阅下面关于“将PATH消息转发到托管段的其他注意事项”的部分）
2. For each forwarding interface:
2. 对于每个转发接口：
* If the device is a layer 3 device, determine whether the interface is on a managed segment managed by a DSBM, based on the presence or absence of I_AM_DSBM messages. If the interface is not on a managed segment, strip out RSVP_HOP_L2, LAN_NHOP, LAN_LOOPBACK, and TCLASS objects (if present), and forward to the unicast or multicast destination.
* 如果设备是第3层设备，则根据I_AM_DSBM消息的存在与否，确定接口是否位于DSBM管理的托管段上。如果接口不在托管段上，请去掉RSVP_HOP_L2、LAN_NHOP、LAN_环回和TCLASS对象（如果存在），并转发到单播或多播目标。
(Note that the RSVP Class Numbers for these new objects are chosen so that if an RSVP message includes these objects, the nodes that are RSVP-aware, but do not participate in the SBM protocol, will ignore and silently discard such objects.)
（请注意，选择这些新对象的RSVP类号是为了，如果RSVP消息包含这些对象，则感知RSVP但不参与SBM协议的节点将忽略并以静默方式丢弃这些对象。）
* If the device is a layer 2 device or it is a layer 3 device *and* the interface is on a managed segment, proceed to rule #3.
* 如果设备是第2层设备或第3层设备*且*接口位于托管段上，请转至规则#3。
3. Forward the PATH message onto the managed segment:
3. 将路径消息转发到托管段：
* If the device is a layer 3 device, insert LAN_NHOP address objects, a LAN_LOOPBACK, and a RSVP_HOP_L2 object into the PATH message. The LAN_NHOP objects carry the LAN_NHOP_L3 and LAN_NHOP_L2 addresses of the next layer 3 hop. The RSVP_HOP_L2 object carries the device's own L2 address, and the LAN_LOOPBACK object contains the IP address of the outgoing interface.
* 如果设备是第3层设备，请在路径消息中插入LAN_NHOP地址对象、LAN_环回和RSVP_HOP_L2对象。LAN_NHOP对象携带下一个第3层跃点的LAN_NHOP_L3和LAN_NHOP_L2地址。RSVP_HOP_L2对象携带设备自己的L2地址，LAN_环回对象包含传出接口的IP地址。
An L3 device should use the map_addr() function described earlier to obtain an L2 address corresponding to an IP address.
L3设备应使用前面描述的map_addr（）函数来获取与IP地址对应的L2地址。
* If the device hosts the DSBM for the segment to which the forwarding interface is attached, do the following:
* 如果设备承载转发接口连接到的段的DSBM，请执行以下操作：
- Retrieve the PHOP information from the standard RSVP HOP object in the PATH message, and store it. This will be used to route RESV messages back through the L2 network. If the PATH message arrived over a managed segment, it will also contain the RSVP_HOP_L2 object; then retrieve and store also the previous hop's L2 address in the PATH state.
- 从PATH消息中的标准RSVP HOP对象检索PHOP信息，并将其存储。这将用于通过L2网络将RESV消息路由回。如果路径消息通过托管段到达，它还将包含RSVP_HOP_L2对象；然后在路径状态中检索并存储上一个跃点的L2地址。
- Copy the IP address of the forwarding interface (layer 2 devices must also have IP addresses) into the standard RSVP HOP object and the L2 address of the forwarding interface into the RSVP_HOP_L2 object.
- 将转发接口的IP地址（第2层设备也必须具有IP地址）复制到标准RSVP HOP对象中，并将转发接口的L2地址复制到RSVP_HOP_L2对象中。
- If the PATH message received does not contain the TCLASS object, insert a TCLASS object. The user_priority value inserted in the TCLASS object is based on service mappings internal to the device that are configured according to the guidelines listed in [RFC-MAP]. If the message already contains the TCLASS object, the user_priority value may be changed based again on the service mappings internal to the device.
- 如果收到的路径消息不包含TCLASS对象，请插入TCLASS对象。TCLASS对象中插入的用户_优先级值基于设备内部的服务映射，这些映射根据[RFC-MAP]中列出的准则进行配置。如果消息已经包含TCLASS对象，则可以根据设备内部的服务映射再次更改user_优先级值。
* If the device is a layer 3 device and hosts a SBM for the segment to which the forwarding interface is attached, it *is required* to retrieve and store the PHOP info.
* 如果该设备是第3层设备，并且承载转发接口连接到的段的SBM，则*需要*检索和存储PHOP信息。
If the device is a layer 2 device and hosts a SBM for the segment to which the forwarding interface is attached, it is *not* required to retrieve and store the PHOP info. If it does not do so, the SBM must leave the standard RSVP HOP object and the RSVP_HOP_L2 objects in the PATH message intact and it will not receive RESV messages.
如果该设备是第2层设备，并且承载转发接口连接到的段的SBM，则*不*需要检索和存储PHOP信息。如果不这样做，SBM必须保持PATH消息中的标准RSVP HOP对象和RSVP_HOP_L2对象完好无损，并且不会接收RESV消息。
If the SBM on a L2 device chooses to overwrite the RSVP HOP and RSVP_HOP_L2 objects with the IP and L2 addresses of its forwarding interface, it will receive RESV messages. In this case, it must store the PHOP address info received in the standard RSVP_HOP field and RSVP_HOP_L2 objects of the incident PATH message.
如果二级设备上的SBM选择用其转发接口的IP和二级地址覆盖RSVP HOP和RSVP_HOP_L2对象，则它将接收RESV消息。在这种情况下，它必须将收到的PHOP地址信息存储在事件路径消息的标准RSVP_HOP字段和RSVP_HOP_L2对象中。
In both the cases mentioned above (L2 or L3 devices), the SBM must forward the TCLASS object in the received PATH message unchanged.
在上述两种情况下（L2或L3设备），SBM必须在接收到的PATH消息中转发TCLASS对象，保持不变。
* Copy the IP address of the forwarding interface into the LAN_LOOPBACK object, unless the SBM protocol entity is a DSBM reflecting a PATH message back onto the incident interface. (See the section below on "Additional notes on forwarding a PATH message onto a managed segment").
* 将转发接口的IP地址复制到LAN_环回对象中，除非SBM协议实体是将路径消息反射回事件接口的DSBM。（请参阅下面关于“将PATH消息转发到托管段的其他注意事项”的部分）。
* If the SBM protocol entity is the DSBM for the segment to which the forwarding interface is attached, it must send the PATH message to the AllSBMAddress.
* 如果SBM协议实体是连接转发接口的段的DSBM，则它必须将PATH消息发送到AllSBMAddress。
* If the SBM protocol entity is a SBM or a DSBM Client on the segment to which the forwarding interface is attached, it must send the PATH message to the DSBMLogicalAddress.
* 如果SBM协议实体是连接转发接口的网段上的SBM或DSBM客户端，则必须将PATH消息发送到DSBMLogicalAddress。
5.5.1. Additional notes on forwarding a PATH message onto a managed segment
5.5.1. 有关将路径消息转发到托管段的附加说明
Rule #1 states that normal IEEE 802.1D forwarding rules should be used to determine the interfaces on which the PATH message should be forwarded. In the case of data packets, standard forwarding rules at a L2 device dictate that the packet should not be forwarded on the interface from which it was received. However, in the case of a DSBM that receives a PATH message over a managed segment, the following exception applies:
规则#1规定，应使用普通的IEEE 802.1D转发规则来确定路径消息应在哪些接口上转发。在数据包的情况下，L2设备上的标准转发规则规定不应在接收数据包的接口上转发数据包。但是，对于通过托管段接收路径消息的DSBM，以下例外情况适用：
E1. If the address in the LAN_NHOP object is a unicast address, consult the filtering database (FDB) to determine whether the destination address is listed on the same interface over which the message was received. If yes, follow the rule below on "reflecting a PATH message back onto an interface" described below; otherwise, proceed with the rest of the message processing as usual.
E1。如果LAN_NHOP对象中的地址是单播地址，请查阅筛选数据库（FDB），以确定目标地址是否列在接收消息的同一接口上。如果是，请遵循下面描述的“将路径消息反射回接口”规则；否则，继续进行其余的消息处理。
E2. If there are members of the multicast group address (specified by the addresses in the LAN_NHOP object), on the segment from which the message was received, the message should be forwarded back onto the interface from which it was received and follow the rule on "reflecting a PATH message back onto an interface" described below.
E2。如果在接收消息的段上有多播组地址（由LAN_NHOP对象中的地址指定）的成员，则应将消息转发回接收它的接口，并遵循下面描述的“将路径消息反射回接口”规则。
*** Reflecting a PATH message back onto an interface ***
*** Reflecting a PATH message back onto an interface ***
Under the circumstances described above, when a DSBM reflects the PATH message back onto an interface over which it was received, it must address it using the AllSBMAddress.
在上述情况下，当DSBM将PATH消息反射回接收它的接口时，它必须使用AllSBMAddress对其进行寻址。
Since it is possible for a DSBM to reflect a PATH message back onto the interface from which it was received, precautions must be taken to avoid looping these messages indefinitely. The LAN_LOOPBACK object addresses this issue. All SBM protocol entities (except DSBMs reflecting a PATH message) overwrite the LAN_LOOPBACK object in the PATH message with the IP address of the outgoing interface. DSBMs which are reflecting a PATH message, leave the LAN_LOOPBACK object unchanged. Thus, SBM protocol entities will always be able to recognize a reflected multicast message by the presence of their own address in the LAN_LOOPBACK object. These messages should be silently discarded.
由于DSBM可以将PATH消息反射回接收它的接口，因此必须采取预防措施避免无限期地循环这些消息。LAN_环回对象解决了这个问题。所有SBM协议实体（反映路径消息的DSBMs除外）使用传出接口的IP地址覆盖路径消息中的LAN_环回对象。反映路径消息的DSBMs使LAN_环回对象保持不变。因此，SBM协议实体将始终能够通过其自身地址在LAN_环回对象中的存在来识别反射的多播消息。这些消息应该被悄悄地丢弃。
Let's see how the rules are applied in the general network illustrated previously (see Figure 2).
让我们看看这些规则是如何在前面所示的通用网络中应用的（见图2）。
Assume that H1 is sending a PATH for a unicast session for which H5 is the receiver. The following PATH message is composed by H1:
假设H1正在发送单播会话的路径，H5是该会话的接收器。以下路径消息由H1组成：
RSVP Contents RSVP session IP address IP address of H5 (3.0.0.35) Sender Template IP address of H1 (1.0.0.11) PHOP IP address of H1 (1.0.0.11) RSVP_HOP_L2 n/a (H1 is not sending onto a managed segment) LAN_NHOP n/a (H1 is not sending onto a managed
RSVP内容RSVP会话IP地址H5的IP地址（3.0.0.35）发送方模板IP地址H1（1.0.0.11）PHOP IP地址H1（1.0.0.11）RSVP_HOP_L2 n/a（H1未发送到托管段）LAN_NHOP n/a（H1未发送到托管段）
segment) LAN_LOOPBACK n/a (H1 is not sending onto a managed segment)
段）LAN_环回不适用（H1未发送到受管段）
IP Header Source address IP address of H1 (1.0.0.11) Destn address IP addr of H5 (3.0.0.35, assuming raw mode & router alert)
IP报头源地址H1的IP地址（1.0.0.11）目标地址H5的IP地址（3.0.0.35，假设原始模式和路由器警报）
MAC Header Destn address The L2 addr corresponding to R1 (determined by map_addr() and routing tables at H1)
MAC头Destn地址与R1相对应的L2地址（由H1的map_addr（）和路由表确定）
Since H1 is not sending onto a managed segment, the PATH message is composed and forwarded according to standard RSVP processing rules.
由于H1未发送到托管段，因此根据标准RSVP处理规则组合和转发路径消息。
Upon receipt of the PATH message, R1 composes and forwards a PATH message as follows:
在收到PATH消息后，R1按如下方式编写并转发PATH消息：
RSVP Contents RSVP session IP address IP address of H5 Sender Template IP address of H1 PHOP IP address of R1 (2.0.0.1) (seed the return path for RESV messages) RSVP_HOP_L2 L2 address of R1 LAN_NHOP LAN_NHOP_L3 (2.0.0.2) and LAN_NHOP_L2 address of R2 (L2ADDR) (this is the next layer 3 hop) LAN_LOOPBACK IP address of R1 (2.0.0.1)
RSVP Contents RSVP session IP address IP address of H5 Sender Template IP address of H1 PHOP IP address of R1 (2.0.0.1) (seed the return path for RESV messages) RSVP_HOP_L2 L2 address of R1 LAN_NHOP LAN_NHOP_L3 (2.0.0.2) and LAN_NHOP_L2 address of R2 (L2ADDR) (this is the next layer 3 hop) LAN_LOOPBACK IP address of R1 (2.0.0.1)translate error, please retry
IP Header Source address IP address of H1 Destn address DSBMLogical IP address (224.0.0.16)
IP头源地址H1 Destn地址的IP地址DSBM逻辑IP地址（224.0.0.16）
MAC Header Destn address DSBMLogical MAC address
MAC头Destn地址DSBM逻辑MAC地址
* R1 does a routing lookup on the RSVP session address, to determine the IP address of the next layer 3 hop, R2.
* R1对RSVP会话地址进行路由查找，以确定下一个第3层跃点R2的IP地址。
* It determines that R2 is accessible via seg A and that seg A is managed by a DSBM, S1.
* 它确定R2可通过seg A访问，且seg A由DSBM S1管理。
* Therefore, it concludes that it is sending onto a managed segment, and composes LAN_NHOP objects to carry the layer 3 and layer 2 next hop addresses. To compose the LAN_NHOP L2ADDR object, it invokes the L3 to L2 address mapping function
* 因此，它得出结论，它正在发送到一个托管段，并组成LAN_NHOP对象来携带第3层和第2层的下一跳地址。为了组成LAN_NHOP L2ADDR对象，它调用L3到L2地址映射函数
("map_address") to find out the MAC address for the next hop L3 device, and then inserts a LAN_NHOP_L2ADDR object (that carries the MAC address) in the message.
（“map_address”）查找下一跳L3设备的MAC地址，然后在消息中插入LAN_NHOP_L2ADDR对象（携带MAC地址）。
* Since R1 is not the DSBM for seg A, it sends the PATH message to the DSBMLogicalAddress.
* 由于R1不是seg A的DSBM，因此它会将PATH消息发送到DSBMLogicalAddress。
Upon receipt of the PATH message, S1 composes and forwards a PATH message as follows:
在接收到路径消息后，S1按照如下方式组合并转发路径消息：
RSVP Contents RSVP session IP address IP address of H5 Sender Template IP address of H1 PHOP IP addr of S1 (seed the return path for RESV messages) RSVP_HOP_L2 L2 address of S1 LAN_NHOP LAN_NHOP_L3 (IP) and LAN_NHOP_L2 address of R2 (layer 2 devices do not modify the LAN_NHOP) LAN_LOOPBACK IP addr of S1
RSVP内容RSVP会话IP地址H5发送方的IP地址模板S1的H1 PHOP IP地址（为RESV消息的返回路径设定种子）S1的RSVP_HOP_L2 L2地址LAN_NHOP_L3（IP）和R2的LAN_NHOP_L2地址（第2层设备不修改LAN_NHOP）S1的LAN_环回IP地址
IP Header Source address IP address of H1 Destn address AllSBMIPaddr (224.0.0.17, since S1 is the DSBM for seg B).
IP头源地址H1 Destn address AllSBMIPaddr的IP地址（224.0.0.17，因为S1是seg B的DSBM）。
MAC Header Destn address All SBM MAC address (since S1 is the DSBM for seg B).
MAC头Destn地址所有SBM MAC地址（因为S1是seg B的DSBM）。
* S1 looks at the LAN_NHOP address information to determine the L2 address towards which it should forward the PATH message.
* S1查看LAN_NHOP地址信息，以确定其应将路径消息转发到的L2地址。
* From the bridge forwarding tables, it determines that the L2 address is reachable via seg B.
* 根据网桥转发表，它确定L2地址可通过seg B访问。
* S1 inserts the RSVP_HOP_L2 object and overwrites the RSVP HOP object (PHOP) with its own addresses.
* S1插入RSVP_HOP_L2对象，并用其自己的地址覆盖RSVP HOP对象（PHOP）。
* Since S1 is the DSBM for seg B, it addresses the PATH message to the AllSBMAddress.
* 由于S1是seg B的DSBM，因此它将路径消息寻址到AllSBMAddress。
Upon receipt of the PATH message, S3 composes and forwards a PATH message as follows:
在收到PATH消息后，S3按照如下方式组合并转发PATH消息：
RSVP Contents RSVP session IP addr IP address of H5 Sender Template IP address of H1 PHOP IP addr of S3 (seed the return path for RESV messages) RSVP_HOP_L2 L2 address of S3 LAN_NHOP LAN_NHOP_L3 (IP) and LAN_NHOP_L2 (MAC) address of R2 (L2 devices don't modify LAN_NHOP) LAN_LOOPBACK IP address of S3
RSVP内容RSVP会话IP地址H5发送方的IP地址模板H1 PHOP的IP地址S3的IP地址（为RESV消息的返回路径种子）RSVP_HOP_L2 S3 LAN_NHOP_NHOP_L3的L2地址（IP）和R2的LAN_NHOP_L2（MAC）地址（L2设备不修改LAN_NHOP）S3的LAN_环回IP地址
IP Header Source address IP address of H1 Destn address DSBMLogical IP addr (since S3 is not the DSBM for seg F)
IP头源地址H1 Destn地址DSBM的IP地址逻辑IP地址（因为S3不是seg F的DSBM）
MAC Header Destn address DSBMLogical MAC address
MAC头Destn地址DSBM逻辑MAC地址
* S3 looks at the LAN_NHOP address information to determine the L2 address towards which it should forward the PATH message.
* S3查看LAN_NHOP地址信息，以确定其应将PATH消息转发到的L2地址。
* From the bridge forwarding tables, it determines that the L2 address is reachable via segment F.
* 根据网桥转发表，它确定L2地址可通过段F访问。
* It has discovered that R2 is the DSBM for segment F. It therefore sends the PATH message to the DSBMLogicalAddress.
* 它发现R2是段F的DSBM。因此，它将PATH消息发送到DSBMLogicalAddress。
* Note that S3 may or may not choose to overwrite the PHOP objects with its own IP and L2 addresses. If it does so, it will receive RESV messages. In this case, it must also store the PHOP info received in the incident PATH message so that it is able to forward the RESV messages on the correct path.
* 请注意，S3可能会也可能不会选择用自己的IP和L2地址覆盖PHOP对象。如果这样做，它将接收RESV消息。在这种情况下，它还必须将收到的PHOP信息存储在事件路径消息中，以便能够在正确的路径上转发RESV消息。
Upon receipt of the PATH message, R2 composes and forwards a PATH message as follows:
在收到PATH消息后，R2按如下方式编写并转发PATH消息：
RSVP Contents RSVP session IP addr IP address of H5 Sender Template IP address of H1 PHOP IP addr of R2 (seed the return path for RESV messages) RSVP_HOP_L2 Removed by R2 (R2 is not sending onto a managed segment) LAN_NHOP Removed by R2 (R2 is not sending onto a managed segment)
RSVP内容RSVP会话IP地址H5发送方的IP地址模板H1的IP地址PHOP IP地址R2的IP地址（为RESV消息的返回路径设定种子）RSVP_HOP_L2被R2删除（R2未发送到托管段）LAN_NHOP被R2删除（R2未发送到托管段）
IP Header Source address IP address of H1 Destn address IP address of H5, the RSVP session address
IP头源地址H1的IP地址Destn地址H5的IP地址，RSVP会话地址
MAC Header Destn address L2 addr corresponding to H5, the next layer 3 hop
MAC头Destn地址L2 addr对应于H5，下一层3跳
* R2 does a routing lookup on the RSVP session address, to determine the IP address of the next layer 3 hop, H5.
* R2对RSVP会话地址进行路由查找，以确定下一个第3层跃点H5的IP地址。
* It determines that H5 is accessible via a segment for which there is no DSBM (not a managed segment).
* 它确定H5可通过没有DSBM的段（非托管段）访问。
* Therefore, it removes the LAN_NHOP and RSVP_HOP_L2 objects and places the RSVP session address in the destination address of the IP header. It places the L2 address of the next layer 3 hop, into the destination address of the MAC header and forwards the PATH message to H5.
* 因此，它删除LAN_NHOP和RSVP_HOP_L2对象，并将RSVP会话地址放在IP报头的目标地址中。它将下一个第3层跃点的L2地址放入MAC报头的目标地址，并将路径消息转发到H5。
The rules described above also apply to multicast (m/c) sessions. For the purpose of this discussion, it is assumed that layer 2 devices track multicast group membership on each port individually. Layer 2 devices which do not do so, will merely generate extra multicast traffic. This is the case for L2 devices which do not implement multicast filtering or GARP/GMRP capability.
上述规则也适用于多播（m/c）会话。在本讨论中，假设第2层设备分别跟踪每个端口上的多播组成员资格。不这样做的第2层设备只会产生额外的多播流量。对于不实现多播过滤或GARP/GMRP功能的L2设备，情况就是这样。
Assume that H1 is sending a PATH for an m/c session for which H3 and H5 are the receivers. The rules are applied as they are in the unicast case described previously, until the PATH message reaches R2, with the following exception. The RSVP session address and the LAN_NHOP carry the destination m/c addresses rather than the unicast addresses carried in the unicast example.
假设H1正在发送一个m/c会话的路径，H3和H5是该会话的接收器。在PATH消息到达R2之前，将按照前面描述的单播情况应用这些规则，但以下情况除外。RSVP会话地址和LAN_NHOP携带目标m/c地址，而不是单播示例中携带的单播地址。
Now let's look at the processing applied by R2 upon receipt of the PATH message. Recall that R2 is the DSBM for segment F. Therefore, S3 will have forwarded its PATH message to the DSBMLogicalAddress, to be picked up by R2. The PATH message will not have been seen by H3 (one of the m/c receivers), since it monitors only the AllSBMAddress, not the DSBMLogicalAddress for incoming PATH messages. We rely on R2 to reflect the PATH message back onto seg f, and to forward it to H5. R2 forwards the following PATH message onto seg f:
现在让我们看看R2在收到PATH消息时应用的处理。回想一下，R2是段F的DSBM。因此，S3将其路径消息转发到DSBMLogicalAddress，由R2拾取。H3（一个m/c接收器）不会看到PATH消息，因为它只监视AllSBMAddress，而不监视传入PATH消息的DSBMLogicalAddress。我们依靠R2将路径信息反射回seg f，并将其转发到H5。R2将以下路径消息转发到seg f：
RSVP Contents RSVP session addr m/c session address Sender Template IP address of H1
RSVP内容RSVP会话地址m/c会话地址发送方模板H1的IP地址
PHOP IP addr of R2 (seed the return path for RESV messages) RSVP_HOP_L2 L2 addr of R2 LAN_NHOP m/c session address and corresponding L2 address LAN_LOOPBACK IP addr of S3 (DSBMs reflecting a PATH message don't modify this object)
R2的PHOP IP地址（为RESV消息的返回路径设定种子）R2 LAN的RSVP_HOP_L2 L2地址\u NHOP m/c会话地址和相应的L2地址LAN_环回S3的IP地址（反映路径消息的DSBMs不修改此对象）
IP Header Source address IP address of H1
IP头源地址H1的IP地址
Destn address AllSBMIP address (since R2 is the DSBM for seg F)
Destn地址AllSBMIP地址（因为R2是seg F的DSBM）
MAC Header Destn address AllSBMMAC address (since R2 is the DSBM for seg F)
MAC头Destn地址AllSBMMAC地址（因为R2是seg F的DSBM）
Since H3 is monitoring the All SBM Address, it will receive the PATH message reflected by R2. Note that R2 violated the standard forwarding rules here by sending an incoming message back onto the interface from which it was received. It protected against loops by leaving S3's address in the LAN_LOOPBACK object unchanged.
由于H3正在监视所有SBM地址，因此它将接收R2反映的路径消息。请注意，R2违反了此处的标准转发规则，将传入消息发送回接收该消息的接口。它通过保持LAN_环回对象中S3的地址不变来防止循环。
R2 forwards the following PATH message on to H5:
R2将以下路径消息转发到H5：
RSVP Contents RSVP session addr m/c session address Sender Template IP address of H1 PHOP IP addr of R2 (seed the return path for RESV messages) RSVP_HOP_L2 Removed by R2 (R2 is not sending onto a managed segment) LAN_NHOP Removed by R2 (R2 is not sending onto a managed segment) LAN_LOOPBACK Removed by R2 (R2 is not sending onto a managed segment)
RSVP内容RSVP会话地址m/c会话地址发送方模板IP地址H1 PHOP IP地址R2（为RESV消息的返回路径设定种子）RSVP_HOP_L2被R2删除（R2未发送到托管段）LAN_NHOP被R2删除（R2未发送到托管段）LAN_环回被R2删除（R2未发送到托管段）
IP Header Source address IP address of H1 Destn address m/c session address
IP头源地址H1目的地IP地址m/c会话地址
MAC Header Destn address MAC addr corresponding to the m/c session address
与m/c会话地址对应的MAC头Destn地址MAC addr
* R2 determines that there is an m/c receiver accessible via a segment for which there is no DSBM. Therefore, it removes the LAN_NHOP and RSVP_HOP_L2 objects and places the RSVP session address in the destination address of the IP header. It
* R2确定存在可通过没有DSBM的段访问的m/c接收器。因此，它删除LAN_NHOP和RSVP_HOP_L2对象，并将RSVP会话地址放在IP报头的目标地址中。信息技术
places the corresponding L2 address into the destination address of the MAC header and multicasts the message towards H5.
将相应的L2地址放入MAC报头的目标地址，并向H5多播消息。
When a DSBM client receives TCLASS objects from different senders (different PATH messages) in the same RSVP session and needs to combine them for sending back a single RESV message (as in a wild-card style reservation), the DSBM client must choose an appropriate value that corresponds to the desired-delay traffic class. An accompanying document discusses the guidelines for traffic class selection based on desired service and the TSpec information [RFC-MAP].
当DSBM客户端在同一RSVP会话中从不同的发送者（不同路径消息）接收TCLASS对象，并需要将它们组合起来以发送回单个RESV消息（如通配符样式的保留）时，DSBM客户端必须选择与所需延迟通信量类别相对应的适当值。随附文件讨论了基于所需服务和TSpec信息[RFC-MAP]的交通等级选择指南。
In addition, when a SBM or DSBM needs to merge RESVs from different next hops at a merge point, it must decide how to handle the TCLASS values in the incoming RESVs if they do not match. Consider the case when a reservation is in place for a flow at a DSBM (or SBM) with a successful admission control done for the TCLASS requested in the first RESV for the flow. If another RESV (not the refresh of the previously admitted RESV) for the same flow arrives at the DSBM, the DSBM must first check the TCLASS value in the new RESV against the TCLASS value in the already installed RESV. If the two values are same, the RESV requests are merged and the new, merged RESV installed and forwarded using the normal rules of message processing. However, if the two values are not identical, the DSBM must generate and send a RESV_ERR message towards the sender (NHOP) of the newer, RESV message. The RESV_ERR must specify the error code corresponding to the RSVP "traffic control error" (RESV_ERR code 21) that indicates failure to merge two incompatible service requests (sub-code 01 for the RSVP traffic control error) [RFC-2205]. The RESV_ERR message may include additional objects to assist downstream nodes in recovering from this condition. The definition and usage of such objects is beyond the scope of this memo.
此外，当SBM或DSBM需要在合并点合并来自不同下一个跃点的RESV时，它必须决定如何处理传入RESV中的TCLASS值（如果它们不匹配）。考虑当在DSBM（或SBM）中为一个流进行预约时的情况，在该流的第一个RESV中为成功的接纳控制完成了一个成功的接纳控制。如果相同流的另一个RESV（不是先前允许的RESV的刷新）到达DSBM，DSBM必须首先对照已安装的RESV中的TCLASS值检查新RESV中的TCLASS值。如果两个值相同，将合并RESV请求，并使用消息处理的常规规则安装和转发新的合并RESV。但是，如果两个值不相同，DSBM必须生成并向较新的RESV消息的发送方（NHOP）发送RESV_ERR消息。RESV_ERR必须指定与RSVP“流量控制错误”（RESV_ERR代码21）对应的错误代码，该错误代码表示未能合并两个不兼容的服务请求（RSVP流量控制错误的子代码01）[RFC-2205]。RESV_ERR消息可以包括其他对象，以帮助下游节点从这种情况中恢复。此类对象的定义和使用超出了本备忘录的范围。
SBM transparent devices are unaware of the entire SBM/DSBM protocol. They do not intercept messages addressed to either of the SBM related local group addresses (the DSBMLogicalAddrss and the ALLSBMAddress), but instead, pass them through. As a result, they do not divide the DSBM election scope, they do not explicitly participate in routing of PATH or RESV messages, and they do not participate in admission control. They are entirely transparent with respect to SBM operation.
SBM透明设备不知道整个SBM/DSBM协议。它们不会截获发往任何一个与SBM相关的本地组地址（DSBMLogicalAddress和ALLSBMAddress）的消息，而是将它们传递出去。因此，它们不划分DSBM选择范围，不显式参与PATH或RESV消息的路由，也不参与准入控制。就SBM操作而言，它们是完全透明的。
According to the definitions provided, physical segments interconnected by SBM transparent devices are considered a single managed segment. Therefore, DSBMs must perform admission control on such managed segments, with limited knowledge of the segment's topology. In this case, the network administrator should configure the DSBM for each managed segment, with some reasonable approximation of the segment's capacity. A conservative policy would configure the DSBM for the lowest capacity route through the managed segment. A liberal policy would configure the DSBM for the highest capacity route through the managed segment. A network administrator will likely choose some value between the two, based on the level of guarantee required and some knowledge of likely traffic patterns.
根据提供的定义，SBM透明设备互连的物理段被视为单个受管段。因此，DSBMs必须在对段拓扑了解有限的情况下，对此类受管段执行准入控制。在这种情况下，网络管理员应为每个受管网段配置DSBM，并对网段的容量进行合理的近似。保守策略会将DSBM配置为通过受管段的最低容量路由。宽松的策略将为通过受管段的最高容量路由配置DSBM。网络管理员可能会根据所需的保证级别和对可能的流量模式的一些了解，在两者之间选择一些值。
This document does not specify the configuration mechanism or the choice of a policy.
本文档未指定配置机制或策略的选择。
In the example illustrated, S3 hosts a SBM, but the SBM on S3 did not win the election to act as DSBM on any segment. One might ask what purpose such a SBM protocol entity serves. Such SBMs actually provide two useful functions. First, the additional SBMs remain passive in the background for fault tolerance. They listen to the periodic announcements from the current DSBM for the managed segment (Appendix A describes this in more detail) and step in to elect a new DSBM when the current DSBM fails or ceases to be operational for some reason. Second, such SBMs also provide the important service of dividing the election scope and reducing the size and complexity of managed segments. For example, consider the sample topology in Figure 3 again. the device S3 contains an SBM that is not a DSBM for any f the segments, B, E, or F, attached to it. However, if the SBM protocol entity on S3 was not present, segments B and F would not be separate segments from the point of view of the SBM protocol. Instead, they would constitute a single managed segment, managed by a single DSBM. Because the SBM entity on S3 divides the election scope, seg B and seg F are each managed by separate DSBMs. Each of these segments have a trivial topology and a well defined capacity. As a result, the DSBMs for these segments do not need to perform admission control based on approximations (as would be the case if S3 were SBM transparent).
在所示的示例中，S3承载一个SBM，但S3上的SBM没有赢得在任何段上充当DSBM的选举。有人可能会问这样一个SBM协议实体有什么用途。此类SBM实际上提供了两个有用的功能。首先，额外的SBM在容错背景下保持被动。他们听取当前DSBM对托管段的定期公告（附录A对此进行了更详细的描述），并在当前DSBM因某种原因出现故障或停止运行时，介入选择新的DSBM。第二，此类SBM还提供了划分选举范围和减少管理部分的规模和复杂性的重要服务。例如，再次考虑图3中的示例拓扑结构。设备S3包含一个SBM，该SBM不是连接到其上的任何f段（B、E或f）的DSBM。但是，如果S3上的SBM协议实体不存在，则从SBM协议的角度来看，B段和F段不会是单独的段。相反，它们将构成一个单一的托管段，由单个DSBM管理。因为S3上的SBM实体划分了选择范围，所以seg B和seg F分别由单独的DSBMs管理。这些段中的每一段都有一个简单的拓扑结构和定义良好的容量。因此，这些段的DSBMs不需要基于近似值执行准入控制（如果S3是SBM透明的，情况就是这样）。
Note that, SBM protocol entities which are not DSBMs, are not required to overwrite the PHOP in incident PATH messages with their own address. This is because it is not necessary for RESV messages to be routed through these devices. RESV messages are only required to be routed through the correct sequence of DSBMs. SBMs may not process RESV messages that do pass through them, other than to forward them towards their destination address, using standard
请注意，非DSBMs的SBM协议实体不需要用自己的地址覆盖事件路径消息中的PHOP。这是因为没有必要通过这些设备路由RESV消息。RESV消息只需要通过正确的DSBMs序列进行路由。SBM可能不会处理确实通过它们的RESV消息，而不是使用标准消息将它们转发到其目标地址
forwarding rules.
转发规则。
SBM protocol entities which are not DSBMs are required to overwrite the address in the LAN_LOOPBACK object with their own address, in order to avoid looping multicast messages. However, no state need be stored.
非DSBMs的SBM协议实体需要用自己的地址覆盖LAN_环回对象中的地址，以避免循环多播消息。但是，不需要存储任何状态。
There are a few interesting inter-operability issues related to the deployment of a DSBM-based admission control method in an environment consisting of network nodes with and without RSVP capability. In the following, we list some of these scenarios and explain how SBM-aware clients and nodes can operate in those scenarios:
在由具有和不具有RSVP能力的网络节点组成的环境中，部署基于DSBM的准入控制方法有几个有趣的互操作性问题。在下文中，我们列出了其中一些场景，并解释了支持SBM的客户端和节点如何在这些场景中运行：
6.1. An L2 domain with no RSVP capability.
6.1. 没有RSVP功能的L2域。
It is possible to envisage L2 domains that do not use RSVP signaling for requesting resource reservations, but, instead, use some other (e.g., SNMP or static configuration) mechanism to reserve bandwidth at a particular network device such as a router. In that case, the question is how does a DSBM-based admission control method work and interoperate with the non-RSVP mechanism. The SBM-based method does not attempt to provide an admission control solution for such an environment. The SBM-based approach is part of an end to end signaling approach to establish resource reservations and does not attempt to provide a solution for SNMP-based configuration scenario.
可以设想L2域不使用RSVP信令来请求资源预留，而是使用一些其他（例如SNMP或静态配置）机制来预留特定网络设备（例如路由器）的带宽。在这种情况下，问题是基于DSBM的准入控制方法如何工作以及如何与非RSVP机制互操作。基于SBM的方法并不试图为这种环境提供准入控制解决方案。基于SBM的方法是建立资源预留的端到端信令方法的一部分，并不试图为基于SNMP的配置方案提供解决方案。
As stated earlier, the SBM-based approach can, however, co-exist with any other, non-RSVP bandwidth allocation mechanism as long as resources being reserved are either partitioned statically between the different mechanisms or are resolved dynamically through a common bandwidth allocator so that there is no over-commitment of the same resource.
然而，如前所述，基于SBM的方法可以与任何其他非RSVP带宽分配机制共存，只要所保留的资源在不同机制之间静态地划分，或者通过公共带宽分配器动态地解析，从而不存在相同资源的过度承诺。
6.2. An L2 domain with SBM-transparent L2 Devices.
6.2. 具有SBM透明L2设备的L2域。
This scenario has been addressed earlier in the document. The SBM-based method is designed to operate in such an environment. When SBM-transparent L2 devices interconnect SBM-aware devices, the resulting managed segment is a combination of one or more physical segments and the DSBM for the managed segment may not be as efficient in allocating resources as it would if all L2 devices were SBM-aware.
本文档前面已经讨论过这种情况。基于SBM的方法设计用于在这样的环境中运行。当SBM透明二级设备互连SBM感知设备时，产生的受管段是一个或多个物理段的组合，并且受管段的DSBM在分配资源方面可能不如所有二级设备都感知SBM时那么有效。
6.3. An L2 domain on which some RSVP-based senders are not DSBM clients.
6.3. 一个L2域，其中一些基于RSVP的发送方不是DSBM客户端。
All senders that are sourcing RSVP-based traffic flows onto a managed segment MUST be SBM-aware and participate in the SBM protocol. Use of the standard, non-SBM version of RSVP may result in over-allocation of resources, as such use bypasses the resource management function of the DSBM. All other senders (i.e., senders that are not sending streams subject to RSVP admission control) should be elastic applications that send traffic of lower priority than the RSVP traffic, and use TCP-like congestion avoidance mechanisms.
所有将基于RSVP的通信流发送到受管网段的发送方必须了解SBM并参与SBM协议。使用标准、非SBM版本的RSVP可能会导致资源过度分配，因为这种使用会绕过DSBM的资源管理功能。所有其他发送方（即，不发送受RSVP许可控制的流的发送方）应该是弹性应用程序，发送优先级低于RSVP流量的流量，并使用类似TCP的拥塞避免机制。
All DSBMs, SBMs, or DSBM clients on a managed segment (a segment with a currently active DSBM) must not accept PATH messages from senders that are not SBM-aware. PATH messages from such devices can be easily detected by SBMs and DSBM clients as they would not be multicast to the ALLSBMAddress (in case of SBMs and DSBM clients) or the DSBMLogicalAddress (in case of DSBMs).
受管段（具有当前活动DSBM的段）上的所有DSBMs、SBM或DSBM客户端不得接受来自不了解SBM的发送方的路径消息。SBMs和DSBM客户端可以很容易地检测到来自此类设备的路径消息，因为它们不会多播到ALLSBMAddress（对于SBMs和DSBM客户端）或DSBMLogicalAddress（对于DSBMs）。
6.4. A non-SBM router that interconnects two DSBM-managed L2 domains.
6.4. 连接两个DSBM管理的L2域的非SBM路由器。
Multicast SBM messages (e.g., election and PATH messages) have local scope and are not intended to pass between the two domains. A correctly configured non-SBM router will not pass such messages between the domains. A broken router implementation that does so may cause incorrect operation of the SBM protocol and consequent over- or under-allocation of resources.
多播SBM消息（例如，选举和路径消息）具有本地作用域，不打算在两个域之间传递。正确配置的非SBM路由器不会在域之间传递此类消息。这样做的中断路由器实现可能会导致SBM协议的错误操作，并导致资源分配过度或不足。
6.5. Interoperability with RSVP clients that use UDP encapsulation and are not capable of receiving/sending RSVP messages using RAW_IP
6.5. 与使用UDP封装且不能使用原始IP接收/发送RSVP消息的RSVP客户端的互操作性
This document stipulates that DSBMs, DSBM clients, and SBMs use only raw IP for encapsulating RSVP messages that are forwarded onto a L2 domain. RFC-2205 (the RSVP Proposed Standard) includes support for both raw IP and UDP encapsulation. Thus, a RSVP node using only the UDP encapsulation will not be able to interoperate with the DSBM unless DSBM accepts and supports UDP encapsulated RSVP messages.
本文档规定DSBMs、DSBM客户端和SBM仅使用原始IP封装转发到L2域的RSVP消息。RFC-2205（RSVP建议的标准）包括对原始IP和UDP封装的支持。因此，仅使用UDP封装的RSVP节点将无法与DSBM进行互操作，除非DSBM接受并支持UDP封装的RSVP消息。
In the following, we provide guidelines for implementers on different aspects of the implementation of the SBM-based admission control procedure including suggestions for DSBM initialization, etc.
在下文中，我们就基于SBM的准入控制程序实施的不同方面为实施者提供指导，包括DSBM初始化建议等。
As stated earlier, DSBM initialization includes configuration of maximum bandwidth that can be reserved on a managed segment under its control. We suggest the following guideline.
如前所述，DSBM初始化包括可在其控制下的受管段上保留的最大带宽的配置。我们建议遵循以下准则。
In the case of a managed segment consisting of L2 devices interconnected by a single shared segment, DSBM entities on such devices should assume the bandwidth of the interface as the total link bandwidth. In the case of a DSBM located in a L2 switch, it might additionally need to be configured with an estimate of the device's switching capacity if that is less than the link bandwidth, and possibly with some estimate of the buffering resources of the switch (see [RFC-FRAME] for the architectural model assumed for L2 switches). Given the total link bandwidth, the DSBM may be further configured to limit the maximum amount of bandwidth for RSVP-enabled flows to ensure spare capacity for best-effort traffic.
对于由单个共享段互连的L2设备组成的受管段，此类设备上的DSBM实体应假定接口带宽为总链路带宽。在位于二级交换机中的DSBM的情况下，如果设备的交换容量小于链路带宽，则可能还需要对其进行配置，并且可能需要对交换机的缓冲资源进行一些估计（关于二级交换机假定的架构模型，请参阅[RFC-FRAME]）。给定总链路带宽，DSBM可进一步配置为限制启用RSVP的流的最大带宽量，以确保最大努力流量的备用容量。
Depending on a L2 topology, a DSBM may be called upon to manage resources for one or more segments and the implementers must bear in mind efficiency implications of the use of DSBM in different L2 topologies. Trivial L2 topologies consist of a single "physical segment". In this case, the 'managed segment' is equivalent to a single segment. Complex L2 topologies may consist of a number of Admission control on such an L2 extended segment can be performed from a single pool of resources, similar to a single shared segment, from the point of view of a single DSBM.
根据L2拓扑，可以调用DSBM来管理一个或多个段的资源，并且实现者必须牢记在不同L2拓扑中使用DSBM的效率影响。普通L2拓扑由单个“物理段”组成。在这种情况下，“托管段”相当于单个段。从单个DSBM的角度来看，复杂的L2拓扑可能包括对这样的L2扩展段的多个许可控制，这些许可控制可以从单个资源池执行，类似于单个共享段。
This configuration compromises the efficiency with which the DSBM can allocate resources. This is because the single DSBM is required to make admission control decisions for all reservation requests within the L2 topology, with no knowledge of the actual physical segments affected by the reservation.
这种配置会降低DSBM分配资源的效率。这是因为需要单个DSBM为L2拓扑内的所有保留请求做出接纳控制决策，而不知道受保留影响的实际物理段。
We can realize improvements in the efficiency of resource allocation by subdividing the complex segment into a number of managed segments, each managed by their own DSBM. In this case, each DSBM manages a managed segment having a relatively simple topology. Since managed segments are simpler, the DSBM can be configured with a more accurate estimate of the resources available for all reservations in the managed segment. In the ultimate configuration, each physical segment is a managed segment and is managed by its own DSBM. We make no assumption about the number of managed segments but state, simply, that in complex L2 topologies, the efficiency of resource allocation improves as the granularity of managed segments increases.
我们可以通过将复杂段细分为多个受管段，每个段由各自的DSBM管理，从而提高资源分配的效率。在这种情况下，每个DSBM管理一个具有相对简单拓扑的托管段。由于托管段比较简单，因此可以通过对托管段中所有预订可用资源的更准确估计来配置DSBM。在最终配置中，每个物理段都是一个托管段，由其自己的DSBM管理。我们对托管段的数量不做任何假设，但简单地说，在复杂的L2拓扑中，随着托管段粒度的增加，资源分配的效率会提高。
The message formatting and usage rules described in this note raise security issues, identical to those raised by the use of RSVP and Integrated Services. It is necessary to control and authenticate
本说明中描述的消息格式和使用规则会引发安全问题，这与使用RSVP和集成服务所引发的问题相同。有必要进行控制和验证
access to enhanced qualities of service enabled by the technology described in this RFC. This requirement is discussed further in [RFC-2205], [RFC-2211], and [RFC-2212].
通过本RFC中描述的技术，访问增强的服务质量。[RFC-2205]、[RFC-2211]和[RFC-2212]进一步讨论了该要求。
[RFC-RSVPMD5] describes the mechanism used to protect the integrity of RSVP messages carrying the information described here. A SBM implementation should satisfy the requirements of that RFC and provide the suggested mechanisms just as though it were a conventional RSVP implementation. It should further use the same mechanisms to protect the additional, SBM-specific objects in a message.
[RFC-RSVPMD5]描述了用于保护承载此处所述信息的RSVP消息完整性的机制。SBM实现应该满足RFC的要求，并提供建议的机制，就像它是传统的RSVP实现一样。它应该进一步使用相同的机制来保护消息中额外的、特定于SBM的对象。
Finally, it is also necessary to authenticate DSBM candidates during the election process, and a mechanism based on a shared secret among the DSBM candidates may be used. The mechanism defined in [RFC-RSVPMD5] should be used.
最后，还需要在选举过程中认证DSBM候选人，并且可以使用基于DSBM候选人之间的共享秘密的机制。应使用[RFC-RSVPMD5]中定义的机制。
[RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC 2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 2205，1997年9月。
[RFC-RSVPMD5] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC-RSVPMD5]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC 2206] Baker, F. and J. Krawczyk, "RSVP Management Information Base", RFC 2206, September 1997.
[RFC 2206]Baker，F.和J.Krawczyk，“RSVP管理信息库”，RFC 2206，1997年9月。
[RFC 2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC 2211]Wroclawski，J.“受控负荷网元服务规范”，RFC 2211，1997年9月。
[RFC 2212] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC 2212]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[RFC 2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[RFC 2215]Shenker，S.和J.Wroclawski，“综合业务网元的一般特征参数”，RFC 2215，1997年9月。
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC 2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC 2213] Baker, F. and J. Krawczyk, "Integrated Services Management Information Base", RFC 2213, September 1997.
[RFC 2213]Baker，F.和J.Krawczyk，“综合服务管理信息库”，RFC 2213，1997年9月。
[RFC-FRAME] Ghanwani, A., Pace, W., Srinivasan, V., Smith, A. and M.Seaman, "A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies", RFC 2816, May 2000.
[RFC-FRAME]Ghanwani，A.，Pace，W.，Srinivasan，V.，Smith，A.和M.Seaman，“通过共享和交换LAN技术提供综合服务的框架”，RFC 28162000年5月。
[RFC-MAP] Seaman, M., Smith, A. and E. Crawley, "Integrated Service Mappings on IEEE 802 Networks", RFC 2815, May 2000.
[RFC-MAP]Seaman，M.，Smith，A.和E.Crawley，“IEEE 802网络上的综合服务映射”，RFC 2815，2000年5月。
[IEEE802Q] "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", Draft Standard P802.1Q/D9, February 20, 1998.
[IEEE802Q]“局域网和城域网的IEEE标准：虚拟桥接局域网”，标准草案P802.1Q/D9，1998年2月20日。
[IEEEP8021p] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision (Incorporating IEEE P802.1p: Traffic Class Expediting and Dynamic Multicast Filtering)", ISO/IEC Final CD 15802-3 IEEE P802.1D/D15, November 24, 1997.
[IEEEP8021p]“信息技术-系统间电信和信息交换-局域网和城域网-通用规范-第3部分：媒体访问控制（MAC）网桥：修订版（包括IEEE P802.1p：流量等级加速和动态多播过滤）”，ISO/IEC最终CD 15802-3 IEEE P802.1D/D15，1997年11月24日。
[IEEE8021D] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993.
[IEEE8021D]“MAC网桥”，ISO/IEC 10038，ANSI/IEEE标准802.1D-1993。
To simplify the rest of this discussion, we will assume that there is a single DSBM for the entire L2 domain (i.e., assume a shared L2 segment for the entire L2 domain). Later, we will discuss how a DSBM is elected for a half-duplex or full-duplex switched segment.
为了简化本讨论的其余部分，我们将假设整个L2域有一个DSBM（即，假设整个L2域有一个共享的L2段）。稍后，我们将讨论如何为半双工或全双工交换段选择DSBM。
To allow for quick recovery from the failure of a DSBM, we assume that additional SBMs may be active in a L2 domain for fault tolerance. When more than one SBM is active in a L2 domain, the SBMs use an election algorithm to elect a DSBM for the L2 domain. After the DSBM is elected and is operational, other SBMs remain passive in the background to step in to elect a new DSBM when necessary. The protocol for electing and discovering DSBM is called the "DSBM election protocol" and is described in the rest of this Appendix.
为了允许从DSBM故障中快速恢复，我们假设在L2域中可能有其他SBM处于活动状态，以实现容错。当一个L2域中有多个SBM处于活动状态时，SBM使用选择算法为L2域选择DSBM。DSBM当选并投入运行后，其他SBM在后台保持被动，以便在必要时介入选举新的DSBM。选择和发现DSBM的协议称为“DSBM选择协议”，并在本附录的其余部分进行了描述。
Once elected, a DSBM periodically multicasts an I_AM_DSBM message on the AllSBMAddress to indicate its presence. The message is sent every period (e.g., every 5 seconds) according to the RefreshInterval timer value (a configuration parameter). Absence of such a message over a certain time interval (called "DSBMDeadInterval"; another configuration parameter typically set to a multiple of RefreshInterval) indicates that the DSBM has failed or terminated and triggers another round of the DSBM election. The DSBM clients always listen for periodic DSBM advertisements. The advertisement includes the unicast IP address of the DSBM (DSBMAddress) and DSBM clients send their PATH/RESV (or other) messages to the DSBM. When a DSBM client detects the failure of a DSBM, it waits for a subsequent I_AM_DSBM advertisement before resuming any communication with the DSBM. During the period when a DSBM is not present, a DSBM client may forward outgoing PATH messages using the standard RSVP forwarding rules.
一旦当选，DSBM会定期在AllSBMAddress上多播I_AM_DSBM消息，以表明其存在。根据RefreshInterval定时器值（配置参数），每段时间（例如，每5秒）发送一次消息。在特定时间间隔内（称为“DSBMDeadInterval”；另一个配置参数通常设置为RefreshInterval的倍数）没有此类消息表示DSBM失败或终止，并触发另一轮DSBM选择。DSBM客户端始终侦听定期的DSBM播发。播发包括DSBM的单播IP地址（DSBMAddress），DSBM客户端将其PATH/RESV（或其他）消息发送到DSBM。当DSBM客户端检测到DSBM故障时，它将等待后续I_AM_DSBM播发，然后再恢复与DSBM的任何通信。在DSBM不存在期间，DSBM客户端可以使用标准RSVP转发规则转发传出路径消息。
The exact message formats and addresses used for communication with (and among) SBM(s) are described in Appendix B.
附录B中描述了用于与SBM（以及SBM之间）通信的确切消息格式和地址。
When a SBM first starts up, it listens for incoming DSBM advertisements for some period to check whether a DSBM already exists in its L2 domain. If one already exists (and no new election is in progress), the new SBM stays quiet in the background until an election of DSBM is necessary. All messages related to the DSBM election and DSBM advertisements are always sent to the AllSBMAddress.
当SBM首次启动时，它会在一段时间内侦听传入的DSBM播发，以检查DSBM是否已存在于其L2域中。如果已经存在一个（并且没有进行新的选举），新的SBM将保持沉默，直到有必要选举DSBM。与DSBM选举和DSBM广告相关的所有消息始终发送到AllsBM地址。
If no DSBM exists, the SBM initiates the election of a DSBM by sending out a DSBM_WILLING message that lists its IP address as a candidate DSBM and its "SBM priority". Each SBM is assigned a priority to determine its relative precedence. When more than one SBM candidate exists, the SBM priority determines who gets to be the DSBM based on the relative priority of candidates. If there is a tie based on the priority value, the tie is broken using the IP addresses of tied candidates (one with the higher IP address in the lexicographic order wins). The details of the election protocol start in Section A.4.
如果不存在DSBM，则SBM通过发送一条DSBM意愿消息来启动DSBM的选择，该消息将其IP地址列为候选DSBM及其“SBM优先级”。为每个SBM分配一个优先级，以确定其相对优先级。当存在多个SBM候选者时，SBM优先级根据候选者的相对优先级确定谁将成为DSBM。如果存在基于优先级值的平局，则使用平局候选的IP地址打破平局（在字典顺序中IP地址较高的一个获胜）。选举协议的细节从A.4节开始。
For the purpose of the algorithm, a SBM is in one of the four states (Idle, DetectDSBM, ElectDSBM, IAMDSBM).
就算法而言，SBM处于四种状态之一（空闲、检测到的SBM、选择的DSBM、IAMDSBM）。
A SBM (call it X) starts up in the DetectDSBM state and waits for a ListenInterval for incoming I_AM_DSBM (DSBM advertisement) or DSBM_WILLING messages. If an I_AM_DSBM advertisement is received during this state, the SBM notes the current DSBM (its IP address and priority) and enters the Idle state. If a DSBM_WILLING message is received from another SBM (call it Y) during this state, then X enters the ElectDSBM state. Before entering the new state, X first checks to see whether it itself is a better candidate than Y and, if so, sends out a DSBM_WILLING message and then enters the ElectDSBM state.
SBM（称为X）在DetectDSBM状态下启动，并等待接收到的I_AM_DSBM（DSBM广告）或DSBM自愿消息的ListentServal。如果在此状态期间收到I_AM_DSBM播发，SBM将记录当前DSBM（其IP地址和优先级）并进入空闲状态。如果在此状态期间从另一个SBM（称为Y）接收到DSBM意愿消息，则X进入SelectDSBM状态。在进入新状态之前，X首先检查其本身是否比Y更好，如果是，则发送DSBM_意愿消息，然后进入SelectDSBM状态。
When a SBM (call it X) enters the ElectDSBM state, it sets a timer (called ElectionIntervalTimer, and typically set to a value at least equal to the DSBMDeadInterval value) to wait for the election to finish and to discover who is the best candidate. In this state, X keeps track of the best (or better) candidate seen so far (including itself). Whenever it receives another DSBM_WILLING message it updates its notion of the best (or better) candidate based on the priority (and tie-breaking) criterion. During the ElectionInterval, X sends out a DSBM_WILLING message every RefreshInterval to (re)assert its candidacy.
当SBM（称为X）进入SelectDSBM状态时，它会设置一个计时器（称为ElectionIntervalTimer，通常设置为至少等于DSBMDeadInterval值的值），以等待选举结束并发现谁是最佳候选人。在这种状态下，X跟踪到目前为止看到的最佳（或更好）候选对象（包括它自己）。每当它收到另一条DSBM_意愿消息时，它都会根据优先级（和打破平局）标准更新其最佳（或更好）候选者的概念。在选举期间，X每隔一个刷新间隔发送一条DSBM_意愿消息，以（重新）断言其候选资格。
At the end of the ElectionInterval, X checks whether it is the best candidate so far. If so, it declares itself to be the DSBM (by sending out the I_AM_DSBM advertisement) and enters the IAMDSBM state; otherwise, it decides to wait for the best candidate to declare itself the winner. To wait, X re-initializes its ElectDSBM state and continues to wait for another round of election (each round lasts for an ElectionTimerInterval duration).
在选举间隔结束时，X检查它是否是迄今为止最好的候选人。如果是，则声明自己是DSBM（通过发送I_AM_DSBM广告），并进入IAMDSBM状态；否则，它决定等待最佳候选人宣布自己为获胜者。要等待，X将重新初始化其SelectDSBM状态，并继续等待另一轮选举（每轮选举持续一个ElectionTimerInterval持续时间）。
A SBM is in Idle state when no election is in progress and the DSBM is already elected (and happens to be someone else). In this state, it listens for incoming I_AM_DSBM advertisements and uses a DSBMDeadIntervalTimer to detect the failure of DSBM. Every time the advertisement is received, the timer is restarted. If the timer fires, the SBM goes into the DetectDSBM state to prepare to elect the new DSBM. If a SBM receives a DSBM_WILLING message from the current DSBM in this state, the SBM enters the ElectDSBM state after sending out a DSBM_WILLING message (to announce its own candidacy).
当没有选举正在进行且DSBM已经被选举（并且碰巧是其他人）时，SBM处于空闲状态。在此状态下，它侦听传入的I_AM_DSBM播发，并使用DSBMDeadIntervalTimer检测DSBM的故障。每次收到广告时，计时器都会重新启动。如果定时器触发，SBM进入DetectDSBM状态，准备选择新DSBM。如果SBM在此状态下收到来自当前DSBM的DSBM意愿消息，则SBM在发送DSBM意愿消息（以宣布其自己的候选资格）后进入SelectDSBM状态。
In the IAMDSBM state, the DSBM sends out I_AM_DSBM advertisements every refresh interval. If the DSBM wishes to shut down (gracefully terminate), it sends out a DSBM_WILLING message (with SBM priority value set to zero) to initiate the election procedure. The priority value zero effectively removes the outgoing DSBM from the election procedure and makes way for the election of a different DSBM.
在IAMDSBM状态下，DSBM在每个刷新间隔发送I_AM_DSBM播发。如果DSBM希望关闭（正常终止），它将发送一条DSBM意愿消息（SBM优先级值设置为零）以启动选择程序。优先级值0有效地将传出DSBM从选择过程中移除，并为选择不同的DSBM让路。
When a DSBM fails (DSBMDeadIntervalTimer fires), all the SBMs enter the ElectDSBM state and start the election process.
当DSBM失败（DSBMDeadIntervalTimer触发）时，所有SBM都会进入SelectDSBM状态并启动选择过程。
At the end of the ElectionInterval, the elected DSBM sends out an I_AM_DSBM advertisement and the DSBM is then operational.
在选举间隔结束时，当选的DSBM发送I_AM_DSBM广告，然后DSBM开始运行。
The I_AM_DSBM advertisement contains the following information:
I_AM_DSBM广告包含以下信息：
1. DSBM address information -- contains the IP and L2 addresses of the DSBM and its SBM priority (a configuration parameter -- priority specified by a network administrator). The priority value is used to choose among candidate SBMs during the election algorithm. Higher integer values indicate higher priority and the value is in the range 0..255. The value zero indicates that the SBM is not eligible to be the DSBM. The IP address is required and used for breaking ties. The L2 address is for the interface of the managed segment.
1. DSBM地址信息——包含DSBM的IP和L2地址及其SBM优先级（配置参数——网络管理员指定的优先级）。优先级值用于在选举算法期间在候选SBM之间进行选择。整数值越高表示优先级越高，且该值的范围为0..255。值为零表示SBM没有资格成为DSBM。IP地址是必需的，用于断开连接。L2地址用于托管段的接口。
2. RegreshInterval -- contains the value of RefreshInterval in seconds. Value zero indicates the parameter has been omitted in the message. Receivers may substitute their own default value in this case.
2. RegreshInterval--包含RefreshInterval的值（以秒为单位）。值零表示消息中省略了参数。在这种情况下，接收者可以替换他们自己的默认值。
3. DSBMDeadInterval -- contains the value of DSBMDeadInterval in seconds. If the value is omitted (or value zero is specified), a default value (from initial configuration) should be used.
3. DSBMDeadInterval--包含以秒为单位的DSBMDeadInterval值。如果省略该值（或指定值零），则应使用默认值（来自初始配置）。
4. Miscellaneous configuration information to be advertised to senders on the managed segment. See Appendix C for further details.
4. 要在托管段上通告给发件人的其他配置信息。详见附录C。
When a SBM wishes to declare its candidacy to be the DSBM during an election phase, it sends out a DSBM_WILLING message. The DSBM_WILLING message contains the following information:
当SBM希望在选举阶段宣布其为DSBM候选人时，它会发出DSBM意愿信息。DSBM_意愿消息包含以下信息：
1. DSBM address information -- Contains the SBM's own addresses (IP and L2 address), if it wishes to be the DSBM. The IP address is required and used for breaking ties. The L2 address is the address of the interface for the managed segment in question. Also, the DSBM address information includes the corresponding priority of the SBM whose address is given above.
1. DSBM地址信息——如果希望成为DSBM，则包含SBM自己的地址（IP和L2地址）。IP地址是必需的，用于断开连接。L2地址是相关托管段的接口地址。此外，DSBM地址信息包括其地址在上面给出的SBM的相应优先级。
For each network interface, a SBM maintains the following state variables related to the election of the DSBM for the L2 domain on that interface:
对于每个网络接口，SBM维护与该接口上L2域DSBM选择相关的以下状态变量：
a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, 0.0.0.0) and priority. All IP addresses are assumed to be in network byte order. In addition, current DSBM's L2 address is also stored as part of this state information.
a) LocalDSBMAddrInfo—当前DSBM的IP地址（最初为0.0.0.0）和优先级。假设所有IP地址都是按网络字节顺序排列的。此外，当前DSBM的L2地址也存储为该状态信息的一部分。
b) OwnAddrInfo -- SBM's own IP address and L2 address for the interface and its own priority (a configuration parameter).
b) OwnAddrInfo——SBM自己的IP地址和接口的L2地址及其自己的优先级（配置参数）。
c) RefreshInterval in seconds. When the DSBM is not yet elected, it is set to a default value specified as a configuration parameter.
c) 刷新间隔（秒）。如果尚未选择DSBM，则将其设置为作为配置参数指定的默认值。
d) DSBMDeadInterval in seconds. When the DSBM is not yet elected, it is initially set to a default value specified as a configuration parameter.
d) DSBMDeadInterval，以秒为单位。当尚未选择DSBM时，它最初设置为作为配置参数指定的默认值。
f) ListenInterval in seconds -- a configuration parameter that decides how long a SBM spends in the DetectDSBM state (see below).
f) ListentInterval（以秒为单位）——一个配置参数，决定SBM在DetectDSBM状态下花费的时间（见下文）。
g) ElectionInterval in seconds -- a configuration parameter that decides how long a SBM spends in the ElectDSBM state when it has declared its candidacy.
g) ElectionInterval（以秒为单位）——一个配置参数，用于确定SBM在宣布其候选资格后处于ElectDSBM状态的时间。
Figure 3 shows the state transition diagram for the election protocol and the various states are described below. A complete description of the state machine is provided in Section A.10.
图3显示了选举协议的状态转换图，下面描述了各种状态。第A.10节提供了状态机的完整描述。
DOWN -- SBM is not operational.
停机——SBM不工作。
DetectDSBM -- typically, the initial state of a SBM when it starts up. In this state, it checks to see whether a DSBM already exists in its domain.
DetectDSBM——通常是SBM启动时的初始状态。在此状态下，它将检查DSBM是否已存在于其域中。
Idle -- SBM is in this state when no election is in progress and it is not the DSBM. In this state, SBM passively monitors the state of the DSBM.
Idle——当没有进行选举且不是DSBM时，SBM处于这种状态。在此状态下，SBM被动监视DSBM的状态。
ElectDSBM -- SBM is in this state when a DSBM election is in progress.
SelectDSBM——当DSBM选举正在进行时，SBM处于此状态。
IAMDSBM -- SBM is in this state when it is the DSBM for the L2 domain.
IAMDSBM——SBM是L2域的DSBM时处于此状态。
StartUp -- SBM starts operation.
启动——SBM启动操作。
ListenInterval Timeout -- The ListenInterval timer has fired. This means that the SBM has monitored its domain to check for an existing DSBM or to check whether there are candidates (other than itself) willing to be the DSBM.
ListenInterval超时--ListenInterval计时器已启动。这意味着SBM已监控其域，以检查现有DSBM或检查是否存在愿意成为DSBM的候选者（自身除外）。
DSBM_WILLING message received -- This means that the SBM received a DSBM_WILLING message from some other SBM. Such a message is sent when a SBM wishes to declare its candidacy to be the DSBM.
收到DSBM_意愿消息——这意味着SBM从其他SBM收到了DSBM_意愿消息。当SBM希望宣布其为DSBM候选人时，发送此类信息。
I_AM_DSBM message received -- SBM received a DSBM advertisement from the DSBM in its L2 domain.
收到I_AM_DSBM消息——SBM从其L2域中的DSBM接收到DSBM播发。
DSBMDeadInterval Timeout -- The DSBMDeadIntervalTimer has fired. This means that the SBM did not receive even one DSBM advertisement during this period and indicates possible failure of the DSBM.
DSBMDeadInterval超时—DSBMDeadIntervalTimer已启动。这意味着SBM在此期间甚至没有收到一个DSBM播发，并表示DSBM可能出现故障。
RefreshInterval Timeout -- The RefreshIntervalTimer has fired. In the IAMDSBM state, this means it is the time for sending out the next DSBM advertisement. In the ElectDSBM state, the event means that it is the time to send out another DSBM_WILLING message.
RefreshInterval超时--RefreshIntervalTimer已启动。在IAMDSBM状态下，这意味着是发送下一个DSBM广告的时间。在SelectDSBM状态下，事件意味着是时候发送另一条DSBM消息了。
ElectionInterval Timeout -- The ElectionIntervalTimer has fired. This means that the SBM has waited long enough after declaring its candidacy to determine whether or not it succeeded.
ElectionInterval超时--ElectionInterval计时器已启动。这意味着SBM在宣布其候选资格后等待了足够长的时间，以确定其是否成功。
+-----------+
+--<--------------<-|DetectDSBM |---->------+
| +-----------+ |
| |
| |
| |
| +-------------+ +---------+ |
+->---| Idle |--<>---|ElectDSBM|--<--+
+-------------+ +---------+
| |
| |
| |
| +-----------+ |
+<<- +---| IAMDSBM |-<-+
| +-----------+
|
| +-----------+
+>>-| SHUTDOWN |
+-----------+
+-----------+
+--<--------------<-|DetectDSBM |---->------+
| +-----------+ |
| |
| |
| |
| +-------------+ +---------+ |
+->---| Idle |--<>---|ElectDSBM|--<--+
+-------------+ +---------+
| |
| |
| |
| +-----------+ |
+<<- +---| IAMDSBM |-<-+
| +-----------+
|
| +-----------+
+>>-| SHUTDOWN |
+-----------+
Based on the events and states described above, the state changes at a SBM are described below. Each state change is triggered by an event and is typically accompanied by a sequence of actions. The state machine is described assuming a single threaded implementation (to avoid race conditions between state changes and timer events) with no timer events occurring during the execution of the state machine.
基于上述事件和状态，下面描述SBM处的状态改变。每个状态更改都由事件触发，通常伴随着一系列操作。状态机描述为假设在状态机执行期间没有发生计时器事件的单线程实现（以避免状态更改和计时器事件之间的争用条件）。
The following routines will be frequently used in the description of the state machine:
在状态机的描述中将经常使用以下例程：
ComparePrio(FirstAddrInfo, SecondAddrInfo) -- determines whether the entity represented by the first parameter is better than the second entity using the priority information and the IP address information in the two parameters. If any address is zero, that entity automatically loses; then first priorities are compared; higher priority candidate wins. If there is a tie based on the priority value, the tie is broken using the IP addresses of tied candidates (one with the higher IP address in the lexicographic order wins). Returns TRUE if first entity is a better choice. FALSE otherwise.
ComparePrio（FirstAddrInfo，SecondAddrInfo）——使用两个参数中的优先级信息和IP地址信息确定第一个参数表示的实体是否优于第二个实体。如果任何地址为零，则该实体自动丢失；然后比较第一优先级；优先级较高的候选人获胜。如果存在基于优先级值的平局，则使用平局候选的IP地址打破平局（在字典顺序中IP地址较高的一个获胜）。如果第一个实体是更好的选择，则返回TRUE。否则就错了。
SendDSBMWilling Message() Begin Send out DSBM_WILLING message listing myself as a candidate for DSBM (copy OwnAddr and priority into appropriate fields) start RefreshIntervalTimer goto ElectDSBM state End
SendDSBMWill Message（）开始发送DSBM_Will Message，将自己列为DSBM的候选对象（将OwnAddr和优先级复制到相应字段）开始刷新IntervalTimer转到选择DSBM状态结束
AmIBetterDSBM(OtherAddrInfo) Begin if (ComparePrio(OwnAddrInfo, OtherAddrInfo)) return TRUE
如果（ComparePrio（OwnAddrInfo，OtherAddrInfo））返回TRUE，则AmIBetterDSBM（OtherAddrInfo）开始
change LocalDSBMInfo = OtherDSBMAddrInfo return FALSE End
更改LocalDSBMInfo=OtherDSBMAddrInfo返回FALSE End
UpdateDSBMInfo()
/* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */
Begin
update LocalDSBMInfo such as IP addr, DSBM L2 address,
DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer
End
UpdateDSBMInfo()
/* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */
Begin
update LocalDSBMInfo such as IP addr, DSBM L2 address,
DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer
End
In the following, the action "continue" or "continue in current state" means an "exit" from the current action sequence without a state transition.
在下文中，动作“继续”或“在当前状态下继续”意味着在不进行状态转换的情况下从当前动作序列中“退出”。
State: DOWN Event: StartUp New State: DetectDSBM Action: Initialize the local state variables (LocalDSBMADDR and LocalDSBMAddrInfo set to 0). Start the ListenIntervalTimer.
状态：关闭事件：启动新状态：DetectDSBM操作：初始化本地状态变量（LocalDSBMADDR和LocalDSBMAddrInfo设置为0）。启动ListentServatimer。
State: DetectDSBM New State: Idle Event: I_AM_DSBM message received Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo start DeadDSBMInterval timer goto Idle State
状态：DetectDSBM新状态：空闲事件：I_AM_DSBM消息已接收操作：将LocalDSBMAddrInfo=IncomingDSBMAddrInfo启动死区DSBMInterval计时器转到空闲状态
State: DetectDSBM Event: ListenIntervalTimer fired New State: ElectDSBM Action: Start ElectionIntervalTimer SendDSBMWillingMessage();
状态：DetectDSBM事件：ListentServatimer已启动新状态：ElectDSBM操作：启动ElectionIntervalTimer SendDSBMWillingMessage（）；
State: DetectDSBM Event: DSBM_WILLING message received New State: ElectDSBM Action: Cancel any active timers
状态：DetectDSBM事件：DSBM_意愿消息收到新状态：SelectDSBM操作：取消任何活动计时器
Start ElectionIntervalTimer
/* am I a better choice than this dude? */
If (ComparePrio(OwnAddrInfo, IncomingDSBMInfo)) {
/* I am better */
SendDSBMWillingMessage()
} else {
Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo
goto ElectDSBM state
}
Start ElectionIntervalTimer
/* am I a better choice than this dude? */
If (ComparePrio(OwnAddrInfo, IncomingDSBMInfo)) {
/* I am better */
SendDSBMWillingMessage()
} else {
Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo
goto ElectDSBM state
}
State: Idle Event: DSBMDeadIntervalTimer fired. New State: ElectDSBM Action: start ElectionIntervalTimer set LocalDSBMAddrInfo = OwnAddrInfo SendDSBMWiliingMessage()
状态：空闲事件：DSBMDeadIntervalTimer已激发。新状态：ElectDSBM操作：启动ElectionIntervalTimer设置LocalDSBMAddrInfo=OwnAddrInfo SendDSBMWiliingMessage（）
State: Idle
Event: I_AM_DSBM message received.
New State: Idle
Action: /* first check whether anything has changed */
if (!ComparePrio(LocalDSBMAddrInfo, IncomingDSBMAddrInfo))
change LocalDSBMAddrInfo to reflect new info
endif
restart DSBMDeadIntervalTimer;
continue in current state;
State: Idle
Event: I_AM_DSBM message received.
New State: Idle
Action: /* first check whether anything has changed */
if (!ComparePrio(LocalDSBMAddrInfo, IncomingDSBMAddrInfo))
change LocalDSBMAddrInfo to reflect new info
endif
restart DSBMDeadIntervalTimer;
continue in current state;
State: Idle
Event: DSBM_WILLING Message is received
New State: Depends on action (ElectDSBM or Idle)
Action: /* check whether it is from the DSBM itself (shutdown) */
if (IncomingDSBMAddr == LocalDSBMAddr) {
cancel active timers
Set LocalDSBMAddrInfo = OwnAddrInfo
Start ElectionIntervalTimer
SendDSBMWillingMessage() /* goto ElectDSBM state */
}
State: Idle
Event: DSBM_WILLING Message is received
New State: Depends on action (ElectDSBM or Idle)
Action: /* check whether it is from the DSBM itself (shutdown) */
if (IncomingDSBMAddr == LocalDSBMAddr) {
cancel active timers
Set LocalDSBMAddrInfo = OwnAddrInfo
Start ElectionIntervalTimer
SendDSBMWillingMessage() /* goto ElectDSBM state */
}
/* else, ignore it */
continue in current state
/* else, ignore it */
continue in current state
State: ElectDSBM Event: ElectionIntervalTimer Fired
状态：ElectDSBM事件：ElectionIntervalTimer已启动
New State: depends on action (IAMDSBM or Current State)
Action: If (LocalDSBMAddrInfo == OwnAddrInfo) {
/* I won */
send I_AM_DSBM message
start RefreshIntervalTimer
goto IAMDSBM state
} else { /* someone else won, so wait for it to declare
itself to be the DSBM */
set LocalDSBMAddressInfo = OwnAddrInfo
start ElectionIntervalTimer
SendDSBMWillingMessage()
continue in current state
}
New State: depends on action (IAMDSBM or Current State)
Action: If (LocalDSBMAddrInfo == OwnAddrInfo) {
/* I won */
send I_AM_DSBM message
start RefreshIntervalTimer
goto IAMDSBM state
} else { /* someone else won, so wait for it to declare
itself to be the DSBM */
set LocalDSBMAddressInfo = OwnAddrInfo
start ElectionIntervalTimer
SendDSBMWillingMessage()
continue in current state
}
State: ElectDSBM Event: I_AM_DSBM message received New State: Idle Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo Cancel any active timers start DeadDSBMInterval timer goto Idle State
状态：ElectDSBM事件：I_AM_DSBM消息收到新状态：空闲操作：设置LocalDSBMAddrInfo=IncomingDSBMAddrInfo取消任何活动计时器启动死机DSBMInterval计时器转到空闲状态
State: ElectDSBM
Event: DSBM_WILLING message received
New State: ElectDSBM
Action: Check whether it's a loopback and if so, discard, continue;
if (!AmIBetterDSBM(IncomingDSBMAddrInfo)) {
Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo
Cancel RefreshIntervalTimer
} else if (LocalDSBMAddrInfo == OwnAddrInfo) {
SendDSBMWillingMessage()
}
continue in current state
State: ElectDSBM
Event: DSBM_WILLING message received
New State: ElectDSBM
Action: Check whether it's a loopback and if so, discard, continue;
if (!AmIBetterDSBM(IncomingDSBMAddrInfo)) {
Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo
Cancel RefreshIntervalTimer
} else if (LocalDSBMAddrInfo == OwnAddrInfo) {
SendDSBMWillingMessage()
}
continue in current state
State: ElectDSBM
Event: RefreshIntervalTimer fired
New State: ElectDSBM
Action: /* continue to send DSBMWilling messages until
election interval ends */
SendDSBMWillingMessage()
State: ElectDSBM
Event: RefreshIntervalTimer fired
New State: ElectDSBM
Action: /* continue to send DSBMWilling messages until
election interval ends */
SendDSBMWillingMessage()
State: IAMDSBM
Event: DSBM_WILLING message received
New State: depends on action (IAMDSBM or SteadyState)
Action: /* check whether other guy is better */
If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) {
/* I am better */
send I_AM_DSBM message
State: IAMDSBM
Event: DSBM_WILLING message received
New State: depends on action (IAMDSBM or SteadyState)
Action: /* check whether other guy is better */
If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) {
/* I am better */
send I_AM_DSBM message
restart RefreshIntervalTimer
continue in current state
} else {
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto SteadyState
}
restart RefreshIntervalTimer
continue in current state
} else {
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto SteadyState
}
State: IAMDSBM Event: RefreshIntervalTimer fired New State: IAMDSBM Action: send I_AM_DSBM message restart RefreshIntervalTimer
状态：IAMDSBM事件：RefreshIntervalTimer已启动新状态：IAMDSBM操作：发送I_AM_DSBM消息重新启动RefreshIntervalTimer
State: IAMDSBM
Event: I_AM_DSBM message received
New State: depends on action (IAMDSBM or Idle)
Action: /* check whether other guy is better */
If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) {
/* I am better */
send I_AM_DSBM message
restart RefreshIntervalTimer
continue in current state
} else {
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto Idle State
}
State: IAMDSBM
Event: I_AM_DSBM message received
New State: depends on action (IAMDSBM or Idle)
Action: /* check whether other guy is better */
If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) {
/* I am better */
send I_AM_DSBM message
restart RefreshIntervalTimer
continue in current state
} else {
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto Idle State
}
State: IAMDSBM Event: Want to shut myself down New State: DOWN Action: send DSBM_WILLING message with My address filled in, but priority set to zero goto Down State
状态：IAMDSBM事件：要关闭自己新状态：关闭操作：发送DSBM_意愿消息并填写我的地址，但优先级设置为零转到关闭状态
To avoid DSBM outages for long period, to ensure quick recovery from DSBM failures, and to avoid timeout of PATH and RESV state at the edge devices, we suggest the following values for various timers.
为避免DSBM长时间停机，确保从DSBM故障中快速恢复，并避免边缘设备的路径超时和RESV状态，我们建议为各种计时器设置以下值。
Assuming that the RSVP implementations use a 30 second timeout for PATH and RESV refreshes, we suggest that the RefreshIntervalTimer should be set to about 5 seconds with DSBMDeadIntervalTimer set to 15 seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be set
假设RSVP实现对PATH和RESV刷新使用30秒超时，我们建议将RefreshIntervalTimer设置为约5秒，将DSBMDeadIntervalTimer设置为15秒（K=3，K*RefreshInterval）。应设置DetectDSBMTimer
to a random value between (DSBMDeadIntervalTimer, 2*DSBMDeadIntervalTimer). The ElectionIntervalTimer should be set at least to the value of DSBMDeadIntervalTimer to ensure that each SBM has a chance to have its DSBM_WILLING message (sent every RefreshInterval in ElectDSBM state) delivered to others.
到之间的随机值（DSBMDeadIntervalTimer，2*DSBMDeadIntervalTimer）。ElectionIntervalTimer应至少设置为DSBMDeadIntervalTimer的值，以确保每个SBM都有机会将其愿意发送的DSBM消息（在ElectionDSBM状态下，每个刷新间隔发送一次）传递给其他SBM。
Network administrators should configure SBM protocol entity at each SBM-capable device with the device's "SBM priority" for each of the interfaces attached to a managed segment. SBM_PRIORITY is an 8-bit, unsigned integer value (in the range 0-255) with higher integer values denoting higher priority. The value zero for an interface indicates that the SBM protocol entity on the device is not eligible to be a DSBM for the segment attached to the interface.
网络管理员应在每个支持SBM的设备上配置SBM协议实体，并为连接到受管段的每个接口配置设备的“SBM优先级”。SBM_优先级是一个8位无符号整数值（范围为0-255），更高的整数值表示更高的优先级。接口的值为零表示设备上的SBM协议实体没有资格成为连接到接口的段的DSBM。
A separate range of values is reserved for each type of SBM-capable device to reflect the relative priority among different classes of L2/L3 devices. L2 devices get higher priority followed by routers followed by hosts. The priority values in the range of 128..255 are reserved for L2 devices, the values in the range of 64..127 are reserved for routers, and values in the range of 1..63 are reserved for hosts.
为每种支持SBM的设备保留单独的值范围，以反映不同类别的L2/L3设备之间的相对优先级。L2设备获得更高的优先级，其次是路由器，然后是主机。128..255范围内的优先级值为二级设备保留，64..127范围内的优先级值为路由器保留，1..63范围内的优先级值为主机保留。
The election algorithm works as described before in this case except each SBM-capable L2 device restricts the scope of the election to its local segment. As described in Section B.1 below, all messages related to the DSBM election are sent to a special multicast address (AllSBMAddress). AllSBMAddress (its corresponding MAC multicast address) is configured in the permanent database of SBM-capable, layer 2 devices so that all frames with AllSBMAddress as the destination address are not forwarded and instead directed to the SBM management entity in those devices. Thus, a DSBM can be elected separately on each point-to-point segment in a switched topology. For example, in Figure 2, DSBM for "segment A" will be elected using the election algorithm between R1 and S1 and none of the election-related messages on this segment will be forwarded by S1 beyond "segment A". Similarly, a separate election will take place on each segment in this topology.
在这种情况下，选择算法如前所述工作，除了每个支持SBM的L2设备将选择范围限制在其本地段之外。如下面第B.1节所述，所有与DSBM选择相关的消息都被发送到一个特殊的多播地址（AllSBMAddress）。AllSBMAddress（其对应的MAC多播地址）在支持SBM的第2层设备的永久数据库中配置，以便所有以AllSBMAddress作为目标地址的帧不会被转发，而是被定向到这些设备中的SBM管理实体。因此，可以在交换拓扑中的每个点到点段上分别选择DSBM。例如，在图2中，“段A”的DSBM将使用R1和S1之间的选择算法进行选择，并且此段上的任何与选择相关的消息都不会被S1转发到“段A”之外。类似地，将在该拓扑中的每个段上进行单独的选举。
When a switched segment is a half-duplex segment, two senders (one sender at each end of the link) share the link. In this case, one of the two senders will win the DSBM election and will be responsible for managing the segment.
当交换段是半双工段时，两个发送方（链路两端各有一个发送方）共享链路。在这种情况下，两个发件人中的一个将赢得DSBM选举，并负责管理该段。
If a switched segment is full-duplex, exactly one sender sends on the link in each direction. In this case, either one or two DSBMs can exist on such a managed segment. If a sender at each end wishes to serve as a DSBM for that end, it can declare itself to be the DSBM by sending out an I_AM_DSBM advertisement and start managing the resources for the outgoing traffic over the segment. If one of the two senders does not wish itself to be the DSBM, then the other DSBM will not receive any DSBM advertisement from its peer and assume itself to be the DSBM for traffic traversing in both directions over the managed segment.
如果交换段是全双工的，则在链路上每个方向上只有一个发送方发送。在这种情况下，一个或两个DSBMs可以存在于这样一个受管段上。如果每一端的发送方希望充当该端的DSBM，则它可以通过发送I_AM_DSBM广告来声明自己是DSBM，并开始管理该段上传出流量的资源。如果两个发送方中的一个不希望自己是DSBM，则另一个DSBM将不会从其对等方接收任何DSBM播发，并假定自己是DSBM，用于在受管段上双向传输流量。
Appendix B Message Encapsulation and Formats
附录B消息封装和格式
To minimize changes to the existing RSVP implementations and to ensure quick deployment of a SBM in conjunction with RSVP, all communication to and from a DSBM will be performed using messages constructed using the current rules for RSVP message formats and raw IP encapsulation. For more details on the RSVP message formats, refer to the RSVP specification (RFC 2205). No changes to the RSVP message formats are proposed, but new message types and new L2-specific objects are added to the RSVP message formats to accommodate DSBM-related messages. These additions are described below.
为了尽量减少对现有RSVP实施的更改，并确保SBM与RSVP的快速部署，所有与DSBM之间的通信都将使用使用RSVP消息格式和原始IP封装的当前规则构造的消息来执行。有关RSVP消息格式的更多详细信息，请参阅RSVP规范（RFC 2205）。未提议对RSVP消息格式进行任何更改，但在RSVP消息格式中添加了新的消息类型和新的L2特定对象，以适应DSBM相关消息。这些新增内容如下所述。
For the purpose of DSBM election and detection, AllSBMAddress is used as the destination address while sending out both DSBM_WILLING and I_AM_DSBM messages. A DSBM client first detects a managed segment by listening to I_AM_DSBM advertisements and records the DSBMAddress (unicast IP address of the DSBM).
出于DSBM选择和检测的目的，在发送DSBM_-will和I_-AM_-DSBM消息时，将AllSBMAddress用作目标地址。DSBM客户端首先通过侦听I_AM_DSBM播发来检测托管段，并记录DSBMAddress（DSBM的单播IP地址）。
Each message must occupy exactly one IP datagram. If it exceeds the MTU, such a datagram will be fragmented by IP and reassembled at the recipient node. This has a consequence that a single message may not exceed the maximum IP datagram size, approximately 64K bytes.
每条消息必须正好占用一个IP数据报。如果超过MTU，这样的数据报将被IP分割并在接收方节点重新组装。这导致单个消息可能不会超过最大IP数据报大小（约64K字节）。
All RSVP messages directed to and from a DSBM may contain various RSVP objects defined in the RSVP specification and messages continue to follow the formatting rules specified in the RSVP specification. In addition, an RSVP implementation must also recognize new object classes that are described below.
所有指向和来自DSBM的RSVP消息可能包含RSVP规范中定义的各种RSVP对象，并且消息继续遵循RSVP规范中指定的格式规则。此外，RSVP实现还必须识别下面描述的新对象类。
All objects are defined using the format specified in the RSVP specification. Each object has a 32-bit header that contains length (of the object in bytes including the object header), the object class number, and a C-Type. All unused fields should be set to zero and ignored on receipt.
所有对象都使用RSVP规范中指定的格式定义。每个对象都有一个32位标头，其中包含长度（以字节为单位，包括对象标头）、对象类编号和C类型。所有未使用的字段应设置为零，并在收到时忽略。
Note that the Class-Num values for the SBM specific objects (LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2) are chosen from the codespace 10XXXXXX. This coding assures that non-SBM aware RSVP nodes will ignore the objects without forwarding them or generating an error message.
请注意，SBM特定对象（LAN_NHOP、LAN_环回和RSVP_HOP_L2）的类Num值是从代码空间10XXXXXX中选择的。此编码确保非SBM感知的RSVP节点将忽略对象，而不会转发它们或生成错误消息。
Within the SBM specific codespace, note the following interpretation of the third most significant bit of the Class-Num:
在SBM特定的代码空间中，注意以下对类Num的第三高有效位的解释：
a) Objects of the form 100XXXXX are to be silently discarded by SBM nodes that do not recognize them.
a) 形式为100XXXXX的对象将被不识别它们的SBM节点以静默方式丢弃。
b) Objects of the form 101XXXXX are to be silently forwarded by SBM nodes that do not recognize them.
b) 101XXXXX形式的对象将由不识别它们的SBM节点静默转发。
The 48-bit MAC Addresses used by IEEE 802 were originally defined in terms of wire order transmission of bits in the source and destination MAC address fields. The same wire order applied to both Ethernet and Token Ring. Since the bit transmission order of Ethernet and Token Ring data differ - Ethernet octets are transmitted least significant bit first, Token Ring most significant first - the numeric values naturally associated with the same address on different 802 media differ. To facilitate the communication of address values in higher layer protocols which might span both token ring and Ethernet attached systems connected by bridges, it was necessary to define one reference format - the so called canonical format for these addresses. Formally the canonical format defines the value of the address, separate from the encoding rules used for transmission. It comprises a sequence of octets derived from the original wire order transmission bit order as follows. The least significant bit of the first octet is the first bit transmitted, the next least significant bit the second bit, and so on to the most significant bit of the first octet being the 8th bit transmitted; the least significant bit of the second octet is the 9th bit transmitted, and so on to the most significant bit of the sixth octet of the canonical format being the last bit of the address transmitted.
IEEE 802使用的48位MAC地址最初是根据源和目标MAC地址字段中位的线顺序传输定义的。以太网和令牌环均采用相同的接线顺序。由于以太网和令牌环数据的位传输顺序不同-以太网八位字节先传输最低有效位，令牌环先传输最高有效位-与不同802媒体上相同地址自然关联的数值不同。为了便于在可能跨越令牌环和通过网桥连接的以太网连接系统的更高层协议中通信地址值，有必要定义一种参考格式——这些地址的所谓规范格式。在形式上，规范格式定义了地址的值，与用于传输的编码规则不同。它包括从原始线顺序传输位顺序派生的八位字节序列，如下所示。第一个八位字节的最低有效位是传输的第一位，下一个最低有效位是第二位，依此类推，第一个八位字节的最高有效位是传输的第八位；第二个八位字节的最低有效位是传输的第9位，依此类推，标准格式的第六个八位字节的最高有效位是传输地址的最后一位。
This canonical format corresponds to the natural value of the address octets for Ethernet. The actual transmission order or formal encoding rules for addresses on media which do not transmit bit serially are derived from the canonical format octet values.
此规范格式对应于以太网地址八位字节的自然值。对于不连续传输位的介质上的地址，其实际传输顺序或正式编码规则是从规范格式的八位字节值推导而来的。
This document requires that all L2 addresses used in conjunction with the SBM protocol be encoded in the canonical format as a sequence of 6 octets. In the following, we define the object formats for objects that contain L2 addresses that are based on the canonical representation.
本文件要求与SBM协议一起使用的所有L2地址均以规范格式编码为6个八位字节的序列。在下面，我们为包含基于规范表示的L2地址的对象定义对象格式。
RSVP_HOP_L2 object uses object class = 161; it contains the L2 address of the previous hop L3 device in the IEEE Canonical address format discussed above.
RSVP_HOP_L2对象使用对象类=161；它包含前一跳L3设备的L2地址，采用上面讨论的IEEE标准地址格式。
RSVP_HOP_L2 object: class = 161, C-Type represents the addressing format used. In our case, C-Type=1 represents the IEEE Canonical Address format.
RSVP_HOP_L2对象：class=161，C-Type表示使用的寻址格式。在我们的例子中，C-Type=1表示IEEE标准地址格式。
0 1 2 3
+---------------+---------------+---------------+----------------+
| Length | 161 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+
| Variable length Opaque data |
+---------------+---------------+---------------+----------------+
0 1 2 3
+---------------+---------------+---------------+----------------+
| Length | 161 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+
| Variable length Opaque data |
+---------------+---------------+---------------+----------------+
C-Type = 1 (IEEE Canonical Address format)
C-Type=1（IEEE标准地址格式）
When C-Type=1, the object format is:
当C-Type=1时，对象格式为：
0 1 2 3
+---------------+---------------+---------------+---------------+
| 12 | 161 | 1 |
+---------------+---------------+---------------+---------------+
| Octets 0-3 of the MAC address |
+---------------+---------------+---------------+---------------+
| Octets 4-5 of the MAC addr. | /// | /// |
+---------------+---------------+---------------+---------------+
0 1 2 3
+---------------+---------------+---------------+---------------+
| 12 | 161 | 1 |
+---------------+---------------+---------------+---------------+
| Octets 0-3 of the MAC address |
+---------------+---------------+---------------+---------------+
| Octets 4-5 of the MAC addr. | /// | /// |
+---------------+---------------+---------------+---------------+
/// -- unused (set to zero)
/// -- unused (set to zero)
LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address
object and LAN_NHOP_L2 address object.
<LAN_NHOP object> ::= <LAN_NHOP_L2 object> <LAN_NHOP_L3 object>
LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address
object and LAN_NHOP_L2 address object.
<LAN_NHOP object> ::= <LAN_NHOP_L2 object> <LAN_NHOP_L3 object>
LAN_NHOP_L2 address object uses object class = 162 and uses the same format (but different class number) as the RSVP_HOP_L2 object. It provides the L2 or MAC address of the next hop L3 device.
LAN_NHOP_L2地址对象使用对象类=162，并使用与RSVP_HOP_L2对象相同的格式（但不同的类号）。它提供下一跳L3设备的L2或MAC地址。
0 1 2 3
+---------------+---------------+---------------+----------------+
| Length | 162 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+
| Variable length Opaque data |
+---------------+---------------+---------------+----------------+
0 1 2 3
+---------------+---------------+---------------+----------------+
| Length | 162 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+
| Variable length Opaque data |
+---------------+---------------+---------------+----------------+
C-Type = 1 (IEEE 802 Canonical Address Format as defined below) See the RSVP_HOP_L2 address object for more details.
C-Type=1（IEEE 802标准地址格式定义如下）有关更多详细信息，请参阅RSVP_HOP_L2地址对象。
LAN_NHOP_L3 object uses object class = 163 and gives the L3 or IP address of the next hop L3 device.
LAN_NHOP_L3对象使用对象类=163，并给出下一跳L3设备的L3或IP地址。
LAN_NHOP_L3 object: class = 163, C-Type specifies IPv4 or IPv6 address family used.
LAN_NHOP_L3对象：class=163，C-Type指定使用的IPv4或IPv6地址族。
IPv4 LAN_NHOP_L3 object: class =163, C-Type = 1
+---------------+---------------+---------------+---------------+
| Length = 8 | 163 | 1 |
+---------------+---------------+---------------+---------------+
| IPv4 NHOP address |
+---------------------------------------------------------------+
IPv4 LAN_NHOP_L3 object: class =163, C-Type = 1
+---------------+---------------+---------------+---------------+
| Length = 8 | 163 | 1 |
+---------------+---------------+---------------+---------------+
| IPv4 NHOP address |
+---------------------------------------------------------------+
IPv6 LAN_NHOP_L3 object: class =163, C-Type = 2
+---------------+---------------+---------------+---------------+
| Length = 20 | 163 | 2 |
+---------------+---------------+---------------+---------------+
| IPv6 NHOP address (16 bytes) |
+---------------------------------------------------------------+
IPv6 LAN_NHOP_L3 object: class =163, C-Type = 2
+---------------+---------------+---------------+---------------+
| Length = 20 | 163 | 2 |
+---------------+---------------+---------------+---------------+
| IPv6 NHOP address (16 bytes) |
+---------------------------------------------------------------+
The LAN_LOOPBACK object gives the IP address of the outgoing interface for a PATH message and uses object class=164; both IPv4 and IPv6 formats are specified.
LAN_环回对象为路径消息提供传出接口的IP地址，并使用对象类=164；指定了IPv4和IPv6格式。
IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1
IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | 164 | 1 |
+---------------+---------------+---------------+---------------+
| IPV4 address of an interface |
+---------------+---------------+---------------+---------------+
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | 164 | 1 |
+---------------+---------------+---------------+---------------+
| IPV4 address of an interface |
+---------------+---------------+---------------+---------------+
IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2
IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2
+---------------+---------------+---------------+---------------+
| Length | 164 | 2 |
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPV6 address of an interface +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| Length | 164 | 2 |
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPV6 address of an interface +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
TCLASS object (traffic class based on IEEE 802.1p) uses object class = 165.
TCLASS对象（基于IEEE 802.1p的流量类）使用对象类=165。
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | 165 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /// | /// | /// | /// | PV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | 165 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /// | /// | /// | /// | PV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Only 3 bits in data contain the user_priority value (PV).
数据中只有3位包含用户优先级值（PV）。
As specified in the RSVP specification, a PATH and PATH_TEAR messages contain the RSVP Common Header and the relevant RSVP objects.
按照RSVP规范的规定，路径和路径撕裂消息包含RSVP公共头和相关RSVP对象。
For the RSVP Common Header, refer to the RSVP specification (RFC 2205). Enhancements to an RSVP_PATH message include additional objects as specified below.
有关RSVP公用标头，请参阅RSVP规范（RFC 2205）。RSVP_路径消息的增强功能包括以下指定的其他对象。
<PATH Message> ::= <RSVP Common Header> [<INTEGRITY>]
<RSVP_HOP_L2> <LAN_NHOP>
<LAN_LOOPBACK> [<TCLASS>] <SESSION><RSVP_HOP>
<TIME_VALUES> [<POLICY DATA>] <sender descriptor>
<PATH Message> ::= <RSVP Common Header> [<INTEGRITY>]
<RSVP_HOP_L2> <LAN_NHOP>
<LAN_LOOPBACK> [<TCLASS>] <SESSION><RSVP_HOP>
<TIME_VALUES> [<POLICY DATA>] <sender descriptor>
<PATH_TEAR Message> ::= <RSVP Common Header> [<INTEGRITY>]
<LAN_LOOPBACK> <LAN_NHOP> <SESSION> <RSVP_HOP>
[<sender descriptor>]
<PATH_TEAR Message> ::= <RSVP Common Header> [<INTEGRITY>]
<LAN_LOOPBACK> <LAN_NHOP> <SESSION> <RSVP_HOP>
[<sender descriptor>]
If the INTEGRITY object is present, it must immediately follow the RSVP common header. L2-specific objects must always precede the SESSION object.
如果存在INTEGRITY对象，它必须紧跟在RSVP公共头之后。L2特定对象必须始终位于会话对象之前。
As specified in the RSVP specification, an RSVP_RESV message contains the RSVP Common Header and relevant RSVP objects. In addition, it may contain an optional TCLASS object as described earlier.
按照RSVP规范的规定，RSVP_RESV消息包含RSVP公共头和相关RSVP对象。此外，如前所述，它可能包含可选的TCLASS对象。
New RSVP message types are introduced to allow interactions between a DSBM and an RSVP node (host/router) for the purpose of discovering and binding to a DSBM. New RSVP message types needed are as follows:
引入了新的RSVP消息类型，以允许DSBM和RSVP节点（主机/路由器）之间的交互，从而发现和绑定DSBM。所需的新RSVP消息类型如下：
RSVP Msg Type (8 bits) Value DSBM_WILLING 66 I_AM_DSBM 67
RSVP消息类型（8位）值DSBM\U 66 I\U AM\U DSBM 67
All SBM-specific messages are formatted as RSVP messages with an RSVP common header followed by SBM-specific objects.
所有SBM特定的消息都被格式化为RSVP消息，RSVP公共头后跟SBM特定的对象。
<SBMP_MESSAGE> ::= <SBMP common header> <SBM-specific objects>
<SBMP_MESSAGE> ::= <SBMP common header> <SBM-specific objects>
where <SBMP common header> ::= <RSVP common Header> [<INTEGRITY>]
where <SBMP common header> ::= <RSVP common Header> [<INTEGRITY>]
For each SBM message type, there is a set of rules for the permissible choice of object types. These rules are specified using
对于每种SBM消息类型，都有一组允许选择对象类型的规则。这些规则是使用
Backus-Naur Form (BNF) augmented with square brackets surrounding optional sub-sequences. The BNF implies an order for the objects in a message. However, in many (but not all) cases, object order makes no logical difference. An implementation should create messages with the objects in the order shown here, but accept the objects in any permissible order. Any exceptions to this rule will be pointed out in the specific message formats.
巴克斯-诺尔形式（BNF），在可选子序列周围用方括号扩充。BNF表示消息中对象的顺序。然而，在许多（但不是所有）情况下，对象顺序在逻辑上没有区别。实现应该按照此处显示的顺序使用对象创建消息，但接受任何允许的顺序的对象。此规则的任何例外情况都将在特定的消息格式中指出。
DSBM_WILLING Message
DSBM_意愿信息
<DSBM_WILLING message> ::= <SBM Common Header> <DSBM IP ADDRESS>
<DSBM L2 address> <SBM PRIORITY>
<DSBM_WILLING message> ::= <SBM Common Header> <DSBM IP ADDRESS>
<DSBM L2 address> <SBM PRIORITY>
I_AM_DSBM Message
我是DSBM消息
<I_AM_DSBM> ::= <SBM Common Header> <DSBM IP ADDRESS> <DSBM L2 address>
<SBM PRIORITY> <DSBM Timer Intervals>
[<NON_RESV_SEND_LIMIT>]
<I_AM_DSBM> ::= <SBM Common Header> <DSBM IP ADDRESS> <DSBM L2 address>
<SBM PRIORITY> <DSBM Timer Intervals>
[<NON_RESV_SEND_LIMIT>]
For compatibility reasons, receivers of the I_AM_DSBM message must be prepared to receive additional objects of the Unknown Class type [RFC-2205].
出于兼容性原因，I_AM_DSBM消息的接收器必须准备好接收未知类类型的其他对象[RFC-2205]。
All I_AM_DSBM messages are multicast to the well known AllSBMAddress. The default priority of a SBM is 1 and higher priority values represent higher precedence. The priority value zero indicates that the SBM is not eligible to be the DSBM.
所有I_AM_DSBM消息都被多播到众所周知的AllSBMAddress。SBM的默认优先级为1，优先级越高表示优先级越高。优先级值为零表示SBM没有资格成为DSBM。
Relevant Objects
相关对象
DSBM IP ADDRESS objects use object class = 42; IPv4 DSBM IP ADDRESS object uses <Class=42, C-Type=1> and IPv6 DSBM IP ADDRESS object uses <Class=42, C-Type=2>.
DSBM IP地址对象使用对象类=42；IPv4 DSBM IP地址对象使用<Class=42，C-Type=1>，IPv6 DSBM IP地址对象使用<Class=42，C-Type=2>。
IPv4 DSBM IP ADDRESS object: class = 42, C-Type =1
0 1 2 3
+---------------+---------------+---------------+---------------+
| IPv4 DSBM IP Address |
+---------------+---------------+---------------+---------------+
IPv4 DSBM IP ADDRESS object: class = 42, C-Type =1
0 1 2 3
+---------------+---------------+---------------+---------------+
| IPv4 DSBM IP Address |
+---------------+---------------+---------------+---------------+
IPv6 DSBM IP ADDRESS object: Class = 42, C-Type = 2
IPv6 DSBM IP ADDRESS object: Class = 42, C-Type = 2
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPv6 DSBM IP Address +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPv6 DSBM IP Address +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
<DSBM L2 address> Object is the same as <RSVP_HOP_L2> object with C-Type = 1 for IEEE Canonical Address format.
<DSBM L2 address>对象与IEEE标准地址格式的C-Type=1的<RSVP\u HOP\u L2>对象相同。
<DSBM L2 address> ::= <RSVP_HOP_L2>
<DSBM L2 address> ::= <RSVP_HOP_L2>
A SBM may omit this object by including a NULL L2 address object. For C-Type=1 (IEEE Canonical address format), such a version of the L2 address object contains value zero in the six octets corresponding to the MAC address (see section B.3.4 for the exact format).
SBM可以通过包含空L2地址对象来忽略此对象。对于C-Type=1（IEEE标准地址格式），这种版本的L2地址对象在与MAC地址对应的六个八位字节中包含值零（具体格式见第B.3.4节）。
SBM_PRIORITY Object: class = 43, C-Type =1
SBM_PRIORITY Object: class = 43, C-Type =1
0 1 2 3
+---------------+---------------+---------------+---------------+
| /// | /// | /// | SBM priority |
+---------------+---------------+---------------+---------------+
0 1 2 3
+---------------+---------------+---------------+---------------+
| /// | /// | /// | SBM priority |
+---------------+---------------+---------------+---------------+
TIMER INTERVAL VALUES.
计时器间隔值。
The two timer intervals, namely, DSBM Dead Interval and DSBM Refresh Interval, are specified as integer values each in the range of 0..255 seconds. Both values are included in a single "DSBM Timer Intervals" object described below.
两个计时器间隔，即DSBM死区间隔和DSBM刷新间隔，分别指定为0..255秒范围内的整数值。这两个值都包含在下面描述的单个“DSBM定时器间隔”对象中。
DSBM Timer Intervals Object: class = 44, C-Type =1
DSBM Timer Intervals Object: class = 44, C-Type =1
+---------------+---------------+---------------+----------------+
| /// | /// | DeadInterval | RefreshInterval|
+---------------+---------------+---------------+----------------+
+---------------+---------------+---------------+----------------+
| /// | /// | DeadInterval | RefreshInterval|
+---------------+---------------+---------------+----------------+
NON_RESV_SEND_LIMIT Object: class = 45, C-Type = 1
NON_RESV_SEND_LIMIT Object: class = 45, C-Type = 1
0 1 2 3
+---------------+---------------+---------------+----------------+
| NonResvSendLimit(limit on traffic allowed to send without RESV)|
| |
+---------------+---------------+---------------+----------------+
0 1 2 3
+---------------+---------------+---------------+----------------+
| NonResvSendLimit(limit on traffic allowed to send without RESV)|
| |
+---------------+---------------+---------------+----------------+
<NonResvSendLimit> ::= <Intserv Sender_TSPEC object>
(class=12, C-Type =2)
<NonResvSendLimit> ::= <Intserv Sender_TSPEC object>
(class=12, C-Type =2)
The NON_RESV_SEND_LIMIT object specifies a per-flow limit on the profile of traffic which a sending host is allowed to send onto a managed segment without a valid RSVP reservation (see Appendix C for further details on the usage of this object). The object contains the NonResvSendLimit parameter. This parameter is equivalent to the Intserv SENDER_TSPEC (see RFC 2210 for contents and encoding rules). The SENDER_TSPEC includes five parameters which describe a traffic profile (r, b, p, m and M). Sending hosts compare the SENDER_TSPEC describing a sender traffic flow to the SENDER_TSPEC advertised by the DSBM. If the SENDER_TSPEC of the traffic flow in question is less than or equal to the SENDER_TSPEC advertised by the DSBM, it is allowable to send traffic on the corresponding flow without a valid RSVP reservation in place. Otherwise it is not.
NON_RESV_SEND_LIMIT对象指定了流量配置文件中的每流量限制，允许发送主机在没有有效RSVP保留的情况下发送到托管段（有关此对象用法的更多详细信息，请参阅附录C）。该对象包含NONRSVSENDLIMIT参数。此参数相当于Intserv SENDER_TSPEC（有关内容和编码规则，请参阅RFC 2210）。发送方_TSPEC包括五个参数，这些参数描述了一个流量配置文件（r、b、p、m和m）。发送主机将描述发送方流量的发送方规范与DSBM公布的发送方规范进行比较。如果所讨论的流量的发送方规格小于或等于DSBM公布的发送方规格，则允许在没有有效RSVP保留的情况下在相应流量上发送流量。否则就不是了。
The network administrator may configure the DSBM to disallow any sent
traffic in the absence of an RSVP reservation by configuring a
NonResvSendLimit in which r = 0, b = 0, p = 0, m = infinity and M =
The network administrator may configure the DSBM to disallow any sent
traffic in the absence of an RSVP reservation by configuring a
NonResvSendLimit in which r = 0, b = 0, p = 0, m = infinity and M =
0. Similarly the network administrator may allow any traffic to be sent in the absence of an RSVP reservation by configuring a NonResvSendLimit in which r = infinity, b = infinity, p = infinity, m = 0 and M = infinity. Of course, any of these parameters may be set to values between zero and infinity to advertise finite per-flow limits.
0. 类似地，网络管理员可以通过配置非发送限制（其中r=无穷大、b=无穷大、p=无穷大、m=0和m=无穷大），允许在没有RSVP保留的情况下发送任何通信量。当然，这些参数中的任何一个都可以设置为介于零和无穷大之间的值，以显示有限的每流量限制。
The NON_RESV_SEND_LIMIT object is optional. Senders on a managed segment should interpret the absence of the NON_RESV_SEND_LIMIT object as equivalent to an infinitely large SENDER_TSPEC (it is permissible to send any traffic profile in the absence of an RSVP reservation).
非RESV\u SEND\u LIMIT对象是可选的。托管网段上的发送方应将没有非RESV\u SEND\u LIMIT对象解释为等同于无限大的发送方\u TSPEC（允许在没有RSVP保留的情况下发送任何流量配置文件）。
Appendix C The DSBM as a Source of Centralized Configuration Information
附录C将DSBM作为集中配置信息的来源
There are certain configuration parameters which it may be useful to distribute to layer-3 senders on a managed segment. The DSBM may serve as a centralized management point from which such parameters can easily be distributed. In particular, it is possible for the network administrator configuring a DSBM to cause certain configuration parameters to be distributed as objects appended to the I_AM_DSBM messages. The following configuration object is defined at this time. Others may be defined in the future. See Appendix B for further details regarding the NON_RESV_SEND_LIMIT object.
某些配置参数可能有助于将其分发到托管段上的第3层发送方。DSBM可以用作集中管理点，从中可以轻松分配此类参数。具体而言，网络管理员配置DSBM可能导致某些配置参数作为附加到I_AM_DSBM消息的对象分发。此时定义了以下配置对象。其他的可能在将来定义。有关非重新发送限制对象的更多详细信息，请参见附录B。
As we QoS enable layer 2 segments, we expect an evolution from subnets comprised of traditional shared segments (with no means of traffic separation and no DSBM), to subnets comprised of dedicated segments switched by sophisticated switches (with both DSBM and 802.1p traffic separation capability).
当我们启用第2层网段的QoS时，我们期望从由传统共享网段组成的子网（没有流量分离手段，也没有DSBM）发展到由复杂交换机交换的专用网段组成的子网（具有DSBM和802.1p流量分离能力）。
A set of intermediate configurations consists of a group of QoS enabled hosts sending onto a traditional shared segment. A layer-3 device (or a layer-2 device) acts as a DSBM for the shared segment, but cannot enforce traffic separation. In such a configuration, the DSBM can be configured to limit the number of reservations approved for senders on the segment, but cannot prevent them from sending. As a result, senders may congest the segment even though a network administrator has configured an appropriate limit for admission control in the DSBM.
一组中间配置由一组支持QoS的主机组成，这些主机发送到传统的共享段。第3层设备（或第2层设备）充当共享段的DSBM，但不能强制实施流量分离。在这种配置中，DSBM可以配置为限制段上批准的发送者保留的数量，但不能阻止他们发送。因此，即使网络管理员已在DSBM中为准入控制配置了适当的限制，发送方也可能阻塞该段。
One solution to this problem which would give the network administrator control over the segment, is to require applications (or operating systems on behalf of applications) not to send until they have obtained a reservation. This is problematic as most applications are used to sending as soon as they wish to and expect to get whatever service quality the network is able to grant at that time. Furthermore, it may often be acceptable to allow certain applications to send before a reservation is received. For example, on a segment comprised of a single 10 Mbps ethernet and 10 hosts, it may be acceptable to allow a 16 Kbps telephony stream to be transmitted but not a 3 Mbps video stream.
此问题的一个解决方案是要求应用程序（或代表应用程序的操作系统）在获得预订之前不发送，这将使网络管理员能够控制该网段。这是有问题的，因为大多数应用程序都习惯于在希望并期望获得网络当时能够授予的任何服务质量时立即发送。此外，允许某些应用程序在收到预订之前发送通常是可以接受的。例如，在由单个10 Mbps以太网和10台主机组成的段上，允许传输16 Kbps电话流而不是3 Mbps视频流是可以接受的。
A more pragmatic solution then, is to allow the network administrator to set a per-flow limit on the amount of non-adaptive traffic which a sender is allowed to generate on a managed segment in the absence of a valid reservation. This limit is advertised by the DSBM and received by sending hosts. An API on the sending host can then approve or deny an application's QoS request based on the resources
因此，一个更实用的解决方案是允许网络管理员在没有有效保留的情况下，对允许发送方在托管段上生成的非自适应通信量设置每流限制。此限制由DSBM公布，并由发送主机接收。然后，发送主机上的API可以基于资源批准或拒绝应用程序的QoS请求
requested.
请求。
The NON_RESV_SEND_LIMIT object can be used to advertise a Flowspec which describes the shape of traffic that a sender is allowed to generate on a managed segment when its RSVP reservation requests have either not yet completed or have been rejected.
非RESV\u SEND\u LIMIT对象可用于公布Flowspec，该Flowspec描述了当发送方的RSVP保留请求尚未完成或被拒绝时，允许发送方在托管段上生成的流量的形状。
ACKNOWLEDGEMENTS
致谢
Authors are grateful to Eric Crawley (Argon), Russ Fenger (Intel), David Melman (Siemens), Ramesh Pabbati (Microsoft), Mick Seaman (3COM), Andrew Smith (Extreme Networks) for their constructive comments on the SBM design and the earlier versions of this document.
作者感谢Eric Crawley（Argon）、Russ Fenger（Intel）、David Melman（西门子）、Ramesh Pabbati（微软）、Mick Seaman（3COM）、Andrew Smith（Extreme Networks）对SBM设计和本文件早期版本提出的建设性意见。
Raj Yavatkar Intel Corporation 2111 N.E. 25th Avenue, Hillsboro, OR 97124 USA
拉吉·雅瓦卡尔英特尔公司2111美国希尔斯伯勒第25大道东北部，邮编：97124
Phone: +1 503-264-9077
EMail: yavatkar@ibeam.intel.com
Phone: +1 503-264-9077
EMail: yavatkar@ibeam.intel.com
Don Hoffman Teledesic Corporation 2300 Carillon Point Kirkland, WA 98033 USA
美国华盛顿州科克兰卡里隆角2300号唐·霍夫曼电信公司，邮编：98033
Phone: +1 425-602-0000
电话：+1 425-602-0000
Yoram Bernet Microsoft 1 Microsoft Way Redmond, WA 98052 USA
美国华盛顿州雷德蒙微软路1号Yoram Bernet微软98052
Phone: +1 206 936 9568
EMail: yoramb@microsoft.com
Phone: +1 206 936 9568
EMail: yoramb@microsoft.com
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 USA
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara，加利福尼亚州93111
Phone: +1 408 526 4257
EMail: fred@cisco.com
Phone: +1 408 526 4257
EMail: fred@cisco.com
Michael Speer Sun Microsystems, Inc 901 San Antonio Road UMPK15-215 Palo Alto, CA 94303
加利福尼亚州帕洛阿尔托市圣安东尼奥路901号UMPK15-215迈克尔·斯佩尔太阳微系统公司，邮编94303
Phone: +1 650-786-6368
EMail: speer@Eng.Sun.COM
Phone: +1 650-786-6368
EMail: speer@Eng.Sun.COM
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。