Network Working Group H. Khosravi
Request for Comments: 3604 Intel
Category: Informational G. Kullgren
S. Shew
Nortel Networks
J. Sadler
Tellabs
A. Watanabe
NTT
October 2003
Requirements for Adding Optical Support to
the General Switch Management Protocol version 3 (GSMPv3)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification.
このメモは一般的なスイッチ管理プロトコル（GSMP）に光スイッチングのサポートを追加するための要件を提供します。また、明確化が含まれているとGSMPv3仕様への変更を提案しました。
Conventions used in this document
この文書で使用されている表記
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 BCP 14, RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
This document details the changes to GSMP necessary for the support of optical (non-transparent and all optical), SONET/SDH, and spatial switching of IP packets, Layer 2 (L2) frames and TDM data. When implemented, GSMP controllers will then be able to control: photonic cross-connects (optical-optical), transparent optical cross connects (optical-electrical-optical, frame independent), opaque cross connects (optical-electrical-optical, SONET/SDH frames), and traditional TDM switches (all electrical). The resulting systems could form IP based optical routers, optical label switches, wavelength routers, and dynamic optical cross connects.
この文書は、光のサポートに必要なGSMP（不透明および全ての光学）、SONET / SDH、およびIPパケットの空間切り替えの変更、レイヤ2（L2）フレームとTDMデータを詳述します。実装された場合、GSMPコントローラは、制御することができるであろう：光クロスコネクト（光 - 光）、透明な光クロスコネクト（光 - 電気 - 光、フレームに依存しない）、光 - 電気 - 光学的に不透明なクロスコネクト（SONET / SDHフレーム）、及び伝統的なTDMスイッチ（すべての電気）。結果として得られるシステムは、IPベースの光ルータ、光ラベルスイッチ、波長ルータ、および動的光クロスコネクトを形成することができます。
Several different generic models exist defining how to provide control plane functionality in an optical network [2], [3], [4]. This document takes no position on which model is most appropriate (e.g., single or multiple routing plane instances). The only assumption is that the ability to separate the control mechanisms from the data switching is as useful for the signaling of optical paths (e.g., GMPLS) as it is for the signaling of L2 paths (e.g., MPLS). Therefore, the requirements contained within are focused only on the separation of control functions from data functions in order to provide a more flexible network architecture.
いくつかの異なる一般的なモデルは、光ネットワークの制御プレーン機能を提供する方法を定義存在する[2]、[3]、[4]。この文書は、モデルが最も適切な（例えば、単一または複数のルーティング・プレーン・インスタンス）されたいかなる位置を取りません。唯一の仮定は、L2パス（例えば、MPLS）シグナリングのためのものであるようにデータ交換からの制御機構を分離する能力は、光路（例えば、GMPLS）のシグナリング用として有用であるということです。したがって、内に含まれる要件は、より柔軟なネットワークアーキテクチャを提供するためにのみデータ関数から制御機能の分離に焦点を当てています。
GSMPv3 [5] is well suited for providing the control interface necessary for allowing an IP based controller to direct the activities of an optical switch. In order for GSMP to operate between controllers and optical switches and cross connects, support for optical labels and service and resource abstractions must be added to GSMP.
GSMPv3 [5] IPベースのコントローラは、光スイッチの活動を指示することを可能にするために必要な制御インタフェースを提供するのに適しています。 GSMPは、コントローラと光スイッチとクロスコネクトとの間で動作するために、光学的標識とサービスとリソースの抽象化のためのサポートがGSMPに追加されなければなりません。
This document also includes changes recommended by implementers that will facilitate easier development of a GSMP implementation. These changes consist of rearranging PDU formats, clarification of flags, transaction identifiers, and response codes.
この文書はまた、GSMP実装の容易な開発を促進する実装が推奨する変更が含まれます。これらの変化は、PDUフォーマット、フラグの明確化、トランザクション識別子、及びレスポンスコードを再配列から成ります。
New labels are needed to identify the entities that are to be switched in the optical fabric. These are longer than the labels defined in GSMPv3 as they have physical and structural context. As GMPLS [2], [3] has had very similar requirements for label formats, alignment with GMPLS is proposed. This includes support for:
新しいラベルは、光ファブリックに切り替えることになっているエンティティを識別するために必要とされています。彼らは物理的および構造的なコンテキストを持っているように、これらはGSMPv3で定義されたラベルよりも長くなっています。 GMPLS [2]、[3]ラベルフォーマットのための非常に同様の要件を持っているように、GMPLSとの位置合わせが提案されています。これはのためのサポートが含まれています。
- Digital Carrier Hierarchy (e.g., DS-1, E1)
- SONET and SDH Hierarchy (e.g., OC-3, STM-1, VT1.5, VC-12)
- Plesiochronous Data Hierarchy (PDH) labels [6]
- OTN G.709 labels
- Lambdas
- Fibers
GSMP MUST include support for all label types list above, as well as for label hierarchies and label lists as defined by GMPLS. Therefore, the ability to perform operations on groups of the above labels MUST also be supported (e.g., 5 OC-3s, contiguous wavebands).
GMPLSで定義されたGSMPは、上記のすべてのラベルタイプのリストについては、同様にラベルの階層構造とラベルリストのサポートを含まなければなりません。したがって、上記ラベルのグループに対する操作を実行する能力はまた、（例えば、5 OC-3S、連続波長帯）をサポートしなければなりません。
An updated label range message MUST be provided. There MUST also be support of multiplexing (e.g., no multiplexing, SONET, Gigabit Ethernet multiplexing etc).
更新ラベル範囲のメッセージを提供しなければなりません。また、多重化（例えば、無多重、SONET、ギガビット・イーサネット多重化など）のサポートがなければなりません。
Optical switches have a number of different statistics which are not in common with ATM, or Frame Relay switches. Consequently, the statistics messages SHOULD be updated to report Performance Monitoring statistics defined for all new optical transport technologies added to GSMP.
光スイッチは、ATMと共通していない別の統計の数、またはフレームリレースイッチを持っています。その結果、統計メッセージがGSMPに追加されたすべての新しい光伝送技術のために定義されたパフォーマンス監視の統計情報を報告するために更新する必要があります。
Since an Optical Switch may be able to provide connection services at multiple transport layers (i.e., STS-3c, STS-1, VT-1.5, DS3, DS1), and not all switches are expected to support the same transport layers, the switch will need to notify the controller of the specific layers it can support.
光スイッチは、複数のトランスポート層（すなわち、STS-3C、STS-1、VT-1.5、DS3、DS1）、およびすべてのスイッチが同じトランスポート層をサポートするために期待されていない、スイッチに接続サービスを提供することができるのでそれがサポートすることができ、特定の層のコントローラに通知する必要があります。
Therefore, the Switch Configuration message MUST be extended to provide a list of the transport layers for which an optical switch can perform switching.
このため、スイッチ構成メッセージは、光スイッチがスイッチングを行うことができるため、トランスポート層のリストを提供するように拡張されなければなりません。
The port configuration message supplies the controller with the configuration information related to a single port. Consequently, extensive additions will need to be made to this command.
ポート・コンフィギュレーション・メッセージは、単一のポートに関連する設定情報をコントローラに供給する。その結果、大規模な追加は、このコマンドに行われる必要があります。
Port types MUST be added to support the mix of optical signals that can operate over a single fiber.
ポートタイプは、単一のファイバで動作することができる光信号の混在をサポートするために追加されなければなりません。
The port information that MAY need to be conveyed includes [7]:
搬送される必要があるかもしれないポート情報を含む[7]：
- wavelengths available per interface
- bit rate per wavelength
- type of fiber
Since a port on an optical switch may support signals at multiple transport layers, it is necessary to understand the signals supported, as well as the possible ways that one signal can be transported within another.
光スイッチ上のポートは、複数のトランスポート層における信号をサポートすることができるので、サポートされているシグナル、ならびに1つの信号が別内に輸送することができる可能な方法を理解することが必要です。
For OTN, SONET/SDH and PDH optical switches, the Port configuration message MUST be extended to detail the different transport layer signals that are supported by a port. Furthermore, this extension MUST detail which signals may be transported by another signal.
OTN、SONET / SDHおよびPDHの光スイッチは、ポート構成メッセージを詳細にポートによってサポートされる異なるトランスポート層信号を拡張する必要があります。信号は別の信号によって搬送されてもよいまた、この拡張MUST詳細。
This mechanism MUST also provide information about optional capabilities (such as virtual concatenation and arbitrary concatenation for SONET/SDH) available on a port.
このメカニズムは、ポート上で利用可能な（例えば、バーチャルコンカチネーションとSONET / SDHのための任意の連結のような）任意の機能に関する情報を提供しなければなりません。
A number of transport layer signals include overhead channels that can be used to identify the source of a signal. Since they are embedded in the signal, only the network element has access to the signals. However, not all network elements have the capability to set or read the messages in these channels on every port. Consequently, this port attribute needs to be reported to the controller.
トランスポート層信号の数は、信号のソースを識別するために使用することができるオーバーヘッドチャネルを含みます。これらは、信号に埋め込まれているので、唯一のネットワーク要素は、信号へのアクセスを有します。ただし、すべてのネットワーク要素は、すべてのポート上でこれらのチャネル内のメッセージを設定または読み取りする機能を持っていません。その結果、このポート属性がコントローラに報告する必要があります。
The Port Configuration message MUST be extended to report which trace mechanisms are supported by a port.
ポート設定メッセージは、ポートでサポートされているトレースのメカニズムを報告するように拡張されなければなりません。
Since contemporary Optical switches have the ability to support tens of thousands of ports in hundreds of shelves located in as potentially as many bays, the current "Slot/Port" location identifier is inadequate.
現代の光スイッチは、潜在的にできるだけ多くの湾にある棚の数百に数十ポートの何千ものをサポートする能力を持っているので、現在の「スロット/ポート」位置識別子は不十分です。
The Slot/Port Location Identifier MUST be extended to encode Bay/Shelf/Slot/Port.
スロット/ポート場所識別子は、ベイ/シェルフ/スロット/ポートをエンコードするために拡張する必要があります。
Partitioning can be done for any resource that exists in the network element. The GSMP partitioning draft currently defines ports and switching resources as partitionable resources. Since optical switches may support multiple transport network layers, an additional resource type is introduced: the transport layer signal.
パーティショニングは、ネットワーク要素に存在するすべてのリソースに対して行うことができます。 GSMP分割案は、現在、分割可能リソースとして、ポート、スイッチング・リソースを定義します。光スイッチは、複数のトランスポートネットワークレイヤをサポートすることができるので、追加のリソースタイプが導入された：トランスポート層信号。
The point where a transport layer signal is inserted into a lower layer signal (called an "access point" by the ITU [8]), is very similar to a port. Therefore, when partitioning is done on a transport layer signal basis, the partition that is the user of the access point MUST have a port that associated with the access point. Labels will then be used in the to describe the subordinate signals.
トランスポート層信号（ITU [8]による「アクセスポイント」と呼ばれる）下位レイヤ信号内に挿入される点は、ポートに非常に類似しています。パーティショニングは、トランスポート層の信号に基づいて行われる場合したがって、アクセスポイントのユーザであるパーティションは、アクセスポイントに関連付けられているポートがなければなりません。ラベルは、従属信号を記述するために使用されます。
While new capability sets MUST be added to support quality parameters in optical switches, no changes are foreseen to the service configuration message as its role to carry the service information as defined in the applicable service model.
新しい機能セットが光スイッチに品質パラメータをサポートするために追加されなければならないが、変更は適用可能なサービス・モデルで定義されているサービス情報を運ぶために、その役割としてサービス構成メッセージに予見されていません。
While one assumption of using optical media is that bandwidth is plentiful, it should be expected that traffic engineering will be necessary in any case [5]. GSMP provides the means for each connection to be created with specific attributes. Therefore, service parameters will need to be defined for each of the Different Optical technologies.
光メディアを使用することの1つの仮定は、帯域幅が豊富であり、トラフィックエンジニアリングは、いずれの場合にも必要であることが期待されるべきであることであるが[5]。 GSMPは、特定の属性を使用して作成される各接続のための手段を提供します。そのため、サービスパラメータが異なる光学技術ごとに定義する必要があります。
Capability to control re-timing and re-shaping on a per port level MUST be added.
ポートごとのレベルでのリタイミングと再整形を制御する機能が追加されなければなりません。
The capability to control the adaptation parameters used when a transport signal is inserted into another transport signal MUST be added. These parameters SHOULD be modifiable at times other than adding a branch so that functions such as Tandem Connection Monitoring can be configured. Currently, the default set of service models in GSMP are all based on the services models defined elsewhere, e.g., the Intserv model [9], [10], the Diffserv [11]
搬送信号は別の搬送信号に挿入されるときに使用される適応パラメータを制御する機能が追加されなければなりません。これらのパラメータは、タンデム接続監視などの機能を構成することができるようにブランチを追加する以外の時間に変更可能であるべきです。現在、GSMPにおけるサービスモデルのデフォルトセットは全て、例えば、他の場所で定義されたサービスモデル上のIntServモデルに基づいている[9]、[10]、Diffservの[11]
model, ATM QoS models and the Frame relay forum QoS models. A determination needs to be made of the applicable service models for optical channel trails. These models MUST then be mapped to the GSMP capability set mechanism.
モデル、ATMのQoSモデルやフレームリレーフォーラムのQoSモデル。決意は、光チャネルの軌跡に適用サービスモデルで作られる必要があります。これらのモデルは、GSMP能力セット機構にマッピングする必要があります。
The working group needs to decide whether a new encapsulation is required. In other words, will all optical switches used in either the MPLS over Optics and the IP over optics applications require that IP be implemented on the control channel connecting the GSMP controller and Optical switch (the GSMP target).
ワーキンググループは新しいカプセル化が必要かどうかを決定する必要があります。換言すれば、光学用途の上に光学上MPLSとIPのいずれかで使用されるすべての光スイッチは、IPをGSMPコントローラと光スイッチを接続制御チャネル（GSMPターゲット）上に実装されていることが必要であろう。
A new encapsulation SHOULD be defined allowing the use of a non-IP raw wavelength control connection.
新しいカプセル化は、非IP生波長制御接続の使用を可能に定義されるべきです。
Likewise, a new encapsulation SHOULD be defined allowing GSMP to be used in legacy Data Communication Network (DCN) environments that use OSI CLNP.
同様に、新しいカプセル化はGSMPは、OSI CLNPを使用する従来のデータ通信ネットワーク（DCN）環境で使用することができるように定義されなければなりません。
The security risks of additional non-IP encapsulations MUST be described, since the mandatory to implement mechanism of IPsec is not available for these control channels, as in the RFC 3293 Ethernet and ATM cases. It is in scope to perform risk analysis and describe if mechanisms for link-level security mitigate the risk.
追加の非IPカプセル化のセキュリティリスクは、IPsecのメカニズムはRFC 3293、イーサネットとATMの場合のように、これらの制御チャネルのために使用できません実現するために必須であるため、説明しなければなりません。リンクレベルのセキュリティのためのメカニズムは、リスクを軽減する場合は、リスク分析を実行し、記述する範囲です。
If a new encapsulation is defined, then the encapsulation group SHOULD be updated. No other changes should be required.
新しいカプセル化が定義されている場合、カプセル化グループを更新する必要があります。その他の変更は必要ありませんする必要があります。
Many existing OXCs use a command interface which assumes a serial transaction model. That is, a new command cannot be issued or processed until the existing command is completed. Under provisioning control via a network management application, and with non-dynamic path setup, this model has been adequate.
多くの既存のOXCは、シリアルトランザクションモデルを想定して、コマンド・インタフェースを使用します。それは、新しいコマンドが発行されたり、既存のコマンドが完了するまでに処理することはできませんされています。ネットワーク管理アプリケーションを介して制御をプロビジョニング下、および非動的パス設定して、このモデルは適切でした。
Moving to a dynamic path setup capability with a distributed control plane, a parallel transaction model is likely required for performance. This is particularly helpful when the performance of setting up a TDM style connection is much slower than setting up an L2 connection table. If the OXC is not able to support a parallel transaction model, a GSMP controller MUST be informed of this and adopt serial transaction behavior.
分散制御プレーンと動的経路設定機能への移動、平行トランザクションモデルは、おそらく性能のために必要とされます。 TDMスタイルの接続をセットアップするのパフォーマンスはL2接続テーブルを設定するよりもはるかに遅い場合、これは特に便利です。 OXCは、並列トランザクションモデルをサポートすることができない場合には、GSMPコントローラはこの知らさとシリアルトランザクション動作を採用しなければなりません。
Again due to the time it may take some OXCs to setup TDM connections relative to L2 fabrics (e.g., VC-4/STS-1 SPE fabric in an HOVC/STS switch), support for sending multiple transactions in the same message is a useful optimization. When an OXC receives a bulk message, the individual transactions are acted upon and a single reply is sent. If parallel transactions are not supported, bulk messages can improve performance by reducing transaction overhead. Bulk transactions SHOULD be supported.
再びによりそれがL2ファブリックに対して設定TDM接続するためにいくつかのOXCを取ることができる時間（HOVC / STSに、例えば、VC-4 / STS-1 SPEファブリックスイッチ）、同じメッセージで複数のトランザクションを送信するためのサポートが有用です最適化。 OXCは、バルクメッセージを受信すると、個々のトランザクションが作用され、単一の応答が送信されます。並列トランザクションはサポートされていない場合は、バルクのメッセージは、トランザクションのオーバーヘッドを減らすことによって、パフォーマンスを向上させることができます。バルクトランザクションがサポートされる必要があります。
To achieve good link protection performance (e.g., 50 ms after failure detection), SONET/SDH and some OXC systems use hardware based protection schemes (e.g., ring protection). Achieving this level of performance solely using a data control plane such as GMPLS is a serious challenge. An alternate approach is to utilize protection capabilities of an OXC with a dynamic control plane. An implication of this hybrid approach is that extensions are needed to GSMP to provision the behavior of an OXC in anticipation of a link failure.
良好なリンク保護性能（故障検出後、例えば、50ミリ秒）を達成するために、SONET / SDH、一部OXCシステムは、ハードウェアベースの保護方式（例えば、リングプロテクション）を使用します。単に、このようなGMPLSなどのデータコントロールプレーンを使ってこのレベルの性能を達成することは重大な挑戦です。別のアプローチは、動的な制御プレーンとOXCの保護機能を利用することです。このハイブリッドアプローチの含意は拡張子がリンク障害を見越して準備OXCの動作をするGSMPに必要とされることです。
This differs from the strict master-slave relationship in GSMP for Layer 2 switches in that here the OXC is capable of taking an action independent of the GSMP controller and then informing the controller afterwards. Consequently, the GSMP port configuration command MUST be extended to allow autonomous protection behaviors to be provisioned into the Network Element.
これは、ここでは、OXC GSMPコントローラのアクション独立を取り、次いでその後コントローラに通知することが可能であることで、レイヤ2スイッチのGSMPに厳密主従関係とは異なります。その結果、GSMPポート・コンフィギュレーション・コマンドは、自律保護行動がネットワーク要素にプロビジョニングすることができるように拡張されなければなりません。
Furthermore, the controller MUST be able to provide the parameters for when reversion from a backup link to the original link is allowed. This may take the form of hold-off timers, BER parameters, or the requirement for controller directed reversion.
また、コントローラは、元のリンクへのバックアップリンクからの復帰が許可されたときのためのパラメータを提供できなければなりません。これは、ホールドオフタイマー、BERパラメータ、またはコントローラ向け復帰のための要件の形をとることができます。
An example of protection OXC behavior is that when a link fails, a backup link may be used to protect traffic on. This backup link could be selected from a set of links, none of which are pre-reserved. A backup link could be shared with one or more "working" links which is a form of 1:n shared protection. Specifying the set of possible backup links SHOULD be done as an option to the Add-Branch message.
保護OXCの動作の例は、リンクに障害が発生した場合、バックアップリンクは上のトラフィックを保護するために使用することができるということです。このバックアップリンクはリンクのセットから選択することができ、のどれも、事前に予約されていません。 nは共有の保護：バックアップリンクは、一つ以上の1の形である「作業」リンクを共有することができます。可能なバックアップリンクのセットを指定すると、アドイン支店メッセージにオプションとして行われるべきです。
When a backup link is used or the OXC reverts back to the original link, the control plane (i.e., signaling) may need to know about the new path state in order to notify the operator, or take some other OAM action (e.g., billing, SLA monitoring). An additional GSMP message to inform the controller SHOULD be added to do this.
バックアップリンクが使用されているか、OXCは元のリンク、コントロールプレーンに戻りますとき（すなわち、シグナリング）（例えば、課金いくつかの他のOAMアクションをオペレータに通知、または取るために、新しいパスの状態について知る必要があるかもしれません、SLAモニタリング）。コントローラに通知する追加のGSMPメッセージは、これを行うに追加する必要があります。
A more specialized form of restoration called "1+1" defines a (usually node disjoint) protection path in a transport/optical network for a given working path. At the ingress node to the path, the traffic signal is sent simultaneously along both working and protection paths. Under non-failure conditions at the egress node, only the last link of the working path is connected to the client. When any link in the working path fails, traffic on the working path ceases to be received at end of the path. The egress OXC detects this condition and then switches to use the last link of the protection path without the controller having to issue a Move-Input-Branch message. At no time is the ingress node aware which link the egress node is using. Selection of the protection path and all of its links is outside the scope of GSMP.
「1 + 1」と呼ばれる復元のより特殊な形態は、所与の現用パスのためのトランスポート/光ネットワークにおける（通常ノードディスジョイント）予備パスを定義します。パスの入口ノードにおいて、トラフィック信号は、両方の現用と予備経路に沿って同時に送信されます。出口ノードでは非障害状態の下では、ワーキングパスの最後のリンクは、クライアントに接続されています。現用パスのいずれかのリンクに障害が発生した場合には、現用パス上のトラフィックは、パスの最後に受信されなくなります。出口OXCは、この状態を検出し、コントローラは移動-入力 - 支店メッセージを発行することなく、保護パスの最後のリンクを使用して切り替えます。時間がない時に入口ノードは出口ノードが使用してリンクしている認識しています。保護パスとそのリンクのすべての選択は、GSMPの範囲外です。
Specification of the two output branches at the ingress node can be done with the usual Add-Branch semantics. The ingress node protection link is not shared with any other working link.
入口ノードの2つの出力ブランチの仕様は、通常のアドイン支店のセマンティクスで行うことができます。入口ノード保護リンクは、他の作業のリンクと共有されていません。
Specification of the two input branches at the egress node should be done when the Add-Branch message is sent. This SHOULD be an option to that message. The egress node protection link is not shared with any other working link.
アドイン支店メッセージが送信されるとき、出口ノードに2つの入力ブランチの指定は行われるべきです。これは、そのメッセージにオプションであるべきです。出口ノード保護リンクは、他の作業のリンクと共有されていません。
When a protection link is used or the OXC reverts back to the working link, the control plane (i.e., signaling) may need to know about the new path state in order to notify the operator, or take some other OAM action (e.g., billing, SLA monitoring). An additional GSMP message to inform the controller SHOULD be added to do this.
保護リンクが使用されているか、OXCは働いリンク、コントロールプレーン（すなわち、シグナリング）他のいくつかのOAMアクションをオペレータに通知するために、新しいパスの状態について知る必要がある、またはかかる場合があります（例えば、課金に戻りますとき、SLAモニタリング）。コントローラに通知する追加のGSMPメッセージは、これを行うに追加する必要があります。
If an alternate input port is not specified with an original Add-Branch message, it MAY be specified in a subsequent Add-Branch message. In this case, it is useful to include information about existing users of the output port in that Add-Branch message. This helps the OXC immediately learn of the association between the new input port and an existing one. The association is used to enable OXC protection procedures. This capability MUST be added to the add-branch message.
代替の入力ポートは、元の追加ブランチメッセージで指定されていない場合は、後続の追加ブランチメッセージで指定されてもよいです。この場合、そのアドイン支店メッセージで出力ポートの既存のユーザーに関する情報を含めることが有益です。これは、OXCは、すぐに新しい入力ポートと既存のものとの間の関連を学ぶことができます。協会は、OXC保護手続を有効にするために使用されます。この機能は、アドオン分岐メッセージに追加する必要があります。
Similar contextual information is needed for a Delete-Branch message so that the OXC can determine if a path becomes unprotected. This capability MUST be added to the Delete-branch message.
パスが保護されていないとなった場合OXCが決定できるように同様のコンテキスト情報を削除分岐メッセージのために必要とされます。この機能は削除分岐メッセージに加えなければなりません。
Aside from link or equipment failures, there are a variety of maintenance conditions that could cause the backup/protection link(s) to be used. These may include:
別にリンクや機器の故障から、使用するバックアップ/保護リンク（複数可）を引き起こす可能性があり、メンテナンスの様々な条件があります。これらを含めることがあります。
- Scheduled maintenance of the working link. Here the network operator deliberately takes a link out of service to perform maintenance. - Reconfiguration of fiber/node/network which causes temporary need to use backup links.
- 働きリンクのメンテナンスを予定。ここでは、ネットワークオペレータは、意図的にメンテナンスを実行するサービスのうち、リンクを取ります。 - バックアップリンクを使用する一時的な必要性が発生し、繊維/ノード/ネットワークの再構成。
It may be useful to specify these triggers when the backup/protection links are defined with the Add-Branch message. This depends on how the OXC is implemented to be aware of such triggers. This is for further study.
バックアップ/保護リンクが追加-支店メッセージで定義されている場合にはこれらのトリガーを指定することが有用であり得ます。これは、OXCは、このようなトリガを認識するように実装されている方法によって異なります。これは今後の検討課題です。
When an OXC has the capability to perform protection switching independently from the Optical Call Controller (OCC), it may be useful for the OCC to be informed of these capabilities at switch and/or port configuration. Applications in the GSMP controller could use this information. For example, signaling clients could define a path protection scheme over multiple GSMP enabled OXCs. This is for further study.
OXCは、光コールコントローラ（OCC）から独立して保護スイッチングを実行する能力を持っている場合は、スイッチおよび/またはポートの構成で、これらの機能の通知をするOCCのために有用である可能性があります。 GSMPコントローラのアプリケーションは、この情報を使用することができます。例えば、シグナリング・クライアントは、複数のGSMP有効のOXCオーバーパスの保護スキームを定義することができます。これは今後の検討課題です。
Bi-directional Connection Replacement
双方向接続の交換
Connections in the transport network are inherently point-to-point bi-directional. Unfortunately, GSMPv3 currently does not allow for the B and R flags to be set on an add branch message. This means that it is not possible to do an atomic replacement of a bi-directional connection -- an action that is desirable for controller directed restoration. Consequently, the protocol MUST be changed to allow these flags to be used at the same time.
トランスポートネットワーク内の接続は、本質的にポイントツーポイントの双方向です。残念ながら、GSMPv3は現在、BおよびRフラグが追加分岐メッセージに設定することはできません。コントローラ向け復元するための望ましい作用 - 双方向接続の原子交換を行うことができないことを意味します。従って、プロトコルは、これらのフラグが同時に使用できるように変更しなければなりません。
GSMP for Optical Switching should also support optical burst switching. As described in [12], [13], and [14], part of burst switching connection setup includes reserving time on the transport medium for the client.
光スイッチングのためのGSMPは、光バーストスイッチングをサポートする必要があります。 [12]、[13]及び[14]に記載されているように、バーストスイッチング接続セットアップの一部は、クライアントのための輸送媒体の時間を予約含みます。
This time is characterized by two parameters: a start time and the duration. These values MAY define a one-time reservation or a repeating reservation. Upon a request for setup of a burst connection, the GSMP controller MUST perform appropriate Connection Admission Control for the time and duration specified and, if the connection is allowed, MUST signal these parameters to the burst switching device to reserve the exact bandwidth required [12], [14]. The burst switch MUST perform the switching operation autonomously, using the synchronization methods prescribed for the burst network it is operating in.
開始時間と持続時間：この時間は、2つのパラメータによって特徴付けられます。これらの値は、1回の予約や、繰り返し予約を定義することができます。バースト接続のセットアップのための要求に応じて、GSMPコントローラは、指定された時間と持続時間のための適切な接続アドミッション制御を実行しなければならないと、接続が許可されている場合、必要とされる正確な帯域幅を確保するためにバーストスイッチングデバイスにこれらのパラメータをシグナリングしなければならない[12 ]、[14]。バーストスイッチは、それが動作しているバーストネットワークの所定の同期方法を使用して、自律的にスイッチング動作を実行しなければなりません。
This section describes requirements to GSMP v3 based on some implementation experience. They address areas of ambiguity, missing semantics, and configuration recommendations.
このセクションでは、いくつかの実装経験に基づくGSMP V3に要件について説明します。彼らは、あいまいさの領域、不足している意味論、およびコンフィギュレーションの推奨事項に取り組みます。
The Basic GSMP Message Format in chapter 3.1.1 in [5] describes the common fields present in all GSMP messages except for the Adjacency protocol.
で、3.1.1に基本的なGSMPメッセージ形式[5]隣接プロトコルを除くすべてのGSMPメッセージに存在する一般的なフィールドについて説明します。
If a message exceeds the MTU of the link layer it has to be segmented. This was originally done with the "More" value in the Result field. The addition of the I flag and the SubMessage Number to the header has made the "More" value obsolete.
メッセージは、リンク層のMTUを超える場合には、分割されなければなりません。これは、もともと結果]フィールドの「詳細」の値で行われました。 Iフラグとヘッダにサブメッセージ数の追加は、「詳細」値が廃止されています。
The I flag and SubMessage numbers should be used in all messages that can be segmented.
Iフラグとサブメッセージ番号は、セグメント化することができるすべてのメッセージで使用されるべきです。
It should be specified if the SubMessage Number starts on 0 or 1 in a segmented message and what value the I flag should have in an message that is not segmented.
サブメッセージ番号がセグメント化されたメッセージに0または1で始まり、Iフラグがセグメント化されていないメッセージにどのような価値を持っている必要がある場合は指定する必要があります。
Clarification of what value should be used in the Length field for segmented messages. Specifically, does the Length field contain the total length of the message or the length of the current segment.
どのような価値の明確化は、セグメント化されたメッセージのためにLengthフィールドで使用されるべきです。具体的には、Lengthフィールドは、メッセージまたは現在のセグメントの長さの合計長さを含んでありません。
To avoid all ambiguity an example of message segmentation should be provided.
メッセージの分割の例を提供する必要があるすべての曖昧さを避けるために。
The Transaction Identifier in [5] does not distinguish between replies from a request with "AckAll" and "NoSuccessAck". It also does not provide any information about how to handle replies where the Transaction ID doesn't match a Transaction ID from a previously sent request.
トランザクション識別子は、[5]「AckAll」および「NoSuccessAck」との要求からの応答を区別しません。また、トランザクションIDは、以前に送られたリクエストからトランザクションIDが一致しない応答を処理する方法に関する情報を提供していません。
If multiple controllers are connected to a single switch and the switch sends an event message with "ReturnReceipt" set to all of them, there is no way for the switch to identify which controller the receipt is coming from.
複数のコントローラが単一のスイッチおよびスイッチに接続されている場合は、それらのすべてに設定された「RETURNRECEIPT」のイベントメッセージを送信し、スイッチがレシートから来されたコントローラを識別するための方法はありません。
The "ReturnReceipt" value should not be permitted for Events.
「RETURNRECEIPT」値はイベントのために許可すべきではありません。
The Switch Configuration Message defined in chapter 8.1 in [5] defines a Window size to be used by the controller when sending messages to the switch. It is not stated if this window should apply to all messages or only to messages that will always generate a reply.
[5]の章8.1で定義されたスイッチ構成メッセージは、スイッチにメッセージを送信するときにコントローラによって使用されるウィンドウサイズを定義します。このウィンドウは、すべてのメッセージにのみ、常に応答を生成しますメッセージに適用すべきかどうかは明記されていません。
If messages that may not generate a reply should be counted against the window a time-out period when they are to be removed from the window should be defined.
応答を生成しないことがありますメッセージがウィンドウに対してカウントする必要がある場合、それらはウィンドウから削除されるタイムアウト時間を定義する必要があります。
It is not defined if the window should be cleared when the adjacency is lost and later recovered.
隣接関係が失われ、後に回収されたときに、ウィンドウをクリアする必要があるかどうかは定義されていません。
A retransmission policy with a well-designed exponential backoff should be used if no reply is received for a message with "AckAll" set.
返事が「AckAll」が設定されたメッセージのために受信されない場合にうまく設計された指数バックオフと再送ポリシーが使用されるべきです。
The "Delete Branch Element" has a 4 bit Error field that should be redefined to match the size of the "Failure Response Codes".
「削除支店要素は」「失敗応答コード」のサイズに合うように再定義する必要がある4ビット・エラー・フィールドがあります。
The chapter about how to handle a new adjacency and re-established adjacencies should be clarified.
新しい隣接関係と再確立隣接関係をどのように扱うかについての章では、明確にする必要があります。
The switch must not reset the connection states if another adjacency has already been established since this would destroy an already valid state.
これは、すでに有効な状態を破壊してしまうので、別の隣接関係が既に確立されている場合、スイッチは、接続状態をリセットしてはいけません。
The security of GSMP's TCP/IP control channel has been addressed in [15]. Any potential remaining security considerations are not addressed in this requirements document.
GSMPのTCP / IP制御チャネルのセキュリティは[15]で解決されています。任意の潜在的な残りのセキュリティに関する考慮事項は、この要件ドキュメントに対処されていません。
The list of authors provided with this document is a reduction of the original list. Currently listed authors wish to acknowledge that a substantial amount was also contributed to this work by: Avri Doria and Kenneth Sundell
この文書で提供作者のリストは、元のリストの減少です。 AvriドリアとケネスSundell：現在記載されている著者は、かなりの量もすることで、この作業に貢献したことを認めることを望みます
The authors would like to acknowledge the careful review and comments of Dimitri Papadimitriou, Torbjorn Hedqvist, Satoru Okamoto, and Kohei Shiomoto.
著者は、慎重に検討し、ディミトリPapadimitriou、Torbjorn Hedqvist、岡本聡、および康平Shiomotoのコメントを確認したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Berger, L., Ed., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003.
[2]バーガー、L.、エド、 "一般化MPLS - 機能説明シグナリング"。、RFC 3471、2003年1月。
[3] Mannie, E., et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Work in Progress, May 2003.
[3]マニー、E.、ら、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ"、進歩、2003年5月での作業。
[4] ITU-T Recommendation, "Architecture for the Automatically Switched Optical Network (ASON)", G.8080/Y.1304, January 2003
[4] ITU-T勧告、G.8080 / Y.1304、2003年1月 "の自動交換光ネットワーク（ASON）のためのアーキテクチャ"
[5] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General Switch Management Protocol V3", RFC 3292, June 2002.
[5]ドリア、A.、Sundell、K.、Hellstrand、F.とT. Worsterは、RFC 3292、2002年6月 "一般的には、管理プロトコルV3を切り替えます"。
[6] Sadler, J., Mack-Crane, B., "TDM Labels for GSMP", Work in Progress, February 2001.
[6]サドラー、J.、マック・クレーン、B.、 "GSMPのためのTDMラベル"、進歩、2001年2月作業。
[7] Rajagopalan, B., et al., "IP over Optical Networks: A Framework", Work in Progress, September 2003.
[7] Rajagopalan、B.ら、 "光ネットワーク上のIP：フレームワーク"。、進歩、2003年9月の作業。
[8] ITU-T Recommendation, "Generic functional architecture of transport networks", G.805, March 2000.
[8] ITU-T勧告、 "トランスポート・ネットワークの一般的な機能アーキテクチャ"、G.805、2000年3月。
[9] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", RFC 1633, June 1994.
[9]ブレーデン、R.、クラーク、D.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[10] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[10] Wroclawski、J.、RFC 2211 "制御負荷ネットワーク要素サービスの仕様"、1997年9月。
[11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, _"An Architecture for Differentiated Services", RFC 2475, December 1998.
[11]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、_ "微分されたサービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[12] C. Qiao, M. Yoo, "Choice, and Feature and Issues in Optical Burst Switching", Optical Net. Mag., vol.1, No.2, Apr.2000, pp.36-44.
[12] C.橋、M.ユ、「選択、および光バースト交換における機能と課題」、光ネット。マグ。、第1巻、第2号、Apr.2000、pp.36-44。
[13] Ilia Baldine, George N. Rouskas, Harry G. Perros, Dan Stevension, "JumpStart: A Just-in-time Signaling Architecture for WDM Burst-Switching Networks", IEEE Comm. Mag., Fab. 2002.
[13]イリヤBaldine、ジョージN. Rouskas、ハリー・G.ペロス、ダンStevension、「ジャンプスタート：WDMバースト交換網のためのジャストインタイムシグナリングアーキテクチャ」、IEEEコム。マグ。、のFab。 2002。
[14] Sanjeev Verma, et al. "Optical burst switching: a viable solution for terabit IP backbone", IEEE network, pp. 48-53, Nov/Dec 2000.
[14]サンジーブバーマ、ら。 「光バーストスイッチング：テラビットIPバックボーンのための実行可能な解決策」。、IEEEネットワーク、頁48から53まで、2000年11月/ 12月
[15] Worster, T., Doria, A. and J. Buerkle, "GSMP Packet Encapsulations for ATM, Ethernet and TCP", RFC 3293, June 2002.
[15] Worster、T.、ドリア、A.およびJ. Buerkle、 "ATM、イーサネット（登録商標）及びTCP用GSMPパケットカプセル化"、RFC 3293、2002年6月。
Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
Hormuzd Khosraviインテル2111 NE 25日アベニューヒルズボロ、OR 97124 USA
Phone: +1 503 264 0334 EMail: hormuzd.m.khosravi@intel.com
電話：+1 503 264 0334 Eメール：hormuzd.m.khosravi@intel.com
Georg Kullgren Nortel Networks AB S:t Eriksgatan 115 A P.O. Box 6701 SE-113 85 Stockholm Sweden
ゲオルク・Kullgren Nortel NetworksのABセントEerikinkatu 115Aの私書箱ボックス6701 SE-113 85ストックホルムスウェーデン
EMail: geku@nortelnetworks.com
メールアドレス：geku@nortelnetworks.com
Jonathan Sadler Tellabs Operations, Inc. 1415 West Diehl Road Naperville, IL 60563
ジョナサン・サドラーテラブスオペレーションズ株式会社1415西ディール道路ネーパーヴィル、IL 60563
Phone: +1 630-798-6182 EMail: Jonathan.Sadler@tellabs.com
電話：+1 630-798-6182電子メール：Jonathan.Sadler@tellabs.com
Stephen Shew Nortel Networks PO Box 3511 Station C Ottawa, ON K1Y 4H7
K1Y 4H7 ONスティーブン供えNortel Networksの私書箱3511駅のCオタワ、
EMail: sdshew@nortelnetworks.com
メールアドレス：sdshew@nortelnetworks.com
Kohei Shiomoto
こへい しおもと
EMail: Shiomoto.Kohei@lab.ntt.co.jp
メールアドレス：Shiomoto.Kohei@lab.ntt.co.jp
Atsushi Watanabe Nippon Telegraph and Telephone Corporation 807A 1-1 Hikari-no-oka, Yokosuka-shi Kanagawa 239-0847, Japan
あつし わたなべ にっぽん てぇｇらｐｈ あんｄ てぇｐほね こｒぽらちおん ８０７あ １ー１ ひかりーのーおか、 よこすかーし かながわ ２３９ー０８４７、 じゃぱん
EMail: atsushi@exa.onlab.ntt.co.jp
メールアドレス：atsushi@exa.onlab.ntt.co.jp
Satoru Okamoto Nippon Telegraph and Telephone Corporation 9-11 Midori-cho 3-chome, Musashino-shi Tokyo 180-8585, Japan
さとる おかもと にっぽん てぇｇらｐｈ あんｄ てぇｐほね こｒぽらちおん ９ー１１ みどりーちょ ３ーちょめ、 むさしのーし ときょ １８０ー８５８５、 じゃぱん
EMail: okamoto@exa.onlab.ntt.co.jp
メールアドレス：okamoto@exa.onlab.ntt.co.jp
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。