RFC2430 日本語訳
2430 A Provider Architecture for Differentiated Services and TrafficEngineering (PASTE). T. Li, Y. Rekhter. October 1998. (Format: TXT=40148 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Li
Request for Comments: 2430 Juniper Networks
Category: Informational Y. Rekhter
Cisco Systems
October 1998
コメントを求めるワーキンググループT.李の要求をネットワークでつないでください: 2430年の杜松はカテゴリをネットワークでつなぎます: 情報のY.Rekhterシスコシステムズ1998年10月
A Provider Architecture for
Differentiated Services and Traffic Engineering
(PASTE)
微分されたサービスと交通工学のためのプロバイダー構造(ペースト)
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。
1.0 Abstract
1.0 要約
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.
このドキュメントはDifferentiated ServicesのためのProvider ArchitectureとインターネットサービスプロバイダのためのTraffic Engineering(PASTE)(ISP)について説明します。 大きいISPにおける現在の流れの全くの数に従って問題が提示したスケーリングが1流れあたりの状態を容認できなく維持する費用を作るので、微分されたサービスを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は、微分されたサービスを支持するスケーラブルな交通管理体系を作成するのにMultiprotocol Label Switching(MPLS)[1]とResource予約プロトコル(RSVP)[2]を使用することによって、これらの問題を記述します。 このドキュメントは、読者がこれらの技術の両方に少なくとも何らかの親しみを持っていると仮定します。
2.0 Terminology
2.0 用語
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接続などのホストの間で通常、非常にすばらしい粒状を持って、ただ一つの置き換えを反映します。 集められた流れはルータの系列に沿って状態とただ一つの資源予約を進めながら共有される多くの流れです。
Li & Rekhter Informational [Page 1] RFC 2430 PASTE October 1998
李とRekhterの情報[1ページ]のRFC2430は1998年10月を貼ります。
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つのメカニズムがMultiprotocol Label Switching(MPLS)です。 MPLSでは、最小量のヘッダー[3]でそれらを包装することによって、パケットはトンネルを堀られます。 そのような各ヘッダーはラベルを含んでいて、それは推進と資源予約意味論の両方を運びます。 MPLSは、Label Switched Path(LSP)を組み立てるために一連のLabel Switching Routers(LSRs)に沿ってラベルベースの推進情報をインストールするためにメカニズムを定義します。 また、資源予約情報にLSPsを関連づけることができます。
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].
そのようなLSPsを組み立てるための1つのプロトコルがResource予約プロトコル(RSVP)[4]です。 Explicit Route Object(ERO)[5]と共に使用されると、明白なルート[6]に沿ってLSPを組み立てるのにRSVPを使用できます。
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.
ネットワークControl交通はルーティング・プロトコルとネットワークマネージメント交通から主として成ります。 Network Control交通が落とされるなら、ネットワークの不安定性をもたらして、ルーティング・プロトコルは、失敗するか、またはばたつくことができます。 したがって、Network Controlには、非常に低い低下好みがなければなりません。 しかしながら、Network Control交通は、一般に、遅れを加減するために神経が鈍く、比較的少な量の帯域幅を必要とします。 わずかな帯域幅保証は、Network Control交通が正しく作動するのを保障するために十分です。
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における、かなりの大多数の交通はBest Effort交通です。 この交通はだいたい、神経の鈍くて合理的に混雑に適応型の遅れです。
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は属します。
Li & Rekhter Informational [Page 2] RFC 2430 PASTE October 1998
李とRekhterの情報[2ページ]のRFC2430は1998年10月を貼ります。
3.0 Introduction
3.0 序論
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に制限されません。 multiprovider catenetが微分されたサービスを必要とする場合、同じ構造はいずれでも大きい状態で使用されるかもしれません。
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.
これまでの微分されたサービスの議論は頻繁に1流れあたりの状態か1流れあたりの列を作りを必要とする解決策をもたらしました。 「インターネットの無デフォルトのゾーン」の中の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
微分されたサービスは、単一の企業のVirtual兵士のNetwork(VPN)などのアプリケーションを支持するためにただ一つのISPの向こう側に配備されそうです。 しかしながら、唯一のこれはサービス実現の最初の波です。 密接にこれに続くのは、微分されたサービスがエクストラネットを支持する必要性であるだろう、企業VPNsはそれです。
Li & Rekhter Informational [Page 3] RFC 2430 PASTE October 1998
李とRekhterの情報[3ページ]のRFC2430は1998年10月を貼ります。
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.
ISP、または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.
この構造における別の重要な考慮すべき事柄は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の向こう側の優先権流れの一貫した記述と処理を必要性にして。
4.0 Components of the Architecture
4.0 構造の成分
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構造は連携方法で使用されると上に概説された目標を実現する数個の異なったメカニズムの統合です。 このセクションは何らかの詳細に使用されるそれぞれのメカニズムについて説明します。 そして、その後のセクションはこれらのメカニズムのinteroperationについて詳述するでしょう。
4.1 Traffic classes
4.1 交通のクラス
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.
CoSのためにMPLSラベルヘッダーの中に予約された3ビットでMPLSパケットの交通のクラスをコード化できます。 さらに、IPv4 ToSバイトでIPv4パケットのための交通のクラスを分類できます、ことによるとそのバイトの中の3先行ビットの以内で。 交通のクラスの一貫した解釈がこのクラスを示すのに使用されるビットにかかわらずPASTEの重要な特徴であることに注意してください。
Li & Rekhter Informational [Page 4] RFC 2430 PASTE October 1998
李とRekhterの情報[4ページ]のRFC2430は1998年10月を貼ります。
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に入るどんなNetwork Control交通も慎重に扱われるのは、重要です。 また、慎重にそのような交通のコンテンツを認証しなければなりません。 現在、ISPの境界ルータを通過するために、ドメインに外部であることの形で発生する交通の必要は全くありません。
4.2 Trunks
4.2 トランクス
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に集められる1つの交通のクラスの交通は交通トランク、または単にトランクと呼ばれます。 それらがネットワークのサイズとネットワークの交通の量からインフラストラクチャにおけるオーバーヘッドに衝撃を吸収させるので、トランクスは構造に不可欠です。 代わりに、交通が拡大するのに従って、トランクスの交通の量は増加します。 トランクスの数でない。
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個のトランクの最悪の場合があります。 サービスのトポロジーとCのクラスにNルータがあれば、これは(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本の流し台木があるので、結果は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トランクスで全体のトポロジーをかぶせることができます。
Li & Rekhter Informational [Page 5] RFC 2430 PASTE October 1998
李とRekhterの情報[5ページ]のRFC2430は1998年10月を貼ります。
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.
さらに、同様に扱われて、あるBest Effortトランクスと個々のBest Effort流れであるなら、IGPに続くどんなBest Effortトランクも例示するどんな必要性も経路を計算しませんでした。 これはLSPなしでパケットを直接進めることができるからです。 しかしながら、交通工学は、Best Effortトランクスが個々のBest Effort流れと異なって扱われるのを必要とするかもしれません、その結果、Best EffortトランクスのためにLSPsの具体化を必要とします。 集められたPriority流れを支持する終わりから終わりへのRSVPパケットにトンネルを堀らなければならないのでPriorityトランクスを例示しなければならないことに注意してください。
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.
また、他のトランクスで各トランクのためにラベルのスタックに新しいラベルを加えることによって、トランクスを集めることができます、事実上、単一のトンネルにトランクスを投げ込んで。 私たちが具体的に言うとそうしなければならないと、また、このドキュメントの目的のために、これがトランクであると考えられるか、またはこれは集められたトランクと呼ばれるでしょう。 それらの経路の部分を共有するなら、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などのように。 バックアップ胴体が確立されて、第一のトランクがサービスに戻るなら、バックアップ胴体は、非活性化されていて代わりに使用される第一のトランクであるかもしれません。
4.3 RSVP
4.3 RSVP
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]。
Li & Rekhter Informational [Page 6] RFC 2430 PASTE October 1998
李とRekhterの情報[6ページ]のRFC2430は1998年10月を貼ります。
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 Objectsの創造を考慮することによって、簡単な伸展性メカニズムを提供します。 また、この柔軟性で、私たちは資源予約状態に関連して推進状態の創設を許すことと同様に純粋な資源予約以外の情報のために分散状態を創設して、維持するために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つのタスクに独立しているのではなく、相互関連しているという観測から来ます。 独立しているセットの手順でそれぞれのこれらの機能を達成したどんな選択肢、機能の間の追加コーディネートを必要とするでしょう、より多くの複雑さをシステムに追加して。
Li & Rekhter Informational [Page 7] RFC 2430 PASTE October 1998
李とRekhterの情報[7ページ]のRFC2430は1998年10月を貼ります。
4.4 Traffic Engineering
4.4 交通工学
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の正確な支配力を与えることです。 標準のIGPsがそれぞれリンクするために唯一行政上割り当てられたメートル法に基づく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.
交互に、経路における最初のルータがトランクを確立できるように、Explicit Route Object(ERO)と共にRSVPなどのプロトコルを使用できます。 明白なルートの計算は、このドキュメントの範囲を超えていますが、トポロジーと手動で構成された代替手段に方針と静電気とダイナミックな帯域幅配分、混雑の問題を含むかもしれません。
4.5 Resource reservation
4.5 資源予約
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はローカルの方針に基づく予約をこの情報を見て、受け入れるか、または拒絶する能力を持っています。 この方針はネットワークが、Priority交通に備えても構わないと思っているというネットワークと集合容量で後押しされることができる交通取り扱い機能に関する規制を含んでいそうです。
Li & Rekhter Informational [Page 8] RFC 2430 PASTE October 1998
李とRekhterの情報[8ページ]のRFC2430は1998年10月を貼ります。
4.6 Inter-Provider SLAs (IPSs)
4.6 相互プロバイダーSLA(IPSs)
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.
これと同様のドキュメントは、今日、Best Effort交通を代表して存在して、じっと見る協定として知られています。 微分されたサービスを支持するじっと見る協定を広げていると、事実上、Inter-プロバイダーSLA(IPS)は創設されるでしょう。 そのような協定は1つのISPがもう片方のISPに提供する微分されたサービスのタイプを含むかもしれません、ISPが、もう片方のISPから受け入れる、運んでも構わないと思っているくらいの各サービスに関連している交通の量の上限と同様に。 さらに、IPSは第三者ISPから発するかもしれない交通の量で微分されたサービスと上限のタイプを制限して、IPSの1つの署名者からもう片方まで渡されるかもしれません。
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に関連している予想されたコストが左右対称でないなら、パーティーは、1つの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構造がIPSsを設立する技術的な基礎を提供することに注意してください、PASTEの範囲の外にそのようなIPSsを作成するのに必要な手順がありますが。
4.7 Traffic shaping and policing
4.7 交通形成と取り締まり
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.
ヘルプサポートIPSsに、特別な施設はISPの間の内部連絡のときに利用可能であるに違いありません。 これらのメカニズムが、Priority交通のトランクを伝えるネットワークが同意された交通特殊化と容量の中でそうするのを保障するのに必要です。 そのようなメカニズムの安易な例は1トランクあたり1個のベースで導入される象徴バケットシステムであるかもしれません。 同様に、トランク基礎あたりのaでトランクを受けるISPがISPの間の協定に従ってない交通しか受けるのを保障するメカニズムがあるのが必要です。
Li & Rekhter Informational [Page 9] RFC 2430 PASTE October 1998
李とRekhterの情報[9ページ]のRFC2430は1998年10月を貼ります。
4.8 Multilateral IPSs
4.8 多面的なIPSs
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にかかるかもしれません。 その結果、特定のトランクを確立するのは2つ以上のISPを必要とするかもしれません。 結果は多面的なIPSでしょう。役に立つ結果のために複数の参加団体を必要とするので、このタイプの協定は既存のインターネット商習慣に関して珍しいです。 また、一般的に受け入れられたサービスレベル定義がなければそこでは、多面的な定義であることが必要であり、この定義は同じパーティーの間のIPSsで使用されていた状態で互換性がないかもしれないので、これもやりがいがあります。
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を通して集められたトランクスを確証して、次に、顧客と共に彼らのトランクスに集めるのを収縮させるのは、より簡単であるかもしれません。 このように、多面的なIPSsを必要としないで、トランクスは複数の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 微分されたServicesとTraffic EngineeringのためのProvider Architecture(ペースト)
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.
確立するメカニズムがISPの向こう側にサービス連結部を微分したので、微分されたServicesとTraffic Engineering(PASTE)のためのProvider Architectureは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.
ネットワークは1トランクあたり1個のベースで特定の待ち行列アルゴリズムか低下計算などの特別な交通取り扱い操作を支持できます、これらのサービスがネットワークにおける、トランクスの数で比例するのを許容して。
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の間のトランクスの取り扱いのための協定は協定の両側で法的なドキュメンテーションと順応メカニズムの両方を必要とします。 トランクが単方向ので、送信機がアウトバウンドトラフィックをモニターして、形成するのは、十分です、受信機が交通プロフィールを取り締まりますが。
Li & Rekhter Informational [Page 10] RFC 2430 PASTE October 1998
李とRekhterの情報[10ページ]のRFC2430は1998年10月を貼ります。
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は既に地方の経路修理をする能力を含んでいます。 トランクの故障の場合、この能力で、RSVPはEROで抽象化を指定する能力と共に多くの失敗シナリオでトランクを復職させることができます。
6.0 Traffic flow in the PASTE architecture
6.0 PASTE構造における交通の流れ
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.
ノードD.Becauseにこれを横断する必要性が音声通話である、この音声通話のためのデータ・パケットがノードSで作成されると仮定してください。そうすれば、データ・パケットはPriorityパケットとしてコード化されます。 交通のクラスの中により多くの粒状があれば、これらのパケットは低いジターが欲しく、低低下好みを持っているとしてコード化されるかもしれません。 初めは、これはIPv4 ToSバイトの先行ビットにコード化されます。
6.1 Propagation of RSVP messages
6.1 RSVPメッセージの伝播
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メッセージを発生させます。 例えば、流れは、200ms. ThisメッセージがノードSの企業内情報通信網に通り抜けて、結局ノードSのISPに現れるより3kbpsに帯域幅を要求して、50ms以下のジターに神経が鈍く、以下の遅れを必要とするかもしれません。 これが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
ISP Fには、ここに、オプションにおけるかなりの緯度があります。 Fに関する要件はFのインフラストラクチャを出る前にトランクへの流れを置くことです。 Fがするかもしれない1つのことは最初のホップルータにおける入場コントロール機能を実行することです。 ここに、Fは、それに容量と能力があったならそれ自身のインフラストラクチャの向こう側に出口ルータE.Ifまで流れを運ぶのにおいて、入場コントロール決定が否定的であることを決定して、最初のホップルータはそうすることができます。
Li & Rekhter Informational [Page 11] RFC 2430 PASTE October 1998
李とRekhterの情報[11ページ]のRFC2430は1998年10月を貼ります。
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.
RSVPを使用することでノードSを知らせてください。 交互に、それはルータE.を出る経路に沿ったRSVP PATHメッセージを伝播できます。Thisは微分された流れにおける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 Fが維持するISP X、Y、およびZを通過して、バンド情報から経路情報の、または、オンなBGPの上のISP L.Basedで終わるトランクがあって、Node DはISP L.ExitルータEの顧客が要件は互換性があるというISP L.Assumingへのトランクの特性(例えば、残存容量)へのRSVP PATHメッセージの流れ要件に合って、次に、流れがトランクに集められるべきであることに注意するということであることが知られています。
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.に伝えられるところでItは結局、トランクの端に達して、次に、それがどこでルータU. PATHメッセージによってdecapsulatedされるかは、最終仕向地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.
ルータUからEまでのRESVメッセージがルータEへのトンネルを通って返さなければならないルータU.で慎重に終わりから終わりへのRSVP RESVメッセージを扱わなければならないことに注意してください。
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は出口ルータEによって使用されます。ISP L.にトランクを初期化して、維持する、このトランクへのRSVPメッセージはトランク自体の中に置かれませんが、終わりから終わりへのRSVPメッセージは置かれます。 PASTEの複数の重なっているRSVPセッションの存在は、簡単ですが、特定のRSVPセッションについて議論するとき、明白な列挙を必要とします。
6.2 Propagation of user data
6.2 利用者データの伝播
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.
流れの予約に従うISP Fのネットワークと結局S流動によって作成されたデータ・パケットが指すルータE.Atに行って、それらをMPLSラベルを与えて、トランクに置きます。 正常なMPLSの切り換えはISP Xのネットワークの向こう側にこのパケットを伝播するでしょう。 クラスコード化がMPLSラベルでIPv4ヘッダーの先行ビットからCoSビットまで伝播されるので同じ交通のクラスがまだ適用されていることに注意してください。 パケットがISP Xのネットワークを出るとき、ISP Yをtranisitingするはっきりとした目的のためにそれを別のトランクに集めることができます。
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.に向かってトランクが「反-集合」であり、結果として起こるトランクを送ります。Thisトランクは、ISP Zを通過して、ISP LでルータU.Atのこのポイント、パケットがトランクから移されて、RSVPによって計算された経路に沿って送られるデータを終えます。
Li & Rekhter Informational [Page 12] RFC 2430 PASTE October 1998
李とRekhterの情報[12ページ]のRFC2430は1998年10月を貼ります。
6.3 Trunk establishment and maintenance
6.3 トランク設立と維持
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 ZでISP FからISP X、Y、およびZまで走って、他の集められたトランクがISP Xで始めるISP L.で終わって、ISP Yを通過して、終わります。
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 Yがこの多面的な協定の一部でなく、ISP Xがこの協定あたりのISP Z.Alsoにトランクのキャリッジを供給するのに契約上原因となるというISPのFと、Xと、ZとL.Noteとの多面的な協定に基づいて確立されるかもしれません、そして、トンネルは、RSVPの使用でISP Fによって維持されて、初期化されて、維持されます、そして、この明白なルート、ISP X、およびISP Lが厳しいとして与えられているISP X、Z、およびL.Withinを記載する明白なルート物は跳びます; 規制は全くISP XとZ.Furtherの間の経路に置かれます、したがって、組のISP FとXの組、Z、およびL.Howeverを仲裁する他のISPがないように経路を抑制することがなくて、どのルータが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 FのルータのひとりによってISP X.For丈夫さに隣接して維持されます、そして、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.の間の二国間条約によって確立されるかもしれません。ISP Zはかかわりません。 2番目のトランクが強制的であるので、それはYのインフラストラクチャの中で最後のホップルータで終わります。 このトンネルは、RSVPの使用とISP Yのインフラストラクチャの中に最後のホップルータを記載する明白なルートで、初期化されて、維持されます。 最後のホップルータの失敗に関するケースに冗長を供給するために、ISP Xのルータに構成された複数の明白なルートがあります。 これらのルータはそれらの構成されたリストから1つの働く明白なルートを選択できます。 さらに、Xの第一のルータの失敗に対して冗長を提供するために、Xはバックアップ胴体をバックアップルータに提供します。
6.4 Robustness
6.4 丈夫さ
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つで終わる複数の明白なルート物は各トランクを構成できます。
Li & Rekhter Informational [Page 13] RFC 2430 PASTE October 1998
李とRekhterの情報[13ページ]のRFC2430は1998年10月を貼ります。
7.0 Security Considerations
7.0 セキュリティ問題
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.
Priority交通にはBest Effort交通より多くの'値'が本質的にあるので、慎重にPriority交通をネットワークに注ぐ能力を制御しなければなりません。 さらに、シグナリング情報がPriorityサービスのための特定の会計と結局支払いをもたらしそうであるので、Priority交通に関して合図するのは認証されなければなりません。 ISPが、それらが受け入れるPriority交通がそうであることを保障すると警告されて、事実上、前であることの状態で知られているaから跳んでください。 これが個人的なpeeringsに実現させるのが簡単である要件ですが、それが公共の内部連絡のときにはるかに難しいことに注意してください。 この理由で、公共の内部連絡のときにPriority交通を細心の注意を払って交換するべきです。
RSVP traffic needs to be authenticated. This can possibly be done through the use of the Integrity Object.
RSVP交通は、認証される必要があります。 Integrity Objectの使用でこれができます。
8.0 Conclusion
8.0 結論
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.
微分されたServicesとTraffic Engineering(PASTE)のためのProvider Architectureはインターネットで微分されたサービスを配備する強健で、スケーラブルな手段を提供します。 それは、クラスの特定の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需要を満たすためにスケーリングするために十分な構造であり、大きいサポート交通工学に微分されたサービスを前提として、インターネットで成長し続けることができます。
8.1 Acknowledgments
8.1 承認
Inspiration and comments about this document came from Noel Chiappa, Der-Hwa Gan, Robert Elz, Lisa Bourgeault, and Paul Ferguson.
このドキュメントの周りのインスピレーションとコメントはクリスマスChiappa、Der-Hwaガン、ロバートElz、リサBourgeault、およびポールファーガソンから来ました。
Li & Rekhter Informational [Page 14] RFC 2430 PASTE October 1998
李とRekhterの情報[14ページ]のRFC2430は1998年10月を貼ります。
9.0 References
9.0の参照箇所
[1] Rosen, E., Viswanathan, A., and R. Callon, "A Proposed
Architecture for MPLS", Work in Progress.
[1] ローゼン、E.、Viswanathan、A.、およびR.Callon、「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] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、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.とRekhterとY.とタッパンとD.とファリナッチとD.、Fedorkowと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.、Rekhter、Y.、ローゼン、E.、Viswanathan、A.、およびV.Srinivasan、「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] 「RSVPを使用することで明白な経路に予約をセットアップし」て、ガン、D.H.、ゲラン、R.、Kamat、S.、李、T.、およびE.ローゼンは進行中で働いています。
[6] Davie, B., Li, T., Rosen, E., and Y. Rekhter, "Explicit Route
Support in MPLS", Work in Progress.
[6] デイビー、B.、李、T.、ローゼン、E.、およびY.Rekhter、「MPLSでの明白なルートサポート」が進行中で働いています。
[7] http://www.anxo.com/
[7] http://www.anxo.com/
10.0 Authors' Addresses
10.0 作者のアドレス
Tony Li Juniper Networks, Inc. 385 Ravendale Dr. Mountain View, CA 94043
トニー李Juniperはマウンテンビュー、Inc.385Ravendale博士カリフォルニア 94043をネットワークでつなぎます。
Phone: +1 650 526 8006 Fax: +1 650 526 8001 EMail: tli@juniper.net
以下に電話をしてください。 +1 650 526、8006Fax: +1 8001年の650 526メール: tli@juniper.net
Yakov Rekhter cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134
サンノゼ、ヤコフRekhterコクチマスSystems Inc.170W.タスマン博士カリフォルニア 95134
EMail: yakov@cisco.com
メール: yakov@cisco.com
Li & Rekhter Informational [Page 15] RFC 2430 PASTE October 1998
李とRekhterの情報[15ページ]のRFC2430は1998年10月を貼ります。
11. Full Copyright Statement
11. 完全な著作権宣言文
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Li & Rekhter Informational [Page 16]
李とRekhter情報です。[16ページ]
一覧
スポンサーリンク
