Network Working Group JP. Vasseur, Ed.
Request for Comments: 4971 N. Shen, Ed.
Category: Standards Track Cisco Systems, Inc.
R. Aggarwal, Ed.
Juniper Networks
July 2007
Intermediate System to Intermediate System (IS-IS) Extensions
for Advertising Router Information
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain.
この文書では、中間システムルータがIS-ISレベルまたは全体のルーティングドメイン内にその機能をアナウンスすることを可能にする複数のサブTLVは、で形成された（ - である）TLV名前能力に新しい任意の中間システムを定義します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. IS-IS Router CAPABILITY TLV .....................................3
3. Elements of Procedure ...........................................4
4. Interoperability with Routers Not Supporting the
Capability TLV ..................................................5
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
7. Acknowledgment ..................................................6
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................8
There are several situations where it is useful for the IS-IS [IS-IS] [IS-IS-IP] routers to learn the capabilities of the other routers of their IS-IS level, area, or routing domain. For the sake of illustration, three examples related to MPLS Traffic Engineering (TE) are described here:
それが彼らのIS-ISレベル、エリア、またはルーティングドメインの他のルータの機能を学ぶためのIS-IS [IS-IS] [IS-IS-IP]ルーターのに便利ですいくつかの状況があります。説明のために、MPLSトラフィックエンジニアリング（TE）に関連する3つの例はここに記載されています。
1. Mesh-group: the setting up of a mesh of TE Label Switched Paths (LSPs) [IS-IS-TE] requires some significant configuration effort. [AUTOMESH] proposes an auto-discovery mechanism whereby every Label Switching Router (LSR) of a mesh advertises its mesh-group membership by means of IS-IS extensions.
1.メッシュグループ：TEラベルのメッシュの設定は、（LSPを）パスの交換[IS-IS-TE]いくつかの重要な設定作業が必要です。メッシュのすべてのラベルスイッチングルータ（LSR）がIS-ISの拡張によって、そのメッシュグループのメンバーシップをアドバタイズすることにより[AUTOMESH]は、自動検出メカニズムを提案しています。
2. Point to Multipoint TE LSP (P2MP LSP). A specific sub-TLV ([TE-NODE-CAP]) allows an LSR to advertise its Point To Multipoint capabilities ([P2MP] and [P2MP-REQS]).
TE LSP（P2MP LSP）を対多2.ポイント。特定のサブTLVは、（[TE-NODE-CAP]）はLSRが（[P2MP]及び[P2MP-REQS]）機能を対多、そのポイントをアドバタイズすることを可能にします。
3. Inter-area traffic engineering: Advertisement of the IPv4 and/or the IPv6 Traffic Engineering Router IDs.
3.エリア間のトラフィックエンジニアリング：IPv4および/またはIPv6トラフィックエンジニアリングルータIDの広告。
The use of IS-IS for Path Computation Element (PCE) discovery may also be considered and will be discussed in the PCE WG.
経路計算エレメント（PCE）発見のためのIS-ISの使用も考慮してもよいし、PCEのWGで議論されます。
The capabilities mentioned above require the specification of new sub-TLVs carried within the CAPABILITY TLV defined in this document.
上記機能は、本文書で定義されたCAPABILITYのTLVの中で運ば新しいサブのTLVの仕様を必要とします。
Note that the examples above are provided for the sake of illustration. This document proposes a generic capability advertising mechanism that is not limited to MPLS Traffic Engineering.
上記の例は説明のために提供されることに留意されたいです。この文書では、MPLSトラフィックエンジニアリングに限定されるものではなく、一般的な能力の広告メカニズムを提案しています。
This document defines a new optional IS-IS TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. The applications mentioned above require the specification of new sub-TLVs carried within the CAPABILITY TLV defined in this document.
この文書は、新しいオプションは、ルータがIS-ISレベルまたは全体のルーティングドメイン内にその機能をアナウンスすることを可能にする複数のサブTLVは、TLVで形成命名CAPABILITY、IS-IS定義します。上記アプリケーションは、この文書で定義されたCAPABILITYのTLVの中で運ば新しいサブのTLVの仕様を必要とします。
Definition of these sub-TLVs is outside the scope of this document.
これらのサブのTLVの定義は、この文書の範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC-2119]に記載されているように解釈されます。
The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 1 octet that specifies the number of bytes in the value field, and a variable length value field that starts with 4 octets of Router ID, indicating the source of the TLV, and followed by 1 octet of flags.
IS-ISルータCAPABILITY TLVは、TLVのソースを示すタイプの1つのオクテット、値フィールドのバイト数を指定する1つのオクテット、およびルータIDの4つのオクテットから始まる可変長値フィールドから構成されています、およびフラグの1つのオクテットが続きます。
A set of optional sub-TLVs may follow the flag field. Sub-TLVs are formatted as described in RFC 3784 [IS-IS-TE].
任意のサブのTLVのセットは、フラグフィールドに従うことができます。サブTLVのRFC 3784に記載されているように[IS-IS-TE]フォーマットされます。
TYPE: 242 LENGTH: from 5 to 255 VALUE: Router ID (4 octets) Flags (1 octet) Set of optional sub-TLVs (0-250 octets)
TYPE：242 LENGTH：5から255の値に：オプションサブTLVの（0-250オクテット）のルータID（4つのオクテット）フラグ（1つのオクテット）セット
Flags
国旗
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |D|S|
+-+-+-+-+-+-+-+-+
Currently two bit flags are defined.
現在、2ビットのフラグが定義されています。
S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV MUST be flooded across the entire routing domain. If the S bit is not set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking.
Sビットは（0×01）：Sビットは（1）設定されている場合、IS-ISルータCAPABILITY TLV全体のルーティングドメイン全体にフラッディングされなければなりません。 Sビットは（0）に設定されていない場合、TLVは、レベル間漏洩してはいけません。このビットは、TLVの漏洩時に変更しないでください。
D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from level-2 to level-1, the D bit MUST be set. Otherwise, this bit MUST be clear. IS-IS Router capability TLVs with the D bit set MUST NOT be leaked from level-1 to level-2. This is to prevent TLV looping.
Dビット（0×02）：IS-ISルータCAPABILITY TLVがレベル2からレベル1に漏洩される場合、Dビットを設定しなければなりません。それ以外の場合、このビットは明確でなければなりません。 Dビットが設定されたルータの能力のTLVは、レベル2にレベル1から漏洩してはいけません-ISです。これは、TLVのループを防ぐためです。
The Router CAPABILITY TLV is OPTIONAL. As specified in Section 3, more than one Router CAPABILITY TLV from the same source MAY be present.
ルータ機能TLVはOPTIONALです。セクション3で指定されるように、同じソースから複数のルータ機能TLVが存在してもよいです。
This document does not specify how an application may use the Router Capability TLV and such specification is outside the scope of this document.
この文書では、ルータ能力TLV及びそのような仕様を使用することができるアプリケーションがこの文書の範囲外である方法を指定しません。
A router that generates a CAPABILITY TLV MUST have a Router ID that is a 32-bit number. The ID MUST be unique within the IS-IS area. If the router generates any capability TLVs with domain flooding scope, then the ID MUST also be unique within the IS-IS routing domain.
TLVは、32ビットの数値であり、ルータIDを持たなければならない機能を生成するルータ。 IDは、IS-ISエリア内で一意でなければなりません。ルータは、ドメインの氾濫範囲を持つ任意の能力TLVを生成した場合、IDはまた、IS-ISルーティングドメイン内で一意でなければなりません。
When advertising capabilities with different flooding scopes, a router MUST originate a minimum of two Router CAPABILITY TLVs, each TLV carrying the set of sub-TLVs with the same flooding scope. For instance, if a router advertises two sets of capabilities, C1 and C2, with an area/level scope and routing domain scope respectively, C1 and C2 being specified by their respective sub-TLV(s), the router will originate two Router CAPABILITY TLVs:
異なるフラッディングスコープと機能をアドバタイズすると、ルータは、二つのルータCAPABILITYのTLV、同一の氾濫範囲を有するサブTLVのセットを運ぶ各TLVの最小値を発信しなければなりません。ルータは、それぞれの領域/レベル範囲およびルーティングドメイン範囲と能力、C1とC2の二組をアドバタイズした場合、例えば、C1及びC2は、それぞれのサブTLV（S）で指定され、ルータは、二つのルータ機能を発信しますTLV：
- One Router CAPABILITY TLV with the S flag cleared, carrying the sub-TLV(s) relative to C1. This Router CAPABILITY TLV will not be leaked into another level.
- 一つのルータCAPABILITY TLV SフラグとC1サブTLV（S）相対を運ぶ、クリア。このルータ機能TLVは別のレベルに漏洩することはありません。
- One Router CAPABILITY TLV with the S flag set, carrying the sub-TLV(s) relative to C2. This Router CAPABILITY TLV will be leaked into other IS-IS levels. When the TLV is leaked from level-2 to level-1, the D bit will be set in the level-1 LSP advertisement.
- C2サブTLV（S）相対搬送Sフラグが設定された一つのルータ能力TLV、。このルータ機能TLVは、他のIS-ISレベルに漏洩するでしょう。 TLVは、レベル1にレベル2から漏れている場合、Dビットは、レベル1 LSPの広告に設定されます。
In order to prevent the use of stale capabilities, a system MUST NOT use a Capability TLV present in an LSP of a system that is not currently reachable via Level-x paths, where "x" is the level (1 or 2) in which the sending system advertised the TLV. This requirement applies regardless of whether or not the sending system is the originator of the Capabilities TLV. Note that leaking a Capabilities TLV is one of the uses that is prohibited under these conditions.
古くなった機能の使用を防止するために、システムは、「x」はレベルであるレベルのXパスを介して現在到達できないシステムのLSP（1又は2）での機能TLVの存在を使用してはいけません送信側システムは、TLVを宣伝しました。この要件は関係なく、送信側システムは、機能のTLVの創始者であるかどうかの適用されます。機能のTLVをリークすることは、これらの条件の下で禁止されている用途の一つであることに注意してください。
Example: If Level-1 router A generates a Capability TLV and floods it to two L1/L2 routers, S and T, they will flood it into the Level-2 domain. Now suppose the Level-1 area partitions, such that A and S are in one partition and T is in another. IP routing will still continue to work, but if A now issues a revised version of the CAP TLV, or decides to stop advertising it, S will follow suit, but T will continue to advertise the old version until the LSP times out.
例：レベル1ルータAは、能力TLVと2 L1 / L2ルータ、SおよびTに洪水それを生成した場合、彼らはレベル2のドメインにそれをフラッディングします。今AとSを1つのパーティション内にあり、Tは別であるように、レベル1の領域のパーティションを仮定します。 IPルーティングはまだ動作し続けますが、今CAP TLVの改訂版を発行し、またはそれをアドバタイズを停止することを決定した場合、Sは追随しますが、Tは、LSPがタイムアウトするまで、古いバージョンを宣伝していきます。
Routers in other areas have to choose whether to trust T's copy of A's capabilities or S's copy of A's information and, they have no reliable way to choose. By making sure that T stops leaking A's information, this removes the possibility that other routers will use stale information from A.
他の地域内のルータには、Aの能力のTのコピーまたはAの情報のSのコピーを信頼するかどうかを選択しなければならないと、彼らが選択する信頼できる方法がありません。 TはAの情報漏洩を停止することを確認することで、これは他のルータは、Aから古い情報を使用する可能性を取り除きます
In IS-IS, the atomic unit of the update process is a TLV -- or more precisely, in the case of TLVs that allow multiple entries to appear in the value field (e.g., IS-neighbors), the atomic unit is an entry in the value field of a TLV. If an update to an entry in a TLV is advertised in an LSP fragment different from the LSP fragment associated with the old advertisement, the possibility exists that other systems can temporarily have either 0 copies of a particular advertisement or 2 copies of a particular advertisement, depending on the order in which new copies of the LSP fragment that had the old advertisement and the fragment that has the new advertisement arrive at other systems.
IS-ISは、更新処理の原子単位は、TLV - またはより正確には、複数のエントリ（例えば、-近隣IS）値フィールドに表示することを可能にするのTLVの場合には、原子単位でのエントリでありますTLVの値フィールドに入力します。 TLV内のエントリへの更新が古い広告に関連するLSPフラグメント異なるLSPフラグメントでアドバタイズされた場合、可能性は、他のシステムが一時的に特定の広告の0コピーまたは特定の広告の2つのコピーのいずれかを有することができること存在します古い広告を持っていたLSPフラグメントと新しい広告を持っているフラグメントの新しいコピーを他のシステムに到着した順序に依存します。
Wherever possible, an implementation SHOULD advertise the update to a capabilities TLV in the same LSP fragment as the advertisement that it replaces. Where this is not possible, the two affected LSP fragments should be flooded as an atomic action.
可能な限り、実装はそれが置き換わることを広告と同じLSPフラグメントにおける機能のTLVへの更新を宣伝すべきです。これが不可能な場合、2つの影響を受けるLSPフラグメントは、アトミックアクションとして浸水する必要があります。
Systems that receive an update to an existing capability TLV can minimize the potential disruption associated with the update by employing a holddown time prior to processing the update so as to allow for the receipt of multiple LSP fragments associated with the same update prior to beginning processing.
既存の能力TLVへの更新を受信するシステムは、ホールドダウン時間を使用前に処理を開始する前に同一の更新に関連する複数のLSPフラグメントの受信を可能にするように更新を処理することによって、更新に関連する潜在的な混乱を最小限に抑えることができます。
Where a receiving system has two copies of a capabilities TLV from the same system that have different settings for a given attribute, the procedure used to choose which copy shall be used is undefined.
受信システムは、特定の属性ごとに異なる設定を持つ同一のシステムから機能TLVの2つのコピーを持っている場合は、使用しなければならないそのコピーを選択するために使用手順が定義されていません。
Routers that do not support the Router CAPABILITY TLV MUST silently ignore the TLV(s) and continue processing other TLVs in the same LSP. Routers that do not support specific sub-TLVs carried within a Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and continue processing those sub-TLVs that are supported in the Router CAPABILITY TLV. How partial support may impact the operation of the capabilities advertised within the Router CAPABILITY TLV is outside the scope of this document.
ルータ機能をサポートしていないルータは、TLVは黙って（S）TLVを無視し、同じLSP内の他のTLVの処理を継続しなければなりません。特定のサブTLVをサポートしていないルータは、TLVが静かにサポートされていないサブTLVを無視し、ルータ機能TLVでサポートされているそれらのサブTLVの処理を継続しなければならないルータの能力の範囲内で実施しました。どのように部分的なサポートは、TLVは、このドキュメントの範囲外であるルータの能力の範囲内で宣伝機能の動作に影響を与える可能性があります。
In order for Router CAPABILITY TLVs with domain-wide scope originated by L1 Routers to be flooded across the entire domain, at least one L1/L2 Router in every area of the domain MUST support the Router CAPABILITY TLV.
L1ルータによって発信ドメイン全体のスコープを持つルータ機能TLVのためのルータ機能TLVをサポートしなければならない領域のすべての領域に少なくとも一つのL1 / L2ルータ、ドメイン全体にフラッディングされます。
If leaking of the CAPABILITY TLV is required, the entire CAPABILITY TLV MUST be leaked into another level even though it may contain some of the unsupported sub-TLVs.
CAPABILITY TLVの漏れが必要な場合は、全体CAPABILITY TLVは、それがサポートされていないサブのTLVの一部を含んでいても、別のレベルに漏洩しなければなりません。
Any new security issues raised by the procedures in this document depend upon the opportunity for LSPs to be snooped and modified, the ease/difficulty of which has not been altered. As the LSPs may now contain additional information regarding router capabilities, this new information would also become available to an attacker. Specifications based on this mechanism need to describe the security considerations around the disclosure and modification of their information. Note that an integrity mechanism, such as the one defined in [RFC-3567] or [IS-IS-HMAC], should be applied if there is high risk resulting from modification of capability information.
このマニュアルの手順で発生したすべての新しいセキュリティ上の問題が詮索して修正するのLSPのための機会に依存し、のしやすさ/難易度が変更されていません。 LSPは今ルータ機能に関する追加情報が記載されているように、この新しい情報は、攻撃者に利用可能になるでしょう。このメカニズムに基づいた仕様は、自分の情報の開示や変更に関するセキュリティ上の考慮事項を記述する必要があります。能力情報の変更に起因する高いリスクがある場合、このような[RFC-3567]で定義された1つまたは[IS-IS-HMAC]として完全性機構は、適用されるべきであることに留意されたいです。
IANA assigned a new IS-IS TLV code-point for the newly defined IS-IS TLV type named the IS-IS Router CAPABILITY TLV and defined in this document. The assigned value is 242.
IANAが割り当てられ、新たに定義されたIS-IS TLVのタイプの新しいIS-IS TLVコードポイントは、IS-ISルータ機能のTLVを命名し、この文書で定義されます。割り当てられた値は242です。
The authors would like to thank Jean-Louis Le Roux, Paul Mabey, Andrew Partan, and Adrian Farrel for their useful comments.
作者は彼らの役に立つコメントをジャン=ルイ・ル・ルー、ポールMabey、アンドリューPartan、およびエードリアンファレルに感謝したいと思います。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[IS-IS] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO 10589.
[IS-IS]「中間システム中間にシステムドメイン内のRouteing交換プロトコル接続モード・ネットワーク・サービス（ISO 8473）の提供のための議定書と併せて使用する」、ISO 10589を。
[RFC-3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
[RFC-3567]のLi、T.及びR.アトキンソン、 "中間システム（IS-IS）暗号化認証に中間システム"、RFC 3567、2003年7月。
[IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[IS-IS-IP] Callon、R.、 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためにIS-IS"、RFC 1195、1990年12月。
[IS-IS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[IS-IS-TE]スミット、H.、およびT.李、 "中間システムへの中間システムは、（IS-IS）トラフィックエンジニアリング（TE）のための拡張機能"、RFC 3784、2004年6月。
[AUTOMESH] Vasseur, JP., Ed., Le Roux, JL., Ed., Yasukawa, S., Previdi, S., Psenak, P., and P. Mabbey, "Routing extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972, July 2007.
【AUTOMESH] Vasseur、JP。、編、ルルー、JL。、編、安川、S.、Previdi、S.、Psenak、P.、およびP. Mabbey、「マルチプロトコルの発見のためのルーティング拡張（MPLS）ラベルスイッチルータ（LSR）トラフィックエンジニアリング（TE）メッシュメンバーシップ」、RFC 4972、2007年7月。
[TE-NODE-CAP] Vasseur, JP., Ed., and J.L. Le Roux, "Routing Extensions for Discovery of Traffic Engineering Node Capabilities", Work in Progress, April 2007.
[TE-NODE-CAP] Vasseur、JP。、エド。、およびJ.L.ル・ルー、 "トラフィックエンジニアリングノード能力の発見のためのルーティング拡張機能"、進歩、2007年4月に作業。
[P2MP] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
。。。[P2MP]アガルワルは、R.、エド、Papadimitriou、D.、エド、およびS.安川、エドは、「機能拡張は、予約プロトコルをリソースへ - トラフィックエンジニアリング（RSVP-TE）をラベルスイッチドポイント・ツー・マルチポイントTEのためにパス（LSPを）」、RFC 4875、2007年5月。
[P2MP-REQS] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[P2MP-REQS]は安川、S.、エド。、2006 4月には、RFC 4461、 "ポイントツーマルチポイントトラフィック・エンジニアMPLSラベルのためのシグナリング要件は、スイッチパス（LSP）"。
[IS-IS-HMAC] Bhatia, M., Ed. and V. Manral, Ed., "IS-IS Generic Cryptographic Authentication", Work in Progress, May 2007.
[IS-IS-HMAC] Bhatiaは、M.、エド。そして、V. Manral、エド。、 "IS-ISジェネリック暗号認証"、進歩、2007年5月での作業。
Authors' Addresses
著者のアドレス
Jean-Philippe Vasseur CISCO Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: jpv@cisco.com
ジャン=フィリップVasseurシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA電子メール：jpv@cisco.com
Stefano Previdi CISCO Systems, Inc. Via Del Serafico 200 00142 - Roma ITALY EMail: sprevidi@cisco.com
sprevidi@cisco.com：ローマイタリアメール - スティーブンは、Cisco Systems、Inc.のヴィアデルセラフィック200 00142予感しました
Mike Shand Cisco Systems 250 Longwater Avenue, Reading, Berkshire, RG2 6GB UK EMail: mshand@cisco.com
マイク・シャンドシスコシステムズ250 Longwaterアベニュー、読書、バークシャー、RG2 6ギガバイト英国のEメール：mshand@cisco.com
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, Ca. 95035 USA EMail: ginsberg@cisco.com
レ・ギンズバーグシスコシステムズ510マッカーシーブルバードミルピタス、カリフォルニア95035 USA Eメール：ginsberg@cisco.com
Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519 USA EMail: acee@redback.com
ACEE Lindemレッドバック・ネットワーク102 Carricベンド裁判所カリー、NC 27519 USA電子メール：acee@redback.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: naiming@cisco.com
Naimingシェンシスコシステムズ225西タスマン・ドライブサンノゼ、CA 95134 USA電子メール：naiming@cisco.com
Rahul Aggarwal Juniper Networks 1194 N. Mathilda Avenue San Jose, CA 94089 USA EMail: rahul@juniper.net
ラウール・アガーウォールジュニパーネットワークスの1194 N.マチルダアベニューサンノゼ、CA 94089 USA電子メール：rahul@juniper.net
Scott Shaffer EMail: sshaffer@bridgeport-networks.com
スコット・シェイファーEメール：sshaffer@bridgeport-networks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、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機能のための基金は現在、インターネット協会によって提供されます。