[要約] RFC 5329は、OSPF Version 3におけるトラフィックエンジニアリングの拡張に関する規格です。このRFCの目的は、IPv6ネットワークにおいて効果的なトラフィック制御と経路選択を実現するための手法を提供することです。

Network Working Group                                        K. Ishiguro
Request for Comments: 5329                                     V. Manral
Category: Standards Track                               IP Infusion, Inc
                                                                A. Davey
                                                 Data Connection Limited
                                                          A. Lindem, Ed.
                                                        Redback Networks
                                                          September 2008
        

Traffic Engineering Extensions to OSPF Version 3

OSPFバージョン3へのトラフィックエンジニアリング拡張

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 (2008).

著作権(c)The IETF Trust(2008)。

Abstract

概要

This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks.

このドキュメントでは、OSPFV3への拡張機能について説明して、エリア内交通工学(TE)をサポートしています。このドキュメントは、IPv6ネットワークを処理するためにOSPFV2 TEを拡張します。新しいTLVといくつかの新しいサブTLVが、IPv6ネットワークをサポートするために定義されています。

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Requirements Notation ......................................2
   2. Intra-Area-TE-LSA ...............................................3
      2.1. Intra-Area-TE-LSA Payload ..................................4
   3. Router IPv6 Address TLV .........................................4
   4. Link TLV ........................................................5
      4.1. Link ID Sub-TLV ............................................6
      4.2. Neighbor ID Sub-TLV ........................................6
      4.3. Local Interface IPv6 Address Sub-TLV .......................6
      4.4. Remote Interface IPv6 Address Sub-TLV ......................7
   5. Security Considerations .........................................8
   6. Management Considerations .......................................8
   7. IANA Considerations .............................................9
   8. References ......................................................9
      8.1. Normative References .......................................9
      8.2. Informative References ....................................10
   Acknowledgments ...................................................10
        
1. Introduction
1. はじめに

OSPFv3 has a very flexible mechanism for adding new LS types. Unknown LS types are flooded properly based on the flooding scope bits in the LS type [OSPFV3]. This document defines the Intra-Area-TE-LSA to OSPFv3.

OSPFV3には、新しいLSタイプを追加するための非常に柔軟なメカニズムがあります。不明なLSタイプは、LSタイプ[OSPFV3]の洪水スコープビットに基づいて適切に浸水します。このドキュメントでは、A-AREA-TE-LSAからOSPFV3を定義しています。

For Traffic Engineering, this document uses "Traffic Engineering Extensions to OSPF" [TE] as a base for TLV definitions. New TLVs and sub-TLVs are added to [TE] to extend TE capabilities to IPv6 networks. Some existing TLVs and sub-TLVs require clarification for OSPFv3 applicability.

トラフィックエンジニアリングの場合、このドキュメントでは、TLV定義のベースとして「Traffic Engineering Extensions to OSPF」[TE]を使用しています。新しいTLVとサブTLVが[TE]に追加され、TE機能がIPv6ネットワークに拡張されます。一部の既存のTLVおよびサブTLVは、OSPFV3の適用性を明確にする必要があります。

GMPLS [GMPLS] and the Diff-Serv MPLS extensions [TE-DIFF] are based on [TE]. These functions can also be extended to OSPFv3 by utilizing the TLVs and sub-TLVs described in this document.

GMPLS [GMPLS]およびDIFSERV MPLS拡張[TE-DIFF]は[TE]に基づいています。これらの関数は、このドキュメントで説明されているTLVとSub-TLVを利用することにより、OSPFV3に拡張することもできます。

1.1. Requirements Notation
1.1. 要件表記

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 [RFC-KEYWORDS].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [RFC-KeyWords]に記載されているとおりに解釈されます。

2. Intra-Area-TE-LSA
2. エリア内TE-LSA

A new LS type is defined for the Intra-Area-TE-LSA. This is different from OSPFv2 Traffic Engineering [TE] where opaque LSAs are used to advertise TE information [OPAQUE]. The LSA function code is 10, the U-bit is set, and the scope is set to 01 for area-scoping. When the U-bit is set to 1, an OSPFv3 router must flood the LSA at its defined flooding scope even if it does not recognize the LS type [OSPFV3].

A-AREA-TE-LSAに対して新しいLSタイプが定義されています。これは、OSPFV2トラフィックエンジニアリング[TE]とは異なり、不透明なLSAを使用してTE情報を宣伝します[不透明]。LSA関数コードは10で、Uビットが設定されており、領域を並べて01に設定されています。Uビットが1に設定されている場合、OSPFV3ルーターは、LSタイプ[OSOSPFV3]を認識していなくても、定義された洪水範囲で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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            LS age             |1|0|1|          10             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Link State ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Advertising Router                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    LS sequence number                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        LS checksum            |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-                            TLVs                             -+
      |                             ...                               |
        

OSPFv3 Intra-Area-TE-LSA

OSPFV3 A-AREA-TE-LSA

The Link State ID of an Intra-Area-TE-LSA is an arbitrary value used to maintain multiple Traffic Engineering LSAs. The Link State ID has no topological significance.

AREA-AREA-TE-LSAのリンク状態IDは、複数のトラフィックエンジニアリングLSAを維持するために使用される任意の価値です。Link State IDにはトポロジカルな意味がありません。

The format of the TLVs within the body of an Intra-Area-TE-LSA is the same as the format used by the Traffic Engineering extensions to OSPF [TE]. The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets. The format of each TLV is:

エリア内TE-LSAの本体内のTLVの形式は、Traffic Engineering ExtensionsがOSPF [TE]に使用する形式と同じです。LSAペイロードは、1つ以上のネストされたタイプ/長さ/値(TLV)トリプレットで構成されています。各TLVの形式は次のとおりです。

       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...                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

TLV Format

TLV形式

The Length field defines the length of the value portion in octets (thus, a TLV with no value portion would have a length of 0). The TLV is padded to 4-octet alignment; padding is not included in the Length field (so a 3-octet value would have a length of 3, but the total size of the TLV would be 8 octets). Nested TLVs are also 32- bit aligned. For example, a 1-byte value would have the Length field set to 1, and 3 octets of padding would be added to the end of the value portion of the TLV. Unrecognized types are ignored.

長さのフィールドは、オクテットの値部分の長さを定義します(したがって、値部分がないTLVは0の長さになります)。TLVは4-OCTETアライメントにパッドで埋められています。パディングは長さフィールドに含まれていません(したがって、3オクテットの値は3の長さですが、TLVの合計サイズは8オクテットになります)。ネストされたTLVも32ビットアライメントされています。たとえば、1バイト値の長さフィールドは1に設定され、3オクテットのパディングがTLVの値部分の最後に追加されます。認識されていないタイプは無視されます。

2.1. Intra-Area-TE-LSA Payload
2.1. エリア内TE-LSAペイロード

An Intra-Area-TE-LSA contains one top-level TLV. There are two applicable top-level TLVs:

エリア内TE-LSAには、1つのトップレベルTLVが含まれています。適用可能なトップレベルのTLVが2つあります。

2 - Link TLV

2-リンクTLV

3 - Router IPv6 Address TLV

3 -Router IPv6アドレスTLV

3. Router IPv6 Address TLV
3. ルーターIPv6アドレスTLV

The Router IPv6 Address TLV advertises a reachable IPv6 address. This is a stable IPv6 address that SHOULD be reachable if there is connectivity to the OSPFv3 router.

ルーターIPv6アドレスTLVは、到達可能なIPv6アドレスを宣伝します。これは、OSPFV3ルーターへの接続がある場合に到達可能な安定したIPv6アドレスです。

The Router IPv6 Address TLV has type 3, length 16, and a value containing a 16-octet local IPv6 address. A link-local address MUST NOT be specified for this TLV. It MUST appear in exactly one Traffic Engineering LSA originated by an OSPFv3 router supporting the TE extensions. The Router IPv6 Address TLV is a top-level TLV as defined in "Traffic Engineering Extensions to OSPF" [TE], and only one top-level TLV may be contained in an LSA.

ルーターIPv6アドレスTLVには、タイプ3、長さ16、および16オクテットのローカルIPv6アドレスを含む値があります。このTLVには、リンクローカルアドレスを指定してはなりません。TE拡張機能をサポートするOSPFV3ルーターから発信される1つのトラフィックエンジニアリングLSAに表示される必要があります。Router IPv6アドレスTLVは、「OSPFへのトラフィックエンジニアリング拡張」[TE]で定義されているトップレベルTLVであり、LSAに1つのトップレベルTLVのみが含まれる可能性があります。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              3                |            16                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-                                                 -+-+-+-+
      |                                                               |
      +-+-+-+-             Router IPv6 Address                 -+-+-+-+
      |                                                               |
      +-+-+-+-                                                 -+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Type A 16-bit field set to 3. Length A 16-bit field that indicates the length of the value portion in octets. For this TLV, it is always 16. Value A stable and routable IPv6 address.

タイプA 16ビットフィールドは3に設定されています。オクテットの値部分の長さを示す16ビットフィールドの長さ。このTLVの場合、それは常に16です。安定したルーティング可能なIPv6アドレスです。

Router IPv6 Address TLV

ルーターIPv6アドレスTLV

4. リンクTLV

The Link TLV describes a single link and consists of a set of sub-TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID sub-TLV are applicable to OSPFv3. The Link ID sub-TLV can't be used in OSPFv3 since it is defined to use the OSPFv2 identification for the Designated Router (DR) on multi-access networks. In OSPFv2, neighbors on point-to-point networks and virtual links are identified by their Router IDs while neighbors on broadcast, Non-Broadcast Multi-Access (NBMA), and Point-to-Multipoint links are identified by their IPv4 interface addresses (refer to section 8.2 in [OSPFV2]). The IPv4 interface address is not known to OSPFv3. In contrast to OSPFv2, OSPFv3 always identifies neighboring routers by their Router IDs (refer to section 2.11 in [OSPFV3]).

リンクTLVは単一のリンクを記述し、サブTLV [TE]のセットで構成されています。Link ID Sub-TLV以外の[TE]のすべてのサブTLVは、OSPFV3に適用されます。Link ID Sub-TLVは、Multi-Accessネットワークで指定されたルーター(DR)のOSPFv2識別を使用するように定義されているため、OSPFV3では使用できません。OSPFV2では、ポイントツーポイントネットワークと仮想リンクの近隣boがルーターIDによって識別され、隣人は放送、非放送マルチアクセス(NBMA)、およびポイントツーマルティポイントリンクがIPv4インターフェイスアドレスによって識別されます([OSPFV2]のセクション8.2を参照してください。IPv4インターフェイスアドレスは、OSPFV3には不明です。OSPFV2とは対照的に、OSPFV3は常にルーターIDによって隣接するルーターを識別します([OSPFV3]のセクション2.11を参照)。

Three new sub-TLVs for the Link TLV are defined:

リンクTLVの3つの新しいサブTLVが定義されています。

18 - Neighbor ID (8 octets)

18-ネイバーID(8オクテット)

19 - Local Interface IPv6 Address (16N octets, where N is the number of IPv6 addresses)

19-ローカルインターフェイスIPv6アドレス(16nオクテット、ここで、nはIPv6アドレスの数)

20 - Remote Interface IPv6 Address (16N octets, where N is the number of IPv6 addresses)

20-リモートインターフェイスIPv6アドレス(16nオクテット、ここでnはIPv6アドレスの数)

The Neighbor ID sub-TLV is mandatory for OSPFv3 Traffic Engineering support. It MUST appear exactly once in a Link TLV. All other sub-TLVs defined in this document SHOULD NOT occur more than once in a Link TLV. If a sub-TLV is specified more than once, instances subsequent to the first are ignored.

Neighbor ID Sub-TLVは、OSPFV3トラフィックエンジニアリングサポートに必須です。リンクTLVに正確に1回表示する必要があります。このドキュメントで定義されている他のすべてのサブTLVは、リンクTLVで1回以上発生しないでください。Sub-TLVが複数回指定されている場合、最初のインスタンスは無視されます。

4.1. リンクID sub-tlv

The Link ID sub-TLV is used in OSPFv2 to identify the other end of the link. In OSPFv3, the Neighbor ID sub-TLV MUST be used for link identification. In OSPFv3, the Link ID sub-TLV SHOULD NOT be sent and MUST be ignored upon receipt.

リンクIDサブTLVは、OSPFV2で使用され、リンクのもう一方の端を識別します。OSPFV3では、隣接IDサブTLVをリンク識別に使用する必要があります。OSPFV3では、リンクID sub-tlvを送信しないでください。受信時に無視する必要があります。

4.2. Neighbor ID Sub-TLV
4.2. ネイバーID sub-tlv

In OSPFv2, the Link ID is used to identify the other end of a link. In OSPFv3, the combination of Neighbor Interface ID and Neighbor Router ID is used for neighbor link identification. Both are advertised in the Neighbor ID sub-TLV.

OSPFV2では、リンクIDを使用してリンクのもう一方の端を識別します。OSPFV3では、Neighbor Interface IDとNeighbor Router IDの組み合わせが近隣リンク識別に使用されます。どちらもNeighbor ID sub-tlvに宣伝されています。

Neighbor Interface ID and Neighbor Router ID values are the same as described in RFC 5340 [OSPFV3], A.4.3 Router-LSAs.

近隣インターフェイスIDおよびネイバールーターID値は、RFC 5340 [OSOSPFV3]、A.4.3ルーター-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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              18               |             8                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Neighbor Interface ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Neighbor Router ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Type A 16-bit field set to 18. Length A 16-bit field that indicates the length of the value portion in octets. For this sub-TLV, it is always 8. Value The neighbor's Interface ID and Router ID.

タイプA 16ビットフィールドは18に設定されています。長さの16ビットフィールドは、オクテットの値部分の長さを示します。このサブTLVの場合、常に8です。近隣のインターフェイスIDとルーターIDを大切にします。

Neighbor ID Sub-TLV

ネイバーID sub-tlv

4.3. Local Interface IPv6 Address Sub-TLV
4.3. ローカルインターフェイスIPv6アドレスSub-tlv

The Local Interface IPv6 Address sub-TLV specifies the IPv6 address(es) of the interface corresponding to this link. If there are multiple local addresses assigned to the link, then they MAY all be listed in this sub-TLV. Link-local addresses MUST NOT be included in this sub-TLV.

ローカルインターフェイスIPv6アドレスSub-TLVは、このリンクに対応するインターフェイスのIPv6アドレス(ES)を指定します。リンクに割り当てられた複数のローカルアドレスがある場合、それらはすべてこのサブTLVにリストされる場合があります。Link-Localアドレスは、このサブTLVに含めてはなりません。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              19               |              Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-                                                 -+-+-+-+
      |                                                               |
      +-+-+-+-          Local Interface IPv6 Address           -+-+-+-+
      |                                                               |
      +-+-+-+-                                                 -+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         o                                     |
      |                         o                                     |
      |                         o                                     |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-                                                 -+-+-+-+
      |                                                               |
      +-+-+-+-          Local Interface IPv6 Address           -+-+-+-+
      |                                                               |
      +-+-+-+-                                                 -+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Type A 16-bit field set to 19. Length A 16-bit field that indicates the length of the value portion in octets. For this sub-TLV, it MUST always be a multiple of 16 octets dependent on the number of IPv6 global addresses advertised. Value A list of one or more local IPv6 interface addresses each consuming 16 octets.

タイプA 16ビットフィールドは19に設定されています。長さの16ビットフィールドは、オクテットの値部分の長さを示します。このサブTLVの場合、宣伝されているIPv6グローバルアドレスの数に依存する16のオクテットの倍数でなければなりません。値1つ以上のローカルIPv6インターフェイスのリストは、それぞれ16個のオクテットを消費します。

Local Interface IPv6 Address Sub-TLV

ローカルインターフェイスIPv6アドレスSub-tlv

4.4. Remote Interface IPv6 Address Sub-TLV
4.4. リモートインターフェイスIPv6アドレスSub-TLV

The Remote Interface IPv6 Address sub-TLV advertises the IPv6 address(es) associated with the neighbor's interface. This sub-TLV and the Local Interface IPv6 Address sub-TLV are used to discern amongst parallel links between OSPFv3 routers. If the link type is multi-access, the Remote Interface IPv6 Address MAY be set to ::. Alternately, an implementation MAY choose not to send this sub-TLV. Link-local addresses MUST NOT be advertised in this sub-TLV. Neighbor addresses advertised in link-LSAs with a prefix length of 128 and the LA-bit set MAY be advertised.

リモートインターフェイスIPv6アドレスSub-TLVは、近隣のインターフェイスに関連付けられているIPv6アドレス(ES)を宣伝します。このサブTLVおよびローカルインターフェイスIPv6アドレスSub-TLVは、OSPFV3ルーター間の並列リンクの中で識別するために使用されます。リンクタイプがマルチアクセスの場合、リモートインターフェイスIPv6アドレスを::に設定できます。あるいは、実装では、このサブTLVを送信しないことを選択する場合があります。Link-Localアドレスは、このサブTLVで宣伝してはなりません。Neighborは、リンクLSAで宣伝されている128のプレフィックス長でアドレスを獲得し、LAビットセットが宣伝される場合があります。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              20               |              Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-                                                 -+-+-+-+
      |                                                               |
      +-+-+-+-             Remote Interface IPv6 Address       -+-+-+-+
      |                                                               |
      +-+-+-+-                                                 -+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         o                                     |
      |                         o                                     |
      |                         o                                     |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-                                                 -+-+-+-+
      |                                                               |
      +-+-+-+-             Remote Interface IPv6 Address       -+-+-+-+
      |                                                               |
      +-+-+-+-                                                 -+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Type A 16-bit field set to 20. Length A 16-bit field that indicates the length of the value portion in octets. For this sub-TLV, it MUST be a multiple of 16 octets dependent on the number of IPv6 global addresses advertised. Value A variable-length Remote Interface IPv6 Address list.

タイプA 16ビットフィールドは20に設定されています。長さの16ビットフィールドは、オクテットの値部分の長さを示します。このサブTLVの場合、宣伝されているIPv6グローバルアドレスの数に依存する16のオクテットの倍数でなければなりません。変数長のリモートインターフェイスIPv6アドレスリストを値。

Remote Interface IPv6 Address Sub-TLV

リモートインターフェイスIPv6アドレスSub-TLV

5. Security Considerations
5. セキュリティに関する考慮事項

The function described in this document does not create any new security issues for the OSPFv3 protocol. Security considerations for the base OSPFv3 protocol [OSPFV3] and OSPFv2 Traffic Engineering [TE] are applicable to OSPFv3 Traffic Engineering.

このドキュメントで説明されている機能は、OSPFV3プロトコルの新しいセキュリティ問題を作成しません。Base OSPFV3プロトコル[OSOSPFV3]およびOSPFV2トラフィックエンジニアリング[TE]のセキュリティ上の考慮事項は、OSPFV3トラフィックエンジニアリングに適用できます。

6. Management Considerations
6. 管理上の考慮事項

The typical management interface for routers running the new extensions to OSPF for intra-area Traffic Engineering is Simple Network Management Protocol (SNMP) based. The extra management objects for configuration operations and statistics are defined in [OSPFV3-MIB], and an implementation of the extensions defined in this document SHOULD provide for the appropriate hooks or instrumentation that allow for the MIB objects to be implemented.

エリア内交通工学のために新しい拡張機能をOSPFに実行するルーターの典型的な管理インターフェイスは、単純なネットワーク管理プロトコル(SNMP)ベースです。構成操作と統計の追加管理オブジェクトは[OSPFV3-MIB]で定義されており、このドキュメントで定義されている拡張機能の実装は、MIBオブジェクトを実装できる適切なフックまたは計装を提供する必要があります。

The following MIB variables have been added to the OSPFv3 MIB in support of TE:

TEをサポートするために、次のMIB変数がOSPFV3 MIBに追加されました。

ospfv3AreaTEEnabled This TruthValue MIB variable in the ospfv3AreaEntry table entry indicates whether or not OSPFv3 TE advertisement for OSPFv3 interfaces is enabled for the corresponding area. The default value is FALSE.

OSPFV3AREATEENABLED OSPFV3AREAENTRYテーブルエントリのこの真実値MIB変数は、対応する領域でOSPFV3インターフェイスのOSPFV3 TE広告が有効になっているかどうかを示します。デフォルト値はfalseです。

ospfv3IfTEDisabled This TruthValue MIB variable in the ospfv3IfEntry table entry indicates whether or not OSPFv3 TE advertisement for OSPFv3 for the corresponding interface is disabled. This MIB variable is only applicable if ospfv3AreaTEEnabled is TRUE for the interface's area. The default value is FALSE.

OSPFV3IFTEDISABLED OSPFV3IFENTRYテーブルエントリのこの真実値MIB変数は、対応するインターフェイスのOSPFV3のOSPFV3 TE広告が無効になっているかどうかを示します。このMIB変数は、Interfaceの領域にOSPFV3Areateenabledが当てはまる場合にのみ適用されます。デフォルト値はfalseです。

7. IANA Considerations
7. IANAの考慮事項

The following IANA assignments have been made from existing registries:

次のIANAの割り当ては、既存のレジストリから行われました。

1. The OSPFv3 LSA type function code 10 has been assigned to the OSPFv3 Intra-Area-TE-LSA.

1. OSPFV3 LSAタイプ関数コード10は、OSPFV3 Intra-AREA-TE-LSAに割り当てられています。

2. The Router IPv6 Address TLV type 3 has been assigned from the existing registry for OSPF TE TLVs.

2. Router IPv6アドレスTLVタイプ3は、OSPF TLVの既存のレジストリから割り当てられています。

3. The Neighbor ID (18), Local Interface IPv6 Address (19), and Remote Interface IPv6 Address (20) sub-TLVs have been assigned from the existing registry for OSPF TE sub-TLVs.

3. 近隣ID(18)、ローカルインターフェイスIPv6アドレス(19)、およびリモートインターフェイスIPv6アドレス(20)サブTLVは、OSPF TEサブTLVの既存のレジストリから割り当てられています。

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献

[OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[OSPFV2] Moy、J。、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。

[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.

[OSPFV3] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。

[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC-Keywords] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.

[Te] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering(TE)拡張オブOSPFバージョン2」、RFC 3630、2003年9月。

8.2. Informative References
8.2. 参考引用

[GMPLS] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.

[GMPLS] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)をサポートするOSPF拡張」、RFC 4203、2005年10月。

[OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008.

[Opaque] Berger、L.、Bryskin、I.、Zinin、A。、およびR. Coltun、「OSPF Opaque LSAオプション」、RFC 5250、2008年7月。

[OSPFV3-MIB] Joyal, D. and V. Manral, "Management Information Base for OSPFv3", Work in Progress, September 2007.

[OSPFV3-MIB] Joyal、D。およびV. Manral、「OSPFV3の管理情報基盤」、2007年9月、作業中。

[TE-DIFF] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.

[Te-Diff] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P.、J。Heinanen、 "Multi-protocol差別化されたサービスのラベルスイッチング(MPLS)サポート」、RFC 3270、2002年5月。

Acknowledgments

謝辞

Thanks to Kireeti Kompella, Alex Zinin, Adrian Farrell, and Mach Chen for their comments.

Kireeti Kompella、Alex Zinin、Adrian Farrell、Mach Chenのコメントに感謝します。

Thanks to Vijay K. Gurbani for providing the General Area Review Team (Gen-ART) review.

General Area Review Team(Gen-Art)レビューを提供してくれたVijay K. Gurbaniに感謝します。

Thanks to Rob Austein for providing the Security Directorate (secdir) review.

セキュリティ局(SECDIR)レビューを提供してくれたRob Austeinに感謝します。

Thanks to Dan Romascanu for providing the text for the "Management Considerations" section in the context of the IESG review.

IESGレビューのコンテキストで「管理上の考慮事項」セクションにテキストを提供してくれたDan Romascanuに感謝します。

Thanks to Dave Ward, Tim Polk, Jari Arkko, and Pasi Eronen for comments and relevant discussion in the context of the IESG review.

Dave Ward、Tim Polk、Jari Arkko、およびPasi Eronenに、IESGレビューの文脈でのコメントと関連する議論に感謝します。

The RFC text was produced using Marshall Rose's xml2rfc tool.

RFCテキストは、Marshall RoseのXML2RFCツールを使用して作成されました。

Authors' Addresses

著者のアドレス

Kunihiro Ishiguro IP Infusion, Inc. 1188 East Arques Avenue, Sunnyvale, CA 94085 USA

Kunihiro Ishiguro IP Infusion、Inc。1188 East Arques Avenue、Sunnyvale、CA 94085 USA

   EMail: kunihiro@ipinfusion.com
        

Vishwas Manral IP Infusion, Inc #41, Ground Floor, 5th Cross Road 8th Main Road Vasanth Nagar, Bangalore 560052 India

Vishwas Manral IP Implusion、Inc#41、1階、5番目のクロスロード8th Main Road Vasanth Nagar、Bangalore 560052 India

   EMail: vishwas@ipinfusion.com
        

Alan Davey Data Connection Limited 100 Church Street Enfield EN2 6BQ UK

Alan Davey Data Connection Limited 100 Church Street Enfield EN2 6BQ UK

   EMail: Alan.Davey@dataconnection.com
        

Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519 USA

ACEE LINDEM REDBACK NETWORKS 102 CARRIC BEND COURT CARY、NC 27519 USA

   EMail: acee@redback.com
        

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への情報をお問い合わせください。