[要約] RFC 2816は、共有およびスイッチングされたIEEE 802 LANテクノロジー上での統合サービスのためのフレームワークを提供しています。このRFCの目的は、異なるサービスを提供するネットワーク上での統合サービスの実現と管理を支援することです。
Network Working Group A. Ghanwani
Request for Comments: 2816 Nortel Networks
Category: Informational W. Pace
IBM
V. Srinivasan
CoSine Communications
A. Smith
Extreme Networks
M. Seaman
Telseon
May 2000
A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies
共有および切り替えのIEEE 802 LANテクノロジーを介した統合サービスのフレームワーク
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This memo describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure. It includes background material on the capabilities of IEEE 802 like networks with regard to parameters that affect Integrated Services such as access latency, delay variation and queuing support in LAN switches. It discusses aspects of IETF's Integrated Services model that cannot easily be accommodated in different LAN environments. It outlines a functional model for supporting the Resource Reservation Protocol (RSVP) in such LAN environments. Details of extensions to RSVP for use over LANs are described in an accompanying memo [14]. Mappings of the various Integrated Services onto IEEE 802 LANs are described in another memo [13].
このメモは、共有および切り替えのLANインフラストラクチャでIETF統合サービスをサポートするためのフレームワークについて説明しています。IEEE 802の機能に関する背景素材が含まれており、LANスイッチのアクセスレイテンシ、遅延バリエーション、キューイングサポートなどの統合サービスに影響を与えるパラメーターに関するIEEE 802のようなネットワークのようなネットワークが含まれています。さまざまなLAN環境では簡単に対応できないIETFの統合サービスモデルの側面について説明します。このようなLAN環境でリソース予約プロトコル（RSVP）をサポートするための機能モデルの概要を説明します。LANを介して使用するためのRSVPへの拡張の詳細については、付随するメモ[14]で説明されています。IEEE 802 LANへのさまざまな統合サービスのマッピングは、別のメモ[13]で説明されています。
Contents
コンテンツ
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Outline . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
4. Frame Forwarding in IEEE 802 Networks . . . . . . . . . . 5
4.1. General IEEE 802 Service Model . . . . . . . . . . . 5
4.2. Ethernet/IEEE 802.3 . . . . . . . . . . . . . . . . . 7
4.3. Token Ring/IEEE 802.5 . . . . . . . . . . . . . . . . 8
4.4. Fiber Distributed Data Interface . . . . . . . . . . 10
4.5. Demand Priority/IEEE 802.12 . . . . . . . . . . . . . 10
5. Requirements and Goals . . . . . . . . . . . . . . . . . . 11
5.1. Requirements . . . . . . . . . . . . . . . . . . . . 11
5.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Non-goals . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Assumptions . . . . . . . . . . . . . . . . . . . . . 14
6. Basic Architecture . . . . . . . . . . . . . . . . . . . . 15
6.1. Components . . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Requester Module . . . . . . . . . . . . . . 15
6.1.2. Bandwidth Allocator . . . . . . . . . . . . . 16
6.1.3. Communication Protocols . . . . . . . . . . . 16
6.2. Centralized vs. Distributed Implementations . . . . 17
7. Model of the Bandwidth Manager in a Network . . . . . . . 18
7.1. End Station Model . . . . . . . . . . . . . . . . . . 19
7.1.1. Layer 3 Client Model . . . . . . . . . . . . 19
7.1.2. Requests to Layer 2 ISSLL . . . . . . . . . . 19
7.1.3. At the Layer 3 Sender . . . . . . . . . . . . 20
7.1.4. At the Layer 3 Receiver . . . . . . . . . . . 21
7.2. Switch Model . . . . . . . . . . . . . . . . . . . . 22
7.2.1. Centralized Bandwidth Allocator . . . . . . . 22
7.2.2. Distributed Bandwidth Allocator . . . . . . . 23
7.3. Admission Control . . . . . . . . . . . . . . . . . . 25
7.4. QoS Signaling . . . . . . . . . . . . . . . . . . . . 26
7.4.1. Client Service Definitions . . . . . . . . . 26
7.4.2. Switch Service Definitions . . . . . . . . . 27
8. Implementation Issues . . . . . . . . . . . . . . . . . . 28
8.1. Switch Characteristics . . . . . . . . . . . . . . . 29
8.2. Queuing . . . . . . . . . . . . . . . . . . . . . . . 30
8.3. Mapping of Services to Link Level Priority . . . . . 31
8.4. Re-mapping of Non-conforming Aggregated Flows . . . . 31
8.5. Override of Incoming User Priority . . . . . . . . . 32
8.6. Different Reservation Styles . . . . . . . . . . . . 32
8.7. Receiver Heterogeneity . . . . . . . . . . . . . . . 33
9. Network Topology Scenarios . . . . . . . . . . . . . . . 35
9.1. Full Duplex Switched Networks . . . . . . . . . . . . 36
9.2. Shared Media Ethernet Networks . . . . . . . . . . . 37
9.3. Half Duplex Switched Ethernet Networks . . . . . . . 38
9.4. Half Duplex Switched and Shared Token Ring Networks . 39
9.5. Half Duplex and Shared Demand Priority Networks . . . 40
10. Justification . . . . . . . . . . . . . . . . . . . . . . 42
11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43
References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Security Considerations . . . . . . . . . . . . . . . . . . . 45
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 47
The Internet has traditionally provided support for best effort traffic only. However, with the recent advances in link layer technology, and with numerous emerging real time applications such as video conferencing and Internet telephony, there has been much interest for developing mechanisms which enable real time services over the Internet. A framework for meeting these new requirements was set out in RFC 1633 [8] and this has driven the specification of various classes of network service by the Integrated Services working group of the IETF, such as Controlled Load and Guaranteed Service [6,7]. Each of these service classes is designed to provide certain Quality of Service (QoS) to traffic conforming to a specified set of parameters. Applications are expected to choose one of these classes according to their QoS requirements. One mechanism for end stations to utilize such services in an IP network is provided by a QoS signaling protocol, the Resource Reservation Protocol (RSVP) [5] developed by the RSVP working group of the IETF. The IEEE under its Project 802 has defined standards for many different local area network technologies. These all typically offer the same MAC layer datagram service [1] to higher layer protocols such as IP although they often provide different dynamic behavior characteristics -- it is these that are important when considering their ability to support real time services. Later in this memo we describe some of the relevant characteristics of the different MAC layer LAN technologies. In addition, IEEE 802 has defined standards for bridging multiple LAN segments together using devices known as "MAC Bridges" or "Switches" [2]. Recent work has also defined traffic classes, multicast filtering, and virtual LAN capabilities for these devices [3,4]. Such LAN technologies often constitute the last hop(s) between users and the Internet as well as being a primary building block for entire campus networks. It is therefore necessary to provide standardized mechanisms for using these technologies to support end-to-end real time services. In order to do this, there must be some mechanism for resource management at the data link layer. Resource management in this context encompasses the functions of admission control, scheduling, traffic policing, etc. The ISSLL (Integrated Services over Specific Link Layers) working group in the IETF was chartered with the purpose of exploring and standardizing such mechanisms for various link layer technologies.
インターネットは、伝統的にベストエフェクショントラフィックのみをサポートしてきました。ただし、リンクレイヤーテクノロジーの最近の進歩と、ビデオ会議やインターネットテレフォニーなどの多くの新興リアルタイムアプリケーションにより、インターネットを介したリアルタイムサービスを可能にするメカニズムを開発することには大きな関心があります。これらの新しい要件を満たすためのフレームワークはRFC 1633 [8]に記載されており、これにより、制御された負荷や保証サービスなど、IETFの統合サービスワーキンググループによってさまざまなクラスのネットワークサービスの仕様が駆動されました[6,7]。これらの各サービスクラスは、指定されたパラメーターセットに適合するトラフィックに特定のサービス品質（QO）を提供するように設計されています。アプリケーションは、QoS要件に従ってこれらのクラスのいずれかを選択することが期待されています。IPネットワークでそのようなサービスを利用するエンドステーションの1つのメカニズムは、IETFのRSVPワーキンググループによって開発されたQoSシグナリングプロトコル、リソース予約プロトコル（RSVP）[5]によって提供されます。IEEEプロジェクト802に基づくIEEEは、多くの異なるローカルエリアネットワークテクノロジーの標準を定義しています。これらはすべて、通常、同じMACレイヤーデータグラムサービス[1]をIPなどの高レイヤープロトコルに提供しますが、多くの場合、異なる動的な動作特性を提供します。リアルタイムサービスをサポートする能力を考慮すると重要です。このメモの後半では、さまざまなMacレイヤーLANテクノロジーの関連する特性のいくつかについて説明します。さらに、IEEE 802は、「Mac Bridges」または「Switches」として知られるデバイスを使用して、複数のLANセグメントを一緒にブリッジングするための標準を定義しています[2]。最近の研究では、これらのデバイスのトラフィッククラス、マルチキャストフィルタリング、仮想LAN機能も定義されています[3,4]。このようなLANテクノロジーは、多くの場合、ユーザーとインターネットの間の最後のホップを構成し、キャンパスネットワーク全体の主要なビルディングブロックです。したがって、これらのテクノロジーを使用してエンドツーエンドのリアルタイムサービスをサポートするための標準化されたメカニズムを提供する必要があります。これを行うには、データリンクレイヤーにリソース管理のメカニズムがある必要があります。このコンテキストでのリソース管理には、ITFのISSLL（特定のリンクレイヤーを介した統合サービス）ワーキンググループは、さまざまなリンクレイヤーテクノロジーのそのようなメカニズムを調査および標準化する目的でチャーターされていました。。
This document is concerned with specifying a framework for providing Integrated Services over shared and switched LAN technologies such as Ethernet/IEEE 802.3, Token Ring/IEEE 802.5, FDDI, etc. We begin in Section 4 with a discussion of the capabilities of various IEEE 802 MAC layer technologies. Section 5 lists the requirements and goals for a mechanism capable of providing Integrated Services in a LAN. The resource management functions outlined in Section 5 are provided by an entity referred to as a Bandwidth Manager (BM). The architectural model of the BM is described in Section 6 and its various components are discussed in Section 7. Some implementation issues with respect to link layer support for Integrated Services are examined in Section 8. Section 9 discusses a taxonomy of topologies for the LAN technologies under consideration with an emphasis on the capabilities of each which can be leveraged for enabling Integrated Services. This framework makes no assumptions about the topology at the link layer. The framework is intended to be as exhaustive as possible; this means that it is possible that all the functions discussed may not be supportable by a particular topology or technology, but this should not preclude the usage of this model for it.
このドキュメントは、イーサネット/IEEE 802.3、トークンリング/IEEE 802.5、FDDIなどの共有および切り替えのLANテクノロジーを介して統合サービスを提供するためのフレームワークを指定することに関係しています。Macレイヤーテクノロジー。セクション5には、LANで統合サービスを提供できるメカニズムの要件と目標を示します。セクション5で概説されているリソース管理機能は、帯域幅マネージャー（BM）と呼ばれるエンティティによって提供されます。BMのアーキテクチャモデルについてはセクション6で説明し、そのさまざまなコンポーネントについてセクション7で説明します。統合サービスのリンクレイヤーサポートに関するいくつかの実装の問題については、セクション8で検討します。セクション9では、LANテクノロジーのトポロジーの分類法について説明します。統合サービスを有効にするために活用できる各能力に重点を置いて検討中です。このフレームワークは、リンクレイヤーでのトポロジーについての仮定を行いません。フレームワークは、可能な限り網羅的であることを目的としています。これは、議論されたすべての機能が特定のトポロジやテクノロジーによってサポートされない可能性があることを意味しますが、これはこのモデルの使用を排除するべきではありません。
The following is a list of terms used in this and other ISSLL documents.
以下は、この文書およびその他のISSLLドキュメントで使用されている用語のリストです。
- Link Layer or Layer 2 or L2: Data link layer technologies such as Ethernet/IEEE 802.3 and Token Ring/IEEE 802.5 are referred to as Layer 2 or L2.
- リンクレイヤーまたはレイヤー2またはL2：イーサネット/IEEE 802.3やトークンリング/IEEE 802.5などのデータリンクレイヤーテクノロジーは、レイヤー2またはL2と呼ばれます。
- Link Layer Domain or Layer 2 Domain or L2 Domain: Refers to a set of nodes and links interconnected without passing through a L3 forwarding function. One or more IP subnets can be overlaid on a L2 domain.
- リンクレイヤードメインまたはレイヤー2ドメインまたはL2ドメイン：L3転送機能を通過せずに相互接続された一連のノードとリンクを参照します。1つ以上のIPサブネットは、L2ドメインでオーバーレイできます。
- Layer 2 or L2 Devices: Devices that only implement Layer 2 functionality as Layer 2 or L2 devices. These include IEEE 802.1D [2] bridges or switches.
- レイヤー2またはL2デバイス：レイヤー2またはL2デバイスとしてレイヤー2機能を実装するデバイス。これらには、IEEE 802.1d [2]ブリッジまたはスイッチが含まれます。
- Internetwork Layer or Layer 3 or L3: Refers to Layer 3 of the ISO OSI model. This memo is primarily concerned with networks that use the Internet Protocol (IP) at this layer.
- インターネットワークレイヤーまたはレイヤー3またはL3：ISO OSIモデルのレイヤー3を指します。このメモは、主にこのレイヤーでインターネットプロトコル（IP）を使用するネットワークに関係しています。
- Layer 3 Device or L3 Device or End Station: These include hosts and routers that use L3 and higher layer protocols or application programs that need to make resource reservations.
- レイヤー3デバイスまたはL3デバイスまたはエンドステーション：L3および高層プロトコルを使用するホストとルーターまたはリソース予約を行う必要があるアプリケーションプログラムが含まれます。
- Segment: A physical L2 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; (b) a half duplex link between two stations or switches; (c) one direction of a switched full duplex link.
- セグメント：1つ以上の送信者が共有する物理L2セグメント。セグメントの例には、次のものが含まれます。（a）CSMAまたはトークンの合格を使用したメディアアクセスのための共有イーサネットまたはトークンリングワイヤー解決競合。（b）2つのステーションまたはスイッチの間の半分二重リンク。（c）切り替えられたフル二重リンクの1つの方向。
- Managed Segment: A managed segment is a segment with a DSBM (designated subnet bandwidth manager, see [14]) 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（指定されたサブネット帯域幅マネージャー、[14]を参照）を備えたセグメントです。管理されたセグメントには、DSBMSによって分離されていない共有LANの相互接続された部分が含まれます。
- Traffic Class: Refers to an aggregation of data flows which are given similar service within a switched network.
- トラフィッククラス：スイッチネットワーク内で同様のサービスが与えられるデータフローの集約を指します。
- Subnet: Used in this memo to indicate a group of L3 devices sharing a common L3 network address prefix along with the set of segments making up the L2 domain in which they are located.
- サブネット：このメモで使用されて、共通のL3ネットワークアドレスのプレフィックスを共有するL3デバイスのグループと、それらが配置されているL2ドメインを構成するセグメントのセットを示す。
- Bridge/Switch: A Layer 2 forwarding device as defined by IEEE 802.1D [2]. The terms bridge and switch are used synonymously in this memo.
- ブリッジ/スイッチ：IEEE 802.1d [2]で定義されているレイヤー2転送デバイス。ブリッジとスイッチという用語は、このメモで同義語で使用されます。
The 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 and 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/IEEE 802.5 carries this value encoded in its FC octet while basic Ethernet/IEEE 802.3 does not carry it. IEEE 802.12 may or may not carry it depending on the frame format in use. When the frame format in use is IEEE 802.5, the user_priority is carried explicitly. When IEEE 802.3 frame format is used, only the two levels of priority (high/low) that are used to determine access priority can be recovered. This is based on the value of priority encoded in the start delimiter of the IEEE 802.3 frame.
user_priorityは、IEEE 802サービスモデルのすべてのフレームの送信と受信に関連する値です。MACサービスを使用している送信者から提供され、MACサービスを使用してデータとともにレシーバーに提供されます。実際にネットワークを介して運ばれる場合とそうでない場合があります。トークンリング/IEEE 802.5は、FCオクテットにエンコードされたこの値を携帯していますが、基本的なイーサネット/IEEE 802.3は運ばれません。IEEE 802.12は、使用中のフレーム形式に応じて携帯する場合と運ばない場合があります。使用中のフレーム形式がIEEE 802.5の場合、user_priorityは明示的に運ばれます。IEEE 802.3フレーム形式を使用すると、アクセスの優先度を決定するために使用される2つの優先度（高/低）のみを回復できます。これは、IEEE 802.3フレームの開始デリミタでエンコードされた優先度の値に基づいています。
NOTE: The original IEEE 802.1D standard [2] contains the specifications for the operation of MAC bridges. This has recently been extended to include support for traffic classes and dynamic multicast filtering [3]. In this document, the reader should be aware that references to the IEEE 802.1D standard refer to [3], unless explicitly noted otherwise.
注：元のIEEE 802.1D標準[2]には、Macブリッジの動作の仕様が含まれています。これは最近、トラフィッククラスと動的なマルチキャストフィルタリングのサポートを含むように拡張されました[3]。このドキュメントでは、読者は、IEEE 802.1d標準への参照が明示的に特に明示的に記載されていない限り、[3]を参照することを認識する必要があります。
IEEE 802.1D [3] defines a consistent way for carrying the value of the user_priority over a bridged network consisting of Ethernet, Token Ring, Demand Priority, FDDI or other MAC layer media using an extended frame format. The usage of user_priority is summarized below. We refer the interested reader to the IEEE 802.1D specification for further information.
IEEE 802.1d [3]は、拡張フレーム形式を使用して、イーサネット、トークンリング、需要の優先順位、FDDI、またはその他のMacレイヤーメディアで構成されるブリッジネットワークを介して、user_priorityの値を運ぶための一貫した方法を定義します。user_priorityの使用を以下に要約します。詳細については、関心のある読者にIEEE 802.1D仕様を紹介します。
If the user_priority is carried explicitly in packets, its utility is as a simple label enabling packets within a data stream in different classes to be discriminated easily by downstream nodes without having to parse the packet in more detail.
user_priorityがパケットに明示的に運ばれている場合、そのユーティリティは、パケットをより詳細に解析することなく、さまざまなクラスのデータストリーム内のパケットをダウンストリームノードによって簡単に区別できるようにする簡単なラベルとしてです。
Apart from making the job of desktop or wiring closet switches easier, an explicit field means they do not have to change hardware or software as the rules for classifying packets evolve; e.g. based on new protocols or new policies. More sophisticated Layer 3 switches, perhaps deployed in the core of a network, may be able to provide added value by performing packet classification more accurately and, hence, utilizing network resources more efficiently and providing better isolation between flows. This appears to be a good economic choice since there are likely to be very many more desktop/wiring closet switches in a network than switches requiring Layer 3 functionality.
デスクトップまたは配線クローゼットスイッチの仕事を簡単にすることとは別に、明示的なフィールドは、パケットを分類するためのルールが進化するため、ハードウェアやソフトウェアを変更する必要がないことを意味します。例えば新しいプロトコルまたは新しいポリシーに基づいています。おそらくネットワークのコアに展開されているより洗練されたレイヤー3スイッチは、パケット分類をより正確に実行することで付加価値を提供できる場合があり、したがって、ネットワークリソースをより効率的に利用し、フロー間のより良い分離を提供することができます。これは、レイヤー3の機能を必要とするスイッチよりも、ネットワーク内のデスクトップ/配線クローゼットスイッチが非常に多い可能性が高いため、良い経済的選択のように思われます。
The IEEE 802 specifications make no assumptions about how user_priority is to be used by end stations or by the network. Although IEEE 802.1D defines static priority queuing as the default mode of operation of switches that implement multiple queues, the user_priority is really a priority only in a loose sense since it depends on the number of traffic classes actually implemented by a switch. The user_priority is defined as a 3 bit quantity with a value of 7 representing the highest priority and a value of 0 as the lowest. The general switch algorithm is as follows. Packets are queued within a particular traffic class based on the received user_priority, the value of which is either obtained directly from the packet if an IEEE 802.1Q header or IEEE 802.5 network is used, or is assigned according to some local policy. The queue is selected based on a mapping from user_priority (0 through 7) onto the number of available traffic classes. A switch may implement one or more traffic classes. The advertised IntServ parameters and the switch's admission control behavior may be used to determine the mapping from user_priority to traffic classes within the switch. A switch is not precluded from implementing other scheduling algorithms such as weighted fair queuing and round robin.
IEEE 802仕様は、ユーザー_Priorityがエンドステーションまたはネットワークによってどのように使用されるかについて仮定しません。IEEE 802.1dは、静的優先度キューイングを複数のキューを実装するスイッチのデフォルト操作モードとして定義していますが、user_priorityは、実際にスイッチによって実装されているトラフィッククラスの数に依存するため、ゆるい意味でのみ優先されます。user_priorityは3ビット数量として定義され、値は最高の優先度を表し、値は最低の値です。一般的なスイッチアルゴリズムは次のとおりです。パケットは、受信したuser_priorityに基づいて特定のトラフィッククラス内でキューに掲載され、その値はIEEE 802.1qヘッダーまたはIEEE 802.5ネットワークが使用されている場合、パケットから直接取得されるか、ローカルポリシーに従って割り当てられます。キューは、user_priority（0〜7）から利用可能なトラフィッククラスの数へのマッピングに基づいて選択されます。スイッチは、1つ以上のトラフィッククラスを実装する場合があります。宣伝されているIntServパラメーターとスイッチの入場制御動作を使用して、user_priorityからスイッチ内のトラフィッククラスへのマッピングを決定できます。スイッチは、加重公正なキューイングやラウンドロビンなどの他のスケジューリングアルゴリズムを実装することを妨げられません。
IEEE 802.1D makes no recommendations about how a sender should select the value for user_priority. One of the primary purposes of this document is to propose such usage rules, and to discuss the communication of the semantics of these values between switches and end stations. In the remainder of this document we use the term traffic class synonymously with user_priority.
IEEE 802.1dは、送信者がuser_priorityの値を選択する方法について推奨しません。このドキュメントの主な目的の1つは、このような使用規則を提案し、スイッチとエンドステーション間のこれらの値のセマンティクスの通信を議論することです。このドキュメントの残りの部分では、user_priorityと同義語でトラフィッククラスという用語を使用します。
There is no explicit traffic class or user_priority field carried in Ethernet packets. This means that user_priority must be regenerated at a downstream receiver or switch according to some defaults or by parsing further into higher layer protocol fields in the packet. Alternatively, IEEE 802.1Q encapsulation [4] may be used which provides an explicit user_priority field on top of the basic MAC frame format.
イーサネットパケットに運ばれる明示的なトラフィッククラスまたはuser_priorityフィールドはありません。これは、user_priorityを、一部のデフォルトに応じて、またはパケット内のより高い層プロトコルフィールドにさらに解析することにより、下流のレシーバーまたはスイッチで再生する必要があることを意味します。あるいは、IEEE 802.1qカプセル化[4]を使用して、基本的なMacフレーム形式の上に明示的なuser_priorityフィールドを提供する場合があります。
For the different IP packet encapsulations used over Ethernet/IEEE 802.3, it will be necessary to adjust any admission control calculations according to the framing and padding requirements as shown in Table 1. Here, "ip_len" refers to the length of the IP packet including its headers.
イーサネット/IEEE 802.3で使用されるさまざまなIPパケットカプセルの場合、表1に示すように、フレーミングおよびパディングの要件に従って入学制御計算を調整する必要があります。そのヘッダー。
Table 1: Ethernet encapsulations
表1：イーサネットのカプセル
---------------------------------------------------------------
Encapsulation Framing Overhead IP MTU
bytes/pkt bytes
---------------------------------------------------------------
IP EtherType (ip_len<=46 bytes) 64-ip_len 1500
(1500>=ip_len>=46 bytes) 18 1500
IP EtherType over 802.1D/Q (ip_len<=42) 64-ip_len 1500*
(1500>=ip_len>=42 bytes) 22 1500*
IP EtherType over LLC/SNAP (ip_len<=40) 64-ip_len 1492
(1500>=ip_len>=40 bytes) 24 1492
---------------------------------------------------------------
*Note that the packet length of an Ethernet frame using the IEEE 802.1Q specification exceeds the current IEEE 802.3 maximum packet length values by 4 bytes. The change of maximum MTU size for IEEE 802.1Q frames is being accommodated by IEEE 802.3ac [21].
*IEEE 802.1q仕様を使用したイーサネットフレームのパケット長は、現在のIEEE 802.3の最大パケット長値を4バイトで超えていることに注意してください。IEEE 802.1Qフレームの最大MTUサイズの変更は、IEEE 802.3AC [21]によって収容されています。
The Token Ring standard [6] provides a priority mechanism that can be used to control both the queuing of packets for transmission and the access of packets to the shared media. The priority mechanisms are implemented using bits within the Access Control (AC) and the Frame Control (FC) fields of a LLC frame. The first three bits of the AC field, the Token Priority bits, together with the last three bits of the AC field, the Reservation bits, regulate which stations get access to the ring. The last three bits of the FC field of a LLC frame, the User Priority bits, are obtained from the higher layer in the user_priority parameter when it requests transmission of a packet. This parameter also establishes the Access Priority used by the MAC. The user_priority value is conveyed end-to-end by the User Priority bits in the FC field and is typically preserved through Token Ring bridges of all types. In all cases, 0 is the lowest priority.
トークンリング標準[6]は、送信用のパケットのキューイングと共有メディアへのパケットのアクセスの両方を制御するために使用できる優先メカニズムを提供します。優先メカニズムは、LLCフレームのアクセス制御（AC）およびフレーム制御（FC）フィールド内のビットを使用して実装されます。ACフィールドの最初の3ビット、トークン優先ビットは、ACフィールドの最後の3ビットである予約ビットで、どのステーションがリングにアクセスできるかを調整します。LLCフレームのFCフィールドの最後の3ビットであるユーザー優先ビットは、パケットの送信を要求するときに、user_priorityパラメーターの高層から取得されます。このパラメーターは、Macが使用するアクセスの優先度も確立します。user_priority値は、FCフィールドのユーザー優先ビットによってエンドツーエンドで伝えられ、通常、あらゆるタイプのトークンリングブリッジによって保存されます。すべての場合において、0は最低の優先度です。
Token Ring also uses a concept of Reserved Priority which relates to the value of priority which a station uses to reserve the token for its next transmission on the ring. When a free token is circulating, only a station having an Access Priority greater than or equal to the Reserved Priority in the token will be allowed to seize the token for transmission. Readers are referred to [14] for further discussion of this topic.
トークンリングは、リング上の次の送信のためにトークンを予約するためにステーションが使用する優先度の価値に関連する予約された優先度の概念も使用します。自由なトークンが循環している場合、トークンの予約優先度以上のアクセス優先度を持つステーションのみが、伝送のためにトークンを押収することが許可されます。このトピックのさらなる議論のために、読者は[14]に紹介されます。
A Token Ring station is theoretically capable of separately queuing each of the eight levels of requested user_priority and then transmitting frames in order of priority. A station sets Reservation bits according to the user_priority of frames that are queued for transmission in the highest priority queue. This allows the access mechanism to ensure that the frame with the highest priority throughout the entire ring will be transmitted before any lower priority frame. Annex I to the IEEE 802.5 Token Ring standard recommends that stations send/relay frames as follows.
トークンリングステーションは、要求された8つのレベルの各レベルのそれぞれを個別に排除し、優先順位の順にフレームを送信することができます。ステーションは、最高優先キューで送信するためにキューに掲載されているフレームのuser_priorityに従って予約ビットを設定します。これにより、アクセスメカニズムは、リング全体で最優先のフレームが優先度の低いフレームの前に送信されるようにすることができます。IEEE 802.5トークンリング標準への付録Iは、ステーションが次のようにフレームを送信/リレーフレームを送信することを推奨しています。
Table 2: Recommended use of Token Ring User Priority
表2：トークンリングユーザーの優先順位の推奨使用
-------------------------------------
Application User Priority
-------------------------------------
Non-time-critical data 0
- 1
- 2
- 3
LAN management 4
Time-sensitive data 5
Real-time-critical data 6
MAC frames 7
-------------------------------------
To reduce frame jitter associated with high priority traffic, the annex also recommends that only one frame be transmitted per token and that the maximum information field size be 4399 octets whenever delay sensitive traffic is traversing the ring. Most existing implementations of Token Ring bridges forward all LLC frames with a default access priority of 4. Annex I recommends that bridges forward LLC frames that have a user_priority greater than 4 with a reservation equal to the user_priority (although IEEE 802.1D [3] permits network management override this behavior). The capabilities provided by the Token Ring architecture, such User Priority and Reserved Priority, can provide effective support for Integrated Services flows that require QoS guarantees.
優先度の高いトラフィックに関連するフレームジッターを削減するために、付録は、トークンごとに1つのフレームのみを送信することを推奨し、遅延機密トラフィックがリングを通過する場合はいつでも最大情報フィールドサイズが4399オクテットになることを推奨しています。トークンリングブリッジのほとんどの既存の実装は、デフォルトのアクセスの優先度4のすべてのLLCフレームを前方に進みます。Annex私は、user_priorityに等しい予約を持つ4を超えるユーザー_priorityを持つブリッジフォワードLLCフレームをお勧めします（ただし、IEEE 802.1d [3]が許可されますネットワーク管理はこの動作をオーバーライドします）。トークンリングアーキテクチャによって提供される機能（ユーザーの優先順位と予約済みの優先順位）は、QoS保証を必要とする統合サービスフローに効果的なサポートを提供できます。
For the different IP packet encapsulations used over Token Ring/IEEE 802.5, it will be necessary to adjust any admission control calculations according to the framing requirements as shown in Table 3.
トークンリング/IEEE 802.5で使用されるさまざまなIPパケットカプセルの場合、表3に示すように、フレーミング要件に従って入学制御計算を調整する必要があります。
Table 3: Token Ring encapsulations
表3：トークンリングカプセル
---------------------------------------------------------------
Encapsulation Framing Overhead IP MTU
bytes/pkt bytes
---------------------------------------------------------------
IP EtherType over 802.1D/Q 29 4370*
IP EtherType over LLC/SNAP 25 4370*
---------------------------------------------------------------
*The suggested MTU from RFC 1042 [13] is 4464 bytes but there are issues related to discovering the maximum supported MTU between any two points both within and between Token Ring subnets. The MTU reported here is consistent with the IEEE 802.5 Annex I recommendation.
*RFC 1042 [13]からの提案されたMTUは4464バイトですが、トークンリングサブネットの両方で2つのポイント間で最大サポートされているMTUを発見することに関連する問題があります。ここで報告されたMTUは、IEEE 802.5の付録Iの推奨と一致しています。
The Fiber Distributed Data Interface (FDDI) standard [16] provides a priority mechanism that can be used to control both the queuing of packets for transmission and the access of packets to the shared media. The priority mechanisms are implemented using similar mechanisms to Token Ring described above. The standard also makes provision for "Synchronous" data traffic with strict media access and delay guarantees. This mode of operation is not discussed further here and represents area within the scope of the ISSLL working group that requires further work. In the remainder of this document, for the discussion of QoS mechanisms, FDDI is treated as a 100 Mbps Token Ring technology using a service interface compatible with IEEE 802 networks.
ファイバー分散データインターフェイス（FDDI）標準[16]は、送信用のパケットのキューイングと共有メディアへのパケットのアクセスの両方を制御するために使用できる優先メカニズムを提供します。優先メカニズムは、上記のトークンリングに同様のメカニズムを使用して実装されます。また、この標準は、厳格なメディアアクセスと遅延保証を備えた「同期」データトラフィックを提供します。この動作モードはここではこれ以上説明されておらず、さらなる作業が必要なISSLLワーキンググループの範囲内の領域を表します。このドキュメントの残りの部分では、QoSメカニズムの議論のために、FDDIはIEEE 802ネットワークと互換性のあるサービスインターフェイスを使用して、100 Mbpsトークンリングテクノロジーとして扱われます。
IEEE 802.12 [19] is a standard for a shared 100 Mbps LAN. Data packets are transmitted using either the IEEE 802.3 or IEEE 802.5 frame format. The MAC protocol is called Demand Priority. Its main characteristics with respect to QoS are the support of two service priority levels, normal priority and high priority, and the order of service for each of these. Data packets from all network nodes (end hosts and bridges/switches) are served using a simple round robin algorithm.
IEEE 802.12 [19]は、共有された100 Mbps LANの標準です。データパケットは、IEEE 802.3またはIEEE 802.5フレーム形式のいずれかを使用して送信されます。MACプロトコルは需要優先度と呼ばれます。QoSに関する主な特徴は、2つのサービス優先レベル、通常の優先度と優先度の高いサポートと、これらのそれぞれのサービス順序です。すべてのネットワークノード（エンドホストとブリッジ/スイッチ）のデータパケットは、単純なラウンドロビンアルゴリズムを使用して提供されます。
If the IEEE 802.3 frame format is used for data transmission then the user_priority is encoded in the starting delimiter of the IEEE 802.12 data packet. If the IEEE 802.5 frame format is used then the user_priority is additionally encoded in the YYY bits of the FC field in the IEEE 802.5 packet header (see also Section 4.3). Furthermore, the IEEE 802.1Q encapsulation with its own user_priority field may also be applied in IEEE 802.12 networks. In all cases, switches are able to recover any user_priority supplied by a sender.
IEEE 802.3フレーム形式がデータ送信に使用される場合、user_priorityはIEEE 802.12データパケットの開始デリミタでエンコードされます。IEEE 802.5フレーム形式を使用する場合、IEEE 802.5パケットヘッダーのFCフィールドのYYYビットでユーザー_Priorityがさらにエンコードされます（セクション4.3も参照）。さらに、独自のuser_priorityフィールドを備えたIEEE 802.1qカプセル化も、IEEE 802.12ネットワークに適用される場合があります。すべての場合において、スイッチは送信者から提供されたユーザー_priorityを回復することができます。
The same rules apply for IEEE 802.12 user_priority mapping in a bridge as with other media types. The only additional information is that normal priority is used by default for user_priority values 0 through 4 inclusive, and high priority is used for user_priority levels 5 through 7. This ensures that the default Token Ring user_priority level of 4 for IEEE 802.5 bridges is mapped to normal priority on IEEE 802.12 segments.
他のメディアタイプと同様に、BridgeでのIEEE 802.12ユーザー_Priorityマッピングにも同じルールが適用されます。唯一の追加情報は、user_priority値0〜4の包括的値にデフォルトで使用されることです。これにより、IEEE 802.5ブリッジのデフォルトのトークンリングユーザー_プリオリティレベル4のデフォルトのトークンリングuser_priorityレベルがマッピングされることが保証されます。IEEE 802.12セグメントの通常の優先度。
The medium access in IEEE 802.12 LANs is deterministic. The Demand Priority mechanism ensures that, once the normal priority service has been preempted, all high priority packets have strict priority over packets with normal priority. In the event that a normal priority packet has been waiting at the head of line of a MAC transmit queue for a time period longer than PACKET_PROMOTION (200 - 300 ms) [19], its priority is automatically promoted to high priority. Thus, even normal priority packets have a maximum guaranteed access time to the medium.
IEEE 802.12 LANSの中程度のアクセスは決定論的です。需要優先メカニズムにより、通常の優先度サービスが先制されると、すべての優先度パケットが通常の優先度を持つパケットよりも厳密な優先度があることが保証されます。MACのラインの頭で通常の優先度パケットがPacket_promotion（200-300ミリ秒）よりも長い期間、キューを送信するために待機していた場合、その優先度は自動的に高優先度に昇格されます。したがって、通常の優先度パケットでも、メディアへの最大保証アクセス時間があります。
Integrated Services can be built on top of the IEEE 802.12 medium access mechanism. When combined with admission control and bandwidth enforcement mechanisms, delay guarantees as required for a Guaranteed Service can be provided without any changes to the existing IEEE 802.12 MAC protocol.
統合サービスは、IEEE 802.12メディアアクセスメカニズムの上に構築できます。入学制御および帯域幅の施行メカニズムと組み合わせると、既存のIEEE 802.12 MACプロトコルに変更を加えることなく、保証されたサービスに必要な遅延保証を提供できます。
Since the IEEE 802.12 standard supports the IEEE 802.3 and IEEE 802.5 frame formats, the same framing overhead as reported in Sections 4.2 and 4.3 must be considered in the admission control computations for IEEE 802.12 links.
IEEE 802.12標準はIEEE 802.3およびIEEE 802.5フレーム形式をサポートしているため、IEEE 802.12リンクのアミズミコントロール計算でセクション4.2および4.3で報告された同じフレーミングオーバーヘッドを考慮する必要があります。
This section discusses the requirements and goals which should drive the design of an architecture for supporting Integrated Services over LAN technologies. The requirements refer to functions and features which must be supported, while goals refer to functions and features which are desirable, but are not an absolute necessity. Many of the requirements and goals are driven by the functionality supported by Integrated Services and RSVP.
このセクションでは、LANテクノロジーよりも統合サービスをサポートするためのアーキテクチャの設計を推進する要件と目標について説明します。要件は、サポートする必要がある関数と機能を指し、目標は望ましいが絶対に必要ではない関数と機能を指します。要件と目標の多くは、統合サービスとRSVPによってサポートされる機能によって推進されています。
- Resource Reservation: The mechanism must be capable of reserving resources on a single segment or multiple segments and at bridges/switches connecting them. It must be able to provide reservations for both unicast and multicast sessions. It should be possible to change the level of reservation while the session is in progress.
- リソースの予約：メカニズムは、単一のセグメントまたは複数のセグメント、およびそれらを接続するブリッジ/スイッチでリソースを予約できる必要があります。ユニキャストとマルチキャストの両方のセッションの予約を提供できる必要があります。セッションが進行中に予約レベルを変更することが可能です。
- Admission Control: The mechanism must be able to estimate the level of resources necessary to meet the QoS requested by the session in order to decide whether or not the session can be admitted. For the purpose of management, it is useful to provide the ability to respond to queries about availability of resources. It must be able to make admission control decisions for different types of services such as Guaranteed Service, Controlled Load, etc.
- 入場管理：メカニズムは、セッションを認めることができるかどうかを決定するために、セッションで要求されたQoSを満たすために必要なリソースのレベルを推定できる必要があります。管理の目的のために、リソースの可用性に関するクエリに対応する機能を提供することが有用です。保証されたサービス、制御された負荷など、さまざまな種類のサービスに対して入場管理の決定を下すことができなければなりません。
- Flow Separation and Scheduling: It is necessary to provide a mechanism for traffic flow separation so that real time flows can be given preferential treatment over best effort flows. Packets of real time flows can then be isolated and scheduled according to their service requirements.
- フローの分離とスケジューリング：リアルタイムのフローを最良の努力フローよりも優先処理することができるように、トラフィックフロー分離のメカニズムを提供する必要があります。その後、リアルタイムフローのパケットは、サービス要件に従って分離してスケジュールできます。
- Policing/Shaping: Traffic must be shaped and/or policed by end stations (workstations, routers) to ensure conformance to negotiated traffic parameters. Shaping is the recommended behavior for traffic sources. A router initiating an ISSLL session must have implemented traffic control mechanisms according to the IntServ requirements which would ensure that all flows sent by the router are in conformance. The ISSLL mechanisms at the link layer rely heavily on the correct implementation of policing/shaping mechanisms at higher layers by devices capable of doing so. This is necessary because bridges and switches are not typically capable of maintaining per flow state which would be required to check flows for conformance. Policing is left as an option for bridges and switches, which if implemented, may be used to enforce tighter control over traffic flows. This issue is further discussed in Section 8.
- ポリシング/シェーピング：交渉済みのトラフィックパラメーターへの適合を確保するために、トラフィックはエンドステーション（ワークステーション、ルーター）によって形作られ、ポリシングする必要があります。形状は、交通源に推奨される動作です。ISSLLセッションを開始するルーターは、ルーターによって送信されるすべてのフローが適合していることを保証するINTSERV要件に従ってトラフィック制御メカニズムを実装している必要があります。リンク層のISSLLメカニズムは、そうすることができるデバイスによって、高レイヤーでのポリシング/シェーピングメカニズムの正しい実装に大きく依存しています。これは、橋とスイッチが通常、フロー状態ごとに維持できないため、フローを確認する必要があるため、これが必要です。ポリシングは、橋とスイッチのオプションとして残されています。これは、実装されていれば、交通フローのより厳しい制御を実施するために使用できます。この問題については、セクション8でさらに説明します。
- Soft State: The mechanism must maintain soft state information about the reservations. This means that state information must periodically be refreshed if the reservation is to be maintained; otherwise the state information and corresponding reservations will expire after some pre-specified interval.
- ソフト状態：メカニズムは、予約に関するソフト状態情報を維持する必要があります。これは、予約を維持するためには、状態情報を定期的に更新する必要があることを意味します。それ以外の場合、州の情報と対応する予約は、いくつかの事前に指定された間隔の後に期限切れになります。
- Centralized or Distributed Implementation: In the case of a centralized implementation, a single entity manages the resources of the entire subnet. This approach has the advantage of being easier to deploy since bridges and switches may not need to be upgraded with additional functionality. However, this approach scales poorly with geographical size of the subnet and the number of end stations attached. In a fully distributed implementation, each segment will have a local entity managing its resources. This approach has better scalability than the former. However, it requires that all bridges and switches in the network support new mechanisms. It is also possible to have a semi-distributed implementation where there is more than one entity, each managing the resources of a subset of segments and bridges/switches within the subnet. Ideally, implementation should be flexible; i.e. a centralized approach may be used for small subnets and a distributed approach can be used for larger subnets. Examples of centralized and distributed implementations are discussed in Section 6.
- 集中または分散の実装：集中実装の場合、単一のエンティティがサブネット全体のリソースを管理します。ブリッジとスイッチを追加の機能でアップグレードする必要がない場合があるため、このアプローチには展開が容易になるという利点があります。ただし、このアプローチは、サブネットの地理的サイズと接続されたエンドステーションの数では不十分にスケーリングします。完全に分散した実装では、各セグメントには、リソースを管理するローカルエンティティがあります。このアプローチは、前者よりもスケーラビリティが優れています。ただし、ネットワーク内のすべてのブリッジとスイッチが新しいメカニズムをサポートする必要があります。また、それぞれがサブネット内のセグメントとブリッジ/スイッチのサブセットのリソースを管理する複数のエンティティがあるセミディストリビューされた実装を持つことも可能です。理想的には、実装は柔軟である必要があります。つまり、集中型アプローチを小さなサブネットに使用でき、より大きなサブネットに分散アプローチを使用できます。集中型および分散実装の例については、セクション6で説明します。
- Scalability: The mechanism and protocols should have a low overhead and should scale to the largest receiver groups likely to occur within a single link layer domain.
- スケーラビリティ：メカニズムとプロトコルのオーバーヘッドは低く、単一のリンクレイヤードメイン内で発生する可能性のある最大の受信機グループにスケーリングする必要があります。
- Fault Tolerance and Recovery: The mechanism must be able to function in the presence of failures; i.e. there should not be a single point of failure. For instance, in a centralized implementation, some mechanism must be specified for back-up and recovery in the event of failure.
- フォールトトレランスと回復：メカニズムは、障害の存在下で機能できる必要があります。つまり、単一の障害ポイントがあるべきではありません。たとえば、集中型の実装では、障害が発生した場合にバックアップと回復のために、いくつかのメカニズムを指定する必要があります。
- Interaction with Existing Resource Management Controls: The interaction with existing infrastructure for resource management needs to be specified. For example, FDDI has a resource management mechanism called the "Synchronous Bandwidth Manager". The mechanism must be designed so that it takes advantage of, and specifies the interaction with, existing controls where available.
- 既存のリソース管理コントロールとの相互作用：リソース管理のための既存のインフラストラクチャとの相互作用を指定する必要があります。たとえば、FDDIには「同期帯域幅マネージャー」と呼ばれるリソース管理メカニズムがあります。メカニズムは、利用可能な場合の既存のコントロールを利用し、および相互作用するように設計する必要があります。
- Independence from higher layer protocols: The mechanism should, as far as possible, be independent of higher layer protocols such as RSVP and IP. Independence from RSVP is desirable so that it can interwork with other reservation protocols such as ST2 [10]. Independence from IP is desirable so that it can interwork with other network layer protocols such as IPX, NetBIOS, etc.
- 高層プロトコルからの独立性：メカニズムは、可能な限り、RSVPやIPなどの高層プロトコルとは無関係でなければなりません。RSVPからの独立性が望ましいため、ST2などの他の予約プロトコルと対戦できるようになります[10]。IPからの独立性が望ましいため、IPX、NetBiosなどの他のネットワークレイヤープロトコルとインターワークできます。
- Receiver heterogeneity: this refers to multicast communication where different receivers request different levels of service. For example, in a multicast group with many receivers, it is possible that one of the receivers desires a lower delay bound than the others. A better delay bound may be provided by increasing the amount of resources reserved along the path to that receiver while leaving the reservations for the other receivers unchanged. In its most complex form, receiver heterogeneity implies the ability to simultaneously provide various levels of service as requested by different receivers. In its simplest form, receiver heterogeneity will allow a scenario where some of the receivers use best effort service and those requiring service guarantees make a reservation. Receiver heterogeneity, especially for the reserved/best effort scenario, is a very desirable function. More details on supporting receiver heterogeneity are provided in Section 8.
- レシーバーの不均一性：これは、異なる受信機が異なるレベルのサービスを要求するマルチキャスト通信を指します。たとえば、多くのレシーバーを備えたマルチキャストグループでは、レシーバーの1つが他のレシーバーよりも低い遅延バウンドを望んでいる可能性があります。他のレシーバーの予約を変更せずに、そのレシーバーへのパスに沿って予約されたリソースの量を増やすことで、より良い遅延バウンドが提供される場合があります。最も複雑な形で、受信機の不均一性は、異なる受信機が要求するように、さまざまなレベルのサービスを同時に提供する能力を意味します。最も単純な形式では、レシーバーの不均一性により、受信者の一部が最良の努力サービスを使用し、サービス保証が必要なものが予約を行うシナリオが可能になります。レシーバーの不均一性は、特に予約された/最良のシナリオの場合、非常に望ましい機能です。サポートレシーバーの不均一性の詳細については、セクション8に記載されています。
- Support for different filter styles: It is desirable to provide support for the different filter styles defined by RSVP such as fixed filter, shared explicit and wildcard. Some of the issues with respect to supporting such filter styles in the link layer domain are examined in Section 8.
- さまざまなフィルタースタイルのサポート：固定フィルター、共有明示的、ワイルドカードなど、RSVPによって定義されたさまざまなフィルタースタイルをサポートすることが望ましいです。リンクレイヤードメインのこのようなフィルタースタイルのサポートに関する問題のいくつかを、セクション8で検討します。
- Path Selection: In source routed LAN technologies such as Token Ring/IEEE 802.5, it may be useful for the mechanism to incorporate the function of path selection. Using an appropriate path selection mechanism may optimize utilization of network resources.
- パス選択：トークンリング/IEEE 802.5などのソースルーティングLANテクノロジーでは、メカニズムがパス選択の機能を組み込むのに役立つ場合があります。適切なパス選択メカニズムを使用すると、ネットワークリソースの利用を最適化する場合があります。
This document describes service mappings onto existing IEEE and ANSI defined standard MAC layers and uses standard MAC layer services as in IEEE 802.1 bridging. It does not attempt to make use of or describe the capabilities of other proprietary or standard MAC layer protocols although it should be noted that published work regarding MAC layers suitable for QoS mappings exists. These are outside the scope of the ISSLL working group charter.
このドキュメントでは、既存のIEEEへのサービスマッピングとANSIが標準MACレイヤーを定義し、IEEE 802.1ブリッジングのように標準のMacレイヤーサービスを使用しています。QoSマッピングに適したMac層に関する公開された作業が存在することに注意する必要がありますが、他の独自または標準のMacレイヤープロトコルの機能を使用したり、説明したりしようとはしません。これらは、ISSLLワーキンググループチャーターの範囲外です。
This framework assumes that typical subnetworks that are concerned about QoS will be "switch rich"; i.e. most communication between end stations using integrated services support is expected to pass through at least one switch. The mechanisms and protocols described will be trivially extensible to communicating systems on the same shared medium, but it is important not to allow problem generalization which may complicate the targeted practical application to switch rich LAN topologies. There have also been developments in the area of MAC enhancements to ensure delay deterministic access on network links e.g. IEEE 802.12 [19] and also proprietary schemes.
このフレームワークは、QoSを懸念する典型的なサブネットワークが「リッチ」になることを前提としています。つまり、統合サービスサポートを使用したエンドステーション間のほとんどの通信は、少なくとも1つのスイッチを通過すると予想されます。記述されているメカニズムとプロトコルは、同じ共有媒体上の通信システムに簡単に拡張可能になりますが、ターゲットを絞った実用アプリケーションを複雑にしてリッチLANトポロジーを切り替える可能性のある問題の一般化を許可しないことが重要です。また、ネットワークリンクでの決定論的アクセスの遅延を確保するために、MAC強化の分野での開発もありました。IEEE 802.12 [19]および独自のスキーム。
Although we illustrate most examples for this model using RSVP as the upper layer QoS signaling protocol, there are actually no real dependencies on this protocol. RSVP could be replaced by some other dynamic protocol, or the requests could be made by network management or other policy entities. The SBM signaling protocol [14], which is based upon RSVP, is designed to work seamlessly in the architecture described in this memo.
このモデルのほとんどの例は、RSVPを上層QoSシグナル伝達プロトコルとして使用していることを示していますが、実際にはこのプロトコルに実際の依存関係はありません。RSVPは、他の動的プロトコルに置き換えられるか、ネットワーク管理または他のポリシーエンティティによってリクエストを行うことができます。RSVPに基づくSBMシグナル伝達プロトコル[14]は、このメモで説明されているアーキテクチャでシームレスに動作するように設計されています。
There may be a heterogeneous mix of switches with different capabilities, all compliant with IEEE 802.1D [2,3], but implementing varied queuing and forwarding mechanisms ranging from simple systems with two queues per port and static priority scheduling, to more complex systems with multiple queues using WFQ or other algorithms.
さまざまな機能を備えたスイッチの不均一なミックスがあり、すべてIEEE 802.1d [2,3]に準拠していますが、ポートあたり2つのキューと静的な優先度スケジューリングを備えた単純なシステムから、より複雑なシステムまでのさまざまなキューイングと転送メカニズムを実装しています。WFQまたはその他のアルゴリズムを使用した複数のキュー。
The problem is decomposed into smaller independent parts which may lead to sub-optimal use of the network resources but we contend that such benefits are often equivalent to very small improvement in network efficiency in a LAN environment. Therefore, it is a goal that the switches in a network operate using a much simpler set of information than the RSVP engine in a router. In particular, it is assumed that such switches do not need to implement per flow queuing and policing (although they are not precluded from doing so).
この問題は、ネットワークリソースの最適な使用につながる可能性のあるより小さな独立した部分に分解されますが、そのような利点はLAN環境のネットワーク効率の非常に小さな改善に相当することが多いと主張します。したがって、ネットワーク内のスイッチは、ルーターのRSVPエンジンよりもはるかにシンプルな情報セットを使用して動作することを目標です。特に、そのようなスイッチは、フローキューイングとポリシングごとに実装する必要がないと想定されています（ただし、そうすることを妨げられていませんが）。
A fundamental assumption of the IntServ model is that flows are isolated from each other throughout their transit across a network. Intermediate queuing nodes are expected to shape or police the traffic to ensure conformance to the negotiated traffic flow specification. In the architecture proposed here for mapping to Layer 2, we diverge from that assumption in the interest of simplicity. The policing/shaping functions are assumed to be implemented in end stations. In some LAN environments, it is reasonable to assume that end stations are trusted to adhere to their negotiated contracts at the inputs to the network, and that we can afford to over-allocate resources during admission control to compensate for the inevitable packet jitter/bunching introduced by the switched network itself. This divergence has some implications on the types of receiver heterogeneity that can be supported and the statistical multiplexing gains that may be exploited, especially for Controlled Load flows. This is discussed in Section 8.7 of this document.
INTSERVモデルの基本的な仮定は、ネットワークを横切る通過中、フローが互いに分離されることです。中間キューイングノードは、交渉された交通フロー仕様に適合するために、トラフィックを形作るか、警察することが期待されます。ここで提案されているアーキテクチャでは、レイヤー2へのマッピングのために、単純さのためにその仮定から分岐します。ポリシング/シェーピング関数は、エンドステーションに実装されていると想定されています。一部のLAN環境では、エンドステーションがネットワークへの入力で交渉された契約を遵守すると信頼されていると想定するのは合理的です。また、避けられないパケットジッター/バンチングを補償するために、アジズミコントロール中にリソースを過剰に割り当てる余裕がありますスイッチネットワーク自体によって導入されました。この発散は、サポートできるレシーバーの不均一性の種類と、特に制御された負荷フローのために悪用される可能性のある統計的多重化ゲインにいくつかの意味を持っています。これについては、このドキュメントのセクション8.7で説明します。
The functional requirements described in Section 5 will be performed by an entity which we refer to as the Bandwidth Manager (BM). The BM is responsible for providing mechanisms for an application or higher layer protocol to request QoS from the network. For architectural purposes, the BM consists of the following components.
セクション5で説明されている機能要件は、帯域幅マネージャー（BM）と呼ばれるエンティティによって実行されます。BMは、ネットワークからQOを要求するためのアプリケーションまたは高層プロトコルのメカニズムを提供する責任があります。建築目的のために、BMは次のコンポーネントで構成されています。
The Requester Module (RM) resides in every end station in the subnet. One of its functions is to provide an interface between applications or higher layer protocols such as RSVP, ST2, SNMP, etc. and the BM. An application can invoke the various functions of the BM by using the primitives for communication with the RM and providing it with the appropriate parameters. To initiate a reservation, in the link layer domain, the following parameters must be passed to the RM: the service desired (Guaranteed Service or Controlled Load), the traffic descriptors contained in the TSpec, and an RSpec specifying the amount of resources to be reserved [9]. More information on these parameters may be found in the relevant Integrated Services documents [6,7,8,9]. When RSVP is used for signaling at the network layer, this information is available and needs to be extracted from the RSVP PATH and RSVP RESV messages (See [5] for details). In addition to these parameters, the network layer addresses of the end points must be specified. The RM must then translate the network layer addresses to link layer addresses and convert the request into an appropriate format which is understood by other components of the BM responsible admission control. The RM is also responsible for returning the status of requests processed by the BM to the invoking application or higher layer protocol.
リクエスターモジュール（RM）は、サブネットのすべてのエンドステーションに存在します。その機能の1つは、アプリケーションまたはRSVP、ST2、SNMPなど、BMなどの高層プロトコル間のインターフェイスを提供することです。アプリケーションは、RMとの通信にプリミティブを使用し、適切なパラメーターを提供することにより、BMのさまざまな機能を呼び出すことができます。リンクレイヤードメインで予約を開始するには、次のパラメーターをRMに渡す必要があります：希望するサービス（保証されたサービスまたは制御負荷）、TSPECに含まれるトラフィック記述子、および予約済み[9]。これらのパラメーターの詳細については、関連する統合サービスドキュメント[6,7,8,9]に記載されています。RSVPがネットワークレイヤーでのシグナリングに使用される場合、この情報は利用可能であり、RSVPパスとRSVP RESVメッセージから抽出する必要があります（詳細については[5]を参照）。これらのパラメーターに加えて、エンドポイントのネットワークレイヤーアドレスを指定する必要があります。RMは、ネットワークレイヤーアドレスをリンクレイヤーアドレスに翻訳し、リクエストを適切な形式に変換する必要があります。これは、BMの責任ある入場制御の他のコンポーネントが理解するものです。RMは、BMによって処理されたリクエストのステータスを呼び出しアプリケーションまたは高層プロトコルに返すことも責任を負います。
The Bandwidth Allocator (BA) is responsible for performing admission control and maintaining state about the allocation of resources in the subnet. An end station can request various services, e.g. bandwidth reservation, modification of an existing reservation, queries about resource availability, etc. These requests are processed by the BA. The communication between the end station and the BA takes place through the RM. The location of the BA will depend largely on the implementation method. In a centralized implementation, the BA may reside on a single station in the subnet. In a distributed implementation, the functions of the BA may be distributed in all the end stations and bridges/switches as necessary. The BA is also responsible for deciding how to label flows, e.g. based on the admission control decision, the BA may indicate to the RM that packets belonging to a particular flow be tagged with some priority value which maps to the appropriate traffic class.
帯域幅アロケーター（BA）は、サブネットのリソースの割り当てに関する入場制御を実行し、状態を維持する責任があります。エンドステーションはさまざまなサービスを要求できます。帯域幅の予約、既存の予約の変更、リソースの可用性に関するクエリなど。これらの要求はBAによって処理されます。エンドステーションとBAの間の通信は、RMを介して行われます。BAの位置は、実装方法に大きく依存します。集中型の実装では、BAはサブネットの単一のステーションに居住する場合があります。分散型の実装では、BAの機能は、必要に応じてすべてのエンドステーションとブリッジ/スイッチに配布される場合があります。BAは、フローにラベルを付ける方法を決定する責任もあります。入場管理の決定に基づいて、BAは、特定のフローに属するパケットに適切なトラフィッククラスにマップする優先順位値でタグ付けされることをRMに示す場合があります。
The protocols for communication between the various components of the BM system must be specified. These include the following:
BMシステムのさまざまなコンポーネント間の通信のプロトコルを指定する必要があります。これらには次のものが含まれます。
- Communication between the higher layer protocols and the RM: The BM must define primitives for the application to initiate reservations, query the BA about available resources, change change or delete reservations, etc. These primitives could be implemented as an API for an application to invoke functions of the BM via the RM.
- 高層プロトコルとRMの間の通信：BMは、予約を開始するためのアプリケーションのプリミティブを定義し、利用可能なリソースについてBAを照会し、変更または削除を削除する必要があります。これらのプリミティブは、呼び出すアプリケーションのAPIとして実装できます。RMを介したBMの関数。
- Communication between the RM and the BA: A signaling mechanism must be defined for the communication between the RM and the BA. This protocol will specify the messages which must be exchanged between the RM and the BA in order to service various requests by the higher layer entity.
- RMとBAの間の通信：RMとBAの間の通信のために、シグナル伝達メカニズムを定義する必要があります。このプロトコルでは、高層エンティティによるさまざまな要求を提供するために、RMとBAの間で交換する必要があるメッセージを指定します。
- Communication between peer BAs: If there is more than one BA in the subnet, a means must be specified for inter-BA communication. Specifically, the BAs must be able to decide among themselves about which BA would be responsible for which segments and bridges or switches. Further, if a request is made for resource reservation along the domain of multiple BAs, the BAs must be able to handle such a scenario correctly. Inter-BA communication will also be responsible for back-up and recovery in the event of failure.
- PEER BAS間の通信：サブネットに複数のBAがある場合、BA間通信には手段を指定する必要があります。具体的には、BASは、どのBAがどのセグメントと橋またはスイッチを担当するかを自分自身の間で決定できる必要があります。さらに、複数のBASのドメインに沿ったリソース予約の要求が行われた場合、BASはそのようなシナリオを正しく処理できる必要があります。また、BA間コミュニケーションは、障害が発生した場合のバックアップと回復についても担当します。
Example scenarios are provided showing the location of the components of the bandwidth manager in centralized and fully distributed implementations. Note that in either case, the RM must be present in all end stations that need to make reservations. Essentially, centralized or distributed refers to the implementation of the BA, the component responsible for resource reservation and admission control. In the figures below, "App" refers to the application making use of the BM. It could either be a user application, or a higher layer protocol process such as RSVP.
サンプルシナリオは、集中型および完全に分散された実装における帯域幅マネージャーのコンポーネントの位置を示すことを示しています。どちらの場合でも、RMは予約する必要があるすべてのエンドステーションに存在する必要があることに注意してください。基本的に、集中または分散とは、リソースの予約と入場制御を担当するコンポーネントであるBAの実装を指します。以下の図では、「APP」とは、BMを使用するアプリケーションを指します。これは、ユーザーアプリケーション、またはRSVPなどの高層プロトコルプロセスのいずれかである可能性があります。
+---------+
.-->| BA |<--.
/ +---------+ \
/ .-->| Layer 2 |<--. \
/ / +---------+ \ \
/ / \ \
/ / \ \
+---------+ / / \ \ +---------+
| App |<----- /-/---------------------------\-\----->| App |
+---------+ / / \ \ +---------+
| RM |<----. / \ .--->| RM |
+---------+ / +---------+ +---------+ \ +---------+
| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |
+---------+ +---------+ +---------+ +---------+
RSVP Host/ Intermediate Intermediate RSVP Host/ Router Bridge/Switch Bridge/Switch Router
RSVPホスト/中間中級RSVPホスト/ルーターブリッジ/スイッチブリッジ/スイッチルーター
Figure 1: Bandwidth Manager with centralized Bandwidth Allocator
図1：集中帯域幅アロケーターを備えた帯域幅マネージャー
Figure 1 shows a centralized implementation where a single BA is responsible for admission control decisions for the entire subnet. Every end station contains a RM. Intermediate bridges and switches in the network need not have any functions of the BM since they will not be actively participating in admission control. The RM at the end station requesting a reservation initiates communication with its BA. For larger subnets, a single BA may not be able to handle the reservations for the entire subnet. In that case it would be necessary to deploy multiple BAs, each managing the resources of a non-overlapping subset of segments. In a centralized implementation, the BA must have some knowledge of the Layer 2 topology of the subnet e.g., link layer spanning tree information, in order to be able to reserve resources on appropriate segments. Without this topology information, the BM would have to reserve resources on all segments for all flows which, in a switched network, would lead to very inefficient utilization of resources.
図1は、単一のBAがサブネット全体の入場管理の決定に責任を負う集中型の実装を示しています。すべてのエンドステーションにはRMが含まれています。ネットワーク内の中間ブリッジとスイッチは、Andimant Controlに積極的に参加しないため、BMの機能は必要ありません。予約を要求するエンドステーションのRMは、BAとのコミュニケーションを開始します。大規模なサブネットの場合、単一のBAがサブネット全体の予約を処理できない場合があります。その場合、それぞれがセグメントの非重複サブセットのリソースを管理する複数のBASを展開する必要があります。集中型の実装では、BAは、適切なセグメントのリソースを予約できるように、サブネットのレイヤー2トポロジなど、リンクレイヤースパンツリー情報の知識を持っている必要があります。このトポロジ情報がなければ、BMはすべてのフローのすべてのセグメントのリソースを予約する必要があり、スイッチネットワークではリソースの非常に非効率的な利用につながります。
+---------+ +---------+
| App |<-------------------------------------------->| App |
+---------+ +---------+ +---------+ +---------+
| RM/BA |<------>| BA |<------>| BA |<------>| RM/BA |
+---------+ +---------+ +---------+ +---------+
| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |
+---------+ +---------+ +---------+ +---------+
RSVP Host/ Intermediate Intermediate RSVP Host/ Router Bridge/Switch Bridge/Switch Router
RSVPホスト/中間中級RSVPホスト/ルーターブリッジ/スイッチブリッジ/スイッチルーター
Figure 2: Bandwidth Manager with fully distributed Bandwidth Allocator
図2：完全に分散した帯域幅アロケーターを備えた帯域幅マネージャー
Figure 2 depicts the scenario of a fully distributed bandwidth manager. In this case, all devices in the subnet have BM functionality. All the end hosts are still required to have a RM. In addition, all stations actively participate in admission control. With this approach, each BA would need only local topology information since it is responsible for the resources on segments that are directly connected to it. This local topology information, such as a list of ports active on the spanning tree and which unicast addresses are reachable from which ports, is readily available in today's switches. Note that in the figures above, the arrows between peer layers are used to indicate logical connectivity.
図2は、完全に分散された帯域幅マネージャーのシナリオを示しています。この場合、サブネット内のすべてのデバイスにはBM機能があります。すべてのエンドホストは、RMを持つためにまだ必要です。さらに、すべてのステーションが積極的に入学管理に参加しています。このアプローチを使用すると、各BAは、直接接続されているセグメントのリソースに責任があるため、ローカルトポロジー情報のみが必要です。スパニングツリーでアクティブなポートのリストや、どのポートからどのポートから到達できるかなどのこのローカルトポロジ情報は、今日のスイッチで容易に利用できます。上記の図では、ピア層間の矢印を使用して論理的な接続性を示すことに注意してください。
In this section we describe how the model above fits with the existing IETF Integrated Services model of IP hosts and routers. First, we describe Layer 3 host and router implementations. Next, we describe how the model is applied in Layer 2 switches. Throughout we indicate any differences between centralized and distributed implementations. Occasional references are made to terminology from the Subnet Bandwidth Manager specification [14].
このセクションでは、上記のモデルがIPホストとルーターの既存のIETF統合サービスモデルにどのように適合するかについて説明します。まず、レイヤー3ホストとルーターの実装について説明します。次に、モデルがレイヤー2スイッチでどのように適用されるかについて説明します。全体を通して、集中型と分散の実装の違いを示します。サブネット帯域幅マネージャーの仕様[14]からの用語について、時折参照が行われます。
We assume the same client model as IntServ and RSVP where we use the term "client" to mean the entity handling QoS in the Layer 3 device at each end of a Layer 2 Domain. In this model, the sending client is responsible for local admission control and packet scheduling onto its link in accordance with the negotiated service. As with the IntServ model, this involves per flow scheduling with possible traffic shaping/policing in every such originating node.
「クライアント」という用語を使用して、レイヤー2ドメインの両端にあるレイヤー3デバイスのQOを処理するエンティティを意味する場合、intservおよびrsvpと同じクライアントモデルを想定しています。このモデルでは、送信クライアントは、ネゴシエートされたサービスに従って、ローカルの入場制御とリンクへのパケットスケジューリングを担当しています。IntServモデルと同様に、これには、そのようなすべての発信ノードでトラフィックの形成/ポリシングの可能性を備えたフロースケジューリングごとが含まれます。
For now, we assume that the client runs an RSVP process which presents a session establishment interface to applications, provides signaling over the network, programs a scheduler and classifier in the driver, and interfaces to a policy control module. In particular, RSVP also interfaces to a local admission control module which is the focus of this section.
今のところ、クライアントは、アプリケーションへのセッション確立インターフェイスを提示するRSVPプロセスを実行し、ネットワーク上のシグナリングを提供し、ドライバーのスケジューラと分類器をプログラムし、ポリシーコントロールモジュールにインターフェイスを提供すると想定しています。特に、RSVPは、このセクションの焦点であるローカルアミズニーコントロールモジュールにもインターフェイスします。
The following figure, reproduced from the RSVP specification, depicts the RSVP process in sending hosts.
RSVP仕様から再現された次の図は、ホストの送信におけるRSVPプロセスを示しています。
+-----------------------------+
| +-------+ +-------+ | RSVP
| |Appli- | | RSVP <------------------->
| | cation<--> | |
| | | |process| +-----+|
| +-+-----+ | +->Polcy||
| | +--+--+-+ |Cntrl||
| |data | | +-----+|
|===|===========|==|==========|
| | +--------+ | +-----+|
| | | | +--->Admis||
| +-V--V-+ +---V----+ |Cntrl||
| |Class-| | Packet | +-----+|
| | ifier|==>Schedulr|===================>
| +------+ +--------+ | data
+-----------------------------+
Figure 3: RSVP in Sending Hosts
図3：送信ホストのRSVP
The local admission control entity within a client is responsible for mapping Layer 3 session establishment requests into Layer 2 semantics.
クライアント内のローカルアドミズント管理エンティティは、レイヤー3セッションの確立要求をレイヤー2セマンティクスにマッピングする責任があります。
The upper layer entity makes a request, in generalized terms to ISSLL of the form:
上層層エンティティは、フォームのISSLLに一般化された用語で要求を行います。
"May I reserve for traffic with <traffic characteristic> with
<performance requirements> from <here> to <there> and how should I
label it?"
where
ただし
<traffic characteristic> = Sender Tspec (e.g. bandwidth, burstiness,
MTU)
<performance requirements> = FlowSpec (e.g. latency, jitter bounds)
<here> = IP address(es)
<there> = IP address(es) - may be multicast
The ISSLL functionality in the sender is illustrated in Figure 4.
送信者のISSLL機能を図4に示します。
The functions of the Requester Module may be summarized as follows:
リクエスターモジュールの関数は、次のように要約できます。
- Maps the endpoints of the conversation to Layer 2 addresses in the LAN, so that the client can determine what traffic is going where. This function probably makes reference to the ARP protocol cache for unicast or performs an algorithmic mapping for multicast destinations.
- 会話のエンドポイントをLAN内の2つのアドレスをレイヤーにマッピングして、クライアントがどこに進んでいるのかを決定できるようにします。この関数は、おそらくユニキャスト用のARPプロトコルキャッシュを参照するか、マルチキャスト宛先のアルゴリズムマッピングを実行します。
- Communicates with any local Bandwidth Allocator module for local admission control decisions.
- ローカルの帯域幅アロケーターモジュールと通信して、ローカルの入学管理の決定を決定します。
- Formats a SBM request to the network with the mapped addresses and flow/filter specs.
- マッピングされたアドレスとフロー/フィルター仕様を使用して、SBM要求をネットワークにフォーマットします。
- Receives a response from the network and reports the admission control decision to the higher layer entity, along with any negotiated modifications to the session parameters.
- ネットワークから応答を受け取り、セッションパラメーターの交渉された変更とともに、上級レイヤーエンティティへの入場管理決定を報告します。
- Saves any returned user_priority to be associated with this session in a "802 header" table. This will be used when constructing the Layer 2 headers for future data packets belonging to this session. This table might, for example, be indexed by the RSVP flow identifier.
- 「802ヘッダー」テーブルで、このセッションに関連付けられる返されたuser_priorityを保存します。これは、このセッションに属する将来のデータパケットのレイヤー2ヘッダーを構築するときに使用されます。このテーブルは、たとえば、RSVPフロー識別子によってインデックス付けされる場合があります。
from IP from RSVP
+----|------------|------------+
| +--V----+ +---V---+ |
| | Addr <---> | | SBM signaling
| |mapping| |Request|<----------------------->
| +---+---+ |Module | |
| | | | |
| +---+---+ | | |
| | 802 <---> | |
| | header| +-+-+-+-+ |
| +--+----+ / | | |
| | / | | +-----+ |
| | +-----+ | +->|Band-| |
| | | | |width| |
| +--V-V-+ +-----V--+ |Alloc| |
| |Class-| | Packet | +-----+ |
| | ifier|==>Schedulr|=========================>
| +------+ +--------+ | data
+------------------------------+
Figure 4: ISSLL in a Sending End Station
図4：送信エンドステーションのISSLL
The Bandwidth Allocator (BA) component is only present when a distributed BA model is implemented. When present, its function is basically to apply local admission control for the outgoing link bandwidth and driver's queuing resources.
帯域幅アロケーター（BA）コンポーネントは、分散BAモデルが実装されている場合にのみ存在します。存在する場合、その機能は基本的に、発信リンク帯域幅とドライバーのキューイングリソースにローカル入場制御を適用することです。
The ISSLL functionality in the receiver is simpler and is illustrated in Figure 5.
受信機のISSLL機能はより単純で、図5に示されています。
The functions of the Requester Module may be summarized as follows:
リクエスターモジュールの関数は、次のように要約できます。
- Handles any received SBM protocol indications.
- 受信したSBMプロトコル表示を処理します。
- Communicates with any local BA for local admission control decisions.
- ローカルBAとコミュニケーションをとり、ローカルの入学管理の決定を決定します。
- Passes indications up to RSVP if OK.
- OKの場合、RSVPまでの適応症を渡します。
- Accepts confirmations from RSVP and relays them back via SBM signaling towards the requester.
- RSVPからの確認を受け入れ、SBMシグナル伝達を介してリクエスターに向かってリレーします。
to RSVP to IP
^ ^
+----|------------|------+
| +--+----+ | |
SBM signaling | |Request| +---+---+ |
<-------------> |Module | | Strip | |
| +--+---++ |802 hdr| |
| | \ +---^---+ |
| +--v----+\ | |
| | Band- | \ | |
| | width| \ | |
| | Alloc | . | |
| +-------+ | | |
| +------+ +v---+----+ |
data | |Class-| | Packet | |
<==============>| ifier|==>|Scheduler| |
| +------+ +---------+ |
+------------------------+
Figure 5: ISSLL in a Receiving End Station
図5：受信エンドステーションのISSLL
- May program a receive classifier and scheduler, if used, to identify traffic classes of received packets and accord them appropriate treatment e.g., reservation of buffers for particular traffic classes.
- 受信された分類器とスケジューラーをプログラムすることができます。使用すると、受信したパケットのトラフィッククラスを特定し、特定のトラフィッククラスのバッファーの予約など、適切な処理を承認します。
- Programs the receiver to strip away link layer header information from received packets.
- 受信したパケットからリンクレイヤーヘッダー情報を取り除くために受信機をプログラムします。
The Bandwidth Allocator, present only in a distributed implementation applies local admission control to see if a request can be supported with appropriate local receive resources.
分散実装にのみ存在する帯域幅のアロケーターは、ローカルの入場制御を適用して、適切なローカル受信リソースでリクエストをサポートできるかどうかを確認します。
Where a centralized Bandwidth Allocator model is implemented, switches do not take part in the admission control process. Admission control is implemented by a centralized BA, e.g., a "Subnet Bandwidth Manager" (SBM) as described in [14]. This centralized BA may actually be co-located with a switch but its functions would not necessarily then be closely tied with the switch's forwarding functions as is the case with the distributed BA described below.
集中帯域幅アロケーターモデルが実装されている場合、スイッチは入場制御プロセスに参加しません。入学制御は、[14]で説明されているように、「サブネット帯域幅マネージャー」（SBM）など、集中型BAによって実装されます。この集中化されたBAは、実際にはスイッチと共同で配置される可能性がありますが、その機能は、以下に説明する分布BAの場合のように、必ずしもスイッチの転送機能と密接に結びついているわけではありません。
The model of Layer 2 switch behavior described here uses the terminology of the SBM protocol as an example of an admission control protocol. The model is equally applicable when other mechanisms, e.g. static configuration or network management, are in use for admission control. We define the following entities within the switch:
ここで説明するレイヤー2スイッチの動作のモデルは、Andiming Controlプロトコルの例としてSBMプロトコルの用語を使用しています。モデルは、他のメカニズム、例えば静的構成またはネットワーク管理は、入場制御に使用されています。スイッチ内の次のエンティティを定義します。
- Local Admission Control Module: One of these on each port accounts for the available bandwidth on the link attached to that port. For half duplex links, this involves taking account of the resources allocated to both transmit and receive flows. For full duplex links, the input port accountant's task is trivial.
- ローカルアドミズ系コントロールモジュール：各ポートのこれらの1つは、そのポートに添付されたリンク上の利用可能な帯域幅を説明します。半分二重リンクの場合、これには、送信および受信フローの両方に割り当てられたリソースを考慮することが含まれます。完全なデュプレックスリンクの場合、入力ポート会計士のタスクは些細なことです。
- Input SBM Module: One instance on each port performs the "network" side of the signaling protocol for peering with clients or other switches. It also holds knowledge about the mappings of IntServ classes to user_priority.
- 入力SBMモジュール：各ポートの1つのインスタンスは、クライアントまたは他のスイッチとのピアリング用のシグナリングプロトコルの「ネットワーク」側を実行します。また、intservクラスのマッピングに関する知識をuser_priorityに保持しています。
- SBM Propagation Module: Relays requests that have passed admission control at the input port to the relevant output ports' SBM modules. This will require access to the switch's forwarding table (Layer-2 "routing table" cf. RSVP model) and port spanning tree state.
- SBM伝播モジュール：入力ポートで入力ポートに渡されたリクレイリクエストは、関連する出力ポートのSBMモジュールになります。これには、スイッチの転送テーブル（レイヤー2 "ルーティングテーブル" cf. rsvpモデル）とポートスパニングツリー状態へのアクセスが必要です。
- Output SBM Module: Forwards requests to the next Layer 2 or Layer 3 hop.
- 出力SBMモジュール：次のレイヤー2またはレイヤー3ホップにリクエストを転送します。
- Classifier, Queue and Scheduler Module: The functions of this module are basically as described by the Forwarding Process of IEEE 802.1D (see Section 3.7 of [3]). The Classifier module identifies the relevant QoS information from incoming packets and uses this, together with the normal bridge forwarding database, to decide at which output port and traffic class to enqueue the packet. Different types of switches will use different techniques for flow identification (see Section 8.1). In IEEE 802.1D switches this information is the regenerated user_priority parameter which has already been decoded by the receiving MAC service and potentially remapped by the forwarding process (see Section 3.7.3 of [3]). This does not preclude more sophisticated classification rules such as the classification of individual IntServ flows. The Queue and Scheduler implement the output queues for ports and provide the algorithm for servicing the queues for transmission onto the output link in order to provide the promised IntServ service. Switches will implement one or more output queues per port and all will implement at least a basic static priority dequeuing algorithm as their default, in accordance with IEEE 802.1D.
- 分類器、キュー、スケジューラモジュール：このモジュールの機能は、基本的にIEEE 802.1dの転送プロセスで説明されているとおりです（[3]のセクション3.7を参照）。分類子モジュールは、着信パケットから関連するQoS情報を識別し、これを通常のブリッジ転送データベースとともに使用して、パケットをエンキューする出力ポートとトラフィッククラスを決定します。さまざまな種類のスイッチは、フロー識別に異なる手法を使用します（セクション8.1を参照）。IEEE 802.1Dのスイッチでは、この情報は再生されたuser_priorityパラメーターであり、受信Macサービスによってすでにデコードされており、転送プロセスによって再マッピングされている可能性があります（[3]のセクション3.7.3を参照）。これは、個々のINTSERVフローの分類など、より洗練された分類ルールを排除するものではありません。キューとスケジューラは、ポートの出力キューを実装し、約束されたINTSERVサービスを提供するために、出力リンクに送信するためのキューを保守するためのアルゴリズムを提供します。スイッチはポートごとに1つ以上の出力キューを実装し、すべてがIEEE 802.1dに従って、デフォルトとして少なくとも基本的な静的優先度のデキューイングアルゴリズムを実装します。
- Ingress Traffic Class Mapping and Policing Module: Its functions are as described in IEEE 802.1D Section 3.7. This optional module may police the data within traffic classes for conformance to the negotiated parameters, and may discard packets or re-map the user_priority. The default behavior is to pass things through unchanged.
- イングレストラフィッククラスのマッピングとポリシングモジュール：その機能は、IEEE 802.1dセクション3.7で説明されています。このオプションのモジュールは、交渉されたパラメーターに準拠するためにトラフィッククラス内のデータを警察し、パケットを破棄したり、user_priorityを再マップしたりする場合があります。デフォルトの動作は、変更されていないことを通過することです。
- Egress Traffic Class Mapping Module: Its functions are as described in IEEE 802.1D Section 3.7. This optional module may perform re-mapping of traffic classes on a per output port basis. The default behavior is to pass things through unchanged.
- 出力トラフィッククラスマッピングモジュール：ITS関数は、IEEE 802.1dセクション3.7で説明されているとおりです。このオプションのモジュールは、出力ポートごとにトラフィッククラスの再マッピングを実行できます。デフォルトの動作は、変更されていないことを通過することです。
Figure 6 shows all of the modules in an ISSLL enabled switch. The ISSLL model is a superset of the IEEE 802.1D bridge model.
図6は、ISSLL対応スイッチのすべてのモジュールを示しています。ISSLLモデルは、IEEE 802.1Dブリッジモデルのスーパーセットです。
+-------------------------------+
SBM signaling | +-----+ +------+ +------+ | SBM signaling
<------------------>| IN |<->| SBM |<->| OUT |<---------------->
| | SBM | | prop.| | SBM | |
| +-++--+ +---^--+ /----+-+ |
| / | | / | |
______________| / | | | | +-------------+
| \ /+--V--+ | | +--V--+ / |
| \ ____/ |Local| | | |Local| / |
| \ / |Admis| | | |Admis| / |
| \/ |Cntrl| | | |Cntrl| / |
| +-----V+\ +-----+ | | +-----+ /+-----+ |
| |traff | \ +---+--+ +V-------+ / |egrss| |
| |class | \ |Filter| |Queue & | / |traff| |
| |map & |=====|==========>|Data- |=| Packet |=|===>|class| |
| |police| | | base| |Schedule| | |map | |
| +------+ | +------+ +--------+ | +-+---+ |
+----^---------+-------------------------------+------|------+
data in | |data out
========+ +========>
Figure 6: ISSLL in a Switch
図6：スイッチ内のISSLL
On receipt of an admission control request, a switch performs the following actions, again using SBM as an example. The behavior is different depending on whether the "Designated SBM" for this segment is within this switch or not. See [14] for a more detailed specification of the DSBM/SBM actions.
入場制御要求を受け取ったとき、スイッチは次のアクションを実行し、再びSBMを例として使用します。動作は、このセグメントの「指定されたSBM」がこのスイッチ内にあるかどうかによって異なります。DSBM/SBMアクションのより詳細な仕様については、[14]を参照してください。
- If the ingress SBM is the "Designated SBM" for this link, it either translates any received user_priority or selects a Layer 2 traffic class which appears compatible with the request and whose use does not violate any administrative policies in force. In effect, it matches the requested service with the available traffic classes and chooses the "best" one. It ensures that, if this reservation is successful, the value of user_priority corresponding to that traffic class is passed back to the client.
- Ingress SBMがこのリンクの「指定されたSBM」である場合、受信したuser_priorityを翻訳するか、リクエストと互換性があり、その使用が有効な管理ポリシーに違反しないレイヤー2トラフィッククラスを選択します。実際には、要求されたサービスを利用可能なトラフィッククラスと一致させ、「最高の」クラスを選択します。この予約が成功した場合、そのトラフィッククラスに対応するuser_priorityの価値がクライアントに渡されることが保証されます。
- The ingress DSBM observes the current state of allocation of resources on the input port/link and then determines whether the new resource allocation from the mapped traffic class can be accommodated. The request is passed to the reservation propagator if accepted.
- Ingress DSBMは、入力ポート/リンク上のリソースの現在の割り当ての状態を観察し、マッピングされたトラフィッククラスからの新しいリソース割り当てに対応できるかどうかを判断します。受け入れられれば、リクエストは予約プロパゲーターに渡されます。
- If the ingress SBM is not the "Designated SBM" for this link then it directly passes the request on to the reservation propagator.
- Ingress SBMがこのリンクの「指定されたSBM」ではない場合、リクエストを予約プロパゲーターに直接渡します。
- The reservation propagator relays the request to the bandwidth accountants on each of the switch's outbound links to which this reservation would apply. This implies an interface to routing/forwarding database.
- 予約プロパゲーターは、この予約が適用されるスイッチのアウトバウンドリンクごとに帯域幅の会計士にリクエストを中継します。これは、ルーティング/転送データベースへのインターフェイスを意味します。
- The egress bandwidth accountant observes the current state of allocation of queuing resources on its outbound port and bandwidth on the link itself and determines whether the new allocation can be accommodated. Note that this is only a local decision at this switch hop; further Layer 2 hops through the network may veto the request as it passes along.
- 出力帯域幅の会計士は、リンク自体のアウトバウンドポートと帯域幅にキューイングリソースの配分の現在の状態を観察し、新しい割り当てに対応できるかどうかを判断します。これは、このスイッチホップでのローカル決定にすぎないことに注意してください。ネットワークを介してさらにレイヤー2ホップすると、リクエストが渡されると、リクエストが拒否される場合があります。
- The request, if accepted by this switch, is propagated on each output link selected. Any user_priority described in the forwarded request must be translated according to any egress mapping table.
- このスイッチに受け入れられた場合、リクエストは選択された各出力リンクで伝播されます。転送された要求に記載されているユーザー_Priorityは、出力マッピングテーブルに従って翻訳する必要があります。
- If accepted, the switch must notify the client of the user_priority to be used for packets belonging to that flow. Again, this is an optimistic approach assuming that admission control succeeds; downstream switches may refuse the request.
- 受け入れられた場合、スイッチは、そのフローに属するパケットに使用するために、ユーザー_Priorityをクライアントに通知する必要があります。繰り返しますが、これは入学管理が成功すると仮定して楽観的なアプローチです。ダウンストリームスイッチは、リクエストを拒否する場合があります。
- If this switch wishes to reject the request, it can do so by notifying the client that originated the request by means of its Layer 2 address.
- このスイッチがリクエストを拒否したい場合、レイヤー2アドレスからリクエストを発信したクライアントに通知することでそうすることができます。
The mechanisms described in this document make use of a signaling protocol for devices to communicate their admission control requests across the network. The service definitions to be provided by such a protocol e.g. [14] are described below. We illustrate the primitives and information that need to be exchanged with such a signaling protocol entity. In all of the examples, appropriate delete/cleanup mechanisms will also have to be provided for tearing down established sessions.
このドキュメントで説明されているメカニズムは、デバイスのシグナル伝達プロトコルを使用して、ネットワーク全体で入学制御要求を伝えます。このようなプロトコルによって提供されるサービス定義。[14]を以下に説明します。このようなシグナル伝達プロトコルエンティティと交換する必要があるプリミティブと情報を説明します。すべての例では、確立されたセッションを取り壊すためには、適切な削除/クリーンアップメカニズムも提供する必要があります。
The following interfaces can be identified from Figures 4 and 5.
次のインターフェイスは、図4および5から識別できます。
- SBM <-> Address Mapping
- SBM <->アドレスマッピング
This is a simple lookup function which may require ARP protocol interactions or an algorithmic mapping. The Layer 2 addresses are needed by SBM for inclusion in its signaling messages to avoid requiring that switches participating in the signaling have Layer 3 information to perform the mapping.
これは、ARPプロトコルの相互作用またはアルゴリズムマッピングを必要とする可能性のある単純なルックアップ関数です。レイヤー2アドレスは、信号メッセージに参加することを避けるために、SBMがシグナリングメッセージに含めるために必要です。シグナリングに参加するスイッチには、マッピングを実行するためのレイヤー3情報が必要です。
l2_addr = map_address( ip_addr )
l2_addr = map_address（ip_addr）
- SBM <-> Session/Link Layer Header
- SBM <->セッション/リンクレイヤーヘッダー
This is for notifying the transmit path of how to add Layer 2 header information, e.g. user_priority values to the traffic of each outgoing flow. The transmit path will provide the user_priority value when it requests a MAC layer transmit operation for each packet. The user_priority is one of the parameters passed in the packet transmit primitive defined by the IEEE 802 service model.
これは、レイヤー2ヘッダー情報を追加する方法の送信パスを通知するためです。各発信フローのトラフィックに対するuser_priority値。送信パスは、各パケットのMacレイヤー送信操作を要求するときにuser_priority値を提供します。user_priorityは、IEEE 802サービスモデルによって定義されたパケット送信プリミティブで渡されるパラメーターの1つです。
bind_l2_header( flow_id, user_priority )
bind_l2_header（flow_id、user_priority）
- SBM <-> Classifier/Scheduler
- SBM <->分類器/スケジューラ
This is for notifying transmit classifier/scheduler of any additional Layer 2 information associated with scheduling the transmission of a packet flow. This primitive may be unused in some implementations or it may be used, for example, to provide information to a transmit scheduler that is performing per traffic class scheduling in addition to the per flow scheduling required by IntServ; the Layer 2 header may be a pattern (in addition to the FilterSpec) to be used to identify the flow's traffic.
これは、パケットフローの送信のスケジューリングに関連する追加のレイヤー2情報の送信分類器/スケジューラに通知するためです。このプリミティブは、いくつかの実装では使用されていない場合があります。たとえば、INTSERVが必要とするフローあたりのスケジューリングに加えて、トラフィッククラスごとに実行される送信スケジューラに情報を提供するために使用される場合があります。レイヤー2ヘッダーは、フローのトラフィックを識別するために使用するパターン（フィルタースペックに加えて）である場合があります。
bind_l2schedulerinfo( flow_id, , l2_header, traffic_class )
bind_l2schedulerinfo（flow_id、、l2_header、traffic_class）
- SBM <-> Local Admission Control
- SBM <->ローカル入場管理
This is used for applying local admission control for a session e.g. is there enough transmit bandwidth still uncommitted for this new session? Are there sufficient receive buffers? This should commit the necessary resources if it succeeds. It will be necessary to release these resources at a later stage if the admission control fails at a subsequent node. This call would be made, for example, by a segment's Designated SBM.
これは、セッションのためにローカル入場制御を適用するために使用されます。この新しいセッションにはまだ不可能な帯域幅がまだありますか？十分な受信バッファーはありますか？これは、それが成功した場合、必要なリソースをコミットするはずです。後続のノードで入場制御が失敗した場合、これらのリソースを後の段階でリソースをリリースする必要があります。この呼び出しは、たとえば、セグメントの指定SBMによって行われます。
status = admit_l2session( flow_id, Tspec, FlowSpec )
status = admit_l2session（flow_id、tspec、flowspec）
- SBM <-> RSVP
- SBM <-> rsvp
This is outlined above in Section 7.1.2 and fully described in [14].
これは、上記のセクション7.1.2で概説されており、[14]で完全に説明されています。
- Management Interfaces
- 管理インターフェイス
Some or all of the modules described by this model will also require configuration management. It is expected that details of the manageable objects will be specified by future work in the ISSLL WG.
このモデルで説明されているモジュールの一部またはすべてには、構成管理も必要です。管理可能なオブジェクトの詳細は、ISSLL WGでの将来の作業によって指定されることが期待されています。
The following interfaces are identified from Figure 6.
次のインターフェイスを図6から識別します。
- SBM <-> Classifier
- SBM <->分類器
This is for notifying the receive classifier of how to match incoming Layer 2 information with the associated traffic class. It may in some cases consist of a set of read only default mappings.
これは、受信分類器に、着信層2の情報を関連するトラフィッククラスと一致させる方法を通知するためです。場合によっては、読み取り専用のデフォルトマッピングのセットで構成される場合があります。
bind_l2classifierinfo( flow_id, l2_header, traffic_class )
bind_l2classifierinfo（flow_id、l2_header、traffic_class）
- SBM <-> Queue and Packet Scheduler
- SBM <->キューとパケットスケジューラ
This is for notifying transmit scheduler of additional Layer 2 information associated with a given traffic class. It may be unused in some cases (see discussion in previous section).
これは、特定のトラフィッククラスに関連付けられた追加のレイヤー2情報の送信スケジューラに通知するためです。場合によっては使用されていない場合があります（前のセクションで説明を参照）。
bind_l2schedulerinfo( flow_id, l2_header, traffic_class )
bind_l2schedulerinfo（flow_id、l2_header、traffic_class）
- SBM <-> Local Admission Control
- SBM <->ローカル入場管理
Same as for the host discussed above.
上記のホストと同じです。
- SBM <-> Traffic Class Map and Police
- SBM <->交通クラスマップと警察
Optional configuration of any user_priority remapping that might be implemented on ingress to and egress from the ports of a switch. For IEEE 802.1D switches, it is likely that these mappings will have to be consistent across all ports.
スイッチのポートからイングレスと出口で実装される可能性のあるuser_priorityの再マッピングのオプション構成。IEEE 802.1Dスイッチの場合、これらのマッピングはすべてのポートで一貫している必要がある可能性があります。
bind_l2ingressprimap( inport, in_user_pri, internal_priority ) bind_l2egressprimap( outport, internal_priority, out_user_pri )
bind_l2ingressprimap（inport、in_user_pri、internal_priority）bind_l2egressprimap（outport、internal_priority、out_user_pri）
Optional configuration of any Layer 2 policing function to be applied on a per class basis to traffic matching the Layer 2 header. If the switch is capable of per flow policing then existing IntServ/RSVP models will provide a service definition for that configuration.
レイヤー2ヘッダーに一致するトラフィックにクラスごとに適用されるレイヤー2ポリシング関数のオプション構成。スイッチがフローあたりのポリシングが可能な場合、既存のIntServ/RSVPモデルは、その構成のサービス定義を提供します。
bind_l2policing( flow_id, l2_header, Tspec, FlowSpec )
bind_l2policing（flow_id、l2_header、tspec、flowspec）
- SBM <-> Filtering Database
- SBM <->データベースのフィルタリング
SBM propagation rules need access to the Layer 2 forwarding database to determine where to forward SBM messages. This is analogous to RSRR interface in Layer 3 RSVP.
SBM伝播ルールは、SBMメッセージを転送する場所を決定するために、レイヤー2転送データベースにアクセスする必要があります。これは、レイヤー3 RSVPのRSRRインターフェイスに類似しています。
output_portlist = lookup_l2dest( l2_addr )
output_portlist = lookup_l2dest（l2_addr）
- Management Interfaces
- 管理インターフェイス
Some or all of the modules described by this model will also require configuration management. It is expected that details of the manageable objects will be specified by future work in the ISSLL working group.
このモデルで説明されているモジュールの一部またはすべてには、構成管理も必要です。管理可能なオブジェクトの詳細は、ISSLLワーキンググループの将来の作業によって指定されることが期待されています。
As stated earlier, the Integrated Services working group has defined various service classes offering varying degrees of QoS guarantees. Initial effort will concentrate on enabling the Controlled Load [6] and Guaranteed Service classes [7]. The Controlled Load service provides a loose guarantee, informally stated as "the same as best effort would be on an unloaded network". The Guaranteed Service provides an upper bound on the transit delay of any packet. The extent to which these services can be supported at the link layer will depend on many factors including the topology and technology used. Some of the mapping issues are discussed below in light of the emerging link layer standards and the functions supported by higher layer protocols. Considering the limitations of some of the topologies, it may not be possible to satisfy all the requirements for Integrated Services on a given topology. In such cases, it is useful to consider providing support for an approximation of the service which may suffice in most practical instances. For example, it may not be feasible to provide policing/shaping at each network element (bridge/switch) as required by the Controlled Load specification. But if this task is left to the end stations, a reasonably good approximation to the service can be obtained.
前述のように、統合サービスワーキンググループは、さまざまな程度のQoS保証を提供するさまざまなサービスクラスを定義しています。最初の努力は、制御された負荷[6]と保証されたサービスクラス[7]を有効にすることに集中します。制御されたロードサービスは、「最良の努力がアンロードされていないネットワーク上にある」と非公式に述べられているゆるい保証を提供します。保証されたサービスは、パケットのトランジット遅延に上限を提供します。これらのサービスをリンクレイヤーでサポートできる程度は、使用されるトポロジや技術を含む多くの要因に依存します。マッピングの問題のいくつかは、新しいリンク層標準と、高層プロトコルによってサポートされる関数に照らして以下で説明します。いくつかのトポロジの制限を考慮すると、特定のトポロジに関する統合サービスのすべての要件を満たすことはできない場合があります。そのような場合、ほとんどの実用的なインスタンスで十分なサービスの近似のサポートを提供することを検討することは有用です。たとえば、制御された負荷仕様で要求されているように、各ネットワーク要素（ブリッジ/スイッチ）でポリシング/シェーピングを提供することは実行不可能な場合があります。しかし、このタスクがエンドステーションに任されている場合、サービスの合理的に適切な近似値を取得できます。
There are many LAN bridges/switches with varied capabilities for supporting QoS. We discuss below the various kinds of devices that that one may expect to find in a LAN environment.
QoSをサポートするためのさまざまな機能を備えた多くのLANブリッジ/スイッチがあります。以下では、LAN環境で見つけることが期待されるさまざまな種類のデバイスについて説明します。
The most basic bridge is one which conforms to the IEEE 802.1D specification of 1993 [2]. This device has a single queue per output port, and uses the spanning tree algorithm to eliminate topology loops. Networks constructed from this kind of device cannot be expected to provide service guarantees of any kind because of the complete lack of traffic isolation.
最も基本的な橋は、1993年のIEEE 802.1D仕様に準拠したものです[2]。このデバイスには、出力ポートごとに単一のキューがあり、スパニングツリーアルゴリズムを使用してトポロジループを排除します。この種のデバイスから構築されたネットワークは、トラフィックの分離が完全に不足しているため、あらゆる種類のサービス保証を提供することは期待できません。
The next level of bridges/switches are those which conform to the more recently revised IEEE 802.1D specification [3]. They include support for queuing up to eight traffic classes separately. The level of traffic isolation provided is coarse because all flows corresponding to a particular traffic class are aggregated. Further, it is likely that more than one priority will map to a traffic class depending on the number of queues implemented in the switch. It would be difficult for such a device to offer protection against misbehaving flows. The scope of multicast traffic may be limited by using GMRP to only those segments which are on the path to interested receivers.
次のレベルのブリッジ/スイッチは、最近改訂されたIEEE 802.1D仕様[3]に準拠するものです。これらには、最大8つのトラフィッククラスを別々にキューイングするためのサポートが含まれています。特定のトラフィッククラスに対応するすべてのフローが集約されているため、提供されるトラフィックの分離のレベルは粗いです。さらに、スイッチに実装されているキューの数に応じて、複数の優先度がトラフィッククラスにマッピングされる可能性があります。そのようなデバイスが不正なフローから保護を提供することは難しいでしょう。マルチキャストトラフィックの範囲は、GMRPを使用して、関心のあるレシーバーへのパス上にあるセグメントのみに制限される場合があります。
A next step above these devices are bridges/switches which implement optional parts of the IEEE 802.1D specification such as mapping the received user_priority to some internal set of canonical values on a per-input-port basis. It may also support the mapping of these internal canonical values onto transmitted user_priority on a per-output-port basis. With these extra capabilities, network administrators can perform mapping of traffic classes between specific pairs of ports, and in doing so gain more control over admission of traffic into the protected classes.
これらのデバイスの上の次のステップは、受信したuser_priorityをいくつかの内部標準値にマッピングするなど、IEEE 802.1D仕様のオプション部分を実装するブリッジ/スイッチです。また、これらの内部標準値のマッピングを、PER OUTPUT-PORTベースで送信されたuser_priorityにサポートする場合があります。これらの追加機能により、ネットワーク管理者は、ポートの特定のペア間でトラフィッククラスのマッピングを実行できます。これにより、保護されたクラスへのトラフィックの入場をさらに制御できます。
Other entirely optional features that some bridges/switches may support include classification of IntServ flows using fields in the network layer header, per-flow policing and/or reshaping which is essential for supporting Guaranteed Service, and more sophisticated scheduling algorithms such as variants of weighted fair queuing to limit the bandwidth consumed by a traffic class. Note that it is advantageous to perform flow isolation and for all network elements to police each flow in order to support the Controlled Load and Guaranteed Service.
一部のブリッジ/スイッチがサポートする可能性のあるその他の完全にオプションの機能には、ネットワークレイヤーヘッダーのフィールドを使用したINTSERVフローの分類、保証されたサービスをサポートするために不可欠なフローパーポリシングおよび/または再形成、および加重のバリエーションなどのより洗練されたスケジューリングアルゴリズムが含まれます。トラフィッククラスによって消費される帯域幅を制限するための公正なキューイング。制御された負荷と保証されたサービスをサポートするために、フロー分離を実行し、すべてのネットワーク要素を各フローを警察することが有利であることに注意してください。
Connectionless packet networks in general, and LANs in particular, work today because of scaling choices in network provisioning. Typically, excess bandwidth and buffering is provisioned in the network to absorb the traffic sourced by higher layer protocols, often sufficient to cause their transmission windows to run out on a statistical basis, so that network overloads are rare and transient and the expected loading is very low.
一般に、Connectionless Packetネットワーク、特にLANSは、ネットワークプロビジョニングの選択肢のスケーリングのために今日機能します。通常、過剰な帯域幅とバッファリングがネットワークでプロビジョニングされ、高層プロトコルによって供給されたトラフィックを吸収するために、多くの場合、伝送ウィンドウが統計的に不足するようになるため、ネットワークの過負荷はまれで一時的であり、予想される負荷は非常に低い。
With the advent of time-critical traffic such over-provisioning has become far less easy to achieve. Time-critical frames may be queued for annoyingly long periods of time behind temporary bursts of file transfer traffic, particularly at network bottleneck points, e.g. at the 100 Mbps to 10 Mbps transition that might occur between the riser to the wiring closet and the final link to the user from a desktop switch. In this case, however, if it is known a priori (either by application design, on the basis of statistics, or by administrative control) that time-critical traffic is a small fraction of the total bandwidth, it suffices to give it strict priority over the non-time-critical traffic. The worst case delay experienced by the time-critical traffic is roughly the maximum transmission time of a maximum length non-time-critical frame -- less than a millisecond for 10 Mbps Ethernet, and well below the end to end delay budget based on human perception times.
タイムクリティカルなトラフィックの出現により、このような過剰なプロビジョニングは、達成がはるかに容易になりません。時間型のフレームは、特にネットワークボトルネックポイントで、ファイル転送トラフィックの一時的なバーストの後ろで、迷惑に長い間キューに留められている可能性があります。100 Mbpsから10 Mbpsの移行で、ライザーの間に配線クローゼットまで発生する可能性があり、デスクトップスイッチからユーザーへの最終リンク。ただし、この場合、先験的に（アプリケーションの設計、統計に基づいて、または管理制御による）ということが知られている場合、時間批判的なトラフィックは総帯域幅のわずかな部分であるため、厳密な優先度を与えるだけで十分で十分です。非時間的に批判的なトラフィックについて。タイムクリティカルなトラフィックによって経験される最悪のケースの遅延は、10 Mbpsイーサネットのミリ秒未満であり、人間に基づいて端から端までの端までの遅延予算をはるかに下回る最大長さの非時間批判的なフレームの最大伝送時間です。知覚時間。
When more than one priority service is to be offered by a network element e.g. one which supports both Controlled Load as well as Guaranteed Service, the requirements for the scheduling discipline become more complex. In order to provide the required isolation between the service classes, it will probably be necessary to queue them separately. There is then an issue of how to service the queues which requires a combination of admission control and more intelligent queuing disciplines. As with the service specifications themselves, the specification of queuing algorithms is beyond the scope of this document.
複数の優先サービスがネットワーク要素によって提供される場合。制御された負荷と保証されたサービスの両方をサポートするもの、スケジューリング規律の要件がより複雑になります。サービスクラス間に必要な分離を提供するためには、おそらくそれらを個別にキューにする必要があります。次に、入場制御とよりインテリジェントなキューイングの分野の組み合わせを必要とするキューのサービス方法の問題があります。サービス仕様自体と同様に、キューイングアルゴリズムの仕様はこのドキュメントの範囲を超えています。
The number of traffic classes supported and access methods of the technology under consideration will determine how many and what services may be supported. Native Token Ring/IEEE 802.5, for instance, supports eight priority levels which may be mapped to one or more traffic classes. Ethernet/IEEE 802.3 has no support for signaling priorities within frames. However, the IEEE 802 standards committee has recently developed a new standard for bridges/switches related to multimedia traffic expediting and dynamic multicast filtering [3]. A packet format for carrying a user_priority field on all IEEE 802 LAN media types is now defined in [4]. These standards allow for up to eight traffic classes on all media. The user_priority bits carried in the frame are mapped to a particular traffic class within a bridge/switch. The user_priority is signaled on an end-to-end basis, unless overridden by bridge/switch management. The traffic class that is used by a flow should depend on the quality of service desired and whether the reservation is successful or not. Therefore, a sender should use the user_priority value which maps to the best effort traffic class until told otherwise by the BM. The BM will, upon successful completion of resource reservation, specify the value of user_priority to be used by the sender for that session's data. An accompanying memo [13] addresses the issue of mapping the various Integrated Services to appropriate traffic classes.
サポートされているトラフィッククラスの数と検討中のテクノロジーのアクセス方法により、サポートできるサービスの数とどのサービスが決定されます。たとえば、ネイティブトークンリング/IEEE 802.5は、1つ以上のトラフィッククラスにマッピングできる8つの優先レベルをサポートします。Ethernet/IEEE 802.3は、フレーム内のシグナリング優先順位をサポートしていません。ただし、IEEE 802標準委員会は最近、マルチメディアトラフィックの迅速化と動的なマルチキャストフィルタリングに関連するブリッジ/スイッチの新しい標準を開発しました[3]。すべてのIEEE 802 LANメディアタイプにuser_priorityフィールドを運ぶためのパケット形式は、[4]で定義されています。これらの標準では、すべてのメディアで最大8つのトラフィッククラスが可能になります。フレームに携帯されるuser_priorityビットは、ブリッジ/スイッチ内の特定のトラフィッククラスにマッピングされます。user_priorityは、ブリッジ/スイッチ管理によって無効にされない限り、エンドツーエンドベースでシグナルにされます。フローで使用されるトラフィッククラスは、希望するサービスの品質と、予約が成功しているかどうかに依存する必要があります。したがって、送信者は、BMが別の方法で伝えるまで、最良のトラフィッククラスにマップするuser_priority値を使用する必要があります。BMは、リソース予約が正常に完了すると、そのセッションのデータに送信者が使用するuser_priorityの値を指定します。付随するメモ[13]は、さまざまな統合サービスを適切なトラフィッククラスにマッピングするという問題に対処しています。
One other topic under discussion in the IntServ context is how to handle the traffic for data flows from sources that exceed their negotiated traffic contract with the network. An approach that shows some promise is to treat such traffic with "somewhat less than best effort" service in order to protect traffic that is normally given "best effort" service from having to back off. Best effort traffic is often adaptive, using TCP or other congestion control algorithms, and it would be unfair to penalize those flows due to badly behaved traffic from reserved flows which are often set up by non-adaptive applications.
INTSERVコンテキストで議論されているもう1つのトピックは、ネットワークとの交渉されたトラフィック契約を超えるソースからのデータフローのトラフィックを処理する方法です。いくつかの約束を示すアプローチは、通常「最良の努力」サービスが後退しないようにするトラフィックを保護するために、そのようなトラフィックを「やや努力よりもやや少ない」サービスで扱うことです。最良のトラフィックは、TCPまたはその他の輻輳制御アルゴリズムを使用して適応性があることがよくあり、不適格なアプリケーションによってしばしば設定される予約フローからの不十分な動作のために、これらのフローを罰することは不公平です。
A possible solution might be to assign normal best effort traffic to one user_priority and to label excess non-conforming traffic as a lower user_priority although the re-ordering problems that might arise from doing this may make this solution undesirable, particularly if the flows are using TCP. For this reason the controlled load service recommends dropping excess traffic, rather than re-mapping to a lower priority. This is further discussed below.
可能な解決策は、通常の最適な努力トラフィックを1人のuser_priorityに割り当て、過剰な不適合トラフィックをより低いユーザー_プリアリにラベル付けすることですが、これを行うことで発生する可能性のある再注文の問題は、このソリューションを望ましくない場合、特にフローが使用している場合TCP。このため、制御された負荷サービスは、より低い優先度に再マッピングするのではなく、過剰なトラフィックを落とすことを推奨しています。これについては、以下でさらに説明します。
In some cases, a network administrator may not trust the user_priority values contained in packets from a source and may wish to map these into some more suitable set of values. Alternatively, due perhaps to equipment limitations or transition periods, the user_priority values may need to be re-mapped as the data flows to/from different regions of a network.
場合によっては、ネットワーク管理者は、ソースからのパケットに含まれるuser_priority値を信頼できず、これらをより適切な値のセットにマッピングすることをお勧めします。あるいは、おそらく機器の制限または移行期間のために、ユーザー_Priority値をネットワークの異なる領域に賛成するデータが流れるときに再マッピングする必要がある場合があります。
Some switches may implement such a function on input that maps received user_priority to some internal set of values. This function is provided by a table known in IEEE 802.1D as the User Priority Regeneration Table (Table 3-1 in [3]). These values can then be mapped using an output table described above onto outgoing user_priority values. These same mappings must also be used when applying admission control to requests that use the user_priority values (see e.g. [14]). More sophisticated approaches are also possible where a device polices traffic flows and adjusts their onward user_priority based on their conformance to the admitted traffic flow specifications.
一部のスイッチは、MAPがいくつかの内部値のセットにuser_priorityを受信した入力にそのような関数を実装する場合があります。この関数は、IEEE 802.1Dでユーザーの優先度再生表として知られているテーブルによって提供されます（[3]の表3-1）。これらの値は、上記の出力テーブルを使用して発信ユーザー_priority値にマッピングできます。これらの同じマッピングは、user_priority値を使用するリクエストに入学制御を適用するときにも使用する必要があります（例：[14]を参照）。また、デバイスポリシーがトラフィックを流し、認められたトラフィックフロー仕様への適合に基づいて外向きのuser_priorityを調整する場合、より洗練されたアプローチも可能です。
In the figure above, SW is a bridge/switch in the link layer domain. S1, S2, S3, R1 and R2 are end stations which are members of a group associated with the same RSVP flow. S1, S2 and S3 are upstream end stations. R1 and R2 are the downstream end stations which receive traffic from all the senders. RSVP allows receivers R1 and R2 to specify reservations which can apply to: (a) one specific sender only (fixed filter); (b) any of two or more explicitly specified senders (shared explicit filter); and (c) any sender in the group (shared wildcard filter). Support for the fixed filter style is straightforward; a separate reservation is made for the traffic from each of the senders. However, support for the other two filter styles has implications regarding policing; i.e. the merged flow from the different senders must be policed so that they conform to traffic parameters specified in the filter's RSpec. This scenario is further complicated if the services requested by R1 and R2 are different. Therefore, in the absence of policing within bridges/switches, it may be possible to support only fixed filter reservations at the link layer.
上の図では、SWはリンクレイヤードメインのブリッジ/スイッチです。S1、S2、S3、R1、およびR2は、同じRSVPフローに関連するグループのメンバーであるエンドステーションです。S1、S2、およびS3は上流のエンドステーションです。R1とR2は、すべての送信者からトラフィックを受け取る下流のエンドステーションです。RSVPを使用すると、Receiver R1とR2は、（a）1つの特定の送信者のみ（固定フィルター）に適用できる予約を指定できます。（b）2つ以上の明示的に指定された送信者のいずれか（共有明示的なフィルター）。（c）グループ内の送信者（共有ワイルドカードフィルター）。固定フィルタースタイルのサポートは簡単です。各送信者からのトラフィックのために別の予約が行われます。ただし、他の2つのフィルタースタイルのサポートには、ポリシングに関する意味があります。つまり、異なる送信者からのマージされたフローをポリシングして、フィルターのRSPECで指定されたトラフィックパラメーターに適合する必要があります。このシナリオは、R1とR2が要求したサービスが異なる場合、さらに複雑です。したがって、ブリッジ/スイッチ内のポリシングがない場合、リンクレイヤーでの固定フィルター予約のみをサポートすることが可能かもしれません。
+-----+ +-----+ +-----+
| S1 | | S2 | | S3 |
+-----+ +-----+ +-----+
| | |
| v |
| +-----+ |
+--------->| SW |<---------+
+-----+
| |
+----+ +----+
| |
v V
+-----+ +-----+
| R1 | | R2 |
+-----+ +-----+
Figure 7: Illustration of filter styles
図7：フィルタースタイルのイラスト
At Layer 3, the IntServ model allows heterogeneous receivers for multicast flows where different branches of a tree can have different types of reservations for a given multicast destination. It also supports the notion that trees may have some branches with reserved flows and some using best effort service. If we were to treat a Layer 2 subnet as a single network element as defined in [8], then all of the branches of the distribution tree that lie within the subnet could be assumed to require the same QoS treatment and be treated as an atomic unit as regards admission control, etc. With this assumption, the model and protocols already defined by IntServ and RSVP already provide sufficient support for multicast heterogeneity. Note, however, that an admission control request may well be rejected because just one link in the subnet is oversubscribed leading to rejection of the reservation request for the entire subnet.
レイヤー3では、INTSERVモデルにより、ツリーの異なる枝が特定のマルチキャスト宛先のさまざまな種類の予約を持つことができるマルチキャストフローの不均一レシーバーが可能になります。また、木は予約されたフローを備えた枝と、最良の努力サービスを使用している枝があるかもしれないという概念を支持しています。[8]で定義されているように、レイヤー2サブネットを単一のネットワーク要素として扱う場合、サブネット内にある分布ツリーの分岐はすべて、同じQoS処理を必要とし、原子として扱われると想定できます。この仮定により、入場管理などに関してユニットは、IntSVとRSVPによってすでに定義されているモデルとプロトコルは、すでにマルチキャストの不均一性を十分にサポートしています。ただし、サブネットの1つのリンクだけがサブネット全体の予約要求の拒否につながるため、入場制御要求が拒否される可能性があることに注意してください。
As an example, consider Figure 8, SW is a Layer 2 device (bridge/switch) participating in resource reservation, S is the upstream source end station and R1 and R2 are downstream end station receivers. R1 would like to make a reservation for the flow while R2 would like to receive the flow using best effort service. S sends RSVP PATH messages which are multicast to both R1 and R2. R1 sends an RSVP RESV message to S requesting the reservation of resources.
例として、図8を考慮して、SWはリソース予約に参加するレイヤー2デバイス（ブリッジ/スイッチ）であり、Sは上流のソースエンドステーション、R1とR2は下流のエンドステーションレシーバーです。R1はフローの予約をしたいのですが、R2はBest Effems Serviceを使用してフローを受け取りたいと考えています。Sは、R1とR2の両方にマルチキャストであるRSVPパスメッセージを送信します。R1は、RSVP RESVメッセージをSに送信し、リソースの予約を要求します。
+-----+
| S |
+-----+
|
v
+-----+ +-----+ +-----+
| R1 |<-----| SW |----->| R2 |
+-----+ +-----+ +-----+
Figure 8: Example of receiver heterogeneity
図8：レシーバーの不均一性の例
If the reservation is successful at Layer 2, the frames addressed to the group will be categorized in the traffic class corresponding to the service requested by R1. At SW, there must be some mechanism which forwards the packet providing service corresponding to the reserved traffic class at the interface to R1 while using the best effort traffic class at the interface to R2. This may involve changing the contents of the frame itself, or ignoring the frame priority at the interface to R2.
レイヤー2で予約が成功した場合、グループに宛てられたフレームは、R1が要求したサービスに対応するトラフィッククラスに分類されます。SWでは、インターフェイスで最適な努力トラフィッククラスをR2に使用しながら、インターフェースの予約されたトラフィッククラスに対応するパケット提供サービスを転送するメカニズムがある必要があります。これには、フレーム自体の内容を変更したり、R2へのインターフェイスでフレームの優先度を無視したりする場合があります。
Another possibility for supporting heterogeneous receivers would be to have separate groups with distinct MAC addresses, one for each class of service. By default, a receiver would join the "best effort" group where the flow is classified as best effort. If the receiver makes a reservation successfully, it can be transferred to the group for the class of service desired. The dynamic multicast filtering capabilities of bridges and switches implementing the IEEE 802.1D standard would be a very useful feature in such a scenario. A given flow would be transmitted only on those segments which are on the path between the sender and the receivers of that flow. The obvious disadvantage of such an approach is that the sender needs to send out multiple copies of the same packet corresponding to each class of service desired thus potentially duplicating the traffic on a portion of the distribution tree.
不均一なレシーバーをサポートするもう1つの可能性は、サービスの各クラスに1つずつ、個別のMACアドレスを持つ個別のグループを持つことです。デフォルトでは、レシーバーは、フローが最善の努力として分類される「最良の努力」グループに参加します。レシーバーが予約を成功裏に行うと、希望するサービスクラスのためにグループに転送できます。IEEE 802.1D標準を実装するブリッジとスイッチの動的なマルチキャストフィルタリング機能は、このようなシナリオでは非常に有用な機能です。特定のフローは、送信者とそのフローの受信機の間の経路上にあるセグメントにのみ送信されます。このようなアプローチの明らかな欠点は、送信者が、希望する各クラスに対応する同じパケットの複数のコピーを送信する必要があることです。
The above approaches would provide very sub-optimal utilization of resources given the expected size and complexity of the Layer 2 subnets. Therefore, it is desirable to enable switches to apply QoS differently on different egress branches of a tree that divide at that switch.
上記のアプローチは、レイヤー2サブネットの予想されるサイズと複雑さを考慮して、リソースの非常に最適な利用を提供します。したがって、スイッチがそのスイッチで分割されるツリーの異なる出力分岐でQoSを異なる方法で適用できるようにすることが望ましいです。
IEEE 802.1D specifies a basic model for multicast whereby a switch makes multicast forwarding decisions based on the destination address. This would produce a list of output ports to which the packet should be forwarded. In its default mode, such a switch would use the user_priority value in received packets, or a value regenerated on a per input port basis in the absence of an explicit value, to enqueue the packets at each output port. Any IEEE 802.1D switch which supports multiple traffic classes can support this operation.
IEEE 802.1Dマルチキャストの基本モデルを指定し、スイッチが宛先アドレスに基づいてマルチキャスト転送決定を行うことです。これにより、パケットを転送する出力ポートのリストが作成されます。デフォルトモードでは、このようなスイッチは、受信したパケットでuser_priority値を使用するか、明示的な値がない場合に入力ポートごとに再生成され、各出力ポートのパケットをenceueします。複数のトラフィッククラスをサポートするIEEE 802.1Dスイッチは、この操作をサポートできます。
If a switch selects per port output queues based only on the incoming user_priority, as described by IEEE 802.1D, it must treat all branches of all multicast sessions within that user_priority class with the same queuing mechanism. Receiver heterogeneity is then not possible and this could well lead to the failure of an admission control request for the whole multicast session due to a single link being oversubscribed. Note that in the Layer 2 case as distinct from the Layer 3 case with RSVP/IntServ, the option of having some receivers getting the session with the requested QoS and some getting it best effort does not exist as basic IEEE 802.1 switches are unable to re-map the user_priority on a per link basis. This could become an issue with heavy use of dynamic multicast sessions. If a switch were to implement a separate user_priority mapping at each output port, then, in some cases, reservations can use a different traffic class on different paths that branch at such a switch in order to provide multiple receivers with different QoS. This is possible if all flows within a traffic class at the ingress to a switch egress in the same traffic class on a port. For example, traffic may be forwarded using user_priority 4 on one branch where receivers have performed admission control and as user_priority 0 on ones where they have not. We assume that per user_priority queuing without taking account of input or output ports is the minimum standard functionality for switches in a LAN environment (IEEE 802.1D) but that more functional Layer 2 or even Layer 3 switches (i.e. routers) can be used if even more flexible forms of heterogeneity are considered necessary to achieve more efficient resource utilization. The behavior of Layer 3 switches in this context is already well standardized by the IETF.
IEEE 802.1Dで説明されているように、入力ユーザー_Priorityのみに基づいてスイッチがポート出力キューごとに選択される場合、そのユーザー_Priorityクラス内のすべてのマルチキャストセッションのすべてのブランチを同じキューイングメカニズムで処理する必要があります。レシーバーの不均一性は不可能であり、これは単一のリンクが過剰にサブスクライブされているため、マルチキャストセッション全体の入場制御要求の障害につながる可能性があります。RSVP/intServのレイヤー3ケースとは異なるレイヤー2のケースでは、一部の受信機に要求されたQoSでセッションを取得するオプションは、基本的なIEEE 802.1スイッチが再会できないため、最善の努力を得ることができないことに注意してください。-user_priorityをリンクごとにマップします。これは、ダイナミックマルチキャストセッションの大量に使用することで問題になる可能性があります。スイッチが各出力ポートに個別のuser_priorityマッピングを実装する場合、場合によっては、複数のレシーバーに異なるQOを提供するために、そのようなスイッチで分岐する異なるパスで異なるトラフィッククラスを使用できます。これは、ポート上の同じトラフィッククラスのスイッチエベルに入り込んでいるトラフィッククラス内のすべての流れがあれば可能です。たとえば、トラフィックは、受信機が入学制御を実行した1つのブランチのuser_priority 4を使用して、およびuser_priority 0を使用して転送できます。入力または出力ポートを考慮せずにuser_priorityキューイングごとに、LAN環境のスイッチの最小標準機能であるが、より機能的なレイヤー2またはレイヤー3スイッチ（すなわち、ルーター）を使用できると仮定します。より効率的なリソース利用を実現するには、より柔軟な形の不均一性が必要であると考えられています。このコンテキストでのレイヤー3スイッチの動作は、IETFによってすでに十分に標準化されています。
The extent to which service guarantees can be provided by a network depend to a large degree on the ability to provide the key functions of flow identification and scheduling in addition to admission control and policing. This section discusses some of the capabilities of the LAN technologies under consideration and provides a taxonomy of possible topologies emphasizing the capabilities of each with regard to supporting the above functions. For the technologies considered here, the basic topology of a LAN may be shared, switched half duplex or switched full duplex. In the shared topology, multiple senders share a single segment. Contention for media access is resolved using protocols such as CSMA/CD in Ethernet and token passing in Token Ring and FDDI. Switched half duplex, is essentially a shared topology with the restriction that there are only two transmitters contending for resources on any segment. Finally, in a switched full duplex topology, a full bandwidth path is available to the transmitter at each end of the link at all times. Therefore, in this topology, there is no need for any access control mechanism such as CSMA/CD or token passing as there is no contention between the transmitters. Obviously, this topology provides the best QoS capabilities. Another important element in the discussion of topologies is the presence or absence of support for multiple traffic classes. These were discussed earlier in Section 4.1. Depending on the basic topology used and the ability to support traffic classes, we identify six scenarios as follows:
ネットワークによってサービス保証を提供できる範囲は、入場管理とポリシングに加えて、フロー識別とスケジューリングの重要な機能を提供する能力に大きく依存します。このセクションでは、検討中のLANテクノロジーの機能の一部について説明し、上記の機能をサポートすることに関して、それぞれの機能を強調する可能性のあるトポロジの分類法を提供します。ここで考慮されるテクノロジーの場合、LANの基本的なトポロジーを共有、半分二重の切り替え、または完全なデュプレックスを切り替えることができます。共有トポロジでは、複数の送信者が単一のセグメントを共有しています。メディアアクセスの競合は、イーサネットのCSMA/CDなどのプロトコルやトークンリングとFDDIの通過トークンなどのプロトコルを使用して解決されます。半分二重の切り替えは、基本的に共有トポロジであり、セグメントのリソースを競合するトランスミッターが2つしかないという制限です。最後に、切り替えられた完全な二重トポロジでは、常にリンクの両端にあるトランスミッターが完全な帯域幅パスを利用できます。したがって、このトポロジでは、送信機の間に競合がないため、CSMA/CDやトークンの通過などのアクセス制御メカニズムは必要ありません。明らかに、このトポロジーは最高のQoS機能を提供します。トポロジーの議論におけるもう1つの重要な要素は、複数の交通クラスのサポートの有無です。これらについては、セクション4.1で前述しました。使用される基本トポロジとトラフィッククラスをサポートする機能に応じて、次のように6つのシナリオを特定します。
1. Shared topology without traffic classes. 2. Shared topology with traffic classes. 3. Switched half duplex topology without traffic classes. 4. Switched half duplex topology with traffic classes. 5. Switched full duplex topology without traffic classes. 6. Switched full duplex topology with traffic classes.
1. 交通クラスのない共有トポロジ。2.トラフィッククラスとトポロジを共有します。3.トラフィッククラスなしで半二重トポロジを切り替えました。4.トラフィッククラスで半分二重トポロジを切り替えました。5.トラフィッククラスなしでフルデュプレックストポロジを切り替えました。6.トラフィッククラスを使用してフルデュプレックストポロジを切り替えました。
There is also the possibility of hybrid topologies where two or more of the above coexist. For instance, it is possible that within a single subnet, there are some switches which support traffic classes and some which do not. If the flow in question traverses both kinds of switches in the network, the least common denominator will prevail. In other words, as far as that flow is concerned, the network is of the type corresponding to the least capable topology that is traversed. In the following sections, we present these scenarios in further detail for some of the different IEEE 802 network types with discussion of their abilities to support the IntServ services.
また、上記の2つ以上が共存するハイブリッドトポロジの可能性もあります。たとえば、単一のサブネット内では、トラフィッククラスをサポートするスイッチやそうでないスイッチがいくつかある可能性があります。問題のフローがネットワーク内の両方の種類のスイッチを通過すると、最も一般的な分母が勝ちます。言い換えれば、そのフローに関する限り、ネットワークは、移動されている最も有能なトポロジに対応するタイプです。以下のセクションでは、これらのシナリオを、IntServサービスをサポートする能力について説明し、さまざまなIEEE 802ネットワークタイプのいくつかについてさらに詳しく説明します。
On a full duplex switched LAN, the MAC protocol is unimportant as as access is concerned, but must be factored into the characterization parameters advertised by the device since the access latency is equal to the time required to transmit the largest packet. Approximate values for the characteristics on various media are provided in the following tables. These delays should be also be considered in the context of the speed of light delay which is approximately 400 ns for typical 100 m UTP links and 7 us for typical 2 km multimode fiber links.
完全なデュプレックススイッチLANでは、アクセスが関係するようにMACプロトコルは重要ではありませんが、アクセスレイテンシは最大のパケットを送信するのに必要な時間に等しいため、デバイスによって宣伝された特性評価パラメーターに因数分解する必要があります。さまざまなメディアの特性の近似値は、次の表に記載されています。これらの遅延は、典型的な100 m UTPリンクで約400 ns、典型的な2 kmのマルチモードファイバーリンクで7米ドルである光遅延速度のコンテキストでも考慮する必要があります。
Table 4: Full duplex switched media access latency
表4：完全なデュプレックス切り替えメディアアクセスレイテンシ
--------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
--------------------------------------------------
Ethernet 10 Mbps 1.2 ms 1.2 ms
100 Mbps 120 us 120 us
1 Gbps 12 us 12 us
Token Ring 4 Mbps 9 ms 9 ms
16 Mbps 9 ms 9 ms
FDDI 100 Mbps 360 us 8.4 ms
Demand Priority 100 Mbps 120 us 120 us
--------------------------------------------------
Full duplex switched network topologies offer good QoS capabilities for both Controlled Load and Guaranteed Service when supported by suitable queuing strategies in the switches.
フルデュプレックススイッチネットワークトポロジは、スイッチの適切なキューイング戦略によってサポートされている場合、制御された負荷と保証サービスの両方に適したQoS機能を提供します。
Thus far, we have not discussed the difficulty of dealing with allocation on a single shared CSMA/CD segment. As soon as any CSMA/CD algorithm is introduced the ability to provide any form of Guaranteed Service is seriously compromised in the absence of any tight coupling between the multiple senders on the link. There are a number of reasons for not offering a better solution to this problem.
これまでのところ、単一の共有CSMA/CDセグメントでの割り当てを扱うことの難しさについては議論していません。CSMA/CDアルゴリズムが導入されるとすぐに、リンク上の複数の送信者間の緊密な結合がない場合、あらゆる形態の保証サービスを提供する機能が大幅に侵害されます。この問題のより良い解決策を提供しない理由はいくつかあります。
Firstly, we do not believe this is a truly solvable problem as it would require changes to the MAC protocol. IEEE 802.1 has examined research showing disappointing simulation results for performance guarantees on shared CSMA/CD Ethernet without MAC enhancements. There have been proposals for enhancements to the MAC layer protocols, e.g. BLAM and enhanced flow control in IEEE 802.3. However, any solution involving an enhanced software MAC running above the traditional IEEE 802.3 MAC, or other proprietary MAC protocols, is outside the scope of the ISSLL working group and this document. Secondly, we are not convinced that it is really an interesting problem. While there will be end stations on shared segments for some time to come, the number of deployed switches is steadily increasing relative to the number of stations on shared segments. This trend is proceeding to the point where it may be satisfactory to have a solution which assumes that any network communication requiring resource reservations will take place through at least one switch or router. Put another way, the easiest upgrade to existing Layer 2 infrastructure for QoS support is the installation of segment switching. Only when this has been done is it worthwhile to investigate more complex solutions involving admission control. Thirdly, the core of campus networks typically consists of solutions based on switches rather than on repeated segments. There may be special circumstances in the future, e.g. Gigabit buffered repeaters, but the characteristics of these devices are different from existing CSMA/CD repeaters anyway.
第一に、MACプロトコルの変更が必要になるため、これが本当に解決可能な問題であるとは考えていません。IEEE 802.1は、MACの強化なしに共有CSMA/CDイーサネットのパフォーマンス保証のための失望したシミュレーション結果を示す研究を調査しました。MACレイヤープロトコルの強化の提案がありました。IEEE 802.3のBLAMと強化フロー制御。ただし、従来のIEEE 802.3 Macまたはその他の独自のMACプロトコルの上で実行されている拡張ソフトウェアMACを含むソリューションは、ISSLLワーキンググループおよびこのドキュメントの範囲外です。第二に、私たちはそれが本当に興味深い問題であると確信していません。これからしばらく共有セグメントにエンドステーションがありますが、展開されたスイッチの数は、共有セグメントのステーションの数に比べて着実に増加しています。この傾向は、リソースの予約を必要とするネットワーク通信が少なくとも1つのスイッチまたはルーターを介して行われると仮定するソリューションを持つことが満足のいく点に進んでいます。別の言い方をすれば、QoSサポートのための既存のレイヤー2インフラストラクチャへの最も簡単なアップグレードは、セグメントスイッチングのインストールです。これが行われた場合にのみ、入学管理を含むより複雑なソリューションを調査する価値があります。第三に、キャンパスネットワークのコアは通常、繰り返されるセグメントではなく、スイッチに基づくソリューションで構成されています。将来的には特別な状況があるかもしれません。ギガビットはリピーターをバッファリングしましたが、これらのデバイスの特性は、とにかく既存のCSMA/CDリピーターとは異なります。
Table 5: Shared Ethernet media access latency
表5：共有イーサネットメディアアクセスレイテンシ
--------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
--------------------------------------------------
Ethernet 10 Mbps 1.2 ms unbounded
100 Mbps 120 us unbounded
1 Gbps 12 us unbounded
--------------------------------------------------
Many of the same arguments for sub optimal support of Guaranteed Service on shared media Ethernet also apply to half duplex switched Ethernet. In essence, this topology is a medium that is shared between at least two senders contending for packet transmission. Unless these are tightly coupled and cooperative, there is always the chance that the best effort traffic of one will interfere with the reserved traffic of the other. Dealing with such a coupling would require some form of modification to the MAC protocol.
共有メディアイーサネットでの保証されたサービスのサブ最適なサポートに関する同じ議論の多くは、半分二重スイッチ付きイーサネットにも適用されます。本質的に、このトポロジーは、パケット送信を競合する少なくとも2人の送信者の間で共有される媒体です。これらがしっかりと結合され、協力的でない限り、一方の最良のトラフィックが他方の予約されたトラフィックを妨げる可能性が常にあります。このような結合を扱うには、MACプロトコルの何らかの形の変更が必要です。
Not withstanding the above argument, half duplex switched topologies do seem to offer the chance to provide Controlled Load service. With the knowledge that there are exactly two potential senders that are both using prioritization for their Controlled Load traffic over best effort flows, and with admission control having been done for those flows based on that knowledge, the media access characteristics while not deterministic are somewhat predictable. This is probably a close enough useful approximation to the Controlled Load service.
上記の議論に耐えられないように、半分二重切り替えトポロジーは、制御された負荷サービスを提供する機会を提供しているようです。最良の努力よりも制御された負荷トラフィックに優先順位付けを使用している2つの潜在的な送信者が正確に2つの潜在的な送信者がいるという知識があり、その知識に基づいてそれらのフローに対して入場制御が行われているため、決定論的ではないがメディアアクセス特性は多少予測可能です。これはおそらく、制御された負荷サービスに十分な有用な近似です。
Table 6: Half duplex switched Ethernet media access latency
表6：ハーフデュプレックススイッチ付きイーサネットメディアアクセスレイテンシ
------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
------------------------------------------
Ethernet 10 Mbps 1.2 ms unbounded
100 Mbps 120 us unbounded
1 Gbps 12 us unbounded
------------------------------------------
In a shared Token Ring network, the network access time for high priority traffic at any station is bounded and is given by (N+1)*THTmax, where N is the number of stations sending high priority traffic and THTmax is the maximum token holding time [14]. This assumes that network adapters have priority queues so that reservation of the token is done for traffic with the highest priority currently queued in the adapter. It is easy to see that access times can be improved by reducing N or THTmax. The recommended default for THTmax is 10 ms [6]. N is an integer from 2 to 256 for a shared ring and 2 for a switched half duplex topology. A similar analysis applies for FDDI.
共有トークンリングネットワークでは、任意のステーションでの優先度の高いトラフィックのネットワークアクセス時間が境界を掲載し、（n 1）*thtmaxによって与えられます。nは優先度の高いトラフィックを送信するステーションの数であり、thtmaxは最大トークン保持時間です[14]。これは、ネットワークアダプターに優先キューがあるため、トークンの予約は、現在アダプターでキューティングされている最高の優先度を持つトラフィックのために行われることを前提としています。NまたはThtmaxを減らすことで、アクセス時間を改善できることがわかります。THTMAXの推奨デフォルトは10ミリ秒です[6]。nは、共有リングの場合は2〜256、切り替えられた半分二重トポロジの場合は2の整数です。同様の分析がFDDIに適用されます。
Table 7: Half duplex switched and shared Token
Ring media access latency
----------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
----------------------------------------------------
Token Ring 4/16 Mbps shared 9 ms 2570 ms
4/16 Mbps switched 9 ms 30 ms
FDDI 100 Mbps 360 us 8 ms
----------------------------------------------------
Given that access time is bounded, it is possible to provide an upper bound for end-to-end delays as required by Guaranteed Service assuming that traffic of this class uses the highest priority allowable for user traffic. The actual number of stations that send traffic mapped into the same traffic class as Guaranteed Service may vary over time but, from an admission control standpoint, this value is needed a priori. The admission control entity must therefore use a fixed value for N, which may be the total number of stations on the ring or some lower value if it is desired to keep the offered delay guarantees smaller. If the value of N used is lower than the total number of stations on the ring, admission control must ensure that the number of stations sending high priority traffic never exceeds this number. This approach allows admission control to estimate worst case access delays assuming that all of the N stations are sending high priority data even though, in most cases, this will mean that delays are significantly overestimated.
アクセス時間が制限されていることを考えると、このクラスのトラフィックがユーザートラフィックに許容される最高の優先度を使用していると仮定して、保証されたサービスで必要なエンドツーエンドの遅延の上限を提供することができます。保証されたサービスと同じトラフィッククラスにマッピングされたトラフィックを送信するステーションの実際の数は、時間の経過とともに異なる場合がありますが、入場管理の観点からは、この値は先験的に必要です。したがって、入場管理エンティティはNに固定値を使用する必要があります。これは、提供された遅延保証を小さく保つことが望まれる場合、リング上のステーションの総数またはある程度の値である場合があります。使用されるnの値がリング上のステーションの総数よりも低い場合、入学制御は、優先度の高いトラフィックを送信するステーションの数がこの数を超えないことを確認する必要があります。このアプローチにより、入場制御は、すべてのNステーションが高い優先度データを送信していると仮定して、最悪のケースアクセス遅延を推定することができます。
Assuming that Controlled Load flows use a traffic class lower than that used by Guaranteed Service, no upper bound on access latency can be provided for Controlled Load flows. However, Controlled Load flows will receive better service than best effort flows.
制御された負荷フローが保証されたサービスで使用されるトラフィッククラスよりも低いトラフィッククラスを使用していると仮定すると、制御された負荷フローにアクセスレイテンシの上限を提供することはできません。ただし、制御された負荷フローは、最良の努力フローよりも優れたサービスを受けるでしょう。
Note that on many existing shared Token Rings, bridges transmit frames using an Access Priority (see Section 4.3) value of 4 irrespective of the user_priority carried in the frame control field of the frame. Therefore, existing bridges would need to be reconfigured or modified before the above access time bounds can actually be used.
多くの既存の共有トークンリングでは、フレームのフレーム制御フィールドにあるuser_priorityに関係なく、アクセスの優先度（セクション4.3を参照）の値（セクション4.3を参照）を使用してフレームを送信することに注意してください。したがって、上記のアクセス時間境界を実際に使用する前に、既存のブリッジを再構成または変更する必要があります。
In IEEE 802.12 networks, communication between end nodes and hubs and between the hubs themselves is based on the exchange of link control signals. These signals are used to control access to the shared medium. If a hub, for example, receives a high priority request while another hub is in the process of serving normal priority requests, then the service of the latter hub can effectively be preempted in order to serve the high priority request first. After the network has processed all high priority requests, it resumes the normal priority service at the point in the network at which it was interrupted.
IEEE 802.12ネットワークでは、エンドノードとハブ間およびハブ間の通信自体が、リンク制御信号の交換に基づいています。これらの信号は、共有媒体へのアクセスを制御するために使用されます。たとえば、ハブが通常の優先度のリクエストを提供するプロセスにある間に、ハブが高い優先リクエストを受信する場合、後者のハブのサービスを最初に高い優先リクエストを提供するために効果的に先制することができます。ネットワークがすべての優先度要求をすべて処理した後、中断されたネットワークのポイントで通常の優先サービスを再開します。
The network access time for high priority packets is basically the time needed to preempt normal priority network service. This access time is bounded and it depends on the physical layer and on the topology of the shared network. The physical layer has a significant impact when operating in half duplex mode as, e.g. when used across unshielded twisted pair cabling (UTP) links, because link control signals cannot be exchanged while a packet is transmitted over the link. Therefore the network topology has to be considered since, in larger shared networks, the link control signals must potentially traverse several links and hubs before they can reach the hub which has the network control function. This may delay the preemption of the normal priority service and hence increase the upper bound that may be guaranteed.
優先度の高いパケットのネットワークアクセス時間は、基本的に通常の優先度ネットワークサービスを先取りするために必要な時間です。このアクセス時間は制限されており、物理レイヤーと共有ネットワークのトポロジに依存します。物理層は、半分二重モードで動作するときに大きな影響を与えます。リンク制御信号を交換できないため、リンク上にパケットが送信されているため、シールドされていないツイストペアケーブル（UTP）リンクで使用する場合。したがって、より大きな共有ネットワークでは、ネットワーク制御機能を持つハブに到達する前に、リンク制御信号がいくつかのリンクとハブを通過する可能性があるため、ネットワークトポロジを考慮する必要があります。これにより、通常の優先度サービスの先制が遅れる可能性があるため、保証される可能性のある上限が増加します。
Upper bounds on the high priority access time are given below for a UTP physical layer and a cable length of 100 m between all end nodes and hubs using a maximum propagation delay of 570 ns as defined in
優先度の高いアクセス時間の上限は、すべてのエンドノードとハブの間でUTPの物理層とケーブル長100 mのケーブルの長さについて、570 nsの最大伝播遅延を使用して、
[19]. These values consider the worst case signaling overhead and assume the transmission of maximum sized normal priority data packets while the normal priority service is being preempted.
[19]。これらの値は、最悪のケースが頭上にシグナリングすることを考慮し、通常の優先度サービスが先制されている間、最大サイズの通常の優先度データパケットの送信を想定しています。
Table 8: Half duplex switched Demand Priority UTP access latency
表8：ハーフデュプレックスの切り替え需要優先度UTPアクセス待ち時間
------------------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
------------------------------------------------------------
Demand Priority 100 Mbps, 802.3 pkt, UTP 120 us 254 us
802.5 pkt, UTP 360 us 733 us
------------------------------------------------------------
Shared IEEE 802.12 topologies can be classified using the hub cascading level "N". The simplest topology is the single hub network (N = 1). For a UTP physical layer, a maximum cascading level of N = 5 is supported by the standard. Large shared networks with many hundreds of nodes may be built with a level 2 topology. The bandwidth manager could be informed about the actual cascading level by network management mechanisms and can use this information in its admission control algorithms.
共有IEEE 802.12トポロジーは、ハブカスケードレベル「n」を使用して分類できます。最も単純なトポロジは、単一のハブネットワーク（n = 1）です。UTPの物理層の場合、n = 5の最大カスケードレベルが標準によってサポートされています。レベル2トポロジーで何百ものノードを備えた大きな共有ネットワークを構築できます。帯域幅マネージャーは、ネットワーク管理メカニズムによって実際のカスケードレベルについて通知することができ、この情報を入学制御アルゴリズムで使用できます。
In contrast to UTP, the fiber optic physical layer operates in dual simplex mode. Upper bounds for the high priority access time are given below for 2 km multimode fiber links with a propagation delay of 10 us.
UTPとは対照的に、光ファイバーの物理層はデュアルシンプレックスモードで動作します。優先度の高いアクセス時間の上限は、10 USの伝播遅延を伴う2 kmのマルチモードファイバーリンクについて以下に示されています。
For shared media with distances of up to 2 km between all end nodes and hubs, the IEEE 802.12 standard allows a maximum cascading level of 2. Higher levels of cascaded topologies are supported but require a reduction of the distances [15].
すべてのエンドノードとハブの間に最大2 kmの距離を持つ共有メディアの場合、IEEE 802.12標準では、最大カスケードレベル2を可能にします。
The bounded access delay and deterministic network access allow the support of service commitments required for Guaranteed Service and Controlled Load, even on shared media topologies. The support of just two priority levels in 802.12, however, limits the number of services that can simultaneously be implemented across the network.
制限されたアクセス遅延と決定論的なネットワークアクセスにより、共有されたメディアトポロジであっても、保証されたサービスと制御された負荷に必要なサービスコミットメントのサポートが可能になります。ただし、802.12の2つの優先レベルのみのサポートにより、ネットワーク全体で実装できるサービスの数が制限されます。
Table 9: Shared Demand Priority UTP access latency
表9：共有需要の優先度UTPアクセスレイテンシ
----------------------------------------------------------------
Type Speed Max Pkt Max Access Topology
Length Latency
----------------------------------------------------------------
Demand Priority 100 Mbps, 802.3 pkt 120 us 262 us N = 1
120 us 554 us N = 2
120 us 878 us N = 3
120 us 1.24 ms N = 4
120 us 1.63 ms N = 5
Demand Priority 100 Mbps, 802.5 pkt 360 us 722 us N = 1
360 us 1.41 ms N = 2
360 us 2.32 ms N = 3
360 us 3.16 ms N = 4
360 us 4.03 ms N = 5
-----------------------------------------------------------------
Table 10: Half duplex switched Demand Priority
fiber access latency
-------------------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
-------------------------------------------------------------
Demand Priority 100 Mbps, 802.3 pkt, fiber 120 us 139 us
802.5 pkt, fiber 360 us 379 us
-------------------------------------------------------------
Table 11: Shared Demand Priority fiber access latency
表11：共有需要優先ファイバーアクセスレイテンシ
---------------------------------------------------------------
Type Speed Max Pkt Max Access Topology
Length Latency
---------------------------------------------------------------
Demand Priority 100 Mbps, 802.3 pkt 120 us 160 us N = 1
120 us 202 us N = 2
Demand Priority 100 Mbps, 802.5 pkt 360 us 400 us N = 1
360 us 682 us N = 2
---------------------------------------------------------------
An obvious concern is the complexity of this model. It essentially does what RSVP already does at Layer 3, so why do we think we can do better by reinventing the solution to this problem at Layer 2? The key is that there are a number of simple Layer 2 scenarios that cover a considerable portion of the real QoS problems that will occur. A solution that covers the majority of problems at significantly lower cost is beneficial. Full RSVP/IntServ with per flow queuing in strategically positioned high function switches or routers may be needed to completely resolve all issues, but devices implementing the architecture described in herein will allow for a significantly simpler network.
明らかな懸念は、このモデルの複雑さです。基本的に、RSVPがレイヤー3ですでに行っていることです。レイヤー2でこの問題の解決策を再発明することで、なぜ私たちはより良いことができると思うのでしょうか？重要なのは、発生する実際のQoS問題のかなりの部分をカバーする多くの単純なレイヤー2シナリオがあることです。大部分の問題を大幅に低いコストでカバーするソリューションは有益です。すべての問題を完全に解決するには、戦略的に配置された高機能スイッチまたはルーターでのフローごとのキューイングを備えたフルRSVP/IntServが必要になる場合がありますが、ここに記載されているアーキテクチャを実装するデバイスは、大幅に単純なネットワークを可能にします。
This document has specified a framework for providing Integrated Services over shared and switched LAN technologies. The ability to provide QoS guarantees necessitates some form of admission control and resource management. The requirements and goals of a resource management scheme for subnets have been identified and discussed. We refer to the entire resource management scheme as a Bandwidth Manager. Architectural considerations were discussed and examples were provided to illustrate possible implementations of a Bandwidth Manager. Some of the issues involved in mapping the services from higher layers to the link layer have also been discussed. Accompanying memos from the ISSLL working group address service mapping issues [13] and provide a protocol specification for the Bandwidth Manager protocol [14] based on the requirements and goals discussed in this document.
このドキュメントは、共有および切り替えのLANテクノロジーを介して統合サービスを提供するためのフレームワークを指定しています。QoS保証を提供する機能には、何らかの形の入場管理とリソース管理が必要です。サブネットのリソース管理スキームの要件と目標が特定され、議論されています。リソース管理スキーム全体を帯域幅マネージャーと呼びます。帯域幅マネージャーの実装の可能性を示すために、建築上の考慮事項が議論され、例が提供されました。高レイヤーからリンク層へのサービスのマッピングに伴う問題のいくつかも議論されています。ISSLLワーキンググループのメモに付随するメモは、サービスマッピングの問題[13]に伴い、このドキュメントで説明した要件と目標に基づいて、帯域幅マネージャープロトコル[14]のプロトコル仕様を提供します。
References
参考文献
[1] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.
[1] ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ、ANSI/IEEE STD 802、1990。
[2] ISO/IEC 10038 Information technology - Telecommunications and information exchange between systems - Local area networks - Media Access Control (MAC) Bridges, (also ANSI/IEEE Std 802.1D-1993), 1993.
[2] ISO/IEC 10038情報技術 - システム間の通信と情報交換 - ローカルエリアネットワーク - メディアアクセス制御（MAC）ブリッジ、（ANSI/IEEE STD 802.1D -1993）、1993年。
[3] ISO/IEC 15802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) bridges (also ANSI/IEEE Std 802.1D-1998), 1998.
[3] ISO/IEC 15802-3情報技術 - システム間の電気通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 共通仕様 - パート3：メディアアクセス制御（MAC）ブリッジ（ANSI/IEEE STD 802.1D -1998）、1998年。
[4] IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks, IEEE Std 802.1Q-1998, 1998.
[4] ローカルおよびメトロポリタンエリアネットワークのIEEE標準：仮想ブリッジ型ローカルエリアネットワーク、IEEE STD 802.1Q-1998、1998。
[5] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[5] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[6] Wroclawski, J., "Specification of the Controlled Load Network Element Service", RFC 2211, September 1997.
[6] Wroclawski、J。、「制御された負荷ネットワーク要素サービスの仕様」、RFC 2211、1997年9月。
[7] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[7] Shenker、S.、Partridge、C。and R. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[8] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", RFC 1633, June 1994.
[8] Braden、R.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[9] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[9] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[10] Shenker, S. and J. Wroclawski, "Network Element Service Specification Template", RFC 2216, September 1997.
[10] Shenker、S。およびJ. Wroclawski、「ネットワーク要素サービス仕様テンプレート」、RFC 2216、1997年9月。
[11] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[11] Shenker、S。およびJ. Wroclawski、「統合されたサービスネットワーク要素の一般的な特性評価パラメーター」、RFC 2215、1997年9月。
[12] Delgrossi, L. and L. Berger (Editors), "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 1995.
[12] Delgrossi、L。およびL. Berger（編集者）、「インターネットストリームプロトコルバージョン2（ST2）プロトコル仕様 - バージョンST2」、RFC 1819、1995年8月。
[13] Seaman, M., Smith, A. and E. Crawley, "Integrated Service Mappings on IEEE 802 Networks", RFC 2815, May 2000.
[13] Seaman、M.、Smith、A。、およびE. Crawley、「IEEE 802ネットワークの統合サービスマッピング」、RFC 2815、2000年5月。
[14] Yavatkar, R., Hoffman, D., Bernet, Y. and F. Baker, "SBM Subnet Bandwidth Manager): Protocol for RSVP-based Admission Control Over IEEE 802-style Networks", RFC 2814, May 2000.
[14] Yavatkar、R.、Hoffman、D.、Bernet、Y。、およびF. Baker、「SBM Subnet Bandwidth Manager）：IEEE 802スタイルネットワークのRSVPベースの入学制御のプロトコル、RFC 2814、2000年5月。
[15] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 1996.
[15] ISO/IEC 8802-3情報技術 - システム間の電気通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 共通仕様 - パート3：キャリアセンス衝突検出付きの複数アクセス（CSMA/CD）アクセス法と物理層仕様（また）/IEEE STD 802.3- 1996）、1996。
[15] ISO/IEC 8802-5 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 5: Token Ring Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.5-1995), 1995.
[15] ISO/IEC 8802-5情報技術 - システム間の電気通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 共通仕様 - パート5：トークンリングアクセス方法と物理レイヤー仕様（ANSI/IEEE STD 802.5-1995）、1995年。
[17] Postel, J. and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, February 1988.
[17] Postel、J。およびJ. Reynolds、「IEEE 802ネットワークを介したIPデータグラムの送信の標準」、STD 43、RFC 1042、1988年2月。
[18] C. Bisdikian, B. V. Patel, F. Schaffa, and M Willebeek-LeMair, The Use of Priorities on Token Ring Networks for Multimedia Traffic, IEEE Network, Nov/Dec 1995.
[18] C. Bisdikian、B。V。Patel、F。Schaffa、およびM Willebeek-Lemair、マルチメディアトラフィックのトークンリングネットワークでの優先順位の使用、IEEEネットワーク、1995年11月。
[19] IEEE Standards for Local and Metropolitan Area Networks: Demand Priority Access Method, Physical Layer and Repeater Specification for 100 Mb/s Operation, IEEE Std 802.12-1995.
[19] ローカルおよびメトロポリタンエリアネットワークのIEEE標準：100 MB/s操作の需要優先アクセス方法、物理層、リピーター仕様、IEEE STD 802.12-1995。
[20] Fiber Distributed Data Interface MAC, ANSI Std. X3.139-1987.
[20] ファイバー分散データインターフェイスMac、ANSI STD。X3.139-1987。
[21] ISO/IEC 15802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Supplement to Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Frame Extensions for Virtual Bridged Local Area Network (VLAN) Tagging on 802.3 Networks, IEEE Std 802.3ac-1998 (Supplement to IEEE 802.3 1998 Edition), 1998.
[21] ISO/IEC 15802-3情報技術 - システム間の電気通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 特定の要件 - キャリアセンス衝突検出付きマルチアクセス（CSMA/CD）アクセス方法と物理層の仕様 - 仮想のフレーム拡張機能802.3ネットワークでのBridged Local Area Network（VLAN）タグ付け、IEEE STD 802.3AC-1998（IEEE 802.3 1998版の補足）、1998。
Security Considerations
セキュリティに関する考慮事項
Implementation of the model described in this memo creates no known new avenues for malicious attack on the network infrastructure. However, readers are referred to Section 2.8 of the RSVP specification [5] for a discussion of the impact of the use of admission control signaling protocols on network security.
このメモで説明されているモデルの実装は、ネットワークインフラストラクチャに対する悪意のある攻撃のための既知の新しい道を作成しません。ただし、読者は、ネットワークセキュリティに対するアニメーション制御シグナル伝達プロトコルの使用の影響について議論するために、RSVP仕様[5]のセクション2.8に紹介されています。
Acknowledgements
謝辞
Much of the work presented in this document has benefited greatly from discussion held at the meetings of the Integrated Services over Specific Link Layers (ISSLL) working group. We would like to acknowledge contributions from the many participants via discussion at these meetings and on the mailing list. We would especially like to thank Eric Crawley, Don Hoffman and Raj Yavatkar for contributions via previous Internet drafts, and Peter Kim for contributing the text about Demand Priority networks.
このドキュメントで提示された作業の多くは、特定のリンクレイヤー（ISSLL）ワーキンググループを介した統合サービスの会議で開催された議論から大きな恩恵を受けています。これらの会議およびメーリングリストでの議論を通じて、多くの参加者からの貢献を認めたいと思います。特に、以前のインターネットドラフトを介した貢献について、エリック・クローリー、ドン・ホフマン、ラジ・ヤヴァトカル、および需要優先ネットワークに関するテキストに貢献してくれたピーター・キムに感謝します。
Authors' Addresses
著者のアドレス
Anoop Ghanwani Nortel Networks 600 Technology Park Dr Billerica, MA 01821, USA
Anoop Ghanwani Nortel Networks 600 Technology Park Dr Billerica、MA 01821、米国
Phone: +1-978-288-4514
EMail: aghanwan@nortelnetworks.com
Wayne Pace IBM Corporation P. O. Box 12195 Research Triangle Park, NC 27709, USA
ウェインペースIBM Corporation P. O. Box 12195 Research Triangle Park、NC 27709、米国
Phone: +1-919-254-4930
EMail: pacew@us.ibm.com
Vijay Srinivasan CoSine Communications 1200 Bridge Parkway Redwood City, CA 94065, USA
Vijay Srinivasan Cosine Communications 1200 Bridge Parkway Redwood City、CA 94065、米国
Phone: +1-650-628-4892
EMail: vijay@cosinecom.com
Andrew Smith Extreme Networks 3585 Monroe St Santa Clara, CA 95051, USA
Andrew Smith Extreme Networks 3585 Monroe St Santa Clara、CA 95051、米国
Phone: +1-408-579-2821
EMail: andrew@extremenetworks.com
Mick Seaman Telseon 480 S. California Ave Palo Alto, CA 94306 USA
Mick Seaman Telseon 480 S. California Ave Palo Alto、CA 94306 USA
Email: mick@telseon.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。