RFC2816 日本語訳
2816 A Framework for Integrated Services Over Shared and Switched IEEE802 LAN Technologies. A. Ghanwani, J. Pace, V. Srinivasan, A. Smith,M. Seaman. May 2000. (Format: TXT=119043 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Ghanwaniがコメントのために要求するワーキンググループA.をネットワークでつないでください: 2816 ノーテルはカテゴリをネットワークでつなぎます: 情報のW.のSrinivasanコサインコミュニケーションA.スミスペースIBM V.極端は2000年5月にM.船員Telseonをネットワークでつなぎます。
A Framework for Integrated Services
Over Shared and Switched IEEE 802 LAN Technologies
共有されて切り換えられたIEEE802LAN技術の上の統合サービスのための枠組み
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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 Integrated Servicesを支持するために枠組みについて説明します。 アクセス潜在や、遅れ変化や列を作りのIntegrated Servicesに影響するパラメタに関するネットワークがLANでスイッチを支えるようにそれはIEEE802の能力のバックグラウンドの材料を含んでいます。 それは異なったLAN環境で容易に対応できないIETFのIntegrated Servicesモデルの局面について議論します。 それは、そのようなLAN環境におけるResource予約プロトコル(RSVP)をサポートするために機能論的モデルについて概説します。 LANの上の使用のためのRSVPへの拡大の詳細は付随のメモ[14]で説明されます。 様々なIntegrated Servicesに関するマッピングは別のメモ[13]にIEEE802LANに説明されます。
Ghanwani, et al. Informational [Page 1] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[1ページ]のRFC2816枠組み
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 3 2。 アウトライン. . . . . . . . . . . . . . . . . . . . . 4 3を記録してください。 定義. . . . . . . . . . . . . . . . . . . . . . . 4 4。 IEEE802ネットワーク. . . . . . . . . . 5 4.1で推進を縁どってください。 IEEE802司令官はモデル. . . . . . . . . . . 5 4.2にサービスを提供します。 イーサネット/IEEE802.3.74.3。 トークンリング/IEEE802.5.84.4。 ファイバ分散データインタフェース. . . . . . . . . . 10 4.5。 優先権/IEEE802.12.105を要求してください。 要件と目標. . . . . . . . . . . . . . . . . . 11 5.1。 要件. . . . . . . . . . . . . . . . . . . . 11 5.2。 目標. . . . . . . . . . . . . . . . . . . . . . . . 13 5.3。 非目標.145.4。 仮定. . . . . . . . . . . . . . . . . . . . . 14 6。 基本的な構造. . . . . . . . . . . . . . . . . . . . 15 6.1。 コンポーネント. . . . . . . . . . . . . . . . . . . . . 15 6.1.1。 リクエスタモジュール. . . . . . . . . . . . . . 15 6.1.2。 帯域幅アロケータ. . . . . . . . . . . . . 16 6.1.3。 通信プロトコル. . . . . . . . . . . 16 6.2。 分配された実現. . . . 17 7に対して集結されます。 ネットワーク. . . . . . . 18 7.1の帯域幅マネージャのモデル。 天気図記入形式. . . . . . . . . . . . . . . . . . 19 7.1.1を終わらせてください。 3クライアントモデル. . . . . . . . . . . . 19 7.1.2を層にしてください。 層2のISSLL. . . . . . . . . . 19 7.1.3への要求。 層3の送付者. . . . . . . . . . . . 20 7.1.4で。 層3の受信機. . . . . . . . . . . 21 7.2で。 モデル. . . . . . . . . . . . . . . . . . . . 22 7.2.1を切り換えてください。 帯域幅アロケータ. . . . . . . 22 7.2.2を集結しました。 分配された帯域幅アロケータ. . . . . . . 23 7.3。 入場コントロール. . . . . . . . . . . . . . . . . . 25 7.4。 QoSシグナリング. . . . . . . . . . . . . . . . . . . . 26 7.4.1。 クライアントサービス定義. . . . . . . . . 26 7.4.2。 サービス定義. . . . . . . . . 27 8を切り換えてください。 導入問題. . . . . . . . . . . . . . . . . . 28 8.1。 特性. . . . . . . . . . . . . . . 29 8.2を切り換えてください。 列を作. . . . . . . . . . . . . . . . . . . . . . . 30 8.3り。 リンク・レベル優先権. . . . . 31 8.4に対するサービスのマッピング。 非の従うのに関する再マッピングは流れ. . . . 31 8.5に集められました。 入って来るユーザ優先権. . . . . . . . . 32 8.6のオーバーライド。 異なった予約様式. . . . . . . . . . . . 32 8.7。 受信機の異種性. . . . . . . . . . . . . . . 33 9。 ネットワーク形態シナリオ. . . . . . . . . . . . . . . 35 9.1。 全二重交換網. . . . . . . . . . . . 36 9.2。 共有されたメディアイーサネットは.379.3をネットワークでつなぎます。 半二重はイーサネットネットワーク. . . . . . . 38 9.4を切り換えました。 半二重は、トークンリングネットワーク. 39を切り換えて、共有しました。
Ghanwani, et al. Informational [Page 2] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[2ページ]のRFC2816枠組み
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
9.5. 半二重と共有された要求優先権は.40 10をネットワークでつなぎます。 正当化. . . . . . . . . . . . . . . . . . . . . . 42 11。 概要.43の参照箇所. . . . . . . . . . . . . . . . . . . . . . . . . . 43セキュリティ問題. . . . . . . . . . . . . . . . . . . 45承認. . . . . . . . . . . . . . . . . . . . . . . 45作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 46の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 47
1. Introduction
1. 序論
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
インターネットはベストエフォート型交通だけのサポートを伝統的に提供しました。 しかしながら、リンクレイヤ技術における最近の進歩、およびビデオ会議やインターネット電話などの頻繁な現れているリアルタイムのアプリケーションで、インターネットの上にリアルタイムのサービスを可能にする展開しているメカニズムに関する大きな関心がありました。 これらの新しい必要条件を満たすための枠組みはRFC1633[8]を始められました、そして、これはIETFのIntegrated Servicesワーキンググループによる様々なクラスのネットワーク・サービスの仕様を追い立てました、Controlled LoadやGuaranteed Service[6、7]のように。 それぞれのこれらのサービスのクラスは、Service(QoS)のあるQualityを指定されたセットのパラメタに従う交通に提供するように設計されています。 それらのQoS要件に従ってアプリケーションがこれらのクラスの1つを選ぶと予想されます。 QoSシグナリングプロトコル(IETFのRSVPワーキンググループによって開発されたResource予約プロトコル(RSVP)[5])で端のステーションがIPネットワークでそのようなサービスを利用する1つのメカニズムを提供します。 Project802の下のIEEEは多くの異なったローカル・エリア・ネットワーク技術の規格を定義しました。 しばしば異なった動的挙動の特性を提供しますが、これらはすべて、IPなどの、より高い層のプロトコルへの同じMAC層のデータグラムサービス[1]を通常提供します--リアルタイムのサービスを支持する彼らの能力を考えるとき、重要であるのは、これらです。 このメモで、より遅く、私たちは異なったMAC層のLAN技術の関連特性のいくつかについて説明します。 さらに、IEEE802は「MAC橋」か「スイッチ」[2]として知られている装置を使用することで複数のLANセグメントに一緒に橋を架ける規格を定義しました。 また、近作はこれらの装置[3、4]のために交通のクラス、マルチキャストフィルタリング、およびバーチャルLAN能力を定義しました。 そのようなLAN技術は全体のキャンパスネットワークのためにしばしば第一のブロックであることと同様にユーザとインターネットの間の最後のホップを構成します。 したがって、提供するのが終わりから終わりに対するリアルタイムのサービスを支持するこれらの技術を使用するためにメカニズムを標準化したのが必要です。 これをするために、データ・リンク層には資源管理のための何らかのメカニズムがあるに違いありません。 資源管理はこのような関係においては入場コントロール、スケジューリング、交通の取り締まりの機能を取り囲みます。 ISSLL、(統合サービス
Ghanwani, et al. Informational [Page 3] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[3ページ]のRFC2816枠組み
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.
Specific Link Layers) IETFのワーキンググループの上で様々なリンクレイヤ技術のためにそのようなメカニズムを探って、標準化する目的でチャーターされました。
2. Document Outline
2. ドキュメントアウトライン
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.
このドキュメントはイーサネット/IEEE802.3、Token Ring/IEEE802.5、FDDIなどの共有されて切り換えられたLAN技術の上にIntegrated Servicesを提供するのに枠組みを指定するのに関係があります。 私たちはセクション4で様々なIEEE802MAC層の技術の能力の議論で始めます。 セクション5はIntegrated ServicesをLANに提供できるメカニズムの要件と目標をリストアップします。 Bandwidthマネージャ(BM)と呼ばれた実体でセクション5に概説されたリソース管理機能を提供します。 BMの建築モデルはセクション6で説明されます、そして、セクション7で様々なコンポーネントについて議論します。 Integrated Servicesのリンクレイヤサポートに関するいくつかの導入問題がセクション8で調べられます。 セクション9はLAN技術のためにIntegrated Servicesを有効にするために投機できるそれぞれの能力への強調に考慮でtopologiesの分類学について論じます。 この枠組みはリンクレイヤでトポロジーに関する仮定を全くしません。 枠組みができるだけ徹底的であることを意図します。 これは、機能が議論したすべてが特定のトポロジーか技術で我慢できるかもしれないというわけではありませんが、これがそれのためにこのモデルの使用法を排除しないのが、可能であることを意味します。
3. Definitions
3. 定義
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: イーサネット/IEEE802.3やToken Ring/IEEE802.5などのデータ・リンク層技術はLayer2か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セットのノードとリンクを参照します。 L2ドメインで1つ以上のIPサブネットをかぶせることができます。
- 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装置: Layer2かL2装置としてLayer2の機能性を実行するだけである装置。 これらは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モデルのLayer3について言及します。 このメモは主としてこの層でインターネットプロトコル(IP)を使用するネットワークに関係があります。
Ghanwani, et al. Informational [Page 4] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[4ページ]のRFC2816枠組み
- Layer 3 Device or L3 Device or End Station: These include hosts
and routers that use L3 and higher layer protocols or application
programs that need to make resource reservations.
- 3の装置、L3装置または終わりの駅を層にしてください: これらはホストとL3と、より高い層のプロトコルを使用するルータか資源予約をする必要があるアプリケーション・プログラムを含んでいます。
- Segment: A physical L2 segment that is shared by one or more
senders. Examples of segments include: (a) a shared Ethernet or
Token Ring wire resolving contention for media access using CSMA
or token passing; (b) a half duplex link between two stations or
switches; (c) one direction of a switched full duplex link.
- セグメント: 1人以上の送付者によって共有される物理的なL2セグメント。 セグメントに関する例は: (a) メディアのための主張を決議する共有されたイーサネットかToken Ringワイヤが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.
- セグメントを管理します: 管理されたセグメントはDSBMがあるセグメントです。(指定されたサブネット帯域幅マネージャは[14])は入場コントロールを資源予約を求める要求に及ぼすのに現在であって責任があるのがわかってください。 管理されたセグメントはDSBMsによって切り離されない共有されたLANのそれらのインタコネクトされた部品を含んでいます。
- Traffic Class: Refers to an aggregation of data flows which are
given similar service within a switched network.
- 交通のクラス: 同様のサービスが交換網の中で与えられているデータフローの集合について言及します。
- Subnet: Used in this memo to indicate a group of L3 devices
sharing a common L3 network address prefix along with the set of
segments making up the L2 domain in which they are located.
- サブネット: このメモでは、L3装置のグループを示すために、それらが位置しているL2ドメインを作るセグメントのセットに伴う一般的な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.
- 橋を架けるか、または切り替わってください: IEEE 802.1D[2]によって定義されるLayer2推進装置。 用語橋とスイッチはこのメモで同じ意味で使用されます。
4. Frame Forwarding in IEEE 802 Networks
4. IEEE802ネットワークにおけるフレーム推進
4.1. General IEEE 802 Service Model
4.1. IEEE802サービスモデル司令官
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.
ユーザ_優先権はIEEE802サービスモデルにおける、すべてのフレームのトランスミッションとレセプションに関連している値です。 それをMACサービスを利用している送付者が供給して、データと共に受信機にMACサービスを利用することで提供します。 それは実際にネットワークの上まで運ばれるかもしれません。 象徴Ring/IEEE802.5は基本的なイーサネット/IEEE802.3がそれを運びませんが、FC八重奏でコード化されたこの値を運びます。 使用中のフレーム形式によって、IEEE802.12はそれを運ぶかもしれません。 使用中のフレーム形式がIEEE802.5であるときに、ユーザ_優先権は明らかに運ばれます。 IEEE802.3フレーム形式が使用されているとき、アクセス優先順位を決定するのに使用される優先権(高いか低い)の2つのレベルだけは回復できます。 これはIEEE802.3フレームのスタートデリミタでコード化された優先権の価値に基づいています。
Ghanwani, et al. Informational [Page 5] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[5ページ]のRFC2816枠組み
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]は拡張フレーム形式を使用するイーサネットから成る橋を架けられたネットワークの上までユーザ_優先権の価値を運ぶための一貫した方法、Token Ring、Demand Priority、FDDIまたは他のMAC層のメディアを定義します。 ユーザ_優先権の用法は以下へまとめられます。 私たちは詳細のための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.
ユーザ_優先権がパケットで明らかに運ばれるなら、異なったクラスにおけるデータ・ストリームの中のパケットが川下のノードによって容易にさらに詳細にパケットを分析する必要はなくて差別されるのを可能にする簡単なラベルとしてユーティリティがあります。
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.
デスクトップか配線の仕事を押し入れのスイッチにより簡単な状態ですることは別として、明白な分野は、パケットを分類するための規則が発展するのに従ってハードウェアかソフトウェアを変える必要はないことを意味します。 例えば、新しいプロトコルか新しい政策に基づいて。 恐らくネットワークのコアで配備されたスイッチが提供できるかもしれないより高性能のLayer3は、より正確にパケット分類を実行して、したがって、より効率的にネットワーク資源を利用して、より良い孤立を流れの間に提供することによって、価値を高めました。 ネットワークには非常にずっと多くのデスクトップ/配線クロゼットスイッチが切り替わるよりありそうであるので、これはLayer3の機能性を必要としながら、良い経済選択であるように見えます。
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
IEEE802仕様は端のステーションかネットワークによってどう使用されるかに関するユーザ_優先権がことである仮定を全くしません。 IEEE 802.1Dは複数の待ち行列を実行するスイッチのデフォルト運転モードとして列を作る静的な優先権を定義しますが、実際にスイッチによって実行された交通のクラスの数によるので、ユーザ_優先権は本当にあいまいな意味でだけ優先です。 最優先を表す7の値と0の値が最も低い状態でユーザ_優先権は3ビットの量と定義されます。 一般的なスイッチアルゴリズムは以下の通りです。 パケットは容認されたユーザ_優先権に基づく特定の交通のクラスの中に列に並ばせられます。その値をIEEE 802.1QヘッダーかIEEE802.5ネットワークが使用されているなら直接パケットから得るか、または何らかのローカルの方針によると、割り当てます。 待ち行列はユーザ_優先権(0〜7)からのマッピングに基づいて利用可能な交通のクラスの数に選択されます。 スイッチは複数の交通のクラスを実行するかもしれません。 広告を出しているIntServパラメタとスイッチの入場コントロールの振舞いはマッピングを決定するのにおいて使用されているかもしれません。
Ghanwani, et al. Informational [Page 6] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[6ページ]のRFC2816枠組み
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.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は送付者がユーザ_優先権のためにどう値を選択するべきであるかに関して推薦状を全くしません。 このドキュメントの第一の目的の1つは、そのような用法規則を提案して、スイッチと端のステーションの間のこれらの値の意味論に関するコミュニケーションについて議論することです。 このドキュメントの残りでは、私たちはユーザ_優先権と共に同じ意味で用語交通のクラスを使用します。
4.2. Ethernet/IEEE 802.3
4.2. イーサネット/IEEE802.3
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.
イーサネットパケットで運ばれたどんな明白な交通のクラスもユーザ_優先権野原もいません。 これは、いくつかのデフォルトかさらにパケットの、より高い層のプロトコル分野に分析することによって川下の受信機かスイッチにユーザ_優先権を作り直さなければならないことを意味します。 あるいはまた、基本的なMACフレーム形式の上で明白なユーザ_優先権野原を供給するIEEE 802.1Qカプセル化[4]は使用されるかもしれません。
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.
縁どりとTable1に示されるように要件を水増しするのに応じてどんな入場規制計算も調整するのはイーサネット/IEEE802.3の上で使用される異なったIPパケットカプセル化に必要になるでしょう。 ここと、「ip_len」はヘッダーを含むIPパケットの長さを呼びます。
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
--------------------------------------------------------------- カプセル化Framing Overhead IP MTUバイト/pktバイト--------------------------------------------------------------- IP EtherType(46ip_len<=バイト)64-ip_len1500(1500>はip_len>と= 46バイト等しい)18 1500
IP EtherType over 802.1D/Q (ip_len<=42) 64-ip_len 1500*
(1500>=ip_len>=42 bytes) 22 1500*
802.1D/Q(ip_len<=42)64-ip_len1500*(1500>はip_len>と= 42バイト等しいです)22 1500*の上のIP EtherType
IP EtherType over LLC/SNAP (ip_len<=40) 64-ip_len 1492
(1500>=ip_len>=40 bytes) 24 1492
---------------------------------------------------------------
LLC/SNAP(ip_len<=40)64-ip_の上のIP EtherTypeは1492(1500>はip_len>と= 40バイト等しい)24 1492をlenします。---------------------------------------------------------------
*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仕様を使用するイーサネットフレームのパケット長が現在のIEEE802.3の最大のパケット長値を4バイト超えていることに注意してください。 IEEE 802.3ac[21]はIEEE 802.1Qフレームへの最大のMTUサイズの変化に対応しています。
Ghanwani, et al. Informational [Page 7] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[7ページ]のRFC2816枠組み
4.3. Token Ring/IEEE 802.5
4.3. トークンリング/IEEE802.5
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.
Token Ring規格[6]はトランスミッションのためのパケットの列を作りと共有されたメディアへのパケットのアクセスの両方を制御するのに使用できる優先権メカニズムを提供します。 優先権メカニズムは、Access Control(西暦)とLLCフレームのFrame Control(FC)分野の中でビットを使用することで実行されます。 交流分野の最初の3ビット、交流分野の最後の3ビットに伴うToken Priorityビット(予約ビット)はステーションがリングへのアクセスを手に入れるものを規制します。 パケットのトランスミッションを要求すると、ユーザ_優先権パラメタの、より高い層からLLCフレームのFC分野の最後の3ビット(User Priorityビット)を入手します。 また、このパラメタはMACによって使用されたAccess Priorityを設立します。 ユーザ_優先順位の値は、運ばれたFC分野のUser Priorityビットの終わりから端であり、すべてのタイプのToken Ring橋を通って通常保存されます。 すべての場合では、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.
また、象徴Ringはステーションが次のトランスミッションのためにリングの上に象徴を予約するのに使用する優先権の価値に関連するReserved Priorityの概念を使用します。 無料の象徴であるときに、ステーションだけにはAccess Priorityが、よりあって、循環するのが、Reserved Priorityです。象徴では、トランスミッションのために象徴を差押えるのが許容されるでしょう。 読者はこの話題のさらなる議論のための[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.
Token Ringステーションは、別々にそれぞれの8つのレベルの要求されたユーザ_優先権を列に並ばせて、優先権の順に理論的に次にフレームを伝えることができます。 最優先待ち行列におけるトランスミッションのために列に並ばせられるフレームのユーザ_優先権に従って、ステーションは予約ビットを設定します。 これで、アクセス機構は、全体のリング中に最優先があるフレームがどんな低優先度フレームの前にも伝えられるのを保証できます。 IEEE802.5Token Ring規格への私が以下のフレームを送るか、またはリレーすることをそのステーションを勧める別館。
Ghanwani, et al. Informational [Page 8] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[8ページ]のRFC2816枠組み
Table 2: Recommended use of Token Ring User Priority
テーブル2: Token Ring User Priorityのお勧めの使用
-------------------------------------
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
-------------------------------------
------------------------------------- アプリケーションユーザ優先権------------------------------------- 非時の重要なデータ0--1--2--6MACが縁どるLAN管理4のTime-極秘データの3の5つのレアルの時間の批判的なデータ7-------------------------------------
To reduce frame jitter associated with high priority traffic, the annex also recommends that only one frame be transmitted per token and that the maximum information field size be 4399 octets whenever delay sensitive traffic is traversing the ring. Most existing implementations of Token Ring bridges forward all LLC frames with a default access priority of 4. Annex I recommends that bridges forward LLC frames that have a user_priority greater than 4 with a reservation equal to the user_priority (although IEEE 802.1D [3] permits network management override this behavior). The capabilities provided by the Token Ring architecture, such User Priority and Reserved Priority, can provide effective support for Integrated Services flows that require QoS guarantees.
また、高い優先権交通、別館に関連しているフレームジターを減少させるのは、1個のフレームだけが象徴単位で伝えられることを勧めます、そして、最大の情報が遅れ敏感であるときはいつも、4399の八重奏が交通であったならサイズをさばくのがリングを横断しています。 Token Ring橋のほとんどの既存の実現が4のデフォルトアクセス優先順位があるすべてのLLCフレームを進めます。 私がユーザ_優先権(IEEE 802.1D[3]はこの振舞いをネットワークマネージメントオーバーライドに可能にしますが)と等しい予約でユーザ_優先より多くの4を持っている前進のLLCフレームに橋を架けることをそれを勧める別館。 Token Ring構造によって提供された能力(そのようなUser PriorityとReserved Priority)は、QoS保証を必要とするIntegrated Services流れの有効なサポートを提供できます。
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.
Table3に示される縁どり要件に応じてどんな入場規制計算も調整するのはToken Ring/IEEE802.5の上で使用される異なったIPパケットカプセル化に必要になるでしょう。
Table 3: Token Ring encapsulations
テーブル3: 象徴Ringカプセル化
---------------------------------------------------------------
Encapsulation Framing Overhead IP MTU
bytes/pkt bytes
---------------------------------------------------------------
IP EtherType over 802.1D/Q 29 4370*
IP EtherType over LLC/SNAP 25 4370*
---------------------------------------------------------------
--------------------------------------------------------------- カプセル化Framing Overhead IP MTUバイト/pktバイト--------------------------------------------------------------- LLC/スナップ25 4370*の上の802.1D/Q29 4370*IP EtherTypeの上のIP EtherType---------------------------------------------------------------
*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.
*RFC1042[13]からの提案されたMTUは4464バイトですが、最大がサブネットとToken Ringサブネットの間の任意な2点の間でMTUを支持したと発見すると関連する問題があります。 ここで報告されたMTUはIEEE802.5Annex I推薦と一致しています。
Ghanwani, et al. Informational [Page 9] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[9ページ]のRFC2816枠組み
4.4. Fiber Distributed Data Interface
4.4. ファイバ分散データインタフェース
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]はトランスミッションのためのパケットの列を作りと共有されたメディアへのパケットのアクセスの両方を制御するのに使用できる優先権メカニズムを提供します。 優先権メカニズムは、上で説明されたToken Ringに同様のメカニズムを使用することで実行されます。 また、アクセスと遅れが保証する厳しいメディアで規格は「同期」のデータ通信量に備えます。 この運転モードは、ここでさらに議論しないで、さらなる仕事を必要とするISSLLワーキンググループの範囲の中に領域を表します。 このドキュメントの残りでは、QoSメカニズムの議論において、FDDIは、100Mbps Token Ring技術としてIEEE802ネットワークとのコンパチブルサービスインタフェースを使用することで扱われます。
4.5. Demand Priority/IEEE 802.12
4.5. 要求優先権/IEEE802.12
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.
IEEE802.12[19]は共有された100Mbps LANの規格です。 データ・パケットは、IEEE802.3かIEEE802.5フレーム形式を使用することで伝えられます。 MACプロトコルはDemand Priorityと呼ばれます。 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.
IEEE802.3フレーム形式がデータ伝送に使用されるなら、ユーザ_優先権はIEEE802.12データ・パケットの始めのデリミタでコード化されます。 IEEE802.5フレーム形式が使用されているなら、ユーザ_優先権はIEEE802.5パケットのヘッダーのFC分野のYYYビットでさらに、コード化されます(また、セクション4.3を見てください)。 その上、また、それ自身のユーザ_優先権分野があるIEEE 802.1Qカプセル化はIEEE802.12ネットワークで適用されるかもしれません。 すべての場合では、スイッチは優先権が送付者から供給したどんなユーザ_も回収できます。
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.
同じ規則は他のメディアタイプのように橋の中でIEEE802.12ユーザ_優先権マッピングに申し込みます。 唯一の追加情報は正常な優先権がユーザ_優先順位の値にデフォルトで0〜4に包括的に使用されて、高い優先度がユーザ_優先順位に5〜7に使用されるということです。 これは、IEEE802.5橋への4のデフォルトToken Ringユーザ_優先順位が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
IEEE802.12LANにおける中型のアクセスは決定論的です。 Demand Priorityメカニズムは、通常の優先サービスがいったん先取りされるとすべての高い優先権パケットにはパケットより厳しい優先権が正常な優先権と共にあるのを確実にします。 正常な優先権パケットがMACの線のヘッドで待っている場合、待ち行列を伝えてください。
Ghanwani, et al. Informational [Page 10] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[10ページ]のRFC2816枠組み
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.
PACKET_PROMOTION(200--300ms)[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.
IEEE802.12の中型のアクセス機構の上に統合Servicesを造ることができます。 既存のIEEE802.12MACプロトコルへの少しも変化なしでGuaranteed Serviceを提供できるので必要に応じて入場コントロールと帯域幅実施メカニズム、遅れ保証に結合されると。
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.
IEEE802.12規格がIEEE802.3とIEEE802.5フレーム形式を支持するので、同じくらいはIEEE802.12のための入場コントロール計算でリンクされますセクション4.2と4.3で報告されるオーバーヘッドを縁どるのを考えなければならない。
5. Requirements and Goals
5. 要件と目標
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技術の上でIntegrated Servicesを支持するために構造のデザインを追い立てるべきである要件と目標について論じます。 要件はサポートしなければならない機能と特徴について言及します、目標は望ましいのですが、絶対必要でない機能と特徴について言及しますが。 要件と目標の多くがIntegrated ServicesとRSVPによって支持された機能性によって動かされます。
5.1. Requirements
5.1. 要件
- 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に会うのに必要なリソースのレベルを見積もることができなければなりません。 管理の目的に、リソースの有用性に関して質問に応じる能力を提供するのは役に立ちます。 それは入場を異なったタイプのGuaranteed Service、Controlled Loadなどのサービスのためのコントロール決定にすることができなければなりません。
Ghanwani, et al. Informational [Page 11] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[11ページ]のRFC2816枠組み
- 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.
- 以下を取り締まるか、または形成すること。 端のステーション(ワークステーション、ルータ)は、交渉された交通パラメタに順応を確実にするために交通を形成される、そして/または、取り締まらなければなりません。 形成は交通源へのお勧めの振舞いです。 ルータによって送られたすべての流れが順応中であることを確実にするIntServ要件に従って、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.
- 実現を集結するか、または広げます: 集結された実現の場合では、単一体は全体のサブネットに関するリソースを管理します。 このアプローチには、橋とスイッチが追加機能性でアップグレードする必要はないかもしれないので、より簡単であるのが展開する利点があります。 しかしながら、このアプローチはサブネットの地理的なサイズと端のステーションの添付の数で不十分に比例します。 完全に分配された実現では、各セグメントはリソースを管理するローカル要素を持つでしょう。 このアプローチには、前者より良いスケーラビリティがあります。 しかしながら、それは、ネットワークにおけるすべての橋とスイッチが新しいメカニズムをサポートするのを必要とします。また、1つ以上の実体があるところで準分配された実現を持っているのも可能です、サブネットの中でそれぞれセグメントと橋/スイッチの部分集合に関するリソースを管理して。 理想的に、実現はフレキシブルであるべきです。 小さいサブネットにすなわち、集結されたアプローチを使用するかもしれません、そして、より大きいサブネットに分散型アプローチを使用できます。 セクション6で集結されて分配された実現に関する例について議論します。
Ghanwani, et al. Informational [Page 12] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[12ページ]のRFC2816枠組み
- 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.
- 耐障害性と回復: メカニズムは失敗があるとき機能できなければなりません。 すなわち、1ポイントの失敗があるべきではありません。 例えば、集結された実現では、失敗の場合、バックアップと回復に何らかのメカニズムを指定しなければなりません。
- 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には、「同期帯域幅マネージャ」と呼ばれる資源管理メカニズムがあります。 入手できるところで既存のコントロールで利点を活用して、相互作用を指定するように、メカニズムを設計しなければなりません。
5.2. Goals
5.2. 目標
- Independence from higher layer protocols: The mechanism should,
as far as possible, be independent of higher layer protocols such
as RSVP and IP. Independence from RSVP is desirable so that it can
interwork with other reservation protocols such as ST2 [10].
Independence from IP is desirable so that it can interwork with
other network layer protocols such as IPX, NetBIOS, etc.
- より高い層のプロトコルからの独立: メカニズムはRSVPやIPなどの、より高い層のプロトコルからできるだけ独立しているべきです。 RSVPからの独立は、他の予約でST2[10]などのプロトコルを織り込むことができるくらい望ましいです。 IPからの独立は、IPX、NetBIOSなどとして他のネットワーク層プロトコルでそのようなものを織り込むことができるくらい望ましいです。
- Receiver heterogeneity: this refers to multicast communication
where different receivers request different levels of service.
For example, in a multicast group with many receivers, it is
possible that one of the receivers desires a lower delay bound
than the others. A better delay bound may be provided by
increasing the amount of resources reserved along the path to that
receiver while leaving the reservations for the other receivers
unchanged. In its most complex form, receiver heterogeneity
implies the ability to simultaneously provide various levels of
service as requested by different receivers. In its simplest
form, receiver heterogeneity will allow a scenario where some of
the receivers use best effort service and those requiring service
guarantees make a reservation. Receiver heterogeneity, especially
for the reserved/best effort scenario, is a very desirable
function. More details on supporting receiver heterogeneity are
provided in Section 8.
- 受信機の異種性: これは異なった受信機が異なったレベルのサービスを要求するマルチキャストコミュニケーションを示します。 例えば、多くの受信機があるマルチキャストグループでは、受信機のひとりが他のものより低い遅れバウンドを望んでいるのは、可能です。 他の受信機の予約を変わりがないままにする間に経路に沿ってその受信機に予約されたリソースの量を増加させることによって、より良い遅れバウンドを提供するかもしれません。 最も複雑なフォームでは、受信機の異種性は同時に要求された通り異なった受信機で様々なレベルのサービスを提供する能力を含意します。 最も簡単なフォームでは、受信機の異種性はいくつかの受信機がベストエフォート型サービスを利用するシナリオを許容するでしょう、そして、サービス保証を必要とするものが予約をします。 特に予約されたかベストエフォート型のシナリオのために、受信機の異種性は非常に望ましい機能です。 受信機の異種性を支持することに関するその他の詳細をセクション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で調べられます。
Ghanwani, et al. Informational [Page 13] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[13ページ]のRFC2816枠組み
- 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.
- 経路選択: Token Ring/IEEE802.5などのソースの発送されたLAN技術で、メカニズムが経路選択の機能を取り入れるのは、役に立つかもしれません。 適切な経路選択メカニズムを使用すると、ネットワーク資源の利用は最適化されるかもしれません。
5.3. Non-goals
5.3. 非目標
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のように標準のMAC層のサービスを利用する、802.1は橋を架けます。 それは、他の独占であるか標準のMAC層のプロトコルの能力について利用するか、QoSマッピングに適したMAC層での発行された仕事が存在することに注意されるべきですが、または説明するのを試みません。 ISSLLワーキンググループ特許の範囲の外にこれらはあります。
5.4. Assumptions
5.4. 仮定
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 topologiesを切り換えるのを許容しないのは重要です。 また、例えば、IEEE802.12に決定論的なアクセスをネットワークリンクに遅らせるように保証するために、開発がMAC増進の領域にありました。[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をある他のダイナミックなプロトコルに取り替えることができましたか、またはネットワークマネージメントか他の方針実体で要求をすることができました。 SBMシグナリングプロトコル[14](RSVPに基づいています)は、このメモで説明された構造で継ぎ目なく働くように設計されています。
There may be a heterogeneous mix of switches with different capabilities, all compliant with IEEE 802.1D [2,3], but implementing varied queuing and forwarding mechanisms ranging from simple systems with two queues per port and static priority scheduling, to more complex systems with multiple queues using WFQ or other algorithms.
異なった能力があるスイッチの異種のミックスがあるかもしれません、IEEE 802.1D[2、3]と共にすべて言いなりになりますが、実行は1ポートあたり2つの待ち行列と静的な優先度スケジュールで簡単なシステムから変化するメカニズムを列に並ばせて、進めながら、異なりました、複数の待ち行列がWFQか他のアルゴリズムを使用しているより複雑なシステムに。
The problem is decomposed into smaller independent parts which may lead to sub-optimal use of the network resources but we contend that such benefits are often equivalent to very small improvement in network efficiency in a LAN environment. Therefore, it is a goal that the switches in a network operate using a much simpler set of
問題はネットワーク資源のサブ最適の使用に通じるかもしれないより小さい独立している部分に分解されますが、私たちは、そのような利益がしばしばLAN環境におけるネットワーク効率における非常に小さい改良に同等であると主張します。 したがって、ネットワークにおけるスイッチがセットされて、より簡単な状態で多くを使用することで作動するのは、目標です。
Ghanwani, et al. Informational [Page 14] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[14ページ]のRFC2816枠組み
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).
情報、ルータにおける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モデルの基本的仮説は流れが彼らのトランジットの間中ネットワークの向こう側に互いから隔離されるということです。 中間的列を作りノードは、交渉された交通の流れ仕様に順応を確実にするために交通を形成するか、または取り締まると予想されます。 マッピングのためにここでLayer2に提案された構造では、私たちは簡単さのためにその仮定からそれます。 端のステーションで取り締まり/形成機能が実行されると思われます。 いくつかのLAN環境では、端のステーションが入力のときにそれらの随意契約をネットワークに固く守ると信じられて、私たちには交換網自体によって導入された必然のパケットのジター/束になることを補うために入場コントロールの間、リソースを割り当て過ぎる余裕があると仮定するのは妥当です。 この分岐は支持できる受信機の異種性のタイプと利用されるかもしれない統計的多重化利得にいくつかの意味を持っています、特にControlled Loadが流れるので。 このドキュメントのセクション8.7でこれについて議論します。
6. Basic Architecture
6. 基本的な構造
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で説明された機能条件書は私たちがBandwidthマネージャ(BM)を呼ぶ実体によって実行されるでしょう。 BMはアプリケーションか、より高い層のプロトコルがネットワークからQoSを要求するようにメカニズムを提供するのに責任があります。 建築目的のために、BMは以下のコンポーネントから成ります。
6.1. Components
6.1. コンポーネント
6.1.1. Requester Module
6.1.1. リクエスタモジュール
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
Requester Module(RM)はあらゆる端のステーションにサブネットで住んでいます。 機能の1つはRSVPや、ST2や、SNMPや、などやBMなどのアプリケーションか、より高い層のプロトコルの間のインタフェースを提供することです。 アプリケーションは、RMとのコミュニケーションに基関数を使用して、適切なパラメタをそれに提供することによって、BMの様々な機能を呼び出すことができます。 リンクレイヤドメインで予約を開始するために、以下のパラメタをRMに通過しなければなりません: 予約された[9]になるようにリソースの量を指定する望まれていたサービス(保証されたServiceかControlled Load)、記述子がTSpecに含んだ交通、およびRSpec。 これらのパラメタに関する詳しい情報は関連Integrated Servicesドキュメント[6、7、8、9]で見つけられるかもしれません。 RSVPがネットワーク層で合図するのに使用されるとき、この情報は、利用可能であり、RSVP PATHとRSVP RESVメッセージから抽出される必要があります(詳細のための[5]を見てください)。 in addition to
Ghanwani, et al. Informational [Page 15] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[15ページ]のRFC2816枠組み
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によって呼び出しアプリケーションか、より高い層のプロトコルに処理された要求の状態を返すのに責任があります。
6.1.2. Bandwidth Allocator
6.1.2. 帯域幅アロケータ
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.
Bandwidth Allocator(BA)はサブネットにおける、リソースの配分に関して入場コントロールを実行して、状態を維持するのに責任があります。 端のステーションは様々なサービス、例えば、帯域幅の予約、既存の予約の変更、リソースの有用性に関する質問などを要求できます。 これらの要求はBAによって処理されます。 端のステーションとBAとのコミュニケーションはRMを通して行われます。 BAの位置は主に実現方法によるでしょう。 集結された実現では、BAは単一のステーションにサブネットで住むかもしれません。 分配された実現では、BAの機能は必要に応じてすべての端のステーションと橋/スイッチで分配されるかもしれません。 また、BAも何らかの優先順位の値でタグ付けをされて、BAが例えば、入場コントロール決定に基づいて特定の流れに属すパケットがあるRMに示すかもしれない流れをどの地図とラベルするか方法を適切な交通のクラスに決めるのに責任があります。
6.1.3. Communication Protocols
6.1.3. 通信プロトコル
The protocols for communication between the various components of the BM system must be specified. These include the following:
BMシステムの様々な部品のコミュニケーションのためのプロトコルを指定しなければなりません。 これらは以下を含んでいます:
- Communication between the higher layer protocols and the RM: The
BM must define primitives for the application to initiate
reservations, query the BA about available resources, change
change or delete reservations, etc. These primitives could be
implemented as an API for an application to invoke functions of
the BM via the RM.
- より高い層のプロトコルとRMとのコミュニケーション: BMはアプリケーションが予約を開始するように基関数を定義しなければならないか、利用可能資源に関してBAについて質問しなければならないか、変化を変えなければならないか、または予約などを削除しなければなりません。 アプリケーションがRMを通してBMの機能を呼び出すように、APIとしてこれらの基関数を実行できました。
- 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
- 同輩BAsのコミュニケーション: サブネットに1BAがあれば、相互BAコミュニケーションに手段を指定しなければなりません。 明確に、BAsは自分たちの中で決めることができなければなりません。
Ghanwani, et al. Informational [Page 16] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[16ページ]のRFC2816枠組み
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はどのセグメントと橋かスイッチに責任があるか。 さらに、資源予約のために複数のBAsのドメインに沿って要求をするなら、BAsは正しくそのようなシナリオを扱うことができなければなりません。 また、相互BAコミュニケーションは失敗の場合、バックアップと回復に原因となるようになるでしょう。
6.2. Centralized vs. Distributed Implementations
6.2. 分配された実現に対して集結されます。
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 |
+---------+ +---------+ +---------+ +---------+
+---------+ .-->| Ba| <--. / +---------+ \ / .-->| 層2| <--. \ / / +---------+ \ \ / / \ \ / / \ \ +---------+ / / \ \ +---------+ | 装置| <、-、-、-、-- /-/---------------------------\-\----->| 装置| +---------+ / / \ \ +---------+ | RM| <、-、-、--. / \ .--->| RM| +---------+ / +---------+ +---------+ \ +---------+ | 層2| <、-、-、-、-、--、>| 層2| <、-、-、-、-、--、>| 層2| <、-、-、-、-、--、>| 層2| +---------+ +---------+ +---------+ +---------+
RSVP Host/ Intermediate Intermediate RSVP Host/
Router Bridge/Switch Bridge/Switch Router
RSVPホスト/中間的な中間的RSVPホスト/ルータ橋/スイッチ橋/スイッチルータ
Figure 1: Bandwidth Manager with centralized Bandwidth Allocator
図1: 集結されたBandwidth Allocatorの帯域幅マネージャ
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
図1は、独身のBAはどこで全体のサブネットのための入場コントロール決定に責任があるかを集結された実現に示します。 あらゆる端のステーションがRMを含んでいます。 活発に入場コントロールに参加しないので、ネットワークにおける中間的橋とスイッチには、BMのどんな機能もある必要はありません。 予約を要求する端のステーションのRMはBAとのコミュニケーションを開始します。 より大きいサブネットにおいて、独身のBAは全体のサブネットの予約を扱うことができないかもしれません。 それぞれaに関するリソースを管理して、その場合、複数のBAsを配備するのが必要でしょう。
Ghanwani, et al. Informational [Page 17] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[17ページ]のRFC2816枠組み
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.
セグメントの非重なっている部分集合。 集結された実現では、BAはサブネットのLayer2トポロジーに関する何らかの知識を持たなければなりません、例えば、層のスパニングツリー情報をリンクしてください、適切なセグメントに関するリソースを予約できるように。 このトポロジー情報がなければ、BMは交換網でリソースの非常に効率の悪い利用につながるすべての流れのためにすべてのセグメントに関するリソースを予約しなければならないでしょう。
+---------+ +---------+ | App |<-------------------------------------------->| App | +---------+ +---------+ +---------+ +---------+ | RM/BA |<------>| BA |<------>| BA |<------>| RM/BA | +---------+ +---------+ +---------+ +---------+ | Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 | +---------+ +---------+ +---------+ +---------+
+---------+ +---------+ | 装置|<-------------------------------------------->| 装置| +---------+ +---------+ +---------+ +---------+ | RM/Ba| <、-、-、-、-、--、>| Ba| <、-、-、-、-、--、>| Ba| <、-、-、-、-、--、>| RM/Ba| +---------+ +---------+ +---------+ +---------+ | 層2| <、-、-、-、-、--、>| 層2| <、-、-、-、-、--、>| 層2| <、-、-、-、-、--、>| 層2| +---------+ +---------+ +---------+ +---------+
RSVP Host/ Intermediate Intermediate RSVP Host/
Router Bridge/Switch Bridge/Switch Router
RSVPホスト/中間的な中間的RSVPホスト/ルータ橋/スイッチ橋/スイッチルータ
Figure 2: Bandwidth Manager with fully
distributed Bandwidth Allocator
図2: 完全に分配された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はローカルのトポロジー情報だけを必要とするでしょう。 どのポートからスパニングツリーであってどのユニキャストアドレスが届いているかに関してアクティブなポートのリストのこのローカルのトポロジー情報は今日のスイッチで容易に利用可能です。 上では、数字では、同輩層の間の矢が論理的な接続性を示すのに使用されることに注意してください。
7. Model of the Bandwidth Manager in a Network
7. ネットワークの帯域幅マネージャのモデル
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].
このセクションで、私たちは既存のIETF Integrated Servicesがある発作の上のモデルがIPホストとルータについてどうモデル化するかを説明します。 まず最初に、私たちはLayer3ホストとルータ実現について説明します。 次に、私たちはモデルがLayer2スイッチでどう適用されるかを説明します。 あらゆる点で、私たちは、間のどんな違いも実現を集結して、広げたのを示します。 Subnet Bandwidthマネージャ仕様[14]から用語に時々の参照をします。
Ghanwani, et al. Informational [Page 18] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[18ページ]のRFC2816枠組み
7.1. End Station Model
7.1. 終わりの天気図記入形式
7.1.1. Layer 3 Client Model
7.1.1. 層3のクライアントモデル
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.
私たちは、私たちが「クライアント」という用語を使用するIntServとRSVPと同じクライアントモデルがLayer2Domainの各端のLayer3装置で実体取り扱いQoSを意味すると思います。 このモデルでは、交渉されたサービスに従って、送付クライアントはリンクへの地方の入場コントロールとパケットスケジューリングに責任があります。 IntServモデルのように、流れスケジューリング単位でこれはそのようなあらゆる由来しているノードにおける交通の形成/取り締まりに可能にかかわります。
For now, we assume that the client runs an RSVP process which presents a session establishment interface to applications, provides signaling over the network, programs a scheduler and classifier in the driver, and interfaces to a policy control module. In particular, RSVP also interfaces to a local admission control module which is the focus of this section.
当分、私たちは、クライアントがセッション設立インタフェースをアプリケーションに提示して、ネットワークの上にシグナリングを提供して、ドライバーでスケジューラとクラシファイアをプログラムして、方針コントロールモジュールに連結するRSVPの過程を走らせると思います。 また、特に、RSVPはこのセクションの焦点であるローカルの入場コントロールモジュールに連結します。
The following figure, reproduced from the RSVP specification, depicts the RSVP process in sending hosts.
RSVP仕様から複製された以下の図は送付ホストにRSVPの過程について表現します。
+-----------------------------+
| +-------+ +-------+ | RSVP
| |Appli- | | RSVP <------------------->
| | cation<--> | |
| | | |process| +-----+|
| +-+-----+ | +->Polcy||
| | +--+--+-+ |Cntrl||
| |data | | +-----+|
|===|===========|==|==========|
| | +--------+ | +-----+|
| | | | +--->Admis||
| +-V--V-+ +---V----+ |Cntrl||
| |Class-| | Packet | +-----+|
| | ifier|==>Schedulr|===================>
| +------+ +--------+ | data
+-----------------------------+
+-----------------------------+ | +-------+ +-------+ | RSVP| |Appli| | RSVP<。------------------->|、| 陽イオン<-->。| | | | | |過程| +-----+| | +-+-----+ | +->Polcyです。|| | | +--+--+-+ |Cntrl|| | |データ| | +-----+| |===|===========|==|==========| | | +--------+ | +-----+| | | | | +--->Admis|| | +V--V-++---V----+ |Cntrl|| | |クラス| | パケット| +-----+| | | ifier|==>Schedulr|===================>| +------+ +--------+ | データ+-----------------------------+
Figure 3: RSVP in Sending Hosts
図3: 送付ホストのRSVP
7.1.2. Requests to Layer 2 ISSLL
7.1.2. 層2のISSLLへの要求
The local admission control entity within a client is responsible for mapping Layer 3 session establishment requests into Layer 2 semantics.
クライアントの中の地方の入場コントロール実体はLayer3セッション設立要求をLayer2意味論に写像するのに原因となります。
Ghanwani, et al. Informational [Page 19] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[19ページ]のRFC2816枠組み
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(例えば、帯域幅、burstiness、MTU)のために、ここで、>がそこの>=IPが記述するIPアドレス(es)<と等しいという<性能要件>=FlowSpec(例えば、潜在、ジター領域)<(es)を取引します--マルチキャストであるかもしれません。
7.1.3. At the Layer 3 Sender
7.1.3. 層3の送付者で
The ISSLL functionality in the sender is illustrated in Figure 4.
送付者のISSLLの機能性は図4で例証されます。
The functions of the Requester Module may be summarized as follows:
Requester Moduleの機能は以下の通りまとめられるかもしれません:
- 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.
- クライアントが、どんな交通がどこに行くかであるかを決心できるようにLayer2との会話の終点がLANで記述する地図 この機能は、ユニキャストにたぶんARPプロトコルキャッシュを参照するか、またはマルチキャストの目的地にアルゴリズムのマッピングを実行します。
- Communicates with any local Bandwidth Allocator module for local
admission control decisions.
- ローカルの入場コントロール決定のためのどんなローカルのBandwidth Allocatorモジュールでも、交信します。
- 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ヘッダー」テーブルでこのセッションに関連しているようにどんな返されたユーザ_にも優先権を貯蓄します。 このセッションに属する将来のデータ・パケットのためにLayer2ヘッダーを組み立てるとき、これは使用されるでしょう。 例えば、このテーブルはRSVP流れ識別子によって索引をつけられるかもしれません。
Ghanwani, et al. Informational [Page 20] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[20ページ]のRFC2816枠組み
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
+------------------------------+
RSVP+からのIPから----|------------|------------+ | +--V----+ +---V---+ | | | Addr<。--->|、| SBMシグナリング| |マッピング| |要求| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| +---+---+ |モジュール| | | | | | | | +---+---+ | | | | | 802 <。--->|、|、|、| ヘッダー| +-+-+-+-+ | | +--+----+ / | | | | | / | | +-----+ | | | +-----+ | +->|バンド| | | | | | |幅| | | +--V-V-++-----V--+|Alloc| | | |クラス| | パケット| +-----+ | | | ifier|==>Schedulr|=========================>| +------+ +--------+ | データ+------------------------------+
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モデルが実行されるときだけ、Bandwidth Allocator(BA)の部品は存在しています。 存在しているとき、機能は基本的に外向的なリンク帯域幅とドライバーがリソースを列に並ばせるための地方の入場コントロールを適用することです。
7.1.4. At the Layer 3 Receiver
7.1.4. 層3の受信機で
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:
Requester Moduleの機能は以下の通りまとめられるかもしれません:
- 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.
- リクエスタに向かって合図するSBMを通してRSVPから確認を受け入れて、それらをリレーします。
Ghanwani, et al. Informational [Page 21] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[21ページ]のRFC2816枠組み
to RSVP to IP
^ ^
+----|------------|------+
| +--+----+ | |
SBM signaling | |Request| +---+---+ |
<-------------> |Module | | Strip | |
| +--+---++ |802 hdr| |
| | \ +---^---+ |
| +--v----+\ | |
| | Band- | \ | |
| | width| \ | |
| | Alloc | . | |
| +-------+ | | |
| +------+ +v---+----+ |
data | |Class-| | Packet | |
<==============>| ifier|==>|Scheduler| |
| +------+ +---------+ |
+------------------------+
IP^ ^ +へのRSVPに----|------------|------+ | +--+----+ | | SBMシグナリング| |要求| +---+---+ | <、-、-、-、-、-、-、-、-、-、-、-、-->| モジュール| | 片| | | +--+---++ |802 hdr| | | | \ +---^---+ | | +--v----+\ | | | | バンド| \ | | | | 幅| \ | | | | Alloc| . | | | +-------+ | | | | +------+ + v---+----+ | データ| |クラス| | パケット| | <=======>| ifier|==>|スケジューラ| | | +------+ +---------+ | +------------------------+
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.
- 使用されるならaがクラシファイアとスケジューラを受けるプログラムが、容認されたパケットの交通のクラスを特定して、適切な処理をそれらに与えますように、例えば、バッファの特定の交通の予約は属します。
- 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.
Bandwidth Allocator、分配された実現だけにおけるプレゼントは適切なローカルと共に要求を支持できるならリソースを受け取るように確実にするために地方の入場コントロールを当てはまります。
7.2. Switch Model
7.2. スイッチモデル
7.2.1. Centralized Bandwidth Allocator
7.2.1. 集結された帯域幅アロケータ
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.
集結されたBandwidth Allocatorモデルが実行されるところでは、スイッチは入場コントロールの過程に参加しません。 集結されたBA、例えば、[14]で説明される「サブネット帯域幅マネージャ」(SBM)によって入場管理は実施されます。 この集結されたBAは実際にスイッチで共同見つけられるかもしれませんが、そして、分配されたBAが以下で説明されている状態でそうであるように機能は必ず密接にスイッチの推進機能で結ばれるというわけではないでしょう。
Ghanwani, et al. Informational [Page 22] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[22ページ]のRFC2816枠組み
7.2.2. Distributed Bandwidth Allocator
7.2.2. 分配された帯域幅アロケータ
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:
ここで説明されたLayer2スイッチの振舞いのモデルは入場制御プロトコルに関する例として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つの例が、クライアントか他のスイッチでじっと見るためにシグナリングプロトコルの「ネットワーク」側を実行します。 また、それはIntServのクラスのマッピングに関する知識をユーザ_優先権として保持します。
- SBM Propagation Module: Relays requests that have passed
admission control at the input port to the relevant output ports'
SBM modules. This will require access to the switch's forwarding
table (Layer-2 "routing table" cf. RSVP model) and port spanning
tree state.
- SBM伝播モジュール: 入力ポートで関連出力ポートのSBMモジュールに入場コントロールを通過した要求をリレーします。 これはスイッチの推進テーブルへのアクセスを必要とするでしょう。(層-2「経路指定テーブル」Cf。 RSVPモデル) そして、スパニングツリー状態を移植してください。
- Output SBM Module: Forwards requests to the next Layer 2 or Layer
3 hop.
- SBMモジュールを出力してください: 前方に、次のLayer2かLayer3への要求は跳びます。
- 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
- クラシファイア、待ち行列、およびスケジューラモジュール: IEEE 802.1DのForwarding Processによって説明されるようにこのモジュールの機能は基本的にそうです。([3])のセクション3.7を見てください。 Classifierモジュールは、どの出力ポートと交通のクラスでパケットを待ち行列に入れると決めるかに入って来るパケットから関連QoS情報を特定して、正常な橋の推進データベースと共にこれを使用します。 異なったタイプのスイッチは流れ識別に異なったテクニックを使用するでしょう(セクション8.1を見てください)。 この情報はIEEE 802.1Dスイッチでは、既にMACが修理する受信で解読されて、推進工程で潜在的に再写像された作り直されたユーザ_優先権パラメタです。([3])についてセクション3.7.3を見てください。 これは個々のIntServ流れの分類などの、より精巧な分類規則を排除しません。 QueueとSchedulerは実行します。
Ghanwani, et al. Informational [Page 23] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[23ページ]のRFC2816枠組み
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.
出力キュー、約束のIntServサービスを提供するために出力リンクにトランスミッションのための待ち行列を修理するためのアルゴリズムを移植して、提供してください。 スイッチは1ポートあたり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で説明されるようにあります。 この任意のモジュールは、順応のために交通のクラスの中で交渉されたパラメタまでデータを取り締まって、パケットを捨てるか、またはユーザ_優先権を再写像するかもしれません。 デフォルトの振舞いは変わりがない状態で終わったものを渡すことです。
- 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で説明されるようにあります。 この任意のモジュールは出力ポート基礎あたりのaに交通のクラスに関する再マッピングを実行するかもしれません。 デフォルトの振舞いは変わりがない状態で終わったものを渡すことです。
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.
ISSLLのモジュールのすべてが可能にした図6ショーは切り替わります。 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
========+ +========>
+-------------------------------+ SBMシグナリング| +-----+ +------+ +------+ | SBMシグナリング<。------------------>| IN| <->| SBM| <->| アウト| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| SBM| | 支柱、|| SBM| | | +-++--+ +---^--+ /----+-+ | | / | | / | | ______________| / | | | | +-------------+ | \/+--V--+| | +--V--+ /| | \ ____/ |ローカル| | | |ローカル| / | | \ / |Admis| | | |Admis| / | | \/ |Cntrl| | | |Cntrl| / | | +-----V+\+-----+ | | +-----+ /+-----+ | | |traff| \ +---+--+ + V-------+ / |egrss| | | |クラス| \ |フィルタ| |待ち行列| / |traff| | | |地図|=====|==========>|データ|=| パケット|=|===>|クラス| | | |警察| | | ベース| |スケジュール| | |地図| | | +------+ | +------+ +--------+ | +-+---+ | +----^---------+-------------------------------+------|------+ 中のデータ| |データアウト========+ +========>。
Figure 6: ISSLL in a Switch
図6: スイッチのISSLL
Ghanwani, et al. Informational [Page 24] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[24ページ]のRFC2816枠組み
7.3. Admission Control
7.3. 入場コントロール
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」であるなら、それは、どんな容認されたユーザ_優先権も翻訳するか、または要求と互換性があるように見えて、使用が大挙して少しの施政方針にも違反しないLayer2交通のクラスを選択します。 事実上、それは、利用可能な交通のクラスに要求されたサービスに匹敵して、1つを「最もよく」選びます。 それは、この予約がうまくいくならその交通のクラスに対応するユーザ_優先権の価値がクライアントに戻されるのを確実にします。
- 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.
- 出口帯域幅会計士は、配分の外国行きのポートに関するリソースを列に並ばせて、帯域幅の現状のときにリンク自体の上に見て、新しい配分を設備することができるかどうかと決心しています。 これがこのスイッチホップでのローカルの決定にすぎないことに注意してください。 ネットワークを通した一層のLayer2ホップはそれとしての要求が回す拒否権がそうするかもしれません。
- 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.
- このスイッチで受け入れるなら、選択されたそれぞれの出力リンクの上に要求を伝播します。 どんな出口マッピングテーブルに従っても、優先権が転送された要求で説明したどんなユーザ_も翻訳しなければなりません。
- 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.
- 受け入れるなら、スイッチは、ユーザ_優先権のクライアントがその流れに属すパケットに使用されるように通知しなければなりません。 一方、これは入場コントロールが成功すると仮定する楽観的なアプローチです。 川下のスイッチは要求を拒否するかもしれません。
Ghanwani, et al. Informational [Page 25] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[25ページ]のRFC2816枠組み
- 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.
- このスイッチが要求を拒絶したいなら、それが、Layer2アドレスによって要求を溯源したクライアントに通知することによって、そうできます。
7.4. QoS Signaling
7.4. QoSシグナリング
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]が以下で説明されるかどうかということであるサービス定義。 私たちはそのようなシグナリングプロトコル実体で交換される必要がある基関数と情報を例証します。 全部で例について適切である、また確立したセッションを取りこわしながら備えられるためにメカニズムにはいる/クリーンアップを削除してください。
7.4.1. Client Service Definitions
7.4.1. クライアントサービス定義
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プロトコル相互作用を必要とするかもしれない簡単なルックアップ機能かアルゴリズムのマッピングです。 メッセージに合図することにおける包含が、マッピングを実行するのにシグナリングに参加するスイッチがLayer3情報を持つのが必要であることを避けるように、Layer2アドレスはSBMによって必要とされます。
l2_addr = map_address( ip_addr )
l2_addrは地図_アドレスと等しいです。(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.
これが通知するものである、どうLayer2ヘッダー情報を加えるかに関する経路を伝えてください、例えば、それぞれの外向的な流れの交通へのユーザ_優先順位の値。 それが、MAC層が各パケットのための操作を伝えるよう要求するときには意志がユーザ_優先順位の値を提供する経路を伝えてください。 ユーザ_優先権はIEEE802サービスモデルによって定義されて、パケットで通過されたパラメタの1つが原始的に伝わるということです。
bind_l2_header( flow_id, user_priority )
ひも_l2_ヘッダー(流れ_イド、ユーザ_優先権)
- 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
これは通知がパケット流動の送信の計画をすると関連しているどんな追加Layer2情報のクラシファイア/スケジューラも送るからです。 それは使用されるかもしれません、そして、この基関数がいくつかの実現で未使用であるかもしれません、または例えば、情報をaに提供するために、交通単位で働いているスケジューラを送ってください。
Ghanwani, et al. Informational [Page 26] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[26ページ]のRFC2816枠組み
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.
に加えてクラススケジューリング、流れに従って、スケジューリングがIntServが必要です。 Layer2ヘッダーは、流れの交通を特定するのに使用されるためにはパターンであるかもしれません(FilterSpecに加えた)。
bind_l2schedulerinfo( flow_id, , l2_header, traffic_class )
ひも_l2schedulerinfo(流れ_イド、l2_ヘッダー、交通_のクラス)
- 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.
セッションのための地方の入場コントロールを適用して、例えば、十分があるので、使用されるこれはこの新しいセッションのためのまだ未遂の帯域幅を伝えますか? 十分な受信バッファがありますか? 成功するなら、これは必要なリソースを遂行するべきです。 入場コントロールがその後のノードで失敗すると、後期段階にこれらのリソースを発表するのが必要でしょう。 例えば、この電話はセグメントのDesignated SBMによってかけられるでしょう。
status = admit_l2session( flow_id, Tspec, FlowSpec )
状態=は_l2sessionを認めます。(流れ_イド、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の今後の活動で指定されると予想されます。
7.4.2. Switch Service Definitions
7.4.2. スイッチサービス定義
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.
これが通知するものである、どう入って来るLayer2情報に関連交通のクラスに匹敵するかに関するクラシファイアを受けてください。 いくつかの場合、それは1セットの書き込み禁止デフォルトマッピングから成るかもしれません。
bind_l2classifierinfo( flow_id, l2_header, traffic_class )
ひも_l2classifierinfo(流れ_イド、l2_ヘッダー、交通_のクラス)
- 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).
これは通知が与えられた交通のクラスに関連している追加Layer2情報のスケジューラを送るからです。 いくつかの場合、それは未使用であるかもしれません(前項の議論を見てください)。
Ghanwani, et al. Informational [Page 27] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[27ページ]のRFC2816枠組み
bind_l2schedulerinfo( flow_id, l2_header, traffic_class )
ひも_l2schedulerinfo(流れ_イド、l2_ヘッダー、交通_のクラス)
- 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.
それを再写像するどんなユーザ_優先権の任意の構成もスイッチのポートからのイングレスと出口で実行されるかもしれません。 IEEE 802.1Dスイッチに関しては、これらのマッピングはすべてのポートの向こう側に一貫しなければならなそうでしょう。
bind_l2ingressprimap( inport, in_user_pri, internal_priority )
bind_l2egressprimap( outport, internal_priority, out_user_pri )
ひも_l2ingressprimap(_ユーザ_pri、内部の_優先権における「不-ポート」)ひも_l2egressprimap(_ユーザ_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.
Layer2ヘッダーを合わせながらクラス基礎あたりのaで交通に適用されるために機能を取り締まるどんなLayer2の任意の構成。 スイッチが流れ単位で取り締まることができると、既存のIntServ/RSVPモデルはその構成のためのサービス定義を提供するでしょう。
bind_l2policing( flow_id, l2_header, Tspec, FlowSpec )
ひも_l2policing(流れ_イド、l2_ヘッダー、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に転送するかを決定するためにLayer2推進データベースへのアクセスを必要とします。 これはLayer3RSVPでRSRRインタフェースに類似しています。
output_portlist = lookup_l2dest( l2_addr )
出力_「恰幅のい-者」はルックアップ_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ワーキンググループにおける今後の活動で指定されると予想されます。
8. Implementation Issues
8. 導入問題
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
より早く述べられるように、Integrated Servicesですワーキンググループが定義された様々なサービスのクラスに異なった度のQoS保証を提供させる。 初期の努力はControlled Load[6]とGuaranteed Serviceのクラス[7]を有効にするのに結集されるでしょう。 Controlled Loadサービスは「ベストエフォート型と同じくらいが降ろされたネットワークにあるだろう」ので非公式に述べられたゆるい保証を提供します。 Guaranteed Serviceはどんなパケットのトランジット遅れでも上限を提供します。 The
Ghanwani, et al. Informational [Page 28] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[28ページ]のRFC2816枠組み
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.
リンクレイヤでこれらのサービスを支持できる範囲は使用されるトポロジーと技術を含む多くの要素に依存するでしょう。 現れているリンクレイヤ規格と、より高い層のプロトコルでサポートされた機能の観点から以下でマッピング問題のいくつかについて議論します。 いくらかのtopologiesの制限を考える場合、与えられたトポロジーのIntegrated Servicesのためのすべての要件を満たすのは可能でないかもしれません。 そのような場合、ほとんどの実用的な例で十分であるかもしれないサービスの近似のサポートを提供すると考えるのは役に立ちます。 例えば、提供するのは、必要に応じてそれぞれのネットワーク要素(橋/スイッチ)でControlled Load仕様で取り締まるか、または形成しながら、可能でないかもしれません。 しかし、端のステーションにこのタスクを任せるなら、サービスへのかなり良い近似を得ることができます。
8.1. Switch Characteristics
8.1. スイッチの特性
There are many LAN bridges/switches with varied capabilities for supporting QoS. We discuss below the various kinds of devices that that one may expect to find in a LAN environment.
QoSを支持するための様々な能力がある多くのLAN橋/スイッチがあります。 私たちは様々な種類の装置の下でLAN環境で見つける予想するかもしれないそれについて議論します。
The most basic bridge is one which conforms to the IEEE 802.1D specification of 1993 [2]. This device has a single queue per output port, and uses the spanning tree algorithm to eliminate topology loops. Networks constructed from this kind of device cannot be expected to provide service guarantees of any kind because of the complete lack of traffic isolation.
最も基本的な橋は1993[2]のIEEE 802.1D仕様に従うものです。 この装置は、出力ポートあたり1つのただ一つの待ち行列を持って、トポロジー輪を排除するのにスパニングツリーアルゴリズムを使用します。 この種類の装置から構成されたネットワークが交通孤立の完全な不足のためにどんな種類のサービス保証も提供することを期待できません。
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つのトラフィックのクラスを列に並ばせるサポートを含んでいます。 特定のトラフィックのクラスに対応するすべての流れが集められるので、分離が提供したトラフィックのレベルは粗いです。 さらに、トラフィックのクラスへの地図がスイッチで実装された待ち行列の数によって、1つ以上の優先権がありそうになるのは、ありそうです。 そのようなデバイスがふらちな事する流れに対する保護を提供するのは、難しいでしょう。 マルチキャストトラフィックの範囲は、関心がある受信機には経路にないそれらのセグメントしか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.
これらのデバイスの上のA次ステップがaでいくつかの容認されたユーザ_優先権を写像などなどのインターナルが設定した正準な値のIEEE 802.1D仕様のオプショナル・パーツを実装するブリッジ/スイッチである、-、入力ポート、基礎。 また、それがaでこれらの内部の正準な値に関するマッピングを伝えられたユーザ_優先権にサポートするかもしれない、-、出力ポート基礎。 特定の組のポートの間のトラフィックのクラスに関するマッピングを実行するので、これらの付加的な能力で、ネットワーク管理者は、することでトラフィックの入場の、より多くのコントロールを保護されたクラスに獲得できます。
Ghanwani, et al. Informational [Page 29] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[29ページ]のRFC2816フレームワーク
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.
いくつかのブリッジ/スイッチがサポートするかもしれない他の完全に任意の特徴は、トラフィックのクラスによって消費された帯域幅を制限するのにネットワーク層ヘッダー、1流れあたりの取り締まり、そして/または、Guaranteed Serviceをサポートするのに、不可欠であることの造り直すことにおける分野、および均等化キューイングの異形などの、より精巧なスケジューリングアルゴリズムを使用することでIntServ流れの分類を含んでいます。 Controlled LoadとGuaranteed Serviceをサポートするために流れ分離を実行して、すべてのネットワーク要素が各流れを取り締まるのが、有利であることに注意してください。
8.2. Queuing
8.2. 列を作ります。
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.
時間重要なトラフィックの到来に従って、そのような食糧を供給し過ぎることは達成するのがはるかに簡単でなくなりました。 時間重要なフレームはうるさく長い期間にファイル転送トラフィックの一時的な炸裂の後ろに列に並ばせられるかもしれません、特にネットワークボトルネックポイントで、例えば、配線クロゼットへの起床者とユーザへの最終的なリンクの間にデスクトップスイッチから起こるかもしれない10Mbps変遷への100Mbpsで。 しかしながら、時間重要なトラフィックが総帯域幅のわずかな部分であることが先験的(アプリケーション設計、または統計に基づいた運営管理コントロールで)に知られているなら、この場合それを優先させるために厳しい十分である、終わっている、非、-、時間重要なトラフィック。 最悪の場合遅れが経験した、-、重要なトラフィックがおよそ最大の長さの最大のトランスミッション時間である、非時間重要である、フレーム--1ミリセカンド未満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つ以上の優先サービスがネットワーク要素で提供することであるときに、Controlled LoadとGuaranteed Serviceの両方をサポートするもの、スケジューリング規律のための例えば要件は、より複雑になります。 サービスのクラスの間に必要な分離を提供するために、別々にそれらを列に並ばせるのがたぶん必要でしょう。 その時、どう入場コントロールと、より知的な待ち行列の規律の組み合わせを必要とする待ち行列を修理するかに関する問題があります。 サービス仕様自体のように、待ち行列アルゴリズムの仕様はこのドキュメントの範囲を超えています。
Ghanwani, et al. Informational [Page 30] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[30ページ]のRFC2816フレームワーク
8.3. Mapping of Services to Link Level Priority
8.3. リンク・レベル優先権に対するサービスのマッピング
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.
クラスがサポートしたトラフィックの数と考慮している技術のアクセス法は、どんな何、とサービスがサポートされるかもしれないかを決定するでしょう。 例えば、ネイティブのToken Ring/IEEE802.5は1つ以上のトラフィックのクラスに写像されるかもしれない8つの優先順位をサポートします。 イーサネット/IEEE802.3はフレームの中にシグナリングプライオリティのサポートを全く持っていません。 しかしながら、IEEE802規格委員会は最近、マルチメディアのトラフィックの速めていてダイナミックなマルチキャストフィルタリング[3]に関連するブリッジ/スイッチの新しい規格を開発しました。 すべてのIEEE802LANメディアタイプの上のユーザ_優先権野原を運ぶためのパケット・フォーマットは現在、[4]で定義されます。 これらの規格は8まですべてのメディアのトラフィックのクラスを許容します。 フレームで運ばれたユーザ_優先権ビットはブリッジ/スイッチの中の特定のトラフィックのクラスに写像されます。 ブリッジ/スイッチ経営者側によってくつがえされない場合、ユーザ_優先権は終わりから終わりへのベースで合図されます。 望まれていて、予約がうまくいっているか否かに関係なく、流れによって使用されるトラフィックのクラスはサービスの質に依存するべきです。 したがって、送付者がユーザ_優先順位の値を使用するべきである、どれ、そうでなくBMによって言われるまで、ベストエフォート型トラフィックのクラスに写像するか。 資源予約の無事終了のときに、そのセッションのデータに送付者によって使用されるように、BMはユーザ_優先権の価値を指定するでしょう。 付随のメモ[13]はトラフィックのクラスを当てるために様々なIntegrated Servicesを写像する問題を扱います。
8.4. Re-mapping of Non-conforming Aggregated Flows
8.4. 非の従うのに関する再マッピングは流れに集められました。
One other topic under discussion in the IntServ context is how to handle the traffic for data flows from sources that exceed their negotiated traffic contract with the network. An approach that shows some promise is to treat such traffic with "somewhat less than best effort" service in order to protect traffic that is normally given "best effort" service from having to back off. Best effort traffic is often adaptive, using TCP or other congestion control algorithms, and it would be unfair to penalize those flows due to badly behaved traffic from reserved flows which are often set up by non-adaptive applications.
IntServ文脈で議論での他の1つの話題はネットワークとの彼らの交渉されたトラフィック契約を超えているソースからのデータフローのためにどうトラフィックを扱うかということです。 何らかの見込みを示しているアプローチは通常、有からの「ベストエフォート型」のサービスが引き返すために与えられているトラフィックを保護するために「いくらかベストエフォート型あまりでない」サービスでそのようなトラフィックを扱うことです。 TCPか他の輻輳制御アルゴリズムを使用して、ベストエフォート型トラフィックはしばしば適応型です、そして、非適応型のアプリケーションでしばしばセットアップされる予約された流れからひどく振る舞っているトラフィックによるそれらの流れを罰するのは不公平でしょう。
A possible solution might be to assign normal best effort traffic to one user_priority and to label excess non-conforming traffic as a lower user_priority although the re-ordering problems that might arise from doing this may make this solution undesirable, particularly if the flows are using TCP. For this reason the controlled load service recommends dropping excess traffic, rather than re-mapping to a lower priority. This is further discussed below.
可能なソリューションは、このソリューションがこれをすることにおける起こるかもしれない再注文問題で望ましくなくなりますが、1つのユーザ_優先権に正常なベストエフォート型トラフィックを割り当てて、下側のユーザ_優先度として非従っているトラフィックと過剰をラベルすることであるかもしれません、特に流れがTCPを使用しているなら。 この理由で、制御負荷サービスは、再マッピングよりむしろ余分なトラフィックを低優先度に下げることを勧めます。 以下でさらにこれについて議論します。
Ghanwani, et al. Informational [Page 31] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[31ページ]のRFC2816フレームワーク
8.5. Override of Incoming User Priority
8.5. 入って来るユーザ優先権のオーバーライド
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.
いくつかの場合、ネットワーク管理者は、ソースからパケットに含まれたユーザ_優先順位の値を信じないで、それ以上の適当な値にこれらを写像したがっているかもしれません。 あるいはまた、恐らく設備制限か過渡期への支払われるべきもの、ユーザ_優先順位の値はデータがネットワークの異なった領域からの/に流れるので再写像される必要があるかもしれません。
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 Regeneration TableとしてIEEE 802.1Dで知られているテーブルはこの機能を提供します。([3])のテーブル3-1。 そして、上で外向的なユーザ_優先順位の値に説明された出力テーブルを使用することでこれらの値を写像できます。 また、ユーザ_優先順位の値を使用する要求に入場コントロールを適用するとき、これらの同じマッピングを使用しなければなりません。(例えば、[14])を見てください。 また、デバイスが交通の流れを取り締まって、彼らの順応に基づくそれらの前方のユーザ_優先権を認められた交通の流れ仕様に調整するところで、より洗練されたアプローチも可能です。
8.6. Different Reservation Styles
8.6. 異なった予約様式
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によって要求されたサービスが異なるなら、このシナリオはさらに複雑です。 したがって、ブリッジ/スイッチの中の取り締まりが不在のとき、リンクレイヤで固定フィルタの予約だけをサポートするのは可能であるかもしれません。
Ghanwani, et al. Informational [Page 32] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[32ページ]のRFC2816フレームワーク
+-----+ +-----+ +-----+
| S1 | | S2 | | S3 |
+-----+ +-----+ +-----+
| | |
| v |
| +-----+ |
+--------->| SW |<---------+
+-----+
| |
+----+ +----+
| |
v V
+-----+ +-----+
| R1 | | R2 |
+-----+ +-----+
+-----+ +-----+ +-----+ | S1| | S2| | S3| +-----+ +-----+ +-----+ | | | | v| | +-----+ | +--------->| SW| <、-、-、-、-、-、-、-、--+ +-----+ | | +----+ +----+ | | V+に対して-----+ +-----+ | R1| | R2| +-----+ +-----+
Figure 7: Illustration of filter styles
図7: フィルタスタイルのイラスト
8.7. Receiver Heterogeneity
8.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.
Layer3では、IntServモデルはマルチキャスト流れのための木の異なった枝が異なったタイプの与えられたマルチキャストの目的地の予約を持つことができる異種の受信機を許容します。 また、木には予約された流れと何かがベストエフォート型サービスを利用しているいくつかのブランチがあるかもしれないのはその考えを支持します。 私たちが[8]で定義されるようにただ一つのネットワーク要素としてLayer2サブネットを扱うなら、同じQoS処理を必要として、あいさつとしての原子力ユニットとして扱われた入場コントロールであるのなどとサブネットに属す分配木の枝のすべてを思うことができるでしょうに。 この仮定に、IntServとRSVPによって既に定義されたモデルとプロトコルは既にマルチキャストの異種性の十分なサポートを提供します。 しかしながら、サブネットにおけるちょうど1個のリンクが全体のサブネットのための予約の要請の拒絶への申込みが超過している先導であるので入場コントロール要求がたぶん拒絶されるだろうことに注意してください。
As an example, consider Figure 8, SW is a Layer 2 device (bridge/switch) participating in resource reservation, S is the upstream source end station and R1 and R2 are downstream end station receivers. R1 would like to make a reservation for the flow while R2 would like to receive the flow using best effort service. S sends RSVP PATH messages which are multicast to both R1 and R2. R1 sends an RSVP RESV message to S requesting the reservation of resources.
SWは資源予約に参加するLayer2デバイス(ブリッジ/スイッチ)です、そして、Sは上流のソース端のステーションです、そして、例と、図8を考えてください、そして、R1とR2は川下の終わりのステーション受信機です。 R2がベストエフォート型サービスを利用することで流れを受けたがっている間、R1は流れの予約をしたがっています。 SはR1とR2の両方へのマルチキャストであるメッセージをRSVP PATHに送ります。 R1はリソースの予約を要求するSにRSVP RESVメッセージを送ります。
Ghanwani, et al. Informational [Page 33] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[33ページ]のRFC2816フレームワーク
+-----+
| S |
+-----+
|
v
+-----+ +-----+ +-----+
| R1 |<-----| SW |----->| R2 |
+-----+ +-----+ +-----+
+-----+ | S| +-----+ | +に対して-----+ +-----+ +-----+ | R1| <、-、-、-、--、| SW|、-、-、-、--、>| R2| +-----+ +-----+ +-----+
Figure 8: Example of receiver heterogeneity
エイト環: 受信機の異種性に関する例
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.
予約がLayer2にうまくいくと、グループに扱われたフレームは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アドレス(それぞれのクラスのサービスのためのもの)がある別々のグループを持つだろうことです。 デフォルトで、受信機は流れがベストエフォート型として分類される「ベストエフォート型」のグループに加わるでしょう。 受信機が首尾よく予約をするなら、望まれていたサービスのクラスのためにそれをグループに移すことができます。 ブリッジとスイッチが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.
Layer2サブネットの予想されたサイズと複雑さを考えて、上のアプローチはリソースの非常にサブ最適の利用を提供するでしょう。 したがって、スイッチがそのスイッチで分裂する木の異なった出口枝の上にQoSを異なって当てるのを可能にするのは望ましいです。
Ghanwani, et al. Informational [Page 34] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[34ページ]のRFC2816フレームワーク
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はスイッチがマルチキャスト推進を送付先アドレスに基づく決定にするマルチキャストに基本型を指定します。 これはパケットが送られるべきである出力ポートのリストを作り出すでしょう。 デフォルトモードで、そのようなスイッチが容認されたパケットでユーザ_優先順位の値を使用するだろうか、または値は、明白な値がないときそれぞれの出力ポートでパケットを待ち行列に入れるために入力ポート基礎あたりのaで作り直されました。 複数のトラフィックがクラスであるとサポートするどんなIEEE 802.1Dスイッチもこの操作をサポートすることができます。
If a switch selects per port output queues based only on the incoming user_priority, as described by IEEE 802.1D, it must treat all branches of all multicast sessions within that user_priority class with the same queuing mechanism. Receiver heterogeneity is then not possible and this could well lead to the failure of an admission control request for the whole multicast session due to a single link being oversubscribed. Note that in the Layer 2 case as distinct from the Layer 3 case with RSVP/IntServ, the option of having some receivers getting the session with the requested QoS and some getting it best effort does not exist as basic IEEE 802.1 switches are unable to re-map the user_priority on a per link basis. This could become an issue with heavy use of dynamic multicast sessions. If a switch were to implement a separate user_priority mapping at each output port, then, in some cases, reservations can use a different traffic class on different paths that branch at such a switch in order to provide multiple receivers with different QoS. This is possible if all flows within a traffic class at the ingress to a switch egress in the same traffic class on a port. For example, traffic may be forwarded using user_priority 4 on one branch where receivers have performed admission control and as user_priority 0 on ones where they have not. We assume that per user_priority queuing without taking account of input or output ports is the minimum standard functionality for switches in a LAN environment (IEEE 802.1D) but that more functional Layer 2 or even Layer 3 switches (i.e. routers) can be used if even more flexible forms of heterogeneity are considered necessary to achieve more efficient resource utilization. The behavior of Layer 3 switches in this context is already well standardized by the IETF.
スイッチがポート単位でIEEE 802.1Dによって説明されるように入って来るユーザ_優先権だけに基づく出力キューを選択するなら、それはそのユーザ_優先権のクラスの中で同じ列を作りメカニズムですべてのマルチキャストセッションのすべてのブランチを治療しなければなりません。 次に、受信機の異種性は可能ではありません、そして、これはたぶん申込みが超過している単一のリンクによる全体のマルチキャストセッションを求める入場コントロール要求の失敗に通じるでしょう。 RSVP/IntServ(基本的なIEEE802.1スイッチがリンク基礎あたりのaでユーザ_優先権を再写像できないときそれがベストエフォート型になる要求されたQoSといくつかとのセッションを得るとするいくつかの受信機を存在させないオプション)と共にLayer3ケースと異なるとしてLayer2場合でそれに注意してください。 これはダイナミックなマルチキャストセッションの重い使用の問題になることができました。 スイッチがそれぞれの出力ポートで別々のユーザ_優先権マッピングを実装するつもりであったなら、いくつかの場合、予約は異なったQoSを複数の受信機に提供するためにそのようなスイッチで分岐する異なった経路の異なったトラフィックのクラスを使用できます。 すべてがポートの上をイングレスにおけるトラフィックのクラスの中を同じトラフィックのクラスでスイッチ出口に流れるなら、これは可能です。 例えば、受信機が入場コントロールを実行したところと、そして、それらがそうしていないものに関するユーザ_優先権0として1つの支店でユーザ_優先権4を使用することでトラフィックを進めるかもしれません。 私たちは、入力か出力ポートを考慮に入れないで列を作るユーザ_優先権あたりのそれがLAN環境(IEEE 802.1D)におけるスイッチのための最低基準の機能性であると思いますが、さらにフレキシブルなフォームの異種性が、より効率的なリソース利用を達成するのに必要な状態で考えられるなら、そのより機能的なLayer2かLayer3スイッチ(すなわち、ルータ)さえ使用できます。 Layer3スイッチの働きはIETFによってこのような関係においては既によく標準化されます。
9. Network Topology Scenarios
9. ネットワーク形態シナリオ
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
ネットワークがサービス保証を提供できる範囲は入場コントロールと取り締まりに加えて流れ識別とスケジューリングの主要な機能を提供するかなり能力に依存します。 このセクションは、考慮でLAN技術の能力のいくつかについて論じて、上の機能をサポートすることに関してそれぞれの能力を強調する可能なtopologiesの分類学を提供します。 the
Ghanwani, et al. Informational [Page 35] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[35ページ]のRFC2816フレームワーク
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の基本的なトポロジーが共有されるかもしれないと考えたか、半二重を切り換えたか、または全二重を切り換えました。 共有されたトポロジーで、複数の送付者がただ一つのセグメントを共有します。 メディアアクセスのための主張は、イーサネットにおけるCSMA/CDなどのプロトコルとToken RingとFDDIのトークンパッシングを使用することで決議されています。 切り換えられた半二重は本質的にはどんなセグメントに関するリソースも競争する2個の送信機しかないという制限がある共有されたトポロジーです。 最終的に、切り換えられた全二重トポロジーでは、完全な帯域幅経路がいつもリンクの各端の送信機に利用可能です。 したがって、このトポロジーには、送信機の間に主張が全くないとき、CSMA/CDかトークンパッシングなどのどんなアクセス管理機構の必要も全くありません。 明らかに、このトポロジーは最も良いQoS能力を提供します。 topologiesの議論における別の重要な要素は、複数のトラフィックのクラスのサポートの存在か欠如です。 より早くセクション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.
また、ハイブリッドtopologiesの可能性が2つの上記以上が共存するところにあります。 例えば、ただ一つのサブネットの中に、トラフィックがクラスであるとサポートするいくつかのスイッチとそうしない何かがあるのは、可能です。 問題の流れがネットワークで両方の種類のスイッチを横断すると、共通項は広がるでしょう。 言い換えれば、その流れに関する限り、横断される中で最もできないトポロジーに対応するタイプにはネットワークがあります。 以下のセクションでは、私たちは詳細のIntServサービスをサポートする彼らの能力の議論がある何人かの異なったIEEE802ネットワークタイプのこれらのシナリオを提示します。
9.1. Full Duplex Switched Networks
9.1. 全二重交換網
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プロトコルは、アクセスが重要でないのですが、ありますが、アクセス潜在が最も大きいパケットを伝えるのに必要である時間と等しくて、デバイスで広告に掲載された特殊化パラメタを要因として考慮しなければなりません。 様々なメディアの特性のための近似値を以下のテーブルに提供します。 また、光速の文脈が遅らせる100mの典型的なUTPリンクへのおよそ400ナノ秒である考えられたコネと7が私たちであるなら、これらの遅れは2kmの典型的な多モード・ファイバーリンクへのそうでしょうに。
Ghanwani, et al. Informational [Page 36] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[36ページ]のRFC2816フレームワーク
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
--------------------------------------------------
-------------------------------------------------- 速度マックスPktマックスアクセス長さの潜在をタイプしてください。-------------------------------------------------- イーサネット10Mbps1.2ms1.2ms100Mbps120、私たち120、私たち1Gbps12、私たち12、私たちToken Ring4Mbps9が私たち8.4に16Mbps9の9ms ms9ms FDDI100Mbps360をmsする、ms Demand Priority100Mbps120、私たち120、私たち--------------------------------------------------
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.
スイッチの適当な列を作り戦略でサポートされると、全二重交換網topologiesはControlled LoadとGuaranteed Serviceの両方のために良いQoS能力を提供します。
9.2. Shared Media Ethernet Networks
9.2. 共有されたメディアイーサネットネットワーク
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アルゴリズムも導入するとすぐに、Guaranteed Serviceのどんなフォームも提供する能力はリンクの上の複数の送付者の間のどんな密結合がないとき真剣に感染されます。 より良いソリューションをこの問題に提供しない多くの理由があります。
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
まず第一に、私たちは、MACプロトコルへの変化を必要とするでしょう、したがって、これが本当に解決できる問題であると信じていません。 IEEE802.1は契約履行保証のために共有されたCSMA/CDイーサネットにMAC増進なしで期待はずれなシミュレーションの結果を示している研究を調べました。 MAC層のプロトコル、例えば、BLAMへの増進のための提案と高められたフロー制御がIEEE802.3にありました。 しかしながら、ISSLLワーキンググループとこのドキュメントの範囲の外に伝統的なIEEE802.3MAC、または他の独占MACプロトコルを超えた高められたソフトウェアMAC実行にかかわるどんなソリューションもあります。 第二に、私たちはそれが本当におもしろい問題であると確信していません。 端のステーションが共用セグメントにここしばらくある間、配布しているスイッチの数は着実に共用セグメントのステーションの数に比例して増加しています。 この傾向は資源予約を必要とするどんなネットワークコミュニケーションも少なくとも1つのスイッチかルータを通して行われると仮定するソリューションを持っているのが満足できるかもしれない肝心の進行です。 別の方法を置いてください、そして、QoSサポートのための既存のLayer2インフラストラクチャへの最も簡単なアップグレードはセグメントの切り換えのインストールです。 これが完了していたときだけ、それ、意味ありげな状態で、より複雑なソリューションを調査するために価値があります。
Ghanwani, et al. Informational [Page 37] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[37ページ]のRFC2816フレームワーク
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.
入場コントロール。 三番目に、キャンパスネットワークのコアは繰り返されたセグメントに関してというよりむしろスイッチに基づくソリューションから通常成ります。 将来、特殊事情があるかもしれませんが、例えば、Gigabitはリピータをバッファリングしましたが、これらのデバイスの特性は既存の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
--------------------------------------------------
-------------------------------------------------- 速度マックスPktマックスアクセス長さの潜在をタイプしてください。-------------------------------------------------- イーサネット10Mbps1.2ms限りない100Mbps120、私たち限りない1Gbps12、私たち、限りなさ--------------------------------------------------
9.3. Half Duplex Switched Ethernet Networks
9.3. 半二重はイーサネットネットワークを切り換えました。
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.
また、共有されたメディアイーサネットにおけるGuaranteed Serviceの潜水艦の最適のサポートのための同じ議論の多くが半二重の切り換えられたイーサネットに適用されます。 本質では、このトポロジーはパケット伝送を競争する少なくとも2人の送付者の間で共有される媒体です。 これらがしっかり結合されていて協力的でない場合、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.
上の議論に耐えないで、半二重の切り換えられたtopologiesはサービスをControlled Loadに供給する機会を提供するように思えます。 特性が彼らのControlled Loadトラフィックにベストエフォート型流れの上でともに優先順位づけを使用している2人の潜在的送付者がまさにいて、決定論的ではありませんが、その知識に基づくそれらの流れ、メディアアクセスのために入場コントロールをして、いくらか予測できるという知識で。 これはたぶんControlled Loadサービスへの十分厳密な役に立つ近似です。
Ghanwani, et al. Informational [Page 38] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[38ページ]のRFC2816フレームワーク
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
------------------------------------------
------------------------------------------ 速度マックスPktマックスアクセス長さの潜在をタイプしてください。------------------------------------------ イーサネット10Mbps1.2ms限りない100Mbps120、私たち限りない1Gbps12、私たち、限りなさ------------------------------------------
9.4. Half Duplex Switched and Shared Token Ring Networks
9.4. 半二重は、トークンリングネットワークを切り換えて、共有しました。
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.
共有されたToken Ringネットワークで、どんなステーションの高い優先権トラフィックのためのネットワークアクセスタイムも、境界があって、(N+1)*THTmaxによって与えられています、Nが高い優先権トラフィックを送るステーションの数であり、THTmaxが最大のトークン把持時間[14]であるところで。 これが、ネットワークアダプターには優先待ち行列があると仮定するので、最優先が現在アダプターに列に並ばせられている状態で、トークンのその予約はトラフィックのために終わっています。 NかTHTmaxを減少させることによってアクセスタイムを改良できるのがわかるのは簡単です。 THTmaxにおけるお勧めのデフォルトは10ms[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
----------------------------------------------------
テーブル7: 半二重は切り替わりました、そして、共有されたToken Ringメディアは潜在にアクセスします。---------------------------------------------------- 速度マックスPktマックスアクセス長さの潜在をタイプしてください。---------------------------------------------------- トークンRing4/16のMbpsの分配している9ms2570ms4/16Mbpsは私たち8がmsする9ms30ms FDDI100Mbps360を切り換えました。----------------------------------------------------
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
アクセスタイムは境界があるなら、必要に応じてこのクラスのトラフィックがユーザトラフィックにおいて、許容できる最優先を使用すると仮定するGuaranteed Serviceで終わりから終わりへの遅れに上限を提供するのが可能です。 Guaranteed Serviceと同じトラフィックのクラスに写像されたトラフィックを送るステーションの実数は時間がたつにつれて、異なるかもしれませんが、入場コントロール見地から、この値が先験的に必要です。 したがって、入場コントロール実体はNに一定の価値を使用しなければなりません。(提供された遅れ保証をより小さく保つのが必要であるなら、それは、リングか何らかの下側の値のステーションの総数であるかもしれません)。 中古であるNの値であるなら、必須がそれを確実にするリングの上のステーションの総数より低い入場コントロールは送付の高い優先権トラフィックが決して超えていないステーションの数ですか?
Ghanwani, et al. Informational [Page 39] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[39ページ]のRFC2816フレームワーク
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ステーションのすべてが高い優先権データを送ると仮定するのを遅らせると見積もることができます。
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.
Controlled Loadが流れると仮定して、Controlled Loadが流れるのでGuaranteed Service、潜在を提供できるアクセスでの上限がないことによって使用されるそれより低くトラフィックのクラスを使用してください。 しかしながら、Controlled Load流れはベストエフォート型流れより良いサービスを受けるでしょう。
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.
多くの既存の共有されたTokenリングスでは、ブリッジがフレームのフレーム制御フィールドで運ばれたユーザ_優先権の如何にかかわらず4のAccess Priority(セクション4.3を見る)値を使用することでフレームを伝えるというメモ。 したがって、既存のブリッジは、実際に上のアクセスタイム領域を使用できる前に、再構成されるか、または変更される必要があるでしょう。
9.5. Half Duplex and Shared Demand Priority Networks
9.5. 半二重と共有された要求優先権ネットワーク
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.
802.12のネットワーク、エンドノードとハブとハブ自体とのコミュニケーションに基づいているIEEEでは、リンク制御の交換は合図します。 これらの信号は、共有された媒体へのアクセスを制御するのに使用されます。 通常の優先権要求に役立つことの途中に別のハブがありますが、例えば、ハブが高い優先権要求を受け取るなら、事実上、最初に高い優先権要求に役立つように後者のハブのサービスを先取りできます。 ネットワークがすべての高い優先権要求を処理した後に、それは中断されたネットワークで通常のポイントでの優先サービスを再開します。
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
すべての間の100mの長さが定義されるように最大570ナノ秒の伝播遅延を使用するノードとハブを終わらせるUTPの物理的な層とケーブルのために高い優先権アクセスタイムに関する上限を以下に与えます。
Ghanwani, et al. Informational [Page 40] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[40ページ]のRFC2816フレームワーク
[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: 半二重はDemand Priority 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
------------------------------------------------------------
------------------------------------------------------------ 速度マックスPktマックスアクセス長さの潜在をタイプしてください。------------------------------------------------------------ Priority100Mbpsを要求してください、802.3がpktされて、UTP120が私たち私たち802.5がpktする254歳であり、UTP360が私たち733歳である、私たち------------------------------------------------------------
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.
レベル「N」をどっと落させていながらハブを使用することで共有されたIEEE802.12topologiesを分類できます。 最も簡単なトポロジーはただ一つのハブネットワーク(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と対照して、光ファイバーの物理的な層は二元的なシンプレクスモードで作動します。 2kmの多モード・ファイバーが10の伝播遅延に私たちをリンクするので、高い優先権アクセスタイムのための上限を以下に与えます。
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].
すべてのエンドノードの間の最大2kmの距離がある共有されたメディアとハブに関しては、IEEE802.12規格は2つの最大の滝のレベルを許容します。 どっと落しているtopologiesの、より高いレベルは、サポートされますが、距離[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.
境界があるアクセス遅延と決定論的なネットワークアクセスはGuaranteed ServiceとControlled Loadに必要であるサービス委任のサポートを許します、共有されたメディアtopologiesでさえ。 しかしながら、802.12における、ちょうど2つの優先順位のサポートは同時にネットワークの向こう側に実装することができるサービスの数を制限します。
Ghanwani, et al. Informational [Page 41] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[41ページ]のRFC2816フレームワーク
Table 9: Shared Demand Priority UTP access latency
テーブル9: 共有されたDemand Priority 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
---------------------------------------------------------------- 速度マックスPktマックスアクセストポロジー長さの潜在をタイプしてください。---------------------------------------------------------------- Priority100Mbpsを要求してください、802.3pkt120、私たち262、私たちN=1 120、私たち554、私たちN=2 120、私たち878、私たちN=3 120、私たち1.24が私たち1.63がmsするN=4 120を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
-----------------------------------------------------------------
Priority100Mbpsを要求してください、802.5pkt360、私たち722、私たちN=1 360、私たち1.41が私たち2.32がmsするN=2 360をmsする、N=3 360、私たち3.16が私たち4.03がmsするN=4 360を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
-------------------------------------------------------------
テーブル10: 半二重はDemand Priorityファイバーアクセス潜在を切り換えました。------------------------------------------------------------- 速度マックスPktマックスアクセス長さの潜在をタイプしてください。------------------------------------------------------------- Priority100Mbpsを要求してください、802.3がpktされて、ファイバー120が私たち私たち802.5がpktする139であり、ファイバー360が私たち379である、私たち-------------------------------------------------------------
Table 11: Shared Demand Priority fiber access latency
テーブル11: 共有されたDemand Priorityファイバーアクセス潜在
---------------------------------------------------------------
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
--------------------------------------------------------------- 速度マックスPktマックスアクセストポロジー長さの潜在をタイプしてください。--------------------------------------------------------------- Priority100Mbps、802.3pkt120を要求してください、私たち160、私たちN=1 120、私たち202、私たちN=2
Demand Priority 100 Mbps, 802.5 pkt 360 us 400 us N = 1
360 us 682 us N = 2
---------------------------------------------------------------
Priority100Mbps、802.5pkt360を要求してください、私たち400、私たちN=1 360、私たち682、私たちN=2---------------------------------------------------------------
10. Justification
10. 正当化
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?
明白な関心はこのモデルの複雑さです。 それが本質的には、RSVPがLayer3で既にすることをするので、私たちは、なぜLayer2でこの問題にソリューションを再発明することによって順調であることができると考えますか?
Ghanwani, et al. Informational [Page 42] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[42ページ]のRFC2816フレームワーク
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問題のかなりの部分をカバーする多くの簡単なLayer2シナリオがあるということです。 かなり低い費用で問題の大部分をカバーするソリューションは有益です。 すべての問題、しかし、説明されたアーキテクチャを実装するデバイスを完全に決議するスイッチかルータが必要であるかもしれない戦略上置かれた高機能における、列を作ることの1流れあたり完全なRSVP/IntServはここにかなり簡単なネットワークを考慮するでしょう。
11. Summary
11. 概要
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技術の上にIntegrated Servicesを提供するのにフレームワークを指定しました。 保証をQoSに供給する能力は何らかの形式の入場コントロールと資源管理を必要とします。 サブネットのための資源管理制度の要件と目標について、特定されて、議論しました。 私たちは全体の資源管理制度をBandwidthマネージャと呼びます。 建築問題について議論しました、そして、Bandwidthマネージャの可能な実装を例証するために例を提供しました。 また、より高い層からリンクレイヤまでのサービスを写像するのにかかわる問題のいくつかについて議論しました。 ISSLLワーキンググループからの付随のメモは、要件に基づくBandwidthマネージャプロトコル[14]と本書では議論した目標に、サービス対応表が問題[13]であると扱って、プロトコル仕様を前提とします。
References
参照
[1] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[1] 地方とメトロポリタンエリアネットワークのIEEE規格: 概要とアーキテクチャ、ANSI/IEEE Std802、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/IEC10038情報技術--システム--ローカル・エリア・ネットワークの間のテレコミュニケーションと情報交換--メディアAccess Control(MAC)は(ANSI/IEEE Std 802.1D1993も)、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/IEC15802-3情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--一般的な仕様--パート3: メディアAccess Control(MAC)は(ANSI/IEEE Std 802.1D-1998も)、1998にブリッジします。
[4] IEEE Standards for Local and Metropolitan Area Networks:
Virtual Bridged Local Area Networks, IEEE Std 802.1Q-1998, 1998.
[4] 地方とメトロポリタンエリアネットワークのIEEE規格: 仮想のブリッジしているローカル・エリア・ネットワーク、IEEE Std 802.1Q-1998、1998。
[5] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource Reservation Protocol (RSVP) - Version 1 Functional
Specification", RFC 2205, September 1997.
[5] ブレーデン、B.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
Ghanwani, et al. Informational [Page 43] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[43ページ]のRFC2816フレームワーク
[6] Wroclawski, J., "Specification of the Controlled Load Network
Element Service", RFC 2211, September 1997.
[6]Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、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.ゲラン、「保証されたサービスの質の仕様」、RFC2212、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、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、1994年6月。
[9] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997.
[9]Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[10] Shenker, S. and J. Wroclawski, "Network Element Service
Specification Template", RFC 2216, September 1997.
[10]ShenkerとS.とJ.Wroclawski、「ネットワーク要素サービス仕様テンプレート」、RFC2216、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、「統合サービスネットワークElementsへの一般的性質パラメタ」、RFC2215、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+」、RFC1819、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.クローリー(「IEEE802ネットワークに関する統合サービス対応表」、RFC2815)は2000がそうするかもしれません。
[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ベースの入場コントロールのためのプロトコル」(RFC2814)は2000がそうするかもしれません。
[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/IEC8802-3情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--一般的な仕様--パート3: 衝突検出型搬送波検知多重アクセス(CSMA/CD)はメソッドと物理的な層の仕様、(ANSI/IEEE Std802.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/IEC8802-5情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--一般的な仕様--パート5: トークンリングアクセス法と物理的な層の仕様、(ANSI/IEEE Std802.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.レイノルズ、「IEEE802ネットワークの上のIPデータグラムの送信の規格」、STD43、RFC1042、1988年2月。
Ghanwani, et al. Informational [Page 44] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[44ページ]のRFC2816フレームワーク
[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ネットワーク(1995年11月/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規格: IEEE Std802.12-1995、100Mb/sの操作のための優先権アクセス法、物理的な層、およびリピータ仕様を要求してください。
[20] Fiber Distributed Data Interface MAC, ANSI Std. X3.139-1987.
[20] ファイバ分散データインタフェースMac、ANSI Std。 X3.139-1987。
[21] ISO/IEC 15802-3 Information technology - Telecommunications and
information exchange between systems - Local and metropolitan
area networks - Specific requirements - Supplement to Carrier
Sense Multiple Access with Collision Detection (CSMA/CD) Access
Method and Physical Layer Specifications - Frame Extensions for
Virtual Bridged Local Area Network (VLAN) Tagging on 802.3
Networks, IEEE Std 802.3ac-1998 (Supplement to IEEE 802.3 1998
Edition), 1998.
[21]ISO/IEC15802-3情報技術--システム--地方とメトロポリタンエリアネットワーク--決められた一定の要求の間のテレコミュニケーションと情報交換--衝突検出型搬送波検知多重アクセス(CSMA/CD)のアクセスMethodとPhysical Layer Specificationsに補ってください--802.3NetworksでのVirtual Bridgedローカル・エリア・ネットワーク(VLAN)タグ付けのためのフレームExtensions、IEEE Std 802.3ac-1998(IEEE802.3 1998Editionに補う)、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.
本書では提示された仕事の多くが大いにSpecific Link Layers(ISSLL)ワーキンググループでIntegrated Servicesのミーティングで行われる議論の利益を得ました。 多くの関係者からこれらのミーティングにおけるメーリングリストについての議論で貢献を承諾したいと思います。 前のインターネット草稿を通した貢献についてエリック・クローリー、ドン・ホフマン、およびRaj Yavatkarに感謝します、そして、Demand Priorityネットワークに関するテキストを寄付するためにピーター・キムに特に感謝したいと思います。
Ghanwani, et al. Informational [Page 45] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[45ページ]のRFC2816フレームワーク
Authors' Addresses
作者のアドレス
Anoop Ghanwani Nortel Networks 600 Technology Park Dr Billerica, MA 01821, USA
Anoop Ghanwaniノーテルはビルリカ、600技術Park MA博士 01821、米国をネットワークでつなぎます。
Phone: +1-978-288-4514 EMail: aghanwan@nortelnetworks.com
以下に電話をしてください。 +1-978-288-4514 メールしてください: aghanwan@nortelnetworks.com
Wayne Pace IBM Corporation P. O. Box 12195 Research Triangle Park, NC 27709, USA
ウェインペースIBM社の私書箱12195リサーチトライアングル公園、NC 27709、米国
Phone: +1-919-254-4930 EMail: pacew@us.ibm.com
以下に電話をしてください。 +1-919-254-4930 メールしてください: pacew@us.ibm.com
Vijay Srinivasan CoSine Communications 1200 Bridge Parkway Redwood City, CA 94065, USA
Parkwayレッドウッドシティー、ビジェイSrinivasanコサインコミュニケーション1200Bridgeカリフォルニア 94065、米国
Phone: +1-650-628-4892 EMail: vijay@cosinecom.com
以下に電話をしてください。 +1-650-628-4892 メールしてください: vijay@cosinecom.com
Andrew Smith Extreme Networks 3585 Monroe St Santa Clara, CA 95051, USA
アンドリュー・スミスExtremeはサンタクララ、カリフォルニア 95051、3585モンローSt米国をネットワークでつなぎます。
Phone: +1-408-579-2821 EMail: andrew@extremenetworks.com
以下に電話をしてください。 +1-408-579-2821 メールしてください: andrew@extremenetworks.com
Mick Seaman Telseon 480 S. California Ave Palo Alto, CA 94306 USA
ミック船員Telseon480秒間カリフォルニアAveパロアルト、カリフォルニア94306米国
Email: mick@telseon.com
メール: mick@telseon.com
Ghanwani, et al. Informational [Page 46] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000
Ghanwani、他 IEEE802LAN2000年5月の上のInt-Servのための情報[46ページ]のRFC2816フレームワーク
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ghanwani, et al. Informational [Page 47]
Ghanwani、他 情報[47ページ]
一覧
スポンサーリンク
