[要約] 要約： RFC 4208は、GMPLSユーザーネットワークインターフェース（UNI）におけるオーバーレイモデルのサポートに関するRSVP-TEの使用方法を定義しています。目的： このRFCの目的は、GMPLSユーザーネットワークインターフェース（UNI）において、オーバーレイモデルをサポートするためのRSVP-TEの使用方法を提供することです。
Network Working Group G. Swallow
Request for Comments: 4208 Cisco Systems, Inc
Category: Standards Track J. Drake
Boeing
H. Ishimatsu
G1M Co., Ltd.
Y. Rekhter
Juniper Networks, Inc
October 2005
Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model
一般化されたマルチプロトコルラベルスイッチング（GMPLS）ユーザーネットワークインターフェイス（UNI）：オーバーレイモデルのリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）サポート
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model.
一般化されたマルチプロトコルラベルスイッチング（GMPLS）は、さまざまなスイッチングテクノロジーでラベルスイッチパス（LSP）を作成するためのルーティングプロトコルとシグナリングプロトコルの両方を定義します。これらのプロトコルは、多くの展開シナリオをサポートするために使用できます。このメモは、GMPLのオーバーレイモデルへの適用に対応しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. GMPLS User-Network Interface (GMPLS UNI) ...................4
2. Addressing ......................................................5
3. ERO Processing ..................................................6
3.1. Path Message without ERO ...................................6
3.2. Path Message with ERO ......................................6
3.3. Explicit Label Control .....................................7
4. RRO Processing ..................................................7
5. Notification ....................................................7
6. Connection Deletion .............................................8
6.1. Alarm-Free Connection Deletion .............................8
6.2. Connection Deletion with PathErr ...........................8
7. VPN Connections .................................................9
8. Security Considerations ........................................10
9. Acknowledgments ................................................10
10. References ....................................................10
10.1. Normative References .....................................10
10.2. Informational References .................................10
Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various transport technologies. These protocols can be used to support a number of deployment scenarios. In a peer model, edge-nodes support both a routing and a signaling protocol. The protocol interactions between an edge-node and a core-node are the same as between two core-nodes. In the overlay model, the core-nodes act more as a closed system. The edge-nodes do not participate in the routing protocol instance that runs among the core nodes; in particular, the edge-nodes are unaware of the topology of the core-nodes. There may, however, be a routing protocol interaction between a core-node and an edge-node for the exchange of reachability information to other edge-nodes.
一般化されたマルチプロトコルラベルスイッチング（GMPLS）は、さまざまな輸送技術におけるラベルスイッチパス（LSP）を作成するためのルーティングプロトコルとシグナリングプロトコルの両方を定義します。これらのプロトコルは、多くの展開シナリオをサポートするために使用できます。ピアモデルでは、エッジノードはルーティングとシグナリングプロトコルの両方をサポートしています。エッジノードとコアノード間のプロトコルの相互作用は、2つのコアノード間と同じです。オーバーレイモデルでは、コアノードは閉じたシステムとして機能します。エッジノードは、コアノード間で実行されるルーティングプロトコルインスタンスに参加しません。特に、エッジノードは、コアノードのトポロジーに気付いていません。ただし、他のエッジノードと到達可能な情報を交換するためのコアノードとエッジノードの間のルーティングプロトコル相互作用がある場合があります。
Overlay Overlay
Network +----------------------------------+ Network
+---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | |
| -+ EN +-+-----+--+ CN +----+ CN +----+ CN +---+-----+-+ EN +- |
| | | | +--+--| | | | | | | | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ |
| | | | | | | | | |
+---------+ | | | | | | +---------+
| | | | | |
+---------+ | | | | | | +---------+
| | | | +--+--+ | +--+--+ | | |
| +----+ | | | | | +-------+ | | | +----+ |
| | +-+--+ | | CN +---------------+ CN | | | | | |
| -+ EN +-+-----+--+ | | +---+-----+-+ EN +- |
| | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ |
| | +----------------------------------+ | |
+---------+ Core Network +---------+
Overlay Overlay
Network Network
Legend: EN - Edge Node CN - Core Node
凡例：en-エッジノードCN-コアノード
Figure 1: Overlay Reference Model
図1：オーバーレイ参照モデル
Figure 1 shows a reference network. The core network is represented by the large box in the center. It contains five core-nodes marked 'CN'. The four boxes around the edge marked "Overlay Network" represent four islands of a single overlay network. Only the nodes of this network with TE links into the core network are shown. These nodes are called edge-nodes; the terminology is in respect to the core network, not the overlay network. Note that each box marked "Overlay Network" could contain many other nodes. Such nodes are not shown; they do not participate directly in the signaling described in this document. Only the edge-nodes can signal to set up links across the core to other edge-nodes.
図1は、参照ネットワークを示しています。コアネットワークは、中央の大きなボックスで表されます。「CN」とマークされた5つのコアノードが含まれています。「オーバーレイネットワーク」とマークされた端の周りの4つのボックスは、単一のオーバーレイネットワークの4つの島を表しています。コアネットワークへのTEリンクを持つこのネットワークのノードのみが表示されます。これらのノードはエッジノードと呼ばれます。用語は、オーバーレイネットワークではなく、コアネットワークに関するものです。「オーバーレイネットワーク」とマークされた各ボックスには、他の多くのノードが含まれている可能性があることに注意してください。このようなノードは表示されません。彼らは、このドキュメントに記載されているシグナル伝達に直接参加しません。エッジノードのみが、コアを横切って他のエッジノードにリンクを設定するように信号を送ることができます。
How a link between edge-nodes is requested and triggered is out of the scope of this document, as is precisely how that link is used by the Overlay Network. One possibility is that the edge-nodes will inform the other nodes of the overlay network of the existence of the link, possibly using a forwarding adjacency as described in [MPLS-HIER]. Note that this contrasts with a forwarding adjacency that is provided by the core network as a link between core-nodes.
エッジノード間のリンクが要求され、トリガーされる方法は、そのリンクがオーバーレイネットワークで使用する方法とまったく同じように、このドキュメントの範囲外です。1つの可能性は、エッジノードがリンクの存在のオーバーレイネットワークの他のノードに通知し、おそらく[MPLS-Hier]で説明されている転送隣接を使用していることです。これは、コアノード間のリンクとしてコアネットワークによって提供される転送隣接とは対照的であることに注意してください。
In the overlay model, there may be restrictions on what may be signaled between an edge-node and a core-node. This memo addresses the application of GMPLS to the overlay model. Specifically, it addresses RSVP-TE procedures between an edge-node and a core-node in the overlay model. All signaling procedures are identical to the GMPLS extensions specified in [RFC3473], except as noted in this document.
オーバーレイモデルでは、エッジノードとコアノードの間で何が信号を送られるかについて制限がある場合があります。このメモは、GMPLのオーバーレイモデルへの適用に対応しています。具体的には、オーバーレイモデルのエッジノードとコアノードの間のRSVP-TE手順に対処します。すべてのシグナリング手順は、[RFC3473]で指定されたGMPLS拡張機能と同一ですが、このドキュメントに記載されている場合を除きます。
This document primarily addresses interactions between an edge-node and it's adjacent (at the data plane) core-node; out-of-band and non-adjacent signaling capabilities may mean that signaling messages are delivered on a longer path. Except where noted, the term core-node refers to the node immediately adjacent to an edge-node across a particular data plane interface. The term core-nodes, however, refers to all nodes in the core.
このドキュメントでは、主にエッジノードとITが隣接する（データプレーン）コアノード間の相互作用に対応しています。帯域外および非隣接するシグナリング機能は、より長いパスでシグナリングメッセージが配信されることを意味する場合があります。記載されている場合を除いて、コアノードという用語は、特定のデータプレーンインターフェイス全体のエッジノードに隣接するノードを指します。ただし、コアノードという用語は、コア内のすべてのノードを指します。
Realization of a single or multiple instance of the UNI is implementation dependent at both the CN and EN so long as it meets the functional requirements for robustness, security, and privacy detailed in Section 7.
UNIの単一または複数のインスタンスの実現は、CNとENの両方に実装に依存しており、セクション7に詳述されている堅牢性、セキュリティ、プライバシーの機能要件を満たしています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Readers are assumed to be familiar with the terminology introduced in [RFC3031], [GMPLS-ARCH], and [RFC3471].
読者は、[RFC3031]、[GMPLS-ARCH]、および[RFC3471]で導入された用語に精通していると想定されています。
One can apply the GMPLS Overlay model at the User-Network Interface (UNI) reference point defined in the Automatically Switched Optical Network (ASON) [G.8080]. Consider the case where the 'Core Network' in Figure 1 is a Service Provider network, and the Edge Nodes are 'user' devices. The interface between an EN and a CN is the UNI reference point, and to support the ASON model, one must define signaling across the UNI.
自動化された光ネットワーク（ASON）[G.8080]で定義されたユーザーネットワークインターフェイス（UNI）参照ポイントにGMPLSオーバーレイモデルを適用できます。図1の「コアネットワーク」がサービスプロバイダーネットワークであり、エッジノードが「ユーザー」デバイスである場合を考えてください。ENとCNの間のインターフェイスはUNI参照ポイントであり、ASONモデルをサポートするには、UNI全体のシグナリングを定義する必要があります。
The extensions described in this memo provide mechanisms for UNI signaling that are compatible with GMPLS signaling [RFC3471, RFC3473]. Moreover, these mechanisms for UNI signaling are in line with the RSVP model; namely, there is a single end-to-end RSVP session for the user connection. The first and last hops constitute the UNI, and the RSVP session carries the user parameters end-to-end. This obviates the need to map (or carry) user parameters to (in) the format expected by the network-to-network interface (NNI) used within the Service Provider network. This in turn means that the UNI and NNI can be independent of one another, which is a requirement of the ASON architecture. However, in the case that the UNI and NNI are both GMPLS RSVP-based, the methodology specified in this memo allows for a single RSVP session to instantiate both UNI and NNI signaling, if so desired, and if allowed by Service Provider policy.
このメモで説明されている拡張機能は、GMPLSシグナル伝達[RFC3471、RFC3473]と互換性のあるUNIシグナル伝達のメカニズムを提供します。さらに、UNIシグナル伝達のためのこれらのメカニズムは、RSVPモデルと一致しています。すなわち、ユーザー接続には単一のエンドツーエンドのRSVPセッションがあります。最初と最後のホップはUNIを構成し、RSVPセッションにはユーザーパラメーターがエンドツーエンドです。これにより、サービスプロバイダーネットワーク内で使用されているネットワークからネットワークへのインターフェイス（NNI）が予想される形式に（または携帯）する必要があります。これは、UNIとNNIが互いに独立している可能性があることを意味します。これはASONアーキテクチャの要件です。ただし、UNIとNNIはどちらもGMPLS RSVPベースである場合、このメモで指定された方法論により、単一のRSVPセッションでUNIとNNIの両方のシグナリングを希望する場合、およびサービスプロバイダーポリシーで許可されている場合があります。
Addresses for edge-nodes in the overlay model are drawn from the same address space as the edge-nodes use to address their adjacent core-nodes. This may be the same address space as used by the core-nodes to communicate among themselves, or it may be a VPN space supported by the core-nodes as an overlay.
オーバーレイモデルのエッジノードのアドレスは、エッジノードが隣接するコアノードに対処するために使用するのと同じアドレス空間から描画されます。これは、コアノードが使用するために使用するのと同じアドレス空間である場合があります。または、コアノードがオーバーレイとしてサポートするVPNスペースである場合があります。
To be more specific, an edge-node and its attached core-node must share the same address space that is used by GMPLS to signal between the edge-nodes across the core network. A set of <edge-node, core-node> tuples share the same address space if the edge-nodes in the set could establish LSPs (through the core-nodes) among themselves without address mapping or translation (note that edge-nodes in the set may be a subset of all the edge-nodes). The address space used by the core-nodes to communicate among themselves may, but need not, be shared with the address space used by any of the <edge-node, core-node> tuples. This does not imply a mandatory 1:1 mapping between a set of LSPs and a given addressing space.
より具体的には、エッジノードとその添付のコアノードは、コアネットワーク全体のエッジノード間でシグナルを合わせてGMPLSが使用する同じアドレス空間を共有する必要があります。<edge-node、core-node> tupplesのセットは、セット内のエッジノードがアドレスマッピングや翻訳なしでLSP（コアノードを介して）を確立できる場合、同じアドレス空間を共有します（エッジノードが入力することに注意してくださいセットは、すべてのエッジノードのサブセットである場合があります）。コアノードが自分自身の間で通信するために使用するアドレススペースは、<edge-node、core-node> tupplesのいずれかで使用されるアドレススペースと共有される場合がありますが、必要ではありません。これは、LSPのセットと特定のアドレス指定スペースの間の必須の1：1マッピングを意味するものではありません。
When multiple overlay networks are supported by a single core network, one or more address spaces may be used according to privacy requirements. This may be achieved without varying the core-node addresses since it is the <edge-node, core-node> tuple that constitutes address space membership.
複数のオーバーレイネットワークが単一のコアネットワークによってサポートされている場合、プライバシー要件に応じて1つ以上のアドレススペースを使用できます。これは、アドレススペースメンバーシップを構成するのは<edge-node、core-node> tupleであるため、コアノードアドレスを変更せずに達成できます。
An edge-node is identified by either a single IP address representing its Node-ID, or by one or more numbered TE links that connect the edge-node to the core-nodes. Core-nodes are assumed to be ignorant of any other addresses associated with an edge-node (i.e., addresses that are not used in signaling connections through the GMPLS core).
エッジノードは、ノードIDを表す単一のIPアドレス、またはエッジノードをコアノードに接続する1つ以上の数字のTEリンクのいずれかによって識別されます。コアノードは、エッジノードに関連付けられた他のアドレス（つまり、GMPLSコアを介したシグナリング接続で使用されないアドレス）に無知であると想定されています。
An edge-node need only know its own address, an address of the adjacent core-node, and know (or be able to resolve) the address of any other edge-node to which it wishes to connect, as well as (of course) the addresses used in the overlay network island of which it is a part.
エッジノードは、独自のアドレス、隣接するコアノードのアドレスを知る必要があり、接続したい他のエッジノードのアドレスと（もちろん）アドレスを知る（または解決できる）必要があります（もちろん）それが一部であるオーバーレイネットワーク島で使用されるアドレス。
A core-node need only know (and track) the addresses on interfaces between that core-node and its attached edge-nodes, as well as the Node IDs of those edge-nodes. In addition, a core-node needs to know the interface addresses and Node IDs of other edge-nodes to which an attached edge-node is permitted to connect.
コアノードは、そのコアノードと添付のエッジノードとの間のインターフェイス上のアドレスと、それらのエッジノードのノードIDのみを知る（および追跡）する必要があります。さらに、コアノードは、添付のエッジノードが接続できる他のエッジノードのインターフェイスアドレスとノードIDを知る必要があります。
When forming a SENDER_TEMPLATE, the ingress edge-node includes either its Node-ID or the address of one of its numbered TE links. In the latter case the connection will only be made over this interface.
sender_templateを形成するとき、イングレスエッジノードには、そのノードIDまたは番号付きTEリンクのいずれかのアドレスのいずれかが含まれます。後者の場合、接続はこのインターフェイスに対してのみ行われます。
When forming a SESSION_OBJECT, the ingress edge-node includes either the Node-ID of the egress edge-device or the address of one of the egress' numbered TE links. In the latter case the connection will only be made over this interface. The Extended_Tunnel_ID of the SESSION Object is set to either zero or to an address of the ingress edge-device.
session_objectを形成するとき、イングレスエッジノードには、出口エッジデバイスのノードIDまたはegressの番号付きTEリンクの1つのアドレスのいずれかが含まれます。後者の場合、接続はこのインターフェイスに対してのみ行われます。セッションオブジェクトの拡張_tunnel_idは、ゼロまたはイングレスエッジデバイスのアドレスに設定されます。
Links may be either numbered or unnumbered. Further, links may be bundled or unbundled. See [GMPLS-ARCH], [RFC3471], [BUNDLE], and [RFC3477].
リンクに番号が付けられているか、数えられていない場合があります。さらに、リンクはバンドルまたはバンドルされていない場合があります。[GMPLS-ARCH]、[RFC3471]、[Bundle]、および[RFC3477]を参照してください。
An edge-node MAY include an ERO. A core-node MAY reject a Path message that contains an ERO. Such behavior is controlled by (hopefully consistent) configuration. If a core-node rejects a Path message due to the presence of an ERO, it SHOULD return a PathErr message with an error code of "Unknown object class" toward the sender as described in [RFC3209]. This causes the path setup to fail.
エッジノードにはEROが含まれる場合があります。コアノードは、EROを含むパスメッセージを拒否する場合があります。このような動作は、（できれば一貫した）構成によって制御されます。コアノードがEROの存在のためにパスメッセージを拒否した場合、[RFC3209]に記載されているように、送信者に「不明なオブジェクトクラス」のエラーコードを含むPatherRメッセージを返す必要があります。これにより、パスセットアップが失敗します。
Further, a core-node MAY accept EROs that only include the ingress edge-node, the ingress core-node, the egress core-node, and the egress edge-node. This is to support explicit label control on the edge-node interface; see below. If a core-node rejects a Path message due to the presence of an ERO that is not of the permitted format, it SHOULD return a PathErr message with an error code of Bad Explicit Route Object as defined in [RFC3209].
さらに、コアノードは、イングレスエッジノード、イングレスコアノード、出口コアノード、出力エッジノードのみを含むErosを受け入れる場合があります。これは、エッジノードインターフェイスの明示的なラベル制御をサポートするためです。下記参照。コアノードが許可された形式ではないEROの存在のためにパスメッセージを拒否した場合、[RFC3209]で定義されているように、BAD明示的ルートオブジェクトのエラーコードを使用してPatherRメッセージを返す必要があります。
When a core-node receives a Path message from an edge-node that contains no ERO, it MUST calculate a route to the destination and include that route in an ERO, before forwarding the PATH message. One exception would be if the egress edge-node were also adjacent to this core-node. If no route can be found, the core-node SHOULD return a PathErr message with an error code and value of 24,5 - "No route available toward destination".
コアノードがEROを含むエッジノードからパスメッセージを受信した場合、パスメッセージを転送する前に、宛先へのルートを計算し、EROにそのルートを含める必要があります。1つの例外は、出口エッジノードがこのコアノードにも隣接していた場合です。ルートが見つからない場合、コアノードはエラーコードと24,5の値を持つPatherrメッセージを返す必要があります。「宛先に向けてルートはありません」。
When a core-node receives a Path message from an edge-node that contains an ERO, it SHOULD verify the route against its topology database before forwarding the PATH message. If the route is not viable (according to topology, currently available resources, or local policy), then a PathErr message with an error code and value of 24,5 - "No route available toward destination" should be returned.
コアノードがEROを含むエッジノードからパスメッセージを受信すると、パスメッセージを転送する前にトポロジデータベースに対するルートを検証する必要があります。ルートが実行可能でない場合（トポロジ、現在利用可能なリソース、またはローカルポリシーによると）、エラーコードと24,5の値を持つPatherrメッセージ - 「宛先に向かって利用できないルート」を返す必要があります。
In order to support explicit label control and full identification of the egress link, an ingress edge-node may include this information in the ERO that it passes to its neighboring core-node. In the case that no other ERO is supplied, this explicit control information is provided as the only hop of the ERO and is encoded by setting the first subobject of the ERO to the node-ID of the egress core-node with the L-bit set; following this subobject are all other subobjects necessary to identify the link and labels as they would normally appear.
明示的なラベル制御と出口リンクの完全な識別をサポートするために、侵入エッジノードには、隣接するコアノードに渡されるEROにこの情報を含めることができます。他のEROが提供されていない場合、この明示的な制御情報はEROの唯一のホップとして提供され、EROの最初のサブオブジェクトをl-bitを使用して出力コアノードのノードIDに設定することによりエンコードされます。設定;このサブオブジェクトに従うことは、通常表示されるリンクとラベルを識別するために必要な他のすべてのサブオブジェクトです。
The same rules apply to the presence of the explicit control subobjects as the last hop in the ERO, if a fuller ERO is supplied by the ingress edge-node to its neighbor core-node; but in this case the L-bit MAY be clear.
同じルールは、EROの最後のホップとしての明示的な制御サブオブジェクトの存在に適用されます。しかし、この場合、Lビットは明確になる可能性があります。
This process is described in [RFC3473] and [EXPLICIT].
このプロセスは、[RFC3473]および[明示]で説明されています。
An edge-node MAY include an RRO. A core-node MAY remove the RRO from the Path message before forwarding it. Further, the core-node may remove the RRO from a Resv message before forwarding it to the edge-node. Such behavior is controlled by (hopefully consistent) configuration.
エッジノードにはRROが含まれる場合があります。コアノードは、転送する前にパスメッセージからRROを削除する場合があります。さらに、コアノードはRESVメッセージからRROを削除してから、エッジノードに転送できます。このような動作は、（できれば一貫した）構成によって制御されます。
Further, a core-node MAY edit the RRO in a Resv message such that it includes only the subobjects from the egress core-node through the egress edge-node. This is to allow the ingress node to be aware of the selected link and labels on at the far end of the connection.
さらに、コアノードは、rROをRESVメッセージで編集する場合があります。これにより、出口コアノードからの出口エッジノードからのサブオブジェクトのみが含まれます。これは、イングレスノードが選択したリンクと、接続の遠端でラベルを付けることを可能にするためです。
An edge-node MAY include a NOTIFY_REQUEST object in both the Path and Resv messages it generates. Core-nodes may send Notify messages to edge-nodes that have included the NOTIFY_REQUEST object.
エッジノードには、生成するパスメッセージとRESVメッセージの両方にnotify_requestオブジェクトを含めることができます。コアノードは、notify_requestオブジェクトを含むエッジノードに通知メッセージを送信する場合があります。
A core-node MAY remove a NOTIFY_REQUEST object from a Path or Resv message received from an edge-node before forwarding it.
コアノードは、転送する前にエッジノードから受信したパスまたはRESVメッセージからnotify_requestオブジェクトを削除する場合があります。
If no NOTIFY_REQUEST object is present in the Path or Resv received from an edge-node, the core-node adjacent to the edge-node may include a NOTIFY_REQUEST object and set its value to its own address.
notify_requestオブジェクトがエッジノードから受信されたパスまたはRESVに存在しない場合、エッジノードに隣接するコアノードにはnotify_requestオブジェクトが含まれ、その値を独自のアドレスに設定できます。
In either of the above cases, the core-node SHOULD NOT send Notify messages to the edge-node.
上記のいずれかの場合、コアノードは通知メッセージをエッジノードに送信しないでください。
When a core-node receives a NOTIFY_REQUEST object from an edge-node, it MAY update the Notify Node Address with its own address before forwarding it. In this case, when Notify messages are received, they MAY be selectively (based on local policy) forwarded to the edge-node.
コアノードがエッジノードからnotify_requestオブジェクトを受信すると、転送する前に通知ノードアドレスを独自のアドレスで更新する場合があります。この場合、通知メッセージが受信されると、それらは（ローカルポリシーに基づいて）エッジノードに転送される場合があります。
RSVP-TE currently deletes connections using either a single pass PathTear message, or a ResvTear and PathTear message combination. Upon receipt of the PathTear message, a node deletes the connection state and forwards the message. In optical networks, however, it is possible that the deletion of a connection (e.g., removal of the cross-connect) in a node may cause the connection to be perceived as failed in downstream nodes (e.g., loss of frame, loss of light, etc.). This may in turn lead to management alarms and perhaps the triggering of restoration/protection for the connection.
RSVP-TEは現在、単一のパスPATHTEARメッセージ、またはresVTEARおよびPATHTEARメッセージの組み合わせのいずれかを使用して接続を削除しています。PathTearメッセージを受信すると、ノードが接続状態を削除し、メッセージを転送します。ただし、光学ネットワークでは、ノード内の接続の削除（クロスコネクトの削除など）により、下流ノードでは接続が失敗したと認識される可能性があります（たとえば、フレームの喪失、光の喪失、など）。これにより、管理アラームと、おそらく接続の復元/保護のトリガーにつながる可能性があります。
To address this issue, the graceful connection deletion procedure SHOULD be followed. Under this procedure, an ADMIN_STATUS object MUST be sent in a Path or Resv message along the connection's path to inform all nodes en route to the intended deletion, prior to the actual deletion of the connection. The procedure is described in [RFC3473].
この問題に対処するには、優雅な接続削除手順に従う必要があります。この手順では、接続の実際の削除の前に、admin_statusオブジェクトを接続のパスに沿ってパスまたはRESVメッセージに送信する必要があります。手順は[RFC3473]で説明されています。
If an ingress core-node receives a PathTear without having first seen an ADMIN_STATUS object informing it that the connection is about to be deleted, it MAY pause the PathTear and first send a Path message with an ADMIN_STATUS object to inform all downstream LSRs that the connection is about to be deleted. When the Resv is received echoing the ADMIN_STATUS or using a timer as described in [RFC3473], the ingress core-node MUST forward the PathTear.
Ingress Core-Nodeが、接続が削除されようとしていることを通知するAdmin_Statusオブジェクトを最初に見たことなくPathTearを受信した場合、PATHTEARを一時停止し、最初にAdmin_Statusオブジェクトを使用してパスメッセージを送信して、すべての下流LSRSに接続を通知する場合があります。削除されようとしています。[RFC3473]に記載されているように、admin_statusをエコーしたり、タイマーを使用したりするRESVを受信した場合、IngressコアノードはPATHTEARを転送する必要があります。
[RFC3473] introduces the Path_State_Removed flag to a PathErr message to indicate that the sender has removed all state associated with the LSP and does not need to see a PathTear. A core-node next to an edge-node MAY map between teardown using ResvTear/PathTear and PathErr with Path_state_Removed.
[RFC3473]は、送信者がLSPに関連するすべての状態を削除し、PATHTEARを見る必要がないことを示すために、PATH_STATE_REMOVEDフラグをPATHERRメッセージに導入します。エッジノードの横にあるコアノードは、resvtear/pathtearとpath_state_removedを使用して壊死の間にマッピングできます。
A core-node next to an edge-node receiving a ResvTear from its downstream neighbor MAY respond with a PathTear and send a PathErr with Path_State_Removed further upstream.
下流の隣人からresvtearを受信するエッジノードの横にあるコアノードは、pathtearで応答し、path_state_removedをさらに上流で送信する場合があります。
Note, however, that a core-node next to an edge-node receiving a PathErr with Path_State_Removed from its downstream neighbor MUST NOT retain Path state and send a ResvTear further upstream because that would imply that Path state further downstream had also been retained.
ただし、下流の隣人からpath_state_removedを使用してpatherrを受信するエッジノードの横にあるコアノードは、パス状態を保持し、さらに下流にresvtearを送信してはならないことに注意してください。
As stated in the addressing section above, the extensions in this document are designed to be compatible with the support of VPNs. Since the core network may be some technology other than GMPLS, no mandatory means of mapping core connections to access connections is specified. However, when GMPLS is used for the core network, it is RECOMMENDED that the following procedure based on [MPLS-HIER] is followed.
上記のアドレス指定セクションに記載されているように、このドキュメントの拡張機能は、VPNのサポートと互換性があるように設計されています。コアネットワークはGMPL以外のテクノロジーである可能性があるため、アクセス接続にコア接続をマッピングする必須の手段は指定されていません。ただし、コアネットワークにGMPLSを使用する場合、[MPLS-Hier]に基づく次の手順に従うことをお勧めします。
The VPN connection is modeled as being three hops. One for each access link and one hop across the core network.
VPN接続は、3ホップとしてモデル化されています。各アクセスリンクに1つ、コアネットワークを横切る1つのホップ。
The VPN connection is established using a two-step procedure. When a Path message is received at a core-node on an interface that is part of a VPN, the Path message is held until a core connection is established.
VPN接続は、2段階の手順を使用して確立されます。VPNの一部であるインターフェイス上のコアノードでパスメッセージが受信されると、コア接続が確立されるまでパスメッセージが保持されます。
The connection across the core is setup as a separate signaling exchange between the core-nodes, using the address space of the core nodes. While this exchange is in progress, the original Path message is held at the ingress core-node. Once the exchange for the core connection is complete, this connection is used in the VPN connection as if it were a single link. This is signaled by including an IF_ID RSVP_HOP object (defined in [RFC3473]) using the procedures defined in [MPLS-HIER].
コアを横切る接続は、コアノードのアドレス空間を使用して、コアノード間の個別のシグナル交換としてセットアップされます。この交換が進行中ですが、元のパスメッセージはIngress Coreノードに保持されます。コア接続の交換が完了すると、この接続はVPN接続で単一のリンクであるかのように使用されます。これは、[mpls-hier]で定義された手順を使用して、if_id rsvp_hopオブジェクト（[rfc3473]で定義）を含めることによってシグナル伝達されます。
The original Path message is then forwarded within the VPN addressing realm to the core-node attached to the destination edge-node. Many ways of accomplishing this are available, including IP and GRE tunnels and BGP/MPLS VPNs. Specifying a particular means is beyond the scope of this document.
次に、元のパスメッセージは、VPNにアドレス指定された領域内で、宛先エッジノードに接続されたコアノードに転送されます。IPおよびGREトンネルやBGP/MPLS VPNSなど、これを達成する多くの方法が利用可能です。特定の手段を指定することは、このドキュメントの範囲を超えています。
The trust model between the core and edge-nodes is different than the one described in [RFC3473], as the core is permitted to hide its topology from the edge-nodes, and the core is permitted to restrict the actions of edge-nodes by filtering out specific RSVP objects.
コアとエッジノードの間の信頼モデルは、[RFC3473]で説明されているモデルとは異なります。これは、コアがエッジノードからトポロジーを隠すことが許可されており、コアはエッジノードのアクションを制限することが許可されています。特定のRSVPオブジェクトをフィルタリングします。
The authors would like to thank Kireeti Kompella, Jonathan Lang, Dimitri Papadimitriou, Dimitrios Pendarakis, Bala Rajagopalan, and Adrian Farrel for their comments and input. Thanks for thorough final reviews from Loa Andersson and Dimitri Papadimitriou.
著者は、Kireeti Kompella、Jonathan Lang、Dimitri Papadimitriou、Dimitrios Pendarakis、Bala Rajagopalan、およびAdrian Farrelのコメントと意見に感謝します。Loa AnderssonとDimitri Papadimitriouからの徹底的な最終レビューをありがとう。
Adrian Farrel edited the last two revisions of this document to incorporate comments from Working Group last call and from AD review.
Adrian Farrelは、このドキュメントの最後の2つの改訂を編集して、ワーキンググループの最後のコールとADレビューからコメントを組み込みました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソースリソースプロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[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年。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年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月。
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[バンドル] Kompella、K.、Rekhter、Y。、およびBerger、L。、「MPLS Traffic Engineering（TE）におけるリンクバンドリング」、RFC 4201、2005年10月。
[EXPLICIT] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
[明示] Berger、L。、「GMPLS Signaling Procedure for Eugress Control」、RFC 4003、2005年2月。
[GMPLS-ARCH] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[GMPLS-ARCH] Mannie、E。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[MPLS-HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[MPLS-HIER] Kompella、K。およびY. Rekhter、「ラベルスイッチドパス（LSP）階層、一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えた階層」、2005年10月。
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)," November 2001 (and Revision, January 2003). For information on the availability of this document, please see http://www.itu.int.
[g.8080] itu-t rec。G.8080/Y.1304、「自動化された光ネットワーク（ASON）のアーキテクチャ」、2001年11月（および2003年1月の改訂）。このドキュメントの可用性については、http：//www.itu.intを参照してください。
Authors' Addresses
著者のアドレス
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave, Boxborough, MA 01719
George Swallow Cisco Systems、Inc。1414 Massachusetts Ave、Boxborough、MA 01719
Phone: +1 978 936 1398
EMail: swallow@cisco.com
John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245
ジョンドレイクボーイング衛星システム2300イーストインペリアルハイウェイエルセグンド、カリフォルニア90245
Phone: +1 412 370-3108
EMail: John.E.Drake2@boeing.com
Hirokazu Ishimatsu G1M Co., Ltd. Nishinippori Start up Office 214, 5-37-5 Nishinippori, Arakawaku, Tokyo 116-0013, Japan
Hirokazu ishimatsu G1m Co.、Ltd。Nishinippori Start Up Office 214、5-37-5 Nishinippori、Arakawaku、Tokyo 116-0013、日本
Phone: +81 3 3891 8320
EMail: hirokazu.ishimatsu@g1m.jp
Yakov Rekhter Juniper Networks, Inc.
Yakov Rekhter Juniper Networks、Inc。
EMail: yakov@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。