[要約] RFC 6383は、RSVP-TEを使用して確立されたラベルスイッチパスでデータを送信するのが安全なタイミングに関するアドバイスを提供します。このRFCの目的は、ネットワークエンジニアにデータ送信のタイミングを判断するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) K. Shiomoto
Request for Comments: 6383 NTT
Category: Informational A. Farrel
ISSN: 2070-1721 Old Dog Consulting
September 2011
Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE
RSVP-TEを使用して確立されたラベルスイッチ付きパスのデータの送信を開始しても安全な場合についてアドバイス
Abstract
概要
The Resource Reservation Protocol (RSVP) has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and link to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives.
リソース予約プロトコル（RSVP）は、マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）ネットワークのトラフィックエンジニアリング（TE）をサポートするために拡張されています。このプロトコルにより、シグナリング交換は、ノードを通過してリンクするラベルスイッチパス（LSP）を確立し、エンドツーエンドのデータパスを提供します。各ノードには、信号メッセージが処理されるため、「クロスコネクト」情報がプログラムされています。クロス接続情報は、ノードに受信したデータを転送する方法を指示します。
End points of an LSP need to know when it is safe to start sending data so that it is not misdelivered, and so that safety issues specific to optical data-plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages.
LSPのエンドポイントは、データの送信を開始して誤解を招かないようにし、光学データプレーンテクノロジーに固有の安全性の問題が満たされるようにする必要があります。同様に、LSPのパスに沿ったすべてのラベルスイッチングルーターは、コントロールプレーンメッセージの送信と受信と比較してデータプレーンをいつプログラムするかを知る必要があります。
This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices.
このドキュメントは、一方向および双方向LSPの両方について、LSPに沿ったクロスコネクトのプログラミングに関連するRSVP-TEプロトコル交換を明確にし、要約します。このドキュメントでは、新しい手順やプロトコル拡張機能を定義せず、規範的な参照を提供するドキュメントを完全に扱います。このドキュメントに記載されている明確化は、MPLS-TEおよびGMPLSデバイスのLSP確立パフォーマンスの数値を解釈するのに役立つ場合もあります。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6383.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6383で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
The Resource Reservation Protocol (RSVP) [RFC2205] has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks [RFC3209] [RFC3473]. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and links to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives. In some technologies this requires configuration of physical devices, while in others it may involve the exchange of commands between different components of the node. The nature of a cross-connect is described further in Section 1.1.1.
リソース予約プロトコル（RSVP）[RFC2205]は、マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）ネットワーク[RFC3209] [RFC3473]のトラフィックエンジニアリング（TE）をサポートするために拡張されました。このプロトコルにより、シグナリング交換は、ノードとリンクをトラバースするラベルスイッチパス（LSP）を確立して、エンドツーエンドのデータパスを提供します。各ノードには、信号メッセージが処理されるため、「クロスコネクト」情報がプログラムされています。クロス接続情報は、ノードに受信したデータを転送する方法を指示します。一部のテクノロジーでは、これには物理デバイスの構成が必要ですが、他のテクノロジーでは、ノードの異なるコンポーネント間のコマンドの交換が含まれる場合があります。クロスコネクトの性質については、セクション1.1.1でさらに説明します。
End points of an LSP need to know when it is safe to start sending data. In this context "safe" has two meanings. The first issue is that the sender needs to know that the data path has been fully established, setting up the cross-connects and removing any old, incorrect forwarding instructions, so that data will be delivered to the intended destination. The other meaning of "safe" is that in optical technologies, lasers must not be turned on until the correct cross-connects have been put in place to ensure that service personnel are not put at risk.
LSPのエンドポイントは、データの送信を開始することがいつ安全かを知る必要があります。この文脈では、「安全」には2つの意味があります。最初の問題は、送信者がデータパスが完全に確立されており、クロスコネクトを設定し、古い誤った転送命令を削除して、データが意図した宛先に配信されることを知る必要があることです。「安全」のもう1つの意味は、光学技術では、サービス担当者が危険にさらされないようにするために正しいクロスコネクトが導入されるまでレーザーをオンにしてはならないということです。
Similarly, all Label Switching Routers (LSRs) along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages.
同様に、LSPの経路に沿ったすべてのラベルスイッチングルーター（LSR）は、コントロールプレーンメッセージの送信と受信と比較してデータプレーンをいつプログラムするかを知る必要があります。
This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. Bidirectional LSPs, it should be noted, are supported only in GMPLS. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references.
このドキュメントは、一方向および双方向LSPの両方について、LSPに沿ったクロスコネクトのプログラミングに関連するRSVP-TEプロトコル交換を明確にし、要約します。双方向LSPは、GMPLSでのみサポートされています。このドキュメントでは、新しい手順やプロトコル拡張機能を定義せず、規範的な参照を提供するドキュメントを完全に扱います。
The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices. For example, the dynamic provisioning performance metrics set out in [RFC5814] need to be understood in the context of LSP setup times and not in terms of control message exchange times that are actually only a component of the whole LSP establishment process.
このドキュメントに記載されている明確化は、MPLS-TEおよびGMPLSデバイスのLSP確立パフォーマンスの数値を解釈するのに役立つ場合もあります。たとえば、[RFC5814]に設定されている動的プロビジョニングパフォーマンスメトリックは、LSPセットアップ時間のコンテキストで、実際にLSP確立プロセス全体のコンポーネントであるコントロールメッセージ交換時間の観点では理解する必要があります。
Implementations could significantly benefit from this document definitively identifying any LSR to forward the Path or Resv message [RFC3473] before programming its cross-connect, thereby exploiting pipelining (i.e., doing one action in the background while another is progressing) to try to minimize the total time to set up the LSP. However, while this document gives advice and identifies the issues to be considered, it is not possible to make definitive statements about how much pipelining is safe, since a node cannot "know" much without first probing the network (for example, with protocol extensions) which would defeat the point of pipelining. Due to the number of variables introduced by path length, and other node behavior, ingress might be limited to a very pessimistic view for safety. Furthermore, it seems unlikely that an implementation would necessarily give a full and frank description of how long it takes to program and stabilize its cross-connects. Nevertheless, this document identifies the issues and opportunities for pipelining in GMPLS systems.
実装は、このドキュメントがクロスコネクトをプログラミングする前にパスまたはRESVメッセージ[RFC3473]を転送するためにLSRを明確に識別するために大幅に利益を得ることができ、それによってパイプラインを悪用します（つまり、バックグラウンドで1つのアクションを実行しながら、別のアクションが進行しています）。 LSPをセットアップするための合計時間。ただし、このドキュメントはアドバイスを提供し、考慮すべき問題を特定しますが、ノードは最初にネットワークをプローブすることなく（たとえば、プロトコル拡張機能を使用することなく多くのことを「知る」ことができないため、パイプラインがどれだけ安全であるかについて決定的なステートメントを作成することはできません。 ）これはパイプラインのポイントを打ち負かすでしょう。パスの長さによって導入された変数の数とその他のノードの動作により、イングレスは安全性の非常に悲観的な見方に限定される場合があります。さらに、このクロスコネクトをプログラムして安定させるのにどれくらいの時間がかかるかについて、実装が必然的に完全に率直な説明を与える可能性は低いようです。それにもかかわらず、このドキュメントは、GMPLSシステムでのパイプラインの問題と機会を特定しています。
It is assumed that the reader is familiar with the basic message flows of RSVP-TE as used in MPLS-TE and GMPLS. Refer to [RFC2205], [RFC3209], [RFC3471], and [RFC3473] for more details.
読者は、MPLS-TEおよびGMPLSで使用されるRSVP-TEの基本的なメッセージフローに精通していると想定されています。詳細については、[RFC2205]、[RFC3209]、[RFC3471]、および[RFC3473]を参照してください。
In the context of this document, the concept of a "cross-connection" should be taken to imply the data forwarding instructions installed (that is, "programmed") at a network node (or "switch").
このドキュメントのコンテキストでは、「クロス接続」の概念を使用して、ネットワークノード（または「スイッチ」）にインストールされたデータ転送命令（つまり「プログラム」）を暗示する必要があります。
In packet MPLS networks, this is often referred to as the Incoming Label Map (ILM) and Next Hop Label Forwarding Entry (NHLFE) [RFC3031] which are sometimes considered together as entries in the Label Forwarding Information Base (LFIB) [RFC4221]. Where there is
パケットMPLSネットワークでは、これは多くの場合、受信ラベルマップ（ILM）および次のホップラベル転送エントリ（NHLFE）[RFC3031]と呼ばれます。どこにあり
admission control and resource reservation associated with the data forwarding path (such as the allocation of data buffers) [RFC3209], this can be treated as part of the cross-connect programming process since the LSP will not be available to forward data in the manner agreed to during the signaling protocol exchange until the resources are correctly allocated and reserved.
データ転送パス（データバッファの割り当てなど）に関連する入場制御とリソースの予約[RFC3209]、これは、LSPが方法でフォワードデータを使用できないため、クロスコネクトプログラミングプロセスの一部として扱うことができます。リソースが正しく割り当てられ、予約されるまで、シグナリングプロトコル交換中に合意しました。
In non-packet networks (such as time-division multiplexing, or optical switching networks), the cross-connect concept may be an electronic cross-connect array or a transparent optical device (such as a microelectromechanical system (MEMS)). In all cases, however, the concept applies to the instructions that are programmed into the forwarding plane (that is, the data plane) so that incoming data for the LSP on one port can be correctly handled and forwarded out of another port.
非パケットネットワーク（時間分割マルチプレックスや光スイッチングネットワークなど）では、クロスコネクトコンセプトは、電子クロスコネクトアレイまたは透明な光学デバイス（マイクロエレクトロメカニカルシステム（MEMS）など）である場合があります。ただし、すべての場合において、コンセプトは、あるポートのLSPの着信データを別のポートから正しく処理して転送できるように、転送面（つまりデータプレーン）にプログラムされた命令に適用されます。
[RFC3209] describes the RSVP-TE signaling and processing for MPLS-TE packet-based networks. LSPs in these networks are unidirectional by definition (there are no bidirectional capabilities in [RFC3209]).
[RFC3209]は、MPLS-TEパケットベースのネットワークのRSVP-TEシグナル伝達と処理について説明しています。これらのネットワークのLSPは、定義により一方向です（[RFC3209]には双方向の能力はありません）。
Section 4.1.1.1 of [RFC3209] describes a node's process prior to sending a Resv message to its upstream neighbor.
[RFC3209]のセクション4.1.1.1では、上流の隣人にRESVメッセージを送信する前のノードのプロセスについて説明します。
The node then sends the new LABEL object as part of the Resv message to the previous hop. The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message.
次に、ノードは、RESVメッセージの一部として新しいラベルオブジェクトを前のホップに送信します。ノードは、RESVメッセージを送信する前に、割り当てられたラベルを運ぶパケットを転送する準備をする必要があります。
This means that the cross-connect should be in place to support traffic that may arrive at the node before the node sends the Resv. This is clearly advisable because the upstream LSRs might otherwise complete their cross-connections more rapidly and encourage the ingress to start transmitting data with the risk that the node that sent the Resv "early" would be unable to forward the data it received and would be forced to drop it, or might accidentally send it along the wrong LSP because of stale cross-connect information.
これは、ノードがRESVを送信する前にノードに到達する可能性のあるトラフィックをサポートするために、クロスコネクトを整える必要があることを意味します。これは、上流のLSRがクロス接続をより迅速に完了し、侵入が「早期」に送信したノードが受信したデータを転送できず、それをドロップすることを余儀なくされたか、古いクロス接続情報のために間違ったLSPに沿って誤って送信する可能性があります。
The use of "SHOULD" [RFC2119] in this text indicates that an implementation could be constructed that sends a Resv before it is ready to receive and forward data. This might be done simply because the internal construction of the node means that the control-plane components cannot easily tell when the cross-connection has been installed. Alternatively, it might arise because the implementation is aware that it will be slow and does not wish to hold up the establishment of the LSP. In this latter case, the implementation is choosing to pipeline the cross-connect programming with the protocol
このテキストで「seff」[RFC2119]を使用することは、データを受信および転送する前にRESVを送信する実装を構築できることを示しています。これは、ノードの内部構造がコントロールプレーンコンポーネントがクロス接続がいつインストールされているかを簡単に判断できないことを意味するという理由だけで実行される可能性があります。あるいは、実装が遅くなり、LSPの確立を維持することを望んでいないことを認識しているため、発生する可能性があります。この後者の場合、実装はプロトコルを使用したクロスコネクトプログラミングをパイプラインすることを選択しています
exchange taking a gamble that there will be other upstream LSRs that may also take some time to process, and it will in any case be some time before the ingress actually starts to send data. It should be noted that, as well as the risks described in the previous paragraph, a node that behaves like this must include a mechanism to report a failure to chase the Resv message (using a PathErr) in the event that the pipelined cross-connect processing fails.
交換して、他の上流のLSRがあり、処理に時間がかかる可能性があります。いずれにせよ、イングレスが実際にデータの送信を開始するまでにはしばらく時間がかかります。前の段落に記載されているリスクと同様に、このように動作するノードには、Pipelined Cross-Connectが場合にRESVメッセージを追跡できないことを報告するメカニズムを含める必要があることに注意する必要があります。処理は失敗します。
GMPLS [RFC3945] extends RSVP-TE signaling for use in networks of different technologies [RFC3471] [RFC3473]. This means that RSVP-TE signaling may be used in MPLS packet switching networks, as well as layer two networks (Ethernet, Frame Relay, ATM), time-division multiplexing networks (Time Division Multiplexer (TDM), i.e., Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH)), Wavelength Division Multiplexing (WDM) networks, and fiber switched network.
GMPLS [RFC3945]は、異なる技術のネットワークで使用するためにRSVP-TEシグナル伝達を拡張します[RFC3471] [RFC3473]。これは、RSVP-TEシグナル伝達がMPLSパケットスイッチングネットワークで使用される可能性があることを意味します。また、2つのネットワーク（イーサネット、フレームリレー、ATM）、タイムディビジョンマルチプレックスネットワーク（タイムディビジョンマルチプレクサー（TDM）、すなわち同期光ネットワーク（タイムディビジョンマルチプレクサー（TDM））で使用できることを意味します。SONET）および同期デジタル階層（SDH））、波長分割多重化（WDM）ネットワーク、ファイバースイッチネットワーク。
The introduction of these other technologies, specifically the optical technologies, brings about the second definition of the "safe" commencement of data transmission as described in Section 1. That is, there is a physical safety issue that means that the lasers should not be enabled until the cross-connects are correctly in place.
これらの他のテクノロジー、特に光学技術の導入は、セクション1で説明されているように、データ送信の「安全な」開始の2番目の定義をもたらします。つまり、レーザーを有効にすべきではないことを意味する物理的な安全性の問題があります。クロスコネクトが正しく配置されるまで。
GMPLS supports unidirectional and bidirectional LSPs. These are split into separate sections for discussion. The processing rules are inherited from [RFC3209] unless they are specifically modified by [RFC3471] and [RFC3473].
GMPLSは、単方向および双方向LSPをサポートします。これらは議論のために別々のセクションに分割されます。処理ルールは、[RFC3471]および[RFC3473]によって特異的に変更されない限り、[RFC3209]から継承されます。
Unidirectional LSP processing would be the same as that described in Section 2 except for the use of the Suggested_Label object defined in [RFC3473]. This object allows an upstream LSR to 'suggest' to its downstream neighbor the label that should be used for forward-direction data by including the object on a Path message. The purpose of this object is to help the downstream LSR in its choice of label, but it also makes it possible for the upstream LSR to 'pipeline' programming its cross-connect with the RSVP-TE signaling exchanges. That means that the cross-connect might be in place before the signaling has completed (i.e., before a Resv message carrying a Label object has been received at the upstream LSR).
単方向LSP処理は、[RFC3473]で定義されている提案された_Labelオブジェクトの使用を除き、セクション2で説明したものと同じです。このオブジェクトにより、上流のLSRは、パスメッセージにオブジェクトを含めることにより、順方向データに使用する必要があるラベルを下流の隣のラベルに「提案」できます。このオブジェクトの目的は、下流のLSRがラベルの選択を支援することですが、上流のLSRがRSVP-TEシグナリング交換との相互接続を「パイプライン」プログラミングすることも可能になります。つまり、信号が完了する前にクロスコネクトが整っている可能性があります（つまり、上流のLSRでラベルオブジェクトを運ぶRESVメッセージが受信される前）。
We need to know when it is safe to start sending data. There are three sources of information.
データの送信を開始することがいつ安全かを知る必要があります。3つの情報源があります。
- Section 3.4 of [RFC3471] states:
- [RFC3471]のセクション3.4は次のとおりです。
In particular, an ingress node should not transmit data traffic on a suggested label until the downstream node passes a label upstream.
特に、イングレスノードは、下流ノードが上流のラベルを通過するまで、提案されたラベルにデータトラフィックを送信してはなりません。
The implication here is that an ingress node may (safely) start to transmit data when it receives a label in a Resv message.
ここでの意味は、侵入ノードがRESVメッセージでラベルを受信すると（安全に）データの送信を開始する可能性があることです。
- Section 2.5 of [RFC3473] states:
- [RFC3473]のセクション2.5は次のとおりです。
Furthermore, an ingress node SHOULD NOT transmit data traffic using a suggested label until the downstream node passes a corresponding label upstream.
さらに、イングレスノードは、下流ノードが対応するラベルの上流に渡されるまで、提案されたラベルを使用してデータトラフィックを送信してはなりません。
This is a confirmation of the first source.
これは、最初のソースの確認です。
- Section 4.1.1.1 of [RFC3209] states:
- [RFC3209]のセクション4.1.1.1は次のとおりです。
The node then sends the new LABEL object as part of the Resv message to the previous hop. The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message.
次に、ノードは、RESVメッセージの一部として新しいラベルオブジェクトを前のホップに送信します。ノードは、RESVメッセージを送信する前に、割り当てられたラベルを運ぶパケットを転送する準備をする必要があります。
In this text, the word "prior" is very important. It means that the cross-connect must be in place for forward traffic before the Resv is sent. In other words, each of the transit nodes and the egress node must finish making their cross-connects before they send the Resv message to their upstream neighbors.
このテキストでは、「前」という言葉が非常に重要です。これは、RESVが送信される前に、クロスコネクトが順方向トラフィックのために配置されている必要があることを意味します。言い換えれば、各トランジットノードと出力ノードは、上流の隣人にRESVメッセージを送信する前に、クロスコネクトの作成を終了する必要があります。
Thus, as in Section 2, we can deduce that the ingress must not start to transmit traffic until it has both received a Resv and has programmed its own cross-connect.
したがって、セクション2のように、侵入がRESVを受信し、独自のクロスコネクトをプログラムするまでトラフィックを送信し始めてはならないと推測できます。
A bidirectional LSP is established with one signaling exchange of a Path message from ingress to egress, and a Resv from egress to ingress. The LSP itself is comprised of two sets of forwarding state, one providing a path from the ingress to the egress (the forwards data path), and one from the egress to the ingress (the reverse data path).
双方向LSPは、イングレスから出口へのパスメッセージの1つのシグナル交換と、出口からイングレスへのRESVで確立されます。LSP自体は、侵入から出口（フォワードデータパス）へのパスを提供する2セットの転送状態で構成されています。
The processing for the forwards direction data path is exactly as described for a unidirectional LSP in Section 3.1.
フォワード方向データパスの処理は、セクション3.1の単方向LSPの記述とまったく通りです。
For the reverse direction data flow, an Upstream_Label object is carried in the Path message from each LSR to its downstream neighbor. The Upstream_Label object tells the downstream LSR which label to use for data being sent to the upstream LSR (that is, reverse direction data). The use of the label is confirmed by the downstream LSR when it sends a Resv message. Note that there is no explicit confirmation of the label in the Resv message, but if the label was not acceptable to the downstream LSR, it would return a PathErr message instead.
逆方向のデータフローの場合、upstream_labelオブジェクトは、各LSRから下流の隣人へのパスメッセージに掲載されます。upstream_labelオブジェクトは、下流のLSRに、上流のLSRに送信されるデータに使用するラベル（つまり、逆方向データ）を指示します。ラベルの使用は、RESVメッセージを送信するときに下流のLSRによって確認されます。RESVメッセージにラベルの明示的な確認はありませんが、ラベルが下流のLSRに受け入れられない場合、代わりにPatherRメッセージを返します。
The upstream LSR must decide when to send the Path message relative to when it programs its cross-connect. That is:
アップストリームLSRは、クロスコネクトをプログラムするときと比較してパスメッセージをいつ送信するかを決定する必要があります。あれは：
- Should it program the cross-connect before it sends the Path message;
- パスメッセージを送信する前に、クロスコネクトをプログラムする必要があります。
- Can it overlap the programming with the exchange of messages; or
- プログラミングとメッセージの交換と重複することはできますか。また
- Must it wait until it receives a Resv from its downstream neighbor?
- 下流の隣人からRESVを受け取るまで待つ必要がありますか？
The defining reference is Section 3.1 of [RFC3473]:
定義する参照は[RFC3473]のセクション3.1です。
The Upstream_Label object MUST indicate a label that is valid for forwarding at the time the Path message is sent.
upstream_labelオブジェクトは、パスメッセージが送信された時点で転送に有効なラベルを示す必要があります。
In this text, "valid for forwarding" should be taken to mean that it is safe for the LSR that sends the Path message to receive data, and that the LSR will forward data correctly. The text does not mean that the label is "acceptable for use" (i.e., the label is available to be cross-connected).
このテキストでは、「転送に有効」は、パスメッセージを送信するLSRがデータを受信することが安全であり、LSRがデータを正しく転送することを意味することを意味する必要があります。テキストは、ラベルが「使用に受け入れられる」ことを意味するものではありません（つまり、ラベルは相互接続できます）。
This point is clarified later in Section 3.1 of [RFC3473]:
この点は、[RFC3473]のセクション3.1で後半に明確にされています。
Terminator nodes process Path messages as usual, with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator.
ターミネーターノード上流ラベルをすぐに使用して、LSPに関連するLSPに関連するデータトラフィックをイニシエーターに向けて輸送できることを除いて、ターミネーターノードは通常どおりPATHメッセージを処理します。
This is a clear statement that when a Path message has been fully processed by an egress node, it is completely safe to transmit data toward the ingress (i.e., reverse direction data).
これは、パスメッセージが出口ノードによって完全に処理された場合、データを侵入に向けて送信することが完全に安全であるという明確な声明です（つまり、逆方向データ）。
From this we can deduce several things:
これから私たちはいくつかのことを推測することができます：
- An LSR must not wait to receive a Resv message before it programs the cross-connect for the reverse direction data. It must be ready to receive data from the moment that the egress completes processing the Path message that it receives (i.e., before it sends a Resv back upstream).
- LSRは、逆方向データのクロスコネクトをプログラムする前に、RESVメッセージを受信するのを待ってはなりません。出力が受信するパスメッセージの処理を完了した瞬間からデータを受信する準備ができている必要があります（つまり、RESVを上流に戻す前に）。
- An LSR may expect to start receiving reverse direction data as soon as it sends a Path message for a bidirectional LSP.
- LSRは、双方向LSPのパスメッセージを送信するとすぐに逆方向データの受信を開始することを期待する場合があります。
- An LSR may make some assumptions about the time lag between sending a Path message and the message reaching and being processed by the egress. It may take advantage of this time lag to pipeline programming the cross-connect.
- LSRは、パスメッセージの送信とメッセージが到達することと出口によって処理されるまでの時間遅れについていくつかの仮定を行う場合があります。このタイムラグを利用して、クロスコネクトをプログラミングします。
The ResvConf message is used in standard RSVP [RFC2205] to let the ingress confirm to the egress that the Resv has been successfully received, and what bandwidth has been reserved. In RSVP-TE [RFC3209] and GMPLS [RFC3473], it is not expected that bandwidth will be modified along the path of the LSP, so the purpose of the ResvConf is reduced to a confirmation that the LSP has been successfully established.
RESVCONFメッセージは、標準のRSVP [RFC2205]で使用されて、RESVが正常に受信されたこと、およびどの帯域幅が予約されているかを出口に確認できるようにします。RSVP-TE [RFC3209]およびGMPLS [RFC3473]では、LSPの経路に沿って帯域幅が変更されることは予想されないため、RESVCONFの目的はLSPが正常に確立されたことの確認に還元されます。
The egress may request that a ResvConf be sent by including a Resv_Confirm object in the Resv message that it sends. When the ingress receives the Resv message and sees the Resv_Confirm object, it can respond with a ResvConf message.
出口は、送信するRESVメッセージにRESV_CONFIRMオブジェクトを含めることにより、RESVCONFを送信することを要求する場合があります。IngressがRESVメッセージを受信し、RESV_CONFIRMオブジェクトを表示すると、RESVCONFメッセージで応答できます。
It should be clear that this mechanism might provide a doubly secure way for the egress to ensure that the reverse direction data path is safely in place before transmitting data. That is, if the egress waits until it receives a ResvConf message, it can be sure that the whole LSP is in place.
このメカニズムは、出口がデータを送信する前に逆方向データパスが安全に所定の位置にあることを保証するための二重安全な方法を提供する可能性があることは明らかです。つまり、出力がRESVCONFメッセージを受信するまで待機する場合、LSP全体が整っていることを確認できます。
However, this mechanism is excessive given the definitions presented in Section 3.2.2, and would delay LSP setup by one end-to-end message propagation cycle. It should be noted as well that the generation and of the ResvConf message is not guaranteed. Furthermore, many (if not most) GMPLS implementations neither request nor send ResvConf messages. Therefore, egress reliance on the receipt of a ResvConf as a way of knowing that it is safe to start transmitting reverse direction data is not recommended.
ただし、セクション3.2.2に示されている定義を考えると、このメカニズムは過度にあり、1つのエンドツーエンドメッセージ伝播サイクルごとにLSPセットアップを遅らせます。生成とRESVCONFメッセージの生成が保証されていないことにも注意する必要があります。さらに、多くの（ほとんどではないにしても）GMPLS実装は、ResvConfメッセージを要求したり送信したりしません。したがって、逆方向データの送信を開始することが安全であることを知る方法として、ResvConfの受領に依存することは推奨されません。
GMPLS offers an additional tool for ensuring safety of the LSP. The Administrative Status information is defined in Section 8 of [RFC3471] and is carried in the Admin_Status Object defined in Section 7 of [RFC3473].
GMPLSは、LSPの安全性を確保するための追加ツールを提供します。管理ステータス情報は[RFC3471]のセクション8で定義されており、[RFC3473]のセクション7で定義されているadmin_statusオブジェクトに掲載されています。
This object allows an ingress to set up an LSP in "Administratively Down" state. This state means that [RFC3471]:
このオブジェクトにより、イングレスは「管理上」状態にLSPを設定できます。この状態は、[RFC3471]を意味します。
... the local actions related to the "administratively down" state should be taken.
...「管理上」状態に関連するローカルアクションをとる必要があります。
In this state, it is assumed that the LSP exists (i.e., the cross-connects are all in place), but no data is transmitted (i.e., in optical systems, the lasers are off).
この状態では、LSPが存在すると想定されています（つまり、クロスコネクトはすべて整っています）が、データは送信されません（つまり、光学システムでは、レーザーがオフになっています）。
Additionally, the Admin_Status object allows the LSP to be put into "Testing" state. This state means ([RFC3471]) that:
さらに、Admin_Statusオブジェクトにより、LSPを「テスト」状態に入れることができます。この状態は（[rfc3471]）を意味します。
... the local actions related to the "testing" mode should be taken.
...「テスト」モードに関連するローカルアクションを実行する必要があります。
This state allows the connectivity of the LSP to be tested without actually exchanging user data. For example, in an optical system, it would be possible to run a data continuity test (using some external coordination of errors). In a packet network, a connection verification exchange (such as the in-band Virtual Circuit Connectivity Verification described in Section 5.1.1 of [RFC5085]) could be used. Once connectivity has been verified, the LSP could be put into active mode and the exchange of user data could commence.
この状態により、実際にユーザーデータを交換することなく、LSPの接続をテストすることができます。たとえば、光学システムでは、データ連続性テストを実行することが可能です（エラーの外部調整を使用）。パケットネットワークでは、接続検証交換（[RFC5085]のセクション5.1.1で説明されているインバンド仮想回路接続検証など）を使用できます。接続性が検証されると、LSPをアクティブモードに配置し、ユーザーデータの交換が開始される可能性があります。
These processes may be considered particularly important in systems where the control-plane processors are physically distinct from the data-plane cross-connects (for example, where there is a communication protocol operating between the control-plane processor and the data-plane switch) in which case the successful completion of control-plane signaling cannot necessarily be taken as evidence of correct data-plane programming.
これらのプロセスは、コントロールプレーンプロセッサがデータプレーンのクロスコネクトと物理的に異なるシステムで特に重要であると考えられます（たとえば、コントロールプレーンプロセッサとデータプレーンスイッチの間で動作する通信プロトコルがある場合）その場合、コントロールプレーンシグナル伝達の正常な完了を必ずしも正しいデータプレーンプログラミングの証拠と見なすことはできません。
The ability of LSRs to handle and propagate control-plane messages and to program cross-connects varies considerably from device to device according to switching technology, control-plane connectivity, and implementation. These factors influence how quickly an LSP can be established.
LSRが制御面のメッセージを処理および伝播し、プログラムをプログラムする機能は、スイッチングテクノロジー、コントロールプレーン接続、および実装に応じて、デバイスごとに大幅に異なります。これらの要因は、LSPの確立の速さに影響します。
Different applications have different requirements for the speed of setup of LSPs, and this may be particularly important in recovery scenarios. It is important for service providers considering the deployment of MPLS-TE or GMPLS equipment to have a good benchmark for the performance of the equipment. Similarly, it is important for equipment vendors to be compared on a level playing field.
さまざまなアプリケーションには、LSPのセットアップ速度に異なる要件があり、これは回復シナリオで特に重要な場合があります。MPLS-TEまたはGMPLS機器の展開を考慮して、機器のパフォーマンスのための優れたベンチマークを持つサービスプロバイダーにとって重要です。同様に、機器ベンダーが平等な競技場で比較されることが重要です。
In order to provide a basis for comparison, [RFC5814] defines a series of performance metrics to evaluate dynamic LSP provisioning performance in MPLS-TE/GMPLS networks. Any use of such metrics must be careful to understand what is being measured, bearing in mind that it is not enough to know that the control-plane message has been processed and forwarded: the cross-connect must be put in place before the LSP can be used. Thus, care must be taken to ensure that devices are correctly conforming to the procedures clarified in Section 2 of this document, and not simply forwarding control-plane messages with the intent to program the cross-connects in the background.
比較の基礎を提供するために、[RFC5814]は、MPLS-TE/GMPLSネットワークの動的なLSPプロビジョニングパフォーマンスを評価する一連のパフォーマンスメトリックを定義します。このようなメトリックの使用は、測定されているものを理解するために注意する必要があります。コントロールプレーンメッセージが処理され、転送されていることを知るだけでは十分ではないことに留意してください。利用される。したがって、このドキュメントのセクション2で明確にされた手順にデバイスが正しく準拠していることを確認するために注意する必要があり、バックグラウンドでクロスコネクトをプログラムする意図でコントロールプレーンメッセージを単純に転送するだけではありません。
This document does not define any network behavior and does not introduce or seek to solve any security issues.
このドキュメントは、ネットワークの動作を定義せず、セキュリティの問題を導入または解決しようとしません。
It may be noted that a clear understanding of when to start sending data may reduce the risk of data being accidentally delivered to the wrong place or individuals being hurt.
データの送信を開始するタイミングを明確に理解することで、データが誤って間違った場所に配信されるリスクや個人が傷つけられているリスクが減少する可能性があることに注意することができます。
Thanks to Weiqiang Sun, Olufemi Komolafe, Daniel King, and Stewart Bryant for their review and comments.
Weiqiang Sun、Olufemi Komolafe、Daniel King、Stewart Bryantのレビューとコメントに感謝します。
[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月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[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 TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[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月。
[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", RFC 4221, November 2005.
[RFC4221] Nadeau、T.、Srinivasan、C。、およびA. Farrel、「Multiprotocol Label Switching（MPLS）管理概要」、RFC 4221、2005年11月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085] Nadeau、T.、ed。、およびC. Pignataro、ed。、「Pseudowire Virtual Curned Connectivity Verification（VCCV）：Pseudowiresの制御チャネル」、RFC 5085、2007年12月。
[RFC5814] Sun, W., Ed., and G. Zhang, Ed., "Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks", RFC 5814, March 2010.
[RFC5814] Sun、W.、ed。、およびG. Zhang、ed。、「一般化されたMPLSネットワークにおけるラベルスイッチドパス（LSP）動的プロビジョニングパフォーマンスメトリック」、RFC 5814、2010年3月。
Authors' Addresses
著者のアドレス
Kohei Shiomoto NTT Service Integration Laboratories 3-9-11 Midori Musashino, Tokyo 180-8585 Japan Phone: +81 422 59 4402 EMail: shiomoto.kohei@lab.ntt.co.jp
Kohei Shiomoto NTT Service Integration Laboratories 3-9-11 Midori Musashino、Tokyo 180-8585日本電話：81 422 59 4402メール：shiomoto.kohei@lab.ntt.co.jp
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk