RFC2386 日本語訳
2386 A Framework for QoS-based Routing in the Internet. E. Crawley, R.Nair, B. Rajagopalan, H. Sandick. August 1998. (Format: TXT=93459 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Crawley
Request for Comments: 2386 Argon Networks
Category: Informational R. Nair
Arrowpoint
B. Rajagopalan
NEC USA
H. Sandick
Bay Networks
August 1998
コメントを求めるワーキンググループE.クローリーの要求をネットワークでつないでください: 2386 アルゴンはカテゴリをネットワークでつなぎます: 情報のR.のNEC米国H.SandickベイネットワークスナイアArrowpoint B.Rajagopalan1998年8月
A Framework for QoS-based Routing in the Internet
インターネットのQoSベースのルート設定のための枠組み
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
ABSTRACT
要約
QoS-based routing has been recognized as a missing piece in the evolution of QoS-based service offerings in the Internet. This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet. This framework is based on extending the current Internet routing model of intra and interdomain routing to support QoS.
QoSベースのルーティングはなくなった断片としてインターネットでのQoSベースのサービス提供の発展で認識されました。 このドキュメントは、QoSベースのルーティング問題と要件のいくつかについて説明して、インターネットでのQoSベースのルーティングのために枠組みを提案します。 この枠組みはQoSを支持するためにイントラとinterdomainルーティングの現在のインターネット・ルーティングモデルを広げるのに基づいています。
1. SCOPE OF DOCUMENT & PHILOSOPHY
1. ドキュメントと哲学の範囲
This document proposes a framework for QoS-based routing, with the objective of fostering the development of an Internet-wide solution while encouraging innovations in solving the many problems that arise. QoS-based routing has many complex facets and it is recommended that the following two-pronged approach be employed towards its development:
このドキュメントはQoSベースのルーティングのために枠組みを提案します、起こる多くの問題を解決しながら革新を奨励している間、インターネット全体の解決策の開発を促進する目的で。 QoSベースのルーティングには、多くの複雑な一面があります、そして、以下の2方面からのアプローチが開発に向かって使われるのは、お勧めです:
1. Encourage the growth and evolution of novel intradomain QoS-based
routing architectures. This is to allow the development of
independent, innovative solutions that address the many QoS-based
routing issues. Such solutions may be deployed in autonomous
systems (ASs), large and small, based on their specific needs.
1. 目新しいintradomain QoSベースのルーティング建築の成長と発展を奨励してください。 これは、多くのQoSベースのルーティング問題を記述する独立していて、革新的な解決策の開発を許すためのものです。 そのような解決策は、彼らの特定の必要性に基づいて自律システム(ASs)で配備されて、広くて、小さいかもしれません。
Crawley, et. al. Informational [Page 1] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[1ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
2. Encourage simple, consistent and stable interactions between ASs
implementing routing solutions developed as above.
2. 同じくらい上で見いだされたルーティングソリューションを実現するASsの間の簡単で、一貫して安定した相互作用を奨励してください。
This approach follows the traditional separation between intra and interdomain routing. It allows solutions like QOSPF [GKOP98, ZSSC97], Integrated PNNI [IPNNI] or other schemes to be deployed for intradomain routing without any restriction, other than their ability to interact with a common, and perhaps simple, interdomain routing protocol. The need to develop a single, all encompassing solution to the complex problem of QoS-based routing is therefore obviated. As a practical matter, there are many different views on how QoS-based routing should be done. Much overall progress can be made if an opportunity exists for various ideas to be developed and deployed concurrently, while some consensus on the interdomain routing architecture is being developed. Finally, this routing model is perhaps the most practical from an evolution point of view. It is superfluous to say that the eventual success of a QoS-based Internet routing architecture would depend on the ease of evolution.
このアプローチはイントラとinterdomainルーティングの間の伝統的な分離に続きます。 それは、QOSPF[GKOP98、ZSSC97]、Integrated PNNI[IPNNI]または他の計画のような解決策がintradomainルーティングのために無制限に配備されるのを許容します、一般的で、恐らく簡単なinterdomainルーティング・プロトコルと対話する彼らの能力を除いて。 シングルを開発する必要性であり、したがって、QoSベースのルーティングの複雑な問題の解決をすべて成就するのを取り除きます。 実際問題として、QoSベースのルーティングがどう完了しているべきであるかに関する多くの異なった意見があります。 機会が様々な考えが同時に開発されて、配備されるために存在しているなら、多くの総合的な進歩を見られることができます、interdomainルーティング構造に関する何らかのコンセンサスが育まれている間。 最終的に、このルーティングモデルは恐らく発展観点から最も実用的です。 QoSベースのインターネット・ルーティング構造の終局の成功が発展の容易さによると言うのは余計です。
The aim of this document is to describe the QoS-based routing issues, identify basic requirements on intra and interdomain routing, and describe an extension of the current interdomain routing model to support QoS. It is not an objective of this document to specify the details of intradomain QoS-based routing architectures. This is left up to the various intradomain routing efforts that might follow. Nor is it an objective to specify the details of the interface between reservation protocols such as RSVP and QoS-based routing. The specific interface functionality needed, however, would be clear from the intra and interdomain routing solutions devised. In the intradomain area, the goal is to develop the basic routing requirements while allowing maximum freedom for the development of solutions. In the interdomain area, the objectives are to identify the QoS-based routing functions, and facilitate the development or enhancement of a routing protocol that allows relatively simple interaction between domains.
このドキュメントの目的は、QoSベースのルーティング問題について説明して、イントラとinterdomainルーティングに関する基本的な要件を特定して、QoSを支持するために現在のinterdomainルーティングモデルの拡大について説明することです。 それはintradomain QoSベースのルーティング構造の詳細を指定するこのドキュメントの目的ではありません。 これは続くかもしれない様々なintradomainルーティングの努力に任せられます。 また、それはRSVPなどの予約プロトコルの間のインタフェースの詳細を指定するために客観的でQoSベースのルーティングではありません。 しかしながら、必要である特定のインタフェースの機能性はイントラと掘っている解決策が工夫したinterdomainから明確でしょう。 intradomain領域では、目標は解決策の開発のための最大の自由を許容している間、基本のルーティング要件を開発することです。 interdomain領域では、目的は、QoSベースの経路選択機能を特定して、ドメインの間の比較的簡単な相互作用を許容するルーティング・プロトコルの開発か増進を容易にすることです。
In the next section, a glossary of relevant terminology is given. In Section 3, the objectives of QoS-based routing are described and the issues that must be dealt with by QoS-based Internet routing efforts are outlined. In Section 4, some requirements on intradomain routing are defined. These requirements are purposely broad, putting few constraints on solution approaches. The interdomain routing model and issues are described in Section 5 and QoS-based multicast routing is discussed in Section 6. The interaction between QoS-based routing and resource reservation protocols is briefly considered in Section 7. Security considerations are listed in Section 8 and related work is described in Section 9. Finally, summary and conclusions are presented in Section 10.
次のセクションでは、関連用語の用語集を与えます。 セクション3では、QoSベースのルーティングの目的は説明されます、そして、QoSベースのインターネット・ルーティングの努力で対処しなければならない問題は概説されています。 セクション4では、intradomainルーティングに関するいくつかの要件が定義されます。 わずかな規制しか解決策アプローチに置かないで、これらの要件はわざわざ広いです。 interdomainルーティングモデルと問題はセクション5で説明されます、そして、セクション6でQoSベースのマルチキャストルーティングについて議論します。 QoSベースのルーティングと資源予約プロトコルとの相互作用はセクション7で簡潔に考えられます。 セキュリティ問題はセクション8に記載されています、そして、関連する仕事はセクション9で説明されます。 最終的に、概要と結論はセクション10に提示されます。
Crawley, et. al. Informational [Page 2] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[2ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
2. GLOSSARY
2. 用語集
The following glossary lists the terminology used in this document and an explanation of what is meant. Some of these terms may have different connotations, but when used in this document, their meaning is as given.
以下の用語集は本書では使用される用語と意味されることに関する説明をリストアップします。 これらの用語のいくつかには、異なった含蓄があるかもしれませんが、本書では使用されると、与えられるとしてそれらの意味があります。
Alternate Path Routing : A routing technique where multiple paths, rather than just the shortest path, between a source and a destination are utilized to route traffic. One of the objectives of alternate path routing is to distribute load among multiple paths in the network.
経路ルート設定を交替してください: まさしくソースと目的地の間の最短パスよりむしろ複数の経路が交通を発送するのに利用されるルーティングのテクニック。 代替パスルーティングの目的の1つはネットワークにおける複数の経路に負荷を分配することです。
Autonomous System (AS): A routing domain which has a common administrative authority and consistent internal routing policy. An AS may employ multiple intradomain routing protocols internally and interfaces to other ASs via a common interdomain routing protocol.
自律システム(AS): 一般的な職務権限と一貫した内部のルーティング方針がある経路ドメイン。 ASは内部的に複数のintradomainルーティング・プロトコルを使うかもしれません、そして、一般的なinterdomainルーティングを通した他のASsへのインタフェースは議定書を作ります。
Source: A host or router that can be identified by a unique unicast IP address.
ソース: ユニークなユニキャストIPアドレスで特定できるホストかルータ。
Unicast destination: A host or router that can be identified by a unique unicast IP address.
ユニキャストの目的地: ユニークなユニキャストIPアドレスで特定できるホストかルータ。
Multicast destination: A multicast IP address indicating all hosts and routers that are members of the corresponding group.
マルチキャストの目的地: すべてのホストを示すマルチキャストIPアドレスと対応するグループのメンバーであるルータ。
IP flow (or simply "flow"): An IP packet stream from a source to a destination (unicast or multicast) with an associated Quality of Service (QoS) (see below) and higher level demultiplexing information. The associated QoS could be "best-effort".
IP流動(または、単に「流れ」): Service(QoS)(以下を見る)と、より高い平らな逆多重化情報の関連Qualityとのソースから目的地(ユニキャストかマルチキャスト)までのIPパケットの流れ。 関連QoSは「ベストエフォート型であることができました」。
Quality-of-Service (QoS): A set of service requirements to be met by the network while transporting a flow.
サービスの質(QoS): 流れを輸送している間にネットワークによって会われるという1セットのサービス要件。
Service class: The definitions of the semantics and parameters of a specific type of QoS.
クラスにサービスを提供してください: 意味論の定義とQoSの特定のタイプのパラメタ。
Integrated services: The Integrated Services model for the Internet defined in RFC 1633 allows for integration of QoS services with the best effort services of the Internet. The Integrated Services (IntServ) working group in the IETF has defined two service classes, Controlled Load Service [W97] and Guaranteed Service [SPG97].
統合サービス: RFC1633で定義されたインターネットへのIntegrated Servicesモデルはインターネットのベストエフォート型サービスでQoSサービスの統合を考慮します。 IETFのIntegrated Services(IntServ)ワーキンググループは2つのサービスのクラス、Controlled Load Service[W97]、およびGuaranteed Service[SPG97]を定義しました。
RSVP: The ReSerVation Protocol [BZBH97]. A QoS signaling protocol for the Internet.
RSVP: 予約プロトコル[BZBH97]。 インターネットへのQoSシグナリングプロトコル。
Path: A unicast or multicast path.
経路: ユニキャストかマルチキャスト経路。
Crawley, et. al. Informational [Page 3] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[3ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
Unicast path: A sequence of links from an IP source to a unicast IP destination, determined by the routing scheme for forwarding packets.
ユニキャスト経路: IPソースから推進パケットのルーティング計画で決定するユニキャストIPの目的地へのリンクの系列。
Multicast path (or Multicast Tree): A subtree of the network topology in which all the leaves and zero or more interior nodes are members of the same multicast group. A multicast path may be per-source, in which case the subtree is rooted at the source.
マルチキャスト経路(または、Multicast Tree): すべての葉とゼロか、より内部のノードが同じマルチキャストグループのメンバーであるネットワーク形態の下位木。 マルチキャスト経路がソースであるかもしれない、その場合、下位木はソースに根づきます。
Flow set-up: The act of establishing state in routers along a path to satisfy the QoS requirement of a flow.
流れセットアップ: 流れのQoS要件を満たすために経路に沿ったルータに状態を設置する行為。
Crankback: A technique where a flow setup is recursively backtracked along the partial flow path up to the first node that can determine an alternative path to the destination.
Crankback: 流れセットアップが再帰的にそうであるテクニックは部分的な流路に沿って迂回経路を目的地に決定できる最初のノードまで引き返しました。
QoS-based routing: A routing mechanism under which paths for flows are determined based on some knowledge of resource availability in the network as well as the QoS requirement of flows.
QoSベースのルーティング: リソースの有用性に関する何らかの知識に基づいて流れのための経路が流れのQoS要件と同様にネットワークで決定しているルーティングメカニズム。
Route pinning: A mechanism to keep a flow path fixed for a duration of time.
ピンで止めることを発送してください: 流路を保つメカニズムは時間の持続時間のために修理されました。
Flow Admission Control (FAC): A process by which it is determined whether a link or a node has sufficient resources to satisfy the QoS required for a flow. FAC is typically applied by each node in the path of a flow during flow set-up to check local resource availability.
流れ入場コントロール(FAC): リンクかノードにQoSを満足することができるくらいのリソースがあるか否かに関係なく、それが決定している過程が流れに必要です。 FACは流れセットアップの間の流れの経路の各ノードによって通常適用されて、ローカル資源の有用性をチェックします。
Higher-level admission control: A process by which it is determined whether or not a flow set-up should proceed, based on estimates and policy requirements of the overall resource usage by the flow. Higher-level admission control may result in the failure of a flow set-up even when FAC at each node along the flow path indicates resource availability.
よりハイレベルの入場コントロール: 流れによる総合的なリソース用法の見積りと方針要件に基づいた流れセットアップが続くべきであるか否かに関係なく、それが決定している過程。 流路に沿った各ノードのFACがリソースの有用性を示すときさえ、よりハイレベルの入場コントロールは流れセットアップの失敗をもたらすかもしれません。
3. QOS-BASED ROUTING: BACKGROUND AND ISSUES
3. QOSベースのルーティング: バックグラウンドと問題
3.1 Best-Effort and QoS-Based Routing
3.1 ベストエフォート型の、そして、QoSベースのルート設定
Routing deployed in today's Internet is focused on connectivity and typically supports only one type of datagram service called "best effort" [WC96]. Current Internet routing protocols, e.g. OSPF, RIP, use "shortest path routing", i.e. routing that is optimized for a single arbitrary metric, administrative weight or hop count. These routing protocols are also "opportunistic," using the current shortest path or route to a destination. Alternate paths with acceptable but non-optimal cost can not be used to route traffic (shortest path routing protocols do allow a router to alternate among
今日のインターネットで配備されたルート設定は、接続性に焦点を合わせられて、「ベストエフォート型」の[WC96]と呼ばれる1つのタイプのデータグラムサービスだけを通常支持します。 現在のインターネットルーティング・プロトコル、例えば、OSPF(RIP)は「最短パスルーティング」(すなわち、ただ一つの任意のメートル法の、そして、管理の重さかホップカウントのために最適化されるルーティング)を使用します。 また、現在の最短パスかルートを目的地に使用して、これらのルーティング・プロトコルも「便宜主義的です」。 交通を発送するのに許容できますが、非最適の費用がある代替パスを使用できない、(最短パスルーティング・プロトコルで、ルータは交替されます。
Crawley, et. al. Informational [Page 4] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[4ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
several equal cost paths to a destination).
目的地へのいくつかの等しい費用経路)
QoS-based routing must extend the current routing paradigm in three basic ways. First, to support traffic using integrated-services class of services, multiple paths between node pairs will have to be calculated. Some of these new classes of service will require the distribution of additional routing metrics, e.g. delay, and available bandwidth. If any of these metrics change frequently, routing updates can become more frequent thereby consuming network bandwidth and router CPU cycles.
QoSベースのルーティングは3つの基本的な方法で現在のルーティングパラダイムを広げなければなりません。 まず最初に、統合サービスのクラスのサービス、ノード組の間の複数の経路を使用することで交通を支持するのは計算されていなければならないでしょう。 これらの数人の新しいサービスのクラスが追加ルーティング測定基準、例えば、遅れ、および利用可能な帯域幅の分配を必要とするでしょう。 これらの測定基準のどれかが頻繁に変化するなら、ルーティングアップデートは、その結果、ネットワーク回線容量とルータCPUサイクルを費やしながら、より頻繁になることができます。
Second, today's opportunistic routing will shift traffic from one path to another as soon as a "better" path is found. The traffic will be shifted even if the existing path can meet the service requirements of the existing traffic. If routing calculation is tied to frequently changing consumable resources (e.g. available bandwidth) this change will happen more often and can introduce routing oscillations as traffic shifts back and forth between alternate paths. Furthermore, frequently changing routes can increase the variation in the delay and jitter experienced by the end users.
2番目に、「より良い」経路が見つけられるとすぐに、今日の便宜主義的なルーティングは1つの経路から別の経路までの交通を移行させるでしょう。 既存の経路が既存の交通に関するサービス要件を満たすことができても、交通は移行するでしょう。 ルーティング計算が頻繁に消費可能資源(例えば、利用可能な帯域幅)を変えると結ばれるなら、交通が代替パスの間で前後に移行するとき、この変化は、よりしばしば起こって、ルーティング振動を導入できます。 その上、頻繁にルートを変えるのはエンドユーザによって経験された遅れとジターの変化を増加させることができます。
Third, as mentioned earlier, today's optimal path routing algorithms do not support alternate routing. If the best existing path cannot admit a new flow, the associated traffic cannot be forwarded even if an adequate alternate path exists.
3番目に、先に述べたように、今日の最適経路ルーティング・アルゴリズムは迂回中継を支持しません。 最も良い既存の経路が新しい流れを認めることができないなら、適切な代替パスが存在していても、関連交通を進めることができません。
3.2 QoS-Based Routing and Resource Reservation
3.2 QoSベースのルート設定と資源予約
It is important to understand the difference between QoS-based routing and resource reservation. While resource reservation protocols such as RSVP [BZBH97] provide a method for requesting and reserving network resources, they do not provide a mechanism for determining a network path that has adequate resources to accommodate the requested QoS. Conversely, QoS-based routing allows the determination of a path that has a good chance of accommodating the requested QoS, but it does not include a mechanism to reserve the required resources.
QoSベースのルーティングと資源予約の違いを理解しているのは重要です。 RSVP[BZBH97]などの資源予約プロトコルがネットワーク資源を要求して、予約するための方法を提供している間、適切なリソースを持っているネットワーク経路が要求されたQoSを収容することを決定するのにそれらはメカニズムを提供しません。 逆に、QoSベースのルーティングは要求されたQoSを収容するという十分な見込みを持っている経路の決断を許容しますが、それは、必要なリソースを予約するためにメカニズムを含んでいません。
Consequently, QoS-based routing is usually used in conjunction with some form of resource reservation or resource allocation mechanism. Simple forms of QoS-based routing have been used in the past for Type of Service (TOS) routing [M98]. In the case of OSPF, a different shortest-path tree can be computed for each of the 8 TOS values in the IP header [ISI81]. Such mechanisms can be used to select specially provisioned paths but do not completely assure that resources are not overbooked along the path. As long as strict resource management and control are not needed, mechanisms such as TOS-based routing are useful for separating whole classes of traffic
その結果、通常、QoSベースのルーティングは何らかのフォームの資源予約か資源配分メカニズムに関連して使用されます。 QoSベースのルーティングの単純形は過去にService(TOS)ルーティング[M98]のTypeに使用されました。 OSPFの場合では、IPヘッダー[ISI81]における、それぞれの8つのTOS値のために異なった最短パス木を計算できます。 そのようなメカニズムは、特に、食糧を供給された経路を選択するのに使用できますが、リソースが経路に沿ってオーバーブックされないことを完全に保証するというわけではありません。 厳しい資源管理とコントロールは必要でない限り、TOSベースのルーティングなどのメカニズムが全体のクラスの交通を切り離すことの役に立ちます。
Crawley, et. al. Informational [Page 5] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[5ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
over multiple routes. Such mechanisms might work well with the emerging Differential Services efforts [BBCD98].
複数のルートにわたって。 そのようなメカニズムは現れているDifferential Servicesの努力[BBCD98]でうまくいくかもしれません。
Combining a resource reservation protocol with QoS-based routing allows fine control over the route and resources at the cost of additional state and setup time. For example, a protocol such as RSVP may be used to trigger QoS-based routing calculations to meet the needs of a specific flow.
QoSベースのルーティングに資源予約プロトコルを結合すると、ファイン制御はルートとリソースの上に追加状態と準備時間の費用で許容されます。 例えば、RSVPなどのプロトコルは、特定の流れの需要を満たすのにQoSベースのルーティング計算の引き金となるのにおいて使用されているかもしれません。
3.3 QoS-Based Routing: Objectives
3.3 QoSベースのルート設定: 目的
Under QoS-based routing, paths for flows would be determined based on some knowledge of resource availability in the network, as well as the QoS requirement of flows. The main objectives of QoS-based routing are:
QoSベースのルーティングの下では、リソースの有用性に関する何らかの知識に基づいて流れのための経路はネットワークで決定しているでしょう、流れのQoS要件と同様に。 QoSベースのルーティングの主な目標は以下の通りです。
1. Dynamic determination of feasible paths: QoS-based routing can
determine a path, from among possibly many choices, that has a
good chance of accommodating the QoS of the given flow. Feasible
path selection may be subject to policy constraints, such as path
cost, provider selection, etc.
1. 実行可能経路のダイナミックな決断: QoSベースのルーティングはことによると多くの選択からの与えられた流れのQoSを収容するという十分な見込みを持っている経路を決定できます。 実行可能経路選択は経路費用、プロバイダー選択などの方針規制を受けることがあるかもしれません。
2. Optimization of resource usage: A network state-dependent QoS-
based routing scheme can aid in the efficient utilization of
network resources by improving the total network throughput. Such
a routing scheme can be the basis for efficient network
engineering.
2. リソース用法の最適化: 計画を発送する州の依存するQoSが基礎づけたネットワークは、ネットワーク資源の効率的な利用で総ネットワークスループットを改良することによって、支援されることができます。 そのようなルーティング計画は効率的なネットワーク工学の基礎であるかもしれません。
3. Graceful performance degradation: State-dependent routing can
compensate for transient inadequacies in network engineering
(e.g., during focused overload conditions), giving better
throughput and a more graceful performance degradation as
compared to a state-insensitive routing scheme [A84].
3. 優雅な性能退行: 州の依存するルーティングはネットワーク工学(例えば、集中している過負荷条件の間の)の一時的な不適当を補うことができます、州の神経の鈍いルーティング計画[A84]と比べて、より良い効率と、より優雅な性能退行を与えて。
QoS-based routing in the Internet, however, raises many issues:
しかしながら、インターネットでのQoSベースのルーティングは多くの問題を提起します:
- How do routers determine the QoS capability of each outgoing link
and reserve link resources? Note that some of these links may be
virtual, over ATM networks and others may be broadcast multi-
access links.
- ルータはどのようにそれぞれの出発しているリンクと蓄えのリンクリソースのQoS能力を決定しますか? これらのいくつかのリンクによる仮想であり、ATMネットワークと他のものの上に、放送マルチアクセスリンクがあるかもしれないということであるかもしれないことに注意してください。
- What is the granularity of routing decision (i.e., destination-
based, source and destination-based, or flow-based)?
- ルーティング決定(すなわち、ベースの元の、そして、目的地ベースの目的地の、または、流れベースの)の粒状は何ですか?
- What routing metrics are used and how are QoS-accommodating paths
computed for unicast flows?
- どんなルーティング測定基準が使用されているか、そして、ユニキャストのために計算されたQoSを収容している経路はどのように流れですか?
Crawley, et. al. Informational [Page 6] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[6ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
- How are QoS-accommodating paths computed for multicast flows with
different reservation styles and receiver heterogeneity?
- マルチキャストのために計算されたQoSを収容している経路はどのように異なった予約スタイルと受信機の異種性がある流れですか?
- What are the performance objectives while computing QoS-based
paths?
- QoSベースの経路を計算している間、パフォーマンス目標は何ですか?
- What are the administrative control issues?
- 運営管理コントロール問題は何ですか?
- What factors affect the routing overheads?, and
- どんな要素がルーティングオーバーヘッドに影響しますか?
- How is scalability achieved?
- スケーラビリティはどのように達成されますか?
Some of these issues are discussed briefly next. Interdomain routing is discussed in Section 5.
簡潔に次に、これらの問題のいくつかについて議論します。 セクション5でInterdomainルーティングについて議論します。
3.4 QoS Determination and Resource Reservation
3.4 QoS決断と資源予約
To determine whether the QoS requirements of a flow can be accommodated on a link, a router must be able to determine the QoS available on the link. It is still an open issue as to how the QoS availability is determined for broadcast multiple access links (e.g., Ethernet). A related problem is the reservation of resources over such links. Solutions to these problems are just emerging [GPSS98].
リンク、ルータに流れのQoS要件を収容できるかどうか決定するのがリンクで利用可能なQoSを決定できなければなりません。 それはQoSの有用性が複数のアクセスがリンクする放送(例えば、イーサネット)のためにどう決定するかに関する未解決の問題です。 関連する問題はそのようなリンクの上のリソースの予約です。 これらの問題の解決は[GPSS98]としてただ現れています。
Similar problems arise when a router is connected to a large non- broadcast multiple access network, such as ATM. In this case, if the destination of a flow is outside the ATM network, the router may have multiple egress choices. Furthermore, the QoS availability on the ATM paths to each egress point may be different. The issues then are,
ルータがATMなどの大きい非放送複数のアクセスネットワークに関連づけられるとき、同様の問題は起こります。 この場合、ATMネットワークの外に流れの目的地があるなら、ルータには複数の出口選択があるかもしれません。 その上、それぞれの出口ポイントへのATM経路に関するQoSの有用性は異なっているかもしれません。 そして、問題があります。
o how does a router determine all the egress choices across the
ATM network?
o how does it determine what QoS is available over the path to
each egress point?, and
o what QoS value does the router advertise for the ATM link.
o ○ ルータはATMネットワークの向こう側にすべての出口選択を決定します、そして、(○ それは、経路の上でQoSが何であるかをどのように利用可能な状態でそれぞれの出口ポイントまで決定するか)QoS値がルータをすることはどうATMリンクを公募するか。
Typically, IP routing over ATM (e.g., NHRP) allows the selection of a single egress point in the ATM network, and the procedure does not incorporate any knowledge of the QoS required over the path. An approach like I-PNNI [IPNNI] would be helpful here, although it introduces some complexity.
通常、ATM(例えば、NHRP)の上のIPルーティングはATMネットワークにおける、単一の出口ポイントの選択を許します、そして、手順は経路に関して必要であるQoSに関する少しの知識も取り入れません。 何らかの複雑さを導入しますが、I-PNNI[IPNNI]のようなアプローチはここで役立っているでしょう。
An additional problem with resource reservation is how to determine what resources have already been allocated to a multicast flow. The availability of this information during path computation improves the chances of finding a path to add a new receiver to a multicast flow. QOSPF [ZSSC97] handles this problem by letting routers broadcast reserved resource information to other routers in their area.
資源予約に関する追加問題はどんなリソースが既にマルチキャスト流動に割り当てられたかをどう決定するかということです。 経路計算の間のこの情報の有用性は経路を見つけると新しい受信機がマルチキャスト流動に加える機会を改良します。 ルータに予約されたリソース情報を他のルータに放送させることによって、QOSPF[ZSSC97]はそれらの領域でこの問題を扱います。
Crawley, et. al. Informational [Page 7] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[7ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
Alternate path routing [ZES97] deals with this issue by using probe messages to find a path with sufficient resources. Path QoS Computation (PQC) method, proposed in [GOA97], propagates bandwidth allocation information in RSVP PATH messages. A router receiving the PATH message gets an indication of the resource allocation only on those links in the path to itself from the source. Allocation for the same flow on other remote branches of the multicast tree is not available. Thus, the PQC method may not be sufficient to find feasible QoS-accommodating paths to all receivers.
十分なリソースで経路を見つける徹底的調査メッセージを使用することによって、代替パスルーティング[ZES97]はこの問題に対処します。 [GOA97]で提案された経路QoS Computation(PQC)方法はRSVP PATHメッセージの帯域幅配分情報を伝播します。 PATHメッセージを受け取るルータは経路のそれらのリンクだけにおける資源配分のしるしをソースからそれ自体に得ます。 マルチキャスト木の他のリモート枝における同じ流れのための配分は利用可能ではありません。 したがって、PQC方法は、可能なQoSを収容している経路をすべての受信機に見つけるために十分でないかもしれません。
3.5 Granularity of Routing Decision
3.5 ルート設定決定の粒状
Routing in the Internet is currently based only on the destination address of a packet. Many multicast routing protocols require routing based on the source AND destination of a packet. The Integrated Services architecture and RSVP allow QoS determination for an individual flow between a source and a destination. This set of routing granularities presents a problem for QoS routing solutions.
インターネットのルート設定は現在、パケットの送付先アドレスだけに基づいています。 多くのマルチキャストルーティング・プロトコルが、パケットのソースと目的地に基づいて掘るのを必要とします。 Integrated Services構造とRSVPはソースと目的地の間の個々の流れのための決断をQoSに許容します。 このセットのルーティング粒状はQoSルーティング解決のために問題を提示します。
If routing based only on destination address is considered, then an intermediate router will route all flows between different sources and a given destination along the same path. This is acceptable if the path has adequate capacity but a problem arises if there are multiple flows to a destination that exceed the capacity of the link.
送付先アドレスだけに基づくルーティングが考えられると、中間的ルータは同じ経路に沿ってさまざまな原因と与えられた目的地の間のすべての流れを発送するでしょう。 経路に適切な容量があるなら、これは許容できますが、目的地へのリンクの容量を超えている複数の流れがあれば、問題は起こります。
One version of QOSPF [ZSSC97] determines QoS routes based on source and destination address. This implies that all traffic between a given source and destination, regardless of the flow, will travel down the same route. Again, the route must have capacity for all the QoS traffic for the source/destination pair. The amount of routing state also increases since the routing tables must include source/destination pairs instead of just the destination.
QOSPF[ZSSC97]の1つのバージョンがソースと送付先アドレスに基づくQoSルートを決定します。 これは、与えられたソースと目的地の間のすべての交通が流れにかかわらず同じルートの下側に伝わるのを含意します。 一方、ルートには、ソース/目的地組すべてのQoS交通への容量がなければなりません。 また、経路指定テーブルがまさしく目的地の代わりにソース/目的地組を含まなければならないので、ルーティング状態の量は増加します。
The best granularity is found when routing is based on individual flows but this incurs a tremendous cost in terms of the routing state. Each QoS flow can be routed separately between any source and destination. PQC [GOA97] and alternate path routing [ZES97], are examples of solutions which operate at the flow level.
ルーティングが個々の流れに基づいているとき、最も良い粒状は見つけられますが、これはルーティング状態に関して物凄い費用を被ります。 別々にどんなソースと目的地の間にもそれぞれのQoS流動を発送できます。 PQC[GOA97]と代替パスルーティング[ZES97]は流れレベルで作動する解決策に関する例です。
Both source/destination and flow-based routing may be susceptible to packet looping under hop-by-hop forwarding. Suppose a node along a flow or source/destination-based path loses the state information for the flow. Also suppose that the flow-based route is different from the regular destination-based route. The potential then exists for a routing loop to form when the node forwards a packet belonging to the flow using its destination-based routing table to a node that occurs
ソース/目的地と流れベースのルーティングの両方がパケットループにホップごとの推進で影響されやすいかもしれません。 目的地流れかソース/ベースの経路に沿ったノードが流れのための州の情報を失うと仮定してください。 また、流れベースのルートが通常の目的地ベースのルートと異なっていると仮定してください。 そして、可能性は、ノードが目的地ベースの経路指定テーブルを起こるノードに使用することで流れに属すパケットを進めるとき、ルーティング輪が形成されるために存在しています。
Crawley, et. al. Informational [Page 8] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[8ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
earlier on the flow-based path. This is because the latter node may use its flow-based routing table to forward the packet again to the former and this can go on indefinitely.
流れベースの経路で、より早くに。 これが後者のノードが再びパケットを前者に送るのに流れベースの経路指定テーブルを使用するかもしれないからである無期限に先へ進むことができます。
3.6 Metrics and Path Computation
3.6 測定基準と経路計算
3.6.1 Metric Selection and Representation
3.6.1 メートル法の選択と表現
There are some considerations in defining suitable link and node metrics [WC96]. First, the metrics must represent the basic network properties of interest. Such metrics include residual bandwidth, delay and jitter. Since the flow QoS requirements have to be mapped onto path metrics, the metrics define the types of QoS guarantees the network can support. Alternatively, QoS-based routing cannot support QoS requirements that cannot be meaningfully mapped onto a reasonable combination of path metrics. Second, path computation based on a metric or a combination of metrics must not be too complex as to render them impractical. In this regard, it is worthwhile to note that path computation based on certain combinations of metrics (e.g., delay and jitter) is theoretically hard. Thus, the allowable combinations of metrics must be determined while taking into account the complexity of computing paths based on these metrics and the QoS needs of flows. A common strategy to allow flexible combinations of metrics while at the same time reduce the path computation complexity is to utilize "sequential filtering". Under this approach, a combination of metrics is ordered in some fashion, reflecting the importance of different metrics (e.g., cost followed by delay, etc.). Paths based on the primary metric are computed first (using a simple algorithm, e.g., shortest path) and a subset of them are eliminated based on the secondary metric and so forth until a single path is found. This is an approximation technique and it trades off global optimality for path computation simplicity (The filtering technique may be simpler, depending on the set of metrics used. For example, with bandwidth and cost as metrics, it is possible to first eliminate the set of links that do not have the requested bandwidth and then compute the least cost path using the remaining links.)
適当なリンクとノード測定基準[WC96]を定義するのにおいていくつかの問題があります。 まず最初に、測定基準は興味がある基本的なネットワーク所有地を表さなければなりません。 そのような測定基準は残りの帯域幅、遅れ、およびジターを含んでいます。 流れQoS要件が経路測定基準に写像されなければならないので、測定基準はネットワークが支持できるQoS保証のタイプを定義します。 あるいはまた、QoSベースのルーティングは意味深長に経路測定基準の合理的な組み合わせに写像できないQoS要件を支持できません。 それらを非実用的にして、2番目に、aにメートル法であることで基づく経路計算か測定基準の組み合わせがそれほど複雑であるはずがありません。 この点で、測定基準(例えば、遅れとジター)のある組み合わせに基づく経路計算が理論的に困難であることに注意する価値があります。 したがって、測定基準の許容できる組み合わせは経路がこれらの測定基準に基づかせて、QoSが必要とする流れのコンピューティングの複雑さを考慮に入れている間、決定しているに違いありません。 「連続したフィルタリング」を利用します経路計算の複雑さが同時に減少している間に測定基準のフレキシブルな組み合わせを許す一般的な戦略がことである。 このアプローチで、測定基準の組み合わせは何らかのファッションで命令されます、異なった測定基準の重要性を反映して(例えば費用は遅れなどで続きました)。 予備選挙にメートル法であることで基づく経路は計算されて、ただ一つの経路が見つけられるまで1(簡単なアルゴリズムを使用する例えば、最短パス)番目それらの部分集合が二次に基づいてなどにメートル法で排除されるということです。 これは近似法です、そして、それは経路計算の簡単さのためにグローバルな最適を交換します。(使用される測定基準のセットによって、フィルター技術は、より簡単であるかもしれません。 例えば、測定基準としての帯域幅と費用では、最初に残っているリンクを使用することで要求された帯域幅を持って、次に最小費用経路を計算しないリンクのセットを取り除くのは可能です。)
Now, once suitable link and node metrics are defined, a uniform representation of them is required across independent domains - employing possibly different routing schemes - in order to derive path metrics consistently (path metrics are obtained by the composition of link and node metrics). Encoding of the maximum, minimum, range, and granularity of the metrics are needed. Also, the definitions of comparison and accumulation operators are required. In addition, suitable triggers must be defined for indicating a significant change from a minor change. The former will cause a routing update to be generated. The stability of the QoS routes would
現在、一貫して経路測定基準を引き出すのにことによると異なったルーティング計画を使って、適当なリンクとノード測定基準がいったん定義されると、それらの一定の表現が独立しているドメインの向こう側に必要です(リンクとノード測定基準の構成で経路測定基準を得ます)。 測定基準の最大、最小限、範囲、および粒状がコード化されるのが必要です。 また、比較と蓄積オペレータの定義が必要です。 さらに、マイナーチェンジから著しい変化を示すために適当な引き金を定義しなければなりません。 前者で、ルーティングアップデートを発生させるでしょう。 QoSルートの安定性はそうするでしょう。
Crawley, et. al. Informational [Page 9] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[9ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
depend on the ability to control the generation of updates. With interdomain routing, it is essential to obtain a fairly stable view of the interconnection among the ASs.
アップデートの世代を制御する能力に依存してください。 interdomainルーティングで、インタコネクトのかなり安定した意見をASsに得るのは不可欠です。
3.6.2 Metric Hierarchy
3.6.2 メートル法の階層構造
A hierarchy can be defined among various classes of service based on the degree to which traffic from one class can potentially degrade service of traffic from lower classes that traverse the same link. In this hierarchy, guaranteed constant bit rate traffic is at the top and "best-effort" datagram traffic at the bottom. Classes providing service higher in the hierarchy impact classes providing service in lower levels. The same situation is not true in the other direction. For example, a datagram flow cannot affect a real-time service. Thus, it may be necessary to distribute and update different metrics for each type of service in the worst case. But, several advantages result by identifying a single default metric. For example, one could derive a single metric combining the availability of datagram and real-time service over a common substrate.
1つのクラスからの交通が交通のサービスを潜在的に下がらせることができる程度に基づく様々なクラスのサービスの中で同じリンクを横断する労働者階級から階層構造を定義できます。 この階層構造には、保証された固定ビットレート交通が下部に最高で「ベストエフォート型」のデータグラム交通にあります。 サービスを階層構造で、より高く提供するクラスが、サービスを下のレベルに提供しながら、クラスに影響を与えます。 同じ状況はもう片方の方向に誠実ではありません。 例えば、データグラム流動はリアルタイムのサービスに影響できません。 したがって、それぞれのタイプのサービスのために最悪の場合には異なった測定基準を分配して、アップデートするのが必要であるかもしれません。 しかし、いくつかの利点が、ただ一つのデフォルトを特定することによって、メートル法であることで結果として生じます。 例えば、人はデータグラムの有用性を結合しながら、メートル法であることでシングルを引き出すことができました、そして、リアルタイムのサービスオーバーは一般的な基板を引き出します。
3.6.3 Datagram Flows
3.6.3 データグラムは流れます。
A delay-sensitive metric is probably the most obvious type of metric suitable for datagram flows. However, it requires careful analysis to avoid instabilities and to reduce storage and bandwidth requirements. For example, a recursive filtering technique based on a simple and efficient weighted averaging algorithm [NC94] could be used. This filter is used to stabilize the metric. While it is adequate for smoothing most loading patterns, it will not distinguish between patterns consisting of regular bursts of traffic and random loading. Among other stabilizing tools, is a minimum time between updates that can help filter out high-frequency oscillations.
遅れ敏感である、メートル法であることは、データグラムのためのたぶんメートル法の適当な最も明白なタイプが流れるということです。 しかしながら、不安定性を避けて、格納と帯域幅要件を減らすのが慎重な分析を必要とします。 例えば、簡単で効率的な荷重している平均したアルゴリズム[NC94]に基づく再帰的なフィルター技術は使用できました。 このフィルタは、メートル法を安定させるのに使用されます。 ほとんどのローディング・パターンを整えるのに適切である間、それは交通と無作為のローディングの通常の炸裂から成るパターンを見分けないでしょう。 他の安定したツールの中に、高頻度振動を無視するのを助けることができるアップデートの間には、最小の時間がありますか?
3.6.4 Real-time Flows
3.6.4 リアルタイムの流れ
In real-time quality-of-service, delay variation is generally more critical than delay as long as the delay is not too high. Clearly, voice-based applications cannot tolerate more than a certain level of delay. The condition of varying delays may be expected to a greater degree in a shared medium environment with datagrams, than in a network implemented over a switched substrate. Routing a real-time flow therefore reduces to an exercise in allocating the required network resources while minimizing fragmentation of bandwidth. The resulting situation is a bandwidth-limited minimum hop path from a source to the destination. In other words, the router performs an ordered search through paths of increasing hop count until it finds one that meets all the bandwidth needs of the flow. To reduce contention and the probability of false probes (due to inaccuracy in
一般に、リアルタイムのサービスの質では、遅れ変化は遅れがそれほど高くない限り、延着するより批判的です。 明確に、声のベースのアプリケーションはあるレベルの遅れ以上を許容できません。 遅れを変えるという条件はデータグラムがある共有された中型の環境における、より大きい度予想されるかもしれません、切り換えられた基板の上で実行されたネットワークより。 したがって、リアルタイムの流れを発送するのは帯域幅の断片化を最小にしている間、必要なネットワーク資源を割り当てる際に運動に減少します。 ソースから目的地まで結果として起こる状況は帯域幅で限られた最小のホップ経路です。 言い換えれば、帯域幅が必要とする流れのすべてに会うものを見つけるまで、ルータは増加するホップカウントの経路を通した命令された検索を実行します。 主張と誤った徹底的調査の確率を抑える、(中の不正確
Crawley, et. al. Informational [Page 10] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[10ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
route tables), the router could select a path randomly from a "window" of paths which meet the needs of the flow and satisfy one of three additional criteria: best-fit, first-fit or worst-fit. Note that there is a similarity between the allocation of bandwidth and the allocation of memory in a multiprocessing system. First-fit seems to be appropriate for a system with a high real-time flow arrival rates; and worst-fit is ideal for real-time flows with high holding times. This rather nonintuitive result was shown in [NC94].
ルートテーブル)、ルータは流れの需要を満たして、3つの追加評価基準の1つを満たす経路の「窓」から手当たりしだいに経路を選択できました: 最もよく合うか、最初に、合うか、または最もひどく合ってください。 帯域幅の配分とマルチプロセシングシステムにおける、メモリの配分の間には、類似性があることに注意してください。 最初に、発作は到着が評定する高いリアルタイムの流れでシステムに適切であるように思えます。 そして、リアルタイムの流れに、最も悪いフィットは高い把持時間のために理想的です。 むしろnonintuitive結果が[NC94]に示されたこれ。
3.6.5 Path Properties
3.6.5 経路の特性
Path computation by itself is merely a search technique, e.g., Shortest Path First (SPF) is a search technique based on dynamic programming. The usefulness of the paths computed depends to a large extent on the metrics used in evaluating the cost of a path with respect to a flow.
それ自体で経路計算が単に検索技術である、例えば、Shortest Path First(SPF)は動的計画法に基づく検索技術です。 計算された経路の有用性は大体において流れに関して経路の費用を評価する際に使用される測定基準に依存します。
Each link considered by the path computation engine must be evaluated against the requirements of the flow, i.e., the cost of providing the services required by the flow must be estimated with respect to the capabilities of the link. This requires a uniform method of combining features such as delay, bandwidth, priority and other service features. Furthermore, the costs must reflect the lost opportunity of using each link after routing the flow.
流れの要件に対して経路演算処理エンジンによって考えられた各リンクを評価しなければなりません、すなわち、リンクの能力に関して流れによって必要とされたサービスを提供する費用を見積もらなければなりません。 これは遅れや、帯域幅や、優先権や他のサービス機能などの特徴を結合する一定の方法を必要とします。 その上、コストは流れを発送した後に各リンクを使用する逸したチャンスを反映しなければなりません。
3.6.6 Performance Objectives
3.6.6 パフォーマンス目標
One common objective during path computation is to improve the total network throughput. In this regard, merely routing a flow on any path that accommodates its QoS requirement is not a good strategy. In fact, this corresponds to uncontrolled alternate routing [SD95] and may adversely impact performance at higher traffic loads. It is therefore necessary to consider the total resource allocation for a flow along a path, in relation to available resources, to determine whether or not the flow should be routed on the path. Such a mechanism is referred to in this document as "higher level admission control". The goal of this is to ensure that the "cost" incurred by the network in routing a flow with a given QoS is never more than the revenue gained. The routing cost in this regard may be the lost revenue in potentially blocking other flows that contend for the same resources. The formulation of the higher level admission control strategy, with suitable administrative hooks and with fairness to all flows desiring entry to the network, is an issue. The fairness problem arises because flows with smaller reservations tend to be more successfully routed than flows with large reservations, for a given engineered capacity. To guarantee a certain level of
経路計算の間の1つの共通の目的は総ネットワークスループットを改良することです。 QoS要件を収容するどんな経路でもこの点で、単に流れを発送するのは、優れた戦略ではありません。 事実上、これは、非制御の迂回中継[SD95]に対応している、より高いトラヒック負荷で逆に性能に影響を与えるかもしれません。 したがって、総リソースが経路に沿った流れのための配分であると考えるのが必要です、流れが経路で発送されるべきであるかどうか決定するために利用可能資源と関連して。 そのようなメカニズムは本書では「より高い平らな入場コントロール」と呼ばれます。 この目標は与えられたQoSと共に流れを発送する際にネットワークによって被られた「費用」が決して以上でないことを保証する収入が獲得したことです。 ルーティング費用は潜在的に同じリソースを競争する他の流れを妨げることにおいてこの点で失われた収入であるかもしれません。 より高い平らな入場対応戦略の定式化であり、ネットワークにエントリーを望むのは、適当な管理フックとすべての流れへの公正の、問題です。 より小さい予約がある流れが、大きい予約がある流れより首尾よく発送されている傾向があるので、公正問題は起こります、与えられた設計された容量のために。 あるレベルを保証します。
Crawley, et. al. Informational [Page 11] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[11ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
acceptance rate for "larger" flows, without over-engineering the network, requires a fair higher level admission control mechanism. The application of higher level admission control to multicast routing is discussed later.
ネットワークを過剰設計しないで、「より大きい」流れのための輸入手形決済相場は公正なより高い平らな入場制御機構を必要とします。 後でマルチキャストルーティングへの、より高い平らな入場コントロールの応用について議論します。
3.7 Administrative Control
3.7 運営管理コントロール
There are several administrative control issues. First, within an AS employing state-dependent routing, administrative control of routing behavior may be necessary. One example discussed earlier was higher level admission control. Some others are described in this section. Second, the control of interdomain routing based on policy is an issue. The discussion of interdomain routing is defered to Section 5.
いくつかの運営管理コントロール問題があります。 まず最初に、州の依存するルーティングを使うASの中では、ルーティングの振舞いの運営管理コントロールが必要であるかもしれません。 より早く議論した1つの例は、より高い平らな入場コントロールでした。 このセクションで説明される他のものもいます。 2番目に、方針に基づくinterdomainルーティングのコントロールは問題です。 interdomainルーティングの議論はセクション5にdeferedされます。
Two areas that need administrative control, in addition to appropriate routing mechanisms, are handling flow priority with preemption, and resource allocation for multiple service classes.
適切なルーティングメカニズムに加えて、運営管理コントロールを必要とする2つの領域が、先取りがある取り扱い流れ優先権と、複数のサービスのクラスのための資源配分です。
3.7.1 Flow Priorities and Preemption
3.7.1 流れプライオリティと先取り
If there are critical flows that must be accorded higher priority than other types of flows, a mechanism must be implemented in the network to recognize flow priorities. There are two aspects to prioritizing flows. First, there must be a policy to decide how different users are allowed to set priorities for flows they originate. The network must be able to verify that a given flow is allowed to claim a priority level signaled for it. Second, the routing scheme must ensure that a path with the requested QoS will be found for a flow with a probability that increases with the priority of the flow. In other words, for a given network load, a high priority flow should be more likely to get a certain QoS from the network than a lower priority flow requesting the same QoS. Routing procedures for flow prioritization can be complex. Identification and evaluation of different procedures are areas that require investigation.
他のタイプの流れより高い優先度を与えなければならない批判的な流れがあれば、流れプライオリティを認識するためにネットワークでメカニズムを実行しなければなりません。 流れを最優先させることへの2つの局面があります。 まず最初に、異なったユーザがそれらが溯源する流れのためにどう優先順位をつけることができるかを決める方針があるに違いありません。 ネットワークは、与えられた流れが、優先順位がそれのために合図したと主張できることを確かめることができなければなりません。 2番目に、ルーティング計画は、要求されたQoSがある経路が流れの優先権で増加する確率に従った流れに関して見つけられるのを確実にしなければなりません。 言い換えれば、与えられたネットワーク負荷において、高い優先権流動は同じQoSを要求する低優先度流動よりネットワークからあるQoSを手に入れるべきでありそうです。 流れ優先順位づけのためのルート設定手順は複雑である場合があります。 異なった手順の識別と評価は調査を必要とする領域です。
3.7.2 Resource Control
3.7.2 資源管理
If there are multiple service classes, it is necessary to engineer a network to carry the forecasted traffic demands of each class. To do this, router and link resources may be logically partitioned among various service classes. It is desirable to have dynamic partitioning whereby unused resources in various partitions are dynamically shifted to other partitions on demand [ACFH92]. Dynamic sharing, however, must be done in a controlled fashion in order to prevent traffic under some service class from taking up more resources than
複数のサービスのクラスがあれば、それぞれのクラスの予測された交通需要を運ぶためにネットワークを設計するのが必要です。 これ、ルータ、およびリンクリソースをするのは様々なサービスのクラスで論理的に仕切られるかもしれません。 様々なパーティションにおける未利用資源がダイナミックにオンデマンドの他のパーティション[ACFH92]に移行するダイナミックな仕切りを持っているのは望ましいです。 しかしながら、何らかのサービスのクラスの下の交通が、より多くのリソースを取り上げるのを防ぐために管理された方法でダイナミックな共有をしなければなりません。
Crawley, et. al. Informational [Page 12] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[12ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
what was engineered for it for prolonged periods of time. The design of such a resource sharing scheme, and its incorporation into the QoS-based routing scheme are significant issues.
それのために時間の長期の間に設計されたこと。 そのようなリソース・シェアリングのデザインは計画します、そして、QoSベースのルーティング計画への編入は重要な問題です。
3.8 QoS-Based Routing for Multicast Flows
3.8 マルチキャストのためのQoSベースのルート設定は流れます。
QoS-based multicast routing is an important problem, especially if the notion of higher level admission control is included. The dynamism in the receiver set allowed by IP multicast, and receiver heterogeneity add to the problem. With straightforward implementation of distributed heuristic algorithms for multicast path computation [W88, C91], the difficulty is essentially one of scalability. To accommodate QoS, multicast path computation at a router must have knowledge of not only the id of subnets where group members are present, but also the identity of branches in the existing tree. In other words, routers must keep flow-specific state information. Also, computing optimal shared trees based on the shared reservation style [BZBH97], may require new algorithms. Multicast routing is discussed in some detail in Section 6.
特により高い平らな入場コントロールの概念が含まれているなら、QoSベースのマルチキャストルーティングは重大な問題です。 IPマルチキャストによって許容されて、受信機の力動説はセットしました、そして、受信機の異種性は問題に加えます。 マルチキャスト経路計算[W88、C91]のための分配されたヒューリスティックアルゴリズムの簡単な実現で、困難は本質的には1です。スケーラビリティについて。 QoSを収容するために、ルータにおけるマルチキャスト経路計算には、グループのメンバーが出席しているサブネットのイドだけではなく、既存の木のブランチのアイデンティティに関して知識がなければなりません。 言い換えれば、ルータは、流れ特有の状態が情報であることを保たなければなりません。 共有された予約スタイル[BZBH97]に基づく最適の共有された木をまた計算するのも新しいアルゴリズムを必要とするかもしれません。セクション6で何らかの詳細にマルチキャストルーティングについて議論します。
3.9 Routing Overheads
3.9 ルート設定オーバーヘッド
The overheads incurred by a routing scheme depend on the type of the routing scheme, as well as the implementation. There are three types of overheads to be considered: computation, storage and communication. It is necessary to understand the implications of choosing a routing mechanism in terms of these overheads.
ルーティング計画によって被られたオーバーヘッドはルーティング計画のタイプ、および実現に頼っています。 考えられる3つのタイプのオーバーヘッドがあります: 計算、格納、およびコミュニケーション。 これらのオーバーヘッドに関してルーティングメカニズムを選ぶ含意を理解するのが必要です。
For example, considering link state routing, the choice of the update propagation mechanism is important since network state is dynamic and changes relatively frequently. Specifically, a flooding mechanism would result in many unnecessary message transmissions and processing. Alternative techniques, such as tree-based forwarding [R96], have to be considered. A related issue is the quantization of state information to prevent frequent updating of dynamic state. While coarse quantization reduces updating overheads, it may affect the performance of the routing scheme. The tradeoff has to be carefully evaluated. QoS-based routing incurs certain overheads during flow establishment, for example, computing a source route. Whether this overhead is disproportionate compared to the length of the sessions is an issue. In general, techniques for the minimization of routing-related overheads during flow establishment must be investigated. Approaches that are useful include pre-computation of routes, caching recently used routes, and TOS routing based on hints in packets (e.g., the TOS field).
例えば、リンク状態がルーティングであると考える場合、ネットワーク状態がダイナミックであり、比較的頻繁に変化するので、アップデート伝播メカニズムの選択は重要です。 明確に、氾濫メカニズムは多くの不要なメッセージ送信と処理をもたらすでしょう。 木のベースの推進などの代替のテクニック[R96]は考えられなければなりません。 関連する問題は動態の頻繁なアップデートを防ぐ州の情報の量子化です。 下品な量子化がオーバーヘッドをアップデートしながら減少している間、それはルーティング計画の性能に影響するかもしれません。 見返りは慎重に評価されなければなりません。 例えば、QoSベースのルーティングは、流れ設立の間、送信元経路を計算しながら、あるオーバーヘッドを被ります。 セッションの長さと比べて、このオーバーヘッドが不均衡であるかどうかが、問題です。 一般に、流れ設立の間のルーティング関連のオーバーヘッドの最小化のためのテクニックを調査しなければなりません。 役に立つアプローチはルートのプレ計算を含んでいます、最近中古のルート、およびパケット(例えば、TOS分野)でヒントに基づくTOSルーティングをキャッシュして。
Crawley, et. al. Informational [Page 13] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[13ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
3.10 Scaling by Hierarchical Aggregation
3.10 階層的な集合で比例すること。
QoS-based routing should be scalable, and hierarchical aggregation is a common technique for scaling (e.g., [PNNI96]). But this introduces problems with regard to the accuracy of the aggregated state information [L95]. Also, the aggregation of paths under multiple constraints is difficult. One of the difficulties is the risk of accepting a flow based on inaccurate information, but not being able to support the QoS requirements of flow because the capabilities of the actual paths that are aggregated are not known during route computation. Performance impacts of aggregating path metric information must therefore be understood. A way to compensate for inaccuracies is to use crankback, i.e., dynamic search for alternate paths as a flow is being routed. But crankback increases the time to set up a flow, and may adversely affect the performance of the routing scheme under some circumstances. Thus, crankback must be used judiciously, if at all, along with a higher level admission control mechanism.
QoSベースのルーティングはスケーラブルであるべきです、そして、階層的な集合は、(例えば、[PNNI96])をスケーリングするための一般的なテクニックです。 しかし、これは集められた州の情報[L95]の精度に関して問題を紹介します。 また、複数の規制の下の経路の集合も難しいです。 困難の1つは不正確な情報に基づく流れを受け入れますが、集められる実際の経路の能力が経路計算の間、知られていないので流れのQoS要件を支持できないというリスクです。 したがって、経路のメートル法の情報に集めるパフォーマンス衝撃を理解しなければなりません。 誤りを補う方法がcrankbackを使用することであり、すなわち、流れとしての代替パスのダイナミックな検索は発送されています。 しかし、crankbackは流れをセットアップする時間を増加させて、いくつかの状況でルーティング計画の性能に悪影響を与えるかもしれません。 したがって、より高い平らな入場制御機構と共にcrankbackをせいぜい賢明に使用しなければなりません。
4. INTRADOMAIN ROUTING REQUIREMENTS
4. INTRADOMAINルーティング要件
At the intradomain level, the objective is to allow as much latitude as possible in addressing the QoS-based routing issues. Indeed, there are many ideas about how QoS-based routing services can be provisioned within ASs. These range from on-demand path computation based on current state information, to statically provisioned paths supporting a few service classes.
intradomainレベルでは、目的はQoSベースのルーティング問題を記述するのにおいてできるだけ多くの緯度を許容することです。 本当に、ASsの中でどうQoSベースのルーティングサービスに食糧を供給することができるかに関する多くの考えがあります。 これらは現状情報に基づく要求次第の経路計算から静的に食糧を供給されたサービスの数クラスを支持する経路まで及びます。
Another aspect that might invite differing solutions is performance optimization. Based on the technique used for this, intradomain routing could be very sophisticated or rather simple. Finally, the service classes supported, as well as the specific QoS engineered for a service class, could differ from AS to AS. For instance, some ASs may not support guaranteed service, while others may. Also, some ASs supporting the service may be engineered for a better delay bound than others. Thus, it requires considerable thought to determine the high level requirements for intradomain routing that both supports the overall view of QoS-based routing in the Internet and allows maximum autonomy in developing solutions.
異なった解決策を招待するかもしれないもう一つの側面はパフォーマンスの最適化です。 これに使用されるテクニックに基づいて、intradomainルーティングは、非常に高度であるか、またはかなり簡単であるかもしれません。 最終的に、サービスのクラスのために設計された特定のQoSと同様に支持されたサービスのクラスはASからASまで異なることができました。 例えば、いくつかのASsは保証されたサービスを支持しないかもしれませんが、他のものはそうするかもしれません。 また、サービスを支持するいくつかのASsが他のものより良い遅れバウンドのために設計されるかもしれません。 したがって、インターネットでQoSベースのルーティングの全体図を支持して、現像液で最大の自治を許容するintradomainルーティングのための高い平らな要件を決定するのがかなりの考えを必要とします。
Our view is that certain minimum requirements must be satisfied by intradomain routing in order to be qualified as "QoS-based" routing. These are:
私たちの視点は「QoSベース」のルーティングとして資格があるようにintradomainルーティングで、ある必要最小限を満たさなければならないということです。 これらは以下の通りです。
- The routing scheme must route a flow along a path that can
accommodate its QoS requirements, or indicate that the flow cannot
be admitted with the QoS currently being requested.
- ルーティング計画は、QoS要件を収容できる経路に沿って流れを発送しなければならないか、またはQoSが現在要求されている状態で流れを認めることができないのを示さなければなりません。
Crawley, et. al. Informational [Page 14] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[14ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
- The routing scheme must indicate disruptions to the current route
of a flow due to topological changes.
- ルーティング計画は位相的な変化による流れの現在のルートの分裂を示さなければなりません。
- The routing scheme must accommodate best-effort flows without any
resource reservation requirements. That is, present best effort
applications and protocol stacks need not have to change to run in
a domain employing QoS-based routing.
- ルーティング計画は少しも資源予約要件なしでベストエフォート型流れに対応しなければなりません。 すなわち、現在のベストエフォート型アプリケーションとプロトコル・スタックは、ドメインの雇用のQoSベースのルーティングに立候補するために変化しなければならない必要はありません。
- The routing scheme may optionally support QoS-based multicasting
with receiver heterogeneity and shared reservation styles.
- ルーティング計画は受信機の異種性と共有された予約スタイルで任意にQoSベースのマルチキャスティングを支持するかもしれません。
In addition, the following capabilities are also recommended:
また、さらに、以下の能力もお勧めです:
- Capabilities to optimize resource usage.
- リソース用法を最適化する能力。
- Implementation of higher level admission control procedures to
limit the overall resource utilization by individual flows.
- 個人による総合的なリソース利用を制限するより高い平らな入場コントロール手順の実現は流れます。
Further requirements along these lines may be specified. The requirements should capture the consensus view of QoS-based routing, but should not preclude particular approaches (e.g., TOS-based routing) from being implemented. Thus, the intradomain requirements are expected to be rather broad.
これらの線に沿ったさらなる要件は指定されるかもしれません。 要件は、QoSベースのルーティングの大多数の見解を得るべきですが、実行されるので、特定のアプローチ(例えば、TOSベースのルーティング)を排除するべきではありません。 したがって、intradomain要件がかなり広いと予想されます。
5. INTERDOMAIN ROUTING
5. INTERDOMAINルーティング
The fundamental requirement on interdomain QoS-based routing is scalability. This implies that interdomain routing cannot be based on highly dynamic network state information. Rather, such routing must be aided by sound network engineering and relatively sparse information exchange between independent routing domains. This approach has the advantage that it can be realized by straightforward extensions of the present Internet interdomain routing model. A number of issues, however, need to be addressed to achieve this, as discussed below.
interdomain QoSベースのルーティングに関する基本的な要件はスケーラビリティです。 これは、interdomainルーティングが非常にダイナミックなネットワーク州の情報に基づくことができないのを含意します。 むしろ、独立している経路ドメインの間の音のネットワーク工学と比較的まばらな情報交換でそのようなルーティングを支援しなければなりません。 それは利点であるかもしれませんが、このアプローチは現在のインターネットinterdomainルーティングモデルの簡単な拡大で実感されていた状態でそうしました。 しかしながら、多くの問題が、以下で議論するようにこれを達成するために記述される必要があります。
Crawley, et. al. Informational [Page 15] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[15ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
5.1 Interdomain QoS-Based Routing Model
5.1 Interdomain QoSベースのルート設定モデル
The interdomain QoS-based routing model is depicted below:
interdomain QoSベースのルーティングモデルは以下に表現されます:
AS1 AS2 AS3
___________ _____________ ____________
| | | | | |
| B------B B----B |
| | | | | |
-----B----- B------------- --B---------
\ / /
\ / /
____B_____B____ _________B______
| | | |
| B-------B |
| | | |
| B-------B |
--------------- ----------------
AS4 AS5
AS1 AS2 AS3___________ _____________ ____________ | | | | | | | B------B B----B| | | | | | | -----B----- B------------- --B--------- \ / / \ / / ____B_____B____ _________B______ | | | | | B-------B| | | | | | B-------B| --------------- ---------------- AS4 AS5
Here, ASs exchange standardized routing information via border nodes B. Under this model, each AS can itself consist of a set of interconnected ASs, with standardized routing interaction. Thus, the interdomain routing model is hierarchical. Also, each lowest level AS employs an intradomain QoS-based routing scheme (proprietary or standardized by intradomain routing efforts such as QOSPF). Given this structure, some questions that arise are:
ここで、ASs交換はこのモデル、それぞれのAS缶自体がインタコネクトされたASsの1セットから成るという境界ノードB.Underを通したルーティング情報を標準化しました、標準化されたルーティング相互作用で。 したがって、interdomainルーティングモデルは階層的です。 また、それぞれの最も低いレベルASはintradomain QoSベースのルーティング計画(独占であるかQOSPFなどのintradomainルーティングの努力で標準化された)を使います。 この構造を考えて、起こるいくつかの質問は以下の通りです。
- What information is exchanged between ASs?
- ASsの間でどんな情報を交換しますか?
- What routing capabilities does the information exchange lead to?
(E.g., source routing, on-demand path computation, etc.)
- 情報交換はどんなルーティング能力につながりますか? (例えば、ソースルーティング、要求次第の経路計算など)
- How is the external routing information represented within an AS?
- 外部のルーティング情報はASの中にどのように表されますか?
- How are interdomain paths computed?
- interdomain経路はどのように計算されますか?
- What sort of policy controls may be exerted on interdomain path
computation and flow routing?, and
- どういう方針コントロールがinterdomain経路計算と流れルーティングに及ぼされるかもしれませんか?
- How is interdomain QoS-based multicast routing accomplished?
- interdomain QoSベースのマルチキャストルーティングはどのように達成されますか?
At a high level, the answers to these questions depend on the routing paradigm. Specifically, considering link state routing, the information exchanged between domains would consist of an abstract representation of the domains in the form of logical nodes and links, along with metrics that quantify their properties and resource availability. The hierarchical structure of the ASs may be handled
高いレベルでは、これらの質問の答えはルーティングパラダイムによります。 明確に、リンク状態がルーティングであると考える場合、ドメインの間で交換された情報は論理的なノードとリンクの形における、ドメインの抽象的表現から成るでしょう、それらの特性とリソースの有用性を定量化する測定基準と共に。 ASsの階層構造は扱われるかもしれません。
Crawley, et. al. Informational [Page 16] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[16ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
by a hierarchical link state representation, with appropriate metric aggregation.
階層的なリンクのそばでは、適切なメートル法の集合で表現を述べてください。
Link state routing may not necessarily be advantageous for interdomain routing for the following reasons:
interdomainルーティングには、リンク州のルーティングは以下の理由で必ず有利であるかもしれないというわけではありません:
- One advantage of intradomain link state routing is that it would
allow fairly detailed link state information be used to compute
paths on demand for flows requiring QoS. The state and metric
aggregation used in interdomain routing, on the other hand, erodes
this property to a great degree.
- intradomainリンク州のルーティングの1つの利点は詳細なリンク州の情報を公正に許容するだろうということです。使用されて、QoSを必要としながら、流れのためのオンデマンドの経路を計算してください。 他方では、interdomainルーティングで使用される状態とメートル法の集合は大いにこの特性を浸食します。
- The usefulness of keeping track of the abstract topology and
metrics of a remote domain, or the interconnection between remote
domains is not obvious. This is especially the case when the remote
topology and metric encoding are lossy.
- キープの有用性が遠く離れたドメインの抽象的なトポロジーと測定基準を追跡するか、または遠く離れたドメインの間のインタコネクトは明白ではありません。 遠く離れたトポロジーとメートル法のコード化が損失性であるときに、これは特にそうです。
- ASs may not want to advertise any details of their internal
topology or resource availability.
- ASsはそれらの内部のトポロジーかリソースの有用性のどんな詳細も広告を出したがっていないかもしれません。
- Scalability in interdomain routing can be achieved only if
information exchange between domains is relatively infrequent.
Thus, it seems practical to limit information flow between domains
as much as possible.
- ドメインの間の情報交換が比較的珍しい場合にだけ、interdomainルーティングによるスケーラビリティを達成できます。 したがって、ドメインの間の情報流動をできるだけ制限するのは実用的に思えます。
Compact information flow allows the implementation QoS-enhanced versions of existing interdomain protocols such as BGP-4. We look at the interdomain routing issues in this context.
コンパクトな情報流動は存在する実現のQoSによって高められたバージョンにBGP-4などのinterdomainプロトコルを許容します。 私たちはこのような関係においてはinterdomainルーティング問題を見ます。
5.2 Interdomain Information Flow
5.2 Interdomain情報流動
The information flow between routing domains must enable certain basic functions:
経路ドメインの間の情報流動はある基本機能を可能にしなければなりません:
1. Determination of reachability to various destinations
1. 様々な目的地への可到達性の決断
2. Loop-free flow routes
2. 無輪の流れルート
3. Address aggregation whenever possible
3. 可能であるときはいつも、集合を記述してください。
4. Determination of the QoS that will be supported on the path to a
destination. The QoS information should be relatively static,
determined from the engineered topology and capacity of an AS
rather than ephemeral fluctuations in traffic load through the
AS. Ideally, the QoS supported in a transit AS should be allowed
to vary significantly only under exceptional circumstances, such
as failures or focused overload.
4. 経路で目的地に支持されるQoSの決断。 QoS情報は比較的静的であるべきです、ASを通したトラヒック負荷におけるはかない変動よりむしろASの設計されたトポロジーと容量から、断固としています。 理想的にASが失敗か集中しているオーバーロードなどの例外的な状況だけでかなり変えるはずであることができるトランジットで支持されたQoS。
Crawley, et. al. Informational [Page 17] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[17ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
5. Determination, optionally, of multiple paths for a given
destination, based on service classes.
5. 与えられた目的地への複数の経路について任意にサービスのクラスに基づく決断。
6. Expression of routing policies, including monetary cost, as a
function of flow parameters, usage and administrative factors.
6. 流れパラメタ、用法、および管理要素の関数として貨幣原価を含むルーティング方針の表現。
Items 1-3 are already part of existing interdomain routing. Item 5 is also a straightfoward extension of the current model. The main problem areas are therefore items 4 and 6.
項目1-3は既に既存のinterdomainルーティングの一部です。 また、項目5はstraightfowardにaです。現在のモデルの拡大。 したがって、主な問題領域は項目4と6です。
The QoS of an end-to-end path is obtained by composing the QoS available in each transit AS. Thus, border routers must first determine what the locally available QoS is in order to advertise routes to both internal and external destinations. The determination of local "AS metrics" (corresponding to link metrics in the intradomain case) should not be subject to too much dynamism. Thus, the issue is how to define such metrics and what triggers an occasional change that results in re-advertisements of routes.
各トランジットASで利用可能なQoSを構成することによって、終わりから端への経路のQoSを入手します。 したがって、境界ルータは、最初に、内部の、そして、外部の両方の目的地にルートの広告を出すために局所的に利用可能なQoSが何であるかを決定しなければなりません。 地方の「AS測定基準」(intradomain場合における測定基準をリンクするために対応する)の決断はあまりに多くの力動説を受けることがあるべきではありません。 したがって、問題はどのようにそのような測定基準を定義するか、そして、何がルートの再広告をもたらす時々の変化の引き金となるかということです。
The approach suggested in this document is not to compute paths based on residual or instantaneous values of AS metics (which can be dynamic), but utilize only the QoS capabilities engineered for aggregate transit flows. Such engineering may be based on the knowledge of traffic to be expected from each neighboring ASs and the corresponding QOS needs. This information may be obtained based on contracts agreed upon prior to the provisioning of services. The AS metric then corresponds to the QoS capabilities of the "virtual path" engineered through the AS (for transit traffic) and a different metric may be used for different neighbors. This is illustrated in the following figure.
本書では示されたアプローチはAS metics(ダイナミックである場合がある)の残りの、または、瞬時に起こっている値に基づく経路を計算するのではなく、集合のために設計されたQoS能力だけを利用するために、トランジットが流れるということです。 そのような工学は、それぞれの隣接しているASsとQOSが必要とする対応から予想されるために交通に関する知識に基づくかもしれません。 サービスの食糧を供給することの前に同意された契約に基づいてこの情報を得るかもしれません。 次に、メートル法のASが「仮想の経路」のQoS能力にAS(トランジット交通への)を通して設計されていてa異なった状態で対応している、メートル法、異なった隣人に使用されるかもしれません。 これは以下の図で例証されます。
AS1 AS2 AS3
___________ _____________ ____________
| | | | | |
| B------B1 B2----B |
| | | | | |
-----B----- B3------------ --B---------
\ /
\ /
____B_____B____
| |
| |
| |
| |
---------------
AS4
AS1 AS2 AS3___________ _____________ ____________ | | | | | | | B------B1 B2----B| | | | | | | -----B----- B3------------ --B--------- \ / \ / ____B_____B____ | | | | | | | | --------------- AS4
Crawley, et. al. Informational [Page 18] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[18ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
Here, B1 may utilize an AS metric specific for AS1 when computing path metrics to be advertised to AS1. This metric is based on the resources engineered in AS2 for transit traffic from AS1. Similarly, B3 may utilize a different metric when computing path metrics to be advertised to AS4. Now, it is assumed that as long as traffic flow into AS2 from AS1 or AS4 does not exceed the engineered values, these path metrics would hold. Excess traffic due to transient fluctuations, however, may be handled as best effort or marked with a discard bit.
AS1に広告を出すために経路測定基準を計算するとき、ここで、B1はASのメートル法の詳細をAS1に利用するかもしれません。 これほどメートル法であることは、リソースに基づいてそうです。AS2では、AS1からのトランジット交通に設計されます。 同様に、B3がaを利用するかもしれない、相違、AS4に広告を出すために経路測定基準を計算すると、メートル法です。 現在、AS1かAS4からのAS2への交通の流れが設計された値を超えていない限り、これらの経路測定基準が成立すると思われます。 しかしながら、一時的な変動による余分な交通は、ベストエフォート型として扱われるか、または噛み付かれた破棄で示されるかもしれません。
Thus, this model is different from the intradomain model, where end nodes pick a path dynamically based on the QoS needs of the flow to be routed. Here, paths within ASs are engineered based on presumed, measured or declared traffic and QoS requirements. Under this model, an AS can contract for routes via multiple transit ASs with different QoS requirements. For instance, AS4 above can use both AS1 and AS2 as transits for same or different destinations. Also, a QoS contract between one AS and another may generate another contract between the second and a third AS and so forth.
したがって、このモデルはintradomainモデルと異なっています。そこでは、エンドノードがダイナミックに流れが発送されるQoSの必要性に基づく経路を選びます。 ここで、ASsの中の経路は、推定にされるに基づいて設計されるか、測定されるか、または交通とQoS要件であると宣言されます。 このモデルの下では、ASは異なったQoS要件がある複数のトランジットASsを通してルートを請け負うことができます。 例えば、上のAS4は同じであるか異なった目的地にトランジットとしてAS1とAS2の両方を使用できます。 また、1ASと別のものとのQoS契約は2番目と3分の1ASなどとの別の契約を作るかもしれません。
An issue is what triggers the recomputation of path metrics within an AS. Failures or other events that prevent engineered resource allocation should certainly trigger recomputation. Recomputation should not be triggered in response to arrival of flows within the engineered limit.
問題はASの中で経路測定基準の再計算の引き金となることです。 確かに、設計された資源配分を防ぐ失敗か他の出来事が再計算の引き金となるべきです。 設計された限界の中で流れの到着に対応してRecomputationを引き起こすべきではありません。
5.3 Path Computation
5.3 経路計算
Path computation for an external destination at a border node is based on reachability, path metrics and local policies of selection. If there are multiple selection criteria (e.g., delay, bandwidth, cost, etc.), mutiple alternaives may have to be maintained as well as propagated by border nodes. Selection of a path from among many alternatives would depend on the QoS requests of flows, as well as policies. Path computation may also utilze any heuristics for optimizing resource usage.
境界ノードの外部の目的地のための経路計算は可到達性、経路測定基準、および選択のローカルの方針に基づいています。 複数の選択評価基準(例えば、遅れ、帯域幅、費用など)があれば、mutiple alternaivesは境界ノードによって維持されて、伝播されなければならないかもしれません。 多くの選択肢からの経路の選択は流れ、および方針のQoS要求によるでしょう。 また、経路計算はリソース用法を最適化するためのどんな発見的教授法もutilzeするかもしれません。
5.4 Flow Aggregation
5.4 流れ集合
An important issue in interdomain routing is the amount of flow state to be processed by transit ASs. Reducing the flow state by aggregation techniques must therefore be seriously considered. Flow aggregation means that transit traffic through an AS is classified into a few aggregated streams rather than being routed at the individual flow level. For example, an entry border router may classify various transit flows entering an AS into a few coarse categories, based on the egress node and QoS requirements of the flows. Then, the aggregated stream for a given traffic class may be
An important issue in interdomain routing is the amount of flow state to be processed by transit ASs. Reducing the flow state by aggregation techniques must therefore be seriously considered. Flow aggregation means that transit traffic through an AS is classified into a few aggregated streams rather than being routed at the individual flow level. For example, an entry border router may classify various transit flows entering an AS into a few coarse categories, based on the egress node and QoS requirements of the flows. Then, the aggregated stream for a given traffic class may be
Crawley, et. al. Informational [Page 19] RFC 2386 A Framework for QoS-based Routing August 1998
Crawley, et. al. Informational [Page 19] RFC 2386 A Framework for QoS-based Routing August 1998
routed as a single flow inside the AS to the exit border router. This router may then present individual flows to different neighboring ASs and the process repeats at each entry border router. Under this scenario, it is essential that entry border routers keep track of the resource requirements for each transit flow and apply admission control to determine whether the aggregate requirement from any neighbor exceeds the engineered limit. If so, some policy must be invoked to deal with the excess traffic. Otherwise, it may be assumed that aggregated flows are routed over paths that have adequate resources to guarantee QoS for the member flows. Finally, it is possible that entry border routers at a transit AS may prefer not to aggregate flows if finer grain routing within the AS may be more efficient (e.g., to aid load balancing within the AS).
routed as a single flow inside the AS to the exit border router. This router may then present individual flows to different neighboring ASs and the process repeats at each entry border router. Under this scenario, it is essential that entry border routers keep track of the resource requirements for each transit flow and apply admission control to determine whether the aggregate requirement from any neighbor exceeds the engineered limit. If so, some policy must be invoked to deal with the excess traffic. Otherwise, it may be assumed that aggregated flows are routed over paths that have adequate resources to guarantee QoS for the member flows. Finally, it is possible that entry border routers at a transit AS may prefer not to aggregate flows if finer grain routing within the AS may be more efficient (e.g., to aid load balancing within the AS).
5.5 Path Cost Determination
5.5 Path Cost Determination
It is hoped that the integrated services Internet architecture would allow providers to charge for IP flows based on their QoS requirements. A QoS-based routing architecture can aid in distributing information on expected costs of routing flows to various destinations via different domains. Clearly, from a provider's point of view, there is a cost incurred in guaranteeing QoS to flows. This cost could be a function of several parameters, some related to flow parameters, others based on policy. From a user's point of view, the consequence of requesting a particular QoS for a flow is the cost incurred, and hence the selection of providers may be based on cost. A routing scheme can aid a provider in distributing the costs in routing to various destinations, as a function of several parameters, to other providers or to end users. In the interdomain routing model described earlier, the costs to a destination will change as routing updates are passed through a transit domain. One of the goals of the routing scheme should be to maintain a uniform semantics for cost values (or functions) as they are handled by intermediate domains. As an example, consider the cost function generated by border node B1 in domain A and passed to node B2 in domain B below. The routing update may be injected into domain B by B2 and finally passed to B4 in domain C by router B3. Domain B may interpret the cost value received from domain A in any way it wants, for instance, adding a locally significant component to it. But when this cost value is passed to domain C, the meaning of it must be what domain A intended, plus the incremental cost of transiting domain B, but not what domain B uses internally.
It is hoped that the integrated services Internet architecture would allow providers to charge for IP flows based on their QoS requirements. A QoS-based routing architecture can aid in distributing information on expected costs of routing flows to various destinations via different domains. Clearly, from a provider's point of view, there is a cost incurred in guaranteeing QoS to flows. This cost could be a function of several parameters, some related to flow parameters, others based on policy. From a user's point of view, the consequence of requesting a particular QoS for a flow is the cost incurred, and hence the selection of providers may be based on cost. A routing scheme can aid a provider in distributing the costs in routing to various destinations, as a function of several parameters, to other providers or to end users. In the interdomain routing model described earlier, the costs to a destination will change as routing updates are passed through a transit domain. One of the goals of the routing scheme should be to maintain a uniform semantics for cost values (or functions) as they are handled by intermediate domains. As an example, consider the cost function generated by border node B1 in domain A and passed to node B2 in domain B below. The routing update may be injected into domain B by B2 and finally passed to B4 in domain C by router B3. Domain B may interpret the cost value received from domain A in any way it wants, for instance, adding a locally significant component to it. But when this cost value is passed to domain C, the meaning of it must be what domain A intended, plus the incremental cost of transiting domain B, but not what domain B uses internally.
Crawley, et. al. Informational [Page 20] RFC 2386 A Framework for QoS-based Routing August 1998
Crawley, et. al. Informational [Page 20] RFC 2386 A Framework for QoS-based Routing August 1998
Domain A Domain B Domain C
____________ ___________ ____________
| | | | | |
| B1------B2 B3---B4 |
| | | | | |
------------ ----------- ------------
Domain A Domain B Domain C ____________ ___________ ____________ | | | | | | | B1------B2 B3---B4 | | | | | | | ------------ ----------- ------------
A problem with charging for a flow is the determination of the cost when the QoS promised for the flow was not actually delivered. Clearly, when a flow is routed via multiple domains, it must be determined whether each domain delivers the QoS it declares possible for traffic through it.
A problem with charging for a flow is the determination of the cost when the QoS promised for the flow was not actually delivered. Clearly, when a flow is routed via multiple domains, it must be determined whether each domain delivers the QoS it declares possible for traffic through it.
6. QOS-BASED MULTICAST ROUTING
6. QOS-BASED MULTICAST ROUTING
The goals of QoS-based multicast routing are as follows:
The goals of QoS-based multicast routing are as follows:
- Scalability to large groups with dynamic membership
- Scalability to large groups with dynamic membership
- Robustness in the presence of topological changes
- Robustness in the presence of topological changes
- Support for receiver-initiated, heterogeneous reservations
- Support for receiver-initiated, heterogeneous reservations
- Support for shared reservation styles, and
- Support for shared reservation styles, and
- Support for "global" admission control, i.e., administrative
control of resource consumption by the multicast flow.
- Support for "global" admission control, i.e., administrative control of resource consumption by the multicast flow.
The RSVP multicast flow model is as follows. The sender of a multicast flow advertises the traffic characteristics periodically to the receivers. On receipt of an advertisement, a receiver may generate a message to reserve resources along the flow path from the sender. Receiver reservations may be heterogeneous. Other multicast models may be considered.
The RSVP multicast flow model is as follows. The sender of a multicast flow advertises the traffic characteristics periodically to the receivers. On receipt of an advertisement, a receiver may generate a message to reserve resources along the flow path from the sender. Receiver reservations may be heterogeneous. Other multicast models may be considered.
The multicast routing scheme attempts to determine a path from the sender to each receiver that can accommodate the requested reservation. The routing scheme may attempt to maximize network resource utilization by minimizing the total bandwidth allocated to the multicast flow, or by optimizing some other measure.
The multicast routing scheme attempts to determine a path from the sender to each receiver that can accommodate the requested reservation. The routing scheme may attempt to maximize network resource utilization by minimizing the total bandwidth allocated to the multicast flow, or by optimizing some other measure.
6.1 Scalability, Robustness and Heterogeneity
6.1 Scalability, Robustness and Heterogeneity
When addressing scalability, two aspects must be considered:
When addressing scalability, two aspects must be considered:
1. The overheads associated with receiver discovery. This overhead
is incurred when determining the multicast tree for forwarding
best-effort sender traffic characterization to receivers.
1. The overheads associated with receiver discovery. This overhead is incurred when determining the multicast tree for forwarding best-effort sender traffic characterization to receivers.
Crawley, et. al. Informational [Page 21] RFC 2386 A Framework for QoS-based Routing August 1998
Crawley, et. al. Informational [Page 21] RFC 2386 A Framework for QoS-based Routing August 1998
2. The overheads associated with QoS-based multicast path
computation. This overhead is incurred when flow-specific
state information has to be collected by a router to determine
QoS-accommodating paths to a receiver.
2. The overheads associated with QoS-based multicast path computation. This overhead is incurred when flow-specific state information has to be collected by a router to determine QoS-accommodating paths to a receiver.
Depending on the multicast routing scheme, one or both of these aspects become important. For instance, under the present RSVP model, reservations are established on the same path over which sender traffic characterizations are sent, and hence there is no path computation overhead. On the other hand, under the proposed QOSPF model [ZSSC97] of multicast source routing, receiver discovery overheads are incurred by MOSPF [M94] receiver location broadcasts, and additional path computation overheads are incurred due to the need to keep track of existing flow paths. Scaling of QoS-based multicast depends on both these scaling issues. However, scalable best-effort multicasting is really not in the domain of QoS-based routing work (solutions for this are being devised by the IDMR WG [BCF94, DEFV94]). QoS-based multicast routing may build on these solutions to achieve overall scalability.
Depending on the multicast routing scheme, one or both of these aspects become important. For instance, under the present RSVP model, reservations are established on the same path over which sender traffic characterizations are sent, and hence there is no path computation overhead. On the other hand, under the proposed QOSPF model [ZSSC97] of multicast source routing, receiver discovery overheads are incurred by MOSPF [M94] receiver location broadcasts, and additional path computation overheads are incurred due to the need to keep track of existing flow paths. Scaling of QoS-based multicast depends on both these scaling issues. However, scalable best-effort multicasting is really not in the domain of QoS-based routing work (solutions for this are being devised by the IDMR WG [BCF94, DEFV94]). QoS-based multicast routing may build on these solutions to achieve overall scalability.
There are several options for QoS-based multicast routing. Multicast source routing is one under which multicast trees are computed by the first-hop router from the source, based on sender traffic advertisements. The advantage of this is that it blends nicely with the present RSVP signaling model. Also, this scheme works well when receiver reservations are homogeneous and the same as the maximum reservation derived from sender advertisement. The disadvantages of this scheme are the extra effort needed to accommodate heterogeneous reservations and the difficulties in optimizing resource allocation based on shared reservations.
There are several options for QoS-based multicast routing. Multicast source routing is one under which multicast trees are computed by the first-hop router from the source, based on sender traffic advertisements. The advantage of this is that it blends nicely with the present RSVP signaling model. Also, this scheme works well when receiver reservations are homogeneous and the same as the maximum reservation derived from sender advertisement. The disadvantages of this scheme are the extra effort needed to accommodate heterogeneous reservations and the difficulties in optimizing resource allocation based on shared reservations.
In these regards, a receiver-oriented multicast routing model seems to have some advantage over multicast source routing. Under this model:
In these regards, a receiver-oriented multicast routing model seems to have some advantage over multicast source routing. Under this model:
1. Sender traffic advertisements are multicast over a best-effort
tree which can be different from the QoS-accommodating tree for
sender data.
1. Sender traffic advertisements are multicast over a best-effort tree which can be different from the QoS-accommodating tree for sender data.
2. Receiver discovery overheads are minimized by utilizing a
scalable scheme (e.g., PIM, CBT), to multicast sender traffic
characterization.
2. Receiver discovery overheads are minimized by utilizing a scalable scheme (e.g., PIM, CBT), to multicast sender traffic characterization.
3. Each receiver-side router independently computes a QoS-
accommodating path from the source, based on the receiver
reservation. This path can be computed based on unicast routing
information only, or with additional multicast flow-specific
state information. In any case, multicast path computation is
3. Each receiver-side router independently computes a QoS- accommodating path from the source, based on the receiver reservation. This path can be computed based on unicast routing information only, or with additional multicast flow-specific state information. In any case, multicast path computation is
Crawley, et. al. Informational [Page 22] RFC 2386 A Framework for QoS-based Routing August 1998
Crawley, et. al. Informational [Page 22] RFC 2386 A Framework for QoS-based Routing August 1998
broken up into multiple, concurrent nunicast path computations.
broken up into multiple, concurrent nunicast path computations.
4. Routers processing unicast reserve messages from receivers
aggregate resource reservations from multiple receivers.
4. Routers processing unicast reserve messages from receivers aggregate resource reservations from multiple receivers.
Flow-specific state information may be limited in Step 3 to achieve scalability [RN98]. In general, limiting flow-specific information in making multicast routing decisions is important in any routing model. The advantages of this model are the ease with which heterogeneous reservations can be accommodated, and the ability to handle shared reservations. The disadvantages are the incompatibility with the present RSVP signaling model, and the need to rely on reverse paths when link state routing is not used. Both multicast source routing and the receiver-oriented routing model described above utilize per- source trees to route multicast flows. Another possibility is the utilization of shared, per-group trees for routing flows. The computation and usage of such trees require further work.
Flow-specific state information may be limited in Step 3 to achieve scalability [RN98]. In general, limiting flow-specific information in making multicast routing decisions is important in any routing model. The advantages of this model are the ease with which heterogeneous reservations can be accommodated, and the ability to handle shared reservations. The disadvantages are the incompatibility with the present RSVP signaling model, and the need to rely on reverse paths when link state routing is not used. Both multicast source routing and the receiver-oriented routing model described above utilize per- source trees to route multicast flows. Another possibility is the utilization of shared, per-group trees for routing flows. The computation and usage of such trees require further work.
Finally, scalability at the interdomain level may be achieved if QoS-based multicast paths are computed independently in each domain. This principle is illustrated by the QOSPF multicast source routing scheme which allows independent path computation in different OSPF areas. It is easy to incorporate this idea in the receiver-oriented model also. An evaluation of multicast routing strategies must take into account the relative advantages and disadvantages of various approaches, in terms of scalability features and functionality supported.
Finally, scalability at the interdomain level may be achieved if QoS-based multicast paths are computed independently in each domain. This principle is illustrated by the QOSPF multicast source routing scheme which allows independent path computation in different OSPF areas. It is easy to incorporate this idea in the receiver-oriented model also. An evaluation of multicast routing strategies must take into account the relative advantages and disadvantages of various approaches, in terms of scalability features and functionality supported.
6.2 Multicast Admission Control
6.2 Multicast Admission Control
Higher level admission control, as defined for unicast, prevents excessive resource consumption by flows when traffic load is high. Such an admission control strategy must be applied to multicast flows when the flow path computation is receiver-oriented or sender- oriented. In essence, a router computing a path for a receiver must determine whether the incremental resource allocation for the receiver is excessive under some administratively determined admission control policy. Other admission control criteria, based on the total resource consumption of a tree may be defined.
Higher level admission control, as defined for unicast, prevents excessive resource consumption by flows when traffic load is high. Such an admission control strategy must be applied to multicast flows when the flow path computation is receiver-oriented or sender- oriented. In essence, a router computing a path for a receiver must determine whether the incremental resource allocation for the receiver is excessive under some administratively determined admission control policy. Other admission control criteria, based on the total resource consumption of a tree may be defined.
7. QOS-BASED ROUTING AND RESOURCE RESERVATION PROTOCOLS
7. QOS-BASED ROUTING AND RESOURCE RESERVATION PROTOCOLS
There must clearly be a well-defined interface between routing and resource reservation protocols. The nature of this interface, and the interaction between routing and resource reservation has to be determined carefully to avoid incompatibilities. The importance of this can be readily illustrated in the case of RSVP.
There must clearly be a well-defined interface between routing and resource reservation protocols. The nature of this interface, and the interaction between routing and resource reservation has to be determined carefully to avoid incompatibilities. The importance of this can be readily illustrated in the case of RSVP.
Crawley, et. al. Informational [Page 23] RFC 2386 A Framework for QoS-based Routing August 1998
Crawley, et. al. Informational [Page 23] RFC 2386 A Framework for QoS-based Routing August 1998
RSVP has been designed to operate independent of the underlying routing scheme. Under this model, RSVP PATH messages establish the reverse path for RESV messages. In essence, this model is not compatible with QoS-based routing schemes that compute paths after receiver reservations are received. While this incompatibility can be resolved in a simple manner for unicast flows, multicast with heterogeneous receiver requirements is a more difficult case. For this, reconciliation between RSVP and QoS-based routing models is necessary. Such a reconciliation, however, may require some changes to the RSVP model depending on the QoS-based routing model [ZES97, ZSSC97, GOA97]. On the other hand, QoS-based routing schemes may be designed with RSVP compatibility as a necessary goal. How this affects scalability and other performance measures must be considered.
RSVP has been designed to operate independent of the underlying routing scheme. Under this model, RSVP PATH messages establish the reverse path for RESV messages. In essence, this model is not compatible with QoS-based routing schemes that compute paths after receiver reservations are received. While this incompatibility can be resolved in a simple manner for unicast flows, multicast with heterogeneous receiver requirements is a more difficult case. For this, reconciliation between RSVP and QoS-based routing models is necessary. Such a reconciliation, however, may require some changes to the RSVP model depending on the QoS-based routing model [ZES97, ZSSC97, GOA97]. On the other hand, QoS-based routing schemes may be designed with RSVP compatibility as a necessary goal. How this affects scalability and other performance measures must be considered.
8. SECURITY CONSIDERATIONS
8. SECURITY CONSIDERATIONS
Security issues that arise with routing in general are about maintaining the integrity of the routing protocol in the presence of unintentional or malicious introduction of information that may lead to protocol failure [P88]. QoS-based routing requires additional security measures both to validate QoS requests for flows and to prevent resource-depletion type of threats that can arise when flows are allowed to make arbitratry resource requests along various paths in the network. Excessive resource consumption by an errant flow results in denial of resources to legitimate flows. While these situations may be prevented by setting up proper policy constraints, charging models and policing at various points in the network, the formalization of such protection requires work [BCCH94].
Security issues that arise with routing in general are about maintaining the integrity of the routing protocol in the presence of unintentional or malicious introduction of information that may lead to protocol failure [P88]. QoS-based routing requires additional security measures both to validate QoS requests for flows and to prevent resource-depletion type of threats that can arise when flows are allowed to make arbitratry resource requests along various paths in the network. Excessive resource consumption by an errant flow results in denial of resources to legitimate flows. While these situations may be prevented by setting up proper policy constraints, charging models and policing at various points in the network, the formalization of such protection requires work [BCCH94].
9. RELATED WORK
9. RELATED WORK
"Adaptive" routing, based on network state, has a long history, especially in circuit-switched networks. Such routing has also been implemented in early datagram and virtual circuit packet networks. More recently, this type of routing has been the subject of study in the context of ATM networks, where the traffic characteristics and topology are substantially different from those of circuit-switched networks [MMR96]. It is instructive to review the adaptive routing methodologies, both to understand the problems encountered and possible solutions.
"Adaptive" routing, based on network state, has a long history, especially in circuit-switched networks. Such routing has also been implemented in early datagram and virtual circuit packet networks. More recently, this type of routing has been the subject of study in the context of ATM networks, where the traffic characteristics and topology are substantially different from those of circuit-switched networks [MMR96]. It is instructive to review the adaptive routing methodologies, both to understand the problems encountered and possible solutions.
Fundamentally, there are two aspects to adaptive, network state- dependent routing:
Fundamentally, there are two aspects to adaptive, network state- dependent routing:
1. Measuring and gathering network state information, and
2. Computing routes based on the available information.
1. Measuring and gathering network state information, and 2. Computing routes based on the available information.
Crawley, et. al. Informational [Page 24] RFC 2386 A Framework for QoS-based Routing August 1998
Crawley, et. al. Informational [Page 24] RFC 2386 A Framework for QoS-based Routing August 1998
Depending on how these two steps are implemented, a variety of routing techniques are possible. These differ in the following respects:
Depending on how these two steps are implemented, a variety of routing techniques are possible. These differ in the following respects:
- what state information is used
- whether local or global state is used
- what triggers the propagation of state information
- whether routes are computed in a distributed or centralized manner
- whether routes are computed on-demand, pre-computed, or in a
hybrid manner
- what optimization criteria, if any, are used in computing routes
- whether source routing or hop by hop routing is used, and
- how alternate route choices are explored
- what state information is used - whether local or global state is used - what triggers the propagation of state information - whether routes are computed in a distributed or centralized manner - whether routes are computed on-demand, pre-computed, or in a hybrid manner - what optimization criteria, if any, are used in computing routes - whether source routing or hop by hop routing is used, and - how alternate route choices are explored
It should be noted that most of the adaptive routing work has focused on unicast routing. Multicast routing is one of the areas that would be prominent with Internet QoS-based routing. We treat this separately, and the following review considers only unicast routing. This review is not exhaustive, but gives a brief overview of some of the approaches.
It should be noted that most of the adaptive routing work has focused on unicast routing. Multicast routing is one of the areas that would be prominent with Internet QoS-based routing. We treat this separately, and the following review considers only unicast routing. This review is not exhaustive, but gives a brief overview of some of the approaches.
9.1 Optimization Criteria
9.1 Optimization Criteria
The most common optimization criteria used in adaptive routing is throughput maximization or delay minimization. A general formulation of the optimization problem is the one in which the network revenue is maximized, given that there is a cost associated with routing a flow over a given path [MMR96, K88]. In general, global optimization solutions are difficult to implement, and they rely on a number of assumptions on the characteristics of the traffic being routed [MMR96]. Thus, the practical approach has been to treat the routing of each flow (VC, circuit or packet stream to a given destination) independently of the routing of other flows. Many such routing schemes have been implemented.
The most common optimization criteria used in adaptive routing is throughput maximization or delay minimization. A general formulation of the optimization problem is the one in which the network revenue is maximized, given that there is a cost associated with routing a flow over a given path [MMR96, K88]. In general, global optimization solutions are difficult to implement, and they rely on a number of assumptions on the characteristics of the traffic being routed [MMR96]. Thus, the practical approach has been to treat the routing of each flow (VC, circuit or packet stream to a given destination) independently of the routing of other flows. Many such routing schemes have been implemented.
9.2 Circuit Switched Networks
9.2 Circuit Switched Networks
Many adaptive routing concepts have been proposed for circuit- switched networks. An example of a simple adaptive routing scheme is sequential alternate routing [T88]. This is a hop-by-hop destination-based routing scheme where only local state information is utilized. Under this scheme, a routing table is computed for each node, which lists multiple output link choices for each destination. When a call set-up request is received by a node, it tries each output link choice in sequence, until it finds one that can accommodate the call. Resources are reserved on this link, and the call set-up is forwarded to the next node. The set-up either reaches the destination, or is blocked at some node. In the latter case, the
Many adaptive routing concepts have been proposed for circuit- switched networks. An example of a simple adaptive routing scheme is sequential alternate routing [T88]. This is a hop-by-hop destination-based routing scheme where only local state information is utilized. Under this scheme, a routing table is computed for each node, which lists multiple output link choices for each destination. When a call set-up request is received by a node, it tries each output link choice in sequence, until it finds one that can accommodate the call. Resources are reserved on this link, and the call set-up is forwarded to the next node. The set-up either reaches the destination, or is blocked at some node. In the latter case, the
Crawley, et. al. Informational [Page 25] RFC 2386 A Framework for QoS-based Routing August 1998
Crawley, et. al. Informational [Page 25] RFC 2386 A Framework for QoS-based Routing August 1998
set-up can be cranked back to the previous node or a failure declared. Crankback allows the previous node to try an alternate path. The routing table under this scheme can be computed in a centralized or distributed manner, based only on the topology of the network. For instance, a k-shortest-path algorithm can be used to determine k alternate paths from a node with distinct initial links [T88]. Some mechanism must be implemented during path computation or call set-up to prevent looping.
set-up can be cranked back to the previous node or a failure declared. Crankback allows the previous node to try an alternate path. The routing table under this scheme can be computed in a centralized or distributed manner, based only on the topology of the network. For instance, a k-shortest-path algorithm can be used to determine k alternate paths from a node with distinct initial links [T88]. Some mechanism must be implemented during path computation or call set-up to prevent looping.
Performance studies of this scheme illustrate some of the pitfalls of alternate routing in general, and crankback in particular [A84, M86, YS87]. Specifically, alternate routing improves the throughput when traffic load is relatively light, but adversely affects the performance when traffic load is heavy. Crankback could further degrade the performance under these conditions. In general, uncontrolled alternate routing (with or without crankback) can be harmful in a heavily utilized network, since circuits tend to be routed along longer paths thereby utilizing more capacity. This is an obvious, but important result that applies to QoS-based Internet routing also.
Performance studies of this scheme illustrate some of the pitfalls of alternate routing in general, and crankback in particular [A84, M86, YS87]. Specifically, alternate routing improves the throughput when traffic load is relatively light, but adversely affects the performance when traffic load is heavy. Crankback could further degrade the performance under these conditions. In general, uncontrolled alternate routing (with or without crankback) can be harmful in a heavily utilized network, since circuits tend to be routed along longer paths thereby utilizing more capacity. This is an obvious, but important result that applies to QoS-based Internet routing also.
The problem with alternate routing is that both direct routed (i.e., over shortest paths) and alternate routed calls compete for the same resource. At higher loads, allocating these resources to alternate routed calls result in the displacement of direct routed calls and hence the alternate routing of these calls. Therefore, many approaches have been proposed to limit the flow of alternate routed calls under high traffic loads. These schemes are designed for the fully-connected logical topology of long distance telephone networks (i.e., there is a logical link between every pair of nodes). In this topology, direct routed calls always traverse a 1-hop path to the destination and alternate routed calls traverse at most a 2-hop path.
The problem with alternate routing is that both direct routed (i.e., over shortest paths) and alternate routed calls compete for the same resource. At higher loads, allocating these resources to alternate routed calls result in the displacement of direct routed calls and hence the alternate routing of these calls. Therefore, many approaches have been proposed to limit the flow of alternate routed calls under high traffic loads. These schemes are designed for the fully-connected logical topology of long distance telephone networks (i.e., there is a logical link between every pair of nodes). In this topology, direct routed calls always traverse a 1-hop path to the destination and alternate routed calls traverse at most a 2-hop path.
"Trunk reservation" is a scheme whereby on each link a certain bandwidth is reserved for direct routed calls [MS91]. Alternate routed calls are allowed on a trunk as long as the remaining trunk bandwidth is greater than the reserved capacity. Thus, alternate routed calls cannot totally displace direct routed calls on a trunk. This strategy has been shown to be very effective in preventing the adverse effects of alternate routing.
"Trunk reservation" is a scheme whereby on each link a certain bandwidth is reserved for direct routed calls [MS91]. Alternate routed calls are allowed on a trunk as long as the remaining trunk bandwidth is greater than the reserved capacity. Thus, alternate routed calls cannot totally displace direct routed calls on a trunk. This strategy has been shown to be very effective in preventing the adverse effects of alternate routing.
"Dynamic alternate routing" (DAR) is a strategy whereby alternate routing is controlled by limiting the number of choices, in addition to trunk reservation [MS91]. Under DAR, the source first attempts to use the direct link to the destination. When blocked, the source attempts to alternate route the call via a pre-selected neighbor. If the call is still blocked, a different neighbor is selected for alternate routing to this destination in the future. The present call
"Dynamic alternate routing" (DAR) is a strategy whereby alternate routing is controlled by limiting the number of choices, in addition to trunk reservation [MS91]. Under DAR, the source first attempts to use the direct link to the destination. When blocked, the source attempts to alternate route the call via a pre-selected neighbor. If the call is still blocked, a different neighbor is selected for alternate routing to this destination in the future. The present call
Crawley, et. al. Informational [Page 26] RFC 2386 A Framework for QoS-based Routing August 1998
Crawley, et. al. Informational [Page 26] RFC 2386 A Framework for QoS-based Routing August 1998
is dropped. DAR thus requires only local state information. Also, it "learns" of good alternate paths by random sampling and sticks to them as long as possible.
is dropped. DAR thus requires only local state information. Also, it "learns" of good alternate paths by random sampling and sticks to them as long as possible.
More recent circuit-switched routing schemes utilize global state to select routes for calls. An example is AT&T's Real-Time Network Routing (RTNR) scheme [ACFH92]. Unlike schemes like DAR, RTNR handles multiple classes of service, including voice and data at fixed rates. RTNR utilizes a sophisticated per-class trunk reservation mechanism with dynamic bandwidth sharing between classes. Also, when alternate routing a call, RTNR utilizes the loading on all trunks in the network to select a path. Because of the fully-connected topology, disseminating status information is simple under RTNR; each node simply exchanges status information directly with all others.
More recent circuit-switched routing schemes utilize global state to select routes for calls. An example is AT&T's Real-Time Network Routing (RTNR) scheme [ACFH92]. Unlike schemes like DAR, RTNR handles multiple classes of service, including voice and data at fixed rates. RTNR utilizes a sophisticated per-class trunk reservation mechanism with dynamic bandwidth sharing between classes. Also, when alternate routing a call, RTNR utilizes the loading on all trunks in the network to select a path. Because of the fully-connected topology, disseminating status information is simple under RTNR; each node simply exchanges status information directly with all others.
From the point of view of designing QoS-based Internet routing schemes, there is much to be learned from circuit-switched routing. For example, alternate routing and its control, and dynamic resource sharing among different classes of traffic. It is, however, not simple to apply some of the results to a general topology network with heterogeneous multirate traffic. Work in the area of ATM network routing described next illustrates this.
From the point of view of designing QoS-based Internet routing schemes, there is much to be learned from circuit-switched routing. For example, alternate routing and its control, and dynamic resource sharing among different classes of traffic. It is, however, not simple to apply some of the results to a general topology network with heterogeneous multirate traffic. Work in the area of ATM network routing described next illustrates this.
9.3 ATM Networks
9.3 ATM Networks
The VC routing problem in ATM networks presents issues similar to that encountered in circuit-switched networks. Not surprisingly, some extensions of circuit-switched routing have been proposed. The goal of these routing schemes is to achieve higher throughput as compared to traditional shortest-path routing. The flows considered usually have a single QoS requirement, i.e., bandwidth.
The VC routing problem in ATM networks presents issues similar to that encountered in circuit-switched networks. Not surprisingly, some extensions of circuit-switched routing have been proposed. The goal of these routing schemes is to achieve higher throughput as compared to traditional shortest-path routing. The flows considered usually have a single QoS requirement, i.e., bandwidth.
The first idea is to extend alternate routing with trunk reservation
to general topologies [SD95]. Under this scheme, a distance vector
routing protocol is used to build routing tables at each node with
multiple choices of increasing hop count to each destination. A VC
set-up is first routed along the primary ("direct") path. If
sufficient resources are not available along this path, alternate
paths are tried in the order of increasing hop count. A flag in the
VC set-up message indicates primary or alternate routing, and
bandwidth on links along an alternate path is allocated subject to
trunk reservation. The trunk reservation values are determined based
on some assumptions on traffic characteristics. Because the scheme
works only for a single data rate, the practical utility of it is
limited.
The first idea is to extend alternate routing with trunk reservation to general topologies [SD95]. Under this scheme, a distance vector routing protocol is used to build routing tables at each node with multiple choices of increasing hop count to each destination. A VC set-up is first routed along the primary ("direct") path. If sufficient resources are not available along this path, alternate paths are tried in the order of increasing hop count. A flag in the VC set-up message indicates primary or alternate routing, and bandwidth on links along an alternate path is allocated subject to trunk reservation. The trunk reservation values are determined based on some assumptions on traffic characteristics. Because the scheme works only for a single data rate, the practical utility of it is limited.
The next idea is to import the notion of controlled alternate routing into traditional link state QoS-based routing [GKR96]. To do this,
The next idea is to import the notion of controlled alternate routing into traditional link state QoS-based routing [GKR96]. To do this,
Crawley, et. al. Informational [Page 27] RFC 2386 A Framework for QoS-based Routing August 1998
Crawley, et. al. Informational [Page 27] RFC 2386 A Framework for QoS-based Routing August 1998
first each VC is associated with a maximum permissible routing cost. This cost can be set based on expected revenues in carrying the VC or simply based on the length of the shortest path to the destination. Each link is associated with a metric that increases exponentially with its utilization. A switch computing a path for a VC simply determines a least-cost feasible path based on the link metric and the VC's QoS requirement. The VC is admitted if the cost of the path is less than or equal to the maximum permissible routing cost. This routing scheme thus limits the extent of "detour" a VC experiences, thus preventing excessive resource consumption. This is a practical scheme and the basic idea can be extended to hierarchical routing. But the performance of this scheme has not been analyzed thoroughly. A similar notion of admission control based on the connection route was also incorporated in a routing scheme presented in [ACG92].
first each VC is associated with a maximum permissible routing cost. This cost can be set based on expected revenues in carrying the VC or simply based on the length of the shortest path to the destination. Each link is associated with a metric that increases exponentially with its utilization. A switch computing a path for a VC simply determines a least-cost feasible path based on the link metric and the VC's QoS requirement. The VC is admitted if the cost of the path is less than or equal to the maximum permissible routing cost. This routing scheme thus limits the extent of "detour" a VC experiences, thus preventing excessive resource consumption. This is a practical scheme and the basic idea can be extended to hierarchical routing. But the performance of this scheme has not been analyzed thoroughly. A similar notion of admission control based on the connection route was also incorporated in a routing scheme presented in [ACG92].
Considering the ATM Forum PNNI protocol [PNNI96], a partial list of its stated characteristics are as follows:
Considering the ATM Forum PNNI protocol [PNNI96], a partial list of its stated characteristics are as follows:
o Scales to very large networks
o Supports hierarchical routing
o Supports QoS
o Uses source routed connection setup
o Supports multiple metrics and attributes
o Provides dynamic routing
o Scales to very large networks o Supports hierarchical routing o Supports QoS o Uses source routed connection setup o Supports multiple metrics and attributes o Provides dynamic routing
The PNNI specification is sub-divided into two protocols: a signaling and a routing protocol. The PNNI signaling protocol is used to establish point-to-point and point to multipoint connections and supports source routing, crankback and alternate routing. PNNI source routing allows loop free paths. Also, it allows each implementation to use its own path computation algorithm. Furthermore, source routing is expected to support incremental deployment of future enhancements such as policy routing.
The PNNI specification is sub-divided into two protocols: a signaling and a routing protocol. The PNNI signaling protocol is used to establish point-to-point and point to multipoint connections and supports source routing, crankback and alternate routing. PNNI source routing allows loop free paths. Also, it allows each implementation to use its own path computation algorithm. Furthermore, source routing is expected to support incremental deployment of future enhancements such as policy routing.
The PNNI routing protocol is a dynamic, hierarchical link state protocol that propagates topology information by flooding it through the network. The topology information is the set of resources (e.g., nodes, links and addresses) which define the network. Resources are qualified by defined sets of metrics and attributes (delay, available bandwidth, jitter, etc.) which are grouped by supported traffic class. Since some of the metrics used will change frequently, e.g., available bandwidth, threshold algorithms are used to determine if the change in a metric or attribute is significant enough to require propagation of updated information. Other features include, auto configuration of the routing hierarchy, connection admission control (as part of path calculation) and aggregation and summarization of topology and reachability information.
PNNIルーティング・プロトコルはネットワークを通してそれをあふれさせることによってトポロジー情報を伝播するダイナミックで、階層的なリンク州のプロトコルです。 トポロジー情報はネットワークを定義するリソース(例えば、ノード、リンク、およびアドレス)のセットです。 支持された交通のクラスが構成されている定義されたセットの測定基準と属性(遅れ、利用可能な帯域幅、ジターなど)によってリソースは資格があります。 使用される測定基準のいくつかが頻繁、例えば利用可能な帯域幅を変えるので、敷居アルゴリズムはaのメートル法の変化か属性がアップデートされた情報の伝播を必要とすることができるくらい重要であるかどうか決定するのに使用されます。 もう一方はインクルード、トポロジーと可到達性情報のルーティング階層構造、接続許可制御(経路計算の一部としての)、集合、および総括の自動構成を特徴とします。
Crawley, et. al. Informational [Page 28] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[28ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
Despite its functionality, the PNNI routing protocol does not address the issues of multicast routing, policy routing and control of alternate routing. A problem in general with link state QoS-based routing is that of efficient broadcasting of state information. While flooding is a reasonable choice with static link metrics it may impact the performance adversely with dynamic metrics.
機能性にもかかわらず、PNNIルーティング・プロトコルは迂回中継のマルチキャストルーティング、方針ルーティング、およびコントロールの問題を記述しません。 一般に、ルーティングがリンク状態がQoSを拠点としている、州の情報の効率的な放送のものであるのにおける問題。 スタティック・リンク測定基準で氾濫は正当な選択ですが、それはダイナミックな測定基準と共に性能に逆に影響を与えるかもしれません。
Finally, Integrated PNNI [I-PNNI] has been designed from the start to take advantage of the QoS Routing capabilities that are available in PNNI and integrate them with routing for layer 3. This would provide an integrated layer 2 and layer 3 routing protocol for networks that include PNNI in the ATM core. The I-PNNI specification has been under development in the ATM Forum and, at this time, has not yet incorporated QoS routing mechanisms for layer 3.
最終的に、Integrated PNNI[I-PNNI]は、PNNIで利用可能なQoSルート設定能力を利用して、層3のためにそれらをルーティングと統合するように始めから設計されます。 これは統合層2と層3のルーティング・プロトコルをATMコアにPNNIを含んでいるネットワークに提供するでしょう。 I-PNNI仕様は、ATM Forumで開発中であり、このとき、層3のためにしかし、法人組織のQoSルーティングメカニズムを持っていません。
9.4 Packet Networks
9.4 パケット網
Early attempts at adaptive routing in packet networks had the objective of delay minimization by dynamically adapting to network congestion. Alternate routing based on k-shortest path tables, with route selection based on some local measure (e.g., shortest output queue) has been described [R76, YS81]. The original ARPAnet routing scheme was a distance vector protocol with delay-based cost metric [MW77]. Such a scheme was shown to be prone to route oscillations [B82]. For this and other reasons, a link state delay-based routing scheme was later developed for the ARPAnet [MRR80]. This scheme demonstrated a number of techniques such as triggered updates, flooding, etc., which are being used in OSPF and PNNI routing today. Although none of these schemes can be called QoS-based routing schemes, they had features that are relevant to QoS-based routing.
パケット網における最適経路指定への早めの試みには、遅れ最小化の目的が、ダイナミックにネットワークの混雑に順応することによって、ありました。 k-最短パステーブルに基づく迂回中継、何らかの地方の測定に基づくルート選択で、(例えば、最も短い出力キュー)は説明されます[R76、YS81]。 オリジナルのARPAnetルーティング計画は遅れベースの費用がメートル法であることでの距離ベクトルプロトコル[MW77]でした。 そのような計画は、振動[B82]を発送する傾向があるように示されました。 これと他の理由、リンク状態において、遅れベースのルーティング計画は後でARPAnet[MRR80]のために開発されました。 この計画は引き起こされたアップデート、今日OSPFとPNNIルーティングで使用されている氾濫などの多くのテクニックを示しました。 これらの計画のどれかをQoSベースのルーティング計画と呼ぶことができませんでしたが、それらには、QoSベースのルーティングに関連している特徴がありました。
IBM's System Network Architecture (SNA) introduced the concept of Class of Service (COS)-based routing [A79, GM79]. There were several classes of service: interactive, batch, and network control. In addition, users could define other classes. When starting a data session an application or device would request a COS. Routing would then map the COS into a statically configured route which marked a path across the physical network. Since SNA is connection oriented, a session was set up along this path and the application's or device's data would traverse this path for the life of the session. Initially, the service delivered to a session was based on the network engineering and current state of network congestion. Later, transmission priority was added to subarea SNA. Transmission priority allowed more important traffic (e.g. interactive) to proceed before less time-critical traffic (e.g. batch) and improved link and network utilization. Transmission priority of a session was based on its COS.
IBMのSystem Network Architecture(SNA)はServiceの(COS)ベースのルーティング[A79、GM79]のClassの概念を紹介しました。 数人のクラスのサービスがあります: インタラクティブ、バッチ、およびネットワークは制御されます。 さらに、ユーザは他のクラスを定義できました。 データセッションを始めるとき、アプリケーションか装置がCOSを要求するでしょう。 そして、ルート設定は物理ネットワークの向こう側に経路を示した静的に構成されたルートにCOSを写像するでしょう。 SNAが接続指向しているので、セッションはこの経路に沿って準備させられました、そして、アプリケーションか装置のデータはこの経路をセッションの人生に横断するでしょう。 初めは、セッションまで提供されたサービスはネットワークの混雑のネットワーク工学と現状に基づきました。 その後、トランスミッション優先権は「副-領域」SNAに追加されました。 トランスミッション優先権は、より重要な交通(例えば、インタラクティブ)が、より少ない時間批判的な交通(例えば、バッチ)の前に続くのを許容して、リンクとネットワーク利用を改良しました。 セッションのトランスミッション優先権はCOSに基づきました。
Crawley, et. al. Informational [Page 29] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[29ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
SNA later evolved to support multiple or alternate paths between nodes. But, although assisted by network design tools, the network administrator still had to statically configure routes. IBM later introduced SNA's Advanced Peer to Peer Networking (APPN) [B85]. APPN added new features to SNA including dynamic routing based on a link state database. An application would use COS to indicate it traffic requirements and APPN would calculate a path capable of meeting these requirements. Each COS was mapped to a table of acceptable metrics and parameters that qualified the nodes and links contained in the APPN topology Database. Metrics and parameters used as part of the APPN route calculation include, but are not limited to: delay, cost per minute, node congestion and security. The dynamic nature of APPN allowed it to route around failures and reduce network configuration.
SNAは、後でノードの間の複数の、または、交互の経路を支持するために発展しました。 しかし、ネットワークデザインツールによって補助されましたが、ネットワーク管理者はまだ静的にルートを構成しなければなりませんでした。 IBMは後でPeer Networking(APPN)[B85]にSNAのAdvanced Peerを紹介しました。 APPNはリンク州のデータベースに基づくダイナミックルーティングを含むSNAに新機能を追加しました。 アプリケーションは、要件を取引して、APPNがこれらの必要条件を満たすことができる経路について計算するのを示すのにCOSを使用するでしょう。 各COSはAPPNトポロジーDatabaseに含まれたノードとリンクに資格を与えた許容できる測定基準とパラメタのテーブルに写像されました。 含んでいますが、APPNルート計算の一部として中古の測定基準とパラメタは制限されません: 1分あたりの費用にノード混雑とセキュリティを遅らせてください。 APPNのダイナミックな自然は、失敗の周りのルートにそれを許容して、ネットワーク・コンフィギュレーションを変えます。
The service delivered by APPN was still based on the network engineering, transmission priority and network congestion. IBM later introduced an extension to APPN, High Performance Routing (HPR)[IBM97]. HPR uses a congestion avoidance algorithm called adaptive rate based (ARB) congestion control. Using predictive feedback methods, the ARB algorithm prevents congestion and improves network utilization. Most recently, an extension to the COS table has been defined so that HPR routing could recognize and take advantage of ATM QoS capabilities.
APPNによって提供されたサービスはまだネットワーク工学、トランスミッション優先権、およびネットワークの混雑に基づいていました。 IBMは後でAPPN、Highパフォーマンスルート設定(HPR)[IBM97]に拡大を紹介しました。 HPRはベースの輻輳回避アルゴリズム呼ばれた適応型の率に(ARB)輻輳制御を使用します。 予言のフィードバック方法を使用して、ARBアルゴリズムは、混雑を防いで、ネットワーク利用を改良します。 ごく最近、COSテーブルへの拡大は、HPRルーティングがATM QoS能力を認識して、利用できるように、定義されました。
Considering IP routing, both IDRP [R92] and OSPF support type of service (TOS)-based routing. While the IP header has a TOS field, there is no standardized way of utilizing it for TOS specification and routing. It seems possible to make use of the IP TOS feature, along with TOS-based routing and proper network engineering, to do QoS-based routing. The emerging differentiated services model is generating renewed interest in TOS support. Among the newer schemes, Source Demand Routing (SDR) [ELRV96] allows on-demand path computation by routers and the implementation of strict and loose source routing. The Nimrod architecture [CCM96] has a number of concepts built in to handle scalability and specialized path computation. Recently, some work has been done on QoS-based routing schemes for the integrated services Internet. For example, in [M98], heuristic schemes for efficient routing of flows with bandwidth and/or delay constraints is described and evaluated.
IPルーティング、IDRP[R92]とサービスのOSPFサポートタイプの両方が(TOS)ベースのルーティングであると考えます。 IPヘッダーには、TOS分野がありますが、それを利用する標準化された方法は全くTOS仕様とルーティングのためにありません。 IP TOSの特徴を利用するのは可能に思えます、QoSベースのルーティングをするためにTOSベースのルーティングと適切なネットワーク工学と共に。 現れている微分されたサービスモデルはTOSサポートへの更新された関心を呼んでいます。 より新しい計画の中では、Source Demandルート設定(SDR)[ELRV96]は厳しくてゆるいソースルーティングのルータと実現で要求次第の経路計算を許します。 ニムロデ構造[CCM96]で、スケーラビリティと専門化している経路計算を扱うために多くの概念を築き上げます。 最近、統合サービスインターネットのQoSベースのルーティング計画でいくらかの仕事をしました。 例えば、[M98]では、帯域幅に伴う流れ、そして/または、遅れ規制の効率的なルーティングの発見的な計画は、説明されて、評価されます。
9. SUMMARY AND CONCLUSIONS
9. 概要AND結論
In this document, a framework for QoS-based Internet routing was defined. This framework adopts the traditional separation between intra and interdomain routing. This approach is especially meaningful in the case of QoS-based routing, since there are many views on how QoS-based routing should be accomplished and many different needs. The objective of this document was to encourage the development of
本書では、QoSベースのインターネット・ルーティングのための枠組みは定義されました。 この枠組みはイントラとinterdomainルーティングの間の伝統的な分離を採用します。 このアプローチはQoSベースのルーティングの場合で特に重要です、QoSベースのルーティングがどう優れていて多くの異なった必要性であるべきであるかに関する多くの意見があるので。 ドキュメントが開発を奨励することになっていたこの目的
Crawley, et. al. Informational [Page 30] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[30ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
different solution approaches for intradomain routing, subject to some broad requirements, while consensus on interdomain routing is achieved. To this end, the QoS-based routing issues were described, and some broad intradomain routing requirements and an interdomain routing model were defined. In addition, QoS-based multicast routing was discussed and a detailed review of related work was presented.
interdomainルーティングに関するコンセンサスは達成されますが、異なった解決策にいくつかの広い要件を条件としたintradomainルーティングのためにアプローチします。 このために、QoSベースのルーティング問題は説明されました、そして、いくつかの広いintradomainルーティング要件とinterdomainルーティングモデルは定義されました。 さらに、QoSベースのマルチキャストルーティングについて議論しました、そして、関連する仕事の詳細なレビューは提示されました。
The deployment of QoS-based routing across multiple administrative domains requires both the development of intradomain routing schemes and a standard way for them to interact via a well-defined interdomain routing mechanism. This document, while outlining the issues that must be addressed, did not engage in the specification of the actual features of the interdomain routing scheme. This would be the next step in the evolution of wide-area, multidomain QoS-based routing.
複数の管理ドメイン中のQoSベースのルーティングの展開はintradomainルーティング計画の開発と明確なinterdomainルーティングメカニズムで相互作用する標準の方法の両方を必要とします。 このドキュメントは記述しなければならない問題について概説している間、interdomainルーティング計画の実際の特徴の仕様に従事していませんでした。 これは広い領域の、そして、multidomain QoSベースのルーティングの発展で次のステップでしょう。
REFERENCES
参照
[A79] V. Ahuja, "Routing and Flow Control in SNA", IBM Systems
Journal, 18 No. 2, pp. 298-314, 1979.
Ahujaに対する[A79]と、「SNAによるルート設定とフロー制御」、IBM Systems Journal、18No.、2、ページ 298-314, 1979.
[A84] J. M. Akinpelu, "The Overload Performance of Engineered
Networks with Non-Hierarchical Routing", AT&T Technical
Journal, Vol. 63, pp. 1261-1281, 1984.
[A84]J.M.Akinpelu、「非階層型ルーティングとの設計されたネットワークのオーバーロードパフォーマンス」、AT&T Technical Journal、Vol.63、ページ 1261-1281, 1984.
[ACFH92] G. R. Ash, J. S. Chen, A. E. Frey and B. D. Huang, "RealTime
Network Routing in a Dynamic Class-of-Service Network",
Proceedings of ITC 13, 1992.
[ACFH92]G.R.灰とJ.S.チェンとA.E.フレイとB.D.ホアン、「ダイナミックなサービスのクラスネットワークにおけるリアルタイムでネットワークルート設定」、ITC13、1992年の議事。
[ACG92] H. Ahmadi, J. Chen, and R. Guerin, "Dynamic Routing and Call
Control in High-Speed Integrated Networks", Proceedings of
ITC-13, pp. 397-403, 1992.
[ACG92] H.Ahmadi、J.チェン、およびR.ゲラン、「ダイナミックルーティングと呼び出しは中で高速統合ネットワークを制御する」ITC-13、ページのProceedings 397-403, 1992.
[B82] D. P. Bertsekas, "Dynamic Behavior of Shortest Path Routing
Algorithms for Communication Networks", IEEE Trans. Auto.
Control, pp. 60-74, 1982.
[B82]D.P.Bertsekas、「通信ネットワークのための最短パスルーティング・アルゴリズムの動的挙動」、IEEE、移- 自動。 コントロール、ページ 60-74, 1982.
[B85] A. E. Baratz, "SNA Networks of Small Systems", IEEE JSAC,
May, 1985.
[B85]A.E.Baratz、「小さいシステムのSNAネットワーク」、IEEE JSAC、1985年5月。
[BBCD98] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z., and
W. Weiss, "An Architecture for Differentiated Services",
Work in Progress.
[BBCD98]は黒くします、D.、ブレーク、S.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「微分されたサービスのための構造」処理中の作業。
[BCCH94] Braden, R., Clark, D., Crocker, D., and C. Huitema, "Report
of IAB Workshop on Security in the Internet Architecture",
RFC 1636, June 1994.
[BCCH94] ブレーデン、R.、クラーク、D.、クロッカー、D.、およびC.Huitema、「インターネット構造におけるセキュリティに関するIABワークショップのレポート」、RFC1636(1994年6月)。
Crawley, et. al. Informational [Page 31] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[31ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
[BCF94] A. Ballardie, J. Crowcroft and P. Francis, "Core-Based
Trees: A Scalable Multicast Routing Protocol", Proceedings
of SIGCOMM `94.
[BCF94] A.Ballardie、J.クロウクロフト、およびP.フランシス、「コアベースの木:」 「スケーラブルなマルチキャストルーティング・プロトコル」、SIGCOMM94年の議事。
[BCS94] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: An Overview", RFC 1633, July
1994.
[BCS94] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネット構造における統合サービス:」 「概観」、RFC1633、1994年7月。
[BZ92] S. Bahk and M. El Zarki, "Dynamic Multi-Path Routing and How
it Compares with Other Dynamic Routing Algorithms for High
Speed Wide Area Networks", Proc. SIGCOMM `92, pp. 53-64,
1992.
[BZ92] S.BahkとM.El Zarki、「ダイナミックなMulti-経路ルート設定とHow、それ、High SpeedワイドエリアネットワークのためのOther Dynamicルート設定AlgorithmsとCompares、」、Proc。 SIGCOMM92年、ページ 53-64, 1992.
[BZBH97] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Spec", RFC 2205, September 1997.
[BZBH97] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[C91] C-H. Chow, "On Multicast Path Finding Algorithms",
Proceedings of the IEEE INFOCOM `91, pp. 1274-1283, 1991.
[C91]C-H。 チャウ、「マルチキャスト経路調査結果アルゴリズム」、IEEE INFOCOM91年のProceedings、ページ 1274-1283, 1991.
[CCM96] Castineyra, I., Chiappa, J., and M. Steenstrup, "The Nimrod
Routing Architecture", RFC 1992, August 1996.
1996年8月の[CCM96]CastineyraとI.とChiappa、J.とM.ステーンストルプ、「ニムロデルート設定構造」RFC1992。
[DEFV94] S. E. Deering, D. Estrin, D. Farinnacci, V. Jacobson, C-G.
Liu, and L. Wei, "An Architecture for Wide-Area Multicast
Routing", Technical Report, 94-565, ISI, University of
Southern California, 1994.
[DEFV94] S.E.デアリング、D.Estrin、D.Farinnacci対ジェーコブソン、C-G リュウ、およびL.ウェイ、「広い領域マルチキャストルート設定のための構造」、技術報告書、94-565、ISI、南カリフォルニア大学、1994。
[ELRV96] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
Zappala, "Source Demand Routing: Packet Format and
Forwarding Specification (Version 1)", RFC 1940, May 1996.
[ELRV96] Estrin、D.、李、T.、Rekhter、Y.、Varadhan、K.、およびD.Zappala、「以下を掘るソース要求」 「パケット・フォーマットと推進仕様(バージョン1)」(RFC1940)は1996がそうするかもしれません。
[GKR96] R. Gawlick, C. R. Kalmanek, and K. G. Ramakrishnan, "On-Line
Routing of Permanent Virtual Circuits", Computer
Communications, March, 1996.
1996年3月の[GKR96]R.Gawlick、C.R.KalmanekとK.G.Ramakrishnan、「相手固定接続のオンラインルート設定」コンピュータコミュニケーション。
[GPSS98] A. Ghanwani, J. W. Pace, V. Srinivasan, A. Smith and M.
Seaman, "A Framework for Providing Integrated Services over
Shared and Switched IEEE 802 LAN Technologies", Work in
Progress.
「共有されて切り換えられたIEEE802LAN技術の上に統合サービスを提供するための枠組み」という[GPSS98]A.Ghanwani、J.W.ペース、V.Srinivasan、A.スミス、およびM.船員は進行中で働いています。
[GM79] J. P. Gray, T. B. McNeil, "SNA Multi-System Networking", IBM
Systems Journal, 18 No. 2, pp. 263-297, 1979.
[GM79]J.P.グレー、T.B.マクニール、「SNAマルチシステムネットワーク」、IBM Systems Journal、18No.、2、ページ 263-297, 1979.
[GOA97] Y. Goto, M. Ohta and K. Araki, "Path QoS Collection for
Stable Hop-by-Hop QoS Routing", Proc. INET '97, June, 1997.
[GOA97] Y.ゴトーとM.太田とK.荒木、「ホップごとの安定したQoSルート設定のための経路QoS収集」、Proc。 1997年6月のINET97年。
Crawley, et. al. Informational [Page 32] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[32ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
[GKOP98] R. Guerin, S. Kamat, A. Orda, T. Przygienda, and D.
Williams, "QoS Routing Mechanisms and OSPF extensions", work
in progress, March, 1998.
[GKOP98] R.ゲランとS.KamatとA.オルダ、T.Przygiendaとウィリアムズと、「QoSルート設定MechanismsとOSPF拡張子」が進行中で扱うD.、1998年3月。
[IBM97] IBM Corp, SNA APPN - High Performance Routing Architecture
Reference, Version 2.0, SV40-1018, February 1997.
[IBM97] IBM Corp、SNA APPN--高性能ルート設定構造参照、バージョン2.0、SV40-1018、1997年2月。
[IPNNI] ATM Forum Technical Committee. Integrated PNNI (I-PNNI) v1.0
Specification. af-96-0987r1, September 1996.
[IPNNI]気圧フォーラム専門委員会。 1996年9月の統合PNNI(I-PNNI)v1.0 Specification. af-96-0987r1。
[ISI81] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[ISI81] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[JMW83] J. M. Jaffe, F. H. Moss, R. A. Weingarten, "SNA Routing:
Past, Present, and Possible Future", IBM Systems Journal,
pp. 417-435, 1983.
[JMW83]J.M.ジャフィー、F.H.こけ、R.A.ヴェンガルデン、「以下を掘るSNA」 「過去、Present、およびPossible Future」、IBM Systems Journal、ページ 417-435, 1983.
[K88] F.P. Kelly, "Routing in Circuit-Switched Networks:
Optimization, Shadow Prices and Decentralization", Adv.
Applied Prob., pp. 112-144, March, 1988.
「回路交換ネットワークで以下を掘る」[K88]F.P.ケリー 「最適化、潜在価格、および分散」、副詞 適用されたProb、ページ 112-144と、1988年3月。
[L95] W. C. Lee, "Topology Aggregation for Hierarchical Routing in
ATM Networks", ACM SIGCOMM Computer Communication Review,
1995.
[L95]W.C.リー、「気圧ネットワークにおける階層型ルーティングのためのトポロジー集合」、ACM SIGCOMMコンピュータコミュニケーションレビュー、1995。
[M86] L. G. Mason, "On the Stability of Circuit-Switched Networks
with Non-hierarchical Routing", Proc. 25th Conf. On Decision
and Control, pp. 1345-1347, 1986.
[M86]L.G.メイスン、「非階層型ルーティングがある回路交換ネットワークの安定性」、Proc。 第25Conf。 DecisionとControl、ページに関して 1345-1347, 1986.
[M98] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[M98]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[M94] Moy, J., "MOSPF: Analysis and Experience", RFC 1585, March
1994.
[M94]Moy、J.、「MOSPF:」 「分析と経験」(RFC1585)は1994を行進させます。
[M98] Q. Ma, "Quality-of-Service Routing in Integrated Services
Networks", PhD thesis, Computer Science Department, Carnegie
Mellon University, 1998.
[M98]Q.マ、「統合サービスネットワークにおけるサービスの質ルート設定」、博士論文、コンピュータ理学部、カーネギメロン大学、1998。
[MMR96] D. Mitra, J. Morrison, and K. G. Ramakrishnan, "ATM Network
Design and Optimization: A Multirate Loss Network
Framework", Proceedings of IEEE INFOCOM `96, 1996.
[MMR96] D.ミトラ、J.モリソン、およびK.G.Ramakrishnan、「気圧はデザインと最適化をネットワークでつなぎます」。 「多速度損失ネットワーク枠組み」、IEEE INFOCOM1996 96年の議事。
[MRR80] J. M. McQuillan, I. Richer and E. C. Rosen, "The New Routing
Algorithm for the ARPANET", IEEE Trans. Communications, pp.
711-719, May, 1980.
[MRR80]J.M.マッキランとI.リシェとE.C.ローゼン、「アルパネットのための新しいルーティング・アルゴリズム」、IEEE、移- コミュニケーション、ページ 711-719と、1980年5月。
Crawley, et. al. Informational [Page 33] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[33ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
[MS91] D. Mitra and J. B. Seery, "Comparative Evaluations of
Randomized and Dynamic Routing Strategies for Circuit
Switched Networks", IEEE Trans. on Communications, pp. 102-
116, January, 1991.
Communications、ページの[MS91]D.ミトラとJ.B.Seery、「サーキット交換網のためのランダマイズされるのとダイナミックルーティング戦略の比較評価」(IEEE Trans) 102- 116と、1991年1月。
[MW77] J. M. McQuillan and D. C. Walden, "The ARPANET Design
Decisions", Computer Networks, August, 1977.
[MW77]J.M.マッキランとD.C.ウォルデン、「アルパネットデザイン決定」、コンピュータネットワーク、1977年8月。
[NC94] Nair, R. and Clemmensen, D. : "Routing in Integrated
Services Networks", Proc. 2nd International Conference on
Telecom. Systems Modeling and Analysis, March 1994.
[NC94] ナイアとR.とClemmensen、D.: 「統合サービスネットワークにおけるルート設定」、Proc。 テレコムに関する第2国際会議。 システムモデルと分析、1994年3月。
[P88] R. Perlman, "Network Layer Protocol with Byzantine
Robustness", Ph.D. Thesis, Dept. of EE and CS, MIT, August,
1988.
[P88]R.パールマンと「込み入った丈夫さがあるネットワーク層プロトコル」と博士ThesisとEEの部とCs、MIT、1988年8月。
[PNNI96] ATM Forum PNNI subworking group, "Private Network-Network
Interface Spec. v1.0 (PNNI 1.0)", afpnni-0055.00, March
1996.
1996年3月の[PNNI96]ATM Forum PNNI subworkingグループ、「個人的なNetwork-ネットワークInterface Spec. v1.0(PNNI1.0)」afpnni-0055.00。
[R76] H. Rudin, "On Routing and "Delta Routing": A Taxonomy and
Performance Comparison of Techniques for Packet-Switched
Networks", IEEE Trans. Communications, pp. 43-59, January,
1996.
[R76]H.ルーディン、「ルート設定と「デルタルート設定」に関して:、」 「パケット交換網のための分類学とパフォーマンス技術比較」、IEEE、移- コミュニケーション、ページ 43-59と、1996年1月。
[R92] Y. Rekhter, "IDRP Protocol Analysis: Storage Overhead", ACM
Comp. Comm. Review, April, 1992.
[R92]Y.Rekhter、「IDRPは分析について議定書の中で述べます」。 「格納オーバーヘッド」、ACMコンピュータ。 Comm。 1992年4月に、論評してください。
[R96] B. Rajagopalan, "Efficient Link State Routing", Work in
Progress, available from braja@ccrl.nj.nec.com.
[R96]B.Rajagopalan、「効率的なリンク州のルート設定」、Progressの braja@ccrl.nj.nec.com から利用可能なWork。
[RN98] B. Rajagopalan and R. Nair, "Multicast Routing with Resource
Reservation", to appear in J. of High Speed Networks, 1998.
[RN98]B.Rajagopalan R.ナイア、「資源予約とのマルチキャストルート設定」、High Speed Networks、1998年のJ.では、現れます。
[SD95] S. Sibal and A. Desimone, "Controlling Alternate Routing in
General-Mesh Packet Flow Networks", Proceedings of ACM
SIGCOMM, 1995.
[SD95] S.SibalとA.Desimone、「一般に、かみ合っているパケット流動がネットワークでつなぐ迂回中継を制御します」、ACM SIGCOMM、1995年の議事。
[SPG97] Shenker, S., Partridge, C., and R. Guerin, "Specification of
Guaranteed Quality of Service", RFC 2212, September 1997.
1997年9月の[SPG97]ShenkerとS.とヤマウズラ、C.とR.ゲラン、「保証されたサービスの質の仕様」RFC2212。
[T88] D. M. Topkis, "A k-Shortest-Path Algorithm for Adaptive
Routing in Communications Networks", IEEE Trans.
Communications, pp. 855-859, July, 1988.
[T88]D.M.Topkis、「通信網における最適経路指定のためのk-最短パスアルゴリズム」、IEEE、移- コミュニケーション、ページ 855-859と、1988年7月。
[W88] B. M. Waxman, "Routing of Multipoint Connections", IEEE
JSAC, pp. 1617-1622, December, 1988.
[W88]B.M.ワックスマン、「マルチポイント接続のルート設定」、IEEE JSAC、ページ 1617-1622と、1988年12月。
Crawley, et. al. Informational [Page 34] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[34ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
[W97] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[W97] Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
[WC96] Z. Wang and J. Crowcroft, "QoS Routing for Supporting
Resource Reservation", IEEE JSAC, September, 1996.
[WC96] Z.ワングとJ.クロウクロフト、「資源予約を支持するためのQoSルート設定」、IEEE JSAC、1996年9月。
[YS81] T. P. Yum and M. Schwartz, "The Join-Based Queue Rule and
its Application to Routing in Computer Communications
Networks", IEEE Trans. Communications, pp. 505-511, 1981.
[YS81] T.P.Yum、M.シュワルツ、および「ベースのJoin Queue RuleとコンピュータCommunications Networksのルート設定へのそのApplication」、IEEE Trans。 コミュニケーション、ページ 505-511, 1981.
[YS87] T. G. Yum and M. Schwartz, "Comparison of Routing Procedures
for Circuit-Switched Traffic in Nonhierarchical Networks",
IEEE Trans. Communications, pp. 535-544, May, 1987.
T. G. [YS87]おいしい、そして、M.シュワルツ、「Nonhierarchicalネットワークのサーキットで切り換えられた交通のためのルート設定手順の比較」、IEEE、移- コミュニケーション、ページ 535-544と、1987年5月。
[ZES97] Zappala, D., Estrin, D., and S. Shenker, "Alternate Path
Routing and Pinning for Interdomain Multicast Routing", USC
Computer Science Technical Report #97-655, USC, 1997.
[ZES97] Zappala、D.、Estrin、D.、およびS.Shenker、「経路ルート設定とInterdomainマルチキャストのためにルート設定をピンで止めるのを交替してください」、USCコンピュータサイエンス技術的であるというレポート#97-655、USC、1997。
[ZSSC97] Zhang, Z., Sanchez, C., Salkewicz, B., and E. Crawley, "QoS
Extensions to OSPF", Work in Progress.
Z.[ZSSC97]チャン、サンチェス、C.、Salkewicz、B.、およびE.クローリー、「OSPFへのQoS拡張子」は進行中で働いています。
Crawley, et. al. Informational [Page 35] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[35ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
AUTHORS' ADDRESSES
作者のアドレス
Bala Rajagopalan NEC USA, C&C Research Labs 4 Independence Way Princeton, NJ 08540 U.S.A
Bala Rajagopalan NEC米国、C、およびC研究研究室4独立Wayプリンストン(ニュージャージー)08540U.S.A
Phone: +1-609-951-2969 EMail: braja@ccrl.nj.nec.com
以下に電話をしてください。 +1-609-951-2969 メールしてください: braja@ccrl.nj.nec.com
Raj Nair Arrowpoint 235 Littleton Rd. Westford, MA 01886 U.S.A
主権ナイアArrowpoint235リトルトン通り ウェストフォード、MA01886U.S.A
Phone: +1-508-692-5875, x29 EMail: nair@arrowpoint.com
以下に電話をしてください。 +1-508-692-5875、x29 EMail: nair@arrowpoint.com
Hal Sandick Bay Networks, Inc. 1009 Slater Rd., Suite 220 Durham, NC 27703 U.S.A
ハルSandickベイネットワークスInc.1009スレーター通り、スイート220ダラム、NC27703U.S.A
Phone: +1-919-941-1739 EMail: Hsandick@baynetworks.com
以下に電話をしてください。 +1-919-941-1739 メールしてください: Hsandick@baynetworks.com
Eric S. Crawley Argon Networks, Inc. 25 Porter Rd. Littelton, MA 01460 U.S.A
エリックS.クローリーアルゴンはInc.25ポーター通りをネットワークでつなぎます。 Littelton、MA01460U.S.A
Phone: +1-508-486-0665 EMail: esc@argon.com
以下に電話をしてください。 +1-508-486-0665 メールしてください: esc@argon.com
Crawley, et. al. Informational [Page 36] RFC 2386 A Framework for QoS-based Routing August 1998
etクローリー、アル。 情報[36ページ]のRFC2386 QoSベースのルート設定1998年8月のための枠組み
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Crawley, et. al. Informational [Page 37]
etクローリー、アル。 情報[37ページ]
一覧
スポンサーリンク
