RFC2208 日本語訳
2208 Resource ReSerVation Protocol (RSVP) -- Version 1 ApplicabilityStatement Some Guidelines on Deployment. A. Mankin, Ed., F. Baker, B.Braden, S. Bradner, M. O`Dell, A. Romanow, A. Weinrib, L. Zhang. September 1997. (Format: TXT=14289 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Mankin, Ed.
Request for Comments: 2208 USC/ISI
Category: Informational F. Baker
Cisco Systems
B. Braden
USC/ISI
S. Bradner
Harvard
M. O`Dell
UUNET Technologies
A. Romanow
Sun Microsystems
A. Weinrib
Intel Corporation
L. Zhang
UCLA
September 1997
ワーキンググループのA.マンキン、エドをネットワークでつないでください。コメントのために以下を要求してください。 2208年のUSC/ISIカテゴリ: 情報のF.のWeinribインテル社L.チャンUCLAベイカーシスコシステムズB.ブレーデンUSC/ISI S.ブラドナーハーバードM.オデルUUNET技術A.Romanowサン・マイクロシステムズA.1997年9月
Resource ReSerVation Protocol (RSVP)
Version 1 Applicability Statement
Some Guidelines on Deployment
資源予約プロトコル(RSVP)バージョン1適用性証明は展開に関するいくつかのガイドラインです。
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes the applicability of RSVP along with the Integrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This document accompanies the first submission of RSVP and integrated services specifications onto the Internet standards track.
このドキュメントは、Integrated Servicesプロトコルに伴うRSVPの適用性と資源予約の他のコンポーネントについて説明して、このとき、資源予約の展開のためにガイドラインを提供します。 このドキュメントはRSVPと統合サービス仕様のインターネット標準化過程への最初の服従に伴います。
Mankin, Ed., et. al. Informational [Page 1] RFC 2208 RSVP Applicability and Deployment September 1997
マンキン、エドetである、アル。 情報[1ページ]のRFC2208RSVPの適用性と展開1997年9月
1. Introduction
1. 序論
RSVP [RFC 2205] is a unicast and multicast signalling protocol, designed to install and maintain reservation state information at each router along the path of a stream of data. The state handled by RSVP is defined by services [RFC 2211] and [RFC 2212] specified by the Integrated Services WG. These services and RSVP are being introduced to the IETF's standards track jointly. From henceforth, the acronym RSVP on its own is used as a shorthand for the signalling protocol combined with the integrated service specifications.
RSVP[RFC2205]はデータのストリームの経路に沿った各ルータで予約州の情報をインストールして、保守するように設計されたユニキャストとマルチキャスト合図プロトコルです。 サービス[RFC2211]でRSVPによって扱われた状態は定義されました、そして、[RFC2212]はIntegrated Services WGで指定しました。 共同でこれらのサービスとRSVPをIETFの標準化過程に導入しています。 今後はから、合図プロトコルのための速記が統合サービス仕様に結合したので、それ自身のところの頭文字語RSVPは使用されています。
RSVP must be used in conjunction with several additional components, described in Table 1.
Table1で説明されたいくつかの追加コンポーネントに関連してRSVPを使用しなければなりません。
Table 1 Additional Components of Resource Reservation
テーブル1 資源予約の追加コンポーネント
1. Message formats in which parameters for desired services can be
expressed. A proposed standard set of these formats is specified
in [RFC 2210].
1. 必要なサービスのためのどのパラメタでメッセージ・フォーマットを言い表すことができるか。 これらの形式の提案された標準セットは[RFC2210]で指定されます。
2. Router and host mechanisms (e.g. packet classification and
scheduling, admission control algorithms) to implement one or
both of the models [RFC 2211] and [RFC 2212], which are also
in the standards track.
2. 道具1かモデル[RFC2211]と[RFC2212]の両方へのルータとホストメカニズム(例えば、パケット分類とスケジューリング、入場コントロールアルゴリズム)。(モデルが標準化過程にもあります)。
3. Message formats in which parameters for desired policies for
admission control and resource use can be expressed. A small
common subset of these formats for standards track is in the
RSVP WG's charter. The Policy objects in the RSVP Protocol
Specification are optional only at this time.
3. 入場のための必要な方針のためのパラメタが制御されるメッセージ・フォーマットとリソース使用を言い表すことができます。 標準化過程へのこれらの形式の小さい一般的な部分集合はRSVP WGの特許中です。 RSVPプロトコルSpecificationのPolicyオブジェクトはこのときだけ、任意です。
4. Diversely located mechanisms implementing desired admission
control policy functions, including authorization and other
security mechanisms.
4. 必要な入場を実装するさまざまに見つけられたメカニズムが承認と他のセキュリティー対策を含む方針機能を制御します。
In the presence of some form of each component in Table 1, RSVP- enabled applications can achieve differentiated qualities of service across IP networks. Networked multimedia applications, many of which require (or will benefit from) a predictable end-user experience, are likely to be initial users of RSVP-signalled services.
Table1のそれぞれのコンポーネントの何らかのフォームがあるとき、RSVPの可能にされたアプリケーションはIPネットワークの向こう側に差別化されたサービスの品質を獲得できます。 ネットワークでつながれたマルチメディア応用(それの多くが予測できるエンドユーザ経験を必要とします(または、利益を得る))はRSVPによって合図されたサービスの初期のユーザである傾向があります。
Because RSVP and the integrated services and other components listed in Table 1 mark a significant change to the service model of IP networks, RSVP has received considerable interest and press in advance of its release as a standards track RFC. At present, many vendors of operating systems and routers are incorporating RSVP and integrated services into their products for near-future availability. The goal of this applicability statement is to describe those uses of
RSVP、統合サービス、および他のコンポーネントがTable1マークにIPネットワークのサービスモデルへの著しい変化を記載したので、RSVPは相当な興味を受けました、そして、規格としてのリリースの前のプレスはRFCを追跡します。 現在のところ、オペレーティングシステムとルータの多くのベンダーが近い将来の有用性のためにRSVPと統合サービスをそれらの製品に組み入れています。 声明がそれらの用途について説明することになっているこの適用性の目標
Mankin, Ed., et. al. Informational [Page 2] RFC 2208 RSVP Applicability and Deployment September 1997
マンキン、エドetである、アル。 情報[2ページ]のRFC2208RSVPの適用性と展開1997年9月
the current RSVP specification that are known to be feasible, and to identify areas of limitation and ongoing chartered work addressing some of these limitations.
可能であり、制限の領域を特定するのが知られている、進行中であることの現在のRSVP仕様はこれらの制限のいくつかを扱う仕事をチャーターしました。
2. Issues Affecting Deployment of RSVP
2. RSVPの展開に影響する問題
Wide scale deployment of RSVP must be approached with care, as there remains a number of outstanding issues that may affect the success of deployment.
慎重にRSVPの広いスケール展開にアプローチしなければなりません、展開の成功に影響するかもしれない多くの未解決の問題が残っているので。
2.1. Scalability
2.1. スケーラビリティ
The resource requirements (processing and storage) for running RSVP on a router increase proportionally with the number of separate sessions (i.e., RSVP reservations). Thus, supporting numerous small reservations on a high-bandwidth link may easily overly tax the routers and is inadvisable. Furthermore, implementing the packet classification and scheduling capabilities currently used to provide differentiated services for reserved flows may be very difficult for some router products or on some of their high-speed interfaces (e.g. OC-3 and above).
ルータ増加のときに別々のセッション(すなわち、RSVPの予約)の数でRSVPを比例して実行するためのリソース要件(処理とストレージ)。 したがって、高帯域リンクの頻繁な小さい予約をサポートするのは、容易にルータにひどく税をかけるかもしれなくて、勧められないです。 その上、パケット分類とスケジューリングが現在予約された流れのための差別化されたサービスを提供するのに使用されている能力であると実装するのはいくつかのルータ製品かそれらの高速インタフェース(例えば、OC-3と上)のいくつか上で非常に難しいかもしれません。
These scaling issues imply that it will generally not be appropriate to deploy RSVP on high-bandwidth backbones at the present time. Looking forward, the operators of such backbones will probably not choose to naively implement RSVP for each separate stream. Rather, techniques are being developed that will, at the "edge" of the backbone, aggregate together the streams that require special treatment. Within the backbone, various less costly approaches would then be used to set aside resources for the aggregate as a whole, as a way of meeting end-to-end requirements of individual flows.
これらのスケーリング問題は、一般に、現時点に高帯域バックボーンでRSVPを配布するのが適切でないことを含意します。 楽しみにしていて、そのようなバックボーンのオペレータは、それぞれの別々のストリームのためにRSVPを純真に実装するのをたぶん選ばないでしょう。 むしろ、テクニックは開発することにされます特別な処理を必要とするストリームがバックボーンの「縁」で一緒に集合である。 次に、バックボーンの中では、様々なそれほど高価でないアプローチは全体で集合のためにリソースをかたわらに置くのに使用されるでしょう、終わりから終わりへの個人のミーティング要件の道が流れるとき。
In the near term, various vendors are likely to use diverse approaches to the aggregation of reservations. There is not currently chartered work in the IETF for development of standards in this space. A BOF, Future Directions of Differential Services, on April 7, 1997, at the Memphis IETF, is to consider the IETF's next steps on this, among other issues. Public documentation of aggregation techniques and experience is encouraged.
近いうちに、様々なベンダーは予約の集合へのさまざまのアプローチを使用しそうです。 貸し切りの仕事が現在でないときに、このスペースでの規格の開発のためのIETFにあります。 BOF(メンフィスIETFの1997年4月7日のDifferential ServicesのFuture Directions)はこれにおけるIETFの次のステップを考えることになっています、他の問題の中で。 集合のテクニックと経験の公共のドキュメンテーションは奨励されます。
2.2. Security Considerations
2.2. セキュリティ問題
The RSVP WG submission for Proposed Standard includes two security- related documents [Baker96, RFC 2207]. [Baker96] addresses denial and hijacking or theft of service attacks. [RFC 2207] addresses RSVP mechanisms for data flows that themselves use IPSEC.
Proposed Standardがセキュリティが関係づけた2を含んでいるので、RSVP WG服従は[Baker96、RFC2207]を記録します。 [Baker96]はサービス攻撃の否定とハイジャックか窃盗を扱います。 [RFC2207]は自分たちでIPSECを使用するデータフローのためにRSVPにメカニズムを扱います。
Mankin, Ed., et. al. Informational [Page 3] RFC 2208 RSVP Applicability and Deployment September 1997
マンキン、エドetである、アル。 情報[3ページ]のRFC2208RSVPの適用性と展開1997年9月
The first document is proposed to protect against spoofed reservation requests arriving at RSVP routers; such requests might be used to obtain service to unauthorized parties or to lock up network resources in a denial of service attack. Modified and spoofed reservation requests are detected by use of hop-by-hop MD5 checksums (in an Integrity Object) between RSVP neighbor routers. As described, RSVP hop-by-hop authentication assumes that key management and distribution for routers is resolved and deployed. Until an effective key infrastructure is in place, manually keyed session integrity might be used. In addition, [Baker96] may be updated with RFC 2085.
最初のドキュメントはRSVPルータに到着する偽造している予約の要請から守るために提案されます。 そのような要求は、権限のないパーティーに対するサービスを得るか、またはサービス不能攻撃でネットワーク資源に鍵をかけるのに使用されるかもしれません。 変更されて偽造している予約の要請はホップごとのRSVP隣人ルータの間のMD5チェックサム(Integrity Objectの)の使用で検出されます。 説明されるように、ホップごとのRSVP認証はルータのためのかぎ管理と分配が決議されていて、配布されると仮定します。 有効な主要なインフラストラクチャが適所にあるまで、手動で合わせられたセッション保全は使用されるかもしれません。 さらに、RFC2085と共に[Baker96]をアップデートするかもしれません。
That RSVP needs an effective key infrastructure among routers is not unique to RSVP: it is widely acknowledged that there are numerous denial of service attacks on the routing infrastructure (quite independent of RSVP) that will only be resolved by deployment of a key infrastructure.
RSVPがルータの中で有効な主要なインフラストラクチャを必要とするのは、RSVPにユニークではありません: 頻繁なサービス不能攻撃が主要なインフラストラクチャの展開で決議されるだけであるルーティングインフラストラクチャ(全くRSVPの如何にかかわらず)にあると広く認められます。
Theft of service risks will require the user to deploy with caution. An elementary precaution is to configure management logging of new and changed filter specifications in RSVP-enabled infrastructure, e.g. the newFlow trap [RFC 2206].
サービスリスクの窃盗は、ユーザが慎重に展開するのを必要とするでしょう。 基本の注意はRSVPによって可能にされたインフラストラクチャにおける、新しくて変えられたフィルタ仕様の管理伐採を構成することです、例えば、newFlow罠[RFC2206]。
The Integrity object defined by [Baker96] may also play a role in policy control, as will be described in 2.3.
また、[Baker96]によって定義されたIntegrityオブジェクトは2.3で説明されるように方針コントロールにおける役割を果たすかもしれません。
The second security-related document provides a mechanism for carrying flows in which the transport and user octets have been encrypted (RFC 1827). Although such encryption is highly beneficial to certain applications, it is not relevant to the functional security of RSVP or reservations.
2番目のセキュリティ関連のドキュメントは輸送とユーザ八重奏を暗号化してある流れ(RFC1827)を運ぶのにメカニズムを提供します。 そのような暗号化はあるアプリケーションに非常に有益ですが、それはRSVPか予約の機能的なセキュリティに関連していません。
The following section on Policy Control includes additional discussion of RSVP authorization security.
Policy Controlの上の以下のセクションはRSVP承認セキュリティの追加議論を含んでいます。
2.3. Policy Control
2.3. 方針コントロール
Policy control addresses the issue of who can, or cannot, make reservations once a reservation protocol can be used to set up unequal services.
方針コントロールはだれが不平等なサービスをセットアップするのにいったん予約プロトコルを使用できるとすることができるか、または予約をすることができないかに関する問題を扱います。
Currently, the RSVP specification defines a mechanism for transporting policy information along with reservations. However, the specification does not define policies themselves. At present, vendors have stated that they will use the RSVP-defined mechanism to implement proprietary policies.
現在、RSVP仕様は、予約に伴う方針情報を輸送するためにメカニズムを定義します。 しかしながら、仕様は方針自体を定義しません。 現在のところ、ベンダーは、独占政策を実施するのにRSVPによって定義されたメカニズムを使用すると述べました。
Mankin, Ed., et. al. Informational [Page 4] RFC 2208 RSVP Applicability and Deployment September 1997
マンキン、エドetである、アル。 情報[4ページ]のRFC2208RSVPの適用性と展開1997年9月
The RSVP WG is chartered to specify a simple standardized policy object and complete simple mechanisms for session use of the Integrity object in the near future. This applicability statement may be updated at the completion of the WG's charter.
RSVP WGは、簡単な標準化された政策目的と完全な簡単なメカニズムを近い将来のIntegrityオブジェクトのセッション使用に指定するためにチャーターされます。 WGの特許の完成のときにこの適用性証明をアップデートするかもしれません。
Before any decision to deploy RSVP, it would be wise to ensure that the policy control available from a vendor is adequate for the intended usage. In addition to the lack of documented policy mechanisms in any of the policy areas (such as access control, authorization, and accounting), the community has little experience with describing, setting and controlling policies that limit Internet service. Therefore it is likely that vendor solutions will be revised often, particularly before the IETF has developed any policy specification.
RSVPを配布するというどんな決定の前にも、ベンダーから利用可能な方針コントロールが確実に意図している用法に適切になるようにするのは賢明でしょう。 方針領域(アクセスコントロールや、承認や、会計などの)のどれかにおける、記録された方針メカニズムの不足に加えて、共同体は少しに方針を説明して、設定して、制御するのにその限界インターネットのサービスを経験させます。 したがって、IETFが特にどんな方針仕様も開発する前にベンダーソリューションはしばしば改訂されそうでしょう。
3. Recommendations
3. 推薦
Given the current form of the RSVP specifications, multimedia applications to be run within an intranet are likely to be the first to benefit from RSVP. SNA/DLSW is another "application" considered likely to benefit. Within the single or small number of related administrative domains of an intranet, scalability, security and access policy will be more manageable than in the global Internet, and risk will be more controllable. Use of RSVP and supporting components for small numbers of flows within a single Internet Service Provider is similar to an intranet use.
RSVP仕様の現在のフォームを考えて、イントラネットの中で実行されるべきマルチメディア応用はRSVPの利益を得る1日である傾向があります。 SNA/DLSWは利益を得そうであると考えられた別の「アプリケーション」です。 中では、イントラネット、スケーラビリティ、セキュリティ、およびアクセス方針の関連する管理ドメインの単一の、または、少ない数が世界的なインターネットよりさらに処理しやすくなるでしょう、そして、リスクが、より制御可能になるでしょう。 RSVPとサポートコンポーネントのただ一つのインターネットサービスプロバイダの中の少ない数の流れの使用はイントラネット使用と同様です。
Current experience with RSVP has been collected only from test runs in limited testbeds and intranet deployment. We recommend that people begin to use RSVP in production intranet or limited ISP environments (as mentioned above), in which benefits can be realized without having to resolve some of the issues described in Section 2. To quote RFC 2026 about the use of Proposed Standard technology:
単に限られたテストベッドとイントラネット展開における試運転からRSVPの現在の経験を集めてあります。 私たちは、人々が生産イントラネットか限られたISP環境(以上のように)でRSVPを使用し始めることを勧めます。(そこでは、セクション2で説明された問題のいくつかを決議する必要はなくて、利益を実現できます)。 Proposed Standard技術の使用に関してRFC2026を引用するために:
Implementors should treat Proposed Standards as immature
specifications. It is desirable to implement them in order to gain
experience and to validate, test, and clarify the specification.
However, since the content of Proposed Standards may be changed if
problems are found or better solutions are identified, deploying
implementations of such standards into a disruption-sensitive
environment is not recommended.
作成者は未熟な仕様としてProposed Standardsを扱うべきです。 仕様を経験を積むためにそれらを実装して、有効にして、テストして、はっきりさせるのは望ましいです。 しかしながら、問題を見つけるならProposed Standardsの内容を変えるかもしれないか、または、より良いソリューションを特定するので、そのような規格の実装を混乱しやすい環境に配布するのは推薦されません。
General issues of scalability, security and policy control as outlined in Section 2 are the subjects of active research and development, as are a number of topics beyond this applicability statement, such as third-party setup of either reservations or differentiated service.
セクション2に概説されているスケーラビリティ、セキュリティ、および方針コントロールの一般答弁は活発な研究開発の対象です、この適用性証明を超えた多くの話題のように、予約か差別化されたサービスのどちらかの第三者セットアップなどのように。
Mankin, Ed., et. al. Informational [Page 5] RFC 2208 RSVP Applicability and Deployment September 1997
マンキン、エドetである、アル。 情報[5ページ]のRFC2208RSVPの適用性と展開1997年9月
4. References
4. 参照
[Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in
Progress.
[Baker96] ベイカー、F.、「RSVPの暗号の認証」が進行中で働いています。
[RFC 2206], Baker, F. and J. Krawczyk, "RSVP Management Information
Base", RFC 2206, September 1997.
[RFC2206]とベイカーとF.とJ.Krawczyk、「RSVP管理情報ベース」、RFC2206、1997年9月。
[RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
[RFC2207] バーガーとL.とT.オマリー、「IPSECデータフローのためのRSVP拡張子」、RFC2207、1997年9月。
[RFC 2211] Wroclawski, J., "Specification of Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
[RFC 2212] Shenker, S., C. Partridge and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] ShenkerとS.とC.ヤマウズラとR.ゲラン、「保証されたサービスの質の仕様」、RFC2212、1997年9月。
[RFC 2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
-- Version 1 Functional Specification", RFC 2205,
September 1997.
R.エド[RFC2205]ブレーデン、他、「資源予約は議定書を作ります--バージョン1の機能的な仕様」、RFC2205、9月1997日
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
5. Authors' Addresses
5. 作者のアドレス
Fred Baker Abel Weinrib Cisco Systems Intel Corporation Phone: 408-526-4257 Phone: 503-264-8972 EMail: fred@cisco.com EMail: aweinrib@ibeam.intel.com
フレッドベイカーアベルWeinribシスコシステムズインテル社Phone: 408-526-4257 以下に電話をしてください。 503-264-8972 メールしてください: fred@cisco.com メール: aweinrib@ibeam.intel.com
Bob Braden
USC/ISI Lixia Zhang
4676 Admiralty Way UCLA Computer Science Department
Marina Del Rey, CA 90292 4531G Boelter Hall
Phone: 310-822-1511 Los Angeles, CA 90095-1596 USA
EMail: braden@isi.edu Phone: 310-825-2695
EMail: lixia@cs.ucla.edu
UCLAコンピュータサイエンス部のマリーナデル・レイ、カリフォルニア90292 4531G Boelterホールが電話をするボブ・ブレーデン・USC/ISI Lixiaチャン4676海軍省道: 310-822-1511 ロサンゼルス、カリフォルニア90095-1596米国はメールされます: braden@isi.edu 電話: 310-825-2695 メールしてください: lixia@cs.ucla.edu
Scott Bradner Allyn Romanow Harvard University Sun Microsystems Phone: 617-495-3864 Phone: 415-786-5179 EMail: sob@harvard.edu EMail: allyn@eng.sun.com
スコットブラドナーアリンRomanowハーバード大学サン・マイクロシステムズPhone: 617-495-3864 以下に電話をしてください。 415-786-5179 メールしてください: sob@harvard.edu メール: allyn@eng.sun.com
Michael O'Dell Allison Mankin UUNET Technologies mankin@east.isi.edu Phone: 703-206-5471 EMail: mo@uu.net
マイケルオデルアリソンマンキンUUNET技術 mankin@east.isi.edu は以下に電話をします。 703-206-5471 メールしてください: mo@uu.net
Mankin, Ed., et. al. Informational [Page 6]
マンキン、エドetである、アル。 情報[6ページ]
一覧
スポンサーリンク
