[要約] RFC 2430は、異なるサービスとトラフィックエンジニアリングのためのプロバイダアーキテクチャ（PASTE）に関するものであり、QoSの提供とネットワークリソースの効果的な利用を目的としています。
Network Working Group T. Li
Request for Comments: 2430 Juniper Networks
Category: Informational Y. Rekhter
Cisco Systems
October 1998
A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)
DiffServおよびトラフィックエンジニアリング（PASTE）のプロバイダーアーキテクチャ
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). Providing differentiated services in ISPs is a challenge because the scaling problems presented by the sheer number of flows present in large ISPs makes the cost of maintaining per-flow state unacceptable. Coupled with this, large ISPs need the ability to perform traffic engineering by directing aggregated flows of traffic along specific paths.
このドキュメントでは、インターネットサービスプロバイダー（ISP）向けの差別化サービスおよびトラフィックエンジニアリング（PASTE）のプロバイダーアーキテクチャについて説明します。大規模なISPに存在する膨大な数のフローによって生じるスケーリングの問題により、フローごとの状態を維持するためのコストが許容できないため、ISPで差別化されたサービスを提供することは困難です。これと相まって、大規模ISPは、特定のパスに沿ってトラフィックの集約されたフローを方向付けることにより、トラフィックエンジニアリングを実行する機能を必要とします。
PASTE addresses these issues by using Multiprotocol Label Switching (MPLS) [1] and the Resource Reservation Protocol (RSVP) [2] to create a scalable traffic management architecture that supports differentiated services. This document assumes that the reader has at least some familiarity with both of these technologies.
PASTEは、マルチプロトコルラベルスイッチング（MPLS）[1]とリソース予約プロトコル（RSVP）[2]を使用してこれらの問題に対処し、差別化されたサービスをサポートするスケーラブルなトラフィック管理アーキテクチャを作成します。このドキュメントは、読者がこれらのテクノロジーの両方に少なくともある程度精通していることを前提としています。
In common usage, a packet flow, or a flow, refers to a unidirectional stream of packets, distributed over time. Typically a flow has very fine granularity and reflects a single interchange between hosts, such as a TCP connection. An aggregated flow is a number of flows that share forwarding state and a single resource reservation along a sequence of routers.
一般的な使用法では、パケットフローまたはフローは、時間の経過とともに分散される、パケットの単方向ストリームを指します。通常、フローの粒度は非常に細かく、TCP接続などのホスト間の単一の交換が反映されます。集約されたフローは、ルーターのシーケンスに沿って転送状態と単一のリソース予約を共有する多数のフローです。
One mechanism for supporting aggregated flows is Multiprotocol Label Switching (MPLS). In MPLS, packets are tunneled by wrapping them in a minimal header [3]. Each such header contains a label, that carries both forwarding and resource reservation semantics. MPLS defines mechanisms to install label-based forwarding information along a series of Label Switching Routers (LSRs) to construct a Label Switched Path (LSP). LSPs can also be associated with resource reservation information.
集約フローをサポートするメカニズムの1つは、マルチプロトコルラベルスイッチング（MPLS）です。 MPLSでは、パケットは最小限のヘッダーでラップすることによってトンネリングされます[3]。このような各ヘッダーには、転送とリソース予約の両方のセマンティクスを伝えるラベルが含まれています。 MPLSは、一連のラベルスイッチングルータ（LSR）に沿ってラベルベースの転送情報をインストールして、ラベルスイッチドパス（LSP）を構築するメカニズムを定義します。 LSPは、リソース予約情報に関連付けることもできます。
One protocol for constructing such LSPs is the Resource Reservation Protocol (RSVP) [4]. When used with the Explicit Route Object (ERO) [5], RSVP can be used to construct an LSP along an explicit route [6].
そのようなLSPを構築するための1つのプロトコルは、リソース予約プロトコル（RSVP）[4]です。明示的ルートオブジェクト（ERO）[5]と共に使用すると、RSVPを使用して、明示的ルートに沿ってLSPを構築できます[6]。
To support differentiated services, packets are divided into separate traffic classes. For conceptual purposes, we will discuss three different traffic classes: Best Effort, Priority, and Network Control. The exact number of subdivisions within each class is to be defined.
差別化されたサービスをサポートするために、パケットは個別のトラフィッククラスに分割されます。概念的な目的のために、ベストエフォート、優先度、ネットワーク制御の3つの異なるトラフィッククラスについて説明します。各クラス内のサブディビジョンの正確な数が定義されます。
Network Control traffic primarily consists of routing protocols and network management traffic. If Network Control traffic is dropped, routing protocols can fail or flap, resulting in network instability. Thus, Network Control must have very low drop preference. However, Network Control traffic is generally insensitive to moderate delays and requires a relatively small amount of bandwidth. A small bandwidth guarantee is sufficient to insure that Network Control traffic operates correctly.
ネットワーク制御トラフィックは、主にルーティングプロトコルとネットワーク管理トラフィックで構成されます。ネットワーク制御トラフィックがドロップされると、ルーティングプロトコルが失敗またはフラップして、ネットワークが不安定になる可能性があります。したがって、ネットワーク制御は非常に低いドロップ優先度を持つ必要があります。ただし、ネットワーク制御トラフィックは通常、中程度の遅延の影響を受けず、必要な帯域幅は比較的少量です。ネットワーク制御トラフィックが正しく動作することを保証するには、小さな帯域幅保証で十分です。
Priority traffic is likely to come in many flavors, depending on the application. Particular flows may require bandwidth guarantees, jitter guarantees, or upper bounds on delay. For the purposes of this memo, we will not distinguish the subdivisions of priority traffic. All priority traffic is assumed to have an explicit resource reservation.
プライオリティトラフィックは、アプリケーションによっては、多くのフレーバーになる可能性があります。特定のフローでは、帯域幅の保証、ジッターの保証、または遅延の上限が必要になる場合があります。このメモの目的のために、優先トラフィックのサブディビジョンを区別しません。すべての優先トラフィックには、明示的なリソース予約があると想定されています。
Currently, the vast majority of traffic in ISPs is Best Effort traffic. This traffic is, for the most part, delay insensitive and reasonably adaptive to congestion.
現在、ISPのトラフィックの大部分はベストエフォートトラフィックです。このトラフィックは、ほとんどの場合、遅延の影響を受けず、輻輳に対して合理的に適応します。
When flows are aggregated according to their traffic class and then the aggregated flow is placed inside a LSP, we call the result a traffic trunk, or simply a trunk. The traffic class of a packet is orthogonal to the LSP that it is on, so many different trunks, each with its own traffic class, may share an LSP if they have different traffic classes.
フローがトラフィッククラスに従って集約され、集約されたフローがLSP内に配置される場合、その結果をトラフィックトランクまたは単にトランクと呼びます。パケットのトラフィッククラスは、パケットが置かれているLSPと直交しているため、それぞれ独自のトラフィッククラスを持つ多くの異なるトランクが、異なるトラフィッククラスを持っている場合はLSPを共有できます。
The next generation of the Internet presents special challenges that must be addressed by a single, coordinated architecture. While this architecture allows for distinction between ISPs, it also defines a framework within which ISPs may provide end-to-end differentiated services in a coordinated and reliable fashion. With such an architecture, an ISP would be able to craft common agreements for the handling of differentiated services in a consistent fashion, facilitating end-to-end differentiated services via a composition of these agreements. Thus, the goal of this document is to describe an architecture for providing differentiated services within the ISPs of the Internet, while including support for other forthcoming needs such as traffic engineering. While this document addresses the needs of the ISPs, its applicability is not limited to the ISPs. The same architecture could be used in any large, multiprovider catenet needing differentiated services.
次世代のインターネットは、単一の調整されたアーキテクチャーで対処しなければならない特別な課題を提示します。このアーキテクチャはISP間の区別を可能にしますが、ISPがエンドツーエンドの差別化されたサービスを調整された信頼できる方法で提供できるフレームワークも定義します。このようなアーキテクチャにより、ISPは、差別化されたサービスを一貫した方法で処理するための共通の合意を作成でき、これらの合意の構成を介してエンドツーエンドの差別化されたサービスを容易にします。したがって、このドキュメントの目的は、インターネットのISP内で差別化されたサービスを提供する一方で、トラフィックエンジニアリングなどの他の今後のニーズに対するサポートを含めたアーキテクチャについて説明することです。このドキュメントはISPのニーズに対応していますが、その適用範囲はISPに限定されません。同じアーキテクチャを、差別化されたサービスを必要とする大規模なマルチプロバイダーカテネットで使用できます。
This document only discusses unicast services. Extensions to the architecture to support multicast are a subject for future research.
このドキュメントでは、ユニキャストサービスについてのみ説明します。マルチキャストをサポートするためのアーキテクチャの拡張は、今後の研究の課題です。
One of the primary considerations in any ISP architecture is scalability. Solutions that have state growth proportional to the size of the Internet result in growth rates exceeding Moore's law, making such solutions intractable in the long term. Thus, solutions that use mechanisms with very limited growth rates are strongly preferred.
ISPアーキテクチャにおける主な考慮事項の1つは、スケーラビリティです。インターネットのサイズに比例した州の成長を伴うソリューションは、ムーアの法則を超える成長率をもたらし、そのようなソリューションは長期的には扱いにくくなります。したがって、非常に限られた成長率のメカニズムを使用するソリューションが強く推奨されます。
Discussions of differentiated services to date have frequently resulted in solutions that require per-flow state or per-flow queuing. As the number of flows in an ISP within the "default-free zone of the Internet" scales with the size of the Internet, the growth rate is difficult to support and argues strongly for a solution with lower state requirements. Simultaneously, supporting differentiated services is a significant benefit to most ISPs. Such support would allow providers to offer special services such as priority for bandwidth for mission critical services for users willing to pay a service premium. Customers would contract with ISPs for these services under Service Level Agreements (SLAs). Such an agreement may specify the traffic volume, how the traffic is handled, either in an absolute or relative manner, and the compensation that the ISP receives.
今日までの差別化されたサービスについての議論は、フローごとの状態またはフローごとのキューイングを必要とするソリューションを頻繁にもたらしました。 「インターネットのデフォルトフリーゾーン」内のISP内のフロー数はインターネットのサイズに比例するため、成長率をサポートすることは困難であり、より低い状態要件のソリューションを強く主張します。同時に、差別化されたサービスをサポートすることは、ほとんどのISPにとって大きなメリットです。このようなサポートにより、プロバイダーは、サービスプレミアムを支払う意思のあるユーザーにミッションクリティカルなサービスの帯域幅の優先順位などの特別なサービスを提供できます。顧客は、サービスレベル契約（SLA）に基づいてこれらのサービスについてISPと契約します。このような合意により、トラフィック量、絶対的または相対的な方法でのトラフィックの処理方法、およびISPが受け取る補償を指定できます。
Differentiated services are likely to be deployed across a single ISP to support applications such as a single enterprise's Virtual Private Network (VPN). However, this is only the first wave of service implementation. Closely following this will be the need for differentiated services to support extranets, enterprise VPNs that span ISPs, or industry interconnection networks such as the ANX [7]. Because such applications span enterprises and thus span ISPs, there is a clear need for inter-domain SLAs. This document discusses the technical architecture that would allow the creation of such inter-domain SLAs.
差別化されたサービスは、単一の企業の仮想プライベートネットワーク（VPN）などのアプリケーションをサポートするために、単一のISP全体に展開される可能性があります。ただし、これはサービス実装の最初の波にすぎません。これに密接に従うのは、エクストラネット、ISPにまたがるエンタープライズVPN、またはANXなどの業界の相互接続ネットワークをサポートする差別化されたサービスの必要性です[7]。このようなアプリケーションは企業にまたがってISPにまたがるため、ドメイン間のSLAが明らかに必要です。このドキュメントでは、このようなドメイン間SLAの作成を可能にする技術アーキテクチャについて説明します。
Another important consideration in this architecture is the advent of traffic engineering within ISPs. Traffic engineering is the ability to move trunks away from the path selected by the ISP's IGP and onto a different path. This allows an ISP to route traffic around known points of congestion in its network, thereby making more efficient use of the available bandwidth. In turn, this makes the ISP more competitive within its market by allowing the ISP to pass lower costs and better service on to its customers.
このアーキテクチャのもう1つの重要な考慮事項は、ISP内のトラフィックエンジニアリングの登場です。トラフィックエンジニアリングは、ISPのIGPによって選択されたパスから別のパスにトランクを移動する機能です。これにより、ISPはネットワーク内の既知の輻輳ポイントを中心にトラフィックをルーティングできるため、使用可能な帯域幅をより効率的に使用できます。その結果、ISPが低コストとより良いサービスを顧客に提供できるようになるため、ISPは市場内での競争力を高めます。
Finally, the need to provide end-to-end differentiated services implies that the architecture must support consistent inter-provider differentiated services. Most flows in the Internet today traverse multiple ISPs, making a consistent description and treatment of priority flows across ISPs a necessity.
最後に、エンドツーエンドの差別化されたサービスを提供する必要性は、アーキテクチャが一貫したプロバイダー間で差別化されたサービスをサポートする必要があることを意味します。今日のインターネットのほとんどのフローは複数のISPを通過するため、ISP間の優先フローの一貫した説明と処理が必要です。
The Differentiated Services Backbone architecture is the integration of several different mechanisms that, when used in a coordinated way, achieve the goals outlined above. This section describes each of the mechanisms used in some detail. Subsequent sections will then detail the interoperation of these mechanisms.
Differentiated Services Backboneアーキテクチャは、いくつかの異なるメカニズムを統合したものであり、調整された方法で使用すると、上で概説した目標を達成します。このセクションでは、使用される各メカニズムについて詳細に説明します。その後のセクションでは、これらのメカニズムの相互運用について詳しく説明します。
As described above, packets may fall into a variety of different traffic classes. For ISP operations, it is essential that packets be accurately classified before entering the ISP and that it is very easy for an ISP device to determine the traffic class for a particular packet.
上記のように、パケットはさまざまな異なるトラフィッククラスに分類されます。 ISPの運用では、ISPに入る前にパケットを正確に分類し、ISPデバイスが特定のパケットのトラフィッククラスを非常に簡単に決定できることが重要です。
The traffic class of MPLS packets can be encoded in the three bits reserved for CoS within the MPLS label header. In addition, traffic classes for IPv4 packets can be classified via the IPv4 ToS byte, possibly within the three precedence bits within that byte. Note that the consistent interpretation of the traffic class, regardless of the bits used to indicate this class, is an important feature of PASTE.
MPLSパケットのトラフィッククラスは、MPLSラベルヘッダー内のCoS用に予約されている3ビットでエンコードできます。さらに、IPv4パケットのトラフィッククラスは、IPv4 ToSバイトを介して、場合によってはそのバイト内の3つの優先ビット内で分類できます。トラフィッククラスの一貫した解釈は、このクラスを示すために使用されるビットに関係なく、PASTEの重要な機能であることに注意してください。
In this architecture it is not overly important to control which packets entering the ISP have a particular traffic class. From the ISP's perspective, each Priority packet should involve some economic premium for delivery. As a result the ISP need not pass judgment as to the appropriateness of the traffic class for the application.
このアーキテクチャでは、ISPに入るパケットが特定のトラフィッククラスを持つかどうかを制御することはそれほど重要ではありません。 ISPの観点から見ると、各Priorityパケットには配信の経済的プレミアムが含まれている必要があります。その結果、ISPは、アプリケーションのトラフィッククラスの適切性について判断を下す必要がありません。
It is important that any Network Control traffic entering an ISP be handled carefully. The contents of such traffic must also be carefully authenticated. Currently, there is no need for traffic generated external to a domain to transit a border router of the ISP.
ISPに入るネットワーク制御トラフィックは慎重に処理することが重要です。このようなトラフィックの内容も注意深く認証する必要があります。現在、ISPの境界ルーターを通過するためにドメインの外部で生成されたトラフィックは必要ありません。
As described above, traffic of a single traffic class that is aggregated into a single LSP is called a traffic trunk, or simply a trunk. Trunks are essential to the architecture because they allow the overhead in the infrastructure to be decoupled from the size of the network and the amount of traffic in the network. Instead, as the traffic scales up, the amount of traffic in the trunks increases; not the number of trunks.
上記のように、単一のLSPに集約される単一のトラフィッククラスのトラフィックは、トラフィックトランクまたは単にトランクと呼ばれます。トランクは、インフラストラクチャのオーバーヘッドをネットワークのサイズやネットワークのトラフィック量から切り離すことができるため、アーキテクチャにとって不可欠です。代わりに、トラフィックがスケールアップすると、トランクのトラフィック量が増加します。トランクの数ではありません。
The number of trunks within a given topology has a worst case of one trunk per traffic class from each entry router to each exit router. If there are N routers in the topology and C classes of service, this would be (N * (N-1) * C) trunks. Fortunately, instantiating this many trunks is not always necessary.
特定のトポロジ内のトランクの数は、各エントリルータから各出口ルータへのトラフィッククラスごとに1つのトランクという最悪の場合があります。トポロジにN台のルーターがあり、サービスクラスがCの場合、これは（N *（N-1）* C）トランクになります。幸いなことに、これだけ多くのトランクをインスタンス化する必要はありません。
Trunks with a single exit point which share a common internal path can be merged to form a single sink tree. The computation necessary to determine if two trunks can be merged is straightforward. If, when a trunk is being established, it intersects an existing trunk with the same traffic class and the same remaining explicit route, the new trunk can be spliced into the existing trunk at the point of intersection. The splice itself is straightforward: both incoming trunks will perform a standard label switching operation, but will result in the same outbound label. Since each sink tree created this way touches each router at most once and there is one sink tree per exit router, the result is N * C sink trees.
共通の内部パスを共有する単一の出口点を持つトランクをマージして、単一のシンクツリーを形成できます。 2つのトランクをマージできるかどうかを判断するために必要な計算は簡単です。トランクが確立されているときに、同じトラフィッククラスと同じ明示的なルートが残っている既存のトランクと交差する場合、新しいトランクを交差点で既存のトランクに接続できます。スプライス自体は単純です。両方の着信トランクが標準のラベルスイッチング操作を実行しますが、同じ発信ラベルになります。この方法で作成された各シンクツリーは、各ルーターに最大で1回しか触れず、出口ルーターごとに1つのシンクツリーがあるため、結果はN * Cのシンクツリーになります。
The number of trunks or sink trees can also be reduced if multiple trunks or sink trees for different classes follow the same path. This works because the traffic class of a trunk or sink tree is orthogonal to the path defined by its LSP. Thus, two trunks with different traffic classes can share a label for any part of the topology that is shared and ends in the exit router. Thus, the entire topology can be overlaid with N trunks.
異なるクラスの複数のトランクまたはシンクツリーが同じパスをたどっている場合は、トランクまたはシンクツリーの数を減らすこともできます。これは、トランクまたはシンクツリーのトラフィッククラスが、LSPによって定義されたパスと直交しているために機能します。したがって、トラフィッククラスが異なる2つのトランクは、共有され、出口ルータで終了するトポロジの任意の部分のラベルを共有できます。したがって、トポロジ全体をNトランクでオーバーレイできます。
Further, if Best Effort trunks and individual Best Effort flows are treated identically, there is no need to instantiate any Best Effort trunk that would follow the IGP computed path. This is because the packets can be directly forwarded without an LSP. However, traffic engineering may require Best Effort trunks to be treated differently from the individual Best Effort flows, thus requiring the instantiation of LSPs for Best Effort trunks. Note that Priority trunks must be instantiated because end-to-end RSVP packets to support the aggregated Priority flows must be tunneled.
さらに、ベストエフォートトランクと個々のベストエフォートフローが同じように扱われる場合、IGP計算パスをたどるベストエフォートトランクをインスタンス化する必要はありません。これは、LSPなしでパケットを直接転送できるためです。ただし、トラフィックエンジニアリングでは、ベストエフォートトランクを個別のベストエフォートフローとは異なる方法で処理する必要があるため、ベストエフォートトランクのLSPをインスタンス化する必要があります。集約されたプライオリティフローをサポートするエンドツーエンドのRSVPパケットはトンネリングする必要があるため、プライオリティトランクをインスタンス化する必要があることに注意してください。
Trunks can also be aggregated with other trunks by adding a new label to the stack of labels for each trunk, effectively bundling the trunks into a single tunnel. For the purposes of this document, this is also considered a trunk, or if we need to be specific, this will be called an aggregated trunk. Two trunks can be aggregated if they share a portion of their path. There is no requirement on the exact length of the common portion of the path, and thus the exact requirements for forming an aggregated trunk are beyond the scope of this document. Note that traffic class (i.e., QoS indication) is propagated when an additional label is added to a trunk, so trunks of different classes may be aggregated.
各トランクのラベルのスタックに新しいラベルを追加して、トランクを他のトランクと集約し、トランクを1つのトンネルに効果的にバンドルすることもできます。このドキュメントでは、これもトランクと見なされます。具体的に説明する必要がある場合は、集約トランクと呼ばれます。パスの一部を共有する2つのトランクを集約できます。パスの共通部分の正確な長さに関する要件はないため、集約トランクを形成するための正確な要件は、このドキュメントの範囲を超えています。トランクに追加のラベルが追加されると、トラフィッククラス（つまり、QoS通知）が伝播されるため、異なるクラスのトランクが集約される場合があります。
Trunks can be terminated at any point, resulting in a deaggregation of traffic. The obvious consequence is that there needs to be sufficient switching capacity at the point of deaggregation to deal with the resultant traffic.
トランクは任意の時点で終了できるため、トラフィックが分散されます。明らかな結果は、結果として生じるトラフィックに対処するために、集約解除の時点で十分なスイッチング容量が必要であることです。
High reliability for a trunk can be provided through the use of one or more backup trunks. Backup trunks can be initiated either by the same router that would initiate the primary trunk or by another backup router. The status of the primary trunk can be ascertained by the router that initiated the backup trunk (note that this may be either the same or a different router as the router that initiated the primary trunk) through out of band information, such as the IGP. If a backup trunk is established and the primary trunk returns to service, the backup trunk can be deactivated and the primary trunk used instead.
トランクの高い信頼性は、1つ以上のバックアップトランクを使用して提供できます。バックアップトランクは、プライマリトランクを開始するのと同じルータまたは別のバックアップルータのいずれかによって開始できます。プライマリトランクの状態は、IGPなどの帯域外情報を介して、バックアップトランクを開始したルーター（プライマリトランクを開始したルーターと同じルーターでも異なるルーターでもかまいません）によって確認できます。バックアップトランクが確立され、プライマリトランクがサービスに戻った場合、バックアップトランクを非アクティブにして、代わりにプライマリトランクを使用できます。
Originally RSVP was designed as a protocol to install state associated with resource reservations for individual flows originated/destined to hosts, where path was determined by destination-based routing. Quoting directly from the RSVP specifications, "The RSVP protocol is used by a host, on behalf of an application data stream, to request a specific quality of service (QoS) from the network for particular data streams or flows" [RFC2205].
元々、RSVPは、ホストが発信/宛先する個々のフローのリソース予約に関連付けられた状態をインストールするプロトコルとして設計されました。パスは、宛先ベースのルーティングによって決定されました。 RSVP仕様から直接引用すると、「RSVPプロトコルは、特定のデータストリームまたはフローに対してネットワークから特定のサービス品質（QoS）を要求するために、アプリケーションデータストリームの代わりにホストによって使用されます」[RFC2205]。
The usage of RSVP in PASTE is quite different from the usage of RSVP as it was originally envisioned by its designers. The first difference is that RSVP is used in PASTE to install state that applies to a collection of flows that all share a common path and common pool of reserved resources. The second difference is that RSVP is used in PASTE to install state related to forwarding, including label switching information, in addition to resource reservations. The third difference is that the path that this state is installed along is no longer constrained by the destination-based routing.
PASTEでのRSVPの使用法は、元々その設計者が想定していたRSVPの使用法とはかなり異なります。最初の違いは、RSVPがPASTEでインストール状態を使用して、予約されたリソースの共通パスと共通プールをすべて共有するフローのコレクションに適用されることです。 2番目の違いは、RSVPがPASTEで使用され、リソース予約に加えて、ラベルスイッチング情報を含む転送に関連する状態をインストールすることです。 3番目の違いは、この状態がインストールされているパスが宛先ベースのルーティングによって制約されなくなったことです。
The key factor that makes RSVP suitable for PASTE is the set of mechanisms provided by RSVP. Quoting from the RSVP specifications, "RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths." Moreover, RSVP provides a straightforward extensibility mechanism by allowing for the creation of new RSVP Objects. This flexibility allows us to also use the mechanisms provided by RSVP to create and maintain distributed state for information other than pure resource reservation, as well as allowing the creation of forwarding state in conjunction with resource reservation state.
RSVPをPASTEに適したものにする重要な要素は、RSVPによって提供される一連のメカニズムです。 RSVP仕様から引用すると、「RSVPプロトコルメカニズムは、マルチキャストまたはユニキャスト配信パスのメッシュ全体で分散予約状態を作成および維持するための一般的な機能を提供します。」さらに、RSVPは、新しいRSVPオブジェクトの作成を可能にすることにより、簡単な拡張メカニズムを提供します。この柔軟性により、RSVPが提供するメカニズムを使用して、純粋なリソース予約以外の情報の分散状態を作成および維持したり、リソース予約状態と組み合わせて転送状態を作成したりできます。
The original RSVP design, in which "RSVP itself transfers and manipulates QoS control parameters as opaque data, passing them to the appropriate traffic control modules for interpretation" can thus be extended to include explicit route parameters and label binding parameters. Just as with QoS parameters, RSVP can transfer and manipulate explicit route parameters and label binding parameters as opaque data, passing explicit route parameters to the appropriate forwarding module, and label parameters to the appropriate MPLS module.
したがって、「RSVP自体がQoSデータを不透明なデータとして転送および操作し、解釈のために適切なトラフィック制御モジュールに渡す」という元のRSVP設計を拡張して、明示的なルートパラメータとラベルバインディングパラメータを含めることができます。 QoSパラメータと同様に、RSVPは明示的なルートパラメータとラベルバインディングパラメータを不透明なデータとして転送および操作し、明示的なルートパラメータを適切な転送モジュールに渡し、ラベルパラメータを適切なMPLSモジュールに渡すことができます。
Moreover, an RSVP session in PASTE is not constrained to be only between a pair of hosts, but is also used between pairs of routers that act as the originator and the terminator of a traffic trunk.
さらに、PASTEのRSVPセッションは、1組のホスト間だけに制限されるのではなく、トラフィックトランクの発信元とターミネーターとして機能するルーターのペア間でも使用されます。
Using RSVP in PASTE helps consolidate procedures for several tasks: (a) procedures for establishing forwarding along an explicit route, (b) procedures for establishing a label switched path, and (c) RSVP's existing procedures for resource reservation. In addition, these functions can be cleanly combined in any manner. The main advantage of this consolidation comes from an observation that the above three tasks are not independent, but inter-related. Any alternative that accomplished each of these functions via independent sets of procedures, would require additional coordination between functions, adding more complexity to the system.
PASTEでRSVPを使用すると、（a）明示的なルートに沿った転送を確立する手順、（b）ラベルスイッチドパスを確立する手順、および（c）リソース予約のためのRSVPの既存の手順など、いくつかのタスクの手順を統合できます。さらに、これらの機能はどのような方法でもきれいに組み合わせることができます。この統合の主な利点は、上記の3つのタスクは独立しておらず、相互に関連しているという観察にあります。独立した一連の手順を介してこれらの各機能を実現する代替手段は、機能間の追加の調整を必要とし、システムをさらに複雑にします。
The purpose of traffic engineering is to give the ISP precise control over the flow of traffic within its network. Traffic engineering is necessary because standard IGPs compute the shortest path across the ISP's network based solely on the metric that has been administratively assigned to each link. This computation does not take into account the loading of each link. If the ISP's network is not a full mesh of physical links, the result is that there may not be an obvious way to assign metrics to the existing links such that no congestion will occur given known traffic patterns. Traffic engineering can be viewed as assistance to the routing infrastructure that provides additional information in routing traffic along specific paths, with the end goal of more efficient utilization of networking resources.
トラフィックエンジニアリングの目的は、ISPがネットワーク内のトラフィックのフローを正確に制御できるようにすることです。標準のIGPは、各リンクに管理上割り当てられたメトリックのみに基づいて、ISPのネットワーク全体の最短パスを計算するため、トラフィックエンジニアリングが必要です。この計算では、各リンクのロードは考慮されません。 ISPのネットワークが物理リンクのフルメッシュでない場合、既知のトラフィックパターンが与えられても輻輳が発生しないように既存のリンクにメトリックを割り当てる明確な方法がない可能性があります。トラフィックエンジニアリングは、特定のパスに沿ってトラフィックをルーティングする際の追加情報を提供するルーティングインフラストラクチャの支援と見なすことができ、ネットワーキングリソースのより効率的な利用という最終目標があります。
Traffic engineering is performed by directing trunks along explicit paths within the ISP's topology. This diverts the traffic away from the shortest path computed by the IGP and presumably onto uncongested links, eventually arriving at the same destination. Specification of the explicit route is done by enumerating an explicit list of the routers in the path. Given this list, traffic engineering trunks can be constructed in a variety of ways. For example, a trunk could be manually configured along the explicit path. This would involve configuring each router along the path with state information for forwarding the particular label. Such techniques are currently used for traffic engineering in some ISPs today.
トラフィックエンジニアリングは、ISPトポロジ内の明示的なパスに沿ってトランクを誘導することによって実行されます。これにより、IGPによって計算された最短パスからトラフィックが迂回され、おそらく輻輳していないリンクに迂回し、最終的に同じ宛先に到達します。明示的なルートの指定は、パス内のルーターの明示的なリストを列挙することによって行われます。このリストがあれば、トラフィックエンジニアリングトランクはさまざまな方法で構築できます。たとえば、トランクは明示的なパスに沿って手動で構成できます。これには、特定のラベルを転送するための状態情報を使用して、パスに沿った各ルーターを構成することが含まれます。このような技術は現在、一部のISPのトラフィックエンジニアリングに現在使用されています。
Alternately, a protocol such as RSVP can be used with an Explicit Route Object (ERO) so that the first router in the path can establish the trunk. The computation of the explicit route is beyond the scope of this document but may include considerations of policy, static and dynamic bandwidth allocation, congestion in the topology and manually configured alternatives.
または、RSVPなどのプロトコルを明示的ルートオブジェクト（ERO）と共に使用して、パスの最初のルーターがトランクを確立できるようにすることもできます。明示的なルートの計算はこのドキュメントの範囲を超えていますが、ポリシー、静的および動的な帯域幅割り当て、トポロジーの輻輳、および手動で構成された代替の考慮事項が含まれる場合があります。
Priority traffic has certain requirements on capacity and traffic handling. To provide differentiated services, the ISP's infrastructure must know of, and support these requirements. The mechanism used to communicate these requirements dynamically is RSVP. The flow specification within RSVP can describe many characteristics of the flow or trunk. An LSR receiving RSVP information about a flow or trunk has the ability to look at this information and either accept or reject the reservation based on its local policy. This policy is likely to include constraints about the traffic handling functions that can be supported by the network and the aggregate capacity that the network is willing to provide for Priority traffic.
優先トラフィックには、容量とトラフィック処理に関する特定の要件があります。差別化されたサービスを提供するには、ISPのインフラストラクチャがこれらの要件を認識してサポートする必要があります。これらの要件を動的に伝達するために使用されるメカニズムはRSVPです。 RSVP内のフロー仕様は、フローまたはトランクの多くの特性を記述できます。フローまたはトランクに関するRSVP情報を受信するLSRは、この情報を確認し、ローカルポリシーに基づいて予約を受け入れるか拒否することができます。このポリシーには、ネットワークでサポートできるトラフィック処理機能、およびネットワークが優先トラフィックに提供する用意のある総容量に関する制約が含まれる可能性があります。
Trunks that span multiple ISPs are likely to be based on legal agreements and some other external considerations. As a result, one of the common functions that we would expect to see in this type of architecture is a bilateral agreement between ISPs to support differentiated services. In addition to the obvious compensation, this agreement is likely to spell out the acceptable traffic handling policies and capacities to be used by both parties.
複数のISPにまたがるトランクは、法的な合意やその他の外部の考慮事項に基づいている可能性があります。その結果、このタイプのアーキテクチャで期待される一般的な機能の1つは、差別化されたサービスをサポートするためのISP間の双方向の合意です。明白な補償に加えて、この合意は、両当事者が使用する許容可能なトラフィック処理ポリシーと容量を詳しく説明する可能性があります。
Documents similar to this exist today on behalf of Best Effort traffic and are known as peering agreements. Extending a peering agreement to support differentiated services would effectively create an Inter-Provider SLA (IPS). Such agreements may include the types of differentiated services that one ISP provides to the other ISP, as well as the upper bound on the amount of traffic associated with each such service that the ISP would be willing to accept and carry from the other ISP. Further, an IPS may limit the types of differentiated services and an upper bound on the amount of traffic that may originate from a third party ISP and be passed from one signer of the IPS to the other.
これに類似したドキュメントは、ベストエフォートトラフィックに代わって今日存在し、ピアリング契約として知られています。差別化されたサービスをサポートするためにピアリング契約を拡張すると、プロバイダー間SLA（IPS）を効果的に作成できます。そのような合意には、あるISPが他のISPに提供する差別化されたサービスのタイプ、およびISPが他のISPから受け入れて持ち運びするそのような各サービスに関連するトラフィック量の上限が含まれる場合があります。さらに、IPSは、差別化されたサービスのタイプと、サードパーティのISPから発信され、IPSのある署名者から別の署名者に渡されるトラフィック量の上限を制限する場合があります。
If the expected costs associated with the IPS are not symmetric, the parties may agree that one ISP will provide the other ISP with appropriate compensation. Such costs may be due to inequality of traffic exchange, costs in delivering the exchanged traffic, or the overhead involved in supporting the protocols exchanged between the two ISPs.
IPSに関連する予想コストが対称的でない場合、当事者は、一方のISPが他方のISPに適切な補償を提供することに同意する場合があります。このようなコストは、トラフィック交換の不平等、交換されたトラフィックの配信コスト、または2つのISP間で交換されるプロトコルのサポートに伴うオーバーヘッドが原因である可能性があります。
Note that the PASTE architecture provides a technical basis to establish IPSs, while the procedures necessary to create such IPSs are outside the scope of PASTE.
PASTEアーキテクチャはIPSを確立するための技術的基盤を提供しますが、そのようなIPSを作成するために必要な手順はPASTEの範囲外であることに注意してください。
To help support IPSs, special facilities must be available at the interconnect between ISPs. These mechanisms are necessary to insure that the network transmitting a trunk of Priority traffic does so within the agreed traffic characterization and capacity. A simplistic example of such a mechanism might be a token bucket system, implemented on a per-trunk basis. Similarly, there need to be mechanisms to insure, on a per trunk basis, that an ISP receiving a trunk receives only the traffic that is in compliance with the agreement between ISPs.
IPSをサポートするには、ISP間の相互接続で特別な機能を利用できる必要があります。これらのメカニズムは、優先トラフィックのトランクを送信するネットワークが、合意されたトラフィックの特性と容量の範囲内でそうすることを保証するために必要です。そのようなメカニズムの単純な例は、トランクごとに実装されたトークンバケットシステムです。同様に、トランクごとに、トランクを受信するISPがISP間の合意に準拠するトラフィックのみを受信することを保証するメカニズムが必要です。
Trunks may span multiple ISPs. As a result, establishing a particular trunk may require more than two ISPs. The result would be a multilateral IPS. This type of agreement is unusual with respect to existing Internet business practices in that it requires multiple participating parties for a useful result. This is also challenging because without a commonly accepted service level definition, there will need to be a multilateral definition, and this definition may not be compatible used in IPSs between the same parties.
トランクは複数のISPにまたがることがあります。その結果、特定のトランクを確立するには、3つ以上のISPが必要になる場合があります。その結果、多国間IPSになります。このタイプの合意は、有用な結果を得るために複数の参加者を必要とするという点で、既存のインターネットビジネス慣行に関しては珍しいものです。一般に受け入れられているサービスレベル定義がないと、多国間での定義が必要になるため、これは挑戦的であり、この定義は、同じ当事者間のIPSで使用される互換性がない場合があります。
Because this new type of agreement may be a difficulty, it may in some cases be simpler for certain ISPs to establish aggregated trunks through other ISPs and then contract with customers to aggregate their trunks. In this way, trunks can span multiple ISPs without requiring multilateral IPSs.
この新しいタイプの合意は困難な場合があるため、特定のISPが他のISPを介して集約トランクを確立し、顧客と契約してトランクを集約する方が簡単な場合があります。このように、トランクは複数のIPSを必要とせずに複数のISPにまたがることができます。
Either or both of these two alternatives are possible and acceptable within this architecture, and the choice is left for the the participants to make on a case-by-case basis.
これらの2つの代替案のいずれかまたは両方がこのアーキテクチャ内で可能であり、許容可能であり、参加者がケースバイケースで行う選択は残されています。
5.0 The Provider Architecture for differentiated Services and Traffic Engineering (PASTE)
5.0 差別化されたサービスとトラフィックエンジニアリング（PASTE）のプロバイダーアーキテクチャ
The Provider Architecture for differentiated Services and Traffic Engineering (PASTE) is based on the usage of MPLS and RSVP as mechanisms to establish differentiated service connections across ISPs. This is done in a scalable way by aggregating differentiated flows into traffic class specific MPLS tunnels, also known as traffic trunks.
差別化されたサービスとトラフィックエンジニアリング（PASTE）のプロバイダーアーキテクチャは、ISP全体で差別化されたサービス接続を確立するメカニズムとしてのMPLSおよびRSVPの使用に基づいています。これは、差別化されたフローをトラフィックトランクとも呼ばれるトラフィッククラス固有のMPLSトンネルに集約することにより、スケーラブルな方法で行われます。
Such trunks can be given an explicit route by an ISP to define the placement of the trunk within the ISP's infrastructure, allowing the ISP to traffic engineer its own network. Trunks can also be aggregated and merged, which helps the scalability of the architecture by minimizing the number of individual trunks that intermediate systems must support.
このようなトランクには、ISPによって明示的なルートを指定して、ISPのインフラストラクチャ内でのトランクの配置を定義し、ISPが独自のネットワークをトラフィックエンジニアリングできるようにすることができます。トランクを集約およびマージすることもできます。これにより、中間システムがサポートする必要のある個々のトランクの数を最小限に抑えることで、アーキテクチャのスケーラビリティが向上します。
Special traffic handling operations, such as specific queuing algorithms or drop computations, can be supported by a network on a per-trunk basis, allowing these services to scale with the number of trunks in the network.
特定のキューイングアルゴリズムやドロップ計算などの特別なトラフィック処理操作は、トランクごとにネットワークでサポートできるため、これらのサービスをネットワーク内のトランクの数に合わせて拡張できます。
Agreements for handling of trunks between ISPs require both legal documentation and conformance mechanisms on both sides of the agreement. As a trunk is unidirectional, it is sufficient for the transmitter to monitor and shape outbound traffic, while the receiver polices the traffic profile.
ISP間のトランクの処理に関する合意には、合意の両側に法的文書と適合メカニズムの両方が必要です。トランクは単方向であるため、トランスミッタは送信トラフィックを監視およびシェーピングするだけで十分ですが、レシーバはトラフィックプロファイルをポリシングします。
Trunks can either be aggregated across other ISPs or can be the subject of a multilateral agreement for the carriage of the trunk. RSVP information about individual flows is tunneled in the trunk to provide an end-to-end reservation. To insure that the return RSVP traffic is handled properly, each trunk must also have another tunnel running in the opposite direction. Note that the reverse tunnel may be a different trunk or it may be an independent tunnel terminating at the same routers as the trunk. Routing symmetry between a trunk and its return is not assumed.
トランクは、他のISP全体に集約することも、トランクの輸送に関する多国間協定の対象にすることもできます。個々のフローに関するRSVP情報はトランクでトンネリングされ、エンドツーエンドの予約を提供します。戻りRSVPトラフィックが適切に処理されるようにするには、各トランクに反対方向に実行されている別のトンネルも必要です。リバーストンネルは別のトランクである場合と、トランクと同じルーターで終端する独立したトンネルである場合があります。トランクとそのリターンの間のルーティングの対称性は想定されていません。
RSVP already contains the ability to do local path repair. In the event of a trunk failure, this capability, along with the ability to specify abstractions in the ERO, allows RSVP to re-establish the trunk in many failure scenarios.
RSVPには、ローカルパス修復を実行する機能がすでに含まれています。トランク障害が発生した場合、この機能とEROで抽象化を指定する機能により、RSVPは多くの障害シナリオでトランクを再確立できます。
As an example of the operation of this architecture, we consider an example of a single differentiated flow. Suppose that a user wishes to make a telephone call using a Voice over IP service. While this call is full duplex, we can consider the data flow in each direction in a half duplex fashion because the architecture operates symmetrically.
このアーキテクチャの動作の例として、単一の差別化されたフローの例を考えます。ユーザーがボイスオーバーIPサービスを使用して電話をかけたいとします。この呼び出しは全二重ですが、アーキテクチャは対称的に動作するため、半二重方式で各方向のデータフローを検討できます。
Suppose that the data packets for this voice call are created at a node S and need to traverse to node D. Because this is a voice call, the data packets are encoded as Priority packets. If there is more granularity within the traffic classes, these packets might be encoded as wanting low jitter and having low drop preference. Initially this is encoded into the precedence bits of the IPv4 ToS byte.
この音声通話のデータパケットがノードSで作成され、ノードDに移動する必要があるとします。これは音声通話であるため、データパケットは優先パケットとしてエンコードされます。トラフィッククラス内でより細分性がある場合、これらのパケットは、ジッターが低く、ドロップ優先順位が低いものとしてエンコードされる可能性があります。最初に、これはIPv4 ToSバイトの優先ビットにエンコードされます。
To establish the flow to node D, node S first generates an RSVP PATH message which describes the flow in more detail. For example, the flow might require 3kbps of bandwidth, be insensitive to jitter of less than 50ms, and require a delay of less than 200ms. This message is passed through node S's local network and eventually appears in node S's ISP. Suppose that this is ISP F.
ノードDへのフローを確立するために、ノードSは最初に、フローを詳細に説明するRSVP PATHメッセージを生成します。たとえば、フローには3 kbpsの帯域幅が必要で、50ミリ秒未満のジッターの影響を受けず、200ミリ秒未満の遅延が必要な場合があります。このメッセージはノードSのローカルネットワークを通過し、最終的にノードSのISPに表示されます。これがISP Fであるとします。
ISP F has considerable latitude in its options at this point. The requirement on F is to place the flow into a trunk before it exits F's infrastructure. One thing that F might do is to perform the admission control function at the first hop router. At this point, F would determine if it had the capacity and capability of carrying the flow across its own infrastructure to an exit router E. If the admission control decision is negative, the first hop router can inform node S using RSVP. Alternately, it can propagate the RSVP PATH message along the path to exit router E. This is simply normal operation of RSVP on a differentiated flow.
現時点では、ISP Fの選択肢にはかなりの幅があります。 Fの要件は、フローをFのインフラストラクチャから出る前にトランクに配置することです。 Fが行う可能性があることの1つは、最初のホップのルーターでアドミッション制御機能を実行することです。この時点で、Fは自身のインフラストラクチャを通過してフローを出口ルータEに運ぶ能力と能力があるかどうかを判断します。アドミッション制御の決定が否定の場合、ファーストホップルータはRSVPを使用してノードSに通知できます。あるいは、RSVP PATHメッセージをパスに沿ってルータEを終了するまで伝播できます。これは、差別化されたフローでのRSVPの通常の動作です。
At exit router E, there is a trunk that ISP F maintains that transits ISP X, Y, and Z and terminates in ISP L. Based on BGP path information or on out of band information, Node D is known to be a customer of ISP L. Exit router E matches the flow requirements in the RSVP PATH message to the characteristics (e.g., remaining capacity) of the trunk to ISP L. Assuming that the requirements are compatible, it then notes that the flow should be aggregated into the trunk.
出口ルータEには、ISP X、Y、Zを通過し、ISP Lで終端する、ISP Fが維持するトランクがあります。BGPパス情報または帯域外情報に基づいて、ノードDはISPの顧客であることがわかっています。 L.出口ルーターEは、RSVP PATHメッセージのフロー要件をISP Lへのトランクの特性（たとえば、残りの容量）と照合します。要件に互換性があると仮定すると、フローはトランクに集約される必要があることに注意します。
To insure that the flow reservation happens end to end, the RSVP PATH message is then encapsulated into the trunk itself, where it is transmitted to ISP L. It eventually reaches the end of the trunk, where it is decapsulated by router U. PATH messages are then propagated all the way to the ultimate destination D.
フロー予約がエンドツーエンドで行われることを保証するために、RSVP PATHメッセージはトランク自体にカプセル化され、ISP Lに送信されます。最終的にトランクの最後に到達し、ルーターUによってカプセル化解除されます。PATHメッセージ次に、最終的な宛先Dに伝達されます。
Note that the end-to-end RSVP RESV messages must be carefully handled by router U. The RESV messages from router U to E must return via a tunnel back to router E.
エンドツーエンドのRSVP RESVメッセージは、ルーターUで注意深く処理する必要があることに注意してください。ルーターUからEへのRESVメッセージは、トンネルを経由してルーターEに戻る必要があります。
RSVP is also used by exit router E to initialize and maintain the trunk to ISP L. The RSVP messages for this trunk are not placed within the trunk itself but the end-to-end RSVP messages are. The existence of multiple overlapping RSVP sessions in PASTE is straightforward, but requires explicit enumeration when discussing particular RSVP sessions.
RSVPは、ISP Lへのトランクを初期化および維持するために、出口ルータEでも使用されます。このトランクのRSVPメッセージは、トランク自体内には配置されませんが、エンドツーエンドのRSVPメッセージは配置されます。 PASTEで重複する複数のRSVPセッションが存在することは簡単ですが、特定のRSVPセッションについて説明する場合は明示的な列挙が必要です。
Data packets created by S flow through ISP F's network following the flow reservation and eventually make it to router E. At that point, they are given an MPLS label and placed in the trunk. Normal MPLS switching will propagate this packet across ISP X's network. Note that the same traffic class still applies because the class encoding is propagated from the precedence bits of the IPv4 header to the CoS bits in the MPLS label. As the packet exits ISP X's network, it can be aggregated into another trunk for the express purpose of tranisiting ISP Y.
Sによって作成されたデータパケットは、フロー予約に従ってISP Fのネットワークを通過し、最終的にルーターEに到達します。その時点で、MPLSラベルが付与され、トランクに配置されます。通常のMPLSスイッチングは、このパケットをISP Xのネットワーク全体に伝搬します。クラスエンコーディングがIPv4ヘッダーの優先ビットからMPLSラベルのCoSビットに伝播されるため、同じトラフィッククラスが引き続き適用されることに注意してください。パケットがISP Xのネットワークを出ると、ISP Yをトランジットする目的で別のトランクに集約できます。
Again, label switching is used to bring the packet across ISP Y's network and then the aggregated trunk terminates at a router in ISP Z's network. This router deaggregates the trunk, and forwards the resulting trunk towards ISP L. This trunk transits ISP Z and terminates in ISP L at router U. At this point, the data packets are removed from the trunk and forwarded along the path computed by RSVP.
この場合も、ラベルスイッチングを使用してパケットがISP Yのネットワークを通過し、集約されたトランクがISP Zのネットワーク内のルーターで終端します。このルーターはトランクを分解し、結果のトランクをISP Lに転送します。このトランクはISP Zを通過し、ルーターUのISP Lで終端します。この時点で、データパケットはトランクから削除され、RSVPによって計算されたパスに沿って転送されます。
In this example, there are two trunks in use. One trunk runs from ISP F, through ISPs X, Y and Z, and then terminates in ISP L. The other aggregated trunk begins in ISP X, transits ISP Y and terminates in ISP Z.
この例では、2つのトランクが使用されています。 1つのトランクはISP FからISP X、Y、Zを経由して実行され、ISP Lで終了します。他の集約トランクはISP Xで始まり、ISP Yを通過し、ISP Zで終了します。
The first trunk may be established based on a multilateral agreement between ISPs F, X, Z and L. Note that ISP Y is not part of this multilateral agreement, and ISP X is contractually responsible for providing carriage of the trunk into ISP Z. Also per this agreement, the tunnel is maintained by ISP F and is initialized and maintained through the use of RSVP and an explicit route object that lists ISP's X, Z, and L. Within this explicit route, ISP X and ISP L are given as strict hops, thus constraining the path so that there may not be other ISPs intervening between the pair of ISPs F and X and the pair Z and L. However, no constraint is placed on the path between ISPs X and Z. Further, there is no constraint placed on which router terminates the trunk within L's infrastructure.
最初のトランクは、ISP F、X、Z、およびLの間の多国間協定に基づいて確立される場合があります。ISPYはこの多国間協定の一部ではなく、ISP Xは、ISP Zへのトランクの輸送を提供する契約上の責任があることに注意してください。この合意に従って、トンネルはISP Fによって維持され、RSVPおよびISPのX、Z、Lをリストする明示的なルートオブジェクトを使用して初期化および維持されます。この明示的なルート内では、ISP XとISP Lは厳格なものとして指定されますホップ、したがって、パスを制約して、ISP FとXのペアとZとLのペアの間に他のISPが介在しないようにします。ただし、ISP XとZの間のパスには制約がありません。さらに、 Lのインフラストラクチャ内でトランクを終端するルーターに課せられる制約。
Normally this trunk is maintained by one of ISP F's routers adjacent to ISP X. For robustness, ISP F has a second router adjacent to ISP X, and that provides a backup trunk.
通常、このトランクはISP Xに隣接するISP Fのルーターの1つによって維持されます。堅牢性のために、ISP FにはISP Xに隣接する2番目のルーターがあり、バックアップトランクを提供します。
The second trunk may be established by a bilateral agreement between ISP X and Y. ISP Z is not involved. The second trunk is constrained so that it terminates on the last hop router within Y's infrastructure. This tunnel is initialized and maintained through the use of RSVP and an explicit route that lists the last hop router within ISP Y's infrastructure. In order to provide redundancy in the case of the failure of the last hop router, there are multiple explicit routes configured into ISP X's routers. These routers can select one working explicit route from their configured list. Further, in order to provide redundancy against the failure of X's primary router, X provides a backup router with a backup trunk.
2番目のトランクは、ISP XとYの間の二国間協定によって確立される場合があります。ISPZは関与していません。 2番目のトランクは、Yのインフラストラクチャ内の最後のホップルータで終端するように制約されています。このトンネルは、RSVPおよびISP Yのインフラストラクチャ内のラストホップルーターをリストする明示的なルートを使用して初期化および維持されます。ラストホップルーターに障害が発生した場合に冗長性を提供するために、ISP Xのルーターには複数の明示的なルートが構成されています。これらのルータは、設定されたリストから1つの現用明示ルートを選択できます。さらに、Xのプライマリルーターの障害に対して冗長性を提供するために、Xはバックアップトランクを備えたバックアップルーターを提供します。
Note that in this example, there are no single points of failure once the traffic is within ISP F's network. Each trunk has a backup trunk to protect against the failure of the primary trunk. To protect against the failure of any particular router, each trunk can be configured with multiple explicit route objects that terminate at one of several acceptable routers.
この例では、トラフィックがISP Fのネットワーク内にある場合、単一障害点は存在しないことに注意してください。各トランクには、プライマリトランクの障害から保護するためのバックアップトランクがあります。特定のルーターの障害から保護するために、各トランクは、いくつかの受け入れ可能なルーターの1つで終了する複数の明示的なルートオブジェクトで構成できます。
Because Priority traffic intrinsically has more 'value' than Best Effort traffic, the ability to inject Priority traffic into a network must be carefully controlled. Further, signaling concerning Priority traffic has to be authenticated because it is likely that the signaling information will result in specific accounting and eventually billing for the Priority services. ISPs are cautioned to insure that the Priority traffic that they accept is in fact from a known previous hop. Note that this is a simple requirement to fulfill at private peerings, but it is much more difficult at public interconnects. For this reason, exchanging Priority traffic at public interconnects should be done with great care.
優先トラフィックは本質的にベストエフォートトラフィックよりも「価値」が高いため、優先トラフィックをネットワークに注入する機能は慎重に制御する必要があります。さらに、シグナリング情報によって特定のアカウンティングが行われ、最終的にプライオリティサービスの課金が行われる可能性があるため、プライオリティトラフィックに関するシグナリングは認証される必要があります。 ISPは、受け入れるPriorityトラフィックが実際に既知の以前のホップからのものであることを保証するよう警告されています。これはプライベートピアリングで満たすための単純な要件ですが、パブリックインターコネクトでははるかに難しいことに注意してください。このため、パブリック相互接続での優先トラフィックの交換は細心の注意を払って行う必要があります。
RSVP traffic needs to be authenticated. This can possibly be done through the use of the Integrity Object.
RSVPトラフィックは認証される必要があります。これは、おそらくIntegrity Objectを使用して行うことができます。
The Provider Architecture for differentiated Services and Traffic Engineering (PASTE) provides a robust, scalable means of deploying differentiated services in the Internet. It provides scalability by aggregating flows into class specific MPLS tunnels. These tunnels, also called trunks, can in turn be aggregated, thus leading to a hierarchical aggregation of traffic.
差別化されたサービスとトラフィックエンジニアリング（PASTE）のプロバイダーアーキテクチャは、差別化されたサービスをインターネットに展開するための堅牢でスケーラブルな手段を提供します。フローをクラス固有のMPLSトンネルに集約することにより、スケーラビリティを提供します。これらのトンネルはトランクとも呼ばれ、順番に集約できるため、トラフィックが階層的に集約されます。
Trunk establishment and maintenance is done with RSVP, taking advantage of existing work in differentiated services. Explicit routes within the RSVP signaling structure allow providers to perform traffic engineering by placing trunks on particular links in their network.
トランクの確立と保守は、差別化されたサービスでの既存の作業を利用して、RSVPで行われます。 RSVPシグナリング構造内の明示的なルートにより、プロバイダーはネットワーク内の特定のリンクにトランクを配置することにより、トラフィックエンジニアリングを実行できます。
The result is an architecture that is sufficient to scale to meet ISP needs and can provide differentiated services in the large, support traffic engineering, and continue to grow with the Internet.
その結果、ISPのニーズを満たすのに十分な規模のアーキテクチャが実現し、大規模な環境で差別化されたサービスを提供し、トラフィックエンジニアリングをサポートし、インターネットと共に成長し続けることができます。
Inspiration and comments about this document came from Noel Chiappa, Der-Hwa Gan, Robert Elz, Lisa Bourgeault, and Paul Ferguson.
このドキュメントに関するインスピレーションとコメントは、ノエルチャッパ、ダーファガン、ロバートエルツ、リサブルジョー、ポールファーガソンから寄せられました。
[1] Rosen, E., Viswanathan, A., and R. Callon, "A Proposed Architecture for MPLS", Work in Progress.
[1] ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「MPLSの提案されたアーキテクチャ」、進行中。
[2] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[2] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、1997年9月。
[3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow,, G., Li, T., and A. Conta, "MPLS Label Stack Encoding", Work in Progress.
[3] ローゼン、E。、レクター、Y。、タッパン、D。、ファリナッチ、D。、フェドルコウ、G。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、作業中。
[4] Davie, B., Rekhter, Y., Rosen, E., Viswanathan, A., and V. Srinivasan, "Use of Label Switching With RSVP", Work in Progress.
[4] デイビー、B。、レクター、Y。、ローゼン、E。、ヴィスワナサン、A。、およびV.スリニバサン、「RSVPによるラベルスイッチングの使用」、作業中。
[5] Gan, D.-H., Guerin, R., Kamat, S., Li, T., and E. Rosen, "Setting up Reservations on Explicit Paths using RSVP", Work in Progress.
[5] Gan、D.-H.、Guerin、R.、Kamat、S.、Li、T。、およびE. Rosen、「RSVPを使用した明示的なパスでの予約の設定」、作業中。
[6] Davie, B., Li, T., Rosen, E., and Y. Rekhter, "Explicit Route Support in MPLS", Work in Progress.
[6] Davie、B.、Li、T.、Rosen、E。、およびY. Rekhter、「MPLSでの明示的なルートサポート」、作業中。
[7] http://www.anxo.com/
Tony Li Juniper Networks, Inc. 385 Ravendale Dr. Mountain View, CA 94043
Tony Li Juniper Networks、Inc. 385 Ravendale Dr. Mountain View、CA 94043
Phone: +1 650 526 8006
Fax: +1 650 526 8001
EMail: tli@juniper.net
Yakov Rekhter cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134
Yakov Rekhter cisco Systems、Inc. 170 W. Tasman Dr. San Jose、CA 95134
EMail: yakov@cisco.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。