[要約] RFC 3936は、RSVPの変更手順に関するドキュメントであり、RSVPプロトコルの拡張や改善に関するガイドラインを提供しています。目的は、RSVPの機能や性能を向上させるための手順を提供し、ネットワークリソースの予約と制御を効果的に行うことです。
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
IANAは、次のRSVP名スペースを認識します：メッセージタイプ、クラス名、クラス番号、クラスタイプとサブオブジェクト、仮想宛先ポート、エラーコード、および（サブコード）値（これらはすべて、これにおける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.
このドキュメントで使用される割り当てポリシーは、次のとおりです。最後の2つはこのドキュメントで定義されています。これらの割り当てポリシーの目的は、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考慮事項セクション（セクション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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
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アクション中に行われた実際の割り当てによって要求されなければなりません。「Expert Review」の範囲からの値は、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 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.
「組織/ベンダープライベート」範囲は、エンタープライズ固有の値を指します。これらはIANAに登録してはなりません。ベンダーのプライベート値の場合、データフィールドの最初の4オクテットワードは、IANA SMIネットワーク管理プライベートエンタープライズコードに登録されているエンタープライズコード[ENT]でなければなりません。企業。（ベンダープライベート範囲を持つ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ビットクラス番号（クラスナムまたはC-Numとも呼ばれます）によって識別されます。クラス番号は、クラスNumオブジェクトの2つの高次ビット（以下の「B」は少しを表します）によって決定される3つの範囲（0-127、128-191、および192-255）に広く分割されます。
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.
注：Class-Numまたはクラスタイプがベンダープライベート範囲からのものであるオブジェクトの最初の32ビットワードは、ベンダーのSMIエンタープライズコードがネットワークOctetの順序でそのものでなければなりません（これらのエンタープライズコードはIANAから取得し、登録できます。）。[RSVP]、セクション3.10で指定されているように、Class-Numに基づいて、そのオブジェクト（および同封のメッセージ）を認識しないSMIエンタープライズコードを使用してベンダープライベートオブジェクトに遭遇する実装が必要です。
o Class-Num = 0bbbbbbb
o class-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のクラス番号は、専門家のレビューによって割り当てられます。124〜127のクラス番号は、ベンダーの私的使用のために予約されています。
o Class-Num = 10bbbbbb
o class-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までのクラス番号は、専門家のレビューによって割り当てられます。188〜191までのクラス番号は、ベンダーの私的使用のために予約されています。
o Class-Num = 11bbbbbb
o class-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のクラス番号は、専門家のレビューによって割り当てられます。252〜255のクラス番号は、ベンダーの私的使用のために予約されています。
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.
各オブジェクトクラスには、8ビットクラスタイプ（Cタイプとも呼ばれます）があります。クラスタイプはクラス番号にスコープされます。一般に、エキスパートレビューまたはベンダープライベートを通じてクラスタイプの割り当てを許可することの適切性は、クラス番号自体のセマンティクスに依存します。したがって、新しいクラス番号定義は、追加のクラスタイプ値を割り当てるための適切な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.
オブジェクト内では、サブオブジェクトが定義される場合があります。これは、一般に型長の価値トリプルとしてです。このメモは、reblicit_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.
riblicit_routeオブジェクト[rsvp-te]は、7ビット型フィールドによって識別される可変長さサブオブジェクトを搭載します。タイプ0〜119は、標準アクションによって割り当てられます。タイプ120〜123は、専門家のレビューによって割り当てられます。タイプ124〜127は、ベンダーの私的使用のために予約されます。
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は、標準アクションによって割り当てられます。タイプ192から251は、専門家のレビューによって割り当てられます。タイプ252〜255は、ベンダーの私的使用のために予約されます。
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.
liblicit_routeまたはrecord_routeオブジェクトのベンダープライベートサブオブジェクトのサブオブジェクトコンテンツの最初の4オクテットは、ネットワークOctet順序でそのベンダーのSMIエンタープライズコードでなければなりません。
Virtual destination ports are described in [RSVP-IPSEC], which also specifies how IANA assignments are to be made.
仮想宛先ポートは[RSVP-IPSEC]で説明されています。これは、IANAの割り当ての作成方法も指定しています。
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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：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] Berger、L。およびT. O'Malley、「IPSECデータフロー用のRSVP拡張」、RFC 2207、1997年9月。
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089 USA
EMail: kireeti@juniper.net
Jonathan P. Lang Rincon Networks
ジョナサンP.ラングリンコンネットワーク
EMail: jplang@ieee.org
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。