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形式のLAN上RSVPベースのアドミッション制御のためのシグナリング方法およびプロトコルを記述しています。プロトコルは、IEEE 802 LANの現在の世代と同様に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 reservation setup protocols is needed for specific link-layer technologies such as shared and switched IEEE-802-style LAN technologies.
インターネットアーキテクチャとサービスモデルへの新しい拡張機能が統合されたサービスのインターネット[RFC-1633、RFC-2205、RFC-2210]のアプリケーションは、現在のIPに加えて、インターネットから特定の資質やサービスのレベルを要求できるように定義されていますベストエフォート型サービスです。これらの拡張機能は、RSVP、リソース予約セットアッププロトコル、およびサービス統合型ルータでサポートされる新しいサービスクラスの定義が含まれています。 RSVPとサービスクラス定義は、基盤となるネットワーク技術の大部分は独立しており、特定のサブネットワーク技術にRSVPと統合サービス仕様のマッピングを定義する必要があります。例えば、サービスのマッピングと予約セットアッププロトコルの定義は、共有などの特定のリンク層技術のために必要とIEEE-802形式の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は、IEEE 802形式のネットワーク上にそのようなRSVPのようなインターネット・レベル・セットアップ・プロトコルをマッピングするための方法を提供します。特に、RSVP対応のデータフローのためのLANのリソースの予約をサポートするために、RSVP対応のホスト/ルータとリンク層デバイス（スイッチ、ブリッジ）の動作を説明します。共有上の統合サービスを提供し、IEEE-802形式のLAN技術とサービスのマッピングの定義を切り替えるためのフレームワークは、別のドキュメント[RFC-FRAME、RFC-MAP]に記載されています。
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プロトコルからの協力（および執行を）必要とするものに（RSVP対応のトラフィックフローによって消費される帯域幅の量を超える）、純粋な管理制御を行うものから異なるLANの帯域幅管理ソリューションの範囲を可能にします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 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.
II。この文書では、RSVPフローオーバーLANベースのアドミッション制御のための唯一のシグナリング方法とプロトコルを指定します。ここでは、リンク層のための任意のトラフィック制御メカニズムを定義しません。プロトコルはまた、IEEE 802によって定義されたようなメカニズムを使用するように設計されて、私たちは、レイヤ3エンドシステムは、（例えば、ホストまたはルータ）が統合サービスのトラフィックをポリシングによって、トラフィック制御を行使する各流れていることを確認するために流れていると仮定しますそのトラフィックの仕様内の滞在は、アドミッション制御のために提出され、以前の予約要求に定めます。これは、その後、フローごとと組み合わせSBMアドミッション制御を使用したシステムは、IEEE 802形式のLANを介して制御ロード（とさえ保証）サービスの一部近似を実現するためにリンク層でエンドシステムとIEEE定義のトラフィック制御で整形することができます。
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.
III。 （例えば、共有LANセグメントなど）下にあるLAN内の任意のリンクレイヤトラフィック制御やプライオリティキューイングメカニズムの非存在下で、SBMベースのアドミッション制御機構のみでRSVP対応の流れによって課されるトラフィック負荷の総量を制限しますLANを共有しました。このような環境では、トラフィックフローの分離機構は、同じ共有メディア上でベストエフォートトラフィックからRSVP対応のフローを保護するために存在しない、それが唯一の802.1p-からなるトポロジー外にそのようなメカニズムの有用性の問題を提起します対応スイッチ。しかし、我々は、SBMベースのアドミッション制御メカニズムは、まだ二つの理由LANトポロジを共有し、レガシーに有用な目的を果たすだろうと仮定します。まず、統合サービストラフィックを生成するすべてのノードがすべてのトラフィックを送信する前に、リソースの予約を要求するSBMベースのアドミッション制御手順を利用して流れると仮定すると、統合サービスによって生成されたトラフィックの総量を制限する機構がすることにより、所望の範囲内に流れます。 LAN管理者（付録CにNonResvSendLimitパラメータの説明を参照してください）。第二に、TCP / IPベースのトラフィックソースによって生成されたベストエフォート型トラフィックは、一般的にTCP-スタイル「スロースタート」輻輳回避メカニズムまたはオンベースのオーディオ/ビデオ・ストリームで使用されるフィードバックベースのレート適応メカニズムを使用して（適応を評価されますRTP / RTCPプロトコル）および利用可能なネットワーク帯域幅内に収まるように適応します。このように、アドミッション制御およびレート適合の組み合わせは、持続的な交通渋滞を避ける必要があります。しかし、これは、非統合 - サービスのトラフィックは、基盤となるLANインフラストラクチャでのトラフィック制御のサポートがない状態でサービス統合型トラフィックに干渉しないことを保証するものではありません。
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は、第1の文書で使用される様々な用語を定義した後、試料のネットワークへの応用の例をアドミッション制御手順の概要を提供します。
* 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（サブネット帯域幅マネージャを指定）、SBMs、およびDSBMクライアントでPATH（およびPATH_TEAR）メッセージを転送するためのルールを説明しています。
* 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または場合に（SNMPなど）、他のシグナリングプロトコルRSVPシグナリングの非存在下で動作することができる場合の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：私たちは、このようなL2または層2としてIEEE 802.3 /イーサネットなどのデータリンク層技術を参照してください。
- 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転送機能を介さずに相互接続されたノードとリンクのセット。 1つまたは複数の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またはL2デバイス：私たちは、レイヤ2またはL2デバイスとしてのレイヤ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。この文書では、この層ではインターネット・プロトコル（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.
- セグメント：一つ以上の送信者によって共有されるL2物理セグメント。セグメントの例としては、（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とセグメントです。管理セグメントはDSBMsによって分離されていない共有LANのそれらの相互接続された部分を含みます。
- 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層媒体上の架橋ネットワークを介してこの値を運ぶために一貫性のある方法を定義します。 user_priorityの使用は、完全[IEEE8021D]及び802.1P [IEEE8021P「特定のMAC手順によって内層サービスのサポート」802.1Dのセクション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.
- サブネット：それらが配置されているL2ドメインを構成するセグメントのセットと一緒に共通のL3ネットワークアドレスプレフィックスを共有L3装置のグループを示すために、このメモで使用されます。
- 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またはL3デバイスに常駐し、L2セグメント上のリソースを管理するプロトコルエンティティです。最も1つDSBMは、各L2セグメントのために存在します。
- 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がセグメント上に存在する場合、SBMsの一方は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クライアント：これらの管理対象セグメント上にトラフィックを送信し、LANセグメントの上にアドミッション制御のための管理セグメントに対するDSBMのサービスを使用するエンティティです。そのようなホストやルータなど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透明デバイス：（それはまたはRSVPアウェアであってもなくてもよいが）、したがって、管理セグメント上SBMベースのアドミッション制御手順に参加していない「SBM透明」デバイスがSBMs又はDSBMsを知りません。そのようなデバイスは、デバイスに適した標準的な転送ルールを使用して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アドレス」などのレイヤ2つのアドレスとしてL3 / L2デバイスの3つのアドレスを層に参照します。この規則は、レイヤ3及びレイヤネクストホップ（NHOP）と前のホップ（PHOP）デバイスをRSVPを参照するために使用される2つのアドレスを区別するために、文書の残りの部分に使用されます。例えば、従来のRSVPメッセージ処理において、PATHメッセージ内RSVP_HOPオブジェクトは、以前のホップデバイスのL3アドレスを運びます。我々はRSVP_HOP_L2アドレスと呼ぶことにするRSVP_HOP_L3アドレスと前ホップデバイスの対応するMACアドレスとしてRSVP_HOPオブジェクトに含まれているアドレスを参照します。
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クライアントから発信リソース予約要求上アドミッション制御を担当します。セグメント与えられ、一つ以上のSBMsは、セグメント上に存在してもよいです。例えば、多くのSBM対応デバイスは、半二重を共有することができる2 SBM対応スイッチに対し共有L2セグメントにセグメントを切り替え取り付けられてもよいです。その場合、単一DSBMは、セグメントのために選出されます。動的DSBMを選出するための手順は、付録Aに記載されている管理対象セグメントの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 |
+------+ +-------+
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がインターフェイス上に存在するか否かを判定する。発見し、結合したセグメントのためにDSBMの存在を確認するための手順は、クライアント自身がセグメント上DSBMとして機能できる場合は、付録Aに記載されて、それがDSBMになるために選挙に参加することもできます。開始時に、DSBMクライアントはまず、それがアドミッション制御の目的のためにDSBMと通信できるようにDSBMがそのL2ドメイン内に存在することを確認します。
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.
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.
DSBMクライアントが送信または管理セグメントに接続されたインターフェイス上のRSVP PATHメッセージを転送する場合A）は、）は、従来のRSVP処理において行われるように（RSVPセッションの宛先アドレスに送信するのではなく、セグメントのDSBMにPATHメッセージを送信します。 。 （ADSPECを更新する可能性と）処理した後、DSBMは、その宛先アドレスに向けてPATHメッセージを転送します。その処理の一部として、DSBMビルドとセッションに対する経路状態を維持し、それにPATHメッセージを送信した前回の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.
私たちはRSVPセッションに送信者（セッションアドレスは、図1の管理セグメント上のホストAのIPアドレスを指定します）、管理セグメントのL2ドメインの外部に存在し、PATHメッセージを送信することを想定し、図1の管理セグメントを考えてみましょうそれは、ホストAへのパス上にあるルータR1に到着します
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に、送信者からのPATHメッセージを転送します。 DSBMはPATHメッセージを処理し、RSVP受信機（詳細メッセージの処理及び転送ルールは、セクション5に記載されている）に向かってPATHメッセージを転送します。プロセスでは、DSBMは、パス状態を構築セッションの前のホップとしてルータR1（そのL2およびL3アドレス）を記憶し、（後の説明を参照）PHOPオブジェクトに独自のL2とL3アドレスを置き、かつ効果的に挿入され自身の管理対象セグメント上（図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.
ホストA上のアプリケーションは、RSVPセッションの予約をしたい場合b）に示すように、ホストAは、標準的なRSVPメッセージ処理ルールに従い、前のホップL2 / L3アドレスにRSVP RESVメッセージを送信する（DSBMsアドレス）PHOPから得られました以前に受信したPATHメッセージ内のオブジェクト（複数可）。
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は、セッションのためにそのローカルPATH状態に基づいてPHOP（S）へのRESVメッセージを転送します。 DSBMは、同じセッションの予約要求をマージし、可能な場合（セクション5.8で説明されている追加の基準を除く）は、従来のRSVP処理で使用されるものと同様の規則を使用して。
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が含まれている場合、複数の管理対象セグメントによって分離することができます。その場合には、元のPATHメッセージは、各DSBMでパス状態を設定多くDSBMs（AのR1からの経路上の各管理対象セグメントに対して1つ）を介して伝播することになります。したがって、RESVメッセージは、中間DSBMsを通して逆にホップバイホップを伝播し、最終的に全て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).
それは、管理セグメント上の発信PATHメッセージを転送していないときに、通常のRSVP転送ルールは、DSBMクライアントに適用されます。しかし、管理セグメント上の発信PATHメッセージは、（セクション5.2をPATHメッセージは、管理セグメント上DSBMに送信する方法を説明）対応の管理セグメントの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 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.
ポイントツーポイントリンク上で、従来のRSVP処理、RSVPノード（ホスト/ルータ）に次のホップ（トラフィックフローのデータ・パケットの経路における下流ノード）を追跡するRSVP_HOPオブジェクト（NHOPとPHOP情報）を使用し前のホップ（データの流れに対して上流ノード）送信側と受信側との間の経路上のノード。 PATHメッセージの経路に沿ったルータは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ドメイン外に存在しているものとするが、PATHメッセージその受信機は、トランジットサブネットとして使用L2ドメイン内のルータを通過します。送信者XからのPATHメッセージはルータR1に到着すると仮定します。 R1は、パスが管理さL2ドメインを横断するとき、我々はにPATHとRESVメッセージを必要とする、しかし、ホストY.に向けてPATHメッセージを転送するために使用するネクストホップルータ（ルータR2またはルータR3のいずれか）を決定するために、そのローカルルーティング情報を使用しています各管理セグメントのDSBMを通過します。そのようなL2ドメインは、多くの管理セグメント（及びDSBMs）に及ぶことがあり、典型的には、（スイッチなど）L2デバイス上SBMプロトコルエンティティは、スイッチトポロジ内の管理対象セグメントのDSBMsとなります。 R1はDSBM（L2デバイス）へPATHメッセージを転送する場合、DSBMはPATHメッセージを転送する前に、（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).
この目的のために、我々は、PATHメッセージは、2つのL3エンティティ（PHOPとNHOPノードをRSVP）間のL2ドメインを横断するときに、次のL3ホップを追跡LAN_NHOPアドレスオブジェクトと呼ばれる新しいRSVPオブジェクトを紹介します。
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 call it L2ADDR for Layer 2 address) corresponding to the IP address in the LAN_NHOP object.
DSBMクライアント（ホストまたはPATHメッセージの発信元として機能するルータが）DSBMにPATHメッセージを送信すると、そのメッセージにLAN_NHOP情報を含める必要があります。ユニキャスト宛先の場合には、LAN_NHOPアドレスは、宛先アドレス（宛先がそのL2ドメインに対してローカルである場合）、または宛先に向かう次ホップルータのアドレスを指定します。トランジットサブネットとして作用する図1のL2ドメインと送信者Xと受信機Yを含むRSVPセッションの例では、R1は、PATHメッセージを受信した入口ノードです。 R1は、最初R2は、ネクストホップルータ（またはセッションアドレスのL2ドメイン内の出口ノード）であると判断した後、R2のIPアドレスを指定LAN_NHOPオブジェクトを挿入します。 DSBMは、PATHメッセージを受信すると、それは今LAN_NHOPオブジェクトのアドレスを見て、PATHメッセージを処理した後、出口ノードに向けてPATHメッセージを転送することができます。しかし、我々は（我々は、レイヤのためL2ADDRそれを呼び出す（スイッチなど）L2デバイスはL2ドメイン内パス上DSBMsとして機能するように、これらのデバイスはMACアドレスを決定するためにARP機能を持つことを期待するのが妥当ではないかもしれない期待しますLAN_NHOPオブジェクト内のIPアドレスに対応する2アドレス）。
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.
したがって、我々は、（L3デバイスによって生成される）LAN_NHOP情報は、IPアドレス（LAN_NHOP_L3アドレス）及びL2ドメインで次L3ホップに対応するMACアドレス（LAN_NHOP_L2アドレス）の両方を含むことを必要とします。 L2アドレスがからL3 NHOP（出口点に向かってPATHメッセージを転送する方法を決定するためにL2デバイスのSBMプロトコルエンティティによって使用されるのに対し、その宛先に向けてPATHメッセージを転送するためにL3デバイスのSBMプロトコルエンティティによって使用されるLAN_NHOP_L3アドレス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仕様で説明パス処理規則に従って、PATHメッセージを処理します。特に、DSBMは、PATHメッセージ内RSVP_HOPオブジェクトから前ホップのIPアドレスを検索し、そのパス状態でPHOPアドレスを格納します。その後、自身のIPアドレス（RSVP_HOP_L3アドレス）を反映するように修正PHOP（RSVP_HOP）対象とPATHメッセージを転送します。したがって、DSBMはL2ドメインを横切る2つの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流路内の2つのRSVPノード間のホップとしてそれ自体を挿入するため、（例えば、PATH、PATH_TEAR、RESV、RESV_CONF、RESV_TEAR、及びRESV_ERRなど）すべてのRSVP関連するメッセージは、現在DSBM流れます。 PATH_TEARメッセージが転送される前に、その対応するPATHメッセージとローカルパスの状態が第1の各中間ホップでクリーンアップされているように、特に、PATH_TEARメッセージが正確に中間DSBM（S）を介してルーティングされます。
- 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 database) to the LAN_NHOP_L2 address as are applied normally to data packets destined to the address.
- これまでのところ、我々は、PATHメッセージは、パス内の管理対象のセグメントに沿って各DSBMでPATH状態を確立するL2ドメインを介して伝播する方法を説明してきました。 LAN_NHOPオブジェクト内のレイヤ2アドレス（LAN_NHOP_L2アドレス）次L3ホップに向けてPATHメッセージを転送する方法を決定する経路に沿ってL2デバイスによって使用されるべきです。このようなデバイスは、標準のIEEE 802.1D転送ルール（例えば、そのフィルタリングデータベースに基づいて、単一のポートにそれを送ったり、L2アドレスがフィルタリングデータベースに表示されていない場合は、スパニングツリー内のアクティブすべてのポート上でそれをあふれさせる）を適用しますアドレス宛てのデータパケットに正常に適用されているようLAN_NHOP_L2アドレス。
4.2.2.5 Including Both Layer-2 and Layer-3 Addresses in the RSVP_HOP Objects
RSVP_HOPオブジェクト内の両方のレイヤ2およびレイヤ3アドレスを含む4.2.2.5
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メッセージに使用されます。各中間ノードは、パス状態を構築するように、それにPATHメッセージを送信前のホップ（着信メッセージの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.
我々の場合では、送信者（PHOP）と受信機（NHOP）との間の経路に沿って（したがって、中間RSVPはL2ドメインにホップなど）L2デバイスに常駐するSBMエンティティがDSBMsとして作用することが予想されます。 RESVメッセージがDSBMに到着したときにこのように、それはその前のホップへRESVメッセージを転送するために保存されたPHOP IPアドレスを使用する必要があります。しかし、L2デバイスがRESVメッセージを転送する前に、それに対応するL2アドレスにPHOP IPアドレスをマッピングするためにARPキャッシュまたはARP機能を持つことを期待するのは合理的ではないかもしれません。
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デバイスの構築および管理セグメント上PATHメッセージを転送するには、そのIPアドレスRSVP_HOPオブジェクト内（PATHが送信される上インターフェイスのIPアドレス）を含み、インタフェースのための対応するL2アドレスを含むRSVP_HOP_L2オブジェクトを追加する場合。 L2ドメイン内のデバイスは、PATHメッセージを受信すると、そのパスの状態でRSVP_HOPとRSVP_HOP_L2オブジェクトのアドレスを記憶した後、管理セグメント上PATHメッセージを転送する前に、自身のアドレスと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 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.
RSVPセッションアドレスは、マルチキャストアドレスとSBM、DSBMであり、DSBMクライアントが同じL2セグメント（共有セグメント）を共有し、そのPATHメッセージの1つまたは複数のコピーを受信するSBM又はDSBMクライアントのために可能である場合同じワイヤ上のDSBMは（そのような場合の例については、セクション5.7を参照）、それを転送するときに、以前の転送しました。このようなループの検出を容易にするために、我々はLAN_LOOPBACKオブジェクトと呼ばれる新しいRSVPオブジェクトを使用します。 DSBMクライアントまたはSBMs（ただし、それ以前に到着し、その上のインターフェイス上にPATHメッセージを反映するDSBMs）を上書き（またはPATHメッセージがすでにLAN_LOOPBACKオブジェクトが含まれていない場合は追加）する必要があり、独自のユニキャストとPATHメッセージでLAN_LOOPBACKオブジェクトIPアドレス。
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クライアントが簡単に（重複したPATHメッセージがLAN_LOOPBACKオブジェクト内のデバイスの独自のインターフェイスアドレスの一覧が表示されます）LAN_LOOPBACKオブジェクトの内容をチェックすることで、重複を検出して破棄することができます。付録BはLAN_LOOPBACKオブジェクトの正確な形式を指定します。
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 /イーサネットネットワークは、さまざまなサービスを要求する異なるフローを区別するために、トラフィッククラスの任意の概念を提供していません。しかし、IEEE 802.1Pは（詳細については[IEEE8021p、IEEE802Q]を参照）スイッチは、異なるトラフィッククラスを表すパケットで符号化されたいくつかの「user_priority」値を区別するための方法を定義します。 user_priority値は、いずれか（例えば、IEEE 802.5のFCオクテットで）、またはイーサネット（登録商標）の場合には、例えば、MAC層（上記のカプセル化を使用して、各パケットに割り当てられたuser_priority値を搭載するネイティブLANパケットに符号化することができますIEEE 802.1Q [IEEE8021Q]。IEEEによって定義される新しい、拡張フレームフォーマットを使用してフレームヘッダに、しかし、送信者またはネットワークがuser_priority値を使用するべきかについての推奨を行いません。添付文書はuser_priorityの使用に関する勧告を行います値（詳細については[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.
統合サービスモデルでは、トラフィックを送信L3（またはそれ以上）のエンティティは、L2セグメントはアドミッション制御中に指定されるようにフローは、トラフィック仕様を超えないことを保証するために、フローごとのポリシングを実行する必要上に流れます。また、L3デバイスは、それらのサービス・クラスを識別するために、user_priority値と、このようなフローのフレームにラベルを付けることができます。
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
この議論の目的のために、私たちは、パケットの「トラフィッククラス」として拡張フレームヘッダで運ばuser_priority値を参照します。 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デバイスによって上書きされてもよいです。送信者がPATHメッセージを送信した後、下流DSBMsは次L3デバイス（PATHメッセージのL3 NHOP）に移動するPATHメッセージ内の新しいトラフィッククラスオブジェクト（TCLASSオブジェクト）を挿入します。ある程度までは、TCLASSオブジェクトの内容は、RSVP PATHメッセージにADSPECオブジェクトのように扱われます。 PATHメッセージを受信した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で指定されTCLASSおよび他のSBM固有のオブジェクトをRFC 2205あたり、他のすべての、通常のRSVPオブジェクトに加えて、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は、管理セグメントとTCLASSオブジェクトが含まれていないPATHメッセージを超えるPATHメッセージを受信すると、DSBMはそれを転送する前に、PATHメッセージにTCLASSオブジェクトを追加するかもしれません。 DSBMはTCLASSオブジェクトの適切なuser_priority値を決定します。適切なuser_priority値を選択するための機構は、添付文書[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は、PATHメッセージ内TCLASSオブジェクトによって指定user_priority値によって表されるサービスクラスをサポートできない場合は、それはその能力とストアを反映するために意味論的に「低い」サービス値に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.]
[注：添付文書は、INT-SERVマッピングを定義IEEEにわたって802ネットワーク[RFC-MAP]がuser_priority値の正確な定義を提供し、user_priority値は、2つの値の「下」または「最低」を決定するために比較される方法について説明すべてのuser_priority値のうち。]
* 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メッセージにおける通常のフロースペック情報に加えて）トラフィッククラス情報を使用することができます。
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は、フローごとの予約要求を使用してもよいです。他の極端で、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（L2又はL3で）デバイスがTCLASSオブジェクトなしRESVメッセージを受信し、それが同じL2ドメイン内の管理対象セグメント上にRESVメッセージを転送する必要がある場合*、それは最初にそのパスの状態をチェックし、それが持っているかどうかをチェックする必要がありTCLASS値を保存。もしそうなら、それは自身のアドミッション制御を実行した後、発信RESVメッセージでTCLASSオブジェクトを含める必要があります。何TCLASS値が格納されていない場合、それはTCLASSオブジェクトを挿入することなく、RESVメッセージを転送しなければなりません。
* 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.
*（例えばホストまたはエッジルータとしてL3デバイスに常駐する）DSBMクライアントは、それがインターフェイスを介して受け付け、PATHメッセージ内TCLASSオブジェクトを受信すると、インタフェースのためにそのパス状態の一部としてTCLASSオブジェクトを格納する必要があり。クライアントは、インターフェイス上で同じセッションのためのRESVメッセージを転送する際に、後で、クライアントは、それがインターフェイスを介して転送しRESVメッセージに（前回のPATHメッセージで受信されたものから変更）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オブジェクト内user_priority値を渡す必要があります分類器。これは、続いて、発信インタフェースを介して転送される入院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装置はLAN_NHOP、RSVP_HOP_L2と共に（TCLASSオブジェクトを削除する必要がありますPATH / RESVメッセージを転送する前に、PATHメッセージの場合、及びLAN_LOOPBACKオブジェクト）。発信インターフェースは、別個の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デバイスは、同じL2ドメインの一部である添付のセグメントを有する複数のインターフェイスを有していてもよいです。 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.
先に述べたように、我々は、彼らがパスの次のL3ホップに到達する前にDSBMクライアントがL2ドメインで自分のDSBMsへのRSVP PATHメッセージを転送する必要があります。 RSVP PATHメッセージは、（いずれかのIPユニキャストまたはマルチキャストアドレスであることができる）、それらの宛先アドレスに、RFC-2205によれば、アドレス指定されます。 L2デバイスがDSBMをホストする場合、単純に実装機構がデバイスのために提供されなければならない着信PATHメッセージを捕捉し、L3のRSVPメッセージのためにスヌープするL2デバイスを必要とすることなく、ローカルDSBMエージェントにそれを引き渡すことができます。
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クライアントがDSBMにSBMメッセージに対処する方法を知っておく必要があります。ダイナミック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デバイスでのPATHメッセージの取り込みを可能にするために、我々はDSBMは、論理アドレスではなく、物理アドレスを使用して対処する必要があります。私たちは、DSBMとのコミュニケーションの目的のために予約済みのIPマルチキャストアドレス（複数可）を利用します。特に、我々はDSBMクライアントまたはSBMは、管理セグメントの上にPATHメッセージを転送するとき、それは予約済みのIPマルチキャストアドレスにアドレス指定されている必要があります。したがって、L2デバイス上DSBMは、PATHメッセージを傍受し、ローカルSBMプロトコルエンティティに転送することを容易にするように構成する必要があります。たとえば、これは単にメッセージを傍受しますPATHを確保するために、対応するMACマルチキャストアドレスのデバイスのフィルタリングデータベース（FDB）の静的エントリを追加伴うことと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マルチキャストアドレスを使用して管理セグメント上にPATHメッセージを送信し、したがって、管理対象セグメントにSBMs又はDSBMクライアントは、単にメッセージをインターセプトするように構成されなければなりません簡単にPATHメッセージを受信します。
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:
我々は2つの予約済み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管理エンティティに向けられるようにレイヤ2つのデバイスのホストSBMs又はDSBMsの永久的なデータベースで構成されています。これは、これらのデバイスは、明示的にSBM関連の制御パケットのために詮索する必要性がなくなります。
* The two reserved addresses are 224.0.0.16 (DSBMLogicalAddress) and 224.0.0.17 (AllSBMAddress).
* 2つの予約済みアドレスは224.0.0.16（DSBMLogicalAddress）および224.0.0.17（AllSBMAddress）です。
These addresses are used as described in the following table:
次の表に示すように、これらのアドレスが使用されます。
Type DSBMLogicaladdress AllSBMAddress
DSBMLogicaladdress AllSBMAddressを入力
DSBM * Sends PATH messages * Monitors this address to detect Client to this address the presence of a DSBM
DSBM *は、PATHメッセージ*モニターこのアドレスにDSBMの存在をクライアントを検出するためにこのアドレスを送信します。
* Monitors this address to
receive PATH messages
forwarded by the 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によって転送PATHメッセージを受信するためにモニタ*このアドレスをモニター* PATHメッセージを送信し、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 *モニターこのアドレスは*モニタと*このアドレスにPATHメッセージを送信DSBMのそれに向け選挙に参加するためにPATHメッセージのために、この上で送信
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.
IPに対応するL2またはMACアドレス、マルチキャストアドレスが予約さL2アドレスブロック使用してアルゴリズム的に計算される（上位24ビットが00である：00：5E）。割り当てられた番号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).
前述のようにPATHメッセージの経路に沿ってL2デバイスが別々LAN_NHOPオブジェクト内LAN_NHOP_L3アドレス間のマッピングを決定する必要がないように、L3デバイスに常駐するDSBMs又はDSBMクライアントがLAN_NHOP情報にLAN_NHOP_L2アドレスを含める必要がありますその対応する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オブジェクト= map_addr（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機能を実行する必要があります。関数は、L3装置によって解釈される必要はなく、不透明なオブジェクトとして扱うことができるL2ADDRオブジェクトを返します。 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クライアント、およびSBMsはL2ドメインに転送されているRSVPメッセージをカプセル化するための唯一の生のIPを使用することを前提としています。従って、L3デバイス上SBMプロトコルエンティティは、L2セグメントにRSVPメッセージを転送する場合、それだけRAW 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
.................
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は、2台のルータを使用して相互接続3つの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）セグメントA、B S2のためのセグメントF S1スイッチ（レイヤ2）DSBMためDSBMセグメントC、D、E S3スイッチ（レイヤ2）SBMためのスイッチ（レイヤ2）DSBM
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.
次の段落では、これらのデバイスのそれぞれは、（ルールは、同様のメッセージをPATH_TEARに適用）PATHメッセージを転送するために使用すべきルールを説明します。これらは、上記に例示し、一般的なネットワークの文脈で説明されています。実施例はすべてのシナリオに対応していないが、それらは興味深いシナリオのほとんどに対処します。例外は個別に議論することができます。
The forwarding rules are applied to received PATH messages (routers and switches) or originating PATH messages (hosts), as follows:
次のように転送ルールは、受信したPATHメッセージ（ルータやスイッチ）、または発信PATHメッセージ（ホスト）に適用されます。
1. Determine the interface(s) on which to forward the PATH message using standard forwarding rules:
1.標準の転送ルールを使用して、PATHメッセージを転送するインターフェイス（複数可）を決定します。
* 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).
*そこLAN_LOOPBACKオブジェクトがPATHメッセージであり、そしてそれは、このデバイスのアドレスを運ぶ場合は、静かにメッセージを破棄します。 （管理対象セグメント上に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情報とMAC転送テーブルにLAN_NHOP_L2アドレスを使用します。 （「管理対象セグメント上にPATHメッセージを転送に関するその他の注意事項」の以下のセクションを参照してください）
* 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_LOOPBACK、及び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アウェアであるが、SBMプロトコルに参加していないノードは、無視して静かにそのようなオブジェクトを破棄するようにこれらの新しいオブジェクトのためのRSVPクラス番号が選択されることに注意してください）
* 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を支配するために進みます。
* 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デバイスである場合、PATHメッセージにLAN_NHOPアドレスオブジェクト、LAN_LOOPBACK、及びRSVP_HOP_L2オブジェクトを挿入します。 LAN_NHOPオブジェクトは、次の層3ホップのLAN_NHOP_L3とLAN_NHOP_L2アドレスを運びます。 RSVP_HOP_L2オブジェクトは、デバイス自身のL2アドレスを運び、そしてLAN_LOOPBACKオブジェクトは、発信インターフェイスのIPアドレスが含まれています。
An L3 device should use the map_addr() function described earlier to obtain an L2 address corresponding to an IP address.
L3装置は、IPアドレスに対応するL2アドレスを取得するために前述しmap_addr（）関数を使用する必要があります。
* 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ホップオブジェクトからPHOP情報を取得し、それを格納します。これは、バックL2ネットワークを介してルーティングRESVメッセージに使用されます。 PATHメッセージは、管理対象のセグメントの上に到着した場合、それはまた、RSVP_HOP_L2オブジェクトが含まれています。その後、取得し、PATH状態でも、前のホップの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アドレスをコピーし、標準RSVPホップオブジェクトとRSVP_HOP_L2オブジェクトに転送インタフェースのL2アドレスに（レイヤ2つのデバイスは、IPアドレスを持たなければなりません）。
- 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.
- 受信PATHメッセージがTCLASSオブジェクトが含まれていない場合は、TCLASSオブジェクトを挿入します。 TCLASSオブジェクトに挿入user_priority値は、[RFC-MAP]に記載されているガイドラインに従って構成された装置の内部サービスマッピングに基づいています。メッセージがすでにTCLASSオブジェクトが含まれている場合、user_priority値は、デバイスの内部サービスマッピングに再び基づいて変更することができます。
* 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.
L2デバイスにSBMがRSVPホップを上書きすることを選択するとRSVP_HOP_L2が転送インターフェイスのIP及びL2アドレスを持つオブジェクト場合は、RESVメッセージを受信します。この場合、入射PATHメッセージの標準RSVP_HOPフィールドとRSVP_HOP_L2オブジェクトで受信しPHOPアドレス情報を格納する必要があります。
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").
* SBMプロトコルエンティティはバック入射界面へのPATHメッセージを反映DSBMでない限り、LAN_LOOPBACKオブジェクトに転送インターフェイスのIPアドレスをコピーします。 （「管理対象セグメント上に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である場合、それはAllSBMAddressにPATHメッセージを送信しなければなりません。
* 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クライアントである場合、それはDSBMLogicalAddressにPATHメッセージを送信しなければなりません。
5.5.1. Additional notes on forwarding a PATH message onto a managed segment
5.5.1. 管理セグメント上にPATHメッセージを転送に関する追加の注意事項
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:
通常のIEEE 802.1D転送ルールがPATHメッセージが転送されるべきでインターフェイスを決定するために使用されるべきであることをルール＃1の状態。データ・パケットの場合には、L2デバイスで標準転送ルールは、パケットは、それが受信されたインターフェイス上で転送されるべきでないことを指示します。しかし、管理セグメント上のPATHメッセージを受信した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）を参照。 yesの場合は、後述する「バックインターフェース上にPATHメッセージを反映」に以下のルールに従います。そうでない場合は、いつものようにメッセージ処理の残りの部分を進めます。
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オブジェクト内のアドレスで指定された）マルチキャストグループアドレスのメンバーは、存在する場合、メッセージは、それが受信されたインターフェイス上にバック転送され、「上のルールに従わなければなりませんバック以下に説明するインタフェース」へPATHメッセージを反映しています。
*** Reflecting a PATH message back onto an interface ***
*** ***インターフェース上に戻しPATHメッセージを反映
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_LOOPBACKオブジェクトは、この問題を解決します。 （PATHメッセージを反映DSBMs除く）全てのSBMプロトコルエンティティは、発信インターフェイスのIPアドレスをPATHメッセージ内LAN_LOOPBACKオブジェクトを上書きします。 PATHメッセージを反映しているDSBMsは、不変LAN_LOOPBACKオブジェクトを残します。従って、SBMプロトコルエンティティは常にLAN_LOOPBACKオブジェクト内の独自のアドレスの存在によって反射マルチキャストメッセージを認識することができるであろう。これらのメッセージは静かに捨てられるべきです。
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が受信されたユニキャストセッションのパスを送信していると仮定する。次PATHメッセージは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内容N /（H1が管理セグメント上に送信されていない）H1のH5 H1の（3.0.0.35）送信者テンプレートIPアドレス（1.0.0.11）PHOP IPアドレス（1.0.0.11）RSVP_HOP_L2のセッションのIPアドレスIPアドレスをRSVP LAN_NHOP N /（H1は、管理上に送信していません
segment) LAN_LOOPBACK n/a (H1 is not sending onto a managed segment)
セグメント）LAN_LOOPBACK N /（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)
H1のIPヘッダーソースアドレスIPアドレスH5の（1.0.0.11）DestnアドレスIP addrの（3.0.0.35、rawモード＆ルータアラートを仮定して）
MAC Header Destn address The L2 addr corresponding to R1 (determined by map_addr() and routing tables at H1)
MACヘッダDestnは、（H1でmap_addrによって決定（）及びルーティングテーブル）R1に対応するL2のADDRに取り組みます
Since H1 is not sending onto a managed segment, the PATH message is composed and forwarded according to standard RSVP processing rules.
H1は、管理対象セグメントに送信されていないため、PATHメッセージは、標準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内容R1のH1 PHOP IPアドレス（2.0.0.1）のH5送信者テンプレートIPアドレスのセッションのIPアドレスIPアドレス（RESVメッセージのリターンパスをシード）R1 LAN_NHOP LAN_NHOP_L3のRSVP_HOP_L2 L2アドレス（2.0.0.2）とLAN_NHOP_L2アドレスRSVP R2（L2ADDR）（これは次の層3ホップである）R1のLAN_LOOPBACK IPアドレス（2.0.0.1）の
IP Header Source address IP address of H1 Destn address DSBMLogical IP address (224.0.0.16)
IPヘッダーソースH1 DestnアドレスDSBMLogical IPアドレスのアドレスIPアドレス（224.0.0.16）
MAC Header Destn address DSBMLogical MAC address
MACヘッダーDestnアドレスDSBMLogical MACアドレス
* R1 does a routing lookup on the RSVP session address, to determine the IP address of the next layer 3 hop, R2.
* R1は、次の層3ホップ、R2のIPアドレスを決定するために、RSVPセッションアドレスにルーティングルックアップを行います。
* It determines that R2 is accessible via seg A and that seg A is managed by a DSBM, S1.
*これは、R2は、ワンセグAを介してアクセス可能で、ワンセグ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 ("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.
*したがって、それは、管理対象セグメントに送信していると結論付け、及びレイヤ3及びレイヤ2つのネクストホップアドレスを運ぶためにLAN_NHOPオブジェクトを構成します。 LAN_NHOP L2ADDRオブジェクトを構成するために、次ホップL3デバイスのMACアドレスを見つけるためにL3 L2のアドレスマッピング機能（「map_address」）を呼び出し、その後、メッセージにLAN_NHOP_L2ADDRオブジェクト（すなわちMACアドレスを運ぶ）を挿入します。
* Since R1 is not the DSBM for seg A, it sends the PATH message to the DSBMLogicalAddress.
* R1は、ワンセグAのDSBMではないので、それはDSBMLogicalAddressにPATHメッセージを送信します。
Upon receipt of the PATH message, S1 composes and forwards a PATH message as follows:
PATHメッセージを受信すると、S1を構成し、次のようにPATHメッセージを転送します。
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内容はS1のH1 PHOPのIP ADDRのH5送信者テンプレートIPアドレスのセッションのIPアドレスIPアドレスをRSVP（RESVメッセージのリターンパスをシード）S1 LAN_NHOP LAN_NHOP_L3（IP）のRSVP_HOP_L2 L2アドレスとR2のLAN_NHOP_L2アドレス（レイヤ2デバイスが行いますS1のLAN_NHOP）LAN_LOOPBACK IP addrのを修正しません
IP Header Source address IP address of H1 Destn address AllSBMIPaddr (224.0.0.17, since S1 is the DSBM for seg B).
（S1は、SEG BのDSBMであるので、224.0.0.17）H1 DestnのIPヘッダの送信元アドレスIPアドレスはAllSBMIPaddrに対処します。
MAC Header Destn address All SBM MAC address (since S1 is the DSBM for seg B).
MACヘッダDestnアドレス（S1は、SEG BのDSBMであるので）全てSBM MACアドレス。
* S1 looks at the LAN_NHOP address information to determine the L2 address towards which it should forward the PATH message.
* S1は、それがPATHメッセージを転送すべき方向にL2アドレスを決定するためにLAN_NHOPアドレス情報を調べます。
* From the bridge forwarding tables, it determines that the L2 address is reachable via seg B.
*ブリッジの転送テーブルから、SEG Bを介してL2アドレスが到達可能であると判断します
* S1 inserts the RSVP_HOP_L2 object and overwrites the RSVP HOP object (PHOP) with its own addresses.
* S1はRSVP_HOP_L2オブジェクトを挿入し、自身のアドレスを持つRSVPホップオブジェクト（PHOP）を上書きします。
* Since S1 is the DSBM for seg B, it addresses the PATH message to the AllSBMAddress.
* S1は、SEG BのDSBMであるので、AllSBMAddressにPATHメッセージに対処します。
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内容は、セッションIP ADDR S3のH1 PHOPのIP ADDRのH5送信者テンプレートのIPアドレスのIPアドレス（RESVメッセージのリターンパスをシード）S3 LAN_NHOP LAN_NHOP_L3（IP）のRSVP_HOP_L2 L2アドレスとR2のLAN_NHOP_L2（MAC）アドレス（L2をRSVPデバイスは、S3のLAN_NHOP）LAN_LOOPBACK IPアドレスを変更しないでください
IP Header Source address IP address of H1 Destn address DSBMLogical IP addr (since S3 is not the DSBM for seg F)
H1 DestnのIPヘッダーソースアドレスIPアドレス（S3がワンセグF用DSBMではないので）DSBMLogical IP addrに取り組みます
MAC Header Destn address DSBMLogical MAC address
MACヘッダーDestnアドレスDSBMLogical MACアドレス
* S3 looks at the LAN_NHOP address information to determine the L2 address towards which it should forward the PATH message.
* S3は、それがPATHメッセージを転送すべき方向にL2アドレスを決定するためにLAN_NHOPアドレス情報を調べます。
* From the bridge forwarding tables, it determines that the L2 address is reachable via segment F.
*ブリッジの転送テーブルから、セグメントF.介しL2アドレスが到達可能であると判断します
* It has discovered that R2 is the DSBM for segment F. It therefore sends the PATH message to the DSBMLogicalAddress.
*これは、R2は、それ故DSBMLogicalAddressにPATHメッセージを送信セグメントF.ためDSBMであることを見出しました。
* 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メッセージを受信します。正しいパスにRESVメッセージを転送することができるように、この場合には、それはまた、入射PATHメッセージで受信PHOP情報を格納する必要があります。
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内容は、セッションIP ADDR R2のH1 PHOPのIP ADDRのH5送信者テンプレートのIPアドレスのIPアドレス（RESVメッセージのリターンパスをシード）R2により除去RSVP_HOP_L2（R2管理対象セグメント上に送信されていない）、R2（R2により除去LAN_NHOPをRSVP ）、管理部門に送信していません
IP Header Source address IP address of H1 Destn address IP address of H5, the RSVP session address
H5のH1 DestnアドレスIPアドレスのIPヘッダの送信元アドレスのIPアドレス、RSVPセッションアドレス
MAC Header Destn address L2 addr corresponding to H5, the next layer 3 hop
H5、次の層3ホップに対応するMACヘッダDestnアドレスL2のADDR
* R2 does a routing lookup on the RSVP session address, to determine the IP address of the next layer 3 hop, H5.
* R2は、次の層3ホップ、H5のIPアドレスを決定するために、RSVPセッションアドレスにルーティングルックアップを行います。
* 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オブジェクトを削除し、IPヘッダの宛先アドレスにRSVPセッションアドレスを置きます。これは、MACヘッダの宛先アドレスに、次の層3ホップのL2アドレスを置き、H5にPATHメッセージを転送します。
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は、H3およびH5は受信機であるため、M / Cセッションのパスを送信していると仮定する。彼らは前述のユニキャストの場合にあるように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:
今度は、PATHメッセージを受信するとR2によって適用される処理を見てみましょう。 R2は、セグメントのDSBMであることを思い出しF.従って、S3はR2によってピックアップされるように、DSBMLogicalAddressへのPATHメッセージを転送しているであろう。それは着信PATHメッセージのみAllSBMAddress、ないDSBMLogicalAddressを監視するためPATHメッセージは、H3（M / C受信機のうちの1つ）によって確認されていません。私たちは、バックワンセグFへのPATHメッセージを反映するため、およびH5に転送するためにR2に依存しています。 R2は、ワンセグF上に、次のPATHメッセージを転送します。
RSVP Contents RSVP session addr m/c session address Sender Template IP address of H1
RSVPの内容は、H1のセッションADDRのM / Cセッションアドレス送信者テンプレートのIPアドレスをRSVP
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 ADDR（RESVメッセージのリターンパスをシード）R2 LAN_NHOPのM / Cセッションアドレス及びS3の対応するL2アドレスLAN_LOOPBACKのIP ADDRのRSVP_HOP_L2 L2のADDR（PATHメッセージを反映DSBMsこのオブジェクトを変更しません）
IP Header Source address IP address of H1
H1のIPヘッダーソースアドレスIPアドレス
Destn address AllSBMIP address (since R2 is the DSBM for seg F)
DestnアドレスAllSBMIPアドレス（R2はワンセグFためDSBMであるため）
MAC Header Destn address AllSBMMAC address (since R2 is the DSBM for seg F)
MACヘッダDestn（R2はワンセグFためDSBMであるため）AllSBMMACアドレスをアドレス
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で反射されたPATHメッセージを受信します。 R2は、それが受信されたインターフェイスに戻し、着信メッセージを送信することによって、ここで標準の転送ルールに違反することに留意されたいです。それは変わらないLAN_LOOPBACKオブジェクトに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セッションADDR / C M R2のH1 PHOPのIP ADDR（RESVメッセージのリターンパスをシード）R2 R2により除去LAN_NHOP（R2管理対象セグメント上に送信されていない）（R2により除去RSVP_HOP_L2のセッションアドレス送信者テンプレートIPアドレス（R2）は、管理対象セグメント上に送信されていない管理対象セグメント上R2により除去）LAN_LOOPBACKを送信していません
IP Header Source address IP address of H1 Destn address m/c session address
H1 DestnアドレスM / CセッションアドレスのIPヘッダの送信元アドレスのIPアドレス
MAC Header Destn address MAC addr corresponding to the m/c session address
MACヘッダDestnはM / Cセッションアドレスに対応する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 places the corresponding L2 address into the destination address of the MAC header and multicasts the message towards H5.
* R2にはDSBMがないいるセグメントを介してアクセス可能なM / C受信機が存在すると判断します。したがって、LAN_NHOPとRSVP_HOP_L2オブジェクトを削除し、IPヘッダの宛先アドレスにRSVPセッションアドレスを置きます。これは、MACヘッダとマルチキャストH5に向かってメッセージの宛先アドレスに対応するL2アドレスを置きます。
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オブジェクト（別のPATHメッセージ）を受信し、（ワイルドカードスタイルの予約のように）単一RESVメッセージを送り返すためにそれらを結合する必要がある場合、DSBMクライアントが適切に選択する必要があります所望の遅延トラフィッククラスに対応する値。添付文書には、[RFC-MAP]希望のサービスとTSpecの情報に基づいてトラフィッククラスを選択するためのガイドラインを説明します。
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が合流点で異なるネクストホップからRESVsをマージする必要がある場合、それは彼らが一致しない場合は、着信RESVsでTCLASS値をどのように処理するかを決める必要があります。予約フローの最初のRESVで要求TCLASSに対して行わ成功したアドミッションコントロールとDSBM（またはSBM）での流れのための場所にある場合を考えます。同じフローのための別のRESV（以前に入院RESVのないリフレッシュ）がDSBMで到着した場合、DSBMは、最初既にインストールRESVでTCLASS値に対する新しいRESVでTCLASS値をチェックする必要があります。二つの値が同じである場合は、RESV要求が合併し、新しいされ、RESVがインストール合併やメッセージ処理の通常のルールを使用して転送。二つの値が同一でない場合は、DSBMは発生以降、RESVメッセージの送信者（NHOP）に向けてRESV_ERRメッセージを送信する必要があります。 RESV_ERRは、互換性のない2つのサービス要求（RSVPトラフィック制御エラーのサブコード01）[RFC-2205]マージに失敗したことを示すRSVP「トラフィック制御誤差」（RESV_ERRコード21）に対応するエラーコードを指定しなければなりません。 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関連のローカルグループアドレス（DSBMLogicalAddrssとALLSBMAddress）のいずれかに宛てたが、その代わりに、それらを通過インターセプトしません。その結果、彼らは明示的にPATHまたはRESVメッセージのルーティングに参加しない、DSBM選挙スコープを分割していない、と彼らはアドミッション制御には関与しません。彼らは、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を構成します。ネットワーク管理者は、おそらく必要な保証のレベルと、可能性の高いトラフィックのパターンのいくつかの知識に基づいて、2つの間にいくつかの値を、選択します。
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プロトコルエンティティがありますどのような目的頼むかもしれません。このようなSBMsは、実際には2つの便利な機能を提供します。まず、追加SBMsは、フォールトトレランスのために、バックグラウンドでの受動残ります。彼らは、管理セグメントの現在のDSBMからの定期的なアナウンスメント（付録Aは、これをより詳細に説明する）に耳を傾け、現在のDSBMが失敗したか、何らかの理由で運用でなくなったときに新しいDSBMを選出することでステップ。第二に、そのようSBMsも選挙の範囲を分割して管理セグメントのサイズと複雑さを軽減する重要なサービスを提供しています。例えば、再び図3のサンプルトポロジを考えます。デバイスS3は、それに取り付けられたセグメント、B、E、又はF、FいずれかのためにDSBMないSBMを含んでいます。 S3でSBMプロトコルエンティティが存在しない場合は、セグメントBおよびFは、SBMプロトコルの観点から別々のセグメントではないであろう。その代わりに、彼らは、単一のDSBMによって管理される単一の管理対象のセグメントを構成します。 S3のSBMエンティティが選挙の範囲を分割しているため、ワンセグBとワンセグFは、それぞれ別々のDSBMsによって管理されています。これらのセグメントのそれぞれは、密着空間と明確に定義された能力を持っています。 （S3は、SBMが透明であった場合のように）結果として、これらのセグメントのためのDSBMsは近似に基づいてアドミッション制御を実行する必要はありません。
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 forwarding rules.
なお、DSBMsていないSBMプロトコルエンティティは、自分のアドレスを持つ入射PATHメッセージでPHOPを上書きする必要はありません。 RESVメッセージは、これらのデバイスを経由してルーティングされることが必要ではないためです。 RESVメッセージはのみDSBMsの正しい順序を経由してルーティングされる必要があります。 SBMsは、標準の転送ルールを使用して、その宛先アドレスに向けて、それらを転送する以外にそれらを通過しないRESVメッセージを処理しない場合があります。
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_LOOPBACKオブジェクトのアドレスを上書きするために必要とされています。しかし、状態が保存される必要がありません。
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対応クライアントおよびノードは、これらのシナリオで動作することができます方法について説明します。
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.
その代わりに、ルータなどの特定のネットワークデバイスに帯域幅を予約するためにいくつかの他の（例えば、SNMPまたは静的設定）メカニズムを使用し、リソースの予約を要求するためのRSVPシグナリングを使用しないL2ドメインを想定することが可能であるが、。その場合には、質問が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帯域幅割当メカニズムと共存するかの異なるメカニズムの間静的に分配されるか、またはそう共通帯域割当を介して動的に解決されます同じリソースのノーオーバーコミットメントがあります。
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透明L2デバイス相互接続SBM認識デバイス、得管理セグメントは、管理対象セグメントの1つまたは複数の物理セグメントとDSBMの組み合わせである、すべてのL2デバイスがあった場合には同じように資源を割り当てると同様に効率的ではないかもしれませんSBM-気がついて。
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プロトコルに参加しなければなりません。このような使用は、DSBMのリソース管理機能をバイパスするように標準の使用、RSVPの非SBMバージョンは、過剰割当リソースの中で生じ得ます。他のすべての送信者（アドミッション制御を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、SBMs、またはDSBMクライアントがSBM-認識していない送信者からのPATHメッセージを受け入れてはいけません。それらはALLSBMAddress（SBMsとDSBMクライアントの場合）または（DSBMsの場合）DSBMLogicalAddressにマルチキャストされないようなデバイスからPATHメッセージを容易SBMsとDSBMクライアントによって検出することができます。
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メッセージ（例えば、選挙とPATHメッセージ）は、ローカルスコープを有しており、二つのドメイン間を通過しようとするものではありません。正しく構成された非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カプセル化を使用してRAW_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クライアント、およびSBMsはL2ドメインに転送されているRSVPメッセージをカプセル化するための唯一の生のIPを使用することを規定しています。 RFC-2205（標準案RSVP）は、生のIPとUDPカプセル化の両方のためのサポートを含みます。したがって、唯一のUDPカプセル化を使用してRSVPノードがDSBMが受け入れるとUDPは、RSVPメッセージをカプセル化されたサポートされていない限り、DSBMと相互運用することはできません。
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.
以下では、DSBMの初期化などのための提案を含む、SBMベースのアドミッション制御手順の実装のさまざまな側面に実装するためのガイドラインを提供します
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エンティティは、全リンク帯域幅のようなインターフェイスの帯域幅を想定しなければなりません。 L2スイッチに位置DSBMの場合には、さらに（参照することは、リンク帯域幅より小さい場合、デバイスのスイッチング容量の推定値を使用して構成する必要があり、おそらくスイッチのバッファリング資源の一部推定値を用いかもしれませんL2スイッチの想定建築モデルの[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は、1つ以上のセグメントのためのリソースを管理するために呼び出されると、実装は異なるL2トポロジーでDSBMの使用の心の効率への影響に耐えなければなりません。些細なL2トポロジーは、単一の「物理セグメント」から成ります。この場合は、「管理部門」は、単一のセグメントに相当します。複合L2トポロジーは、単一DSBMの観点から、単一の共有セグメントに類似リソースの単一プールから行うことができるよう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 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].
このノート昇給のセキュリティ上の問題で説明したメッセージのフォーマットと使用ルール、RSVPと統合サービスの使用によって発生したものと同じ。この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実装は、従来のRSVP実装しただけであるかのようにそのRFCの要件を満たし、提案のメカニズムを提供しなければなりません。さらに、メッセージ内の追加、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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC-RSVPMD5] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC-RSVPMD5]ベーカー、F.、リンデル、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]ベーカー、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.、ヤマウズラ、C.とR.ゲラン、 "保証されたサービスの質の仕様"、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.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC 2213] Baker, F. and J. Krawczyk, "Integrated Services Management Information Base", RFC 2213, September 1997.
[RFC 2213]ベイカー、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.、ペース、W.、スリニバサン、V.、スミス、A.とM.Seaman、 "共有にわたり統合サービスを提供するためのフレームワークとLAN技術交換"、RFC 2816、2000年5月を。
[RFC-MAP] Seaman, M., Smith, A. and E. Crawley, "Integrated Service Mappings on IEEE 802 Networks", RFC 2815, May 2000.
[RFC-MAP]シーマン、M.、スミス、A.とE.クローリー、 "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 15802-3決勝CD 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
A.1. Introduction
A.1。前書き
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ドメイン（すなわち、全体のL2ドメインの共有L2セグメントを想定）のための単一のDSBMがあると仮定する。その後、我々は、半二重または全二重セグメントを切り替えるため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の障害からの迅速な復旧を可能にするために、我々は、追加のSBMsは、フォールトトレランスのためのL2ドメインに有効であり得ることを前提としています。複数のSBMはL2ドメインでアクティブな場合、SBMsはL2ドメインのDSBMを選出する選挙アルゴリズムを使用します。 DSBMが選出され、運用された後に、他のSBMsは、必要なときに新しいDSBMを選出することでステップバックグラウンドで受動的なまま。 DSBMを選出し、発見するためのプロトコルは、「DSBM選挙プロトコル」と呼ばれ、この付録の残りの部分に記載されています。
A.1.1. How a DSBM Client Detects a Managed Segment
A.1.1。 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に自分のPATH / RESV（または他の）メッセージを送信DSBM（DSBMAddress）とDSBMクライアントのユニキャストIPアドレスを含んでいます。 DSBMクライアントがDSBMの障害を検出すると、それがDSBMとの通信を再開する前に、後続のI_AM_DSBM広告を待ちます。 DSBMが存在しない期間中、DSBMクライアントは、標準のRSVP転送ルールを使用して、発信PATHメッセージを転送することができます。
The exact message formats and addresses used for communication with (and among) SBM(s) are described in Appendix B.
SBM（S）と（との間で）通信するために使用される正確なメッセージフォーマットとアドレスは、付録Bに記載されています。
A.2. Overview of the DSBM Election Procedure
A.2。 DSBM選挙手順の概要
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が既にそのL2ドメイン内に存在するかどうかを確認するためにいくつかの期間に入ってくるDSBM広告をリッスンします。 1がすでに存在している（と新たな選挙が進行中でない）場合はDSBMの選定が必要になるまで、新しいSBMはバックグラウンドで静かなままです。 DSBM選挙とDSBM広告に関連するすべてのメッセージは常にAllSBMAddressに送信されます。
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候補とその「SBM優先」としてそのIPアドレスが表示されますDSBM_WILLINGメッセージを送信することによって、DSBMの選定を開始します。各SBMは、その相対的優先順位を決定する優先順位が割り当てられます。複数のSBM候補が存在する場合、SBMの優先順位は、候補者の相対的な優先順位に基づいてDSBMであることを誰が決定します。優先順位の値に基づいてタイがある場合は、ネクタイは、結ば候補（辞書順勝利で上位IPアドレスを持つ1）のIPアドレスを使用して壊れています。選挙プロトコルの詳細は、セクションA.4で開始します。
A.2.1 Summary of the Election Algorithm
選挙アルゴリズムのA.2.1概要
For the purpose of the algorithm, a SBM is in one of the four states (Idle, DetectDSBM, ElectDSBM, IAMDSBM).
アルゴリズムの目的のために、SBMは、4つの状態（アイドル、DetectDSBM、ElectDSBM、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を呼び出す）着信I_AM_DSBM（DSBM広告）またはDSBM_WILLINGメッセージにListenIntervalためDetectDSBM状態と待機中に開始されます。 I_AM_DSBM広告がこの状態の間に受信した場合、SBMは、現在のDSBM（そのIPアドレスと優先順位）を指摘し、アイドル状態に入ります。 DSBM_WILLINGメッセージがこの状態の間、別のSBM（Yそれを呼び出す）から受信される場合、XはElectDSBM状態に入ります。そう、DSBM_WILLINGメッセージを送信し、その後ElectDSBM状態に入った場合は、新しい状態に入る前に、X最初のチェックは、それ自体がYより良い候補であるかどうかを確認してします。
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それを呼び出す）がElectDSBM状態に入ると、それが終了すると最良の候補者が誰であるかを発見するために選挙を待つためのタイマ（ElectionIntervalTimerと呼ばれ、一般的にDSBMDeadInterval値に少なくとも等しい値に設定）を設定します。この状態では、Xは、（自身を含む）これまで見て最高の（またはそれ以上）候補者を追跡します。それは別のDSBM_WILLINGメッセージを受信するたびに、それは優先順位に基づいて最良の（またはそれ以上）候補のその概念を更新する（そしてタイブレーク）基準を。 ElectionInterval中、Xは、（再）をアサートその候補にDSBM_WILLINGメッセージごとにRefreshIntervalを送信します。
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).
ElectionIntervalの終わりには、Xは、それがこれまでの最高の候補であるかどうかをチェックします。もしそうなら、それは（I_AM_DSBM広告を送信することによって）DSBMであることを自分自身を宣言し、IAMDSBM状態になります。それ以外の場合は、最高の候補者が自身の勝者宣言するのを待つことにしました。待つこと、Xは、（各ラウンドはElectionTimerInterval時間続く）そのElectDSBM状態を再初期化し、選挙の別のラウンドを待ち続けます。
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広告をリッスンとDSBMの故障を検出するDSBMDeadIntervalTimerを使用します。広告が受信されるたびに、タイマーが再起動されます。タイマーが起動した場合、SBMは新しいDSBMを選出するために準備するDetectDSBM状態になります。 SBMは、この状態で電流DSBMからDSBM_WILLINGメッセージを受信した場合、SBMは、（独自の候補を発表する）DSBM_WILLINGメッセージを送信した後ElectDSBM状態に入ります。
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は、（正常終了）をシャットダウンすることを望む場合、それは選挙の手順を開始する（ゼロに設定SBMプライオリティ値を有する）DSBM_WILLINGメッセージを送出します。優先順位の値がゼロでは効果的に選挙の手続きからの発信DSBMを削除し、異なるDSBMの選定のための方法を作ります。
A.3. Recovering from DSBM Failure
A.3。 DSBM障害からの回復
When a DSBM fails (DSBMDeadIntervalTimer fires), all the SBMs enter the ElectDSBM state and start the election process.
DSBMは（DSBMDeadIntervalTimer火を）失敗した場合、すべてのSBMsはElectDSBM状態に入り、選挙プロセスを開始します。
At the end of the ElectionInterval, the elected DSBM sends out an I_AM_DSBM advertisement and the DSBM is then operational.
ElectionIntervalの終わりには、選出されたDSBMはI_AM_DSBM広告を送信し、DSBMは、動作しています。
A.4. DSBM Advertisements
A.4。 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とSBM優先（ - ネットワーク管理者によって指定された優先順位設定パラメータ）のIP及びL2アドレスを含みます。優先順位の値は、選挙のアルゴリズム中に候補SBMsの中から選択するために使用されます。より高い整数値は、より高い優先度を示し、値が範囲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を参照してください。
A.5. DSBM_WILLING Messages
A.5。メッセージをDSBM_WILLING
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_WILLINGメッセージを送信します。 DSBM_WILLINGメッセージには、次の情報が含まれます。
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の対応する優先度を含みます。
A.6. SBM State Variables
A.6。 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.
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）RefreshInterval。 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）ListenInterval - 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.
グラム秒）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で提供されています。
A.7. DSBM Election States
A.7。 DSBM選挙州
DOWN -- SBM is not operational.
DOWN - 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.
アイドル - 何の選挙が進行していない、それはDSBMないときにSBMがこの状態にあります。この状態で、SBMは、受動DSBMの状態を監視します。
ElectDSBM -- SBM is in this state when a DSBM election is in progress.
ElectDSBM - DSBM選挙が進行しているとき、SBMは、この状態にあります。
IAMDSBM -- SBM is in this state when it is the DSBM for the L2 domain.
IAMDSBM - SBMは、L2ドメインのDSBMであるとき、この状態になっています。
A.8. Events that cause state changes
A.8。状態変化を引き起こすイベント
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_WILLINGメッセージが受信された - これは、SBMは、いくつかの他のSBMからDSBM_WILLINGメッセージを受信したことを意味します。 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広告を送出するための時間であることを意味します。 ElectDSBM状態では、イベントは、別のDSBM_WILLINGメッセージを送信する時間であることを意味します。
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タイムアウト - ElectionIntervalTimerは解雇しました。これは、SBMは、それが成功したかどうかを判断するための立候補を宣言した後に十分な長待っていることを意味します。
A.9. State Transition Diagram (Figure 3)
A.9。状態遷移図（図3）
+-----------+
+--<--------------<-|DetectDSBM |---->------+
| +-----------+ |
| |
| |
| |
| +-------------+ +---------+ |
+->---| Idle |--<>---|ElectDSBM|--<--+
+-------------+ +---------+
| |
| |
| |
| +-----------+ |
+<<- +---| IAMDSBM |-<-+
| +-----------+
|
| +-----------+
+>>-| SHUTDOWN |
+-----------+
A.10. Election State Machine
A.10。選挙ステートマシン
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）は、 - 最初のパラメータによって表されるエンティティは、2つのパラメータの優先度情報とIPアドレス情報を使用して第2のエンティティよりも良好であるか否かを判定する。任意のアドレスがゼロの場合、そのエンティティは自動的に失います。最初の優先順位を比較します。優先順位の高い候補が勝利します。優先順位の値に基づいてタイがある場合は、ネクタイは、結ば候補（辞書順勝利で上位IPアドレスを持つ1）のIPアドレスを使用して壊れています。最初のエンティティがより良い選択である場合にTRUEを返します。そうでない場合はFALSE。
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
SendDSBMWillingメッセージ（）DSBM（OwnAddrと適切なフィールドに優先順位をコピー）開始RefreshIntervalTimer後藤ElectDSBM状態の終わりのための候補者として自分自身をリストDSBM_WILLINGメッセージを送る開始
AmIBetterDSBM(OtherAddrInfo) Begin if (ComparePrio(OwnAddrInfo, OtherAddrInfo)) return TRUE
（ComparePrio（OwnAddrInfo、OtherAddrInfo））がTRUEを返す場合AmIBetterDSBM（OtherAddrInfo）が開始します
change LocalDSBMInfo = OtherDSBMAddrInfo return FALSE End
変更LocalDSBMInfo = OtherDSBMAddrInfo FALSE終了を返します
UpdateDSBMInfo()
/* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */
Begin
update LocalDSBMInfo such as IP addr, DSBM L2 address,
DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer
End
A.10.1 State Changes
A.10.1状態の変更
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.
状態：DOWNイベント：スタートアップ新州立：DetectDSBMアクション：（LocalDSBMADDRとLocalDSBMAddrInfoが0に設定）、ローカル状態変数を初期化します。 ListenIntervalTimerを開始します。
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開始DeadDSBMIntervalタイマー後藤アイドル状態
State: DetectDSBM Event: ListenIntervalTimer fired New State: ElectDSBM Action: Start ElectionIntervalTimer SendDSBMWillingMessage();
状態：DetectDSBMイベント：ListenIntervalTimerは新しい状態を解雇：ElectDSBMアクション：スタートElectionIntervalTimer SendDSBMWillingMessage（）;
State: DetectDSBM Event: DSBM_WILLING message received New State: ElectDSBM Action: Cancel any active timers
状態：DetectDSBMイベント：DSBM_WILLINGメッセージは、新しい状態を受け取っ：ElectDSBMアクション：任意のアクティブなタイマーをキャンセル
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: 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
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
}
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キャンセル任意のアクティブなタイマーはDeadDSBMIntervalタイマー後藤アイドル状態を開始します
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
状態：ElectDSBMイベント：DSBM_WILLINGメッセージは、新しい状態を受け取っ：ElectDSBMアクション：それはループバックだかどうかをチェックし、もしそうなら、破棄し、継続; （！AmIBetterDSBM（IncomingDSBMAddrInfo））であれば{SendDSBMWillingMessage（）}現在の状態で継続（LocalDSBMAddrInfo == OwnAddrInfo）場合は、他の{変更LocalDSBMAddrInfo = IncomingDSBMAddrInfoがRefreshIntervalTimerをキャンセル}
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 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: 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イベント：DOWNアクションを：：新しい状態を自分自身をシャットダウンするに充填マイアドレスでDSBM_WILLINGメッセージを送信するが、優先順位はゼロ後藤ダウン状態に設定します
A.10.2 Suggested Values of Interval Timers
インターバルタイマーのA.10.2推奨値
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障害からの迅速な回復を確実にするため、およびエッジデバイスでPATHとRESV状態のタイムアウトを避けるために、長い期間のためのDSBMの停止を回避するために、我々は様々なタイマーの次の値を示唆しています。
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 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.
RSVP実装はPATHとRESVリフレッシュのために30秒のタイムアウトを使用すると仮定すると、我々はRefreshIntervalTimerはDSBMDeadIntervalTimerと約5秒と15秒に設定されるべきであることを示唆している（K = 3、K * RefreshInterval）。 DetectDSBMTimerは（DSBMDeadIntervalTimer、2 * DSBMDeadIntervalTimer）との間のランダムな値に設定されるべきです。 ElectionIntervalTimer各SBMは（ElectDSBM状態毎RefreshInterval送信）そのDSBM_WILLINGメッセージが他人に配信持っている可能性があることを確認するために、少なくともDSBMDeadIntervalTimerの値に設定されるべきです。
A.10.3. Guidelines for Choice of Values for SBM_PRIORITY
A.10.3。 SBM_PRIORITYのための値の選択のためのガイドライン
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_PRIORITYは、より高い優先度を示す高い整数値を（0〜255の範囲内の）8ビット符号なし整数値です。インターフェイスのためのゼロ値は、デバイス上の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.
値の別個の範囲は、L2 / L3デバイスの異なるクラス間の相対的な優先順位を反映するためにSBM可能なデバイスの種類毎に予約されています。 L2デバイスがホストに続くルーター続い高い優先度を取得します。 128..255の範囲の優先順位値がL2デバイスのために予約され、64..127の範囲内の値はルータのために予約され、そして1..63の範囲の値がホストのために予約されています。
A.11. DSBM Election over switched links
A.11。スイッチリンク上DSBM選挙
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持つすべてのフレームがそれらのデバイスにSBM管理エンティティに転送し、代わりに導かれないようにAllSBMAddress（その対応するMACマルチキャストアドレス）SBM可能な、レイヤ2つのデバイスの永久的なデータベースで構成されています。したがって、DSBMは、スイッチトポロジ内の各ポイントツーポイントセグメントに別々に選出することができます。例えば、図2において、「セグメントA」のDSBMは、R1とS1との間の選出アルゴリズムを使用して選出され、このセグメント上の選挙関連のメッセージのいずれも、「セグメントA」を超えS1によって転送されません。同様に、別の選挙は、このトポロジでは、各セグメントに行われます。
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.
スイッチドセグメントが半二重セグメントである場合、2つの送信者（リンクの各端に1つの送信者）は、リンクを共有します。この場合、2つの送信者の一つは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.
スイッチドセグメントが全二重である場合は、正確に一つの送信者は、各方向にリンクを送信します。この場合、1つまたは2つのDSBMsは、管理対象のセグメント上に存在することができます。各端の送信者がその目的のためのDSBMとして機能することを希望する場合は、I_AM_DSBM広告を送信することによってDSBMであることを自分自身を宣言し、セグメント上の発信トラフィックのためのリソースの管理を開始することができます。 2つの送信者のいずれかが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の実装に対する変更を最小限にし、RSVPに連動してSBMの迅速な配備、およびRSVPメッセージ形式と生IPカプセル化のための現在のルールを使用して構築メッセージを使用して実行されるDSBMからのすべての通信を確保します。 RSVPメッセージフォーマットの詳細については、RSVP仕様（RFC 2205）を参照。 RSVPメッセージフォーマットへの変更が提案されていないが、新しいメッセージタイプと新しいL2固有のオブジェクトはDSBM関連メッセージを収容するためにRSVPメッセージフォーマットに追加されます。これらの追加は、以下に記載されています。
B.1 Message Addressing
B.1メッセージのアドレス指定
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_WILLINGとI_AM_DSBMメッセージを送信中にDSBM選挙と検出の目的のために、AllSBMAddressは、宛先アドレスとして使用されます。 DSBMクライアントが最初に広告をI_AM_DSBMを聞くことによって、管理セグメントを検出し、DSBMAddress（DSBMのユニキャストIPアドレス）を記録します。
B.2. Message Sizes
B.2。メッセージのサイズ
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.
各メッセージは、1つのIPデータグラムを占有しなければなりません。それがMTUを超えた場合、そのようなデータグラムがIPによって断片化し、受信者ノードで再組み立てされます。これは、単一のメッセージが最大のIPデータグラムのサイズ、約64Kバイトを超えてはならない結果を有します。
B.3. RSVP-related Message Formats
B.3。 RSVP関連のメッセージフォーマット
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の実装は、以下に説明されている新しいオブジェクトクラスを認識しなければなりません。
B.3.1. Object Formats
B.3.1。オブジェクトフォーマット
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型を有します。すべての未使用のフィールドはゼロに設定し、領収書の上で無視されなければなりません。
B.3.2. SBM Specific Objects
B.3.2。 SBM特定のオブジェクト
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_LOOPBACK、及びRSVP_HOP_L2）のためのクラス民値はコードスペース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.
b) Objects of the form 101XXXXX are to be silently forwarded by SBM nodes that do not recognize them.
フォーム101XXXXXのb）のオブジェクトは、静かにそれらを認識していないSBMノードによって転送されます。
B.3.3. IEEE 802 Canonical Address Format
B.3.3。 IEEE 802正規アドレスフォーマット
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のメディア上の同じアドレスに関連付けられた数値は異なります。これらのアドレスのためのいわゆるカノニカルフォーマット - トークンリングとブリッジによって接続されたイーサネット接続されているシステムの両方にまたがる可能性が上位層プロトコルのアドレス値の通信を容易にするために、一つの基準フォーマットを定義する必要がありました。正式に標準フォーマットは、送信に使用される符号化規則とは別に、アドレスの値を定義します。それは次のように、元のワイヤの順序送信ビット順に由来オクテットの配列を含みます。最初のオクテットの最下位ビットが送信される最初のビットであり、そのため送信さ8ビットである最初のオクテットの最上位ビットへの次の最下位ビットの第2ビット。第2オクテットの最下位ビットは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アドレスが含まれているオブジェクトのオブジェクトフォーマットを定義します。
B.3.4. RSVP_HOP_L2 object
B.3.4。 RSVP_HOP_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を使用します。これは、上述のIEEE正規アドレスフォーマットで前ホップL3装置のL2アドレスを含みます。
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オブジェクト：クラス= 161、C-Typeが使用されるアドレッシング形式を表します。私たちの場合は、C-タイプ= 1はIEEE正規のアドレス形式を表します。
0 1 2 3
+---------------+---------------+---------------+----------------+
| Length | 161 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+
| Variable length Opaque data |
+---------------+---------------+---------------+----------------+
C-Type = 1 (IEEE Canonical Address format)
Cタイプ= 1（IEEE正規アドレスフォーマット）
When C-Type=1, the object format is:
場合Cタイプ= 1、オブジェクトの形式は次のとおりです。
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)
/// - 未使用（ゼロに設定）
B.3.5. LAN_NHOP object
B.3.5。 LAN_NHOPオブジェクト
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 |
+---------------+---------------+---------------+----------------+
C-Type = 1 (IEEE 802 Canonical Address Format as defined below) See the RSVP_HOP_L2 address object for more details.
Cタイプ= 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オブジェクト：クラス= 163、C-Typeが使用IPv4またはIPv6アドレスファミリを指定します。
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) |
+---------------------------------------------------------------+
B.3.6. LAN_LOOPBACK Object
B.3.6。 LAN_LOOPBACKオブジェクト
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_LOOPBACKオブジェクトは、PATHメッセージの発信インターフェイスのIPアドレスを与え、オブジェクトのクラス= 164を使用します。 IPv4とIPv6の両方の形式が指定されています。
IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1
IPv4のLAN_LOOPBACKオブジェクト：クラス= 164、C-タイプ= 1
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | 164 | 1 |
+---------------+---------------+---------------+---------------+
| IPV4 address of an interface |
+---------------+---------------+---------------+---------------+
IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2
IPv6のLAN_LOOPBACKオブジェクト：クラス= 164、C-タイプ= 2
+---------------+---------------+---------------+---------------+
| Length | 164 | 2 |
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPV6 address of an interface +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
B.3.7. TCLASS Object
B.3.7。 TCLASSオブジェクト
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Only 3 bits in data contain the user_priority value (PV).
データの唯一の3ビットはuser_priority値（PV）を含みます。
B.4. RSVP PATH and PATH_TEAR Message Formats
B.4。 RSVP PATHとPATH_TEARメッセージ形式
As specified in the RSVP specification, a PATH and PATH_TEAR messages contain the RSVP Common Header and the relevant RSVP objects.
RSVP仕様で指定されているように、PATHとPATH_TEARメッセージは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メッセージへの拡張は、追加のオブジェクトを含みます。
<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>]
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固有のオブジェクトは、常にセッションオブジェクトを前に置く必要があります。
B.5. RSVP RESV Message Format
B.5。 RSVP RESVメッセージフォーマット
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オブジェクトを含んでいてもよいです。
B.6. Additional RSVP message types to handle SBM interactions
B.6。 SBMの相互作用を処理するための追加のRSVPメッセージタイプ
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に結合するためにDSBMとRSVPノード（ホスト/ルータ）間の相互作用を可能にするために導入されます。次のように必要に応じて新しいRSVPメッセージの種類は次のとおりです。
RSVP Msg Type (8 bits) Value DSBM_WILLING 66 I_AM_DSBM 67
RSVPメッセージ種別（8ビット）値DSBM_WILLING 66 I_AM_DSBM 67
All SBM-specific messages are formatted as RSVP messages with an RSVP common header followed by SBM-specific objects.
全てSBM固有のメッセージは、SBM固有のオブジェクトが続くRSVP共通ヘッダとRSVPメッセージとしてフォーマットされています。
<SBMP_MESSAGE> ::= <SBMP common header> <SBM-specific objects>
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_WILLINGメッセージ
<DSBM_WILLING message> ::= <SBM Common Header> <DSBM IP ADDRESS>
<DSBM L2 address> <SBM PRIORITY>
I_AM_DSBM Message
I_AM_DSBMメッセージ
<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アドレスオブジェクト用途<クラス= 42、C-タイプ= 1>とIPv6 DSBM IPアドレスオブジェクト用途<クラス= 42、C-タイプ= 2>。
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アドレスオブジェクト：クラス= 42、C-タイプ= 2
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ 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アドレス>オブジェクトIEEE正規アドレスフォーマットのC型= 1 <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はNULL L2アドレスオブジェクトを含めることにより、このオブジェクトを省略してもよいです。 Cタイプ= 1（IEEE正規アドレスフォーマット）のために、L2アドレスオブジェクトのこのようなバージョンは、MACアドレス（正確な形式のセクションB.3.4を参照）に対応する6つのオクテットの値ゼロを含んでいます。
SBM_PRIORITY Object: class = 43, C-Type =1
SBM_PRIORITYオブジェクト：クラス= 43、C-タイプ= 1
0 1 2 3
+---------------+---------------+---------------+---------------+
| /// | /// | /// | SBM priority |
+---------------+---------------+---------------+---------------+
TIMER INTERVAL VALUES.
TIMER間隔値。
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.
2つのタイマーの間隔、すなわち、DSBMデッド間隔とDSBM更新間隔は、0..255秒の範囲の整数値としてそれぞれ指定されています。両方の値は、後述するシングル「DSBMタイマー間隔」オブジェクトに含まれています。
DSBM Timer Intervals Object: class = 44, C-Type =1
DSBMタイマ間隔オブジェクト：クラス= 44、C-タイプ= 1
+---------------+---------------+---------------+----------------+
| /// | /// | DeadInterval | RefreshInterval|
+---------------+---------------+---------------+----------------+
NON_RESV_SEND_LIMIT Object: class = 45, C-Type = 1
NON_RESV_SEND_LIMITオブジェクト：クラス= 45、C-タイプ= 1
0 1 2 3
+---------------+---------------+---------------+----------------+
| NonResvSendLimit(limit on traffic allowed to send without RESV)|
| |
+---------------+---------------+---------------+----------------+
<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オブジェクトは、送信側ホストは、（このオブジェクトの使用方法の詳細は、付録Cを参照）を有効RSVP予約なし管理セグメントに送信することを許可されたトラフィックのプロファイルにフローごとの制限を指定します。オブジェクトは、NonResvSendLimitパラメータが含まれています。このパラメータは、IntServのSENDER_TSPEC（コンテンツ及び符号化規則のためのRFC 2210を参照）に相当します。 SENDER_TSPECは、トラフィックプロファイル（R、B、P、MおよびM）を記述する5つのパラメータを含みます。送信ホストはSENDER_TSPECがDSBMによってアドバタイズSENDER_TSPECに送信者のトラフィックフローを記述した比較します。問題のトラフィックフローのSENDER_TSPECがDSBMによってアドバタイズSENDER_TSPEC以下であれば、代わりに、有効な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 =
ネットワーク管理者はNonResvSendLimitを構成することにより、RSVP予約の非存在下で任意送信されるトラフィックを禁止するDSBMを構成することができるここで、R = 0、B = 0、P = 0、M =無限大と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は、同様に、ネットワーク管理者は、すべてのトラフィックがNonResvSendLimitを構成することにより、RSVP予約が存在しない状態で送信することを可能にすることができるここで、R =無限、=無限、P =無限大、M = 0、M =無限大B。もちろん、これらのパラメータのいずれかが有限のフローごとの制限を宣伝するためにゼロと無限の間の値に設定することができます。
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).
NON_RESV_SEND_LIMITオブジェクトはオプションです。管理セグメント上の送信者は、（RSVP予約の不在下で任意のトラフィックプロファイルを送信するために許容される）無限大SENDER_TSPECと同等としてNON_RESV_SEND_LIMITオブジェクトが存在しないことを解釈しなければなりません。
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メッセージに添付オブジェクトとして分散させるようにするために、特に、それが可能です。次の設定オブジェクトは、この時点で定義されています。その他は、将来的に定義されてもよいです。 NON_RESV_SEND_LIMITオブジェクトに関する詳細については、付録Bを参照してください。
C.1. NON_RESV_SEND_LIMIT
C.1。 NON_RESV_SEND_LIMIT
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).
我々QoSはレイヤ2のセグメントを有効として、我々はDSBM及び802.1Pトラフィック分離の両方と（洗練されたスイッチによって切り替え専用セグメントからなるサブネットに、（トラフィック分離なしDSBMのない手段で）従来の共有セグメントからなるサブネットからの進化を期待します能力）。
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.
セグメントにわたるネットワーク管理者の制御を与えるだろう、この問題に対する1つの解決策は、彼らは予約を取得するまで、送信しない（アプリケーションの代わりに、またはオペレーティング・システム）アプリケーションを必要とすることです。ほとんどのアプリケーションは、すぐに彼らがしたいと、ネットワークがその時に付与することが可能であるものは何でもサービス品質を得ることを期待して送信するために使用されているので、これは問題があります。さらに、しばしば予約が受信される前に特定のアプリケーションが送信できるように許容され得ます。例えば、単一の10Mbpsイーサネットおよび10台のホストから成るセグメントには、3 Mbpsのビデオ・ストリーム16 Kbpsのテレフォニーストリームを送信できるように許容されなくてもよいです。
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 requested.
より実用的なソリューションは、その後、ネットワーク管理者は、送信者が有効な予約の不在で管理セグメント上に生成することが許可されている非適応トラフィック量のフローごとの上限を設定することができるようにすることです。この制限はDSBMによってアドバタイズとホストを送信することによって受信されます。送信側ホストのAPIは、要求されたリソースに基づいて、アプリケーションのQoS要求を承認または拒否することができます。
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.
NON_RESV_SEND_LIMITオブジェクトは、送信者がその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.
著者は、SBMの設計と上の彼らの建設的なコメントのためのエリック・クローリー（アルゴン）、ラスFenger（インテル）、デビッドMelman（シーメンス）、ラメシュPabbati（マイクロソフト）、ミック・シーマン（3COM）、アンドリュー・スミス（エクストリームネットワークス）に感謝していますこのドキュメントの以前のバージョン。
Raj Yavatkar Intel Corporation 2111 N.E. 25th Avenue, Hillsboro, OR 97124 USA
ラジYavatkarインテルコーポレーション2111 N.E.第25回アベニュー、ヒルズボロ、OR 97124 USA
Phone: +1 503-264-9077 EMail: yavatkar@ibeam.intel.com
電話：+1 503-264-9077電子メール：yavatkar@ibeam.intel.com
Don Hoffman Teledesic Corporation 2300 Carillon Point Kirkland, WA 98033 USA
ドン・ホフマンテレデシック株式会社2300カリヨンポイントカークランド、WA 98033 USA
Phone: +1 425-602-0000
電話：+1 425-602-0000
Yoram Bernet Microsoft 1 Microsoft Way Redmond, WA 98052 USA
よらｍ べｒねｔ みｃろそｆｔ １ みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うさ
Phone: +1 206 936 9568 EMail: yoramb@microsoft.com
電話：+1 206 936 9568 Eメール：yoramb@microsoft.com
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 USA
フレッドベイカーシスコシステムズ519ラドドライブサンタバーバラ、カリフォルニア93111 USA
Phone: +1 408 526 4257 EMail: fred@cisco.com
電話：+1 408 526 4257 Eメール：fred@cisco.com
Michael Speer Sun Microsystems, Inc 901 San Antonio Road UMPK15-215 Palo Alto, CA 94303
マイケル・シュペーア米国Sun Microsystems、Inc. 901サンアントニオの道UMPK15-215パロアルト、CA 94303
Phone: +1 650-786-6368 EMail: speer@Eng.Sun.COM
電話：+1 650-786-6368電子メール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。