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
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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）でのトラフィックエンジニアリング（TE）と一般化MPLS（GMPLS）ネットワーク[RFC3209] [RFC3473]をサポートするように拡張されました。プロトコルは、エンド・ツー・エンドのデータパスを提供するために、ラベルスイッチを確立するパス（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のエンドポイントは、データの送信を開始するために安全であるとき知っておく必要があります。この文脈では、「安全」二つの意味があります。最初の問題は、送信者は、データが意図した宛先に配信されるように、クロスコネクトを設定し、任意の古い、不正確な転送命令を削除し、データパスが完全に確立されたことを知っている必要があるということです。 「安全」の他の意味は、正しいクロスコネクトは、そのサービスの担当者が危険にさらされていないことを確認するための場所に置かれているまで、光学技術で、レーザーがオンになってはならないことです。
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.
実装が著しく最小化しようとする（別が進行している間、バックグラウンド内の1つのアクションを行う、すなわち、）それによってパイプラインを利用する場合、そのクロスコネクトをプログラムする前に、パスまたはResvメッセージ[RFC3473]を転送する任意のLSRを識別決定的本文書から利益を得ることができます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）時にはラベル転送情報ベース（LFIB）[RFC4221]のエントリとして一緒に考えられている[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が、そうでない場合より迅速にそれらの交差接続を完了し、「早期」のResvを送信したノードは、それが受信したデータを転送することができないであろうとだろうとリスクとのデータの送信を開始するために侵入するのを促す可能性があるため、これは明らかに賢明ですそれをドロップすることを強制、または誤っているため、古いクロスコネクト情報の間違った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 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.
このテキストでは「すべきである」[RFC2119]を使用すると、実装は、データを受信し、前進する準備ができている前のResvを送るように構築することができることを示しています。ノードの内部構造は、クロスコネクトがインストールされているときに、制御プレーンのコンポーネントを簡単に伝えることができないことを意味するので、これは単純に行われる可能性があります。実装は、それが遅くなりますとLSPの確立を保持したくないことを認識しているので、また、それが発生する可能性があります。後者の場合、実装は、パイプラインにプロトコル交換は、プロセスに時間がかかる場合があり、他の上流のLSRがあることを賭けを取るとクロスコネクトプログラミングを選択することであり、いかなる場合においても前にいくつかの時間になりますイングレスは、実際にデータを送信するために開始します。なお、このように振る舞うノードがパイプラインクロスコネクトした場合には（のPathErrを使用して）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）、同期光ネットワーク（ 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]で定義されSuggested_Labelオブジェクトの使用を除いて、セクション2で説明したものと同じです。このオブジェクトは、その下流隣接Pathメッセージにオブジェクトを含めることにより、順方向データのために使用されるべきラベルに「示唆」に上流LSRを可能にします。このオブジェクトの目的は、ラベルのその選択の下流LSRを支援することですが、それはまた、RSVP-TEのシグナリング交換でクロスコネクトプログラミングの「パイプライン」に上流のLSRのためにそれを可能にします。すなわち、シグナリングが完了する前にクロスコネクトが所定の位置にあるかもしれないことを意味する（すなわち、ラベルオブジェクトを運ぶResvメッセージをアップストリームLSRで受信される前）。
We need to know when it is safe to start sending data. There are three sources of information.
私たちは、データの送信を開始するために安全であるとき知っておく必要があります。 、三種類の情報があります。
- 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の出口に入口からPathメッセージ、および入力へ出力からのResvのシグナリング交換を用いて確立されます。 LSP自体は入口（逆方向データ・パス）の状態、出力（転送データパス）に進入からのパスを提供する1つ、及び出口からの1つを転送する二組で構成されています。
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からPathメッセージで運ばれます。 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は、そのクロスコネクト時のプログラムにPathメッセージの相対を送信するタイミングを決定しなければなりません。あれは：
- Should it program the cross-connect before it sends the Path message;
- それはPathメッセージを送信する前にクロスコネクトプログラムべきです。
- 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オブジェクトは、Pathメッセージが送信された時点で転送するための有効なラベルを指定する必要があります。
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).
このテキストでは、「転送するための有効な」それがデータを受信するためにPathメッセージを送る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に関連するデータトラフィックを転送するために使用することができることを除いて、通常どおり処理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).
これは、Pathメッセージが完全に出口ノードによって処理された場合、入口（即ち、逆方向データ）に向けてデータを送信するために完全に安全であることが明確な声明です。
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を返送する前に）を受信Pathメッセージを処理完了した時点からのデータを受信する準備ができなければなりません。
- 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はPathメッセージを送信すると、メッセージが到達し、出口によって処理されるまでのタイムラグについていくつかの仮定を行うことができます。これは、クロスコネクトプログラミングパイプラインに、このタイムラグを利用することができます。
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メッセージが浸入がしたResvが正常に受信された、と何の帯域幅が予約されていることを出口に確認できるように、標準のRSVP [RFC2205]で使用されています。 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.
出口はResvConfは、それが送信ResvメッセージにResv_Confirmオブジェクトを含むによって送信されることを要求してもよいです。イングレスは、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プロビジョニング性能を評価するために定義します。そのようなメトリックの使用は、コントロールプレーンのメッセージが処理され、転送されたことを知っているだけでは十分ではないことを念頭に、測定されているかを理解するように注意する必要があります：クロスコネクト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日、Olufemi Komolafe、ダニエル・キング、そしてスチュワートブライアントに感謝します。
[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月。
[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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ"、RFC 3945、2004年10月。
[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月。
[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", RFC 4221, November 2005.
[RFC4221]ナドー、T.、スリニバサン、C.、およびA.ファレルは、RFC 4221、2005年11月、 "マルチプロトコルラベルは（MPLS）管理の概要を切り替えます"。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]ナドー、T.、エド、およびC. Pignataro、エド、 "Pseudowireの仮想回線接続性検証（VCCV）：スードワイヤ用制御チャネル"。。、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]日、W.、エド。、およびG.張、エド。、 "ラベルスイッチパス一般化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
こへい しおもと んっｔ せｒゔぃせ いんてｇらちおん ぁぼらとりえｓ ３ー９ー１１ みどり むさしの、 ときょ １８０ー８５８５ じゃぱん Ｐほね： ＋８１ ４２２ ５９ ４４０２ えまいｌ： しおもと。こへい＠ぁｂ。んっｔ。こ。ｊｐ
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk