RFC4860 日本語訳
4860 Generic Aggregate Resource ReSerVation Protocol (RSVP)Reservations. F. Le Faucheur, B. Davie, P. Bose, C. Christou, M.Davenport. May 2007. (Format: TXT=73010 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Le Faucheur
Request for Comments: 4860 B. Davie
Category: Standards Track Cisco Systems, Inc.
P. Bose
Lockheed Martin
C. Christou
M. Davenport
Booz Allen Hamilton
May 2007
Le Faucheurがコメントのために要求するワーキンググループF.をネットワークでつないでください: 4860年のB.デイビーカテゴリ: 標準化過程シスコシステムズInc.P.ボーズロッキード・マーチンC.クリストウM.ダヴェンポートBoozアレンハミルトン2007年5月
Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations
一般的な集合資源予約プロトコル(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 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC 3175 also defines how end- to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network.
RFC3175はリソースが与えられたPer Hop Behavior(PHB)のためにDiffservネットワークで予約されるか、またはPHBsのセットに与えられているのを許容する集合Resource ReSerVationプロトコル(RSVP)の予約を、定義します、与えられたソースから与えられた目的地まで。 また、RFC3175はDiffserv雲を通して通過するとき、どう終わりまでの終わりのRSVPの予約をそのような集合予約に集めることができるかを定義します。 状況が複数のそのようなもの集合の予約が同じソースIPのアドレス、送付先IPアドレス、およびPHB(または、PHBsのセット)に必要であるところにあります。 しかしながら、これはRFC3175で定義された集合予約で支持されません。 これを支持するために、現在のドキュメントは一般的な集合予約と呼ばれたよりフレキシブルなタイプの集合RSVPの予約を定義します。 与えられたPHB(または、PHBsのセット)のために与えられたソースIPアドレスから与えられた送付先IPアドレスまで複数のそのようなもの一般的な集合予約を確立できます。 一般的な集合予約は、終わりから終わりへのRSVP予約に集めるのに使用されるかもしれません。 また、このドキュメントはそのような集合のために手順を定義します。 また、一般的な集合予約は、直接Diffservネットワークに取り付けられたエンドシステムによる、中古の終わりから終わりであるかもしれません。
Le Faucheur, et al. Standards Track [Page 1] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Related IETF Documents .....................................6
1.2. Organization of This Document ..............................6
1.3. Requirements Language ......................................7
2. Object Definition ...............................................7
2.1. SESSION Class ..............................................8
2.2. SESSION-OF-INTEREST (SOI) Class ...........................11
3. Processing Rules for Handling Generic Aggregate RSVP
Reservations ...................................................13
3.1. Extensions to Path and Resv Processing ....................13
4. Procedures for Aggregation over Generic Aggregate RSVP
Reservations ...................................................14
5. Example Usage Of Multiple Generic Aggregate Reservations
per PHB from a Given Aggregator to a Given Deaggregator ........19
6. Security Considerations ........................................21
7. IANA Considerations ............................................24
8. Acknowledgments ................................................25
9. Normative References ...........................................26
10. Informative References ........................................26
Appendix A. Example Signaling Flow ................................28
1. 序論…3 1.1. IETFドキュメントについて話します…6 1.2. このドキュメントの組織…6 1.3. 要件言語…7 2. 物の定義…7 2.1. セッションのクラス…8 2.2. 興味があるセッション(SOI)のクラス…11 3. 処理は取り扱いの一般的な集合RSVP予約のために統治されます…13 3.1. 経路への拡大とResv処理…13 4. ジェネリックの上の集合のための手順はRSVP予約に集められます…14 5. 複数の与えられたアグリゲータから与えられたDeaggregatorまでのPHBあたりの一般的な集合予約の例の用法…19 6. セキュリティ問題…21 7. IANA問題…24 8. 承認…25 9. 標準の参照…26 10. 有益な参照…26付録A.例のシグナリングは流れます…28
Le Faucheur, et al. Standards Track [Page 2] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[2ページ]。
1. Introduction
1. 序論
[RSVP-AGG] defines RSVP aggregate reservations that allow resources to be reserved in a Diffserv network for a flow characterized by its 3-tuple <source IP address, destination IP address, Diffserv Code Point>.
[RSVP-AGG]はリソースが3-tuple<ソースIPアドレスによって特徴付けられた流れのためにDiffservネットワークで予約されるのを許容するRSVPの集合予約を定義します、送付先IPアドレス、Diffserv Code Point>。
[RSVP-AGG] also defines the procedures for aggregation of end-to-end (E2E) RSVP reservations onto such aggregate reservations when transiting through a Diffserv cloud. Such aggregation is illustrated in Figure 1. This document reuses the terminology defined in [RSVP-AGG].
また、Diffserv雲を通して通過するとき、[RSVP-AGG]は終わりから終わり(2EのE)へのRSVP予約の集合のためにそのような集合予約と手順を定義します。 そのような集合は図1で例証されます。 このドキュメントは[RSVP-AGG]で定義された用語を再利用します。
--------------------------
/ Aggregation \
|----| | Region | |----|
H--| R |\ |-----| |------| /| R |-->H
H--| |\\| | |---| |---| | |//| |-->H
|----| \| | | I | | I | | |/ |----|
| Agg |======================>| Deag |
/| | | | | | | |\
H--------//| | |---| |---| | |\\-------->H
H--------/ |-----| |------| \-------->H
| |
\ /
--------------------------
-------------------------- /集合、\|----| | 領域| |----| H--| R|\ |-----| |------| /| R|-->H H--| |\\| | |---| |---| | |//| |-->H|----| \| | | I| | I| | |/ |----| | Agg|======================>| Deag| /| | | | | | | |\H--------//| | |---| |---| | |\\-------->H H--------/ |-----| |------| \-------->H| | \ / --------------------------
H = Host requesting end-to-end RSVP reservations R = RSVP router Agg = Aggregator Deag = Deaggregator I = Interior Router
RSVPルータAggホスト要求終わりから終わりへのRSVP予約H=R==アグリゲータDeag=Deaggregator Iは内部のRouterと等しいです。
--> = E2E RSVP reservation ==> = Aggregate RSVP reservation
-->はE2E RSVPの予約=>=の集合RSVPの予約と等しいです。
Figure 1 : Aggregation of E2E Reservations
over Aggregate RSVP Reservations
図1: 集合RSVP予約の上の2ユーロのE予約の集合
These aggregate reservations use a SESSION type specified in [RSVP-AGG] that contains the receiver (or Deaggregator) IP address and the Diffserv Code Point (DSCP) of the Per Hop Behavior (PHB) from which Diffserv resources are to be reserved. For example, in the case of IPv4, the SESSION object is specified as:
これらの集合予約は受信機(または、Deaggregator)IPアドレスを含む[RSVP-AGG]と予約されているDiffservリソースがことであるPer Hop Behavior(PHB)のDiffserv Code Point(DSCP)で指定されたSESSIONタイプを使用します。 例えば、IPv4の場合では、SESSION物は以下として指定されます。
Le Faucheur, et al. Standards Track [Page 3] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[3ページ]。
o Class = SESSION,
C-Type = RSVP-AGGREGATE-IP4
o RSVPの集合クラス=セッション、C-タイプ=IP4
+-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | IPv4 Session Address(4バイト)| +-------------+-------------+-------------+-------------+ | /////////// | 旗| ///////// | DSCP| +-------------+-------------+-------------+-------------+
These aggregate reservations use SENDER_TEMPLATE and FILTER_SPEC types, specified in [RSVP-AGG], that contain only the sender (or Aggregator) IP address. For example, in the case of IPv4, the SENDER_TEMPLATE object is specified as:
これらの集合予約は送付者(または、Aggregator)IPアドレスだけを含む[RSVP-AGG]で指定されたSENDER_TEMPLATEとFILTER_SPECタイプを使用します。 例えば、IPv4の場合では、SENDER_TEMPLATE物は以下として指定されます。
o Class = SENDER_TEMPLATE,
C-Type = RSVP-AGGREGATE-IP4
o RSVPの集合クラス=送付者_テンプレート、C-タイプ=IP4
+-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | IPv4 Aggregator Address(4バイト)| +-------------+-------------+-------------+-------------+
Thus, it is possible to establish, from a given source IP address to a given destination IP address, separate such aggregate reservations for different PHBs (or different sets of PHBs). However, from a given source IP address to a given IP destination address, only a single [RSVP-AGG] aggregate reservation can be established for a given PHB (or given set of PHBs).
したがって、それは設立するのにおいて可能です、与えられたソースIPアドレスから与えられた送付先IPアドレスまで、異なったPHBs(または、PHBsの異なったセット)の別々のそのようなもの集合の予約。 しかしながら、与えられたソースIPアドレスから与えられた受信者IPアドレスまで、与えられたPHBのためにただ一つの[RSVP-AGG]集合予約しか確立できません(PHBsのセットを考えて)。
Situations have since been identified where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). One example is where E2E reservations using different preemption priorities (as per [RSVP-PREEMP]) need to be aggregated through a Diffserv cloud using the same PHB. Using multiple aggregate reservations for the same PHB allows enforcement of the different preemption priorities within the aggregation region. In turn, this allows more efficient management of the Diffserv resources, and in periods of resource shortage, this allows sustainment of a larger number of E2E reservations with higher preemption priorities.
複数のそのようなもの集合の予約が同じソースIPのアドレス、送付先IPアドレス、およびPHB(または、PHBsのセット)に必要であるところで状況は以来、特定されています。 1つの例が異なった先取りプライオリティ([RSVP-PREEMP]に従って)を使用する2ユーロのEの予約がDiffserv雲を通して同じPHBを使用することで集められる必要があるところです。 同じPHBにおいて複数の集合予約を使用すると、異なった先取りプライオリティの実施は集合領域の中で許されます。 順番に、これはDiffservリソースの、より効率的な管理を許します、そして、リソース不足の時代に、より高い先取りプライオリティがある2ユーロの予約をより多くのEの持続に許します。
For example, [SIG-NESTED] discusses in detail how end-to-end RSVP reservations can be established in a nested VPN environment through RSVP aggregation. In particular, [SIG-NESTED] describes how multiple parallel generic aggregate reservations (for the same PHB), each with different preemption priorities, can be used to efficiently support the preemption priorities of end-to-end reservations.
例えば、[SIG-NESTED]は詳細にRSVP集合を通してどう終わりから終わりへのRSVP予約を入れ子にされたVPN環境に確立できるかについて議論します。 特に、[SIG-NESTED]は効率的に終わりから終わりへの予約の先取りプライオリティを支持するのに、どう、複数の平行な一般的な集合条件(同じPHBのための)(異なった先取りプライオリティがあるそれぞれ)を使用できるかを説明します。
Le Faucheur, et al. Standards Track [Page 4] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[4ページ]。
This document addresses this requirement for multiple aggregate reservations for the same PHB (or same set of PHBs), by defining a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservations. This is achieved primarily by adding the notions of a Virtual Destination Port and of an Extended Virtual Destination Port in the RSVP SESSION object.
このドキュメントは同じPHB(または、PHBsの同じセット)において複数の集合予約のためのこの要件を記述します、一般的な集合予約と呼ばれたよりフレキシブルなタイプの集合RSVPの予約を定義することによって。 これは、主としてRSVP SESSION物でVirtual Destination PortとExtended Virtual Destination Portの概念を加えることによって、達成されます。
The notion of Virtual Destination Port was introduced in [RSVP-IPSEC] to address a similar requirement (albeit in a different context) for identification and demultiplexing of sessions beyond the IP destination address. This document reuses this notion from [RSVP-IPSEC] for identification and demultiplexing of generic aggregate sessions beyond the IP destination address and PHB. This allows multiple generic aggregate reservations to be established for a given PHB (or set of PHBs), from a given source IP address to a given destination IP address.
Virtual Destination Portの概念は、セッションの識別と逆多重化のために受信者IPアドレスを超えて同様の要件を記述する(それにしても異なった文脈で)ために[RSVP-IPSEC]で紹介されました。 このドキュメントは一般的な集合セッションの識別と逆多重化のために受信者IPアドレスとPHBを超えて[RSVP-IPSEC]からこの概念を再利用します。 これは、複数の一般的な集合予約が与えられたPHB(または、PHBsのセット)のために確立されるのを許容します、与えられたソースIPアドレスから与えられた送付先IPアドレスまで。
[RSVP-TE] introduced the concept of an Extended Tunnel ID (in addition to the tunnel egress address and the Tunnel ID) in the SESSION object used to establish MPLS Traffic Engineering tunnels with RSVP. The Extended Tunnel ID provides a very convenient mechanism for the tunnel ingress node to narrow the scope of the session to the ingress-egress pair. The ingress node can achieve this by using one of its own IP addresses as a globally unique identifier and including it in the Extended Tunnel ID and therefore within the SESSION object. This document reuses this notion of Extended Tunnel ID from [RSVP-TE], simply renaming it Extended Virtual Destination Port. This provides a convenient mechanism to narrow the scope of a generic aggregate session to an Aggregator- Deaggregator pair.
[RSVP-TE]はRSVPと共にMPLS Traffic Engineeringトンネルを証明するのに使用されるSESSION物でExtended Tunnel ID(トンネル出口アドレスとTunnel IDに加えた)の概念を紹介しました。 トンネルイングレスノードがイングレス出口組にセッションの範囲を狭くするように、Extended Tunnel IDは非常に便利なメカニズムを提供します。 イングレスノードは、グローバルにユニークな識別子としてそれ自身のIPアドレスの1つを使用して、したがって、Extended Tunnel IDとSESSION物の中にそれを含んでいることによって、これを実現できます。 単にそれをExtended Virtual Destination Portに改名して、このドキュメントは[RSVP-TE]からExtended Tunnel IDのこの概念を再利用します。 これは、一般的な集合セッションの範囲をAggregator- Deaggregator組に狭くするために便利なメカニズムを提供します。
The RSVP SESSION object for generic aggregate reservations uses the PHB Identification Code (PHB-ID) defined in [PHB-ID] to identify the PHB, or set of PHBs, from which the Diffserv resources are to be reserved. This is instead of using the Diffserv Code Point (DSCP) as per [RSVP-AGG]. Using the PHB-ID instead of the DSCP allows explicit indication of whether the Diffserv resources belong to a single PHB or to a set of PHBs. It also facilitates handling of situations where a generic aggregate reservation spans two (or more) Diffserv domains that use different DSCP values for the same Diffserv PHB (or set of PHBs) from which resources are reserved. This is because the PHB-ID allows conveying of the PHB (or set of PHBs) independently of what DSCP value(s) are used locally for that PHB (or set of PHBs).
一般的な集合予約のためのRSVP SESSION物は(PHB-ID)がPHBを特定するか、またはセットするために[PHB-ID]で定義したPHBsのPHB Identification Codeを使用します。(DiffservリソースはPHBsから予約されていることです)。 [RSVP-AGG]に従ってDiffserv Code Point(DSCP)を使用することの代わりにこれはあります。 DSCPの代わりにPHB-IDを使用すると、Diffservリソースが独身のPHB、または、PHBsの1セットに属するかどうか明白なしるしは許容されます。 また、それは一般的な集合予約がリソースが予約されているのと同じDiffserv PHB(または、PHBsのセット)に異なったDSCP値を使用する2つ(さらに)のDiffservドメインにかかる状況の取り扱いを容易にします。 これはどんなDSCP値がそのPHB(または、PHBsのセット)に局所的に使用されるかの如何にかかわらずPHB-IDがPHB(または、PHBsのセット)を運ばせるからです。
The generic aggregate reservations may be used to aggregate end-to- end RSVP reservations. This document also defines the procedures for such aggregation. These procedures are based on those of [RSVP-AGG], and this document only specifies the differences from those.
一般的な集合予約は、終わりから終わりへのRSVP予約に集めるのに使用されるかもしれません。 また、このドキュメントはそのような集合のために手順を定義します。 これらの手順は[RSVP-AGG]のものに基づいています、そして、このドキュメントはそれらから違いを指定するだけです。
Le Faucheur, et al. Standards Track [Page 5] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[5ページ]。
The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network.
また、一般的な集合予約は、直接Diffservネットワークに取り付けられたエンドシステムによる、中古の終わりから終わりであるかもしれません。
1.1. Related IETF Documents
1.1. 関連IETFドキュメント
This document is heavily based on [RSVP-AGG]. It reuses [RSVP-AGG] wherever applicable and only specifies the necessary extensions beyond [RSVP-AGG].
このドキュメントはずっしりと[RSVP-AGG]に基づいています。 それは、どこでも、適切であるところで[RSVP-AGG]を再利用して、[RSVP-AGG]を超えて必要な拡大を指定するだけです。
The mechanisms defined in [BW-REDUC] allow an existing reservation to be reduced in allocated bandwidth by RSVP routers in lieu of tearing that reservation down. These mechanisms are applicable to the generic aggregate reservations defined in the present document.
[BW-REDUC]で定義されたメカニズムは、その予約を取りこわすことの代わりに既存の予約が割り当てられた帯域幅でRSVPルータによって抑えられるのを許容します。 これらのメカニズムは現在のドキュメントで定義された一般的な集合予約に適切です。
[RSVP-TUNNEL] describes a general approach to running RSVP over various types of tunnels. One of these types of tunnel, referred to as a "type 2 tunnel", has some similarity with the generic aggregate reservations described in this document. The similarity stems from the fact that a single, aggregate reservation is made for the tunnel while many individual flows are carried over that tunnel. However, [RSVP-TUNNEL] does not address the use of Diffserv-based classification and scheduling in the core of a network (between tunnel endpoints), but rather relies on a UDP/IP tunnel header for classification. This is why [RSVP-AGG] required additional objects and procedures beyond those of [RSVP-TUNNEL]. Like [RSVP-AGG], this document also assumes the use of Diffserv-based classification and scheduling in the aggregation region and, thus, requires additional objects and procedures beyond those of [RSVP-TUNNEL].
[RSVP-TUNNEL]は様々なタイプのトンネルに走行RSVPに一般的方法を説明します。 「タイプ2トンネル」と呼ばれたトンネルのこれらのタイプのひとりに、一般的な集合予約が本書では説明されている何らかの類似性があります。 類似性はそのトンネルの上まで多くの個々の流れを運びますが、トンネルの単一の、そして、集合の予約をするという事実によります。 しかしながら、[RSVP-TUNNEL]は、ネットワーク(トンネル終点の間の)のコアにDiffservベースの分類とスケジューリングの使用を記述しませんが、分類のためにむしろUDP/IPトンネルヘッダーを当てにします。 これは[RSVP-AGG]が[RSVP-TUNNEL]のものを超えて追加物と手順を必要とした理由です。 [RSVP-AGG]のように、このドキュメントは、また、集合領域でDiffservベースの分類とスケジューリングの使用を仮定して、その結果、[RSVP-TUNNEL]のものを超えて追加物と手順を必要とします。
As explained earlier, this document reuses the notion of Virtual Destination Port from [RSVP-IPSEC] and the notion of Extended Tunnel ID from [RSVP-TE].
より早く説明されるように、このドキュメントは[RSVP-TE]から[RSVP-IPSEC]からのVirtual Destination Portの概念とExtended Tunnel IDの概念を再利用します。
1.2. Organization Of This Document
1.2. このドキュメントの組織
Section 2 defines the new RSVP objects related to generic aggregate reservations and to aggregation of E2E reservations onto those. Section 3 describes the processing rules for handling of generic aggregate reservations. Section 4 specifies the procedures for aggregation of end-to-end RSVP reservations over generic aggregate RSVP reservations. Section 5 provides example usage of how the generic aggregate reservations may be used.
セクション2は一般的な集合予約と、そして、2ユーロのEの予約の集合に関係づけられた新しいRSVP物をそれらと定義します。 セクション3は一般的な集合予約の取り扱いのための処理規則について説明します。 セクション4は一般的な集合RSVPの予約の上の終わりから終わりへのRSVP予約の集合に手順を指定します。 セクション5は一般的な集合予約がどう使用されるかもしれないかに関する例の用法を提供します。
The Security Considerations and the IANA Considerations are discussed in Sections 6 and 7, respectively.
セクション6と7でそれぞれSecurity ConsiderationsとIANA Considerationsについて議論します。
Le Faucheur, et al. Standards Track [Page 6] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[6ページ]。
Finally, Appendix A provides an example signaling flow that illustrates aggregation of E2E RSVP reservations onto generic aggregate RSVP reservations.
最終的に、Appendix Aは2ユーロのE RSVPの予約の集合を一般的な集合RSVPの予約に例証する例のシグナリング流動を供給します。
1.3. Requirements Language
1.3. 要件言語
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 RFC 2119 [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?
2. Object Definition
2. オブジェクト定義
This document reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP- AGGREGATE-IP6 FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE, and RSVP-AGGREGATE-IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG].
このドキュメントはTEMPLATE物が[RSVP-AGG]で定義したRSVP-AGGREGATE-IP4 FILTER_SPEC、RSVP- AGGREGATE-IP6 FILTER_SPEC、RSVP-AGGREGATE-IP4 SENDER_TEMPLATE、およびRSVP-AGGREGATE-IP6 SENDER_を再利用します。
This document defines:
このドキュメントは以下を定義します。
- two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC-
AGGREGATE-IP6 SESSION) under the existing SESSION Class, and
- そして既存のSESSION Classの下の2個の新しい物(GENERIC-AGGREGATE-IP4 SESSIONとGENERIC- AGGREGATE-IP6 SESSION)。
- two new objects (GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI)
under a new SESSION-OF-INTEREST Class.
- 新しいSESSION-OF-INTEREST Classの下の2個の新しい物(GENERIC-AGG-IP4-SOIとGENERIC-AGG-IP6-SOI)。
Detailed description of these objects is provided below in this section.
このセクションでこれらの物の詳述を以下に提供します。
The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION objects are applicable to all types of RSVP messages.
GENERIC-AGGREGATE-IP4 SESSIONとGENERIC-AGGREGATE-IP6 SESSION物はすべてのタイプに関するRSVPメッセージに適切です。
This specification defines the use of the GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI objects in two circumstances:
この仕様は2つの事情におけるGENERIC-AGG-IP4-SOIとGENERIC-AGG-IP6-SOI物の使用を定義します:
- inside an E2E PathErr message that contains an error code of
NEW-AGGREGATE-NEEDED in order to convey the session of a new
generic aggregate reservation that needs to be established.
- E2E PathErrメッセージでは、それは、設立される必要がある新しい一般的な集合予約のセッションを伝えるためにNEW-AGGREGATEによって必要のエラーコードを含んでいます。
- inside an E2E Resv message in order to convey the session of the
generic aggregate reservation onto which this E2E reservation
needs to be mapped.
- E2E Resvメッセージでは、この2ユーロのEの予約が必要がある一般的な集合予約のセッションを伝えるには、写像されてください。
Details of the corresponding procedures can be found in Section 4.
セクション4で対応する手順の詳細を見つけることができます。
However, it is envisioned that the ability to signal, inside RSVP messages, the Session of another reservation (which has some relationship with the current RSVP reservation) might have some other applicability in the future. Thus, those objects have been specified in a more generic manner under a flexible SESSION-OF-INTEREST class.
しかしながら、それは思い描かれます。RSVPメッセージで別の条件(現在のRSVPの予約との何らかの関係を持っている)のSessionに合図する能力には、ある他の適用性が将来、あるかもしれません。 したがって、それらの物はフレキシブルなSESSION-OF-INTERESTのクラスの下で、より一般的な方法で指定されました。
Le Faucheur, et al. Standards Track [Page 7] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[7ページ]。
All the new objects defined in this document are optional with respect to RSVP so that general RSVP implementations that are not concerned with generic aggregate reservations do not have to support these objects. RSVP routers supporting generic aggregate IPv4 or IPv6 reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION object or the GENERIC-AGGREGATE-IP6 SESSION object, respectively. RSVP routers supporting RSVP aggregation over generic aggregate IPv4 or IPv6 reservations MUST support the GENERIC-AGG-IP4-SOI object or GENERIC-AGG-IP6-SOI object, respectively.
本書では定義されたすべての新しい物がRSVPに関して任意であるので、一般的な集合予約に関しない一般的なRSVP実現はこれらの物を支える必要はありません。 一般的な集合IPv4を支持するRSVPルータかIPv6の予約がGENERIC-AGGREGATE-IP4 SESSION物を支えなければならない、さもなければ、GENERIC-AGGREGATE-IP6 SESSIONはそれぞれ反対します。 一般的な集合IPv4の上でRSVP集合を支持するRSVPルータかIPv6の予約がGENERIC-AGG-IP4-SOI物を支えなければならない、さもなければ、GENERIC-AGG-IP6-SOIはそれぞれ反対します。
2.1. SESSION Class
2.1. セッションのクラス
o GENERIC-AGGREGATE-IP4 SESSION object:
Class = 1 (SESSION)
C-Type = 17
o GENERIC-AGGREGATE-IP4 SESSIONは反対します: クラス=1(セッション)C-タイプ=17
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31
0 7 8 15 16 23 24 31 +-------------+-------------+-------------+-------------+ | IPv4 DestAddress(4バイト)| +-------------+-------------+-------------+-------------+ | 予約されます。| 旗| PHB-ID| +-------------+-------------+-------------+-------------+ | 予約されます。| vDstPort| +-------------+-------------+-------------+-------------+ | 拡張vDstPort| +-------------+-------------+-------------+-------------+ 0 7 8 15 16 23 24 31
IPv4 DestAddress (IPv4 Destination Address)
IPv4 DestAddress(IPv4送付先アドレス)
IPv4 address of the receiver (or Deaggregator).
受信機(または、Deaggregator)のIPv4アドレス。
Reserved
予約されます。
An 8-bit field. All bits MUST be set to 0 on transmit. This
field MUST be ignored on receipt.
8ビットの分野。 0へのセットがオンであったならビットがそうしなければならないすべてが伝わります。 領収書の上でこの分野を無視しなければなりません。
Flags
旗
An 8-bit field. The content and processing of this field are the
same as for the Flags field of the IPv4/UDP SESSION object (see
[RSVP]).
8ビットの分野。 この分野の内容と処理はIPv4/UDP SESSION物のFlags分野のように同じです([RSVP]を見てください)。
Le Faucheur, et al. Standards Track [Page 8] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[8ページ]。
PHB-ID (Per Hop Behavior Identification Code)
PHB-ID(ホップ振舞い識別コードあたりの)
A 16-bit field containing the Per Hop Behavior Identification Code
of the PHB, or of the set of PHBs, from which Diffserv resources
are to be reserved. This field MUST be encoded as specified in
Section 2 of [PHB-ID].
PHB、または予約されているDiffservリソースがことであるPHBsのセットのPer Hop Behavior Identification Codeを含む16ビットの分野。 指定されるとして[PHB-ID]のセクション2でこの分野をコード化しなければなりません。
Reserved
予約されます。
A 16-bit field. All bits MUST be set to 0 on transmit. This
field MUST be ignored on receipt.
16ビットの分野。 0へのセットがオンであったならビットがそうしなければならないすべてが伝わります。 領収書の上でこの分野を無視しなければなりません。
VDstPort (Virtual Destination Port)
VDstPort(仮想の仕向港)
A 16-bit identifier used in the SESSION that remains constant over
the life of the generic aggregate reservation.
16ビットの識別子は一般的な集合予約の人生の間、SESSIONでその残り定数を使用しました。
Extended vDstPort (Extended Virtual Destination Port)
拡張vDstPort(拡張仮想の仕向港)
A 32-bit identifier used in the SESSION that remains constant over
the life of the generic aggregate reservation. A sender (or
Aggregator) that wishes to narrow the scope of a SESSION to the
sender-receiver pair (or Aggregator-Deaggregator pair) SHOULD
place its IPv4 address here as a network unique identifier. A
sender (or Aggregator) that wishes to use a common session with
other senders (or Aggregators) in order to use a shared
reservation across senders (or Aggregators) MUST set this field to
all zeros.
32ビットの識別子は一般的な集合予約の人生の間、SESSIONでその残り定数を使用しました。 IPv4がネットワークのユニークな識別子としてここに記述する送付者受信機組(Aggregator-Deaggregatorは対にする)SHOULD場所にSESSIONの範囲を狭くしたがっている送付者(または、Aggregator)。 送付者(または、Aggregators)の向こう側に共有された予約を使用するのに他の送付者(または、Aggregators)との一般的なセッションを使用したがっている送付者(または、Aggregator)はすべてのゼロにこの分野を設定しなければなりません。
o GENERIC-AGGREGATE-IP6 SESSION object:
Class = 1 (SESSION)
C-Type = 18
o GENERIC-AGGREGATE-IP6 SESSIONは反対します: クラス=1(セッション)C-タイプ=18
Le Faucheur, et al. Standards Track [Page 9] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[9ページ]。
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| |
+ +
| Extended vDstPort |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15 16 25 26 31
0 7 8 15 16 23 24 31 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 DestAddress(16バイト)+| | + + | | +-------------+-------------+-------------+-------------+ | 予約されます。| 旗| PHB-ID| +-------------+-------------+-------------+-------------+ | 予約されます。| vDstPort| +-------------+-------------+-------------+-------------+ | | + + | 拡張vDstPort| + + | (16バイト) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 7 8 15 16 25 26 31
IPv6 DestAddress (IPv6 Destination Address)
IPv6 DestAddress(IPv6送付先アドレス)
IPv6 address of the receiver (or Deaggregator).
受信機(または、Deaggregator)のIPv6アドレス。
Reserved
予約されます。
An 8-bit field. All bits MUST be set to 0 on transmit. This
field MUST be ignored on receipt.
8ビットの分野。 0へのセットがオンであったならビットがそうしなければならないすべてが伝わります。 領収書の上でこの分野を無視しなければなりません。
Flags
旗
An 8-bit field. The content and processing of this field are the
same as for the Flags field of the IPv6/UDP SESSION object (see
[RSVP]).
8ビットの分野。 この分野の内容と処理はIPv6/UDP SESSION物のFlags分野のように同じです([RSVP]を見てください)。
PHB-ID (Per Hop Behavior Identification Code)
PHB-ID(ホップ振舞い識別コードあたりの)
A 16-bit field containing the Per Hop Behavior Identification Code
of the PHB, or of the set of PHBs, from which Diffserv resources
are to be reserved. This field MUST be encoded as specified in
Section 2 of [PHB-ID].
PHB、または予約されているDiffservリソースがことであるPHBsのセットのPer Hop Behavior Identification Codeを含む16ビットの分野。 指定されるとして[PHB-ID]のセクション2でこの分野をコード化しなければなりません。
Le Faucheur, et al. Standards Track [Page 10] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[10ページ]。
Reserved
予約されます。
A 16-bit field. All bits MUST be set to 0 on transmit. This
field MUST be ignored on receipt.
16ビットの分野。 0へのセットがオンであったならビットがそうしなければならないすべてが伝わります。 領収書の上でこの分野を無視しなければなりません。
VDstPort (Virtual Destination Port)
VDstPort(仮想の仕向港)
A 16-bit identifier used in the SESSION that remains constant over
the life of the generic aggregate reservation.
16ビットの識別子は一般的な集合予約の人生の間、SESSIONでその残り定数を使用しました。
Extended vDstPort (Extended Virtual Destination Port)
拡張vDstPort(拡張仮想の仕向港)
A 128-bit identifier used in the SESSION that remains constant
over the life of the generic aggregate reservation. A sender (or
Aggregator) that wishes to narrow the scope of a SESSION to the
sender-receiver pair (or Aggregator-Deaggregator pair) SHOULD
place its IPv6 address here as a network unique identifier. A
sender (or Aggregator) that wishes to use a common session with
other senders (or Aggregators) in order to use a shared
reservation across senders (or Aggregators) MUST set this field to
all zeros.
128ビットの識別子は一般的な集合予約の人生の間、SESSIONでその残り定数を使用しました。 IPv6がネットワークのユニークな識別子としてここに記述する送付者受信機組(Aggregator-Deaggregatorは対にする)SHOULD場所にSESSIONの範囲を狭くしたがっている送付者(または、Aggregator)。 送付者(または、Aggregators)の向こう側に共有された予約を使用するのに他の送付者(または、Aggregators)との一般的なセッションを使用したがっている送付者(または、Aggregator)はすべてのゼロにこの分野を設定しなければなりません。
2.2. SESSION-OF-INTEREST (SOI) Class
2.2. 興味があるセッション(SOI)のクラス
o GENERIC-AGG-IP4-SOI object:
Class = 132
C-Type = 1
o GENERIC-AGG-IP4-SOIは反対します: クラス=132C-タイプ=1
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| |
// Content of a GENERIC-AGGREGATE-IP4 SESSION Object //
| |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31 +-------------+-------------+-------------+-------------+ | | SOI|AGG-IP4に情報を得る、-| | 長さ(バイト)| クラスヌム|SOI C-タイプ| +-------------+-------------+-------------+-------------+ | | 一般的な集合IP4セッション物//の//内容| | +-------------+-------------+-------------+-------------+
Content of a GENERIC-AGGREGATE-IP4 SESSION Object:
一般的な集合IP4セッション物の内容:
This field contains a copy of the SESSION object of the session
that is of interest for the reservation. In the case of a
GENERIC-AGG-IP4-SOI, the session of interest conveyed in this
field is a GENERIC-AGGREGATE-IP4 SESSION.
この分野は予約のために興味があるセッションのSESSION目的のコピーを含んでいます。 GENERIC-AGG-IP4-SOIの場合では、この分野で伝えられた関心のセッションはGENERIC-AGGREGATE-IP4 SESSIONです。
Le Faucheur, et al. Standards Track [Page 11] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[11ページ]。
o GENERIC-AGG-IP6-SOI object:
Class = 132
C-Type = 2
o GENERIC-AGG-IP6-SOIは反対します: クラス=132C-タイプ=2
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP6- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| |
// Content of a GENERIC-AGGREGATE-IP6 SESSION Object //
| |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31 +-------------+-------------+-------------+-------------+ | | SOI|AGG-IP6に情報を得る、-| | 長さ(バイト)| クラスヌム|SOI C-タイプ| +-------------+-------------+-------------+-------------+ | | 一般的な集合IP6セッション物//の//内容| | +-------------+-------------+-------------+-------------+
Content of a GENERIC-AGGREGATE-IP6 SESSION Object:
一般的な集合IP6セッション物の内容:
This field contains a copy of the SESSION object of the session
that is of interest for the reservation. In the case of a
GENERIC-AGG-IP6-SOI, the session of interest conveyed in this
field is a GENERIC-AGGREGATE-IP6 SESSION.
この分野は予約のために興味があるセッションのSESSION目的のコピーを含んでいます。 GENERIC-AGG-IP6-SOIの場合では、この分野で伝えられた関心のセッションはGENERIC-AGGREGATE-IP6 SESSIONです。
For example, if a SESSION-OF-INTEREST object is used inside an E2E Resv message (as per the procedures defined in Section 4) to indicate which generic aggregate IPv4 session the E2E reservation is to be mapped onto, then the GENERIC-AGG-IP4-SOI object will be used, and it will be encoded like this:
例えば、SESSION-OF-INTEREST物が2ユーロのEの予約がどの一般的な集合IPv4セッションに写像されるかことであることを示すのにE2E Resvメッセージ(セクション4で定義された手順に従って)に使用されると、GENERIC-AGG-IP4-SOI物は使用されるでしょう、そして、それはこのようにコード化されるでしょう:
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+--+----------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31
0 7 8 15 16 23 24 31 +-------------+-------------+-------------+-------------+ | | SOI|AGG-IP4に情報を得る、-| | 長さ(バイト)| クラスヌム|SOI C-タイプ| +-------------+-------------+-------------+-------------+ | IPv4 DestAddress(4バイト)| +-------------+-------------+-------------+--+----------+ | 予約されます。| 旗| PHB-ID| +-------------+-------------+-------------+-------------+ | 予約されます。| vDstPort| +-------------+-------------+-------------+-------------+ | 拡張vDstPort| +-------------+-------------+-------------+-------------+ 0 7 8 15 16 23 24 31
Note that a SESSION-OF-INTEREST object is not a SESSION object in itself. It does not replace the SESSION object in RSVP messages. It does not modify the usage of the SESSION object in RSVP messages. It simply allows conveying the Session of another RSVP reservation inside RSVP signaling messages, for some particular purposes. In the context of this document, it is used to convey, inside an E2E RSVP
SESSION-OF-INTEREST物が本来SESSION物でないことに注意してください。 それはRSVPメッセージでSESSION物を置き換えません。 それはRSVPメッセージでSESSION物の使用法を変更しません。 それで、単にRSVPシグナリングメッセージにおける、いくつかの特定の目的の別のRSVPの予約のSessionを運びます。 このドキュメントの文脈では、それは、2E EでRSVPを運ぶのに使用されます。
Le Faucheur, et al. Standards Track [Page 12] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[12ページ]。
message pertaining to an end-to-end reservation, the Session of a generic aggregate reservation associated with the E2E reservation. Details for the corresponding procedures are specified in Section 4.
メッセージが終わりから終わりへの予約に関係して、一般的な集合予約のSessionは2ユーロのEの予約と交際しました。 対応する手順のための詳細はセクション4で指定されます。
3. Processing Rules for Handling Generic Aggregate RSVP Reservations
3. 取り扱いの一般的な集合RSVP予約のための処理規則
This section presents extensions to the processing of RSVP messages required by [RSVP] and presented in [RSVP-PROCESS]. These extensions are required in order to properly process the GENERIC-AGGREGATE-IP4 or GENERIC-AGGREGATE-IP6 SESSION object and the RSVP-AGGREGATE-IP4 or RSVP-AGGREGATE-IP6 FILTER_SPEC object. Values for referenced error codes can be found in [RSVP]. As with the other RSVP documents, values for internally reported (API) errors are not defined.
このセクションは[RSVP]が必要であり、[RSVP-PROCESS]に提示されたRSVPメッセージの処理に拡大を提示します。 これらの拡大が適切にGENERIC-AGGREGATE-IP4かGENERIC-AGGREGATE-IP6 SESSION物を処理するのに必要です、そして、RSVP-AGGREGATE-IP4かRSVP-AGGREGATE-IP6 FILTER_SPECが反対します。 [RSVP]で参照をつけられたエラーコードのための値を見つけることができます。 内部的に報告された(API)誤りのための値が他のRSVPドキュメントで定義されないので。
When referring to the new GENERIC-AGGREGATE-IP4 and GENERIC- AGGREGATE-IP6 SESSION objects, IP version will not be included, and they will be referred to simply as GENERIC-AGGREGATE SESSION, unless a specific distinction between IPv4 and IPv6 is being made.
新しいGENERIC-AGGREGATE-IP4とGENERIC- AGGREGATE-IP6 SESSION物を示す場合、IPバージョンは含められないでしょう、そして、それらは単にGENERIC-AGGREGATE SESSIONと呼ばれるでしょう、IPv4とIPv6の特定の区別をしていない場合。
When referring to the [RSVP-AGG] RSVP-AGGREGATE-IP4 and RSVP- AGGREGATE-IP6 SESSION, FILTER_SPEC, and SENDER_TEMPLATE objects, IP version will not be included, and they will be referred to simply as RSVP-AGGREGATE, unless a specific distinction between IPv4 and IPv6 is being made.
[RSVP-AGG]RSVP-AGGREGATE-IP4、RSVP- AGGREGATE-IP6 SESSION、FILTER_SPEC、およびSENDER_TEMPLATE物を示す場合、IPバージョンは含められないでしょう、そして、それらは単にRSVP-AGGREGATEと呼ばれるでしょう、IPv4とIPv6の特定の区別をしていない場合。
3.1. Extensions to Path and Resv Processing
3.1. 経路への拡大とResv処理
The following PATH message processing changes are defined:
以下のPATHメッセージ処理変化は定義されます:
o When a session is defined using the GENERIC-AGGREGATE SESSION
object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may
be used. When this condition is violated in a PATH message
received by an RSVP end-station, the RSVP end-station SHOULD
report a "Conflicting C-Type" API error to the application.
When this condition is violated in a PATH message received by an
RSVP router, the RSVP router MUST consider this as a message
formatting error.
o セッションがGENERIC-AGGREGATE SESSION物を使用することで定義されるとき、[RSVP-AGG]RSVP-AGGREGATE SENDER_TEMPLATEだけを使用してもよいです。 この状態がRSVP端ステーションによって受け取られたPATHメッセージで違反されるとき、RSVP端ステーションSHOULDは「闘争して、Cでタイプしてください」というAPI誤りをアプリケーションに報告します。 この状態がRSVPルータによって受け取られたPATHメッセージで違反されるとき、RSVPルータは、これがメッセージ形式誤りであるとみなさなければなりません。
o For PATH messages that contain the GENERIC-AGGREGATE SESSION
object, the VDstPort value, the Extended VDstPort value, and the
PHB-ID value should be recorded (in addition to the
destination/Deaggregator address and source/Aggregator address).
These values form part of the recorded state of the session.
The PHB-ID may need to be passed to traffic control; however the
vDstPort and Extended VDstPort are not passed to traffic control
since they do not appear inside the data packets of the
corresponding reservation.
o GENERIC-AGGREGATE SESSION物を含むPATHメッセージに関しては、VDstPort値、Extended VDstPort値、およびPHB-ID値は記録されるべきです(目的地/Deaggregatorアドレスとソース/アグリゲータアドレスに加えて)。 これらの値はセッションの記録された状態の一部を形成します。 PHB-IDは、トラフィックコントロールに通過される必要があるかもしれません。 しかしながら、彼らが対応する予約のデータ・パケットの中に現れないので、vDstPortとExtended VDstPortはトラフィックコントロールに渡されません。
Le Faucheur, et al. Standards Track [Page 13] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[13ページ]。
The following changes to RESV message processing are defined:
RESVメッセージ処理への以下の変化は定義されます:
o When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE
FILTER_SPEC, the session MUST be defined using either the RSVP-
AGGREGATE SESSION object (as per [RSVP-AGG]) or the GENERIC-
AGGREGATE SESSION object (as per this document). If this
condition is not met, an RSVP router or end-station MUST
consider that there is a message formatting error.
o RESVメッセージが[RSVP-AGG]RSVP-AGGREGATE FILTER_SPECを含むとき、RSVP- AGGREGATE SESSION物([RSVP-AGG]に従って)かGENERIC- AGGREGATE SESSION物(このドキュメントに従って)のどちらかを使用して、セッションを定義しなければなりません。 この条件が満たされないなら、RSVPルータか端ステーションが、メッセージ形式誤りがあると考えなければなりません。
o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION type
is GENERIC-AGGREGATE, each node uses data classifiers as per the
following:
o RSVP-AGGREGATE FILTER_SPECが使用されていて、SESSIONタイプがGENERIC-AGGREGATEであるときに、各ノードは以下に従ってデータ分類装置を使用します:
* to perform Diffserv classification the node MUST rely on the
Diffserv data classifier based on the DSCP only. The relevant
DSCP value(s) are those that are associated with the PHB-ID of
the generic aggregate reservation.
* Diffserv分類を実行するために、ノードはDSCPだけに基づくDiffservデータ分類装置に頼らなければなりません。 関連DSCP値は一般的な集合予約のPHB-IDに関連しているものです。
* If the node also needs to perform fine-grain classification
(for example, to perform fine-grain input policing at a trust
boundary) then the node MUST create a data classifier
described by the 3-tuple <DestAddress, SrcAddress, DSCP>.
* また、ノードが、細粒分類(例えば信用境界の細粒入力の取り締まりを実行する)を実行する必要があるなら、ノードは3-tuple<DestAddressによって説明されたデータ分類装置を創造しなければなりません、SrcAddress、DSCP>。
The relevant DSCP value(s) are those that are associated with
the PHB-ID of the generic aggregate reservation.
関連DSCP値は一般的な集合予約のPHB-IDに関連しているものです。
Note that if multiple generic aggregate reservations are
established with different Virtual Destination Ports (and/or
different Extended Virtual Destination Ports) but with the
same <DestAddress, SrcAddress, PHB-ID>, then those cannot be
distinguished by the classifier. If the router is using the
classifier for policing purposes, the router will therefore
police those together and MUST program the policing rate to
the sum of the reserved rate across all the corresponding
reservations.
複数の一般的な集合予約が異なったVirtual Destination Ports(そして/または、異なったExtended Virtual Destination Ports)にもかかわらず、SrcAddress、同じ<DestAddressに伴うPHB-ID>と共に確立されるならクラシファイアがものを区別できないことに注意してください。 ルータが目的を取り締まるのにクラシファイアを使用しているなら、ルータは、したがって、一緒にいるそれらを取り締まって、すべての対応する予約の向こう側に予約されたレートの合計に取り締まりレートをプログラムしなければなりません。
4. Procedures for Aggregation over Generic Aggregate RSVP Reservations
4. 一般的な集合RSVP予約の上の集合のための手順
The procedures for aggregation of E2E reservations over generic aggregate RSVP reservations are the same as the procedures specified in [RSVP-AGG] with the exceptions of the procedure changes listed in this section.
一般的な集合RSVPの予約の上の2ユーロのEの予約の集合のための手順は手順変化の例外がこのセクションで記載されている状態で手順が[RSVP-AGG]で指定したのと同じです。
As specified in [RSVP-AGG], the Deaggregator is responsible for mapping a given E2E reservation on a given aggregate reservation. The Deaggregator requests establishment of a new aggregate reservation by sending to the Aggregator an E2E PathErr message with an error code of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the
[RSVP-AGG]で指定されるように、Deaggregatorは与えられた集合予約の与えられたE2Eの予約を写像するのに責任があります。 Deaggregatorは、NEW-AGGREGATEによって必要のエラーコードでE2E PathErrメッセージをAggregatorに送ることによって、新しい集合予約の設立を要求します。 [RSVP-AGG]で
Le Faucheur, et al. Standards Track [Page 14] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[14ページ]。
Deaggregator conveys the DSCP of the new requested aggregate reservation by including a DCLASS Object in the E2E PathErr and encoding the corresponding DSCP inside. This document modifies and extends this procedure. The Deaggregator MUST include in the E2E PathErr message a SESSION-OF-INTEREST object that contains the GENERIC-AGGREGATE SESSION to be used for establishment of the requested generic aggregate reservation. Since this GENERIC- AGGREGATE SESSION contains the PHB-ID, the DCLASS object need not be included in the PathErr message.
Deaggregatorは、2EのE PathErrにDCLASS Objectを含んで、中で対応するDSCPをコード化することによって、新しい要求された集合予約のDSCPを運びます。 このドキュメントは、この手順を変更して、広げています。 Deaggregatorは2EのE PathErrメッセージに要求された一般的な集合予約の設立に使用されるべきGENERIC-AGGREGATE SESSIONを含むSESSION-OF-INTEREST物を含まなければなりません。 このGENERIC- AGGREGATE SESSIONがPHB-IDを含んでいるので、DCLASS物はPathErrメッセージに含まれる必要はありません。
Note that the Deaggregator can easily ensure that different Aggregators use different sessions for their Aggregate Path towards a given Deaggregator. This is because the Deaggregator can easily select VDstPort and/or Extended VDstPort numbers which are different for each Aggregator (for example, by using the Aggregator address as the Extended VDstPort) and can communicate those inside the GENERIC- AGGREGATE SESSION included in the SESSION-OF-INTEREST object. This provides an easy solution to establish separate reservations from every Aggregator to a given Deaggregator. Conversely, if reservation sharing were needed across multiple Aggregators, the Deaggregator could facilitate this by allocating the same VDstPort and Extended VDstPort to the multiple Aggregators, and thus including the same GENERIC-AGGREGATE SESSION inside the SESSION-OF-INTEREST object in the E2E PathErr messages sent to these Aggregators. The Aggregators could then all establish an Aggregate Path with the same GENERIC- AGGREGATE SESSION.
Deaggregatorが、異なったAggregatorsがそれらのAggregate Pathに与えられたDeaggregatorに向かって異なったセッションを使用するのを容易に確実にすることができることに注意してください。 これはDeaggregatorが容易に各Aggregator(例えばExtended VDstPortとしてAggregatorアドレスを使用することによって)において、異なったVDstPort、そして/または、Extended VDstPort番号を選択できて、SESSION-OF-INTEREST物にGENERIC- AGGREGATE SESSIONの中のそれらを含んでいる場合交信できるからです。 これは、別々のあらゆるAggregatorから与えられたDeaggregatorまでの予約を証明するために容易な解決を提供します。 逆に、共有が予約であるなら複数のAggregatorsの向こう側に必要でした、そして、Deaggregatorは同じVDstPortとExtended VDstPortを複数のAggregatorsに割り当てることによって、これを容易にすることができるでしょう、そして、その結果、2EのE PathErrメッセージのSESSION-OF-INTEREST物の中に同じGENERIC-AGGREGATE SESSIONを含んでいるのはこれらのAggregatorsに発信しました。 そして、Aggregatorsはすべて、同じGENERIC- AGGREGATE SESSIONと共にAggregate Pathを設立するかもしれません。
Therefore, various sharing scenarios can easily be supported. Policies followed by the Deaggregator to determine which Aggregators need shared or separate reservations are beyond the scope of this document.
したがって、容易に様々な共有シナリオを支持できます。 どのAggregatorsが共有されたか別々の予約を必要とするかを決定するためにDeaggregatorによって従われた方針はこのドキュメントの範囲を超えています。
The Deaggregator MAY also include in the E2E PathErr message (with an error code of NEW-AGGREGATE-NEEDED) additional RSVP objects which are to be used for establishment of the newly needed generic aggregate reservation. For example, the Deaggregator MAY include in the E2E PathErr an RSVP Signaled Preemption Priority Policy Element (as specified in [RSVP-PREEMP]).
また、Deaggregatorは、2EのE PathErrメッセージ(NEW-AGGREGATEによって必要のエラーコードがある)の追加RSVP物にどれが新たに必要な一般的な集合予約の設立に使用されることになっていたらよいかを含むかもしれません。 例えば、Deaggregatorは2EのE PathErrにRSVP Signaled Preemption Priority Policy Elementを含むかもしれません([RSVP-PREEMP]で指定されるように)。
The [RSVP-AGG] procedures for processing of an E2E PathErr message received with an error code of NEW-AGGREGATE-NEEDED by the Aggregator are extended correspondingly. On receipt of such a message containing a SESSION-OF-INTEREST object, the Aggregator MUST trigger establishment of a generic aggregate reservation. In particular, it MUST start sending aggregate Path messages with the GENERIC-AGGREGATE SESSION found in the received SESSION-OF-INTEREST object. When an RSVP Signaled Preemption Priority Policy Element is contained in the received E2E PathErr message, the Aggregator MUST include this object
AggregatorによるNEW-AGGREGATEによって必要のエラーコードで受け取られたE2E PathErrメッセージの処理のための[RSVP-AGG]手順は対応する広げられます。 SESSION-OF-INTEREST物を含むそのようなメッセージを受け取り次第、Aggregatorは一般的な集合予約の設立の引き金とならなければなりません。 特に、それは、GENERIC-AGGREGATE SESSIONが容認されたSESSION-OF-INTEREST物で見つけられている状態で集合Pathメッセージを送り始めなければなりません。 RSVP Signaled Preemption Priority Policy Elementが2容認されたEのE PathErrメッセージに含まれているとき、Aggregatorはこの物を含まなければなりません。
Le Faucheur, et al. Standards Track [Page 15] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[15ページ]。
in the Aggregate Path for the corresponding generic aggregate reservation. When other additional objects are contained in the received E2E PathErr message and those can be unambiguously interpreted as related to the new needed generic aggregate reservation (as opposed to related to the E2E reservation), the Aggregator SHOULD include those in the Aggregate Path for the corresponding generic aggregate reservation. The Aggregator MUST use as the Source Address (i.e., as the Aggregator Address in the Sender- Template) for the generic aggregate reservation, the address it uses to identify itself as the PHOP (RSVP previous hop) when forwarding the E2E Path messages corresponding to the E2E PathErr message.
対応するジェネリックのためのAggregate Pathでは、予約に集めてください。 2容認されたEのE PathErrメッセージに他の追加物を含んでいて、新しい必要な一般的な集合条件(2ユーロのEの予約に関連と対照的に)に関連されるように明白にものを解釈できるとき、Aggregator SHOULDは対応する一般的な集合予約のためのAggregate Pathにそれらを含んでいます。 Aggregatorは一般的な集合予約のためのSource Address(すなわち、SenderテンプレートのAggregator Addressとしての)として使用しなければなりません、それが2EのE PathErrメッセージに対応する2EのE Pathメッセージを転送するとき、それ自体がPHOP(RSVP前のホップ)であると認識するのに使用するアドレス。
The Deaggregator follows the same procedures as described in [RSVP-AGG] for establishing, maintaining and clearing the aggregate Resv state. However, a Deaggregator behaving according to the present specification MUST use the generic aggregate reservations and hence use the GENERIC-AGGREGATE SESSION specified earlier in this document.
Deaggregatorは集合Resv状態を設置して、維持して、きれいにするために[RSVP-AGG]で説明されるのと同じ手順に従います。 しかしながら、現在の仕様通りに振る舞うDeaggregatorは一般的な集合予約を使用して、したがって、より早く本書では指定されたGENERIC-AGGREGATE SESSIONを使用しなければなりません。
This document also modifies the procedures of [RSVP-AGG] related to exchange of E2E Resv messages between Deaggregator and Aggregator. The Deaggregator MUST include the new SESSION-OF-INTEREST object in the E2E Resv message, in order to indicate to the Aggregator the generic aggregate session to map a given E2E reservation onto. Again, since the GENERIC-AGGREGATE SESSION (included in the SESSION- OF-INTEREST object) contains the PHB-ID, the DCLASS object need not be included in the E2E Resv message. The Aggregator MUST interpret the SESSION-OF-INTEREST object in the E2E Resv as indicating which generic aggregate reservation session the corresponding E2E reservation is mapped onto. The Aggregator MUST not include the SESSION-OF-INTEREST object when sending an E2E Resv upstream towards the sender.
また、このドキュメントはDeaggregatorとAggregatorの間の2EのE Resvメッセージの交換に関連する[RSVP-AGG]の手順を変更します。 Deaggregatorは2EのE Resvメッセージに新しいSESSION-OF-INTEREST物を含まなければなりません、与えられたE2Eの予約を写像する一般的な集合セッションをAggregatorに示すために。 一方、GENERIC-AGGREGATE SESSION(SESSION- OF-INTEREST物では、含まれている)がPHB-IDを含んでいるので、DCLASS物は2EのE Resvメッセージに含まれる必要はありません。 対応する2ユーロのEの予約がどの一般的な集合予約セッションに写像されるかを示すとAggregatorは2EのE ResvのSESSION-OF-INTEREST物を解釈しなければなりません。 2EのE Resv上流を送付者に向かって送るとき、AggregatorはSESSION-OF-INTEREST物を含んではいけません。
Based on relevant policy, the Deaggregator may decide at some point that an aggregate reservation is no longer needed and should be torn down. In that case, the Deaggregator MUST send an aggregate ResvTear. On receipt of the aggregate ResvTear, the Aggregator SHOULD send an aggregate PathTear (unless the relevant policy instructs the Aggregator to do otherwise or to wait for some time before doing so, for example in order to speed up potential re- establishment of the aggregate reservation in the future).
関連方針に基づいて、Deaggregatorは集合予約をもう必要でなく、取りこわすべきであるという何らかのポイントで決めるかもしれません。 その場合、Deaggregatorは集合ResvTearを送らなければなりません。 集合ResvTearを受け取り次第、Aggregator SHOULDは集合PathTearを送ります(関連方針が、別の方法でするか、またはそうする前にしばらく待つようAggregatorに命令しない場合、例えば、将来、疾走するために集合予約の潜在的再設立を上げてください)。
[RSVP-AGG] describes how the Aggregator and Deaggregator can communicate their respective identities to each other. For example, the Aggregator includes one of its IP addresses in the RSVP HOP object in the E2E Path that is transmitted downstream and received by the Deaggregator once it traversed the aggregation region. Similarly, the Deaggregator identifies itself to the Aggregator by
[RSVP-AGG]はAggregatorとDeaggregatorがどう互いに彼らのそれぞれのアイデンティティを伝えることができるかを説明します。 例えば、Aggregatorはいったん集合領域を横断すると、川下に送信されて、Deaggregatorによって受け取られる2EのE PathのRSVP HOP物のIPアドレスの1つを含んでいます。 同様に、DeaggregatorはAggregatorにそれ自体を特定します。
Le Faucheur, et al. Standards Track [Page 16] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[16ページ]。
including one of its IP addresses in various fields, including the ERROR SPECIFICATION of the E2E PathErr message (containing the NEW- AGGREGATE-NEEDED Error Code) and in the RSVP HOP object of the E2E Resv message. However, [RSVP-AGG] does not discuss which IP addresses are to be selected by the Aggregator and Deaggregator for such purposes. Because these addresses are intended to identify the Aggregator and Deaggregator and not to identify any specific interface on these devices, this document RECOMMENDS that the Aggregator and Deaggregator SHOULD use interface-independent addresses (for example, a loopback address) whenever they communicate their respective identities to each other. This ensures that respective identification of the Aggregator and Deaggregator is not impacted by any interface state change on these devices. In turn, this results in more stable operations and considerably reduced RSVP signaling in the aggregation region. For example, if interface- independent addresses are used by the Aggregator and the Deaggregator, then a failure of an interface on these devices may simply result in the rerouting of a given generic aggregate reservation, but will not result in the generic aggregate reservation having to be torn down and another one established. Moreover, it will not result in a change of mapping of E2E reservations on generic aggregate reservations (assuming the Aggregator and Deaggregator still have reachability after the failure, and the Aggregator and Deaggregator are still on the shortest path to the destination).
2EのPathErrメッセージ(NEW- AGGREGATEによって必要なError Codeを含んでいる)と2EのE ResvメッセージのRSVP HOP物にEのERROR SPECIFICATIONを含む多岐にIPアドレスの1つを含んでいます。 しかしながら、そのような目的のためにAggregatorとDeaggregatorによって選択されるように、[RSVP-AGG]は、IPアドレスがどれであるかと議論しません。 これらのアドレスがAggregatorとDeaggregatorを特定して、どんな特定のインタフェースも特定しないことを意図するので、これらの装置、AggregatorとDeaggregator SHOULDが使用するこのドキュメントRECOMMENDSでは、彼らが互いに自分達のそれぞれのアイデンティティを伝えるときはいつも、インタフェース独立者は(例えば、ループバックアドレス)を記述します。 これは、AggregatorとDeaggregatorのそれぞれの識別がこれらの装置でどんな界面準位変化によっても影響を与えられないのを確実にします。 順番に、これは集合領域で、より安定した操作とかなり減少しているRSVPシグナリングをもたらします。 例えば、インタフェースの独立しているアドレスがAggregatorとDeaggregatorによって使用されると、これらの装置の上のインタフェースの失敗は、単に与えられた一般的な集合予約のコースを変更することをもたらすかもしれませんが、取りこわされなければならない一般的な集合予約と1つが設立した別のものはもたらさないでしょう。 そのうえ、それは一般的な集合予約での2ユーロのEの予約に関するマッピングの変化をもたらさないでしょう(Aggregatorを仮定して、Deaggregatorには、失敗の後に、可到達性がまだあります、そして、目的地にはAggregatorとDeaggregatorがまだ最短パスにあります)。
However, when identifying themselves to real RSVP neighbors (i.e., neighbors that are not on the other side of the aggregation region), the Aggregator and Deaggregator SHOULD continue using interface- dependent addresses as per regular [RSVP] procedures. This applies for example when the Aggregator identifies itself downstream as a PHOP for the generic aggregate reservation or identifies itself upstream as a NHOP (RSVP next hop) for an E2E reservation. This also applies when the Deaggregator identifies itself downstream as a PHOP for the E2E reservation or identifies itself upstream as a NHOP for the generic aggregate reservation. As part of the processing of generic aggregate reservations, interior routers (i.e., routers within the aggregation region) SHOULD continue using interface- dependent addresses as per regular [RSVP] procedures.
しかしながら、本当のRSVP隣人(すなわち、集合領域の反対側の上にいない隣人)に自分たちを特定するとき、AggregatorとDeaggregator SHOULDは、通常の[RSVP]手順に従ってインタフェースの依存するアドレスを使用し続けています。 一般的な集合予約のためのPHOPとして川下でそれ自体を特定するか、またはAggregatorはNHOPであると上流へ名乗るとき(次のRSVPは跳びます)、例えば、これはE2Eの予約のために申し込まれます。 また、2ユーロのEの予約のためにPHOPとして川下でそれ自体を特定するか、または一般的な集合予約のためにDeaggregatorはNHOPであると上流へ名乗るとき、これが適用されます。 一般的な集合予約の処理の一部として、内部のルータ(すなわち、集合領域の中のルータ)SHOULDは、通常の[RSVP]手順に従ってインタフェースの依存するアドレスを使用し続けています。
More generally, within the aggregation region (i.e., between Aggregator and Deaggregator) the operation of RSVP should be modeled with the notion that E2E reservations are mapped to aggregate reservations and are no longer tied to physical interfaces (as was the case with regular RSVP). However, generic aggregate reservations (within the aggregation region) as well as E2E reservations (outside the aggregation region) retain the model of regular RVSP and remain tied to physical interfaces.
より一般に、集合領域(すなわち、AggregatorとDeaggregatorの間の)の中では、RSVPの操作は2ユーロのEの予約が予約に集めるために写像されて、もう物理インターフェースに結ばれないという(通常のRSVPに関してそうであったように)概念でモデル化されるべきです。 しかしながら、2ユーロのE条件(集合領域の外の)と同様に一般的な集合条件(集合領域の中の)は、通常のRVSPのモデルを保有して、物理インターフェースに結ばれたままで残っています。
Le Faucheur, et al. Standards Track [Page 17] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[17ページ]。
As discussed above, generic aggregate reservations may be established edge-to-edge as a result of the establishment of E2E reservations (from outside the aggregation region) that are to be aggregated over the aggregation region. However, generic aggregate reservations may also be used end-to-end by end-systems directly attached to a Diffserv domain, such as Public Switched Telephone Network (PSTN) gateways. In that case, the generic aggregate reservations may be established by the end-systems in response to application-level triggers such as voice call signaling. Alternatively, generic aggregate reservations may also be used edge-to-edge to manage bandwidth in a Diffserv cloud even if RSVP is not used end-to-end. A simple example of such a usage would be the static configuration of a generic aggregate reservation for a certain bandwidth for traffic from an ingress (Aggregator) router to an egress (Deaggregator) router.
上で議論するように、一般的な集合予約は、集合領域の上で集められることになっている2ユーロのE条件(集合領域の外からの)の設立の結果、確立した縁から縁であるかもしれません。 しかしながら、また、一般的な集合予約は、直接Diffservドメインに取り付けられたエンドシステムによる、中古の終わりから終わりであるかもしれません、Public Switched Telephone Network(PSTN)ゲートウェイなどのように。 その場合、一般的な集合予約はエンドシステムによって音声通話シグナリングなどのアプリケーションレベル引き金に対応して確立されるかもしれません。 あるいはまた、また、RSVPが中古の終わりから終わりでなくても、一般的な集合予約は、中古のDiffserv雲で帯域幅を管理する縁から縁であるかもしれません。 そのような用法の簡単な例はある一定の帯域幅のイングレス(アグリゲータ)ルータから出口(Deaggregator)ルータまでの交通の一般的な集合予約の静的な構成でしょう。
In this case, the establishment of the generic aggregate reservations is controlled by configuration on the Aggregator and on the Deaggregator. Configuration on the Aggregator triggers generation of the aggregate Path message and provides sufficient information to the Aggregator to derive the content of the GENERIC-AGGREGATE SESSION object. This would typically include Deaggregator IP address, PHB-ID and possibly VDstPort. Configuration on the Deaggregator would instruct the Deaggregator to respond to a received generic aggregate Path message and would provide sufficient information to the Deaggregator to control the reservation. This may include bandwidth to be reserved by the Deaggregator (for a given <Deaggregator, PHB-ID, VDstPort> tuple).
この場合、一般的な集合予約の設立はAggregatorの上と、そして、Deaggregatorの上の構成によって制御されます。 Aggregatorでの構成は、集合Pathメッセージの世代の引き金となって、GENERIC-AGGREGATE SESSION物の内容を引き出すために十分な情報をAggregatorに供給します。 これはDeaggregator IPアドレス、PHB-ID、およびことによるとVDstPortを通常含んでいるでしょう。 Deaggregatorでの構成は、受信された一般的な集合Pathメッセージに応じるようDeaggregatorに命令して、予約を制御するために十分な情報をDeaggregatorに供給するでしょう。 Deaggregator(与えられた<Deaggregator、PHB-ID VDstPort>tupleのための)によって予約されるように、これは帯域幅を含むかもしれません。
In the absence of E2E microflow reservations, the Aggregator can use a variety of policies to set the DSCP of packets passing into the aggregation region and how they are mapped onto generic aggregate reservations, thus determining whether they gain access to the resources reserved by the aggregate reservation. These policies are a matter of local configuration, as is typical for a device at the edge of a Diffserv cloud.
2ユーロのE microflowの予約がないとき、AggregatorはパケットのDSCPが集合領域とそれらがどう一般的な集合予約に写像されるかに入るように設定するのにさまざまな方針を使用できます、その結果、それらが集合予約で予約されたリソースへのアクセスを得るかどうか決定します。 これらの方針は典型的であるようにDiffserv雲の縁の装置のための地方の構成の問題です。
Le Faucheur, et al. Standards Track [Page 18] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[18ページ]。
5. Example Usage Of Multiple Generic Aggregate Reservations per PHB
from a Given Aggregator to a Given Deaggregator
5. 複数の与えられたアグリゲータから与えられたDeaggregatorまでのPHBあたりの一般的な集合予約の例の用法
Let us consider the environment depicted in Figure 2 below. RSVP aggregation is used to support E2E reservations between Cloud-1, Cloud-2, and Cloud-3.
以下の図2に表現された環境を考えましょう。 RSVP集合は、Cloud-1と、Cloud-2と、Cloud-3の間の2ユーロのEの予約を支持するのに使用されます。
I----------I I----------I
I Cloud-1 I I Cloud-2 I
I----------I I----------I
| |
Agg-Deag-1------------ Agg-Deag-2
/ \
/ Aggregation |
| Region |
| |
| ---/
\ /
\Agg-Deag-3---------/
|
I----------I
I Cloud-3 I
I----------I
I----------I I----------I I雲-1I I雲-2のI I----------I I----------I| | Agg-Deag-1------------ Agg-Deag-2/\/集合| | 領域| | | | ---/\/\Agg-Deag-3---------/ | I----------I I雲-3I I----------I
Figure 2 : Example Usage of Generic Aggregate IP Reservations
図2: 一般的な集合IP予約の例の用法
Let us assume that:
以下のことと仮定しましょう。
o The E2E reservations from Cloud-1 to Cloud-3 have a preemption
of either P1 or P2.
o 2ユーロのCloud-1からCloud-3までのEの予約には、P1かP2のどちらかの先取りがあります。
o The E2E reservations from Cloud-2 to Cloud-3 have a preemption
of either P1 or P2.
o 2ユーロのCloud-2からCloud-3までのEの予約には、P1かP2のどちらかの先取りがあります。
o The E2E reservations are only for Voice (which needs to be
treated in the aggregation region using the EF -Expedited
Forwarding- PHB).
o 2ユーロのEの予約がVoiceのためだけのもの(どれが、集合領域でEFを使用することで扱われる必要があるかがForwarding- PHBを速めた)です。
o Traffic from the E2E reservations is encapsulated in aggregate
IP reservations from Aggregator to Deaggregator using Generic
Routing Encapsulation [GRE] tunneling.
o 2ユーロのEの予約からの交通は、AggregatorからDeaggregatorまでの集合IPの予約でGenericルート設定Encapsulation[GRE]トンネリングを使用することで要約されます。
Then, the following generic aggregate RSVP reservations may be established from Agg-Deag-1 to Agg-Deag-3 for aggregation of the end- to-end RSVP reservations:
次に、以下の一般的な集合RSVPの予約は終わりまでの終わりのRSVPの予約の集合のためにAgg-Deag-1からAgg-Deag-3まで確立されるかもしれません:
(1) A first generic aggregate reservation for aggregation of Voice
reservations from Cloud-1 to Cloud-3 requiring use of P1:
(1) Cloud-1からP1の使用を必要とするCloud-3までのVoiceの予約の集合の最初の一般的な集合予約:
Le Faucheur, et al. Standards Track [Page 19] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[19ページ]。
* GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress = Agg-Deag-3
vDstPort = V1
PHB-ID = EF
Extended VDstPort = Agg-Deag-1
* 一般的な集合IP4セッション: V1 PHB-ID=IPv4 DestAddress=Agg-Deag-3 vDstPort=EFはVDstPort=Agg-Deag-1を広げました。
* STYLE = FF or SE
* スタイルはffかSEと等しいです。
* IPv4/GPI FILTER_SPEC:
IPv4 SrcAddress = Agg-Deag-1
* IPv4/GPIは_仕様をフィルターにかけます: IPv4 SrcAddressはAgg-Deag-1と等しいです。
* POLICY_DATA (PREEMPTION_PRI) = P1
* 方針_データ(先取り_PRI)はP1と等しいです。
(2) A second generic aggregate reservation for aggregation of Voice
reservations from Cloud-1 to Cloud-3 requiring use of P2:
(2) Cloud-1からP2の使用を必要とするCloud-3までのVoiceの予約の集合の2番目の一般的な集合予約:
* GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress = Agg-Deag-3
vDstPort = V2
PHB-ID = EF
Extended VDstPort = Agg-Deag-1
* 一般的な集合IP4セッション: V2 PHB-ID=IPv4 DestAddress=Agg-Deag-3 vDstPort=EFはVDstPort=Agg-Deag-1を広げました。
* STYLE = FF or SE
* スタイルはffかSEと等しいです。
* IPv4/GPI FILTER_SPEC:
IPv4 SrcAddress = Agg-Deag-1
* IPv4/GPIは_仕様をフィルターにかけます: IPv4 SrcAddressはAgg-Deag-1と等しいです。
* POLICY_DATA (PREEMPTION_PRI) = P2
* 方針_データ(先取り_PRI)はP2と等しいです。
where V1 and V2 are arbitrary VDstPort values picked by Agg-
Deag-3.
V1とV2がAgg- Deag-3によって選ばれた任意のVDstPort値であるところ。
The following generic aggregate RSVP reservations may be established from Agg-Deag-2 to Agg-Deag-3 for aggregation of the end-to-end RSVP reservations:
以下の一般的な集合RSVPの予約は終わりから終わりへのRSVP予約の集合のためにAgg-Deag-2からAgg-Deag-3まで確立されるかもしれません:
(3) A third generic aggregate reservation for aggregation of Voice
reservations from Cloud-2 to Cloud-3 requiring use of P1:
(3) Cloud-2からP1の使用を必要とするCloud-3までのVoiceの予約の集合の3番目の一般的な集合予約:
* GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress = Agg-Deag-3
vDstPort = V3
PHB-ID = EF
Extended VDstPort = Agg-Deag-2
* 一般的な集合IP4セッション: V3 PHB-ID=IPv4 DestAddress=Agg-Deag-3 vDstPort=EFはVDstPort=Agg-Deag-2を広げました。
* STYLE = FF or SE
* スタイルはffかSEと等しいです。
Le Faucheur, et al. Standards Track [Page 20] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[20ページ]。
* IPv4/GPI FILTER_SPEC:
IPv4 SrcAddress = Agg-Deag-2
* IPv4/GPIは_仕様をフィルターにかけます: IPv4 SrcAddressはAgg-Deag-2と等しいです。
* POLICY_DATA (PREEMPTION_PRI) = P1
* 方針_データ(先取り_PRI)はP1と等しいです。
(4) A fourth generic aggregate reservation for aggregation of Voice
reservations from Cloud-2 to Cloud-3 requiring use of P2:
(4) Cloud-2からP2の使用を必要とするCloud-3までのVoiceの予約の集合の4番目の一般的な集合予約:
* GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress = Agg-Deag-3
vDstPort = V4
PHB-ID = EF
Extended VDstPort = Agg-Deag-2
* 一般的な集合IP4セッション: V4 PHB-ID=IPv4 DestAddress=Agg-Deag-3 vDstPort=EFはVDstPort=Agg-Deag-2を広げました。
* STYLE = FF or SE
* スタイルはffかSEと等しいです。
* IPv4/GPI FILTER_SPEC:
IPv4 SrcAddress = Agg-Deag-2
* IPv4/GPIは_仕様をフィルターにかけます: IPv4 SrcAddressはAgg-Deag-2と等しいです。
* POLICY_DATA (PREEMPTION_PRI) = P2
* 方針_データ(先取り_PRI)はP2と等しいです。
where V3 and V4 are arbitrary VDstPort values picked by Agg-
Deag-3.
V3とV4がAgg- Deag-3によって選ばれた任意のVDstPort値であるところ。
Note that V3 and V4 could be equal to V1 and V2 (respectively)
since, in this example, the Extended VDstPort of the GENERIC-
AGGREGATE Session contains the address of the Aggregator and,
thus, ensures that different sessions are used from each
Aggregator.
GENERIC- AGGREGATE SessionのExtended VDstPortが、この例でAggregatorのアドレスを含んでいて、その結果、各Aggregatorと異なったセッションが使用されるのを確実にするので、V3とV4がV1とV2(それぞれ)と等しいかもしれないことに注意してください。
6. Security Considerations
6. セキュリティ問題
In the environments addressed by this document, RSVP messages are used to control resource reservations for generic aggregate reservations and may be used to control resource reservations for E2E reservations being aggregated over the generic aggregate reservations. To ensure the integrity of the associated reservation and admission control mechanisms, the RSVP Authentication mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] may be used. These protect RSVP message integrity hop-by-hop and provide node authentication as well as replay protection, thereby protecting against corruption and spoofing of RSVP messages. These hop-by-hop integrity mechanisms can be naturally used to protect the RSVP messages used for generic aggregate reservations and to protect RSVP messages used for E2E reservations outside the aggregation region. These hop-by-hop RSVP integrity mechanisms can also be used to protect RSVP messages used for E2E reservations when those transit through the aggregation region. This is because the Aggregator and
このドキュメントによって記述された環境で、RSVPメッセージは、一般的な集合予約の資源予約を制御するのに使用されて、一般的な集合予約の上で集められる2ユーロのEの予約の資源予約を制御するのに使用されるかもしれません。 関連予約と入場制御機構の保全を確実にするために、[RSVP-CRYPTO1]と[RSVP-CRYPTO2]で定義されたRSVP Authenticationメカニズムは使用されるかもしれません。 これらは、RSVPメッセージの保全ホップごとに保護して、ノード認証を提供して、保護を再演します、その結果、RSVPメッセージの不正とスプーフィングから守ります。 一般的な集合予約に使用されるRSVPメッセージを保護するのに自然にホップごとのこれらの保全メカニズムを使用できました、そして、RSVPメッセージを保護するのは2EのEに集合領域の外で予約を使用しました。 また、集合領域を通るそれらのトランジットであるときに2ユーロのEの予約に使用されるRSVPメッセージを保護するのにホップごとのこれらのRSVP保全メカニズムを使用できます。 そしてこれがそうである、Aggregator。
Le Faucheur, et al. Standards Track [Page 21] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[21ページ]。
Deaggregator behave as RSVP neighbors from the viewpoint of the E2E flows (even if they are not necessarily IP neighbors).
DeaggregatorはRSVP隣人として2EのE流れの観点から振る舞います(彼らが必ずIP隣人であるというわけではなくても)。
[RSVP-CRYPTO1] discusses several approaches for key distribution. First, the RSVP Authentication shared keys can be distributed manually. This is the base option and its support is mandated for any implementation. However, in some environments, this approach may become a burden if keys frequently change over time. Alternatively, a standard key management protocol for secure key distribution can be used. However, existing key distribution protocols may not be appropriate in all environments because of the complexity or operational burden they involve.
[RSVP-CRYPTO1]は主要な分配のためのいくつかのアプローチについて議論します。 まず最初に、手動でRSVP Authenticationの分配しているキーを分配できます。 これは基本オプションです、そして、サポートはどんな実現のためにも強制されます。 しかしながら、いくつかの環境で、キーが時間がたつにつれて頻繁に変化するなら、このアプローチは負担になるかもしれません。 あるいはまた、安全な主要な分配のための標準のかぎ管理プロトコルを使用できます。 しかしながら、既存の主要な分配プロトコルは複雑さかそれらが伴う操作上の負担のためにすべての環境で適切でないかもしれません。
The use of RSVP Authentication in parts of the network where there may be one or more IP hops in between two RSVP neighbors raises an additional challenge. This is because, with some RSVP messages such as a Path message, an RSVP router does not know the RSVP next hop for that message at the time of forwarding it. In fact, part of the role of a Path message is precisely to discover the RSVP next hop (and to dynamically re-discover it when it changes, say because of a routing change). Hence, the RSVP router may not know which security association to use when forwarding such a message. This applies in particular to the case where RSVP Authentication mechanisms are to be used for protection of RSVP E2E messages (e.g., E2E Path) while they transit through an aggregation region and where the dynamic Deaggregator determination procedure defined in [RSVP-AGG] is used. This is because the Aggregator and the Deaggregator behave as RSVP neighbors for the E2E reservation, while there may be one or more IP hops in between them, and the Aggregator does not know ahead of time which router is going to act as the Deaggregator.
2人のRSVP隣人の間に1つ以上のIPホップがあるかもしれないネットワークの部分でのRSVP Authenticationの使用は追加挑戦を上げます。 これはRSVPルータが、PathメッセージなどのいくつかのRSVPメッセージでそれを進める時点で次のRSVPがそのメッセージのために飛び越すのを知らないからです。 事実上、まさに次のRSVPが跳ぶと発見するために、Pathメッセージの役割の一部があります(変化するとき、ダイナミックにそれを再発見するには、ルーティング変化のために、言ってください)。 したがって、RSVPルータは、そのようなメッセージを転送するとき、どのセキュリティ協会を使用したらよいかを知らないかもしれません。 これはRSVP Authenticationメカニズムが2EのRSVP Eメッセージ(例えば、2EのE Path)の保護に集合領域を通って通過している間に使用されることであり、[RSVP-AGG]で定義されたダイナミックなDeaggregator決断手順が使用されているケースに特に適用されます。 これはAggregatorとDeaggregatorが2ユーロのEの予約のためのRSVP隣人として振る舞うからです、それらの間には、1つ以上のIPホップがあるかもしれません、そして、Aggregatorは早めに、どのルータがDeaggregatorとして機能するかを知りませんが。
In that situation, one approach is to share the same RSVP Authentication shared key across all the RSVP routers of a part of the network where there may be RSVP neighbors with IP hops in between. For example, all the Aggregators or Deaggregators of an aggregation region could share the same RSVP Authentication key, while different per-neighbor keys could be used between any RSVP router pair straddling the boundary between two administrative domains that have agreed to use RSVP signaling.
その状況で、1つのアプローチは中間でIPホップによってRSVP隣人がいるかもしれないネットワークの一部のすべてのRSVPルータの向こう側に主要な状態でRSVP Authenticationが共有した同じくらいを共有することです。 例えば、集合領域のすべてのAggregatorsかDeaggregatorsが同じRSVP Authenticationキーを共有するかもしれません、RSVPシグナリングを使用するのに同意した2つの管理ドメインの間の境界にまたがっているどんなRSVPルータ組の間でも1隣人異なったキーを使用できましたが。
When the same RSVP Authentication shared key is to be shared among multiple RSVP neighbors, manual key distribution may be used. For situations where RSVP is being used for multicast flows, it might also be possible, in the future, to adapt a multicast key management method (e.g. from IETF Multicast Security Working Group) for key distribution with such multicast RSVP usage. For situations where RSVP is being used for unicast flows across domain boundaries, it is not currently clear how one might provide automated key management.
主要な状態で共有された同じRSVP Authenticationが複数のRSVP隣人の中で共有されることになっているとき、手動の主要な分配は使用されるかもしれません。 RSVPがそうである状況のために、マルチキャストに使用されるのは流れます、また、主要な分配のためにそのようなマルチキャストRSVP用法でマルチキャストかぎ管理方法を適合させるのも(例えば、IETF Multicast Security作業部会から)将来、可能であるかもしれません。 1つがどのように自動化されたかぎ管理を提供するかは、現在、RSVPがそうである状況のために、ユニキャストに使用されるのがドメイン境界の向こう側に流れるのが明確ではありません。
Le Faucheur, et al. Standards Track [Page 22] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[22ページ]。
Specification of a specific automated key management technique is outside the scope of this document. Operators should consider these key management issues when contemplating deployment of this specification.
このドキュメントの範囲の外に特定の自動化されたかぎ管理のテクニックの仕様があります。 この仕様の展開を熟考するとき、オペレータは、これらが主要な管理問題であると考えるべきです。
The RSVP Authentication mechanisms do not provide confidentiality. If confidentiality is required, IPsec ESP [IPSEC-ESP] may be used, although it imposes the burden of key distribution. It also faces the additional issue discussed for key management above in the case where there can be IP hops in between RSVP hops. In the future, confidentiality solutions may be developed for the case where there can be IP hops in between RSVP hops, perhaps by adapting confidentiality solutions developed by the IETF MSEC Working Group. Such confidentiality solutions for RSVP are outside the scope of this document.
RSVP Authenticationメカニズムは秘密性を提供しません。 IPsec、秘密性が必要です。主要な分配の負担を課しますが、超能力[IPSEC-超能力]は使用されるかもしれません。 また、それはRSVPホップの間にIPホップがあることができる場合における上のかぎ管理のために議論した追加設定に直面しています。 将来、秘密性解決策はRSVPホップの間にIPホップがあることができるケースのために見いだされるかもしれません、恐らくIETF MSEC作業部会によって見いだされた秘密性解決策を適合させることによって。 このドキュメントの範囲の外にRSVPのそのような秘密性解決策があります。
Protection against traffic analysis is also not provided by RSVP Authentication. Since generic aggregate reservations are intended to reserve resources collectively for a whole set of users or hosts, malicious snooping of the corresponding RSVP messages could provide more traffic analysis information than snooping of an E2E reservation. When RSVP neighbors are directly attached, mechanisms such as bulk link encryption might be used when protection against traffic analysis is required. This approach could be used inside the aggregation region for protection of the generic aggregate reservations. It may also be used outside the aggregation region for protection of the E2E reservation. However, it is not applicable to the protection of E2E reservations while the corresponding E2E RSVP messages transit through the aggregation region.
また、トラヒック分析に対する保護はRSVP Authenticationによって提供されません。 一般的な集合予約が1つの全体集合のユーザかホストのためにリソースをまとめて予約することを意図するので、対応するRSVPメッセージの悪意がある詮索はE2Eの予約について詮索するより多くのトラヒック分析情報を提供するかもしれません。 RSVP隣人が直接付けられているとき、トラヒック分析に対する保護が必要であるときに、大量のリンク暗号化などのメカニズムは使用されるかもしれません。 一般的な集合予約の保護に集合領域の中でこのアプローチを使用できました。 また、それは2ユーロのEの予約の保護に集合領域の外で使用されるかもしれません。 しかしながら、それは集合領域を通る対応する2ユーロのE RSVPメッセージトランジットである間、2ユーロのEの予約の保護に適切ではありません。
When generic aggregate reservations are used for aggregation of E2E reservations, the security considerations discussed in [RSVP-AGG] apply and are revisited here.
一般的な集合予約が2ユーロのEの予約の集合に使用されるとき、[RSVP-AGG]で議論したセキュリティ問題は、適用して、ここに再訪します。
First, the loss of an aggregate reservation to an aggressor causes E2E flows to operate unreserved, and the reservation of a great excess of bandwidth may result in a denial of service. These issues are not confined to the extensions defined in the present document: RSVP itself has them. However, they may be exacerbated here by the fact that each aggregate reservation typically facilitates communication for many sessions. Hence, compromising one such aggregate reservation can result in more damage than compromising a typical E2E reservation. Use of the RSVP Authentication mechanisms to protect against such attacks has been discussed above.
まず最初に、2EのE流れが侵略者への集合予約の損失で無遠慮な状態で作動します、そして、帯域幅のすばらしい過剰の予約はサービスの否定をもたらすかもしれません。 これらの問題は現在のドキュメントで定義された拡大に閉じ込められません: RSVP自身には、彼らがいます。 しかしながら、それぞれの集合予約が多くのセッションのためのコミュニケーションを通常容易にするという事実によってそれらはここで悪化させられるかもしれません。 したがって、そのような予約の集合1つで妥協すると、2ユーロの予約で典型的なEで妥協するより多くの損害がもたらされることができます。 上でそのような攻撃に対して保護するRSVP Authenticationメカニズムの使用について議論しました。
An additional security consideration specific to RSVP aggregation involves the modification of the IP protocol number in RSVP Path messages that traverse an aggregation region. Malicious modification
RSVP集合に特定の追加担保の考慮は集合領域を横断するRSVP Pathメッセージにおける、IPプロトコル番号の変更にかかわります。 悪意がある変更
Le Faucheur, et al. Standards Track [Page 23] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[23ページ]。
of the IP protocol number in a Path message would cause the message to be ignored by all subsequent RSVP devices on its path, preventing reservations from being made. It could even be possible to correct the value before it reached the receiver, making it difficult to detect the attack. Note that, in theory, it might also be possible for a node to modify the IP protocol number for non-RSVP messages as well, thus interfering with the operation of other protocols. It is RECOMMENDED that implementations of this specification only support modification of the IP protocol number for RSVP Path, PathTear, and ResvConf messages. That is, a general facility for modification of the IP protocol number SHOULD NOT be made available.
IPでは、Pathメッセージのプロトコル番号は経路のすべてのその後のRSVP装置によって無視されるべきメッセージを引き起こすでしょう、予約をするのを防いで。 受信機に達する前に値を修正するのは可能でさえあるかもしれません、攻撃を検出するのを難しくして。 また、理論上、ノードがまた、非RSVPメッセージのIPプロトコル番号を変更するのも、可能であるかもしれないことに注意してください、その結果、他のプロトコルの操作を妨げます。 この仕様の実現がRSVP Path、PathTear、およびResvConfメッセージのIPプロトコル番号の変更を支持するだけであるのは、RECOMMENDEDです。 すなわち、IPの変更のための一般的な施設は数のSHOULD NOTについて議定書の中で述べます。利用可能に作られています。
Network operators deploying routers with RSVP aggregation capability should be aware of the risks of inappropriate modification of the IP protocol number and should take appropriate steps (physical security, password protection, etc.) to reduce the risk that a router could be configured by an attacker to perform malicious modification of the protocol number.
RSVP集合能力でルータを配備しているネットワーク・オペレータは、IPプロトコル番号の不適当な変更のリスクを意識しているべきであり、攻撃者がプロトコル番号の悪意がある変更を実行するためにルータを構成できたという危険を減少させるために適切な手段を講じるべきです(物理的なセキュリティ、パスワード保護など)。
7. IANA Considerations
7. IANA問題
IANA modified the RSVP parameters registry, 'Class Names, Class Numbers, and Class Types' subregistry, and assigned two new C-Types under the existing SESSION Class (Class number 1), as described below:
IANAはRSVPパラメタ登録、'クラスNames、Class民数記、およびClass Types'副登録を変更して、既存のSESSION Class(クラス番号1)の下の2つの新しいC-タイプを選任しました、以下で説明されるように:
Class Number Class Name Reference ------ ----------------------- ---------
クラス番号クラス名前参照------ ----------------------- ---------
1 SESSION [RFC2205]
1つのセッション[RFC2205]
Class Types or C-Types:
クラスタイプかC-タイプ:
17 GENERIC-AGGREGATE-IP4 [RFC4860]
18 GENERIC-AGGREGATE-IP6 [RFC4860]
17 一般的な集合IP4[RFC4860]18一般的な集合IP6[RFC4860]
Le Faucheur, et al. Standards Track [Page 24] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[24ページ]。
IANA also modified the RSVP parameters registry, 'Class Names, Class Numbers, and Class Types' subregistry, and assigned one new Class Number for the SESSION-OF-INTEREST class and two new C-Types for that class, according to the table below:
IANAはまた、RSVPパラメタ登録、'クラスNames、Class民数記、およびClass Types'副登録を変更して、SESSION-OF-INTERESTのクラスのための1新しいClass Numberとそのクラスのための2つの新しいC-タイプを選任しました、以下のテーブルに従って:
Class Number Class Name Reference ------ ----------------------- ---------
クラス番号クラス名前参照------ ----------------------- ---------
132 SESSION-OF-INTEREST [RFC4860]
興味がある132セッション[RFC4860]
Class Types or C-Types:
クラスタイプかC-タイプ:
1 GENERIC-AGG-IP4-SOI [RFC4860]
2 GENERIC-AGG-IP6-SOI [RFC4860]
1 ジェネリック-AGG-IP4-SOI[RFC4860]2ジェネリック-AGG-IP6-SOI[RFC4860]
These allocations are in accordance with [RSVP-MOD].
[RSVP-MOD]に従って、これらの配分があります。
8. Acknowledgments
8. 承認
This document borrows heavily from [RSVP-AGG]. It also borrows the concepts of Virtual Destination Port and Extended Virtual Destination Port from [RSVP-IPSEC] and [RSVP-TE], respectively.
このドキュメントは[RSVP-AGG]から大いに借ります。 また、それは[RSVP-IPSEC]と[RSVP-TE]からVirtual Destination PortとExtended Virtual Destination Portの概念をそれぞれ借ります。
Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel Voce, Anil Agarwal, Alexander Sayenko, and Anca Zamfir for their input into the content of this document. Thanks to Steve Kent for insightful comments on usage of RSVP reservations in IPsec environments.
また、私たちはこのドキュメントの中身への彼らの入力についてフレッド・ベイカー、ロジャー・レベスク、キャロル・イトゥラルデ、ダニエル・ボース、Anil Agarwal、アレクサンダーSayenko、およびアンカZamfirに感謝します。 IPsec環境におけるRSVPの予約の用法の洞察に満ちたコメントをスティーブ・ケントをありがとうございます。
Ran Atkinson, Fred Baker, Luc Billot, Pascal Delprat, and Eric Vyncke provided guidance and suggestions for the security considerations section.
セキュリティ問題部への指導と提案であるならアトキンソン、フレッド・ベイカー、リュックBillot、Pascalデルプラート、およびエリックVynckeを車で送りました。
Le Faucheur, et al. Standards Track [Page 25] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[25ページ]。
9. Normative References
9. 引用規格
[IPSEC-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[IPSEC-超能力] ケント、S.、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC4303、2005年12月。
[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月。
[PHB-ID] Black, D., Brim, S., Carpenter, B., and F. Le
Faucheur, "Per Hop Behavior Identification Codes", RFC
3140, June 2001.
[PHB-ID] 黒とD.と縁とS.と大工、B.とF.Le Faucheur、「ホップ振舞い識別コード」、RFC3140、2001年6月。
[RSVP] Braden, R., Ed., 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-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-MOD] Kompella, K. and J. Lang, "Procedures for Modifying
the Resource reSerVation Protocol (RSVP)", BCP 96, RFC
3936, October 2004.
[RSVP-モッズ]Kompella、K.とJ.ラング、「資源予約プロトコル(RSVP)を変更するための手順」BCP96、2004年10月のRFC3936。
10. Informative References
10. 有益な参照
[BW-REDUC] Polk, J. and S. Dhesikan, "A Resource Reservation
Protocol (RSVP) Extension for the Reduction of
Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[BW-REDUC] ポーク、J.、およびS.Dhesikan(「予約流動の帯域幅の減少のための資源予約プロトコル(RSVP)拡大」、RFC4495)は2006がそうするかもしれません。
[GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC
2784, March 2000.
2000年3月の[GRE]ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。
[RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy
Element", RFC 3181, October 2001.
[RSVP-PREEMP] ハーツォグ、S.、「合図された先取り優先権方針要素」、RFC3181、2001年10月。
Le Faucheur, et al. Standards Track [Page 26] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[26ページ]。
[RSVP-PROCESS] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RSVP-過程] ブレーデンとR.とL.チャン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1メッセージ処理は統治する」RFC2209、1997年9月。
[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月。
[RSVP-TUNNEL] 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。
[SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested
Virtual Private Network", Work in Progress, February
2007.
[SIGによって入れ子にされた] 「入れ子にされた仮想私設網で合図するQoS」というベイカー、F.、およびP.ボーズは進歩、2007年2月に働いています。
Le Faucheur, et al. Standards Track [Page 27] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[27ページ]。
Appendix A. Example Signaling Flow
付録A.例のシグナリング流動
This appendix does not provide additional specification. It only illustrates the specification detailed in Section 4 through a possible flow of RSVP signaling messages. This flow assumes an environment where E2E reservations are aggregated over generic aggregate RSVP reservations. It illustrates a possible RSVP message flow that could take place in the successful establishment of a unicast E2E reservation that is the first between a given pair of Aggregator/Deaggregator.
この付録は追加仕様を提供しません。 それはRSVPシグナリングメッセージの可能な流れを通してセクション4で詳細な仕様を例証するだけです。 この流れは2ユーロのEの予約が一般的な集合RSVPの予約の上で集められる環境を仮定します。 それはAggregator/Deaggregatorの与えられた組の間の1番目である2EのユニキャストEの予約のうまくいっている設立で起こることができた可能なRSVPメッセージ流動を例証します。
Le Faucheur, et al. Standards Track [Page 28] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[28ページ]。
Aggregator Deaggregator
アグリゲータDeaggregator
E2E Path
----------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed,SOI=GAx)
<----------------------------------
E2E PathErr(New-agg-needed,SOI=GAy)
<----------------------------------
(3)
AggPath(Session=GAx)
------------------------------->
AggPath(Session=GAy)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (Session=GAx)
<-------------------------------
AggResv (Session=GAy)
<-------------------------------
(6)
AggResvConfirm (Session=GAx)
------------------------------>
AggResvConfirm (Session=GAy)
------------------------------>
(7)
E2E Resv
<---------
(8)
E2E Resv (SOI=GAx)
<-----------------------------
(9)
E2E Resv
<-----------
2EのE経路-----------2>(1)EのE経路-------------------------------2>(2)EのE PathErr(必要である、新しいagg、SOI=GAx)<。---------------------------------- 2EのE PathErr(必要である、新しいagg、SOI=同性愛者)<。---------------------------------- (3) AggPath(セッション=GAx)------------------------------->AggPath(セッション=同性愛者の)-------------------------------2>(4)EのE経路----------->(5)AggResv(セッション=GAx)<。------------------------------- AggResvの(セッション=同性愛者)の<。------------------------------- (6) AggResvConfirm(セッション=GAx)------------------------------>AggResvConfirm(セッション=同性愛者の)------------------------------2>(7)EのE Resv<。--------- (8) 2EのE Resv(SOI=GAx)<。----------------------------- (9) 2EのE Resv<。-----------
(1) The Aggregator forwards E2E Path into the aggregation region
after modifying its IP protocol number to RSVP-E2E-IGNORE
(1) 2RSVP EのE-IGNOREにIPプロトコル番号を変更した後に、Aggregatorは2EのE Pathを集合領域に送ります。
(2) Let's assume no Aggregate Path exists. To be able to accurately
update the ADSPEC of the E2E Path, the Deaggregator needs the
ADSPEC of Aggregate Path. In this example, the Deaggregator
elects to instruct the Aggregator to set up Aggregate Path states
for the two supported PHB-IDs. To do that, the Deaggregator
(2) どんなAggregate Pathも存在しないと仮定しましょう。 正確に2EのE PathのADSPECをアップデートできるように、DeaggregatorはAggregate PathのADSPECを必要とします。 この例では、Deaggregatorは、2つの支持されたPHB-IDのためにAggregate Path州を設立するようAggregatorに命令するのを選びます。 それをするためにDeaggregator
Le Faucheur, et al. Standards Track [Page 29] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[29ページ]。
sends two E2E PathErr messages with a New-Agg-Needed PathErr
code. Both PathErr messages also contain a SESSION-OF-INTEREST
(SOI) object. In the first E2E PathErr, the SOI contains a
GENERIC-AGGREGATE SESSION (GAx) whose PHB-ID is set to x. In the
second E2E PathErr, the SOI contains a GENERIC-AGGREGATE SESSION
(GAy) whose PHB-ID is set to y. In both messages the GENERIC-
AGGREGATE SESSION contains an interface-independent Deaggregator
address inside the DestAddress and appropriate values inside the
vDstPort and Extended vDstPort fields.
New-Aggによって必要なPathErrコードがある2 2E EのPathErrメッセージを送ります。 また、両方のPathErrメッセージはSESSION-OF-INTEREST(SOI)物を含んでいます。 最初に、2EのE PathErrでは、SOIはPHB-IDがxに設定されるGENERIC-AGGREGATE SESSION(GAx)を含んでいます。 2Eの第2E PathErrでは、SOIはPHB-IDがyに設定されるGENERIC-AGGREGATE SESSION(GAy)を含んでいます。 両方のメッセージでは、GENERIC- AGGREGATE SESSIONはvDstPortとExtended vDstPort分野の中にDestAddressと適切な値の中にインタフェースから独立しているDeaggregatorアドレスを保管しています。
(3) The Aggregator follows the request from the Deaggregator and
signals an Aggregate Path for both GENERIC-AGGREGATE Sessions
(GAx and GAy).
(3) AggregatorはDeaggregatorからの要求に続きます、そして、信号は両方のためのAggregate Pathに続きます。GENERIC-AGGREGATEセッションズ(GAxとGAy)。
(4) The Deaggregator takes into account the information contained in
the ADSPEC from both Aggregate Paths and updates the E2E Path
ADSPEC accordingly. The Deaggregator also modifies the E2E Path
IP protocol number to RSVP before forwarding it.
(4) DeaggregatorはAggregate Pathsとアップデートの両方からADSPECに含まれた情報を2EのE Path ADSPECそれに従って、考慮に入れます。 また、それを進める前に、Deaggregatorは2EのE Path IPプロトコル番号をRSVPに変更します。
(5) In this example, the Deaggregator elects to immediately proceed
with establishment of generic aggregate reservations for both
PHB-IDs. In effect, the Deaggregator can be seen as anticipating
the actual demand of E2E reservations so that resources are
available on the generic aggregate reservations when the E2E Resv
requests arrive, in order to speed up establishment of E2E
reservations. Assume also that the Deaggregator includes the
optional Resv Confirm Request in these Aggregate Resv.
(5) この例では、Deaggregatorは、すぐに両方のPHB-IDの一般的な集合予約の設立を続けるのを選びます。 事実上、2ユーロのEの予約の実需を予期するのをDeaggregatorを見ることができるので、2ユーロのE Resv要求が到着するとき、リソースは一般的な集合予約で利用可能です、2ユーロのEの予約の設立を早くするために。 また、DeaggregatorがこれらのAggregate Resvに任意のResv Confirm Requestを含んでいると仮定してください。
(6) The Aggregator merely complies with the received ResvConfirm
Request and returns the corresponding Aggregate ResvConfirm.
(6) Aggregatorは単に容認されたResvConfirm Requestに従って、対応するAggregate ResvConfirmを返します。
(7) The Deaggregator has explicit confirmation that both Aggregate
Resvs are established.
(7) 両方のAggregate Resvsは明白な確認ですが、Deaggregatorは確立していた状態でそうしました。
(8) On receipt of the E2E Resv, the Deaggregator applies the mapping
policy defined by the network administrator to map the E2E Resv
onto a generic aggregate reservation. Let's assume that this
policy is such that the E2E reservation is to be mapped onto the
generic aggregate reservation with PHB-ID=x. The Deaggregator
knows that a generic aggregate reservation (GAx) is in place for
the corresponding PHB-ID since (7). The Deaggregator performs
admission control of the E2E Resv onto the generic aggregate
reservation for PHB-ID=x (GAx). Assuming that the generic
aggregate reservation for PHB-ID=x (GAx) had been established
with sufficient bandwidth to support the E2E Resv, the
Deaggregator adjusts its counter, tracking the unused bandwidth
on the generic aggregate reservation. Then it forwards the E2E
Resv to the Aggregator including a SESSION-OF-INTEREST object
(8) 2EのE Resvを受け取り次第、Deaggregatorは2EのE Resvを一般的な集合予約に写像するためにネットワーク管理者によって定義されたマッピング方針を適用します。 2ユーロのEの予約がこの方針がそのようなものであるのでPHB-ID=xとの一般的な集合予約に写像されることであると仮定しましょう。 Deaggregatorは、(7)以来対応するPHB-IDには一般的な集合条件(GAx)が適所にあるのを知っています。 DeaggregatorはPHB-ID=x(GAx)の一般的な集合予約への2EのE Resvの入場コントロールを実行します。 PHB-IDの一般的な集合予約=x(GAx)が2EのE Resvを支持できるくらいの帯域幅で設立されたと仮定して、Deaggregatorはカウンタを調整します、一般的な集合予約における未使用の帯域幅を追跡して。 そして、それはSESSION-OF-INTEREST物を含むAggregatorに2EのE Resv転送します。
Le Faucheur, et al. Standards Track [Page 30] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[30ページ]。
conveying the selected mapping onto GAx (and hence onto
PHB-ID=x).
選択されたマッピングをGAxに伝える、(したがって、PHB-ID=x)
(9) The Aggregator records the mapping of the E2E Resv onto GAx (and
onto PHB-ID=x). The Aggregator removes the SOI object and
forwards the E2E Resv towards the sender.
(9) AggregatorはGAx(そしてPHB-ID=xに)に2EのE Resvに関するマッピングを記録します。 Aggregatorは送付者に向かってSOI物を移して、2EのE Resvを送ります。
Authors' Addresses
作者のアドレス
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot Sophia-Antipolis France EMail: flefauch@cisco.com
フランソアLe FaucheurシスコシステムズInc.Village d'EntrepriseグリーンSide--Batiment T3 400、アベニューdeルーマニーユ06410・Biotソフィア-AntipolisフランスEMail: flefauch@cisco.com
Bruce Davie Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA EMail: bds@cisco.com
ブルースデイビーシスコシステムズInc.1414マサチューセッツAve。 Boxborough、MA01719米国はメールされます: bds@cisco.com
Pratik Bose Lockheed Martin 700 North Frederick Ave. Gaithersburg, MD 20879 USA EMail: pratik.bose@lmco.com
Pratikボーズロッキード・マーチン700の北のフレディリックAve。 MD20879ゲイザースバーグ(米国)はメールされます: pratik.bose@lmco.com
Chris Christou Booz Allen Hamilton 13200 Woodland Park Road Herndon, VA 20171 USA EMail: christou_chris@bah.com
クリス・クリストウ・Boozアレン・ハミルトン13200・ウッドランド・パークRoadヴァージニア20171ハーンドン(米国)はメールされます: christou_chris@bah.com
Michael Davenport Booz Allen Hamilton Suite 390 5220 Pacific Concourse Drive Los Angeles, CA 90045 USA EMail: davenport_michael@bah.com
マイケルダヴェンポートBoozアレンハミルトンSuite390 5220年の太平洋のコンコースDriveカリフォルニア90045ロサンゼルス(米国)はメールされます: davenport_michael@bah.com
Le Faucheur, et al. Standards Track [Page 31] RFC 4860 Generic Aggregate RSVP Reservations May 2007
Le Faucheur、他 規格は集合RSVP予約2007年5月にRFC4860ジェネリックを追跡します[31ページ]。
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機能のための基金は現在、インターネット協会によって提供されます。
Le Faucheur, et al. Standards Track [Page 32]
Le Faucheur、他 標準化過程[32ページ]
一覧
スポンサーリンク
