RFC2749 日本語訳
2749 COPS usage for RSVP. S. Herzog, Ed., J. Boyle, R. Cohen, D.Durham, R. Rajan, A. Sastry. January 2000. (Format: TXT=33477 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S . Herzog, Ed.
Request for Comments: 2749 IPHighway
Category: Standards Track J. Boyle
Level3
R. Cohen
Cisco
D. Durham
Intel
R. Rajan
AT&T
A. Sastry
Cisco
January 2000
ネットワークワーキンググループSエドハーツォグ、コメントを求める要求: 2749年のIPHighwayカテゴリ: 標準化過程J.ボイルLevel3R.コーエンコクチマスD.ダラムインテルR.Rajan AT&T A.Sastryコクチマス2000年1月
COPS usage for RSVP
RSVPのためのCOPS用法
Status of this Memo
この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 Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document describes usage directives for supporting COPS policy services in RSVP environments.
このドキュメントはCOPSがRSVP環境で方針サービスであるとサポートするための用法指示について説明します。
Table of Contents
目次
1 Introduction....................................................2 2 RSVP values for COPS objects....................................2 2.1 Common Header, client-type...................................2 2.2 Context Object (Context).....................................3 2.3 Client Specific Information (ClientSI).......................4 2.4 Decision Object (Decision)...................................4 3 Operation of COPS for RSVP PEPs.................................6 3.1 RSVP flows...................................................6 3.2 Expected Associations for RSVP Requests......................6 3.3 RSVP's Capacity Admission Control: Commit and Delete.........7 3.4 Policy Control Over PathTear and ResvTear....................7
1つの序論…2 2RSVPはCOPSのためにオブジェクトを評価します…2 2.1 一般的なHeader、クライアントタイプ…2 2.2 文脈オブジェクト(文脈)…3 2.3 クライアント特殊情報(ClientSI)…4 2.4 決定オブジェクト(決定)…RSVPの巡査の操作が元気づける4 3…6 3.1 RSVPは流れます…6 3.2 協会はRSVP要求のために予想しました…6 3.3 RSVPの容量入場コントロール: 遂行して、削除します。7 3.4 PathTearとResvTearの方針コントロール…7
Herzog, et al. Standards Track [Page 1] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[1ページ]RFC2749COPS用法
3.5 PEP Caching COPS Decisions...................................7 3.6 Using Multiple Context Flags in a single query...............8 3.7 RSVP Error Reporting.........................................9 4 Security Considerations.........................................9 5 Illustrative Examples, Using COPS for RSVP......................9 5.1 Unicast Flow Example.........................................9 5.2 Shared Multicast Flows......................................11 6 References.....................................................14 7 Author Information and Acknowledgments.........................15 8 Full Copyright Statement.......................................17
3.5 気力キャッシュは決定を獲得します…7 3.6 ただ一つの質問にMultiple Context Flagsを使用します…8 3.7 RSVP誤り報告…9 4のセキュリティ問題…RSVPに巡査を使用する9 5の説明に役立つ実例…9 5.1ユニキャスト流れの例…9 5.2の共有されたマルチキャストは流れます…11 6つの参照箇所…14 7 情報と承認を書いてください…15 8 完全な著作権宣言文…17
1 Introduction
1つの序論
The Common Open Policy Service (COPS) protocol is a query response protocol used to exchange policy information between a network policy server and a set of clients [COPS]. COPS is being developed within the RSVP Admission Policy Working Group (RAP WG) of the IETF, primarily for use as a mechanism for providing policy-based admission control over requests for network resources [RAP].
CommonオープンPolicy Service(COPS)プロトコルはネットワーク方針サーバとクライアント[COPS]のセットの間の為替政策情報に使用される質問応答プロトコルです。 COPSはIETFのRSVP Admission Policy作業部会(RAP WG)の中で開発されています、主としてメカニズムとしてのネットワーク資源[RAP]を求める要求の方針ベースの入場コントロールを提供する使用のために。
This document is based on and assumes prior knowledge of the RAP framework [RAP] and the basic COPS [COPS] protocol. It provides specific usage directives for using COPS in outsourcing policy control decisions by RSVP clients (PEPs) to policy servers (PDPs).
このドキュメントは、RAPフレームワーク[RAP]と基本的なCOPS[COPS]プロトコルに関する先の知識をに基礎づけていて、仮定します。 それはRSVPクライアント(PEPs)によるアウトソーシング方針コントロール決定に方針サーバ(PDPs)にCOPSを使用するための特定の用法指示を提供します。
Given the COPS protocol design, RSVP directives are mainly limited to RSVP applicability, interoperability and usage guidelines, as well as client specific examples.
COPSプロトコルデザインを考えて、RSVP指示はRSVPの適用性、相互運用性、および用法ガイドラインに主に制限されます、クライアントの特定の例と同様に。
2 RSVP values for COPS objects
2 COPSオブジェクトのためのRSVP値
The usage of several COPS objects is affected when used with the RSVP client type. This section describes these objects and their usage.
RSVPクライアントタイプで使用されると、数個のCOPSオブジェクトの使用法は影響を受けます。 このセクションはこれらのオブジェクトとそれらの用法を説明します。
2.1 Common Header, client-type
2.1 一般的なHeader、クライアントタイプ
RSVP is COPS client-type 1
RSVPは1COPSクライアントタイプ歳です。
Herzog, et al. Standards Track [Page 2] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[2ページ]RFC2749COPS用法
2.2 Context Object (Context)
2.2 文脈オブジェクト(文脈)
The semantics of the Context object for RSVP is as follows:
RSVPのためのContextオブジェクトの意味論は以下の通りです:
R-Type (Request Type Flag)
R-タイプ(要求タイプ旗)
Incoming-Message request
入って来るメッセージ要求
This context is used when the PEP receives an incoming RSVP
message. The PDP may decide to accept or reject the incoming
message and may also apply other decision objects to it. If the
incoming message is rejected, RSVP should treat it as if it
never arrived.
PEPが入って来るRSVPメッセージを受け取るとき、この背景は使用されています。 PDPは入力メッセージを受け入れるか、または拒絶すると決めて、また、他の決定オブジェクトをそれに申し込むかもしれません。 入力メッセージが拒絶されるなら、RSVPはまるで決して到着しないかのようにそれを扱うはずです。
Resource-Allocation request
リソース配分要求
This context is used when the PEP is about to commit local
resources to an RSVP flow (admission control). This context
applies to Resv messages only. The decision whether to commit
local resources is made for the merge of all reservations
associated with an RSVP flow (which have arrived on a
particular interface, potentially from several RSVP Next-Hops).
PEPがRSVP流動(入場コントロール)にローカル資源を遂行しようとしているとき、この背景は使用されています。 この文脈はResvメッセージだけに適用されます。 RSVP流動に関連しているすべての条件(特定のインタフェースでいくつかのRSVP Next-ホップから潜在的に到着した)のマージのために、ローカル資源を遂行するかどうかという決定をします。
Outgoing-Message request (forwarding an outgoing RSVP message)
送信するメッセージ要求(送信するRSVPメッセージを転送します)
This context is used when the PEP is about to forward an
outgoing RSVP message. The PDP may decide to allow or deny the
outgoing message, as well as provide an outgoing policy data
object.
PEPが送信するRSVPメッセージを転送しようとしているとき、この背景は使用されています。 PDPは送信されるメッセージを許容するか、または否定して、出発している方針データ・オブジェクトを提供すると決めるかもしれません。
M-Type (Message Type)
Mタイプ(メッセージタイプ)
The M-Type field in the Context Object identifies the applicable RSVP message type. M-Type values are identical to the values used in the "msg type" field in the RSVP header [RSVP].
Context ObjectのMタイプ分野は適切なRSVPメッセージタイプを特定します。 Mタイプ値はRSVPヘッダー[RSVP]の「msgタイプ」分野で使用される値と同じです。
The following RSVP message types are supported in COPS:
以下のRSVPメッセージタイプはCOPSでサポートされます:
Path Resv PathErr ResvErr
経路Resv PathErr ResvErr
Other message types such as PathTear, ResvTear, and Resv Confirm are not supported. The list of supported message types can only be extended in later versions of RSVP and/or later version of this document.
PathTearや、ResvTearや、Resv Confirmなどの他のメッセージタイプはサポートされません。 RSVPの、より遅いバージョン、そして/または、このドキュメントの、より遅いバージョンでサポートしているメッセージタイプのリストを広げることができるだけです。
Herzog, et al. Standards Track [Page 3] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[3ページ]RFC2749COPS用法
2.3 Client Specific Information (ClientSI)
2.3 クライアント特殊情報(ClientSI)
All objects that were received in an RSVP message are encapsulated inside the Client Specific Information Object (Signaled ClientSI) sent from the PEP to the remote PDP (see Section 3.1. on multiple flows packed in a single RSVP message).
RSVPメッセージに受け取られたすべてのオブジェクトがPEPからリモートPDPに送られたClient Specific情報Object(ClientSIに合図する)の中でカプセルに入れられます(複数の流れのセクション3.1がただ一つのRSVPメッセージを大勢引きつけたのを確実にしてください)。
The PEP and PDP share RSVP state, and the PDP is assumed to implement the same RSVP functional specification as the PEP. In the case where a PDP detects the absence of objects required by [RSVP] it should return an <Error> in the Decision message indicating "Mandatory client-specific info missing". If, on the other hand, the PDP detects the absence of optional RSVP objects that are needed to approve the Request against current policies, the PDP should return a negative <Decision>.
PEPとPDPはRSVP状態を共有します、そして、PDPが、PEPとして同じRSVPが機能的な仕様であると実装すると思われます。 PDPが[RSVP]によって必要とされたオブジェクトの不在を検出する場合では、それは「義務的なクライアント特有のインフォメーションの取り逃がすこと」を示すDecisionメッセージで<Error>を返すべきです。 他方では、PDPが通貨政策に対してRequestを承認するのが必要である任意のRSVPオブジェクトの不在を検出するなら、PDPは否定的<Decision>を返すはずです。
Unlike the Incoming and Outgoing contexts, "Resource Allocation" is not always directly associated with a specific RSVP message. In a multicast session, it may represent the merging of multiple incoming reservations. Therefore, the ClientSI object should specifically contain the SESSION and STYLE objects along with the merged FLOWSPEC, FILTERSPEC list, and SCOPE object (whenever relevant).
IncomingとOutgoing文脈と異なって、「資源配分」はいつも直接特定のRSVPメッセージに関連づけられるというわけではありません。 マルチキャストセッションのときに、それは複数の入って来る予約の合併を表すかもしれません。 したがって、ClientSIオブジェクトは明確に合併しているFLOWSPEC、FILTERSPECリスト、およびSCOPEオブジェクトに伴うSESSIONと様式オブジェクトを含むはずです(関連しているときはいつも)。
2.4 Decision Object (Decision)
2.4 決定オブジェクト(決定)
COPS provides the PDP with flexible controls over the PEP using RSVP's response to messages. While accepting an RSVP message, PDPs may provide preemption priority, trigger warnings, replace RSVP objects, and much more, using Decision Commands, Flags, and Objects.
COPSは、メッセージへのRSVPの応答を使用することでPEPのフレキシブルなコントロールをPDPに提供します。 PDPsは、RSVPオブジェクト、およびはるかに多くを取り替えてください、Decision Commands、Flags、およびObjectsを使用してRSVPメッセージを受け入れている間先取り優先権、引き金の警告を前提とするかもしれません。
DECISION COMMANDS
決定命令
Only two commands apply to RSVP
2つのコマンドだけがRSVPに適用されます。
Install
インストールしてください。
Positive Response:
Accept/Allow/Admit an RSVP message or local resource allocation.
積極的な応答: RSVPメッセージかローカル資源配分を受け入れるか、許容する、または認めてください。
Remove
取り外してください。
Negative Response:
Deny/Reject/Remove an RSVP message or local resource allocation.
否定応答: RSVPメッセージかローカル資源配分を否定するか、拒絶する、または取り除いてください。
Herzog, et al. Standards Track [Page 4] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[4ページ]RFC2749COPS用法
DECISION FLAGS
決定旗
The only decision flag that applies to RSVP:
RSVPに適用される唯一の決定旗:
Trigger Error
引き金の誤り
If this flag is set, RSVP should schedule a PathErr, in response
to a Path message, or a ResvErr (in response of a Resv message).
この旗が設定されるなら、RSVPはPathErrの計画をするはずです、Pathメッセージ、またはResvErr(Resvメッセージの応答における)に対応して。
STATELESS POLICY DATA
状態がない方針データ
This object may include one or more policy elements (as specified for the RSVP Policy Data object [RSVP-EXT]) which are assumed to be well understood by the client's LPDP. The PEP should consider these as an addition to the decision already received from the PDP (it can only add, but cannot override it).
このオブジェクトはクライアントのLPDPによく解釈されると思われる1つ以上の方針要素(RSVP Policy Dataオブジェクト[RSVP-EXT]に指定されるように)を含むかもしれません。 PEPは、これらが追加であるとPDPから既に受けられた決定にみなすはずです(それは、加えることができるだけですが、それをくつがえすことができません)。
For example, given Policy Elements that specify a flow's preemption priority, these elements may be included in an incoming Resv message or may be provided by the PDP responding to a query.
例えば、それをPolicy Elementsに考えて、流れの先取り優先権を指定してください、これらの要素が入って来るResvメッセージに含まれるかもしれませんか、または質問に応じるPDPによって提供されるかもしれません。
Stateless objects must be well understood, but not necessarily supported by all PEPs. For example, assuming a standard policy element for preemption priority, it is perfectly legitimate for some PEPs not to support such preemption and to ignore it. The PDP must be careful when using such objects. In particular, it must be prepared for these objects to be ignored by PEPs.
状態がないオブジェクトは、よく理解されていますが、すべてのPEPsが必ずサポートしなければならないというわけではありません。 例えば、先取り優先権のために標準約款要素を仮定して、いくつかのPEPsがそのような先取りをサポートしないで、それを無視するのは完全に正統です。 そのようなオブジェクトを使用するとき、PDPは慎重であるに違いありません。 これらのオブジェクトがPEPsによって無視されるのは、特に、準備していなければなりません。
Stateless Policy Data may be returned in decisions and apply individually to each of the contexts flagged in REQ messages. When applied to Incoming, it is assumed to have been received as a POLICY_DATA object in the incoming message. When applied to Resource Allocation it is assumed to have been received on all merged incoming messages. Last, when applied to outgoing messages it is assumed to have been received in all messages contributing to the outgoing message.
状態がないPolicy DataはREQメッセージで旗を揚げられたそれぞれの文脈に、決定で返されて、個別に適用するかもしれません。 Incomingに適用されると、POLICY_DATAオブジェクトとして入力メッセージに受け取られたと思われます。 Resource Allocationに適用されると、すべての合併している入力メッセージに受け取られたと思われます。 それが送信されるメッセージに貢献しながらすべてのメッセージに受け取られたと思われる送信されるメッセージに適用されたいつという最終。
REPLACEMENT DATA
交換データ
The Replacement object may contain multiple RSVP objects to be replaced (from the original RSVP request). Typical replacement is performed on the "Forward Outgoing" request (for instance, replacing outgoing Policy Data), but is not limited, and can also be performed on other contexts (such as "Resources-Allocation Request"). In other cases, replacement of the RSVP FlowSpec object may be useful for controlling resources across a trusted zone (with policy ignorant
Replacementオブジェクトは複数の取り替えられるべき(オリジナルのRSVP要求から)RSVPオブジェクトを含むかもしれません。 典型的な交換は「フォワード送信する」要求(例えば、出発しているPolicy Dataを取り替える)に実行されます、制限していなくて、また、他の文脈(「リソース配分要求」などの)に実行できるのを除いて。 他の場合では、RSVP FlowSpecオブジェクトの交換が信じられたゾーンの向こう側にリソースを制御することの役に立つかもしれない、(無知な方針
Herzog, et al. Standards Track [Page 5] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[5ページ]RFC2749COPS用法
nodes (PINs). Currently, RSVP clients are only required to allow replacement of three objects: POLICY_DATA, ERROR_SPEC, and FLOWSPEC, but could optionally support replacement of other objects.
ノード(暗証番号)。 現在、RSVPクライアントは3個のオブジェクトの交換を許すだけでよいです: POLICY_DATA、ERROR_SPEC、およびFLOWSPECだけ、任意に、他のオブジェクトの交換をサポートすることができました。
RSVP object replacement is performed in the following manner:
RSVPオブジェクト交換は以下の方法で実行されます:
If no Replacement Data decision appears in a decision message, all signaled objects are processed as if the PDP was not there. When an object of a certain C-Num appears, it replaces ALL the instances of C-Num objects in the RSVP message. If it appears empty (with a length of 4) it simply removes all instances of C-Num objects without adding anything.
Replacement Data決定が全く決定メッセージに現れないなら、まるでPDPがそこにないかのようにすべての合図されたオブジェクトが処理されます。 あるC-ヌムのオブジェクトが現れるとき、それはRSVPメッセージでC-ヌムオブジェクトのすべてのインスタンスを取り替えます。 空に(4の長さがある)見えるなら、何も加えないで、それは単にC-ヌムオブジェクトのすべてのインスタンスを取り除きます。
3 Operation of COPS for RSVP PEPs
RSVPの巡査の操作が元気づける3
3.1 RSVP flows
3.1 RSVPは流れます。
Policy Control is performed per RSVP flow, which is defined by the atomic unit of an RSVP reservation (TC reservation). Reservation styles may also impact the definition of flows; a set of senders which are considered as a single flow for WF reservation are considered as a set of individual flows when FF style is used.
方針ControlはRSVP流動単位で実行されます。流動はRSVP条件(TCの予約)の原子力ユニットによって定義されます。 また、予約スタイルは流れの定義に影響を与えるかもしれません。 FFスタイルが使用されているとき、WFの予約のためのただ一つの流れであるとみなされる1セットの送付者は1セットの個々の流れであるとみなされます。
Multiple FF flows may be packed into a single Resv message. A packed message must be unpacked where a separate request is issued for each of the packed flows as if they were individual RSVP messages. Each COPS Request should include the associated POLICY_DATA objects, which are, by default, all POLICY_DATA objects in the packed message. Sophisticated PEPs, capable of looking inside policy objects, may examine the POLICY_DATA or SCOPE object to narrow down the list of associated flows (as an optimization).
複数のFF流れがただ一つのResvメッセージに詰め込まれるかもしれません。 まるでそれらが個々のRSVPメッセージであるかのように別々の要求がそれぞれの詰まっている流れのために出されるところで詰まっているメッセージをアンパックしなければなりません。 各COPS Requestは関連POLICY_DATAオブジェクトを含んでいるはずです。(デフォルトで、オブジェクトはすべて、詰まっているメッセージのPOLICY_DATAオブジェクトです)。 政策目的の中で見ることができる高性能のPEPsは、関連流れ(最適化としての)のリストを限定するためにPOLICY_DATAかSCOPEオブジェクトを調べるかもしれません。
Please note that the rules governing Packed RSVP message apply equally to the Incoming as well as the Outgoing REQ context.
Packed RSVPメッセージを支配する規則は等しくOutgoing REQ文脈と同様にIncomingに適用されます。
3.2 Expected Associations for RSVP Requests
3.2はRSVP要求のために協会を予想しました。
When making a policy decision, the PDP may consider both Resv as well as its matching Path state (associated state). State association is straightforward in the common unicast case since the RSVP flow includes one Path state and one Resv state. In multicast cases this correspondence may be more complicated, as the match may be many-to- many. The COPS protocol assumes that the PDP is RSVP knowledgeable and capable of determining these associations based on the contents of the Client REQ message and especially the ClientSI object.
政策決定をするとき、PDPは、Resvとその合っているPath状態の両方が(関連状態)であると考えるかもしれません。 RSVP流動が1つのPath州と1つのResv州を含んでいるので、州の協会は一般的なユニキャスト場合で簡単です。 マッチが多いかもしれないようにマルチキャスト場合では、この通信が、より複雑であるかもしれない、-、-、多くです。 COPSプロトコルは、PDPがRSVPであると仮定します博識でClient REQメッセージと特にClientSIオブジェクトのコンテンツに基づくこれらの協会を決定できる。
Herzog, et al. Standards Track [Page 6] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[6ページ]RFC2749COPS用法
For example, the PDP should be able to recognize activation and deactivation of RSVP blockade state following discrete events like the arrival of a ResvErr message (activate the blockade state) as well as the change in the outgoing Resv message.
例えば、送信するResvメッセージにおける変化と同様にResvErrメッセージの到着のように離散事象に続いて(封鎖州を動かします)、PDPはRSVP封鎖州の起動と非活性化を認識するはずであることができます。
3.3 RSVP's Capacity Admission Control: Commit and Delete
3.3 RSVPの容量入場コントロール: 遂行して、削除します。
In RSVP, the admission of a new reservation requires both an administrative approval (policy control) and capacity admission control. After being approved by both, and after the reservation was successfully installed, the PEP notifies the remote PDP by sending a report message specifying the Commit type. The Commit type report message signals when billing should effectively begin and performing heavier delayed operations (e.g., debiting a credit card) is permissible by the PDP.
RSVPでは、新しい予約の入場は管理承認(方針コントロール)と容量入場コントロールの両方を必要とします。 両方で承認して、予約が首尾よくインストールされた後に、レポートメッセージにCommitタイプを指定させることによって、PEPはリモートPDPに通知します。 支払いが事実上始まると、Commitはレポートメッセージ信号をタイプします、そして、より重い遅れた操作(例えば、クレジットカードを借り方に記入する)を実行するのはPDPを許されさせています。
If, instead, a PDP approved reservation fails admission due to lack of resources, the PEP must issue a no-commit report and fold back and send an updated request to its previous state (previously installed reservation). If no state was previously installed, the PEP should issue a delete (DRQ).
PDPが代わりに承認したなら予約が財源不足による入場に失敗して、PEPは公約していないレポートと折り目を発行し返して、先に(以前にインストールされた予約)アップデートされた要求を送らなければなりません。 PEPはインストールされて、以前にどんな状態もそうでないなら、そうするでしょうに。aが削除する問題(DRQ)。
3.4 Policy Control Over PathTear and ResvTear
3.4 PathTearとResvTearの方針コントロール
PathTear and ResvTear messages are not controlled by this policy architecture. This relies on two assumptions: First, that MD-5 authentication verifies that the Tear is received from the same node that sent the initial reservation, and second, that it is functionally equivalent to that node holding off refreshes for this reservation. When a ResvTear or PathTear is received at the PEP, all affected states installed on the PDP should either be deleted or updated by the PEP.
PathTearとResvTearメッセージはこの方針アーキテクチャによって制御されません。 これは2つの仮定に依存します: まず最初に、そのMD-5認証は初期の予約、および2番目を送ったのと同じノードからTearを受け取って、それが距離を保つのがこの予約のためにリフレッシュするそのノードに機能上同等であることを確かめます。 PEPにResvTearかPathTearを受け取るとき、PEPはPDPの上にインストールされたすべての影響を受ける州を、削除するはずであるか、またはアップデートするはずです。
3.5 PEP Caching COPS Decisions
3.5 気力キャッシュは決定を獲得します。
Because COPS is a stateful protocol, refreshes for RSVP Path and Resv messages need not be constantly sent to the remote PDP. Once a decision has been returned for a request, the PEP can cache that decision and apply it to future refreshes. When the PEP detects a change in the corresponding Resv or Path message, it should update the PDP with the new request-state. PEPs may continue to use the cached state until receiving the PDP response. This case is very different from initial admission of a flow; given that valid credentials and authentication have already been established, the relatively long RSVP refresh period, and the short PEP-PDP response time, the tradeoff between expedient updates and attack prevention leans toward expediency. However, this is really a PEP choice, and is irrelevant to PDPs.
COPSがstatefulプロトコルであり、RSVP PathとResvのためにリフレッシュするので、絶えずリモートPDPにメッセージを送る必要はありません。 決定がいったんあると、要求、PEPがその決定をキャッシュして、適用できるので返して、それは未来までリフレッシュします。 PEPが対応するResvかPathメッセージにおける変化を検出するとき、それは新しい要求状態があるPDPをアップデートするべきです。 PEPsは、PDP応答を受けるまでキャッシュされた状態を使用し続けるかもしれません。 本件は流れの初期の入場と非常に異なっています。 正当な証明書と認証が既に確立されたなら、比較的長いRSVPは好都合なアップデートと攻撃防止赤身の間で期間、および短いPEP-PDP応答時間、見返りを便宜に向かってリフレッシュします。 しかしながら、これは、本当にPEP選択であり、PDPsと無関係です。
Herzog, et al. Standards Track [Page 7] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[7ページ]RFC2749COPS用法
If the connection is lost between the PEP and the PDP, the cached RSVP state may be retained for the RSVP timeout period to be used for previously admitted flows (but cannot be applied to new or updated state). If the connection can not be reestablished with the PDP or a backup PDP after the timeout period, the PEP is expected to purge all its cached decisions. Without applicable cached decision, the PEP must either reject the flow or resort to its LPDP (if available) for decisions.
接続がPEPとPDPの間で迷子になるなら、キャッシュされたRSVP状態は、以前に認められた流れ(しかし、新しいかアップデートされた状態に適用できない)に使用されるためにRSVPタイムアウト時間の間、保有されるかもしれません。 接続がタイムアウト時間の後にPDPかバックアップPDPで回復できないなら、PEPがすべてのキャッシュされた決定を掃除すると予想されます。 適切なキャッシュされた決定がなければ、PEPは決定のために流れを拒絶しなければならないか、またはLPDPに頼らなければなりません(利用可能であるなら)。
Once a connection is reestablished to a new (or the original) PDP the PDP may issue a SSQ request. In this case, the PEP must reissue requests that correspond to the current RSVP state (as if all the state has been updated recently). It should also include in its LPDPDecision the current (cached) decision regarding each such state.
接続がいったん新しい(または、オリジナル)PDPに回復すると、PDPはSSQ要求を出すかもしれません。 この場合、PEPは現在のRSVP状態に対応する要求を再発行しなければなりません(まるで最近すべての状態をアップデートしたかのように)。 また、それはLPDPDecisionにそのような各状態に関する現在(キャッシュされる)の決定を含むべきです。
3.6 Using Multiple Context Flags in a single query
3.6 ただ一つの質問にMultiple Context Flagsを使用すること。
RSVP is a store-and-forward control protocol where messages are processed in three distinctive steps (input, resource allocation, and output). Each step requires a separate policy decision as indicated by context flags (see Section 2.2). In many cases, setting multiple context flags for bundling two or three operations together in one request may significantly optimize protocol operations.
RSVPはメッセージが特有の3ステップ(入力、資源配分、および出力)で処理される店とフォワード制御プロトコルです。 各ステップは文脈旗で示されるように別々の政策決定を必要とします(セクション2.2を見てください)。 多くの場合、1で2か3つの操作を一緒に添付するための旗が要求する複数の文脈を設定すると、プロトコル操作はかなり最適化されるかもしれません。
The following rules apply for setting multiple Context flags:
以下の規則は複数のContext旗を設定するために申し込まれます:
a. Multiple context flags can be set only in two generic cases, which
represent a substantial portion of expected COPS transactions, and
can be guaranteed not to cause ambiguity.
a。 複数の文脈旗を2つのジェネリック場合だけで設定できて、あいまいさを引き起こさないように保証できます。(場合は予想されたCOPSトランザクションのかなりの部分を表します)。
Unicast FF:
ユニキャストff:
[Incoming + Allocation + Outgoing]
[入来+配分+送信する]です。
Multicast with only one Resv message received on the interface
インタフェースに1つのResvメッセージだけを受け取っているマルチキャスト
[Incoming + Allocation]
[入来+配分]
b. Context events are ordered by time since every message must first
be processed as Incoming, then as Resource allocation and only
then as Outgoing. When multiple context flags are set, all
ClientSI objects included in the request are assumed to be
processed according to the latest flag. This rule applies both to
the request (REQ) context as well as to the decision (DEC)
context.
b。 文脈イベントは、最初にIncomingとしてそしてResource配分としてそして、Outgoingとしてだけあらゆるメッセージを処理しなければならないので、時間までに命令されます。 複数の文脈旗が設定されるとき、最新の旗に従って要求に含まれていたすべてのClientSIオブジェクトが処理されると思われます。 この規則は決定(12月)文脈に関してまた、要求(REQ)文脈に両方を当てはまります。
Herzog, et al. Standards Track [Page 8] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[8ページ]RFC2749COPS用法
For example, when combining Incoming + Allocation for an incoming
Resv message, the flowspec included in the ClientSI would be the
one corresponding to the Resource-Allocation context (TC).
入って来るResvメッセージのためのIncoming+配分を結合するとき、例えば、ClientSIにflowspecを含むのは、Resource-配分文脈(TC)に対応するものです。
c. Each decision is bound to a context object, which determines which
portion of the request context it applies to. When individual
decisions apply to different sub-groups of the context, the PDP
should send each group of decision objects encapsulated by the
context flags object with the context flags applicable to these
objects set (see the examples in Section 5).
c。 各決定は文脈目的に縛られます。(それは、それが、要求文脈のどの部分がそうするのに申し込むかを決定します)。 個々の決定が文脈の異なったサブグループに適用されるとき、PDPは旗がこれらのオブジェクトに適切な旗が設定する文脈で反対させる文脈によってカプセルに入れられた決定オブジェクトの各グループを送るはずです(セクション5で例を見てください)。
3.7 RSVP Error Reporting
3.7 RSVP誤り報告
RSVP uses the ERROR_SPEC object in PathErr and ResvErr messages to report policy errors. While the contents of the ERROR_SPEC object are defined in [RSVP,RSVP-EXT], the PDP is in the best position to provide its contents (sub-codes). This is performed in the following manner: First, the PEP (RSVP) queries the PDP before sending a PathErr or ResvErr, and then the PDP returns the constructed ERROR_SPEC in the Replacement Data Decision Object.
RSVPはPathErrと方針誤りを報告するResvErrメッセージでERROR_SPECオブジェクトを使用します。 ERROR_SPECオブジェクトの内容は[RSVP、RSVP-EXT]で定義されますが、PDPがコンテンツ(サブコード)を提供する最も良い立場にあります。 これは以下の方法で実行されます: まず最初に、PathErrかResvErrを送る前にPEP(RSVP)はPDPについて質問します、そして、次に、PDPはReplacement Data Decision Objectで組み立てられたERROR_SPECを返します。
4 Security Considerations
4 セキュリティ問題
This document relies on COPS for its signaling and its security. Please refer to section "Security Considerations" in [COPS].
このドキュメントはシグナリングとそのセキュリティのためにCOPSを当てにします。 [COPS]の「セキュリティ問題」というセクションを参照してください。
Security for RSVP messages is provided by inter-router MD5 authentication [MD5], assuming a chain-of-trust model. A likely deployment scenario calls for PEPs to be deployed only at the network edge (boundary nodes) while the core of the network (backbone) consists of PIN nodes. In this scenario MD5 trust (authentication) is established between boundary (non-neighboring) PEPs. Such trust can be achieved through internal signing (integrity) of the Policy Data object itself, which is left unmodified as it passes through PIN nodes (see [RSVP-EXT]).
信頼のチェーンモデルに就いて、相互ルータMD5認証[MD5]でRSVPメッセージのためのセキュリティを提供します。 ネットワーク(バックボーン)のコアは暗証番号ノードから成りますが、ありそうな展開シナリオは、PEPsがネットワーク縁(境界ノード)だけで配布されるように求めます。 このシナリオに、MD5信頼(認証)は境界(非隣接している)PEPsの間で確立されます。 Policy Dataオブジェクト自体の内部の署名(保全)を通してそのような信頼を達成できます。それが暗証番号ノードを通り抜けるのに従って([RSVP-EXT]を見てください)、署名は変更されていないままにされます。
5 Illustrative Examples, Using COPS for RSVP
5 RSVPに巡査を使用する説明に役立った例
This section details both typical unicast and multicast scenarios.
このセクションは典型的なユニキャストとマルチキャストシナリオの両方を詳しく述べます。
5.1 Unicast Flow Example
5.1 ユニキャスト流れの例
This section details the steps in using COPS for controlling a Unicast RSVP flow. It details the contents of the COPS messages with respect to Figure 1.
このセクションはUnicast RSVP流動を制御するのにCOPSを使用する際にステップを詳しく述べます。 それは図1に関してCOPSメッセージのコンテンツを詳しく述べます。
Herzog, et al. Standards Track [Page 9] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[9ページ]RFC2749COPS用法
PEP (router)
+-----------------+
| |
R1 ------------+if1 if2+------------ S1
| |
+-----------------+
(ルータ)+を元気づけてください。-----------------+ | | R1------------+ if1 if2+------------ S1| | +-----------------+
Figure 1: Unicast Example: a single PEP view
図1: ユニキャストの例: ただ一つのPEP視点
The PEP router has two interfaces (if1, if2). Sender S1 sends to receiver R1.
PEPルータには、2つのインタフェース(if1、if2)があります。 送付者S1は受信機R1に発信します。
A Path message arrives from S1:
PathメッセージはS1から到着します:
PEP --> PDP REQ := <Handle A> <Context: in & out, Path>
<In-Interface if2> <Out-Interface if1>
<ClientSI: all objects in Path message>
元気づけてください-->PDP REQ:=<は><文脈を扱います: 中と外と、Path><In-インタフェースif2><はif1><ClientSIをOut連結します: Pathメッセージ>のすべてのオブジェクト
PDP --> PEP DEC := <Handle A> <Context: in & out, Path>
<Decision: Command, Install>
PDP-->気力12月の:=<は><文脈を扱います: コネと出ているPath><Decision: 命令してください、そして、>をインストールしてください。
A Resv message arrives from R1:
ResvメッセージはR1から到着します:
PEP --> PDP REQ := <Handle B>
<Context: in & allocation & out, Resv>
<In-Interface if1> <Out-Interface if2>
<ClientSI: all objects in Resv message>
気力-->PDP REQ:=<ハンドルB><文脈: コネ、配分、および出ているResv><Inインタフェースif1><Out-インタフェースif2><ClientSI: Resvメッセージ>のすべてのオブジェクト
PDP --> PEP DEC := <Handle B>
<Context: in, Resv>
<Decision: command, Install>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, Priority=7>
<Context: out, Resv>
<Decision: command, Install>
<Decision: replacement, POLICY-DATA1>
PDP-->気力12月の:=<はB><文脈を扱います: コネ、Resv><Decision: Install><Context、命令してください: 配分、Resv><Decision: Install><Decision、命令してください: 状態がなくて、優先権は7><文脈と等しいです: 出ているResv><Decision: Install><Decision、命令してください: 交換、POLICY-DATA1>。
PEP --> PDP RPT := <Handle B>
<Report type: commit>
PEP-->PDP RPT:=<Handle B><Reportはタイプします: >を遂行してください。
Notice that the Decision was split because of the need to specify different decision objects for different context flags.
Decisionが異なった文脈旗に異なった決定オブジェクトを指定する必要性のために分割されたのに注意してください。
Herzog, et al. Standards Track [Page 10] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[10ページ]RFC2749COPS用法
Time Passes, the PDP changes its decision:
時間Passes、PDPは決定を変えます:
PDP --> PEP DEC := <Handle B>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, Priority=3>
PDP-->気力12月の:=<はB><文脈を扱います: 配分、Resv><Decision: Install><Decision、命令してください: 状態がなくて、優先権は3>と等しいです。
Because the priority is too low, the PEP preempts the flow:
優先度が低過ぎるので、PEPは流れを先取りします:
PEP --> PDP DRQ := <Handle B>
<Reason Code: Preempted>
元気づけてください-->PDP DRQ:=<ハンドルB><はコードを推論します: 先取りされた>。
Time Passes, the sender S1 ceases to send Path messages:
時間Passes、送付者S1はメッセージをPathに送るのをやめます:
PEP --> PDP DRQ := <Handle A>
<Reason: Timeout>
元気づけてください-->PDP DRQ:=<は><理由を扱います: タイムアウト>。
5.2 Shared Multicast Flows
5.2 共有されたマルチキャスト流れ
This section details the steps in using COPS for controlling a multicast RSVP flow. It details the contents of the COPS messages with respect to Figure 2.
このセクションはマルチキャストRSVP流動を制御するのにCOPSを使用する際にステップを詳しく述べます。 それは図2に関してCOPSメッセージのコンテンツを詳しく述べます。
PEP (router)
+-----------------+
| |
R1-------------+ if1 if3 +--------- S1
| |
R2----+ | |
| | |
+--------+ if2 if4 +--------- S2
| | |
R3----+ +-----------------+
(ルータ)+を元気づけてください。-----------------+ | | R1-------------+ if1 if3+--------- S1| | R2----+ | | | | | +--------+ if2 if4+--------- S2| | | R3----+ +-----------------+
Figure 2: Multicast example: a single PEP view
図2: マルチキャストの例: ただ一つのPEP視点
Figure 2 shows an RSVP PEP (router) which has two senders (S1, S2) and three receivers (R1, R2, R3) for the same multicast session. Interface if2 is connected to a shared media. In this example, we assume that the multicast membership is already in place. No previous RSVP messages were received, and the first to arrive is a Path message on interface if3 from sender S1:
図2は、どれに2人の送付者(S1、S2)と3台の受信機(R1、R2、R3)が同じマルチキャストセッションのためにあるかをRSVP PEP(ルータ)に示します。 インタフェースif2は共有されたメディアに接続されます。 この例では、私たちは、マルチキャスト会員資格が既に適所にあると思います。 前のRSVPメッセージを全く受け取りませんでした、そして、到着する1番目は送付者S1からのインタフェースif3に関するPathメッセージです:
PEP --> PDP REQ := <Handle A> <Context: in, Path>
<In-interface if3>
<ClientSI: all objects in incoming Path>
元気づけてください-->PDP REQ:=<は><文脈を扱います: コネ、Path><In-インタフェースif3><ClientSI: 入って来るPath>のすべてのオブジェクト
Herzog, et al. Standards Track [Page 11] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[11ページ]RFC2749COPS用法
PDP --> PEP DEC := <Handle A> <Context: in, Path>
<Decision: command, Install>
PDP-->気力12月の:=<は><文脈を扱います: コネ、Path><Decision: コマンド、Install>。
The PEP consults its forwarding table, and finds two outgoing interface for the path (if1, if2). The exchange below is for interface if1, another exchange would likewise be completed for if2 using the new handle B2.
PEPは経路(if1、if2)に推進テーブルに相談して、2の外向的なインタフェースを見つけます。 以下での交換はインタフェースif1のためのものであり、別の交換は、if2のために新しいハンドルB2を使用することで同様に終了するでしょう。
PEP --> PDP REQ := <Handle B1> <Context: out, Path>
<Out-interface if1>
<clientSI: all objects in outgoing Path>
気力-->PDP REQ:=<ハンドルB1><文脈: 出かけているPath><Out-インタフェースif1><clientSI: 出発しているPath>のすべての物
PDP --> PEP DEC := <Handle B1>
<Context: out, Path>
<Decision: command, Install>
<Decision: Replacement, POLICY-DATA1>
PDP-->気力12月の:=<はB1><文脈を扱います: 出ているPath><Decision: Install><Decision、命令してください: 交換、方針-DATA1、>。
Here, the PDP decided to allow the forwarding of the Path message and provided the appropriate policy-data object for interface if1.
ここで、PDPはPathメッセージの推進を許すと決めて、適切な方針データ・オブジェクトをインタフェースif1に供給しました。
Next, a WF Resv message from receiver R2 arrives on interface if2.
次に、受信機R2からのWF Resvメッセージはインタフェースif2で到着します。
PEP --> PDP REQ := <Handle C> <Context: in & allocation, Resv>
<In-interface if2>
<ClientSI: all objects in Resv message
including RSpec1 >
気力-->PDP REQ:=<ハンドルC><文脈: コネと配分、Resv><はif2><ClientSIをIn連結します: RSpec1>を含むResvメッセージのすべての物
PDP --> PEP DEC := <Handle C>
<Context: in, Resv>
<Decision: command, Install>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, priority=5>
PDP-->気力12月の:=<はC><文脈を扱います: コネ、Resv><Decision: Install><Context、命令してください: 配分、Resv><Decision: Install><Decision、命令してください: 国がなくて、優先権は5>と等しいです。
PEP --> PDP RPT := <handle C> <Commit>
元気づけてください-->PDP RPT:=<ハンドルC><は>を遂行します。
Here, the PDP approves the reservation and assigned it preemption priority of 5. The PEP responded with a commit report.
ここで、PDPは予約を承認して、5の先取り優先権をそれに割り当てました。 aで反応するPEPはレポートを遂行します。
The PEP needs to forward the Resv message upstream toward S1:
PEPは、Resvメッセージ上流をS1に向かって送る必要があります:
PEP --> PDP REQ := <Handle E> <Context: out, Resv>
<out-interface if3>
<Client info: all objects in outgoing Resv>
気力-->PDP REQ:=<ハンドルE><文脈: 出ているResvの<の出かけているインタフェースif3><Client>インフォメーション: 出発しているResv>のすべての物
Herzog, et al. Standards Track [Page 12] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[12ページ]RFC2749COPS用法
PDP --> PEP DEC := <Handle E>
<Context: out, Resv>
<Decision: command, Install>
<Decision: replacement, POLICY-DATA2>
PDP-->気力12月の:=<はE><文脈を扱います: 出ているResv><Decision: Install><Decision、命令してください: 交換、POLICY-DATA2>。
Note: The Context object is part of this DEC message even though it may look redundant since the REQ specified only one context flag.
以下に注意してください。 REQが1個の文脈旗だけを指定したので、余分に見えるかもしれませんが、Context物はこの12月のメッセージの一部です。
Next, a new WF Resv message from receiver R3 arrives on interface if2 with a higher RSpec (Rspec2). Given two reservations arrived on if2, it cannot perform a request with multiple context flags, and must issue them separately.
次に、受信機R3からの新しいWF Resvメッセージは、より高いRSpec(Rspec2)と共にインタフェースif2で到着します。 2つの与えられた予約がif2で到着して、それは、複数の文脈旗による要求を実行できないで、別々にそれらを発行しなければなりません。
The PEP re-issues an updated handle C REQ with a new context object <Context: in , Resv>, and receives a DEC for handle C.
PEPは新しい文脈物の<Contextと共にアップデートされたハンドルC REQを再発行します: コネ、Resv>、ハンドルCのためにa12月を受けます。
PEP --> PDP REQ := <Handle F> <Context: in , Resv>
<In-interface if2>
<ClientSI: all objects in Resv message
including RSpec2 >
気力-->PDP REQ:=<ハンドルF><文脈: コネ、Resv><In-インタフェースif2><ClientSI: RSpec2>を含むResvメッセージのすべての物
PDP --> PEP DEC := <Handle F> <Context: in , Resv>
<Decision: command, Install>
PDP-->気力12月の:=<はF><文脈を扱います: コネ、Resv><決定: コマンド、Install>。
PEP --> PDP REQ := <Handle G> <Context: allocation, Resv>
<In-interface if2>
<ClientSI: all objects in merged Resv
including RSpec2 >
気力-->PDP REQ:=<ハンドルG><文脈: 配分、Resv><In-インタフェースif2><ClientSI: RSpec2>を含む合併しているResvのすべての物
PDP --> PEP DEC := <Handle G>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, Priority=5>
PDP-->気力12月の:=<はG><文脈を扱います: 配分、Resv><Decision: Install><Decision、命令してください: 国がなくて、優先権は5>と等しいです。
PEP --> PDP RPT := <handle G> <Commit>
元気づけてください-->PDP RPT:=<ハンドルG><は>を遂行します。
Given the change in incoming reservations, the PEP needs to forward a new outgoing Resv message upstream toward S1. This repeats exactly the previous interaction of Handle E, except that the ClientSI objects now reflect the merging of two reservations.
上流へ入って来る予約における変化、新しい送信するResvメッセージを転送するPEPの必要性をS1に向かって与えます。 これはちょうどHandle Eの前の相互作用を繰り返します、ClientSI物が現在2つの予約の合併を反映するのを除いて。
If an ResvErr arrives from S1, the PEP maps it to R3 only (because it has a higher flowspec: Rspec2) the following takes place:
ResvErrがS1から到着するなら、PEPは撮影が置くR3の唯一(より高いflowspec: Rspec2を持っているので)の以下にそれを写像します:
PEP --> PDP REQ := <Handle H> <Context: in, ResvErr>
<In-interface if3>
<ClientSI: all objects in incoming ResvErr>
気力-->PDP REQ:=<ハンドルH><文脈: コネ、ResvErr><In-インタフェースif3><ClientSI: 入って来るResvErr>のすべての物
Herzog, et al. Standards Track [Page 13] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[13ページ]RFC2749COPS用法
PDP --> PEP DEC := <Handle H> <Context: in, ResvErr>
<Decision: command, Install>
PDP-->気力12月の:=<はH><文脈を扱います: コネ、ResvErr><Decision: コマンド、Install>。
PEP --> PDP REQ := <Handle I> <Context: out, ResvErr>
<Out-interface if2>
<ClientSI: all objects in outgoing ResvErr>
気力-->PDP REQ:=<ハンドルI><文脈: 出かけているResvErr><Out-インタフェースif2><ClientSI: 出発しているResvErr>のすべての物
PDP --> PEP DEC := <Handle I>
<Context: out, ResvErr>
<Decision: command, Install>
<Decision: Replacement, POLICY-DATA3>
PDP-->気力12月の:=<はI><文脈を扱います: 出ているResvErr><Decision: Install><Decision、命令してください: 交換、方針-DATA3、>。
When S2 joins the session by sending a Path message, incoming and outgoing Path requests are issued for the new Path. A new outgoing Resv request would be sent to S2.
Pathメッセージを送ることによってS2がセッションに参加すると、送受信のPath要求は新しいPathのために出されます。 新しい送信するResv要求をS2に送るでしょう。
6 References
6つの参照箇所
[RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC
2750, January 2000.
[RSVP-EXT] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」、RFC2750、2000年1月。
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
for Policy Based Admission Control", RFC 2753, January
2000.
[叩きます] YavatkarとR.とPendarakisとD.とR.ゲラン、「方針のベースの入場コントロールのための枠組み」、RFC2753、2000年1月。
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and
A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
[巡査]ボイル、J.、コーエン、R.、ダラム、D.、ハーツォグ、S.、王侯、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) - Functional
Specification", RFC 2205, September 1997.
[RSVP] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--機能的な仕様」、RFC2205、1997年9月。
Herzog, et al. Standards Track [Page 14] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[14ページ]RFC2749COPS用法
7 Author Information and Acknowledgments
7 作者情報と承認
Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, Fred Baker, Laura Cunningham, Russell Fenger, Roch Guerin, Ping Pan, and Raj Yavatkar, for their valuable contributions.
彼らの有価約因のための特別な感謝のアンドリュー・スミスとティモシー・オマリーへの私たちのWG Chairs、フレッド・ベイカー、ローラカニンハム、ラッセルFenger、Rochゲラン、Ping Pan、およびRaj Yavatkar。
Jim Boyle Level 3 Communications 1025 Eldorado Boulevard Broomfield, CO 80021
ジムボイルLevel3 コミュニケーション1025エルドラドBoulevardブルームフィールド、CO 80021
Phone: 720.888.1192 EMail: jboyle@Level3.net
以下に電話をしてください。 720.888.1192 メールしてください: jboyle@Level3.net
Ron Cohen CISCO Systems 4 Maskit St. Herzeliya Pituach 46766 Israel
ロンコーエンコクチマスシステム4Maskit聖Herzeliya Pituach46766イスラエル
Phone: 972.9.9700064 EMail: ronc@cisco.com
以下に電話をしてください。 972.9.9700064 メールしてください: ronc@cisco.com
David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124
第25デヴィッドダラムインテル2111Ne Avenueヒースボロー、または97124
Phone: 503.264.6232 EMail: David.Durham@intel.com
以下に電話をしてください。 503.264.6232 メールしてください: David.Durham@intel.com
Raju Rajan AT&T Labs Research 180 Park Ave., P.O. Box 971 Florham Park, NJ 07932
ラジュRajan AT&T研究室が180公園Aveについて研究する、ニュージャージー 私書箱971Florham公園、07932
Phone: 973.360.7229 EMail: raju@research.att.com
以下に電話をしてください。 973.360.7229 メールしてください: raju@research.att.com
Herzog, et al. Standards Track [Page 15] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[15ページ]RFC2749COPS用法
Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701
ShaiハーツォグIPHighway Inc.55ニューヨークAvenueフレイミングハム、MA 01701
Phone: 508.620.1141 EMail: herzog@iphighway.com
以下に電話をしてください。 508.620.1141 メールしてください: herzog@iphighway.com
Arun Sastry Cisco Systems 4 The Square Stockley Park Uxbridge, Middlesex UB11 1BN UK
アルンSastryシスコシステムズ4正方形のストックリー・Parkアクスブリッジ、ミドルセックスUB11 1BNイギリス
Phone: +44-208-756-8693 EMail: asastry@cisco.com
以下に電話をしてください。 +44-208-756-8693 メールしてください: asastry@cisco.com
Herzog, et al. Standards Track [Page 16] RFC 2749 COPS usage for RSVP January 2000
ハーツォグ、他 RSVP2000年1月のための規格Track[16ページ]RFC2749COPS用法
8 Full Copyright Statement
8 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Herzog, et al. Standards Track [Page 17]
ハーツォグ、他 標準化過程[17ページ]
一覧
スポンサーリンク
