原文

[要約] RFC 4220は、トラフィックエンジニアリング(TE)において、ネットワークリンクの属性(利用可能帯域、遅延、コストなど)をSNMPで管理・監視するためのMIB(TE-LMIB)を定義しています。経路計算エンジンが最新のネットワーク状態を把握し、最適なパスを選択するためのデータ基盤を提供します。

Network Working Group                                           M. Dubuc
Request for Comments: 4220                                    Consultant
Category: Standards Track                                      T. Nadeau
                                                           Cisco Systems
                                                                 J. Lang
                                                             Sonos, Inc.
                                                           November 2005
        

Traffic Engineering Link Management Information Base

トラフィックエンジニアリング (TE) リンクのための管理情報ベース (MIB)

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 Internet Society (2005).

Copyright(c)The Internet Society(2005)。

Abstract

概要

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document.

このメモは、インターネットコミュニティのネットワーク管理プロトコルで使用するための管理情報ベース(MIB)の一部を定義します。特に、MPLSトラフィックエンジニアリング(TE)ドキュメントのリンクバンドリングで説明されているように、TEリンクをモデリングするための管理オブジェクトについて説明します。

Table of Contents

目次

   1. The Internet-Standard Management Framework ......................2
   2. Introduction ....................................................3
   3. Terminology .....................................................3
   4. Feature Checklist ...............................................4
   5. Outline .........................................................4
   6. Brief Description of MIB Objects ................................4
      6.1. teLinkTable ................................................4
      6.2. teLinkDescriptorTable ......................................4
      6.3. teLinkSrlgTable ............................................5
      6.4. teLinkBandwidthTable .......................................5
      6.5. componentLinkTable .........................................5
      6.6. componentLinkDescriptorTable ...............................5
      6.7. componentLinkBandwidthTable ................................5
   7. Example of Bundled Link Setup ...................................5
   8. Application of the Interfaces Group to TE Links .................9
      8.1. Support of the TE Link Layer by ifTable ....................9
      8.2. Using ifStackTable ........................................11
      8.3. Applicability of ifRcvAddressTable ........................13
   9. TE Link MIB Module Definitions .................................13
   10. Security Considerations .......................................50
   11. Contributors ..................................................51
   12. Acknowledgements ..............................................51
   13. IANA Considerations ...........................................51
       13.1. IANA Considerations for the TE-LINK-STD-MIB .............51
   14. References ....................................................51
       14.1. Normative References ....................................51
       14.2. Informative References ..................................52
        
1. The Internet-Standard Management Framework
1. インターネット標準の管理フレームワーク

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].

現在のインターネット標準管理フレームワークを説明するドキュメントの詳細な概要については、RFC 3410 [RFC3410]のセクション7を参照してください。

Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].

管理されたオブジェクトは、管理情報ベースまたはMIBと呼ばれる仮想情報ストアからアクセスされます。MIBオブジェクトは通常、単純なネットワーク管理プロトコル(SNMP)からアクセスされます。MIBのオブジェクトは、管理情報の構造(SMI)で定義されたメカニズムを使用して定義されます。このメモは、STD 58、RFC 2578 [RFC2578]、STD 58、RFC 2579 [RFC2579]およびSTD 58、RFC 2580 [RFC2580]に記載されているSMIV2に準拠したMIBモジュールを指定します。

2. Introduction
2. はじめに

OSPF [RFC3630], Generalized MPLS (GMPLS) [RFC3471], and the Link Management Protocol (LMP) [RFC4204] use the concept of traffic engineering (TE) links to abstract link properties. The effect of this approach is a reduction in the amount of routing information exchanged in the network, which improves routing scalability. In addition, the use of TE links allows the implementation of new capabilities such as link protection.

OSPF [RFC3630]、一般化されたMPLS(GMPLS)[RFC3471]、およびリンク管理プロトコル(LMP)[RFC4204]は、抽象リンクプロパティへのトラフィックエンジニアリング(TE)リンクの概念を使用します。このアプローチの効果は、ネットワークで交換されるルーティング情報の量を減らすことであり、ルーティングのスケーラビリティが向上します。さらに、TEリンクを使用すると、リンク保護などの新しい機能を実装できます。

In this document, we present a MIB module that can be used to manage TE links and their extension, the bundled link. This MIB module enables both the configuration and the performance monitoring of TE links and the bundled link.

このドキュメントでは、TEリンクとその拡張機能であるバンドルリンクを管理するために使用できるMIBモジュールを提示します。このMIBモジュールは、TEリンクの構成とパフォーマンス監視とバンドルリンクの両方を有効にします。

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] で説明されているように解釈されるものとします。

3. Terminology
3. 用語

This document uses terminology from the documents describing link bundling [RFC4201] and GMPLS [RFC3945].

このドキュメントでは、リンクバンドリング[RFC4201]およびGMPLS [RFC3945]を説明するドキュメントの用語を使用しています。

The link bundling feature is designed to aggregate one or more similar entities between a node pair into a bundled link [RFC4201]. In RFC 4201, those entities are referred to as TE links. A TE link is a subinterface capable of carrying MPLS traffic engineered traffic. A TE Link may be comprised of only one underlying component link. In cases where more than one component links are to be combined, multiple component links should be created with differing priorities to indicate hot-standby or parallel utilization.

Link Bundling機能は、ノードペア間で1つ以上の類似のエンティティをバンドルリンク[RFC4201]に集約するように設計されています。RFC 4201では、これらのエンティティはTEリンクと呼ばれます。TEリンクは、MPLSトラフィックエンジニアリングトラフィックを運ぶことができるサブインターフェイスです。TEリンクは、1つの基礎となるコンポーネントリンクのみで構成されている場合があります。複数のコンポーネントリンクを組み合わせる場合は、ホットスタンドーまたは並列利用を示すために、異なる優先順位で複数のコンポーネントリンクを作成する必要があります。

A bundled link is another kind of Traffic Engineering (TE) link (see [RFC4203]). A link bundle is a subinterface that binds the traffic of a group of one or more TE links. There should be more than one TE Link in a link bundle, but this is not a requirement. Furthermore, if there are more than one TE links in a link bundle at some time, and at some point later, all but one of the links are deleted, the agent may choose to either delete the link bundle, or it may choose to leave it intact. Traffic counters on a link bundle are cumulative for all subinterfaces that it binds together.

バンドルされたリンクは、別の種類のトラフィックエンジニアリング(TE)リンクです([RFC4203]を参照)。リンクバンドルは、1つ以上のTEリンクのグループのトラフィックをバインドするサブインターフェイスです。リンクバンドルには複数のTEリンクがあるはずですが、これは要件ではありません。さらに、ある時点でリンクバンドルに複数のTEリンクがあり、ある時点でリンクの1つを除くすべてが削除された場合、エージェントはリンクバンドルを削除するか、離れることを選択できます。それは無傷です。リンクバンドルのトラフィックカウンターは、結合するすべてのサブインターフェイスに対して累積的です。

4. Feature Checklist
4. 機能チェックリスト

The TE Link MIB module (TE-LINK-STD-MIB) is designed to satisfy the following requirements and constraints:

TE Link MIBモジュール(TE-Link-STD-MIB)は、次の要件と制約を満たすように設計されています。

- The MIB module supports the management of TE links, including bundled links.

- MIBモジュールは、バンドルされたリンクを含むTEリンクの管理をサポートしています。

- Support is provided for configuration of traffic engineering parameters associated with TE links.

- TEリンクに関連するトラフィックエンジニアリングパラメーターの構成のためのサポートが提供されます。

- The MIB module is used to monitor the priority-based component link and TE link bandwidth values.

- MIBモジュールは、優先度ベースのコンポーネントリンクとTEリンク帯域幅の値を監視するために使用されます。

5. Outline
5. 概要

Configuring bundled links involves the following steps:

バンドルリンクの構成には、次の手順が含まれます。

- Creating a bundled link.

- バンドルされたリンクを作成します。

- Creating TE links.

- TEリンクの作成。

- Optionally specifying the shared risk link groups associated with the TE links.

- オプションで、TEリンクに関連付けられた共有リスクリンクグループを指定します。

- Configuring the component links including the bandwidth parameters and associating the component links with the appropriate TE link.

- 帯域幅パラメーターを含むコンポーネントリンクを構成し、コンポーネントリンクを適切なTEリンクに関連付けます。

- Associating the TE links with the appropriate bundled link.

- TEリンクを適切なバンドルリンクに関連付けます。

6. Brief Description of MIB Objects
6. MIBオブジェクトの簡単な説明

Sections 6.1 - 6.4 describe objects pertaining to TE links while Sections 6.5 - 6.7 describe objects pertaining to component links. The MIB objects were derived from the link bundling document [RFC4201].

セクション6.1-6.4は、TEリンクに関連するオブジェクトについて説明し、セクション6.5〜6.7はコンポーネントリンクに関連するオブジェクトを記述します。MIBオブジェクトは、リンクバンドリングドキュメント[RFC4201]から派生しました。

6.1. teLinkTable
6.1. teLinkTable

This table represents the TE links, including bundled links, and their generic traffic engineering parameters.

この表は、バンドルされたリンクや一般的なトラフィックエンジニアリングパラメーターを含むTEリンクを表しています。

6.2. teLinkDescriptorTable
6.2. teLinkDescriptorTable

This table represents the TE link interface switching capability descriptors.

このテーブルは、TEリンクインターフェイススイッチング機能記述子を表します。

6.3. teLinkSrlgTable
6.3. teLinkSrlgTable

This table represents the shared risk link groups (SRLGs) associated with TE links.

この表は、TEリンクに関連する共有リスクリンクグループ(SRLG)を表します。

6.4. teLinkBandwidthTable
6.4. TelinkBandwidtable

This table specifies the priority-based bandwidth traffic engineering parameters associated with TE links.

この表は、TEリンクに関連する優先順位ベースの帯域幅トラフィックエンジニアリングパラメーターを指定します。

6.5. componentLinkTable
6.5. componentLinkTable

This table enumerates the component links and their generic traffic engineering parameters.

このテーブルは、コンポーネントリンクとその一般的なトラフィックエンジニアリングパラメーターを列挙します。

6.6. componentLinkDescriptorTable
6.6. componentLinkDescriptorTable

This table enumerates the interface switching capability descriptors that each component link supports.

このテーブルは、各コンポーネントリンクがサポートするインターフェイススイッチング機能記述子を列挙します。

6.7. componentLinkBandwidthTable
6.7. componentLinkBandwidthTable

The component link bandwidth table specifies the priority-based bandwidth values associated with the component links.

コンポーネントリンク帯域幅テーブルは、コンポーネントリンクに関連付けられた優先順位ベースの帯域幅値を指定します。

Component links that belong to the same TE link must be compatible. If these two tables are managed independently, mechanisms should be put in place to ensure consistency between the two tables. TE links that form a bundled link must have compatible traffic engineering parameters (resource class, link metric, and protection type).

同じTEリンクに属するコンポーネントリンクは互換性がなければなりません。これらの2つのテーブルが独立して管理されている場合、2つのテーブル間の一貫性を確保するために、メカニズムを導入する必要があります。バンドルリンクを形成するTEリンクには、互換性のあるトラフィックエンジニアリングパラメーター(リソースクラス、リンクメトリック、および保護タイプ)が必要です。

The link descriptors of the teLinkDescriptorTable can be derived from the link descriptors of the componentLinkDescrTable.

teLinkDescriptorTableのリンク記述子は、componentLinkDescrTableのリンク記述子から導出できます。

Some of the bandwidth parameters of the teLinkTable, teLinkDescriptorTable, teLinkBandwidthTable are derived from the bandwidth parameters of the componentLinkTable, componentLinkDescriptorTable, and componentLinkBandwidthTable (maximum reservable bandwidth, minimum LSP bandwidth, maximum LSP bandwidth at specified priority, and unreserved bandwidth).

teLinkTable、teLinkDescriptorTable、teLinkBandwidthTableの帯域幅パラメーターの一部は、コンポーネントリンクテーブル、componentLinkDescriptorTable、およびComponentLinkWidthtableの帯域幅パラメーターから派生しています。

7. バンドルされたリンクセットアップの例
8. インターフェイスグループのTEリンクへの適用
8.1. ifTableによるTEリンクレイヤーのサポート
8.2. Using ifStackTable
8.2. ifStackTableの使用

This section describes, by example, how to use the ifStackTable to represent the relationship of TE links with underlying TE-enabled interfaces. Implementors of the stack table for TE link interfaces should look at the appropriate RFC for the service being stacked on TE links. The examples given below are for illustration purposes only.

このセクションでは、たとえば、ifStackTableを使用してTEリンクの基礎となるTE対応インターフェイスとの関係を表す方法について説明します。TEリンクインターフェイスのスタックテーブルの実装者は、TEリンクに積み重ねられているサービスに適したRFCを調べる必要があります。以下に示す例は、イラストのみを目的としています。

Example: MPLS is being carried on a bundled TE link. The bundled TE link represents a 1:1 optical transport interface.

例:MPLSは、バンドルされたTEリンクで運ばれています。バンドルされたTEリンクは、1:1の光学輸送インターフェイスを表します。

In this example, the component link is a TE link. The two component links/TE links are grouped in a bundled link.

この例では、コンポーネントリンクはTEリンクです。2つのコンポーネントリンク/TEリンクは、バンドルリンクにグループ化されています。

   +-------------------------------------------------------------------+
   | MPLS interface ifType = mpls(166)                                 |
   | ifIndex = 1                                                       |
   +-------------------------------------------------------------------+
   | TE link (bundled link) ifType = teLink(200)                       |
   | ifIndex = 2                                                       |
   +--------------------------------+-+--------------------------------+
   | TE link ifType = teLink(200)   | | TE link ifType = teLink(200)   |
   | ifIndex = 3                    | | ifIndex = 4                    |
   +--------------------------------+ +--------------------------------+
   | Component link                 | | Component link                 |
   | ifType = opticalTransport(196) | | ifType = opticalTransport(196) |
   | ifIndex = 5                    | | ifIndex = 6                    |
   +--------------------------------+ +--------------------------------+
   The assignment of the index values could, for example, be:
        
            ifIndex  Description
            1        mpls             (type 166)
            2        teLink           (type 200)
            3        teLink           (type 200)
            4        teLink           (type 200)
            5        opticalTransport (type 196)
            6        opticalTransport (type 196)
        

The ifStackTable is then used to show the relationships between the various interfaces.

ifStackTableは、さまざまなインターフェイス間の関係を表示するために使用されます。

ifStackTable Entries

ifStackTableエントリ

            HigherLayer   LowerLayer
            0             1
            1             2
            2             3
            2             4
            3             5
            4             6
            5             0
            6             0
        

In the case where MPLS is using a single TE link, then the upper TE link layer (link bundle) is not required.

MPLSが単一のTEリンクを使用している場合、上部TEリンクレイヤー(リンクバンドル)は必要ありません。

      +-----------------------------------+
      | MPLS interface ifType = mpls(166) |
      +-----------------------------------+
      | TE link ifType = teLink(200)      |
      +-----------------------------------+
      | Component link                    |
      | ifType = opticalTransport(196)    |
      +-----------------------------------+
        

The assignment of the index values could for example be:

たとえば、インデックス値の割り当ては次のとおりです。

            ifIndex  Description
            1        mpls             (type 166)
            2        teLink           (type 200)
            3        opticalTransport (type 196)
        

The ifStackTable is then used to show the relationships between the various interfaces.

ifStackTableは、さまざまなインターフェイス間の関係を表示するために使用されます。

ifStackTable Entries

ifStackTableエントリ

            HigherLayer   LowerLayer
            0             1
            1             2
            2             3
            3             0
        
8.3. Applicability of ifRcvAddressTable
8.3. ifRcvAddressTableの適用可能性

TE link interfaces are logical interfaces with no media-level addresses. As such, the ifRcvAddressTable is not applicable to these interfaces.

TEリンクインターフェイスは、メディアレベルのアドレスがない論理インターフェイスです。そのため、ifRcvAddressTableはこれらのインターフェイスに適用できません。

9. TEリンクMIBモジュール定義
10. Security Considerations
10. セキュリティに関する考慮事項

There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability:

このMIBモジュールには、読み取りワイトおよび/またはread-Createの最大アクセス句を備えた管理オブジェクトが多数あります。このようなオブジェクトは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしの非セキュア環境でのセット操作のサポートは、ネットワーク操作に悪影響を与える可能性があります。これらはテーブルとオブジェクトであり、その感度/脆弱性です。

- All the tables in this MIB module have routing information in them, so they all have the same security attributes. Unauthorized changes to attributes of these tables can disrupt resource allocation in the network.

- このMIBモジュールのすべてのテーブルにはルーティング情報が含まれているため、それらはすべて同じセキュリティ属性を持っています。これらのテーブルの属性に対する不正な変更は、ネットワーク内のリソース割り当てを破壊する可能性があります。

Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability:

このMIBモジュールの読み取り可能なオブジェクトのいくつか(つまり、アクセスできないこと以外に最大アクセスを備えたオブジェクト)は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのオブジェクトへのアクセスを取得および/または通知することさえ制御し、SNMPを介してネットワーク上に送信するときにこれらのオブジェクトの値を暗号化することも重要です。これらはテーブルとオブジェクトであり、その感度/脆弱性です。

- IP address entries in the teLinkTable (teLinkLocalIpAddr and teLinkRemoteIpAddr) may reveal the internals of a network provider IP address space.

- teLinkTable(teLinkLocalIpAddrおよびteLinkRemoteIpAddr)のIPアドレスエントリは、ネットワークプロバイダーのIPアドレススペースの内部を明らかにする可能性があります。

SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.

SNMPV3以前のSNMPバージョンには、適切なセキュリティは含まれていませんでした。ネットワーク自体が(たとえばIPSECを使用して)安全である場合でも、それでもセキュアネットワークで誰がアクセスして取得/セット(読み取り/変更/作成/削除/削除)を制御することはできません。MIBモジュール。

It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).

実装者は、SNMPV3暗号化メカニズム(認証とプライバシー用)の完全なサポートを含む、SNMPV3フレームワーク([RFC3410]、セクション8を参照)で提供されるセキュリティ機能を考慮することをお勧めします。

Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.

さらに、SNMPV3より前のSNMPバージョンの展開は推奨されません。代わりに、SNMPV3を展開し、暗号化セキュリティを有効にすることをお勧めします。その場合、このMIBモジュールのインスタンスへのアクセスを提供するSNMPエンティティが、実際に取得または設定する正当な権利を持つプリンシパル(ユーザー)にのみオブジェクトにアクセスできるように適切に構成されていることを保証するのは、顧客/オペレーターの責任です(変更を変更します(変更)/作成/削除)それら。

11. Contributors
11. 貢献者

Sudheer Dharanikota EMail: sudheer@ieee.org

Sudheer Dharanikotaメール:sudheer@ieee.org

12. Acknowledgements
12. 謝辞

The authors would like to acknowledge the contribution of Dmitry Ryumkin.

著者は、Dmitry Ryumkinの貢献を認めたいと考えています。

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

The following "IANA Considerations" subsection requests IANA for a new assignment. New assignments can only be made via Standards Action as specified in [RFC2434].

次の「IANAの考慮事項」サブセクションは、IANAに新しい割り当てを要求します。新しい割り当ては、[RFC2434]で指定されているように、標準アクションによってのみ行うことができます。

13.1. TE-Link-STD-MIBのIANAの考慮事項
14. References
14. 参考文献
14.1. Normative References
14.1. 引用文献

[IANAifType] "IANAifType MIB Module", http://www.iana.org/assignments/ianaiftype-mib.

[IANAifType] "IANAifType mib module"、http://www.iana.org/assignments/ianaiftype-mib。

[IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653- 8).

[IEEE] IEEE、「バイナリフローティングポイント算術のIEEE標準」、標準754-1985、1985(ISBN 1-5593-7653-8)。

[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月。

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[RFC2434] Narten, T. and H. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。

[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder、「管理情報の構造バージョン2(SMIV2)」、STD 58、RFC 2578、1999年4月。

[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.

[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder、「SMIV2のテキストコンベンション」、STD 58、RFC 2579、1999年4月。

[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.

[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder、「SMIV2の適合ステートメント」、STD 58、RFC 2580、1999年4月。

[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.

[RFC2863] McCloghrie, K. and F. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。

[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.

[RFC3471] Berger, L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナル伝達機能説明」、RFC 3471、2003年1月。

[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. and D. Yeung、「Traffic Engineering(TE)拡張拡張版」、RFC 3630、2003年9月。

[RFC4201] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.

[RFC4201] Kompella, K., Rekhter, Y. and L. Berger、「MPLS Traffic Engineering(TE)のリンクバンドリング」、RFC 4201、2005年10月。

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

[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)をサポートするルーティング拡張機能」、RFC 4202、2005年10月。

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

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

[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

[RFC4206] Kompella, K. and Y. Rekhter、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)トラフィックエンジニアリング(TE)を備えたラベルスイッチ付きパス(LSP)階層」、2005年10月。

[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.

[RFC4204] Lang, J., Ed.、「Link Management Protocol(LMP)」、RFC 4204、2005年10月。

14.2. Informative References
14.2. 参考引用

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。

[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.

[RFC3945] Mannie, E.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)アーキテクチャ」、RFC 3945、2004年10月。

Authors' Addresses

著者のアドレス

Martin Dubuc

マーティン・デュブック

   EMail: mdubuc@ncf.ca
        

Thomas D. Nadeau Cisco Systems 1414 Massachusetts Ave. Boxborough, MA 01719

トーマス・D・ナドー・シスコ・システム1414マサチューセッツ・アベニュー・ボックスボロー、マサチューセッツ州01719

   Phone: +1-978-244-3051
   EMail: tnadeau@cisco.com
        

Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra St. Santa Barbara, CA 93101

Jonathan P. Lang Sonos、Inc。223 E. de la Guerra St. Santa Barbara、CA 93101

   EMail: jplang@ieee.org
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2005).

Copyright(c)The Internet Society(2005)。

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

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織(もしあれば)が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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エディター機能の資金は現在、インターネット協会によって提供されています。