[要約] RFC 7308は、MPLS Traffic Engineering（MPLS-TE）における拡張管理グループに関する規格であり、MPLSネットワークのトラフィックエンジニアリングにおいて管理グループの機能を拡張することを目的としています。
Internet Engineering Task Force (IETF) E. Osborne
Request for Comments: 7308 July 2014
Category: Standards Track
ISSN: 2070-1721
Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)
MPLSトラフィックエンジニアリング（MPLS-TE）の拡張管理グループ
Abstract
概要
MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).
MPLSトラフィックエンジニアリング（MPLS-TE）は、管理グループサブTLVを使用して、32の管理グループ（一般に「色」または「リンクの色」と呼ばれます）を通知します。これは、OSPFv2（RFC 3630）、OSPFv3（RFC 5329）、およびIS-IS（RFC 5305）に対して定義されています。
This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.
このドキュメントでは、サブTLVをIGP TE拡張「拡張管理グループ」に追加します。このサブTLVは、現在の制限である32を超える追加の管理グループ（リンクの色）を提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7308.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7308で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Extended Administrative Groups Sub-TLV . . . . . . . . . . . 3
2.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Admin Group Numbering . . . . . . . . . . . . . . . . . . 4
2.3. Backward Compatibility . . . . . . . . . . . . . . . . . 4
2.3.1. AG and EAG Coexistence . . . . . . . . . . . . . . . 4
2.3.2. Desire for Unadvertised EAG Bits . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Do we need more than 32 bits?
32ビット以上必要ですか？
The IGP extensions to support MPLS-TE (RFCs 3630 [RFC3630] and 5305 [RFC5305]) define a link TLV known as Administrative Group (AG) with a limit of 32 AGs per link. The concept of Administrative Groups comes from Section 6.2 of RFC 2702 [RFC2702], which calls them Resource Classes. RFCs 3630 [RFC3630] and 5305 [RFC5305] describe the mechanics of the TLV and use the term Administrative Groups (sometimes abbreviated herein as AGs), as does this document.
MPLS-TEをサポートするIGP拡張機能（RFC 3630 [RFC3630]および5305 [RFC5305]）は、リンクごとに32 AGの制限を持つ管理グループ（AG）と呼ばれるリンクTLVを定義します。管理グループの概念は、リソースクラスと呼ばれるRFC 2702 [RFC2702]のセクション6.2に由来しています。 RFC 3630 [RFC3630]および5305 [RFC5305]は、TLVのメカニズムを説明し、このドキュメントと同様に、管理グループ（ここではAGと略されることもあります）という用語を使用します。
Networks have grown over time, and MPLS-TE has grown right along with them. Administrative Groups are advertised as fixed-length 32-bit bitmasks. This can be quite constraining, as it is possible to run out of values rather quickly. One such use case is #5 in Section 6.2 of RFC 2702 [RFC2702], using AGs to constrain traffic within specific topological regions of the network. A large network may well have far more than 32 geographic regions. One particular operator builds their network along the lines of this use case, using AGs to flag network regions down to the metro scale, e.g., Seattle, San Francisco, Dallas, Chicago, St. Louis, etc. MPLS-TE tunnels are then specified with affinities to include or exclude specific metro regions in their path calculation. Each metro region is given its own bit in the AG bitmask. This means that 32 bits can only (cleanly) represent 32 metro areas. It should be obvious that 32 may not be enough even for a US-based network, never mind a worldwide network.
ネットワークは時間とともに成長し、MPLS-TEもそれに伴って成長しました。管理グループは、固定長の32ビットビットマスクとしてアドバタイズされます。値がすぐに足りなくなる可能性があるため、これはかなり制約になる可能性があります。そのような使用例の1つは、RFC 2702 [RFC2702]のセクション6.2の＃5で、AGを使用してネットワークの特定のトポロジー領域内のトラフィックを制限します。大規模なネットワークには、32をはるかに超える地理的領域がある場合があります。ある特定のオペレーターは、このユースケースのラインに沿ってネットワークを構築し、AGを使用して、メトロ地域までネットワーク地域にフラグを立てます（シアトル、サンフランシスコ、ダラス、シカゴ、セントルイスなど）。次に、MPLS-TEトンネルが指定されますパス計算に特定の大都市圏を含めたり除外したりするためのアフィニティ。各大都市圏には、AGビットマスクで独自のビットが与えられます。つまり、32ビットは32のメトロエリアのみを（きれいに）表すことができます。米国を拠点とするネットワークであっても、32では十分ではない場合があることは明らかです。
There may be some opportunity for color reuse; that is, bit 0x8 may mean 'Seattle' or 'Prague' or 'Singapore' depending on the geography in which it is used. In practice, coordinating this reuse is fraught with peril and the reuse effectively becomes the limiting factor in MPLS-TE deployment. With this example, it is not possible to build a Label Switched Path (LSP) that avoids Seattle while including Prague, as it is the same AG value.
色を再利用する機会があるかもしれません。つまり、ビット0x8は、それが使用されている地域に応じて、「シアトル」、「プラハ」、または「シンガポール」を意味する場合があります。実際には、この再利用の調整は危険に満ちており、再利用はMPLS-TE展開の制限要素になります。この例では、プラハを含めながらシアトルを回避するラベルスイッチドパス（LSP）を構築することはできません。これは、同じAG値であるためです。
This document provides Extended Administrative Groups (EAGs). The number of EAGs has no fixed limit, it is constrained only by protocol-specific restrictions such as Link State Advertisement (LSA) or MTU size. While an operator may one day need to go beyond these protocol-specific restrictions, allowing for an arbitrary number of EAGs should easily provide the operator with hundreds or thousands of bit values, thus no longer making the number of AGs an impediment to network growth.
このドキュメントでは、拡張管理グループ（EAG）について説明します。 EAGの数には固定の制限はなく、リンク状態アドバタイズ（LSA）またはMTUサイズなどのプロトコル固有の制限によってのみ制約されます。オペレーターはいつかこれらのプロトコル固有の制限を超える必要があるかもしれませんが、任意の数のEAGを許可すると、オペレーターに数百または数千のビット値を簡単に提供できるため、AGの数がネットワークの成長を妨げることはなくなります。
EAG's intended use case is within a single domain. As such, this document provides no support for signaling an EAG. It provides no analog to either the SESSION_ATTRIBUTE of C-Type 1 defined in [RFC3209] nor the LSP Attributes (LSPA) object of the Path Computation Element Communication Protocol (PCEP), defined in [RFC5440]. Since this specification provides no way of signaling an LSP's path requirements in reference to the EAG, such constraints may only be applied at the ingress.
EAGの使用目的は、単一のドメイン内にあります。そのため、このドキュメントでは、EAGのシグナリングをサポートしていません。これは、[RFC3209]で定義されているCタイプ1のSESSION_ATTRIBUTEや、[RFC5440]で定義されているパス計算要素通信プロトコル（PCEP）のLSP属性（LSPA）オブジェクトに類似していません。この仕様は、EAGに関してLSPのパス要件をシグナリングする方法を提供しないため、そのような制約は入口でのみ適用できます。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document defines the Extended Administrative Group (EAG) sub-TLV for both OSPF [RFC3630] and IS-IS [RFC5305]. The EAG sub-TLV is used in addition to the Administrative Groups when an operator wants to make more than 32 colors available for advertisement in a network. The EAG sub-TLV is optional. Coexistence of EAG and AG TLVs is covered in Section 2.3.1 of this document.
このドキュメントでは、OSPF [RFC3630]とIS-IS [RFC5305]の両方の拡張管理グループ（EAG）サブTLVを定義しています。 EAGサブTLVは、管理者グループに加えて、オペレーターがネットワークで32色以上の広告を利用できるようにする場合に使用されます。 EAGサブTLVはオプションです。 EAGとAG TLVの共存については、このドキュメントのセクション2.3.1で説明しています。
This document uses the term 'colors' as a shorthand to refer to particular bits with an AG or EAG. The examples in this document use 'red' to represent the least significant bit in the AG (red == 0x1), 'blue' to represent the second bit (blue == 0x2). To say that a link has a given color or that the specified color is set on the link is to say that the corresponding bit or bits in the link's AG are set to 1.
このドキュメントでは、AGまたはEAGの特定のビットを指す省略形として「色」という用語を使用します。このドキュメントの例では、「赤」を使用してAGの最下位ビット（赤== 0x1）を表し、「青」を使用して2番目のビット（青== 0x2）を表します。リンクが特定の色を持っている、または指定された色がリンクに設定されているとは、リンクのAG内の対応するビットが1に設定されているということです。
The format of the Extended Administrative Groups sub-TLV is the same for both OSPF and IS-IS:
拡張管理グループサブTLVのフォーマットは、OSPFとIS-ISの両方で同じです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the sub-TLV for OSPF is 26 and for IS-IS is 14. The Length is the size of the Extended Admin Group (EAG) value in bytes. The EAG may be of any non-zero length, but it MUST be a multiple of 4 bytes. The only limits on EAG size are those that are imposed by protocol-specific or media-specific constraints (e.g., max packet length).
OSPFのサブTLVのタイプは26、IS-ISのタイプは14です。長さは、拡張管理グループ（EAG）のサイズ（バイト単位）です。 EAGはゼロ以外の長さでもかまいませんが、4バイトの倍数でなければなりません。 EAGサイズの唯一の制限は、プロトコル固有またはメディア固有の制約（最大パケット長など）によって課されるものです。
By convention, the existing Administrative Group sub-TLVs are numbered 0 (least significant bit) to 31 (most significant bit). The EAG values are a superset of AG. That is, bits 0-31 in the EAG have the same meaning and MUST have the same values as an AG flooded for the same link. If an EAG's length is more than 4 bytes, numbering for these additional bytes picks up where the previous byte left off. For example, the least significant bit in the fifth byte of an 8-byte EAG is referred to as bit 32.
慣例により、既存の管理グループのサブTLVには、0（最下位ビット）から31（最上位ビット）までの番号が付けられています。 EAG値はAGのスーパーセットです。つまり、EAGのビット0〜31は同じ意味を持ち、同じリンクにフラッディングされるAGと同じ値を持つ必要があります。 EAGの長さが4バイトを超える場合、これらの追加バイトの番号付けは、前のバイトが中断したところから始まります。たとえば、8バイトのEAGの5番目のバイトの最下位ビットは、ビット32と呼ばれます。
There are two questions to consider for backward compatibility with existing AG implementations -- how do AG and EAG coexist, and what happens if a node has matching criteria for unadvertised EAG bits?
既存のAG実装との下位互換性について考慮すべき2つの質問があります。AGとEAGはどのように共存し、ノードが非アドバタイズされたEAGビットの一致基準を持っている場合はどうなりますか？
If a node advertises EAG, it MAY also advertise AG.
ノードがEAGをアドバタイズする場合は、AGもアドバタイズする場合があります。
If a node advertises both AG and EAG, then the first 32 bits of the EAG MUST be identical to the advertised AG.
ノードがAGとEAGの両方をアドバタイズする場合、EAGの最初の32ビットはアドバタイズされたAGと同一である必要があります。
If both an AG and EAG are present, a receiving node MUST use the AG as the first 32 bits (0-31) of administrative color and use the EAG for bits 32 and higher, if present.
AGとEAGの両方が存在する場合、受信ノードはAGを管理色の最初の32ビット（0〜31）として使用し、存在する場合はビット32以上のEAGを使用する必要があります。
A receiving node that notices that the AG differs from the first 32 bits of the EAG SHOULD report this mismatch to the operator.
AGがEAGの最初の32ビットと異なることに気づいた受信ノードは、この不一致をオペレーターに報告する必要があります（SHOULD）。
This process allows nodes that do not support EAG to obtain some link color information from the network, while also allowing for an eventual migration away from AG.
このプロセスにより、EAGをサポートしていないノードがネットワークからリンクの色情報を取得できると同時に、AGからの最終的な移行も可能になります。
The existing AG sub-TLV is optional; thus a node may be configured with a preference to include red or exclude blue and may be faced with a link that is not advertising a value for either blue or red. What does an implementation do in this case? It shouldn't assume that red is set, but it is also arguably incorrect to assume that red is NOT set, as a bit must first exist before it can be set to 0.
既存のAGサブTLVはオプションです。したがって、ノードは赤を含むか青を除外するように設定され、青または赤の値を通知していないリンクに直面する可能性があります。この場合、実装は何をしますか？赤が設定されていると想定すべきではありませんが、赤が設定されていないと想定することは間違いなく間違いです。
Practically speaking, this has not been an issue for deployments, as many implementations always advertise the AG bits, often with a default value of 0x00000000. However, this issue may be of more concern once EAGs are added to the network. EAGs may exist on some nodes but not others, and the EAG length may be longer for some links than for others.
実際のところ、多くの実装は常にAGビットをアドバタイズし、多くの場合デフォルト値は0x00000000であるため、これはデプロイメントの問題ではありません。ただし、EAGがネットワークに追加されると、この問題はさらに懸念される可能性があります。 EAGは一部のノードにのみ存在し、他のノードには存在しない場合があります。また、EAGの長さは、一部のリンクでは他のリンクよりも長い場合があります。
To allow for maximum interoperability, an implementation SHOULD treat desired but unadvertised EAG bits as if they were set to 0. Consider the case where a node wants to only use links where the 127th bit of an EAG is set to 1. If a link is only advertising 64 EAG bits, the setting of the 127th EAG bit is not known -- that is, it is neither explicitly 0 nor 1. The node that wants the 127th EAG bit to be 1 will not use this link when implementing the recommended behavior, as the assumption is than the unadvertised 127th bit is set to 0.
最大の相互運用性を可能にするために、実装は、望ましいがアドバタイズされていないEAGビットを0に設定されているかのように扱う必要があります。ノードが、EAGの127番目のビットが1に設定されているリンクのみを使用する場合を考えます。 64 EAGビットのみをアドバタイズします。127番目のEAGビットの設定は不明です。つまり、明示的に0でも1でもありません。127番目のEAGビットを1にしたいノードは、推奨される動作を実装するときにこのリンクを使用しません。 、というのは、アドバタイズされていない127番目のビットが0に設定されているためです。
That said, each implementation makes its own choices based on necessary constraints, and there might be reasons to provide other strategies for handling this case. A strategy that deviates from the behavior this document recommends SHOULD be configurable to use the recommended behavior, in order to provide maximum interoperability.
とはいえ、各実装は必要な制約に基づいて独自の選択を行い、このケースを処理するための他の戦略を提供する理由があるかもしれません。最大の相互運用性を提供するために、このドキュメントが推奨する動作を使用するように構成可能であることを推奨する動作から逸脱する戦略。
This extension adds no new security considerations.
この拡張機能により、セキュリティに関する新しい考慮事項は追加されません。
This document registers a sub-TLV allocation in both OSPF and ISIS.
このドキュメントでは、OSPFとISISの両方でサブTLV割り当てを登録しています。
For OSPF, the subregistry is the "Types for sub-TLVs of TE Link TLV (Value 2)" in the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registry.
OSPFの場合、サブレジストリは、「Open Shortest Path First（OSPF）トラフィックエンジニアリングTLV」レジストリの「TEリンクTLVのサブTLVのタイプ（値2）」です。
For IS-IS, it is "Sub-TLVs for TLV 22, 141, and 222" subregistry in the "IS-IS TLV Codepoints" registry. For IS-IS, the value should be marked 'y' for Sub-TLVs 22, 141 and 222; this is identical to the allocation for the Administrative Group sub-TLV (value 3 in the same subregistry).
IS-ISの場合は、「IS-IS TLVコードポイント」レジストリの「TLV 22、141、および222のサブTLV」サブレジストリです。 IS-ISの場合、サブTLV 22、141、および222の値は「y」とマークする必要があります。これは、管理グループサブTLVの割り当てと同じです（同じサブレジストリの値3）。
The assigned value from the OSPF registry is 26 and the assigned value from the IS-IS registry is 14. The sub-TLV is called "Extended Administrative Group".
OSPFレジストリからの割り当て値は26で、IS-ISレジストリからの割り当て値は14です。サブTLVは「拡張管理グループ」と呼ばれます。
Thanks to Santiago Alvarez, Rohit Gupta, Liem Nguyen, Tarek Saad, Robert Sawaya, Andy Malis, Les Ginsberg and Adrian Farrel for their review and comments.
Santiago Alvarez、Rohit Gupta、Liem Nguyen、Tarek Saad、Robert Sawaya、Andy Malis、Les Ginsberg、Adrian Farrelのレビューとコメントに感謝します。
[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月。
[RFC3209] 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.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、2003年9月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、2008年10月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。、Ed。、and JL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、2009年3月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「Requirements for Traffic Engineering Over MPLS」、RFC 2702、1999年9月。
Author's Address
著者のアドレス
Eric Osborne
エリック・オズボーン
EMail: eric.osborne@notcom.com