[要約] RFC 4972は、MPLS Label Switch Router（LSR）トラフィックエンジニアリング（TE）メッシュメンバーシップの発見のためのルーティング拡張に関するものです。このRFCの目的は、MPLSネットワーク内のTEメッシュメンバーシップを自動的に検出するためのプロトコルを提案することです。
Network Working Group JP. Vasseur, Ed.
Request for Comments: 4972 Cisco Systems, Inc
Category: Standards Track JL. Leroux, Ed.
France Telecom
S. Yasukawa
NTT
S. Previdi
P. Psenak
Cisco Systems, Inc
P. Mabbey
Comcast
July 2007
Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership
マルチプロトコル（MPLS）ラベルスイッチルーター（LSR）トラフィックエンジニアリング（TE）メッシュメンバーシップの発見のためのルーティング拡張機能
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）The IETF Trust（2007）。
Abstract
概要
The setup of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Label Switch Routers (LSR) is a common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of a potentially large number of TE LSPs (on the order of the square of the number of LSRs). This document specifies Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and Open Shortest Path First (OSPF) so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh of TE LSPs.
マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）ラベルスイッチルーターのセット（LSR）のラベルスイッチパス（LSR）のフルメッシュのセットアップは、帯域幅の最適化のためのMPLSトラフィックエンジニアリングの一般的な展開シナリオです。帯域幅の保証またはMPLS Fast Rerouteによる高速再ルーティング。このような展開には、潜在的に多数のTE LSPの構成が必要になる場合があります（LSRの数の2平方の順序で）。このドキュメントは、インテリアゲートウェイプロトコル（IGP）ルーティング拡張機能を指定します。Te LSPのそのようなメッシュの作成を自動化する。
Table of Contents
目次
1. Introduction ....................................................2
2. Definitions .....................................................3
2.1. Conventions Used in This Document ..........................4
3. Description of a TE Mesh-Group ..................................4
4. TE-MESH-GROUP TLV Formats .......................................4
4.1. OSPF TE-MESH-GROUP TLV Format ..............................4
4.2. IS-IS TE-MESH-GROUP Sub-TLV Format .........................7
5. Elements of Procedure ...........................................9
5.1. OSPF .......................................................9
5.2. IS-IS .....................................................10
6. Backward Compatibility .........................................11
7. IANA Considerations ............................................11
7.1. OSPF ......................................................11
7.2. IS-IS .....................................................11
8. Security Considerations ........................................12
9. Acknowledgements ...............................................12
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................13
There are two well-known approaches in deploying MPLS Traffic Engineering:
MPLSトラフィックエンジニアリングの展開には、2つのよく知られているアプローチがあります。
(1) The so-called "strategic" approach that consists of setting up a full mesh of TE LSPs between a set of LSRs.
(1) LSRのセット間でTE LSPの完全なメッシュをセットアップすることで構成されるいわゆる「戦略的」アプローチ。
(2) The so-called "tactical" approach, where a set of TE LSPs are provisioned on well-identified "hot spots" in order to alleviate a congestion resulting, for instance, from an unexpected traffic growth in some parts of the network.
(2) いわゆる「戦術的な」アプローチ。たとえば、ネットワークの一部の予期せぬトラフィックの成長から生じるうっ血を緩和するために、よく特定された「ホットスポット」でTE LSPのセットがプロビジョニングされます。
The setup of a full mesh of TE LSPs among a set of LSRs is a common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees, or fast rerouting with MPLS Fast Reroute. Setting up a full mesh of TE LSPs between N LSRs requires the configuration of a potentially large number of TE LSPs (O(N^2)). Furthermore, the addition of any new LSR in the mesh requires the configuration of N additional TE LSPs on the new LSR and one new TE LSP on every LSR of the existing mesh destined to this new LSR, which gives a total of 2*N TE LSPs to be configured. Such an operation is not only time consuming but also risky (prone to misconfiguration) for Service Providers. Hence, an automatic mechanism for setting up TE LSPs meshes is desirable and requires the ability to automatically discover the set of LSRs that belong to the mesh. This document specifies routing extensions so as to automatically discover the members of a mesh, also referred to as a "TE mesh-group". Note that the mechanism(s) needed for the dynamic creation of TE LSPs is implementation specific and outside the scope of this document.
LSRのセット間のTE LSPの完全なメッシュのセットアップは、帯域幅の最適化、帯域幅保証、またはMPLS Fast Rerouteでの高速再ルーティングのためのMPLSトラフィックエンジニアリングの一般的な展開シナリオです。N LSR間でTe LSPの完全なメッシュをセットアップするには、潜在的に多数のTe LSP（O（n^2））の構成が必要です。さらに、メッシュに新しいLSRを追加するには、この新しいLSRのすべてのLSRに新しいLSRにn追加のTE LSPを構成する必要があります。構成するLSP。このような操作は、時間がかかるだけでなく、サービスプロバイダーにとって危険な（誤解を招く傾向があります）。したがって、TE LSPメッシュをセットアップするための自動メカニズムが望ましいため、メッシュに属するLSRのセットを自動的に発見する能力が必要です。このドキュメントは、「Te Mesh-Group」とも呼ばれるメッシュのメンバーを自動的に発見するために、ルーティング拡張機能を指定します。TE LSPの動的な作成に必要なメカニズムは、このドキュメントの範囲外であり、範囲外であることに注意してください。
Routing extensions have been defined in [RFC4970] and [RFC4971] in order to advertise router capabilities. This document specifies IGP (OSPF and IS-IS) TE Mesh Group (Type Length Value) TLVs allowing for the automatic discovery of a TE mesh-group members, to be carried in the OSPF Router Information (Link State Advertisement) LSA [RFC4970] and IS-IS Router Capability TLV [RFC4971]. The routing extensions specified in this document provide the ability to signal multiple TE mesh groups. An LSR may belong to more than one TE mesh-group(s).
ルーター機能を宣伝するために、ルーティング拡張機能は[RFC4970]および[RFC4971]で定義されています。このドキュメントは、OSPFルーター情報（リンク状態広告）LSA [RFC4970]で運ばれるTEメッシュグループメンバーの自動発見を可能にするIGP（OSPFおよびIS-IS）TEメッシュグループ（タイプ長値）TLVを指定しています。IS-ISルーター機能TLV [RFC4971]。このドキュメントで指定されているルーティング拡張機能は、複数のTEメッシュグループを信号する機能を提供します。LSRは、複数のTEメッシュグループに属している場合があります。
There are relatively tight real-time constraints on the operation of IGPs (such as OSPF and IS-IS). For this reason, some care needs to be applied when proposing to carry additional information in an IGP. The information described in this document is both relatively small in total volume (compared with other information already carried in IGPs), and also relatively stable (i.e., changes are based on configuration changes, but not on dynamic events within the network, or on dynamic triggers, such as the leaking of information from other routing protocols or routing protocol instances).
IGPS（OSPFやIS-ISなど）の動作には比較的厳しいリアルタイム制約があります。このため、IGPで追加情報を携帯することを提案する際には、ある程度の注意が必要です。このドキュメントで説明されている情報は、総量が比較的少ない（IGPで既に運ばれている他の情報と比較して）、比較的安定しています（つまり、変更は構成の変更に基づいていますが、ネットワーク内の動的イベント、または動的なイベントにはありません。他のルーティングプロトコルやルーティングプロトコルインスタンスからの情報の漏れなどのトリガー。
Terminology used in this document
このドキュメントで使用される用語
IGP: Interior Gateway Protocol
IGP：インテリアゲートウェイプロトコル
IGP Area: OSPF area or IS-IS level
IGPエリア：OSPFエリアまたはIS-ISレベル
IS-IS: Intermediate System-to-Intermediate System (IS-IS)
IS-IS：中間システムから中間体のシステム（IS-IS）
LSR: Label Switch Router
LSR：ラベルスイッチルーター
OSPF: Open Shortest Path First
OSPF：最初に最短パスを開きます
OSPF LSA: OSPF Link State Advertisement
OSPF LSA：OSPFリンク状態広告
TE LSP: Traffic Engineering Label Switched Path
TE LSP：トラフィックエンジニアリングラベルの切り替えパス
TE LSP head-end: head/source of the TE LSP
TE LSPヘッドエンド：TE LSPのヘッド/ソース
TE LSP tail-end: tail/destination of the TE LSP.
TE LSPテールエンド：TE LSPのテール/宛先。
TLV: Type Length Value
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
A TE mesh-group is defined as a group of LSRs that are connected by a full mesh of TE LSPs. Routing extensions are specified in this document, allowing for dynamic discovery of the TE mesh-group members. Procedures are also specified for a member to join and leave a TE mesh-group. For each TE mesh-group membership announced by an LSR, the following information is advertised:
TEメッシュグループは、TE LSPの完全なメッシュで接続されているLSRのグループとして定義されます。このドキュメントではルーティング拡張機能が指定されており、TEメッシュグループメンバーの動的な発見が可能になります。また、メンバーが参加してTEメッシュグループを去るための手順も指定されています。LSRによって発表されたTEメッシュグループメンバーシップごとに、次の情報が宣伝されています。
- A mesh-group number identifying the TE mesh-group that the LSR belongs to,
- LSRが属するTEメッシュグループを識別するメッシュグループ番号、
- A tail-end address (used as the TE LSP Tail-end address by other LSRs belonging to the same mesh-group),
- テールエンドアドレス（同じメッシュグループに属する他のLSRによってTE LSPテールエンドアドレスとして使用）、
- A tail-end name: a display string that is allocated to the tail-end used to ease the TE-LSP naming.
- テールエンド名：TE-LSPの命名を容易にするために使用されるテールエンドに割り当てられたディスプレイ文字列。
The TE-MESH-GROUP TLV is used to advertise the desire of an LSR to join/leave a given TE mesh-group. No sub-TLV is currently defined for the TE-MESH-GROUP TLV.
TE-Mesh-Group TLVは、LSRが特定のTEメッシュグループに参加/残したいという欲求を宣伝するために使用されます。現在、TE-Mesh-Group TLVに対してサブTLVは定義されていません。
The OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information LSA defined in [RFC4970]) has the following format:
OSPF TE-MESH-GROUP TLV（[RFC4970]で定義されているOSPFルーター情報LSAで宣伝されています）には、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - OSPF TE-MESH-GROUP TLV format
図1-OSPF TE-MESH-GROUP TLV形式
Where Type: identifies the TLV type Length: the length of the value field in octets
ここでタイプ：TLVタイプの長さを識別します：オクテットの値フィールドの長さ
The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV format used by the Traffic Engineering Extensions to OSPF (see[RFC3630]). The TLV is padded to a four-octet alignment; padding is not included in the length field (so a three-octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. Unrecognized types are ignored. All types between 32768 and 65535 are reserved for vendor-specific extensions. All other undefined type codes are reserved for future assignment by IANA.
OSPF TE-Mesh-Group TLVの形式は、トラフィックエンジニアリング拡張機能がOSPFに使用するTLV形式と同じです（[RFC3630]を参照）。TLVは、4オクテットのアライメントにパッドで塗られています。パディングは長さフィールドに含まれていません（したがって、3オクテットの値は3つの長さですが、TLVの合計サイズは8オクテットになります）。ネストされたTLVも32ビットアライメントされています。認識されていないタイプは無視されます。32768から65535の間のすべてのタイプは、ベンダー固有の拡張用に予約されています。他のすべての未定義のタイプコードは、IANAによる将来の割り当てのために予約されています。
The OSPF TE-MESH-GROUP TLV format for IPv4 (Figure 2) and IPv6 (Figure 3) is as follows:
IPv4（図2）およびIPv6（図3）のOSPF TE-MESH-GROUP TLV形式は次のとおりです。
TYPE: 3 LENGTH: Variable
タイプ：3長さ：変数
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address)
図2-OSPF TE-MESH-GROUP TLV形式（IPv4アドレス）
TYPE: 4 LENGTH: Variable
タイプ：4長さ：変数
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tail-end IPv6 address 1 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tail-end IPv6 address n |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - OSPF TE-MESH-GROUP TLV format (IPv6 Address)
図3-OSPF TE-MESH-GROUPTLV形式（IPv6アドレス）
The OSPF TE-MESH-GROUP TLV may contain one or more mesh-group entries, where each entry corresponds to a TE mesh-group and is made of the following fields:
OSPF TE-Mesh-Group TLVには、各エントリがTEメッシュグループに対応し、次のフィールドで構成されている1つ以上のメッシュグループエントリが含まれている場合があります。
- A mesh-group-number that identifies the mesh-group number.
- メッシュグループ数を識別するメッシュグループ番号。
- A Tail-end address: an IPv4 or IPv6 IP address to be used as a tail-end TE LSP address by other LSRs belonging to the same mesh-group.
- テールエンドアドレス：同じメッシュグループに属する他のLSRによってテールエンドTE LSPアドレスとして使用されるIPv4またはIPv6 IPアドレス。
- Name length field: An integer, expressed in octets, that indicates the length of the Tail-end name before padding.
- 名前の長さフィールド：オクテットで表現された整数で、パディング前のテールエンド名の長さを示します。
- A Tail-end name: A display string that is allocated to the Tail-end. The field is of variable length field and is used to facilitate the TE LSP identification.
- テールエンド名：テールエンドに割り当てられたディスプレイ文字列。フィールドは可変長さフィールドであり、TE LSPの識別を促進するために使用されます。
The TE-MESH-GROUP sub-TLV is used to advertise the desire of an LSR to join/leave a given TE mesh-group. No sub-TLV is currently defined for the TE-MESH-GROUP sub-TLV.
TE-Mesh-Group Sub-TLVは、LSRが特定のTEメッシュグループに参加/残したいという欲求を宣伝するために使用されます。現在、TE-Mesh-Group Sub-TLVに対してサブTLVは定義されていません。
The IS-IS TE-MESH-GROUP sub-TLV (advertised in the IS-IS CAPABILITY TLV defined in [RFC4971]) is composed of 1 octet for the type, 1 octet specifying the TLV length and a value field. The format of the TE-MESH-GROUP sub-TLV is identical to the TLV format used by the Traffic Engineering Extensions for IS-IS [RFC3784].
IS-IS TE-Mesh-Group Sub-TLV（[RFC4971]で定義されているIS-IS機能TLVで宣伝）は、タイプの1オクテット、TLVの長さと値フィールドを指定する1オクテットで構成されています。TE-Mesh-Group Sub-TLVの形式は、IS-IS [RFC3784]のトラフィックエンジニアリング拡張機能で使用されるTLV形式と同一です。
The IS-IS TE-MESH-GROUP sub-TLV format for IPv4 (Figure 4) and IPv6 (Figure 5) is as follows:
IPv4（図4）およびIPv6（図5）のIS-IS TE-Mesh-Group Sub-TLV形式は次のとおりです。
TYPE: 3
LENGTH: Variable
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - IS-IS TE-MESH-GROUP sub-TLV format (IPv4 Address)
図4-is-is te-mesh-group sub-tlvフォーマット（IPv4アドレス）
TYPE: 4 LENGTH: Variable
タイプ：4長さ：変数
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tail-end IPv6 address 1 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tail-end IPv6 address n |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - IS-IS TE-MESH-GROUP sub-TLV format (IPv6 Address)
図5-is-is te-mesh-group sub-tlvフォーマット（IPv6アドレス）
The IS-IS TE-MESH-GROUP sub-TLV may contain one or more mesh-group entries where each entry correspond to a TE mesh-group and is made of the following fields:
IS-IS TE-Mesh-Group Sub-TLVには、各エントリがTEメッシュグループに対応し、次のフィールドで構成されている1つ以上のメッシュグループエントリが含まれる場合があります。
- A mesh-group-number that identifies the mesh-group number.
- メッシュグループ数を識別するメッシュグループ番号。
- A Tail-end address: an IPv4 or IPv6 IP address to be used as a tail-end TE LSP address by other LSRs belonging to the same mesh-group.
- テールエンドアドレス：同じメッシュグループに属する他のLSRによってテールエンドTE LSPアドレスとして使用されるIPv4またはIPv6 IPアドレス。
- Name length field: An integer, expressed in octets, that indicates the length of the Tail-end name before padding.
-
- A Tail-end name: A display string that is allocated to the Tail-end. The field is of variable length and is used to facilitate the TE LSP identification.
- テールエンド名：テールエンドに割り当てられたディスプレイ文字列。フィールドは長さが可変であり、TE LSPの識別を促進するために使用されます。
The OSPF TE-MESH-GROUP TLV is carried within the OSPF Routing Information LSA and the IS-IS TE-MESH-GROUP sub-TLV is carried within the IS-IS Router capability TLV. As such, elements of procedure are inherited from those defined in [RFC4970] and [RFC4971] for OSPF and IS-IS respectively. Specifically, a router MUST originate a new LSA/LSP whenever the content of this information changes, or whenever required by regular routing procedure (e.g., updates).
OSPF TE-MESH-GROUP TLVは、OSPFルーティング情報LSA内で運ばれ、IS-IS TE-Mesh-Group Sub-TLVはIS-ISルーター機能TLV内で運ばれます。そのため、手順の要素は、OSPFおよびIS-ISについてそれぞれ[RFC4970]および[RFC4971]で定義されている要素から継承されます。具体的には、ルーターは、この情報のコンテンツが変更されるたびに、または通常のルーティング手順（更新など）で要求されるたびに、新しいLSA/LSPを発信する必要があります。
The TE-MESH-GROUP TLV is OPTIONAL and MUST NOT include more than one of each of the IPv4 instances or the IPv6 instance. If either the IPv4 or the IPv6 OSPF TE-MESH-GROUP TLV occurs more than once within the OSPF Router Information LSA, only the first instance is processed, subsequent TLV(s) SHOULD be silently ignored. Similarly, if either the IPv4 or the IPv6 IS-IS TE-MESH-GROUP sub-TLV occurs more than once within the IS-IS Router capability TLV, only the first instance is processed, subsequent TLV(s) SHOULD be silently ignored.
The TE-MESH-GROUP TLV is advertised within an OSPF Router Information opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 [RFC2328] and within a new LSA (Router Information LSA) for OSPFv3 [RFC2740]. The Router Information LSAs for OSPFv2 and OSPFv3 are defined in [RFC4970].
TE-Mesh-Group TLVは、OSPFv2 [RFC2328]のOSPFルーター情報不透明LSA（0の不透明なタイプ4、0の不透明ID）およびOSPFV3 [RFC2740]の新しいLSA（ルーター情報LSA）内で宣伝されています。OSPFV2およびOSPFV3のルーター情報LSAは[RFC4970]で定義されています。
A router MUST originate a new OSPF router information LSA whenever the content of any of the advertised TLV changes or whenever required by the regular OSPF procedure (LSA update (every LSRefreshTime)). If an LSR desires to join or leave a particular TE mesh group, it MUST originate a new OSPF Router Information LSA comprising the updated TE-MESH-GROUP TLV. In the case of a join, a new entry will be added to the TE-MESH-GROUP TLV; conversely, if the LSR leaves, a mesh-group the corresponding entry will be removed from the TE-MESH-GROUP TLV. Note that both operations can be performed in the context of a single LSA update. An implementation SHOULD be able to detect any change to a previously received TE-MESH-GROUP TLV from a specific LSR.
ルーターは、広告されたTLVの変更のコンテンツがいつでも、または通常のOSPF手順（LSAアップデート（すべてのLSREFRESHTIME））で要求されるたびに、新しいOSPFルーター情報LSAを発信する必要があります。LSRが特定のTEメッシュグループに参加または去ることを希望する場合、更新されたTE-Mesh-Group TLVを含む新しいOSPFルーター情報LSAを発信する必要があります。結合の場合、TE-Mesh-Group TLVに新しいエントリが追加されます。逆に、LSRが去る場合、メッシュグループは、対応するエントリがTE-Mesh-Group TLVから削除されます。両方の操作は、単一のLSAアップデートのコンテキストで実行できることに注意してください。実装は、特定のLSRから以前に受け取ったTE-Mesh-Group TLVの変更を検出できる必要があります。
As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the flooding scope of the Router Information LSA is determined by the LSA Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3.
OSPVv2の[RFC2370]およびOSPFV3の[RFC2740]で定義されているように、ルーター情報LSAの洪水範囲は、OSPFV2のLSA不透明タイプとOSOSPFV3のS1/S2ビットの値によって決定されます。
For OSPFv2 Router Information opaque LSA:
OSPFV2ルーター情報OPAQUE LSA：
- Link-local scope: type 9;
- Link-Local Scope：タイプ9。
- Area-local scope: type 10;
- エリアローカルスコープ：タイプ10;
- Routing-domain scope: type 11. In this case, the flooding scope is equivalent to the Type 5 LSA flooding scope.
- ルーティングドメイン範囲：タイプ11。この場合、洪水範囲はタイプ5 LSA洪水範囲に相当します。
For OSPFv3 Router Information LSA:
OSPFV3ルーター情報LSA：
- Link-local scope: OSPFv3 Router Information LSA with the S1 and S2 bits cleared;
- Link-Local Scope：S1およびS2ビットを備えたOSPFV3ルーター情報LSAがクリアされました。
- Area-local scope: OSPFv3 Router Information LSA with the S1 bit set and the S2 bit cleared;
- エリアローカルスコープ：S1ビットセットを備えたOSPFV3ルーター情報LSAおよびS2ビットがクリアされました。
- Routing-domain scope: OSPFv3 Router Information LSA with S1 bit cleared and the S2 bit set.
- ルーティングドメインスコープ：s1ビットがクリアされ、S2ビットセットを備えたOSPFV3ルーター情報LSA。
A router may generate multiple OSPF Router Information LSAs with different flooding scopes.
ルーターは、異なる洪水スコープを持つ複数のOSPFルーター情報LSAを生成する場合があります。
The TE-MESH-GROUP TLV may be advertised within an Area-local or Routing-domain scope Router Information LSA, depending on the MPLS TE mesh group profile:
TE-Mesh-Group TLVは、MPLS TEメッシュグループプロファイルに応じて、エリアローカルまたはルーティングドメインスコープルーター情報LSA内で宣伝できます。
- If the MPLS TE mesh-group is contained within a single area (all the LSRs of the mesh-group are contained within a single area), the TE-MESH-GROUP TLV MUST be generated within an Area-local Router Information LSA.
- MPLS TEメッシュグループが単一の領域内に含まれている場合（メッシュグループのすべてのLSRが単一の領域内に含まれています）、TE-MESH-GROUP TLVをエリアローカルルーター情報LSA内で生成する必要があります。
- If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh-group TLV MUST be generated within a Routing-domain scope router information LSA.
- MPLS TEメッシュグループが複数のOSPF領域に及ぶ場合、TEメッシュグループTLVをルーティングドメインスコープルーター情報LSA内で生成する必要があります。
The TE-MESH-GROUP sub-TLV is advertised within the IS-IS Router CAPABILITY TLV defined in [RFC4971]. An IS-IS router MUST originate a new IS-IS LSP whenever the content of any of the advertised sub-TLV changes or whenever required by regular IS-IS procedure (LSP updates). If an LSR desires to join or leave a particular TE mesh group, it MUST originate a new LSP comprising the refreshed IS-IS Router capability TLV comprising the updated TE-MESH-GROUP sub-TLV. In the case of a join, a new entry will be added to the TE-MESH-GROUP sub-TLV; conversely, if the LSR leaves a mesh-group, the corresponding entry will be deleted from the TE-MESH-GROUP sub-TLV. Note that both operations can be performed in the context of a single update. An implementation SHOULD be able to detect any change to a previously received TE-MESH-GROUP sub-TLV from a specific LSR.
TE-Mesh-Group Sub-TLVは、[RFC4971]で定義されているIS-ISルーター機能TLV内で宣伝されています。IS-ISルーターは、広告されたサブTLVの変更のコンテンツがいつでも、または通常のISプロシージャ（LSP更新）で必要な場合はいつでも、新しいIS-IS LSPを発信する必要があります。LSRが特定のTEメッシュグループに参加または去ることを希望する場合、更新されたTE-Mesh-Group Sub-TLVを含む更新されたISルーター機能TLVを含む新しいLSPを発信する必要があります。結合の場合、TE-Mesh-Group Sub-TLVに新しいエントリが追加されます。逆に、LSRがメッシュグループを離れると、対応するエントリはTE-Mesh-Group Sub-TLVから削除されます。両方の操作は、単一の更新のコンテキストで実行できることに注意してください。実装は、特定のLSRから以前に受け取ったTE-Mesh-Group Sub-TLVの変更を検出できる必要があります。
If the flooding scope of a TE-MESH-GROUP sub-TLV is limited to an IS-IS level/area, the sub-TLV MUST not be leaked across level/area and the S flag of the Router CAPABILITY TLV MUST be cleared. Conversely, if the flooding scope of a TE-MESH-GROUP sub-TLV is the entire routing domain, the TLV MUST be leaked across IS-IS levels/areas, and the S flag of the Router CAPABILITY TLV MUST be set. In both cases, the flooding rules specified in [RFC4971] apply.
TE-Mesh-Group Sub-TLVの洪水範囲がIS-ISレベル/エリアに制限されている場合、サブTLVをレベル/エリア全体にリークしてはならず、ルーター機能TLVのSフラグをクリアする必要があります。逆に、TE-Mesh-Group Sub-TLVの洪水範囲がルーティングドメイン全体である場合、TLVをIS-ISレベル/領域に漏らしなければならず、ルーター機能TLVのSフラグを設定する必要があります。どちらの場合も、[RFC4971]で指定された洪水ルールが適用されます。
As specified in [RFC4971], a router may generate multiple IS-IS Router CAPABILITY TLVs within an IS-IS LSP with different flooding scopes.
[RFC4971]で指定されているように、ルーターは、異なる洪水スコープを持つIS-IS LSP内で複数のIS-ISルーター機能TLVを生成する場合があります。
The TE-MESH-GROUP TLVs defined in this document do not introduce any interoperability issue. For OSPF, a router not supporting the TE-MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in [RFC2370]. For an IS-IS, a router not supporting the TE-MESH-GROUP sub-TLV SHOULD just silently ignore the sub-TLV.
このドキュメントで定義されているTE-Mesh-Group TLVは、相互運用性の問題を導入しません。OSPFの場合、TE-Mesh-Group TLVをサポートしていないルーターは、[RFC2370]で指定されているようにTLVを静かに無視する必要があります。IS-ISの場合、TE-Mesh-Group Sub-TLVをサポートしていないルーターは、Sub-TLVを静かに無視する必要があります。
The registry for the Router Information LSA is defined in [RFC4970]. IANA assigned a new OSPF TLV code-point for the TE-MESH-GROUP TLVs carried within the Router Information LSA.
ルーター情報LSAのレジストリは[RFC4970]で定義されています。IANAは、ルーター情報LSA内で運ばれるTE-Mesh-Group TLVに新しいOSPF TLVコードポイントを割り当てました。
Value Sub-TLV References
----- -------- ----------
3 TE-MESH-GROUP TLV (IPv4) RFC 4972 (this doc)
4 TE-MESH-GROUP TLV (IPv6) RFC 4972 (this doc)
The registry for the Router Capability TLV is defined in [RFC4971]. IANA assigned a new IS-IS sub-TLV code-point for the TE-MESH-GROUP sub-TLVs carried within the IS-IS Router Capability TLV.
ルーター機能TLVのレジストリは[RFC4971]で定義されています。IANAは、IS-ISルーター機能TLV内で運ばれるTE-Mesh-Group Sub-TLVに新しいIS-ISサブTLVコードポイントを割り当てました。
Value Sub-TLV References
----- -------- ----------
3 TE-MESH-GROUP TLV (IPv4) RFC 4972 (this doc)
4 TE-MESH-GROUP TLV (IPv6) RFC 4972 (this doc)
The function described in this document does not create any new security issues for the OSPF and IS-IS protocols. Security considerations are covered in [RFC2328] and [RFC2740] for the base OSPF protocol and in [RFC1195] for IS-IS. It must be noted that the advertisement of "fake" TE Mesh Group membership(s) by a mis-configured or malicious LSR Y would not have any major impact on the network (other than overloading the IGP), such as triggering the set up of new MPLS TE LSP: indeed, for a new TE LSP originated by another LSR X destined to LSR Y to be set up, the same TE Mesh group membership must be configured on both LSRs. Thus such fake advertisement could not amplify any Denial of Service (DoS) attack.
このドキュメントで説明されている機能は、OSPFおよびIS-ISプロトコルの新しいセキュリティ問題を作成しません。セキュリティ上の考慮事項は、基本OSPFプロトコルの[RFC2328]および[RFC2740]とIS-ISの[RFC1195]でカバーされています。失敗したまたは悪意のあるLSR yによる「偽の」TEメッシュグループメンバーシップの広告は、セットアップをトリガーするなど、ネットワークに大きな影響を与えない（IGPの過負荷以外）にはないことに注意する必要があります。新しいMPLS TE LSPの：実際、設定するLSR yが運命づけられている別のLSR Xから生まれた新しいTE LSPの場合、同じTEメッシュグループメンバーシップを両方のLSRで構成する必要があります。したがって、このような偽の広告は、サービス拒否（DOS）攻撃を増幅することはできませんでした。
We would like to thank Dean Cheng, Adrian Farrel, Yannick Le Louedec, Dave Ward, Les Ginsberg, Stephen Nadas, Acee Lindem, Dimitri Papadimitriou, and Lakshminath Dondeti for their useful comments.
ディーン・チェン、エイドリアン・ファレル、ヤニック・ル・ルーデック、デイブ・ウォード、レス・ギンズバーグ、スティーブン・ナダス、エイシー・リンデム、ディミトリ・パパディミトリウ、ラクシュミナス・ドンデティに有用なコメントに感謝します。
[RFC4971] Vasseur, J-P., Ed., Shen, N., Ed., and R. Aggarwal, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007.
[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007.
[RFC4970] Lindem、A.、Ed。、Shen、N.、Vasseur、Jp。、Aggarwal、R。、およびS. Shaffer、「オプションのルーター機能の広告のためのOSPFへの拡張」、RFC 4970、2007年7月。
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[RFC2370] Coltun、R。、「OSPF Opaque LSAオプション」、RFC 2370、1998年7月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740] Coltun、R.、Ferguson、D。、およびJ. Moy、「OSPF for IPv6」、RFC 2740、1999年12月。
[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バージョン2」、RFC 3630、2003年9月。
[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月。
Authors' Addresses
著者のアドレス
JP Vasseur (editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（編集者）Cisco Systems、Inc 1414 Massachusetts Avenue Boxborough、MA 01719 USA
EMail: jpv@cisco.com
JL Le Roux (editor) France Telecom 2, Avenue Pierre-Marzin Lanion, 22307 FRANCE
Jl Le Roux（編集者）フランステレコム2、アベニューピエールマルジンラニオン、22307フランス
EMail: jeanlouis.leroux@orange-ftgroup.com
Seisho Yasukawa NTT 3-1, Otemachi 2-Chome Chiyoda-ku Tokyo, 100-8116 JAPAN
Seisho Yasukawa NTT 3-1、Otemachi 2-Chome Chiyoda-Ku Tokyo、100-8116 Japan
EMail: s.yasukawa@hco.ntt.co.jp
Stefano Previdi Cisco Systems, Inc Via Del Serafico 200 Roma, 00142 Italy
Stefano Previdi Cisco Systems、Inc、Del Serafico 200 Roma、00142 Italy
EMail: sprevidi@cisco.com
Peter Psenak
Cisco Systems
Mlynske Nivy 43
821 09
Bratislava
Slovakia
EMail: ppsenak@cisco.com
Paul Mabbey Comcast Cable 4100 E. Dry Creek Rd Centennial, CO 80122 USA
Paul Mabbey Comcast Cable 4100 E. Dry Creek Rd Centennial、Co 80122 USA
EMail: Paul_Mabey@cable.comcast.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。