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
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.
著作権（C）インターネット協会（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統合サービスをサポートするためのフレームワークについて説明します。このようなアクセスのレイテンシ、遅延変動や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]、これは、このような制御されたロードおよび保証サービス[6,7]として、IETFの統合サービスワーキンググループによってネットワークサービスの様々なクラスの仕様を牽引してきました。これらのサービスクラスのそれぞれは、パラメータの指定されたセットに準拠するトラフィックへのサービス（QoS）の一定の品質を提供するように設計されています。アプリケーションは、そのQoS要件に応じて、これらのクラスのいずれかを選択することが期待されています。 IPネットワークにおいて、このようなサービスを利用するエンドステーションのための一つのメカニズムは、プロトコル、リソース予約プロトコル（RSVP）をQoSシグナリングによって提供されている[5] IETFのRSVPワーキンググループによって開発されました。そのプロジェクト802の下のIEEEは、多くの異なるローカル・エリア・ネットワーク技術の標準を定義しています。彼らはしばしば異なる動的挙動特性を提供するが、これらはすべて、一般的なIPなどの上位層プロトコルに[1]と同じMACレイヤデータグラムサービスを提供しています - それは、リアルタイムサービスをサポートする能力を検討する際に重要であり、これらのです。その後、このメモでは、我々は異なるMACレイヤLAN技術の関連する特性のいくつかを説明します。また、IEEE 802 [2]「MACブリッジ」または「スイッチ」として知られているデバイスを使用して一緒に複数のLANセグメントをブリッジするための基準を定義しています。最近の研究はまた、[3,4]トラフィッククラス、マルチキャストフィルタリング、およびこれらのデバイスの仮想LAN機能を定義しました。このようなLAN技術は、多くの場合、ユーザーとインターネットの間に最後のホップ（複数可）を構成するだけでなく、全体をキャンパスネットワークの主要なビルディング・ブロックであること。エンドツーエンドのリアルタイムサービスをサポートするために、これらの技術を使用するための標準化されたメカニズムを提供することが必要です。これを行うためには、データリンク層でのリソース管理のためのいくつかのメカニズムが存在しなければなりません。などのリソース、この文脈での管理アドミッション制御の機能を包含し、スケジューリング、トラフィックポリシング、IETFにおける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の機能についての議論と、セクション4で始まる共有し、イーサネット/ IEEE 802.3としてLAN技術を切り替え、トークンリング/ IEEE 802.5、FDDIなどの上に統合サービスを提供するためのフレームワークを指定すると懸念していますMAC層技術。第5節では、LANに統合サービスを提供することが可能な仕組みのための要件と目標を示しています。第5節で概説リソース管理機能は、帯域幅マネージャ（BM）と呼ばれるエンティティによって提供されます。 BMの建築モデルはセクション6に記載されており、その様々な構成要素は、セクション7に記載されているサービス統合のためのリンク層支持体に対するいくつかの実装上の問題はセクション9はLAN技術のトポロジの分類について説明し、セクション8で検討されています統合サービスを有効に活用することができ、それぞれの機能に重点を置いて検討中。このフレームワークは、リンク層でのトポロジを想定していません。フレームワークは、できるだけ網羅することを意図しています。説明したすべての機能が特定のトポロジーまたは技術によってサポート可能ではないかもしれないことが可能であることを意味するが、これは、このモデルの使用を妨げてはなりません。
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.
- セグメント：一つ以上の送信者によって共有される物理L2セグメント。セグメントの例としては、（a）は、CSMAまたはトークンパッシングを使用してメディアアクセスのための共有イーサネットまたはトークンリングワイヤ解決競合。 （B）は、2つの局またはスイッチ間の半二重リンク。 （C）に切り替え、全二重リンクの一方向。
- 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.
- 管理セグメント：管理セグメント存在し、リソース予約の要求を超えるアドミッション制御を実行するための責任を負う（指定されたサブネット帯域幅マネージャ、[14]参照）DSBM有するセグメントです。管理セグメントは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.
- サブネット：それらが配置されているL2ドメインを構成するセグメントのセットと一緒に共通のL3ネットワークアドレスプレフィックスを共有L3装置のグループを示すために、このメモで使用されます。
- 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.
- ブリッジ/スイッチ：レイヤ2フォワーディングデバイスIEEE 802.1Dによって定義される[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.3は、それを運ぶしませんが、トークンリング/ IEEE 802.5は、そのFCオクテットで符号化され、この値を運びます。 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の仕様は、user_priorityは、エンドステーションまたはネットワークで使用する方法についての仮定を行いません。 IEEE 802.1Dは、複数のキューを実装するスイッチのデフォルトの動作モードとして、静的プライオリティキューイングを定義しますが、それは実際にスイッチによって実装されるトラフィッククラスの数に依存するため、user_priorityは本当に唯一の緩い意味での優先事項です。 user_priorityは、最高の優先順位と最低として0の値を表す7の値を有する3ビットの量として定義されます。次のように一般的なスイッチのアルゴリズムがあります。パケットが受信されたuser_priority、IEEE 802.1QヘッダーまたはIEEE 802.5ネットワークが使用されている、またはいくつかのローカルポリシーに従って割り当てられている場合、パケットから直接取得されるか、その値に基づいて、特定のトラフィッククラス内のキューに入れられます。キューは、利用可能なトラフィッククラスの数へuser_priority（0〜7）からのマッピングに基づいて選択されます。スイッチは、1つまたは複数のトラフィッククラスを実装することができます。宣伝イントサーブパラメータとスイッチのアドミッションコントロールの動作は、スイッチ内のトラフィッククラスへの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の値を選択すべきかについての提言を行うものではありません。この文書の主な目的の一つは、このような使用規則を提案し、スイッチとエンドステーションとの間のこれらの値のセマンティクスの通信を議論することです。この文書の残りの部分では、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パケットのカプセル化のために、以下を含むIPパケットの長さを指し、「ip_len」、ここでは表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_len 802.1D / QオーバーIPのEtherType <= 42）* 64 ip_len 1500（1500> = ip_len> = 42バイト）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規格を使用して、イーサネットフレームのパケット長が4バイトで現在のIEEE 802.3最大パケット長値を超えたことに留意されたいです。 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]は、送信のためのパケットのキューイングおよび共有メディアへのパケットのアクセスの両方を制御するために使用できる優先順位メカニズムを提供します。優先メカニズムはアクセス制御（AC）とLLCフレームのフレーム制御（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.
トークンリングステーションは、別々に要求user_priorityの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.
優先度の高いトラフィックに関連するフレームジッターを低減するために、附属書はまた、唯一のフレームがトークンごと遅延に敏感なトラフィックがリングを通過するたびに最大情報フィールドのサイズは4399個のオクテットであることを送信することをお勧めします。フォワードトークンリングブリッジIが推奨4附属書のデフォルトのアクセス優先順位を有する全てのLLCフレームのほとんどの既存の実装は、（user_priorityに等しい予約とuser_priorityより大きい4を有するブリッジフォワード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]共有100Mbpsの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フレームフォーマットが使用される場合user_priorityをさらにIEEE 802.5パケットヘッダにおけるFCフィールドのYYYビットで符号化される（セクション4.3参照）。また、独自のuser_priorityフィールドを持つIEEE 802.1Qカプセル化はまた、IEEE 802.12ネットワークに適用することができます。すべての場合において、スイッチは、送信者によって提供される任意のuser_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.
同じルールが他のメディアタイプと同様に、ブリッジにIEEE 802.12 user_priorityマッピングに適用します。唯一の追加情報は、通常の優先度が0〜4包括user_priority値にデフォルトで使用され、高い優先度が7を介して5 user_priorityレベルのために使用される。これは、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のLAN内の媒体アクセスが決定的です。デマンドプライオリティメカニズムは、通常の優先度のサービスが先取りされた後、すべての優先度の高いパケットは通常の優先度を持つパケットを厳密に優先権を持っている、ということを保証します。通常の優先度のパケットがPACKET_PROMOTIONよりも長い期間のMAC送信キューの行の先頭に待機していた場合には（200から300ミリ秒）[19]は、その優先度は自動的に高い優先度に促進されます。このように、でも、通常の優先度のパケットは、メディアへの最大保証アクセス時間を持っています。
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.
セクション4.2および4.3で報告されたようにIEEE 802.12規格は、IEEE 802.3およびIEEE 802.5フレーム形式、同一のフレーミングオーバーヘッドをサポートするためのIEEE 802.12リンクのアドミッション制御の計算に考慮しなければなりません。
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セッションを開始するルータは、ルータによって送信されたすべてのフローが適合していることを保証するであろうイントサーブ要件に従ってトラフィック制御メカニズムを実装している必要があります。リンク層での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などの上位層プロトコルとは無関係であるべきです。そのようなST2 [10]など、他の予約プロトコルと連動できるようにRSVPから独立であることが望ましいです。それは等IPX、NetBIOSのような他のネットワーク層プロトコルと連動できるように、IPから独立であることが望ましいです
- 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.
- 受信機の異質性：これは、異なる受信機が異なるレベルのサービスを要求するマルチキャスト通信を指します。例えば、多くの受信機と、マルチキャストグループでは、受信機の一つが他のものよりも下限遅延を望む可能性があります。結合したよりよい遅延は変更されない他の受信機の予約を残しながらその受信機へのパスに沿って予約されたリソースの量を増加させることによって提供されてもよいです。その最も複雑な形態では、受信機の異質性は、異なる受信機によって要求されるように同時にサービスのさまざまなレベルを提供する能力を意味しています。最も単純な形式では、受信機の異質性は、受信機のいくつかは、ベストエフォート型のサービスを利用し、サービス保証を必要とするものは予約をするシナリオが可能になります。レシーバの異質性は、特に、予約/ベストエフォートのシナリオのために、非常に望ましい機能です。受信機の異質性をサポートに関する詳細は、セクション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.
私たちは、上位層のQoSシグナリングプロトコルとしてRSVPを使用して、このモデルのためにほとんどの例を示しているが、実際にこのプロトコルには、実際の依存関係はありません。 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.
そこ[2,3] IEEE 802.1Dとのすべての準拠、異なる機能を持つスイッチの異種混合であるが、二つのポートごとのキューと静的優先度スケジューリングを持つ単純なシステムに至るまで多様なキューイングおよび転送メカニズムを実装するとより複雑なシステムにすることができます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は、ネットワークからQoSを要求するアプリケーションまたは上位層プロトコルのためのメカニズムを提供する責任があります。建築の目的のために、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
リクエスタモジュール（RM）は、サブネット内のすべてのエンドステーションに常駐します。その機能の一つは、アプリケーションまたはそのようなRSVP、ST2、SNMPなど、およびBMのような上位層プロトコルとの間のインタフェースを提供することです。アプリケーションは、RMとの通信のためのプリミティブを使用して、適切なパラメータでそれを提供することにより、BMの様々な機能を呼び出すことができます。するリソースの量を指定したいサービス（保証サービスまたは制御されたロード）、TSpecの中に含まれるトラフィック記述子、およびRSpecの：予約を開始するには、リンク層ドメインで、次のパラメータがRMに渡される必要があります予約された[9]。これらのパラメータの詳細については、[6,7,8,9]の関連するサービス統合型ドキュメントで見つけることができます。 RSVPは、ネットワーク層でのシグナリングのために使用される場合、この情報が利用可能であるとのRSVP PATH及びRSVP RESVメッセージから抽出される必要がある（詳細については[5]を参照）。に加えて
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は、その後、層アドレスをリンクし、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は、これらのプリミティブはに適用するためのAPIとして実装することができなどのアプリケーション、予約を開始し、利用可能なリソースについてのBAを照会、変更の変更や予約を削除するには、のためのプリミティブを定義する必要があります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.
- ピアのBA間の通信：サブネット内の複数のBAがある場合、手段は、インターBAの通信のために指定されなければなりません。具体的には、BASがBAは、どのセグメントおよびブリッジやスイッチの責任を負うことになるかについての自分たちの中で決めることができなければなりません。要求が複数のBAのドメインに沿ってリソース予約のために作られている場合また、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の実装、リソース予約および入場制御を担当する構成要素を指します。以下の図では、「アプリ」とは、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が含まれています。彼らは積極的にアドミッション制御に参加されることはありませんので、ネットワーク内の中間ブリッジおよびスイッチは、BMのいずれかの機能を有する必要はありません。予約を要求するエンドステーションでのRMは、BAとの通信を開始します。大きなサブネットのために、単一のBAは、サブネット全体の予約を扱うことができないかもしれません。その場合、各セグメントの重複しないサブセットのリソースを管理し、複数のBAを展開する必要があります。集中型の実装において、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
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デバイスでのQoSを扱う実体を意味する用語「クライアント」を使用するIntServとRSVPと同じクライアントモデルを前提としています。このモデルでは、送信側クライアントがネゴシエートサービスに応じて、そのリンクの上にローカルアドミッション制御とパケットスケジューリングを担当しています。イントサーブモデルと同じように、これは、すべて、このような元のノードで可能なトラフィック・シェーピング/ポリシングと流れスケジューリングごとに必要とします。
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.
クライアント内のローカルアドミッション制御エンティティは、レイヤ2つのセマンティクスにマッピングするレイヤ3セッション確立要求をする責任があります。
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
<トラフィック特性> =送信者Tspecは（例えば帯域幅、バースト、MTU）<性能要件> =たFlowSpec（例えば、遅延、ジッタ限界）<ここ> = IPアドレス（ES）<そこ> = IPアドレス（ES） - マルチキャストであってもよいです
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]に記載されているように集中BA、例えば、「サブネット帯域幅マネージャー」（SBM）によって実現されます。この集中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スイッチの動作のモデルは、アドミッション制御プロトコルの例として、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.
- ローカルアドミッションコントロールモジュール：そのポートに接続されたリンク上で利用可能な帯域幅のために、各ポートのアカウントにこれらの一つ。半二重リンクについては、これは送信およびフローを受信の両方に割り当てられたリソースを考慮して必要とします。全二重リンクについては、入力ポート会計士の仕事は簡単です。
- 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つのインスタンスは、クライアントまたは他のスイッチとのピアリングのためのシグナリングプロトコルの「ネットワーク」側を行います。また、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「ルーティングテーブル」を参照されたい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にこの情報が既に受信MACサービスによって復号化され、潜在的に（[3]のセクション3.7.3を参照）転送処理によって再マップされた再生user_priorityパラメータで切り替えます。これは、個々のイントサーブフローの分類として、より洗練された分類規則を排除するものではありません。キューおよびスケジューラは、ポートの出力キューを実装し、約束の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.
- 出力トラフィッククラスマッピングモジュール：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.
- イングレス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.
- 入口DSBMは、入力ポート/リンク上のリソースの割り当ての現在の状態を観察した後、マップされたトラフィッククラスから新しいリソース割り当てを収容することができるか否かを判断します。受け入れた場合、要求は、予約のプロパゲータに渡されます。
- If the ingress SBM is not the "Designated SBM" for this link then it directly passes the request on to the reservation propagator.
- イングレス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.
- 要求は、このスイッチによって受け入れられた場合、選択された各出力リンク上で伝搬されます。転送された要求に記載される任意のuser_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.
- 受け入れた場合、スイッチはその流れに属するパケットに使用するuser_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つのアドレスは、マッピングを実行するレイヤすなわちシグナル伝達に関与するスイッチ3の情報を有する必要を回避するために、そのシグナリングメッセージに含めるためにSBMによって必要とされます。
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サービスモデルによって定義されたプリミティブ送信パケットで渡されるパラメータの一つです。
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ヘッダーは、フローのトラフィックを識別するために使用される（FilterSpecにに加えて）パターンであってもよいです。
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 )
ステータス= 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（アウトポート、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保証の様々な程度を提供する様々なサービスクラスを定義しています。初期の努力は、[7] [6]負荷制御を可能に集中し、保証サービスクラスます。制御されたロードサービスは非公式に「ベストエフォートと同じで無負荷ネットワーク上だろう」と述べた緩い保証を提供します。保証サービスは、任意のパケットの伝送遅延の上限を提供します。これらのサービスは、リンク層でサポートできる程度には使用トポロジーと技術を含む多くの要因に依存します。マッピングの問題のいくつかは、新興リンク層の規格と上位層プロトコルがサポートしている機能に照らして、以下に説明されています。トポロジのいくつかの制限を考慮すると、与えられたトポロジーに統合サービスのためのすべての要件を満たすことができないかもしれません。このような場合には、最も実用的な例で十分であろうサービスの近似のためのサポートを提供することを検討するのに便利です。例えば、制御されたロード仕様によって要求されるように各ネットワーク要素（ブリッジ/スイッチ）でシェーピング/ポリシングを提供することが可能ではないかもしれません。このタスクは、エンドステーションに残っている場合でも、サービスを合理的に良好な近似値を得ることができます。
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ブリッジ/スイッチがあります。私たちは、その1は、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規格の任意の部分を実装するブリッジ/スイッチです。またごと出力ポートに基づいて送信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.
なぜならネットワークのプロビジョニングに選択肢をスケーリングのコネクションレスパケット一般的にネットワーク、特に、作業中のLANは、今日。ネットワークの過負荷は稀で、一時的なものと予想される負荷が非常にあるように、一般的に、過剰な帯域幅およびバッファリングは、統計に基づいて実行するように彼らの透過窓を引き起こすことがしばしば十分な上位層プロトコルによってソーストラフィックを吸収するために、ネットワークでプロビジョニングされました低いです。
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.
タイムクリティカルなトラフィックの出現により、このようなオーバープロビジョニングはるかに簡単に達成することになっています。タイムクリティカルなフレームは、例えば、特に、ネットワークのボトルネックポイントで、ファイル転送トラフィックの一時的なバーストの背後にある時間のうるさく長時間キューに入れることができます配線クローゼットにライザーとデスクトップスイッチからユーザへの最後のリンクとの間に発生する可能性が10 Mbpsの遷移に100Mbpsで。それは事前に知られているこの場合、しかしながら、（いずれかのアプリケーションの設計によって、または管理制御により、統計に基づいて）そのタイムクリティカルなトラフィックは、全帯域幅のごく一部であり、それはそれを完全プライオリティを与えることで十分非タイムクリティカルなトラフィックオーバー。ミリ秒未満で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.
複数の優先サービスは、ネットワーク要素によって提供される、例えばスケジューリング規律のための要件がより複雑になって、制御された負荷だけでなく、保証サービスの両方をサポートしています1。サービスクラスの間に必要な絶縁を提供するために、おそらく、それらを別々にキューイングする必要があります。アドミッション制御と、よりインテリジェントなキューイング規則の組み合わせを必要とするキューにサービスを提供する方法の問題は、あります。サービス仕様そのものと同じように、アルゴリズムをキューイングの仕様は、このドキュメントの範囲を超えています。
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つのプライオリティレベルをサポートしています。イーサネット/ 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.
イントサーブの文脈で議論してもう一つのトピックは、ネットワークとの交渉さトラフィック契約を超えるソースからのデータ・フローのトラフィックを処理する方法です。いくつかの約束を示しアプローチが後退することから、通常は「ベストエフォート」のサービスを付与されたトラフィックを保護するために「最善の努力よりもやや少ない」サービスで、このようなトラフィックを処理することです。ベストエフォートトラフィックは、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に通常のベストエフォート型トラフィックを割り当てることとフローが使用している場合は特に、これを行うことから生じる可能性のある並べ替えの問題は、このソリューションは望ましくないものかもしれないが下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値を信頼しなくてもよく、値のいくつかのより適切なセットにこれらをマッピングすることを望むかもしれません。データは、ネットワークの異なる領域に/から流れる代わりに、機器の制限又は遷移期間におそらく、user_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.
一部のスイッチは、値のいくつかの内部設定に受信user_priorityをマップ入力にそのような機能を実装することができます。この機能は、ユーザプライオリティ再生テーブルとしてIEEE 802.1Dで知られているテーブルによって提供される（表3-1 [3]）。これらの値は、発信user_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は、受信器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で、イントサーブモデルは、ツリーの異なるブランチが所定のマルチキャスト送信先の予約の種類を持つことができる場所マルチキャストのための異種の受信機は流れができます。また、木が予約されたフローといくつか使用してベストエフォートサービスといくつかの分岐を有していてもよいという概念をサポートしています。我々はで定義されるような単一のネットワーク要素としてのレイヤ2サブネットを治療した場合、[8]、次いで、サブネット内にある配信ツリーの枝の全てが同一のQoS処理を必要とすると仮定することができ、原子として扱われます単位この仮定により等、アドミッション制御に関しては、既にのIntServとRSVPによって定義されたモデルとプロトコルが既にマルチキャスト不均一性のために十分な支持を提供します。サブネット内のただ一つのリンクはサブネット全体のための予約要求の拒否につながるオーバーサブスクライブされているため、受付制御要求を十分に拒否されてもよいことが、注意してください。
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は、ベストエフォート型のサービスを使用してフローを受け取りたいながら流れのために予約をしたいと思います。 Sは、R1とR2の両方にマルチキャストされたRSVP PATHメッセージを送信します。 R1は、リソースの予約を要求するSへのRSVP RESVメッセージを送信します。
+-----+
| 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へのインタフェースでベストエフォートトラフィッククラスを使用しながら、R1との界面での予約トラフィッククラスに対応するサービスを提供するパケットを転送し、いくつかのメカニズムが存在しなければなりません。これは、フレーム自体の内容を変更する、又は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.
異種の受信機を支持するための別の可能性は、異なるMACアドレスを持つサービスの各クラスのための1つの別個のグループを持っているであろう。デフォルトでは、受信機は、フローはベストエフォートとして分類され、「ベストエフォート」グループに参加します。受信機が正常に予約をした場合、それは、所望のサービスクラスのためのグループに転送することができます。 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値、または明示的な値が存在しない場合に、入力ポートごとに再生値を使用します。複数のトラフィッククラスをサポートする任意の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.
スイッチが入ってくるだけuser_priorityに基づいて、ポートの出力キューごとに選択した場合、IEEE 802.1Dによって記載されているように、それは同じキューイングメカニズムとそのuser_priorityクラス内のすべてのマルチキャストセッションのすべての分岐を扱う必要があります。レシーバの異質性は、不可能であり、これは十分に起因するオーバーサブスクライブされた単一のリンクに全体のマルチキャストセッションのためのアドミッション制御要求の失敗につながる可能性があります。そのレイヤ2の場合におけるRSVP / IntServの、いくつかの受信機が要求されたQoSとのセッションを取得し、いくつかの基本的なIEEE 802.1スイッチは再することができないとして、それが最善の努力が存在しないになったのオプションを使用して、レイヤ3の場合は異なるように注意してくださいリンクごとにuser_priorityを-map。これは、動的マルチキャストセッションを頻繁に使用して問題になる可能性があります。スイッチは、各出力ポートにおける別user_priorityマッピングを実装した場合、その後、いくつかのケースでは、予約が異なるQoSを有する複数の受信機を提供するために、このようなスイッチでその分岐異なるパス上の異なるトラフィッククラスを使用することができます。すべてのポートで同じトラフィッククラスにスイッチ出口に入口でトラフィッククラス内を流れる場合、これは可能です。たとえば、トラフィックが受信機はアドミッション制御を行い、彼らが持っていないものでuser_priority 0としている1本の枝にuser_priority 4を使用して転送することができます。私たちは、入力または出力ポートを考慮せずにキューイングあたりuser_priorityは、LAN環境（IEEE 802.1D）内のスイッチのための最低限の標準機能であるが、場合でも、それ以上の機能レイヤ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の基本的なトポロジを共有することができる、半二重切り替えや全二重を切り替えます。共有トポロジでは、複数の送信者は、単一のセグメントを共有します。メディア・アクセスの競合は、トークンリングおよびFDDIでCSMA /イーサネットでCDやトークンパッシングなどのプロトコルを使用して解決されます。半二重切り替え、本質的に任意のセグメントでのリソースの競合のみ2つの送信機があるという制限を持つ共有トポロジーです。最後に、切り替え全二重トポロジーにおいて、全帯域幅パスが常にリンクの各端に送信機に利用可能です。したがって、このトポロジでは、そのような送信機との間に競合が存在しないようにCSMA / CD又はトークンパッシング等の任意のアクセス制御機構は不要です。明らかに、このトポロジは最高のQoS機能を提供します。トポロジの議論におけるもう一つの重要な要素は、複数のトラフィッククラスのサポートの存在または不在です。これらは、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.
上記共存の二つ以上のハイブリッドトポロジの可能性もあります。例えば、単一のサブネット内、トラフィッククラスとそうでないものもをサポートするいくつかのスイッチがあることも可能です。問題の流れは、ネットワーク内のスイッチの両方の種類を横断した場合、少なくとも共通の分母が優先されます。換言すれば、限り、そのフローに関しては、ネットワークを横断する少なくとも可能なトポロジに対応するタイプのものです。次のセクションでは、我々は、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プロトコルは重要ではない切り替えます。様々な媒体上の特性の近似値は、以下の表に提供されます。これらの遅延は、典型的な2キロマルチモードファイバリンクの米国約400の典型的な100メートルUTPリンクのNS及び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と強化されたフロー制御。しかし、MACは、従来のIEEE 802.3 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.
共有メディアイーサネット上の保証サービスのサブ最適なサポートのために同じ引数の多くは、半二重に適用されるイーサネットスイッチ。本質的に、このトポロジは、パケット送信のために競合する少なくとも二つの送信者との間で共有される媒体です。これらは密結合と協力している場合を除き、1のベストエフォートトラフィックが他の予約トラフィックを妨害する可能性が常にあります。このようなカップリングに対処する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.
上記の引数に耐えない、半二重は、トポロジを切り替え制御のロードサービスを提供する機会を提供しているように見えるん。確定的ではないが、幾分予測可能である一方で、両方のベストエフォートフロー上でその負荷制御トラフィックに優先順位付けを使用している、とアドミッションコントロールとその知識に基づいて、これらのフローのために行われた、メディア・アクセス特性を正確に二つの潜在的な送信者があることを知識を持ちます。これはおそらく、制御されたロードサービスに十分近い便利な近似です。
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は優先度の高いトラフィックを送信する局の数であり、THTmaxが最大トークン保持している（N + 1）* 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の値（セクション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物理層と570ナノ秒の最大伝搬遅延を使用して、すべてのエンドノードとハブとの間の100メートルのケーブル長さ以下に示します。
[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私たちの伝播遅延と2キロマルチモードファイバリンクについては下記を与えられています。
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キロの距離に共有されたメディアについては、IEEE 802.12規格ではサポートされているカスケード接続トポロジの2より高いレベルの最大カスケードレベルを可能にするが、距離[15]の減少を必要とします。
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?
明白な懸念は、このモデルの複雑さです。それは本質的にすでにレイヤ3で何RSVPないので、なぜ我々はレイヤ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.
キーが発生します本当の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規格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規格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規格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 802.1Q STD-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]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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.、ヤマウズラ、C.とR.ゲラン、 "保証されたサービスの質の仕様"、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]ブレーデン、R.、クラーク、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.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[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.バーガー（編集者）、 "インターネットストリームプロトコルバージョン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]シーマン、M.、スミス、A.とE.クローリー、 "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.、ホフマン、D.、Bernet、Y.およびF.ベイカー、 "SBMサブネット帯域幅マネージャー）：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）アクセス方法および物理層仕様、多重アクセス（また、ANSI / IEEE規格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規格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]ポステル、J.、およびJ.レイノルズ、 "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.パテル、F. Schaffa、およびM Willebeek-LeMair、マルチメディアトラフィック、IEEEネットワーク、11月/ 1995年12月のためのトークンリングネットワーク上の優先順位の使用。
[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規格802.12から1995に。
[20] Fiber Distributed Data Interface MAC, ANSI Std. X3.139-1987.
データインタフェースMAC、ANSI STD分散[20]繊維。 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）アクセス方法および物理層仕様搬送波感知多重アクセスへの補足 - フレーム仮想ブリッジローカルエリアネットワーク（VLAN）802.3ネットワーク上のタグ付け、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）ワーキンググループを超えるサービス統合型の会議で開催された議論から大幅に恩恵を受けています。我々は、これらの会合でメーリングリスト上の議論を通じて多くの参加者からの貢献を認めたいと思います。我々は、特に需要優先ネットワークに関するテキストを貢献するためにエリック・クローリー、ドン・ホフマンとラジYavatkar以前のインターネットドラフトを通じて貢献のため、そしてピーター・キムに感謝したいと思います。
Authors' Addresses
著者のアドレス
Anoop Ghanwani Nortel Networks 600 Technology Park Dr Billerica, MA 01821, USA
ノーテルネットワークghanavaniラグーン600あたりbillerike tecanoloji公園、中01821
Phone: +1-978-288-4514 EMail: aghanwan@nortelnetworks.com
電話：+ 1-978-288-4514 Eメール：aghanwan@nortelnetworks.com
Wayne Pace IBM Corporation P. O. Box 12195 Research Triangle Park, NC 27709, USA
ウェイン・ペースIBMコーポレーションP. O.ボックス12195リサーチトライアングルパーク、NC 27709、USA
Phone: +1-919-254-4930 EMail: pacew@us.ibm.com
電話：+ 1-919-254-4930 Eメール：pacew@us.ibm.com
Vijay Srinivasan CoSine Communications 1200 Bridge Parkway Redwood City, CA 94065, USA
ビジェイ・スリニバサンコサインコミュニケーションズ1200ブリッジパークウェイレッドウッドシティ、CA 94065、USA
Phone: +1-650-628-4892 EMail: vijay@cosinecom.com
電話：+ 1-650-628-4892 Eメール：vijay@cosinecom.com
Andrew Smith Extreme Networks 3585 Monroe St Santa Clara, CA 95051, USA
アンドリュー・スミスエクストリームネットワークス3585・モンローセントサンタクララ、CA 95051、USA
Phone: +1-408-579-2821 EMail: andrew@extremenetworks.com
電話：+ 1-408-579-2821 Eメール：andrew@extremenetworks.com
Mick Seaman Telseon 480 S. California Ave Palo Alto, CA 94306 USA
ミック・シーマンTelseon 480 S.カリフォルニアアベニューパロアルト、CA 94306 USA
Email: mick@telseon.com
メール：mick@telseon.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。