RFC2814 日本語訳
2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-basedAdmission Control over IEEE 802-style networks. R. Yavatkar, D.Hoffman, Y. Bernet, F. Baker, M. Speer. May 2000. (Format: TXT=141886 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
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
Yavatkarがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2814年のインテルカテゴリ: 標準化過程D.ホフマンTeledesic Y.BernetマイクロソフトF.ベイカーコクチマスM.シュペーアサン・マイクロシステムズ2000年5月
SBM (Subnet Bandwidth Manager):
A Protocol for RSVP-based Admission Control over IEEE 802-style networks
SBM(サブネット帯域幅マネージャ): IEEEの802スタイルのネットワークの上のRSVPベースのAdmission Controlのためのプロトコル
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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のベースの入場コントロールのためにシグナリングメソッドとプロトコルについて説明します。 プロトコルは、IEEE802LANの現代と近作がIEEE802.1委員会によって完成していて働くように設計されています。
1. Introduction
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
インターネットアーキテクチャとサービスモデルへの新しい拡大は、アプリケーションが現在のIPベストエフォート型サービスに加えたインターネットワークから特定の品質かレベルのサービスを要求できるように、統合サービスインターネット[RFC-1633、RFC-2205、RFC-2210]と定義されました。 これらの拡大はIntegrated Servicesルータによってサポートされる新しいサービスのクラスのRSVP、資源予約セットアッププロトコル、および定義を含んでいます。 RSVPとサービスクラス定義は基本的なネットワーク・テクノロジーから主に独立しています、そして、RSVPとIntegrated Services仕様に関するマッピングを特定のサブネットワーク技術と定義するのが必要です。 そして例えば、サービス対応表の定義。
Yavatkar, et al. Standards Track [Page 1] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[1ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
reservation setup protocols is needed for specific link-layer technologies such as shared and switched IEEE-802-style LAN technologies.
予約セットアッププロトコルが共有されて切り換えられたIEEE802スタイル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などのインターネットレベルセットアッププロトコルを写像するためのメソッドをIEEE802スタイルネットワークに提供します。 特に、それは、LANリソースのRSVPによって可能にされたデータフローの予約をサポートするためにRSVPによって可能にされたホスト/ルータとリンクレイヤデバイス(スイッチ、ブリッジ)の操作について説明します。 共有されて切り換えられたIEEE802スタイルでIntegrated Servicesを提供して、マッピングが説明されるサービスのLAN技術と定義が分離するので、フレームワークは[RFC- FRAME、RFC-MAP]を記録します。
2. Goals and Assumptions
2. 目標と仮定
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:
IEEE802レベル-2つのネットワークにおける、SBM(サブネットBandwidthマネージャ)プロトコルとその入場コントロールと帯域幅管理の使用は以下の建築目標と仮定に基づいています:
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 topologiesの成ることの増強された使用に向かっていますが、私たちは、LAN技術がレガシーの共有されたか切り換えられたLANセグメントとIEEE 802.1p仕様に基づくより新しい切り換えられたセグメントについてずっと混ぜると思います。 したがって、私たちはレガシーと、より新しいLAN topologiesの両方の上の帯域幅を管理するのにシグナリングプロトコルを指定します、そして、スイッチ、ハブ、またはブリッジの新しい世代で利用可能になるとき、それは追加機能性(異なったトラフィックのクラスか統合サービスのクラスの明白なサポートなどの)を利用します。 その結果、SBMプロトコルはIEEE802LANで純粋にすべてのエンドシステムから協力(そして、実施)を必要とするものへの運営管理コントロール(RSVPによって可能にされた交通の流れによって消費された帯域幅の量の上)かスイッチを運動させる1と異なるさまざまな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
II。 このドキュメントはRSVP流れのLANベースの入場コントロールにシグナリングメソッドとプロトコルだけを指定します。 私たちはリンクレイヤのためにここでどんなトラフィックコントロールメカニズムも定義しません。 プロトコルは、IEEE802によって定義されたどんなそのようなメカニズムも使用するように設計されています。 さらに、私たちは、Layer3エンドシステム(例えば、ホストかルータ)が各流れが入場コントロールのために提出された以前の予約の要請で規定されたトラフィック仕様の範囲内にとどまるのを保証するためにIntegrated Services交通の流れを取り締まることによってトラフィックコントロールを運動させると思います。 そしてこの
Yavatkar, et al. Standards Track [Page 2] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[2ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
allows a system using SBM admission control combined with per flow
shaping at end systems and IEEE-defined traffic control at link
layer to realize some approximation of Controlled Load (and even
Guaranteed) services over IEEE 802-style LANs.
リンクレイヤでコントロールがエンドシステムで形成される流れ単位で結合したSBM入場とIEEEによって定義されたトラフィックコントロールを使用するシステムがIEEEの802スタイルのLANの上で何らかのControlled Load(そして、Guaranteedさえ)サービスの近似がわかるのを許容します。
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ベースの入場制御機構にメカニズムを列に並ばせるどんなリンクレイヤトラフィックコントロールや優先権がないとき、トラヒック負荷の総量がでしゃばった限界だけが共有されたLANに関する流れをRSVP可能にしました。 そのような環境で、交通の流れ分離メカニズムは全く同じ共有されたメディアで最も良い取り組みトラフィックからのRSVPによって可能にされた流れを保護するために存在していません、そして、それは802.1p対応することのスイッチだけから成りながら、トポロジーの外でそのようなメカニズムに関するユーティリティの問題を引き起こします。 しかしながら、私たちは、それでも、SBMベースの入場制御機構がレガシー(2つの理由による共有されたLANトポロジー)で目的に有効に適うと思います。 まず最初に、Integrated Servicesが交通の流れであると生成するすべてのノードがどんなトラフィックも送る前にリソースの予約を要求するのにSBMベースの入場コントロール手順を利用すると仮定すると、メカニズムはLAN管理者によって望まれていた領域の中のIntegrated Services流れによって生成されたトラフィックの総量を制限するでしょう(Appendix CでのNonResvSendLimitパラメタの議論を見てください)。 2番目に、TCP/IPベースのトラフィックソースによって生成されたベストエフォート型トラフィックは、一般に、レート適応型であり(TCP-スタイル「遅れた出発」輻輳回避メカニズムかRTP/RTCPプロトコルに基づくオーディオ/ビデオストリームによって使用されるフィードバックベースのレート適合メカニズムを使用します)、利用可能なネットワーク回線容量の範囲内にとどまるために適合します。 したがって、入場コントロールとレート適合の組み合わせは永続的なトラフィック混雑を避けるべきです。 しかしながら、これは、非統合しているサービストラフィックが基本的なLANインフラストラクチャにおけるトラフィックコントロールサポートがないときIntegrated Servicesトラフィックを妨げないのを保証しません。
3. Organization of the rest of this document
3. このドキュメントの残りの組織
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:
このドキュメントの残りはSBMベースの入場コントロール手順の詳述をIEEE802LAN技術に提供します。 ドキュメントは以下の通りまとめられます:
* 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は処理と推進PATH(そして、PATH_TEAR)メッセージのためにDSBMs(Subnet Bandwidthマネージャに指定される)、SBMs、およびDSBMクライアントで規則について説明します。
Yavatkar, et al. Standards Track [Page 3] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[3ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
* 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.
* DSBMがLayer3で合図するRSVPが不在のとき作動するかもしれないか、または別のシグナリングプロトコル(SNMPなどの)がLANセグメントに関するリソースを予約するのに使用されるとき、セクション6は、相互運用性が問題であると扱います。
* 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は1SBMが存在しているとき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の使用法を説明します。
4. Overview
4. 概要
4.1. Definitions
4.1. 定義
- Link Layer or Layer 2 or L2: We refer to data-link layer
technologies such as IEEE 802.3/Ethernet as L2 or layer 2.
- リンクレイヤ、層2またはL2: 私たちはL2か層2としてのIEEE802.3/イーサネットなどのデータ・リンク層技術を示します。
- Link Layer Domain or Layer 2 domain or L2 domain: a set of nodes
and links interconnected without passing through a L3 forwarding
function. One or more IP subnets can be overlaid on a L2 domain.
- Layer DomainかLayer2ドメインかL2ドメインをリンクしてください: L3推進機能を通り抜けないで、1セットのノードとリンクは内部連絡されました。 L2ドメインで1つ以上のIPサブネットをかぶせることができます。
- 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デバイス: 私たちはLayer2かL2デバイスとしてLayer2が機能性であると実装するだけであるデバイスについて言及します。 これらは802.1Dブリッジかスイッチを含んでいます。
- Internetwork Layer or Layer 3 or L3: Layer 3 of the ISO 7 layer
model. This document is primarily concerned with networks that use
the Internet Protocol (IP) at this layer.
- インターネットワーク層、層3またはL3: 3つのISO7階層モデルを層にしてください。 このドキュメントは主としてこの層でインターネットプロトコル(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の物理的なセグメント。 セグメントに関する例は(b) (a) CSMAかトークンパッシング(「共有されたL2セグメント」)を使用することでメディアアクセスのための主張を決議する共有されたイーサネットかToken-リングワイヤか2つのステーションの間の半二重リンクかスイッチ(c) (切り換えられた全二重リンクの一方向)を含んでいます。
Yavatkar, et al. Standards Track [Page 4] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[4ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
- 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".
- ユーザ_優先権: ユーザ_優先権はIEEE802サービスモデルにおける、すべてのフレームのトランスミッションとレセプションに関連している値です: それはMACサービスを利用している送付者によって供給されます。 データと共にそれを受信機にMACサービスを利用することで提供します。 それは実際にネットワークの上まで運ばれるかもしれません: トークンリング/802.5はこの値(FC八重奏では、コード化されます)(使用中のフレーム形式に依存する802.3がそうしない/、802.12がそうする基本的なイーサネット)を運びます。 802.1 pは、拡張フレーム形式を使用することでイーサネット、Token Ring、Demand-優先権、FDDIまたは他のMAC-層のメディアでブリッジしているネットワークの上までこの値を運ぶ一貫した方法を定義します。 ユーザ_優先権の用法は「特定のMAC手順による内部の層のサービスのサポート」という802.1D[IEEE8021D]と802.1p[IEEE8021P]のセクション2.5で完全に説明されます。
- Subnet: used in this memo to indicate a group of L3 devices
sharing a common L3 network address prefix along with the set of
segments making up the L2 domain in which they are located.
- サブネット: このメモでは、L3デバイスのグループを示すために、それらが位置しているL2ドメインを作るセグメントのセットに伴う一般的なL3ネットワーク・アドレス接頭語を共有しながら、使用されます。
- Bridge/Switch: a layer 2 forwarding device as defined by IEEE
802.1D. The terms bridge and switch are used synonymously in this
document.
- ブリッジするか、または切り替わってください: IEEE 802.1Dによって定義される層2の推進デバイス。 用語ブリッジとスイッチは同じ意味で本書では使用されます。
- DSBM: Designated SBM (DSBM) is a protocol entity that resides in a
L2 or L3 device and manages resources on a L2 segment. At most one
DSBM exists for each L2 segment.
- DSBM: SBM(DSBM)に指定されているのは、L2かL3デバイスに住んでいて、L2セグメントでリソースを管理するプロトコル実体です。 最も1つでは、DSBMはそれぞれのL2セグメントのために存在しています。
- SBM: the SBM is a protocol entity that resides in a L2 or L3
device and is capable of managing resources on a segment. However,
only a DSBM manages the resources for a managed segment. When more
than one SBM exists on a segment, one of the SBMs is elected to be
the DSBM.
- SBM: SBMはL2かL3デバイスにあるプロトコル実体であり、セグメントに関するリソースを管理できます。 しかしながら、DSBMだけが管理されたセグメントのためのリソースを管理します。 1SBMがセグメントに存在するとき、SBMsの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のデバイスによってインタコネクトされたいくつかの管理されたセグメントが拡張セグメントを構成します。
Yavatkar, et al. Standards Track [Page 5] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[5ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
- 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ドメインのセグメントで入場コントロールをリソースに及ぼすためにL2ドメインと存在しているDSBMsなしでそれを区別するために管理された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透明な」デバイスは、SBMsかDSBMs(それはRSVP意識しているかもしれませんが)に気づかなく、したがって、管理されたセグメントの上でSBMベースの入場コントロール手順に参加しません。 そのようなデバイスは、デバイスに、適切な標準の推進規則を使用して、SBMに関して透明です。 そのようなL2デバイスに関する例は資源予約に参加しないレガシースイッチです。
- Layer 3 and layer 2 addresses: We refer to layer 3 addresses of
L3/L2 devices as "L3 addresses" and layer 2 addresses as "L2
addresses". This convention will be used in the rest of the
document to distinguish between Layer 3 and layer 2 addresses used
to refer to RSVP next hop (NHOP) and previous hop (PHOP) devices.
For example, in conventional RSVP message processing, RSVP_HOP
object in a PATH message carries the L3 address of the previous
hop device. We will refer to the address contained in the RSVP_HOP
object as the RSVP_HOP_L3 address and the corresponding MAC
address of the previous hop device will be referred to as the
RSVP_HOP_L2 address.
- 層3と層2のアドレス: 私たちは「L2アドレス」として「L3アドレス」と層2のアドレスとL3/L2装置の層3のアドレスを呼びます。 このコンベンションは、RSVP次のホップ(NHOP)と前のホップ(PHOP)装置について言及するのに使用されるLayer3と層2のアドレスを見分けるのにドキュメントの残りに使用されるでしょう。 例えば、従来のRSVPメッセージ処理では、HOPがPATHメッセージで反対させるRSVP_は前のホップ装置のL3アドレスを運びます。 私たちはRSVP_HOP_L3アドレスと前のホップ装置の対応するMACアドレスがRSVP_HOP_L2アドレスと呼ばれるようにRSVP_HOP物に含まれたアドレスを参照するつもりです。
4.2. Overview of the SBM-based Admission Control Procedure
4.2. SBMベースの入場コントロール手順の概観
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クライアントからそのセグメントで発するリソース予約の要請の入場コントロールに原因となります。 セグメントを考えて、1SBMsがセグメントに存在するかもしれません。 例えば、多くのSBMできる装置が共有されたL2セグメントに取り付けられるかもしれませんが、2個のSBMできるスイッチが半分のデュプレックスの切り換えられたセグメントを共有するかもしれません。 その場合、独身のDSBMはセグメントのために選出されます。 ダイナミックにDSBMを選出するための手順はAppendix A.で説明されます。管理されたセグメントにDSBMを指定するための他の唯一の承認された方法はSBMできる装置での静的な構成です。
Yavatkar, et al. Standards Track [Page 6] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[6ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
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は入場コントロールの目的のためにただ一つの管理されたセグメントとしてそのようなセグメントの収集を扱うそれらのセグメントのためのリソースを管理するでしょう。
4.2.1. Basic Algorithm
4.2.1. 基本的なアルゴリズム
Figure 1 - An Example of a Managed Segment.
図1--管理されたセグメントに関する例。
+-------+ +-----+ +------+ +-----+ +--------+
|Router | | Host| | DSBM | | Host| | Router |
| R2 | | C | +------+ | B | | R3 |
+-------+ +-----+ / +-----+ +--------+
| | / | |
| | / | |
==============================================================LAN
| |
| |
+------+ +-------+
| Host | | Router|
| A | | R1 |
+------+ +-------+
+-------+ +-----+ +------+ +-----+ +--------+ |ルータ| | ホスト| | DSBM| | ホスト| | ルータ| | R2| | C| +------+ | B| | R3| +-------+ +-----+ / +-----+ +--------+ | | / | | | | / | | ==============================================================LAN| | | | +------+ +-------+ | ホスト| | ルータ| | 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は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装置で静的である傾向があります。 今後の活動はこの情報のダイナミックな発見を考慮するかもしれません。 このドキュメントは構成メカニズムを指定しません。
Yavatkar, et al. Standards Track [Page 7] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[7ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
2. DSBM Client Initialization: For each interface attached, a DSBM
client determines whether a DSBM exists on the interface. The
procedure for discovering and verifying the existence of the DSBM
for an attached segment is described in Appendix A. If the client
itself is capable of serving as the DSBM on the segment, it may
choose to participate in the election to become the DSBM. At the
start, a DSBM client first verifies that a DSBM exists in its L2
domain so that it can communicate with the DSBM for admission
control purposes.
2. DSBMクライアント初期設定: それぞれの添付のインタフェースに関しては、DSBMクライアントは、DSBMがインタフェースに存在するかどうかと決心しています。 付属セグメントのためにDSBMの存在を発見して、確かめるための手順はクライアント自身がセグメントのDSBMとして役立つことができるAppendix A.Ifで説明されて、それは、DSBMになるように選挙に参加するのを選ぶかもしれません。 始めでは、DSBMクライアントは、最初に、DSBMが入場管理目的のためにDSBMとコミュニケートできるようにL2ドメインに存在することを確かめます。
In the case of a full-duplex segment, an election may not be
necessary as the SBM at each end will typically act as the DSBM
for outgoing traffic in each direction.
全二重セグメントの場合では、各端のSBMが外向的な交通へのDSBMとして各方向に通常機能するので、選挙は必要でないかもしれません。
3. DSBM-based Admission Control: To request reservation of resources
(e.g., LAN bandwidth in a L2 domain), DSBM clients (RSVP-capable
L3 devices such as hosts and routers) follow the following steps:
3. DSBMベースの入場コントロール: リソース(例えば、L2ドメインのLAN帯域幅)の予約を要求するために、DSBMクライアント(ホストやルータなどのRSVPできるL3装置)は以下の方法に従います:
a) When a DSBM client sends or forwards a RSVP PATH message over
an interface attached to a managed segment, it sends the PATH
message to the segment's DSBM instead of sending it to the RSVP
session destination address (as is done in conventional RSVP
processing). After processing (and possibly updating an
ADSPEC), the DSBM will forward the PATH message toward its
destination address. As part of its processing, the DSBM builds
and maintains a PATH state for the session and notes the
previous L2/L3 hop that sent it the PATH message.
a) DSBMクライアントが管理されたセグメントに付けられたインタフェースの上にRSVP PATHメッセージを送るか、または転送するとき、それはRSVPセッション送付先アドレスにそれを送ることの代わりにセグメントのDSBMにPATHメッセージを送ります(従来のRSVP処理でするように)。 処理(ことによるとADSPECをアップデートして)の後に、DSBMは送付先アドレスに向かってPATHメッセージを転送するでしょう。 処理の一部として、DSBMは、セッションと注意のためのPATH状態がPATHメッセージをそれに送った前のL2/L3ホップであることを、建てて、支持します。
Let us consider the managed segment in Figure 1. Assume that a
sender to a RSVP session (session address specifies the IP
address of host A on the managed segment in Figure 1) resides
outside the L2 domain of the managed segment and sends a PATH
message that arrives at router R1 which is on the path towards
host A.
図1の管理されたセグメントを考えましょう。 RSVPセッション(セッションアドレスは図1の管理されたセグメントでホストAのIPアドレスを指定する)までの送付者が管理されたセグメントのL2ドメインの外に住んでいて、経路にあるルータR1に到着するPATHメッセージをホストAに向かって送ると仮定してください。
DSBM client on Router R1 forwards the PATH message from the
sender to the DSBM. The DSBM processes the PATH message and
forwards the PATH message towards the RSVP receiver (Detailed
message processing and forwarding rules are described in
Section 5). In the process, the DSBM builds the PATH state,
remembers the router R1 (its L2 and l3 addresses) as the
previous hop for the session, puts its own L2 and L3 addresses
in the PHOP objects (see explanation later), and effectively
inserts itself as an intermediate node between the sender (or
R1 in Figure 1) and the receiver (host A) on the managed
segment.
Router R1の上のDSBMクライアントは送付者からDSBMまでPATHメッセージを転送します。 DSBMはPATHメッセージを処理して、RSVP受信機に向かってPATHメッセージを転送します(詳細なメッセージ処理と推進規則はセクション5で説明されます)。 それ自身のL2が、過程で、DSBMはPATH状態を造ります、とルータR1(L2とl3アドレス)がセッションのために前のホップとして覚えているのを置いて、L3はPHOPに物(後で説明を見る)を記述して、事実上、中間的ノードとして管理されたセグメントで送付者(または、図1のR1)と受信機(ホストA)の間にそれ自体を挿入します。
Yavatkar, et al. Standards Track [Page 8] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[8ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
b) When an application on host A wishes to make a reservation for
the RSVP session, host A follows the standard RSVP message
processing rules and sends a RSVP RESV message to the previous
hop L2/L3 address (the DSBMs address) obtained from the PHOP
object(s) in the previously received PATH message.
b) ホストAにおけるアプリケーションがRSVPセッションのために予約をしたがっているとき、ホストAは、以前に受信されたPATHメッセージのPHOP物から得られた前のホップL2/L3アドレス(DSBMsアドレス)に、標準のRSVPメッセージ処理規則に従って、RSVP RESVメッセージを送ります。
c) The DSBM processes the RSVP RESV message based on the bandwidth
available and returns an RESV_ERR message to the requester
(host A) if the request cannot be granted. If sufficient
resources are available and the reservation request is granted,
the DSBM forwards the RESV message towards the PHOP(s) based on
its local PATH state for the session. The DSBM merges
reservation requests for the same session as and when possible
using the rules similar to those used in the conventional RSVP
processing (except for an additional criterion described in
Section 5.8).
c) 要求を承諾できないなら、DSBMは利用可能な帯域幅に基づくRSVP RESVメッセージを処理して、リクエスタ(ホストA)にRESV_ERRメッセージを返します。 十分なリソースが利用可能であり、予約の要請を与えるなら、DSBMはセッションのために地方のPATH状態に基づくPHOP(s)に向かってRESVメッセージを転送します。 同じくらいそして、可能であるときに、DSBMは、従来の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ドメインが1つ以上の管理されたセグメントを含んでいるなら、リクエスタ(ホストA)と混載業者(ルータR1)は1つ以上の管理されたセグメントによって切り離されるかもしれません。 その場合、オリジナルのPATHメッセージは、各DSBMにPATH状態を設立しながら、多くのDSBMs(R1からAまでの経路のそれぞれの管理されたセグメントあたり1つ)を通して伝播されるでしょう。 したがって、RESVメッセージは、ホップごとに中間的DSBMsを通して逆であり伝播して、すべてのDSBMsでの入場コントロールが成功するなら、結局、L2ドメインでオリジナルの混載業者(ルータR1)に届くでしょう。
4.2.2. Enhancements to the conventional RSVP operation
4.2.2. 従来のRSVP操作への増進
(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で続きます。
4.2.2.1 Sending PATH Messages to the DSBM on a Managed Segment
4.2.2.1 管理されたセグメントのDSBMに経路メッセージを送ること。
Normal RSVP forwarding rules apply at a DSBM client when it is not forwarding an outgoing PATH message over a managed segment. However, outgoing PATH messages on a managed segment are sent to the DSBM for the corresponding managed segment (Section 5.2 describes how the PATH messages are sent to the DSBM on a managed segment).
送信するPATHメッセージを管理されたセグメントの上に転送していないとき、正常なRSVP推進規則はDSBMクライアントで適用されます。 しかしながら、対応する管理されたセグメントのために管理されたセグメントに関する送信するPATHメッセージをDSBMに送ります(セクション5.2はどうPATHメッセージを送るかを管理されたセグメントのDSBMに説明します)。
4.2.2.2 The LAN_NHOP Objects
4.2.2.2 LAN_NHOP物
In conventional RSVP processing over point-to-point links, RSVP nodes (hosts/routers) use RSVP_HOP object (NHOP and PHOP info) to keep track of the next hop (downstream node in the path of data packets in a traffic flow) and the previous hop (upstream nodes with respect to
ポイントツーポイント接続の上の従来のRSVP処理に、RSVPノード(ホスト/ルータ)が次のホップ(データ・パケットの経路の交通の流れにおける川下のノード)と前のホップの動向をおさえるのに、RSVP_HOP物(NHOPとPHOPインフォメーション)を使用する、(上流のノード
Yavatkar, et al. Standards Track [Page 9] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[9ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
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.
データフロー) . PATHメッセージの経路に沿ったルータが送付先アドレスに向かったメッセージを転送する送付者と受信機の間の経路のノードはテーブルをL3ルーティング(パケット推進)に基礎づけました。
For example, consider the L2 domain in Figure 1. Assume that both the sender (some host X) and the receiver (some host Y) in a RSVP session reside outside the L2 domain shown in the Figure, but PATH messages from the sender to its receiver pass through the routers in the L2 domain using it as a transit subnet. Assume that the PATH message from the sender X arrives at the router R1. R1 uses its local routing information to decide which next hop router (either router R2 or router R3) to use to forward the PATH message towards host Y. However, when the path traverses a managed L2 domain, we require the PATH and RESV messages to go through a DSBM for each managed segment. Such a L2 domain may span many managed segments (and DSBMs) and, typically, SBM protocol entities on L2 devices (such as a switch) will serve as the DSBMs for the managed segments in a switched topology. When R1 forwards the PATH message to the DSBM (an L2 device), the DSBM may not have the L3 routing information necessary to select the egress router (between R2 and R3) before forwarding the PATH message. To ensure correct operation and routing of RSVP messages, we must provide additional forwarding information to DSBMs.
例えば、図1のL2ドメインを考えてください。 送付者(ホストX)とRSVPセッションにおける受信機(ホストY)の両方が図に示されたL2ドメインの外に住んでいると仮定してください、L2ドメインのルータを通した送付者から受信機パスまでのPATHメッセージだけがトランジットサブネットとしてそれを使用して。 送付者XからのPATHメッセージがルータR1に到着すると仮定してください。 R1はホストY.Howeverに向かってPATHメッセージを転送するのに、どの次のホップルータ(ルータR2かルータR3のどちらか)を使用したらよいかを決めるのにローカルのルーティング情報を使用します、経路が管理されたL2ドメインを横断するとき私たちはPATHとそれぞれの管理されたセグメントのためにDSBMを通るRESVメッセージを必要とします。 そのようなL2ドメインは多くの管理されたセグメント(そして、DSBMs)にかかるかもしれません、そして、通常、L2装置(スイッチなどの)の上のSBMプロトコル実体は管理されたセグメントのためのDSBMsとして切り換えられたトポロジーで機能するでしょう。 R1がDSBM(L2装置)にPATHメッセージを転送するとき、DSBMはPATHメッセージを転送する前に、L3ルーティング情報を出口ルータを選択するのに必要に(R2とR3の間の)しないかもしれません。 RSVPメッセージの正しい操作とルーティングを確実にするために、私たちは追加推進情報をDSBMsに供給しなければなりません。
For this purpose, we introduce new RSVP objects called LAN_NHOP address objects that keep track of the next L3 hop as the PATH message traverses an L2 domain between two L3 entities (RSVP PHOP and NHOP nodes).
このために、私たちはPATHメッセージが2つのL3実体(RSVP PHOPとNHOPノード)の間のL2ドメインを横断するとき次のL3ホップの動向をおさえるLAN_NHOPアドレス物と呼ばれる新しいRSVP物を紹介します。
4.2.2.3 Including Both Layer-2 and Layer-3 Addresses in the LAN_NHOP
4.2.2.3 ラン_NHOPの層-2と層-3つのアドレスの両方を含んでいること。
When a DSBM client (a host or a router acting as the originator of a PATH message) sends out a PATH message to the DSBM, it must include LAN_NHOP information in the message. In the case of a unicast destination, the LAN_NHOP address specifies the destination address (if the destination is local to its L2 domain) or the address of the next hop router towards the destination. In our example of an RSVP session involving the sender X and receiver Y with L2 domain in Figure 1 acting as the transit subnet, R1 is the ingress node that receives the PATH message. R1 first determines that R2 is the next hop router (or the egress node in the L2 domain for the session address) and then inserts a LAN_NHOP object that specifies R2's IP address. When a DSBM receives a PATH message, it can now look at the address in the LAN_NHOP object and forward the PATH message towards the egress node after processing the PATH message. However, we expect the L2 devices (such as switches) to act as DSBMs on the path within the L2 domain and it may not be reasonable to expect these devices to have an ARP capability to determine the MAC address (we
DSBMクライアント(PATHメッセージの創始者として務めるホストかルータ)がPATHメッセージをDSBMに出すとき、それはメッセージにLAN_NHOP情報を含まなければなりません。 ユニキャストの目的地の場合では、LAN_NHOPアドレスは送付先アドレス(目的地がL2ドメインに地方であるなら)か次のホップルータのアドレスを目的地に向かって指定します。 私たちの図1のトランジットサブネットとして機能するL2ドメインに送付者Xと受信機YにかかわるRSVPセッションに関する例では、R1はPATHメッセージを受け取るイングレスノードです。 R1は最初に、R2が次のホップルータ(または、セッションアドレスのためのL2ドメインの出口ノード)であることを決定して、次に、R2のIPアドレスを指定するLAN_NHOP物を挿入します。 DSBMがPATHメッセージを受け取るとき、それは、今、LAN_NHOP物のアドレスを見て、PATHメッセージを処理した後に、出口ノードに向かってPATHメッセージを転送できます。 しかしながら、これらの装置にはMACアドレスを決定するARP能力があると予想するのがL2ドメインの中の経路のDSBMsとそれは妥当でないかもしれなくて、私たちが、L2装置(スイッチなどの)が作動すると予想する、(私たち
Yavatkar, et al. Standards Track [Page 10] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[10ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
call it L2ADDR for Layer 2 address) corresponding to the IP address in the LAN_NHOP object.
それをLayer2アドレスのためのL2ADDR) 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装置で、発生される)がIPアドレス(LAN_NHOP_L3アドレス)とL2ドメインの上の次のL3ホップのための対応するMACアドレス(LAN_NHOP_L2アドレス)の両方を含んでいるのを必要とします。 LAN_NHOP_L3アドレスはL3装置でSBMプロトコル実体によって使用されて、PATHメッセージを目的地に向かって転送しますが、L2アドレスはL2装置でSBMプロトコル実体によって使用されて、L3 NHOP(L2ドメインからの出口ポイント)に向かってPATHメッセージを転送する方法を決定します。 LAN_NHOP情報と関連物の正確な形式は後でAppendix Bで説明されます。
4.2.2.4 Similarities to Standard RSVP Message Processing
4.2.2.4 標準のRSVPメッセージ処理への類似性
- When a DSBM receives a RSVP PATH message, it processes the PATH
message according to the PATH processing rules described in the
RSVP specification. In particular, the DSBM retrieves the IP
address of the previous hop from the RSVP_HOP object in the PATH
message and stores the PHOP address in its PATH state. It then
forwards the PATH message with the PHOP (RSVP_HOP) object modified
to reflect its own IP address (RSVP_HOP_L3 address). Thus, the
DSBM inserts itself as an intermediate hop in the chain of nodes
in the path between two L3 nodes across the L2 domain.
- DSBMがRSVP PATHメッセージを受け取るとき、RSVP仕様で説明されたPATH処理規則に従って、それはPATHメッセージを処理します。 DSBMは特に、PATHメッセージでRSVP_HOP物から前のホップのIPアドレスを検索して、PATH状態にPHOPアドレスを格納します。 そして、PHOP(RSVP_HOP)物がそれ自身のIPアドレス(RSVP_HOP_L3アドレス)を反映するように変更されている状態で、それはPATHメッセージを転送します。 したがって、DSBMは中間的ホップとしてL2ドメイン中の2つのL3ノードの間の経路のノードのチェーンにそれ自体を挿入します。
- The PATH state in a DSBM is used for forwarding subsequent RESV
messages as per the standard RSVP message processing rules. When
the DSBM receives a RESV message, it processes the message and
forwards it to appropriate PHOP(s) based on its PATH state.
- DSBMのPATH状態は、標準のRSVPメッセージ処理規則に従ってその後のRESVメッセージを転送するのに使用されます。 DSBMがRESVメッセージを受け取るとき、それは、PATH状態に基づくPHOP(s)を当てるためにメッセージを処理して、それを進めます。
- 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メッセージと地方のPATH状態をきれいにするとき、特に、ちょうど中間的DSBM(s)を通してPATH_TEARメッセージを発送します。
- 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
- 今までのところ、私たちはPATHメッセージに経路の管理されたセグメントに沿って各DSBMでPATH状態を設置しながらL2ドメインを通してどう伝播されるかを説明しました。 LAN_NHOPオブジェクトの層2のアドレス(LAN_NHOP_L2アドレス)は経路に沿ったL2デバイスによって使用されて、次のL3ホップに向かってPATHメッセージを転送する方法を決めるべきです。 そのようなデバイスが規則を進めながら標準のIEEE 802.1Dを適用する、(例えば、フィルタリングデータベースに基づく単一のポートにそれを送るか、またはL2アドレスがフィルタリングに現れないなら、スパニングツリーでアクティブなすべてのポートの上にそれをあふれさせてください。
Yavatkar, et al. Standards Track [Page 11] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[11ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
database) to the LAN_NHOP_L2 address as are applied normally to
data packets destined to the address.
データベース) 通常、アドレスに運命づけられたデータ・パケットに適用されるLAN_NHOP_L2アドレスに。
4.2.2.5 Including Both Layer-2 and Layer-3 Addresses in the RSVP_HOP
Objects
4.2.2.5 RSVP_ホップオブジェクトの層-2と層-3つのアドレスの両方を含んでいること。
In the conventional RSVP message processing, the PATH state established along the nodes on a path is used to route the RESV message from a receiver to a sender in an RSVP session. As each intermediate node builds the path state, it remembers the previous hop (stores the PHOP IP address available in the RSVP_HOP object of an incoming message) that sent it the PATH message and, when the RESV message arrives, the intermediate node simply uses the stored PHOP address to forward the RESV after processing it successfully.
従来のRSVPメッセージ処理では、経路のノードに沿って設置されたPATH状態は、RSVPセッションのときに受信機から送付者までRESVメッセージを発送するのに使用されます。 それぞれの中間的ノードが経路州を建てるとき、それは、単にPATHメッセージとRESVメッセージが到着するときの中間的ノードをそれに送った前のホップ(入力メッセージのRSVP_HOPオブジェクトで利用可能なPHOP IPアドレスを保存する)が首尾よくそれを処理した後に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実体がDSBMs(したがって、中間的RSVPはL2ドメインを跳ぶ)として送付者(PHOP)と受信機(NHOP)の間の経路に沿って機能すると予想します。 RESVメッセージがDSBMに到着するとき、したがって、それは、RESVメッセージを前のホップに転送するのに保存されたPHOP IPアドレスを使用しなければなりません。 しかしながら、L2デバイスにはARPキャッシュかRESVメッセージを転送する前に対応するL2アドレスにPHOP IPアドレスを写像するARP能力があると予想するのは妥当でないかもしれません。
To obviate the need for such address mapping at L2 devices, we use a RSVP_HOP_L2 object in the PATH message. The RSVP_HOP_L2 object includes the Layer 2 address (L2ADDR) of the previous hop and complements the L3 address information included in the RSVP_HOP object (RSVP_HOP_L3 address).
L2デバイスのそのようなアドレス・マッピングの必要性を取り除くために、私たちはPATHメッセージでRSVP_HOP_L2オブジェクトを使用します。 RSVP_HOPオブジェクト(RSVP_HOP_L3アドレス)にL3アドレス情報を含んでいて、RSVP_HOP_L2オブジェクトは前のホップと補数のLayer2アドレス(L2ADDR)を含んでいます。
When a L3 device constructs and forwards a PATH message over a managed segment, it includes its IP address (IP address of the interface over which PATH is sent) in the RSVP_HOP object and adds a RSVP_HOP_L2 object that includes the corresponding L2 address for the interface. When a device in the L2 domain receives such a PATH message, it remembers the addresses in the RSVP_HOP and RSVP_HOP_L2 objects in its PATH state and then overwrites the RSVP_HOP and RSVP_HOP_L2 objects with its own addresses before forwarding the PATH message over a managed segment.
L3デバイスが管理されたセグメントの上にPATHメッセージを構成して、転送するとき、それは、RSVP_HOPオブジェクトでIPアドレス(PATHが送られるインタフェースのIPアドレス)を含めて、対応するL2アドレスを含んでいるRSVP_HOP_L2オブジェクトをインタフェースに加えます。 L2ドメインのデバイスがそのようなPATHメッセージを受け取ると、それは、PATH状態のRSVP_HOPとRSVP_HOP_L2オブジェクトでアドレスを覚えていて、管理されたセグメントの上にPATHメッセージを転送する前のそれ自身のアドレスでRSVP_HOPとRSVP_HOP_L2オブジェクトを上書きします。
The exact format of RSVP_HOP_L2 object is specified in Appendix B.
RSVP_HOP_L2オブジェクトの正確な形式はAppendix Bで指定されます。
4.2.2.6 Loop Detection
4.2.2.6 輪の検出
When an RSVP session address is a multicast address and a SBM, DSBM, and DSBM clients share the same L2 segment (a shared segment), it is possible for a SBM or a DSBM client to receive one or more copies of a PATH message that it forwarded earlier when a DSBM on the same wire
RSVPセッションアドレスがマルチキャストアドレスであり、SBM、DSBM、およびDSBMクライアントが同じL2セグメント(共用セグメント)を共有するとき、SBMかDSBMクライアントが同じワイヤの上のDSBMであるときにそれが、より早く転送したPATHメッセージのコピー1部以上を受け取るのは、可能です。
Yavatkar, et al. Standards Track [Page 12] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[12ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
forwards it (See Section 5.7 for an example of such a case). To facilitate detection of such loops, we use a new RSVP object called the LAN_LOOPBACK object. DSBM clients or SBMs (but not the DSBMs reflecting a PATH message onto the interface over which it arrived earlier) must overwrite (or add if the PATH message does NOT already include a LAN_LOOPBACK object) the LAN_LOOPBACK object in the PATH message with their own unicast IP address.
それ(そのような場合の例に関してセクション5.7を見る)を進めます。 そのような輪の検出を容易にするために、私たちはLAN_LOOPBACKオブジェクトと呼ばれる新しいRSVPオブジェクトを使用します。 DSBMクライアントかSBMs(しかし、それが、より早く到着したインタフェースにPATHメッセージを反映しないいずれのDSBMsも)がPATHメッセージでそれら自身のユニキャストIPアドレスでLAN_LOOPBACKオブジェクトを上書きしなければなりません(PATHメッセージが既にLAN_LOOPBACKオブジェクトを含まないなら、加えてください)。
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オブジェクトのコンテンツをチェックすることによって、容易に写しを検出して、捨てることができます(写しPATHメッセージはLAN_LOOPBACKオブジェクトにデバイスの自己のインターフェース・アドレスを記載するでしょう)。 付録BはLAN_LOOPBACKオブジェクトの正確な形式を指定します。
4.2.2.7 802.1p, User Priority and TCLASS
4.2.2.7 802.1 p、ユーザ優先権、およびTCLASS
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).
Integrated Servicesワーキンググループによって提案されたモデルは彼らのトランジットの間、ネットワークの向こう側に互いからの交通の流れの分離を必要とします。 交通の流れ分離に関する動機は保護を同じ経路を共有するふらちな事をしている流れと他のベストエフォート型トラフィックからIntegrated Services流れに提供することです。 基本的なIEEE802.3/イーサネットネットワークは、異なったサービスを要求する異なった流れの中で差別するためにトラフィックのクラスのどんな概念も提供しません。 しかしながら、IEEE 802.1pはスイッチが異なったトラフィックのクラスを表しながらパケットでコード化されたいくつかの「ユーザ_優先権」値の中で差別化する方法(さらに詳しい明細については見ます[IEEE802Q、IEEE8021p])を定義します。 ネイティブのLANパケット(例えば、IEEE802.5のFC八重奏における)かMAC層を超えてカプセル化を使用することによって、ユーザ_優先順位の値をコード化できます。(例えば、イーサネットの場合では、各パケットに割り当てられたユーザ_優先順位の値は、フレームヘッダーでIEEE802によって定義された新しくて、拡張しているフレーム形式を使用することで運ばれるでしょう; しかしながら、1Q IEEE8021Q. IEEEは送付者かネットワークがどうユーザ_優先順位の値を使用するべきであるかに関して推薦状を全くしません。添付書類はユーザの使用法における推薦状を_優先順位の値にします(詳細に関してRFC-MAPを見てください)。
Under the Integrated Services model, L3 (or higher) entities that transmit traffic flows onto a L2 segment should perform per-flow policing to ensure that the flows do not exceed their traffic specification as specified during admission control. In addition, L3 devices may label the frames in such flows with a user_priority value to identify their service class.
Integrated Servicesモデルの下では、L2セグメントに交通の流れを伝えるL3(より高い)実体は、流れが入場コントロールの間の指定されるとしてのそれらのトラフィック仕様を超えていないのを保証するために1流れあたりの取り締まりを実行するべきです。 さらに、L3デバイスは、それらのサービスのクラスを特定するためにユーザ_優先順位の値でそのような流れでフレームをラベルするかもしれません。
For the purpose of this discussion, we will refer to the user_priority value carried in the extended frame header as the "traffic class" of a packet. Under the ISSLL model, the L3 entities, that send traffic and that use the SBM protocol, may select the appropriate traffic class of outgoing packets [RFC-MAP]. This
この議論の目的について、私たちはパケットの「トラフィックのクラス」として拡張フレームヘッダーで運ばれたユーザ_優先順位の値について言及するつもりです。 ISSLLの下では、モデル、トラフィックを送って、SBMプロトコルを使用するL3実体は適切なトラフィックのクラスの出発しているパケット[RFC-MAP]を選択するかもしれません。 これ
Yavatkar, et al. Standards Track [Page 13] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[13ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
selection may be overridden by DSBM devices, in the following manner. once a sender sends a PATH message, downstream DSBMs will insert a new traffic class object (TCLASS object) in the PATH message that travels to the next L3 device (L3 NHOP for the PATH message). To some extent, the TCLASS object contents are treated like the ADSPEC object in the RSVP PATH messages. The L3 device that receives the PATH message must remove and store the TCLASS object as part of its PATH state for the session. Later, when the same L3 device needs to forward a RSVP RESV message towards the original sender, it must include the TCLASS object in the RESV message. When the RESV message arrives at the original sender, the sender must use the user_priority value from the TCLASS object to override its selection for the traffic class marked in outgoing packets.
選択はDSBMデバイスによってくつがえされるかもしれません、以下の方法で。送付者がいったんPATHメッセージを送ると、川下のDSBMsは次のL3デバイス(PATHメッセージのためのL3 NHOP)に移動するPATHメッセージに新しいトラフィッククラスオブジェクト(TCLASSは反対する)を挿入するでしょう。 ある程度、TCLASSオブジェクト含有量はRSVP PATHメッセージのADSPECオブジェクトのように扱われます。 PATHメッセージを受け取るL3デバイスは、セッションのためにPATH状態の一部としてTCLASSオブジェクトを取り除いて、保存しなければなりません。 同じL3デバイスが、その後RSVP RESVメッセージを元の送り主に向かって転送する必要があるとき、それはRESVメッセージにTCLASSオブジェクトを含まなければなりません。 RESVメッセージが元の送り主に到着するとき、送付者は、出発しているパケットでマークされたトラフィックのクラスのために選択をくつがえすのにTCLASSオブジェクトからユーザ_優先順位の値を使用しなければなりません。
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オブジェクトの形式はAppendix B.Noteで指定されて、そのTCLASSと他のSBM特有のオブジェクトがRSVPメッセージですべてのRFC2205あたりの他の、そして、標準のRSVPオブジェクトに加えて運ばれるということです。
4.2.2.8 Processing the TCLASS Object
4.2.2.8 TCLASSオブジェクトを処理すること。
In summary, use of TCLASS objects requires following additions to the conventional RSVP message processing at DSBMs, SBMs, and DSBM clients:
概要では、TCLASSオブジェクトの使用は、DSBMs、SBMs、およびDSBMクライアントで従来のRSVPメッセージ処理に追加に続くのを必要とします:
* When a DSBM receives a PATH message over a managed segment and the
PATH message does not include a TCLASS object, the DSBM MAY add a
TCLASS object to the PATH message before forwarding it. The DSBM
determines the appropriate user_priority value for the TCLASS
object. A mechanism for selecting the appropriate user_priority
value is described in an accompanying document [RFC-MAP].
* DSBMが管理されたセグメントの上にPATHメッセージを受け取って、PATHメッセージがTCLASSオブジェクトを含んでいないと、それを進める前に、DSBM MAYはTCLASSオブジェクトをPATHメッセージに追加します。 DSBMはTCLASSオブジェクトのために適切なユーザ_優先順位の値を決定します。 適切なユーザ_優先順位の値を選択するためのメカニズムは添付書類[RFC-MAP]で説明されます。
* When SBM or DSBM receives a PATH message with a TCLASS object over
a managed segment in a L2 domain and needs to forward it over a
managed segment in the same L2 domain, it will store it in its
path state and typically forward the message without changing the
contents of the TCLASS object. However, if the DSBM/SBM cannot
support the service class represented by the user_priority value
specified by the TCLASS object in the PATH message, it may change
the priority value in the TCLASS to a semantically "lower" service
value to reflect its capability and store the changed TCLASS value
in its path state.
* SBMかDSBMが、TCLASSオブジェクトでL2ドメインの管理されたセグメントの上にPATHメッセージを受け取って、同じL2ドメインの管理されたセグメントの上にそれを送る必要があると、TCLASSオブジェクトのコンテンツを変えないで、それは、経路州にそれを保存して、メッセージを通常転送するでしょう。 しかしながら、DSBM/SBMがPATHメッセージにTCLASSオブジェクトによって指定されたユーザ_優先順位の値によって表されたサービスのクラスをサポートすることができないなら、それは、経路州に能力を反映して、変えられたTCLASS値を保存するためにTCLASSで優先順位の値を意味的に「より低い」サービス値に変えるかもしれません。
Yavatkar, et al. Standards Track [Page 14] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[14ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
[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.]
[注意: 添付書類は[RFC-MAP]がすべてのユーザ_優先順位の値の中で「最も低く2つの値の「より低い」か」決定するためにユーザ_優先順位の値の厳密な定義を提供して、ユーザ_優先順位の値がどう比較されるかを説明するIEEE802ネットワークの上でint-servマッピングを定義します。]
* 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.
このドキュメントが入場コントロールに使用される実際のアルゴリズムか方針を指定しないことに注意してください。 1つの極端では、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デバイスに住んでいる)がインタフェースの上で受け入れるというPATHメッセージにTCLASSオブジェクトを受け取るとき、それはPATH状態の一部としてTCLASSオブジェクトをインタフェースとして保存するべきです。 クライアントがその後インタフェースの同じセッションへのRESVメッセージを転送するとき、クライアントはそれがインタフェースの上で転送するRESVメッセージで(前のPATHメッセージに受け取られたものから変わりのない)でTCLASSオブジェクトを入れなければなりません。
* When a DSBM client receives a TCLASS object in an incoming RESV
message over a managed segment and local admission control
succeeds for the session for the outgoing interface over the
managed segment, the client must pass the user_priority value in
the TCLASS object to its local packet classifier. This will ensure
that the data packets in the admitted RSVP flow that are
subsequently forwarded over the outgoing interface will contain
the appropriate value encoded in their frame header.
* DSBMクライアントが入って来るRESVメッセージに管理されたセグメントの上にTCLASSオブジェクトを受け取って、地方の入場コントロールが外向的なインタフェースのためのセッションのために管理されたセグメントの上で成功すると、クライアントはTCLASSオブジェクトでユーザ_優先順位の値を地元のパケットクラシファイアに渡さなければなりません。 これは、認められたRSVP流動における次に外向的なインタフェースの上に送られるデータ・パケットが彼らのフレームヘッダーでコード化された適切な値を含むのを確実にするでしょう。
Yavatkar, et al. Standards Track [Page 15] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[15ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
* 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ドメインの管理されたセグメントの上にPATHかRESVメッセージを受け取って、そのドメインの外のインタフェースの上にPATH/RESVメッセージを転送する必要があると、PATH/RESVメッセージを転送する前に、L3デバイスはTCLASSオブジェクト(PATHメッセージの場合におけるLAN_NHOP、RSVP_HOP_L2、およびLAN_LOOPBACKオブジェクトに伴う)を取り除かなければなりません。 外向的なインタフェースが別々のL2ドメインにあるなら、そのインタフェースに適切な処理規則に従って、これらのオブジェクトは作り直されるかもしれません。
5. Detailed Message Processing Rules
5. 詳細なメッセージ処理規則
5.1. Additional Notes on Terminology
5.1. 用語に関する補注
* 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プロトコル実体は、SBMとしてインタフェースAに機能して、DSBMとしてインタフェースBに機能できました。
* 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クライアントを決して接待しないでしょう。
5.2. Use Of Reserved IP Multicast Addresses
5.2. 予約されたIPマルチキャストアドレスの使用
As stated earlier, we require that the DSBM clients forward the RSVP PATH messages to their DSBMs in a L2 domain before they reach the next L3 hop in the path. RSVP PATH messages are addressed, according to RFC-2205, to their destination address (which can be either an IP unicast or multicast address). When a L2 device hosts a DSBM, a simple-to-implement mechanism must be provided for the device to capture an incoming PATH message and hand it over to the local DSBM agent without requiring the L2 device to snoop for L3 RSVP messages.
より早く述べられるように、私たちは、彼らが経路で次のL3ホップに達する前にDSBMクライアントがL2ドメインのそれらのDSBMsにRSVP PATHメッセージを転送するのを必要とします。 RSVP PATHメッセージは扱われます、RFC-2205によると、それらの送付先アドレス(IPユニキャストかマルチキャストアドレスのどちらかであるかもしれない)に。 L2デバイスがDSBMを接待するとき、デバイスがL3 RSVPメッセージのために詮索するためにL2デバイスを必要としないで入って来るPATHメッセージを得て、地元の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を検出して、扱うのは可能であるべきです。
Yavatkar, et al. Standards Track [Page 16] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[16ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
To facilitate dynamic DSBM-client binding as well as to enable easy detection and capture of PATH messages at L2 devices, we require that a DSBM be addressed using a logical address rather than a physical address. We make use of reserved IP multicast address(es) for the purpose of communication with a DSBM. In particular, we require that when a DSBM client or a SBM forwards a PATH message over a managed segment, it is addressed to a reserved IP multicast address. Thus, a DSBM on a L2 device needs to be configured in a way to make it easy to intercept the PATH message and forward it to the local SBM protocol entity. For example, this may involve simply adding a static entry in the device's filtering database (FDB) for the corresponding MAC multicast address to ensure the PATH messages get intercepted and are not forwarded further without the DSBM intervention.
ダイナミックなDSBM-クライアント結合を容易にして、L2デバイスでPATHメッセージの簡単な検出と捕獲を可能にするために、私たちは、DSBMが物理アドレスよりむしろ論理アドレスを使用することで扱われるのを必要とします。 私たちはDSBMとのコミュニケーションの目的に予約されたIPマルチキャストアドレス(es)を利用します。 特に、私たちは、DSBMクライアントかSBMが管理されたセグメントの上にPATHメッセージを転送するとき、それが予約されたIPマルチキャストアドレスに扱われるのを必要とします。 したがって、L2デバイスの上のDSBMは、PATHメッセージを傍受して、地方のSBMプロトコル実体にそれを送るのを簡単にする方法で構成される必要があります。 例えば、これは、対応するMACマルチキャストアドレスが、PATHメッセージが妨害されて、より遠くにDSBM介入なしで転送されないのを保証するようにデバイスがデータベース(FDB)をフィルターにかける際に単に静的なエントリーを加えることを伴うかもしれません。
Similarly, a DSBM always sends the PATH messages over a managed segment using a reserved IP multicast address and, thus, the SBMs or DSBM clients on the managed segments must simply be configured to intercept messages addressed to the reserved multicast address on the appropriate interfaces to easily receive PATH messages.
同様に、DSBMは予約されたIPマルチキャストアドレスを使用することで管理されたセグメントの上にPATHメッセージをいつも送ります、そして、その結果、容易にPATHメッセージを受け取るために適切なインタフェースに関する予約されたマルチキャストアドレスに扱われたメッセージを傍受するために単に管理されたセグメントの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メッセージはずっとPATH状態の一部としてそれぞれの中間的ホップに保存された前のホップアドレスにユニキャストです。
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.
* それらはSBMsかDSBMsを接待する層2のデバイスの永久的なデータベースで構成されます、彼らがこれらのデバイスのSBM経営体に向けられるように。 これはこれらのデバイスが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*はこれがこのアドレスにClientを検出するために演説するPATHメッセージ*モニターにDSBMの存在を送ります。
Yavatkar, et al. Standards Track [Page 17] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[17ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
* Monitors this address to
receive PATH messages
forwarded by the DSBM
* DSBMによって転送されたPATHメッセージを受け取るためにこのアドレスをモニターします。
SBM * Sends PATH messages * Monitors and sends on this
to this address address to participate in
election of the DSBM
* Monitors this address to
receive PATH messages
forwarded by the DSBM
SBM*は、DSBMによって転送されたPATHメッセージを受け取るために*がDSBM*モニターの選挙に参加するためにこれでこのアドレスアドレスにモニターして、送るPATHメッセージにこのアドレスを送ります。
DSBM * Monitors this address * Monitors and sends on this
for PATH messages to participate in election
directed to it of the DSBM
* Sends PATH messages to this
address
DSBM*は、*がモニターするこのアドレスをモニターして、DSBM*についてそれに向けられた選挙に参加するPATHメッセージのためのこれがこのアドレスへのメッセージをPATHに送るのを転送します。
The L2 or MAC addresses corresponding to IP multicast addresses are computed algorithmically using a reserved L2 address block (the high order 24-bits are 00:00:5e). The Assigned Numbers RFC [RFC-1700] gives additional details.
IPマルチキャストアドレスに対応するL2かMACアドレスが、algorithmicallyに予約されたL2あて先ブロックを使用することで計算されます(高位の24ビットは00:00:5eです)。 Assigned民数記RFC[RFC-1700]は追加詳細を述べます。
5.3. Layer 3 to Layer 2 Address Mapping
5.3. 層2のアドレス・マッピングへの層3
As stated earlier, DSBMs or DSBM clients residing at a L3 device must include a LAN_NHOP_L2 address in the LAN_NHOP information so that L2 devices along the path of a PATH message do not need to separately determine the mapping between the LAN_NHOP_L3 address in the LAN_NHOP object and its corresponding L2 address (for example, using ARP).
L3デバイスに住んでいるDSBMsかDSBMクライアントが、より早く述べられるようにLAN_NHOP情報でLAN_NHOP_L2アドレスを入れなければならないので、PATHメッセージの経路に沿ったL2デバイスは別々にLAN_NHOPオブジェクトのLAN_NHOP_L3アドレスとその対応するL2アドレス(例えば、ARPを使用する)の間のマッピングを決定する必要はありません。
For the purpose of such mapping at L3 devices, we assume a mapping function called "map_address" that performs the necessary mapping:
L3デバイスのそのようなマッピングの目的のために、私たちは必要なマッピングを実行する「地図_アドレス」と呼ばれるマッピング機能を仮定します:
L2ADDR object = map_addr(L3Addr)
L2ADDRオブジェクト=地図_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オブジェクトの形式はAppendix Bで指定されます。
5.4. Raw vs. UDP Encapsulation
5.4. UDPカプセル化に対して生です。
We assume that the DSBMs, DSBM clients, and SBMs use only raw IP for encapsulating RSVP messages that are forwarded onto a L2 domain. Thus, when a SBM protocol entity on a L3 device forwards a RSVP message onto a L2 segment, it will only use RAW IP encapsulation.
私たちは、DSBMs、DSBMクライアント、およびSBMsがL2ドメインに転送されるメッセージをRSVPにカプセル化するのに生のIPだけを使用すると思います。 L3デバイスの上のSBMプロトコル実体がRSVPメッセージをL2セグメントに転送するときだけ、したがって、それはRAW IPカプセル化を使用するでしょう。
Yavatkar, et al. Standards Track [Page 18] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[18ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
5.5. The Forwarding Rules
5.5. 推進規則
The message processing and forwarding rules will be described in the context of the sample network illustrated in Figure 2.
メッセージ処理と推進規則は図2で例証されたサンプルネットワークの文脈で説明されるでしょう。
Figure 2 - A sample network or L2 domain consisting of switched and shared L2 segments
図2--切り換えられて共有されたL2セグメントから成るサンプルネットワークかL2ドメイン
..........
.
+------+ . +------+ seg A +------+ seg C +------+ seg D +------+
| H1 |_______| R1 |_________| S1 |_________| S2 |_______| H2 |
| | . | | | | | | | |
+------+ . +------+ +------+ +------+ +------+
. | /
1.0.0.0 . | /
. |___ /
. seg B | / seg E
.......... | /
2.0.0.0 | /
+-----------+
| S3 |
| |
+-----------+
|
|
|
|
seg F | .................
------------------------------ .
| | | .
+------+ +------+ +------+ . +------+
| H3 | | H4 | | R2 |____________| H5 |
| | | | | | . | |
+------+ +------+ +------+ . +------+
.
. 3.0.0.0
.................
.......... . +------+ . +------+ seg A+------+ seg C+------+ seg D+------+ | H1|_______| R1|_________| S1|_________| S2|_______| H2| | | . | | | | | | | | +------+ . +------+ +------+ +------+ +------+ . | / 1.0.0.0 . | / . |___ /seg B| /seg E… | / 2.0.0.0 | / +-----------+ | S3| | | +-----------+ | | | | seg F| ................. ------------------------------ . | | | . +------+ +------+ +------+ . +------+ | H3| | H4| | R2|____________| H5| | | | | | | . | | +------+ +------+ +------+ . +------+ . . 3.0.0.0 .................
Figure 2 illustrates a sample network topology consisting of three IP subnets (1.0.0.0, 2.0.0.0, and 3.0.0.0) interconnected using two routers. The subnet 2.0.0.0 is an example of a L2 domain consisting of switches, hosts, and routers interconnected using switched segments and a shared L2 segment. The sample network contains the following devices:
そして、図2が3つのIPサブネットから成るaサンプルネットワーク形態を例証する、(1.0 .0 .0 2.0 .0 .0、3.0 .0 .0は、)2つのルータを使用することで内部連絡されました。 サブネット、2.0、.0、.0、切り換えられたセグメントと共有されたL2セグメントを使用することでインタコネクトされたスイッチ、ホスト、およびルータから成るL2ドメインに関する例はそうです。 サンプルネットワークは以下のデバイスを含んでいます:
Yavatkar, et al. Standards Track [Page 19] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[19ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
Device Type SBM Type
装置タイプSBMはタイプします。
H1, H5 Host (layer 3) SBM Transparent H2-H4 Host (layer 3) DSBM Client R1 Router (layer 3) SBM R2 Router (layer 3) DSBM for segment F S1 Switch (layer 2) DSBM for segments A, B S2 Switch (layer 2) DSBM for segments C, D, E S3 Switch (layer 2) SBM
H1、セグメントAのためのセグメントF S1 Switch(層2)DSBM、セグメントC、DのためのB S2 Switch(層2)DSBM、E S3 Switch(層2)SBMのためのH5 Host(層3)SBM Transparent H2-H4 Host(層3)DSBM Client R1 Router(層3)SBM R2 Router(層3)DSBM
The following paragraphs describe the rules, which each of these devices should use to forward PATH messages (rules apply to PATH_TEAR messages as well). They are described in the context of the general network illustrated above. While the examples do not address every scenario, they do address most of the interesting scenarios. Exceptions can be discussed separately.
以下のパラグラフは規則について説明します(規則はまた、PATH_TEARメッセージに適用されます)。(それぞれのこれらのデバイスは、メッセージをPATHに転送するのに規則を使用するはずです)。 それらは上で例証された一般的なネットワークの文脈で説明されます。 例はあらゆるシナリオを扱うというわけではありませんが、それらはおもしろいシナリオの大部分を扱います。 別々に例外について議論できます。
The forwarding rules are applied to received PATH messages (routers and switches) or originating PATH messages (hosts), as follows:
推進規則は、受信されたPATHメッセージ(ルータとスイッチ)に適用されるか、または以下の通り、PATHメッセージ(ホスト)を溯源することです:
1. Determine the interface(s) on which to forward the PATH message
using standard forwarding rules:
1. 標準の推進規則を使用することでPATHメッセージを転送するインタフェースを決定してください:
* If there is a LAN_LOOPBACK object in the PATH message, and it
carries the address of this device, silently discard the
message. (See the section below on "Additional notes on
forwarding the PATH message onto a managed segment).
* PATHメッセージにはLAN_LOOPBACKオブジェクトがあって、このデバイスのアドレスを運ぶなら、静かにメッセージを捨ててください。 (下のセクションがオンであることを見てください、「PATHメッセージを管理されたセグメントに転送することに関する補注)」
* Layer 3 devices use the RSVP session address and perform a
routing lookup to determine the forwarding interface(s).
* 層3のデバイスは、RSVPセッションアドレスを使用して、推進インタフェースを決定するためにルーティングルックアップを実行します。
* Layer 2 devices use the LAN_NHOP_L2 address in the LAN_NHOP
information and MAC forwarding tables to determine the
forwarding interface(s). (See the section below on "Additional
notes on forwarding the PATH message onto a managed segment")
* 層2のデバイスは、推進インタフェースを決定するためにテーブルを進めながら、_LANのNHOP情報とMACのLAN_NHOP_L2アドレスを使用します。 (「PATHメッセージを管理されたセグメントに転送することに関する補注」の下のセクションを見ます)
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デバイスであるなら、インタフェースがDSBMによって管理された管理されたセグメントにあるか決定してください、I_AM_DSBMメッセージの存在か欠如に基づいて。 インタフェースが管理されたセグメントにないなら、RSVP_HOP_L2、LAN_NHOP、LAN_LOOPBACK、TCLASSオブジェクト(存在しているなら)、およびフォワードをユニキャストかマルチキャストの目的地に取り除いてください。
Yavatkar, et al. Standards Track [Page 20] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[20ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
(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 Class民数記(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. PATHメッセージを管理されたセグメントに転送してください:
* 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オブジェクトをPATHメッセージに挿入してください。 LAN_NHOPオブジェクトは次の層3のNHOP_L3とLAN_NHOP_L2アドレスが飛び越すラン_を運びます。 RSVP_HOP_L2オブジェクトはデバイスの自己のL2アドレスを運びます、そして、LAN_LOOPBACKオブジェクトは外向的なインタフェースのIPアドレスを含んでいます。
An L3 device should use the map_addr() function described
earlier to obtain an L2 address corresponding to an IP address.
L3デバイスはIPアドレスに対応するL2アドレスを得るために、より早く説明された地図_addr()機能を使用するはずです。
* If the device hosts the DSBM for the segment to which the
forwarding interface is attached, do the following:
* デバイスが推進インタフェースが付けているセグメントのためにDSBMを接待するなら、以下をしてください:
- Retrieve the PHOP information from the standard RSVP HOP
object in the PATH message, and store it. This will be used
to route RESV messages back through the L2 network. If the
PATH message arrived over a managed segment, it will also
contain the RSVP_HOP_L2 object; then retrieve and store also
the previous hop's L2 address in the PATH state.
- PATHメッセージの標準のRSVP HOPオブジェクトからのPHOP情報を検索してください、そして、それを保存してください。 これは、L2ネットワークを通してRESVメッセージを発送するのに使用されるでしょう。 また、PATHメッセージが管理されたセグメントの上で到着したなら、RSVP_HOP_L2オブジェクトを含むでしょう。 また、次に、PATH状態に前のホップのL2アドレスを検索して、保存してください。
- Copy the IP address of the forwarding interface (layer 2
devices must also have IP addresses) into the standard RSVP
HOP object and the L2 address of the forwarding interface
into the RSVP_HOP_L2 object.
- 推進インタフェース(また、層2のデバイスには、IPアドレスがなければならない)の標準のRSVP HOPオブジェクトへのIPアドレスとRSVP_HOP_L2オブジェクトへの推進インタフェースの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.
- 受け取られたPATHメッセージがTCLASSオブジェクトを含まないなら、TCLASSオブジェクトを挿入してください。 TCLASSオブジェクトに挿入されたユーザ_優先順位の値は[RFC-MAP]にリストアップされたガイドラインに従った構成されたデバイスへの内部のサービス対応表に基づいています。 メッセージが既にTCLASSオブジェクトを含んでいるなら、再びデバイスへの内部のサービス対応表でベースでユーザ_優先順位の値を変えるかもしれません。
Yavatkar, et al. Standards Track [Page 21] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[21ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
* 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.
* 推進が連結するセグメントのためのSBMはデバイスが層3のデバイスとホストであるなら付属しています、それ。*はPHOPインフォメーションを検索して、保存する必要な*です。
If the device is a layer 2 device and hosts a SBM for the
segment to which the forwarding interface is attached, it is
*not* required to retrieve and store the PHOP info. If it does
not do so, the SBM must leave the standard RSVP HOP object and
the RSVP_HOP_L2 objects in the PATH message intact and it will
not receive RESV messages.
デバイスが層2のデバイスであり、推進インタフェースが付けているセグメントのためにSBMを接待するなら、それは*でないのがPHOPインフォメーションを検索して、保存するのを必要とした*です。 そうしないなら、SBMはPATHメッセージで標準のRSVP HOPオブジェクトとRSVP_をHOP_L2オブジェクトに完全なままにしなければなりません、そして、それはRESVメッセージを受け取らないでしょう。
If the SBM on a L2 device chooses to overwrite the RSVP HOP and
RSVP_HOP_L2 objects with the IP and L2 addresses of its
forwarding interface, it will receive RESV messages. In this
case, it must store the PHOP address info received in the
standard RSVP_HOP field and RSVP_HOP_L2 objects of the incident
PATH message.
L2デバイスの上のSBMが、推進インタフェースのIPとL2アドレスでRSVP HOPとRSVP_HOP_L2オブジェクトを上書きするのを選ぶと、それはRESVメッセージを受け取るでしょう。 この場合、それは付随しているPATHメッセージの標準のRSVP_HOP分野とRSVP_HOP_L2オブジェクトに受け取られたPHOPアドレスインフォメーションを保存しなければなりません。
In both the cases mentioned above (L2 or L3 devices), the SBM
must forward the TCLASS object in the received PATH message
unchanged.
前記のように両方の場合(L2かL3デバイス)では、SBMは受信されたPATHメッセージで変わりがない状態でTCLASSオブジェクトを進めなければなりません。
* Copy the IP address of the forwarding interface into the
LAN_LOOPBACK object, unless the SBM protocol entity is a DSBM
reflecting a PATH message back onto the incident interface.
(See the section below on "Additional notes on forwarding a
PATH message onto a managed segment").
* LAN_LOOPBACKオブジェクトに推進インタフェースのIPアドレスをコピーしてください、SBMプロトコル実体がPATHメッセージを付随しているインタフェースに映し出すDSBMでないなら。 (「PATHメッセージを管理されたセグメントに転送することに関する補注」の下のセクションを見ます。)
* If the SBM protocol entity is the DSBM for the segment to which
the forwarding interface is attached, it must send the PATH
message to the AllSBMAddress.
* SBMプロトコル実体が推進インタフェースが付けているセグメントのためのDSBMであるなら、それはPATHメッセージをAllSBMAddressに送らなければなりません。
* If the SBM protocol entity is a SBM or a DSBM Client on the
segment to which the forwarding interface is attached, it must
send the PATH message to the DSBMLogicalAddress.
* SBMプロトコル実体が推進インタフェースが付けているセグメントのSBMかDSBM Clientであるなら、それはPATHメッセージをDSBMLogicalAddressに送らなければなりません。
5.5.1. Additional notes on forwarding a PATH message onto a managed
segment
5.5.1. PATHメッセージを管理されたセグメントに転送することに関する補注
Rule #1 states that normal IEEE 802.1D forwarding rules should be used to determine the interfaces on which the PATH message should be forwarded. In the case of data packets, standard forwarding rules at a L2 device dictate that the packet should not be forwarded on the interface from which it was received. However, in the case of a DSBM that receives a PATH message over a managed segment, the following exception applies:
規則#1、は、正常なIEEE 802.1D推進規則がPATHメッセージが転送されるべきであるインタフェースを決定するのに使用されるべきであると述べます。 データ・パケットのケースでは、L2デバイスの標準の推進規則は、パケットがそれが受け取られたインタフェースで進められるべきでないと決めます。 しかしながら、管理されたセグメントの上にPATHメッセージを受け取るDSBMの場合では、以下の例外は適用されます:
Yavatkar, et al. Standards Track [Page 22] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[22ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
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.
1E。 LAN_NHOP物のアドレスがユニキャストアドレスであるなら、フィルタリングデータベース(FDB)に相談して、送付先アドレスがメッセージが受け取られたのと同じインタフェースに記載されているかどうか決定してください。 はいなら、以下で説明されていた状態で「PATHメッセージをインタフェースに映し出します」の以下の規則に従ってください。 さもなければ、通常通りのメッセージ処理の残りを続けてください。
E2. If there are members of the multicast group address (specified
by the addresses in the LAN_NHOP object), on the segment from
which the message was received, the message should be
forwarded back onto the interface from which it was received
and follow the rule on "reflecting a PATH message back onto an
interface" described below.
2E。 マルチキャストグループアドレス(LAN_NHOP物のアドレスで、指定される)のメンバーがいれば、メッセージが受け取られたセグメントでは、メッセージは、それが受け取られたインタフェースに送って戻られて、「PATHメッセージをインタフェースに映し出します」のときに以下で説明された規則に従うべきです。
*** Reflecting a PATH message back onto an interface ***
*** インタフェース***にPATHメッセージを映し出します。
Under the circumstances described above, when a DSBM reflects the
PATH message back onto an interface over which it was received, it
must address it using the AllSBMAddress.
DSBMがそれが受け取られたインタフェースにPATHメッセージを映し出すとき上で説明された状況の下では、それは、AllSBMAddressを使用することでそれを記述しなければなりません。
Since it is possible for a DSBM to reflect a PATH message back
onto the interface from which it was received, precautions must be
taken to avoid looping these messages indefinitely. The
LAN_LOOPBACK object addresses this issue. All SBM protocol
entities (except DSBMs reflecting a PATH message) overwrite the
LAN_LOOPBACK object in the PATH message with the IP address of the
outgoing interface. DSBMs which are reflecting a PATH message,
leave the LAN_LOOPBACK object unchanged. Thus, SBM protocol
entities will always be able to recognize a reflected multicast
message by the presence of their own address in the LAN_LOOPBACK
object. These messages should be silently discarded.
DSBMがそれが受け取られたインタフェースにPATHメッセージを映し出すのが、可能であるので、これらのメッセージを無期限に輪にするのを避けるために注意しなければなりません。 LAN_LOOPBACK物はこの問題を記述します。 すべてのSBMプロトコル実体(PATHメッセージを反映するDSBMsを除いた)がPATHメッセージで外向的なインタフェースのIPアドレスでLAN_LOOPBACK物を上書きします。 PATHメッセージを反映しているDSBMs、LAN_LOOPBACK物を変わりがないままにしてください。 したがって、SBMプロトコル実体はいつもLAN_LOOPBACK物でのそれら自身のアドレスの存在で反射したマルチキャストメッセージを認識できるでしょう。 これらのメッセージは静かに捨てられるべきです。
5.6. Applying the Rules -- Unicast Session
5.6. 規則を適用します--ユニキャストセッション
Let's see how the rules are applied in the general network illustrated previously (see Figure 2).
規則が以前に例証された一般的なネットワークでどう適用されるかを(図2を見てください)見ましょう。
Assume that H1 is sending a PATH for a unicast session for which H5 is the receiver. The following PATH message is composed by H1:
H1がH5が受信機であるユニキャストセッションのためにPATHを送ると仮定してください。以下のPATHメッセージはH1によって構成されます:
RSVP Contents
RSVP session IP address IP address of H5 (3.0.0.35)
Sender Template IP address of H1 (1.0.0.11)
PHOP IP address of H1 (1.0.0.11)
RSVP_HOP_L2 n/a (H1 is not sending onto a managed
segment)
LAN_NHOP n/a (H1 is not sending onto a managed
H5のRSVP Contents RSVPセッションIPアドレスIPアドレス、(H1の3.0.0.35)送付者Template IPアドレス、(H1の1.0.0.11)PHOP IPアドレス、(1.0、.0、.11)RSVP_HOP_L2、なし、(H1は管理されたセグメントに発信しません)LAN_NHOP、なし、(H1は管理されたaに発信しません。
Yavatkar, et al. Standards Track [Page 23] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[23ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
segment)
LAN_LOOPBACK n/a (H1 is not sending onto a managed
segment)
セグメント) LAN_LOOPBACK、なし。(H1は管理されたセグメントに発信しません)
IP Header
Source address IP address of H1 (1.0.0.11)
Destn address IP addr of H5 (3.0.0.35, assuming raw mode
& router alert)
IP Header SourceがH1のIPアドレスを記述する、(H5の1.0.0.11)DestnアドレスIP addr(3.0.0の仮定の.35、生のモード、およびルータ警戒)
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を記述します。(地図_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処理規則に従って、PATHメッセージを構成して、転送します。
Upon receipt of the PATH message, R1 composes and forwards a PATH message as follows:
PATHメッセージを受け取り次第、R1は以下のPATHメッセージを構成して、転送します:
RSVP Contents
RSVP session IP address IP address of H5
Sender Template IP address of H1
PHOP IP address of R1 (2.0.0.1)
(seed the return path for RESV messages)
RSVP_HOP_L2 L2 address of R1
LAN_NHOP LAN_NHOP_L3 (2.0.0.2) and
LAN_NHOP_L2 address of R2 (L2ADDR)
(this is the next layer 3 hop)
LAN_LOOPBACK IP address of R1 (2.0.0.1)
R1のH1 PHOP IPアドレスのH5 Sender Template IPアドレスのRSVP Contents RSVPセッションIPアドレスIPアドレス、(2.0、HOP_L2 L2が記述するR1 LAN_NHOP LAN_NHOP_L3の.0.1(RESVのためのリターンパスが通信させる種子))RSVP_、(_NHOP_L2が記述するR1のR2(L2ADDR)(これは次の層3のホップである)LAN_LOOPBACK IPアドレスの2.0の.0の.2と)LAN(2.0.0.1)
IP Header
Source address IP address of H1
Destn address DSBMLogical IP address (224.0.0.16)
H1 DestnアドレスDSBMLogical IPアドレスのIP Header SourceアドレスIPアドレス(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は3が飛び越す次の層のIPアドレスを決定するためにRSVPセッションアドレスでルーティングルックアップをします、R2。
* It determines that R2 is accessible via seg A and that seg A
is managed by a DSBM, S1.
* それは、R2がseg Aを通してアクセスしやすく、seg AがDSBM、S1によって管理されることを決定します。
* Therefore, it concludes that it is sending onto a managed
segment, and composes LAN_NHOP objects to carry the layer 3
and layer 2 next hop addresses. To compose the LAN_NHOP
L2ADDR object, it invokes the L3 to L2 address mapping function
* したがって、それは、それが管理されたセグメントに発信すると結論を下して、次の2ホップが記述する層3と層を運ぶためにLAN_NHOP物を構成します。 LAN_NHOP L2ADDR物を構成するために、それはL2アドレスマッピング機能へL3を呼び出します。
Yavatkar, et al. Standards Track [Page 24] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[24ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
("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.
(「地図_アドレス」) 見つけるために、MACは次のホップL3装置、および次に、差し込みのために、メッセージにLAN_NHOP_L2ADDR物(それはMACアドレスを運ぶ)を記述します。
* Since R1 is not the DSBM for seg A, it sends the PATH message
to the DSBMLogicalAddress.
* R1がseg AのためのDSBMでないので、それはPATHメッセージをDSBMLogicalAddressに送ります。
Upon receipt of the PATH message, S1 composes and forwards a PATH message as follows:
PATHメッセージを受け取り次第、S1は以下のPATHメッセージを構成して、転送します:
RSVP Contents
RSVP session IP address IP address of H5
Sender Template IP address of H1
PHOP IP addr of S1 (seed the return path for RESV
messages)
RSVP_HOP_L2 L2 address of S1
LAN_NHOP LAN_NHOP_L3 (IP) and LAN_NHOP_L2
address of R2
(layer 2 devices do not modify the LAN_NHOP)
LAN_LOOPBACK IP addr of S1
S1 LAN_NHOP LAN_NHOP_L3(IP)のS1(RESVメッセージのためにリターンパスに種を蒔く)RSVP_HOP_L2 L2アドレスとS1のR2(層の2装置はラン_NHOPを変更しない)LAN_LOOPBACK IP addrのLAN_NHOP_L2アドレスのH1 PHOP IP addrのH5 Sender Template IPアドレスのRSVP Contents RSVPセッションIPアドレスIPアドレス
IP Header
Source address IP address of H1
Destn address AllSBMIPaddr (224.0.0.17, since S1 is the
DSBM for seg B).
IP Header SourceがH1 DestnアドレスAllSBMIPaddrのIPアドレスを記述する、(224.0 .0 S1がseg BのためのDSBMである時から.17
MAC Header
Destn address All SBM MAC address (since S1 is the DSBM
for seg B).
MAC Header DestnはAll 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は、それがPATHメッセージを転送するべきであるL2アドレスを決定するためにLAN_NHOPアドレス情報を見ます。
* From the bridge forwarding tables, it determines that the L2
address is reachable via seg B.
* 橋の推進テーブルから、それは、L2アドレスにseg Bを通して届いていることを決定します。
* S1 inserts the RSVP_HOP_L2 object and overwrites the RSVP HOP
object (PHOP) with its own addresses.
* S1はRSVP_HOP_L2物を挿入して、それ自身のアドレスでRSVP HOP物(PHOP)を上書きします。
* Since S1 is the DSBM for seg B, it addresses the PATH message
to the AllSBMAddress.
* S1がseg BのためのDSBMであるので、それはPATHメッセージをAllSBMAddressに記述します。
Upon receipt of the PATH message, S3 composes and forwards a PATH message as follows:
PATHメッセージを受け取り次第、S3は以下のPATHメッセージを構成して、転送します:
Yavatkar, et al. Standards Track [Page 25] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[25ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
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
S3 LAN_NHOP LAN_NHOP_L3(IP)のS3(RESVメッセージのためにリターンパスに種を蒔く)RSVP_HOP_L2 L2アドレスとS3のR2(L2装置はLAN_NHOPを変更しない)LAN_LOOPBACK IPアドレスのLAN_NHOP_L2(MAC)アドレスのH1 PHOP IP addrのH5 Sender Template IPアドレスのRSVP Contents RSVPセッションIP addr IPアドレス
IP Header
Source address IP address of H1
Destn address DSBMLogical IP addr (since S3 is
not the DSBM for seg F)
H1 DestnアドレスDSBMLogical IP addrのIP Header SourceアドレスIPアドレス(S3がseg FのためのDSBMでないので)
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は、それがPATHメッセージを転送するべきであるL2アドレスを決定するためにLAN_NHOPアドレス情報を見ます。
* 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がDSBMLogicalAddressへのしたがってItがPATHメッセージを送るセグメントF.のためのDSBMであると発見しました。
* Note that S3 may or may not choose to overwrite the PHOP
objects with its own IP and L2 addresses. If it does so, it
will receive RESV messages. In this case, it must also store
the PHOP info received in the incident PATH message so that
it is able to forward the RESV messages on the correct path.
* S3が、それ自身のIPとL2アドレスでPHOP物を上書きするのを選ぶかもしれないことに注意してください。 そうすると、それはRESVメッセージを受け取るでしょう。 また、この場合、それは、正しい経路に関するRESVメッセージを転送できるように付随しているPATHメッセージに受け取られたPHOPインフォメーションを格納しなければなりません。
Upon receipt of the PATH message, R2 composes and forwards a PATH message as follows:
PATHメッセージを受け取り次第、R2は以下のPATHメッセージを構成して、転送します:
RSVP Contents
RSVP session IP addr IP address of H5
Sender Template IP address of H1
PHOP IP addr of R2 (seed the return path for RESV
messages)
RSVP_HOP_L2 Removed by R2 (R2 is not sending onto a
managed segment)
LAN_NHOP Removed by R2 (R2 is not sending onto a
managed segment)
R2によるR2(R2は管理されたセグメントに発信しない)LAN_NHOP RemovedによるR2(RESVメッセージのためにリターンパスに種を蒔く)RSVP_HOP_L2 RemovedのH1 PHOP IP addrのH5 Sender Template IPアドレスのRSVP Contents RSVPセッションIP addr IPアドレス(R2は管理されたセグメントに発信しません)
Yavatkar, et al. Standards Track [Page 26] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[26ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
IP Header
Source address IP address of H1
Destn address IP address of H5, the RSVP session address
H5のH1 DestnアドレスIPアドレス、RSVPセッションアドレスのIP Header SourceアドレスIPアドレス
MAC Header
Destn address L2 addr corresponding to H5, the next
layer 3 hop
H5に対応するMAC Header DestnアドレスL2 addr、3が飛び越す次の層
* R2 does a routing lookup on the RSVP session address, to
determine the IP address of the next layer 3 hop, H5.
* R2は3が飛び越す次の層のIPアドレスを決定するためにRSVPセッションアドレスでルーティングルックアップをします、H5。
* It determines that H5 is accessible via a segment for which
there is no DSBM (not a managed segment).
* それは、H5がDSBM(管理されたセグメントでない)が全くないセグメントでアクセスしやすいことを決定します。
* Therefore, it removes the LAN_NHOP and RSVP_HOP_L2 objects
and places the RSVP session address in the destination
address of the IP header. It places the L2 address of the
next layer 3 hop, into the destination address of the MAC
header and forwards the PATH message to H5.
* したがって、それは、LAN_NHOPとRSVP_HOP_L2物を取り外して、IPヘッダーの送付先アドレスのRSVPセッションアドレスを置きます。 それは、3が飛び越す次の層のL2アドレスをMACヘッダーの送付先アドレスに置いて、PATHメッセージをH5に転送します。
5.7. Applying the Rules - Multicast Session
5.7. 規則を適用します--マルチキャストセッション
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台の装置を層にしてください、そして、余分なマルチキャスト交通を単に発生させるでしょう。 これはマルチキャストフィルタリングかガープ/GMRP能力を実行しないL2装置のためのそうです。
Assume that H1 is sending a PATH for an m/c session for which H3 and H5 are the receivers. The rules are applied as they are in the unicast case described previously, until the PATH message reaches R2, with the following exception. The RSVP session address and the LAN_NHOP carry the destination m/c addresses rather than the unicast addresses carried in the unicast example.
H1がH3とH5が受信機であるm/cセッションのためにPATHを送ると仮定してください。 以前に説明されたユニキャスト場合にはそれらがあって、規則は適用されています、PATHメッセージがR2に達するまで、以下の例外で。 RSVPセッションアドレスとラン_NHOPはユニキャストの例で運ばれたユニキャストアドレスよりむしろ送付先m/cアドレスを載せます。
Now let's look at the processing applied by R2 upon receipt of the PATH message. Recall that R2 is the DSBM for segment F. Therefore, S3 will have forwarded its PATH message to the DSBMLogicalAddress, to be picked up by R2. The PATH message will not have been seen by H3 (one of the m/c receivers), since it monitors only the AllSBMAddress, not the DSBMLogicalAddress for incoming PATH messages. We rely on R2 to reflect the PATH message back onto seg f, and to forward it to H5. R2 forwards the following PATH message onto seg f:
今、PATHメッセージを受け取り次第R2によって適用された処理を見ましょう。 R2がセグメントF.のためのDSBMであると思い出してください。Therefore、R2によって拾われるように、S3はPATHメッセージをDSBMLogicalAddressに転送してしまうでしょう。 PATHメッセージはH3によって見られていないでしょう(m/c受信機の1つ)、入って来るPATHメッセージのためにDSBMLogicalAddressではなく、AllSBMAddressだけをモニターするので。 私たちは、PATHメッセージをseg fに映し出して、それをH5に送るためにR2を当てにします。 R2は以下のPATHメッセージをseg fに転送します:
RSVP Contents
RSVP session addr m/c session address
Sender Template IP address of H1
H1のRSVP Contents RSVPセッションaddr m/cセッションアドレスSender Template IPアドレス
Yavatkar, et al. Standards Track [Page 27] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[27ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
PHOP IP addr of R2 (seed the return path for
RESV messages)
RSVP_HOP_L2 L2 addr of R2
LAN_NHOP m/c session address and corresponding L2 address
LAN_LOOPBACK IP addr of S3 (DSBMs reflecting a PATH
message don't modify this object)
R2 LAN_NHOP m/cセッションアドレスのR2(RESVメッセージのためにリターンパスに種を蒔きます)RSVP_HOP_L2 L2 addrとS3の対応するL2アドレスLAN_LOOPBACK IP addrのPHOP IP addr(PATHメッセージを反映するDSBMsがこの物を変更しません)
IP Header
Source address IP address of H1
H1のIP Header Sourceアドレス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がAll SBM Addressをモニターしているので、それはR2によって反映されたPATHメッセージを受け取るでしょう。 それが受け取られたインタフェースに入力メッセージを返送することによってR2がここで標準の推進規則に違反したことに注意してください。 それは、LAN_LOOPBACK物でS3をアドレスに残すことによって、変わりがない状態で輪から守りました。
R2 forwards the following PATH message on to H5:
R2は以下のPATHメッセージを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)
R2によるR2(R2は管理されたセグメントに発信しない)LAN_LOOPBACK RemovedによるR2(R2は管理されたセグメントに発信しない)LAN_NHOP RemovedによるR2(RESVメッセージのためにリターンパスに種を蒔く)RSVP_HOP_L2 RemovedのH1 PHOP IP addrのRSVP Contents RSVPセッションaddr m/cセッションアドレスSender Template IPアドレス(R2は管理されたセグメントに発信しません)
IP Header
Source address IP address of H1
Destn address m/c session address
H1 Destnアドレスm/cセッションアドレスのIP Header SourceアドレスIPアドレス
MAC Header
Destn address MAC addr corresponding to the m/c
session address
m/cセッションアドレスに対応するMAC Header DestnアドレスMAC addr
* R2 determines that there is an m/c receiver accessible via a
segment for which there is no DSBM. Therefore, it removes the
LAN_NHOP and RSVP_HOP_L2 objects and places the RSVP session
address in the destination address of the IP header. It
* R2は、DSBMが全くないセグメントを通してアクセスしやすいm/c受信機があることを決定します。 したがって、それは、LAN_NHOPとRSVP_HOP_L2物を取り外して、IPヘッダーの送付先アドレスのRSVPセッションアドレスを置きます。 それ
Yavatkar, et al. Standards Track [Page 28] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[28ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
places the corresponding L2 address into the destination
address of the MAC header and multicasts the message towards
H5.
対応するL2がMACヘッダーとマルチキャストの送付先アドレスにH5に向かったメッセージを記述する場所。
5.8. Merging Traffic Class objects
5.8. Traffic Class物を合併します。
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セッションのときに異なった送付者(異なったPATHメッセージ)から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が、マージポイントの次の異なったホップからRESVsを合併する必要があって、彼らが合っていないなら、それは入って来るRESVsでTCLASS値を扱う方法を決めなければなりません。 予約がDSBM(または、SBM)の流れのために最初のRESVで要求されたTCLASSのためにうまくいっている入場コントロールをしている流れのために適所にあるときにはケースを考えてください。 別のRESVである、(リフレッシュする、以前に認められたRESV) 同じくらいに関しては、流れはDSBMに到着して、DSBMは最初に、新しいRESVで既にインストールされたRESVのTCLASS値に対してTCLASS値をチェックしなければなりません。 2つの値が同じであるなら、RESV要求が合併されていて、新しくて、合併しているRESVは標準が統治するメッセージ処理の使用をインストールして、進めました。 しかしながら、2つの値が同じでないなら、DSBMは、より新しいRESVメッセージの送付者(NHOP)に向かってRESV_ERRメッセージを発生して、送らなければなりません。 RESV_ERRは2つの両立しないサービスのリクエスト(RSVPトラフィックコントロール誤りのためのサブコード01)[RFC-2205]を合併しないことを示すRSVP「トラフィックコントロール誤り」(RESV_ERRコード21)に対応するエラーコードを指定しなければなりません。 RESV_ERRメッセージは、この状態から回復するのに川下のノードを助けるために追加物を含むかもしれません。 そのような物の定義と使用法はこのメモの範囲を超えています。
5.9. Operation of SBM Transparent Devices
5.9. SBMの透明な装置の操作
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プロトコルに気づきません。 彼らは関連する地域団体が代わりに(DSBMLogicalAddrssとALLSBMAddress)を記述して、彼らを通過するSBMのどちらかに記述されたメッセージを傍受しません。 その結果、彼らはDSBM選挙範囲を分割しません、そして、彼らは明らかにPATHかRESVメッセージのルーティングに参加しません、そして、それらは入場コントロールに参加しません。 それらはSBM操作に関して完全に透明です。
Yavatkar, et al. Standards Track [Page 29] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[29ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
According to the definitions provided, physical segments interconnected by SBM transparent devices are considered a single managed segment. Therefore, DSBMs must perform admission control on such managed segments, with limited knowledge of the segment's topology. In this case, the network administrator should configure the DSBM for each managed segment, with some reasonable approximation of the segment's capacity. A conservative policy would configure the DSBM for the lowest capacity route through the managed segment. A liberal policy would configure the DSBM for the highest capacity route through the managed segment. A network administrator will likely choose some value between the two, based on the level of guarantee required and some knowledge of likely traffic patterns.
定義によると、SBMの透明な装置によってインタコネクトされた提供されて、物理的なセグメントはただ一つの管理されたセグメントであると考えられます。 したがって、DSBMsはセグメントのトポロジーの知識不足でそのような管理されたセグメントに入場コントロールを実行しなければなりません。 この場合、ネットワーク管理者はそれぞれの管理されたセグメントのためにDSBMを構成するべきです、セグメントの容量の何らかの合理的な近似で。 保守政策は管理されたセグメントを通して最も低い容量ルートにDSBMを構成するでしょう。 自由主義政策は管理されたセグメントを通して最も高い容量ルートにDSBMを構成するでしょう。 ネットワーク管理者はおそらく2つの間の何らかの値を選ぶでしょう、必要である保証のレベルとありそうなトラフィック・パターンに関する何らかの知識に基づいて。
This document does not specify the configuration mechanism or the choice of a policy.
このドキュメントは構成メカニズムか方針の選択を指定しません。
5.10. Operation of SBMs Which are NOT DSBMs
5.10. SBMs Whichの操作はDSBMsではありません。
In the example illustrated, S3 hosts a SBM, but the SBM on S3 did not win the election to act as DSBM on any segment. One might ask what purpose such a SBM protocol entity serves. Such SBMs actually provide two useful functions. First, the additional SBMs remain passive in the background for fault tolerance. They listen to the periodic announcements from the current DSBM for the managed segment (Appendix A describes this in more detail) and step in to elect a new DSBM when the current DSBM fails or ceases to be operational for some reason. Second, such SBMs also provide the important service of dividing the election scope and reducing the size and complexity of managed segments. For example, consider the sample topology in Figure 3 again. the device S3 contains an SBM that is not a DSBM for any f the segments, B, E, or F, attached to it. However, if the SBM protocol entity on S3 was not present, segments B and F would not be separate segments from the point of view of the SBM protocol. Instead, they would constitute a single managed segment, managed by a single DSBM. Because the SBM entity on S3 divides the election scope, seg B and seg F are each managed by separate DSBMs. Each of these segments have a trivial topology and a well defined capacity. As a result, the DSBMs for these segments do not need to perform admission control based on approximations (as would be the case if S3 were SBM transparent).
例では、例証されて、S3はSBMを接待しますが、S3の上のSBMは、DSBMとしてどんなセグメントにも機能するように選挙に勝ちませんでした。 人は、そのようなSBMプロトコル実体がどんな目的に役立つかを尋ねるかもしれません。 そのようなSBMsは実際に2つの役に立つ機能を提供します。 まず最初に、追加SBMsはバックグラウンドで耐障害性に受け身のままです。 彼らは、管理されたセグメント(付録Aはさらに詳細にこれについて説明する)に関して現在のDSBMから周期的な発表を聞いて、現在のDSBMが、失敗するか、またはある理由で操作上であることをやめるとき、新しいDSBMを選出するために中へ入ります。 また、2番目に、そのようなSBMsは選挙範囲を分割して、管理されたセグメントのサイズと複雑さを減少させる大任を提供します。 例えば、図のサンプルトポロジーが3であるともう一度考えてください。装置S3はDSBMではなく、そうするSBMを含んでいます。どんなfに関してはも、セグメント(B、E、またはF)は、それに付きました。 しかしながら、S3の上のSBMプロトコル実体が存在していないなら、セグメントBとFはSBMプロトコルの観点からの別々のセグメントでないでしょうに。 代わりに、彼らは独身のDSBMによって管理されたただ一つの管理されたセグメントを構成するでしょう。 S3の上のSBM実体が選挙範囲を分割するので、seg Bとseg Fは別々のDSBMsによってそれぞれ管理されます。それぞれのこれらのセグメントには、些細なトポロジーとよく定義された容量があります。 その結果、これらのセグメントのためのDSBMsは近似に基づく入場コントロールを実行する必要はありません(S3がSBM透明であるならそうであるように)。
Note that, SBM protocol entities which are not DSBMs, are not required to overwrite the PHOP in incident PATH messages with their own address. This is because it is not necessary for RESV messages to be routed through these devices. RESV messages are only required to be routed through the correct sequence of DSBMs. SBMs may not process RESV messages that do pass through them, other than to forward them towards their destination address, using standard
それ(DSBMsでないSBMプロトコル実体)は付随しているPATHメッセージでそれら自身のアドレスでPHOPを上書きするのに必要でないことに注意してください。 これはそれがこれらの装置を通して発送されるべきRESVメッセージに必要でないからです。 RESVメッセージは必要であるだけであることで、DSBMs. SBMsの正しい系列を通して発送されるのがそれらを通り抜けるRESVメッセージを処理しないかもしれません、それらの送付先アドレスに向かってそれらを送るのを除いて、規格を使用してことです。
Yavatkar, et al. Standards Track [Page 30] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[30ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
forwarding rules.
推進は統治されます。
SBM protocol entities which are not DSBMs are required to overwrite the address in the LAN_LOOPBACK object with their own address, in order to avoid looping multicast messages. However, no state need be stored.
DSBMsでないSBMプロトコル実体がLAN_LOOPBACK物でそれら自身のアドレスでアドレスを上書きするのに必要です、マルチキャストメッセージを輪にするのを避けるために。 しかしながら、状態は全く格納される必要はありません。
6. Inter-Operability Considerations
6. 相互運用性問題
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 Devicesがある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意識しているなら効率的であるほど効率的でないかもしれません。
Yavatkar, et al. Standards Track [Page 31] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[31ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
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).
管理されたセグメント(現在アクティブなDSBMがあるセグメント)のすべてのDSBMs、SBMs、またはDSBMクライアントがSBM意識していない送付者からPATHメッセージを受け入れてはいけません。 彼らはALLSBMAddress(SBMsとDSBMクライアントの場合の)かDSBMLogicalAddress(DSBMsの場合の)へのマルチキャストでないでしょう、したがって、SBMsとDSBMクライアントは容易にそのような装置からのPATHメッセージを検出できます。
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メッセージ(例えば、選挙とPATHメッセージ)は、地方の範囲を持って、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. RAW_IPを使用することでメッセージをRSVPに受け取るか、または送るUDPカプセル化を使用している、できないRSVPクライアントがいる相互運用性
This document stipulates that DSBMs, DSBM clients, and SBMs use only raw IP for encapsulating RSVP messages that are forwarded onto a L2 domain. RFC-2205 (the RSVP Proposed Standard) includes support for both raw IP and UDP encapsulation. Thus, a RSVP node using only the UDP encapsulation will not be able to interoperate with the DSBM unless DSBM accepts and supports UDP encapsulated RSVP messages.
このドキュメントは、DSBMs、DSBMクライアント、およびSBMsがL2ドメインに転送されるRSVPメッセージを要約するのに生のIPだけを使用するのを規定します。 RFC-2205(RSVP Proposed Standard)は生のIPとUDPカプセル化の両方のサポートを含んでいます。 したがって、DSBMがUDPを受け入れて、支持しない場合カプセル化がDSBMと共に共同利用できないUDPだけを使用するRSVPノードはRSVPメッセージを要約しました。
7. Guidelines for Implementers
7. Implementersのためのガイドライン
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ベースの入場コントロール手順の実現の異なった局面でimplementersのためのガイドラインを提供します。
7.1. DSBM Initialization
7.1. DSBM初期設定
As stated earlier, DSBM initialization includes configuration of maximum bandwidth that can be reserved on a managed segment under its control. We suggest the following guideline.
より早く述べられるように、DSBM初期化はコントロールの下における管理されたセグメントに控えることができる最大の帯域幅の構成を含んでいます。 私たちは以下のガイドラインを勧めます。
Yavatkar, et al. Standards Track [Page 32] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[32ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
In the case of a managed segment consisting of L2 devices interconnected by a single shared segment, DSBM entities on such devices should assume the bandwidth of the interface as the total link bandwidth. In the case of a DSBM located in a L2 switch, it might additionally need to be configured with an estimate of the device's switching capacity if that is less than the link bandwidth, and possibly with some estimate of the buffering resources of the switch (see [RFC-FRAME] for the architectural model assumed for L2 switches). Given the total link bandwidth, the DSBM may be further configured to limit the maximum amount of bandwidth for RSVP-enabled flows to ensure spare capacity for best-effort traffic.
管理されたセグメントがただ一つの共用セグメントによってインタコネクトされたL2装置から成る場合では、そのような装置の上のDSBM実体は総リンク帯域幅としてインタフェースの帯域幅を仮定するべきです。 L2スイッチに位置するDSBMの場合では、それがリンク帯域幅よりそれほど、そして、ことによるとスイッチに関するバッファリングリソースの何らかの見積りと共にいるなら(L2スイッチのために思われた建築モデルに関して[RFC-FRAME]を見てください)、それは、さらに、装置の切り換え容量の見積りによって構成される必要があるかもしれません。 総リンク帯域幅を考えて、DSBMは、RSVPによって可能にされた流れがベストエフォート型交通に設備余力を確実にするように最大の量の帯域幅を制限するためにさらに構成されるかもしれません。
7.2. Operation of DSBMs in Different L2 Topologies
7.2. 異なったL2 TopologiesでのDSBMsの操作
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つ以上のセグメントのためのリソースを管理するのが要求されるかもしれなくて、implementersは異なったL2 topologiesにおけるDSBMの使用の効率含意を覚えておかなければなりません。 些細なL2 topologiesは単一の「物理的なセグメント」から成ります。 この場合、'管理されたセグメント'はただ一つのセグメントに同等です。 複雑なL2 topologiesはそのようなL2のシングルがプールする拡張セグメントを実行できるAdmissionコントロールの数からリソースを成らせるかもしれません、ただ一つの共用セグメントと同様です、独身のDSBMの観点から。
This configuration compromises the efficiency with which the DSBM can allocate resources. This is because the single DSBM is required to make admission control decisions for all reservation requests within the L2 topology, with no knowledge of the actual physical segments affected by the reservation.
この構成はDSBMとリソースを割り当てることができる効率で妥協します。 これは独身のDSBMがL2トポロジーの中で入場をすべての予約の要請のためのコントロール決定にしなければならないからです、予約で影響を受ける実際の物理的なセグメントに関する知識なしで。
We can realize improvements in the efficiency of resource allocation by subdividing the complex segment into a number of managed segments, each managed by their own DSBM. In this case, each DSBM manages a managed segment having a relatively simple topology. Since managed segments are simpler, the DSBM can be configured with a more accurate estimate of the resources available for all reservations in the managed segment. In the ultimate configuration, each physical segment is a managed segment and is managed by its own DSBM. We make no assumption about the number of managed segments but state, simply, that in complex L2 topologies, the efficiency of resource allocation improves as the granularity of managed segments increases.
私たちは、複雑なセグメントを多くの管理されたセグメント(それら自身のDSBMによって管理されたそれぞれ)に細分することによって、資源配分の効率における改良を達成できます。 この場合、各DSBMは比較的簡単なトポロジーを持っている管理されたセグメントを管理します。 管理されたセグメントが、より簡単であるので、管理されたセグメントですべての予約に利用可能なリソースの、より正確な見積りはDSBMを構成できます。 究極の構成では、それぞれの物理的なセグメントは、管理されたセグメントであり、それ自身のDSBMによって管理されます。 私たちは、仮定を全く管理されたセグメントのおよそ数にしませんが、複雑なL2 topologiesでは、資源配分の効率が管理されたセグメント増加の粒状として向上すると単に述べます。
8. Security Considerations
8. セキュリティ問題
The message formatting and usage rules described in this note raise security issues, identical to those raised by the use of RSVP and Integrated Services. It is necessary to control and authenticate
この注意で説明されたメッセージ形式と用法規則は安全保障問題を提起します、RSVPとIntegrated Servicesの使用で上げられたものと同じです。 それが、制御して、認証するのに必要です。
Yavatkar, et al. Standards Track [Page 33] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[33ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
access to enhanced qualities of service enabled by the technology described in this RFC. This requirement is discussed further in [RFC-2205], [RFC-2211], and [RFC-2212].
高められたこのRFCで説明された技術で可能にされたサービスの品質へのアクセス。 [RFC-2205]、[RFC-2211]、および[RFC-2212]で、より詳しくこの要件について議論します。
[RFC-RSVPMD5] describes the mechanism used to protect the integrity of RSVP messages carrying the information described here. A SBM implementation should satisfy the requirements of that RFC and provide the suggested mechanisms just as though it were a conventional RSVP implementation. It should further use the same mechanisms to protect the additional, SBM-specific objects in a message.
[RFC-RSVPMD5]はここで説明された情報を運ぶRSVPメッセージの保全を保護するのに使用されるメカニズムについて説明します。 SBM実現は、まるでまさしくそれが従来のRSVP実現であるかのようにそのRFCの要件を満たして、提案されたメカニズムを提供するべきです。 それは、メッセージに追加していて、SBM特有の物を保護するのにさらに同じメカニズムを使用するべきです。
Finally, it is also necessary to authenticate DSBM candidates during the election process, and a mechanism based on a shared secret among the DSBM candidates may be used. The mechanism defined in [RFC- RSVPMD5] should be used.
また、最終的に、選挙の過程の間、DSBM候補を認証するのも必要であり、DSBM候補の中で共有秘密キーに基づくメカニズムは使用されるかもしれません。 [RFC- RSVPMD5]で定義されたメカニズムは使用されるべきです。
9. References
9. 参照
[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.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC-RSVPMD5] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RFC-RSVPMD5] ベイカーとF.とリンデルとB.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[RFC 2206] Baker, F. and J. Krawczyk, "RSVP Management Information
Base", RFC 2206, September 1997.
[RFC2206] ベイカーとF.とJ.Krawczyk、「RSVP管理情報ベース」、RFC2206、1997年9月。
[RFC 2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
[RFC 2212] Shenker, S., Partridge, C. and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
[RFC2212] ShenkerとS.とヤマウズラとC.とR.ゲラン、「保証されたサービスの質の仕様」、RFC2212、1997年9月。
[RFC 2215] Shenker, S. and J. Wroclawski, "General
Characterization Parameters for Integrated Service
Network Elements", RFC 2215, September 1997.
[RFC2215] ShenkerとS.とJ.Wroclawski、「統合サービスネットワークElementsへの一般的性質パラメタ」、RFC2215、1997年9月。
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[RFC 2213] Baker, F. and J. Krawczyk, "Integrated Services
Management Information Base", RFC 2213, September 1997.
[RFC2213] ベイカーとF.とJ.Krawczyk、「統合サービス管理情報ベース」、RFC2213、1997年9月。
Yavatkar, et al. Standards Track [Page 34] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[34ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
[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.、失礼ですが、W.とSrinivasanとV.とスミスとA.とM.船員、「共有されて切り換えられたLAN技術の上に統合サービスを提供するための枠組み」、RFC2816、2000年5月。
[RFC-MAP] Seaman, M., Smith, A. and E. Crawley, "Integrated
Service Mappings on IEEE 802 Networks", RFC 2815, May
2000.
[RFC-地図] 船員、M.、スミス、A.、およびE.クローリー(「IEEE802ネットワークに関する統合サービス対応表」、RFC2815)は2000がそうするかもしれません。
[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の最終的なCD15802-3IEEE P802.1D/D15、1997年11月24日。
[IEEE8021D] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-
1993.
[IEEE8021D]「MAC橋」、ISO/IEC10038、ANSI/IEEE Std 802.1D1993。
Yavatkar, et al. Standards Track [Page 35] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[35ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
A.1. Introduction
A.1。 序論
To simplify the rest of this discussion, we will assume that there is a single DSBM for the entire L2 domain (i.e., assume a shared L2 segment for the entire L2 domain). Later, we will discuss how a DSBM is elected for a half-duplex or full-duplex switched segment.
この議論の残りを簡素化するために、私たちは、全体のL2ドメインへの独身の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の失敗からの迅速な回復を考慮するために、私たちは、耐障害性に、追加SBMsがL2ドメインでアクティブであるかもしれないと思います。 1SBMがL2ドメインでアクティブであるときに、SBMsは、L2ドメインにDSBMを選出するのに選挙アルゴリズムを使用します。 DSBMが選出されて、操作上になった後に、他のSBMsは、必要であるときに、新しいDSBMを選出するために中へ入るためにバックグラウンドで受け身のままです。 DSBMを選出して、発見するためのプロトコルは、「DSBM選挙プロトコル」と呼ばれて、このAppendixの残りで説明されます。
A.1.1. How a DSBM Client Detects a Managed Segment
A.1.1。 DSBMクライアントはどう管理されたセグメントを検出するか。
Once elected, a DSBM periodically multicasts an I_AM_DSBM message on the AllSBMAddress to indicate its presence. The message is sent every period (e.g., every 5 seconds) according to the RefreshInterval timer value (a configuration parameter). Absence of such a message over a certain time interval (called "DSBMDeadInterval"; another configuration parameter typically set to a multiple of RefreshInterval) indicates that the DSBM has failed or terminated and triggers another round of the DSBM election. The DSBM clients always listen for periodic DSBM advertisements. The advertisement includes the unicast IP address of the DSBM (DSBMAddress) and DSBM clients send their PATH/RESV (or other) messages to the DSBM. When a DSBM client detects the failure of a DSBM, it waits for a subsequent I_AM_DSBM advertisement before resuming any communication with the DSBM. During the period when a DSBM is not present, a DSBM client may forward outgoing PATH messages using the standard RSVP forwarding rules.
一度選出されたa DSBM、定期的に、I_AM_DSBMがAllSBMAddressで通信するマルチキャストは存在を示します。 RefreshIntervalタイマ価値(設定パラメータ)に応じて、いつも期間(例えばあらゆる5秒)にメッセージを送ります。 ある一定の時間間隔(呼ばれた"DSBMDeadInterval"; RefreshIntervalの倍数に通常設定された別の設定パラメータ)の間のそのようなメッセージの欠如は、DSBM選挙の別のラウンドをDSBMが失敗したのを示すか、終えて、または引き金となります。 DSBMクライアントはいつも周期的なDSBM広告の聞こうとします。 広告はDSBM(DSBMAddress)のユニキャストIPアドレスを含んでいます、そして、DSBMクライアントは彼らのPATH/RESV(何らかの)メッセージをDSBMに送ります。 DSBMクライアントがDSBMの失敗を検出するとき、DSBMとのどんなコミュニケーションも再開する前に、それはその後のI_AM_DSBM広告を待ちます。 DSBMが存在していない期間、DSBMクライアントは、規則を進めながら標準のRSVPを使用することで送信するPATHメッセージを転送するかもしれません。
The exact message formats and addresses used for communication with (and among) SBM(s) are described in Appendix B.
(and among) SBM(s)とのコミュニケーションに使用される正確なメッセージ・フォーマットとアドレスはAppendix Bで説明されます。
A.2. Overview of the DSBM Election Procedure
A.2。 DSBM選挙手順の概観
When a SBM first starts up, it listens for incoming DSBM advertisements for some period to check whether a DSBM already exists in its L2 domain. If one already exists (and no new election is in progress), the new SBM stays quiet in the background until an election of DSBM is necessary. All messages related to the DSBM election and DSBM advertisements are always sent to the AllSBMAddress.
SBMが最初に始動すると、それは、DSBMがL2ドメインに既に存在するかどうかチェックするためにいつかの期間、入って来るDSBM広告の聞こうとします。 1つが既に存在しているなら(どんな新しい選挙も進行していません)、DSBMの選挙が必要になるまで、新しいSBMはバックグラウンドで静かなままです。 いつもDSBM選挙とDSBM広告に関連するすべてのメッセージをAllSBMAddressに送ります。
Yavatkar, et al. Standards Track [Page 36] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[36ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
If no DSBM exists, the SBM initiates the election of a DSBM by sending out a DSBM_WILLING message that lists its IP address as a candidate DSBM and its "SBM priority". Each SBM is assigned a priority to determine its relative precedence. When more than one SBM candidate exists, the SBM priority determines who gets to be the DSBM based on the relative priority of candidates. If there is a tie based on the priority value, the tie is broken using the IP addresses of tied candidates (one with the higher IP address in the lexicographic order wins). The details of the election protocol start in Section A.4.
どんなDSBMも存在していないなら、SBMは、候補DSBMとその「SBM優先権」にIPアドレスについて記載するDSBM_WILLINGメッセージを出すことによって、DSBMの選挙を開始します。 優先は、相対的な先行を決定するために各SBMに割り当てられます。 1人以上のSBM候補が存在すると、SBM優先権は、だれが、候補の相対的な優先権に基づくDSBMであり始めるかを決定します。 優先順位の値に基づく繋がりがあれば、繋がりは結ばれた候補のIPアドレスを使用するのにおいて中断しています(より高いIPアドレスが辞書式順序にある1つは獲得されます)。 選挙プロトコルの詳細はセクションA.4で始まります。
A.2.1 Summary of the Election Algorithm
選挙アルゴリズムのA.2.1概要
For the purpose of the algorithm, a SBM is in one of the four states (Idle, DetectDSBM, ElectDSBM, IAMDSBM).
アルゴリズムの目的のために、SBMが4つの州の1つにある、(怠けてください、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広告)のためのListenIntervalかDSBM_WILLINGメッセージを待っています。 この状態の間、I_AM_DSBM広告を受け取るなら、SBMは現在のDSBM(そのIPアドレスと優先権)に注意して、Idle状態に入れます。 この状態の間、別の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状態に入るとき、それは、タイマ(ElectionIntervalTimerと呼ばれて、DSBMDeadInterval値と少なくとも等しい値に通常設定される)に選挙が終わって、だれが最も良い候補であるかを発見するのを待つように設定します。 この状態では、Xは今までのところ見られている最も良くて(より良い)の候補の動向をおさえます(それ自体を含んでいて)。 別のDSBM_WILLINGメッセージを受け取るときはいつも、それは優先権(そして、繋がり壊す)評価基準に基づく最も良くて(より良い)の候補の概念をアップデートします。 ElectionIntervalの間、Xは(re)へのあらゆるRefreshIntervalが立候補であると断言する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).
ElectionIntervalの端では、Xは、今までのところそれが最も良い候補であるかどうかチェックします。 そうだとすれば、それ自体がDSBM(I_AM_DSBM広告を出すのによる)であると宣言して、IAMDSBM状態に入ります。 さもなければ、それは、最も良い候補が、それ自体が勝者であると宣言するのを待つと決めます。 Xは、待つために、ElectDSBM状態を再初期化して、選挙の別のラウンドを待ち続けています(各ラウンドはElectionTimerInterval持続時間のために続きます)。
Yavatkar, et al. Standards Track [Page 37] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[37ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
A SBM is in Idle state when no election is in progress and the DSBM is already elected (and happens to be someone else). In this state, it listens for incoming I_AM_DSBM advertisements and uses a DSBMDeadIntervalTimer to detect the failure of DSBM. Every time the advertisement is received, the timer is restarted. If the timer fires, the SBM goes into the DetectDSBM state to prepare to elect the new DSBM. If a SBM receives a DSBM_WILLING message from the current DSBM in this state, the SBM enters the ElectDSBM state after sending out a DSBM_WILLING message (to announce its own candidacy).
選挙が全く進行していなくて、DSBMが既に選出されるとき(そして、たまたま、他の誰かです)、SBMがIdle状態にあります。 この状態では、それは、入って来るI_AM_DSBM広告の聞こうとして、DSBMの失敗を検出するのにDSBMDeadIntervalTimerを使用します。 広告が受け取られているときはいつも、タイマは再開されます。 タイマが撃たれるなら、SBMは、新しいDSBMを選出するのを準備するためにDetectDSBM状態に入ります。 SBMがこの状態の現在のDSBMからDSBM_WILLINGメッセージを受け取るなら、DSBM_WILLINGメッセージ(それ自身の立候補を発表する)を出した後に、SBMは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の選挙に道をあけます。
A.3. Recovering from DSBM Failure
A.3。 DSBMの故障から、回復します。
When a DSBM fails (DSBMDeadIntervalTimer fires), all the SBMs enter the ElectDSBM state and start the election process.
DSBMが(DSBMDeadIntervalTimer炎)に失敗すると、すべてのSBMsがElectDSBM状態に入れて、選挙の過程を始めます。
At the end of the ElectionInterval, the elected DSBM sends out an I_AM_DSBM advertisement and the DSBM is then operational.
ElectionIntervalの端に、選出されたDSBMはI_AM_DSBM広告を出します、そして、次に、DSBMは操作上です。
A.4. DSBM Advertisements
A.4。 DSBM広告
The I_AM_DSBM advertisement contains the following information:
I_AM_DSBM広告は以下の情報を含んでいます:
1. DSBM address information -- contains the IP and L2 addresses of
the DSBM and its SBM priority (a configuration parameter --
priority specified by a network administrator). The priority
value is used to choose among candidate SBMs during the election
algorithm. Higher integer values indicate higher priority and the
value is in the range 0..255. The value zero indicates that the
SBM is not eligible to be the DSBM. The IP address is required
and used for breaking ties. The L2 address is for the interface
of the managed segment.
1. DSBMは情報を記述します--DSBMの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--秒のRefreshIntervalの値を含んでいます。 値ゼロは、パラメタがメッセージで省略されたのを示します。 受信機はこの場合それら自身のデフォルト値を代入するかもしれません。
3. DSBMDeadInterval -- contains the value of DSBMDeadInterval in
seconds. If the value is omitted (or value zero is specified), a
default value (from initial configuration) should be used.
3. DSBMDeadInterval--秒のDSBMDeadIntervalの値を含んでいます。 値が省略されるなら(値ゼロは指定されます)、デフォルト値(初期の構成からの)は使用されるべきです。
Yavatkar, et al. Standards Track [Page 38] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[38ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
4. Miscellaneous configuration information to be advertised to
senders on the managed segment. See Appendix C for further
details.
4. 管理されたセグメントに送付者に広告を出すべき種々雑多な設定情報。 さらに詳しい明細についてはAppendix Cを見てください。
A.5. DSBM_WILLING Messages
A.5。 DSBMの_の望んでいるメッセージ
When a SBM wishes to declare its candidacy to be the DSBM during an election phase, it sends out a DSBM_WILLING message. The DSBM_WILLING message contains the following information:
SBMが選挙段階の間のDSBMになるように立候補を宣言したがっているとき、それはDSBM_WILLINGメッセージを出します。 DSBM_WILLINGメッセージは以下の情報を含んでいます:
1. DSBM address information -- Contains the SBM's own addresses (IP
and L2 address), if it wishes to be the DSBM. The IP address is
required and used for breaking ties. The L2 address is the
address of the interface for the managed segment in question.
Also, the DSBM address information includes the corresponding
priority of the SBM whose address is given above.
1. DSBMは情報を記述します--DSBMになりたがっているなら、SBMの自己のアドレス(IPとL2アドレス)を含んでいます。 IPアドレスは、壊れている結びつきに必要であり、使用されます。 L2アドレスは問題の管理されたセグメントのためのインタフェースのアドレスです。 また、DSBMアドレス情報はアドレスが上に与えられているSBMの対応する優先権を含んでいます。
A.6. SBM State Variables
A.6。 SBM州の変数
For each network interface, a SBM maintains the following state variables related to the election of the DSBM for the L2 domain on that interface:
各ネットワーク・インターフェースに関しては、SBMはDSBMの選挙に関連する以下の州の変数をそのインタフェースのL2ドメインに維持します:
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) 秒のRefreshInterval。 DSBMがまだ選出されていないとき、それは設定パラメータとして指定されたデフォルト値に設定されます。
d) DSBMDeadInterval in seconds. When the DSBM is not yet elected,
it is initially set to a default value specified as a
configuration parameter.
d) 秒のDSBMDeadInterval。 DSBMが初めはまだ選出されていないとき、それは設定パラメータとして指定されたデフォルト値に設定されます。
f) ListenInterval in seconds -- a configuration parameter that
decides how long a SBM spends in the DetectDSBM state (see
below).
f) 秒のListenInterval--どれくらい長い間SBMについて決める設定パラメータはDetectDSBM状態に費やされます(以下を見てください)。
g) ElectionInterval in seconds -- a configuration parameter that
decides how long a SBM spends in the ElectDSBM state when it has
declared its candidacy.
g) 秒のElectionInterval--立候補を宣言したとき、どれくらい長い間SBMについて決める設定パラメータはElectDSBM状態に費やされます。
Yavatkar, et al. Standards Track [Page 39] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[39ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
Figure 3 shows the state transition diagram for the election protocol and the various states are described below. A complete description of the state machine is provided in Section A.10.
図3は選挙プロトコルのために状態遷移ダイヤグラムを示しています、そして、様々な州は以下で説明されます。 州のマシンの完全な記述をセクションA.10に提供します。
A.7. DSBM Election States
A.7。 DSBM選挙州
DOWN -- SBM is not operational.
DOWN--SBMは操作上ではありません。
DetectDSBM -- typically, the initial state of a SBM when it
starts up. In this state, it checks to see whether a DSBM already
exists in its domain.
DetectDSBM--それであるときに、通常、SBMの初期状態は始動します。 この状態では、それは、DSBMがドメインに既に存在するかどうか確認するためにチェックします。
Idle -- SBM is in this state when no election is in progress and
it is not the DSBM. In this state, SBM passively monitors the
state of the DSBM.
怠けてください--選挙が全く進行していなくて、またそれがDSBMでないときに、SBMがこの状態にあります。 この状態では、SBMはDSBMの州を受け身にモニターします。
ElectDSBM -- SBM is in this state when a DSBM election is in
progress.
ElectDSBM--DSBM選挙が進行しているとき、SBMがこの状態にあります。
IAMDSBM -- SBM is in this state when it is the DSBM for the L2
domain.
IAMDSBM--それがL2ドメインへのDSBMであるときに、SBMがこの状態にあります。
A.8. Events that cause state changes
A.8。 州の変化を引き起こす出来事
StartUp -- SBM starts operation.
StartUp--SBMは操業を開始します。
ListenInterval Timeout -- The ListenInterval timer has fired.
This means that the SBM has monitored its domain to check for an
existing DSBM or to check whether there are candidates (other
than itself) willing to be the DSBM.
ListenInterval Timeout--ListenIntervalタイマは撃たれました。 これは、SBMが既存のDSBMがないかどうかチェックするか、またはDSBMであっても構わないと思っている候補(それ自体を除いた)がいるかどうかチェックするためにドメインをモニターしたことを意味します。
DSBM_WILLING message received -- This means that the SBM received
a DSBM_WILLING message from some other SBM. Such a message is
sent when a SBM wishes to declare its candidacy to be the DSBM.
DSBM_WILLINGメッセージは受信されました--これは、SBMがある他のSBMからDSBM_WILLINGメッセージを受け取ったことを意味します。 SBMがDSBMになるように立候補を宣言したがっているとき、そのようなメッセージを送ります。
I_AM_DSBM message received -- SBM received a DSBM advertisement
from the DSBM in its L2 domain.
I_AM_DSBMメッセージは受信されました--SBMはL2ドメインのDSBMからDSBM広告を受け取りました。
DSBMDeadInterval Timeout -- The DSBMDeadIntervalTimer has fired.
This means that the SBM did not receive even one DSBM
advertisement during this period and indicates possible failure
of the DSBM.
DSBMDeadInterval Timeout--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.
RefreshInterval Timeout--RefreshIntervalTimerは発火しました。 IAMDSBM状態では、これは、次のDSBM広告を出すための時間であることを意味します。 ElectDSBM状態では、出来事は、もう別のDSBM_WILLINGメッセージを出すべき時間であることを意味します。
Yavatkar, et al. Standards Track [Page 40] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[40ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
ElectionInterval Timeout -- The ElectionIntervalTimer has fired.
This means that the SBM has waited long enough after declaring
its candidacy to determine whether or not it succeeded.
ElectionInterval Timeout--ElectionIntervalTimerは発火しました。 これは、SBMがそれが成功したかどうか決定するために立候補を宣言した後に十分長い間待ったことを意味します。
A.9. State Transition Diagram (Figure 3)
A.9。 状態遷移ダイヤグラム(図3)
+-----------+
+--<--------------<-|DetectDSBM |---->------+
| +-----------+ |
| |
| |
| |
| +-------------+ +---------+ |
+->---| Idle |--<>---|ElectDSBM|--<--+
+-------------+ +---------+
| |
| |
| |
| +-----------+ |
+<<- +---| IAMDSBM |-<-+
| +-----------+
|
| +-----------+
+>>-| SHUTDOWN |
+-----------+
+-----------+ +--<。--------------<、-、|DetectDSBM|、-、-、--、>、-、-、-、-、--+ | +-----------+ | | | | | | | | +-------------+ +---------+ | +->。---| 怠けてください。| --<>、-、--、|ElectDSBM|、--<--+ +-------------+ +---------+ | | | | | | | +-----------+ | + <<-+---| IAMDSBM|、-、<、-+ | +-----------+ | | +-----------+ + >>、-| 閉鎖| +-----------+
A.10. Election State Machine
A.10。 選挙州のマシン
Based on the events and states described above, the state changes at a SBM are described below. Each state change is triggered by an event and is typically accompanied by a sequence of actions. The state machine is described assuming a single threaded implementation (to avoid race conditions between state changes and timer events) with no timer events occurring during the execution of the state machine.
上で説明された出来事と州に基づいて、SBMの州の変化は以下で説明されます。 それぞれの州の変化は、出来事によって引き起こされて、動作の系列によって通常伴われます。 州のマシンの実行の間に起こるタイマ出来事なしでただ一つの糸を通された実現(州の変化とタイマ出来事の間の競合条件を避ける)を仮定して、州のマシンは説明されます。
The following routines will be frequently used in the description of the state machine:
以下のルーチンは州のマシンの記述に頻繁に使用されるでしょう:
ComparePrio(FirstAddrInfo, SecondAddrInfo)
-- determines whether the entity represented by the first parameter
is better than the second entity using the priority information
and the IP address information in the two parameters. If any
address is zero, that entity automatically loses; then first
priorities are compared; higher priority candidate wins. If there
is a tie based on the priority value, the tie is broken using the
IP addresses of tied candidates (one with the higher IP address
in the lexicographic order wins). Returns TRUE if first entity
is a better choice. FALSE otherwise.
ComparePrio(FirstAddrInfo、SecondAddrInfo)--最初のパラメタによって表された実体が優先権情報を使用する2番目の実体と2つのパラメタのIPアドレス情報より良いか否かに関係なく、決定します。 何かアドレスがゼロであるなら、その実体は自動的に損をします。 次に、最初に、プライオリティは比較されます。 より高い優先権候補は勝ちます。 優先順位の値に基づく繋がりがあれば、繋がりは結ばれた候補のIPアドレスを使用するのにおいて中断しています(より高いIPアドレスが辞書式順序にある1つは獲得されます)。 最初の実体が、より良い選択であるならTRUEを返します。 FALSE、そうでなければ。
Yavatkar, et al. Standards Track [Page 41] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[41ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
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(適切な分野へのコピーOwnAddrと優先権)スタートRefreshIntervalTimer goto ElectDSBM州のEndの候補に自分について記載するSendの出ているDSBM_WILLINGメッセージを始めます。
AmIBetterDSBM(OtherAddrInfo)
Begin
if (ComparePrio(OwnAddrInfo, OtherAddrInfo))
return TRUE
(ComparePrio(OwnAddrInfo、OtherAddrInfo))がTRUEを返すなら、AmIBetterDSBM(OtherAddrInfo)は始まります。
change LocalDSBMInfo = OtherDSBMAddrInfo
return FALSE
End
変化LocalDSBMInfoはOtherDSBMAddrInfoリターンFALSE Endと等しいです。
UpdateDSBMInfo()
/* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */
Begin
update LocalDSBMInfo such as IP addr, DSBM L2 address,
DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer
End
UpdateDSBMInfo()/*は、IP addrなどのアップデートLocalDSBMInfoをLocalDSBMInfo=OtherAddrInfo*などの課題で呼び出されるか、または始めます、DSBM L2アドレス、DSBM優先権、RefreshIntervalTimer、DSBMDeadIntervalTimer End
A.10.1 State Changes
A.10.1州の変化
In the following, the action "continue" or "continue in current state" means an "exit" from the current action sequence without a state transition.
以下では、動作が「続く」か、または「現状のときに、続いてください」は現在の動作系列から状態遷移なしで「出口」を意味します。
State: DOWN
Event: StartUp
New State: DetectDSBM
Action: Initialize the local state variables (LocalDSBMADDR and
LocalDSBMAddrInfo set to 0). Start the ListenIntervalTimer.
州: 出来事の下側に: 始動の新しい州: 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メッセージはActionを受けました: セットLocalDSBMAddrInfo=IncomingDSBMAddrInfoはDeadDSBMIntervalタイマgoto Idle州を始めます。
State: DetectDSBM
Event: ListenIntervalTimer fired
New State: ElectDSBM
Action: Start ElectionIntervalTimer
SendDSBMWillingMessage();
州: DetectDSBM出来事: ListenIntervalTimerはNew州を発火させました: ElectDSBM動作: ElectionIntervalTimer SendDSBMWillingMessage()を始動してください。
Yavatkar, et al. Standards Track [Page 42] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[42ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
State: DetectDSBM Event: DSBM_WILLING message received New State: ElectDSBM Action: Cancel any active timers
州: DetectDSBM出来事: DSBM_WILLINGメッセージはNew州を受けました: 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
}
スタートElectionIntervalTimer/*はこの奴より良いI a選択ですか? */、(ComparePrio(OwnAddrInfo、IncomingDSBMInfo))であるなら/*Iが、より良い*/SendDSBMWillingMessage()である、ほか変化LocalDSBMAddrInfoはIncomingDSBMAddrInfo goto ElectDSBM状態と等しいです。
State: Idle
Event: DSBMDeadIntervalTimer fired.
New State: ElectDSBM
Action: start ElectionIntervalTimer
set LocalDSBMAddrInfo = OwnAddrInfo
SendDSBMWiliingMessage()
州: 出来事を空費してください: DSBMDeadIntervalTimerは発火しました。 新しい州: ElectDSBM動作: ElectionIntervalTimerセットLocalDSBMAddrInfo=OwnAddrInfo SendDSBMWiliingMessageを始動してください。()
State: Idle
Event: I_AM_DSBM message received.
New State: Idle
Action: /* first check whether anything has changed */
if (!ComparePrio(LocalDSBMAddrInfo, IncomingDSBMAddrInfo))
change LocalDSBMAddrInfo to reflect new info
endif
restart DSBMDeadIntervalTimer;
continue in current state;
州: 出来事を空費してください: I_AM_DSBMメッセージは受信されました。 新しい州: 動作を空費してください: /*は、最初に、(ComparePrio(LocalDSBMAddrInfo、IncomingDSBMAddrInfo))が新しいインフォメーションendif再開DSBMDeadIntervalTimerを反映するためにLocalDSBMAddrInfoを変えるなら何か*/を変えたかどうかチェックします。 現状のときに、続いてください。
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 */
}
州: 出来事を空費してください: DSBM_WILLING Messageは容認されたNew州です: 動作(ElectDSBMかIdle)動作によります: /*が、それがDSBM(閉鎖)自身から来ているかをチェックする、*/、(IncomingDSBMAddr=LocalDSBMAddr)です。OwnAddrInfo Start ElectionIntervalTimer SendDSBMWillingMessage()/*アクティブなタイマSet LocalDSBMAddrInfo=goto ElectDSBM状態*/を取り消してください。
/* else, ignore it */
continue in current state
/、*ほかに、それを無視してください、*/は現状のときに続きます。
State: ElectDSBM Event: ElectionIntervalTimer Fired
州: ElectDSBM出来事: ElectionIntervalTimerは発火しました。
Yavatkar, et al. Standards Track [Page 43] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[43ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
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
}
新しい州: 動作(IAMDSBMかCurrent州)動作によります: */に勝つ/*私が(LocalDSBMAddrInfo=OwnAddrInfo)であるならI_AM_DSBMメッセージスタートRefreshIntervalTimer goto IAMDSBM状態を送る、ほか他の誰かが勝つのでそれ自体がOwnAddrInfoスタートElectionIntervalTimer SendDSBMWillingMessage()が現状のときに続けているDSBM*/セットLocalDSBMAddressInfo=であると宣言するためにちょっと聞く/*
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メッセージはNew州を受けました: 動作を空費してください: IncomingDSBMAddrInfo LocalDSBMAddrInfo=キャンセルどんなアクティブなタイマスタートDeadDSBMIntervalタイマgoto Idle州も設定してください。
State: ElectDSBM
Event: DSBM_WILLING message received
New State: ElectDSBM
Action: Check whether it's a loopback and if so, discard, continue;
if (!AmIBetterDSBM(IncomingDSBMAddrInfo)) {
Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo
Cancel RefreshIntervalTimer
} else if (LocalDSBMAddrInfo == OwnAddrInfo) {
SendDSBMWillingMessage()
}
continue in current state
州: ElectDSBM出来事: DSBM_WILLINGメッセージはNew州を受けました: ElectDSBM動作: それがループバックであるかどうかチェックしてください、そして、そうだとすれば、捨ててください、そして、続いてください。 (LocalDSBMAddrInfo=OwnAddrInfo)SendDSBMWillingMessage()が現状のときに続くなら(AmIBetterDSBM(IncomingDSBMAddrInfo))がほかにIncomingDSBMAddrInfoキャンセルLocalDSBMAddrInfo=RefreshIntervalTimerを変えるなら
State: ElectDSBM
Event: RefreshIntervalTimer fired
New State: ElectDSBM
Action: /* continue to send DSBMWilling messages until
election interval ends */
SendDSBMWillingMessage()
州: ElectDSBM出来事: RefreshIntervalTimerはNew州を発火させました: ElectDSBM動作: /*は、選挙間隔が*/SendDSBMWillingMessageを終わらせるまでメッセージをDSBMWillingに送り続けています。()
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
州: IAMDSBM出来事: DSBM_WILLINGメッセージはNew州を受けました: 動作(IAMDSBMかSteadyState)動作によります: 他の奴がいるか否かに関係なく、/*チェックが(ComparePrio(OwnAddrInfo、IncomingAddrInfo))であるなら*/を改善する、/*Iは/がI_AM_DSBMメッセージを送るより良い*です。
Yavatkar, et al. Standards Track [Page 44] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[44ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
restart RefreshIntervalTimer
continue in current state
} else {
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto SteadyState
}
再開RefreshIntervalTimerが現状のときに続く、ほかセットLocalDSBMAddrInfo=IncomingAddrInfoは活発なタイマスタートDSBMDeadIntervalTimer goto SteadyStateを取り消します。
State: IAMDSBM
Event: RefreshIntervalTimer fired
New State: IAMDSBM
Action: send I_AM_DSBM message
restart RefreshIntervalTimer
州: IAMDSBM出来事: RefreshIntervalTimerはNew州を発火させました: IAMDSBM動作: I_AM_DSBMメッセージ再開RefreshIntervalTimerを送ってください。
State: IAMDSBM
Event: I_AM_DSBM message received
New State: depends on action (IAMDSBM or Idle)
Action: /* check whether other guy is better */
If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) {
/* I am better */
send I_AM_DSBM message
restart RefreshIntervalTimer
continue in current state
} else {
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto Idle State
}
州: IAMDSBM出来事: I_AM_DSBMメッセージはNew州を受けました: 動作(IAMDSBMかIdle)動作によります: /*チェック、/*Iが(ComparePrio(OwnAddrInfo、IncomingAddrInfo))であるなら他の奴が、より良い*/であるか否かに関係なく、/がRefreshIntervalTimerが現状のときに続けているI_AM_DSBMメッセージ再開を送るより良い*である、ほかセットLocalDSBMAddrInfo=IncomingAddrInfoは活発なタイマスタートDSBMDeadIntervalTimer goto Idle州を取り消します。
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出来事: 自分でNew州の下側に以下を閉じたいです。 動作の下側に: 記入されるMyアドレスにもかかわらず、優先権がgoto Down州のゼロに合って、設定されるDSBM_WILLINGメッセージを送ってください。
A.10.2 Suggested Values of Interval Timers
A.10.2はインタバルタイマの値を勧めました。
To avoid DSBM outages for long period, to ensure quick recovery from DSBM failures, and to avoid timeout of PATH and RESV state at the edge devices, we suggest the following values for various timers.
長期のDSBM供給停止を避けて、DSBMの故障からの迅速な回復を確実にして、エッジデバイスでPATHとRESV状態のタイムアウトを避けるために、私たちは様々なタイマのために以下の値を勧めます。
Assuming that the RSVP implementations use a 30 second timeout for PATH and RESV refreshes, we suggest that the RefreshIntervalTimer should be set to about 5 seconds with DSBMDeadIntervalTimer set to 15 seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be set
RSVP実現がPATHとRESVのための2番目のタイムアウトがリフレッシュする30を使用すると仮定して、私たちは、RefreshIntervalTimerが15秒(K=3、K*RefreshInterval)に用意ができているDSBMDeadIntervalTimerと共におよそ5秒に用意ができるべきであると示唆します。 DetectDSBMTimerは用意ができるべきです。
Yavatkar, et al. Standards Track [Page 45] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[45ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
to a random value between (DSBMDeadIntervalTimer, 2*DSBMDeadIntervalTimer). The ElectionIntervalTimer should be set at least to the value of DSBMDeadIntervalTimer to ensure that each SBM has a chance to have its DSBM_WILLING message (sent every RefreshInterval in ElectDSBM state) delivered to others.
(DSBMDeadIntervalTimer、2*DSBMDeadIntervalTimer)の間の無作為の値に。 ElectionIntervalTimerは各SBMにはDSBM_WILLINGメッセージ(ElectDSBM状態であらゆるRefreshIntervalを送る)を他のものに送らせる機会があるのを保証するように少なくともDSBMDeadIntervalTimerの値に用意ができるべきです。
A.10.3. Guidelines for Choice of Values for SBM_PRIORITY
A.10.3。 SBM_優先権のための値の選択のためのガイドライン
Network administrators should configure SBM protocol entity at each SBM-capable device with the device's "SBM priority" for each of the interfaces attached to a managed segment. SBM_PRIORITY is an 8-bit, unsigned integer value (in the range 0-255) with higher integer values denoting higher priority. The value zero for an interface indicates that the SBM protocol entity on the device is not eligible to be a DSBM for the segment attached to the interface.
ネットワーク管理者はそれぞれのSBMできる装置で装置の「SBM優先権」で管理されたセグメントに付けられたそれぞれのインタフェースにSBMプロトコル実体を構成するべきです。 SBM_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.
それぞれのタイプのSBMできる装置が異なったクラスのL2/L3装置の中で相対的な優先権を反映するように、別々の範囲の値は予約されます。 L2装置で、ホストによって後をつけられたルータは、より高い優先度のあとに続きます。 128の範囲の優先順位の値。255はL2装置、64の範囲の値のために予約されます。127はルータ、および値のために1の範囲で予約されます。63はホストのために予約されます。
A.11. DSBM Election over switched links
A.11。 切り換えられたリンクの上のDSBM Election
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で説明されるように、特別なマルチキャストアドレス(AllSBMAddress)にDSBM選挙に関連するすべてのメッセージを送ります。 AllSBMAddress(対応するMACマルチキャストアドレス)はSBMできることの永久的なデータベースで構成されます、層2の装置によって、送付先アドレスとしてのAllSBMAddressがあるすべてのフレームが、送られて、代わりにそれらの装置のSBM経営体に向けられるというわけではありません。 したがって、別々に切り換えられたトポロジーのそれぞれの二地点間セグメントでDSBMを選出できます。 例えば、図2では、「セグメントA」のためのDSBMはR1とS1の間の選挙アルゴリズムを使用することで選出されるでしょう、そして、このセグメントに関する選挙関連のメッセージのいずれも「セグメントA」を超えてS1によって転送されないでしょう。 同様に、別々の選挙はこのトポロジーの各セグメントで行われるでしょう。
When a switched segment is a half-duplex segment, two senders (one sender at each end of the link) share the link. In this case, one of the two senders will win the DSBM election and will be responsible for managing the segment.
切り換えられたセグメントが半二重セグメントであるときに、2人の送付者(リンクの各端の1人の送付者)がリンクを共有します。 この場合、2人の送付者のひとりは、DSBMに選挙に勝って、セグメントを管理するのに責任があるでしょう。
Yavatkar, et al. Standards Track [Page 46] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[46ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
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人の送付者が各方向にリンクを転送します。 この場合、どちらかか2DSBMsがそのような管理されたセグメントに存在できます。 それのためのa DSBMが終わっている間、各端の送付者が役立ちたいなら、それは、それ自体がI_AM_DSBM広告を出すのによるDSBMであり、セグメントの上で外向的な交通のためのリソースを管理し始めると宣言できます。 2人の送付者のひとりが、それ自体にDSBMであって欲しくないなら、もう片方のDSBMは、同輩からどんなDSBM広告も受け取って、それ自体が管理されたセグメントの上の両方の方向への交通横断のためのDSBMであると仮定しないでしょう。
Yavatkar, et al. Standards Track [Page 47] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[47ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
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とDSBMからのすべてのコミュニケーションがRSVPメッセージ・フォーマットと生のIPカプセル化に現在の規則を使用することで構成されたメッセージを使用することで実行されるでしょう。 RSVPメッセージ・フォーマットに関するその他の詳細について、RSVP仕様(RFC2205)を参照してください。 RSVPメッセージ・フォーマットへの変化は全く提案されませんが、新しいメッセージタイプと新しいL2特有の物は、DSBMの関連するメッセージに対応するためにRSVPメッセージ・フォーマットに加えられます。 これらの追加は以下で説明されます。
B.1 Message Addressing
B.1メッセージアドレシング
For the purpose of DSBM election and detection, AllSBMAddress is used as the destination address while sending out both DSBM_WILLING and I_AM_DSBM messages. A DSBM client first detects a managed segment by listening to I_AM_DSBM advertisements and records the DSBMAddress (unicast IP address of the DSBM).
DSBM選挙と検出の目的のために、送付先アドレスが_DSBM_WILLINGとI AM_DSBMの両方を出している間、通信するようにAllSBMAddressは使用されています。 DSBMクライアントは、最初に、I_AM_DSBM広告を聞くことによって管理されたセグメントを検出して、DSBMAddress(DSBMのユニキャストIPアドレス)を記録します。
B.2. Message Sizes
B.2。 メッセージサイズ
Each message must occupy exactly one IP datagram. If it exceeds the MTU, such a datagram will be fragmented by IP and reassembled at the recipient node. This has a consequence that a single message may not exceed the maximum IP datagram size, approximately 64K bytes.
各メッセージはちょうど1個のIPデータグラムを占領しなければなりません。 MTUを超えていると、そのようなデータグラムは、IPによって断片化されて、受取人ノードで組み立て直されるでしょう。 これには、ただ一つのメッセージが最大のIPデータグラムサイズ、およそ64Kバイト超えないかもしれない結果があります。
B.3. RSVP-related Message Formats
B.3。 RSVP関連のメッセージ・フォーマット
All RSVP messages directed to and from a DSBM may contain various RSVP objects defined in the RSVP specification and messages continue to follow the formatting rules specified in the RSVP specification. In addition, an RSVP implementation must also recognize new object classes that are described below.
DSBMとDSBMから指示されたすべてのRSVPメッセージがRSVP仕様に基づき定義された様々なRSVPオブジェクトを含むかもしれません、そして、メッセージはずっとRSVP仕様で指定された形式規則に従います。 また、さらに、RSVP実装は以下で説明される新しいオブジェクトのクラスを認識しなければなりません。
B.3.1. Object Formats
B.3.1。 オブジェクト形式
All objects are defined using the format specified in the RSVP specification. Each object has a 32-bit header that contains length (of the object in bytes including the object header), the object class number, and a C-Type. All unused fields should be set to zero and ignored on receipt.
すべてのオブジェクトが、RSVP仕様で指定された形式を使用することで定義されます。 各オブジェクトには、長さ(バイトで表現されるオブジェクトがオブジェクトヘッダーを含むのについて)、オブジェクトクラス番号、およびC-タイプを含む32ビットのヘッダーがあります。 すべての未使用の分野が、ゼロに設定されて、領収書の上で無視されるべきです。
Yavatkar, et al. Standards Track [Page 48] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[48ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
B.3.2. SBM Specific Objects
B.3.2。 SBMの特定のオブジェクト
Note that the Class-Num values for the SBM specific objects (LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2) are chosen from the codespace 10XXXXXX. This coding assures that non-SBM aware RSVP nodes will ignore the objects without forwarding them or generating an error message.
SBMの特定のオブジェクト(LAN_NHOP、LAN_LOOPBACK、およびRSVP_HOP_L2)のためのClass-ヌム値がcodespace 10XXXXXXから選ばれていることに注意してください。 このコード化は、非SBMの意識しているRSVPノードがそれらを進めるか、またはエラーメッセージを生成しないでオブジェクトを無視することを保証します。
Within the SBM specific codespace, note the following interpretation of the third most significant bit of the Class-Num:
SBMの特定のcodespaceの中では、Class-ヌムの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ノードによって静かに進められることになっています。
B.3.3. IEEE 802 Canonical Address Format
B.3.3。 IEEE802の正準なアドレス形式
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.
MAC AddressesがIEEE802で使用した48ビットは元々、ソースと目的地MACアドレス・フィールドでのビットのワイヤオーダー送信で定義されました。 同じワイヤオーダーはイーサネットとToken Ringの両方に適用されました。 イーサネットとToken Ringのビット伝送命令以来、データは異なります--最初にイーサネット八重奏は伝えられた最下位ビットです、Token Ring最も重要な1番目--自然に異なった802のメディアに関する同じアドレスに関連している数値は異なります。 1つの正書法を定義するのが必要でした--トークンリングと添付のイーサネットの両方にかかるかもしれないより高い層のプロトコルのアドレス値に関するコミュニケーションを容易にするために、システムはブリッジで接続して、これらのアドレスのためのいわゆる正準な形式。 正式に、正準な形式はトランスミッションに使用される符号化規則から別々のアドレスの値を定義します。 それは以下のオリジナルのワイヤオーダートランスミッションビット命令から得られた八重奏の系列を含みます。 8番目のビットである最初の八重奏の噛み付かれる、およびしたがって、最も重要なビットへの秒の間の次の最下位ビットは、最初の八重奏の最下位ビットが伝えられた最初のビットであると伝えました。 2番目の八重奏の最下位ビットはアドレスの最後のビットであることが伝わったように伝えられて、とても正準な形式の6番目の八重奏の最も重要なビットにオンな9番目のビットです。
This canonical format corresponds to the natural value of the address octets for Ethernet. The actual transmission order or formal encoding rules for addresses on media which do not transmit bit serially are derived from the canonical format octet values.
この正準な形式はイーサネットのためのアドレス八重奏の自然な値に対応しています。 伝わらないメディアに関するアドレスに順次噛み付いたので、正準な形式八重奏値から実際のトランスミッション命令か正式なコード化規則を得ます。
Yavatkar, et al. Standards Track [Page 49] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[49ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
This document requires that all L2 addresses used in conjunction with the SBM protocol be encoded in the canonical format as a sequence of 6 octets. In the following, we define the object formats for objects that contain L2 addresses that are based on the canonical representation.
このドキュメントは、SBMプロトコルに関連して使用されるすべてのL2アドレスが6つの八重奏の系列として正準な形式でコード化されるのを必要とします。 以下では、私たちは正準な表現に基づいているL2アドレスを含むオブジェクトのためにオブジェクト書式を定義します。
B.3.4. RSVP_HOP_L2 object
B.3.4。 RSVP_HOP_L2オブジェクト
RSVP_HOP_L2 object uses object class = 161; it contains the L2 address of the previous hop L3 device in the IEEE Canonical address format discussed above.
RSVP_HOP_L2オブジェクトはオブジェクトのクラス=161を使用します。 それは上で議論したIEEE Canonicalアドレス形式に前のホップL3デバイスのL2アドレスを含んでいます。
RSVP_HOP_L2 object: class = 161, C-Type represents the addressing format used. In our case, C-Type=1 represents the IEEE Canonical Address format.
RSVP_HOP_L2は反対します: クラス=161、C-タイプは形式が使用したアドレシングを表します。 私たちの場合では、C-タイプ=1はIEEE Canonical Address書式を表します。
0 1 2 3
+---------------+---------------+---------------+----------------+
| Length | 161 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+
| Variable length Opaque data |
+---------------+---------------+---------------+----------------+
0 1 2 3 +---------------+---------------+---------------+----------------+ | 長さ| 161 |C-タイプ(addrtype)| +---------------+---------------+---------------+----------------+ | 可変長Opaqueデータ| +---------------+---------------+---------------+----------------+
C-Type = 1 (IEEE Canonical Address format)
C-タイプ=1(IEEE Canonical Address形式)
When C-Type=1, the object format is:
C-タイプ=1であるのに、オブジェクト形式は以下の通りです。
0 1 2 3
+---------------+---------------+---------------+---------------+
| 12 | 161 | 1 |
+---------------+---------------+---------------+---------------+
| Octets 0-3 of the MAC address |
+---------------+---------------+---------------+---------------+
| Octets 4-5 of the MAC addr. | /// | /// |
+---------------+---------------+---------------+---------------+
0 1 2 3 +---------------+---------------+---------------+---------------+ | 12 | 161 | 1 | +---------------+---------------+---------------+---------------+ | MACアドレスの八重奏0-3| +---------------+---------------+---------------+---------------+ | MAC addrの八重奏4-5。 | /// | /// | +---------------+---------------+---------------+---------------+
/// -- unused (set to zero)
///--、未使用(ゼロへのセット)
B.3.5. LAN_NHOP object
B.3.5。 LAN_NHOPオブジェクト
LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address
object and LAN_NHOP_L2 address object.
<LAN_NHOP object> ::= <LAN_NHOP_L2 object> <LAN_NHOP_L3 object>
すなわち、LAN_NHOP_L3アドレスオブジェクトとLAN_NHOP_L2アドレスは、LAN_NHOPオブジェクトが2個のオブジェクトを表すのを反対します。 <LAN_NHOPオブジェクト>:、:= _<LAN_NHOP_L2オブジェクト><LAN NHOP_L3オブジェクト>。
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アドレスオブジェクトは、RSVP_HOP_L2オブジェクトとしてオブジェクトのクラス=162を使用して、同じ形式(しかし、異なったクラス番号)を使用します。 それは次のホップL3デバイスのアドレスをL2かMACに供給します。
Yavatkar, et al. Standards Track [Page 50] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[50ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
0 1 2 3
+---------------+---------------+---------------+----------------+
| Length | 162 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+
| Variable length Opaque data |
+---------------+---------------+---------------+----------------+
0 1 2 3 +---------------+---------------+---------------+----------------+ | 長さ| 162 |C-タイプ(addrtype)| +---------------+---------------+---------------+----------------+ | 可変長Opaqueデータ| +---------------+---------------+---------------+----------------+
C-Type = 1 (IEEE 802 Canonical Address Format as defined below) See the RSVP_HOP_L2 address object for more details.
C-タイプ=1(以下で定義されるIEEE802Canonical Address Format)はその他の詳細に関してRSVP_HOP_L2アドレスオブジェクトを見ます。
LAN_NHOP_L3 object uses object class = 163 and gives the L3 or IP address of the next hop L3 device.
LAN_NHOP_L3オブジェクトは、オブジェクトのクラス=163を使用して、次のホップL3デバイスのアドレスをL3かIPに与えます。
LAN_NHOP_L3 object: class = 163, C-Type specifies IPv4 or IPv6 address family used.
LAN_NHOP_L3は反対します: クラス=163、C-タイプはIPv4か使用されるIPv6アドレスファミリーを指定します。
IPv4 LAN_NHOP_L3 object: class =163, C-Type = 1 +---------------+---------------+---------------+---------------+ | Length = 8 | 163 | 1 | +---------------+---------------+---------------+---------------+ | IPv4 NHOP address | +---------------------------------------------------------------+
IPv4LAN_NHOP_L3は反対します: クラスは163、C-タイプ=1+と等しいです。---------------+---------------+---------------+---------------+ | 長さ=8| 163 | 1 | +---------------+---------------+---------------+---------------+ | IPv4 NHOPアドレス| +---------------------------------------------------------------+
IPv6 LAN_NHOP_L3 object: class =163, C-Type = 2 +---------------+---------------+---------------+---------------+ | Length = 20 | 163 | 2 | +---------------+---------------+---------------+---------------+ | IPv6 NHOP address (16 bytes) | +---------------------------------------------------------------+
IPv6LAN_NHOP_L3は反対します: クラスは163、C-タイプ=2+と等しいです。---------------+---------------+---------------+---------------+ | 長さ=20| 163 | 2 | +---------------+---------------+---------------+---------------+ | IPv6 NHOPアドレス(16バイト)| +---------------------------------------------------------------+
B.3.6. LAN_LOOPBACK Object
B.3.6。 LAN_ループバックオブジェクト
The LAN_LOOPBACK object gives the IP address of the outgoing interface for a PATH message and uses object class=164; both IPv4 and IPv6 formats are specified.
LAN_LOOPBACKオブジェクトは、PATHメッセージのために外向的なインタフェースのIPアドレスを与えて、オブジェクトのクラス=164を使用します。 IPv4とIPv6形式の両方が指定されます。
IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1
IPv4LAN_LOOPBACKは反対します: クラスは164、C-タイプ=1と等しいです。
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | 164 | 1 |
+---------------+---------------+---------------+---------------+
| IPV4 address of an interface |
+---------------+---------------+---------------+---------------+
0 1 2 3 +---------------+---------------+---------------+---------------+ | 長さ| 164 | 1 | +---------------+---------------+---------------+---------------+ | インタフェースのIPV4アドレス| +---------------+---------------+---------------+---------------+
Yavatkar, et al. Standards Track [Page 51] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[51ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2
IPv6LAN_LOOPBACKは反対します: クラスは164、C-タイプ=2と等しいです。
+---------------+---------------+---------------+---------------+ | Length | 164 | 2 | +---------------+---------------+---------------+---------------+ | | + + | | + IPV6 address of an interface + | | + + | | +---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+ | 長さ| 164 | 2 | +---------------+---------------+---------------+---------------+ | | + + | | + インタフェース+のIPV6アドレス| | + + | | +---------------+---------------+---------------+---------------+
B.3.7. TCLASS Object
B.3.7。 TCLASSオブジェクト
TCLASS object (traffic class based on IEEE 802.1p) uses object class = 165.
TCLASSオブジェクト(IEEE 802.1pに基づくトラフィックのクラス)はオブジェクトのクラス=165を使用します。
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | 165 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /// | /// | /// | /// | PV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| 165 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /// | /// | /// | /// | PV| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Only 3 bits in data contain the user_priority value (PV).
データの3ビットだけがユーザ_優先順位の値(PV)を含んでいます。
B.4. RSVP PATH and PATH_TEAR Message Formats
B.4。 RSVP経路と経路_裂け目のメッセージ・フォーマット
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 Common Headerと関連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 Common Headerについて、RSVP仕様(RFC2205)を参照してください。 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>
<経路メッセージ>:、:= <RSVP Common Header>[<INTEGRITY>]<RSVP_HOP_L2><LAN_NHOP><LAN_LOOPBACK>[<TCLASS>]<SESSION><RSVP_HOP><タイム誌_VALUES>[<POLICY DATA>]<送付者記述子>。
<PATH_TEAR Message> ::= <RSVP Common Header> [<INTEGRITY>]
<LAN_LOOPBACK> <LAN_NHOP> <SESSION> <RSVP_HOP>
[<sender descriptor>]
<経路_裂け目のメッセージ>:、:= <RSVP一般的なヘッダー>[<保全>]<LAN_ループバック><LAN_NHOP><セッション><RSVP_ホップ>。[<送付者記述子>]
Yavatkar, et al. Standards Track [Page 52] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[52ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
If the INTEGRITY object is present, it must immediately follow the RSVP common header. L2-specific objects must always precede the SESSION object.
INTEGRITYオブジェクトが存在しているなら、それはすぐに、RSVPの一般的なヘッダーに続かなければなりません。 L2特有のオブジェクトはいつもSESSIONオブジェクトに先行しなければなりません。
B.5. RSVP RESV Message Format
B.5。 RSVP RESVメッセージ・フォーマット
As specified in the RSVP specification, an RSVP_RESV message contains the RSVP Common Header and relevant RSVP objects. In addition, it may contain an optional TCLASS object as described earlier.
RSVP仕様で指定されるように、RSVP_RESVメッセージはRSVP Common Headerと関連RSVPオブジェクトを含んでいます。 さらに、それは、より早く説明されるように任意のTCLASSオブジェクトを含むかもしれません。
B.6. Additional RSVP message types to handle SBM interactions
B.6。 SBM相互作用を扱う追加RSVPメッセージタイプ
New RSVP message types are introduced to allow interactions between a DSBM and an RSVP node (host/router) for the purpose of discovering and binding to a DSBM. New RSVP message types needed are as follows:
DSBMと発見とDSBMに付く目的のためのRSVPノード(ホスト/ルータ)との相互作用を許容するために新しいRSVPメッセージタイプを導入します。 必要である新しいRSVPメッセージタイプは以下の通りです:
RSVP Msg Type (8 bits) Value DSBM_WILLING 66 I_AM_DSBM 67
RSVPエムエスジーType(8ビット)値のDSBM_WILLING66I_AM_DSBM67
All SBM-specific messages are formatted as RSVP messages with an RSVP common header followed by SBM-specific objects.
RSVPの一般的なヘッダーがあるRSVPメッセージがSBM特有のオブジェクトで従って、すべてのSBM特有のメッセージがフォーマットされます。
<SBMP_MESSAGE> ::= <SBMP common header> <SBM-specific objects>
<SBMP_メッセージ>:、:= <のSBMPの一般的なヘッダー><SBM特有のオブジェクト>。
where <SBMP common header> ::= <RSVP common Header> [<INTEGRITY>]
どこの<のSBMPの一般的なヘッダー>:、:= <のRSVPの一般的なHeader>。[<保全>]
For each SBM message type, there is a set of rules for the permissible choice of object types. These rules are specified using
それぞれのSBMメッセージタイプのために、オブジェクト・タイプの許されている選択のための1セットの規則があります。 これらの規則は指定された使用です。
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.
BN記法(BNF)は角括弧で周囲の任意のサブ系列を増大させました。 BNFはメッセージのオブジェクトの注文を含意します。 しかしながら、多くの(すべてでない)場合では、オブジェクトオーダーはどんな論理的な違いも作りません。 実装はここのオーダーでオブジェクトでメッセージを作成するべきですが、あらゆる許されているオーダーでオブジェクトを受け入れてください。 この規則へのどんな例外も特定のメッセージ・フォーマットで指摘されるでしょう。
DSBM_WILLING Message
DSBMの_の望んでいるメッセージ
<DSBM_WILLING message> ::= <SBM Common Header> <DSBM IP ADDRESS>
<DSBM L2 address> <SBM PRIORITY>
<DSBM_WILLINGメッセージ>:、:= <SBM Common Header><DSBM IP ADDRESS><DSBM L2アドレス><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>]
_<I AM_DSBM>:、:= <SBM Common Header><DSBM IP ADDRESS><DSBM L2アドレス><SBM PRIORITY><DSBM Timer Intervals>。[RESV_が_限界>を送る<非_]
Yavatkar, et al. Standards Track [Page 53] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[53ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
For compatibility reasons, receivers of the I_AM_DSBM message must be prepared to receive additional objects of the Unknown Class type [RFC-2205].
互換性理由のために、Unknown Classタイプ[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 ADDRESSオブジェクトはオブジェクトのクラス=42を使用します。 使用するIP ADDRESSが1個の<Class=42、>、およびIPv6 DSBM IP ADDRESS C-タイプ=オブジェクトを反対させるIPv4 DSBMが<Class=42を使用して、C-タイプは2>と等しいです。
IPv4 DSBM IP ADDRESS object: class = 42, C-Type =1
0 1 2 3
+---------------+---------------+---------------+---------------+
| IPv4 DSBM IP Address |
+---------------+---------------+---------------+---------------+
IPv4 DSBM IP ADDRESSは反対します: クラスは42、C-タイプ=1 0 1 2 3+と等しいです。---------------+---------------+---------------+---------------+ | IPv4 DSBM IPアドレス| +---------------+---------------+---------------+---------------+
IPv6 DSBM IP ADDRESS object: Class = 42, C-Type = 2
IPv6 DSBM IP ADDRESSは反対します: クラスは42、C-タイプ=2と等しいです。
+---------------+---------------+---------------+---------------+ | | + + | | + IPv6 DSBM IP Address + | | + + | | +---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+ | | + + | | + IPv6 DSBM IPアドレス+| | + + | | +---------------+---------------+---------------+---------------+
<DSBM L2 address> Object is the same as <RSVP_HOP_L2> object with C- Type = 1 for IEEE Canonical Address format.
IEEE Canonical Address形式に、<DSBM L2アドレス>ObjectはCタイプ=1で<RSVP_HOP_L2>オブジェクトと同じです。
<DSBM L2 address> ::= <RSVP_HOP_L2>
<DSBM L2は>を扱います:、:= <RSVP_ホップ_L2>。
A SBM may omit this object by including a NULL L2 address object. For C-Type=1 (IEEE Canonical address format), such a version of the L2 address object contains value zero in the six octets corresponding to the MAC address (see section B.3.4 for the exact format).
SBMは、NULL L2アドレスオブジェクトを含んでいることによって、このオブジェクトを省略するかもしれません。 C-タイプ=1(IEEE Canonicalアドレス形式)のために、L2アドレスオブジェクトのそのようなバージョンはMACアドレスに対応する6つの八重奏における値ゼロを含んでいます(正確な形式に関してセクションB.3.4を見てください)。
Yavatkar, et al. Standards Track [Page 54] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[54ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
SBM_PRIORITY Object: class = 43, C-Type =1
SBM_優先権オブジェクト: クラスは43、C-タイプ=1と等しいです。
0 1 2 3
+---------------+---------------+---------------+---------------+
| /// | /// | /// | SBM priority |
+---------------+---------------+---------------+---------------+
0 1 2 3 +---------------+---------------+---------------+---------------+ | /// | /// | /// | SBM優先権| +---------------+---------------+---------------+---------------+
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 Dead IntervalとDSBM Refresh Interval)が、それぞれ整数値として0の範囲で指定されます。255秒。 両方の値は以下で説明された単一の「DSBMタイマ間隔」オブジェクトに含まれています。
DSBM Timer Intervals Object: class = 44, C-Type =1
DSBMタイマ間隔オブジェクト: クラスは44、C-タイプ=1と等しいです。
+---------------+---------------+---------------+----------------+ | /// | /// | DeadInterval | RefreshInterval| +---------------+---------------+---------------+----------------+
+---------------+---------------+---------------+----------------+ | /// | /// | DeadInterval| RefreshInterval| +---------------+---------------+---------------+----------------+
NON_RESV_SEND_LIMIT Object: class = 45, C-Type = 1
非_のRESV_は_限界オブジェクトを送ります: クラスは45、C-タイプ=1と等しいです。
0 1 2 3
+---------------+---------------+---------------+----------------+
| NonResvSendLimit(limit on traffic allowed to send without RESV)|
| |
+---------------+---------------+---------------+----------------+
0 1 2 3 +---------------+---------------+---------------+----------------+ | NonResvSendLimit(RESVなしで発信できたトラフィックでは、制限します)| | | +---------------+---------------+---------------+----------------+
<NonResvSendLimit> ::= <Intserv Sender_TSPEC object> (class=12, C-Type =2)
<NonResvSendLimit>:、:= <Intserv Sender_TSPECオブジェクト>。(クラス=12、C-タイプ=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の予約なしで管理されたセグメントに送ることができるトラフィックのプロフィールの上に1流れあたり1つの限界を指定します(さらに詳しい明細についてはこのオブジェクトの使用法のAppendix Cを見てください)。 オブジェクトはNonResvSendLimitパラメタを含んでいます。 このパラメタはIntserv SENDER_TSPECに同等です(コンテンツと符号化規則に関してRFC2210を見てください)。 SENDER_TSPECはトラフィックプロフィール(r、b、p、m、およびM)について説明する5つのパラメタを含んでいます。 送付ホストは送付者交通の流れについて説明するSENDER_TSPECをDSBMによって広告に掲載されたSENDER_TSPECと比較します。 問題の交通の流れのSENDER_TSPECがDSBMによって広告に掲載されたよりSENDER_TSPEC以下であるなら、適所で有効なRSVPの予約なしで対応する流れにトラフィックを送るのは許容できます。 さもなければ、それはそうではありません。
The network administrator may configure the DSBM to disallow any sent traffic in the absence of an RSVP reservation by configuring a NonResvSendLimit in which r = 0, b = 0, p = 0, m = infinity and M =
ネットワーク管理者は、rが0、bと等しいNonResvSendLimitを構成する=0、p=0、m=無限とM=のRSVPの予約がないときどんな送られたトラフィックも禁じるためにDSBMを構成するかもしれません。
Yavatkar, et al. Standards Track [Page 55] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[55ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
0. Similarly the network administrator may allow any traffic to be sent in the absence of an RSVP reservation by configuring a NonResvSendLimit in which r = infinity, b = infinity, p = infinity, m = 0 and M = infinity. Of course, any of these parameters may be set to values between zero and infinity to advertise finite per-flow limits.
0. 同様に、ネットワーク管理者は、どんなトラフィックもrが無限と等しいNonResvSendLimitを構成するのによるRSVPの予約がないとき送られるのを許すかもしれません、b=無限、p=無限、m=0とM=無限。 もちろん、ゼロと無限の間の値にこれらのパラメタのどれかが1流れあたりの有限限界の広告を出すように設定されるかもしれません。
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オブジェクトは任意です。 管理されたセグメントのSendersは無限に大きいSENDER_TSPECに同じくらい同等なNON_RESV_SEND_LIMITオブジェクトの不在を解釈するべきです(RSVPの予約がないときどんなトラフィックプロフィールも送るのは許されています)。
Yavatkar, et al. Standards Track [Page 56] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[56ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
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はそのようなパラメタを容易に分配できる集中的管理ポイントとして機能するかもしれません。 オブジェクトがAM_DSBMメッセージをI_に追加したので、DSBMを構成するネットワーク管理者にとって、ある設定パラメータが分配されることを引き起こすのは特に、可能です。 以下の構成オブジェクトはこのとき、定義されます。 他のものは将来、定義されるかもしれません。 さらに詳しい明細についてはNON_RESV_SEND_LIMITオブジェクトに関してAppendix Bを見てください。
C.1. NON_RESV_SEND_LIMIT
C.1。 非_のRESV_は_限界を送ります。
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.
1セットの中間的構成はQoSのグループから成ります。伝統的な共用セグメントに発信しながら、ホストを可能にしました。 層-3デバイス(または、層-2デバイス)は、共用セグメントのためのDSBMとして機能しますが、トラフィック分離を実施できません。 そのような構成では、DSBMは、送付者のためにセグメントで承認された予約の数を制限するために構成できますが、彼らが発信するのを防ぐことができません。 その結果、ネットワーク管理者はDSBMでの入場コントロールのための適切な限界を構成しましたが、送付者はセグメントを充血させるかもしれません。
One solution to this problem which would give the network administrator control over the segment, is to require applications (or operating systems on behalf of applications) not to send until they have obtained a reservation. This is problematic as most applications are used to sending as soon as they wish to and expect to get whatever service quality the network is able to grant at that time. Furthermore, it may often be acceptable to allow certain applications to send before a reservation is received. For example, on a segment comprised of a single 10 Mbps ethernet and 10 hosts, it may be acceptable to allow a 16 Kbps telephony stream to be transmitted but not a 3 Mbps video stream.
予約を得るまで、セグメントのネットワーク管理者支配力を与えて、発信しないように、アプリケーション(または、アプリケーションを代表したオペレーティングシステム)を必要とすることであるこの問題への1つの解決。 ほとんどのアプリケーションが願って、ネットワークがその時与えることができるどんなサービス品質も得ると予想するとすぐに、発信するのに使用されるとき、これは問題が多いです。 その上、予約が受け取られている前に発信するためにあるアプリケーションを許容するのはしばしば許容できるかもしれません。 例えば、ただ一つの10Mbpsイーサネットと10人のホストから成るセグメントでは、それは3Mbpsビデオストリームではなく、伝えられるべき16Kbps電話ストリームを許容するのにおいて許容できるかもしれません。
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
より実践的なソリューション、そして、a送付者が有効な予約がないとき管理されたセグメントで生成することができる非適応型のトラフィックの量における1流れあたり1つの限界を設定するネットワーク管理者は許すことになっています。 この限界をDSBMによって広告を出されて、ホストを送ることによって、受けます。 そして、送付ホストの上のAPIは、リソースに基づくアプリケーションのQoS要求を、承認する場合があるか、または否定する場合があります。
Yavatkar, et al. Standards Track [Page 57] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[57ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
requested.
要求にされる。
The NON_RESV_SEND_LIMIT object can be used to advertise a Flowspec which describes the shape of traffic that a sender is allowed to generate on a managed segment when its RSVP reservation requests have either not yet completed or have been rejected.
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.
作者はエリック・クローリー(アルゴン)、ラスFenger(インテル)、デヴィッド・メルマン(シーメンス)、Ramesh Pabbati(マイクロソフト)、ミックSeaman(3COM)、SBMデザインの彼らの建設的なコメントのためのアンドリュー・スミス(極端なNetworks)、およびこのドキュメントの以前のバージョンに感謝しています。
6. Authors' Addresses
6. 作者のアドレス
Raj Yavatkar Intel Corporation 2111 N.E. 25th Avenue, Hillsboro, OR 97124 USA
主権Yavatkar諜報社2111のアベニュー、ヒースボロー、または25番目の97124の東北米国
Phone: +1 503-264-9077 EMail: yavatkar@ibeam.intel.com
以下に電話をしてください。 +1 503-264-9077 メールしてください: yavatkar@ibeam.intel.com
Don Hoffman Teledesic Corporation 2300 Carillon Point Kirkland, WA 98033 USA
ドン・ホフマンTeledesic社2300の鐘のPointワシントン98033カークランド(米国)
Phone: +1 425-602-0000
以下に電話をしてください。 +1 425-602-0000
Yoram Bernet Microsoft 1 Microsoft Way Redmond, WA 98052 USA
ヨラムBernetマイクロソフト1マイクロソフト、道のワシントン98052レッドモンド(米国)
Phone: +1 206 936 9568 EMail: yoramb@microsoft.com
以下に電話をしてください。 +1 9568年の206 936メール: yoramb@microsoft.com
Yavatkar, et al. Standards Track [Page 58] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[58ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 USA
フレッドベイカーシスコシステムズ519のLado Driveカリフォルニア93111サンタバーバラ(米国)
Phone: +1 408 526 4257 EMail: fred@cisco.com
以下に電話をしてください。 +1 4257年の408 526メール: fred@cisco.com
Michael Speer Sun Microsystems, Inc 901 San Antonio Road UMPK15-215 Palo Alto, CA 94303
マイケル・シュペーア・サン・マイクロシステムズ、サンアントニオ道路UMPK15-215パロアルト、Inc901カリフォルニア 94303
Phone: +1 650-786-6368 EMail: speer@Eng.Sun.COM
以下に電話をしてください。 +1 650-786-6368 メールしてください: speer@Eng.Sun.COM
Yavatkar, et al. Standards Track [Page 59] RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Yavatkar、他 標準化過程[59ページ]RFC2814SBM(サブネット帯域幅マネージャ)2000年5月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Yavatkar, et al. Standards Track [Page 60]
Yavatkar、他 標準化過程[60ページ]
一覧
スポンサーリンク
