Internet Engineering Task Force (IETF)                          F. Zhang
Request for Comments: 7580                                        Y. Lee
Category: Standards Track                                         J. Han
ISSN: 2070-1721                                                   Huawei
                                                            G. Bernstein
                                                       Grotto Networking
                                                                   Y. Xu
                                                               June 2015

OSPF-TE Extensions for General Network Element Constraints




Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time division (e.g., Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control of GMPLS.

一般化マルチプロトコルラベルスイッチング(GMPLS)は、パケットスイッチング(MPLSなど)、時分割(同期光ネットワーク/同期デジタル階層(SONET / SDH)、光トランスポートネットワーク(OTN)など)を制御するために使用できます。 )、波長(ラムダ)、および空間スイッチング(たとえば、入力ポートまたはファイバーから出力ポートまたはファイバーへ)。これらのテクノロジーの一部では、ネットワーク要素とリンクが、非対称スイッチ接続、非ローカルラベル割り当て、リンクのラベル範囲制限などの追加のルーティング制約を課す場合があります。このドキュメントでは、GMPLSの制御下でこれらの種類の制約をサポートするためのOpen Shortest Path First(OSPF)ルーティングプロトコル拡張について説明します。

Status of This Memo


This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents


   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................3
   2. Node Information ................................................3
      2.1. Connectivity Matrix ........................................4
   3. Link Information ................................................4
      3.1. Port Label Restrictions ....................................5
   4. Routing Procedures ..............................................5
   5. Scalability and Timeliness ......................................6
      5.1. Different Sub-TLVs into Multiple LSAs ......................6
      5.2. Decomposing a Connectivity Matrix into Multiple Matrices ...6
   6. Security Considerations .........................................7
   7. Manageability ...................................................7
   8. IANA Considerations .............................................8
      8.1. Node Information ...........................................8
      8.2. Link Information ...........................................8
   9. References ......................................................9
      9.1. Normative References .......................................9
      9.2. Informative References ....................................10
   Acknowledgments ...................................................11
   Contributors ......................................................11
   Authors' Addresses ................................................12
1. Introduction
1. はじめに

Some data-plane technologies that require the use of a GMPLS control plane impose additional constraints on switching capability and label assignment. In addition, some of these technologies should be capable of performing non-local label assignment based on the nature of the technology, e.g., wavelength continuity constraint in Wavelength Switched Optical Networks (WSONs) [RFC6163]. Such constraints can lead to the requirement for link-by-link label availability in path computation and label assignment.


[RFC7579] provides efficient encodings of information needed by the routing and label assignment process in technologies such as WSON. These encodings are potentially applicable to a wider range of technologies as well. The encoding provided in [RFC7579] is protocol-neutral and can be used in routing, signaling, and/or Path Computation Element communication protocol extensions.

[RFC7579]は、WSONなどのテクノロジーのルーティングおよびラベル割り当てプロセスに必要な情報の効率的なエンコーディングを提供します。これらのエンコーディングは、より広い範囲のテクノロジーにも適用できる可能性があります。 [RFC7579]で提供されるエンコーディングはプロトコルに依存せず、ルーティング、シグナリング、および/またはパス計算エレメント通信プロトコル拡張で使用できます。

This document defines extensions to the OSPF routing protocol based on [RFC7579] to enhance the Traffic Engineering (TE) properties of GMPLS TE that are defined in [RFC3630], [RFC4202], and [RFC4203]. The enhancements to the TE properties of GMPLS TE links can be advertised in OSPF-TE Link State Advertisements (LSAs). The TE LSA, which is an opaque LSA with area flooding scope [RFC3630], has only one top-level Type-Length-Value (TLV) triplet and has one or more nested sub-TLVs for extensibility. The top-level TLV can take one of three values: Router Address [RFC3630], Link [RFC3630], or Node Attribute [RFC5786]. In this document, we enhance the sub-TLVs for the Link TLV in support of the general network element constraints under the control of GMPLS.

このドキュメントは、[RFC7579]に基づくOSPFルーティングプロトコルの拡張を定義して、[RFC3630]、[RFC4202]、および[RFC4203]で定義されているGMPLS TEのトラフィックエンジニアリング(TE)プロパティを拡張します。 GMPLS TEリンクのTEプロパティの拡張機能は、OSPF-TEリンク状態アドバタイズメント(LSA)でアドバタイズできます。エリアフラッディングスコープ[RFC3630]を備えた不透明なLSAであるTE LSAには、トップレベルのType-Length-Value(TLV)トリプレットが1つだけあり、拡張性のために1つ以上のネストされたサブTLVがあります。トップレベルのTLVは、ルーターアドレス[RFC3630]、リンク[RFC3630]、またはノード属性[RFC5786]の3つの値のいずれかを取ります。このドキュメントでは、GMPLSの制御下にある一般的なネットワーク要素の制約をサポートするために、リンクTLVのサブTLVを拡張します。

The detailed encoding of OSPF extensions is not defined in this document. [RFC7579] provides encoding details.

OSPF拡張の詳細なエンコーディングは、このドキュメントでは定義されていません。 [RFC7579]はエンコーディングの詳細を提供します。

1.1. Conventions Used in This Document
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 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

2. Node Information
2. ので いんふぉrまちおん

According to [RFC7579], the additional node information representing node switching asymmetry constraints includes device type and connectivity matrix. Except for the device type, which is defined in [RFC7579], the other pieces of information are defined in this document.

[RFC7579]によると、ノードスイッチングの非対称制約を表す追加のノード情報には、デバイスタイプと接続マトリックスが含まれます。 [RFC7579]で定義されているデバイスタイプを除き、他の情報はこのドキュメントで定義されています。

Per [RFC7579], this document defines the Connectivity Matrix sub-TLV of the Node Attribute TLV defined in [RFC5786]. The new sub-TLV has Type 14.


Depending on the control-plane implementation being used, the Connectivity Matrix sub-TLV may be optional in some specific technologies, e.g., WSON networks. Usually, for example, in WSON networks, the Connectivity Matrix sub-TLV may be advertised in the LSAs since WSON switches are currently asymmetric. If no Connectivity Matrix sub-TLV is included, it is assumed that the switches support symmetric switching.


2.1. Connectivity Matrix
2.1. 接続マトリックス

If the switching devices supporting certain data-plane technology are asymmetric, it is necessary to identify which input ports and labels can be switched to some specific labels on a specific output port.


The connectivity matrix, which can represent either the potential connectivity matrix for asymmetric switches (e.g., Reconfigurable Optical Add/Drop Multiplexers (ROADMs) and such) or fixed connectivity for an asymmetric device such as a multiplexer as defined in [RFC7446], is used to identify these restrictions.

[RFC7446]で定義されているように、非対称スイッチ(例:Reconfigurable Optical Add / Drop Multiplexers(ROADMs)など)の潜在的な接続マトリックス、またはマルチプレクサなどの非対称デバイスの固定接続のいずれかを表すことができる接続マトリックスが使用されます。これらの制限を識別するため。

The Connectivity Matrix is a sub-TLV of the Node Attribute TLV. The length is the length of the value field in octets. The meaning and format of this sub-TLV value field are defined in Section 2.1 of [RFC7579]. One sub-TLV contains one matrix. The Connectivity Matrix sub-TLV may occur more than once to contain multiple matrices within the Node Attribute TLV. In addition, a large connectivity matrix can be decomposed into smaller sub-matrices for transmission in multiple LSAs as described in Section 5.

接続マトリックスは、ノード属性TLVのサブTLVです。長さはオクテット単位の値フィールドの長さです。このサブTLV値フィールドの意味と形式は、[RFC7579]のセクション2.1で定義されています。 1つのサブTLVには1つのマトリックスが含まれます。接続属性サブTLVは、ノード属性TLV内に複数の行列を含むために複数回発生する場合があります。さらに、セクション5で説明するように、複数のLSAで送信するために、大きな接続性マトリックスを小さなサブマトリックスに分解できます。

3. Link Information
3. リンク情報

The most common link sub-TLVs nested in the top-level Link TLV are already defined in [RFC3630] and [RFC4203]. For example, Link ID, Administrative Group, Interface Switching Capability Descriptor (ISCD), Link Protection Type, Shared Risk Link Group (SRLG), and Traffic Engineering Metric are among the typical link sub-TLVs.


Per [RFC7579], this document defines the Port Label Restrictions sub-TLV of the Link TLV defined in [RFC3630]. The new sub-TLV has Type 34.


Generally, all the sub-TLVs above are optional, depending on control-plane implementations being used. The Port Label Restrictions sub-TLV will not be advertised when there are no restrictions on label assignment.


3.1. Port Label Restrictions
3.1. ポートラベルの制限

Port label restrictions describe the label restrictions that the network element (node) and link may impose on a port. These restrictions represent what labels may or may not be used on a link and are intended to be relatively static. For increased modeling flexibility, port label restrictions may be specified relative to the port in general or to a specific connectivity matrix.


For example, the port label restrictions describe the wavelength restrictions that the link and various optical devices such as Optical Cross-Connects (OXCs), ROADMs, and waveband multiplexers may impose on a port in WSON. These restrictions represent which wavelengths may or may not be used on a link and are relatively static. Detailed information about port label restrictions is provided in [RFC7446].


The Port Label Restrictions sub-TLV is a sub-TLV of the Link TLV. The length is the length of value field in octets. The meaning and format of this sub-TLV value field are defined in Section 2.2 of [RFC7579]. The Port Label Restrictions sub-TLV may occur more than once to specify a complex port constraint within the Link TLV.


4. Routing Procedures
4. ルーティング手順

All sub-TLVs are nested in top-level TLV(s) and contained in Opaque LSAs. The flooding rules of Opaque LSAs are specified in [RFC2328], [RFC5250], [RFC3630], and [RFC4203].

すべてのサブTLVはトップレベルのTLVにネストされ、不透明LSAに含まれています。 Opaque LSAのフラッディングルールは、[RFC2328]、[RFC5250]、[RFC3630]、および[RFC4203]で指定されています。

Considering the routing scalability issues in some cases, the routing protocol should be capable of supporting the separation of dynamic information from relatively static information to avoid unnecessary updates of static information when dynamic information is changed. A standards-compliant approach is to separate the dynamic information sub-TLVs from the static information sub-TLVs, each nested in a separate top-level TLV (see [RFC3630] and [RFC5786]), and advertise them in the separate OSPF-TE LSAs.

場合によってはルーティングのスケーラビリティの問題を考慮すると、ルーティング情報は、動的情報が変更されたときに静的情報が不必要に更新されないように、動的情報と比較的静的な情報の分離をサポートできる必要があります。標準に準拠したアプローチは、動的情報サブTLVを静的情報サブTLVから分離し、それぞれを個別のトップレベルTLVにネストし([RFC3630]および[RFC5786]を参照)、それらを別々のOSPF-にアドバタイズします。 TE LSA。

For node information, since the connectivity matrix information is static, the LSA containing the Node Attribute TLV can be updated with a lower frequency to avoid unnecessary updates.


For link information, a mechanism MAY be applied such that static information and dynamic information of one TE link are contained in separate Opaque LSAs. For example, the Port Label Restrictions sub-TLV could be nested in separate top-level Link TLVs and advertised in the separate LSAs.


As with other TE information, an implementation typically takes measures to avoid rapid and frequent updates of routing information that could cause the routing network to become swamped. See Section 3 of [RFC3630] for related details.


5. Scalability and Timeliness
5. スケーラビリティと適時性

This document defines two sub-TLVs for describing generic routing constraints. The examples given in [RFC7579] show that very large systems, in terms of label count or ports, can be very efficiently encoded. However, because there has been concern expressed that some possible systems may produce LSAs that exceed the IP Maximum Transmission Unit (MTU), methods should be given to allow for the splitting of general constraint LSAs into smaller LSAs that are under the MTU limit. This section presents a set of techniques that can be used for this purpose.

このドキュメントでは、一般的なルーティング制約を説明するための2つのサブTLVを定義しています。 [RFC7579]に示されている例は、ラベル数またはポートに関して非常に大規模なシステムを非常に効率的にエンコードできることを示しています。ただし、一部の可能なシステムがIP最大伝送ユニット(MTU)を超えるLSAを生成する可能性があるという懸念が表明されているため、一般的な制約のLSAをMTU制限の下にあるより小さなLSAに分割できる方法を提供する必要があります。このセクションでは、この目的に使用できる一連の手法を示します。

5.1. Different Sub-TLVs into Multiple LSAs
5.1. 複数のLSAへの異なるサブTLV

Two sub-TLVs are defined in this document:


1. Connectivity Matrix (carried in the Node Attribute TLV)

1. 接続マトリックス(ノード属性TLVで実行)

2. Port Label Restrictions (carried in the Link TLV)

2. ポートラベルの制限(リンクTLVで実行)

The Connectivity Matrix sub-TLV can be carried in the Node Attribute TLV (as defined in [RFC5786]), whereas the Port Label Restrictions sub-TLV can be carried in a Link TLV, of which there can be at most one in an LSA (as defined in [RFC3630]). Note that the port label restrictions are relatively static, i.e., only would change with hardware changes or significant system reconfiguration.

コネクティビティマトリックスサブTLVはノード属性TLV([RFC5786]で定義)で伝送できますが、ポートラベル制限サブTLVはリンクTLVで伝送できますが、LSAに最大1つ存在できます。 ([RFC3630]で定義されています)。ポートラベルの制限は比較的静的であることに注意してください。つまり、ハードウェアの変更または重要なシステムの再構成によってのみ変更されます。

5.2. Decomposing a Connectivity Matrix into Multiple Matrices
5.2. 接続性マトリックスを複数のマトリックスに分解

In the highly unlikely event that a Connectivity Matrix sub-TLV by itself would result in an LSA exceeding the MTU, a single large matrix can be decomposed into sub-matrices. Per [RFC7579], a connectivity matrix just consists of pairs of input and output ports that can reach each other; hence, this decomposition would be straightforward. Each of these sub-matrices would get a unique matrix identifier per [RFC7579].

接続マトリックスサブTLV自体がMTUを超えるLSAをもたらす可能性が非常に低い場合、単一の大きなマトリックスをサブマトリックスに分解できます。 [RFC7579]によると、接続性マトリックスは、互いに到達できる入力ポートと出力ポートのペアで構成されています。したがって、この分解は簡単です。これらの各サブマトリックスは、[RFC7579]に従って一意のマトリックス識別子を取得します。

From the point of view of a path computation process, prior to receiving an LSA with a Connectivity Matrix sub-TLV, no connectivity restrictions are assumed, i.e., the standard GMPLS assumption of any port to any port reachability holds. Once a Connectivity Matrix sub-TLV is received, path computation would know that connectivity is restricted and use the information from all Connectivity Matrix sub-TLVs received to understand the complete connectivity potential of the system. Prior to receiving any Connectivity Matrix sub-TLVs, path computation may compute a path through the system when, in fact, no path exists. In between the reception of an additional Connectivity Matrix sub-TLV, path computation may not be able to find a path through the system when one actually exists. Both cases are currently encountered and handled with existing GMPLS mechanisms. Due to the reliability mechanisms in OSPF, the phenomena of late or missing Connectivity Matrix sub-TLVs would be relatively rare.

パス計算プロセスの観点から見ると、接続性マトリックスサブTLVを使用してLSAを受信する前は、接続性の制限は想定されていません。つまり、任意のポートからポートへの到達可能性の標準GMPLSの想定は保持されます。接続マトリックスサブTLVを受信すると、パス計算は接続が制限されていることを認識し、受信したすべての接続マトリックスサブTLVからの情報を使用して、システムの完全な接続可能性を理解します。接続マトリックスサブTLVを受信する前に、実際にはパスが存在しない場合でも、パス計算はシステムを介してパスを計算することがあります。追加の接続性マトリックスサブTLVの受信の間に、パスが実際に存在する場合、パス計算がシステムを通るパスを見つけることができない場合があります。どちらのケースも現在発生しており、既存のGMPLSメカニズムで処理されます。 OSPFの信頼性メカニズムにより、接続マトリックスサブTLVが遅れたり欠落したりする現象は比較的まれです。

In the case where the new sub-TLVs or their attendant encodings are malformed, the proper action would be to log the problem and ignore just the sub-TLVs in GMPLS path computations rather than ignoring the entire LSA.


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

This document does not introduce any further security issues other than those discussed in [RFC3630], [RFC4203], and [RFC5250].


For general security aspects relevant to GMPLS-controlled networks, please refer to [RFC5920].


7. Manageability
7. 管理性

No existing management tools handle the additional TE parameters as defined in this document and distributed in OSPF-TE. The existing MIB module contained in [RFC6825] allows the TE information distributed by OSPF-TE to be read from a network node; this MIB module could be augmented (possibly by a sparse augmentation) to report this new information.

このドキュメントで定義され、OSPF-TEで配布されている追加のTEパラメータを処理する既存の管理ツールはありません。 [RFC6825]に含まれている既存のMIBモジュールにより、OSPF-TEによって配布されたTE情報をネットワークノードから読み取ることができます。この新しい情報を報告するために、このMIBモジュールを(おそらくスパース拡張によって)拡張できます。

The current environment in the IETF favors the Network Configuration Protocol (NETCONF) [RFC6241] and YANG [RFC6020] over SNMP and MIB modules. Work is in progress in the TEAS working group to develop a YANG module to represent the generic TE information that may be present in a Traffic Engineering Database (TED). This model may be extended to handle the additional information described in this document to allow that information to be read from network devices or exchanged between consumers of the TED. Furthermore, links state export using BGP [BGP-LS] enables the export of TE information from a network using BGP. Work could realistically be done to extend BGP-LS to also carry the information defined in this document.

IETFの現在の環境では、SNMPおよびMIBモジュールよりもネットワーク構成プロトコル(NETCONF)[RFC6241]およびYANG [RFC6020]が優先されます。 TEASワーキンググループでは、交通工学データベース(TED)に存在する可能性のある一般的なTE情報を表すYANGモジュールを開発する作業が進行中です。このモデルを拡張して、このドキュメントで説明されている追加情報を処理し、その情報をネットワークデバイスから読み取ったり、TEDのコンシューマー間で交換したりできるようにすることができます。さらに、BGPを使用したリンクステートエクスポート[BGP-LS]では、BGPを使用してネットワークからTE情報をエクスポートできます。 BGP-LSを拡張して、このドキュメントで定義されている情報も運ぶように、現実的に作業を行うことができます。

It is not envisaged that the extensions defined in this document will place substantial additional requirements on Operations, Administration, and Maintenance (OAM) mechanisms currently used to diagnose and debug OSPF systems. However, tools that examine the contents of opaque LSAs will need to be enhanced to handle these new sub-TLVs.

このドキュメントで定義されている拡張機能により、OSPFシステムの診断とデバッグに現在使用されているOAM(Operations、Administration、and Maintenance)メカニズムに実質的な追加要件が課されることは想定されていません。ただし、不透明なLSAの内容を検査するツールは、これらの新しいサブTLVを処理できるように拡張する必要があります。

8. IANA Considerations
8. IANAに関する考慮事項

IANA has allocated new sub-TLVs as defined in Sections 2 and 3 as follows:


8.1. Node Information
8.1. ので いんふぉrまちおん

IANA maintains the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registry with a sub-registry called "Types for sub-TLVs of TE Node Attribute TLV (Value 5)". IANA has assigned a new code point as follows:

IANAは、「Open Shortest Path First(OSPF)Traffic Engineering TLVs」レジストリを維持し、「TEノード属性TLVのサブTLVのタイプ(値5)」というサブレジストリを保持しています。 IANAは、次のように新しいコードポイントを割り当てました。

         Type   |  Sub-TLV                      |  Reference
          14    |  Connectivity Matrix          |  [RFC7580]
8.2. Link Information
8.2. リンク情報

IANA maintains the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registry with a sub-registry called "Types for sub-TLVs of TE Link TLV (Value 2)". IANA has assigned a new code point as follows:

IANAは、「Open Shortest Path First(OSPF)Traffic Engineering TLVs」レジストリを「Types for sub-TLVs of TE Link TLV(Value 2)」というサブレジストリで維持しています。 IANAは、次のように新しいコードポイントを割り当てました。

         Type   |  Sub-TLV                      |  Reference
           34   |  Port Label Restrictions      |  [RFC7580]
9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、< rfc2119>。

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <>.

[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<>。

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

[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering(TE)Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<http://www.rfc>。

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

[RFC4202] Kompella、K。、編、およびY. Rekhter、編、「汎用マルチプロトコルラベルスイッチング(GMPLS)をサポートするルーティング拡張機能」、RFC 4202、DOI 10.17487 / RFC4202、2005年10月、<http: //>。

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

[RFC4203] Kompella、K。、編、およびY. Rekhter、編、「汎用マルチプロトコルラベルスイッチング(GMPLS)をサポートするOSPF拡張機能」、RFC 4203、DOI 10.17487 / RFC4203、2005年10月、<http: //>。

[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, July 2008, <>.

[RFC5250] Berger、L.、Bryskin、I.、Zinin、A。、およびR. Coltun、「OSPF Opaque LSAオプション」、RFC 5250、DOI 10.17487 / RFC5250、2008年7月、<http://www.rfc>。

[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010, <>.

[RFC5786] Aggarwal、R。およびK. Kompella、「OSPFトラフィックエンジニアリング(TE)拡張におけるルーターのローカルアドレスのアドバタイズ」、RFC 5786、DOI 10.17487 / RFC5786、2010年3月、<http://www.rfc-editor。 org / info / rfc5786>。

[RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and J. Han, "General Network Element Constraint Encoding for GMPLS-Controlled Networks", RFC 7579, DOI 10.17487/RFC7579, June 2015, <>.

[RFC7579] Bernstein、G.、Ed。、Lee、Y.、Ed。、Li、D.、Imajuku、W.、and J. Han、 "General Network Element Constraint Encoding for GMPLS-Controlled Networks"、RFC 7579、 DOI 10.17487 / RFC7579、2015年6月、<>。

9.2. Informative References
9.2. 参考引用

[BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", Work in Progress, draft-ietf-idr-ls-distribution-11, June 2015.

[BGP-LS] Gredler、H.、Medved、J.、Previdi、S.、Farrel、A。、およびS. Ray、「BGPを使用したリンク状態およびTE情報の北限定分布」、作業中、 draft-ietf-idr-ls-distribution-11、2015年6月。

[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <>.

[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル(NETCONF)のデータモデリング言語」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<http://www.rfc-editor。 org / info / rfc6020>。

[RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, DOI 10.17487/RFC6163, April 2011, <>.

[RFC6163] Lee、Y.、Ed。、Bernstein、G.、Ed。、およびW. Imajuku、「GMPLSおよびPath Computation Element(PCE)Control for Wavelength Switched Optical Network(WSONs)」、RFC 6163、DOI 10.17487 / RFC6163、2011年4月、<>。

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <>.

[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol(NETCONF)」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<>。

[RFC6825] Miyazawa, M., Otani, T., Kumaki, K., and T. Nadeau, "Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS", RFC 6825, DOI 10.17487/RFC6825, January 2013, <>.

[RFC6825]宮沢真一、大谷敏夫、熊木健一、ナドーT。、「MPLS-TE / GMPLSをサポートするトラフィックエンジニアリングデータベース管理情報ベース」、RFC 6825、DOI 10.17487 / RFC6825、2013年1月、<>。

[RFC7446] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku, "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", RFC 7446, DOI 10.17487/RFC7446, February 2015, <>.

[RFC7446] Lee、Y.、Ed。、Bernstein、G.、Ed。、Li、D。、およびW. Imajuku、「Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks」、RFC 7446、DOI 10.17487 / RFC7446 、2015年2月、<>。

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <>.

[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<>。



We thank Ming Chen and Yabin Ye from DICONNET Project who provided valuable information for this document.

このドキュメントに貴重な情報を提供してくれたDICONNET ProjectのMing ChenとYabin Yeに感謝します。



Guoying Zhang China Academy of Telecommunication Research of MII 11 Yue Tan Nan Jie Beijing China Phone: +86-10-68094272 EMail:

GU Oying Zhang中国電気通信研究アカデミーo FM II 11 Y u ETアンナNJ IE北京中国電話:+ 86-10-68094272メール:张国英@买了。日天天.com。Talent

Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 China Phone: +86-755-28973237 EMail:

Dan Li Huawei Technologies Co.、Ltd. F3-5-B R&D Center、Huawei Base Bantian、Longgang District Shenzhen 518129 China電話:+ 86-755-28973237メール

Ming Chen European Research Center Huawei Technologies Riesstr. 25, 80992 Munchen Germany Phone: 0049-89158834072 EMail:

明陳ヨーロッパ研究センターHuawei Technologies Riesstr。 25、80992ミュンヘンドイツ電話:0049-89158834072メール

Yabin Ye European Research Center Huawei Technologies Riesstr. 25, 80992 Munchen Germany Phone: 0049-89158834074 EMail:

Yabin Ye European Research Center Huawei Technologies Riesstr。 25、80992ドイツミュンヘン電話:0049-89158834074メール

Authors' Addresses


Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 China Phone: +86-755-28972912 EMail:

Fatai Zhang Huawei Technologies F3-5-B R&D Center、Huawei Base Bantian、Longgang District Shenzhen 518129 China電話:+ 86-755-28972912メール

Young Lee Huawei Technologies 5360 Legacy Drive, Building 3 Plano, TX 75023 United States Phone: (469)277-5838 EMail:

Young Lee Huawei Technologies 5360 Legacy Drive、Building 3 Plano、TX 75023 United States電話:(469)277-5838メール

Jianrui Han Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 China Phone: +86-755-28977943 EMail:

Jianrui Han Huawei Technologies Co.、Ltd. F3-5-B R&D Center、Huawei Base Bantian、Longgang District Shenzhen 518129 China電話:+ 86-755-28977943メール

Greg Bernstein Grotto Networking Fremont, CA United States Phone: (510) 573-2237 EMail:

Greg Bernstein Grotto Networking Fremont、CA United States電話:(510)573-2237 Eメール

Yunbin Xu China Academy of Telecommunication Research of MII 11 Yue Tan Nan Jie Beijing China Phone: +86-10-68094134 EMail:

Y UNビンX u中国電気通信研究アカデミーo FM II 11 Y u ETアンナNJ IE北京中国電話:+ 86-10-68094134電子メール:许采學@买了。日天天.com。人材