[要約] RFC 3604は、GSMPv3に光学サポートを追加するための要件を定義しています。その目的は、光学ネットワークの管理を効果的に行うためのプロトコルの拡張です。

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)

一般的なスイッチ管理プロトコルバージョン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.

Copyright(c)The Internet Society(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].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈される。

1. Overview
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.

このドキュメントでは、光学(非透明およびすべての光学)、SONET/SDH、およびIPパケットの空間スイッチング、レイヤー2(L2)フレーム、およびTDMデータのサポートに必要なGSMPの変更について詳しく説明します。実装すると、GSMPコントローラーは、フォトニッククロスコネクト(光学光学)、透明な光クロス接続(光電気光学、フレーム独立)、不透明なクロス接続(光電気術、ソネット/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パス(例:MPL)のシグナル伝達と同様に、光パス(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形式の再配置、フラグの明確化、トランザクション識別子、および応答コードで構成されています。

2. Requirements for Optical Support
2. 光学サポートの要件
2.1. Label
2.1. ラベル
2.1.1. Label Types
2.1.1. ラベルタイプ

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

- デジタルキャリア階層(例:DS-1、E1) - ソネットおよびSDH階層(例:OC-3、STM-1、VT1.5、VC-12) - プレシオクロナスデータ階層(PDH)ラベル[6] -OTN G.709ラベル-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).

GSMPには、上記のすべてのラベルタイプリストのサポート、およびGMPLSで定義されているラベル階層とラベルリストのサポートを含める必要があります。したがって、上記のラベルのグループで操作を実行する機能もサポートする必要があります(たとえば、5つのOC-3、連続波路)。

2.1.2. Label Management Issues
2.1.2. ラベル管理の問題

An updated label range message MUST be provided. There MUST also be support of multiplexing (e.g., no multiplexing, SONET, Gigabit Ethernet multiplexing etc).

更新されたラベル範囲メッセージを提供する必要があります。また、多重化のサポートも必要です(たとえば、マルチプレックス、ソネット、ギガビットイーサネットマルチプレックスなど)。

2.2. Statistics messages
2.2. 統計メッセージ

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に追加されたすべての新しい光学輸送技術について定義されたパフォーマンス監視統計を報告するために、統計メッセージを更新する必要があります。

2.3. Configuration Issues
2.3. 構成の問題
2.3.1. Switch Configuration
2.3.1. 設定を切り替えます
2.3.1.1. Layer Switching Identification
2.3.1.1. レイヤースイッチング識別

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.

したがって、スイッチ構成メッセージを拡張して、光スイッチがスイッチングを実行できる輸送層のリストを提供する必要があります。

2.3.2. Port Configuration
2.3.2. ポート構成

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.

ポート構成メッセージは、単一のポートに関連する構成情報をコントローラーに提供します。その結果、このコマンドに大規模な追加を行う必要があります。

2.3.2.1. Port Type extensions
2.3.2.1. ポートタイプの拡張機能

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

- インターフェイスごとに利用可能な波長 - 波長あたりのビットレート - 繊維の種類

2.3.2.2. Supported Signal Type extensions
2.3.2.2. サポートされている信号タイプ拡張機能

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.

光スイッチのポートは複数の輸送層で信号をサポートする場合があるため、サポートされている信号を理解する必要があります。また、ある信号を別の信号内で輸送できる可能性があります。

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光スイッチの場合、ポート構成メッセージを拡張して、ポートでサポートされているさまざまな輸送層信号を詳しく説明する必要があります。さらに、この拡張機能は、どの信号が別の信号によって輸送される可能性があるかを詳述する必要があります。

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の仮想的連結や任意の連結など)に関する情報も提供する必要があります。

2.3.2.3. Trace Mechanism support Identification
2.3.2.3. トレースメカニズムは識別をサポートします

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.

ポート構成メッセージを拡張して、ポートでサポートされているトレースメカニズムを報告する必要があります。

2.3.2.4. Port Location Identification
2.3.2.4. ポートの場所の識別

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.

スロット/ポートの位置識別子は、ベイ/シェルフ/スロット/ポートをエンコードするために拡張する必要があります。

2.3.2.5. ポート関連のパーティション拡張機能

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]によって「アクセスポイント」と呼ばれる)に挿入されるポイントは、ポートに非常に似ています。したがって、パーティション化が輸送層信号ベースで行われる場合、アクセスポイントのユーザーであるパーティションには、アクセスポイントに関連付けられたポートが必要です。ラベルは、下位信号を記述するために使用されます。

2.3.3. Service Configuration
2.3.3. サービス構成

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.

光スイッチの品質パラメーターをサポートするために新しい機能セットを追加する必要がありますが、該当するサービスモデルで定義されているようにサービス情報を運ぶ役割として、サービス構成メッセージに変更は予見されません。

2.4. Service Model Issues
2.4. サービスモデルの問題

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は、特定の属性で作成される各接続の手段を提供します。したがって、さまざまな光学技術のそれぞれについて、サービスパラメーターを定義する必要があります。

2.4.1. Transparent Optical
2.4.1. 透明な光学

Capability to control re-timing and re-shaping on a per port level MUST be added.

ポートレベルごとに再チミングと再形成を制御する機能を追加する必要があります。

2.4.2. SONET/SDH and OTN
2.4.2. SONET/SDHおよびOTN

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] 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.

輸送信号が別の輸送信号に挿入されたときに使用される適応パラメーターを制御する機能を追加する必要があります。これらのパラメーターは、タンデム接続モニタリングなどの機能を構成できるように、ブランチを追加する以外に変更できる必要があります。現在、GSMPのデフォルトのサービスモデルのセットはすべて、他の場所で定義されているサービスモデル、たとえばIntservモデル[9]、[10]、DiffServ [11]モデル、ATM QOSモデル、フレームリレーフォーラムQoSモデルに基づいています。。光学チャネルトレイルに該当するサービスモデルを決定する必要があります。これらのモデルは、GSMP機能セットメカニズムにマッピングする必要があります。

2.5. Encapsulation issues
2.5. カプセル化の問題

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 Over OpticsおよびIP上のIPで使用されるすべての光スイッチは、GSMPコントローラーと光スイッチ(GSMPターゲット)を接続するコントロールチャネルにIPを実装する必要があります。

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.

同様に、OSI CLNPを使用するレガシーデータ通信ネットワーク(DCN)環境でGSMPを使用できるようにする新しいカプセル化を定義する必要があります。

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.

RFC 3293イーサネットおよびATMケースのように、これらの制御チャネルではIPSECのメカニズムを実装するための必須のメカニズムは利用できないため、追加の非IPカプセルのセキュリティリスクを説明する必要があります。リスク分析を実行し、リンクレベルのセキュリティのメカニズムがリスクを軽減するかどうかを記述することが範囲です。

2.6. MIB Issues
2.6. MIBの問題

If a new encapsulation is defined, then the encapsulation group SHOULD be updated. No other changes should be required.

新しいカプセル化が定義されている場合、カプセル化グループを更新する必要があります。他の変更は必要ありません。

2.7. OXC Transaction Model
2.7. OXCトランザクションモデル
2.7.1. Serial Transactions
2.7.1. シリアルトランザクション

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コントローラーにこれを通知し、シリアルトランザクション動作を採用する必要があります。

2.7.2. Bulk Transactions
2.7.2. バルクトランザクション

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ファブリック(HOVC/STSスイッチのVC-4/STS-1 SPEファブリックなど)に比べてTDM接続をセットアップするのにいくつかのOXCがかかる場合があります。最適化。OXCがバルクメッセージを受信すると、個々のトランザクションが実行され、単一の返信が送信されます。並列トランザクションがサポートされていない場合、バルクメッセージはトランザクションオーバーヘッドを削減することでパフォーマンスを改善できます。バルクトランザクションをサポートする必要があります。

2.8. OXC Protection Capabilities
2.8. 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の保護機能を利用することです。このハイブリッドアプローチの意味は、GSMPに拡張が必要であり、リンク障害を見越してOXCの動作を提供することです。

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.

これは、レイヤー2スイッチのGSMPの厳格なマスタースレーブ関係とは異なります。ここでは、OXCは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パラメーター、またはコントローラー指示復帰の要件の形が取られる場合があります。

2.8.1. 非予約されていない保護リンク

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.

Protection OXCの動作の例は、リンクが故障した場合、バックアップリンクを使用してトラフィックを保護することができることです。このバックアップリンクは、リンクのセットから選択できますが、いずれも事前にリンクされていません。バックアップリンクは、1: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が元のリンクに戻る場合、コントロールプレーン(つまり、シグナリング)がオペレーターに通知するために新しいパス状態を知る必要がある場合があります。、SLAモニタリング)。これを行うには、コントローラーを通知するための追加のGSMPメッセージを追加する必要があります。

2.8.2. 専用の保護リンク

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」と呼ばれるより専門的な形式の修復形態は、特定の作業経路の輸送/光学ネットワーク内の(通常はノードの分離)保護パスを定義します。パスへのイングレスノードで、トラフィック信号は、作業経路と保護パスの両方に沿って同時に送信されます。Egressノードの非失敗条件下では、作業パスの最後のリンクのみがクライアントに接続されます。作業パスのリンクが失敗すると、パスの終わりに作業パスのトラフィックが受信されなくなります。出力OXCはこの条件を検出し、コントローラーがムーブ入力ブランチメッセージを発行することなく、保護パスの最後のリンクを使用するように切り替えます。Engressノードが使用しているリンクリンクを認識することはありません。保護パスの選択とそのすべてのリンクは、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.

Ingressノードでの2つの出力分岐の仕様は、通常のアドブランチセマンティクスで実行できます。Ingressノード保護リンクは、他の作業リンクと共有されていません。

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.

Eugressノードでの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.

delete-branchメッセージに同様のコンテキスト情報が必要であるため、OXCはパスが保護されていないかどうかを判断できます。この機能は、削除ブランチメッセージに追加する必要があります。

2.8.3. Protection Triggers
2.8.3. 保護トリガー

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がどのように実装されるかに依存します。これはさらなる研究のためです。

2.8.4. 保護リンク機能

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)から独立して保護スイッチングを実行する機能を備えている場合、Switchおよび/またはポート構成でこれらの機能をOCCに通知することが役立つ場合があります。GSMPコントローラーのアプリケーションは、この情報を使用できます。たとえば、シグナリングクライアントは、複数のGSMP対応のOXCを超えるパス保護スキームを定義できます。これはさらなる研究のためです。

2.9. Controller directed restoration
2.9. コントローラー指示修復

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フラグを追加ブランチメッセージに設定することを許可していません。これは、双方向接続の原子置換を行うことができないことを意味します。これは、コントローラー指向の修復に望ましいアクションです。その結果、これらのフラグを同時に使用できるようにプロトコルを変更する必要があります。

2.10. Support for optical burst switching
2.10. 光学バーストスイッチングのサポート

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]。バーストスイッチは、動作しているバーストネットワークに規定されている同期方法を使用して、自律的にスイッチング操作を実行する必要があります。

3. Requirements from Implementers
3. 実装者からの要件

This section describes requirements to GSMP v3 based on some implementation experience. They address areas of ambiguity, missing semantics, and configuration recommendations.

このセクションでは、いくつかの実装エクスペリエンスに基づいて、GSMP V3への要件について説明します。曖昧さ、セマンティクスの欠落、構成の推奨事項の領域に対処します。

3.1. GSMP Packet Format
3.1. GSMPパケット形式

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.

[5]の第3.1.1章の基本的なGSMPメッセージ形式は、隣接プロトコルを除くすべてのGSMPメッセージに存在する共通フィールドについて説明しています。

3.1.1. Message segmentation
3.1.1. メッセージセグメンテーション

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フラグとサブメッセージ番号は、セグメント化できるすべてのメッセージで使用する必要があります。

3.1.1.1. SubMessage Number and I flag
3.1.1.1. サブメッセージ番号と私はフラグを立てます

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フラグが持つべき値を指定するかどうかを指定する必要があります。

3.1.1.2. Message Length
3.1.1.2. メッセージの長さ

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.

セグメント化されたメッセージの長さフィールドで使用する値の明確化。具体的には、長さフィールドにはメッセージの全長または現在のセグメントの長さが含まれていますか。

3.1.1.3. Message Segmentation example
3.1.1.3. メッセージセグメンテーションの例

To avoid all ambiguity an example of message segmentation should be provided.

すべてのあいまいさを避けるには、メッセージセグメンテーションの例を提供する必要があります。

3.1.2. Transaction Identifier
3.1.2. トランザクション識別子

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」値は、イベントで許可されるべきではありません。

3.2. Window Size
3.2. ウィンドウサイズ

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.

隣接が失われ、後に回復したときにウィンドウをクリアする必要があるかどうかは定義されていません。

3.3. Retransmission
3.3. 再送信

A retransmission policy with a well-designed exponential backoff should be used if no reply is received for a message with "AckAll" set.

「Ackall」セットを使用したメッセージの返信がない場合は、適切に設計された指数バックオフを使用した再送信ポリシーを使用する必要があります。

3.4. Delete Branches Message
3.4. ブランチメッセージを削除します

The "Delete Branch Element" has a 4 bit Error field that should be redefined to match the size of the "Failure Response Codes".

「削除ブランチ要素」には、「障害応答コード」のサイズに合わせて再定義する必要がある4ビットエラーフィールドがあります。

3.5. Adjacency
3.5. 隣接

The chapter about how to handle a new adjacency and re-established adjacencies should be clarified.

新しい隣接と再確立された隣接を処理する方法についての章を明確にする必要があります。

3.5.1. Loss of Synchronization
3.5.1. 同期の喪失

The switch must not reset the connection states if another adjacency has already been established since this would destroy an already valid state.

これにより、すでに有効な状態が破壊されるため、別の隣接がすでに確立されている場合、スイッチは接続状態をリセットしてはなりません。

4. Security Considerations
4. セキュリティに関する考慮事項

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]で対処されています。この要件文書では、残りのセキュリティに関する潜在的な考慮事項は扱われていません。

5. Acknowledgements
5. 謝辞

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 DoriaとKenneth Sundellによって、相当額もこの作業に貢献したことを認めたいと考えています

The authors would like to acknowledge the careful review and comments of Dimitri Papadimitriou, Torbjorn Hedqvist, Satoru Okamoto, and Kohei Shiomoto.

著者は、Dimitri Papadimitriou、Torbjorn Hedqvist、Satoru Okamoto、およびKohei Shiomotoの慎重なレビューとコメントを認めたいと考えています。

6. References
6. 参考文献
6.1. Normative References
6.1. 引用文献

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

6.2. Informative References
6.2. 参考引用

[2] Berger, L., Ed., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003.

[2] Berger、L.、ed。、「Generalized MPLS-シグナル伝達機能説明」、RFC 3471、2003年1月。

[3] Mannie, E., et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Work in Progress, May 2003.

[3] Mannie、E.、et al。、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)アーキテクチャ」、2003年5月の作業。

[4] ITU-T Recommendation, "Architecture for the Automatically Switched Optical Network (ASON)", G.8080/Y.1304, January 2003

[4] ITU-Tの推奨、「自動化された光ネットワーク(ASON)のアーキテクチャ」、G.8080/Y.1304、2003年1月

[5] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General Switch Management Protocol V3", RFC 3292, June 2002.

[5] Doria、A.、Sundell、K.、Hellstrand、F。、およびT. Worster、「General Switch Management Protocol V3」、RFC 3292、2002年6月。

[6] Sadler, J., Mack-Crane, B., "TDM Labels for GSMP", Work in Progress, February 2001.

[6] Sadler、J.、Mack-Crane、B。、「GSMPのTDMラベル」、2001年2月、進行中の作業。

[7] Rajagopalan, B., et al., "IP over Optical Networks: A Framework", Work in Progress, September 2003.

[7] Rajagopalan、B.、et al。、「Ip over optical Networks:A Framework」、Work in Progress、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] Braden、R.、Clark、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、W。Weiss、_「差別化されたサービスのアーキテクチャ」、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. Qiao、M。Yoo、「光学バーストスイッチングの選択と機能と問題」、光ネット。Mag。、Vol.1、No.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] Ilia Baldine、George N. Rouskas、Harry G. Perros、Dan Stevension、「ジャンプスタート:WDMバーストスイッチングネットワークのジャストインタイムシグナリングアーキテクチャ」、IEEE Comm。雑誌、ファブ。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] Sanjeev Verma、et al。「光バーストスイッチング:Terabit IPバックボーンのための実行可能なソリューション」、IEEE Network、pp。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.、Doria、A。、およびJ. Buerkle、「ATM、Ethernet and TCPのGSMPパケットカプセル」、RFC 3293、2002年6月。

7. Authors' Addresses
7. 著者のアドレス

Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA

Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro、または97124 USA

   Phone: +1 503 264 0334
   EMail: hormuzd.m.khosravi@intel.com
        

Georg Kullgren Nortel Networks AB S:t Eriksgatan 115 A P.O. Box 6701 SE-113 85 Stockholm Sweden

Georg Kullgren Nortel Networks AB S:T ERIKSGATAN 115 A P.O.ボックス6701 SE-113 85ストックホルムスウェーデン

   EMail: geku@nortelnetworks.com
        

Jonathan Sadler Tellabs Operations, Inc. 1415 West Diehl Road Naperville, IL 60563

Jonathan Sadler Tellabs Operations、Inc。1415 West Diehl Road Naperville、IL 60563

   Phone: +1 630-798-6182
   EMail: Jonathan.Sadler@tellabs.com
        

Stephen Shew Nortel Networks PO Box 3511 Station C Ottawa, ON K1Y 4H7

Stephen Shew Nortel Networks PO Box 3511 Station C Ottawa、on K1Y 4H7

   EMail: sdshew@nortelnetworks.com
        

Kohei Shiomoto

小屋小屋

   EMail: 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
        

Satoru Okamoto Nippon Telegraph and Telephone Corporation 9-11 Midori-cho 3-chome, Musashino-shi Tokyo 180-8585, Japan

Satoru Okamoto Nippon Telegraph and Telephone Corporation 9-11 Midori-Cho 3-Chome、Musashino-Shi Tokyo 180-8585、日本

   EMail: okamoto@exa.onlab.ntt.co.jp
        
8. 完全な著作権声明

Copyright (C) The Internet Society (2003). All Rights Reserved.

Copyright(c)The Internet Society(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エディター機能の資金は現在、インターネット協会によって提供されています。