Network Working Group D. Papadimitriou
Request for Comments: 4139 Alcatel
Category: Informational J. Drake
Boeing
J. Ash
ATT
A. Farrel
Old Dog Consulting
L. Ong
Ciena
July 2005
Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)
自動的に交換光ネットワーク（ASON）の使用上のシグナリング一般化MPLS（GMPLS）の要件と拡張機能
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 (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).
一般マルチプロトコルラベルスイッチング（GMPLS）プロトコルのスイートは異なるスイッチング技術と異なるアプリケーションを制御するために定義されています。これらは、同期光ネットワーク（SONET）/同期デジタル階層（SDH）および光トランスポートネットワーク（OTNs）を含む時分割多重（TDM）接続を要求するためのサポートが含まれています。
This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signaling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for the GMPLS signaling protocol to support the ASON functionality.
この文書では、プロトコルのGMPLSスイートのシグナリング側面に集中します。これは、機能が自動的に交換光ネットワーク（ASON）の機能をサポートするためのシグナリングプロトコルGMPLSでカバーされるように識別します。この文書では、問題文のとASONの機能をサポートするためのシグナリングプロトコルGMPLSのための追加要件を提供します。
The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocol specifications provides support for controlling different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) (see [ANSI-T1.105] and [ITU-T-G.707], respectively), and Optical Transport Networks (see [ITU-T-G.709]). In addition, there are certain capabilities needed to support Automatically Switched Optical Networks control planes (their architecture is defined in [ITU-T-G.8080]). These include generic capabilities such as call and connection separation, along with more specific capabilities such as support of soft permanent connections.
プロトコル仕様の汎用マルチプロトコルラベルスイッチング（GMPLS）スイートは、異なるスイッチング技術と異なるアプリケーションを制御するためのサポートを提供します。これらは、同期光ネットワーク（SONET）/同期デジタル階層（SDH）を含む時分割多重（TDM）接続を要求するためのサポートが含まれます（[ANSI-T1.105]をそれぞれ[ITU-TG.707]、）、および光トランスポート・ネットワーク（[ITU-TG.709]を参照してください）。また、自動交換光ネットワークの制御プレーンをサポートするために必要な特定の機能は、（そのアーキテクチャは[ITU-T、G.8080]で定義されている）があります。これらは、ソフト永続的な接続のサポートなど、より具体的な機能に加えて、このような呼び出しと接続分離などの一般的な機能を、含まれています。
This document concentrates on requirements related to the signaling aspects of the GMPLS suite of protocols. It discusses the functional requirements required to support Automatically Switched Optical Networks that may lead to additional extensions to GMPLS signaling (see [RFC3471] and [RFC3473]) to support these capabilities. In addition to ASON signaling requirements, this document includes GMPLS signaling requirements that pertain to backward compatibility (Section 5). A terminology section is provided in the Appendix.
この文書では、プロトコルのGMPLSスイートのシグナリング側面に関連する要件に集中します。これは、これらの機能をサポートするために、（[RFC3471]と[RFC3473]を参照）GMPLSシグナリングに追加的な拡張につながる可能性を自動的に交換光ネットワークをサポートするために必要な機能要件について説明します。 ASONシグナリング要件に加えて、この文書は、後方互換性（セクション5）に関連する要件をGMPLSシグナリングを含みます。専門用語のセクションは、付録に記載されて。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
While [RFC2119] describes interpretations of these key words in terms of protocol specifications and implementations, they are used in this document to describe design requirements for protocol extensions.
[RFC2119]は、プロトコルの仕様と実装の観点からこれらのキーワードの解釈について説明しているが、それらはプロトコル拡張のための設計要件を記述するために、このドキュメントで使用されています。
The Automatically Switched Optical Network (ASON) architecture describes the application of an automated control plane for supporting both call and connection management services (for a detailed description see [ITU-T-G.8080]). The ASON architecture describes a reference architecture, (i.e., it describes functional components, abstract interfaces, and interactions).
自動光ネットワーク（ASON）アーキテクチャを交換（詳細については[ITU-T、G.8080]を参照）の両方の呼接続管理サービスをサポートするための自動制御プレーンのアプリケーションを記述する。 ASONアーキテクチャ（すなわち、それは機能的な構成要素、抽象インタフェース、および相互作用を記述する）、参照アーキテクチャを記述する。
The ASON model distinguishes reference points (representing points of information exchange) defined (1) between a user (service requester) and a service provider control domain, a.k.a. user-network interface (UNI), (2) between control domains, a.k.a. external network-network interface (E-NNI), and, (3) within a control domain, a.k.a. internal network-network interface (I-NNI). The I-NNI and E-NNI interfaces are between protocol controllers, and may or may not use transport plane (physical) links. It must not be assumed that there is a one-to-one relationship between control plane interfaces and transport plane (physical) links, control plane entities and transport plane entities, or control plane identifiers for transport plane resources.
ASONモデルは、外部ネットワーク別名、（2）制御ドメインとの間に、ユーザネットワークインタフェース（UNI）別名、ユーザ（サービス要求）とサービスプロバイダの制御ドメインとの間に（1）定義された（情報交換の点を表す）の基準点を識別する-networkインタフェース（E-NNI）、および、（3）制御ドメイン内、別名内部ネットワークネットワークインターフェース（I-NNI）。 I-NNIおよびE-NNIインターフェイスは、プロトコルコントローラとの間であり、または搬送面（物理的な）リンクを使用してもしなくてもよいです。トランスポート・プレーンリソースのコントロールプレーンインターフェイスと搬送面との間に1対1の関係（物理的な）リンク、制御プレーンエンティティと、トランスポート・プレーンエンティティ、または制御プレーン識別子が存在すると仮定してはなりません。
This document describes requirements related to the use of GMPLS signaling (in particular, [RFC3471] and [RFC3473]) to provide call and connection management (see [ITU-T-G.7713]). The functionality to be supported includes:
この文書では、（[ITU-T、G.7713]を参照）呼接続管理を提供するために（特に、[RFC3471]及び[RFC3473]）をGMPLSシグナリングの使用に関連する要件を記述する。サポートする機能が含まれています：
(a) soft permanent connection capability (b) call and connection separation (c) call segments (d) extended restart capabilities during control plane failures (e) extended label association (f) crankback capability (g) additional error cases
（a）は、ソフト永久接続機能（b）は、コールと接続分離（C）コールセグメント（d）の制御プレーン障害時リスタート機能を拡張（E）拡張ラベルアソシエーション（f）はクランクバック機能（G）追加のエラーケース
The following sections detail the signaling protocol requirements for GMPLS to support the ASON functions listed in Section 3. ASON defines a reference model and functions (information elements) to enable end-to-end call and connection support by a protocol across the respective interfaces, regardless of the particular choice of protocol(s) used in a network. ASON does not restrict the use of other protocols or the protocol-specific messages used to support the ASON functions. Therefore, the support of these ASON functions by a protocol shall not be restricted by (i.e., must be strictly independent of and agnostic to) any particular choice of UNI, I-NNI, or E-NNI used elsewhere in the network. To allow for interworking between different protocol implementations, [ITU-T-G.7713] recognizes that an interworking function may be needed.
以下のセクションで詳細GMPLSのシグナリングプロトコル要件はASONは、それぞれのインタフェースを横切るプロトコルによってエンド・ツー・エンドの呼と接続サポートを可能にするために、基準モデルと機能（情報要素）を定義するセクション3に記載されているASON機能をサポートするために、かかわらずプロトコル（単数または複数）の特定の選択のネットワークで使用されます。 ASONは、他のプロトコルやASON機能をサポートするために使用されるプロトコル固有のメッセージの使用を制限するものではありません。したがって、プロトコルによってこれらASON機能のサポートをすることによって限定されるものではない（すなわち、厳密に独立とに依存しないでなければならない）UNIの任意の特定の選択、I-NNI、またはE-NNIは、ネットワーク内の他の場所で使用されます。異なるプロトコル実装間のインターワーキングを可能にするために、[ITU-T、G.7713]はインターワーキング機能が必要とされ得ることを認識する。
In support of the G.8080 end-to-end call model across different control domains, end-to-end signaling should be facilitated regardless of the administrative boundaries, protocols within the network, or the method of realization of connections within any part of the network. This implies the need for a clear mapping of ASON signaling requests between GMPLS control domains and non-GMPLS control domains. This document provides signaling requirements for G.8080 distributed call and connection management based on GMPLS, within a GMPLS based control domain (I-NNI), and between GMPLS based control domains (E-NNI). It does not restrict use of other (non GMPLS) protocols to be used within a control domain or as an E-NNI or UNI. Interworking aspects related to the use of non-GMPLS protocols, such as UNI, E-NNI, or I-NNI -- including mapping of non-GMPLS protocol signaling requests to corresponding ASON signaling functionality and support of non-GMPLS address formats -- is not within the scope of the GMPLS signaling protocol. Interworking aspects are implementation-specific and strictly under the responsibility of the interworking function and, thus, outside the scope of this document.
異なる管理ドメイン間G.8080のエンド・ツー・エンドの呼モデルのサポートでは、エンドツーエンドシグナリングは、任意の部分内にかかわらず、管理境界、ネットワーク内のプロトコル、または接続の実現方法の促進すべきですネットワーク。これは、GMPLS制御ドメインと非GMPLS制御ドメイン間のASONシグナリング要求の明確なマッピングの必要性を意味します。この文書では、GMPLSベースの制御ドメイン（I-NNI）内、及びGMPLSベースの制御ドメイン（E-NNI）との間に、GMPLSに基づいG.8080分散型コール及び接続管理のためのシグナリング要件を提供します。なお、制御ドメイン内またはE-NNIまたはUNIとして使用する他の（非GMPLS）プロトコルの使用を制限しません。非GMPLSアドレス形式のASONシグナリング機能とサポートの対応する要求シグナリング非GMPLSプロトコルのマッピングを含む - そのようなUNI、E-NNI、またはI-NNIとして非GMPLSプロトコルの使用に関連する側面をインターワーキング - GMPLSシグナリングプロトコルの範囲内ではありません。インターワーキングの側面は、この文書の範囲外で、したがって、実装に固有のものであり、厳密に相互接続機能の責任の下で。
By definition, any User-Network Interface (UNI) that is compliant with [RFC3473] (e.g., [GMPLS-OVERLAY] and [GMPLS-VPN]) is considered to be included within the GMPLS suite of protocols and MUST be supported by the ASON GMPLS signaling functionality.
定義により、任意のユーザネットワークインタフェース（UNI）に準拠して、[RFC3473]（例えば、[GMPLSオーバーレイ]と[-VPNは、GMPLS]）プロトコルのGMPLSスイート内に含まれることによってサポートしなければならないと考えられています機能性シグナルASON GMPLS。
Compatibility aspects of non-GMPLS systems (nodes) within a GMPLS control domain (i.e., the support of GMPLS systems and other systems that utilize other signaling protocols or some that may not support any signaling protocols) is described. For example, Section 4.5, 'Support for Extended Label Association', covers the requirements for when a non-GMPLS capable sub-network is introduced or when nodes do not support any signaling protocols.
GMPLS制御ドメイン内の非GMPLSシステム（ノード）の互換性の側面（即ち、GMPLSシステム及び任意のシグナリングプロトコルをサポートしないかもしれない他のシグナリングプロトコルまたはいくつかを利用する他のシステムのサポート）について説明します。たとえば、4.5節には、「拡張ラベル協会のサポートは」ノードは任意のシグナリングプロトコルをサポートしていない時に非GMPLS対応のサブネットワークが導入されたとき、またはのための要件をカバーしています。
A Soft Permanent Connection (SPC) is a combination of a permanent connection at the source user-to-network side, a permanent connection at the destination user-to-network side, and a switched connection within the network. An Element Management System (EMS) or a Network Management System (NMS) typically initiates the establishment of the switched connection by communicating with the node that initiates the switched connection (also known as the ingress node). The latter then sets the connection using the distributed GMPLS signaling protocol. For the SPC, the communication method between the EMS/NMS and the ingress node is beyond the scope of this document (as it is for any other function described in this document).
ソフト常時接続（SPC）は、ソースユーザ対ネットワーク側の永久接続、宛先ユーザ対ネットワーク側の永久接続、およびネットワーク内の交換接続の組み合わせです。要素管理システム（EMS）またはネットワーク管理システム（NMS）は、典型的には、（これも入口ノードとしても知られる）交換接続を開始するノードと通信することにより交換接続の確立を開始します。後者は、分散GMPLSシグナリングプロトコルを使用して接続を設定します。 （この文書に記載された他の機能のためであるように）SPCのために、EMS / NMSと入口ノードとの間の通信方法は、この文書の範囲外です。
The end-to-end connection is thus created by associating the incoming interface of the ingress node with the switched connection within the network, along with the outgoing interface of the switched connection terminating network node (also referred to as egress node). An SPC connection is illustrated in the following figure. This shows the user's node A connected to a provider's node B via link #1, the user's node Z connected to a provider's node Y via link #3, and an abstract link #2 connecting the provider's node B and node Y. Nodes B and Y are referred to as the ingress and egress (respectively) of the network switched connection.
エンドツーエンド接続は、このように（また、出口ノードと称す）に切り替え接続終端ネットワークノードの発信インターフェイスと共に、ネットワーク内の交換結合と入口ノードの着信インターフェイスを関連付けることによって作成されます。 SPCの接続は、次の図に示します。これは、リンク＃3、及びプロバイダのノードBとノードYとノードBを接続する抽象リンク＃2を介してリンク＃1を介してプロバイダのノードBに接続されたユーザのノードA、プロバイダのノードYに接続されたユーザのノードZを示し、 Y接続を交換ネットワークの（それぞれ）入口と出口と呼ばれます。
--- --- --- ---
| A |--1--| B |-----2-//------| Y |--3--| Z |
--- --- --- ---
In this instance, the connection on link #1 and link #3 are both provisioned (permanent connections that may be simple links). In contrast, the connection over link #2 is set up using the distributed control plane. Thus, the SPC is composed of the stitching of link #1, #2, and #3.
この場合、リンク＃1及びリンク＃3の接続は、両方の（単純なリンクとすることができる永久的な接続）プロビジョニングされます。対照的に、リンク＃2を介した接続は、分散型制御プレーンを使用して設定されています。したがって、SPCは、リンク＃1、＃2、＃3のステッチで構成されています。
Thus, to support the capability of requesting an SPC connection:
このように、SPCの接続を要求する機能をサポートします：
- The GMPLS signaling protocol MUST be capable of supporting the ability to indicate the outgoing link and label information used when setting up the destination provisioned connection.
- GMPLSシグナリングプロトコルは、宛先プロビジョニング接続を設定するときに使用される発信リンクとラベル情報を示す能力をサポートできなければなりません。
- In addition, due to the inter-domain applicability of ASON networks, the GMPLS signaling protocol SHOULD also support indication of the service level requested for the SPC. In cases where an SPC spans multiple domains, indication of both source and destination endpoints controlling the SPC request MAY be needed. These MAY be done via the source and destination signaling controller addresses.
- また、起因ASONネットワークのドメイン間の適用に、シグナリングプロトコルGMPLSはまた、SPCのために要求されたサービスレベルの表示をサポートしなければなりません。 SPCは、複数のドメインにまたがる場合には、SPC要求を制御する両方のソースと宛先エンドポイントの表示が必要とされ得ます。これらは、ソースと宛先シグナリングコントローラアドレスを介して行われてもよいです。
Note that the association at the ingress node, between the permanent connection and the switched connection, is an implementation matter that may be under the control of the EMS/NMS and is not within the scope of the signaling protocol. Therefore, it is outside the scope of this document.
永久的な接続と切り替え接続の間に入口ノードにおける関連付けは、EMS / NMSの制御下にあり得る実装問題であり、シグナリングプロトコルの範囲内ではないことに留意されたいです。したがって、この文書の範囲外です。
A call may be simply described as "An association between endpoints that supports an instance of a service" [ITU-T-G.8080]. Thus, it can be considered a service provided between two end-points, wherein several calls may exist between them. Multiple connections may be associated with each call. The call concept provides an abstract relationship between two users. This relationship describes (or verifies) the extent to which users are willing to offer (or accept) service to/from each other. Therefore, a call does not provide the actual connectivity for transmitting user traffic; it only builds a relationship by which subsequent connections may be made.
コールは、単に[ITU-T、G.8080]「サービスのインスタンスをサポートするエンドポイントとの間の関連付け」として説明することができます。したがって、いくつかのコールが、それらの間に存在してもよく、2つのエンドポイント間に提供されるサービスと考えることができます。複数の接続は、各コールに関連付けられてもよいです。コールのコンセプトは、二人のユーザ間の抽象関係を提供します。この関係は、ユーザーが提供し（または受け入れる）ことを喜んでいる程度に/お互いからサービスを記述する（または検証）。そのため、コールはユーザトラフィックを送信するための実際の接続性を提供していません。それだけで後続の接続がなされてもよいことで関係を構築します。
A call MAY be associated with zero, one, or multiple connections. For the same call, connections MAY be of different types and each connection MAY exist independently of other connections (i.e., each connection is setup and released with separate signaling messages).
コールは、ゼロ、1つ、または複数の接続に関連付けられてもよいです。同一の呼に対して、接続は、異なるタイプであってもよく、各接続は独立して他の接続（すなわち、各接続がセットアップと別個のシグナリングメッセージで放出される）で存在し得ます。
The concept of the call allows for a better flexibility in how end-points set up connections and how networks offer services to users. For example, a call allows:
コールの概念は、エンドポイントは接続をセットアップし、どのようにネットワークがユーザーにサービスを提供する方法でより良い柔軟性を実現しています。例えば、通話ができます。
- An upgrade strategy for control plane operations, where a call control component (service provisioning) may be separate from the actual nodes hosting the connections (where the connection control component may reside).
- 呼制御コンポーネント（サービスプロビジョニング）が（接続制御成分が存在することができる）接続をホストしている実際のノードから分離することができる制御プレーン動作、のアップグレード戦略。
- Identification of the call initiator (with both network call controller, as well as destination user) prior to connection, which may result in decreasing contention during resource reservation.
- リソース予約の際に競合を減少させることをもたらすことができる接続の前に（ネットワーク呼制御装置、並びに宛先ユーザの両方を有する）コール開始剤の同定。
- General treatment of multiple connections, which may be associated for several purposes; for example, a pair of working and recovery connections may belong to the same call.
- いくつかの目的のために関連付けることができる複数の接続の一般的な処置;例えば、作業や復旧の接続のペアは、同じコールに属していてもよいです。
To support the introduction of the call concept, GMPLS signaling SHOULD include a call identification mechanism and SHOULD allow for end-to-end call capability exchange.
コール概念の導入をサポートするために、GMPLSシグナリングは呼識別機構を含むべきであり、エンド・ツー・エンドの呼能力交換を可能にすべきです。
For instance, a feasible structure for the call identifier (to guarantee global uniqueness) MAY concatenate a globally unique fixed ID (e.g., may be composed of country code or carrier code) with an operator specific ID (where the operator specific ID may be composed of a unique access point code - such as source node address - and a local identifier). Other formats SHALL also be possible, depending on the call identification conventions between the parties involved in the call setup process.
例えば、呼識別子の実現可能な構造は、（グローバル一意性を保証するために）、グローバルに一意な固定IDを連結（例えば、国コードまたはキャリアコードで構成されてもよい）、オペレータ固有のIDを構成することができるオペレータ固有のID（とそのようなソースノードアドレスとして - - ユニークなアクセスポイントコードとローカル識別子）。他のフォーマットも、コールセットアッププロセスに関わる当事者間の呼識別規則に応じて、可能なものでなければなりません。
As described in [ITU-T-G.8080], call segmentation MAY be applied when a call crosses several control domains. As such, when the call traverses multiple control domains, an end-to-end call MAY consist of multiple call segments. For a given end-to-end call, each call segment MAY have one or more associated connections, and the number of connections associated with each call segment MAY be different.
[ITU-T、G.8080]に記載されているように、呼が複数の制御領域を横切る場合、呼び出しセグメンテーションを適用することができます。呼が複数の制御領域を横断するときのような、エンド・ツー・エンドの呼は、複数の呼セグメントから構成されてもよいです。所与のエンド・ツー・エンドの呼について、各呼セグメントは、一つ以上の関連する接続を有していてもよく、各呼セグメントに関連付けられた接続の数が異なっていてもよいです。
The initiating caller interacts with the called party by means of one or more intermediate network call controllers, located at control domain boundaries (i.e., at inter-domain reference points, UNI or E-NNI). Call segment capabilities are defined by the policies associated at these reference points.
開始発信者は、制御ドメインの境界に位置する1つの以上の中間ネットワーク呼制御装置（すなわち、ドメイン間の基準点で、UNIまたはE-NNI）によって被呼者と対話します。コールセグメント機能は、これらの基準点に関連付けられたポリシーによって定義されています。
This capability allows for independent (policy based) choices of signaling, concatenation, data plane protection, and control plane driven recovery paradigms in different control domains.
この機能は、異なる制御ドメインにおける独立の（ベースのポリシー）シグナリング、連結の選択、データプレーンの保護、及び制御プレーン駆動回復パラダイムを可能にします。
Various types of failures may occur, affecting the ASON control plane. Requirements placed on control plane failure recovery by [ITU-T-G.8080] include:
障害の各種ASONの制御プレーンに影響を与える、起こり得ます。 [ITU-T、G.8080]によって制御プレーンの障害回復に載置された要件は、次のとおり
- Any control plane failure (i.e., single or multiple control channel and/or controller failure and any combination thereof) MUST NOT result in releasing established calls and connections (including the corresponding transport plane connections).
- 任意の制御プレーン障害（すなわち、単一または複数の制御チャネルおよび/またはコントローラ障害およびそれらの任意の組み合わせ）が確立されたコールと（対応するトランスポート・プレーン接続を含む）接続を解放をもたらしてはいけません。
- Upon recovery from a control plane failure, the recovered control entity MUST have the ability to recover the status of the calls and the connections established before failure occurrence.
- コントロールプレーンの障害からの回復時には、回復制御エンティティは、通話の状況や障害発生前に確立された接続を回復する能力を持たなければなりません。
- Upon recovery from a control plane failure, the recovered control entity MUST have the ability to recover the connectivity information of its neighbors.
- コントロールプレーンの障害からの回復時には、回復制御エンティティは、その隣人の接続情報を回復する能力を持たなければなりません。
- Upon recovery from a control plane failure, the recovered control entity MUST have the ability to recover the association between the call and its associated connections.
- 制御プレーン障害からの回復時には、回収された制御エンティティは、コールとその関連する接続の間の関連を回復する能力を持たなければなりません。
- Upon recovery from a control plane failure, calls and connections in the process of being established (i.e., pending call/connection setup requests) SHOULD be released or continued (with setup).
- 制御プレーン障害からの回復時に、呼び出して（すなわち、呼/接続設定要求を保留中）確立の過程における接続は、（設定で）解放または継続すべきです。
- Upon recovery from a control plane failure, calls and connections in the process of being released MUST be released.
- 制御プレーン障害からの回復時には、解放されたプロセスのコールとの接続が解放されなければなりません。
It is an ASON requirement to enable support for G.805 [ITU-T-G.805] serial compound links. The text below provides an illustrative example of such a scenario, and the associated requirements.
G.805 [ITU-T-G.805]シリアル化合物リンクのサポートを可能にするためASON要件です。以下のテキストは、そのようなシナリオの例示的な例、および関連する要件を提供します。
Labels are defined in GMPLS (see [RFC3471]) to provide information on the resources used on a link local basis for a particular connection. The labels may range from specifying a particular timeslot, indicating a particular wavelength, or to identifying a particular port/fiber. In the ASON context, the value of a label may not be consistent across a link. For example, the figure below illustrates the case where two GMPLS capable nodes (A and Z) are interconnected across two non-GMPLS capable nodes (B and C), where all of these nodes are SONET/SDH nodes, providing, for example, a VC-4 service.
ラベルは、特定の接続のためのリンクローカルに基づいて使用されるリソースに関する情報を提供する（[RFC3471]を参照）GMPLSに定義されています。ラベルは、特定の波長を示し、特定のタイムスロットを指定から、または特定のポート/ファイバを識別するの範囲であってもよいです。 ASONの文脈において、ラベルの値は、リンクの両端の一貫性がないかもしれません。例えば、以下の図は、例えば、提供可能なノード（AおよびZ）は、これらのノードのすべてがSONET / SDHノードである二つの非GMPLSできるノード（B及びC）を横切って相互に接続された2つのGMPLS場合を示しVC-4サービス。
----- -----
| | --- --- | |
| A |---| B |---| C |---| Z |
| | --- --- | |
----- -----
Labels have an associated implicit imposed structure based on [GMPLS-SONET] and [GMPLS-OTN]. Thus, once the local label is exchanged with its neighboring control plane node, the structure of the local label may not be significant to the neighbor node, as the association between the local and the remote label may not necessarily be the same. This issue does not present a problem in simple point-to-point connections between two control plane-enabled nodes in which the timeslots are mapped 1:1 across the interface. However, if a non-GMPLS capable sub-network is introduced between these nodes (as in the above figure, where the sub-network provides re-arrangement capability for the timeslots), label scoping may become an issue.
ラベルは[GMPLS-SONET]および[GMPLS-OTN]に基づいて、関連する暗黙課さ構造を有しています。ローカルラベルは、その隣接する制御プレーンノードと交換されると、ローカルとリモートのラベルの間の関連は、必ずしも同じでなくてもよいようにこのように、ローカルラベルの構造は、隣接ノードに対して重要ではないかもしれません。インタフェースを介して1：この問題は、タイムスロットが1にマッピングされた二つの制御プレーン対応ノード間の単純なポイントツーポイント接続に問題を提示しません。非GMPLS可能なサブネットワークは、（サブネットワークは、タイムスロットの再配置機能を提供する上図、のように）これらのノードの間に導入される場合には、ラベルのスコープは、問題になることができます。
In this context, there is an implicit assumption that the data plane connections between the GMPLS capable edges already exist prior to any connection request. For instance, node A's outgoing VC-4's timeslot #1 (with SUKLM label=[1,0,0,0,0]), as defined in [GMPLS-SONET]), may be mapped onto node B's outgoing VC-4's timeslot #6 (label=[6,0,0,0,0]), or may be mapped onto node C's outgoing VC-4's timeslot #4 (label=[4,0,0,0,0]). Thus, by the time node Z receives the request from node A with label=[1,0,0,0,0], node Z's local label and timeslot no longer correspond to the received label and timeslot information.
この文脈では、GMPLSの間のデータプレーン接続が可能なエッジが既に任意の接続要求に先立って存在するという暗黙の仮定があります。例えば、ノード（SUKLMラベル= [1,0,0,0,0]を有する）Aの発信VC-4のタイムスロット＃1は、[GMPLS-SONET]）で定義されるように、ノードBの送信VC-4の上にマッピングすることができますタイムスロット＃6（ラベル= [6,0,0,0,0]）、またはノードCの送信VC-4のタイムスロット＃4にマッピングされてもよい（ラベル= [4,0,0,0,0]）。したがって、時刻ノードZによってもはや受信したラベルとタイムスロット情報に対応しないラベル= [1,0,0,0,0]、ノードZのローカルラベルとタイムスロットと、ノードAからの要求を受信します。
As such, to support this capability, a label association mechanism SHOULD be used by the control plane node to map the received (remote) label into a locally significant label. The information necessary to allow mapping from a received label value to a locally significant label value can be derived in several ways including:
このように、この機能をサポートするために、ラベルの関連付け機構は、局所的に有意なラベルに受け取ら（リモート）ラベルをマッピングする制御プレーンノードによって使用されるべきです。 ：ローカルで有効なラベル値を受信したラベル値からマッピングを可能にするのに必要な情報を含むいくつかの方法で誘導することができます
- Manual provisioning of the label association
- ラベル協会の手動プロビジョニング
- Discovery of the label association
- ラベル協会の発見
Either method MAY be used. In case of dynamic association, the discovery mechanism operates at the timeslot/label level before the connection request is processed at the ingress node. Note that in the case where two nodes are directly connected, no association is required. In particular, for directly connected TDM interfaces, no mapping function (at all) is required due to the implicit label structure (see [GMPLS-SONET] and [GMPLS-OTN]). In these instances, the label association function provides a one-to-one mapping of the received to local label values.
どちらの方法を用いてもよいです。接続要求が入口ノードで処理される前に動的関連付けの場合には、発見メカニズムは、タイムスロット/ラベル・レベルで動作します。二つのノードが直接接続されている場合には、何の関連付けが必要とされないことに留意されたいです。具体的には、（すべてで）直接接続されたTDMインタフェース、無マッピング機能のため（[GMPLS-SONET]および[GMPLS-OTN]を参照）により暗黙のラベル構造に必要とされます。これらの例では、ラベルの関連付け機能は、ローカルラベルの値に受信の一対一のマッピングを提供します。
Crankback has been identified as an important requirement for ASON networks. Upon a setup failure, it allows a connection setup request to be retried on an alternate path that detours around a blocked link or node (e.g., because a link or a node along the selected path has insufficient resources).
クランクバックはASONネットワークのための重要な要件として同定されています。 （選択された経路に沿ったリンクまたはノードに十分なリソースを持っているので、例えば）セットアップの失敗時に、接続セットアップ要求がブロックされたリンクまたはノードを迂回代替パスに再試行されることを可能にします。
Crankback mechanisms MAY also be applied during connection recovery by indicating the location of the failed link or node. This would significantly improve the successful recovery ratio for failed connections, especially in situations where a large number of setup requests are simultaneously triggered.
クランクバック機構はまた、故障したリンクまたはノードの位置を示すことにより、接続の回復中に適用されてもよいです。これは、大幅に特にセットアップ多数の要求を同時にトリガされる状況では、失敗した接続のための成功の回収率を改善することになります。
The following mechanisms are assumed during crankback signaling:
以下の機構はクランクバックシグナリング中に想定されます。
- The blocking resource (link or node) MUST be identified and returned in the error response message to the repair node (that may or may not be the ingress node); it is also assumed that this process will occur within a limited period of time.
- ブロッキングリソース（リンク又はノード）が識別され、修復ノードにエラー応答メッセージで返さなければならない（つまり、または入力ノードであってもなくてもよいです）。また、このプロセスは、時間の限られた期間内に発生することが想定されます。
- The computation (from the repair node) of an alternate path around the blocking link or node that satisfies the initial connection constraints.
- 最初の接続の制約を満たすブロッキングリンクまたはノードの周りの代替経路の（修復ノードから）計算。
- The re-initiation of the connection setup request from the repair node (i.e., the node that has intercepted and processed the error response message).
- 修復ノードからの接続セットアップ要求の再開始（すなわち、傍受及びエラー応答メッセージを処理したノード）。
The following properties are expected for crankback signaling:
次のプロパティは、クランクバックシグナリングのために期待されています。
- Error information persistence: the entity that computes the alternate (re-routing) path SHOULD store the identifiers of the blocking resources, as indicated in the error message, until the connection is successfully established or until the node abandons rerouting attempts. Since crankback may happen more than once while establishing a specific connection, the history of all experienced blockages for this connection SHOULD be maintained (at least until the routing protocol updates the state of this information) to perform an accurate path computation that will avoid all blockages.
- エラー情報の永続性：ノードが再ルーティング試行を放棄するまで、接続が正常に確立されるまで、または、エラーメッセージに示されているように、代替を計算エンティティパス（経路変更）は、ブロッキングリソースの識別子を格納する必要があります。クランクバックが複数回発生する可能性があるので、特定の接続を確立しながら、この接続のためのすべての経験豊富な閉塞の歴史は全て閉塞を避けるであろう正確な経路計算を実行する（ルーティングプロトコルがこの情報の状態を更新する少なくともまで）維持されるべきです。
- Rerouting attempts limitation: to prevent an endless repetition of connection setup attempts (using crankback information), the number of retries SHOULD be strictly limited. The maximum number of crankback rerouting attempts allowed MAY be limited per connection or per node:
- 再ルーティングは、限定を試行：接続設定の試行（クランクバック情報を使用して）の無限の繰り返しを防止するために、再試行の数は、厳密に制限されるべきです。許容クランクバック再ルーティング試行の最大数は、接続ごと、またはノードごとに制限されてもよいです。
- When the number of retries at a particular node is exceeded, the node that is currently handling the failure reports the error message upstream to the next repair node, where further rerouting attempts MAY be performed. It is important that the crankback information provided indicate that re-routing through this node will not succeed.
- 特定のノードでのリトライ回数を超えた場合、現在の失敗を処理しているノードは、さらに、再ルーティング試みが行われてもよい次の修復ノード、上流エラーメッセージを報告します。提供クランクバックの情報は、このノードを経由して再ルーティングは成功しないだろうことを示していることが重要です。
- When the maximum number of retries for a specific connection has been exceeded, the repair node that is handling the current failure SHOULD send an error message upstream to indicate the "Maximum number of re-routings exceeded". This error message will be sent back to the ingress node with no further rerouting attempts. Then, the ingress node MAY choose to retry the connection setup according to local policy, using its original path, or computing a path that avoids the blocking resources.
- 特定の接続の再試行の最大数を超えた場合、現在の障害を処理する修復ノードは、「再ルーティングの最大数を超え」を示すために、上流のエラーメッセージを送信すべきです。このエラーメッセージはそれ以上の試みを再ルーティングバック入口ノードへ送信されます。次に、入口ノードは元のパスを使用して、またはブロッキングリソースを回避する経路を計算し、ローカルポリシーに従って接続設定を再試行することを選ぶかもしれ。
Note: After several retries, a given repair point MAY be unable to compute a path to the destination node that avoids all of the blockages. In this case, it MUST pass the error message upstream to the next repair point.
注：いくつかの試行後、所定の補修点は閉塞の全てを回避する宛先ノードへの経路を計算することができません。この場合には、次の修理点の上流にエラーメッセージを渡さなければなりません。
To support the ASON network, the following additional category of error cases are defined:
ASONネットワークをサポートするために、エラーの例次の追加カテゴリが定義されています。
- Errors associated with basic call and soft permanent connection support. For example, these MAY include incorrect assignment of IDs for the Call or an invalid interface ID for the soft permanent connection.
- 基本的なコールとソフト常時接続のサポートに関連したエラー。例えば、これらは、コールまたはソフト永続的な接続のための無効なインターフェイスIDのIDの間違った割り当てを含むかもしれません。
- Errors associated with policy failure during processing of the new call and soft permanent connection capabilities. These MAY include unauthorized requests for the particular capability.
- 新しいコールとソフト永続的な接続機能の処理中政策の失敗に関連したエラー。これらは、特定の機能のため不正な要求を含むかもしれません。
- Errors associated with incorrect specification of the service level.
- サービスレベルの間違った仕様に関連したエラー。
As noted above, in support of GMPLS protocol requirements, any extensions to the GMPLS signaling protocol, in support of the requirements described in this document, MUST be backward compatible.
上述したように、GMPLSプロトコル要件をサポートするために、シグナリングプロトコルGMPLSへの拡張は、本書で説明した要件をサポートするために、下位互換性がなければなりません。
Backward compatibility means that in a network of nodes, where some support GMPLS signaling extensions to facilitate the functions described in this document, and some do not, it MUST be possible to set up conventional connections (as described by [RFC3473]) between any arbitrary pair of nodes and to traverse any arbitrary set of nodes. Further, the use of any GMPLS signaling extensions to set up calls or connections that support the functions described in this document MUST not perturb existing conventional connections.
後方互換性は、任意間（[RFC3473]で説明されるように）いくつかの支持GMPLSは、本書で説明した機能を容易にするために、拡張シグナリング、およびいくつかはないノードのネットワークにおいては、従来の接続をセットアップすることが可能でなければならないことを意味しますノードのペアは、ノードの任意のセットを横断します。さらに、このドキュメントで説明する機能をサポートコールや接続を設定するために拡張子を知らせる任意のGMPLSを使用すると、既存の従来の接続を撹乱してはいけません。
Additionally, when transit nodes that do not need to participate in the new functions described in this document lie on the path of a call or connection, the GMPLS signaling extensions MUST be such that those transit nodes are able to participate in the establishment of a call or connection by passing the setup information onwards, unmodified.
コールまたは接続の経路上に、この文書の嘘で説明した新機能に参加する必要がないときにトランジットノードに加え、拡張をGMPLSシグナリングは、これらのトランジットノードは、コールの確立に参加することができますようなものでなければなりませんまたは以降の設定情報を渡すことにより、接続、変更されていません。
Lastly, when a transit or egress node is called upon to support a function described in this document, but does not support the function, the GMPLS signaling extensions MUST be such that they can be rejected by pre-existing GMPLS signaling mechanisms in a way that is not detrimental to the network as a whole.
最後に、トランジットか出口ノードは、このドキュメントで説明する機能をサポートするために呼び出されますが、機能をサポートしていない、GMPLS拡張機能を知らせるときにする方法でシグナル伝達機構、既存のGMPLSによって拒否することができるようでなければなりません全体としてネットワークにとって有害ではありません。
Per [ITU-T-G.8080], it is not possible to establish a connection in advance of call setup completion. Also, policy and authentication procedures are applied prior to the establishment of the call (and can then also be restricted to connection establishment in the context of this call).
パー[ITU-T G.8080 - ]は、呼設定完了の前に、接続を確立することはできません。また、ポリシーおよび認証手順は前の呼の確立に適用される（そして、このコールの文脈において接続確立に制限することができます）。
This document introduces no new security requirements to GMPLS signaling (see [RFC3471]).
この文書では、（[RFC3471]を参照）GMPLSシグナリングに新たなセキュリティ要件を導入していません。
The authors would like to thank Nic Larkin, Osama Aboul-Magd, and Dimitrios Pendarakis for their contribution to the previous version of this document, Zhi-Wei Lin for his contribution to this document, Deborah Brungard for her input and guidance in our understanding of the ASON model, and Gert Grammel for his decryption effort during the reduction of some parts of this document.
作者はこのドキュメントの以前のバージョンに貢献用のNICラーキン、オサマのAboul-Magd、およびディミトリオスPendarakisに感謝したいと思い、この文書への貢献のために志偉林の我々の理解の彼女の入力と指導のためのデボラBrungardこのドキュメントのいくつかの部分の還元時の彼の復号化の努力のためのASONモデル、およびゲルトGrammel。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[ANSI-T1.105] ANSI, "Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, and Formats", T1.105, October 2000.
[ANSI-T1.105] ANSI、 "同期光ネットワーク（SONET）：多重構造、料金、およびフォーマットを含む基本的な説明"、T1.105、2000年10月。
[GMPLS-OTN] Papadimitriou, D., Ed., "Generalized MPLS (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", Work in Progress, January 2005.
[GMPLS-OTN] Papadimitriou、D.編、 "一般化MPLS（GMPLS）G.709光伝送ネットワーク制御のためのシグナリング拡張"、進歩、2005年1月での作業。
[GMPLS-OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalize Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", Work in Progress, October 2004.
[GMPLS-OVERLAY]ツバメ、G.、ドレイクは、Jは、石松、H.、およびY. Rekhterは、「一般化マルチプロトコルラベルスイッチング（GMPLS）ユーザネットワークインタフェース（UNI）：リソース予約プロトコル - トラフィックエンジニアリング（RSVP-オーバレイモデル」、進歩、2004年10月に業務用TE）をサポート。
[GMPLS-SONET] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004.
[GMPLS-SONET]マニー、E.およびD. Papadimitriou、RFC 3946、2004年10月 "同期光ネットワーク（SONET）および同期デジタル階層（SDH）コントロールのための一般化マルチプロトコルラベルスイッチング（GMPLS）の拡張"。
[GMPLS-VPN] Ould-Brahim, H. and Y. Rekhter, Eds., "GVPN Services: Generalized VPN Services using BGP and GMPLS Toolkit", Work in Progress, May 2004.
[GMPLS-VPN]ウルド - Brahimの、H.およびY. Rekhter、編、 "GVPNサービス：BGPを使用して一般化VPNサービスとGMPLSツールキット"。、進歩、2004年5月での作業。
[ITU-T-G.707] ITU-T, "Network Node Interface for the Synchronous Digital Hierarchy (SDH)", Recommendation G.707, October 2000.
[ITU-T G.707-] ITU-T、 "同期デジタル階層（SDH）のためのネットワークノードインタフェース"、勧告G.707、2000年10月。
[ITU-T-G.709] ITU-T, "Interface for the Optical Transport Network (OTN)", Recommendation G.709 (and Amendment 1), February 2001 (October 2001). http://www.itu.int
[ITU-T G.709-] ITU-T、 "オプティカルトランスポートネットワーク（OTN）のためのインタフェース"、勧告G.709（および修正1）、2001年2月（2001年10月）。 http://www.itu.int
[ITU-T-G.7713] ITU-T "Distributed Call and Connection Management", Recommendation G.7713/Y.1304, November 2001. http://www.itu.int
[ITU-T G.7713 - ] ITU-T "コールと接続管理分散"、勧告G.7713 / Y.1304、2001年11月http://www.itu.int
[ITU-T-G.805] ITU-T, "Generic functional architecture of transport networks)", Recommendation G.805, March 2000. http://www.itu.int
[ITU-T-G.805] ITU-T、 "トランスポート・ネットワークの一般的な機能アーキテクチャ）"、勧告G.805、2000年3月http://www.itu.int
[ITU-T-G.8080] ITU-T "Architecture for the Automatically Switched Optical Network (ASON)", Recommendation G.8080/Y.1304, November 2001 (and Revision, January 2003). http://www.itu.int
[ITU-T G.8080 - ] ITU-T "の自動交換光ネットワーク（ASON）のためのアーキテクチャ"、勧告G.8080 / Y.1304、2001年11月（および改訂、2003年1月）。 http://www.itu.int
Appendix - Terminology
付録 - 用語
This document makes use of the following terms:
このドキュメントでは、次の用語を使用します：
Administrative domain: See Recommendation G.805 [ITU-T-G.805].
管理ドメイン：勧告G.805 [ITU-T G.805-]を参照してください。
Call: Association between endpoints that supports an instance of a service.
呼び出し：サービスのインスタンスをサポートし、エンドポイント間の協会。
Connection: Concatenation of link connections and sub-network connections that allows the transport of user information between the ingress and egress points of a sub-network.
接続：サブネットワークの入口と出口点の間のユーザ情報の転送を可能にするリンク接続とサブネットワーク接続の連結。
Control Plane: Performs the call control and connection control functions. The control plane sets up and releases connections through signaling, and may restore a connection in case of a failure.
コントロールプレーンは、呼制御及び接続制御機能を実行します。制御プレーンは、シグナリングを介してアップ解放接続設定し、障害が発生した場合に接続を復元することができます。
(Control) Domain: Represents a collection of entities that are grouped for a particular purpose. G.8080 applies this G.805 recommendation concept (that defines two particular forms: the administrative domain and the management domain) to the control plane in the form of a control domain. Entities grouped in a control domain are components of the control plane.
（コントロール）ドメイン：特定の目的のためにグループ化されたエンティティのコレクションを表します。制御ドメインの形態における制御プレーンに：G.8080は、（管理ドメインと管理ドメインその2つの特定の形態を定義する）このG.805勧告の概念を適用します。制御ドメインにグループ化されたエンティティは、制御プレーンの構成要素です。
External NNI (E-NNI): Interfaces are located between protocol controllers that are situated between control domains.
外部NNI（E-NNI）：インタフェースは、制御ドメインの間に位置しているプロトコルコントローラとの間に位置しています。
Internal NNI (I-NNI): Interfaces are located between protocol controllers within control domains.
内部NNI（I-NNI）：インタフェースは、制御ドメイン内のプロトコルコントローラとの間に配置されています。
Link: See Recommendation G.805 [ITU-T-G.805].
リンク：勧告G.805 [ITU-T G.805-]を参照してください。
Management Plane: Performs management functions for the Transport Plane, the control plane, and the system as a whole. It also provides coordination between all the planes. The following management functional areas are performed in the management plane: performance, fault, configuration, accounting, and security management.
管理プレーンは：トランスポートプレーン、コントロールプレーン、およびシステム全体の管理機能を実行します。また、すべての面の間の調整を提供します。パフォーマンス、障害、設定、アカウンティング、およびセキュリティ管理：以下の管理機能領域は、管理プレーンで実行されています。
Management Domain: See Recommendation G.805 [ITU-T-G.805].
管理ドメイン：勧告G.805 [ITU-T G.805-]を参照してください。
Transport Plane: Provides bi-directional or unidirectional transfer of user information, from one location to another. It can also provide transfer of some control and network management information. The Transport Plane is layered and is equivalent to the Transport Network defined in G.805 [ITU-T-G.805].
トランスポートプレーンは：一つの場所から別のものに、ユーザ情報の双方向または単方向転送を提供します。また、いくつかの制御とネットワーク管理情報の転送を提供することができます。トランスポートプレーンは、層状であり、G.805で定義されたトランスポートネットワーク[ITU-T-G.805]と等価です。
User Network Interface (UNI): Interfaces are located between protocol controllers, between a user and a control domain.
ユーザネットワークインタフェース（UNI）：インターフェイスは、ユーザと制御ドメインとの間に、プロトコルコントローラとの間に配置されています。
Authors' Addresses
著者のアドレス
Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルフランシスVellesplein 1 B-2018アントワープ、Velgiom
Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel.be
電話：+32 3 2408491 Eメール：dimitri.papadimitriou@alcatel.be
John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245
ジョン・ドレイクボーイング衛星システム2300東インペリアルハイウェイエルセグンドー、CA 90245
EMail: John.E.Drake2@boeing.com
メールアドレス：John.E.Drake2@boeing.com
Adrian Farrel Old Dog Consulting
エードリアンファレル古い犬のコンサルティング
Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
電話：+44（0）1978 860944 Eメール：adrian@olddog.co.uk
Gerald R. Ash ATT AT&T Labs, Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA
ジェラルドR.アッシュATT AT＆T Labs社、ルームMT D5-2A01 200ローレルアベニューミドルタウン、NJ 07748、USA
EMail: gash@att.com
メールアドレス：gash@att.com
Lyndon Ong Ciena PO Box 308 Cupertino, CA 95015, USA
リンドン・オングCienaの私書箱308クパチーノ、CA 95015、USA
EMail: lyong@ciena.com
メールアドレス：lyong@ciena.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。