[要約] RFC 2814は、IEEE 802スタイルのネットワーク上でのRSVPベースのアドミッション制御のためのSBM（サブネット帯域幅マネージャ）プロトコルについての規格です。このRFCの目的は、ネットワーク上のトラフィックを制御し、リソースの効果的な利用を可能にすることです。
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（Subnet Bandwidth Manager）：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.
Copyright（c）The Internet Society（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]で定義されています。ベストエフォルトサービス。これらの拡張機能には、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].
このドキュメントでは、IEEE 802スタイルのネットワークに対するRSVPベースの入場制御のシグナル伝達プロトコルであるSBMを定義しています。SBMは、RSVPなどのインターネットレベルのセットアッププロトコルをIEEE 802スタイルネットワークにマッピングする方法を提供します。特に、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:
IEEE 802レベル2ネットワークのSBM（Subnet Bandwidth Manager）プロトコルとその使用への使用は、次のアーキテクチャの目標と仮定に基づいています。
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定義のトラフィックコントロールを組み合わせて、IEEE 802スタイルのLANに制御された負荷（および保証された）サービスの近似を実現できます。
III. In the absence of any link-layer traffic control or priority queuing mechanisms in the underlying LAN (such as a shared LAN segment), the SBM-based admission control mechanism only limits the total amount of traffic load imposed by RSVP-enabled flows on a shared LAN. In such an environment, no traffic flow separation mechanism exists to protect the RSVP-enabled flows from the best-effort traffic on the same shared media and that raises the question of the utility of such a mechanism outside a topology consisting only of 802.1p-compliant switches. However, we assume that the SBM-based admission control mechanism will still serve a useful purpose in a legacy, shared LAN topology for two reasons. First, assuming that all the nodes that generate Integrated Services traffic flows utilize the SBM-based admission control procedure to request reservation of resources before sending any traffic, the mechanism will restrict the total amount of traffic generated by Integrated Services flows within the bounds desired by a LAN administrator (see discussion of the NonResvSendLimit parameter in Appendix C). Second, the best-effort traffic generated by the TCP/IP-based traffic sources is generally rate adaptive (using a TCP-style "slow start" congestion avoidance mechanism or a feedback-based rate adaptation mechanism used by audio/video streams based on RTP/RTCP protocols) and adapts to stay within the available network bandwidth. Thus, the combination of admission control and rate adaptation should avoid persistent traffic congestion. This does not, however, guarantee that non-Integrated-Services traffic will not interfere with the Integrated Services traffic in the absence of traffic control support in the underlying LAN infrastructure.
iii。基礎となるLAN（共有LANセグメントなど）のリンク層トラフィックコントロールまたは優先順位のキューイングメカニズムがない場合、SBMベースの入学制御メカニズムは、RSVP対応フローによって課されるトラフィック負荷の総量を制限するだけです。共有LAN。このような環境では、同じ共有メディアのベストエフォルトトラフィックからRSVP対応の流れを保護するための交通流分離メカニズムは存在しません。準拠したスイッチ。ただし、SBMベースの入学制御メカニズムは、2つの理由でLANトポロジを共有するレガシーにおいて有用な目的に役立つと想定しています。第一に、統合サービストラフィックフローを生成するすべてのノードが、トラフィックを送信する前にリソースの予約を要求するためにSBMベースの入場制御手順を利用すると仮定すると、メカニズムは、統合されたサービスフローによって生成されるトラフィックの合計量を制限します。LAN管理者（付録Cの非Resvsendlimitパラメーターの説明を参照）。第二に、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では、最初にドキュメントで使用されているさまざまな用語を定義し、次にサンプルネットワークへのアプリケーションの例を使用して、入場制御手順の概要を示します。
* 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マネージャーに指定）、SBMS、およびDSBMクライアントでのパス（および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でRSVPシグナル伝達がない場合、またはLANセグメントのリソースを予約するために別のシグナル伝達プロトコル（SNMPなど）が使用される場合に、DSBMが動作する場合に操作性間の問題に対処します。
* Appendix A describes the details of the DSBM election algorithm used for electing a designated SBM on a LAN segment when more than one SBM is present. It also describes how DSBM clients discover the presence of a DSBM on a managed segment.
* 付録Aでは、複数のSBMが存在する場合、LANセグメントで指定されたSBMを選択するために使用されるDSBM選挙アルゴリズムの詳細について説明します。また、DSBMクライアントがマネージドセグメントでDSBMの存在を発見する方法についても説明しています。
* Appendix B specifies the formats of SBM-specific messages used and the formats of new RSVP objects needed for the SBM operation.
* 付録Bは、使用されるSBM固有のメッセージの形式と、SBM操作に必要な新しいRSVPオブジェクトの形式を指定します。
* Appendix C describes usage of the DSBM to distribute configuration information to senders on a managed segment.
* 付録Cでは、管理されたセグメントの送信者に構成情報を配布するためのDSBMの使用について説明します。
- Link Layer or Layer 2 or L2: We refer to data-link layer technologies such as IEEE 802.3/Ethernet as L2 or layer 2.
- リンクレイヤーまたはレイヤー2またはL2：IEEE 802.3/イーサネットなどのデータリンクレイヤーテクノロジーをL2またはレイヤー2と呼びます。
- Link Layer Domain or Layer 2 domain or L2 domain: a set of nodes and links interconnected without passing through a L3 forwarding function. One or more IP subnets can be overlaid on a L2 domain.
- リンクレイヤードメインまたはレイヤー2ドメインまたはL2ドメイン：L3転送機能を通過せずに相互接続されたノードとリンクのセット。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機能のみをレイヤー2またはL2デバイスとして実装するデバイスを参照します。これらには、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.
- ISO 7レイヤーモデルのインターネットワークレイヤーまたはレイヤー3またはL3：レイヤー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.
- セグメント：1人以上の送信者が共有するL2物理セグメント。セグメントの例には、（a）CSMAまたはトークンパスを使用したメディアアクセスのための共有イーサネットまたはトークンリングワイヤー解決競合（「共有L2セグメント」）、（b）2つのステーションまたはスイッチの間の半分のデュプレックスリンク、（c）1つ切り替えられた全二重リンクの方向。
- 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サービスを使用して、データとともに受信機に提供されます。実際にネットワーク上に持ち込まれている場合とそうでない場合があります。Token-ring/802.5は、この値（FC Octetでエンコード）、基本的なイーサネット/802.3は、使用中のフレーム形式に依存しない場合とそうでない場合があります。802.1pは、拡張フレーム形式を使用して、イーサネット、トークンリング、需要優先性、FDDI、またはその他のMac層メディアのブリッジ型ネットワーク上でこの値を運ぶ一貫した方法を定義します。user_priorityの使用法は、802.1D [IEEE8021D]および802.1p [IEEE8021p]のセクション2.5で完全に説明されています。「特定のMACプロシージャによる内部層サービスのサポート」。
- 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.
- サブネット：このメモで使用されて、共通のL3ネットワークアドレスのプレフィックスを共有するL3デバイスのグループと、それらが配置されているL2ドメインを構成するセグメントのセットを示す。
- 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が存在する場合、SBMの1つが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透明デバイス：「SBM透過性」デバイスは、SBMまたはDSBMを認識していません（ただし、RSVPが認識している場合とそうでない場合があります）。このようなデバイスは、デバイスに適した標準転送ルールを使用し、SBMに関して透過的です。このようなL2デバイスの例は、リソース予約に参加しないレガシースイッチです。
- Layer 3 and layer 2 addresses: We refer to layer 3 addresses of L3/L2 devices as "L3 addresses" and layer 2 addresses as "L2 addresses". This convention will be used in the rest of the document to distinguish between Layer 3 and layer 2 addresses used to refer to RSVP next hop (NHOP) and previous hop (PHOP) devices. For example, in conventional RSVP message processing, RSVP_HOP object in a PATH message carries the L3 address of the previous hop device. We will refer to the address contained in the RSVP_HOP object as the RSVP_HOP_L3 address and the corresponding MAC address of the previous hop device will be referred to as the RSVP_HOP_L2 address.
- レイヤー3とレイヤー2アドレス：L3/L2デバイスのレイヤー3アドレスを「L3アドレス」と呼び、レイヤー2アドレスは「L2アドレス」と呼びます。この規則は、RSVP Next Hop（NHOP）と以前のホップ（PHOP）デバイスを参照するために使用されるレイヤー3とレイヤー2アドレスを区別するために、ドキュメントの残りの部分で使用されます。たとえば、従来のRSVPメッセージ処理では、パスメッセージ内のRSVP_HOPオブジェクトには、以前のホップデバイスのL3アドレスが含まれます。RSVP_HOPオブジェクトに含まれるアドレスをRSVP_HOP_L3アドレスとして参照し、以前のホップデバイスの対応するMACアドレスはRSVP_HOP_L2アドレスと呼ばれます。
A protocol entity called "Designated SBM" (DSBM) exists for each managed segment and is responsible for admission control over the resource reservation requests originating from the DSBM clients in that segment. Given a segment, one or more SBMs may exist on the segment. For example, many SBM-capable devices may be attached to a shared L2 segment whereas two SBM-capable switches may share a half-duplex switched segment. In that case, a single DSBM is elected for the segment. The procedure for dynamically electing the DSBM is described in Appendix A. The only other approved method for specifying a DSBM for a managed segment is static configuration at SBM-capable devices.
「指定されたSBM」（DSBM）と呼ばれるプロトコルエンティティは、各管理セグメントに存在し、そのセグメントのDSBMクライアントから発信されるリソース予約要求の入場制御を担当します。セグメントを考えると、セグメントに1つ以上のSBMが存在する場合があります。たとえば、多くのSBM対応デバイスが共有L2セグメントに接続される場合がありますが、2つのSBM対応スイッチは半分二重スイッチセグメントを共有する場合があります。その場合、単一の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の存在により、セグメントは「管理されたセグメント」になります。場合によっては、2つ以上の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は、その制御下にある各管理セグメントで予約できる利用可能なリソースの割合の制限などの情報を取得します。たとえば、帯域幅はそのようなリソースの1つです。リンク速度の自動ネゴシエーションやリンクトポロジの知識などの方法により、リンク容量の発見が可能になりますが、リンクで予約できるリンク容量の割合を制限するために構成が必要になる場合があります。現在の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の存在を発見および検証する手順については、付録Aに説明します。クライアント自体がセグメントでDSBMとして機能する場合、DSBMになるために選挙に参加することを選択できます。最初に、DSBMクライアントは、最初にDSBMがL2ドメインに存在することを確認し、入場管理の目的でDSBMと通信できるようにします。
In the case of a full-duplex segment, an election may not be necessary as the SBM at each end will typically act as the DSBM for outgoing traffic in each direction.
全二重セグメントの場合、各端のSBMは通常、各方向の発信トラフィックのDSBMとして機能するため、選挙は必要ない場合があります。
3. DSBM-based Admission Control: To request reservation of resources (e.g., LAN bandwidth in a L2 domain), DSBM clients (RSVP-capable L3 devices such as hosts and routers) follow the following steps:
3. DSBMベースの入場制御：リソースの予約（L2ドメインのLAN帯域幅など）を要求するには、DSBMクライアント（ホストやルーターなどのRSVP対応L3デバイス）に次の手順に従います。
a) When a DSBM client sends or forwards a RSVP PATH message over an interface attached to a managed segment, it sends the PATH message to the segment's DSBM instead of sending it to the RSVP session destination address (as is done in conventional RSVP processing). After processing (and possibly updating an ADSPEC), the DSBM will forward the PATH message toward its destination address. As part of its processing, the DSBM builds and maintains a PATH state for the session and notes the previous L2/L3 hop that sent it the PATH message.
a) DSBMクライアントが、管理されたセグメントに接続されたインターフェイスにRSVPパスメッセージを送信または転送すると、RSVPセッションの宛先アドレスに送信する代わりに、セグメントのDSBMにパスメッセージを送信します（従来のRSVP処理で行われます）。処理した後（およびADSPECの更新）、DSBMは宛先アドレスにパスメッセージを転送します。処理の一環として、DSBMはセッションのパス状態を構築および維持し、パスメッセージを送信する以前のL2/L3ホップに注意します。
Let us consider the managed segment in Figure 1. Assume that a sender to a RSVP session (session address specifies the IP address of host A on the managed segment in Figure 1) resides outside the L2 domain of the managed segment and sends a PATH message that arrives at router R1 which is on the path towards host A.
図1の管理セグメントを考えてみましょう。RSVPセッションへの送信者（セッションアドレスは、図1のマネージドセグメントのホストAのIPアドレスを指定します）が、管理されたセグメントのL2ドメインの外側にあり、パスメッセージを送信するそれはホスト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.
Router R1のDSBMクライアントは、送信者からDSBMにパスメッセージを転送します。DSBMはパスメッセージを処理し、パスメッセージをRSVPレシーバーに転送します（詳細なメッセージ処理と転送ルールはセクション5で説明されています）。その過程で、DSBMはパス状態を構築し、セッションの前のホップとしてルーターR1（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.
b) ホストのアプリケーションがRSVPセッションの予約を希望する場合、ホストAは標準のRSVPメッセージ処理ルールに従い、PHOPオブジェクトから取得した以前のHOP L2/L3アドレス（DSBMSアドレス）にRSVP RESVメッセージを送信します。s）以前に受信したパスメッセージ。
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メッセージを処理し、リクエストが許可できない場合はREQUESTER（ホストA）にRESV_ERRメッセージを返します。十分なリソースが利用可能であり、予約リクエストが許可された場合、DSBMはセッションのローカルパス状態に基づいてRESVメッセージをPHOPに転送します。DSBMは、従来のRSVP処理で使用されているルールと同様のルールを使用して、可能な場合と同じセッションの予約要求をマージします（セクション5.8で説明されている追加の基準を除く）。
d) If the L2 domain contains more than one managed segment, the requester (host A) and the forwarder (router R1) may be separated by more than one managed segment. In that case, the original PATH message would propagate through many DSBMs (one for each managed segment on the path from R1 to A) setting up PATH state at each DSBM. Therefore, the RESV message would propagate hop-by-hop in reverse through the intermediate DSBMs and eventually reach the original forwarder (router R1) on the L2 domain if admission control at all DSBMs succeeds.
d) L2ドメインに複数のマネージドセグメントが含まれている場合、リクエスター（ホストA）とフォワーダー（ルーターR1）は、複数のマネージドセグメントで分離できます。その場合、元のパスメッセージは、各DSBMに多くのDSBMを介して伝播します（R1からaまでのパス上のマネージドセグメントごとに1つ）各DSBMでパス状態を設定します。したがって、RESVメッセージは、中間DSBMSを介してホップバイホップを逆に伝播し、最終的にすべてのDSBMSが成功した場合、L2ドメインの元のフォワーダー（Router 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).
通常のRSVP転送ルールは、管理されたセグメントに発信パスメッセージを転送していない場合、DSBMクライアントに適用されます。ただし、マネージドセグメントの発信パスメッセージは、対応するマネージドセグメントのDSBMに送信されます（セクション5.2では、パスメッセージが管理されたセグメントのDSBMに送信される方法について説明します）。
In conventional RSVP processing over point-to-point links, RSVP nodes (hosts/routers) use RSVP_HOP object (NHOP and PHOP info) to keep track of the next hop (downstream node in the path of data packets in a traffic flow) and the previous hop (upstream nodes with respect to 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情報）を使用して、次のホップ（トラフィックフローのデータパケットの下流ノード）と送信者と受信機の間のパス上の以前のホップ（データフローに関する上流ノード）ノード。パスメッセージのパスに沿ったルーターは、L3ルーティング（パケット転送）テーブルに基づいて、宛先アドレスに向かってメッセージを前方に進みます。
For example, consider the L2 domain in Figure 1. Assume that both the sender (some host X) and the receiver (some host Y) in a RSVP session reside outside the L2 domain shown in the Figure, but PATH messages from the sender to its receiver pass through the routers in the L2 domain using it as a transit subnet. Assume that the PATH message from the sender X arrives at the router R1. R1 uses its local routing information to decide which next hop router (either router R2 or router R3) to use to forward the PATH message towards host Y. However, when the path traverses a managed L2 domain, we require the PATH and RESV messages to go through a DSBM for each managed segment. Such a L2 domain may span many managed segments (and DSBMs) and, typically, SBM protocol entities on L2 devices (such as a switch) will serve as the DSBMs for the managed segments in a switched topology. When R1 forwards the PATH message to the DSBM (an L2 device), the DSBM may not have the L3 routing information necessary to select the egress router (between R2 and R3) before forwarding the PATH message. To ensure correct operation and routing of RSVP messages, we must provide additional forwarding information to DSBMs.
たとえば、図1のL2ドメインを検討してください。RSVPセッションの送信者（ホストX）と受信機（ホストY）の両方が、図に示されているL2ドメインの外側にあるが、送信者からのパスメッセージがそのレシーバーは、L2ドメインのルーターを通過し、トランジットサブネットとして使用します。送信者XからのパスメッセージがルーターR1に到着すると仮定します。R1はローカルルーティング情報を使用して、次のホップルーター（ルーターR2またはルーターR3のいずれか）を決定して、ホストYにパスメッセージを転送するために使用します。ただし、パスが管理されたL2ドメインを通過すると、パスとRESVメッセージが必要です。管理されたセグメントごとにDSBMを通過します。このようなL2ドメインは、多くの管理されたセグメント（およびDSBMS）にまたがる可能性があり、通常、L2デバイス（スイッチなど）のSBMプロトコルエンティティは、スイッチトポロジの管理されたセグメントのDSBMSとして機能します。R1がパスメッセージをDSBM（L2デバイス）に転送すると、DSBMは、パスメッセージを転送する前に、出力ルーター（R2とR3の間）を選択するために必要なL3ルーティング情報を持たない場合があります。RSVPメッセージの正しい操作とルーティングを確保するには、DSBMSに追加の転送情報を提供する必要があります。
For this purpose, we introduce new RSVP objects called LAN_NHOP address objects that keep track of the next L3 hop as the PATH message traverses an L2 domain between two L3 entities (RSVP PHOP and NHOP nodes).
この目的のために、パスメッセージが2つのL3エンティティ（RSVP PHOPとNHOPノード）の間で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クライアント（ホストまたはパスメッセージのオリジネーターとして機能するルーター）がDSBMにパスメッセージを送信する場合、メッセージにLAN_NHOP情報を含める必要があります。ユニキャストの宛先の場合、LAN_NHOPアドレスは、宛先アドレス（宛先がL2ドメインのローカルである場合）または宛先に向かう次のホップルーターのアドレスを指定します。Transit Subnetとして機能する図1のL2ドメインを含む送信者XおよびレシーバーYを含むRSVPセッションの例では、R1はパスメッセージを受信するイングレスノードです。R1は、最初にR2が次のホップルーター（またはセッションアドレスのL2ドメインの出力ノード）であることを決定し、次にR2のIPアドレスを指定するLAN_NHOPオブジェクトを挿入します。DSBMがパスメッセージを受信すると、LAN_NHOPオブジェクトのアドレスを見て、パスメッセージを処理した後に出口ノードにパスメッセージを転送できます。ただし、L2デバイス（スイッチなど）がL2ドメイン内のパス上でDSBMSとして機能すると予想されており、これらのデバイスがMACアドレスを決定するARP機能を備えていることを期待することは合理的ではない場合があります（レイヤー用L2ADDRと呼びます2アドレス）LAN_NHOPオブジェクトのIPアドレスに対応しています。
Therefore, we require that the LAN_NHOP information (generated by the L3 device) include both the IP address (LAN_NHOP_L3 address) and the corresponding MAC address (LAN_NHOP_L2 address ) for the next L3 hop over the L2 domain. The LAN_NHOP_L3 address is used by SBM protocol entities on L3 devices to forward the PATH message towards its destination whereas the L2 address is used by the SBM protocol entities on L2 devices to determine how to forward the PATH message towards the L3 NHOP (egress point from the L2 domain). The exact format of the LAN_NHOP information and relevant objects is described later in Appendix B.
したがって、LAN_NHOP情報（L3デバイスによって生成された）には、L2ドメイン上の次のL3ホップのIPアドレス（LAN_NHOP_L3アドレス）と対応するMACアドレス（LAN_NHOP_L2アドレス）の両方を含める必要があります。LAN_NHOP_L3アドレスは、L3デバイス上のSBMプロトコルエンティティによって使用されて宛先にパスメッセージを転送するために使用されますが、L2アドレスはL2デバイス上のSBMプロトコルエンティティで使用され、L3 NHOP（Egress Pointからのパスメッセージを転送する方法を決定します。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パスメッセージを受信すると、RSVP仕様で説明されているパス処理ルールに従ってパスメッセージを処理します。特に、DSBMは、パスメッセージ内のRSVP_HOPオブジェクトから前のホップのIPアドレスを取得し、そのパス状態にPHOPアドレスを保存します。次に、パスメッセージを、独自のIPアドレス（rsvp_hop_l3アドレス）を反映するように変更されたphop（rsvp_hop）オブジェクトで転送されます。したがって、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ノード間のホップとして自分自身を挿入するため、すべてのRSVP関連のメッセージ（PATH、PATH_TEAR、RESV、RESV_CONF、RESV_TEAR、RESV_ERRなど）がDSBMを通過するようになりました。特に、PATH_TEARメッセージが転送される前に、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.
- これまでのところ、パスの管理されたセグメントに沿って各DSBMにパスドメインを介してパスメッセージがどのように伝播するかを説明しました。LAN_NHOPオブジェクトのレイヤー2アドレス（LAN_NHOP_L2アドレス）は、パスに沿ってL2デバイスで使用して、次のL3ホップにパスメッセージを転送する方法を決定する必要があります。このようなデバイスは、標準のIEEE 802.1D転送ルールを適用します（たとえば、フィルタリングデータベースに基づいて単一のポートに送信するか、L2アドレスがフィルタリングデータベースに表示されない場合はスパニングツリーのすべてのポートにあふれます）LAN_NHOP_L2アドレスは、アドレスに向けられたデータパケットに通常適用されます。
In the conventional RSVP message processing, the PATH state established along the nodes on a path is used to route the RESV message from a receiver to a sender in an RSVP session. As each intermediate node builds the path state, it remembers the previous hop (stores the PHOP IP address available in the RSVP_HOP object of an incoming message) that sent it the PATH message and, when the RESV message arrives, the intermediate node simply uses the stored PHOP address to forward the RESV after processing it successfully.
従来のRSVPメッセージ処理では、パス上のノードに沿って確立されたパス状態を使用して、RSVPセッションでレシーバーから送信者にRESVメッセージをルーティングします。各中間ノードがパス状態を構築すると、パスメッセージを送信する前のホップ（入ってくるメッセージのRSVP_HOPオブジェクトに使用可能なPHOP IPアドレスを保存）を覚えています。RESVを正常に処理した後、RESVを転送するために保存されたPHOPアドレス。
In our case, we expect the SBM entities residing at L2 devices to act as DSBMs (and, therefore, intermediate RSVP hops in an L2 domain) along the path between a sender (PHOP) and receiver (NHOP). Thus, when a RESV message arrives at a DSBM, it must use the stored PHOP IP address to forward the RESV message to its previous hop. However, it may not be reasonable to expect the L2 devices to have an ARP cache or the ARP capability to map the PHOP IP address to its corresponding L2 address before forwarding the RESV message.
私たちの場合、L2デバイスに居住するSBMエンティティは、送信者（PHOP）とレシーバー（NHOP）の間のパスに沿ってDSBMS（したがって、L2ドメインで中間RSVPホップ）として機能することを期待しています。したがって、RESVメッセージがDSBMに到着すると、保存されたPHOP IPアドレスを使用して、RESVメッセージを以前のホップに転送する必要があります。ただし、L2デバイスがARPキャッシュまたはARP機能に、RESVメッセージを転送する前に対応するL2アドレスにPHOP IPアドレスをマッピングすることを期待することは合理的ではない場合があります。
To obviate the need for such address mapping at L2 devices, we use a RSVP_HOP_L2 object in the PATH message. The RSVP_HOP_L2 object includes the Layer 2 address (L2ADDR) of the previous hop and complements the L3 address information included in the RSVP_HOP object (RSVP_HOP_L3 address).
L2デバイスでのこのようなアドレスマッピングの必要性を回避するには、パスメッセージで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デバイスが管理されたセグメントにパスメッセージを構築および転送する場合、RSVP_HOPオブジェクトにIPアドレス（パスが送信されるインターフェイスのIPアドレス）が含まれ、インターフェイスの対応するL2アドレスを含むRSVP_HOP_L2オブジェクトを追加します。。L2ドメイン内のデバイスがそのようなパスメッセージを受信すると、パス状態のRSVP_HOPおよびRSVP_HOP_L2オブジェクトのアドレスを覚えています。その後、RSVP_HOPとRSVP_HOP_L2オブジェクトを、マネージドセグメントに通うメッセージを転送する前に、独自のアドレスで独自のアドレスを上書きします。
The exact format of RSVP_HOP_L2 object is specified in Appendix B.
RSVP_HOP_L2オブジェクトの正確な形式は、付録Bで指定されています。
When an RSVP session address is a multicast address and a SBM, DSBM, and DSBM clients share the same L2 segment (a shared segment), it is possible for a SBM or a DSBM client to receive one or more copies of a PATH message that it forwarded earlier when a DSBM on the same wire 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セグメント（共有セグメント）を共有する場合、SBMまたはDSBMクライアントがパスメッセージの1つ以上のコピーを受け取ることができます。同じワイヤーのDSBMが前方に転送されたときに先に転送されました（そのような場合の例については、セクション5.7を参照）。このようなループの検出を容易にするために、LAN_Loopbackオブジェクトと呼ばれる新しいRSVPオブジェクトを使用します。DSBMクライアントまたはSBMS（ただし、以前に到着したインターフェイスへのパスメッセージを反映するDSBMSは上書きしなければなりません（または、パスメッセージに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クライアントは、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は、さまざまなトラフィッククラスを表すパケットでエンコードされたいくつかの「user_priority」値をスイッチを区別する方法を定義します（詳細については[IEEE802Q、IEEE8021p]を参照）。user_priority値は、ネイティブLANパケット（IEEE 802.5のFCオクテットなど）のいずれかでエンコードできます。IEEE 802.1Q [IEEE8021Q]で定義された新しい拡張フレーム形式を使用したフレームヘッダー。ただし、IEEEは、送信者またはネットワークが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.
統合サービスモデルでは、トラフィックフローをL2セグメントに送信するL3（またはそれ以上の）エンティティは、フローあたりのポリシングを実行して、入場制御中にフローが指定されているようにトラフィック仕様を超えないようにする必要があります。さらに、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 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.
この議論の目的のために、拡張フレームヘッダーにあるuser_priority値をパケットの「トラフィッククラス」と呼びます。ISSLLモデルでは、トラフィックを送信し、SBMプロトコルを使用するL3エンティティは、発信パケットの適切なトラフィッククラス[RFC-Map]を選択できます。この選択は、次の方法でDSBMデバイスによってオーバーライドされる場合があります。送信者がパスメッセージを送信すると、下流のDSBMSは、次のL3デバイス（パスメッセージのL3 NHOP）に移動するパスメッセージに新しいトラフィッククラスオブジェクト（TCLASSオブジェクト）を挿入します。ある程度、TCLASSオブジェクトの内容は、RSVPパスメッセージのADSPECオブジェクトのように扱われます。パスメッセージを受信するL3デバイスは、セッションのパス状態の一部としてTCLASSオブジェクトを削除および保存する必要があります。その後、同じL3デバイスがRSVP RESVメッセージを元の送信者に転送する必要がある場合、RESVメッセージにTCLASSオブジェクトを含める必要があります。RESVメッセージが元の送信者に到着すると、送信者はTCLASSオブジェクトのuser_priority値を使用して、発信パケットにマークされたトラフィッククラスの選択をオーバーライドする必要があります。
The format of the TCLASS object is specified in Appendix B. Note that TCLASS and other SBM-specific objects are carried in a RSVP message in addition to all the other, normal RSVP objects per RFC 2205.
TCLASSオブジェクトの形式は、付録Bに指定されています。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オブジェクトが含まれていない場合、DSBMは転送する前にパスメッセージに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オブジェクトを含むパスメッセージを受信し、同じL2ドメインのマネージドセグメントに転送する必要がある場合、パス状態に保存し、通常はメッセージを転送する必要があります。TCLASSオブジェクトの内容。ただし、DSBM/SBMがパスメッセージ内のTCLASSオブジェクトによって指定されたユーザー_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.]
[注：付随するドキュメントは、IEEE 802ネットワーク[RFC-MAP]を介したINT-SERVマッピングを定義しています[RFC-MAP]は、user_priority値の正確な定義を提供し、2つの値の「低い」または「最低」の「低い」を決定するためにuser_priority値がどのように比較されるかを説明します。すべての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メッセージの通常のFlowsPec情報に加えて）を使用する場合があります。
Note that this document does not specify the actual algorithm or policy used for admission control. At one extreme, a DSBM may use per-flow reservation request as specified by the flowspec for a fine grain admission control. At the other extreme, a DSBM may only consider the traffic class information for a very coarse-grain admission control based on some static allocation of link capacity for each traffic class. Any combination of the options represented by these two extremes may also be used.
このドキュメントでは、入場管理に使用される実際のアルゴリズムまたはポリシーは指定されていないことに注意してください。極端な場合、DSBMは、細かい粒微粒のコントロールのためにFlowsPecで指定されたフローごとの予約リクエストを使用する場合があります。もう1つの極端な場合、DSBMは、各トラフィッククラスのリンク容量の静的な割り当てに基づいて、非常に粗い粒微粒型の入場制御のトラフィッククラス情報のみを考慮することができます。これらの2つの極端に表されるオプションの任意の組み合わせも使用できます。
* 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.
* DSBMクライアント（ホストやエッジルーターなどのL3デバイスに住む）が、インターフェイス上で受け入れるパスメッセージでTCLASSオブジェクトを受信する場合、TCLASSオブジェクトをインターフェイスのパス状態の一部として保存する必要があります。後で、クライアントがインターフェイス上の同じセッションのRESVメッセージを転送する場合、クライアントは、インターフェイス上で転送するRESVメッセージにTCLASSオブジェクト（前のパスメッセージで受信したものから変更されていない）を含める必要があります。
* When a DSBM client receives a TCLASS object in an incoming RESV message over a managed segment and local admission control succeeds for the session for the outgoing interface over the managed segment, the client must pass the user_priority value in the TCLASS object to its local packet classifier. This will ensure that the data packets in the admitted RSVP flow that are subsequently forwarded over the outgoing interface will contain the appropriate value encoded in their frame header.
* DSBMクライアントがマネージドセグメントを介して着信RESVメッセージでTCLASSオブジェクトを受信し、マネージドセグメント上の発信インターフェイスのセッションでローカルアミズレーションコントロールが成功する場合、クライアントはTCLASSオブジェクトのユーザー_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デバイスが1つのL2ドメインの管理セグメントを介してパスまたはRESVメッセージを受信し、そのドメインの外側のインターフェイスにパス/RESVメッセージを転送する必要がある場合、L3デバイスはTCLASSオブジェクトを削除する必要があります（LAN_NHOP、RSVP_HOP_L2、パス/RESVメッセージを転送する前に、パスメッセージの場合の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.
前述のように、DSBMクライアントは、パスの次のL3ホップに到達する前に、L2ドメインのDSBMSにRSVPパスメッセージを転送することを要求します。RSVPパスメッセージは、RFC-2205に従って宛先アドレス（IPユニキャストまたはマルチキャストアドレスのいずれか）にアドレス指定されます。L2デバイスがDSBMをホストする場合、デバイスがL3 RSVPメッセージをスヌープする必要なく、着信パスメッセージをキャプチャしてローカル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デバイスでのパスメッセージの簡単な検出とキャプチャを可能にするために、物理アドレスではなく論理アドレスを使用してDSBMにアドレス指定する必要があります。DSBMとの通信を目的として、予約済みのIPマルチキャストアドレス（ES）を使用します。特に、DSBMクライアントまたはSBMが管理されたセグメントよりもパスメッセージを転送する場合、予約されたIPマルチキャストアドレスにアドレス指定される必要があります。したがって、L2デバイス上のDSBMは、パスメッセージを簡単に傍受してローカルSBMプロトコルエンティティに転送できるように構成する必要があります。たとえば、これには、対応する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マルチキャストアドレスを使用して管理されたセグメントを介してパスメッセージを送信します。したがって、管理されたセグメント上のSBMSまたはDSBMクライアントは、適切なインターフェイス上の予約されたマルチキャストアドレスにアドレス指定されたメッセージを傍受するように構成する必要があります。パスメッセージを簡単に受信します。
RSVP RESV messages continue to be unicast to the previous hop address stored as part of the PATH state at each intermediate hop.
RSVP RESVメッセージは、各中間ホップでパス状態の一部として保存されている前のホップアドレスと引き続きユニキャストされます。
We define use of two reserved IP multicast addresses. We call these the "AllSBM Address" and the "DSBMLogicalAddress". These are chosen from the range of local multicast addresses, such that:
予約された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管理エンティティに向けられるように、SBMSまたはDSBMをホストするレイヤー2デバイスの永続的なデータベースで構成されています。これにより、これらのデバイスが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 *パスメッセージを送信 *このアドレスを監視してクライアントを検出して、DSBMの存在をこのアドレスに検出します
* Monitors this address to receive PATH messages forwarded by the DSBM
* このアドレスを監視して、DSBMによって転送されたパスメッセージを受信します
SBM * Sends PATH messages * Monitors and sends on this to this address address to participate in election of the DSBM * Monitors this address to receive PATH messages forwarded by the DSBM
SBM *はパスメッセージを送信します *モニターをこのアドレスに送信して、DSBMの選挙に参加するためにこのアドレスをモニターして、DSBMによって転送されたパスメッセージを受信します
DSBM * Monitors this address * Monitors and sends on this
for PATH messages to participate in election
directed to it of the DSBM
* Sends PATH messages to this
address
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).
前述のように、L3デバイスに居住するDSBMSまたはDSBMクライアントは、PATHメッセージのパスに沿ったL2デバイスがLAN_NHOP_L3デバイスにLAN_NHOP_L2アドレスをLAN_NHOP_L3アドレスとLAN_NHOPオブジェクトのLAN_NHOP_L3アドレス間のマッピングを個別に決定する必要がないように、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 object = 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メッセージのカプセル化にRAW IPのみを使用していると仮定します。したがって、L3デバイス上のSBMプロトコルエンティティがRSVPメッセージをL2セグメントに転送する場合、生のIPカプセル化のみを使用します。
The message processing and forwarding rules will be described in the context of the sample network illustrated in Figure 2.
メッセージ処理と転送のルールは、図2に示すサンプルネットワークのコンテキストで説明されています。
Figure 2 - A sample network or L2 domain consisting of switched and shared L2 segments
図2-切り替えおよび共有L2セグメントで構成されるサンプルネットワークまたはL2ドメイン
..........
.
+------+ . +------+ seg A +------+ seg C +------+ seg D +------+
| H1 |_______| R1 |_________| S1 |_________| S2 |_______| H2 |
| | . | | | | | | | |
+------+ . +------+ +------+ +------+ +------+
. | /
1.0.0.0 . | /
. |___ /
. seg B | / seg E
.......... | /
2.0.0.0 | /
+-----------+
| S3 |
| |
+-----------+
|
|
|
|
seg F | .................
------------------------------ .
| | | .
+------+ +------+ +------+ . +------+
| H3 | | H4 | | R2 |____________| H5 |
| | | | | | . | |
+------+ +------+ +------+ . +------+
.
. 3.0.0.0
.................
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:
Device Type SBM Type
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
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メッセージに適用されます）。上記の一般的なネットワークのコンテキストで説明されています。例はすべてのシナリオに対処するわけではありませんが、興味深いシナリオのほとんどに対処しています。例外について個別に説明できます。
The forwarding rules are applied to received PATH messages (routers and switches) or originating PATH messages (hosts), as follows:
フォワーディングルールは、受信したパスメッセージ（ルーターとスイッチ）または発信パスメッセージ（ホスト）に次のように適用されます。
1. Determine the interface(s) on which to forward the PATH message using standard forwarding rules:
1. 標準の転送ルールを使用してパスメッセージを転送するインターフェイスを決定します。
* If there is a LAN_LOOPBACK object in the PATH message, and it carries the address of this device, silently discard the message. (See the section below on "Additional notes on forwarding the PATH message onto a managed segment).
* パスメッセージにLAN_LOOPBACKオブジェクトがあり、このデバイスのアドレスを運ぶ場合、メッセージを静かに破棄します。（「パスメッセージを管理されたセグメントに転送することに関する追加のメモを参照してください）。
* 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アドレスを使用して、転送インターフェイスを決定します。（「パスメッセージを管理セグメントに転送することに関する追加のメモ」の以下のセクションを参照してください）
2. For each forwarding interface:
2. 各転送インターフェイスについて：
* If the device is a layer 3 device, determine whether the interface is on a managed segment managed by a DSBM, based on the presence or absence of I_AM_DSBM messages. If the interface is not on a managed segment, strip out RSVP_HOP_L2, LAN_NHOP, LAN_LOOPBACK, and TCLASS objects (if present), and forward to the unicast or multicast destination.
* デバイスがレイヤー3デバイスの場合、I_AM_DSBMメッセージの存在または不在に基づいて、インターフェイスがDSBMによって管理される管理セグメント上にあるかどうかを判断します。インターフェイスがマネージドセグメントにない場合は、rsvp_hop_l2、lan_nhop、lan_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メッセージにこれらのオブジェクトが含まれている場合、RSVPが認識しますが、SBMプロトコルに参加しないノードは、そのようなオブジェクトを無視し、静かに破棄します。）
* If the device is a layer 2 device or it is a layer 3 device *and* the interface is on a managed segment, proceed to rule #3.
* デバイスがレイヤー2デバイスである場合、またはレイヤー3デバイス *である場合 *および *インターフェイスが管理されたセグメントにある場合は、ルール＃3に進みます。
3. Forward the PATH message onto the managed segment:
3. パスメッセージを管理したセグメントに転送します。
* If the device is a layer 3 device, insert LAN_NHOP address objects, a LAN_LOOPBACK, and a RSVP_HOP_L2 object into the PATH message. The LAN_NHOP objects carry the LAN_NHOP_L3 and LAN_NHOP_L2 addresses of the next layer 3 hop. The RSVP_HOP_L2 object carries the device's own L2 address, and the LAN_LOOPBACK object contains the IP address of the outgoing interface.
* デバイスがレイヤー3デバイスの場合、lan_nhopアドレスオブジェクト、lan_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デバイスは、前述のMAP_ADDR（）関数を使用して、IPアドレスに対応するL2アドレスを取得する必要があります。
* If the device hosts the DSBM for the segment to which the forwarding interface is attached, do the following:
* デバイスが転送インターフェイスが添付されているセグメントのDSBMをホストする場合、次のことを行います。
- Retrieve the PHOP information from the standard RSVP HOP object in the PATH message, and store it. This will be used to route RESV messages back through the L2 network. If the PATH message arrived over a managed segment, it will also contain the RSVP_HOP_L2 object; then retrieve and store also the previous hop's L2 address in the PATH state.
- パスメッセージの標準のRSVPホップオブジェクトからPHOP情報を取得し、保存します。これは、L2ネットワークを介してRESVメッセージをルーティングするために使用されます。パスメッセージが管理されたセグメントに届いた場合、RSVP_HOP_L2オブジェクトも含まれます。次に、パス状態の前のホップのL2アドレスも取得して保存します。
- Copy the IP address of the forwarding interface (layer 2 devices must also have IP addresses) into the standard RSVP HOP object and the L2 address of the forwarding interface into the RSVP_HOP_L2 object.
- 転送インターフェイスのIPアドレス（レイヤー2デバイスにもIPアドレスが必要です）を標準のRSVPホップオブジェクトと、転送インターフェイスのL2アドレスにRSVP_HOP_L2オブジェクトにコピーします。
- If the PATH message received does not contain the TCLASS object, insert a TCLASS object. The user_priority value inserted in the TCLASS object is based on service mappings internal to the device that are configured according to the guidelines listed in [RFC-MAP]. If the message already contains the TCLASS object, the user_priority value may be changed based again on the service mappings internal to the device.
- 受信したパスメッセージにTCLASSオブジェクトが含まれていない場合は、TCLASSオブジェクトを挿入します。TCLASSオブジェクトに挿入された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は標準のRSVPホップオブジェクトとパスメッセージ内の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が、転送インターフェイスのIPおよびL2アドレスを使用してRSVPホップとRSVP_HOP_L2オブジェクトを上書きすることを選択した場合、RESVメッセージを受信します。この場合、インシデントパスメッセージの標準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は、受信したパスメッセージの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プロトコルエンティティがインシデントインターフェイスに戻るパスメッセージを反映するDSBMでない限り、転送インターフェイスのIPアドレスをLAN_Loopbackオブジェクトにコピーします。（「パスメッセージを管理したセグメントに転送することに関する追加のメモ」のセクションを参照してください）。
* 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にパスメッセージを送信する必要があります。
* 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にパスメッセージを送信する必要があります。
Rule #1 states that normal IEEE 802.1D forwarding rules should be used to determine the interfaces on which the PATH message should be forwarded. In the case of data packets, standard forwarding rules at a L2 device dictate that the packet should not be forwarded on the interface from which it was received. However, in the case of a DSBM that receives a PATH message over a managed segment, the following exception applies:
ルール＃1は、通常のIEEE 802.1D転送ルールを使用して、パスメッセージを転送する必要があるインターフェイスを決定する必要があると述べています。データパケットの場合、L2デバイスでの標準的な転送ルールは、パケットを受信したインターフェイスに転送しないでください。ただし、管理されたセグメントを介してパスメッセージを受信するDSBMの場合、次の例外が適用されます。
E1. If the address in the LAN_NHOP object is a unicast address, consult the filtering database (FDB) to determine whether the destination address is listed on the same interface over which the message was received. If yes, follow the rule below on "reflecting a PATH message back onto an interface" described below; otherwise, proceed with the rest of the message processing as usual.
E1。LAN_NHOPオブジェクトのアドレスがユニキャストアドレスである場合、フィルタリングデータベース（FDB）を参照して、メッセージが受信された同じインターフェイスに宛先アドレスがリストされているかどうかを判断します。はいの場合は、以下に説明する「パスメッセージをインターフェイスに反映する」のルールに従ってください。それ以外の場合は、通常どおり、メッセージ処理の残りを続行します。
E2. If there are members of the multicast group address (specified by the addresses in the LAN_NHOP object), on the segment from which the message was received, the message should be forwarded back onto the interface from which it was received and follow the rule on "reflecting a PATH message back onto an interface" described below.
E2。マルチキャストグループアドレスのメンバー（LAN_NHOPオブジェクトのアドレスで指定）がある場合、メッセージが受信されたセグメントで、メッセージを受け取ったインターフェイスに戻し、ルールに従う必要があります。以下で説明するパスメッセージをインターフェイスに反映する。
*** Reflecting a PATH message back onto an interface ***
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が受信されたインターフェイスにパスメッセージを反映する場合、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が受信したインターフェイスにパスメッセージを反映する可能性があるため、これらのメッセージを無期限にループすることを避けるために予防措置を講じる必要があります。LAN_Loopbackオブジェクトは、この問題に対処します。すべてのSBMプロトコルエンティティ（パスメッセージを反映するDSBMSを除く）は、発信インターフェイスのIPアドレスを使用してパスメッセージのLAN_Loopbackオブジェクトを上書きします。パスメッセージを反映している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が受信機であるユニキャストセッションのパスを送信していると仮定します。次のパスメッセージは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
segment) LAN_LOOPBACK n/a (H1 is not sending onto a managed segment)
セグメント）lan_loopback n/a（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)
MAC Header Destn address The L2 addr corresponding to R1 (determined by map_addr() and routing tables at H1)
Mac Header DestnアドレスR1に対応するL2 ADDR（MAP_ADDR（）およびH1でのルーティングテーブルによって決定）
Since H1 is not sending onto a managed segment, the PATH message is composed and forwarded according to standard RSVP processing rules.
H1はマネージドセグメントに送信していないため、パスメッセージは標準のRSVP処理ルールに従って構成および転送されます。
Upon receipt of the PATH message, R1 composes and forwards a PATH message as follows:
パスメッセージを受信すると、R1は次のようにパスメッセージを作成して転送します。
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)
IP Header
Source address IP address of H1
Destn address DSBMLogical IP address (224.0.0.16)
MAC Header Destn address DSBMLogical MAC address
Mac Header 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は、RSVPセッションアドレスをルーティング検索を行い、次のレイヤー3ホップR2のIPアドレスを決定します。
* It determines that R2 is accessible via seg A and that seg A is managed by a DSBM, S1.
* R2はSEG Aを介してアクセス可能であり、セグ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.
* したがって、マネージドセグメントに送信していると結論付け、LAN_NHOPオブジェクトを作成してレイヤー3とレイヤー2の次のホップアドレスを運びます。LAN_NHOP L2ADDRオブジェクトを作成するには、L3をL3に呼び出してL2アドレスマッピング関数（ "MAP_ADDRESS"）を呼び出して、次のHop L3デバイスのMACアドレスを見つけ、LAN_NHOP_L2ADDRオブジェクト（MACアドレスを運ぶ）を挿入します。。
* Since R1 is not the DSBM for seg A, it sends the PATH message to the DSBMLogicalAddress.
* R1はSEG AのDSBMではないため、パスメッセージをDSBMLogicalAddressに送信します。
Upon receipt of the PATH message, S1 composes and forwards a PATH message as follows:
パスメッセージを受信すると、S1は次のようにパスメッセージを作成して転送します。
RSVP Contents
RSVP session IP address IP address of H5
Sender Template IP address of H1
PHOP IP addr of S1 (seed the return path for RESV
messages)
RSVP_HOP_L2 L2 address of S1
LAN_NHOP LAN_NHOP_L3 (IP) and LAN_NHOP_L2
address of R2
(layer 2 devices do not modify the LAN_NHOP)
LAN_LOOPBACK IP addr of S1
IP Header
Source address IP address of H1
Destn address AllSBMIPaddr (224.0.0.17, since S1 is the
DSBM for seg B).
MAC Header Destn address All SBM MAC address (since S1 is the DSBM for seg B).
MacヘッダーDestnアドレスすべてのSBM Macアドレス（S1はSEG BのDSBMであるため）。
* S1 looks at the LAN_NHOP address information to determine the L2 address towards which it should forward the PATH message.
* S1は、LAN_NHOPアドレス情報を調べて、パスメッセージを転送する必要があるL2アドレスを決定します。
* From the bridge forwarding tables, it determines that the L2 address is reachable via seg B.
* ブリッジ転送テーブルから、L2アドレスはSEG Bを介して到達可能であると判断します。
* S1 inserts the RSVP_HOP_L2 object and overwrites the RSVP HOP object (PHOP) with its own addresses.
* S1はRSVP_HOP_L2オブジェクトを挿入し、RSVPホップオブジェクト（PHOP）を独自のアドレスで上書きします。
* Since S1 is the DSBM for seg B, it addresses the PATH message to the AllSBMAddress.
* S1はSEG BのDSBMであるため、AllsBMaddressへのパスメッセージに対処します。
Upon receipt of the PATH message, S3 composes and forwards a PATH message as follows:
パスメッセージを受信すると、S3は次のようにパスメッセージを作成して転送します。
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
IP Header
Source address IP address of H1
Destn address DSBMLogical IP addr (since S3 is
not the DSBM for seg F)
MAC Header Destn address DSBMLogical MAC address
Mac Header 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 LAN_NHOPアドレス情報を調べて、パスメッセージを転送する必要があるL2アドレスを決定します。
* From the bridge forwarding tables, it determines that the L2 address is reachable via segment F.
* ブリッジ転送テーブルから、L2アドレスがセグメントFを介して到達可能であると判断します。
* It has discovered that R2 is the DSBM for segment F. It therefore sends the PATH message to the DSBMLogicalAddress.
* R2がセグメントFのDSBMであることが発見されました。したがって、パスメッセージをDSBMLogicalAddressに送信します。
* Note that S3 may or may not choose to overwrite the PHOP objects with its own IP and L2 addresses. If it does so, it will receive RESV messages. In this case, it must also store the PHOP info received in the incident PATH message so that it is able to forward the RESV messages on the correct path.
* S3は、独自のIPアドレスとL2アドレスを使用してPHOPオブジェクトを上書きすることを選択している場合と選択できない場合があります。そうすれば、RESVメッセージが受信されます。この場合、正しいパスでRESVメッセージを転送できるように、インシデントパスメッセージに受信したPHOP情報を保存する必要があります。
Upon receipt of the PATH message, R2 composes and forwards a PATH message as follows:
パスメッセージを受信すると、R2は次のようにパスメッセージを作成して転送します。
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)
IP Header Source address IP address of H1 Destn address IP address of H5, the RSVP session address
IPヘッダーソースアドレスH1 DESTNアドレスのIPアドレスH5のIPアドレス、RSVPセッションアドレス
MAC Header Destn address L2 addr corresponding to H5, the next layer 3 hop
Mac Header DestnアドレスL2 ADDR H5に対応する次のレイヤー3ホップ
* R2 does a routing lookup on the RSVP session address, to determine the IP address of the next layer 3 hop, H5.
* R2は、RSVPセッションアドレスをルーティング検索を行い、次のレイヤー3ホップH5のIPアドレスを決定します。
* It determines that H5 is accessible via a segment for which there is no DSBM (not a managed segment).
* H5は、DSBMがないセグメントからアクセス可能であると判断します（管理されたセグメントではありません）。
* Therefore, it removes the LAN_NHOP and RSVP_HOP_L2 objects and places the RSVP session address in the destination address of the IP header. It places the L2 address of the next layer 3 hop, into the destination address of the MAC header and forwards the PATH message to H5.
* したがって、LAN_NHOPとRSVP_HOP_L2オブジェクトを削除し、RSVPセッションアドレスをIPヘッダーの宛先アドレスに配置します。次のレイヤー3ホップのL2アドレスをMACヘッダーの宛先アドレスに配置し、パスメッセージをH5に転送します。
The rules described above also apply to multicast (m/c) sessions. For the purpose of this discussion, it is assumed that layer 2 devices track multicast group membership on each port individually. Layer 2 devices which do not do so, will merely generate extra multicast traffic. This is the case for L2 devices which do not implement multicast filtering or GARP/GMRP capability.
上記のルールは、マルチキャスト（M/C）セッションにも適用されます。この議論の目的のために、レイヤー2デバイスは各ポートのマルチキャストグループメンバーシップを個別に追跡すると想定されています。そうしないレイヤー2デバイスは、追加のマルチキャストトラフィックを生成するだけです。これは、マルチキャストフィルタリングまたはGARP/GMRP機能を実装していないL2デバイスの場合です。
Assume that H1 is sending a PATH for an m/c session for which H3 and H5 are the receivers. The rules are applied as they are in the unicast case described previously, until the PATH message reaches R2, with the following exception. The RSVP session address and the LAN_NHOP carry the destination m/c addresses rather than the unicast addresses carried in the unicast example.
H1がH3とH5が受信機であるM/Cセッションのパスを送信していると仮定します。ルールは、パスメッセージがR2に達するまで、次の例外を除いて、前述のユニキャストケースにあるために適用されます。RSVPセッションアドレスとLAN_NHOPには、ユニキャストの例で掲載されたユニキャストアドレスではなく、宛先M/Cアドレスが掲載されています。
Now let's look at the processing applied by R2 upon receipt of the PATH message. Recall that R2 is the DSBM for segment F. Therefore, S3 will have forwarded its PATH message to the DSBMLogicalAddress, to be picked up by R2. The PATH message will not have been seen by H3 (one of the m/c receivers), since it monitors only the AllSBMAddress, not the DSBMLogicalAddress for incoming PATH messages. We rely on R2 to reflect the PATH message back onto seg f, and to forward it to H5. R2 forwards the following PATH message onto seg f:
次に、パスメッセージを受け取ったときにR2で適用される処理を見てみましょう。R2はセグメントFのDSBMであることを思い出してください。したがって、S3はR2によってピックアップされるために、そのパスメッセージをDSBMLogicalAddressに転送します。パスメッセージは、H3（M/Cレシーバーの1つ）では見られませんでした。これは、着信パスメッセージのDSBMLogicalAddressではなく、Allsbmaddressのみを監視するためです。R2に依存して、パスメッセージをSEG Fに戻し、H5に転送します。R2は、次のパスメッセージをSEG Fに転送します。
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 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)
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はseg fのdsbmであるため）
MAC Header Destn address AllSBMMAC address (since R2 is the DSBM for seg F)
Mac Header DestnアドレスALLSBMMACアドレス（R2はSEG FのDSBMであるため）
Since H3 is monitoring the All SBM Address, it will receive the PATH message reflected by R2. Note that R2 violated the standard forwarding rules here by sending an incoming message back onto the interface from which it was received. It protected against loops by leaving S3's address in the LAN_LOOPBACK object unchanged.
H3はすべてのSBMアドレスを監視しているため、R2に反映されるパスメッセージが受信されます。R2は、受信したインターフェイスに着信メッセージを送信することにより、ここで標準的な転送ルールに違反したことに注意してください。LAN_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)
IP Header Source address IP address of H1 Destn address m/c session address
IPヘッダーソースアドレスH1 DESTNアドレスM/CセッションアドレスのIPアドレス
MAC Header Destn address MAC addr corresponding to the m/c session address
Mac Header Destnアドレスmac addr m/cセッションアドレスに対応する
* 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オブジェクトを削除し、RSVPセッションアドレスをIPヘッダーの宛先アドレスに配置します。対応するL2アドレスをMACヘッダーの宛先アドレスに配置し、MultiCastsをH5に向けます。
When a DSBM client receives TCLASS objects from different senders (different PATH messages) in the same RSVP session and needs to combine them for sending back a single RESV message (as in a wild-card style reservation), the DSBM client must choose an appropriate value that corresponds to the desired-delay traffic class. An accompanying document discusses the guidelines for traffic class selection based on desired service and the TSpec information [RFC-MAP].
DSBMクライアントが同じRSVPセッションで異なる送信者（異なるパスメッセージ）からTCLASSオブジェクトを受信し、単一のRESVメッセージを（ワイルドカードスタイルの予約のように）送信するためにそれらを組み合わせる必要がある場合、DSBMクライアントは適切なものを選択する必要があります希望する遅延トラフィッククラスに対応する値。付随するドキュメントでは、目的のサービスとTSPEC情報[RFC-Map]に基づいて、トラフィッククラスの選択に関するガイドラインについて説明します。
In addition, when a SBM or DSBM needs to merge RESVs from different next hops at a merge point, it must decide how to handle the TCLASS values in the incoming RESVs if they do not match. Consider the case when a reservation is in place for a flow at a DSBM (or SBM) with a successful admission control done for the TCLASS requested in the first RESV for the flow. If another RESV (not the refresh of the previously admitted RESV) for the same flow arrives at the DSBM, the DSBM must first check the TCLASS value in the new RESV against the TCLASS value in the already installed RESV. If the two values are same, the RESV requests are merged and the new, merged RESV installed and forwarded using the normal rules of message processing. However, if the two values are not identical, the DSBM must generate and send a RESV_ERR message towards the sender (NHOP) of the newer, RESV message. The RESV_ERR must specify the error code corresponding to the RSVP "traffic control error" (RESV_ERR code 21) that indicates failure to merge two incompatible service requests (sub-code 01 for the RSVP traffic control error) [RFC-2205]. The RESV_ERR message may include additional objects to assist downstream nodes in recovering from this condition. The definition and usage of such objects is beyond the scope of this memo.
さらに、SBMまたはDSBMがマージポイントで異なる次のホップからRESVをマージする必要がある場合、一致しない場合は、着信RESVのTCLASS値を処理する方法を決定する必要があります。Flowの最初のRESVで要求されたTCLASSに対して成功した入場制御が行われたDSBM（またはSBM）でのフローの予約が整っている場合を検討してください。同じフローの別のRESV（以前に認められたRESVの更新ではない）がDSBMに到着した場合、DSBMは最初に、すでにインストールされているRESVのTCLASS値に対して新しいRESVのTCLASS値を確認する必要があります。2つの値が同じ場合、RESV要求がマージされ、新しいマージされたRESVがインストールされ、メッセージ処理の通常のルールを使用して転送されます。ただし、2つの値が同一でない場合、DSBMは、新しいRESVメッセージの送信者（NHOP）にRESV_ERRメッセージを生成および送信する必要があります。RESV_ERRは、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）のいずれかにアドレス指定されたメッセージをインターセプトするのではなく、代わりにそれらを通過させます。その結果、彼らはDSBM選挙の範囲を分割せず、パスまたはRESVメッセージのルーティングに明示的に参加せず、入場管理に参加しません。それらは、SBM操作に関して完全に透明です。
According to the definitions provided, physical segments interconnected by SBM transparent devices are considered a single managed segment. Therefore, DSBMs must perform admission control on such managed segments, with limited knowledge of the segment's topology. In this case, the network administrator should configure the DSBM for each managed segment, with some reasonable approximation of the segment's capacity. A conservative policy would configure the DSBM for the lowest capacity route through the managed segment. A liberal policy would configure the DSBM for the highest capacity route through the managed segment. A network administrator will likely choose some value between the two, based on the level of guarantee required and some knowledge of likely traffic patterns.
提供されている定義によれば、SBM透明デバイスによって相互接続された物理セグメントは、単一の管理されたセグメントと見なされます。したがって、DSBMは、セグメントのトポロジに関する知識が限られている、そのような管理されたセグメントで入場制御を実行する必要があります。この場合、ネットワーク管理者は、セグメントの容量の合理的な近似で、管理された各セグメントの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プロトコルエンティティがどのような目的を果たすかを尋ねるかもしれません。このようなSBMは、実際に2つの有用な機能を提供します。第一に、追加のSBMは、障害のトレランスのためにバックグラウンドで受動的なままです。彼らは、管理されたセグメントの現在のDSBMからの定期的な発表を聞き（付録Aでこれをより詳細に説明しています）、現在のDSBMが何らかの理由で動作しなくなったときに新しいDSBMを選択します。第二に、このようなSBMは、選挙の範囲を分割し、管理されたセグメントのサイズと複雑さを削減する重要なサービスを提供します。たとえば、図3のサンプルトポロジをもう一度考えてみましょう。デバイスS3には、セグメント、B、E、またはFのDSBMではないSBMが含まれています。ただし、S3のSBMプロトコルエンティティが存在しなかった場合、セグメントBとFはSBMプロトコルの観点からセグメントを分離しません。代わりに、それらは単一のDSBMによって管理された単一の管理セグメントを構成します。S3のSBMエンティティは選挙範囲を分割するため、SEG BとSEG Fはそれぞれ別々のDSBMで管理されています。これらの各セグメントには、些細なトポロジと明確に定義された能力があります。その結果、これらのセグメントのDSBMSは、近似に基づいて入学制御を実行する必要はありません（S3がSBM透明であった場合のように）。
Note that, SBM protocol entities which are not DSBMs, are not required to overwrite the PHOP in incident PATH messages with their own address. This is because it is not necessary for RESV messages to be routed through these devices. RESV messages are only required to be routed through the correct sequence of DSBMs. SBMs may not process RESV messages that do pass through them, other than to forward them towards their destination address, using standard forwarding rules.
DSBMSではないSBMプロトコルエンティティは、インシデントパスメッセージの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を認識しているクライアントとノードがこれらのシナリオでどのように動作するかを説明します。
6.1. An L2 domain with no RSVP capability.
6.1. RSVP機能のないL2ドメイン。
It is possible to envisage L2 domains that do not use RSVP signaling for requesting resource reservations, but, instead, use some other (e.g., SNMP or static configuration) mechanism to reserve bandwidth at a particular network device such as a router. In that case, the question is how does a DSBM-based admission control method work and interoperate with the non-RSVP mechanism. The SBM-based method does not attempt to provide an admission control solution for such an environment. The SBM-based approach is part of an end to end signaling approach to establish resource reservations and does not attempt to provide a solution for SNMP-based configuration scenario.
リソースの予約を要求するためにRSVPシグナリングを使用しないL2ドメインを想定することは可能ですが、代わりに、ルーターなどの特定のネットワークデバイスで帯域幅を予約するために、他の（例えば、SNMPまたは静的構成）メカニズムを使用することができます。その場合、問題は、DSBMベースの入学制御方法がどのように機能し、非RSVPメカニズムと相互操作するかです。SBMベースの方法は、このような環境に入学制御ソリューションを提供しようとはしていません。SBMベースのアプローチは、リソースの予約を確立するためのエンドツーエンドシグナル伝達アプローチの一部であり、SNMPベースの構成シナリオのソリューションを提供しようとしません。
As stated earlier, the SBM-based approach can, however, co-exist with any other, non-RSVP bandwidth allocation mechanism as long as resources being reserved are either partitioned statically between the different mechanisms or are resolved dynamically through a common bandwidth allocator so that there is no over-commitment of the same resource.
前述のように、SBMベースのアプローチは、リソースが予約されているリソースが異なるメカニズム間で静的に分割されるか、共通の帯域幅アロケーターを介して動的に解決される限り、他の非RSVP帯域幅割り当てメカニズムと共存することができます。同じリソースの過剰なコミットメントがないこと。
6.2. An L2 domain with SBM-transparent L2 Devices.
6.2. SBM透過性L2デバイスを備えたL2ドメイン。
This scenario has been addressed earlier in the document. The SBM-based method is designed to operate in such an environment. When SBM-transparent L2 devices interconnect SBM-aware devices, the resulting managed segment is a combination of one or more physical segments and the DSBM for the managed segment may not be as efficient in allocating resources as it would if all L2 devices were SBM-aware.
このシナリオは、ドキュメントの前半で説明されています。SBMベースの方法は、このような環境で動作するように設計されています。SBM透過性L2デバイスがSBM対応デバイスを相互接続する場合、結果のマネージドセグメントは1つ以上の物理セグメントの組み合わせであり、管理されたセグメントのDSBMは、すべてのL2デバイスがSBM-SBM-SBM-SBM-SBM-の場合ほどリソースの割り当てに効率的ではない場合があります。わかっている。
6.3. An L2 domain on which some RSVP-based senders are not DSBM clients.
6.3. 一部のRSVPベースの送信者がDSBMクライアントではないL2ドメイン。
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プロトコルに参加する必要があります。RSVPの標準の非SBMバージョンを使用すると、リソースが過剰に配分される可能性があります。そのため、DSBMのリソース管理機能をバイパスするためです。他のすべての送信者（つまり、RSVP入場制御の対象となるストリームを送信していない送信者）は、RSVPトラフィックよりも低いトレフィーのトラフィックを送信する弾力性のあるアプリケーションであり、TCP様うっ血回避メカニズムを使用する必要があります。
All DSBMs, SBMs, or DSBM clients on a managed segment (a segment with a currently active DSBM) must not accept PATH messages from senders that are not SBM-aware. PATH messages from such devices can be easily detected by SBMs and DSBM clients as they would not be multicast to the ALLSBMAddress (in case of SBMs and DSBM clients) or the DSBMLogicalAddress (in case of DSBMs).
管理されたセグメントのすべてのDSBMS、SBMS、またはDSBMクライアント（現在アクティブなDSBMを持つセグメント）は、SBMが認識していない送信者からのパスメッセージを受け入れてはなりません。このようなデバイスからのパスメッセージは、SBMSおよびDSBMクライアントがAllSBMADDRESS（SBMSおよびDSBMクライアントの場合）またはDSBMLogicalAddress（DSBMSの場合）にマルチキャストしないため、簡単に検出できます。
6.4. A non-SBM router that interconnects two DSBM-managed L2 domains.
6.4. 2つのDSBMが管理したL2ドメインを相互接続する非SBMルーター。
Multicast SBM messages (e.g., election and PATH messages) have local scope and are not intended to pass between the two domains. A correctly configured non-SBM router will not pass such messages between the domains. A broken router implementation that does so may cause incorrect operation of the SBM protocol and consequent over- or under-allocation of resources.
マルチキャストSBMメッセージ（選挙やパスメッセージなど）にはローカルスコープがあり、2つのドメイン間を通過することを意図していません。正しく構成されている非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メッセージのカプセル化にRAW IPのみを使用していることを規定しています。RFC-2205（RSVP提案標準）には、生のIPとUDPの両方のカプセル化のサポートが含まれています。したがって、DSBMがUDPカプセル化されたRSVPメッセージを受け入れてサポートしない限り、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の場合、リンク帯域幅よりも少ない場合は、デバイスのスイッチング容量の推定値を推定して構成する必要があり、スイッチのバッファリングリソースのある程度の推定値がある場合があります（[RFCフレーム] L2スイッチ用に想定されるアーキテクチャモデル用）。総リンク帯域幅を考えると、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がリソースを割り当てることができる効率を損ないます。これは、予約の影響を受けた実際の物理セグメントの知識がなく、L2トポロジ内のすべての予約要求について、単一のDSBMが入学管理の決定を下すために必要であるためです。
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の実装は、そのRFCの要件を満たし、従来のRSVP実装であるかのように提案されたメカニズムを提供する必要があります。さらに、同じメカニズムを使用して、メッセージ内の追加のSBM固有のオブジェクトを保護する必要があります。
Finally, it is also necessary to authenticate DSBM candidates during the election process, and a mechanism based on a shared secret among the DSBM candidates may be used. The mechanism defined in [RFC-RSVPMD5] should be used.
最後に、選挙プロセス中にDSBM候補者を認証することも必要であり、DSBM候補者の間で共有された秘密に基づくメカニズムを使用することができます。[RFC-RSVPMD5]で定義されているメカニズムを使用する必要があります。
[RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC 2205] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC-RSVPMD5] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC-RSVPMD5] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[RFC 2206] Baker, F. and J. Krawczyk, "RSVP Management Information Base", RFC 2206, September 1997.
[RFC 2206] Baker、F。およびJ. Krawczyk、「RSVP管理情報ベース」、RFC 2206、1997年9月。
[RFC 2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC 2211] Wroclawski、J。、「制御されたロードネットワーク要素サービスの仕様」、RFC 2211、1997年9月。
[RFC 2212] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC 2212] Shenker、S.、Partridge、C。およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[RFC 2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[RFC 2215] Shenker、S。およびJ. Wroclawski、「統合されたサービスネットワーク要素の一般的な特性評価パラメーター」、RFC 2215、1997年9月。
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC 2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC 2213] Baker, F. and J. Krawczyk, "Integrated Services Management Information Base", RFC 2213, September 1997.
[RFC 2213] Baker、F。およびJ. Krawczyk、「統合サービス管理情報ベース」、RFC 2213、1997年9月。
[RFC-FRAME] Ghanwani, A., Pace, W., Srinivasan, V., Smith, A. and M.Seaman, "A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies", RFC 2816, May 2000.
[RFCフレーム] Ghanwani、A.、Pace、W.、Srinivasan、V.、Smith、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] Seaman、M.、Smith、A。、およびE. Crawley、「IEEE 802ネットワークの統合サービスマッピング」、RFC 2815、2000年5月。
[IEEE802Q] "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", Draft Standard P802.1Q/D9, February 20, 1998.
[IEEE802Q]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：仮想ブリッジ付きローカルエリアネットワーク」、ドラフト標準P802.1Q/D9、1998年2月20日。
[IEEEP8021p] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision (Incorporating IEEE P802.1p: Traffic Class Expediting and Dynamic Multicast Filtering)", ISO/IEC Final CD 15802-3 IEEE P802.1D/D15, November 24, 1997.
[IEEEP8021p] "情報技術 - システム間の通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 共通仕様 - パート3：メディアアクセス制御（MAC）ブリッジ：リビジョン（IEEE P802.1p：トラフィッククラスの露出および動的マルチカストろ過）"、ISO/IEC最終CD 15802-3 IEEE P802.1D/D15、1997年11月24日。
[IEEE8021D] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993.
[IEEE8021D]「Mac Bridges」、ISO/IEC 10038、ANSI/IEEE STD 802.1D-1993。
To simplify the rest of this discussion, we will assume that there is a single DSBM for the entire L2 domain (i.e., assume a shared L2 segment for the entire L2 domain). Later, we will discuss how a DSBM is elected for a half-duplex or full-duplex switched segment.
この議論の残りの部分を簡素化するために、L2ドメイン全体に単一のDSBMがあると仮定します（つまり、L2ドメイン全体の共有L2セグメントを想定しています）。その後、DSBMが半分二重または全二重スイッチされたセグメントでどのように選出されるかについて説明します。
To allow for quick recovery from the failure of a DSBM, we assume that additional SBMs may be active in a L2 domain for fault tolerance. When more than one SBM is active in a L2 domain, the SBMs use an election algorithm to elect a DSBM for the L2 domain. After the DSBM is elected and is operational, other SBMs remain passive in the background to step in to elect a new DSBM when necessary. The protocol for electing and discovering DSBM is called the "DSBM election protocol" and is described in the rest of this Appendix.
DSBMの故障から迅速に回復できるようにするために、障害トレランスのためにL2ドメインで追加のSBMがアクティブになる可能性があると仮定します。L2ドメインで複数のSBMがアクティブになっている場合、SBMは選挙アルゴリズムを使用してL2ドメインのDSBMを選択します。DSBMが選出され、運用可能になった後、他のSBMはバックグラウンドで受動的であり、必要に応じて新しいDSBMを選択するために介入します。DSBMを選択および発見するためのプロトコルは、「DSBM選挙プロトコル」と呼ばれ、この付録の残りの部分で説明されています。
Once elected, a DSBM periodically multicasts an I_AM_DSBM message on the AllSBMAddress to indicate its presence. The message is sent every period (e.g., every 5 seconds) according to the RefreshInterval timer value (a configuration parameter). Absence of such a message over a certain time interval (called "DSBMDeadInterval"; another configuration parameter typically set to a multiple of RefreshInterval) indicates that the DSBM has failed or terminated and triggers another round of the DSBM election. The DSBM clients always listen for periodic DSBM advertisements. The advertisement includes the unicast IP address of the DSBM (DSBMAddress) and DSBM clients send their PATH/RESV (or other) messages to the DSBM. When a DSBM client detects the failure of a DSBM, it waits for a subsequent I_AM_DSBM advertisement before resuming any communication with the DSBM. During the period when a DSBM is not present, a DSBM client may forward outgoing PATH messages using the standard RSVP forwarding rules.
選出されると、DSBMは定期的にALLSBMADDRESSのI_AM_DSBMメッセージを定期的にマルチキャストして、その存在を示します。このメッセージは、leshedintervalタイマー値（構成パラメーター）に従って、毎回（5秒ごとに）送信されます。特定の時間間隔（「DSBMDeadInterval」と呼ばれる、通常はleffeshedintervalの倍数に設定された別の構成パラメーターと呼ばれる）にそのようなメッセージがないことは、DSBMがDSBM選挙の別のラウンドに障害または終了したことを示しています。DSBMクライアントは、常に定期的なDSBM広告を聴きます。広告には、DSBM（DSBMADDRESS）のユニキャストIPアドレスが含まれ、DSBMクライアントはPATH/RESV（またはその他）メッセージをDSBMに送信します。DSBMクライアントがDSBMの障害を検出すると、DSBMとの通信を再開する前に、後続のI_AM_DSBM広告が待機します。DSBMが存在しない期間中、DSBMクライアントは標準のRSVP転送ルールを使用して発信パスメッセージを転送できます。
The exact message formats and addresses used for communication with (and among) SBM(s) are described in Appendix B.
SBMとの通信に使用される正確なメッセージフォーマットとアドレスは、付録Bで説明されています。
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広告の対象となります。すでに存在している場合（そして新しい選挙が進行していない）、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は、IPアドレスを候補DSBMおよび「SBM優先度」としてリストするDSBM_Willingメッセージを送信することにより、DSBMの選挙を開始します。各SBMには、その相対的な優先順位を決定するための優先順位が割り当てられます。複数のSBM候補が存在する場合、SBMの優先順位は、候補者の相対的な優先度に基づいて誰がDSBMになるかを決定します。優先度の値に基づいてタイがある場合、タイ候補のIPアドレスを使用してネクタイが破損します（辞書順の順序でより高いIPアドレスが勝ちます）。選挙プロトコルの詳細は、セクションA. 4から始まります。
For the purpose of the algorithm, a SBM is in one of the four states (Idle, DetectDSBM, ElectDSBM, IAMDSBM).
アルゴリズムの目的のために、SBMは4つの状態のいずれかにあります（IDLE、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と呼ばれる）は、detectdsbm状態で起動し、受信i_am_dsbm（dsbm広告）またはdsbm_willingメッセージのリッスンインターバルを待ちます。この状態でI_AM_DSBM広告が受信された場合、SBMは現在のDSBM（IPアドレスと優先度）に指摘し、アイドル状態に入ります。この状態中に別のSBM（Yと呼ぶ）からDSBM_WILLINGメッセージが受信された場合、XはElectDSBM状態に入ります。新しい状態に入る前に、Xは最初にそれ自体がyよりも優れた候補であるかどうかを確認し、もしそうなら、DSBM_Willingメッセージを送信してから、ElectDSBM状態に入ります。
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状態に入ると、タイマー（lethemeintervaltimerと呼ばれ、通常はdsbmdeadeadinterval値に少なくとも等しい値に設定されています）を設定して、選挙が終了し、誰が最良の候補者であるかを発見するのを待ちます。この状態では、Xはこれまでに見られた最高の（またはそれ以上の）候補者（それ自体を含む）を追跡しています。別のDSBM_WILLINGメッセージを受信するたびに、優先順位（およびタイブレイク）の基準に基づいて、最高の（またはより良い）候補者の概念を更新します。選出中に、XはDSBM_WILLINGメッセージを送信します。
At the end of the ElectionInterval, X checks whether it is the best candidate so far. If so, it declares itself to be the DSBM (by sending out the I_AM_DSBM advertisement) and enters the IAMDSBM state; otherwise, it decides to wait for the best candidate to declare itself the winner. To wait, X re-initializes its ElectDSBM state and continues to wait for another round of election (each round lasts for an ElectionTimerInterval duration).
選挙インターバルの終わりに、Xはこれがこれまでで最高の候補者であるかどうかをチェックします。その場合、それ自体はDSBMであると宣言し（I_AM_DSBM広告を送信することにより）、IAMDSBM状態に入ります。それ以外の場合、最高の候補者が勝者を宣言するのを待つことにしました。待つために、Xはその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).
SBMは、選挙が進行しておらず、DSBMがすでに選出されているときにアイドル状態にあります（そして、たまたま他の誰かです）。この状態では、着信I_AM_DSBM広告に耳を傾け、DSBMDeadIntervalTimerを使用してDSBMの障害を検出します。広告が受信されるたびに、タイマーが再起動されます。タイマーが発射された場合、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がシャットダウン（優雅に終了する）を希望する場合、選挙手続きを開始するためにDSBM_Willingメッセージ（SBM優先値がゼロに設定されている）を送信します。優先順位ゼロは、選挙手続きから発信DSBMを効果的に削除し、異なるDSBMの選挙に道を譲ります。
When a DSBM fails (DSBMDeadIntervalTimer fires), all the SBMs enter the ElectDSBM state and start the election process.
DSBMが失敗すると（DSBMDeadIntervaltimer Fire）、すべてのSBMがElectDSBM状態に入り、選挙プロセスを開始します。
At the end of the ElectionInterval, the elected DSBM sends out an I_AM_DSBM advertisement and the DSBM is then operational.
選挙インターバルの終わりに、選出されたDSBMはI_AM_DSBM広告を送信し、DSBMは運用可能です。
The I_AM_DSBM advertisement contains the following information:
I_AM_DSBM広告には、次の情報が含まれています。
1. DSBM address information -- contains the IP and L2 addresses of the DSBM and its SBM priority (a configuration parameter -- priority specified by a network administrator). The priority value is used to choose among candidate SBMs during the election algorithm. Higher integer values indicate higher priority and the value is in the range 0..255. The value zero indicates that the SBM is not eligible to be the DSBM. The IP address is required and used for breaking ties. The L2 address is for the interface of the managed segment.
1. DSBMアドレス情報 - DSBMのIPおよびL2アドレスとそのSBMの優先度（構成パラメーター - ネットワーク管理者によって指定された優先度）が含まれています。優先順位の値は、選挙アルゴリズム中に候補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- seplessintervalの値が数秒で含まれています。値ゼロは、メッセージでパラメーターが省略されていることを示します。この場合、受信機は独自のデフォルト値を置き換える場合があります。
3. DSBMDeadInterval -- contains the value of DSBMDeadInterval in seconds. If the value is omitted (or value zero is specified), a default value (from initial configuration) should be used.
3. DSBMDEADINTERVAL -DSBMDEADINTERVALの値が数秒で含まれています。値が省略されている場合（または値ゼロが指定されています）、デフォルト値（初期構成から）を使用する必要があります。
4. Miscellaneous configuration information to be advertised to senders on the managed segment. See Appendix C for further details.
4. 管理されたセグメントの送信者に宣伝されるその他の構成情報。詳細については、付録Cを参照してください。
When a SBM wishes to declare its candidacy to be the DSBM during an election phase, it sends out a DSBM_WILLING message. The DSBM_WILLING message contains the following information:
SBMが選挙段階で候補者をDSBMであると宣言したい場合、DSBM_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の対応する優先度が含まれています。
For each network interface, a SBM maintains the following state variables related to the election of the DSBM for the L2 domain on that interface:
各ネットワークインターフェイスについて、SBMは、そのインターフェイス上のL2ドメインのDSBMの選挙に関連する次の状態変数を維持します。
a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, 0.0.0.0) and priority. All IP addresses are assumed to be in network byte order. In addition, current DSBM's L2 address is also stored as part of this state information.
a) localdsbmaddrinfo-現在のDSBMのIPアドレス（最初は0.0.0.0）および優先度。すべてのIPアドレスは、ネットワークバイトの順序であると想定されています。さらに、現在のDSBMのL2アドレスは、この州情報の一部として保存されています。
b) OwnAddrInfo -- SBM's own IP address and L2 address for the interface and its own priority (a configuration parameter).
b) ownaddrinfo-インターフェイスのSBM独自のIPアドレスとL2アドレスと独自の優先度（構成パラメーター）。
c) RefreshInterval in seconds. When the DSBM is not yet elected, it is set to a default value specified as a configuration parameter.
c) 数秒でlreashinterval。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) interval in sconse -scontectdsbm状態でSBMがどのくらいの時間を費やすかを決定する構成パラメーター（以下を参照）。
g) ElectionInterval in seconds -- a configuration parameter that decides how long a SBM spends in the ElectDSBM state when it has declared its candidacy.
g) semold in sconds -sconds -sbmが候補を宣言したときにelectdsbm状態でどのくらいの時間を費やすかを決定する構成パラメーター。
Figure 3 shows the state transition diagram for the election protocol and the various states are described below. A complete description of the state machine is provided in Section A.10.
図3は、選挙プロトコルの状態遷移図を示しており、さまざまな州を以下に説明します。状態マシンの完全な説明は、セクションA.10に記載されています。
DOWN -- SBM is not operational.
ダウン-SBMは動作していません。
DetectDSBM -- typically, the initial state of a SBM when it starts up. In this state, it checks to see whether a DSBM already exists in its domain.
DetectDSBM-通常、SBMが起動するときの初期状態。この状態では、DSBMがすでにそのドメインに存在するかどうかを確認します。
Idle -- SBM is in this state when no election is in progress and it is not the DSBM. In this state, SBM passively monitors the state of the DSBM.
アイドル-SBMは選挙が進行していないときにこの州にあり、DSBMではありません。この状態では、SBMはDSBMの状態を受動的に監視しています。
ElectDSBM -- SBM is in this state when a DSBM election is in progress.
ElectDSBM -SBMは、DSBM選挙が進行中のこの州にいます。
IAMDSBM -- SBM is in this state when it is the DSBM for the L2 domain.
IAMDSBM -SBMは、L2ドメインのDSBMである場合、この状態にあります。
StartUp -- SBM starts operation.
スタートアップ-SBMは操作を開始します。
ListenInterval Timeout -- The ListenInterval timer has fired. This means that the SBM has monitored its domain to check for an existing DSBM or to check whether there are candidates (other than itself) willing to be the DSBM.
Interval Timeoutを聞く-InterIntervalタイマーが解雇されました。これは、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がこの期間中に1つの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.
refleadthintervalタイムアウト - lebledechintervaltimerが解雇されました。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.
選挙インターバルタイムアウト - 選出されたインターバルティマーが解雇されました。これは、SBMが成功したかどうかを判断するために立候補を宣言した後、十分に長く待っていたことを意味します。
+-----------+
+--<--------------<-|DetectDSBM |---->------+
| +-----------+ |
| |
| |
| |
| +-------------+ +---------+ |
+->---| Idle |--<>---|ElectDSBM|--<--+
+-------------+ +---------+
| |
| |
| |
| +-----------+ |
+<<- +---| IAMDSBM |-<-+
| +-----------+
|
| +-----------+
+>>-| SHUTDOWN |
+-----------+
Based on the events and states described above, the state changes at a SBM are described below. Each state change is triggered by an event and is typically accompanied by a sequence of actions. The state machine is described assuming a single threaded implementation (to avoid race conditions between state changes and timer events) with no timer events occurring during the execution of the state machine.
上記のイベントと状態に基づいて、SBMでの状態の変化を以下に説明します。各状態の変更はイベントによってトリガーされ、通常、一連のアクションが伴います。状態マシンは、状態マシンの実行中にタイマーイベントが発生しない単一のスレッド化された実装（州の変更とタイマーイベントの間の人種条件を回避するため）を仮定して説明されています。
The following routines will be frequently used in the description of the state machine:
次のルーチンは、状態マシンの説明で頻繁に使用されます。
ComparePrio(FirstAddrInfo, SecondAddrInfo) -- determines whether the entity represented by the first parameter is better than the second entity using the priority information and the IP address information in the two parameters. If any address is zero, that entity automatically loses; then first priorities are compared; higher priority candidate wins. If there is a tie based on the priority value, the tie is broken using the IP addresses of tied candidates (one with the higher IP address in the lexicographic order wins). Returns TRUE if first entity is a better choice. FALSE otherwise.
ComparePrio（FirstAddrinfo、SecondAddrinfo） - 最初のパラメーターで表されるエンティティが、2つのパラメーターの優先情報とIPアドレス情報を使用して2番目のエンティティよりも優れているかどうかを決定します。いずれかのアドレスがゼロの場合、そのエンティティは自動的に負けます。次に、最初の優先順位が比較されます。優先度の高い候補者が勝ちます。優先度の値に基づいてタイがある場合、タイ候補のIPアドレスを使用してネクタイが破損します（辞書順の順序でより高いIPアドレスが勝ちます）。First Entityがより良い選択である場合、trueを返します。それ以外の場合。
SendDSBMWilling Message() Begin Send out DSBM_WILLING message listing myself as a candidate for DSBM (copy OwnAddr and priority into appropriate fields) start RefreshIntervalTimer goto ElectDSBM state End
senddsbmwilling message（）dsbm_willingメッセージを送信して、dsbm（ownaddrと優先度を適切なフィールドにコピーする）の候補として自分自身をリストします。
AmIBetterDSBM(OtherAddrInfo) Begin if (ComparePrio(OwnAddrInfo, OtherAddrInfo)) return TRUE
amibetterdsbm（otheraddrinfo）が始まるif（compareprio（ownaddrinfo、otheraddrinfo））trueを返す
change LocalDSBMInfo = OtherDSBMAddrInfo return FALSE End
localdsbminfo = otherdsbmaddrinfo false endを変更します
UpdateDSBMInfo()
/* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */
Begin
update LocalDSBMInfo such as IP addr, DSBM L2 address,
DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer
End
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.
状態：ダウンイベント：スタートアップNew State：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メッセージ受信アクション：set localdsbmaddrinfo = incomingdsbmaddrinfo start deaddsbmintervalタイマーgotoアイドル状態
State: DetectDSBM Event: ListenIntervalTimer fired New State: ElectDSBM Action: Start ElectionIntervalTimer SendDSBMWillingMessage();
状態：DetectDSBMイベント：REASNINTERINTERVALTIMERは新しい状態を解雇しました：ElectDSBMアクション：lethemetervaltimer sendsbmwillingmessage（）;
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アクション：lethemeltedintervaltimer set 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
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アクティブなタイマーがキャンセル
State: ElectDSBM
Event: DSBM_WILLING message received
New State: ElectDSBM
Action: Check whether it's a loopback and if so, discard, continue;
if (!AmIBetterDSBM(IncomingDSBMAddrInfo)) {
Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo
Cancel RefreshIntervalTimer
} else if (LocalDSBMAddrInfo == OwnAddrInfo) {
SendDSBMWillingMessage()
}
continue in current state
State: ElectDSBM
Event: RefreshIntervalTimer fired
New State: ElectDSBM
Action: /* continue to send DSBMWilling messages until
election interval ends */
SendDSBMWillingMessage()
State: 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メッセージを送信
State: IAMDSBM
Event: I_AM_DSBM message received
New State: depends on action (IAMDSBM or Idle)
Action: /* check whether other guy is better */
If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) {
/* I am better */
send I_AM_DSBM message
restart RefreshIntervalTimer
continue in current state
} else {
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto Idle State
}
State: IAMDSBM Event: Want to shut myself down New State: DOWN Action: send DSBM_WILLING message with My address filled in, but priority set to zero goto Down State
状態：IAMDSBMイベント：自分自身をシャットダウンしたい新しい状態：ダウンアクション：私のアドレスが記入されてDSBM_WILLINGメッセージを送信しますが、優先度はゼロのGOTOに設定されています
To avoid DSBM outages for long period, to ensure quick recovery from DSBM failures, and to avoid timeout of PATH and RESV state at the edge devices, we suggest the following values for various timers.
DSBMの停止を長期間回避し、DSBMの障害からの迅速な回復を確保し、エッジデバイスでのパスとRESV状態のタイムアウトを回避するために、さまざまなタイマーの次の値をお勧めします。
Assuming that the RSVP implementations use a 30 second timeout for PATH and RESV refreshes, we suggest that the RefreshIntervalTimer should be set to about 5 seconds with DSBMDeadIntervalTimer set to 15 seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be set 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秒のタイムアウトを使用していると仮定すると、DSBMDeadedIntervaltimerを15秒に設定して（k = 3、k*leshedinterval）に、lebhesintervaltimerを約5秒に設定することをお勧めします。detectdsbmtimerは、（dsbmdeadintervaltimer、2*dsbmdeadintervaltimer）の間のランダム値に設定する必要があります。選挙Intervaltimerは、少なくともdsbmdeadedintervaltimerの価値に設定する必要があります。各SBMには、他のSBM（ElectDSBM州のすべてのrefreedintervalが送信される）が他の人に配信される可能性があります。
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は、8ビットの署名されていない整数値（0〜255の範囲）であり、より高い優先度を示す整数値が高くなります。インターフェイスの値ゼロは、デバイス上のSBMプロトコルエンティティが、インターフェイスに接続されたセグメントのDSBMになる資格がないことを示しています。
A separate range of values is reserved for each type of SBM-capable device to reflect the relative priority among different classes of L2/L3 devices. L2 devices get higher priority followed by routers followed by hosts. The priority values in the range of 128..255 are reserved for L2 devices, the values in the range of 64..127 are reserved for routers, and values in the range of 1..63 are reserved for hosts.
L2/L3デバイスのさまざまなクラスの相対的な優先度を反映するために、SBM対応デバイスの各タイプごとに個別の範囲の値が予約されています。L2デバイスは優先度が高く、その後ルーターが続いてホストが続きます。128..255の範囲の優先値はL2デバイスに予約され、64..127の範囲の値はルーター用に予約され、1..63の範囲の値はホスト用に予約されています。
The election algorithm works as described before in this case except each SBM-capable L2 device restricts the scope of the election to its local segment. As described in Section B.1 below, all messages related to the DSBM election are sent to a special multicast address (AllSBMAddress). AllSBMAddress (its corresponding MAC multicast address) is configured in the permanent database of SBM-capable, layer 2 devices so that all frames with AllSBMAddress as the destination address are not forwarded and instead directed to the SBM management entity in those devices. Thus, a DSBM can be elected separately on each point-to-point segment in a switched topology. For example, in Figure 2, DSBM for "segment A" will be elected using the election algorithm between R1 and S1 and none of the election-related messages on this segment will be forwarded by S1 beyond "segment A". Similarly, a separate election will take place on each segment in this topology.
選挙アルゴリズムは、各SBM対応L2デバイスを除き、この場合に説明したとおりに機能します。以下のセクションB.1で説明したように、DSBM選挙に関連するすべてのメッセージは、特別なマルチキャストアドレス（Allsbmaddress）に送信されます。AllSBMADDRESS（対応するMACマルチキャストアドレス）は、SBM対応のレイヤー2デバイスの永続的なデータベースで構成されているため、宛先アドレスが転送されず、代わりにそれらのデバイスのSBM管理エンティティに向けられているため、すべてのフレームがAllSBMADDRESSを使用します。したがって、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人の送信者のうちの1人が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つの送信者が各方向のリンクに送信されます。この場合、そのような管理されたセグメントに1つまたは2つのDSBMSが存在する可能性があります。両端の送信者がその端のDSBMとして機能することを望む場合、I_AM_DSBM広告を送信することにより、DSBMであると宣言し、セグメントを介した発信トラフィックのリソースの管理を開始できます。2人の送信者のいずれかがDSBMになることを望まない場合、もう1つの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の迅速な展開を確保するために、DSBMとの間のすべての通信は、RSVPメッセージ形式の現在のルールと生のIPカプセル化を使用して構築されたメッセージを使用して実行されます。RSVPメッセージ形式の詳細については、RSVP仕様（RFC 2205）を参照してください。RSVPメッセージ形式の変更は提案されていませんが、DSBM関連のメッセージに対応するために、新しいメッセージタイプと新しいL2固有のオブジェクトがRSVPメッセージ形式に追加されます。これらの追加を以下に説明します。
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の選挙と検出の目的で、AllsbmaddressはDSBM_WILLINGとI_AM_DSBMメッセージの両方を送信しながら、宛先アドレスとして使用されます。DSBMクライアントは、最初にI_AM_DSBM広告を聴き、DSBMADDRESS（DSBMのユニキャストIPアドレス）を記録することにより、マネージドセグメントを検出します。
Each message must occupy exactly one IP datagram. If it exceeds the MTU, such a datagram will be fragmented by IP and reassembled at the recipient node. This has a consequence that a single message may not exceed the maximum IP datagram size, approximately 64K bytes.
各メッセージは、正確に1つのIPデータグラムを占有する必要があります。MTUを超えると、そのようなデータグラムはIPによって断片化され、受信者ノードで再組み立てされます。これは、単一のメッセージが最大IPデータグラムのサイズ、約64Kバイトを超えない可能性があるという結果です。
All RSVP messages directed to and from a DSBM may contain various RSVP objects defined in the RSVP specification and messages continue to follow the formatting rules specified in the RSVP specification. In addition, an RSVP implementation must also recognize new object classes that are described below.
DSBMに送られたすべてのRSVPメッセージには、RSVP仕様で定義されているさまざまなRSVPオブジェクトが含まれている場合があり、メッセージはRSVP仕様で指定されたフォーマットルールに従っています。さらに、RSVPの実装は、以下で説明する新しいオブジェクトクラスも認識する必要があります。
All objects are defined using the format specified in the RSVP specification. Each object has a 32-bit header that contains length (of the object in bytes including the object header), the object class number, and a C-Type. All unused fields should be set to zero and ignored on receipt.
すべてのオブジェクトは、RSVP仕様で指定された形式を使用して定義されます。各オブジェクトには、（オブジェクトヘッダーを含むバイト内のオブジェクトの）、オブジェクトクラス番号、およびCタイプの長さを含む32ビットヘッダーがあります。すべての未使用のフィールドは、ゼロに設定し、受領時に無視する必要があります。
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）のクラス-NUM値は、CodeSpace 10XXXXXXから選択されていることに注意してください。このコーディングは、非SBM認識RSVPノードがオブジェクトを転送せず、エラーメッセージを生成せずにオブジェクトを無視することを保証します。
Within the SBM specific codespace, note the following interpretation of the third most significant bit of the Class-Num:
SBM固有のコードスペース内で、クラスNumの3番目に重要なビットの次の解釈に注意してください。
a) Objects of the form 100XXXXX are to be silently discarded by SBM nodes that do not recognize them.
a) フォーム100xxxxxのオブジェクトは、それらを認識していないSBMノードによって静かに廃棄されます。
b) Objects of the form 101XXXXX are to be silently forwarded by SBM nodes that do not recognize them.
b) フォーム101xxxxxのオブジェクトは、それらを認識しないSBMノードによって静かに転送されます。
The 48-bit MAC Addresses used by IEEE 802 were originally defined in terms of wire order transmission of bits in the source and destination MAC address fields. The same wire order applied to both Ethernet and Token Ring. Since the bit transmission order of Ethernet and Token Ring data differ - Ethernet octets are transmitted least significant bit first, Token Ring most significant first - the numeric values naturally associated with the same address on different 802 media differ. To facilitate the communication of address values in higher layer protocols which might span both token ring and Ethernet attached systems connected by bridges, it was necessary to define one reference format - the so called canonical format for these addresses. Formally the canonical format defines the value of the address, separate from the encoding rules used for transmission. It comprises a sequence of octets derived from the original wire order transmission bit order as follows. The least significant bit of the first octet is the first bit transmitted, the next least significant bit the second bit, and so on to the most significant bit of the first octet being the 8th bit transmitted; the least significant bit of the second octet is the 9th bit transmitted, and so on to the most significant bit of the sixth octet of the canonical format being the last bit of the address transmitted.
IEEE 802で使用される48ビットMACアドレスは、元々、ソースおよび宛先MACアドレスフィールドのビットのワイヤオーダー伝送に関して定義されていました。イーサネットとトークンリングの両方に同じワイヤオーダーが適用されます。イーサネットとトークンリングのデータのビット伝送順序は異なるため、イーサネットオクテットは最初に最も有意なビットを送信します。トークンリングは最初に最も重要なリングです。ブリッジで接続されたトークンリングとイーサネット接続システムの両方にまたがる可能性のある高層プロトコルでのアドレス値の通信を容易にするために、これらのアドレスのいわゆる標準形式である1つの参照形式を定義する必要がありました。正式には、標準形式は、送信に使用されるエンコードルールとは別のアドレスの値を定義します。次のように、元のワイヤ注文送信ビットの順序から派生したオクテットのシーケンスで構成されています。最初のオクテットの中で最も有意なビットは、最初のビットが送信され、次に最も重要なビットが2番目のビットであり、最初のオクテットの最も重要なビットは8ビット送信されます。2番目のオクテットの中で最も有意なビットは、9番目のビットが送信され、標準形式の6番目のオクテットの最も重要なビットが、送信されたアドレスの最後のビットです。
This canonical format corresponds to the natural value of the address octets for Ethernet. The actual transmission order or formal encoding rules for addresses on media which do not transmit bit serially are derived from the canonical format octet values.
この正規形式は、イーサネットのアドレスオクテットの自然値に対応します。ビットを連続的に送信しないアドレスの実際の送信順序または正式なエンコードルールは、標準形式のオクテット値から派生します。
This document requires that all L2 addresses used in conjunction with the SBM protocol be encoded in the canonical format as a sequence of 6 octets. In the following, we define the object formats for objects that contain L2 addresses that are based on the canonical representation.
このドキュメントでは、SBMプロトコルと組み合わせて使用されるすべてのL2アドレスを、6オクテットのシーケンスとして正規形式でエンコードすることが必要です。以下では、標準表現に基づいたL2アドレスを含むオブジェクトのオブジェクト形式を定義します。
RSVP_HOP_L2 object uses object class = 161; it contains the L2 address of the previous hop L3 device in the IEEE Canonical address format discussed above.
rsvp_hop_l2オブジェクトはオブジェクトクラス= 161を使用します。上記のIEEE Canonicalアドレス形式の以前のHOP 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オブジェクト：class = 161、c-typeは、使用されるアドレス指定形式を表します。この場合、C-Type = 1はIEEE Canonicalアドレス形式を表します。
0 1 2 3
+---------------+---------------+---------------+----------------+
| Length | 161 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+
| Variable length Opaque data |
+---------------+---------------+---------------+----------------+
C-Type = 1 (IEEE Canonical Address format)
c-type = 1（IEEE Canonicalアドレス形式）
When C-Type=1, the object format is:
c-type = 1の場合、オブジェクト形式は次のとおりです。
0 1 2 3
+---------------+---------------+---------------+---------------+
| 12 | 161 | 1 |
+---------------+---------------+---------------+---------------+
| Octets 0-3 of the MAC address |
+---------------+---------------+---------------+---------------+
| Octets 4-5 of the MAC addr. | /// | /// |
+---------------+---------------+---------------+---------------+
/// -- unused (set to zero)
///-未使用（ゼロに設定）
LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address
object and LAN_NHOP_L2 address object.
<LAN_NHOP object> ::= <LAN_NHOP_L2 object> <LAN_NHOP_L3 object>
LAN_NHOP_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-Type = 1（以下に定義するIEEE 802 Canonicalアドレス形式）詳細については、RSVP_HOP_L2アドレスオブジェクトを参照してください。
LAN_NHOP_L3 object uses object class = 163 and gives the L3 or IP address of the next hop L3 device.
LAN_NHOP_L3オブジェクトはオブジェクトクラス= 163を使用し、次のホップL3デバイスのL3またはIPアドレスを提供します。
LAN_NHOP_L3 object: class = 163, C-Type specifies IPv4 or IPv6 address family used.
LAN_NHOP_L3オブジェクト：class = 163、cタイプは、使用する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) |
+---------------------------------------------------------------+
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オブジェクトは、パスメッセージの送信インターフェイスのIPアドレスを指定し、オブジェクトクラス= 164を使用します。IPv4フォーマットとIPv6形式の両方が指定されています。
IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | 164 | 1 |
+---------------+---------------+---------------+---------------+
| IPV4 address of an interface |
+---------------+---------------+---------------+---------------+
IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2
+---------------+---------------+---------------+---------------+
| Length | 164 | 2 |
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPV6 address of an interface +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
TCLASS object (traffic class based on IEEE 802.1p) uses object class = 165.
TCLASSオブジェクト（IEEE 802.1pに基づくトラフィッククラス）は、オブジェクトクラス= 165を使用します。
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | 165 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /// | /// | /// | /// | PV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Only 3 bits in data contain the user_priority value (PV).
データの3ビットのみがuser_priority値（PV）を含んでいます。
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.
整合性オブジェクトが存在する場合、RSVP Commonヘッダーに直接たどる必要があります。L2固有のオブジェクトは、常にセッションオブジェクトの先行する必要があります。
As specified in the RSVP specification, an RSVP_RESV message contains the RSVP Common Header and relevant RSVP objects. In addition, it may contain an optional TCLASS object as described earlier.
RSVP仕様で指定されているように、RSVP_RESVメッセージにはRSVP共通ヘッダーと関連するRSVPオブジェクトが含まれています。さらに、前述のようにオプションのTCLASSオブジェクトが含まれる場合があります。
New RSVP message types are introduced to allow interactions between a DSBM and an RSVP node (host/router) for the purpose of discovering and binding to a DSBM. New RSVP message types needed are as follows:
DSBMを発見して結合する目的で、DSBMとRSVPノード（ホスト/ルーター）間の相互作用を可能にするために、新しいRSVPメッセージタイプが導入されています。必要な新しいRSVPメッセージタイプは次のとおりです。
RSVP Msg Type (8 bits) Value
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固有のメッセージは、RSVP共通ヘッダーとSBM固有のオブジェクトを備えた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メッセージの受信機を準備する必要があります。
All I_AM_DSBM messages are multicast to the well known AllSBMAddress. The default priority of a SBM is 1 and higher priority values represent higher precedence. The priority value zero indicates that the SBM is not eligible to be the DSBM.
すべてのI_AM_DSBMメッセージは、よく知られているAllsbmaddressのマルチキャストです。SBMのデフォルトの優先度は1であり、優先度の高い値が高いことは優先度が高いことです。優先値ゼロは、SBMがDSBMになる資格がないことを示しています。
Relevant Objects
関連するオブジェクト
DSBM IP ADDRESS objects use object class = 42; IPv4 DSBM IP ADDRESS object uses <Class=42, C-Type=1> and IPv6 DSBM IP ADDRESS object uses <Class=42, C-Type=2>.
DSBM IPアドレスオブジェクトはオブジェクトクラスを使用します= 42;IPv4 DSBM IPアドレスオブジェクトは<class = 42、c-type = 1>およびIPv6 DSBM IPアドレスオブジェクトを使用します<class = 42、c-type = 2>。
IPv4 DSBM IP ADDRESS object: class = 42, C-Type =1
0 1 2 3
+---------------+---------------+---------------+---------------+
| IPv4 DSBM IP Address |
+---------------+---------------+---------------+---------------+
IPv6 DSBM IP ADDRESS object: Class = 42, C-Type = 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 CanOnicalアドレス形式の場合はC-Type = 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-Type = 1（IEEE Canonicalアドレス形式）の場合、L2アドレスオブジェクトのこのようなバージョンには、MACアドレスに対応する6オクテットに値ゼロが含まれます（正確な形式についてはセクションB.3.4を参照）。
SBM_PRIORITY Object: class = 43, C-Type =1
0 1 2 3
+---------------+---------------+---------------+---------------+
| /// | /// | /// | SBM priority |
+---------------+---------------+---------------+---------------+
TIMER INTERVAL VALUES.
タイマー間隔値。
The two timer intervals, namely, DSBM Dead Interval and DSBM Refresh Interval, are specified as integer values each in the range of 0..255 seconds. Both values are included in a single "DSBM Timer Intervals" object described below.
2つのタイマー間隔、すなわちDSBMデッドインターバルとDSBMリフレッシュ間隔は、0..255秒の範囲でそれぞれ整数値として指定されます。両方の値は、以下で説明する単一の「DSBMタイマー間隔」オブジェクトに含まれています。
DSBM Timer Intervals Object: class = 44, C-Type =1
+---------------+---------------+---------------+----------------+
| /// | /// | DeadInterval | RefreshInterval|
+---------------+---------------+---------------+----------------+
NON_RESV_SEND_LIMIT Object: class = 45, C-Type = 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オブジェクトは、有効なRSVP予約なしで送信ホストがマネージドセグメントに送信できるトラフィックのプロファイルのフローごとの制限を指定します（このオブジェクトの使用に関する詳細については、付録Cを参照）。オブジェクトには、非resvsendlimitパラメーターが含まれます。このパラメーターは、intserv sender_tspecに相当します（内容とエンコーディングルールについては、RFC 2210を参照）。Sender_TSPECには、トラフィックプロファイル（R、B、P、M、M）を記述する5つのパラメーターが含まれています。送信ホストは、DSBMによって宣伝されているsender_tspecへの送信者トラフィックフローを説明する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 = 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.
ネットワーク管理者は、r = 0、b = 0、p = 0、m =無限、m = 0の非resvsendlimitを構成することにより、RSVP予約がない場合に送信されたトラフィックを禁止するようにDSBMを構成することができます。R =無限、b =無限、p =無限、m = 0、およびm =無限地を構成することにより、RSVP予約がない場合にトラフィックを送信することを許可します。もちろん、これらのパラメーターのいずれかは、ゼロと無限の間の値に設定されて、フローごとの限界を宣伝することができます。
The NON_RESV_SEND_LIMIT object is optional. Senders on a managed segment should interpret the absence of the NON_RESV_SEND_LIMIT object as equivalent to an infinitely large SENDER_TSPEC (it is permissible to send any traffic profile in the absence of an RSVP reservation).
non_resv_send_limitオブジェクトはオプションです。マネージドセグメントの送信者は、non_resv_send_limitオブジェクトが無限に大きなsender_tspecに相当すると解釈する必要があります（RSVP予約がない場合にトラフィックプロファイルを送信することは許可されます）。
Appendix C The DSBM as a Source of Centralized Configuration Information
付録C集中構成情報のソースとしてのDSBM
There are certain configuration parameters which it may be useful to distribute to layer-3 senders on a managed segment. The DSBM may serve as a centralized management point from which such parameters can easily be distributed. In particular, it is possible for the network administrator configuring a DSBM to cause certain configuration parameters to be distributed as objects appended to the I_AM_DSBM messages. The following configuration object is defined at this time. Others may be defined in the future. See Appendix B for further details regarding the NON_RESV_SEND_LIMIT object.
管理されたセグメントでレイヤー3センダーに配布することが役立つ可能性のある特定の構成パラメーターがあります。DSBMは、そのようなパラメーターを簡単に分散できる集中管理ポイントとして機能する場合があります。特に、DSBMを構成するネットワーク管理者が、I_AM_DSBMメッセージに追加されたオブジェクトとして特定の構成パラメーターを配布する可能性があります。次の構成オブジェクトは、現時点で定義されています。その他は将来定義される場合があります。non_resv_send_limitオブジェクトに関する詳細については、付録Bを参照してください。
As we QoS enable layer 2 segments, we expect an evolution from subnets comprised of traditional shared segments (with no means of traffic separation and no DSBM), to subnets comprised of dedicated segments switched by sophisticated switches (with both DSBM and 802.1p traffic separation capability).
QoSがレイヤー2セグメントを有効にするため、従来の共有セグメントで構成されるサブネットからの進化（トラフィックの分離なしでDSBMなし）から、洗練されたスイッチによって切り替えられた専用セグメント（DSBMおよび802.1Pの交通分離を含む専用セグメントで構成されるサブネットからの進化が期待されています。能力）。
A set of intermediate configurations consists of a group of QoS enabled hosts sending onto a traditional shared segment. A layer-3 device (or a layer-2 device) acts as a DSBM for the shared segment, but cannot enforce traffic separation. In such a configuration, the DSBM can be configured to limit the number of reservations approved for senders on the segment, but cannot prevent them from sending. As a result, senders may congest the segment even though a network administrator has configured an appropriate limit for admission control in the DSBM.
中間構成のセットは、従来の共有セグメントに送信するQoS対応ホストのグループで構成されています。レイヤー-3デバイス（またはレイヤー2デバイス）は、共有セグメントのDSBMとして機能しますが、トラフィックの分離を強制することはできません。このような構成では、DSBMはセグメント上の送信者に承認された予約の数を制限するように構成できますが、送信を防ぐことはできません。その結果、ネットワーク管理者がDSBMでの入場制御に適切な制限を設定している場合でも、送信者はセグメントを混雑させることができます。
One solution to this problem which would give the network administrator control over the segment, is to require applications (or operating systems on behalf of applications) not to send until they have obtained a reservation. This is problematic as most applications are used to sending as soon as they wish to and expect to get whatever service quality the network is able to grant at that time. Furthermore, it may often be acceptable to allow certain applications to send before a reservation is received. For example, on a segment comprised of a single 10 Mbps ethernet and 10 hosts, it may be acceptable to allow a 16 Kbps telephony stream to be transmitted but not a 3 Mbps video stream.
ネットワーク管理者にセグメントを制御するこの問題の1つの解決策は、予約が得られるまで送信しないように、アプリケーション（またはアプリケーションに代わってオペレーティングシステム）を要求することです。ほとんどのアプリケーションは、ネットワークがその時点で許可できるサービス品質を取得することを望み、期待してすぐに送信に使用されるため、これは問題があります。さらに、予約を受ける前に特定のアプリケーションが送信できるようにすることは、多くの場合受け入れられるかもしれません。たとえば、単一の10 Mbpsイーサネットと10ホストのホストで構成されるセグメントでは、16 kbpsのテレフォニーストリームを送信しますが、3 Mbpsのビデオストリームではないことが許容される場合があります。
A more pragmatic solution then, is to allow the network administrator to set a per-flow limit on the amount of non-adaptive traffic which a sender is allowed to generate on a managed segment in the absence of a valid reservation. This limit is advertised by the DSBM and received by sending hosts. An API on the sending host can then approve or deny an application's QoS request based on the resources 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予約要求がまだ完了していないか拒否されていない場合、送信者がマネージドセグメントで生成できるトラフィックの形状を説明するFlowsPecを宣伝することができます。
ACKNOWLEDGEMENTS
謝辞
Authors are grateful to Eric Crawley (Argon), Russ Fenger (Intel), David Melman (Siemens), Ramesh Pabbati (Microsoft), Mick Seaman (3COM), Andrew Smith (Extreme Networks) for their constructive comments on the SBM design and the earlier versions of this document.
著者は、Eric Crawley（Argon）、Russ Fenger（Intel）、David Melman（Siemens）、Ramesh Pabbati（Microsoft）、Mick Seaman（3Com）、Andrew Smith（Extreme Networks）に、SBMデザインとThe Sbm DesignとThe The The Andrew Smith（Extreme Networks）に感謝しています。このドキュメントの以前のバージョン。
Raj Yavatkar Intel Corporation 2111 N.E. 25th Avenue, Hillsboro, OR 97124 USA
Raj Yavatkar Intel Corporation 2111 N.E.25番街、ヒルズボロ、または97124 USA
Phone: +1 503-264-9077
EMail: yavatkar@ibeam.intel.com
Don Hoffman Teledesic Corporation 2300 Carillon Point Kirkland, WA 98033 USA
ドンホフマンテレデシックコーポレーション2300カリヨンポイントカークランド、ワシントン州98033 USA
Phone: +1 425-602-0000
電話：1 425-602-0000
Yoram Bernet Microsoft 1 Microsoft Way Redmond, WA 98052 USA
Yoram Bernet Microsoft 1 Microsoft Way Redmond、WA 98052 USA
Phone: +1 206 936 9568 EMail: yoramb@microsoft.com Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 USA
電話：1 206 936 9568メール：Yoramb@microsoft.com Fred Baker Cisco Systems 519 Lado Drive Santa Barbara、California 93111 USA
Phone: +1 408 526 4257
EMail: fred@cisco.com
Michael Speer Sun Microsystems, Inc 901 San Antonio Road UMPK15-215 Palo Alto, CA 94303
Michael Speer Sun Microsystems、Inc 901 San Antonio Road Umpk15-215 Palo Alto、CA 94303
Phone: +1 650-786-6368
EMail: speer@Eng.Sun.COM
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。