RFC4208 日本語訳
4208 Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering(RSVP-TE) Support for the Overlay Model. G. Swallow, J. Drake, H.Ishimatsu, Y. Rekhter. October 2005. (Format: TXT=28693 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループG.ツバメ要求をネットワークでつないでください: 4208年のシスコシステムズ、Incカテゴリ: 標準化過程J.ドレイクボーイングH.Ishimatsu G1M株式会社Y.Rekhter杜松ネットワーク、Inc2005年10月
Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI):
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
Support for the Overlay Model
一般化されたMultiprotocolはユーザネットワーク・インターフェース(UNI)と切り換え(GMPLS)をラベルします: オーバレイモデルの資源予約プロトコル交通工学(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
一般化されたMultiprotocol Label Switching(GMPLS)は様々な切り換え技術における、Label Switched Paths(LSPs)の創造のためにルーティングとシグナリングプロトコルの両方を定義します。 多くの展開シナリオを支持するのにこれらのプロトコルを使用できます。 このメモはオーバレイモデルにGMPLSのアプリケーションを記述します。
Swallow, et al. Standards Track [Page 1] RFC 4208 RSVP-TE Support for the Overlay Model October 2005
ツバメ、他 規格はモデル2005年10月にオーバレイのRFC4208RSVP-Teサポートを追跡します[1ページ]。
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
1. 序論…2 1.1. GMPLSユーザネットワーク・インターフェース(GMPLS UNI)…4 2. 記述します。5 3. ERO処理…6 3.1. EROのない経路メッセージ…6 3.2. EROがある経路メッセージ…6 3.3. 明白なラベルコントロール…7 4. RRO処理…7 5. 通知…7 6. 接続削除…8 6.1. 無アラームの接続削除…8 6.2. PathErrとの接続削除…8 7. VPNコネクションズ…9 8. セキュリティ問題…10 9. 承認…10 10. 参照…10 10.1. 標準の参照…10 10.2. 情報の参照…10
1. Introduction
1. 序論
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.
一般化されたMultiprotocol Label Switching(GMPLS)は様々な輸送技術における、Label Switched Paths(LSPs)の創造のためにルーティングとシグナリングプロトコルの両方を定義します。 多くの展開シナリオを支持するのにこれらのプロトコルを使用できます。 同輩モデルでは、縁ノードはルーティングとシグナリングプロトコルの両方をサポートします。 縁ノードとコアノードとのプロトコル相互作用は2つのコアノードの間と同じです。 オーバレイモデルでは、コアノードはさらにクローズドシステムとして機能します。 縁ノードはコアノードの中を走るルーティング・プロトコル例に参加しません。 縁ノードはコアノードのトポロジーに特に、気づきません。 しかしながら、他の縁ノードへの可到達性情報の交換のためのコアノードと縁ノードとのルーティング・プロトコル相互作用があるかもしれません。
Swallow, et al. Standards Track [Page 2] RFC 4208 RSVP-TE Support for the Overlay Model October 2005
ツバメ、他 規格はモデル2005年10月にオーバレイのRFC4208RSVP-Teサポートを追跡します[2ページ]。
Overlay Overlay
Network +----------------------------------+ Network
+---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | |
| -+ EN +-+-----+--+ CN +----+ CN +----+ CN +---+-----+-+ EN +- |
| | | | +--+--| | | | | | | | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ |
| | | | | | | | | |
+---------+ | | | | | | +---------+
| | | | | |
+---------+ | | | | | | +---------+
| | | | +--+--+ | +--+--+ | | |
| +----+ | | | | | +-------+ | | | +----+ |
| | +-+--+ | | CN +---------------+ CN | | | | | |
| -+ EN +-+-----+--+ | | +---+-----+-+ EN +- |
| | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ |
| | +----------------------------------+ | |
+---------+ Core Network +---------+
Overlay Overlay
Network Network
オーバレイオーバレイネットワーク+----------------------------------+ ネットワーク+---------+ | | +---------+ | +----+ | | +-----+ +-----+ +-----+ | | +----+ | | | | | | | | | | | | | | | | | | -+ アン、++-----+--+ CN+----+ CN+----+ CN+---+-----++アン+| | | | | +--+--| | | | | | | | | | | | +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ | | | | | | | | | | | +---------+ | | | | | | +---------+ | | | | | | +---------+ | | | | | | +---------+ | | | | +--+--+ | +--+--+ | | | | +----+ | | | | | +-------+ | | | +----+ | | | +-+--+ | | CN+---------------+ CN| | | | | | | -+ アン、++-----+--+ | | +---+-----++アン+| | | | | | +-----+ +-----+ | | | | | | +----+ | | | | +----+ | | | +----------------------------------+ | | +---------+ コアネットワーク+---------+ オーバレイオーバレイネットワークネットワーク
Legend: EN - Edge Node
CN - Core Node
伝説: アン--縁のノード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.
このドキュメントの範囲の外に縁ノードの間のリンクがどう要求されていて、引き起こされるかがあります、そのリンクがOverlay Networkによって正確にどう使用されるように。 1つの可能性は縁ノードがリンクの存在のオーバレイネットワークの他のノードを知らせるということです、ことによると[MPLS-HIER]で説明されるように推進隣接番組を使用して。 これがコアノードの間のリンクとしてコアネットワークによって提供される推進隣接番組とひどく違うことに注意してください。
Swallow, et al. Standards Track [Page 3] RFC 4208 RSVP-TE Support for the Overlay Model October 2005
ツバメ、他 規格はモデル2005年10月にオーバレイのRFC4208RSVP-Teサポートを追跡します[3ページ]。
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.
セクション7で詳細な丈夫さ、セキュリティ、およびプライバシーのための機能条件書を満たす限り、UNIのシングルか複数の例の実現は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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Readers are assumed to be familiar with the terminology introduced in [RFC3031], [GMPLS-ARCH], and [RFC3471].
読者が[RFC3031]、[GMPLS-ARCH]、および[RFC3471]で紹介された用語によく知られさせると思われます。
1.1. GMPLS User-Network Interface (GMPLS UNI)
1.1. GMPLSユーザネットワーク・インターフェース(GMPLS UNI)
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.
1つはAutomatically Switched Optical Network(ASON)[G.8080]で定義されたUser-ネットワークInterface(UNI)基準点でGMPLS Overlayモデルを適用できます。 図1の'コアNetwork'がService Providerネットワークであり、Edge Nodesが'ユーザ'装置であるケースを考えてください。 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
このメモで説明された拡大は合図するGMPLSと互換性があるUNIシグナリング[RFC3471、RFC3473]にメカニズムを提供します。 そのうえ、UNIシグナリングのためのこれらのメカニズムがRSVPモデルに沿ってあります。 すなわち、ユーザ接続のためのただ一つの終わりから終わりへのRSVPセッションがあります。 1番目と最後のホップはUNIを構成します、そして、RSVPセッションはユーザのパラメタの終わりから終わりを運びます。 これは形式がService Providerネットワークの中で使用されたネットワークからネットワーク・インターフェース(NNI)で予想した(in)にユーザパラメタを写像する(運んでください)必要性を取り除きます。 これは、UNIとNNI缶がお互いから独立していることを順番に意味して、要件はどれのものであるか。
Swallow, et al. Standards Track [Page 4] RFC 4208 RSVP-TE Support for the Overlay Model October 2005
ツバメ、他 規格はモデル2005年10月にオーバレイのRFC4208RSVP-Teサポートを追跡します[4ページ]。
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セッション、Service Provider方針で許容されているならこのメモが許容するコネを指定しました。
2. Addressing
2. アドレシング
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によって使用されるのと同じアドレス空間を共有しなければなりません。 1セットの<縁ノード、セットにおける縁ノードが自分たちの中にアドレス・マッピングも翻訳なしでLSPs(コアノードを通した)を設立できるなら(セットにおける縁ノードがすべての縁ノードの部分集合であるかもしれないことに注意してください)、コアノード>tuplesは同じアドレス空間を共有します。 しかし、コアノードによって使用される、自分たちの中で交信するアドレス空間がそうするかもしれない、<縁ノード(コアノード>tuples)のいずれによっても使用されるアドレス空間と共有されなければならなくなってください。 これはLSPsの1セットと与えられたアドレシングスペースの間の義務的な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つ以上のアドレス空間が使用されるかもしれません。 それが<縁ノード(アドレス空間会員資格を構成するコアノード>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).
縁ノードがNode-IDを表すただ一つのIPアドレス、またはもの時までに特定されたか、または以上は縁ノードをコアノードに接続する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.
コアノードの必要性はそのコアノードとその添付の縁ノードとのインタフェースに関するアドレスを知っているだけです(追跡してください)、それらの縁ノードのNode IDと同様に。 さらに、コアノードは、添付の縁ノードが接続することが許可されている他の縁ノードのインターフェース・アドレスとNode IDを知る必要があります。
Swallow, et al. Standards Track [Page 5] RFC 4208 RSVP-TE Support for the Overlay Model October 2005
ツバメ、他 規格はモデル2005年10月にオーバレイのRFC4208RSVP-Teサポートを追跡します[5ページ]。
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を形成するとき、イングレス縁ノードはNode-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を形成するとき、イングレス縁ノードは出口エッジデバイスのNode-IDか出口の番号付のTEリンクの1つのアドレスのどちらかを含んでいます。 後者の場合では、このインタフェースであることを接続を変更されるだけでしょう。 SESSION Objectの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-アーチ]、[RFC3471]、[バンドル]、および[RFC3477]を見てください。
3. ERO Processing
3. ERO処理
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を含むPathメッセージを拒絶するかもしれません。 そのような振舞いは(願わくは一貫する)の構成によって制御されます。 コアノードはEROの存在のためPathメッセージを拒絶して、それは[RFC3209]で説明される送付者に向かった「未知の物のクラス」のエラーコードがあるSHOULDリターンa 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の存在のためPathメッセージを拒絶するなら、それは受入れられた形式のものでなく、それは中で定義されるBad Explicit Route Object[RFC3209]のエラーコードがあるSHOULDリターンa PathErrメッセージです。
3.1. Path Message without ERO
3.1. EROのない経路メッセージ
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メッセージを受け取るとき、目的地にルートを計算して、EROでそのルートを含めなければなりません、PATHメッセージを転送する前に。 出口縁ノードがこのコアノードに隣接してもいるなら、1つの例外がそうでしょうに。 ルートを全く見つけることができないなら、コアノードSHOULDは24、5のエラーコードと値があるPathErrメッセージを返します--「目的地に向かって利用可能なルートがありません。」
3.2. Path Message with ERO
3.2. EROがある経路メッセージ
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
コアノードが縁ノードからPathメッセージを受け取るとき、それはEROを含んでいます、それ。PATHメッセージを転送する前に、SHOULDはトポロジーデータベースに対してルートを確かめます。 ルートがそうでないなら
Swallow, et al. Standards Track [Page 6] RFC 4208 RSVP-TE Support for the Overlay Model October 2005
ツバメ、他 規格はモデル2005年10月にオーバレイのRFC4208RSVP-Teサポートを追跡します[6ページ]。
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.
24、5のエラーコードと値がある実行可能(トポロジー、現在利用可能なリソース、またはローカルの方針によると)で、当時のa PathErrメッセージ--「目的地に向かって利用可能なルートがありません」を返すべきです。
3.3. Explicit Label Control
3.3. 明白なラベルコントロール
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]で説明されます。
4. RRO Processing
4. RRO処理
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を編集するかもしれないので、それは出口コアノードから出口縁ノードまで「副-物」だけを含んでいます。 これは、イングレスノードが接続の遠端でオンな選択されたリンクとラベルを意識しているのを許容するためのものです。
5. Notification
5. 通知
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物を含んでいた縁ノードへのメッセージをNotifyに送るかもしれません。
A core-node MAY remove a NOTIFY_REQUEST object from a Path or Resv message received from an edge-node before forwarding it.
コアノードはそれを進める前に縁ノードから受け取られたPathか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物も縁ノードから受け取られたPathかResvに存在していないなら、縁ノードに隣接したコアノードは、NOTIFY_REQUEST物を含んで、それ自身のアドレスに値を設定するかもしれません。
Swallow, et al. Standards Track [Page 7] RFC 4208 RSVP-TE Support for the Overlay Model October 2005
ツバメ、他 規格はモデル2005年10月にオーバレイのRFC4208RSVP-Teサポートを追跡します[7ページ]。
In either of the above cases, the core-node SHOULD NOT send Notify messages to the edge-node.
上のケースのどちらかでは、コアノードSHOULD NOTは縁ノードへのメッセージをNotifyに送ります。
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物を受けるとき、それはそれを進める前のそれ自身のアドレスでNotify Node Addressをアップデートするかもしれません。 Notifyメッセージがこの場合受信されているとき、選択的に縁のノードにそれらを送るかもしれません(ローカルの方針に基づいています)。
6. Connection Deletion
6. 接続削除
6.1. Alarm-Free Connection Deletion
6.1. 無アラームの接続削除
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は、現在、ResvTearとただ一つのパスPathTearメッセージか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].
この問題、優雅な接続削除手順SHOULDを記述するには、続かれてください。 この手順の下では、_STATUSがあるに違いないのを反対させるADMINは意図している削除への途中ですべてのノードを知らせるために接続の経路に沿ってPathか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をポーズして、最初に、接続が削除されようとしていることをすべての川下のLSRsに知らせるためにADMIN_STATUS物でPathメッセージを送るかもしれません。 ResvがADMIN_STATUSを反響するか、または[RFC3473]で説明されるようにタイマを使用するのにおいて受け取られているとき、イングレスコアノードはPathTearを進めなければなりません。
6.2. Connection Deletion with PathErr
6.2. PathErrとの接続削除
[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_州_Removed旗を取り入れます。 縁ノードの横のコアノードはPathと共にResvTear/PathTearを使用する分解とPathErrの間で_状態_Removedを写像するかもしれません。
Swallow, et al. Standards Track [Page 8] RFC 4208 RSVP-TE Support for the Overlay Model October 2005
ツバメ、他 規格はモデル2005年10月にオーバレイのRFC4208RSVP-Teサポートを追跡します[8ページ]。
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_州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状態が保有されたのを含意するでしょう、_Path_州Removedと共に川下の隣人からPathErrを受ける縁ノードの横のコアノードが上流へPath状態を保有して、したがって、さらにResvTearを送ってはいけないことに注意してください。
7. VPN Connections
7. VPNコネクションズ
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.
上のアドレシング部で述べられているように、拡大はVPNsのサポートと互換性があるように本書では設計されています。 コアネットワークがGMPLS以外の何らかの技術であるかもしれないことで、接続にアクセスするコア接続を写像するどんな義務的な手段も指定されません。 しかしながら、GMPLSがコアネットワークに使用されるとき、[MPLS-HIER]に基づく以下の手順が従われているのは、RECOMMENDEDです。
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接続は、ツーステップ手順を用いることで確立されます。 VPNの一部であるインタフェースのコアノードにPathメッセージを受け取るとき、コア接続が確立されるまで、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接続に使用されます。 包含することによってこれが合図される、_ID RSVP_HOPが[MPLS-HIER]で定義された手順を用いることで反対するなら([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アドレシング分野の中で目的地縁ノードに添付されたコアノードにオリジナルのPathメッセージを転送します。 IP、GREトンネル、およびBGP/MPLS VPNsを含んでいて、これを達成する多くの方法が利用可能です。 特定の手段を指定するのはこのドキュメントの範囲を超えています。
Swallow, et al. Standards Track [Page 9] RFC 4208 RSVP-TE Support for the Overlay Model October 2005
ツバメ、他 規格はモデル2005年10月にオーバレイのRFC4208RSVP-Teサポートを追跡します[9ページ]。
8. Security Considerations
8. セキュリティ問題
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物を無視することによって縁ノードの機能を制限することが許可されているとき。
9. Acknowledgments
9. 承認
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、Bala Rajagopalan、およびエードリアン・ファレルに感謝したがっています。 徹底的な最終審査をLoaアンデションとディミトリPapadimitriouからありがとうございます。
Adrian Farrel edited the last two revisions of this document to incorporate comments from Working Group last call and from AD review.
エードリアン・ファレルは作業部会から最後の呼び出しとADレビューからコメントを取り入れるこのドキュメントの最後の2つの改正を編集しました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、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)拡大」、RFC3473、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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
10.2. Informational References
10.2. 情報の参照
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、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)」、RFC3477、2003年1月。
Swallow, et al. Standards Track [Page 10] RFC 4208 RSVP-TE Support for the Overlay Model October 2005
ツバメ、他 規格はモデル2005年10月にオーバレイのRFC4208RSVP-Teサポートを追跡します[10ページ]。
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering (TE)", RFC 4201,
October 2005.
2005年10月の[バンドル]KompellaとK.とRekhter、Y.とバーガー、L.、「MPLS交通工学(Te)におけるリンクバンドリング」RFC4201。
[EXPLICIT] Berger, L., "GMPLS Signaling Procedure for Egress
Control", RFC 4003, February 2005.
[明白な] バーガー、L.、「出口コントロールのためのGMPLSシグナリング手順」、RFC4003、2005年2月。
[GMPLS-ARCH] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[GMPLS-アーチ] マニー、E.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)構造」、RFC3945、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)は「一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学(Te)で切り換えられた経路(LSP)を階層構造とラベルします」、RFC4206、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(そして、改正、2003年1月)年11月。 このドキュメントの有用性の情報に関しては、 http://www.itu.int を見てください。
Swallow, et al. Standards Track [Page 11] RFC 4208 RSVP-TE Support for the Overlay Model October 2005
ツバメ、他 規格はモデル2005年10月にオーバレイのRFC4208RSVP-Teサポートを追跡します[11ページ]。
Authors' Addresses
作者のアドレス
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave, Boxborough, MA 01719
Boxborough、MA ジョージツバメシスコシステムズInc.1414マサチューセッツAve、01719
Phone: +1 978 936 1398 EMail: swallow@cisco.com
以下に電話をしてください。 +1 1398年の978 936メール: swallow@cisco.com
John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245
エルセガンド、ジョンドレイクボーイングサテライト・システム2300の東帝国のHighwayカリフォルニア 90245
Phone: +1 412 370-3108 EMail: John.E.Drake2@boeing.com
以下に電話をしてください。 +1 412 370-3108 メールしてください: John.E.Drake2@boeing.com
Hirokazu Ishimatsu G1M Co., Ltd. Nishinippori Start up Office 214, 5-37-5 Nishinippori, Arakawaku, Tokyo 116-0013, Japan
裕和Ishimatsu G1M株式会社Nishinipporiはオフィス214、5-37-5Nishinippori、Arakawaku、東京116-0013、日本を立ち上げます。
Phone: +81 3 3891 8320 EMail: hirokazu.ishimatsu@g1m.jp
以下に電話をしてください。 +81 3 3891 8320はメールされます: hirokazu.ishimatsu@g1m.jp
Yakov Rekhter Juniper Networks, Inc.
ヤコフRekhter JuniperはInc.をネットワークでつなぎます。
EMail: yakov@juniper.net
メール: yakov@juniper.net
Swallow, et al. Standards Track [Page 12] RFC 4208 RSVP-TE Support for the Overlay Model October 2005
ツバメ、他 規格はモデル2005年10月にオーバレイのRFC4208RSVP-Teサポートを追跡します[12ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Swallow, et al. Standards Track [Page 13]
ツバメ、他 標準化過程[13ページ]
一覧
スポンサーリンク
