RFC4804 日本語訳
4804 Aggregation of Resource ReSerVation Protocol (RSVP) Reservationsover MPLS TE/DS-TE Tunnels. F. Le Faucheur, Ed.. February 2007. (Format: TXT=69473 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Le Faucheur, Ed. Request for Comments: 4804 Cisco Systems, Inc. Category: Standards Track February 2007
ワーキンググループF.Le Faucheur、エドをネットワークでつないでください。コメントのために以下を要求してください。 4804年のシスコシステムズInc.カテゴリ: 標準化過程2007年2月
Aggregation of Resource ReSerVation Protocol (RSVP)
Reservations over MPLS TE/DS-TE Tunnels
MPLS DS Te/TE Tunnelsの上の資源予約プロトコル(RSVP)予約の集合
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
RFC 3175 specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-end reservations over aggregate RSVP reservations. This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels. This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels.
RFC3175は集合RSVPの予約の上のResource ReSerVationプロトコル(RSVP)終わりから終わりへの予約の集合を指定します。 このドキュメントはMPLS Traffic Engineering(TE)トンネルかMPLS Diffserv意識しているMPLS Traffic Engineering(DS-TE)トンネルの上のRSVP終わりから終わりへの予約の集合を指定します。 このアプローチは、RFC3175に基づいていて、単に集合RSVPの予約の代わりにMPLS TEトンネルの上の操作のための対応する手順を変更します。 ネットワークのコアの装置が終わりから終わりへのRSVP予約に気づかなく、MPLS TEトンネルを意識しているだけであるのでスケーラブルな方法における非常に多くの流れの入場コントロールを達成するのにこのアプローチを使用できます。
Faucheur Standards Track [Page 1] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[1ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
Table of Contents
目次
1. Introduction ....................................................3
2. Specification of Requirements ...................................7
3. Definitions .....................................................7
4. Operations of RSVP Aggregation over TE with
Pre-established Tunnels .........................................8
4.1. Reference Model ............................................9
4.2. Receipt of E2E Path Message by the Aggregator ..............9
4.3. Handling of E2E Path Message by Transit LSRs ..............11
4.4. Receipt of E2E Path Message by the Deaggregator ...........11
4.5. Handling of E2E Resv Message by the Deaggregator ..........12
4.6. Handling of E2E Resv Message by the Aggregator ............12
4.7. Forwarding of E2E Traffic by the Aggregator ...............14
4.8. Removal of E2E Reservations ...............................14
4.9. Removal of the TE Tunnel ..................................14
4.10. Example Signaling Flow ...................................15
5. IPv4 and IPv6 Applicability ....................................16
6. E2E Reservations Applicability .................................16
7. Example Deployment Scenarios ...................................16
7.1. Voice and Video Reservations Scenario .....................16
7.2. PSTN/3G Voice Trunking Scenario ...........................17
8. Security Considerations ........................................18
9. Acknowledgments ................................................20
10. Normative References ..........................................20
11. Informative References ........................................21
Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator ........23
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels
for VoIP Call Admission Control (CAC) ................25
1. 序論…3 2. 要件の仕様…7 3. 定義…7 4. プレ確立したTunnelsとのTeの上のRSVP集合の操作…8 4.1. 参照モデル…9 4.2. アグリゲータによる2EのE経路メッセージの領収書…9 4.3. トランジットLSRsによる2EのE経路メッセージの取り扱い…11 4.4. Deaggregatorによる2EのE経路メッセージの領収書…11 4.5. Deaggregatorによる2EのE Resvメッセージの取り扱い…12 4.6. アグリゲータによる2EのE Resvメッセージの取り扱い…12 4.7. アグリゲータによる2ユーロのE交通の推進…14 4.8. 2ユーロのE予約の取り外し…14 4.9. Teトンネルの取り外し…14 4.10. 例のシグナリングは流れます…15 5. IPv4とIPv6の適用性…16 6. 2EのE予約の適用性…16 7. 例の展開シナリオ…16 7.1. 声とビデオ予約シナリオ…16 7.2. PSTN/3Gは中継方式シナリオを声に出します…17 8. セキュリティ問題…18 9. 承認…20 10. 標準の参照…20 11. 有益な参照…21 付録A--RSVPアグリゲータにおけるRSVPプロキシの任意の使用…23 付録B--DSTEの上のRSVP集合の例の用法はVoIPコール許可コントロール(CAC)のためにトンネルを堀ります…25
Faucheur Standards Track [Page 2] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[2ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
1. Introduction
1. 序論
The Integrated Services (Intserv) [INT-SERV] architecture provides a means for the delivery of end-to-end Quality of Service (QoS) to applications over heterogeneous networks.
Integrated Services(Intserv)[INT-SERV]構造は異機種ネットワークの上でService(QoS)の終わりから終わりへのQualityの配送のための手段をアプリケーションに提供します。
[RSVP] defines the Resource reSerVation Protocol that can be used by applications to request resources from the network. The network responds by explicitly admitting or rejecting these RSVP requests. Certain applications that have quantifiable resource requirements express these requirements using Intserv parameters as defined in the appropriate Intserv service specifications ([GUARANTEED], [CONTROLLED]).
[RSVP]はネットワークからリソースを要求するのにアプリケーションで使用できるResource reSerVationプロトコルを定義します。 ネットワークは、明らかにこれらのRSVP要求を認めるか、または拒絶することによって、応じます。 定量化可能なリソース要件を持っているあるアプリケーションが、適切なIntservサービス仕様[GUARANTEED][CONTROLLED)に基づき定義されるようにIntservパラメタを使用することでこれらの要件を言い表します。
The Differentiated Services (DiffServ) architecture ([DIFFSERV]) was then developed to support the differentiated treatment of packets in very large scale environments. In contrast to the per-flow orientation of Intserv and RSVP, Diffserv networks classify packets into one of a small number of aggregated flows or "classes", based on the Diffserv codepoint (DSCP) in the packet IP header. At each Diffserv router, packets are subjected to a "per-hop behavior" (PHB), which is invoked by the DSCP. The primary benefit of Diffserv is its scalability. Diffserv eliminates the need for per-flow state and per-flow processing, and therefore scales well to large networks.
そして、Differentiated Services(DiffServ)構造([DIFFSERV])は、非常に大きいスケール環境における、パケットの微分された処理を支持するために開発されました。 IntservとRSVPの1流れあたりのオリエンテーションと対照して、Diffservネットワークはパケットを少ない数の集められた流れか「クラス」の1つに分類します、パケットIPヘッダーのDiffserv codepoint(DSCP)に基づいて。 それぞれのDiffservルータでは、パケットは「1ホップあたりの振舞い」(PHB)にかけられます。(それは、DSCPによって呼び出されます)。 Diffservの主要便益はそのスケーラビリティです。 Diffservは大きいネットワークによく1流れあたりの状態と1流れあたりの処理の必要性を排泄して、したがって、スケールを排泄します。
However, DiffServ does not include any mechanism for communication between applications and the network. Thus, as detailed in [INT-DIFF], significant benefits can be achieved by using Intserv over Diffserv including resource-based admission control, policy- based admission control, assistance in traffic identification/classification, and traffic conditioning. As discussed in [INT-DIFF], Intserv can operate over Diffserv in multiple ways. For example, the Diffserv region may be statically provisioned or RSVP aware. When it is RSVP aware, several mechanisms may be used to support dynamic provisioning and topology-aware admission control, including aggregate RSVP reservations, per-flow RSVP, or a bandwidth broker. The advantage of using aggregate RSVP reservations is that it offers dynamic, topology-aware admission control over the Diffserv region without per-flow reservations and the associated level of RSVP signaling in the Diffserv core. In turn, this allows dynamic, topology-aware admission control of flows requiring QoS reservations over the Diffserv core even when the total number of such flows carried over the Diffserv core is extremely large.
しかしながら、DiffServはアプリケーションとネットワークとのコミュニケーションのためのどんなメカニズムも含んでいません。 したがって、[INT-DIFF]で詳しく述べられるように、リソースベースの入場コントロール、方針ベースの入場コントロール、交通識別/分類における支援、および交通調節を含んでいて、Diffservの上でIntservを使用することによって、重要な利益を達成できます。 [INT-DIFF]で議論するように、IntservはDiffservの上で複数の方法で作動できます。 例えば、Diffserv領域は、静的に食糧を供給されるか、またはRSVP意識しているかもしれません。 それがRSVP意識しているとき、数個のメカニズムがダイナミックな食糧を供給していてトポロジー意識している入場コントロールを支持するのに使用されるかもしれません、集合RSVPの予約、1流れあたりのRSVP、または帯域幅ブローカーを含んでいて。 集合RSVPの予約を使用する利点はDiffservコアで1流れあたりの予約と関連レベルのRSVPシグナリングなしでDiffserv領域のダイナミックで、トポロジー意識している入場コントロールを提供するということです。 順番に、これはDiffservコアの上まで運ばれたそのような流れの総数が非常に大きいときにさえDiffservコアの上のQoSの予約を必要とする流れのダイナミックで、トポロジー意識している入場コントロールを許します。
[RSVP-AGG] and [RSVP-GEN-AGG] describe in detail how to perform such aggregation of end-to-end RSVP reservations over aggregate RSVP reservations in a Diffserv cloud. They establish an architecture
[RSVP-AGG]と[RSVP-GEN-AGG]は詳細であり集合RSVPの予約の上の終わりから終わりへのRSVP予約のそのような集合がDiffserv雲でどのように働いたかを記述します。 彼らは構造を確立します。
Faucheur Standards Track [Page 3] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[3ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
where multiple end-to-end RSVP reservations sharing the same ingress router (Aggregator) and egress router (Deaggregator) at the edges of an "aggregation region" can be mapped onto a single aggregate reservation within the aggregation region. This considerably reduces the amount of reservation state that needs to be maintained by routers within the aggregation region. Furthermore, traffic belonging to aggregate reservations is classified in the data path purely using Diffserv marking.
複数であるところでは、終わりから終わりへのRSVP「集合領域」の縁で同じイングレスルータ(アグリゲータ)と出口ルータ(Deaggregator)を共有する予約は集合領域の中のただ一つの集合予約に写像できます。 これは集合領域の中のルータによって維持される必要がある予約州の量をかなり減少させます。 その上、集合予約に属す交通が、データ経路で純粋にDiffservマークを使用することで分類されます。
[MPLS-TE] describes how MPLS Traffic Engineering (TE) tunnels can be used to carry arbitrary aggregates of traffic for the purposes of traffic engineering. [RSVP-TE] specifies how such MPLS TE tunnels can be established using RSVP-TE signaling. MPLS TE uses Constraint-Based Routing to compute the path for a TE tunnel. Then, Admission Control is performed during the establishment of TE tunnels to ensure they are granted their requested resources.
[MPLS-TE]は交通工学の目的のための交通の任意の集合を運ぶのにどうMPLS Traffic Engineering(TE)トンネルを使用できるかを説明します。 [RSVP-TE]はRSVP-TEシグナリングを使用することでどうそのようなMPLS TEトンネルを確立できるかを指定します。 MPLS TEは、TEトンネルに経路を計算するのにベースのConstraintルート設定を使用します。 そして、Admission Controlは、それらの要求されたリソースがそれらに与えられるのを保証するためにTEトンネルの設立の間、実行されます。
[DSTE-REQ] presents the Service Providers requirements for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). With DS-TE, separate DS-TE tunnels can be used to carry different Diffserv classes of traffic, and different resource constraints can be enforced for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling extensions as well as OSPF and Intermediate System to Intermediate System (IS-IS) extensions for support of DS-TE.
[DSTE-REQ]はDiffserv意識しているMPLS Traffic Engineering(DS-TE)のサポートのためのService Providers要件を提示します。 DS-TEと共に、異なったDiffservのクラスの交通を運ぶのに別々のDS-TEトンネルを使用できます、そして、これらの異なったクラスのために異なったリソース規制を励行できます。 [DSTE-プロト]がOSPFとIntermediate Systemと同様にRSVP-TEシグナリング拡張子をIntermediate Systemに指定する、(-、)、DS-TEのサポートのための拡大。
In the rest of this document we will refer to both TE tunnels and DS-TE tunnels simply as "TE tunnels".
このドキュメントの残りでは、私たちは両方のTEトンネルについて言及するつもりです、そして、DS-TEは単に「TEはトンネルを堀る」ようにトンネルを堀ります。
TE tunnels have much in common with the aggregate RSVP reservations used in [RSVP-AGG] and [RSVP-GEN-AGG]:
TEトンネルには、[RSVP-AGG]と[RSVP-GEN-AGG]で使用される集合RSVPの予約と共用して多くがあります:
- A TE tunnel is subject to Admission Control and thus is
effectively an aggregate bandwidth reservation.
- TEトンネルは、Admission Controlを受けることがあって、その結果、事実上、集合帯域幅の予約です。
- In the data plane, packet scheduling relies exclusively on
Diffserv classification and PHBs.
- データ飛行機では、パケットスケジューリングは排他的にDiffserv分類とPHBsに依存します。
- Both TE tunnels and aggregate RSVP reservations are controlled
by "intelligent" devices on the edge of the "aggregation core"
(Head-end and Tail-end in the case of TE tunnels; Aggregator and
Deaggregator in the case of aggregate RSVP reservations.
- TEトンネルと集合RSVPの予約の両方が「集合コア」の縁の「知的」装置によって制御されます。(TEに関するケースへのギヤエンドとTail-終わりはトンネルを堀ります;、集合RSVPの予約の場合におけるアグリゲータとDeaggregator。
- Both TE tunnels and aggregate RSVP reservations are signaled
using the RSVP protocol (with some extensions defined in
[RSVP-TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE
tunnels).
- RSVPプロトコル(いくつかの拡大が[RSVP-TE]と[DSTE-プロト]でそれぞれTEトンネルとDS-TEトンネルと定義されている)を使用することでTEトンネルと集合RSVPの予約の両方が合図されます。
Faucheur Standards Track [Page 4] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[4ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
This document provides a detailed specification for performing aggregation of end-to-end RSVP reservations over MPLS TE tunnels (which act as aggregate reservations in the core). This document builds on the RSVP Aggregation procedures defined in [RSVP-AGG] and [RSVP-GEN-AGG], and only changes those where necessary to operate over TE tunnels. With [RSVP-AGG] and [RSVP-GEN-AGG], a lot of responsibilities (such as mapping end-to-end reservations to Aggregate reservations and resizing the Aggregate reservations) are assigned to the Deaggregator (which is the equivalent of the tunnel Tail-end) while with TE, the tunnels are controlled by the tunnel Head-end. Hence, the main change over the RSVP Aggregations procedures defined in [RSVP-AGG] and [RSVP-GEN-AGG] is to modify these procedures to reassign responsibilities from the Deaggregator to the Aggregator (i.e., the tunnel Head-end).
このドキュメントはMPLS TEトンネル(コアでの集合予約としてのどの行為)の上に終わりから終わりへのRSVP予約の集合を実行するための仕様詳細を供給するか。 このドキュメントは、[RSVP-AGG]と[RSVP-GEN-AGG]で定義されたRSVP Aggregation手順に建てて、TEトンネルの上で作動するために必要であるところのそれらを変えるだけです。 トンネルはTEと共にトンネルHead-エンドまでに制御されますが、[RSVP-AGG]と[RSVP-GEN-AGG]と共に多くの責任(終わりから終わりへの予約をAggregateの予約に写像して、Aggregateの予約をリサイズなどなどの)がDeaggregator(トンネルTail-エンドの同等物である)に割り当てられます。 したがって、[RSVP-AGG]と[RSVP-GEN-AGG]で定義されたRSVP Aggregations手順の上の主な変化は、DeaggregatorからAggregator(すなわち、トンネルHead-エンド)まで責任を再選任するようにこれらの手順を変更することになっています。
[LSP-HIER] defines how to aggregate MPLS TE Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. This involves nesting of end-to-end LSPs into an aggregate LSP in the core (by using the label stack construct). Since end-to-end TE LSPs are themselves signaled with RSVP-TE and reserve resources at every hop, this can be looked at as a form of aggregation of RSVP(-TE) reservations over MPLS TE tunnels. This document capitalizes on the similarities between nesting of TE LSPs over TE tunnels and RSVP aggregation over TE tunnels, and reuses the procedures of [LSP-HIER] wherever possible.
[LSP-HIER]はそのようなLSPsの階層構造を作成することによってMPLS TE Label Switched Paths(LSPs)に集める方法を定義します。 これは、コア(ラベルスタック構造物を使用するのによる)の集合LSPに終わりから終わりへのLSPsを巣ごもらせることを伴います。 終わりから終わりへのTE LSPsがあらゆるホップでRSVP-TEと蓄えのリソースで合図されるので、MPLS TEの上のRSVP(-TE)の予約の集合のフォームがトンネルを堀るとき、これを見ることができます。 このドキュメントは、TEトンネルの上でTEトンネルとRSVP集合でTE LSPsを巣ごもらせることの間の類似性を利用して、どこでも、可能であるところで[LSP-HIER]の手順を再利用します。
This document also builds on the "RSVP over Tunnels" concepts of RFC 2746 [RSVP-TUN]. It differs from that specification in the following ways:
また、このドキュメントはRFC2746[RSVP-TUN]の「Tunnelsの上のRSVP」概念に建てられます。 それは以下の方法でその仕様と異なっています:
- This document describes operation over MPLS tunnels, whereas RFC
2746 describes operation with IP tunnels. One consequence of
this difference is the need to deal with penultimate hop popping
(PHP).
- このドキュメントはMPLSトンネルの上の操作について説明しますが、RFC2746はIPトンネルによる操作について説明します。 この違いの1つの結果が終わりから二番目のホップの飛び出し(PHP)に対処する必要性です。
- MPLS-TE tunnels inherently reserve resources, whereas the
tunnels in RFC 2746 do not have resource reservations by
default. This leads to some simplifications in the current
document.
- MPLS-TEトンネルは本来リソースを予約しますが、RFC2746のトンネルには、資源予約がデフォルトでありません。 これは現在のドキュメントにおけるいくつかの簡素化に通じます。
- This document builds on the fact that there is exactly one
aggregate reservation per MPLS-TE tunnel, whereas RFC 2746
permits a model where one reservation is established on the
tunnel path for each end-to-end flow.
- このドキュメントはMPLS-TEトンネルあたり1つの集合予約がまさにあるという事実に建てられますが、RFC2746は1つの予約が終わりから終わりへのそれぞれの流動のためにトンネル経路で確立されるモデルを可能にします。
Faucheur Standards Track [Page 5] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[5ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
- We have assumed in the current document that a given MPLS-TE
tunnel will carry reserved traffic and nothing but reserved
traffic, which negates the requirement of RFC 2746 to
distinguish reserved and non-reserved traffic traversing the
same tunnel by using distinct encapsulations.
- 私たちは、現在のドキュメントで与えられたMPLS-TEトンネルが予約された交通と予約された交通だけを運ぶと思いました。(交通はRFC2746が異なったカプセル化を使用することによって同じトンネルを横断する予約されて非予約された交通を区別するという要件を否定します)。
- There may be several MPLS-TE tunnels that share common Head-end
and Tail-end routers, with the Head-end policy determining which
tunnel is appropriate for a particular flow. This scenario does
not appear to be addressed in RFC 2746.
- 一般的なHead-終わりとTail-終わりのルータを共有するいくつかのMPLS-TEトンネルがあるかもしれません、Head-終わりの方針が、特定の流れに、どのトンネルが適切であるかを決定していて。 このシナリオはRFC2746に記述されるように見えません。
At the same time, this document does have many similarities with RFC 2746. MPLS-TE tunnels are "type 2 tunnels" in the nomenclature of RFC 2746:
同時に、このドキュメントには、RFC2746がある多くの類似性があります。 RFC2746の用語体系でMPLS-TEトンネルは「タイプ2トンネル」です:
"The (logical) link may be able to promise that some overall level
of resources is available to carry traffic, but not to allocate
resources specifically to individual data flows".
「(論理的)のリンクは、特に個々のデータフローにリソースを割り当てるのではなく、何らかの総合的なレベルのリソースが交通を運ぶために利用可能であると約束できるかもしれません。」
Aggregation of end-to-end RSVP reservations over TE tunnels combines the benefits of [RSVP-AGG] and [RSVP-GEN-AGG] with the benefits of MPLS, including the following:
TEトンネルの上の終わりから終わりへのRSVP予約の集合は[RSVP-AGG]と[RSVP-GEN-AGG]の利益をMPLSの利益に結合します、以下を含んでいて:
- Applications can benefit from dynamic, topology-aware,
resource-based admission control over any segment of the end-
to-end path, including the core.
- アプリケーションは終わりまでの端の経路のどんなセグメントのダイナミックで、トポロジー意識していて、リソースベースの入場コントロールも利益を得ることができます、コアを含んでいて。
- As per regular RSVP behavior, RSVP does not impose any burden on
routers where such admission control is not needed (for example,
if the links upstream and downstream of the MPLS TE core are
vastly over-engineered compared to the core capacity, admission
control is not required on these over-engineered links and RSVP
need not be processed on the corresponding router hops).
- 定期的なRSVPの振舞いに従って、RSVPはルータでのそのような入場コントロールが必要でない(例えば、コア容量と比べて、MPLS TEコアの上流と川下はリンクであるなら広大に過剰設計されます、そして、入場コントロールはこれらの過剰設計されたリンクの上に必要ではありません、そして、RSVPは対応するルータホップで処理される必要はありません)少しの負担も課しません。
- The core scalability is not affected (relative to the
traditional MPLS TE deployment model) since the core remains
unaware of end-to-end RSVP reservations and only has to maintain
aggregate TE tunnels since the datapath classification and
scheduling in the core relies purely on the Diffserv mechanism
(or more precisely the MPLS Diffserv mechanisms, as specified in
[DIFF-MPLS]).
- コアが終わりから終わりへのRSVP予約に気づかないままであり、datapath分類以来の集合TEトンネルが維持されるだけでよくて、中でコアの計画をするとDiffservメカニズム(または、より正確に中で指定されるとしてのMPLS Diffservメカニズム[DIFF-MPLS])が純粋に当てにされるので、コアスケーラビリティは影響を受けません(伝統的なMPLS TE展開モデルに比例した)。
- The aggregate reservation (and thus the traffic from the
corresponding end to end reservations) can be network engineered
via the use of Constraint based routing (e.g., affinity,
optimization on different metrics) and when needed can take
advantage of resources on other paths than the shortest path.
- Constraintの使用で設計されたネットワークがベースのルーティングであったかもしれなく(例えば、親近感、異なった測定基準における最適化)、必要であると、集合条件(そして、その結果、予約を終わらせる対応する終わりからの交通)は最短パス以外の経路に関するリソースを利用できます。
Faucheur Standards Track [Page 6] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[6ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
- The aggregate reservations (and thus the traffic from the
corresponding end-to-end reservations) can be protected against
failure through the use of MPLS Fast Reroute.
- MPLS Fast Rerouteの使用による失敗に対して集合条件(そして、その結果、終わりから終わりへの対応する予約からの交通)を保護できます。
This document, like [RSVP-AGG] and [RSVP-GEN-AGG], covers aggregation of unicast sessions. Aggregation of multicast sessions is for further study.
[RSVP-AGG]と[RSVP-GEN-AGG]のように、このドキュメントはユニキャストセッションの集合をカバーしています。 さらなる研究にはマルチキャストセッションの集合があります。
2. Specification of Requirements
2. 要件の仕様
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[キーワード]で説明されるように本書では解釈されることであるべきですか?
3. Definitions
3. 定義
For readability, a number of definitions from [RSVP-AGG] as well as definitions for commonly used MPLS TE terms are provided here:
読み易さにおいて、一般的に使用されたMPLS TE期間の定義と同様に[RSVP-AGG]からの多くの定義をここに提供します:
Aggregator This is the process in (or associated with) the
router at the ingress edge of the aggregation region
(with respect to the end-to-end RSVP reservation)
and behaving in accordance with [RSVP-AGG]. In this
document, it is also the TE tunnel Head-end.
アグリゲータThisは集合領域(終わりから終わりへのRSVP予約に関する)のイングレス縁の(または、交際します)ルータにおける過程と[RSVP-AGG]に従って、振る舞うことです。 本書では、また、TEトンネルHead-エンドです。
Deaggregator This is the process in (or associated with) the
router at the egress edge of the aggregation region
(with respect to the end-to-end RSVP reservation)
and behaving in accordance with [RSVP-AGG]. In this
document, it is also the TE tunnel Tail-end
Deaggregator Thisは集合領域(終わりから終わりへのRSVP予約に関する)の出口縁の(または、交際します)ルータにおける過程と[RSVP-AGG]に従って、振る舞うことです。 本書では、また、TEトンネルTail-エンドです。
E2E End to end
終わらせる2EのE終わり
E2E Reservation This is an RSVP reservation such that:
2EのE予約This RSVPの予約がそのようなものであるので:
(i) corresponding Path messages are initiated
upstream of the Aggregator and terminated
downstream of the Deaggregator, and
そして(i) 対応するPathメッセージがAggregatorの開始している上流とDeaggregatorの終えられた川下である。
(ii) corresponding Resv messages are initiated
downstream of the Deaggregator and terminated
upstream of the Aggregator, and
そして(ii)対応するResvメッセージがDeaggregatorの開始している川下とAggregatorの終えられた上流である。
(iii) this RSVP reservation is aggregated over an
MPLS TE tunnel between the Aggregator and
Deaggregator.
(iii) このRSVPの予約はAggregatorとDeaggregatorの間のMPLS TEトンネルの上で集められます。
Faucheur Standards Track [Page 7] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[7ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
An E2E RSVP reservation may be a per-flow
reservation. Alternatively, the E2E reservation may
itself be an aggregate reservation of various types
(e.g., Aggregate IP reservation, Aggregate IPsec
reservation). See Section 5 and 6 for more details
on the types of E2E RSVP reservations. As per
regular RSVP operations, E2E RSVP reservations are
unidirectional.
1流れあたりE2E RSVPの予約は1つの予約であるかもしれません。 あるいはまた、2ユーロのEの予約がそうするかもしれない、それ自体、様々なタイプ(例えば、Aggregate IPの予約、Aggregate IPsecの予約)の集合予約になってください。 2ユーロのE RSVPの予約のタイプに関するその他の詳細に関してセクション5と6を見てください。 定期的なRSVP操作に従って、2ユーロのE RSVPの予約が単方向です。
Head-end This is the Label Switch Router responsible for
establishing, maintaining, and tearing down a given
TE tunnel.
ギヤエンドThisは与えられたTEトンネルを確立して、維持して、取りこわすのに責任があるLabel Switch Routerです。
Tail-end This is the Label Switch Router responsible for
terminating a given TE tunnel.
末端Thisは与えられたTEトンネルを終えるのに責任があるLabel Switch Routerです。
Transit LSR This is a Label Switch Router that is on the path of
a given TE tunnel and is neither the Head-end nor
the Tail-end.
トランジットLSR Thisは与えられたTEトンネルの経路にあるLabel Switch Routerであり、Head-終わりでなくてまたTail-終わりではありません。
4. Operations of RSVP Aggregation over TE with Pre-established Tunnels
4. プレ確立したTunnelsとのTeの上のRSVP集合の操作
[RSVP-AGG] and [RSVP-GEN-AGG] support operations both in the case where aggregate RSVP reservations are pre-established and where Aggregators and Deaggregators have to dynamically discover each other and dynamically establish the necessary aggregate RSVP reservations.
[RSVP-AGG]と[RSVP-GEN-AGG]サポート操作はケースの中、そして、集合RSVPの予約があらかじめ確立されて、AggregatorsとDeaggregatorsがダイナミックに互いを発見しなければならないダイナミックに必要な集合RSVPの予約を確立します。
Similarly, RSVP Aggregation over TE tunnels could operate both in the case where the TE tunnels are pre-established and where the tunnels need to be dynamically established.
同様に、TEトンネルの上のRSVP AggregationはTEトンネルがあらかじめ確立されるケースの中と、そして、トンネルがダイナミックに設立される必要があるところで作動できました。
In this document we provide a detailed description of the procedures in the case where TE tunnels are already established. These procedures are based on those defined in [LSP-HIER]. The routing aspects discussed in Section 3 of [LSP-HIER] are not relevant here because those aim at allowing the constraint based routing of end- to-end TE LSPs to take into account the (aggregate) TE tunnels. In the present document, the end-to-end RSVP reservations to be aggregated over the TE tunnels rely on regular SPF routing. However, as already mentioned in [LSP-HIER], we note that a TE tunnel may be advertised into IS-IS or OSPF, to be used in normal SPF by nodes upstream of the Aggregator. This would affect SPF routing and thus routing of end-to-end RSVP reservations. The control of aggregation boundaries discussed in Section 6 of [LSP-HIER] is also not relevant here. This uses information exchanged in GMPLS protocols to dynamically discover the aggregation boundary. In this document, TE tunnels are pre-established, so that the aggregation boundary can be easily inferred. The signaling aspects discussed in Section 6.2 of
本書では私たちはTEトンネルが既に確立される場合における、手順の詳述を提供します。 これらの手順は[LSP-HIER]で定義されたものに基づいています。 それらが目的とされるので、[LSP-HIER]のセクション3で議論したルーティング局面は(集合)のTEトンネルを考慮に入れるために終わりまでの終わりのTE LSPsのベースのルーティングを規制に許すところでここで関連していません。 現在のドキュメントでは、終わりから終わりへのRSVP TEトンネルの上で集められるべき予約は通常のSPFルーティングを当てにします。 しかしながら、私たちが、[LSP-HIER]で既に言及されるようにTEトンネルに広告を出すかもしれないことに注意する、-、または、OSPF、正常なSPFでAggregatorのノード上流によって使用されるために。 これは終わりから終わりへのRSVP予約のSPFルーティングとその結果ルーティングに影響するでしょう。 また、[LSP-HIER]のセクション6で議論した集合境界のコントロールもここで関連していません。 これはダイナミックに集合境界を発見するためにGMPLSプロトコルで交換された情報を使用します。 本書では、TEトンネルは、容易に集合境界を推論できるようにあらかじめ確立されます。 セクション6.2で議論した局面に合図します。
Faucheur Standards Track [Page 8] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[8ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
[LSP-HIER] apply to the establishment/termination of the aggregate TE tunnels when this is triggered by GMPLS mechanisms (e.g., as a result of an end-to-end TE LSP establishment request received at the aggregation boundary). As this document assumes pre-established tunnels, those aspects are not relevant here. The signaling aspects discussed in Section 6.1 of [LSP-HIER] relate to the establishment/maintenance of the end-to-end TE LSPs over the aggregate TE tunnel. This document describes how to use the same procedures as those specified in Section 6.1 of [LSP-HIER], but for the establishment of end-to-end RSVP reservations (instead of end- to-end TE LSPs) over the TE tunnels. This is covered further in Section 4 of the present document.
GMPLSメカニズム(例えば、終わりから終わりへのTE LSP設立集合境界に受け取られた要求の結果、)によってこれが引き起こされるとき、[LSP-HIER]は集合TEトンネルの設立/終了に適用します。 このドキュメントがプレ確立したトンネルを仮定するとき、それらの局面はここで関連していません。 [LSP-HIER]のセクション6.1で議論したシグナリング局面は集合TEトンネルの上の終わりから終わりへのTE LSPsの設立/維持に関連します。 このドキュメントはTEトンネルの上でものが[LSP-HIER]のセクション6.1で指定しましたが、終わりから終わりへのRSVP予約の設立に同じ手順を用いる(終わりまでの終わりのTE LSPsの代わりに)方法を説明します。 これは現在のドキュメントのセクション4で、より遠くに覆われています。
Pre-establishment of the TE tunnels may be triggered by any mechanisms including; for example, manual configuration or automatic establishment of a TE tunnel mesh through dynamic discovery of TE Mesh membership as allowed in [AUTOMESH].
TEトンネルのプレ設立はどんなメカニズム包含でも引き起こされるかもしれません。 例えば、TEトンネルの手動の構成か自動設立が[AUTOMESH]に許容されているようにTE Mesh会員資格のダイナミックな発見でかみ合います。
Procedures in the case of dynamically established TE tunnels are for further studies.
さらなる研究にはダイナミックに設立されたTEトンネルの場合における手順があります。
4.1. Reference Model
4.1. 規範モデル
|----| |----|
H--| R |\ |-----| |------| /| R |--H
H--| |\\| | |---| | |//| |--H
|----| \| He/ | | T | | Te/ |/ |----|
| Agg |=======================| Deag |
/| | | | | |\
H--------//| | |---| | |\\--------H
H--------/ |-----| |------| \--------H
|----| |----| H--| R|\ |-----| |------| /| R|--H H--| |\\| | |---| | |//| |--H|----| \| 彼、/| | T| | Te/|/ |----| | Agg|=======================| Deag| /| | | | | |\H--------//| | |---| | |\\--------H H--------/ |-----| |------| \--------H
H = Host requesting end-to-end RSVP reservations R = RSVP router He/Agg = TE tunnel Head-end/Aggregator Te/Deag = TE tunnel Tail-end/Deaggregator T = Transit LSR
ホスト要求終わりから終わりへのRSVP予約H=RがRSVPルータと等しい、彼、TEトンネルTail-エンド/Deaggregator/Agg=TEトンネルHead-エンド/アグリゲータTe/Deag=TはトランジットLSRと等しいです。
-- = E2E RSVP reservation == = TE tunnel
-- 2EのE RSVP予約==TEトンネルと等しいです。
4.2. Receipt of E2E Path Message by the Aggregator
4.2. アグリゲータによる2EのE経路メッセージの領収書
The first event is the arrival of the E2E Path message at the Aggregator. The Aggregator MUST follow traditional RSVP procedures for the processing of this E2E path message augmented with the extensions documented in this section.
最初の出来事はAggregatorの2EのE Pathメッセージの到着です。 Aggregatorは拡大がこのセクションで記録されている状態で増大するこの2EのE経路メッセージの処理のための伝統的なRSVP手順に従わなければなりません。
Faucheur Standards Track [Page 9] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[9ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
The Aggregator MUST first attempt to map the E2E reservation onto a TE tunnel. This decision is made in accordance with routing information as well as any local policy information that may be available at the Aggregator. Examples of such policies appear in the following paragraphs. Just for illustration purposes, among many other criteria, such mapping policies might take into account the Intserv service type, the Application Identity [RSVP-APPID], and/or the signaled preemption [RSVP-PREEMP] of the E2E reservation (for example, the aggregator may take into account the E2E reservations RSVP preemption priority and the MPLS TE tunnel setup and/or hold priorities when mapping the E2E reservation onto an MPLS TE tunnel).
Aggregatorは、最初に、2ユーロのEの予約をTEトンネルに写像するのを試みなければなりません。 どんなAggregatorで利用可能であるかもしれないローカルの方針情報と同様にルーティング情報によると、この決定をします。 そのような方針に関する例は以下のパラグラフに現れます。 まさしくイラスト目的のために、方針をそのような写像であるなら、他の多くの評価基準の中では、2ユーロのEの予約のIntservサービスタイプ、Application Identity[RSVP-APPID]、そして/または、合図された先取り[RSVP-PREEMP]は考慮に入れられるかもしれません(2ユーロのEの予約をMPLS TEトンネルに写像するとき、例えば、アグリゲータは、2ユーロのE予約RSVP先取り優先権とMPLS TEトンネルセットアップを考慮に入れる、そして/または、優位に立つかもしれません)。
There are situations where the Aggregator is able to make a final mapping decision. That would be the case, for example, if there is a single TE tunnel toward the destination and if the policy is to map any E2E RSVP reservation onto TE tunnels.
状況がAggregatorが最終的なマッピング決定をすることができるところにあります。 例えば、方針が単一のTEトンネルが目的地に向かっていて、どんな2ユーロのE RSVPの予約もTEトンネルに写像することであるなら、それはそうでしょう。
There are situations where the Aggregator is not able to make a final determination. That would be the case, for example, if routing identifies two DS-TE tunnels toward the destination, one belonging to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel and Intserv Controlled Load reservations to a Class-Type 0 tunnel, and if the E2E RSVP Path message advertises both Guaranteed Service and Controlled Load.
状況がAggregatorが最終的決定をすることができないところにあります。 例えば、ルーティングが1つが属して、DS-TEが目的地に向かってDS-TE Class-タイプ1とClass-タイプ1対0までトンネルを堀る2を特定するなら、それはそうでしょう、方針がClass-タイプ1つのトンネルへのIntserv Guaranteed Servicesの予約とClass-タイプ0トンネルへのIntserv Controlled Loadの予約を写像することであり、2EのE RSVP PathメッセージがGuaranteed ServiceとControlled Loadの両方の広告を出すなら。
Whether final or tentative, the Aggregator makes a mapping decision and selects a TE tunnel. Before forwarding the E2E Path message toward the receiver, the Aggregator SHOULD update the ADSPEC inside the E2E Path message to reflect the impact of the MPLS TE cloud onto the QoS achievable by the E2E flow. This update is a local matter and may be based on configured information, on the information available in the MPLS TE topology database, on the current TE tunnel path, on information collected via RSVP-TE signaling, or a combination thereof. Updating the ADSPEC allows receivers that take into account the information collected in the ADSPEC within the network (such as delay and bandwidth estimates) to make more informed reservation decisions.
最終的であるか、または一時的であることにかかわらず、Aggregatorはマッピング決定をして、TEトンネルを選択します。 2EのE Pathメッセージを受信機に向かって転送する前に、Aggregator SHOULDは2EのE流動で達成可能なQoSにMPLS TE雲の衝撃を反映する2EのE PathメッセージでADSPECをアップデートします。 このアップデートは、地域にかかわる事柄であり、構成された情報に基づくかもしれません、MPLS TEトポロジーデータベースで利用可能な情報で、現在のTEトンネル経路で、RSVP-TEシグナリングで集められた情報、またはそれの組み合わせに関して。 ADSPECをアップデートするのに、ネットワーク(遅れや帯域幅見積りなどの)の中にADSPECに集められた情報を考慮に入れる受信機は、より知識がある予約決定をすることができます。
The Aggregator MUST then forward the E2E Path message to the Deaggregator (which is the Tail-end of the selected TE tunnel). In accordance with [LSP-HIER], the Aggregator MUST send the E2E Path message with an IF_ID RSVP_HOP object instead of an RSVP_HOP object. The data interface identification MUST identify the TE tunnel.
そして、AggregatorはDeaggregator(選択されたTEトンネルのTail-端である)に2EのE Pathメッセージを転送しなければなりません。 [LSP-HIER]に応じてAggregatorがPathと通信する2EのEを送らなければならない、__ID RSVP_HOPがRSVPの代わりに反対するなら、HOPは反対します。 データインタフェース識別はTEトンネルを特定しなければなりません。
Faucheur Standards Track [Page 10] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[10ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
To send the E2E Path message, the Aggregator MUST address it directly to the Deaggregator by setting the destination address in the IP Header of the E2E Path message to the Deaggregator address. The Router Alert is not set in the E2E Path message.
2EのE Pathメッセージを送るために、AggregatorはDeaggregatorアドレスへの2EのE PathメッセージのIP Headerに送付先アドレスをはめ込むことによって、直接Deaggregatorにそれを記述しなければなりません。 Router Alertは2EのE Pathメッセージで用意ができていません。
Optionally, the Aggregator MAY also encapsulate the E2E Path message in an IP tunnel or in the TE tunnel itself.
また、任意に、AggregatorはIPトンネルかTEトンネル自体で2EのE Pathメッセージを要約するかもしれません。
Regardless of the encapsulation method, the Router Alert is not set. Thus, the E2E Path message will not be visible to routers along the path from the Aggregator to the Deaggregator. Therefore, in contrast to the procedures of [RSVP-AGG] and [RSVP-GEN-AGG], the IP Protocol number does not need to be modified to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating "RSVP") by the Aggregator.
カプセル化方法にかかわらず、Router Alertは用意ができていません。 したがって、2EのE PathメッセージはAggregatorからDeaggregatorまで経路に沿ったルータに目に見えるようにならないでしょう。 したがって、[RSVP-AGG]と[RSVP-GEN-AGG]の手順と対照してIPプロトコル番号が変更される必要はない、「RSVP-E2E-は無視する」、。 アグリゲータはそれをそのままな("RSVP"を示します)ままにしなければなりません。
In some environments, the Aggregator and Deaggregator MAY also act as IPsec Security Gateways in order to provide IPsec protection to E2E traffic when it transits between the Aggregator and the Deaggregator. In that case, to transmit the E2E Path message to the Deaggregator, the Aggregator MUST send the E2E Path message into the relevant IPsec tunnel terminating on the Deaggregator.
また、いくつかの環境で、AggregatorとDeaggregatorは、AggregatorとDeaggregatorの間を通過するとき、2ユーロのE交通への保護をIPsecに供給するためにIPsec Security Gatewaysとして機能するかもしれません。 その場合、2EのE PathメッセージをDeaggregatorに送るために、Aggregatorは2EのE PathメッセージをDeaggregatorで終わる関連IPsecトンネルに送らなければなりません。
E2E PathTear and ResvConf messages MUST be forwarded by the Aggregator to the Deaggregator exactly like Path messages.
AggregatorはちょうどPathメッセージのように2EのE PathTearとResvConfメッセージをDeaggregatorに転送しなければなりません。
4.3. Handling of E2E Path Message by Transit LSRs
4.3. トランジットLSRsによる2EのE経路メッセージの取り扱い
Since the E2E Path message is addressed directly to the Deaggregator and does not have Router Alert set, it is hidden from all transit LSRs.
2EのE Pathメッセージで直接Deaggregatorに記述されて、Router Alertを用意ができさせないので、すべてのトランジットLSRsそれを隠されます。
4.4. Receipt of E2E Path Message by the Deaggregator
4.4. Deaggregatorによる2EのE経路メッセージの領収書
Upon receipt of the E2E Path message addressed to it, the Deaggregator will notice that the IP Protocol number is set to "RSVP" and will thus perform RSVP processing of the E2E Path message.
それに記述された2EのE Pathメッセージを受け取り次第、DeaggregatorはIPプロトコル番号が"RSVP"に設定されるのに気付いて、その結果、2EのE経路メッセージのRSVP処理を実行するでしょう。
As with [LSP-HIER], the IP TTL vs. RSVP TTL check MUST NOT be made. The Deaggregator is informed that this check is not to be made because of the presence of the IF_ID RSVP HOP object.
[LSP-HIER]と共にIP TTL対RSVP TTLチェックをしてはいけないので。 Deaggregatorがこのチェックが存在のために作られていないことであると知らされる、_ID RSVP HOPが反対するなら。
The Deaggregator MAY support the option to perform the following checks (defined in [LSP-HIER]) by the receiver Y of the IF_ID RSVP_HOP object:
Deaggregatorが受信機Yで、以下のチェック([LSP-HIER]では、定義される)を実行するためにオプションをサポートするかもしれない、_ID RSVP_HOPが反対するなら:
1. Make sure that the data interface identified in the IF_ID
RSVP_HOP object actually terminates on Y.
1. データが特定されていた状態で連結するのを確信しているのに作る、_ID RSVP_HOP物が実際にYで終わるなら。
Faucheur Standards Track [Page 11] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[11ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
2. Find the "other end" of the above data interface, i.e., X. Make
sure that the PHOP in the IF_ID RSVP_HOP object is a control
channel address that belongs to the same node as X.
2. すなわち、上の「他の終わり」データインタフェース、X.Makeが確実にそれであることがわかる、中のPHOP、_ID RSVP_HOP物がXと同じノードに属す規制チャンネル・アドレスであるなら。
The information necessary to perform these checks may not always be available to the Deaggregator. Hence, the Deaggregator MUST support operations in such environments where the checks cannot be made.
これらのチェックを実行するのに必要な情報はいつもDeaggregatorに利用可能であるかもしれないというわけではありません。 したがって、Deaggregatorはチェックをすることができないそのような環境における操作を支持しなければなりません。
The Deaggregator MUST forward the E2E Path downstream toward the receiver. In doing so, the Deaggregator sets the destination address in the IP header of the E2E Path message to the IP address found in the destination address field of the Session object. The Deaggregator also sets the Router Alert.
Deaggregatorは受信機に向かった2EのE Path川下を送らなければなりません。そうするのを、Deaggregatorは、Session物の目的地アドレス・フィールドで見つけられたIPアドレスへの2EのE PathメッセージのIPヘッダーに送付先アドレスをはめ込みます。 また、DeaggregatorはRouter Alertを設定します。
An E2E PathErr sent by the Deaggregator in response to the E2E Path message (which contains an IF_ID RSVP_HOP object) SHOULD contain an IF_ID RSVP_HOP object.
E2E PathErrがDeaggregatorで2EのE Pathメッセージに対応して発信した、(どれ、含有、_ID RSVP_HOP物) SHOULDが含んでいるか、_ID RSVP_HOPが反対するなら。
4.5. Handling of E2E Resv Message by the Deaggregator
4.5. Deaggregatorによる2EのE Resvメッセージの取り扱い
As per regular RSVP operations, after receipt of the E2E Path, the receiver generates an E2E Resv message which travels upstream hop- by-hop towards the sender.
定期的なRSVP操作に従って、2EのE Pathの領収書の後に、受信機はホップで上流ホップを送付者に向かって旅行するE2E Resvメッセージを発生させます。
Upon receipt of the E2E Resv, the Deaggregator MUST follow traditional RSVP procedures on receipt of the E2E Resv message. This includes performing admission control for the segment downstream of the Deaggregator and forwarding the E2E Resv message to the PHOP signaled earlier in the E2E Path message and which identifies the Aggregator. Since the E2E Resv message is directly addressed to the Aggregator and does not carry the Router Alert option (as per traditional RSVP Resv procedures), the E2E Resv message is hidden from the routers between the Deaggregator and the Aggregator which, therefore, handle the E2E Resv message as a regular IP packet.
2EのE Resvを受け取り次第、Deaggregatorは2EのE Resvメッセージを受け取り次第伝統的なRSVP手順に従わなければなりません。 これは、Aggregatorを特定するより早く2EのE Pathメッセージで合図されたPHOPにDeaggregatorのセグメント川下のための入場コントロールを実行して、2EのE Resvメッセージを転送するのを含んでいます。 2EのE Resvメッセージが直接Aggregatorに記述されて、Router Alertオプションを運ばないので(伝統的なRSVP Resv手順に従って)、2EのE Resvメッセージはルータからしたがって、レギュラーのIPパケットとして2EのE Resvメッセージを扱うDeaggregatorとAggregatorの間を隠されます。
If the Aggregator and Deaggregator are also acting as IPsec Security Gateways, the Deaggregator MUST send the E2E Resv message into the relevant IPsec tunnel terminating on the Aggregator.
また、AggregatorとDeaggregatorがIPsec Security Gatewaysとして機能しているなら、Deaggregatorは2EのE ResvメッセージをAggregatorで終わる関連IPsecトンネルに送らなければなりません。
4.6. Handling of E2E Resv Message by the Aggregator
4.6. アグリゲータによる2EのE Resvメッセージの取り扱い
The Aggregator is responsible for ensuring that there is sufficient bandwidth available and reserved over the appropriate TE tunnel to the Deaggregator for the E2E reservation.
2ユーロのEの予約において、Deaggregatorへの適切なTEトンネルの上で利用可能で予約された十分な帯域幅があるのを確実にするのにAggregatorは責任があります。
On receipt of the E2E Resv message, the Aggregator MUST first perform the final mapping onto the final TE tunnel (if the previous mapping was only a tentative one).
2EのE Resvメッセージを受け取り次第、Aggregatorは最初に、最終的なTEトンネルに最終的なマッピングを実行しなければなりません(前のマッピングが一時的なものにすぎなかったなら)。
Faucheur Standards Track [Page 12] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[12ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
If the tunnel did not change during the final mapping, the Aggregator continues the processing of the E2E Resv as described in the four following paragraphs.
トンネルが最終的なマッピングの間、変化しなかったなら、Aggregatorは4つの次のパラグラフで説明されるように2EのE Resvの処理を続けています。
The aggregator calculates the size of the resource request using traditional RSVP procedures. That is, it follows the procedures in [RSVP] to determine the resource requirements from the Sender Tspec and the Flowspec contained in the Resv. Then it compares the resource request with the available resources of the selected TE tunnel.
アグリゲータは、伝統的なRSVP手順を用いることで資源要求のサイズについて計算します。 すなわち、それは、Resvに含まれたSender TspecとFlowspecからのリソース要件を決定するために[RSVP]で手順に従います。 そして、それは選択されたTEトンネルに関する利用可能資源と資源要求を比べます。
If sufficient bandwidth is available on the final TE tunnel, the Aggregator MUST update its internal understanding of how much of the TE tunnel is in use and MUST forward the E2E Resv messages to the corresponding PHOP.
十分な帯域幅が最終的なTEトンネルで利用可能であるなら、AggregatorはTEトンネルのいくらが使用中であるかに関する内部の理解をアップデートしなければならなくて、2EのE Resvメッセージを対応するPHOPに転送しなければなりません。
As noted in [RSVP-AGG], a range of policies MAY be applied to the re-sizing of the aggregate reservation (in this case, the TE tunnel). For example, the policy may be that the reserved bandwidth of the tunnel can only be changed by configuration. More dynamic policies are also possible, whereby the aggregator may attempt to increase the reserved bandwidth of the tunnel in response to the amount of allocated bandwidth that has been used by E2E reservations. Furthermore, to avoid the delay associated with the increase of the tunnel size, the Aggregator may attempt to anticipate the increases in demand and adjust the TE tunnel size ahead of actual needs by E2E reservations. In order to reduce disruptions, the Aggregator SHOULD use "make-before-break" procedures as described in [RSVP-TE] to alter the TE tunnel bandwidth.
[RSVP-AGG]で有名であることで、さまざまな方針が集合予約のリサイズに適用されるかもしれません(この場合、TEはトンネルを堀ります)。 例えば、方針は構成でトンネルの予約された帯域幅を変えることができるだけであるということであるかもしれません。 また、よりダイナミックな方針も可能である、アグリゲータが2ユーロのEの予約で使用された割り当てられた帯域幅の量に対応してトンネルの予約された帯域幅を増加させるのを試みるかもしれない。 その上、トンネルサイズの増加に関連している遅れを避けるために、Aggregatorは2ユーロのEの予約で要求で増加を予期して、実際の必要性の前にTEトンネルサイズを調整するのを試みるかもしれません。 分裂を抑えるために、Aggregator SHOULDはTEトンネル帯域幅を変更するために[RSVP-TE]で説明されるように「以前、開閉してください」という手順を用います。
If sufficient bandwidth is not available on the final TE tunnel, the Aggregator MUST follow the normal RSVP procedure for a reservation being placed with insufficient bandwidth to support it. That is, the reservation is not installed and a ResvError is sent back toward the receiver.
十分な帯域幅が最終的なTEトンネルで利用可能でないなら、Aggregatorはそれを支持するために不十分な帯域幅に置かれる予約のための正常なRSVP手順に従わなければなりません。 すなわち、予約はインストールされません、そして、ResvErrorは受信機に向かって返送されます。
If the tunnel did change during the final mapping, the Aggregator MUST first resend to the Deaggregator an E2E Path message with the IF_ID RSVP_HOP data interface identification identifying the final TE tunnel. If needed, the ADSPEC information in this E2E Path message SHOULD be updated. Then the Aggregator MUST
トンネルが最終的なマッピングの間、変化したなら、Aggregatorが最初にE Pathが通信するE2をDeaggregatorに再送しなければならない、_ID RSVP_HOPデータが最終的なTEを特定する識別を連結するなら、トンネルを堀ってください。 必要であるなら、この2EのE PathのADSPEC情報はSHOULDを通信させます。アップデートします。 そして、アグリゲータはそうしなければなりません。
- either drop the E2E Resv message
- どちらかが2EのE Resvメッセージを落とします。
- or proceed with the processing of the E2E Resv in the same
manner as in the case where the tunnel did not change (described
above).
- または、トンネルが変化しなかった(上で、説明されます)ケースの中ように同じ方法における、2EのE Resvの処理を続けてください。
Faucheur Standards Track [Page 13] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[13ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
In the former case, admission control over the final TE tunnel (and forwarding of E2E Resv message upstream toward the sender) would only occur when the Aggregator received the subsequent E2E Resv message (that will be sent by the Deaggregator in response to the resent E2E Path). In the latter case, admission control over the final tunnel is carried out immediately by the Aggregator, and if successful the E2E Resv message is generated upstream toward the sender.
前の場合では、Aggregatorが2その後のEのE Resvメッセージを受け取ったときだけ(それは再送に対応してDeaggregatorによって2EのE Path送られるでしょう)、最終的なTEトンネル(そして、送付者に向かった2EのE Resvメッセージ上流の推進)の入場コントロールは起こるでしょう。 後者の場合では、最終的なトンネルの入場コントロールがすぐAggregatorによって行われます、そして、うまくいくなら、2EのE Resvメッセージが上流へ送付者に向かって発生します。
Upon receipt of an E2E ResvConf from the Aggregator, the Deaggregator MUST forward the E2E ResvConf downstream toward the receiver. In doing so, the Deaggregator sets the destination address in the IP header of the E2E ResvConf message to the IP address found in the RESV_CONFIRM object of the corresponding Resv. The Deaggregator also sets the Router Alert.
AggregatorからのE2E ResvConfを受け取り次第、Deaggregatorは受信機に向かった2EのE ResvConf川下を送らなければなりません。そうするのを、Deaggregatorは、対応ResvのRESV_CONFIRM物で見つけられたIPアドレスへの2EのE ResvConfメッセージのIPヘッダーに送付先アドレスをはめ込みます。 また、DeaggregatorはRouter Alertを設定します。
4.7. Forwarding of E2E Traffic by the Aggregator
4.7. アグリゲータによる2ユーロのE交通の推進
When the Aggregator receives a data packet belonging to an E2E reservations currently mapped over a given TE tunnel, the Aggregator MUST encapsulate the packet into that TE tunnel.
Aggregatorがデータ・パケットを受けるとき、2E Eに予約が現在与えられたTEトンネル、Aggregatorの上で写像した属すのはそのTEトンネルにパケットをカプセルに入れらなければなりません。
If the Aggregator and Deaggregator are also acting as IPsec Security Gateways, the Aggregator MUST also encapsulate the data packet into the relevant IPsec tunnel terminating on the Deaggregator before transmission into the MPLS TE tunnel.
また、また、AggregatorとDeaggregatorがIPsec Security Gatewaysとして機能しているなら、AggregatorはMPLS TEトンネルへのトランスミッションの前にDeaggregatorで終わる関連IPsecトンネルにデータ・パケットをカプセルに入れらなければなりません。
4.8. Removal of E2E Reservations
4.8. 2ユーロのE予約の取り外し
E2E reservations are removed in the usual way via PathTear, ResvTear, timeout, or as the result of an error condition. When a reservation is removed, the Aggregator MUST update its local view of the resources available on the corresponding TE tunnel accordingly.
2ユーロのEの予約を取り除く、不断のとおりPathTear、ResvTear、タイムアウトを通してエラー条件の結果 予約を取り除くとき、Aggregatorはそれに従って、対応するTEトンネルで利用可能なリソースのローカルの視点をアップデートしなければなりません。
4.9. Removal of the TE Tunnel
4.9. Teトンネルの取り外し
Should a TE tunnel go away (presumably due to a configuration change, route change, or policy event), the Aggregator behaves much like a conventional RSVP router in the face of a link failure. That is, it may try to forward the Path messages onto another tunnel, if routing and policy permit, or it may send Path_Error messages to the sender if a suitable tunnel does not exist. In case the Path messages are forwarded onto another tunnel, which terminates on a different Deaggregator, or the reservation is torn down via Path Error messages, the reservation state established on the router acting as the Deaggregator before the TE tunnel went away, will time out since it will no longer be refreshed.
TEトンネルが遠ざかるはずであるなら(おそらく、構成変更、ルート変化、または方針イベントのため)、Aggregatorはリンクの故障に直面して従来のRSVPルータのように振る舞います。 Pathメッセージを別のトンネルに転送しようとするかもしれません、ルーティングと方針が可能にするか、または適当なトンネルが存在していないならPath_Errorに送付者へのメッセージを送るかもしれないなら。 予約州は、TEがトンネルを堀る前にDeaggregatorが遠ざかったとき行動するルータでPathメッセージを別のトンネルに転送するか、またはPath Errorメッセージで予約を取りこわすといけないので、それ以来のタイムアウトがもうリフレッシュされないのを確証しました。トンネルは異なったDeaggregatorで終わります。
Faucheur Standards Track [Page 14] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[14ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
4.10. Example Signaling Flow
4.10. 例のシグナリング流動
Aggregator Deaggregator
アグリゲータDeaggregator
(*)
RSVP-TE Path
=========================>
(*)RSVP-Te経路=========================>。
RSVP-TE Resv
<=========================
(**)
RSVP-Te Resv<。========================= (**)
E2E Path
-------------->
(1)
E2E Path
------------------------------->
(2)
E2E Path
----------->
2EのE経路--------------2>(1)EのE経路-------------------------------2>(2)EのE経路----------->。
E2E Resv
<-----------
(3)
E2E Resv
<-----------------------------
(4)
E2E Resv
<-------------
2EのE Resv<。----------- (3) 2EのE Resv<。----------------------------- (4) 2EのE Resv<。-------------
(*) Aggregator is triggered to pre-establish the TE tunnel(s)
(*)アグリゲータは、TEトンネルをあらかじめ証明するために引き起こされます。(s)
(**) TE tunnel(s) are pre-established
(**) TEトンネルはあらかじめ確立されます。
(1) Aggregator tentatively selects the TE tunnel and forwards
E2E path to Deaggregator
(1) アグリゲータは、試験的にTEトンネルを選択して、2EのE経路をDeaggregatorに送ります。
(2) Deaggregator forwards the E2E Path toward the receiver
(2) Deaggregatorは2EのE Pathを受信機に向かって送ります。
(3) Deaggregator forwards the E2E Resv to the Aggregator
(3) DeaggregatorはAggregatorに2EのE Resv転送します。
(4) Aggregator selects final TE tunnel, checks that there is
sufficient bandwidth on TE tunnel, and forwards E2E Resv to
PHOP. If final tunnel is different from tunnel tentatively
selected, the Aggregator re-sends an E2E Path with an updated
IF_ID RSVP_HOP and possibly an updated ADSPEC.
(4) アグリゲータは、最終的なTEトンネルを選択して、TEトンネルの上に十分な帯域幅があるのをチェックして、PHOPに2EのE Resv転送します。 最終的なトンネルが試験的に選択されたトンネルと異なるなら、AggregatorがE2E Pathを再送する、_ID RSVP_HOPとことによるとアップデートされたADSPECであるなら、アップデートします。
Faucheur Standards Track [Page 15] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[15ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
5. IPv4 and IPv6 Applicability
5. IPv4とIPv6の適用性
The procedures defined in this document are applicable to all the following cases:
本書では定義された手順は以下のすべてのケースに適切です:
(1) Aggregation of E2E IPv4 RSVP reservations over IPv4 TE
tunnels.
(1) IPv4 TEの上の2ユーロのE IPv4 RSVPの予約の集合はトンネルを堀ります。
(2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE
tunnels.
(2) IPv6 TEの上の2ユーロのE IPv6 RSVPの予約の集合はトンネルを堀ります。
(3) Aggregation of E2E IPv6 RSVP reservations over IPv4 TE
tunnels, provided a mechanism such as [6PE] is used by the
Aggregator and Deaggregator for routing of IPv6 traffic over
an IPv4 MPLS core.
(3) IPv4 TEの上の2ユーロのE IPv6 RSVPの予約の集合はトンネルを堀ります、[6PE]などのメカニズムがIPv4 MPLSコアの上のIPv6交通のルーティングにAggregatorとDeaggregatorによって使用されるなら。
(4) Aggregation of E2E IPv4 RSVP reservations over IPv6 TE
tunnels, provided a mechanism is used by the Aggregator and
Deaggregator for routing IPv4 traffic over IPv6 MPLS.
(4) IPv6 TEの上の2ユーロのE IPv4 RSVPの予約の集合はトンネルを堀ります、メカニズムがIPv6 MPLSの上のルーティングIPv4交通にAggregatorとDeaggregatorによって使用されるなら。
6. E2E Reservations Applicability
6. 2EのE予約の適用性
The procedures defined in this document are applicable to many types of E2E RSVP reservations including the following cases:
本書では定義された手順は以下のケースを含む多くのタイプの2EのE RSVPの予約に適切です:
(1) The E2E RSVP reservation is a per-flow reservation where the
flow is characterized by the usual 5-tuple
(1) 1流れあたり2ユーロのE RSVPの予約は流れが普通の5-tupleによって特徴付けられるところの1つの予約です。
(2) The E2E reservation is an aggregate reservation for multiple
flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the
set of flows is characterized by the <source address,
destination address, DSCP>
(2) 2ユーロのEの予約が流れのセットが<ソースアドレスによって特徴付けられる[RSVP-AGG]か[RSVP-GEN-AGG]で説明されるように複数の流れの集合予約です、送付先アドレス、DSCP>。
(3) The E2E reservation is a reservation for an IPsec protected
flow. For example, where the flow is characterized by the
<source address, destination address, SPI> as described in
[RSVP-IPSEC].
(3) 2ユーロのEの予約はIPsecの予約が流れを保護したということです。 流れが<ソースアドレスによって特徴付けられるところの送付先アドレス、例えば[RSVP-IPSEC]で説明されるSPI>。
7. Example Deployment Scenarios
7. 例の展開シナリオ
7.1. Voice and Video Reservations Scenario
7.1. 声とビデオ予約シナリオ
An example application of the procedures specified in this document is admission control of voice and video in environments with a very high number of hosts. In the example illustrated below, hosts generate E2E per-flow reservations for each of their video streams associated with a video-conference, each of their audio streams associated with a video-conference and each of their voice calls.
本書では指定された手順の例の適用は、非常に大きい数のホストがいる声の入場コントロールと環境でビデオです。 以下で例証された例では、ホストはそれぞれのそれぞれの彼らのテレビ会議に関連しているビデオストリーム、彼らのテレビ会議に関連しているオーディオの流れ、およびそれぞれの彼らの音声通話の2ユーロの1流れあたりのEの予約を発生させます。
Faucheur Standards Track [Page 16] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[16ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
These reservations are aggregated over MPLS DS-TE tunnels over the packet core. The mapping policy defined by the user may be that all the reservations for audio and voice streams are mapped onto DS-TE tunnels of Class-Type 1, while reservations for video streams are mapped onto DS-TE tunnels of Class-Type 0.
これらの予約はパケットコアの上のMPLS DS-TEトンネルの上で集められます。 ユーザによって定義されたマッピング方針はオーディオと声の流れのすべての予約がClass-タイプ1のDS-TEトンネルに写像されるということであるかもしれません、ビデオストリームの予約はClass-タイプ0のDS-TEトンネルに写像されますが。
------ ------
| H |# ------- -------- #| H |
| |\#| | ----- | |#/| |
-----| \| Agg | | T | | Deag |/ ------
| |==========================| |
------ /| |::::::::::::::::::::::::::| |\ ------
| H |/#| | ----- | |#\| H |
| |# ------- -------- #| |
------ ------
------ ------ | H|# ------- -------- #| H| | |\#| | ----- | |#/| | -----| \| Agg| | T| | Deag|/ ------ | |==========================| | ------ /| |::::::::::::::::::::::::::| |\ ------ | H|/#| | ----- | |#\| H| | |# ------- -------- #| | ------ ------
H = Host Agg = Aggregator (TE tunnel Head-end) Deagg = Deaggregator (TE tunnel Tail-end) T = Transit LSR
Deaggregator(TEトンネルTail-エンド)アグリゲータ(TEトンネルHead-エンド)ホストH=Agg=Deagg=TはトランジットLSRと等しいです。
/ = E2E RSVP reservation for a Voice flow # = E2E RSVP reservation for a Video flow == = DS-TE tunnel from Class-Type 1 :: = DS-TE tunnel from Class-Type 0
2EのVoice流動#の2ユーロのE RSVPの/=予約=Eで、Video流動=のRSVPの予約=DS-TEはClass-タイプ1から以下にトンネルを堀ります: = DS-TEはClass-タイプ0からトンネルを堀ります。
7.2. PSTN/3G Voice Trunking Scenario
7.2. PSTN/3G声の中継方式シナリオ
An example application of the procedures specified in this document is voice call admission control in large-scale telephony trunking environments. A Trunk VoIP Gateway may generate one aggregate RSVP reservation for all the calls in place toward another given remote Trunk VoIP Gateway (with resizing of this aggregate reservation in a step function depending on the current number of calls). In turn, these reservations may be aggregated over MPLS TE tunnels over the packet core so that tunnel Head-ends act as Aggregators and perform admission control of Trunk Gateway reservations into MPLS TE tunnels. The MPLS TE tunnels may be protected by MPLS Fast Reroute. This scenario is illustrated below:
本書では指定された手順の例の適用は大規模な電話中継方式環境で音声通話入場コントロールです。 リモートTrunk VoIPゲートウェイ(階段関数における、この集合予約のリサイズを呼び出しの最新号に依存している)を考えて、Trunk VoIPゲートウェイは適所にあるすべての呼び出しの1つの集合RSVPの予約を別のものに向かって発生させるかもしれません。 順番に、トンネルがパケットコアの上のMPLS TEトンネルの上で集められるかもしれないのでHead終わるというこれらの条件は、Aggregatorsとして機能して、Trunkゲートウェイの予約の入場コントロールをMPLS TEトンネルに実行します。 MPLS TEトンネルはMPLS Fast Rerouteによって保護されるかもしれません。 このシナリオは以下で例証されます:
Faucheur Standards Track [Page 17] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[17ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
------ ------
| GW |\ ------- -------- /| GW |
| |\\| | ----- | |//| |
-----| \| Agg | | T | | Deag |/ ------
| |==========================| |
------ /| | | | | |\ ------
| GW |//| | ----- | |\\| GW |
| |/ ------- -------- \| |
------ ------
------ ------ | GW|\ ------- -------- /| GW| | |\\| | ----- | |//| | -----| \| Agg| | T| | Deag|/ ------ | |==========================| | ------ /| | | | | |\ ------ | GW|//| | ----- | |\\| GW| | |/ ------- -------- \| | ------ ------
GW = VoIP Gateway Agg = Aggregator (TE tunnel Head-end) Deagg = Deaggregator (TE tunnel Tail-end) T = Transit LSR
GW=VoIPゲートウェイAgg=アグリゲータ(TEトンネルHead-エンド)Deagg=Deaggregator(TEトンネルTail-エンド)TはトランジットLSRと等しいです。
/ = Aggregate Gateway to Gateway E2E RSVP reservation == = TE tunnel
/はゲートウェイのE2E RSVPの予約==TEトンネルへの集合ゲートウェイと等しいです。
8. Security Considerations
8. セキュリティ問題
In the environments concerned by this document, RSVP messages are used to control resource reservations for E2E flows outside the MPLS region as well as to control resource reservations for MPLS TE tunnels inside the MPLS region. To ensure the integrity of the associated reservation and admission control mechanisms, the mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] can be used. The mechanisms protect the integrity of RSVP messages hop-by-hop and provide node authentication, thereby protecting against corruption and spoofing of RSVP messages. These hop-by-hop integrity mechanisms can naturally be used to protect the RSVP messages used for E2E reservations outside the MPLS region, to protect RSVP messages used for MPLS TE tunnels inside the MPLS region, or for both. These hop- by-hop RSVP integrity mechanisms can also be used to protect RSVP messages used for E2E reservations when those transit through the MPLS region. This is because the Aggregator and Deaggregator behave as RSVP neighbors from the viewpoint of the E2E flows (even if they are not necessarily IP neighbors nor RSVP-TE neighbors). In that case, the Aggregator and Deaggregator need to use a pre-shared secret.
このドキュメント、RSVPでメッセージが2Eの資源予約を制御するのに使用されることを心配させた環境で、Eはまた、MPLS領域の外をMPLS領域の中のMPLS TEトンネルのコントロール資源予約に関して流れます。 関連予約と入場制御機構の保全を確実にするために、[RSVP-CRYPTO1]と[RSVP-CRYPTO2]で定義されたメカニズムは使用できます。 メカニズムは、ホップごとにRSVPメッセージの保全を保護して、ノード認証を提供します、その結果、RSVPメッセージの不正とスプーフィングから守ります。 MPLS領域の外での2ユーロのEの予約に使用されるRSVPメッセージを保護して、MPLS領域の中のMPLS TEトンネル、または両方に使用されるRSVPメッセージを保護するのに自然にホップごとのこれらの保全メカニズムを使用できます。 また、MPLS領域を通るそれらのトランジットであるときに2ユーロのEの予約に使用されるRSVPメッセージを保護するのにホップによるこれらのホップRSVP保全メカニズムを使用できます。 これはAggregatorとDeaggregatorがRSVP隣人として2EのE流れの観点から振る舞うから(彼らが必ずIP隣人かRSVP-TE隣人でなくても)です。 その場合、AggregatorとDeaggregatorは、プレ共有秘密キーを使用する必要があります。
As discussed in Section 6 of [RSVP-TE], filtering of traffic associated with an MPLS TE tunnel can only be done on the basis of an MPLS label, instead of the 5-tuple of conventional RSVP reservation as per [RSVP]. Thus, as explained in [RSVP-TE], an administrator may wish to limit the domain over which TE tunnels (which are used for aggregation of RSVP E2E reservations as per this specification) can be established. See Section 6 of [RSVP-TE] for a description of how
[RSVP-TE]のセクション6で議論するように、MPLSラベルに基づいてMPLS TEトンネルに関連している交通のフィルタリングができるだけです、[RSVP]に従って従来のRSVPの予約の5-tupleの代わりに。 したがって、管理者は[RSVP-TE]で説明されるようにTEトンネル(この仕様に従って2EのRSVP Eの予約の集合に使用される)を確立できるドメインを制限したがっているかもしれません。 a記述のための[RSVP-TE]のセクション6を見る、どのように
Faucheur Standards Track [Page 18] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[18ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
filtering of RSVP messages associated with MPLS TE tunnels can be deployed to that end.
そのためにMPLS TEトンネルに関連しているRSVPメッセージのフィルタリングを配備できます。
This document is based in part on [RSVP-AGG], which specifies aggregation of RSVP reservations. Section 5 of [RSVP-AGG] raises the point that because many E2E flows may share an aggregate reservation, if the security of an aggregate reservation is compromised, there is a multiplying effect in the sense that it can in turn compromise the security of many E2E reservations whose quality of service depends on the aggregate reservation. This concern applies also to RSVP Aggregation over TE tunnels as specified in the present document. However, the integrity of MPLS TE tunnels operation can be protected using the mechanisms discussed in the previous paragraphs. Also, while [RSVP-AGG] specifies RSVP Aggregation over dynamically established aggregate reservations, the present document restricts itself to RSVP Aggregation over pre-established TE tunnels. This further reduces the security risks.
このドキュメントは[RSVP-AGG]に一部基づいています。(それは、RSVPの予約の集合を指定します)。 [RSVP-AGG]のセクション5は集合予約のセキュリティが妥協するなら多くの2EのE流れが集合予約を共有するかもしれないので順番にサービスの質を集合予約に依存する多くの2ユーロのEの予約のセキュリティで妥協できるという意味における増える効果があるというポイントを上げます。 また、この関心は現在のドキュメントの指定されるとしてのTEトンネルの上でRSVP Aggregationに適用されます。 しかしながら、MPLS TEの保全は保護された使用が前のパラグラフで議論したメカニズムであったかもしれないなら操作にトンネルを堀ります。 また、[RSVP-AGG]はダイナミックに設立された集合予約の上でRSVP Aggregationを指定しますが、現在のドキュメントはプレ確立したTEトンネルの上でそれ自体をRSVP Aggregationに制限します。 これはセキュリティ危険をさらに減少させます。
In the case where the Aggregators dynamically resize the TE tunnels based on the current level of reservation, there are risks that the TE tunnels used for RSVP aggregation hog resources in the core, which could prevent other TE tunnels from being established. There are also potential risks that such resizing results in significant computation and signaling as well as churn on tunnel paths. Such risks can be mitigated by configuration options allowing control of TE tunnel dynamic resizing (maximum TE tunnel size, maximum resizing frequency, etc.), and/or possibly by the use of TE preemption.
Aggregatorsがダイナミックに現在のレベルの予約に基づくTEトンネルをリサイズする場合には、TEトンネルがRSVPに他のTEトンネルが確立されるのを防ぐことができたコアで集合豚リソースを使用したというリスクがあります。 また、そのようなリサイズが攪乳器と同様に重要な計算とシグナリングをもたらすという潜在的リスクがトンネル経路にあります。 ことによると(最大のTEトンネルサイズ、頻度をリサイズする最大など)をリサイズするTEトンネル動力のコントロールを許す設定オプション、TE先取りの使用でそのような危険を緩和できます。
Section 5 of [RSVP-AGG] also discusses a security issue specific to RSVP aggregation related to the necessary modification of the IP Protocol number in RSVP E2E Path messages that traverses the aggregation region. This security issue does not apply to the present document since aggregation of RSVP reservation over TE tunnels does not use this approach of changing the protocol number in RSVP messages.
また、[RSVP-AGG]のセクション5は2EのRSVP E Pathメッセージにおける、集合領域を横断するIPプロトコル番号の必要な変更に関連するRSVP集合に特定の安全保障問題について論じます。 TEトンネルの上のRSVPの予約の集合がRSVPメッセージでプロトコル番号を変えるこのアプローチを使用しないので、この安全保障問題は現在のドキュメントに適用されません。
Section 7 of [LSP-HIER] discusses security considerations stemming from the fact that the implicit assumption of a binding between data interface and the interface over which a control message is sent is no longer valid. These security considerations are equally applicable to the present document.
[LSP-HIER]のセクション7はコントロールメッセージが送られるデータインタフェースとインタフェースの間の結合の暗黙の仮定がもう有効でないという事実によるセキュリティ問題について論じます。 これらのセキュリティ問題は等しく現在のドキュメントに適切です。
If the Aggregator and Deaggregator are also acting as IPsec Security Gateways, the Security Considerations of [SEC-ARCH] apply.
また、AggregatorとDeaggregatorがIPsec Security Gatewaysとして機能しているなら、[SEC-ARCH]のSecurity Considerationsは適用します。
Faucheur Standards Track [Page 19] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[19ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
9. Acknowledgments
9. 承認
This document builds on the [RSVP-AGG], [RSVP-TUN], and [LSP-HIER] specifications. We would like to thank Tom Phelan, John Drake, Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol Iturralde, and James Gibson for their input into this document.
このドキュメントは[RSVP-AGG]、[RSVP-TUN]、および[LSP-HIER]仕様に建てられます。 トムフェランに感謝申し上げます、ジョン・ドレイク、Arthi Ayyangar、フレッド・ベイカー、Subha Dhesikan、クォック、-、おーい、このドキュメントへの彼らの入力のためのチェン、キャロル・イトゥラルデ、およびジェームズ・ギブソン。
10. Normative References
10. 引用規格
[CONTROLLED] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
1997年9月のWroclawski、J.、[制御される]の「制御負荷ネットワーク要素サービスの仕様」RFC2211。
[DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[DIFFSERV] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「微分されたサービスのための構造」RFC2475、1998年12月。
[DSTE-PROTO] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005.
[DSTE-プロト]Le Faucheur、F.、「Diffserv意識しているMPLS交通工学のサポートのためのプロトコル拡大」、RFC4124、2005年6月。
[GUARANTEED] Shenker, S., Partridge, C., and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
1997年9月の[保証される]のShenkerとS.とヤマウズラ、C.とR.ゲラン、「保証されたサービスの質の仕様」RFC2212。
[INT-DIFF] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang,
L., Speer, M., Braden, R., Davie, B., Wroclawski, J.,
and E. Felstaine, "A Framework for Integrated Services
Operation over Diffserv Networks", RFC 2998, November
2000.
[INT-デフ] Bernet、Y.、フォード、P.、Yavatkar、R.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.、およびE.Felstaine、「Diffservネットワークの上の統合サービス操作のための枠組み」、RFC2998(2000年11月)。
[INT-SERV] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[INT-SERV] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネット構造における統合サービス:」 「概観」、RFC1633、1994年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[LSP-HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
[LSP-HIER]Kompella(K.とY.Rekhter)は「一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学(Te)で切り換えられた経路(LSP)を階層構造とラベルします」、RFC4206、2005年10月。
[MPLS-TE] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[MPLS-Te] AwducheとD.とマルコムとJ.とAgogbuaとJ.とオデル、M.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
Faucheur Standards Track [Page 20] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[20ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RSVP] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RSVP-AGG] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RSVP-AGG] ベイカー、F.、イトゥラルデ、C.、Le Faucheur、F.、およびB.デイビー、「IPv4とIPv6予約のためのRSVPの集合」、RFC3175(2001年9月)。
[RSVP-CRYPTO1] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RSVP-CRYPTO1] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[RSVP-CRYPTO2] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC
3097, April 2001.
[RSVP-CRYPTO2] ブレーデンとR.とL.チャン、「RSVPの暗号の認証--メッセージタイプ価値をアップデートする」RFC3097、2001年4月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RSVP-Te] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[SEC-ARCH] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[SEC-アーチ] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
11. Informative References
11. 有益な参照
[6PE] De Clercq, J., Ooms, D., Prevost, S., and F. Le
Faucheur, "Connecting IPv6 Islands over IPv4 MPLS
using IPv6 Provider Edge Routers (6PE)", RFC 4798,
February 2007.
[6PE] De Clercq、J.、オームス、D.、プレヴォー、S.、およびF.Le Faucheur、「IPv6プロバイダーを使用することでIPv4 MPLSの上にIPv6諸島をつなげて、ルータ(6PE)を斜めに進ませてください」、RFC4798、2007年2月。
[AUTOMESH] Vasseur and Leroux, "Routing extensions for discovery
of Multiprotocol (MPLS) Label Switch Router (LSR)
Traffic Engineering (TE) mesh membership", Work in
Progress.
[AUTOMESH] Vasseurとルルー、「Multiprotocol(MPLS)ラベルSwitch Router(LSR)交通Engineering(TE)の発見のためのルート設定拡大は会員資格を網の目にかけます」、ProgressのWork。
[DIFF-MPLS] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J.
Heinanen, "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May
2002.
[デフ-MPLS]Le Faucheur、F.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「微分されたサービスのマルチプロトコルラベルスイッチング(MPLS)サポート」(RFC3270)は2002がそうするかもしれません。
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support
of Differentiated Services-aware MPLS Traffic
Engineering", RFC 3564, July 2003.
[DSTE-REQ] Le FaucheurとF.とW.レイ、「微分されたサービス意識しているMPLS交通工学のサポートのための要件」、RFC3564、2003年7月。
[L-RSVP] Manner, et al., Localized RSVP for Controlling RSVP
Proxies, Work in Progress.
[L-RSVP] 方法、他、Controlling RSVP ProxiesのためのLocalized RSVP、ProgressのWork。
Faucheur Standards Track [Page 21] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[21ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
[RSVP-APPID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
T., Herzog, S., and R. Hess, "Identity Representation
for RSVP", RFC 3182, October 2001.
[RSVP-APPID]YadavとS.とYavatkarとR.とPabbatiとR.とフォードとP.とムーアとT.とハーツォグ、S.とR.ヘス、「RSVPのアイデンティティ表現」RFC3182(2001年10月)。
[RSVP-GEN-AGG] Le Faucheur, R., Davie, B., Bose, P., Martin, L.,
Christou, C., Davenport, M., and A. Hamilton, "Generic
Aggregate Resource ReSerVation Protocol (RSVP)
Reservations", Work in Progress, January 2007.
[RSVPはAGGに情報を得ます]のLe Faucheur、R.、デイビー、B.、ボーズ、P.、マーチン、L.、クリストウ、C.、ダヴェンポート、M.、およびA.ハミルトン、「一般的な集合資源予約プロトコル(RSVP)予約」は進行中(2007年1月)で働いています。
[RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
[RSVP-IPSEC] バーガーとL.とT.オマリー、「IPSECデータフローのためのRSVP拡張子」、RFC2207、1997年9月。
[RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy
Element", RFC 3181, October 2001.
[RSVP-PREEMP] ハーツォグ、S.、「合図された先取り優先権方針要素」、RFC3181、2001年10月。
[RSVP-PROXY1] Gai, et al., RSVP Proxy, Work in Progress.
[RSVP-PROXY1] ガイ、他、RSVP Proxy、ProgressのWork。
[RSVP-PROXY2] Le Faucheur, et al., RSVP Proxy Approaches, Work in
Progress.
[RSVP-PROXY2] Le Faucheur、他、RSVP Proxy Approaches、ProgressのWork。
[RSVP-TUN] Terzis, A., Krawczyk, J., Wroclawski, J., and L.
Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
January 2000.
[RSVP-大酒樽] 2000年1月のTerzisとA.とKrawczykとJ.とWroclawski、J.とL.チャン、「IP Tunnelsの上のRSVP操作」RFC2746。
[SIP-RSVP] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session
Initiation Protocol (SIP)", RFC 3312, October 2002.
[一口RSVP] キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、「資源管理とセッション開始プロトコル(一口)の統合」、RFC3312(2002年10月)。
Faucheur Standards Track [Page 22] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[22ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator
付録A--RSVPアグリゲータにおけるRSVPプロキシの任意の使用
A number of approaches ([RSVP-PROXY1],[RSVP-PROXY2], [L-RSVP]) have been, or are being, discussed in the IETF in order to allow a network node to behave as an RSVP proxy which:
多くのアプローチ[RSVP-PROXY1]、[RSVP-PROXY2]、[L-RSVP)は、ネットワーク・ノードがRSVPプロキシとしてどれを振る舞わせるかを許容するためにあるか、存在であって、またはIETFで議論されています:
- originates the Resv Message (in response to the Path message) on
behalf of the destination node
- 目的地ノードを代表してResv Message(Pathメッセージに対応した)を溯源します。
- originates the Path message (in response to some trigger) on
behalf of the source node.
- ソースノードを代表してPathメッセージ(ある引き金に対応した)を溯源します。
We observe that such approaches may optionally be used in conjunction with the aggregation of RSVP reservations over MPLS TE tunnels as specified in this document. In particular, we consider the case where the RSVP Aggregator/Deaggregator also behaves as the RSVP proxy.
私たちは、そのようなアプローチが任意にこのドキュメントの指定されるとしてのMPLS TEトンネルの上のRSVPの予約の集合に関連して使用されるかもしれないのを観測します。 特に、私たちはまたRSVP Aggregator/DeaggregatorがRSVPプロキシとして振る舞うケースを考えます。
The information in this Appendix is purely informational and illustrative.
このAppendixの情報は、純粋に情報であって説明に役立っています。
As discussed in [RSVP-PROXY1]:
[RSVP-PROXY1]で議論するように:
"The proxy functionality does not imply merely generating a single Resv message. Proxying the Resv involves installing state in the node doing the proxy i.e. the proxying node should act as if it had received a Resv from the true endpoint. This involves reserving resources (if required), sending periodic refreshes of the Resv message and tearing down the reservation if the Path is torn down."
「ただ一つのResvメッセージを単に発生させている機能性が含意しないプロキシ。」 ResvをProxyingするのは、プロキシをするノードに状態をインストールすることを伴います、すなわち、まるで本当の終点からResvを受けたかのようにproxyingノードが行動するはずです。 「これは、Resvメッセージをリフレッシュして、Pathを取りこわすなら予約を取りこわしながら、リソース(必要なら)、発信を予約することを周期的に伴います。」
Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may effectively perform resource reservation over the MPLS TE tunnel (and hence over the whole segment between the RSVP Aggregator and the RSVP Deaggregator) even if the RSVP signaling only takes place upstream of the MPLS TE tunnel (i.e., between the host and the RSVP aggregator).
RSVP Proxyとして振る舞うとき、したがって、事実上、RSVP AggregatorがMPLS TEトンネルの上の資源予約を実行するかもしれない、(したがって、終わる、RSVP AggregatorとRSVP Deaggregatorの間の全体のセグメント) RSVPシグナリングが取るだけであっても、MPLS TEトンネル(すなわち、ホストとRSVPアグリゲータの間の)の上流を置いてください。
Also, the RSVP Proxy can generate the Path message on behalf of the remote source host in order to achieve reservation in the return direction (i.e., from RSVP aggregator/Deaggregator to host).
また、RSVP Proxyは、リモート送信元ホストを代表してリターン方向(すなわち、RSVPアグリゲータ/Deaggregatorからホストまでの)に予約を達成するためにPathメッセージを発生させることができます。
Faucheur Standards Track [Page 23] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[23ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
The resulting Signaling Flow is illustrated below, covering reservations for both directions:
両方の指示の予約をカバーしていて、結果として起こるSignaling Flowは以下で例証されます:
|----| |--------------| |------| |--------------| |----| | | | Aggregator/ | | MPLS | | Aggregator/ | | | |Host| | Deaggregator/| | cloud| | Deaggregator/| |Host| | | | RSVP Proxy | | | | RSVP Proxy | | | |----| |--------------| |------| |--------------| |----|
|----| |--------------| |------| |--------------| |----| | | | アグリゲータ/| | MPLS| | アグリゲータ/| | | |ホスト| | Deaggregator/| | 雲| | Deaggregator/| |ホスト| | | | RSVPプロキシ| | | | RSVPプロキシ| | | |----| |--------------| |------| |--------------| |----|
==========TE Tunnel==========>
<========= TE Tunnel==========
==========Teトンネル===========><==== Teトンネル==========
Path Path
------------> (1)-\ /-(i) <----------
Resv | | Resv
<------------ (2)-/ \-(ii) ------------>
Path Path
<------------ (3) (iii) ------------>
Resv Resv
------------> <------------
経路経路------------>(1)\/-(i)<。---------- Resv| | Resv<。------------ (2)-/\(ii)------------>経路経路<。------------ (3) (iii) ------------>Resv Resv------------><。------------
(1)(i) : Aggregator/Deaggregator/Proxy receives Path message,
selects the TE tunnel, performs admission control over the
TE tunnel. (1) and (i) happen independently of each other.
(1)(i): アグリゲータ/Deaggregator/プロキシは、Pathメッセージを受け取って、TEトンネルを選択して、TEトンネルの入場コントロールを実行します。 (1) (i) そして、互いの如何にかかわらず、起こってください。
(2)(ii) : Aggregator/Deaggregator/Proxy generates the Resv message
toward Host. (2) is triggered by (1) and (ii) is triggered
by (i). Before generating this Resv message, the
Aggregator/Proxy performs admission control of the
corresponding reservation over the TE tunnel that will
eventually carry the corresponding traffic.
(2)(ii): アグリゲータ/Deaggregator/プロキシはResvメッセージをHostに向かって発生させます。 (2) (1)によって引き起こされて、(i)によって引き起こされます(ii)。 このResvメッセージを発生させる前に、Aggregator/プロキシは結局対応する交通を運ぶTEトンネルの上の対応する予約の入場コントロールを実行します。
(3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message
toward Host for reservation in return direction. The
actual trigger for this depends on the actual RSVP proxy
solution. As an example, (3) and (iii) may simply be
triggered respectively by (1) and (i).
(3)(iii): アグリゲータ/Deaggregator/プロキシは予約のためにリターン指示でPathメッセージをHostに向かって発生させます。 これのための実際の引き金は実際のRSVPプロキシ解決策によります。 例として、(3)と(iii)は(1)と(i)によって単にそれぞれ引き起こされるかもしれません。
Note that the details of the signaling flow may vary slightly depending on the actual approach used for RSVP Proxy. For example, if the [L-RSVP] approach was used instead of [RSVP-PROXY1], an additional PathRequest message would be needed from host to Aggregator/Deaggregator/Proxy in order to trigger the generation of the Path message for return direction.
RSVP Proxyに使用される実際のアプローチによって、シグナリング流動の詳細がわずかに変わるかもしれないことに注意してください。 例えば、[L-RSVP]アプローチが[RSVP-PROXY1]の代わりに使用されるなら、追加PathRequestメッセージが、リターン方向へのPathメッセージの世代の引き金となるのにホストからAggregator/Deaggregator/プロキシまで必要でしょうに。
But regardless of the details of the call flow and of the actual RSVP Proxy approach, RSVP proxy may optionally be deployed in combination with RSVP Aggregation over MPLS TE tunnels, in such a way that
しかし、呼び出し流動と実際のRSVP Proxyアプローチの詳細にかかわらずRSVPプロキシはMPLS TEトンネルの上のRSVP Aggregationと組み合わせて任意に配備されるかもしれなくて、そのようなものの道はそれです。
Faucheur Standards Track [Page 24] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[24ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
ensures (when used on both the Host-Aggregator and Deaggregator-Host sides, and when both end systems support RSVP):
(いつ両方のHost-アグリゲータとDeaggregator-ホスト側で使用されて、両方のエンドシステムがRSVPを支持すると)を確実にするか:
(i) admission control and resource reservation is performed on
every segment of the end-to-end path (i.e., between source
host and Aggregator, over the TE tunnel between the
Aggregator and Deaggregator that itself has been subject to
admission control by MPLS TE, between Deaggregator and
destination host).
(i) 入場コントロールと資源予約は終わりから端への経路(すなわち、Aggregatorとそれ自体でMPLS TEによる入場コントロールを受けることがあるDeaggregator、Deaggregatorとあて先ホストの間のTEトンネルの上の送信元ホストとAggregatorの間の)のあらゆるセグメントに実行されます。
(ii) this is achieved in both directions.
(ii) これは両方の方向に達成されます。
(iii) RSVP signaling is localized between hosts and
Aggregator/Deaggregator, which may result in significant
reduction in reservation establishment delays (and in turn
in post-dial delay in the case where these reservations are
pre-conditions for voice call establishment), particularly
in the case where the MPLS TE tunnels span long distances
with high propagation delays.
(iii)RSVPシグナリングはホストとAggregator/Deaggregatorの間で局所化されます(ポストダイヤルでこれらの予約が音声通話設立のためのプレ状態である場合で順番に延着してください)、特にMPLS TEトンネルが高い伝播遅延で長距離を測る場合で。Aggregator/Deaggregatorは予約設立遅れのかなりの減少をもたらすかもしれません。
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for
VoIP Call Admission Control (CAC)
付録B--VoIPコール許可コントロールのためのDSTE Tunnelsの上のRSVP集合の例の用法(CAC)
This Appendix presents an example scenario where the mechanisms described in this document are used, in combination with other mechanisms specified by the IETF, to achieve Call Admission Control (CAC) of Voice over IP (VoIP) traffic over the packet core.
このAppendixは本書では説明されたメカニズムがIETFによって指定された他のメカニズムと組み合わせてパケットコアの上でボイス・オーバー IP(VoIP)交通のCall Admission Control(CAC)を達成するのに使用される例のシナリオを提示します。
The information in this Appendix is purely informational and illustrative.
このAppendixの情報は、純粋に情報であって説明に役立っています。
Consider the scenario depicted in Figure B1. VoIP Gateways GW1 and GW2 are both signaling and media gateways. They are connected to an MPLS network via edge routers PE1 and PE2, respectively. In each direction, a DSTE tunnel passes from the Head-end edge router, through core network P routers, to the Tail-end edge router. GW1 and GW2 are RSVP-enabled. The RSVP reservations established by GW1 and GW2 are aggregated by PE1 and PE2 over the DS-TE tunnels. For reservations going from GW1 to GW2, PE1 serves as the Aggregator/Head-end and PE2 serves as the Deaggregator/Tail-end. For reservations going from GW2 to GW2, PE2 serves as the Aggregator/Head-end and PE1 serves as the Deaggregator/Tail-end.
図B1に表現されたシナリオを考えてください。 VoIP Gateways GW1とGW2はシグナリングとメディアゲートウェイの両方です。 それらは縁のルータのPE1とPE2を通してそれぞれMPLSネットワークに接続されます。 各方向に、DSTEトンネルはHead-終わりの縁のルータから変化します、コアネットワークPルータを通して、Tail-終わりの縁のルータに。 GW1とGW2はRSVPによって可能にされます。 GW1とGW2によって確立されたRSVPの予約はDS-TEトンネルの上でPE1とPE2によって集められます。 GW1からGW2まで行く予約のために、PE1はAggregator/ギヤエンドとして機能します、そして、PE2はDeaggregator/末端として機能します。 GW2からGW2まで行く予約のために、PE2はAggregator/ギヤエンドとして機能します、そして、PE1はDeaggregator/末端として機能します。
To determine whether there is sufficient bandwidth in the MPLS core to complete a connection, the originating and destination GWs each send for each connection a Resource Reservation Protocol (RSVP) bandwidth request to the network PE router to which it is connected. As part of its Aggregator role, the PE router effectively performs
MPLSコアの接続を終了できるくらいの帯域幅、由来、および目的地があるかどうか決定するために、GWsは各接続のためにそれぞれResource予約プロトコル(RSVP)帯域幅要求をそれが関連しているネットワークPEルータに送ります。 Aggregatorの役割の一部として、事実上、PEルータは働きます。
Faucheur Standards Track [Page 25] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[25ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
admission control of the bandwidth request generated by the GW onto the resources of the corresponding DS-TE tunnel.
GWによって対応するDS-TEトンネルに関するリソースに発生した帯域幅要求の入場コントロール。
In this example, in addition to behaving as Aggregator/Deaggregator, PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path message from a GW, it does not propagate the Path message any further. Rather, the PE performs admission control of the bandwidth signaled in the Path message over the DSTE tunnel toward the destination. Assuming there is enough bandwidth available on that tunnel, the PE adjusts its bookkeeping of remaining available bandwidth on the tunnel and generates a Resv message back toward the GW to confirm resources have been reserved over the DSTE tunnel.
この例Aggregator/Deaggregatorとして振る舞うことに加えて、PE1とPE2はRSVPプロキシとして振る舞います。 それで、PEがGWからPathメッセージを受け取るとき、それはPathメッセージをこれ以上伝播しません。 むしろ、PEはDSTEトンネルの上でPathメッセージで合図された帯域幅の入場コントロールを目的地に向かって実行します。 そのトンネルで利用可能な帯域幅が十分あると仮定して、PEは、トンネルの上に利用可能な帯域幅のままで残る簿記を調整して、リソースがDSTEトンネルの上で予約されたと確認するためにResvメッセージをGWに向かって発生して戻させます。
,-. ,-.
_.---' `---' `-+
,-'' +------------+ :
( | | `.
\ ,' CCA `. :
\ ,' | | `. ;
;' +------------+ `._
,'+ ; `.
,' -+ Application Layer' `.
SIP,' `---+ | ; `.SIP
,' `------+---' `.
,' `.
,' `.
,' ,-. ,-. `.
,' ,--+ `--+--'- --'\ `._
+-`--+_____+------+ { +----+ +----+ `. +------+_____+----+
|GW1 | RSVP| |______| P |___| P |______| | RSVP|GW2 |
| |-----| PE1 | { +----+ +----+ /+| PE2 |-----| |
| | | |==========================>| | | |
+-:--+ RTP | |<==========================| | RTP +-:--+
_|..__ +------+ { DSTE Tunnels ; +------+ __----|--.
_,' \-| ./ -'._ / |
| Access \ / +----+ \, |_ Access |
| Network | \_ | P | | / Network |
| / `| +----+ / | '
`--. ,.__,| | IP/MPLS Network / '---'- ----'
'`' '' ' .._,,'`.__ _/ '---' |
| '`''' |
C1 C2
,-. ,-. _.---' `---' `-+ ,-'' +------------+ : ( | | `. \ ,' CCA `. : \ ,' | | `. ; ;' +------------+ `._ ,'+ ; `. ,' -+ Application Layer' `. SIP,' `---+ | ; `.SIP ,' `------+---' `. ,' `. ,' `. ,' ,-. ,-. `. ,' ,--+ `--+--'- --'\ `._ +-`--+_____+------+ { +----+ +----+ `. +------+_____+----+ |GW1 | RSVP| |______| P |___| P |______| | RSVP|GW2 | | |-----| PE1 | { +----+ +----+ /+| PE2 |-----| | | | | |==========================>| | | | +-:--+ RTP | |<==========================| | RTP +-:--+ _|..__ +------+ { DSTE Tunnels ; +------+ __----|--. _,' \-| ./ -'._ / | | Access \ / +----+ \, |_ Access | | Network | \_ | P | | / Network | | / `| +----+ / | ' `--. ,.__,| | IP/MPLS Network / '---'- ----' '`' '' ' .._,,'`.__ _/ '---' | | '`''' | C1 C2
Figure B1. Integration of SIP Resource Management and
RSVP Aggregation over MPLS TE Tunnels
図B1。 MPLS TE Tunnelsの上の一口資源管理とRSVP集合の統合
[SIP-RSVP] discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session
[SIP-RSVP]は人工のaがSessionによって開始されたセッションの設立のための前提条件であったかもしれないならサービスについてネットワーク上質でその方法について議論します。
Faucheur Standards Track [Page 26] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[26ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
Initiation Protocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. The reservation of network resources are performed through a signaling protocol such as RSVP.
開始プロトコル(一口)。 これらの前提条件は、セッションを続行する前に関係者がネットワーク資源を予約するのを必要とします。 ネットワーク資源の予約はRSVPなどのシグナリングプロトコルを通して実行されます。
Through the collaboration between SIP resource management, RSVP signaling, RSVP Aggregation and DS-TE as described above, we see that:
上で説明されるSIP資源管理と、RSVPシグナリングと、RSVP AggregationとDS-TEとの共同で、私たちは、以下のことがわかります。
a) the PE and GW collaborate to determine whether there is enough
bandwidth on the tunnel between the calling and called GWs to
accommodate the connection,
a) PEとGWは、呼ぶのと呼ばれたGWsの間のトンネルの上に帯域幅が接続を収容できるくらいあるかを決定するために共同します。
b) the corresponding accept/reject decision is communicated to the
GWs on a connection-by-connection basis, and
b) 対応は受け入れます。そして/廃棄物決定が接続による接続ベースのGWsに伝えられる。
c) the PE can optimize network resources by dynamically adjusting
the bandwidth of each tunnel according to the load over that
tunnel. For example, if a tunnel is operating at near
capacity, the network may dynamically adjust the tunnel size
within a set of parameters.
c) PEは、そのトンネルの上の負荷に応じてダイナミックにそれぞれのトンネルの帯域幅を調整することによって、ネットワーク資源を最適化できます。 例えば、トンネルが近い容量で作動しているなら、ネットワークはパラメタのセットの中でダイナミックにトンネルサイズを調整するかもしれません。
We note that admission Control of voice calls over the core network capacity is achieved in a hierarchical manner whereby:
私たちが、コアネットワーク容量の上音声通話の入場Controlが階層的な方法で達成されることに注意する、どうして、:
- DSTE tunnels are subject to Admission Control over the resources
of the MPLS TE core
- DSTEトンネルはMPLS TEコアに関するリソースの上でAdmission Controlを受けることがあります。
- Voice calls are subject to CAC over the DSTE tunnel bandwidth
- 音声通話はDSTEトンネル帯域幅の上でCACを受けることがあります。
This hierarchy is a key element in the scalability of this CAC solution for voice calls over an MPLS Core.
この階層構造はMPLS Coreの上の音声通話のこのCAC解決策のスケーラビリティで主要な要素です。
It is also possible for the GWs to use aggregate RSVP reservations themselves instead of per-call RSVP reservations. For example, instead of setting one reservation for each call GW1 has in place toward GW2, GW1 may establish one (or a small number of) aggregate reservations as defined in [RSVP-AGG] or [RSVP-GEN-AGG], which is used for all (or a subset of all) the calls toward GW2. This effectively provides an additional level of hierarchy whereby:
また、GWsが1呼び出しあたりのRSVPの予約の代わりに集合RSVPの予約自体を使用するのも、可能です。 例えば、GW1が適所にGW2に向かって持っているそれぞれの呼び出しの1つの予約を設定することの代わりにGW1が1つを設立するかもしれない、(少ない数、)、[RSVP-AGG]か[RSVP-GEN-AGG](呼び出しにGW2に向かって使用される)で定義されるように予約に集めてください。 事実上、これが追加レベルの階層構造を提供する、どうして、:
- DSTE tunnels are subject to Admission Control over the resources
of the MPLS TE core
- DSTEトンネルはMPLS TEコアに関するリソースの上でAdmission Controlを受けることがあります。
- Aggregate RSVP reservations (for the calls from one GW to
another GW) are subject to Admission Control over the DSTE
tunnels (as per the "RSVP Aggregation over TE Tunnels"
procedures defined in this document)
- 集合RSVP条件(1GWから別のGWまでの呼び出しのための)はDSTEトンネルの上でAdmission Controlを受けることがあります。(「Teの上のRSVP集合はトンネルを堀ること」手順が本書では定義したに従って)
Faucheur Standards Track [Page 27] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[27ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
- Voice calls are subject to CAC by the GW over the aggregate
reservation toward the appropriate destination GW.
- 音声通話は適切な目的地GWに向かった集合予約の上でGWでCACを受けることがあります。
This pushes even further the scalability limits of this voice CAC architecture.
これはさらにさえこの声のCAC構造のスケーラビリティ限界を押します。
Faucheur Standards Track [Page 28] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[28ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
Contributing Authors
作者を寄付します。
This document was the collective work of several authors. The text and content were contributed by the editor and the co-authors listed below.
このドキュメントは数人の作者の集合著作物でした。 テキストと内容はエディタと以下に記載された共著者によって寄付されました。
Michael DiBiasio Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: dibiasio@cisco.com
ビーバーブルック道路Boxborough、マイケルDiBiasioシスコシステムズInc.300MA01719米国はメールされます: dibiasio@cisco.com
Bruce Davie Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: bdavie@cisco.com
ビーバーブルック道路Boxborough、ブルースデイビーシスコシステムズInc.300MA01719米国はメールされます: bdavie@cisco.com
Christou Christou Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USA EMail: christou_chris@bah.com
クリストウ・クリストウ・Boozアレン・ハミルトン8283・グリーンスバロDriveヴァージニア22102マクリーン(米国)はメールされます: christou_chris@bah.com
Michael Davenport Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USA EMail: davenport_michael@bah.com
マイケル・ダヴェンポート・Boozアレン・ハミルトン8283・グリーンスバロDriveヴァージニア22102マクリーン(米国)はメールされます: davenport_michael@bah.com
Jerry Ash AT&T 200 Laurel Avenue Middletown, NJ 07748 USA EMail: gash@att.com
ジェリー灰のAT&T200ローレルアベニューミドルタウン、ニュージャージー07748米国メール: gash@att.com
Bur Goode AT&T 32 Old Orchard Drive Weston, CT 06883 USA EMail: bgoode@att.com
CT06883米国のいがのグードAT&T32の年取った果樹園Driveウェストンはメールします: bgoode@att.com
Faucheur Standards Track [Page 29] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[29ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
Editor's Address
エディタのアドレス
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot Sophia-Antipolis France
フランソアLe FaucheurシスコシステムズInc.Village d'EntrepriseグリーンSide--Batiment T3 400、アベニューdeルーマニーユ06410・Biotソフィア-Antipolisフランス
EMail: flefauch@cisco.com
メール: flefauch@cisco.com
Faucheur Standards Track [Page 30] RFC 4804 RSVP Aggregation over MPLS TE Tunnels February 2007
MPLS Teの上のFaucheur標準化過程[30ページ]RFC4804RSVP集合は2007年2月にトンネルを堀ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Faucheur Standards Track [Page 31]
Faucheur標準化過程[31ページ]
一覧
スポンサーリンク
