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
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).
著作権（C）インターネット協会（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を）ラベルスイッチの作成のためのルーティングおよびシグナリングプロトコルの両方を規定します。これらのプロトコルは、展開シナリオの数をサポートするために使用することができます。このメモは、オーバレイモデルへのGMPLSのアプリケーションに対応します。
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
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.
エッジ・ノード間のリンクが要求され、トリガされたどのようにリンクしているページがオーバレイネットワークでどのように使われるかを正確であるとして、この文書の範囲外です。一つの可能性は、エッジノードは[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.
オーバーレイモデルでは、エッジノードとコアノードとの間にシグナリングすることができるものに制限があってもよいです。このメモは、オーバレイモデルへのGMPLSのアプリケーションに対応します。具体的には、オーバレイモデルのエッジノードとコアノードとの間の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.
この文書は、主エッジノードとの間の相互作用に対処し、それが（データプレーンにおける）コアノード隣接です。アウトオブバンドと非隣接のシグナリング機能は、シグナリングメッセージがより長い経路上で配信されていることを意味します。記載した以外は、用語コアノードは、特定のデータ・プレーン・インタフェースを介してエッジノードに直接隣接ノードを指します。用語コアノードは、しかしながら、コア内のすべてのノードを指します。
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の単一または複数のインスタンスの実現は、それが第7章に詳述ロバスト性、セキュリティおよびプライバシーのための機能要件を満たすようにCNとENの両方で実装依存です。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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
このメモに記載の拡張機能は[RFC3471、RFC3473]をGMPLSシグナリングと互換性のあるUNIシグナリングのためのメカニズムを提供します。また、UNIシグナリングのためのこれらのメカニズムは、RSVPモデルと一致しています。すなわち、ユーザ接続のための単一のエンドツーエンドRSVPセッションがあります。最初と最後のホップはUNIを構成し、RSVPセッションは、ユーザ・パラメータは、エンドツーエンド運びます。これは、サービスプロバイダーネットワーク内で使用されるネットワーク・ツー・ネットワークインタフェース（NNI）が期待する形式（IN）にユーザパラメータをマッピング（または運ぶ）する必要がなくなります。これは、順番にUNIとNNIはの要件である、互いに独立していることを意味し
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.
ASONアーキテクチャ。しかしながら、所望であればUNIとNNIはGMPLSのRSVPベースの両方される場合に、このメモで指定された方法論は、UNIおよびNNIシグナリングの両方をインスタンス化するために単一のRSVPセッションを可能にし、サービスプロバイダのポリシーによって許可されている場合。
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によって使用される同じアドレス空間を共有しなければなりません。セット内のエッジノードはアドレスマッピングまたは変換せずにそれらの間（コアノードを介して）LSPを確立することができれば、<エッジノード、コアノード>のセットはタプルが同じアドレス空間を共有する（でそのエッジノードを注意セット）は、すべてのエッジノードのサブセットであってもよいです。アドレス相互に通信するコアノードによって使用されるスペースもよいが、のいずれかによって使用されるアドレス空間<エッジノード、コアノード>タプルと共有することは、必要はありません。 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.
複数のオーバレイネットワークは、単一のコア・ネットワークによってサポートされている場合、一つ以上のアドレス空間は、プライバシー要件に応じて使用することができます。それは、アドレススペースのメンバーシップを構成する<エッジノード、コアノード>タプルであるので、これは、コア・ノード・アドレスを変えることなく達成することができます。
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リンクの1つのアドレスのいずれかを含みます。後者の場合、接続は、このインターフェースを介して行われます。
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のいずれかの出口エッジデバイスまたは出力のいずれかのアドレスを含むTEリンクの番号。後者の場合、接続は、このインターフェースを介して行われます。セッションオブジェクトのExtended_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の存在のためにPathメッセージを拒否した場合、[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].
さらに、コアノードは、入口エッジノード、入口コアノード、出口コアノード、および出口エッジノードを含むエロスを受け入れることができます。これは、エッジノードのインタフェース上で明示的にラベル制御をサポートすることです。下記参照。コアノードが原因許可フォーマットでないEROの存在にPathメッセージを拒否した場合、[RFC3209]で定義されるように、それは悪い明示的ルート・オブジェクトのエラーコードの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が含まれていないエッジノードからPathメッセージを受信すると、目的地までの経路を計算しなければならないし、PATHメッセージを転送する前に、EROにその経路を含みます。出口エッジノードもこのコアノードに隣接していた場合は、1つの例外は、あろう。 NOルートが見つからない場合、コア・ノードは、24.5のエラーコードと値とのPathErrメッセージを返してはならない - 「宛先に向けて利用可能なNOルート」。
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を含んエッジノードからPathメッセージを受信すると、PATHメッセージを転送する前に、そのトポロジ・データベースに対してルートを確認する必要があります。ルートが実行可能でない場合（トポロジー、現在利用可能なリソース、またはローカルポリシーに従って）、次いで24.5のエラーコードと値とのPathErrメッセージ - 「宛先に向かって使用可能Noルート」が返されるべきです。
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の唯一のホップとして提供され、Lビットと出口コアノードのノードIDにEROの最初のサブオブジェクトを設定して符号化されますセットする;このサブオブジェクト以下、彼らが正常に見えるように、リンクとラベルを識別するために必要な他のすべてのサブオブジェクトです。
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がその隣接コアノードへの入口エッジノードによって供給される場合、同じ規則が、EROの最後のホップとして、明示的な制御サブオブジェクトの存在に適用されます。しかし、この場合、Lビットが明確である場合があります。
This process is described in [RFC3473] and [EXPLICIT].
このプロセスは、[RFC3473]と[EXPLICIT]に記載されています。
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を含むかもしれません。コアノードはそれを転送する前に、Pathメッセージから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.
さらに、コア・ノードは、出口エッジノードを介して出口コアノードからのみサブオブジェクトを含むようにResvメッセージにRROを編集することができます。これは、入口ノードが選択されたリンクを認識することができるようにすることですと、接続の遠端でのラベル。
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.
エッジノードは、Pathとが生成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.
入口コアノードは、最初の接続が削除されようとしていることを知らせるADMIN_STATUSオブジェクトを見たことなくPathTearを受信した場合、それはPathTearを一時停止し、最初にその接続のすべての下流のLSRに通知するADMIN_STATUSオブジェクトとPathメッセージを送信することができます削除されようとしています。 ResvはADMIN_STATUSをエコーまたは[RFC3473]に記載されているように、タイマを使用して受信されると、入口コアノードは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を参照する必要がないことを示すためのPathErrメッセージにPath_State_Removedフラグを導入します。エッジノードへの次のコアノードはPath_state_Removedと共にたResvTear / PathTearとのPathErrを用いてティアダウンの間にマッピングしてもよいです。
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とのPathErrを送信することができます。
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のサポートと互換性を持つように設計されています。コアネットワークは、GMPLS以外の技術であってもよいので、接続にアクセスするためのマッピングコア接続のない必須の手段が指定されていません。 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つのホップの一つ。
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ステップ手順を使用して確立されます。 Pathメッセージは、VPNの一部であるインターフェイス上のコア・ノードで受信されると、コア接続が確立されるまで、Pathメッセージが保持されています。
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].
コアの両端の接続は、コア・ノードのアドレス空間を使用して、コア・ノードとの間の別個のシグナリング交換、などの設定です。この交換が進行している間、元のPathメッセージは、入口コアノードに保持されます。コア接続用の交換が完了すると、それは単一のリンクであるかのように、この接続はVPN接続で使用されています。これは、[MPLS-HIER]で定義された手順を使用して（[RFC3473]で定義される）IF_ID RSVP_HOPオブジェクトを含めることによりシグナリングされます。
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 VPNを含む、利用可能です。特定の手段を指定すると、このドキュメントの範囲を超えています。
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、ジョナサンラング、ディミトリPapadimitriou、ディミトリオスPendarakis、バラRajagopalan、およびエードリアンファレルに感謝したいと思います。ロア・アンダーソンとディミトリPapadimitriouからの徹底した最終口コミ情報をお寄せいただきありがとうございます。
Adrian Farrel edited the last two revisions of this document to incorporate comments from Working Group last call and from AD review.
エードリアンファレルは、ワーキンググループの最後の呼び出しからとADのレビューからコメントを組み込むために、このドキュメントの最後の二つのリビジョンを編集しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、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]バーガー、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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.
[BUNDLE] Kompella、K.、Rekhter、Y.、およびバーガー、L.、 "MPLSでのリンクバンドルトラフィックエンジニアリング（TE）"、RFC 4201、2005年10月。
[EXPLICIT] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
バーガー、L.、 "出力制御のためのGMPLSシグナリング手順"、RFC 4003、2005年2月[EXPLICIT]。
[GMPLS-ARCH] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[GMPLS-ARCH]マニー、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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[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勧告。 G.8080 / Y.1304、2001年11月 "の自動交換光ネットワーク（ASON）、のためのアーキテクチャ"（および改訂、2003年1月）。このドキュメントの利用可能性については、http://www.itu.intを参照してください。
Authors' Addresses
著者のアドレス
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave, Boxborough, MA 01719
ジョージツバメシスコシステムズ株式会社1414年マサチューセッツアベニュー、ボックスボロー、MA 01719
Phone: +1 978 936 1398 EMail: swallow@cisco.com
電話：+1 978 936 1398 Eメール：swallow@cisco.com
John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245
ジョン・ドレイクボーイング衛星システム2300東インペリアルハイウェイエルセグンドー、CA 90245
Phone: +1 412 370-3108 EMail: John.E.Drake2@boeing.com
電話：+1 412 370-3108 Eメール：John.E.Drake2@boeing.com
Hirokazu Ishimatsu G1M Co., Ltd. Nishinippori Start up Office 214, 5-37-5 Nishinippori, Arakawaku, Tokyo 116-0013, Japan
ひろかず いしまつ Ｇ１Ｍ こ。、 Ｌｔｄ。 にしにっぽり Ｓたｒｔ うｐ おっふぃせ ２１４、 ５ー３７ー５ にしにっぽり、 あらかわく、 ときょ １１６ー００１３、 じゃぱん
Phone: +81 3 3891 8320 EMail: hirokazu.ishimatsu@g1m.jp
電話：+81 3 3891 8320 Eメール：hirokazu.ishimatsu@g1m.jp
Yakov Rekhter Juniper Networks, Inc.
ヤコフ・レックタージュニパーネットワークス株式会社
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。