[要約] RFC 4990は、GMPLSネットワークでのアドレスの使用に関するガイドラインです。その目的は、GMPLSネットワークにおけるアドレスの適切な使用方法を提供することです。
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
一般化されたマルチプロトコルラベルスイッチング（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.
このドキュメントは、一般化されたマルチプロトコルラベルスイッチング（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プロトコル内のアドレスと識別子フィールドを解釈する方法（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.
このドキュメントでは、新しい手順やプロセスを定義しておらず、上記のプロトコル仕様は決定的なものとして扱う必要があります。さらに、このドキュメントが要件ステートメントまたは推奨事項を作成する場合、これらは参照された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).
データプレーンスイッチまたはルーターは、データプレーンエンティティと呼ばれます。これは、データプレーントポロジグラフのノードです。データプレーンリソースは、データプレーンエンティティ（ノード）、データリンク（エッジ）、またはデータラベル（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内の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 ループバックアドレス：ループバックアドレスは、広告ルーターの安定したIPアドレスであり、IP接続がある場合は常に到達可能です[RFC3477]、[RFC3630]。したがって、たとえば、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]は、Router IDをOSPFを実行している各ルーターに割り当てられた32ビットネットワークユニーク番号であると定義しています。IS-IS [RFC1195]には、システムIDに同様の概念が含まれています。このドキュメントは、ルーティングプロトコルを実行しているルーターの「ルーターID」として両方の概念を説明しています。ルーター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リンク：「TEリンクは、IS-IS/OSPFリンク状態広告と、2つのGMPLSノード間の特定の物理リソースとそのプロパティのリンク状態データベースの表現です」[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.
o IP Time to Live（TTL）：IPv4 TTLフィールドまたはIPv6ホップリミットフィールドのいずれか該当する場合。
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.
o IGP：インテリアゲートウェイプロトコル。
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].
このセクションでは、GMPLSに対して定義されている2つのインテリアゲートウェイプロトコル（IGPS）を使用して、OSPF-TEとIS-IS-TEの2つのインテリアゲートウェイプロトコル（IGPS）を使用して、番号付きのアドレス指定について説明します。GMPLのルーティング強化は、[RFC3630]、[RFC3784]、[RFC4202]、[RFC4203]、および[RFC4205]で定義されています。
The IGPs define a field called the "Router Address". It is used to advertise the TE Router ID.
IGPSは、「ルーターアドレス」と呼ばれるフィールドを定義します。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 sub-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]では、拡張されたISリーチビリティ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]
o
o the IPv4 Interface Address sub-TLV in IS-IS-TE [RFC3784].
o IS-IS-TE [RFC3784]のIPv4インターフェイスアドレスSUB-TLV。
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 OSPF-TE [RFC3630]のリモートインターフェイスIPアドレスSUB-TLV
o the IPv4 Neighbor Address sub-TLV in IS-IS-TE [RFC3784].
o IS-IS-TE [RFC3784]のIPv4ネイバーアドレスSUB-TLV。
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）に関連するすべてのメッセージに対して不変です。パスメッセージのイニシエーターは、セッションオブジェクトのIPトンネルエンドポイントアドレスを次のいずれかに設定します。
o The TE Router ID of the egress since the TE Router ID is routable and uniquely identifies the egress node.
o TEルーターIDがルーティング可能であり、出力ノードを一意に識別できるため、出口のTEルーター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リンクのリモートインターフェイス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.
送信者テンプレートオブジェクト[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.
IPv4番号FAをサポートするためにLSPがセットアップされている場合、[RFC4206]は、テールエンドアドレスができるように作成されるTEリンクのヘッドエンドアドレスにIPトンネル送信者アドレスを設定することを推奨します。/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:
FAを形成するために使用されないLSPがセットアップされている場合、送信者テンプレートオブジェクトのIPトンネル送信者アドレスは次のいずれかに設定できます。
o The TE Router ID of the ingress LSR since the TE Router ID is a unique, routable ID per node.
o TEルーターIDはノードごとに一意のルーティング可能なIDであるため、Ingress LSRのTEルーターID。
o The sender data plane address (i.e., the Local Interface IP Address).
o 送信者データプレーンアドレス（つまり、ローカルインターフェイスIPアドレス）。
There are two addresses used in the IF_ID RSVP_HOP object.
if_id rsvp_hopオブジェクトには2つのアドレスが使用されています。
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.
パスまたはRESVメッセージで使用する場合、このアドレスは、メッセージの送信に使用されるコントロールプレーンインターフェイスのIPリーチ可能なアドレス、またはメッセージを送信するノードのTEルーターIDを指定します。つまり、メッセージの送信者のルーティング可能なコントロールプレーンアドレスであり、返信メッセージを送信するために使用できます。データプレーン /コントロールプレーンの分離（セクション7.1を参照）とコントロールプレーンの断層に直面したデータプレーンの堅牢性があるため、より安定したアドレスであるため、TEルーターIDを使用することをお勧めします。
2. The IPv4/IPv6 address in the Value Field of the Interface_ID TLV [RFC3471]
2. interface_id tlv [rfc3471]の値フィールドの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.
このアドレスは、信号メッセージに関連付けられたデータチャネルを識別します。すべての場合において、データチャネルは、上流の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アドレスは、抽象ノード、TEノード、またはTEリンクのデータプレーン識別子を提供し、信号されたLSPの一部になります。
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アドレスは、確立された、または確立されているLSPの一部であるTEノードまたは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メッセージを送信するノードの到達可能な制御プレーンアドレスでなければなりません。コントロールプレーンの堅牢性を提供するために、安定したIPv4またはIPv6コントロールプレーンアドレス（たとえば、TEルーター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アドレスとしてパスメッセージを含む受信したIPパケットのIPソースアドレスを使用する場合があります（セクション4.2.7を参照）。パスメッセージを含む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.
パスメッセージの場合、次のホップノードの安定したIPv4またはIPv6アドレスを使用できます。これは、Next-HopノードのTEルーターIDかもしれません。適切なアドレスは、Next-Hopデータリンクを形成する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.
o パスメッセージを含む受信した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]の次/前のホップアドレスフィールドの受信値の値。
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].
コントロールプレーンの到達可能なアドレスであるTEルーターIDとノードユニークインターフェイスID [RFC3477]の組み合わせによって、番号のないリンクが識別されます。
In this section, we consider unnumbered address advertisement using OSPF-TE and IS-IS-TE.
このセクションでは、OSPF-TEおよびIS-ISTEを使用して、NONMUMBERED ADDRESS ADVERTISEMENTを検討します。
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を宣伝しています。リンクローカル/リモート識別子は、広告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つの要素で構成されています。
- A TE Router ID that is associated with the link local end
- 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].
Link LocalおよびLinkリモート識別子は、拡張された拡張性の単一サブTLVを使用してIS-ISで運ばれます。リンク識別子は、「ポイントツーポイント3ウェイ隣接」の拡張ローカル回路IDフィールドで交換されます。IS-ISオプションタイプ[RFC4205]。
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.
このセクションでは、Noumberedアドレス指定の場合、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).
PATHメッセージとRESVメッセージの両方で、IF_INDEX TLVのインターフェイスIDの値は、アップストリームノードの関連データチャネルのローカルインターフェイスIDを指定します（ノードはパスメッセージを送信してRESVメッセージを受信します）。
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は、TEリンクの数のない識別子を使用して、シグナル付きLSPの一部となる場合があります。
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は、確立されている、または確立されている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.
LSP_TUNNEL_INTERFACE_IDオブジェクトには、[RFC3477]で説明されているように、LSRのルーターIDとインターフェイス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 EROSおよび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には次のいずれかが含まれている場合があります。
1. Address prefix or AS number specifying a group of nodes.
1. アドレスプレフィックスまたはノードのグループを指定する番号として。
2. TE Router ID identifying a specific node.
2. 特定のノードを識別するTEルーターID。
3. Link ID identifying an incoming TE link.
3. リンクID着信TEリンクを識別します。
4. Link ID identifying an outgoing TE link, optionally followed by a Component Interface ID and/or one or two Labels.
4. リンクID発信TEリンクを識別し、オプションでコンポーネントインターフェイス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.
5. リンクID着信TEリンクを識別し、その後に発信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.
6. TEルーターID特定のノードを識別し、その後、発信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.
7. リンクID着信TEリンクを識別し、次に特定のノードを識別するTEルーターIDが続き、次に発信TEリンクを識別するリンク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つのノード間で単一の単方向リソースを識別するラベル値は、上流および下流ノードの観点とは異なる場合があります。これは通常、ラベル値がポート/ファイバーを示す数値であるため、ファイバースイッチングの場合です。ラベル値はハードウェア内のラムダのインデックスであり、ナノメートルの波長などのグローバルに定義された値ではないため、Lambdaスイッチングの場合もあります。
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.
o EROのルーズホップとしてマークされたサブオブジェクトには、発信インターフェイスの識別子（つまり、アドレスまたは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によってパス計算を実行する必要があります。インターフェイスがルーズホップとして指定され、着信インターフェイスとして扱われる場合、パス計算はそのインターフェイスを介してLSRに入るパスを選択します。インターフェイスを発信インターフェイスとして使用することを目的としている場合、計算されたパスは不十分であり、EROの明示的なルートを解決することは不可能かもしれません。したがって、インターフェイスを識別するルーズホップは、常にデータプレーンの着信リンクを識別する必要があります。
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のパスを記録するためにPATHおよびRESVメッセージで使用されます。各LSRは、rroにサブオブジェクトを追加して情報を記録します。ノードによってRROに追加された情報は、LSPセットアップ中に使用できない情報がある場合がありますが、パスと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の1つの使用は、オペレーターが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.
また、Ingress LSRで受信したRESVメッセージのRRO全体を、後続のパスメッセージのEROとして使用して、LSPを完全に再現できることも重要です。
Therefore, when a node adds one or more subobjects to an RRO, any of the following options is valid.
したがって、ノードが1つ以上のサブオブジェクトをRROに追加すると、次のオプションのいずれかが有効です。
1. TE Router ID identifying the LSR.
1. LSRを識別するTEルーターID。
2. Link ID identifying the incoming (upstream) TE link.
2. リンクID着信（上流）TEリンクを識別します。
3. Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
3. リンクID発信（下流）TEリンクを識別し、オプションでコンポーネントインターフェイス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.
4. リンクID着信（上流）TEリンクを識別し、その後に発信（下流）TEリンクを識別するリンク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.
5. TEルーターID LSRを識別し、その後、発信（下流）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.
6. リンクID着信（上流）TEリンクを識別し、次にLSRを識別するTEルーターIDが続き、その後、発信（下流）TEリンクを識別するリンクIDが続き、オプションでコンポーネントインターフェイスIDおよび/または1つまたは2つのラベルが続きます。
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オブジェクトのラベル記録フラグを設定するイングレスノードによって要求され、rroを含む[RFC3209]で説明されているパスメッセージに含まれます。これらの状況下では、LSPに沿った各LSRには、使用可能な場合、パスメッセージの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がパス情報を逆方向に記録することです。」これは、ホップが逆順序でRROに追加されることを意味しますが、各LSRに追加された情報は同じ順序であることを意味します（セクション6.1.1、6.1.2、および6.1.3を参照）。したがって、ラベルの録音が要求されると、パスメッセージと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の識別子は、ノードに属する識別子を使用して、上流ノード（ノードがパスメッセージを送信して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.
パスメッセージの最後の宛先は、セッションオブジェクトのトンネルエンドポイントアドレスによって指定された出口ノードです。
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にEROがEgress Control [RFC4003]の出力ノードの送信インターフェイスIDが含まれていても、Egressノードは、対応するパスメッセージを下流に転送してはなりません。
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では、コントロールチャネルをデータチャネルから分離でき、必ずしもコントロールチャネルとデータチャネルとの1対1の関連性がありません。データプレーンに隣接する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.
分離された対照面には、ネイティブとトンネルの2つのタイプがあります。これらは主に、シグナリングメッセージに使用されるカプセル化の性質が異なります。これは、コントロールプレーンのアドレスに関してもわずかに異なるアドレス処理をもたらします。
A native control plane uses IP forwarding to deliver RSVP-TE messages between protocol speakers. The message is not further encapsulated.
ネイティブコントロールプレーンは、IP転送を使用して、プロトコルスピーカー間でRSVP-TEメッセージを配信します。メッセージはさらにカプセル化されていません。
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], 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.
2つの隣接するノードがコントロールプレーンにそれらの間に複数のIPホップがある場合、[RFC3945]のセクション9に記載されているように、実装は[RFC4206]のセクション6.1.1のメカニズムを使用する必要があります。。[RFC4206]のセクション6.1.1は、そのセクションに記載されている「FA-LSP」に適用されるだけでなく、通常のTEリンクが使用される場合の「TEリンク」にも適用されることに注意してください。
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パケットが正確に1つのIPホップを通過するようにトンネルに挿入されたIPパケットにパッケージ化されています。IP-in-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メッセージを受信する実装は、RSVP-TE TTLを他のTTL（IP TTLまたはトンネル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（パケットスイッチング対応）GMPLを分離したコントロールとデータチャネルを備えたGMPLを試みる場合に重要です。
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-TETD-MIBモジュール[RFC3812]およびGMPLS-TETD-MIBモジュール[RFC4802]を使用してLSPトンネルを定義または監視する方法について説明します。ビットIPv6アドレス。これは、MPLSTUNNELTABLE [RFC3812]内のMpLStunningressridlsridおよびmplstunnelegresslsridオブジェクトを使用して、IPv6バリアント（LSP_TUNNEN_IPV6_SESTIONオブジェクト）が使用されるため、シグナル付きセッションオブジェクトからトンネルエンドポイントアドレスと拡張トンネル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トンネルをセットアップするとき、MPLSTUNNELINGRESSLSRIDおよびMPLSTUNNELEGRESSLSRIDフィールドの値をMPLS MPLSTUNNELTABLE [RFC3812]のコピーして、それぞれRSVP-TEで、それぞれ拡張トンネルIDおよびIPv4トンネルエンドポイントアドレスフィールドにコピーすることが一般的です。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].
このアプローチは、128ビットIPv6アドレスによって侵入および出口ルーターがmplstunnelingresslsridとして識別され、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.
さらに詳しくは、トンネルは次のようにイングレスルーターで構成されています。[RFC3812]を参照してください。MIBテーブルオブジェクトの定義、およびデフォルト（つまり「通常」）動作については。
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フィールドは、それぞれイングレスおよび出力LSRのために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.
明示的なルートの最初のホップには、mplstunnelhopaddrtypeフィールドがIPv6（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.
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.
トンネルIDおよびIPv6トンネルエンドポイントアドレスフィールドは、それぞれ、構成された明示的ルートの最初と最後のホップのMPLSTUNNELHOPIPADDRオブジェクトからのRSVP-TE LSP_TUNNEL_IPV6セッションオブジェクト[RFC3209]のフィールドです。
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-TESTD-MIBおよびGMPLS-TESTD-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の実装は、次のようにmplstunneltableの値を返す必要があります（「通常」の動作は[RFC3812]から取られたデフォルトです）。
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に設定されています。つまり、拡張トンネルIDフィールドのIPv6アドレスから、イングレスLSRの32ビットLSR IDまでの各トランジットおよび出口ルーターマップ。各トランジットルーターは、IPv6トンネルエンドポイントアドレスのIPv6アドレスから、出力LSRの32ビットLSR IDへのマップもマッピングします。
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.
アラン・デイビー、川島大島、清水川川、トーマス・D・ナドー、アショク・ナラヤナン、エイジ・オキ、リンドン・オング、ヴィジェイ・パンディアン、ハリ・ラコトラント、エイドリアン・ファレル。
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.
著者は、有益な議論と彼が文書に与えたフィードバックについて、エイドリアン・ファレルに感謝したいと思います。さらに、Jari Arkko、Arthi Ayyangar、Deborah Brungard、Diego Caviglia、Lisa Dusseault、Dimitri Papadimitriou、Jonathan Sadler、Hidetsugu Sugiyama、およびJulien Meuricは有益なコメントと提案を提供しました。
Adrian Farrel edited the final revisions of this document before and after working group last call.
Adrian Farrelは、ワーキンググループの最後のコールの前後にこのドキュメントの最終改訂を編集しました。
[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.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（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] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（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] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to 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] Nadeau、T.、ed。、およびJ. Cucchiara、ed。、「マルチプロトコルラベルスイッチング（MPLS）管理のテキストコンベンション（TCS）の定義」、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] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）、RFC 3812、2004年6月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
[RFC4003] Berger、L。、「GMPLS Signaling Procedure for Eugress Control」、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. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-protocol Label Switching", RFC 4203, October 2005.
[RFC4203] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチングをサポートする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。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740] Coltun、R.、Ferguson、D。、およびJ. Moy、「OSPF for IPv6」、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] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、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.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（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] Nadeau、T.、ed。、およびA. Farrel、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング管理情報ベース」、RFC 4802、2007年2月。
Authors' Addresses
著者のアドレス
Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori Musashino, Tokyo 180-8585 Japan
小屋志子NTTネットワークサービスシステム研究所3-9-11 Midori Musashino、Tokyo 180-8585 Japan
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 Amphitheater Parkway Mountain View、CA 94043
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、バージニア20191アメリカ合衆国アメリカ
Phone: +1 703-860-9273
EMail: rpapneja@isocore.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。