Network Working Group S. Previdi
Request for Comments: 5130 M. Shand, Ed.
Category: Standards Track Cisco Systems
C. Martin
iPath Services
February 2008
A Policy Control Mechanism in IS-IS Using Administrative Tags
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains.
この文書では、IS-ISドメイン内のIPプレフィックス配布を介して管理および制御を容易にするためにできるよう運用能力を追加することですが、-ISプロトコルの拡張について説明します。この文書では、ルータがポリシーで使用するためのリンクステートプロトコル（LSP）データユニットに配置することができます中間システム（IS）という情報を拡張することにより、IS-ISプロトコル強化します。この拡張は、マルチレベルのドメイン-ISを通じてIPプレフィックス分布を制御する機構をオペレータに提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. Sub-TLV Additions . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. 32-bit Administrative Tag Sub-TLV 1 . . . . . . . . . . . . 3
3.2. 64-bit Administrative Tag Sub-TLV 2 . . . . . . . . . . . . 3
4. Ordering of Tags . . . . . . . . . . . . . . . . . . . . . . . 3
5. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9. Manageability Considerations . . . . . . . . . . . . . . . . . 5
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
12.1. Normative References . . . . . . . . . . . . . . . . . . . 6
12.2. Informative References . . . . . . . . . . . . . . . . . . 6
As defined in [RFC1195] and extended in [RFC3784], the IS-IS protocol [ISO10589] may be used to distribute IPv4 prefix reachability information throughout an IS-IS domain. In addition, thanks to extensions made in [RFC5120] and [ISIS-IPv6], IS-IS may be used to distribute IPv6 reachability information.
[RFC1195]で定義されて、[RFC3784]に拡張されるようにドメインを、ISを通じて、IS-ISプロトコル[ISO10589]はIPv4のプレフィックス到達可能性情報を配布するために使用することができます。また、[RFC5120]で作ら拡張および[ISIS-のIPv6]のおかげで、ISISは、IPv6到達可能性情報を配布するために使用することができます。
The IPv4 prefix information is encoded as TLV type 128 and 130 in [RFC1195], with additional information carried in TLV 135 as specified in [RFC3784] and TLV 235 as defined in [RFC5120]. In particular, the extended IP Reachability TLV (TLV 135) contains support for a larger metric space, an up/down bit to indicate redistribution between different levels in the hierarchy, an IP prefix, and one or more sub-TLVs that can be used to carry specific information about the prefix. TLV 235 is a derivative of TLV 135, with the addition of Multi-Topology membership information [RFC5120]. The IPv6 prefix information is encoded as TLV 236 in [ISIS-IPv6], and TLV 237 in [RFC5120].
IPv4のプレフィックス情報は[RFC5120]で定義されるように[RFC3784]及びTLV 235で指定されるようにTLV 135で運ば追加情報で、[RFC1195]でTLVタイプ128および130として符号化されます。具体的には、拡張IP到達可能性TLV（TLV 135）を使用することができる階層内の異なるレベル間の再分配、IPプレフィックス、及び1つ以上のサブTLVを示すために、より大きな距離空間、アップ/ダウンビットのサポートが含まれていプレフィックスに関する特定の情報を運ぶために。 TLV 235は、マルチトポロジ・メンバーシップ情報[RFC5120]を添加して、TLV 135の誘導体です。 IPv6プレフィックス情報は、[ISIS-のIPv6]でTLV 236、および[RFC5120]にTLV 237として符号化されます。
This document defines 2 new sub-TLVs for TLV 135, TLV 235, TLV 236 and TLV 237 that may be used to carry administrative information about an IP prefix.
この文書は、TLV 135、TLV 235のために2つの新しいサブTLVを定義TLV 236とTLV 237 IPプレフィックスに関する管理情報を搬送するために使用することができます。
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, [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、[RFC2119]に記載されているように解釈されます。
This document creates 2 new "Administrative Tag" sub-TLVs to be added to TLV 135, TLV 235, TLV 236 and TLV 237. These TLVs specify one or more 32- or 64-bit unsigned integers that may be associated with an IP prefix. Example uses of these tags include carrying BGP standard (or extended) communities and controlling redistribution between levels and areas, different routing protocols, or multiple instances of IS-IS running on the same router.
この文書では、これらのTLVは、IPプレフィックスに関連付けることができる1つまたは複数の32ビットまたは64ビットの符号なし整数を指定TLV 135、TLV 235、TLV 236とTLV 237に追加される2つの新しい「管理タグ」サブTLVを作成します。例としては、BGP標準（または拡張）コミュニティを運ぶとレベルと領域、異なるルーティングプロトコル、またはIS-ISは、同じルータ上で動作している複数のインスタンス間で再分配を制御するこれらのタグの使用します。
The methods for which their use is employed is beyond the scope of this document and left to the implementer and/or operator.
それらの使用が採用されている方法は、この文書の範囲外であると実施者及び/又はオペレータに委ね。
The encoding of the sub-TLV(s) is discussed in the following subsections.
サブTLV（S）の符号化は、以下のサブセクションで説明されています。
The Administrative Tag SHALL be encoded as one or more 4-octet unsigned integers using Sub-TLV 1 in TLV 135 [RFC3784], TLV 235 [RFC5120], TLV 236 [ISIS-IPv6], and TLV 237 [RFC5120]. The Administrative Tag Sub-TLV has following structure:
管理タグは、TLV 135 [RFC3784]、TLV 235 [RFC5120]、TLV 236 [ISIS-のIPv6]、及びTLV 237 [RFC5120]にサブTLV 1を使用して、1つ以上の4オクテットの符号なし整数として符号化されます。管理タグサブTLVの構造は次のとおりです。
o 1 octet of type (value: 1)
タイプの1つのオクテットをO（値：1）
o 1 octet of length (value: multiple of 4)
長さ1つのオクテット（4の倍数値）O-
o one or more instances of 4 octets of administrative tag
管理タグの4つのオクテットの1つ以上のインスタンスO
On receipt, an implementation MAY consider only one encoded tag, in which case, the first encoded tag MUST be considered and any additional tags ignored. A tag value of zero is reserved and SHOULD be treated as "no tag".
領収書には、実装は、第1の符号化されたタグが考えなければなりませんし、任意の追加のタグが無視された場合には、一つだけエンコードされたタグを考慮することができます。ゼロのタグ値が予約されており、「タグなし」として扱われるべきです。
The Administrative Tag SHALL be encoded as one or more 8-octet unsigned integers using Sub-TLV 2 in TLV 135 [RFC3784], TLV 235 [RFC5120], TLV 236 [ISIS-IPv6], and TLV 237 [RFC5120]. The 64-bit Administrative Tag Sub-TLV has following structure:
管理タグは、TLV 135 [RFC3784]、TLV 235 [RFC5120]、TLV 236 [ISIS-のIPv6]、及びTLV 237 [RFC5120]サブTLV 2を使用して、1つ以上の8オクテットの符号なし整数として符号化されます。 64ビットの管理タグサブTLVは、以下の構造を有しています。
o 1 octet of type (value: 2)
タイプの1つのオクテット（2値）O-
o 1 octet of length (value: multiple of 8)
長さ1つのオクテット（8の倍数値）O-
o one or more instances of 8 octets of administrative tag
管理タグの8つのオクテットの1つ以上のインスタンスO
On receipt, an implementation MAY consider only one encoded tag; in which case, the first encoded tag MUST be considered and any additional tags ignored. A tag value of zero is reserved and SHOULD be treated as "no tag".
領収書には、実装は一つだけエンコードされたタグを考慮することができます。その場合には、第1の符号化されたタグがあると考えられ、任意の追加のタグは無視しなければなりません。ゼロのタグ値が予約されており、「タグなし」として扱われるべきです。
The semantics of the tag order are implementation-dependent. That is, there is no implied meaning to the ordering of the tags that indicates a certain operation or set of operations need be performed based on the order of the tags. Each tag SHOULD be treated as an autonomous identifier that MAY be used in policy to perform a policy action. Whether or not tag A precedes or succeeds tag B SHOULD not change the meaning of the tag set. However, when propagating TLVs that contain multiple tags between levels, an implementation SHOULD preserve the ordering such that the first tag remains the first tag, so that implementations that only recognize a single tag will have a consistent view across levels.
タグの順序のセマンティクスは実装依存です。それは、特定の操作を指示またはタグの順序に基づいて実行される操作を必要とし、タグの順序への暗黙の意味がありません、です。各タグは、ポリシー・アクションを実行するポリシーで使用されるかもしれ自律識別子として扱われるべきです。先行または成功したタグBをタグ付けするかどうかは、タグセットの意味を変更しないでください。レベル間の複数のタグを含むTLVを伝播するときただし、実装は、単一のタグを認識実装がレベル間で一貫したビューを有するように最初のタグは、最初のタグのままであるように順序を維持すべきです。
Each IS that receives an LSP with TLV(s) 135 and/or 235 and/or 236 and/or 237, that have associated sub-TLV(s) 1 and/or 2, MAY operate on the tag values as warranted by the implementation. If an implementation needs to change tag values, for example, when propagating TLVs between levels at an area boundary, then the TLV(s) SHOULD be copied to the newly generated Level-1 or Level-2 LSP. At that point, the contents of the sub-TLV(s) MAY change as dictated by the policy action. In the event that no change is required, the sub-TLV(s) SHOULD be copied in order into the new LSP, such that ordering is preserved.
それぞれ、によって保証されるよう、そのタグ値に動作することができるサブTLV（S）1および/または2に関連しているTLV（S）135及び/又は235及び/又は236及び/又は237とのLSPを、受け取ります実装。実装エリア境界でのレベルとの間のTLVを伝播する際に、例えば、タグ値を変更する必要がある場合、TLV（s）は、新たに生成されたレベル1またはレベル2 LSPにコピーする必要があります。ポリシーアクションにより指示されるように、その時点で、サブTLV（S）の内容が変化してもよいです。変更が不要である場合には、サブTLV（単数または複数）の順序が保存されるように、新しいLSPに順番にコピーする必要があります。
A compliant IS-IS implementation MUST be able to assign one tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV 236, TLV 237. It MUST be able to interpret a single tag present in the sub-TLV, or the first tag where there is more than one tag present in the sub-TLV.
サブに存在する単一のタグを解釈できなければならないTLV 135、TLV 235、TLV 236、TLV 237：準拠した実装は、次のTLVのいずれかに任意のIPプレフィックスに1個のタグを割り当てることができなければならない-IS TLV、またはサブTLVに複数のタグが存在する最初のタグ。
A compliant IS-IS implementation MAY be able to assign more than one tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV 236, TLV 237. It MAY be able to interpret the second and subsequent tags where more than one tag is present in the sub-TLV.
対応は、IS-ISの実装は次のTLVのいずれかにおける任意のIPプレフィックスに複数のタグを割り当てることができる場合があります。TLV 135、TLV 235、TLV 236、TLV 237は、どこ目以降のタグを解釈することができるかもしれません複数のタグは、サブTLVに存在します。
When propagating TLVs between levels, a compliant IS-IS implementation MAY be able to rewrite or remove one or more tags associated with a prefix in any of the following TLVs: TLV 135, TLV 235, TLV 236, TLV 237.
TLV 135、TLV 235、TLV 236、TLV 237：レベル間のTLVを伝播するときに、対応の実装は、次のTLVのいずれかでプレフィックスに関連付けられた1つまたは複数のタグを書き換える、または削除することができMAY-です。
An administrator associates an Administrative Tag value with some interesting property. When IS-IS advertises reachability for some IP prefix that has that property, it adds the Administrative Tag to the IP reachability information TLV for that prefix, and the tag "sticks" to the prefix as it is flooded throughout the routing domain.
管理者は、いくつかの興味深い性質を持つ管理タグ値を関連付けます。 IS-ISは、ときにそれがルーティングドメイン全体にフラッディングされるプロパティは、それがその接頭語のためのIP到達可能性情報TLVへの管理タグ、および接頭辞にタグ「スティック」を追加することを持っているいくつかのIPプレフィックスの到達可能性をアドバタイズします。
Consider the network in Figure 1. We wish to "leak" L1 prefixes [RFC2966] with some property, A, from L2 to the L1 router R1. Without policy groups, there is no way for R2 to know property A prefixes from property B prefixes.
我々は、L2からL1ルータR1に、いくつかのプロパティ、Aと「リーク」L1プレフィックス[RFC2966]をしたい図1のネットワークを考えます。ポリシー・グループがなければ、R2は、プロパティBプレフィックスからプロパティAプレフィックスを知る方法はありません。
R2--------R3--------R4
L2 / \
- - - /- - - - - - - - - - - - - -
L1 / \
R1----1.1.1.0/24 (A) R5
|
|
1.1.2.0/24 (B)
Figure 1: Example of usage
図1：使用例
We associate Administrative Tag 100 with property A, and have R5 attach that value to the IP extended reachability information TLV for prefix 1.1.2.0/24. R2 has a policy in place to "match prefixes with Administrative Tag 100, and leak to L1".
私たちは、プロパティAで管理タグ100を関連付け、およびR5は、プレフィックス1.1.2.0/24のためにIP拡張到達可能性情報TLVにその値を添付しています。 R2は、「管理タグ100とのプレフィックスと一致し、L1に漏れ」するための場所でポリシーを持っています。
The previous example is rather simplistic; it seems that it would be just as easy for R2 simply to match the prefix 1.1.2.0/24. However, if there are a large number of routers that need to apply some policy according to property A and a large number of "A" prefixes, this mechanism can be quite helpful.
前の例では、かなり単純です。 R2は、単にプレフィックス1.1.2.0/24と一致することも同じくらい簡単だろうと思われます。プロパティAと「A」プレフィックスの大きな数に応じていくつかのポリシーを適用する必要があるルータの数が多い場合は、このメカニズムは非常に参考にすることができます。
Implementations that support only a single tag and those that support multiple tags may coexist in the same IS-IS domain. An implementation supporting multiple tags SHOULD therefore assign any tag that is required to be interpreted by all systems as the first tag in any set of multiple tags.
唯一の単一のタグをサポートし、複数のタグをサポートしているものは同じで共存することの実装は、ドメインです。したがって、複数のタグの任意のセット内の最初のタグとして、すべてのシステムによって解釈する必要がある任意のタグを割り当てる必要があり、複数のタグをサポートして実装。
This document raises no new security issues for IS-IS, as any annotations to IP prefixes should not pass outside the administrative control of the network operator of the IS-IS domain. Such an allowance would violate the spirit of Interior Gateway Protocols in general and IS-IS in particular.
この文書では、IPプレフィクスへの注釈がIS-ISドメインのネットワークオペレータの管理制御外で渡すべきではないとして、IS-ISのためにどんな新しい安全保障問題も提起しません。このような手当は、一般的に内部ゲートウェイプロトコルの精神に違反すると特にIS-IS。
IANA has assigned "1" as the type code of the 32-bit Administrative Tag Sub-TLV and "2" as the type code of the 64-bit Administrative Tag Sub-TLV.
IANAは、64ビットの管理タグサブTLVのタイプのコードとして「2」を32ビットの管理タグサブTLVのタイプのコードとして「1」が割り当てられています。
These extensions have been designed, developed, and deployed for many years and do not have any new impact on management and operation of the IS-IS protocol via this standardization process.
これらの拡張機能は、設計、開発、そして長年にわたって展開され、この標準化プロセスを通じてIS-ISプロトコルの管理・運用上の任意の新しいインパクトを持っていないされています。
The authors would like to thank Henk Smit for clarifying the best place to describe this new information, Tony Li and Tony Przygienda for useful comments on this document, and Danny McPherson for some much needed formatting assistance.
著者は、いくつかの多くの必要なフォーマットの支援のために、この文書に関する有益なコメントをこの新しい情報、トニー・リーとトニーPrzygiendaを記述するのに最適な場所を明確にし、ダニー・マクファーソンのためのヘンクスミットに感謝したいと思います。
Brad Neal contributed portions of this document.
ブラッド・ニールは、この文書の一部を拠出しました。
[ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/ IEC 10589:2002, Second Edition, Nov 2002.
「中間システムイントラドメインへの中間システムコネクションレスモードネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための情報交換プロトコルをルーティング」[ISO10589]国際標準化機構、ISO / IEC 10589：2002、第二版、2002年11月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[ISIS-IPv6] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress, October 2007.
[ISIS-のIPv6] Hoppsが、C.、 "ISISとルーティングのIPv6"、進歩、2007年10月の作業。
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[RFC2966]李、T.、Przygienda、T.、およびH.スミット、RFC 2966、2000年10月の "2レベルでドメイン全体のプレフィックス配布は-IS IS"。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング（TE）のための中間システム（IS-IS）への拡張"、RFC 3784、2004年6月。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in IS-IS", RFC 5120, February 2008.
[RFC5120] Przygienda、T.、シェン、N.、およびN. Sheth、 "M-ISIS：ISISにおけるマルチトポロジー（MT）ルーティング"、RFC 5120、2008年2月。
Authors' Addresses
著者のアドレス
Stefano Previdi Cisco Systems Via Del Serafico, 200 00142 Rome, Italy
スティーブンは、シスコシステムズヴィアデルセラフィック、200 00142ローマ、イタリアを予見しました
EMail: sprevidi@cisco.com
メールアドレス：sprevidi@cisco.com
Mike Shand (editor) Cisco Systems 250, Longwater Avenue. Reading, Berks RG2 6GB UK
マイク・シャンド（エディタ）シスコシステムズ250、Longwaterアベニュー。読書、バークスRG2 6ギガバイト英国
Phone: +44 208 824 8690 EMail: mshand@cisco.com
電話：+44 208 824 8690 Eメール：mshand@cisco.com
Christian Martin iPath Services
クリスチャン・マーティンIPATHサービス
EMail: chris@ipath.net
メールアドレス：chris@ipath.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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に情報を記述してください。