Network Working Group K. Kompella
Request for Comments: 3936 Juniper Networks
Updates: 3209, 2205 J. Lang
BCP: 96 Rincon Networks
Category: Best Current Practice October 2004
Procedures for Modifying the Resource reSerVation Protocol (RSVP)
リソース予約プロトコル（RSVP）を変更するための手順
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects.
このメモは、リソース予約プロトコル（RSVP）を変更するための手順を指定します。また、このメモはRSVPメッセージ、オブジェクトクラス、クラス・タイプ、およびサブオブジェクトの番号スペースの新しい割り当てのガイドラインをレイアウト。
This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP) [RSVP], including (but not limited to) adding, updating, extending or obsoleting: messages, message formats and procedures, object classes and class types, object formats and procedures; header formats, error codes and subcodes and semantics, and procedures for sending, receiving, and addressing RSVP messages.
このメモは、以下を含む（これらに限定されない）、追加、更新、拡張または時代遅れ、リソース予約プロトコル（RSVP）[RSVP]を修正するための手順を指定：メッセージ、メッセージ・フォーマットおよび手順、オブジェクトクラスとクラスタイプ、オブジェクトフォーマットおよび手順を、ヘッダフォーマット、エラーコードとサブコードとセマンティクス、及び、送信、受信、およびRSVPメッセージに対処するための手順。
IANA recognizes the following RSVP name spaces: Message Types, Class Names, Class Numbers, Class Types and Sub-objects, Virtual Destination Ports, and Error Codes and (Subcode) Values (all of these will collectively be referred to as RSVP entities in this document). This memo specifies ranges for each name space and assignment policies for each range. New RSVP name spaces must be defined in a Standards Track RFC which include guidelines for IANA assignments within the new name spaces.
これらのすべてをまとめ、この中RSVPエンティティと呼ぶことにするメッセージタイプ、クラス名、クラス番号、クラスの型とサブオブジェクト、仮想宛先ポート、およびエラーコードと（サブコード）の値（：IANAは、次のRSVPの名前空間を認識し、資料）。このメモは、各レンジの各名前空間と割り当てポリシーの範囲を指定します。新しいRSVPの名前空間には、新しい名前空間内のIANAの割り当てのためのガイドラインが含まれる標準化過程RFCで定義する必要があります。
The assignment policies used in this document are: Standards Action (as defined in [IANA]), Expert Review, and Organization/Vendor Private (more simply, "Vendor Private"); the last two are defined in this document. The intent of these assignment policies is to ensure that extensions to RSVP receive adequate review before code-points are assigned, without being overly rigid. Thus, if an extension is widely accepted and its ramifications are well understood, it may receive an assignment from the Standards Action space; however, if an extension is experimental in nature, it receives an assignment from the Expert Review space, and may, with maturity, move to Standards Track. Assignments from the Vendor Private space are not reviewed, but there are mechanisms in place to ensure that these codepoints can co-exist in a network without harm.
この文書で使用されている割り当てポリシーは以下のとおりです。標準アクション（[IANA]で定義される）、エキスパートレビュー、および組織/ベンダープライベート（より単純に、「ベンダープライベート」）;最後の二つは、この文書で定義されています。これらの割り当てポリシーの意図は、コードポイントが割り当てられている前に、拡張子が過度に剛性されることなく、十分な審査を受けるRSVPにいることを確認することです。拡張が広く受け入れられ、その波及効果はよく理解されている場合したがって、それは標準アクション空間から割り当てを受信することができます。しかし、拡張子が本質的に実験的なものであれば、それは専門家レビューの空間から割り当てを受け、かつ、満期、標準化過程に動かすことができます。ベンダーのプライベート空間から割り当てが検討されていないが、これらのコードポイントは害なしでネットワーク内に共存することができることを保証するための場所でのメカニズムがあります。
A standards body other than the IETF that wishes to obtain an assignment for an RSVP entity must decide from which type of name/number space they desire their assignment be made from, and then submit the appropriate documentation. For example, if the assignment is to be made from a number space designated as Standards Action, a Standards Track RFC MUST be submitted in support of the request for assignment.
決定しなければなりませんRSVPエンティティの割り当てを得たいIETF以外の標準化団体は、名前/番号空間のどの種類から、彼らは彼らの割り当てがから作ることが希望し、適切な書類を提出します。割り当ては標準アクションとして指定された数のスペースから作られるのであれば、例えば、標準化過程RFCは、割り当て要求のサポートに提出しなければなりません。
This memo updates the IANA Considerations section (section 7) of [RSVP-TE], replacing the assignment policies stated there.
このメモが記載割り当てポリシーを置き換える、[RSVP-TE]のIANA Considerations部（セクション7）を更新します。
Conventions used in this document
この文書で使用されている表記
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 BCP 14, RFC 2119 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [KEYWORDS]で説明されるように解釈されます。
For each of the RSVP name spaces identified by IANA, the space is divided into assignment ranges; the following terms are used in describing the procedures by which IANA assigns values: "Standards Action" (as defined in [IANA]), "Expert Review", and "Organization/Vendor Private", defined below.
IANAによって識別RSVPの名前空間のそれぞれについて、空間が割り当て範囲に分割されます。 「標準アクション」（[IANA]で定義されるように）、「エキスパートレビュー」、および以下に定義される「組織/ベンダープライベート」、次の用語は、IANAに値を割り当てることによって手順を説明するのに使用されます。
"Expert Review" ranges refer to values that are to be reviewed by an Expert designated by the IESG. The code points from these ranges are typically used for experimental extensions; such assignments MUST be requested by Experimental RFCs that document their use and processing, and the actual assignments made during the IANA actions for the document. Values from "Expert Review" ranges MUST be registered with IANA.
「エキスパートレビュー」の範囲は、IESGが指定した専門家によって審査される値を参照してください。これらの範囲からのコード・ポイントは、典型的には、実験の拡張のために使用されます。そのような割り当ては、その使用して処理を文書化実験のRFC、および文書のためのIANA動作中に行われた実際の割り当てによって要求されなければなりません。 「エキスパートレビュー」の範囲からの値はIANAに登録しなければなりません。
"Organization/Vendor Private" ranges refer to values that are enterprise-specific; these MUST NOT be registered with IANA. For Vendor Private values, the first 4-octet word of the data field MUST be an enterprise code [ENT] as registered with the IANA SMI Network
「組織/ベンダープライベート」の範囲は、企業固有の値を指します。これらは、IANAに登録されてはなりません。ベンダープライベート値に対して、データフィールドの最初の4オクテットワードは、企業コードは[ENT] IANA SMIネットワークに登録されていなければなりません
Management Private Enterprise Codes, and the rest of the data thereafter is for the private use of the registered enterprise. (For each RSVP entity that has a Vendor Private range, it must be specified where exactly the data field starts; see below for examples.) In this way, different enterprises, vendors, or Standards Development Organizations (SDOs) can use the same code point without fear of collision.
管理プライベートエンタープライズコード、およびデータの残りの部分は、その後、登録された企業の私的使用のためです。 （ベンダープライベート範囲を有する各RSVPエンティティは、それは場所を正確にデータフィールドが始まる指定しなければならない。例については以下を参照。）このように、異なる企業、ベンダー、または規格開発組織（のSDO）が同じコードを使用することができ衝突の恐れのないポイント。
A Message Type is an 8-bit number that identifies the function of the RSVP message. Values from 0 through 239 are to be assigned by Standards Action. Values from 240 through 255 are to be assigned by Expert Review.
メッセージタイプは、RSVPメッセージの機能を識別する8ビットの数です。 0から239までの値は、標準化アクションにより割り当てられることになっています。 240から255までの値は、専門家レビューにより割り当てられることになっています。
Each class of data objects in an RSVP message is identified by an all upper-case Class Name and an 8-bit Class Number (also known as Class-Num or C-Num). Class Numbers are divided broadly into three ranges (0-127, 128-191, and 192-255) determined by the two high-order bits of the Class-Num object (the 'b' below represents a bit).
RSVPメッセージ内のデータ・オブジェクトの各クラスは、すべて大文字クラス名と8ビットのクラス番号（また、クラスのNumまたはC-民として知られている）によって識別されます。クラス番号は、クラスのNumオブジェクトの上位2ビットによって決定される3つの範囲（0〜127、128から191、および192から255）に大別される（「b」は以下のビットを表します）。
Note: the first 32-bit word of an Object whose Class-Num or Class-Type is from the Vendor Private range MUST be that vendor's SMI enterprise code in network octet order (these enterprise codes can be obtained from, and registered with, IANA). An implementation encountering a Vendor Private object with an SMI enterprise code that it does not recognize MUST treat that object (and enclosing message) based on the Class-Num, as specified in [RSVP], section 3.10.
注：クラスのNumまたはクラス型ベンダープライベート範囲であるネットワークオクテット順序（これらの企業コードはから得られ、IANAに登録することが可能で、そのベンダーのSMIエンタープライズコードである必要があり、オブジェクトの最初の32ビットワードを）。 [RSVP]で指定されるようにクラス民に基づくSMIエンタープライズがそのオブジェクトを扱わなければなりません認識しないコード（及び包囲メッセージ）とベンダープライベートオブジェクトに遭遇した実装、3.10。
o Class-Num = 0bbbbbbb
クラスのNum = 0bbbbbbbは
Class Numbers from 0 through 119 are to be assigned by Standards Action. Class Numbers from 120 through 123 are to be assigned by Expert Review. Class Numbers from 124 through 127 are reserved for Vendor Private Use.
0から119経由クラス番号は、標準アクションにより割り当てられることになっています。 120から123を通じてクラス番号は、専門家レビューにより割り当てられることになっています。 〜127 124からクラス番号は、ベンダー私的使用のために予約されています。
o Class-Num = 10bbbbbb
OクラスのNum = 10bbbbbb
Class Numbers from 128 through 183 are to be assigned by Standards Action. Class Numbers from 184 through 187 are to be assigned by Expert Review. Class Numbers from 188 through 191 are reserved for Vendor Private Use.
128から183を通じてクラス番号は、標準アクションにより割り当てられることになっています。 184から187を通じてクラス番号は、専門家レビューにより割り当てられることになっています。 〜191 188からクラス番号は、ベンダー私的使用のために予約されています。
o Class-Num = 11bbbbbb
OクラスのNum = 11bbbbbb
Class Numbers from 192 through 247 are to be assigned by Standards Action. Class Numbers from 248 through 251 are to be assigned by Expert Review. Class Numbers from 252 through 255 are reserved for Vendor Private Use.
192から247を通じてクラス番号は、標準アクションにより割り当てられることになっています。 248から251を通じてクラス番号は、専門家レビューにより割り当てられることになっています。 255 252からクラス番号は、ベンダー私的使用のために予約されています。
Within each object class there is an 8-bit Class Type (also known as a C-Type). Class Types are scoped to a Class Number. In general, the appropriateness of allowing assignments of Class Types through Expert Review or Vendor Private depends on the semantics of the Class Number itself. Thus, any new Class Number definition must specify an appropriate IANA Considerations policy for assigning additional Class Type values.
各オブジェクトクラス内（また、C型としても知られる）8ビットのクラスタイプがあります。クラスの型は、クラス番号にスコープされています。一般的には、専門家レビューやベンダープライベートを通じてクラスの型の割り当てを可能にする妥当性は、クラス数自体の意味論に依存します。このように、任意の新しいクラス番号の定義は、追加のクラスタイプの値を割り当てるための適切なIANAの考慮事項のポリシーを指定する必要があります。
For Class Numbers that pre-date this document (specifically, 0, 1, 3-25, 30-37, 42-45, 64, 65, 128-131, 161-165, 192-196, and 207), the default assignment policy for new Class Types is Standards Action, unless a Standards Track or Best Current Practice RFC supercedes this.
クラス番号の事前日付（具体的には、0、1、3-25、30-37、42-45、64、65、128-131、161-165、192-196、および207）は、この文書、デフォルトその標準化過程または最も良い現在の練習のRFCはこれを優先しない限り、新しいクラスの型の割り当てポリシーは、標準アクションです。
Within an object, sub-objects may be defined, generally as a Type-Length-Value triple. This memo defines the assignment policies for sub-objects of EXPLICIT_ROUTE and RECORD_ROUTE. An RFC defining new sub-objects MUST state how IANA is to assign the sub-object Types.
オブジェクト内の、サブオブジェクトは、一般的に三重タイプレングス値として定義することができます。このメモはEXPLICIT_ROUTEとRECORD_ROUTEのサブオブジェクトのための割り当てポリシーを定義します。新しいサブオブジェクトを定義するRFCは、IANAは、サブオブジェクトタイプを割り当てることがいかに述べなければなりません。
The EXPLICIT_ROUTE object [RSVP-TE] carries a variable length sub-object that is identified by a 7-bit Type field. Types 0 through 119 are to be assigned by Standards Action. Types 120 through 123 are to be assigned by Expert Review. Types 124 through 127 are to be reserved for Vendor Private Use.
EXPLICIT_ROUTEオブジェクト[RSVP-TE]は7ビットのTypeフィールドによって識別される可変長サブオブジェクトを運びます。 0〜119種類には、標準化アクションにより割り当てられることになっています。 〜123タイプ120は、専門家レビューにより割り当てられることになっています。 〜127タイプ124は、ベンダーのプライベート利用のために予約されることになります。
The RECORD_ROUTE object [RSVP-TE] carries a variable length sub-object that is identified by an 8-bit Type field. Types 0 through 191 are to be assigned by Standards Action. Types 192 through 251 are to be assigned by Expert Review. Types 252 through 255 are to be reserved for Vendor Private Use.
RECORD_ROUTEオブジェクト[RSVP-TE]は8ビットのタイプ・フィールドによって識別される可変長サブオブジェクトを運びます。 0〜191種類には、標準化アクションにより割り当てられることになっています。タイプ251 192〜エキスパートレビューにより割り当てられることになっています。 255タイプ252は、ベンダーのプライベート利用のために予約されることになります。
The first four octets of the sub-object contents of a Vendor Private sub-object of an EXPLICIT_ROUTE or RECORD_ROUTE object MUST be that vendor's SMI enterprise code in network octet order.
EXPLICIT_ROUTE又はRECORD_ROUTEオブジェクトのベンダープライベートサブオブジェクトのサブオブジェクトのコンテンツの最初の4つのオクテットはネットワークオクテットためにそのベンダーのSMIエンタープライズコードでなければなりません。
Virtual destination ports are described in [RSVP-IPSEC], which also specifies how IANA assignments are to be made.
仮想宛先ポートはまた、IANAの割り当てが行われるべき方法を指定[RSVP-IPSEC]に記載されています。
An Error Code is an 8-bit quantity that appears in an ERROR_SPEC object to broadly define an error condition. With each Error Code there may be a 16-bit Error Value that further specifies the cause of the error. Error Value may be globally defined, in which case the sub-code component is assigned by IANA.
エラーコードは、広く、エラー状態を定義するERROR_SPECオブジェクトに表示される8ビットの量です。各エラーコードを使用して、さらに、エラーの原因を指定する16ビットのエラー値があるかもしれません。エラー値は、グローバルサブコード成分はIANAによって割り当てられている場合には、定義されてもよいです。
Error Code values from 0 through 239 are to be assigned by Standards Action. Values from 240 through 251 are to be assigned by Expert Review. Values from 252 through 255 are reserved for Vendor Private Use. If the Error Code is for Vendor Private Use, the first four octets following the Error Value MUST be the vendor's SMI enterprise code in network octet order.
0から239によるエラーコードの値は、標準化アクションにより割り当てられることになっています。 240から251までの値は、専門家レビューにより割り当てられることになっています。 252から255までの値は、ベンダーのプライベート利用のために予約されています。エラーコードは、ベンダー私的使用のためである場合、エラー値以下の最初の4つのオクテットはネットワークオクテットために、ベンダーのSMIエンタープライズコードでなければなりません。
Globally defined Error Values are assigned by Standards Action.
グローバルに定義されたエラー値は標準アクションによって割り当てられます。
RSVP entities have associated procedures describing when and how they are to be sent, received, processed, and responded to. A change to a procedure that affects the processing of an RSVP entity that belongs to a range designated "Standards Action" MUST be documented in a Standards Track RFC. A change to a procedure that affects the processing of an RSVP entity that belongs to a range designated "Expert Review" MUST be documented in an Experimental RFC.
RSVPエンティティは、ときに彼らが送信される方法を説明する手順を関連する受信、処理、およびに対応してきました。 「標準化アクション」指定された範囲に属しているRSVPエンティティの処理に影響を与え手順への変更は、標準化過程のRFCで文書化されなければなりません。 「エキスパートレビュー」指定された範囲に属しているRSVPエンティティの処理に影響を与え手順への変更は実験的RFCに文書化されなければなりません。
Many thanks to Scott Bradner, who encouraged this project, and made several helpful comments and suggestions.
このプロジェクトを奨励し、いくつかの有益なコメントや提案をしたスコット・ブラッドナー、に感謝します。
It is hoped that the procedures outlined in this memo will ensure that changes made to RSVP will be better reviewed and thus more architecturally sound, thereby enhancing the security both of the protocol and of networks deploying it.
このメモで概説した手順は、それによってプロトコルのそれを展開ネットワークの両方のセキュリティを強化する、RSVPに加えられた変更は、より良好な見直し、従ってよりアーキテクチャ音れることを確実にすることが望まれます。
See section 2.
セクション2を参照してください。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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の機能的な仕様"。、RFC 2205、9月1997。
[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.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209 、2001年12月。
[ENT] IANA PRIVATE ENTERPRISE NUMBERS, http://www.iana.org/assignments/enterprise-numbers
[ENT] IANA民間企業番号、http://www.iana.org/assignments/enterprise-numbers
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RSVP-IPSEC]バーガー、L.とT.オマリー、RFC 2207、1997年9月、 "IPSECデータのためのRSVP拡張フロー"。
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
Kireeti Kompellaジュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089 USA
EMail: kireeti@juniper.net
メールアドレス：kireeti@juniper.net
Jonathan P. Lang Rincon Networks
ジョナサンP.ラングリンコンネットワーク
EMail: jplang@ieee.org
メールアドレス：jplang@ieee.org
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。