RFC3604 日本語訳

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

Khosraviがコメントのために要求するワーキンググループH.をネットワークでつないでください: 3604年のインテルカテゴリ: 情報のG.Kullgren S.シューノーテルはA.渡辺NTT2003年10月にJ.サドラーTellabsをネットワークでつなぎます。

               Requirements for Adding Optical Support to
       the General Switch Management Protocol version 3 (GSMPv3)

一般Switch Managementプロトコルバージョン3へのAdding Optical Supportのための要件(GSMPv3)

Status of this Memo

この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)インターネット協会(2003)。 All rights reserved。

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.

このメモは一般Switch Managementプロトコル(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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[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

このドキュメントは光学(非透過の、そして、すべて光学の)のSonet/SDHのサポート、およびIPパケット、Layer2(L2)フレーム、およびTDMデータの空間的な切り換えに必要なGSMPへの変化について詳述します。 実行されると、GSMPコントローラはその時、制御できるでしょう: (光学的に光学)の、そして、透明な光学十字が接続するフォトニック十字接続、(光学、電気、光学、フレーム独立者)、不透明な十字が接続する、(光学、電気、光学、Sonet/SDHフレーム)

Khosravi, et al.             Informational                      [Page 1]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[1ページ]のRFC3604

   traditional TDM switches (all electrical).  The resulting systems
   could form IP based optical routers, optical label switches,
   wavelength routers, and dynamic optical cross connects.

伝統的な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]にコントロール飛行機の機能性を提供する方法を定義しながら、存在しています。 このドキュメントはどのモデルが最も適切であるかの(例えば、単一であるか複数のルーティング飛行機例)立場を全く取りません。 唯一の仮定はデータの切り換えと制御機構を切り離す能力が光路(例えば、GMPLS)のシグナリングにそれがL2経路(例えば、MPLS)のシグナリングのためのものであるのと同じくらい役に立つということです。 したがって、含まれた要件は、よりフレキシブルなネットワークアーキテクチャを提供するために中でデータ機能からコントロール機能の分離だけに焦点を合わせられます。

   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実現の、より簡単な開発を容易にするimplementersによって推薦された変化を含んでいます。 これらの変化は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

- デジタルCarrier Hierarchy(例えば、DS-1、E1)--SonetとSDH Hierarchy(例えば、OC-3、STM-1、VT1.5、VC-12)--Plesiochronous Data Hierarchy(PDH)ラベル[6]--OTN G.709ラベル--λ--ファイバー

Khosravi, et al.             Informational                      [Page 2]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[2ページ]のRFC3604

   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 MUSTはGMPLSによって定義されるラベル階層構造とラベル・リストのようにすべてのラベル形式リストのサポートを含んでいます。 したがって、また、上のラベルのグループに操作を実行する能力を支持しなければなりません(例えば、5OC-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).

アップデートされたラベル範囲メッセージを提供しなければなりません。 また、(例えば、多重送信でない、Sonet、などを多重送信するGigabitイーサネット)を多重送信するサポートがあるに違いありません。

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と共用していない多くの異なった統計があるか、またはFrame Relayは切り替わります。 その結果、統計はSHOULDを通信させます。アップデートして、すべての新しい光学輸送技術のために定義されたパフォーマンスMonitoring統計が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.

Optical Switchが複数のトランスポート層(すなわち、STS-3c、STS-1、バーモント-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.

したがって、光学スイッチが切り換えを実行できるトランスポート層のリストを提供するためにSwitch Configurationメッセージを広げなければなりません。

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.

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

Khosravi, et al.             Informational                      [Page 3]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[3ページ]のRFC3604

2.3.2.1.  Port Type extensions

2.3.2.1. ポートType拡張子

   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

- 1インタフェースあたり有効な波長--1波長あたりのビット伝送速度--ファイバーのタイプ

2.3.2.2.  Supported Signal Type extensions

2.3.2.2. 支持されたSignal Type拡張子

   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の光学スイッチに関しては、ポートによって支えられる異なったトランスポート層信号について詳述するためにPort構成メッセージを広げなければなりません。 その上、この拡大は、どの信号が別の信号によって輸送されるかもしれないかを詳しく述べなければなりません。

   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. 跡のMechanismサポートIdentification

   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.

それの跡のメカニズムがポートによってサポートされるレポートにPort Configurationメッセージを広げなければなりません。

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.

現代のOpticalスイッチが潜在的に同じくらい多くの湾に位置する何百個もの棚に何万ものポートを支える能力を持っているので、現在の「スロット/ポート」位置の識別子は不十分です。

Khosravi, et al.             Informational                      [Page 4]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[4ページ]のRFC3604

   The Slot/Port Location Identifier MUST be extended to encode
   Bay/Shelf/Slot/Port.

湾/棚/スロット/ポートをコード化するためにSlot/ポートLocation Identifierを広げなければなりません。

2.3.2.5.  Port-related Partitioning Extensions

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は各接続が特定の属性で創造される手段を提供します。 したがって、サービスパラメタは、それぞれのDifferent Optical技術のために定義される必要があるでしょう。

2.4.1.  Transparent Optical

2.4.1. 透明である、光学

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

ポートレベルあたりのaで再タイミングと再形成を制御する能力を加えなければなりません。

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]

輸送信号が別の輸送信号に挿入されるとき使用される適合パラメタを制御する能力を加えなければなりません。 これらのパラメタSHOULD、Tandem Connection Monitoringなどの機能を構成できるようにブランチを加えるのを除いて、時には、修正できてください。 現在、GSMPのサービスモデルのデフォルトセットは皆、ほかの場所で定義されたサービスモデルに基づいています、例えば、Intservモデル[9]、[10]、Diffserv[11]

Khosravi, et al.             Informational                      [Page 5]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[5ページ]のRFC3604

   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はモデル化します、そして、モデル化してください、そして、Frameはフォーラム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).

ワーキンググループは、新しいカプセル化が必要であるかどうか決める必要があります。 言い換えれば、GSMPコントローラとOpticalスイッチ(GSMP目標)に接する制御チャンネルの上に実行されて、光学スイッチがOpticsの上のMPLSと光学アプリケーションの上のIPが必要とするIPがあるどちらかで使用したすべてがそうするでしょう。

   A new encapsulation SHOULD be defined allowing the use of a non-IP
   raw wavelength control connection.

新しいカプセル化SHOULD、非IPの未熟な波長コントロール接続の使用を許しながら、定義されてください。

   Likewise, a new encapsulation SHOULD be defined allowing GSMP to be
   used in legacy Data Communication Network (DCN) environments that use
   OSI CLNP.

同様に新しいカプセル化SHOULD、GSMPがOSI CLNPを使用する遺産Data Communication Network(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のメカニズムを実行するのがRFC3293イーサネットのようにこれらの制御チャンネルに利用可能でないことをATMケース以来。 危険分析を実行して、リンク・レベルセキュリティのためのメカニズムが危険を緩和するかどうか説明するために、それは範囲にあります。

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.

新しいカプセル化が定義されるなら、カプセル化はSHOULDを分類します。アップデートします。 他の変化を全く必要とするべきではありません。

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.

多くの既存のOXCsが連続の取引モデルに就くコマンドインタフェースを使用します。 既存のコマンドが終了するまで、すなわち、新しいコマンドを発行できませんし、処理できません。 ネットワークマネージメントアプリケーションでコントロールに食糧を供給する、および非動態的経路セットアップで、このモデルは適切です。

   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コントローラは、これにおいて知識があって、連続の取引の振舞いを採用しなければなりません。

Khosravi, et al.             Informational                      [Page 6]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[6ページ]のRFC3604

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接続をセットアップするのにいくつかのOXCsを要するかもしれない時のために、同じメッセージにおける送付多数の取引のサポートは役に立つ最適化です。 OXCが大量のメッセージを受け取るとき、個々の取引に作用します、そして、ただ一つの回答を送ります。 平行取引が支持されないなら、大量のメッセージは取引オーバーヘッドを下げるのによる性能を向上させることができます。 取引SHOULDを膨らませてください。支持されます。

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.

性能(例えば、失敗検出の後の50ms)、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.

これはLayer2スイッチのためのGSMPで次に、GSMPコントローラの如何にかかわらず訴訟を起こして、OXCがその後ここでコントローラを知らせることができるという点において厳しいマスター奴隷関係と異なっています。 その結果、自動保護の振舞いがNetwork Elementに食糧を供給されるのを許容するために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.  Non-Reserved Protection Links

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.

保護OXCの振舞いに関する例はリンクが失敗するとき、バックアップリンクが交通を保護するのにおいて使用されているかもしれないということです。 1セットのリンクからこのバックアップリンクを選択できました。そのいずれもプレ予約されていません。 バックアップリンクを1つと共有できましたか、またはリンクをより「扱っ」て、どれが1:nのフォームであるかは保護を共有しました。 可能のバックアップがSHOULDをリンクするのをセットを指定して、オプションとしてAdd支店メッセージにしてください。

Khosravi, et al.             Informational                      [Page 7]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[7ページ]のRFC3604

   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は通信します。コントローラSHOULDに知らせるには、これをすると言い足されてください。

2.8.2.  Dedicated Protection Links

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 」 経路を扱う当然のことのために輸送/光学のネットワークで(通常、ノードはばらばらになります)保護経路を定義します。 経路へのイングレスノードでは、同時に、働きと保護経路の両方に沿って信号を送ります。 出口ノードにおける非失敗条件のもとでは、働く経路の最後のリンクだけがクライアントに接続されます。 働く経路のどれかリンクが失敗すると、働く経路における交通は、経路の端に受け取られるのをやめます。 出口OXCは、この状態を検出して、次に、Moveによって入力された支店のメッセージを発行しなければならないコントローラなしで保護経路の最後のリンクを使用するために切り替わります。 いかなる時も、イングレスノードは出口ノードがどのリンクを使用しているかを意識していません。 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.

普通のAdd-支店意味論でイングレスノードの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.

Add-支店メッセージを送るとき、出口ノードの2つの入力ブランチの仕様をするべきです。 このSHOULD、そのメッセージへのオプションになってください。 出口のノード保護リンクはいかなる他の働くリンクとも共有されません。

   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は通信します。コントローラSHOULDに知らせるには、これをすると言い足されてください。

   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.

代替入力ポートがオリジナルのAdd支店メッセージで指定されないなら、それはその後のAdd-支店メッセージで指定されるかもしれません。 この場合、そのAdd-支店メッセージに出力ポートの既存のユーザの情報を含んでいるのは役に立ちます。 これは、OXCがすぐに新しい入力ポートと既存のものとの協会を知るのを助けます。 協会は、OXC保護手順を可能にするのに使用されます。 この能力を加えなければならない、ブランチメッセージを加えてください。

Khosravi, et al.             Informational                      [Page 8]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[8ページ]のRFC3604

   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が、経路が保護がなくなるかどうか決定できるくらいDelete-支店メッセージに必要です。 Delete-ブランチメッセージにこの能力を追加しなければなりません。

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.

バックアップ/保護リンクがAdd-支店メッセージで定義されるとき、これらの引き金を指定するのは役に立つかもしれません。 これはOXCがそのような引き金を意識しているためにどう実行されるかによります。 さらなる研究にはこれがあります。

2.8.4.  Protection Link Capabilities

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にOptical Call Controller(OCC)から保護の切り換えを独自に実行する能力があるとき、OCCがスイッチでこれらの能力において知識がある、そして/または、構成を移植するのは、役に立つかもしれません。 GSMPコントローラのアプリケーションはこの情報を使用するかもしれません。 例えば、シグナリングクライアントは経路を指定できました。保護計画は複数のGSMPの上でOXCsを有効にしました。 さらなる研究にはこれがあります。

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旗を考慮しない、ブランチメッセージを加えてください。 これは、両性愛者の方向の接続の原子交換をするのが可能でないことを意味します--コントローラの指示された回復に、望ましい動作。 その結果、これらの旗が同時に使用されるのを許容するためにプロトコルを変えなければなりません。

Khosravi, et al.             Informational                      [Page 9]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[9ページ]のRFC3604

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.

また、Optical Switchingのための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コントローラが時間の適切なConnection Admission Controlを実行しなければならなくて、持続時間は、指定して、接続が許されているなら、正確な帯域幅必要な[12]([14])を予約するように炸裂切換装置へのこれらのパラメタに示さなければなりません。 炸裂スイッチは自主的に切り換え操作を実行しなければなりません、それが作動している炸裂ネットワークに定められた同期方法を使用して。

3.  Requirements from Implementers

3. Implementersからの要件

   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におけるBasic GSMP Message FormatはAdjacencyプロトコル以外のすべての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を超えているなら、それは区分されなければなりません。 元々、Result分野で「より多く」の値でこれをしました。 I旗とヘッダーへのSubMessage Numberの添加で、「より多く」の値が時代遅れになりました。

   The I flag and SubMessage numbers should be used in all messages that
   can be segmented.

I旗とSubMessage番号は区分できるすべてのメッセージで使用されるべきです。

3.1.1.1.  SubMessage Number and I flag

3.1.1.1. SubMessage Numberと私は弛みます。

   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.

SubMessage Numberが区分されたメッセージの0か1を始めるかどうかと、I旗が区分されないメッセージにどんな値を持っているはずであるかは指定されるべきです。

Khosravi, et al.             Informational                     [Page 10]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[10ページ]のRFC3604

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.

どんな価値の明確化は区分されたメッセージにLength分野で使用されるべきであるか。 明確に、Length分野はメッセージの全長か現在のセグメントの長さを含んでいますか?

3.1.1.3.  Message Segmentation example

3.1.1.3. メッセージSegmentationの例

   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]のTransaction Identifierは"AckAll"と"NoSuccessAck"との要求と回答を見分けません。 また、それはTransaction IDが以前に送られた要求からTransaction 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.

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章で定義されたSwitch Configuration MessageはWindowサイズを定義します。 この窓がすべてのメッセージに適用されるはずであるか、またはそれが回答をメッセージだけにいつも発生させるなら、それは述べられません。

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

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

"AckAll"がセットした状態でメッセージのために回答を全く受け取らないなら、よく設計された指数のbackoffがある「再-トランスミッション」方針を使用するべきです。

Khosravi, et al.             Informational                     [Page 11]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[11ページ]のRFC3604

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ビットのError分野があります。

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.

[15]にGSMPのTCP/IP制御チャンネルのセキュリティを記述してあります。 どんな潜在的残っているセキュリティ問題もこの要件ドキュメントに記述されません。

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ドーリアとケネス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、Satoru岡本、および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] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

6.2.  Informative References

6.2. 有益な参照

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

[2] バーガー、L.、エド、「機能的な記述に合図して、MPLSを一般化した」、RFC3471、1月2003日

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

[3] マニー、E.、他、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)構造」、Progress、2003年5月のWork。

Khosravi, et al.             Informational                     [Page 12]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[12ページ]のRFC3604

   [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] ドーリア、A.、Sundell、K.、Hellstrand、F.、およびT.オースター、「一般スイッチ経営者側は2002年6月にV3"、RFC3292について議定書の中で述べます」。

   [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 Recommendation、「転送ネットワークの一般的な機能的な建築」、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、「インターネット構造における統合サービス:」 「概観」、RFC1633、1994年6月。

   [10] Wroclawski, J., "Specification of the Controlled-Load Network
        Element Service", RFC 2211, September 1997.

[10]Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、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.ウィス、_「微分されたサービスのための構造」、RFC2475、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.ユーと、「光学炸裂の切り換えにおける選択、特徴、および問題」、光学ネット。 雑誌、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] 腸骨Baldine(ジョージN.Rouskas、ハリーG.Perros、ダン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、他 「以下を切り換える光学炸裂」 「テラビット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] オースターとT.とドーリアとA.とJ.Buerkle、「気圧、イーサネット、およびTCPのためのGSMPパケットカプセル化」、RFC3293、2002年6月。

Khosravi, et al.             Informational                     [Page 13]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[13ページ]のRFC3604

7.  Authors' Addresses

7. 作者のアドレス

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

Hormuzd Khosraviインテル2111NE第25Avenueヒースボロー、または97124米国

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

以下に電話をしてください。 +1 0334年の503 264メール: 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ノーテルはAB S: 私書箱6701SE-113 85ストックホルムスウェーデンあたりt Eriksgatan115をネットワークでつなぎます。

   EMail: geku@nortelnetworks.com

メール: geku@nortelnetworks.com

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

ジョナサンサドラーTellabs OperationsのInc.1415の西ディール・Roadナパービル、イリノイ 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

スティーブンシューノーテルは私書箱3511駅のCオタワをK1Y 4H7にネットワークでつなぎます。

   EMail: sdshew@nortelnetworks.com

メール: sdshew@nortelnetworks.com

   Kohei Shiomoto

Kohei Shiomoto

   EMail: Shiomoto.Kohei@lab.ntt.co.jp

メール: Shiomoto.Kohei@lab.ntt.co.jp

Khosravi, et al.             Informational                     [Page 14]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[14ページ]のRFC3604

   Atsushi Watanabe
   Nippon Telegraph and Telephone Corporation
   807A 1-1 Hikari-no-oka, Yokosuka-shi
   Kanagawa 239-0847, Japan

光ノー、がokaしている篤渡辺NTT807A1-1横須賀市神奈川239-0847(日本)

   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

Satoru岡本日本電信電話会社9-11テロ美土里町3丁目の武蔵野市東京180-8585(日本)

   EMail: okamoto@exa.onlab.ntt.co.jp

メール: okamoto@exa.onlab.ntt.co.jp

Khosravi, et al.             Informational                     [Page 15]

RFC 3604            Adding Optical Support to GSMPv3        October 2003

Khosravi、他 光のサポートをGSMPv3 October 2003に加える情報[15ページ]のRFC3604

8.  Full Copyright Statement

8. 完全な著作権宣言文

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

Copyright(C)インターネット協会(2003)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Khosravi, et al.             Informational                     [Page 16]

Khosravi、他 情報[16ページ]