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）IETFトラスト（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）のセットの中で（LSP）のパスを交換MPLSトラフィックエンジニアリングの一般的な展開シナリオのいずれかで帯域幅の最適化のために、帯域幅保証またはMPLS高速リルートと高速迂回。そのような配置は、（のLSRの数の平方のオーダ）TE LSPの潜在的に多数の構成を必要とし得ます。このドキュメントは、内部ゲートウェイプロトコル（IGP）のルーティング拡張子を指定する中間システムツー中間システム（IS-IS）とOSPF（Open Shortest Path First）のために、メッシュのLSRのメンバーのセットの自動検出を提供するように、 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高速リルートと高速迂回のためのMPLSトラフィックエンジニアリングの一般的な展開シナリオです。 NのLSR間のTE LSPの完全なメッシュを設定するTE LSPの潜在的に多数（O（N ^ 2））の設定が必要です。さらに、メッシュ内の任意の新しいLSRの添加は、新しいLSRと2の合計を提供し、この新しいLSR宛既存のメッシュのすべてのLSR、上の一つの新たなTE LSP * N TEにN追加のTE LSPの設定が必要LSPは設定されています。このような動作は、サービスプロバイダのために時間がかかるだけでなく、危険な（設定ミスを起こしやすい）だけではありません。したがって、TE LSPを設定するための自動機構が望まれると、自動的にメッシュに属するのLSRのセットを発見する能力を必要とするメッシュ。自動的にメッシュのメンバーを発見するために、この文書はまた、「TEメッシュグループ」と呼ばれる、ルーティング拡張子を指定します。 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]で定義されています。この文書では、TEメッシュグループメンバーの自動検出を可能にTLVのは、OSPFルータ情報（リンクステートアドバタイズメント）LSA [RFC4970]で搬送されるIGP（OSPFおよびIS-IS）TEメッシュグループ（タイプ長さ値）を指定しますおよびルータ機能TLV [RFC4971] IS-IS。この文書で指定されたルーティングの拡張機能は、複数の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).
そこのIGPの操作上の比較的タイトなリアルタイム制約されている（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は、与えられたTEメッシュグループを残す/参加するLSRの欲求を宣伝するために使用されます。いいえサブTLVは、現在TE-MESH-GROUP 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（OSPFルータ情報でアドバタイズは[RFC4970]で定義された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にトラフィックエンジニアリングの拡張（[RFC3630]を参照）によって使用されるTLVのフォーマットと同じです。 TLVは4オクテット整列に埋め込まれます。パディングは、長さフィールド（SO三オクテットの値が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
TYPE：3 LENGTH：変数
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
TYPE：4 LENGTH：変数
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-GROUP TLVフォーマット（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メッシュグループに対応し、次のフィールドで構成されている一つまたは複数のメッシュ群のエントリを含んでいてもよいです。
- 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.
- テールエンドアドレス：IPv4またはIPv6のIPアドレスが同じメッシュグループに属する他のLSRによって末尾TE LSPアドレスとして使用されます。
- 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サブTLVは、所与のTEメッシュグループを去る/参加するLSRの欲求をアドバタイズするために使用されます。いいえサブTLVは、現在TE-MESH-GROUPサブ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].
（[RFC4971]で定義されたIS-IS機能TLVでアドバタイズ）IS-IS TE-MESH-GROUPサブTLVは、タイプの1つのオクテット、TLVの長さおよび値フィールドを指定する1つのオクテットで構成されています。 TE-MESH-GROUPサブ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サブ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サブTLVフォーマット（IPv4アドレス）
TYPE: 4 LENGTH: Variable
TYPE：4 LENGTH：変数
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サブ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サブ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.
- テールエンドアドレス：IPv4またはIPv6のIPアドレスが同じメッシュグループに属する他のLSRによって末尾TE LSPアドレスとして使用されます。
- 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は、IS-ISルータ機能TLVの中に運ばれるOSPFルーティング情報LSAとIS-IS TE-MESH-GROUPサブTLVの中に運ばれます。このように、手順の要素はOSPFのために[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.
TE-MESH-GROUP TLVはオプションでのIPv4またはIPv6インスタンスインスタンスの各々の複数を含んではいけません。 IPv4またはIPv6 OSPF TE-MESH-GROUP TLVのいずれかが一度OSPFルータ情報LSA内でより多く発生した場合、最初のインスタンスだけが処理され、その後のTLV（S）は無視されるべきです。 IPv4またはIPv6のいずれかであれば、同様に、TE-MESH-GROUPサブTLVは、一度IS-ISルータ能力TLV以内以上発生、最初のインスタンスだけが処理されるIS-IS、後続のTLV（S）は無視されるべきです。
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はOSPFv3の[RFC2740]は[RFC2328]のOSPFv2のOSPFルータ情報オペークLSA（4の不透明タイプ、0の不透明ID）内でアドバタイズし、新しい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およびOSPFv3のために[RFC2740]の[RFC2370]で定義されるように、ルータ情報LSAの氾濫範囲はOSPFv2のためのLSA不透明タイプおよびOSPFv3のためのS1 / S2ビットの値によって決定されます。
For OSPFv2 Router Information opaque LSA:
OSPFv2のルータ情報の不透明LSAの場合：
- Link-local scope: type 9;
- リンクローカルスコープ：タイプ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;
- リンクローカルスコープ：クリア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とのOSPFv3ルータ情報LSAクリアビットおよびS2ビットをセット。
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サブTLVは[RFC4971]で定義されたTLV IS-ISルータの能力の範囲内でアドバタイズされます。アドバタイズされたサブTLVのいずれかの内容が変更されるたびに、または定期的なIS-IS手順（LSPの更新）によって必要とされるたびにIS-ISルータが新たに発信しなければならないLSPは、IS-IS。 LSRが参加したり、特定のTEメッシュグループを残すことを希望する場合は、それが更新さを備えた新しいLSPを発信する必要があり-ISルータ機能TLVが更新TE-MESH-GROUPサブTLVを備えます。結合の場合には、新しいエントリがTE-MESH-GROUPサブTLVに追加されます。 LSRは、メッシュグループを離れた場合、逆に、対応するエントリは、TE-MESH-GROUPサブTLVから削除されます。両方の操作は、単一の更新のコンテキストで実行することができることに留意されたいです。実装は、特定のLSRから以前に受信したTE-MESH-GROUPサブ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サブTLVの氾濫範囲はIS-ISレベル/地域に限られている場合、サブTLVは、レベル/面積とルータCAPABILITY TLVのSフラグを横切って漏洩してはいけませんクリアする必要があります。 TE-MESH-GROUPサブTLVの氾濫範囲全体のルーティングドメインである場合は逆に、TLVは、IS-ISレベル/領域を横切って漏洩しなければなりません、ルータ能力のSフラグがTLVを設定しなければなりません。両方の場合において、[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内ルータCAPABILITYのTLV-IS ISを生成してもよいです。
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は、任意の相互運用性の問題を導入していません。 [RFC2370]で指定されるようにOSPFのため、TE-MESH-GROUP TLVをサポートしないルータは、単に黙っTLVを無視すべきです。 IS-ISの場合、ルータは黙っサブTLVを無視すべきであるTE-MESH-GROUPサブ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 IS-ISルータ機能TLVの中で運ばTE-MESH-GROUPサブTLVのためのサブ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プロトコルのためにと、IS-ISのための[RFC1195]の[RFC2328]と[RFC2740]でカバーされています。このようなセットをトリガーとして、設定ミスや悪意のある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.
私たちは彼らの有益なコメントをディーン・チェン、エードリアンファレル、ヤニック・ルLouedec、デイブ・ワード、レ・ギンズバーグ、スティーブンNadas、ACEE Lindem、ディミトリPapadimitriou、およびLakshminath Dondetiに感謝したいと思います。
[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.
[RFC4971] Vasseur、JP。、エド。、シェン、N.、エド。、およびR.アガルワル、エド。、 "中間システム広告ルータ情報のための中間システム（IS-IS）への拡張"、RFC 4971、2007年7月。
[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.編、シェン、N.、Vasseur、JP。、アガルワル、R.、およびS.シェイファー、 "広告オプションのルータの機能のための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.は、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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、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.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、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]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）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]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング（TE）のための中間システム（IS-IS）への拡張"、RFC 3784、2004年6月。
Authors' Addresses
著者のアドレス
JP Vasseur (editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（エディタ）は、シスコシステムズ、株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
JL Le Roux (editor) France Telecom 2, Avenue Pierre-Marzin Lanion, 22307 FRANCE
JLル・ルー（編集者）フランステレコム2、アベニューピエールMarzin Lanion、22307 FRANCE
EMail: jeanlouis.leroux@orange-ftgroup.com
メールアドレス：jeanlouis.leroux@orange-ftgroup.com
Seisho Yasukawa NTT 3-1, Otemachi 2-Chome Chiyoda-ku Tokyo, 100-8116 JAPAN
せいしょ やすかわ んっｔ ３ー１、 おてまち ２ーちょめ ちよだーく ときょ、 １００ー８１１６ じゃぱん
EMail: s.yasukawa@hco.ntt.co.jp
メールアドレス：s.yasukawa@hco.ntt.co.jp
Stefano Previdi Cisco Systems, Inc Via Del Serafico 200 Roma, 00142 Italy
スティーブンは、シスコシステムズ、株式会社200ヴィアデルセラフィックローマ、イタリア00142を予見しました
EMail: sprevidi@cisco.com
メールアドレス：sprevidi@cisco.com
Peter Psenak Cisco Systems Mlynske Nivy 43 821 09 Bratislava Slovakia
ピーターPsenakシスコシステムズMlynskéニヴィ43 821 09ブラチスラバスロバキア
EMail: ppsenak@cisco.com
メールアドレス：ppsenak@cisco.com
Paul Mabbey Comcast Cable 4100 E. Dry Creek Rd Centennial, CO 80122 USA
ポール・Mabbey Comcastのケーブル4100 E.ドライクリークRdのセンテニアル、CO 80122 USA
EMail: Paul_Mabey@cable.comcast.com
メールアドレス：Paul_Mabey@cable.comcast.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機能のための基金は現在、インターネット協会によって提供されます。