Network Working Group K. Shiomoto
Request for Comments: 4990 NTT
Category: Informational R. Papneja
Isocore
R. Rabbat
Google
September 2007
Use of Addresses
in Generalized Multiprotocol Label Switching (GMPLS) Networks
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.
この文書では、一般マルチプロトコルラベルスイッチング（GMPLS）ネットワーク内のアドレスの使用を明確にしています。目的は、GMPLS対応のラベルスイッチングルータ（LSRの）のインターワーキングを容易にすることです。文書は、実装で得た経験、相互運用性テスト、および展開に基づいています。
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トラフィックエンジニアリング（TE）管理情報ベース（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.
この文書は、新しい手順やプロセスを定義していません。この文書は、要件のステートメントや勧告を行いたびに、これらは、参照RFCで規範的なテキストから取得されます。
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
10. Acknowledgments ...............................................20
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................21
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.
この情報資料は、一般マルチプロトコルラベルスイッチング（GMPLS）[RFC3945]ネットワーク内のアドレスの使用を明確にしています。目的は、GMPLS対応のラベルスイッチングルータ（LSRの）のインターワーキングを容易にすることです。文書は、実装で得た経験、相互運用性テスト、および展開に基づいています。
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 OSPF [RFC4203]、RSVP-TE [RFC3473]、およびGMPLS ISIS [RFC4205]）をGMPLSプロトコル内のアドレスと識別子フィールドを解釈する方法について説明し、どのように特定の制御プレーンのためにこれらのフィールドに設定するアドレスかを選択します使用モデル。
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.
この文書は、新しい手順やプロセスを定義しないと、上記のプロトコル仕様は決定的として扱われるべきです。この文書は、要件のステートメントや勧告を行いどこさらに、これらは、参照RFCで規範的なテキストから取得されます。本書の内容は規範的と見なされるべきではありません。
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トラフィックエンジニアリング（TE）管理情報ベース（MIB）モジュール[RFC3812]、[RFC4802]でのIPv6送信元と宛先を処理する方法について説明します。
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.
制御プレーンでは、シグナリングまたはルーティングプロトコルを使用して通信ソフトウェア実装されているプロトコルのスピーカーがあります。これらは、制御プレーンエンティティであり、物理的には、制御データプレーンエンティティとは別個に配置することができます。さらに、別のルーティング・エンティティとのシグナリングエンティティが存在してもよいです。
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).
コントロールプレーンとデータプレーンエンティティの組み合わせはラベルスイッチングルータ（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.
用語「ルータIDは」GMPLS内の二つのコンテキストで使用されることに注意してください。これは、ルーティングプロトコルに参加者の識別子を参照することができる、又はそれは、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ループバックアドレス：それへのIP接続[RFC3477]、[RFC3630]が存在する場合、ループバックアドレスが常に到達可能である広告ルータの安定したIPアドレスです。したがって、例えば、IPv4の24分の127アドレスは、この定義から除外されます。
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]は、ルータIDはOSPFを実行している各ルータに割り当てられた32ビットのネットワーク固有の番号であると定義します。 IS-IS [RFC1195]は、システムのIDで同様の概念を含んでいます。この文書では、ルーティングプロトコルを実行しているルータの「ルータID」として、両方の概念を説明します。オペレータが同じノードに到達可能なIPアドレスに設定することができるものの、ルータIDは、到達可能な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].
TEリンクをO：「TEリンクは、2つのGMPLSノードとの間に、IS-IS / OSPFリンク状態広告および特定の物理リソースのリンク状態データベース内の表現であり、その特性」[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 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データプレーンノード：TEグラフ上の頂点。これは、データプレーンスイッチまたはルータです。データプレーンノードは、物理データリンクから構成されているTEリンクによって接続されています。データプレーンノードは、管理および制御プレーン動作のいくつかの組み合わせによって制御されます。データプレーンノードは、制御プレーンノードの完全または部分的な制御下にあってもよいです。
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：インターフェイス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.
適用可能であるいずれか、IPv4のTTLフィールドまたはIPv6ホップリミットフィールド：O IP時間（TTL）をライブします。
o TED: Traffic Engineering Database.
O TED：トラフィックエンジニアリングデータベース。
o LSR: Label Switching Router.
O LSR：ラベルスイッチングルータ。
o FA: Forwarding Adjacency.
O FA：転送隣接。
o IGP: Interior Gateway Protocol.
IGP O：インテリアゲートウェイプロトコル。
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 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は、番号、または唯一の非番号として構成され、独自のリンクをサポートすることが可能として構成され、独自のリンクをサポートすることもできます。これは、の相互運用性の問題につながる可能性があるので、しかし、LSRは、番号またはアンナンバードリンクを使用する他のLSRの選択肢を制限してはなりません。したがって、ノードは、番号と無数の両方のアドレスを含むリンク広告を受け入れて処理することができなければなりません。
Numbered and unnumbered addressing is described in Sections 4 and 5 of this document, respectively.
番号とアドレッシング無数は、それぞれ、セクション4と、この文書の5に記載されています。
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アドレス）によって識別されます。
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].
このセクションでは、我々は2つのGMPLS用に定義された拡張子を持つインテリアゲートウェイプロトコル（IGPの）を使用して取り組む番話し合う：OSPF-TEをし、IS-IS-TE。 GMPLSのルーティング拡張は[RFC3630]、[RFC3784]、[RFC4202]、[RFC4203]及び[RFC4205]で定義されています。
The IGPs define a field called the "Router Address". It is used to advertise the TE Router ID.
IGPは、「ルータアドレス」と呼ばれるフィールドを定義します。 TEルータIDを宣伝するために使用されます。
The Router Address is advertised in OSPF-TE using the Router Address TLV structure of the TE Link State Advertisement (LSA) [RFC3630].
ルータアドレスは、TEリンクステートアドバタイズメント（LSA）[RFC3630]のルータアドレスTLV構造を使用してOSPF-TEに広告を出しています。
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].
IS-IS-TEにおいては、これはトラフィックエンジニアリングルータIDと呼ばれ、そしてアドバタイズトラフィックエンジニアリングルータID TLV [RFC3784]で運ばれます。
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リンクのリモートエンドのルータIDは、リンク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.
IS-IS-TE [RFC3784]では、拡張到達可能性TLVは、システムIDを搬送するために使用されます。第2節で説明したように、このルータIDに相当します。
The Local Interface IP Address is advertised in:
ローカル・インタフェースのIPアドレスがでアドバタイズされます。
o the Local Interface IP Address sub-TLV in OSPF-TE [RFC3630]
OSPF-TEにおけるローカル・インタフェースIPアドレスのサブTLV [RFC3630] O
o the IPv4 Interface Address sub-TLV in IS-IS-TE [RFC3784].
IS-IS-TEでのIPv4インタフェースアドレスサブTLV [RFC3784] O。
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です。これは、ネットワーク固有の番号でなければなりません（このセクションは、アドレッシングの番号に専念しているので）、それはコントロールプレーンでルーティング可能なアドレスである必要はありません。
The Remote Interface IP Address is advertised in:
リモートインタフェースのIPアドレスがでアドバタイズされます。
o the Remote Interface IP Address sub-TLV in OSPF-TE [RFC3630]
OリモートインタフェースのIPアドレスのOSPF-TEにおけるサブTLV [RFC3630]
o the IPv4 Neighbor Address sub-TLV in IS-IS-TE [RFC3784].
IS-IS-TEでのIPv4ネイバーアドレスサブTLV [RFC3784] O。
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です。 （このセクションはアドレッシングの番号に専念しているので）これは、ネットワーク固有の番号でなければなりませんが、それはコントロールプレーンでルーティング可能なアドレスである必要はありません。
The following subsections describe the use of addresses in the GMPLS signaling protocol [RFC3209], [RFC3473].
以下のサブセクションでは、GMPLSシグナリングプロトコルに[RFC3209]、[RFC3473]をアドレスの使用を記載しています。
The IP tunnel end point address of the Session Object [RFC3209] is either an IPv4 or IPv6 address.
セッションオブジェクト[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:
セッションオブジェクトは、同じラベルスイッチパス（LSP）に関連するすべてのメッセージに対して不変です。 Pathメッセージのイニシエータは、のいずれかにセッションオブジェクトにIPトンネルエンドポイントアドレスを設定します。
o The TE Router ID of the egress since the TE Router ID is routable and uniquely identifies the egress node.
TEルータIDがルーティング可能であり、一意の出口ノードを特定するための出口のTEルータID O。
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リンクのリモートインタフェースのIPアドレスです。
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.
セッションオブジェクトにIPトンネルエンドポイントアドレスは、制御プレーンにルーティング可能である必要はないが、TED中に存在すべきです。
The IP tunnel sender address of the Sender Template Object [RFC3209] is either an IPv4 or IPv6 address.
送信者テンプレートオブジェクトのIPトンネルの送信元アドレス[RFC3209]は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トンネルの送信元アドレスが末尾アドレスができるように作成されるTEリンクのヘッドエンドアドレスに設定することをお勧めします/ 31パートナーアドレスとして推測されます。
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を形成するために使用されないことに設定されている場合、送信者テンプレートオブジェクトにIPトンネル送信元アドレスのいずれかに設定することができます。
o The TE Router ID of the ingress LSR since the TE Router ID is a unique, routable ID per node.
TEルータIDは、ノードごとに固有の、ルーティング可能なIDであるので、入口LSRのTEルータID O。
o The sender data plane address (i.e., the Local Interface IP Address).
差出人データ・プレーン・アドレス（すなわち、ローカルインターフェイスIPアドレス）O。
There are two addresses used in the IF_ID RSVP_HOP object.
IF_ID RSVP_HOPオブジェクトで使用される2つのアドレスがあります。
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.
パスまたはRESVメッセージで使用される場合、このアドレスは、メッセージ、またはメッセージを送信するノードのTEルータIDを送信するために使用される制御プレーンインターフェースのIP到達可能なアドレスを指定します。つまり、メッセージの送信者のルーティング可能なコントロールプレーンアドレスで、リターンメッセージを送信するために使用することが可能です。それはより安定したアドレスであるのでための制御プレーン障害の面でデータプレーン/制御プレーンの分離（7.1節を参照）、データ・プレーン・ロバスト性、TEルータIDを使用するのが望ましいことがあることに留意されたいです。
2. The IPv4/IPv6 address in the Value Field of the Interface_ID TLV [RFC3471]
Interface_ID TLVの値フィールド[RFC3471] 2.のIPv4 / IPv6アドレス
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.
このアドレスは、シグナリングメッセージに関連するデータ・チャネルを識別する。全ての場合において、データチャネルは、Pathメッセージの送信者に、つまり、上流のLSRでデータプレーンのローカルインタフェースのアドレスを使用することによって示されています。
See Section 6.2 for a description of these fields when bundled links are used.
バンドルリンクが使用されているこれらのフィールドの説明については、セクション6.2を参照してください。
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アドレスが通知LSPの一部であることを抽象ノード、TEノード、またはTEリンクのデータプレーンの識別子を提供します。
See Section 6 for a description of the use of addresses in the ERO.
EROのアドレスの使用の詳細については、第6章を参照してください。
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アドレスは、TEノードまたは確立されている、または確立されているLSPの一部であるTEリンクのいずれかのデータプレーンの識別子を提供します。
See Section 6 for a description of the use of addresses in the RRO.
RROのアドレスの使用の詳細については、第6章を参照してください。
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メッセージを送信するノードの到達可能な制御プレーン・アドレスでなければなりません。制御プレーンロバスト性を提供するために、（例えば、TEルータID）安定したIPv4またはIPv6制御プレーン・アドレスを使用することができます。
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.
いくつかの実装（セクション4.2.7を参照）に対応するResvメッセージを含むパケットの宛先IPアドレスとしてPathメッセージを含む受信したIPパケットのIPソースアドレスを使用することができます。コントロールプレーンインターフェイスのいずれかがダウンした場合、Pathメッセージを含むIPパケットで安定したIPv4またはIPv6アドレスを使用して堅牢にこの状況をサポートします。
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ルータIDであってもよいです。適切なアドレスは、次ホップのデータ・リンクを形成するTEリンクのTEアドバタイズメントを調べることによって決定することができます。
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.
Pathメッセージを含む受信したIPパケットのIPv4またはIPv6ソースアドレスO。
o A stable IPv4 or IPv6 address of the previous node found by examining the TE advertisements for the upstream data plane interface.
上りデータプレーンインターフェイスのTEアドバタイズメントを調べることによって見出さ前のノードの安定したIPv4またはIPv6アドレス、O。
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]の前/次ホップアドレスフィールドに受信した値。
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].
無数のリンクは、制御プレーンとノード固有のインタフェースIDに到達可能なアドレス[RFC3477]であるTEルータIDの組み合わせによって識別されます。
In this section, we consider unnumbered address advertisement using OSPF-TE and IS-IS-TE.
このセクションでは、OSPF-TEおよびIS-IS-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].
ローカルリンクとリンクTLV [RFC4203]の単一のサブTLVを使用してOSPFに運ばれるリモート識別子をリンクします。彼らはそれぞれ、非番号TEリンクのローカルおよびリモートエンドのIDをアドバタイズします。リンクローカル/リモート識別子は、それぞれのリンク[RFC3477]のリモートエンドを管理する広告LSRおよびLSRのスコープ内で一意の番号です。
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]で定義されるように無数のTEリンクエンドネットワーク全体の識別子は二つの要素から構成されています。
- A TE Router ID that is associated with the link local end
- リンクローカルエンドに関連付けられているTEルータID
- The link local identifier.
- リンクローカル識別子。
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].
リンクローカルおよびリモートリンク識別子は、IS-ISがIS拡張到達可能性TLVの単一のサブTLVを使用して実施されています。リンク識別子は、オプションタイプ[RFC4205] IS-IS「ポイントツーポイントスリーウェイ隣接」の拡張ローカル回線IDフィールドで交換されています。
The same discussion of unique identification applies here as in Section 5.1.1.
一意の識別の同様の議論は、セクション5.1.1のように、ここで適用されます。
We consider in this section the interface ID fields of objects used in RSVP-TE in the case of unnumbered addressing.
私たちは、このセクションに取り組む番号なしの場合にはRSVP-TEで使用されるオブジェクトのインタフェースIDフィールドを検討してください。
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セッションオブジェクト内IPトンネルのエンドポイントアドレスとRSVP送信者テンプレートオブジェクト内IPトンネルの送信者アドレスは、番号の付いていないアドレス[RFC3209]、[RFC3473]を使用することはできません。
The interface ID field in the IF_INDEX TLV specifies the interface of the data channel for an unnumbered interface.
IF_INDEX TLVにおけるインターフェースIDフィールドは、無数のインターフェースのためのデータチャネルのインタフェースを指定します。
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).
パスとRESVメッセージの両方において、IF_INDEX TLVにおけるインターフェースIDの値は、（ノードがPathメッセージを送信し、Resvメッセージを受信した）上流のノードに関連付けられたデータ・チャネルのローカルインタフェースのIDを指定します。
See Section 6.2 for a description of the use bundled links.
使用バンドルされたリンクの説明については、6.2節を参照してください。
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章を参照してください。
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は、TEノードと確立されている、または確立されているLSPの一部であるTEリンクのデータプレーン識別子を記録します。 TEリンクは、アドレス指定の番号の付いていない使用して識別することができます。
See Section 6 for a description of the use of addresses in the RRO.
RROのアドレスの使用の詳細については、第6章を参照してください。
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.
[RFC3477]に記載されているようにLSP_TUNNEL_INTERFACE_IDオブジェクトは無数フォワード隣接インタフェースIDを指定するために、LSRのルータのID及びインタフェースIDを含みます。 GMPLS対応LSRのルータIDは、TEルータIDに設定されなければなりません。
IP packets can only be addressed to numbered addresses.
IPパケットは、番号のアドレスに対応することができます。
This section examines the use of addresses in RSVP EROs and RROs, the identification of component links, and forwarding addresses for RSVP messages.
このセクションでは、RSVPエロスとRROs、コンポーネントリンクの識別におけるアドレスの使用を調べ、RSVPメッセージのアドレスを転送します。
EROs may contain strict or loose hop subobjects. These are discussed separately below. A separate section describes the use of addresses in the RRO.
エロスは厳しいかゆるいホップのサブオブジェクトが含まれていてもよいです。これらは、以下に別々に議論されています。別のセクションには、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.
受信RSVPメッセージを処理する相互運用性の問題が発生したり、経験される場合がありEROまたはRROのコンテンツに関する制限された仮定を実装。そのため、完全な相互運用性を確保するために必要な実装は、彼らのハードウェア機能に適用されるすべてのEROとRROのオプションを処理するための受信をサポートする必要があります。
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.
句「処理のための領収書は」LSRはEROに先読みまたはLSR自身にまたはEROの次のホップを参照しない任意のサブオブジェクトを処理することが期待されていないことを示すことを意図していることに注意してください。 LSRは、一般的に、自身の情報を追加することにより除き、RROを処理することが期待されていません。
Note also that implementations do not need to support the ERO options containing Component Link IDs if they do not support link bundling [RFC4201].
注また、彼らは[RFC4201]を束ねるリンクをサポートしていない場合の実装はコンポーネントリンクIDを含むEROオプションをサポートする必要はありません。
ERO processing at region boundaries is described in [RFC4206].
領域境界におけるERO処理は[RFC4206]に記載されています。
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].
必要とされる制御のレベルに応じて、EROにおけるサブオブジェクトは、抽象ノード（ノードの、すなわち、グループ）、単純な抽象ノード（すなわち、特定のノード）、またはTEの特定のインタフェースを指定することができるアドレスを含みますデータプレーン内のリンク[RFC3209]。
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.
ホップは（LSPは、任意の介在ノードなしに同定次のホップに直接行かなければならないことを意味する）厳しい、または緩いとしてフラグ付けされてもよいです。
If a hop is strict, the ERO may contain any of the following.
ホップが厳密である場合は、EROは、次のいずれかを含有することができます。
4. Link ID identifying an outgoing TE link, optionally followed by a Component Interface ID and/or one or two Labels.
発信TEリンクを識別する前記リンクIDは、必要に応じてコンポーネント・インタフェースID、および/または1つのまたは2つのラベルが続きます。
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.
発信TEリンクを識別するリンクID、続いて、着信TEリンクを識別する前記リンクIDは、必要に応じてコンポーネント・インタフェースID、および/または1つのまたは2つのラベルが続きます。
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.
発信TEリンクを識別するリンクID、続いて特定のノードを識別する6 TEルータIDは、必要に応じてコンポーネント・インタフェースID、および/または1つのまたは2つのラベルが続きます。
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.
発信TEリンクを識別するリンクID、続いて特定のノードを識別するTEルータID、続いて、着信TEリンクを識別する7リンクIDは、必要に応じてコンポーネント・インタフェースID、および/または1つのまたは2つのラベルが続きます。
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.
2つのノード間の単一の単方向リソースを識別するラベル値は、上流と下流ノードの観点から異なっていてもよいです。ラベル値がポート/繊維を示す番号であるので、これは、典型的には、ファイバスイッチングの場合です。ラベル値がハードウェアでラムダの指標であり、そのようなナノメートルの波長としてグローバルに定義された値ではないかもしれないので、それはまた、ラムダスイッチング用ケースであってもよいです。
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.
任意RSVP-TEオブジェクト内のラベルの値は、オブジェクト/ TLV [RFC3471]の送信者の観点からの値を示しています。したがって、EROの任意のラベルは、リソースの上流ノードの識別を用いて説明します。
There are two differences between Loose and Strict subobjects.
ルースと厳格なサブオブジェクト間の2つの違いがあります。
o A subobject marked as a loose hop in an ERO must not be followed by a subobject indicating a label value [RFC3473].
O EROにルーズホップとしてマークされたサブオブジェクトは、ラベル値[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.
EROにルーズホップとしてマークされたサブオブジェクトoを発信インタフェースの識別子（すなわち、アドレスまたはID）を含んではいけません。
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.
サブオブジェクトは、着信または発信TEリンクを識別するかどうかEROに指定する方法はありません。それが識別された次のホップへのLSPの経路を解決するためにルーズホップに遭遇した場合、経路計算はLSRによって実行されなければなりません。インタフェースはルーズホップとして指定され、着信インターフェイスとして扱われる場合、経路計算は、そのインタフェースを介してLSRに入る経路を選択します。インタフェースは出力インターフェースとして使用されることが意図されている場合、計算されたパスが不十分であってもよく、EROで明示的経路を解決することは不可能であってもよいです。したがってインターフェイスを識別するルーズホップは常に、データプレーン内の着信TEリンクを識別すべきです。
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.
RROはLSPのパスを記録するためのパスとRESVメッセージで使用されています。各LSRは、情報を記録するためにRROにサブオブジェクトを追加します。 LSPセットアップ時に利用できないいくつかの情報があるかもしれないが、ノードによってRROに付加された情報は、PathとResvメッセージに同じであるべきです。
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.
RROの一の使用は、オペレータがLSPの経路を表示できるようにすることです。任意のトランジットノードでは、パスとRESVメッセージからRROを一緒に接合することにより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.
入口LSRで受信されたResvメッセージに全体RROが完全にLSPを再作成するために、後続のPathメッセージにEROとして使用することができることも重要です。
Therefore, when a node adds one or more subobjects to an RRO, any of the following options is valid.
したがって、ノードがRROに一つ以上のサブオブジェクトを追加したときに、次のいずれかのオプションが有効です。
3. Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
発信（下流）TEリンクを識別する前記リンクIDは、必要に応じてコンポーネント・インタフェースID、および/または1つのまたは2つのラベルが続きます。
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.
発信（下流）TEリンクを識別するリンクID、続いて入ってくる（上流）TEリンクを識別する4リンクIDは、必要に応じてコンポーネント・インタフェースID、および/または1つのまたは2つのラベルが続きます。
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.
発信（下流）TEリンクを識別するリンクID続いLSRを識別5 TEルータIDは、必要に応じてコンポーネント・インタフェースID、および/または1つのまたは2つのラベルが続きます。
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.
発信（下流）TEリンクを識別するリンクID、続いLSRを識別TEルータID、続いて入ってくる（上流）TEリンクを識別する前記リンクIDは、必要に応じてコンポーネント・インタフェースID、および/または一つまたは二つ続きますラベル。
An implementation may choose any of these options and must be prepared to receive an RRO that contains any of these options.
実装は、これらのオプションのいずれかを選択することができ、これらのオプションのいずれかが含まれている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ラベル記録がSESSION_ATTRIBUTEオブジェクト内のラベル記録フラグを設定し、[RFC3209]に記載されているようにRROは、Pathメッセージに含まれているなど、入口ノードによって要求されています。それが利用可能な場合はこのような状況下では、LSPに沿った各LSRはPathメッセージにRROのラベル情報を含める必要があります。
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.
[RFC3209]に記載されているように、Resvメッセージの処理は、「パスのミラー」と「唯一の違いは、Resvメッセージ中のRROは逆方向に経路情報を記録することです」。これは、（セクション6.1.1、6.1.2および6.1.3を参照）のホップが逆の順序でRROに添加されるが、各LSRに追加情報が同じ順序であることを意味します。ラベル記録が要求されたときにこのように、ラベルはパスとRESVメッセージの両方にRROsに含まれています。
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.
バンドルリンク[RFC4201]は、データチャネルを提供するために使用される場合、コンポーネントリンク識別子が使用されるバンドル内からのデータチャネルを示すためにIF_ID RSVP_HOPオブジェクトのインタフェース識別TLVに指定されています。インターフェイス識別TLVは、番号コンポーネントリンクの場合には無数のコンポーネントリンクとIPv4 TLV（タイプ1）またはIPv6 TLV（タイプ2）の場合にIF_INDEX TLV（タイプ3）です。
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.
上りデータチャネルのためのコンポーネントリンクは、双方向LSPの場合の下りデータチャネルのためのものとは異なっていてもよいです。この場合、下流インタフェースを指定するインタフェース識別TLVは、上流インタフェースを指定する別のインタフェース識別TLVが続きます。
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.
両方のパス内の上流および下流データチャネルとRESVメッセージのためのTLVに識別子がノードに属する識別子を用いて、上流ノード（ノードは、Pathメッセージを送信し、Resvメッセージを受信する）の観点から指定されることに留意されたいです。
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.
EROを構築するLSRは、バンドルされたリンクを特定するリンクIDを含むことができます。 LSRは、コンポーネントリンクのアイデンティティを知っていて、コントロールを発揮することを希望する場合は、それはまた、ERO内のコンポーネントリンク識別子を含むことができます。それ以外の場合は、コンポーネントリンク識別子が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.
バンドルリンクが使用中である場合、RROは、リンクバンドルを識別するリンクIDを含んでいてもよいです。また、RROは、コンポーネントリンク識別子を含むことができます。
The final destination of the Path message is the Egress node that is specified by the tunnel end point address in the Session object.
Pathメッセージの最終宛先は、セッション・オブジェクト内のトンネルエンドポイントアドレスで指定されEgressノードです。
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].
出口ノードはEROが出力制御用Egressノード[RFC4003]の発信インターフェースIDを含んでいても、下流側に対応するPathメッセージを転送してはなりません。
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.
GMPLSにおいて、制御チャネルは、データチャネルから分離することができ、データチャネルに対する制御チャネルの一対一の関連付けは必ずしも存在しません。データプレーンに隣接している2つのノードが複数のIPは、制御プレーンでそれらの間のホップ有していてもよいです。
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.
ネイティブとトンネル化：分離された制御プレーンの二つの広い種類があります。これらはまた、制御プレーン・アドレスに対して処理わずかに異なるアドレスになるメッセージを、シグナリングのために使用されるカプセル化の性質に主に異なります。
A native control plane uses IP forwarding to deliver RSVP-TE messages between protocol speakers. The message is not further encapsulated.
ネイティブ制御プレーンプロトコルスピーカー間RSVP-TEメッセージを配信するためにIP転送を使用します。メッセージはさらに、封入されていません。
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フォワーディングは、IPヘッダに通常のルールを適用します。 IPホップは、受信RSVP-TEメッセージのTTLをデクリメントしてはならないことに注意してください。
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],
2つの隣接ノードは[RFC3945]のセクション9で述べたように、複数のIPは、その後、制御プレーンでそれらの間のホップ有する場合に、
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.
実装は、それらがLSP階層を使用するか否か[RFC4206]のセクション6.1.1のメカニズムを使用しなければなりません。そのセクションで述べたように「FA-LSP」に適用されるだけでなく、通常のTEリンクが使用される場合の「TEリンク」は、[RFC4206]のセクション6.1.1に留意されたいです。
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.
トンネリング制御プレーンと、RSVP-TEのメッセージは、IPパケットが正確に一つのIPホップを横断するように、トンネル内に挿入されたIPパケットにパッケージングされます。種々のトンネリング技術を含む（これらに限定されない）IPインIP、総称ルーティングカプセル化（GRE）、及びMPLSにおけるIPを使用することができます。
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).
トンネリング機構はTTLを含む場合、そのネットワーク上で送信された任意のネットワークメッセージと同様に扱われるべきです。トンネルインターフェイスでRSVP-TEメッセージを受信した実装は、（IP TTL又はトンネルTTLかどうか）は、任意の他のTTLにRSVP-TE 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.
いくつかの実装は、トンネリングされたコントロールプレーンの機能をサポートしていません、すべての実装は、少なくともネイティブコントロールプレーンをサポートする必要があり、相互運用性を可能にすることが示唆されていることが観察されています。
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.
データトラフィックは、制御プレーンを介して送信されてはなりません。分離された制御及びデータチャネルとPSC（パケット交換可能）GMPLSをしようとしたとき、これは重要です。
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.
このセクションでは、MPLS-TE-STD-MIBモジュール[RFC3812]及び入口及び/又は出口ルータが128を使用して同定されたGMPLS-TE-STD-MIBモジュール[RFC4802]を使用して、LSPトンネルを定義またはモニターする方法を記載していますビットのIPv6アドレス。これはmplsTunnelTable [RFC3812]でmplsTunnelIngressLSRIdとmplsTunnelEgressLSRIdオブジェクトがIPv6バリアント（LSP_TUNNEL_IPv6_SESSIONオブジェクト）が使用されているので、シグナリングセッションオブジェクトからトンネルエンドポイントアドレスと拡張トンネルIDフィールドを運ぶために使用することができない場合です。
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.
制御および監視MPLSとGMPLSノードのMIBオブジェクトのための規範的なテキストは、上記で参照したRFCで見出されます。このセクションでは、これらのオブジェクトを変更しませんが、彼らは必要な機能を提供するために使用することができる方法を説明します。
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).
この機能を使用するため、ネットワーク内のすべてのLSRはLSRを識別するために使用できる32ビットの値をアドバタイズしなければなりません。この文書では、これは、32ビットLSRのIDと呼ばれます。 32ビットLSR IDはOSPFv3のルータID [RFC2740]またはISIS IPv4のTEルータID [RFC3784]です。これらは、TEルータIDは異なっていることに注意してください（セクション2を参照）。
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].
RSVP TEトンネルを設定するとき、RSVP-TEで、それぞれ、拡張トンネルIDとIPv4トンネルエンドポイントアドレスフィールドにMPLS TE MIB mplsTunnelTable [RFC3812]でmplsTunnelIngressLSRIdとmplsTunnelEgressLSRIdフィールドの値をコピーするのが一般的ですLSP_TUNNEL_IPv4セッションオブジェクト[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].
入口および出口ルータがmplsTunnelIngressLSRIdとして128ビットのIPv6アドレスによって識別される場合、このアプローチは使用できず、mplsTunnelEgressLSRIdフィールドは32ビット値[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.
代わりに、IPv6アドレスはトンネルの明示的なルートを定義mplsTunnelHopTableエントリの最初と最後のホップとしてmplsHopTableで構成されるべきです。このように、明示的な経路の構成が明示的ルートがシグナリングされることを意味するものではないことに留意すべきであるが、これは、IPv6ソースアドレスと宛先アドレスとのトンネルを設定明示的ルートを有していなければならないことを意味することに留意されたいです。
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.
以下のようにより詳細には、トンネル入口ルータで構成されています。行動（つまり、「ノーマル」である）MIBテーブルオブジェクトの定義については、デフォルトのために[RFC3812]を参照してください。
The mplsTunnelIndex and mplsTunnelInstance fields are set as normal.
mplsTunnelIndexとmplsTunnelInstanceフィールドは、通常のように設定されています。
The mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields should be set to 32-bit LSR IDs for ingress and egress LSRs, respectively.
mplsTunnelIngressLSRIdとmplsTunnelEgressLSRIdフィールドは、それぞれ、入口と出口LSRsのための32ビットLSR IDに設定されるべきです。
The mplsTunnelHopTableIndex must be set to a non-zero value. That is, an explicit route must be specified.
mplsTunnelHopTableIndexはゼロ以外の値に設定する必要があります。これは、指定する必要があります明示的なルートです。
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.
明示的なルートの最初のホップは、IPv6に設定mplsTunnelHopAddrTypeフィールドを有していなければならない（2）と制御プレーンに到達可能である入口ルータのグローバルスコープのIPv6アドレスに設定mplsTunnelHopIpAddrフィールドを有するべきです。
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.
明示的なルートの最後のホップは、IPv6に設定mplsTunnelHopAddrTypeフィールドを有していなければならない（2）と制御プレーンに到達可能な出口ルータのグローバルスコープのIPv6アドレスに設定mplsTunnelHopIpAddrフィールドを有するべきです。
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.
構成された明示的な経路の最初と最後のホップのmplsTunnelHopIpAddrオブジェクトからRSVP-TE LSP_TUNNEL_IPv6セッションオブジェクト[RFC3209]のそれぞれのトンネルIDとIPv6トンネルエンドポイントアドレスフィールド、、。
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.
8.1節に記載されるようにLSPを設定するためのそれらの使用に加えて、TE MIBモジュール（MPLS-TE-STD-MIBとGMPLS-TE-STD-MIB）は、それぞれ、管理し、MPLSとGMPLS TE LSPを監視するために使用することができます。この関数は、出力とトランジットのLSRで特に重要です。
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]).
次のようにIPv6ソースアドレスと宛先アドレスとのトンネルのため、LSRの実装は、（「通常の」行動は[RFC3812]から取られたデフォルトである）mplsTunnelTableの値を返さなければなりません。
The mplsTunnelIndex and mplsTunnelInstance fields are set as normal.
mplsTunnelIndexとmplsTunnelInstanceフィールドは、通常のように設定されています。
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.
mplsTunnelIngressLSRIdフィールドとmplsTunnelEgressLSRIdは、32ビットLSR IDに設定されています。すなわち、入口LSRの32ビットLSR IDに拡張トンネルIDフィールドにIPv6アドレスから各トランジットと出口ルータマップです。各中継ルータはまた、出口LSRの32ビットLSRのIDへのIPv6トンネルエンドポイントアドレスフィールドにIPv6アドレスからマッピングします。
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.
私たちが行った相互運用性テストでは、私たちが見られる主要な問題は、転送データのための制御チャネルを使用しました。これは、PSC（パケット交換可能な）装置において同じ値に制御及びデータの両方プレーン・アドレスの設定によるものでした。分離された制御およびデータチャネルとPSC GMPLSをテストしようとしたときにこれが発生しました。代わりになった何同じアドレスを持つパラレルインタフェースました。これは、単純に別々の制御とデータプレーンのアドレスを保つことによって避けることができます。
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.
あぁん だゔぇｙ、 ゆみこ かわしま、 かおり しみず、 てょまｓ Ｄ。 なであう、 あしょｋ ならやなん、 えいじ おき、 Ｌｙんどん おんｇ、 ゔぃじゃｙ ぱんぢあん、 はり らことらんと、 あんｄ あｄりあん ふぁっれｌ。
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.
著者は、有益な議論と彼は書類に与えたフィードバックのためのエードリアンファレルに感謝したいと思います。また、ヤリArkko、Arthi Ayyangar、デボラBrungard、ディエゴ・Caviglia、リサDusseault、ディミトリPapadimitriou、ジョナサン・サドラー、英嗣杉山、そしてジュリアンMeuricは有益なコメントや提案を提供しました。
Adrian Farrel edited the final revisions of this document before and after working group last call.
エードリアンファレルは、前のグループの最後の呼び出しを働いた後、この文書の最後のリビジョンを編集しました。
[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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K.とY. Rekhter、 "資源予約プロトコルでアンナンバードリンクシグナリング - トラフィックエンジニアリング（RSVP-TE）"、RFC 3477、2003年1月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、2003年9月。
[RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.
[RFC3811]ナドー、T.、エド。、およびJ. Cucchiara、エド。、 "マルチプロトコルラベルのためのテキストの表記法（TCS）の定義は、スイッチング（MPLS）管理"、RFC 3811、2004年6月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]スリニバサン、C.、Viswanathanの、A.、およびT.ナドー、 "マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）"、RFC 3812、2004年6月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ"、RFC 3945、2004年10月。
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
"出力制御のためのGMPLSシグナリング手順" [RFC4003]バーガー、L.、RFC 4003、2005年2月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（TE）"、RFC 4201、2005年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、エド。、およびY. Rekhter、エド。、 "ルーティング拡張一般マルチプロトコルラベルスイッチング（GMPLS）のサポートで"、RFC 4202、2005年10月。
[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.、エド。、およびY. Rekhter、エド。、 "一般化されたマルチプロトコルラベルスイッチングのサポートでOSPF拡張機能"、RFC 4203、2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", RFC 4206, October 2005.
[RFC4206] Kompella、K.、およびY. Rekhter、 "一般化されたMPLS TE LSPと階層"、RFC 4206、2005年10月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740] Coltun、R.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、RFC 2740、1999年12月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング（TE）のための中間システム（IS-IS）への拡張"、RFC 3784、2004年6月。
[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.、エド。、およびY. Rekhter、エド。、 "中間システム（GMPLS）をスイッチング汎用マルチプロトコルラベルの支援における中間システム（IS-IS）への拡張"、RFC 4205、2005年10月。
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
[RFC4802]ナドー、T.、エド。、およびA.ファレル、エド。、 "一般化マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング管理情報ベース"、RFC 4802、2007年2月。
Authors' Addresses
著者のアドレス
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
電話：+81 422 59 4402 Eメール：shiomoto.kohei@lab.ntt.co.jp
Richard Rabbat Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043
リチャードRabbatグーグル株式会社1600アンフィシアターパークウェイマウンテンビュー、CA 94043
Phone: +1 650-714-7618 EMail: rabbat@alum.mit.edu
電話：+1 650-714-7618電子メール：rabbat@alum.mit.edu
Rajiv Papneja Isocore Corporation 12359 Sunrise Valley Drive, Suite 100 Reston, Virginia 20191 United States of America
ラジブPapneja Isocore株式会社12359日の出バレードライブ、アメリカのスイート100レストン、バージニア州20191米国
Phone: +1 703-860-9273 EMail: rpapneja@isocore.com
電話：+1 703-860-9273電子メール：rpapneja@isocore.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。