RFC4990 日本語訳
4990 Use of Addresses in Generalized Multiprotocol Label Switching(GMPLS) Networks. K. Shiomoto, R. Papneja, R. Rabbat. September 2007. (Format: TXT=50908 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Shiomoto
Request for Comments: 4990 NTT
Category: Informational R. Papneja
Isocore
R. Rabbat
Google
September 2007
Shiomotoがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4990年のNTTカテゴリ: 情報のR.Papneja Isocore R.Rabbat Google2007年9月
Use of Addresses
in Generalized Multiprotocol Label Switching (GMPLS) Networks
一般化されたMultiprotocolラベルの切り換え(GMPLS)ネットワークにおけるアドレスの使用
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment.
このドキュメントはGeneralized Multiprotocol Label Switching(GMPLS)ネットワークにおけるアドレスの使用をはっきりさせます。 目的は(LSRs)はGMPLSできるLabel Switching Routersを織り込むのを容易にすることです。 ドキュメントは実装で行われた経験、相互運用性テスト、および展開に基づいています。
The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules.
ドキュメントは、GMPLSプロトコルの中でどのようにアドレスと識別子分野を解釈するか、そして、それらの分野に特定の規制飛行機用法モデルにどのアドレスを設定したらよいかをどのように選ぶかを説明します。 また、それはMPLSとGMPLS Traffic Engineering(TE)管理Information基地(MIB)のモジュールでIPv6ソースと目的地を扱う方法について議論します。
This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs.
このドキュメントは新しい手順かプロセスを定義しません。 このドキュメントが要件を声明か推薦にするときはいつも、これらは参照をつけられたRFCsで標準のテキストから抜粋されます。
Shiomoto, et al. Informational [Page 1] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto、他 GMPLSにおけるアドレスの情報[1ページ]のRFC4990使用は2007年9月をネットワークでつなぎます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Support of Numbered and Unnumbered Links ........................5
4. Numbered Addressing .............................................6
4.1. Numbered Addresses in IGPs .................................6
4.1.1. Router Address and TE Router ID .....................6
4.1.2. Link ID and Remote Router ID ........................6
4.1.3. Local Interface IP Address ..........................7
4.1.4. Remote Interface IP Address .........................7
4.2. Numbered Addresses in RSVP-TE ..............................7
4.2.1. IP Tunnel End Point Address in Session Object .......7
4.2.2. IP Tunnel Sender Address in Sender Template Object ..8
4.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces .......8
4.2.4. Explicit Route Object (ERO) .........................9
4.2.5. Record Route Object (RRO) ...........................9
4.2.6. IP Packet Source Address ............................9
4.2.7. IP Packet Destination Address .......................9
5. Unnumbered Addressing ..........................................10
5.1. Unnumbered Addresses in IGPs ..............................10
5.1.1. Link Local/Remote Identifiers in OSPF-TE ...........10
5.1.2. Link Local/Remote Identifiers in IS-IS-TE ..........11
5.2. Unnumbered Addresses in RSVP-TE ...........................11
5.2.1. Sender and End Point Addresses .....................11
5.2.2. IF_ID RSVP_HOP Object for Unnumbered Interfaces ....11
5.2.3. Explicit Route Object (ERO) ........................11
5.2.4. Record Route Object (RRO) ..........................11
5.2.5. LSP_Tunnel Interface ID Object .....................12
5.2.6. IP Packet Addresses ................................12
6. RSVP-TE Message Content ........................................12
6.1. ERO and RRO Addresses .....................................12
6.1.1. Strict Subobject in ERO ............................12
6.1.2. Loose Subobject in ERO .............................14
6.1.3. RRO ................................................14
6.1.4. Label Record Subobject in RRO ......................15
6.2. Component Link Identification .............................15
6.3. Forwarding Destination of Path Messages with ERO ..........16
7. Topics Related to the GMPLS Control Plane ......................16
7.1. Control Channel Separation ................................16
7.1.1. Native and Tunneled Control Plane ..................16
7.2. Separation of Control and Data Plane Traffic ..............17
8. Addresses in the MPLS and GMPLS TE MIB Modules .................17
8.1. Handling IPv6 Source and Destination Addresses ............18
8.1.1. Identifying LSRs ...................................18
8.1.2. Configuring GMPLS Tunnels ..........................18
8.2. Managing and Monitoring Tunnel Table Entries ..............19
9. Security Considerations ........................................19
1. 序論…3 2. 用語…3 3. 番号付の、そして、無数のリンクのサポート…5 4. アドレシングに付番します…6 4.1. IGPsのアドレスに付番します…6 4.1.1. ルータアドレスとTe Router ID…6 4.1.2. IDと遠く離れたRouter IDをリンクしてください…6 4.1.3. 局所界面IPアドレス…7 4.1.4. リモートインタフェースIPアドレス…7 4.2. RSVP-Teのアドレスに付番します…7 4.2.1. セッションオブジェクトのIPトンネルエンドポイントアドレス…7 4.2.2. 送付者テンプレートオブジェクトのIPトンネル送付者アドレス。8 4.2.3. _ID RSVP_が跳ぶなら、番号付のインタフェースに反対してください…8 4.2.4. 明白なルートオブジェクト(ERO)…9 4.2.5. ルートオブジェクト(RRO)を記録してください…9 4.2.6. IPパケットソースアドレス…9 4.2.7. IPパケット送付先アドレス…9 5. 無数のアドレシング…10 5.1. IGPsの無数のアドレス…10 5.1.1. OSPF-Teの地方の、または、リモートな識別子をリンクしてください…10 5.1.2. 地方の、または、リモートな識別子をリンクする、Teである、…11 5.2. RSVP-Teの無数のアドレス…11 5.2.1. 送付者とエンドポイントアドレス…11 5.2.2. _ID RSVP_が跳ぶなら、無数のインタフェースに反対してください…11 5.2.3. 明白なルートオブジェクト(ERO)…11 5.2.4. ルートオブジェクト(RRO)を記録してください…11 5.2.5. LSP_トンネルインタフェースIDオブジェクト…12 5.2.6. IPパケットアドレス…12 6. RSVP-Teメッセージ内容…12 6.1. EROとRROアドレス…12 6.1.1. EROの厳しいSubobject…12 6.1.2. EROでSubobjectを発射してください…14 6.1.3. RRO…14 6.1.4. RROを記録的なSubobjectをラベルしてください…15 6.2. コンポーネントリンク識別…15 6.3. EROがある経路メッセージの推進の目的地…16 7. 話題はGMPLS制御飛行機に関連しました…16 7.1. チャネルセパレーションを制御してください…16 7.1.1. ネイティブの、そして、トンネルを堀られた制御飛行機…16 7.2. コントロールとデータ空輸の分離…17 8. MPLSとGMPLSでは、TeがMIBモジュールであると扱います…17 8.1. 取り扱いIPv6ソースと送付先アドレス…18 8.1.1. LSRsを特定します…18 8.1.2. GMPLSを構成するのはトンネルを堀ります…18 8.2. トンネルを管理して、モニターすると、エントリーはテーブルの上に置かれます…19 9. セキュリティ問題…19
Shiomoto, et al. Informational [Page 2] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto、他 GMPLSにおけるアドレスの情報[2ページ]のRFC4990使用は2007年9月をネットワークでつなぎます。
10. Acknowledgments ...............................................20
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................21
10. 承認…20 11. 参照…20 11.1. 標準の参照…20 11.2. 有益な参照…21
1. Introduction
1. 序論
This informational document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment.
この情報のドキュメントはGeneralized Multiprotocol Label Switching(GMPLS)[RFC3945]ネットワークにおけるアドレスの使用をはっきりさせます。 目的は(LSRs)はGMPLSできるLabel Switching Routersを織り込むのを容易にすることです。 ドキュメントは実装で行われた経験、相互運用性テスト、および展開に基づいています。
The document describes how to interpret address and identifier fields within GMPLS protocols (RSVP-TE [RFC3473], GMPLS OSPF [RFC4203], and GMPLS ISIS [RFC4205]), and how to choose which addresses to set in those fields for specific control plane usage models.
ドキュメントは、GMPLSプロトコル(RSVP-TE[RFC3473]、GMPLS OSPF[RFC4203]、およびGMPLS ISIS[RFC4205])の中でどのようにアドレスと識別子分野を解釈するか、そして、それらの分野に特定の規制飛行機用法モデルにどのアドレスを設定したらよいかをどのように選ぶかを説明します。
This document does not define new procedures or processes and the protocol specifications listed above should be treated as definitive. Furthermore, where this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. Nothing in this document should be considered normative.
このドキュメントは新しい手順かプロセスを定義しません、そして、上にリストアップされたプロトコル仕様は決定的であるとして扱われるべきです。 その上、このドキュメントが要件を声明か推薦にするところでは、これらは参照をつけられたRFCsで標準のテキストから抜粋されます。 規範的であると本書では何も考えるべきではありません。
This document also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules [RFC3812], [RFC4802].
また、このドキュメントはMPLSとGMPLS Traffic Engineering(TE)管理Information基地(MIB)のモジュール[RFC3812][RFC4802]でIPv6ソースと目的地を扱う方法について議論します。
2. Terminology
2. 用語
As described in [RFC3945], the components of a GMPLS network may be separated into a data plane and a control plane. The control plane may be further split into signaling components and routing components.
[RFC3945]で説明されるように、GMPLSネットワークの成分はデータ飛行機と制御飛行機に切り離されるかもしれません。 制御飛行機はさらにシグナリングコンポーネントとルーティングコンポーネントに分けられるかもしれません。
A data plane switch or router is called a data plane entity. It is a node on the data plane topology graph. A data plane resource is a facility available in the data plane, such as a data plane entity (node), data link (edge), or data label (such as a lambda).
データ飛行機スイッチかルータがデータ飛行機実体と呼ばれます。 それはデータ飛行機トポロジーグラフのノードです。 データ飛行機リソースはデータ飛行機で利用可能な施設です、データ飛行機実体(ノード)、データ・リンク(縁)、またはデータラベル(λなどの)などのように。
In the control plane, there are protocol speakers that are software implementations that communicate using signaling or routing protocols. These are control plane entities, and may be physically located separately from the data plane entities that they control. Further, there may be separate routing entities and signaling entities.
制御飛行機に、シグナリングを使用することで伝えるソフトウェア実行かルーティング・プロトコルであるプロトコルスピーカーがいます。 これらは、コントロール飛行機実体であり、別々にそれらが制御するデータ飛行機実体から物理的に見つけられるかもしれません。 さらに、別々のルーティング実体とシグナリング実体があるかもしれません。
Shiomoto, et al. Informational [Page 3] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto、他 GMPLSにおけるアドレスの情報[3ページ]のRFC4990使用は2007年9月をネットワークでつなぎます。
GMPLS supports a control plane entity that is responsible for one or more data plane entities, and supports the separation of signaling and routing control plane entities. For the purposes of this document, it is assumed that there is a one-to-one correspondence between control plane and data plane entities. That is, each data plane switch has a unique control plane entity responsible for participating in the GMPLS signaling and routing protocols, and that each such control plane presence is responsible for a single data plane switch.
GMPLSは1つ以上のデータ飛行機実体に原因となるコントロール飛行機実体をサポートして、シグナリングとルーティングコントロール飛行機実体の分離をサポートします。 このドキュメントの目的のために、制御飛行機とデータ飛行機実体との1〜1つの通信があると思われます。 すなわちそれぞれのデータ飛行機スイッチでユニークなコントロール飛行機実体はGMPLSシグナリングとルーティング・プロトコルに参加するのに責任があるようになります、そして、そのようなそれぞれのコントロール飛行機存在は単一のデータ飛行機スイッチに原因となります。
The combination of control plane and data plane entities is referred to as a Label Switching Router (LSR).
制御飛行機とデータ飛行機実体の組み合わせはLabel Switching Router(LSR)と呼ばれます。
Note that the term 'Router ID' is used in two contexts within GMPLS. It may refer to an identifier of a participant in a routing protocol, or it may be an identifier for an LSR that participates in TE routing. These could be considered as the control plane and data plane contexts.
'Router ID'という用語がGMPLSの中の2つの文脈で使用されることに注意してください。 それはルーティング・プロトコルの関係者の識別子を示すかもしれませんか、それがTEルーティングに参加するLSRのための識別子であるかもしれません。 制御飛行機とデータ飛行機文脈であるとこれらをみなすことができました。
In this document, the contexts are distinguished by the following definitions.
本書では、文脈は以下の定義で区別されます。
o Loopback address: A loopback address is a stable IP address of the
advertising router that is always reachable if there is any IP
connectivity to it [RFC3477], [RFC3630]. Thus, for example, an
IPv4 127/24 address is excluded from this definition.
o ループバックアドレス: ループバックアドレスは何かそれ[RFC3477][RFC3630]へのIPの接続性があればいつも届いている広告ルータの安定したIPアドレスです。 このようにして、例えば、IPv4 127/24アドレスはこの定義から除かれます。
o TE Router ID: A stable IP address of an LSR that is always
reachable in the control plane if there is any IP connectivity to
the LSR, e.g., a loopback address. The most important requirement
is that the address does not become unusable if an interface on
the LSR is down [RFC3477], [RFC3630].
o TeルータID: そこであるなら制御飛行機でいつも届いているLSRの安定したIPアドレスはLSR(例えば、ループバックアドレス)へのあらゆるIPの接続性です。 最も重要な要件はアドレスがLSRの上のインタフェースが下[RFC3477]である[RFC3630]なら使用不可能にならないということです。
o Router ID: The OSPF protocol version 2 [RFC2328] defines the
Router ID to be a 32-bit network-unique number assigned to each
router running OSPF. IS-IS [RFC1195] includes a similar concept
in the System ID. This document describes both concepts as the
"Router ID" of the router running the routing protocol. The
Router ID is not required to be a reachable IP address, although
an operator may set it to a reachable IP address on the same node.
o ルータID: OSPFプロトコルバージョン2[RFC2328]は、各ルータの実行しているOSPFに割り当てられた32ビットのネットワークユニークな数になるようにRouter IDを定義します。 -、[RFC1195]はSystem IDに同様の概念を含んでいます。 このドキュメントはルーティング・プロトコルを実行するルータの「Router ID」として両方の概念を記述します。 Router IDは届いているIPアドレスになるのに必要ではありません、オペレータが同じノードに関する届いているIPアドレスにそれを設定するかもしれませんが。
o TE link: "A TE link is a representation in the IS-IS/OSPF Link
State advertisements and in the link state database of certain
physical resources, and their properties, between two GMPLS nodes"
[RFC3945].
o TEはリンクします: /OSPF Link州広告とリンクでは、ある物理資源に関するデータベース、および2つのGMPLSノードの間の彼らの特性を述べてください。「TEリンクが中の表現である、-、」 [RFC3945。]
o Data plane node: A vertex on the TE graph. It is a data plane
switch or router. Data plane nodes are connected by TE links that
o データ飛行機ノード: TEグラフの頂点。 それは、データ飛行機スイッチかルータです。 データ飛行機ノードは接続されて、TEがそれをリンクするということです。
Shiomoto, et al. Informational [Page 4] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto、他 GMPLSにおけるアドレスの情報[4ページ]のRFC4990使用は2007年9月をネットワークでつなぎます。
are constructed from physical data links. A data plane node is
controlled through some combination of management and control
plane actions. A data plane node may be under full or partial
control of a control plane node.
物理的なデータ・リンクから、組み立てられます。 データ飛行機ノードは管理とコントロール飛行機動作の何らかの組み合わせで制御されます。 データ飛行機ノードが規制飛行機ノードの完全であるか部分的なコントロールの下にあるかもしれません。
o Control plane node: A GMPLS protocol speaker. It may be part of a
data plane switch or may be a separate computer. Control plane
nodes are connected by control channels that are logical
connection-less or connection-oriented paths in the control plane.
A control plane node is responsible for controlling zero, one, or
more data plane nodes.
o 飛行機ノードを制御してください: GMPLSはスピーカーについて議定書の中で述べます。 それはデータ飛行機スイッチの一部であるかもしれませんか別々のコンピュータであるかもしれません。 規制飛行機ノードは制御飛行機の論理的なコネクションレスであるか接続指向の経路である制御チャンネルによって接続されます。 規制飛行機ノードはゼロ、1つ以上のデータ飛行機ノードを制御するのに原因となります。
o Interface ID: The Interface ID is defined in [RFC3477] and in
Section 9.1 of [RFC3471].
o IDを連結してください: Interface IDは[RFC3477]と[RFC3471]のセクション9.1で定義されます。
o Data Plane Address: This document refers to a data plane address
in the context of GMPLS. It does not refer to addresses such as
E.164 SAPI in Synchronous Digital Hierarchy (SDH).
o データ飛行機アドレス: このドキュメントはGMPLSの文脈のデータ飛行機アドレスを示します。 それは同期デジタルハイアラーキ(SDH)のE.164 SAPIなどのアドレスを参照しません。
o Control Plane Address: An address used to identify a control plane
resource including, and restricted to, control plane nodes and
control channels.
o 飛行機アドレスを制御してください: 包含して、制限されたコントロール飛行機リソースを特定するのにおいて中古のアドレス、規制飛行機ノード、および制御チャンネル。
o IP Time to Live (TTL): The IPv4 TTL field or the IPv6 Hop Limit
field, whichever is applicable.
o 生きるIP時間(TTL): IPv4 TTL分野かIPv6 Hop Limit分野。(その分野は適切です)。
o TED: Traffic Engineering Database.
o テッド: 交通工学データベース。
o LSR: Label Switching Router.
o LSR: 切り換えルータをラベルしてください。
o FA: Forwarding Adjacency.
o ファ: 隣接番組を進めます。
o IGP: Interior Gateway Protocol.
o IGP: 内部のゲートウェイプロトコル。
3. Support of Numbered and Unnumbered Links
3. 番号付の、そして、無数のリンクのサポート
The links in the control and data planes may be numbered or unnumbered [RFC3945]. That is, their end points may be assigned IP addresses, or may be assigned link IDs specific to the control plane or data plane entity at the end of the link. Implementations may decide to support numbered and/or unnumbered addressing.
コントロールとデータ飛行機のリンクは、番号付である、または無数であるかもしれません[RFC3945]。 すなわち、それらのエンドポイントはIPアドレスが割り当てられるか、またはリンクの端の制御飛行機かデータ飛行機実体に特定のリンクIDを割り当てられるかもしれません。 実装は、番号付の、そして/または、無数のアドレシングをサポートすると決めるかもしれません。
The argument for numbered addressing is that it simplifies troubleshooting. The argument for unnumbered addressing is to save on IP address resources.
番号付のアドレシングのための議論はトラブルシューティングを簡素化するということです。 無数のアドレシングのための議論はIPでアドレスがリソースであると保存することです。
An LSR may choose to only support its own links being configured as numbered, or may only support its own links being configured as
LSRはそれ自身のものが付番されるように構成されながらリンクするか、または構成されるそれ自身のリンクを支えるだけであるかもしれないサポートだけに選ぶかもしれません。
Shiomoto, et al. Informational [Page 5] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto、他 GMPLSにおけるアドレスの情報[5ページ]のRFC4990使用は2007年9月をネットワークでつなぎます。
unnumbered. But an LSR must not restrict the choice of other LSRs to use numbered or unnumbered links since this might lead to interoperablity issues. Thus, a node should be able to accept and process link advertisements containing both numbered and unnumbered addresses.
無数。 しかし、LSRは、これがinteroperablity問題に通じるかもしれないので番号付の、または、無数のリンクを使用するために他のLSRsの選択を制限してはいけません。 したがって、ノードは、番号付の、そして、無数の両方のアドレスを含むリンク広告を、受け入れて、処理できるはずです。
Numbered and unnumbered addressing is described in Sections 4 and 5 of this document, respectively.
番号付の、そして、無数のアドレシングはこのドキュメントのセクション4と5でそれぞれ説明されます。
4. Numbered Addressing
4. 番号付のアドレシング
When numbered addressing is used, addresses are assigned to each node and link in both the control and data planes of the GMPLS network.
番号付のアドレシングが使用されているとき、アドレスは、各ノードに割り当てられて、両方でGMPLSネットワークのコントロールとデータ飛行機をリンクします。
A numbered link is identified by a network-unique identifier (e.g., an IP address).
ネットワークユニークな識別子(例えば、IPアドレス)によって番号付のリンクは特定されます。
4.1. Numbered Addresses in IGPs
4.1. IGPsの番号付のアドレス
In this section, we discuss numbered addressing using two Interior Gateway Protocols (IGPs) that have extensions defined for GMPLS: OSPF-TE and IS-IS-TE. The routing enhancements for GMPLS are defined in [RFC3630], [RFC3784], [RFC4202], [RFC4203], and [RFC4205].
このセクションでは、私たちはGMPLSのために定義された拡張子を持っている2つのInteriorゲートウェイプロトコル(IGPs)を使用することで番号付のアドレシングを論じます: そして、OSPF-Te、Teです。 GMPLSのためのルーティング増進は[RFC3630]、[RFC3784]、[RFC4202]、[RFC4203]、および[RFC4205]で定義されます。
4.1.1. Router Address and TE Router ID
4.1.1. ルータアドレスとTe Router ID
The IGPs define a field called the "Router Address". It is used to advertise the TE Router ID.
IGPsは「ルータアドレス」と呼ばれる分野を定義します。 それは、TE Router IDの広告を出すのに使用されます。
The Router Address is advertised in OSPF-TE using the Router Address TLV structure of the TE Link State Advertisement (LSA) [RFC3630].
OSPF-TEにTE Link州Advertisement(LSA)[RFC3630]のRouter Address TLV構造を使用することでRouter Addressの広告を出します。
In IS-IS-TE, this is referred to as the Traffic Engineering router ID, and is carried in the advertised Traffic Engineering router ID TLV [RFC3784].
中、TEである、これは、Traffic EngineeringルータIDと呼ばれて、広告を出しているTraffic EngineeringルータID TLV[RFC3784]で運ばれます。
4.1.2. Link ID and Remote Router ID
4.1.2. IDと遠く離れたRouter IDをリンクしてください。
In OSPF-TE [RFC3630], the Router ID of the remote end of a TE link is carried in the Link ID sub-TLV. This applies for point-to-point TE links only; multi-access links are for further study.
OSPF-TE[RFC3630]では、TEリンクのリモートエンドのRouter IDはLink IDサブTLVで運ばれます。 これは二地点間TEリンクだけに申し込みます。 さらなる研究にはマルチアクセスリンクがあります。
In IS-IS-TE [RFC3784], the Extended IS Reachability TLV is used to carry the System ID. This corresponds to the Router ID as described in Section 2.
中、TEである、[RFC3784]、ExtendedによるReachability TLVがSystem IDを運ぶのに使用されるということです。 これはセクション2で説明されるようにRouter IDに対応しています。
Shiomoto, et al. Informational [Page 6] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto、他 GMPLSにおけるアドレスの情報[6ページ]のRFC4990使用は2007年9月をネットワークでつなぎます。
4.1.3. Local Interface IP Address
4.1.3. 局所界面IPアドレス
The Local Interface IP Address is advertised in:
以下にLocal Interface IP Addressの広告を出します。
o the Local Interface IP Address sub-TLV in OSPF-TE [RFC3630]
o OSPF-TeにおけるサブTLVの局所界面IPアドレス[RFC3630]
o the IPv4 Interface Address sub-TLV in IS-IS-TE [RFC3784].
o IPv4がアドレスサブTLVを連結する、Teである、[RFC3784。]
This is the ID of the local end of the numbered TE link. It must be a network-unique number (since this section is devoted to numbered addressing), but it does not need to be a routable address in the control plane.
これは番号付のTEリンクの地方の端のIDです。 ネットワークユニークな数であるに違いありません(このセクションが番号付のアドレシングにささげられるので)が、それは、制御飛行機の発送可能アドレスである必要がありません。
4.1.4. Remote Interface IP Address
4.1.4. リモートインタフェースIPアドレス
The Remote Interface IP Address is advertised in:
以下にRemote Interface IP Addressの広告を出します。
o the Remote Interface IP Address sub-TLV in OSPF-TE [RFC3630]
o OSPF-TeにおけるサブTLVのリモートインタフェースIPアドレス[RFC3630]
o the IPv4 Neighbor Address sub-TLV in IS-IS-TE [RFC3784].
o IPv4隣人がサブTLVを扱う、Teである、[RFC3784。]
This is the ID of the remote end of the numbered TE link. It must be a network-unique number (since this section is devoted to numbered addressing), but it does not need to be a routable address in the control plane
これは番号付のTEリンクのリモートエンドのIDです。 ネットワークユニークな数であるに違いありません(このセクションが番号付のアドレシングにささげられるので)が、それは、制御飛行機の発送可能アドレスである必要がありません。
4.2. Numbered Addresses in RSVP-TE
4.2. RSVP-Teの番号付のアドレス
The following subsections describe the use of addresses in the GMPLS signaling protocol [RFC3209], [RFC3473].
[RFC3473]、以下の小区分はGMPLSシグナリングプロトコル[RFC3209]におけるアドレスの使用について説明します。
4.2.1. IP Tunnel End Point Address in Session Object
4.2.1. セッションオブジェクトのIPトンネルエンドポイントアドレス
The IP tunnel end point address of the Session Object [RFC3209] is either an IPv4 or IPv6 address.
Session Object[RFC3209]のIPトンネルエンドポイントアドレスは、IPv4かIPv6アドレスのどちらかです。
The Session Object is invariant for all messages relating to the same Label Switched Path (LSP). The initiator of a Path message sets the IP tunnel end point address in the Session Object to one of:
同じLabel Switched Path(LSP)に関連するすべてのメッセージに、Session Objectは不変です。 Pathメッセージの創始者は以下についてIPトンネルエンドポイントアドレスを1つへのSession Objectにはめ込みます。
o The TE Router ID of the egress since the TE Router ID is routable
and uniquely identifies the egress node.
o TE Router ID以来の出口のTE Router IDは、発送可能で、唯一出口ノードを特定します。
o The destination data plane address to precisely identify the
interface that should be used for the final hop of the LSP. That
is, the Remote Interface IP Address of the final TE link, if the
ingress knows that address.
o 正確にLSPの最終的なホップに使用されるべきであるインタフェースを特定する送付先データ飛行機アドレス。 イングレスがそのアドレスを知っているなら、すなわち、最終的なTEのRemote Interface IP Addressはリンクします。
Shiomoto, et al. Informational [Page 7] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto、他 GMPLSにおけるアドレスの情報[7ページ]のRFC4990使用は2007年9月をネットワークでつなぎます。
The IP tunnel end point address in the Session Object is not required to be routable in the control plane, but should be present in the TED.
Session ObjectのIPトンネルエンドポイントアドレスは、制御飛行機で発送可能であることが必要ではありませんが、TEDに存在しているべきです。
4.2.2. IP Tunnel Sender Address in Sender Template Object
4.2.2. 送付者テンプレートオブジェクトのIPトンネル送付者アドレス
The IP tunnel sender address of the Sender Template Object [RFC3209] is either an IPv4 or IPv6 address.
Sender Template Object[RFC3209]のIPトンネル送付者アドレスは、IPv4かIPv6アドレスのどちらかです。
When an LSP is being set up to support an IPv4-numbered FA, [RFC4206] recommends that the IP tunnel sender address be set to the head-end address of the TE link that is to be created so that the tail-end address can be inferred as the /31 partner address.
LSPがIPv4番号付のFAをサポートするためにセットアップされているとき、[RFC4206]は、IPトンネル送付者アドレスが/31パートナーアドレスとして末端アドレスを推論できるように作成されることになっているTEリンクのギヤエンドのアドレスに設定されることを勧めます。
When an LSP is being set up that will not be used to form an FA, the IP tunnel sender address in the Sender Template Object may be set to one of:
LSPであるときに、以下がセットアップされて、それがFAを形成するのに使用されないで、Sender Template ObjectのIPトンネル送付者アドレスが1つに設定されるかもしれないということであることがあります。
o The TE Router ID of the ingress LSR since the TE Router ID is a
unique, routable ID per node.
o 1ノードあたりTE Router ID以来のイングレスLSRのTE Router IDは1つのユニークで、発送可能なIDです。
o The sender data plane address (i.e., the Local Interface IP
Address).
o 送付者データ飛行機は(すなわち、Local Interface IP Address)を扱います。
4.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces
4.2.3. _ID RSVP_が番号付のインタフェースにオブジェクトを飛び越すなら
There are two addresses used in the IF_ID RSVP_HOP object.
中で使用された2つのアドレスがある、_ID RSVP_HOPが反対するなら。
1. The IPv4/IPv6 Next/Previous Hop Address [RFC3473]
1. 次か前のホップが扱うIPv4/IPv6[RFC3473]
When used in a Path or Resv messages, this address specifies the
IP reachable address of the control plane interface used to send
the messages, or the TE Router ID of the node that sends the
message. That is, it is a routable control plane address of the
sender of the message and can be used to send return messages.
Note that because of data plane / control plane separation (see
Section 7.1) and data plane robustness in the face of control
plane faults, it may be advisable to use the TE Router ID since it
is a more stable address.
PathかResvメッセージで使用されると、このアドレスはメッセージを送るのに使用されるコントロール飛行機インタフェースのIPの届いているアドレス、またはメッセージを送るノードのTE Router IDを指定します。 すなわち、それは、メッセージ送信者の発送可能規制飛行機アドレスであり、リターンメッセージを送るのに使用できます。 コントロール飛行機欠点に直面してデータ飛行機/コントロール飛行機分離(セクション7.1を見る)とデータ飛行機丈夫さのために、それがそれが、より安定したアドレスであるのでTE Router IDを使用するのにおいて賢明であるかもしれないことに注意してください。
2. The IPv4/IPv6 address in the Value Field of the Interface_ID TLV
[RFC3471]
2. Interface_ID TLVのValue FieldのIPv4/IPv6アドレス[RFC3471]
This address identifies the data channel associated with the
signaling message. In all cases, the data channel is indicated by
the use of the data plane local interface address at the upstream
LSR, that is, at the sender of the Path message.
このアドレスはシグナリングメッセージに関連しているデータ・チャンネルを特定します。 すべての場合では、データ・チャンネルは上流のLSRでデータ飛行機局所界面アドレスの使用で示されます、すなわち、Pathメッセージの送付者で。
Shiomoto, et al. Informational [Page 8] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto、他 GMPLSにおけるアドレスの情報[8ページ]のRFC4990使用は2007年9月をネットワークでつなぎます。
See Section 6.2 for a description of these fields when bundled links are used.
リンクであると添付されるとこれらの分野の記述のためのセクション6.2が使用されているのを確実にしてください。
4.2.4. Explicit Route Object (ERO)
4.2.4. 明白なルートオブジェクト(ERO)
The IPv4/IPv6 address in the ERO provides a data-plane identifier of an abstract node, TE node, or TE link to be part of the signaled LSP.
EROのIPv4/IPv6アドレスは抽象的なノードに関するデータ飛行機識別子を提供します、TEノード、または、TEが合図されたLSPの一部になるようにリンクします。
See Section 6 for a description of the use of addresses in the ERO.
EROにおけるアドレスの使用の記述に関してセクション6を見てください。
4.2.5. Record Route Object (RRO)
4.2.5. 記録的なルートオブジェクト(RRO)
The IPv4/IPv6 address in the RRO provides a data-plane identifier of either a TE node or a TE link that is part of an LSP that has been established or is being established.
RROのIPv4/IPv6アドレスは設立されるか、または設立されているLSPの一部であるTEノードかTEリンクのどちらかに関するデータ飛行機識別子を提供します。
See Section 6 for a description of the use of addresses in the RRO.
RROにおけるアドレスの使用の記述に関してセクション6を見てください。
4.2.6. IP Packet Source Address
4.2.6. IPパケットソースアドレス
GMPLS signaling messages are encapsulated in IP. The IP packet source address is either an IPv4 or IPv6 address and must be a reachable control plane address of the node sending the TE message. In order to provide control plane robustness, a stable IPv4 or IPv6 control plane address (for example, the TE Router ID) can be used.
GMPLSシグナリングメッセージはIPでカプセル化されます。 IPパケットソースアドレスは、IPv4かIPv6アドレスのどちらかであり、TEメッセージを送るノードの届いている規制飛行機アドレスであるに違いありません。 コントロール飛行機丈夫さを提供するために、安定したIPv4かIPv6規制飛行機アドレス(例えば、TE Router ID)を使用できます。
Some implementations may use the IP source address of a received IP packet containing a Path message as the destination IP address of a packet containing the corresponding Resv message (see Section 4.2.7). Using a stable IPv4 or IPv6 address in the IP packet containing the Path message supports this situation robustly when one of the control plane interfaces is down.
いくつかの実装が対応するResvメッセージを含むパケットの送付先IPアドレスとしてPathメッセージを含む容認されたIPパケットのIPソースアドレスを使用するかもしれません(セクション4.2.7を見てください)。 コントロール飛行機インタフェースの1つが下がっているとき、Pathメッセージを含んでいて、IPパケットで安定したIPv4かIPv6アドレスを使用すると、この状況は強壮にサポートします。
4.2.7. IP Packet Destination Address
4.2.7. IPパケット送付先アドレス
The IP packet destination address for an IP packet carrying a GMPLS signaling message is either an IPv4 or IPv6 address, and must be reachable in the control plane if the message is to be delivered. It must be an address of the intended next-hop recipient of the message. That is, unlike RSVP, the IP packet is not addressed to the ultimate destination (the egress).
GMPLSシグナリングメッセージを伝えるIPパケットのためのIPパケット送付先アドレスは、IPv4かIPv6アドレスのどちらかであり、メッセージが提供されることであるなら制御飛行機で届いているに違いありません。 それはメッセージの意図している次のホップ受取人のアドレスであるに違いありません。 すなわち、RSVPと異なって、IPパケットは最終仕向地(出口)に扱われません。
For a Path message, a stable IPv4 or IPv6 address of the next-hop node may be used. This may be the TE Router ID of the next-hop node. A suitable address may be determined by examining the TE advertisements for the TE link that will form the next-hop data link.
Pathメッセージのために、次のホップノードの安定したIPv4かIPv6アドレスが使用されるかもしれません。 これは次のホップノードのTE Router IDであるかもしれません。 適当なアドレスは、次のホップデータ・リンクを形成するTEリンクがないかどうかTE広告を調べることによって、決定するかもしれません。
Shiomoto, et al. Informational [Page 9] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto、他 GMPLSにおけるアドレスの情報[9ページ]のRFC4990使用は2007年9月をネットワークでつなぎます。
A Resv message is sent to the previous-hop node. The IPv4 or IPv6 destination of an IP packet carrying a Resv message may be any of the following:
前のホップノードにResvメッセージを送ります。 Resvメッセージを伝えるIPパケットのIPv4かIPv6の目的地が以下のいずれであるかもしれませんも:
o The IPv4 or IPv6 source address of the received IP packet
containing the Path message.
o Pathメッセージを含む容認されたIPパケットのIPv4かIPv6ソースアドレス。
o A stable IPv4 or IPv6 address of the previous node found by
examining the TE advertisements for the upstream data plane
interface.
o 上流のデータ飛行機インタフェースがないかどうかTE広告を調べることによって見つけられた前のノードの安定したIPv4かIPv6アドレス。
o The value in the received in the Next/Previous Hop Address field
of the RSVP_HOP (PHOP) Object [RFC2205].
o RSVP_HOP(PHOP)オブジェクト[RFC2205]のNext/前のHop Address分野で受け取られているところの値。
5. Unnumbered Addressing
5. 無数のアドレシング
An unnumbered address is the combination of a network-unique node identifier and a node-unique interface identifier.
無数のアドレスはネットワークユニークなノード識別子とノードユニークなインタフェース識別子の組み合わせです。
An unnumbered link is identified by the combination of the TE Router ID that is a reachable address in the control plane and a node-unique Interface ID [RFC3477].
無数のリンクは制御飛行機とノードユニークなInterface ID[RFC3477]で届いているアドレスであるTE Router IDの組み合わせで特定されます。
5.1. Unnumbered Addresses in IGPs
5.1. IGPsの無数のアドレス
In this section, we consider unnumbered address advertisement using OSPF-TE and IS-IS-TE.
そして、このセクションでは、私たちが、無数のアドレスが広告であるとOSPF-TEを使用することで考える、TEです。
5.1.1. Link Local/Remote Identifiers in OSPF-TE
5.1.1. OSPF-Teの地方の、または、リモートな識別子をリンクしてください。
Link Local and Link Remote Identifiers are carried in OSPF using a single sub-TLV of the Link TLV [RFC4203]. They advertise the IDs of an unnumbered TE link's local and remote ends, respectively. Link Local/Remote Identifiers are numbers unique within the scopes of the advertising LSR and the LSR managing the remote end of the link respectively [RFC3477].
リンクLocalとLink Remote Identifiersは、OSPFでLink TLV[RFC4203]の独身のサブTLVを使用することで運ばれます。 彼らはそれぞれ無数のTEリンクの地方の、そして、リモートな終わりのIDの広告を出します。 リンクLocal/リモートなIdentifiersはそれぞれリンクのリモートエンドを管理する広告LSRとLSR[RFC3477]の範囲の中でユニークな数です。
Note that these numbers are not network-unique and therefore cannot be used as TE link end identifiers on their own. An unnumbered TE link end network-wide identifier is comprised of two elements as defined in [RFC3477]:
これらの数はネットワークユニークでなく、したがって、TEが終わりの識別子をそれら自身のにリンクするとき使用できないことに注意してください。 ネットワーク全体の識別子が[RFC3477]で定義されるように2つの要素から成る無数のTEリンクエンド:
- A TE Router ID that is associated with the link local end
- リンクの地方のエンドに関連しているTE Router ID
- The link local identifier.
- リンクのローカルの識別子。
Shiomoto, et al. Informational [Page 10] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto、他 GMPLSにおけるアドレスの情報[10ページ]のRFC4990使用は2007年9月をネットワークでつなぎます。
5.1.2. Link Local/Remote Identifiers in IS-IS-TE
5.1.2. 地方の、または、リモートな識別子をリンクする、Teです。
The Link Local and Link Remote Identifiers are carried in IS-IS using a single sub-TLV of the Extended IS Reachability TLV. Link identifiers are exchanged in the Extended Local Circuit ID field of the "Point-to-Point Three-Way Adjacency" IS-IS Option type [RFC4205].
Link LocalとLink Remote Identifiersが運ばれる、-、Extendedの独身のサブTLVを使用するのは、Reachability TLVです。 「二地点間3者間の隣接番組」のExtended Local Circuit ID分野でリンク識別子を交換する、-、Optionは[RFC4205]をタイプします。
The same discussion of unique identification applies here as in Section 5.1.1.
ユニークな識別の同じ議論はセクション5.1.1のようにここに適用されます。
5.2. Unnumbered Addresses in RSVP-TE
5.2. RSVP-Teの無数のアドレス
We consider in this section the interface ID fields of objects used in RSVP-TE in the case of unnumbered addressing.
私たちはこのセクションでRSVP-TEで無数のアドレシングの場合に使用されるオブジェクトのインタフェースID分野を考えます。
5.2.1. Sender and End Point Addresses
5.2.1. 送付者とエンドポイントアドレス
The IP Tunnel End Point Address in the RSVP Session Object and the IP Tunnel Sender Address in the RSVP Sender Template Object cannot use unnumbered addresses [RFC3209], [RFC3473].
RSVP Session ObjectのIP Tunnel End Point AddressとRSVP Sender Template ObjectのIP Tunnel Sender Addressは無数のアドレス[RFC3209][RFC3473]を使用できません。
5.2.2. IF_ID RSVP_HOP Object for Unnumbered Interfaces
5.2.2. _ID RSVP_が無数のインタフェースにオブジェクトを飛び越すなら
The interface ID field in the IF_INDEX TLV specifies the interface of the data channel for an unnumbered interface.
中のインタフェースID分野、_INDEX TLVがデータのインタフェースを指定するなら、無数のインタフェースに精神を集中してください。
In both Path and Resv messages, the value of the interface ID in the IF_INDEX TLV specifies the local interface ID of the associated data channel at the upstream node (the node sending the Path message and receiving the Resv message).
PathとResvメッセージ、中のインタフェースIDの値の両方、_INDEX TLVが関連データの局所界面IDを指定するなら、上流のノード(Pathメッセージを送って、Resvメッセージを受け取るノード)で精神を集中してください。
See Section 6.2 for a description of the use bundled links.
リンクであると添付された使用の記述に関してセクション6.2を見てください。
5.2.3. Explicit Route Object (ERO)
5.2.3. 明白なルートオブジェクト(ERO)
The ERO may use an unnumbered identifier of a TE link to be part of the signaled LSP.
EROは、合図されたLSPの一部になるのにTEリンクの無数の識別子を使用するかもしれません。
See Section 6 for a description of the use of addresses in the ERO.
EROにおけるアドレスの使用の記述に関してセクション6を見てください。
5.2.4. Record Route Object (RRO)
5.2.4. 記録的なルートオブジェクト(RRO)
The RRO records the data-plane identifiers of TE nodes and TE links that are part of an LSP that has been established or is being established. TE links may be identified using unnumbered addressing.
RROは設立されるか、または設立されているLSPの一部であるTEノードとTEリンクに関するデータ飛行機識別子を記録します。 TEリンクは、無数のアドレシングを使用することで特定されるかもしれません。
See Section 6 for a description of the use of addresses in the RRO.
RROにおけるアドレスの使用の記述に関してセクション6を見てください。
Shiomoto, et al. Informational [Page 11] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto, et al. Informational [Page 11] RFC 4990 Use of Addresses in GMPLS Networks September 2007
5.2.5. LSP_Tunnel Interface ID Object
5.2.5. LSP_Tunnel Interface ID Object
The LSP_TUNNEL_INTERFACE_ID Object includes the LSR's Router ID and Interface ID, as described in [RFC3477], to specify an unnumbered Forward Adjacency Interface ID. The Router ID of the GMPLS-capable LSR must be set to the TE Router ID.
The LSP_TUNNEL_INTERFACE_ID Object includes the LSR's Router ID and Interface ID, as described in [RFC3477], to specify an unnumbered Forward Adjacency Interface ID. The Router ID of the GMPLS-capable LSR must be set to the TE Router ID.
5.2.6. IP Packet Addresses
5.2.6. IP Packet Addresses
IP packets can only be addressed to numbered addresses.
IP packets can only be addressed to numbered addresses.
6. RSVP-TE Message Content
6. RSVP-TE Message Content
This section examines the use of addresses in RSVP EROs and RROs, the identification of component links, and forwarding addresses for RSVP messages.
This section examines the use of addresses in RSVP EROs and RROs, the identification of component links, and forwarding addresses for RSVP messages.
6.1. ERO and RRO Addresses
6.1. ERO and RRO Addresses
EROs may contain strict or loose hop subobjects. These are discussed separately below. A separate section describes the use of addresses in the RRO.
EROs may contain strict or loose hop subobjects. These are discussed separately below. A separate section describes the use of addresses in the RRO.
Implementations making limited assumptions about the content of an ERO or RRO when processing a received RSVP message may cause or experience interoperability issues. Therefore, implementations that want to ensure full interoperability need to support the receipt for processing of all ERO and RRO options applicable to their hardware capabilities.
Implementations making limited assumptions about the content of an ERO or RRO when processing a received RSVP message may cause or experience interoperability issues. Therefore, implementations that want to ensure full interoperability need to support the receipt for processing of all ERO and RRO options applicable to their hardware capabilities.
Note that the phrase "receipt for processing" is intended to indicate that an LSR is not expected to look ahead in an ERO or process any subobjects that do not refer to the LSR itself or to the next hop in the ERO. An LSR is not generally expected to process an RRO except by adding its own information.
Note that the phrase "receipt for processing" is intended to indicate that an LSR is not expected to look ahead in an ERO or process any subobjects that do not refer to the LSR itself or to the next hop in the ERO. An LSR is not generally expected to process an RRO except by adding its own information.
Note also that implementations do not need to support the ERO options containing Component Link IDs if they do not support link bundling [RFC4201].
Note also that implementations do not need to support the ERO options containing Component Link IDs if they do not support link bundling [RFC4201].
ERO processing at region boundaries is described in [RFC4206].
ERO processing at region boundaries is described in [RFC4206].
6.1.1. Strict Subobject in ERO
6.1.1. Strict Subobject in ERO
Depending on the level of control required, a subobject in the ERO includes an address that may specify an abstract node (i.e., a group of nodes), a simple abstract node (i.e., a specific node), or a specific interface of a TE link in the data plane [RFC3209].
Depending on the level of control required, a subobject in the ERO includes an address that may specify an abstract node (i.e., a group of nodes), a simple abstract node (i.e., a specific node), or a specific interface of a TE link in the data plane [RFC3209].
Shiomoto, et al. Informational [Page 12] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto, et al. Informational [Page 12] RFC 4990 Use of Addresses in GMPLS Networks September 2007
A hop may be flagged as strict (meaning that the LSP must go directly to the identified next hop without any intervening nodes), or loose.
A hop may be flagged as strict (meaning that the LSP must go directly to the identified next hop without any intervening nodes), or loose.
If a hop is strict, the ERO may contain any of the following.
If a hop is strict, the ERO may contain any of the following.
1. Address prefix or AS number specifying a group of nodes.
1. Address prefix or AS number specifying a group of nodes.
2. TE Router ID identifying a specific node.
2. TE Router ID identifying a specific node.
3. Link ID identifying an incoming TE link.
3. Link ID identifying an incoming TE link.
4. Link ID identifying an outgoing TE link, optionally followed by a
Component Interface ID and/or one or two Labels.
4. Link ID identifying an outgoing TE link, optionally followed by a Component Interface ID and/or one or two Labels.
5. Link ID identifying an incoming TE link, followed by a Link ID
identifying an outgoing TE link, optionally followed by a
Component Interface ID and/or one or two Labels.
5. Link ID identifying an incoming TE link, followed by a Link ID identifying an outgoing TE link, optionally followed by a Component Interface ID and/or one or two Labels.
6. TE Router ID identifying a specific node, followed by a Link ID
identifying an outgoing TE link, optionally followed by a
Component Interface ID and/or one or two Labels.
6. TE Router ID identifying a specific node, followed by a Link ID identifying an outgoing TE link, optionally followed by a Component Interface ID and/or one or two Labels.
7. Link ID identifying an incoming TE link, followed by a TE Router
ID identifying a specific node, followed by a Link ID identifying
an outgoing TE link, optionally followed by Component Interface ID
and/or one or two Labels.
7. Link ID identifying an incoming TE link, followed by a TE Router ID identifying a specific node, followed by a Link ID identifying an outgoing TE link, optionally followed by Component Interface ID and/or one or two Labels.
The label value that identifies a single unidirectional resource between two nodes may be different from the perspective of upstream and downstream nodes. This is typically the case in fiber switching because the label value is a number indicating the port/fiber. It may also be the case for lambda switching, because the label value is an index for the lambda in the hardware and may not be a globally defined value such as the wavelength in nanometers.
The label value that identifies a single unidirectional resource between two nodes may be different from the perspective of upstream and downstream nodes. This is typically the case in fiber switching because the label value is a number indicating the port/fiber. It may also be the case for lambda switching, because the label value is an index for the lambda in the hardware and may not be a globally defined value such as the wavelength in nanometers.
The value of a label in any RSVP-TE object indicates the value from the perspective of the sender of the object/TLV [RFC3471]. Therefore, any label in an ERO is given using the upstream node's identification of the resource.
The value of a label in any RSVP-TE object indicates the value from the perspective of the sender of the object/TLV [RFC3471]. Therefore, any label in an ERO is given using the upstream node's identification of the resource.
Shiomoto, et al. Informational [Page 13] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto, et al. Informational [Page 13] RFC 4990 Use of Addresses in GMPLS Networks September 2007
6.1.2. Loose Subobject in ERO
6.1.2. Loose Subobject in ERO
There are two differences between Loose and Strict subobjects.
There are two differences between Loose and Strict subobjects.
o A subobject marked as a loose hop in an ERO must not be followed
by a subobject indicating a label value [RFC3473].
o A subobject marked as a loose hop in an ERO must not be followed by a subobject indicating a label value [RFC3473].
o A subobject marked as a loose hop in an ERO should never include
an identifier (i.e., address or ID) of the outgoing interface.
o A subobject marked as a loose hop in an ERO should never include an identifier (i.e., address or ID) of the outgoing interface.
There is no way to specify in an ERO whether a subobject identifies an incoming or outgoing TE link. Path computation must be performed by an LSR when it encounters a loose hop in order to resolve the LSP route to the identified next hop. If an interface is specified as a loose hop and is treated as an incoming interface, the path computation will select a path that enters an LSR through that interface. If the interface was intended to be used as an outgoing interface, the computed path may be unsatisfactory and the explicit route in the ERO may be impossible to resolve. Thus a loose hop that identifies an interface should always identify the incoming TE link in the data plane.
There is no way to specify in an ERO whether a subobject identifies an incoming or outgoing TE link. Path computation must be performed by an LSR when it encounters a loose hop in order to resolve the LSP route to the identified next hop. If an interface is specified as a loose hop and is treated as an incoming interface, the path computation will select a path that enters an LSR through that interface. If the interface was intended to be used as an outgoing interface, the computed path may be unsatisfactory and the explicit route in the ERO may be impossible to resolve. Thus a loose hop that identifies an interface should always identify the incoming TE link in the data plane.
6.1.3. RRO
6.1.3. RRO
The RRO is used on Path and Resv messages to record the path of an LSP. Each LSR adds subobjects to the RRO to record information. The information added to an RRO by a node should be the same in the Path and the Resv message although there may be some information that is not available during LSP setup.
The RRO is used on Path and Resv messages to record the path of an LSP. Each LSR adds subobjects to the RRO to record information. The information added to an RRO by a node should be the same in the Path and the Resv message although there may be some information that is not available during LSP setup.
One use of the RRO is to allow the operator to view the path of the LSP. At any transit node, it should be possible to construct the path of the LSP by joining together the RRO from the Path and the Resv messages.
One use of the RRO is to allow the operator to view the path of the LSP. At any transit node, it should be possible to construct the path of the LSP by joining together the RRO from the Path and the Resv messages.
It is also important that a whole RRO on a Resv message received at an ingress LSR can be used as an ERO on a subsequent Path message to completely recreate the LSP.
It is also important that a whole RRO on a Resv message received at an ingress LSR can be used as an ERO on a subsequent Path message to completely recreate the LSP.
Therefore, when a node adds one or more subobjects to an RRO, any of the following options is valid.
Therefore, when a node adds one or more subobjects to an RRO, any of the following options is valid.
1. TE Router ID identifying the LSR.
1. TE Router ID identifying the LSR.
2. Link ID identifying the incoming (upstream) TE link.
2. Link ID identifying the incoming (upstream) TE link.
3. Link ID identifying the outgoing (downstream) TE link, optionally
followed by a Component Interface ID and/or one or two Labels.
3. Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
Shiomoto, et al. Informational [Page 14] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto, et al. Informational [Page 14] RFC 4990 Use of Addresses in GMPLS Networks September 2007
4. Link ID identifying the incoming (upstream) TE link, followed by a
Link ID identifying the outgoing (downstream) TE link, optionally
followed by a Component Interface ID and/or one or two Labels.
4. Link ID identifying the incoming (upstream) TE link, followed by a Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
5. TE Router ID identifying the LSR, followed by a Link ID
identifying the outgoing (downstream) TE link, optionally followed
by a Component Interface ID and/or one or two Labels.
5. TE Router ID identifying the LSR, followed by a Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
6. Link ID identifying the incoming (upstream) TE link, followed by
the TE Router ID identifying the LSR, followed by a Link ID
identifying the outgoing (downstream) TE link, optionally followed
by a Component Interface ID and/or one or two Labels.
6. Link ID identifying the incoming (upstream) TE link, followed by the TE Router ID identifying the LSR, followed by a Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
An implementation may choose any of these options and must be prepared to receive an RRO that contains any of these options.
An implementation may choose any of these options and must be prepared to receive an RRO that contains any of these options.
6.1.4. Label Record Subobject in RRO
6.1.4. Label Record Subobject in RRO
RRO Label recording is requested by an ingress node setting the Label Recording flag in the SESSION_ATTRIBUTE object and including an RRO is included in the Path message as described in [RFC3209]. Under these circumstances, each LSR along the LSP should include label information in the RRO in the Path message if it is available.
RRO Label recording is requested by an ingress node setting the Label Recording flag in the SESSION_ATTRIBUTE object and including an RRO is included in the Path message as described in [RFC3209]. Under these circumstances, each LSR along the LSP should include label information in the RRO in the Path message if it is available.
As described in [RFC3209], the processing for a Resv message "mirrors that of the Path" and "The only difference is that the RRO in a Resv message records the path information in the reverse direction." This means that hops are added to the RRO in the reverse order, but the information added at each LSR is in the same order (see Sections 6.1.1, 6.1.2, and 6.1.3). Thus, when label recording is requested, labels are included in the RROs in both the Path and Resv messages.
As described in [RFC3209], the processing for a Resv message "mirrors that of the Path" and "The only difference is that the RRO in a Resv message records the path information in the reverse direction." This means that hops are added to the RRO in the reverse order, but the information added at each LSR is in the same order (see Sections 6.1.1, 6.1.2, and 6.1.3). Thus, when label recording is requested, labels are included in the RROs in both the Path and Resv messages.
6.2. Component Link Identification
6.2. Component Link Identification
When a bundled link [RFC4201] is used to provide a data channel, a component link identifier is specified in the Interface Identification TLV in the IF_ID RSVP_HOP Object in order to indicate which data channel from within the bundle is to be used. The Interface Identification TLV is IF_INDEX TLV (Type 3) in the case of an unnumbered component link and IPv4 TLV (Type 1) or IPv6 TLV (Type 2) in the case of a numbered component link.
When a bundled link [RFC4201] is used to provide a data channel, a component link identifier is specified in the Interface Identification TLV in the IF_ID RSVP_HOP Object in order to indicate which data channel from within the bundle is to be used. The Interface Identification TLV is IF_INDEX TLV (Type 3) in the case of an unnumbered component link and IPv4 TLV (Type 1) or IPv6 TLV (Type 2) in the case of a numbered component link.
The component link for the upstream data channel may differ from that for the downstream data channel in the case of a bidirectional LSP. In this case, the Interface Identification TLV specifying a downstream interface is followed by another Interface Identification TLV specifying an upstream interface.
The component link for the upstream data channel may differ from that for the downstream data channel in the case of a bidirectional LSP. In this case, the Interface Identification TLV specifying a downstream interface is followed by another Interface Identification TLV specifying an upstream interface.
Shiomoto, et al. Informational [Page 15] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto, et al. Informational [Page 15] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Note that identifiers in TLVs for upstream and downstream data channels in both Path and Resv messages are specified from the viewpoint of the upstream node (the node sending the Path message and receiving the Resv message), using identifiers belonging to the node.
Note that identifiers in TLVs for upstream and downstream data channels in both Path and Resv messages are specified from the viewpoint of the upstream node (the node sending the Path message and receiving the Resv message), using identifiers belonging to the node.
An LSR constructing an ERO may include a Link ID that identifies a bundled link. If the LSR knows the identities of the component links and wishes to exert control, it may also include component link identifiers in the ERO. Otherwise, the component link identifiers are not included in the ERO.
An LSR constructing an ERO may include a Link ID that identifies a bundled link. If the LSR knows the identities of the component links and wishes to exert control, it may also include component link identifiers in the ERO. Otherwise, the component link identifiers are not included in the ERO.
When a bundled link is in use, the RRO may include the Link ID that identifies the link bundle. Additionally, the RRO may include a component link identifier.
When a bundled link is in use, the RRO may include the Link ID that identifies the link bundle. Additionally, the RRO may include a component link identifier.
6.3. Forwarding Destination of Path Messages with ERO
6.3. Forwarding Destination of Path Messages with ERO
The final destination of the Path message is the Egress node that is specified by the tunnel end point address in the Session object.
The final destination of the Path message is the Egress node that is specified by the tunnel end point address in the Session object.
The Egress node must not forward the corresponding Path message downstream, even if the ERO includes the outgoing interface ID of the Egress node for Egress control [RFC4003].
The Egress node must not forward the corresponding Path message downstream, even if the ERO includes the outgoing interface ID of the Egress node for Egress control [RFC4003].
7. Topics Related to the GMPLS Control Plane
7. Topics Related to the GMPLS Control Plane
7.1. Control Channel Separation
7.1. Control Channel Separation
In GMPLS, a control channel can be separated from the data channel and there is not necessarily a one-to-one association of a control channel to a data channel. Two nodes that are adjacent in the data plane may have multiple IP hops between them in the control plane.
In GMPLS, a control channel can be separated from the data channel and there is not necessarily a one-to-one association of a control channel to a data channel. Two nodes that are adjacent in the data plane may have multiple IP hops between them in the control plane.
There are two broad types of separated control planes: native and tunneled. These differ primarily in the nature of encapsulation used for signaling messages, which also results in slightly different address handling with respect to the control plane address.
There are two broad types of separated control planes: native and tunneled. These differ primarily in the nature of encapsulation used for signaling messages, which also results in slightly different address handling with respect to the control plane address.
7.1.1. Native and Tunneled Control Plane
7.1.1. Native and Tunneled Control Plane
A native control plane uses IP forwarding to deliver RSVP-TE messages between protocol speakers. The message is not further encapsulated.
A native control plane uses IP forwarding to deliver RSVP-TE messages between protocol speakers. The message is not further encapsulated.
IP forwarding applies normal rules to the IP header. Note that an IP hop must not decrement the TTL of the received RSVP-TE message.
IP forwarding applies normal rules to the IP header. Note that an IP hop must not decrement the TTL of the received RSVP-TE message.
For the case where two adjacent nodes have multiple IP hops between them in the control plane, then as stated in Section 9 of [RFC3945],
For the case where two adjacent nodes have multiple IP hops between them in the control plane, then as stated in Section 9 of [RFC3945],
Shiomoto, et al. Informational [Page 16] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto, et al. Informational [Page 16] RFC 4990 Use of Addresses in GMPLS Networks September 2007
implementations should use the mechanisms of Section 6.1.1 of [RFC4206] whether or not they use LSP Hierarchy. Note that Section 6.1.1 of [RFC4206] applies to an "FA-LSP" as stated in that section, but also to a "TE link" for the case where a normal TE link is used.
implementations should use the mechanisms of Section 6.1.1 of [RFC4206] whether or not they use LSP Hierarchy. Note that Section 6.1.1 of [RFC4206] applies to an "FA-LSP" as stated in that section, but also to a "TE link" for the case where a normal TE link is used.
With a tunneled control plane, the RSVP-TE message is packaged in an IP packet that is inserted into a tunnel such that the IP packet will traverse exactly one IP hop. Various tunneling techniques can be used including (but not limited to) IP-in-IP, Generic Routing Encapsulation (GRE), and IP in MPLS.
With a tunneled control plane, the RSVP-TE message is packaged in an IP packet that is inserted into a tunnel such that the IP packet will traverse exactly one IP hop. Various tunneling techniques can be used including (but not limited to) IP-in-IP, Generic Routing Encapsulation (GRE), and IP in MPLS.
Where the tunneling mechanism includes a TTL, it should be treated as for any network message sent on that network. Implementations receiving RSVP-TE messages on the tunnel interface must not compare the RSVP-TE TTL to any other TTL (whether the IP TTL or the tunnel TTL).
Where the tunneling mechanism includes a TTL, it should be treated as for any network message sent on that network. Implementations receiving RSVP-TE messages on the tunnel interface must not compare the RSVP-TE TTL to any other TTL (whether the IP TTL or the tunnel TTL).
It has been observed that some implementations do not support the tunneled control plane features, and it is suggested that to enable interoperability, all implementations should support at least a native control plane.
It has been observed that some implementations do not support the tunneled control plane features, and it is suggested that to enable interoperability, all implementations should support at least a native control plane.
7.2. Separation of Control and Data Plane Traffic
7.2. Separation of Control and Data Plane Traffic
Data traffic must not be transmitted through the control plane. This is crucial when attempting PSC (Packet-Switching Capable) GMPLS with separated control and data channels.
Data traffic must not be transmitted through the control plane. This is crucial when attempting PSC (Packet-Switching Capable) GMPLS with separated control and data channels.
8. Addresses in the MPLS and GMPLS TE MIB Modules
8. Addresses in the MPLS and GMPLS TE MIB Modules
This section describes a method of defining or monitoring an LSP tunnel using the MPLS-TE-STD-MIB module [RFC3812] and GMPLS-TE-STD- MIB module [RFC4802] where the ingress and/or egress routers are identified using 128-bit IPv6 addresses. This is the case when the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects in the mplsTunnelTable [RFC3812] cannot be used to carry the tunnel end point address and Extended Tunnel Id fields from the signaled Session Object because the IPv6 variant (LSP_TUNNEL_IPv6_SESSION object) is in use.
This section describes a method of defining or monitoring an LSP tunnel using the MPLS-TE-STD-MIB module [RFC3812] and GMPLS-TE-STD- MIB module [RFC4802] where the ingress and/or egress routers are identified using 128-bit IPv6 addresses. This is the case when the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects in the mplsTunnelTable [RFC3812] cannot be used to carry the tunnel end point address and Extended Tunnel Id fields from the signaled Session Object because the IPv6 variant (LSP_TUNNEL_IPv6_SESSION object) is in use.
The normative text for MIB objects for control and monitoring MPLS and GMPLS nodes is found in the RFCs referenced above. This section makes no changes to those objects, but describes how they may be used to provide the necessary function.
The normative text for MIB objects for control and monitoring MPLS and GMPLS nodes is found in the RFCs referenced above. This section makes no changes to those objects, but describes how they may be used to provide the necessary function.
Shiomoto, et al. Informational [Page 17] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto, et al. Informational [Page 17] RFC 4990 Use of Addresses in GMPLS Networks September 2007
8.1. Handling IPv6 Source and Destination Addresses
8.1. Handling IPv6 Source and Destination Addresses
8.1.1. Identifying LSRs
8.1.1. Identifying LSRs
For this feature to be used, all LSRs in the network must advertise a 32-bit value that can be used to identify the LSR. In this document, this is referred to as the 32-bit LSR ID. The 32-bit LSR ID is the OSPFv3 router ID [RFC2740] or the ISIS IPv4 TE Router ID [RFC3784]. Note that these are different from TE router ID (see Section 2).
For this feature to be used, all LSRs in the network must advertise a 32-bit value that can be used to identify the LSR. In this document, this is referred to as the 32-bit LSR ID. The 32-bit LSR ID is the OSPFv3 router ID [RFC2740] or the ISIS IPv4 TE Router ID [RFC3784]. Note that these are different from TE router ID (see Section 2).
8.1.2. Configuring GMPLS Tunnels
8.1.2. Configuring GMPLS Tunnels
When setting up RSVP TE tunnels, it is common practice to copy the values of the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields in the MPLS TE MIB mplsTunnelTable [RFC3812] into the Extended Tunnel ID and IPv4 tunnel end point address fields, respectively, in the RSVP-TE LSP_TUNNEL_IPv4 SESSION object [RFC3209].
When setting up RSVP TE tunnels, it is common practice to copy the values of the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields in the MPLS TE MIB mplsTunnelTable [RFC3812] into the Extended Tunnel ID and IPv4 tunnel end point address fields, respectively, in the RSVP-TE LSP_TUNNEL_IPv4 SESSION object [RFC3209].
This approach cannot be used when the ingress and egress routers are identified by 128-bit IPv6 addresses as the mplsTunnelIngressLSRId, and mplsTunnelEgressLSRId fields are defined to be 32-bit values [RFC3811], [RFC3812].
This approach cannot be used when the ingress and egress routers are identified by 128-bit IPv6 addresses as the mplsTunnelIngressLSRId, and mplsTunnelEgressLSRId fields are defined to be 32-bit values [RFC3811], [RFC3812].
Instead, the IPv6 addresses should be configured in the mplsHopTable as the first and last hops of the mplsTunnelHopTable entries defining the explicit route for the tunnel. Note that this implies that a tunnel with IPv6 source and destination addresses must have an explicit route configured, although it should be noted that the configuration of an explicit route in this way does not imply that an explicit route will be signaled.
Instead, the IPv6 addresses should be configured in the mplsHopTable as the first and last hops of the mplsTunnelHopTable entries defining the explicit route for the tunnel. Note that this implies that a tunnel with IPv6 source and destination addresses must have an explicit route configured, although it should be noted that the configuration of an explicit route in this way does not imply that an explicit route will be signaled.
In more detail, the tunnel is configured at the ingress router as follows. See [RFC3812] for definitions of MIB table objects and for default (that is, "normal") behavior.
In more detail, the tunnel is configured at the ingress router as follows. See [RFC3812] for definitions of MIB table objects and for default (that is, "normal") behavior.
The mplsTunnelIndex and mplsTunnelInstance fields are set as normal.
The mplsTunnelIndex and mplsTunnelInstance fields are set as normal.
The mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields should be set to 32-bit LSR IDs for ingress and egress LSRs, respectively.
The mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields should be set to 32-bit LSR IDs for ingress and egress LSRs, respectively.
The mplsTunnelHopTableIndex must be set to a non-zero value. That is, an explicit route must be specified.
The mplsTunnelHopTableIndex must be set to a non-zero value. That is, an explicit route must be specified.
The first hop of the explicit route must have mplsTunnelHopAddrType field set to ipv6(2) and should have the mplsTunnelHopIpAddr field set to a global scope IPv6 address of the ingress router that is reachable in the control plane.
The first hop of the explicit route must have mplsTunnelHopAddrType field set to ipv6(2) and should have the mplsTunnelHopIpAddr field set to a global scope IPv6 address of the ingress router that is reachable in the control plane.
Shiomoto, et al. Informational [Page 18] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto, et al. Informational [Page 18] RFC 4990 Use of Addresses in GMPLS Networks September 2007
The last hop of the explicit route must have mplsTunnelHopAddrType field set to ipv6(2) and should have the mplsTunnelHopIpAddr field set to a global scope IPv6 address of the egress router that is reachable in the control plane.
The last hop of the explicit route must have mplsTunnelHopAddrType field set to ipv6(2) and should have the mplsTunnelHopIpAddr field set to a global scope IPv6 address of the egress router that is reachable in the control plane.
The ingress router should set the signaled values of the Extended
The ingress router should set the signaled values of the Extended
Tunnel ID and IPv6 tunnel end point address fields, respectively, of the RSVP-TE LSP_TUNNEL_IPv6 SESSION object [RFC3209] from the mplsTunnelHopIpAddr object of the first and last hops in the configured explicit route.
Tunnel ID and IPv6 tunnel end point address fields, respectively, of the RSVP-TE LSP_TUNNEL_IPv6 SESSION object [RFC3209] from the mplsTunnelHopIpAddr object of the first and last hops in the configured explicit route.
8.2. Managing and Monitoring Tunnel Table Entries
8.2. Managing and Monitoring Tunnel Table Entries
In addition to their use for configuring LSPs as described in Section 8.1, the TE MIB modules (MPLS-TE-STD-MIB and GMPLS-TE-STD-MIB) may be used for managing and monitoring MPLS and GMPLS TE LSPs, respectively. This function is particularly important at egress and transit LSRs.
In addition to their use for configuring LSPs as described in Section 8.1, the TE MIB modules (MPLS-TE-STD-MIB and GMPLS-TE-STD-MIB) may be used for managing and monitoring MPLS and GMPLS TE LSPs, respectively. This function is particularly important at egress and transit LSRs.
For a tunnel with IPv6 source and destination addresses, an LSR implementation should return values in the mplsTunnelTable as follows (where "normal" behavior is the default taken from [RFC3812]).
For a tunnel with IPv6 source and destination addresses, an LSR implementation should return values in the mplsTunnelTable as follows (where "normal" behavior is the default taken from [RFC3812]).
The mplsTunnelIndex and mplsTunnelInstance fields are set as normal.
The mplsTunnelIndex and mplsTunnelInstance fields are set as normal.
The mplsTunnelIngressLSRId field and mplsTunnelEgressLSRId are set to 32-bit LSR IDs. That is, each transit and egress router maps from the IPv6 address in the Extended Tunnel ID field to the 32-bit LSR ID of the ingress LSR. Each transit router also maps from the IPv6 address in the IPv6 tunnel end point address field to the 32-bit LSR ID of the egress LSR.
The mplsTunnelIngressLSRId field and mplsTunnelEgressLSRId are set to 32-bit LSR IDs. That is, each transit and egress router maps from the IPv6 address in the Extended Tunnel ID field to the 32-bit LSR ID of the ingress LSR. Each transit router also maps from the IPv6 address in the IPv6 tunnel end point address field to the 32-bit LSR ID of the egress LSR.
9. Security Considerations
9. Security Considerations
In the interoperability testing we conducted, the major issue we found was the use of control channels for forwarding data. This was due to the setting of both control and data plane addresses to the same value in PSC (Packet-Switching Capable) equipment. This occurred when attempting to test PSC GMPLS with separated control and data channels. What resulted instead were parallel interfaces with the same addresses. This could be avoided simply by keeping the addresses for the control and data plane separate.
In the interoperability testing we conducted, the major issue we found was the use of control channels for forwarding data. This was due to the setting of both control and data plane addresses to the same value in PSC (Packet-Switching Capable) equipment. This occurred when attempting to test PSC GMPLS with separated control and data channels. What resulted instead were parallel interfaces with the same addresses. This could be avoided simply by keeping the addresses for the control and data plane separate.
Shiomoto, et al. Informational [Page 19] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto, et al. Informational [Page 19] RFC 4990 Use of Addresses in GMPLS Networks September 2007
10. Acknowledgments
10. Acknowledgments
The following people made textual contributions to this document:
The following people made textual contributions to this document:
Alan Davey, Yumiko Kawashima, Kaori Shimizu, Thomas D. Nadeau,
Ashok Narayanan, Eiji Oki, Lyndon Ong, Vijay Pandian, Hari
Rakotoranto, and Adrian Farrel.
Alan Davey, Yumiko Kawashima, Kaori Shimizu, Thomas D. Nadeau, Ashok Narayanan, Eiji Oki, Lyndon Ong, Vijay Pandian, Hari Rakotoranto, and Adrian Farrel.
The authors would like to thank Adrian Farrel for the helpful discussions and the feedback he gave on the document. In addition, Jari Arkko, Arthi Ayyangar, Deborah Brungard, Diego Caviglia, Lisa Dusseault, Dimitri Papadimitriou, Jonathan Sadler, Hidetsugu Sugiyama, and Julien Meuric provided helpful comments and suggestions.
The authors would like to thank Adrian Farrel for the helpful discussions and the feedback he gave on the document. In addition, Jari Arkko, Arthi Ayyangar, Deborah Brungard, Diego Caviglia, Lisa Dusseault, Dimitri Papadimitriou, Jonathan Sadler, Hidetsugu Sugiyama, and Julien Meuric provided helpful comments and suggestions.
Adrian Farrel edited the final revisions of this document before and after working group last call.
Adrian Farrel edited the final revisions of this document before and after working group last call.
11. References
11. References
11.1. Normative References
11.1. Normative References
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[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) Extensions to OSPF Version 2", RFC 3630, September 2003.
Shiomoto, et al. Informational [Page 20] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto, et al. Informational [Page 20] RFC 4990 Use of Addresses in GMPLS Networks September 2007
[RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of
Textual Conventions (TCs) for Multiprotocol Label Switching
(MPLS) Management", RFC 3811, June 2004.
[RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", RFC 3812, June
2004.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control",
RFC 4003, February 2005.
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
[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, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[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., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-protocol Label Switching", RFC
4203, October 2005.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-protocol Label Switching", RFC 4203, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
Generalized MPLS TE", RFC 4206, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", RFC 4206, October 2005.
11.2. Informative References
11.2. Informative References
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
2740, December 1999.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
System to Intermediate System (IS-IS) Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)", RFC
4205, October 2005.
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
Shiomoto, et al. Informational [Page 21] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto, et al. Informational [Page 21] RFC 4990 Use of Addresses in GMPLS Networks September 2007
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Traffic Engineering
Management Information Base", RFC 4802, February 2007.
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
Authors' Addresses
Authors' Addresses
Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori Musashino, Tokyo 180-8585 Japan
Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori Musashino, Tokyo 180-8585 Japan
Phone: +81 422 59 4402 EMail: shiomoto.kohei@lab.ntt.co.jp
Phone: +81 422 59 4402 EMail: shiomoto.kohei@lab.ntt.co.jp
Richard Rabbat Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043
Richard Rabbat Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043
Phone: +1 650-714-7618 EMail: rabbat@alum.mit.edu
Phone: +1 650-714-7618 EMail: rabbat@alum.mit.edu
Rajiv Papneja Isocore Corporation 12359 Sunrise Valley Drive, Suite 100 Reston, Virginia 20191 United States of America
Rajiv Papneja Isocore Corporation 12359 Sunrise Valley Drive, Suite 100 Reston, Virginia 20191 United States of America
Phone: +1 703-860-9273 EMail: rpapneja@isocore.com
Phone: +1 703-860-9273 EMail: rpapneja@isocore.com
Shiomoto, et al. Informational [Page 22] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Shiomoto, et al. Informational [Page 22] RFC 4990 Use of Addresses in GMPLS Networks September 2007
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
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.
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Shiomoto, et al. Informational [Page 23]
Shiomoto、他 情報[23ページ]
一覧
スポンサーリンク
