[要約] RFC 5130は、IS-ISプロトコルでのポリシーコントロールメカニズムを提案しており、管理タグを使用してネットワークリソースの制御を可能にすることを目的としています。
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
IS-ISのポリシー制御メカニズムは、管理タグを使用しています
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プロトコルの拡張機能を説明して、IS-ISドメイン内のIPプレフィックス分布の管理と制御を容易にする運用機能を追加します。このドキュメントは、ポリシー使用のためにリンク状態プロトコル（LSP）データユニットに中間システム（IS）が配置できる情報を拡張することにより、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プロトコル[ISO10589]を使用して、IS-ISドメイン全体でIPv4プレフィックスリーチビリティ情報を配布することができます。さらに、[RFC5120]および[ISIS-IPV6]で作成された拡張機能のおかげで、IS-ISは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].
[RFC3784]で指定されているように、[RFC3784]で指定されているTLV 135および[RFC5120]で定義されているTLV 235で追加情報が掲載されているIPv4プレフィックス情報は、[RFC1195]のTLVタイプ128および130としてエンコードされています。特に、拡張されたIPリーチビリティTLV（TLV 135）には、より大きなメトリック空間、アップ/ダウンビットのサポートが含まれています。プレフィックスに関する特定の情報を伝達するには。TLV 235はTLV 135の導関数であり、多物学的メンバーシップ情報[RFC5120]が追加されています。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.
このドキュメントでは、IPプレフィックスに関する管理情報を携帯するために使用できるTLV 135、TLV 235、TLV 236、およびTLV 237の2つの新しいサブ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 BCP 14, [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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 135、TLV 235、TLV 236、TLV 237に追加する2つの新しい「管理タグ」サブTLVを作成します。これらのTLVは、IPプレフィックスに関連付けられる可能性のある1つまたは複数の32または64ビットの符号なし整数を指定します。。これらのタグの例には、BGP標準（または拡張）コミュニティを運ぶこと、レベルとエリア間の再分配の制御、異なるルーティングプロトコル、または同じルーターで実行されているIS-Iの複数のインスタンスが含まれます。
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.
Sub-TLVのエンコードについては、以下のサブセクションで説明します。
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]でSub-TLV 1を使用して、1つまたは複数の4-OCTETの非署名整数としてエンコードされます。管理タグSub-TLVには次の構造があります。
o 1 octet of type (value: 1)
o タイプの1オクテット（値：1）
o 1 octet of length (value: multiple of 4)
o 長さの1オクテット（値：4の倍数）
o one or more instances of 4 octets of administrative tag
o 管理タグの4オクテットの1つ以上のインスタンス
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]でSub-TLV 2を使用して、1つまたは複数の8-OCTETの非署名整数としてエンコードされます。64ビットの管理タグSub-TLVには、次の構造があります。
o 1 octet of type (value: 2)
o タイプの1オクテット（値：2）
o 1 octet of length (value: multiple of 8)
o 長さの1オクテット（値：8の倍数）
o one or more instances of 8 octets of administrative tag
o 管理タグの8オクテットの1つ以上のインスタンス
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.
タグ順序のセマンティクスは実装依存です。つまり、タグの順序に基づいて特定の操作または一連の操作を実行する必要があることを示すタグの順序付けに暗黙の意味はありません。各タグは、ポリシーアクションを実行するためにポリシーで使用できる自律識別子として扱う必要があります。タグAが先行するか成功するかどうかは、タグセットの意味を変更しないでください。ただし、レベル間に複数のタグを含む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.
それぞれが、Sub-TLV 1および/または2に関連するTLV（S）135および/または235および/または236および/または237のLSPを受け取っていることが、[実装。実装でタグ値を変更する必要がある場合、たとえば、エリア境界でレベル間でTLVを伝播する場合、TLV（S）を新しく生成されたレベル1またはレベル2 LSPにコピーする必要があります。その時点で、サブTLVの内容は、ポリシーアクションによって決定されるように変化する可能性があります。変更が不要な場合は、順序付けが維持されるように、Sub-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.
準拠したIS-IS実装は、次のTLVのいずれかのIPプレフィックスに1つのタグを割り当てることができなければなりません：TLV 135、TLV 235、TLV 236、TLV 237。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。Sub-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を伝播する場合、準拠したIS-IS実装は、次のTLVのいずれかのプレフィックスに関連付けられた1つまたは複数のタグを書き換えるか、削除できる場合があります：TLV 135、TLV 235、TLV 236、TLV 237。
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プレフィックスのReachabilityを広告すると、そのプレフィックスのIPリーチ可能性情報TLVに管理タグを追加し、タグはルーティングドメイン全体に浸水しているときにプレフィックスに「スティック」します。
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.
図1のネットワークを考えてみましょう。L2からL1ルーターR1までのプロパティAを使用して、L1プレフィックス[RFC2966]を「リーク」します。ポリシーグループがなければ、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".
管理タグ100をプロパティAに関連付け、R5にその値をIPに拡張された到達可能性情報TLVに接続すると、プレフィックス1.1.2.0/24を付けます。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.
単一のタグのみをサポートする実装と複数のタグをサポートする実装は、同じIS-ISドメインで共存する場合があります。したがって、複数のタグをサポートする実装は、すべてのシステムで解釈する必要があるタグを、複数のタグのセットの最初のタグとして割り当てる必要があります。
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の新しいセキュリティの問題を提起しません。このような手当は、一般的にはインテリアゲートウェイプロトコルの精神に違反します。
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は、「1」を32ビット管理タグSub-TLVおよび「2」のタイプコードとして64ビット管理タグSub-TLVのタイプコードとして割り当てました。
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.
著者は、この新しい情報を説明するのに最適な場所、この文書に関する有用なコメントについてはTony LiとTony Przygienda、Danny McPhersonが必要なフォーマット支援について説明してくれたことを明確にしてくれたHenk Smitに感謝したいと思います。
Brad Neal contributed portions of this document.
Brad Nealは、この文書の一部を提供しました。
[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.
[ISO10589]国際標準化機関、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと併用するための中間システムから中間システムへの中間システムへの中間システム内部システム内情報交換プロトコル」、ISO/ IEC 10589：2002、2番目版、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。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ISIS-IPv6] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress, October 2007.
[ISIS-IPV6] HOPPS、C。、「IS-ISを使用した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] Li、T.、Przygienda、T。、およびH. Smit、「2レベルのIS-ISを備えたドメイン全体の接頭分布」、RFC 2966、2000年10月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、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.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）Routing in IS-IS」、RFC 5120、2008年2月。
Authors' Addresses
著者のアドレス
Stefano Previdi Cisco Systems Via Del Serafico, 200 00142 Rome, Italy
Stefano Previdi Cisco Systems Del Serafico、200 00142ローマ、イタリア
EMail: sprevidi@cisco.com
Mike Shand (editor) Cisco Systems 250, Longwater Avenue. Reading, Berks RG2 6GB UK
Mike Shand（編集者）Cisco Systems 250、Longwater Avenue。読書、バークスRG2 6GB UK
Phone: +44 208 824 8690
EMail: mshand@cisco.com
Christian Martin iPath Services
クリスチャン・マーティン・アイパスサービス
EMail: chris@ipath.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
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への情報をお問い合わせください。