[要約] RFC 4139は、GMPLSシグナリングの使用とASONの拡張の要件を定義しています。その目的は、自動切り替え光ネットワークにおける効率的なサービス提供を可能にするためのガイドラインを提供することです。
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)
一般化されたMPLS（GMPLS）シグナリングの使用法と自動スイッチされた光ネットワーク（ASON）の拡張機能の要件
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).
Copyright（c）The Internet Society（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）および光学輸送ネットワーク（OTN）を含む、時分割多重化（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スイートのシグナリングの側面に集中しています。GMPLSシグナリングプロトコルでカバーされる機能を識別して、自動化された光ネットワーク（ASON）の機能をサポートします。このドキュメントは、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）（それぞれ[ANSI-T1.105]および[ITU-T-G.707]を参照）を含む、タイムディビジョンマルチプレックス（TDM）接続を要求するためのサポートが含まれます。輸送ネットワーク（[ITU-T-G.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スイートのシグナリングの側面に関連する要件に集中しています。これらの機能をサポートするために、GMPLSシグナル（[RFC3471]および[RFC3473]を参照）（[RFC3471]および[RFC3473]を参照）を追加する可能性のある自動化されたスイッチされた光ネットワークをサポートするために必要な機能要件について説明します。ASONシグナル伝達要件に加えて、このドキュメントには、後方互換性に関連するGMPLSシグナル伝達要件が含まれています（セクション5）。付録には、用語セクションが記載されています。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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モデルは、（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:
このドキュメントは、コールと接続管理を提供するために、GMPLSシグナル伝達（特に[RFC3471]および[RFC3473]）の使用に関連する要件について説明しています（[ITU-T-G.7713]を参照）。サポートされる機能には次のものが含まれます。
(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.
次のセクションでは、セクション3にリストされているASON関数をサポートするGMPLSのシグナリングプロトコル要件を詳しく説明しています。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シグナリング要求の明確なマッピングが必要であることを意味します。このドキュメントは、G.8080分散コールとGMPLSベースのコントロールドメイン（I-NNI）内、およびGMPLSベースのコントロールドメイン（E-NNI）内のシグナリング要件を提供します。制御ドメイン内またはE-NNIまたはUNIとして使用する他の（非GMPLS）プロトコルの使用を制限しません。Uni、E-NNI、またはI-NNIなどの非GMPLSプロトコルの使用に関連するインターワーキングの側面 - 非GMPLSプロトコルシグナリング要求のマッピングを対応するASONシグナル伝達機能と非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.
定義上、[RFC3473]（例えば[GMPLS-Overlay]および[Gmpls-VPN]）に準拠したユーザーネットワークインターフェイス（UNI）は、プロトコルの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とIngressノードの間の通信方法は、このドキュメントの範囲を超えています（このドキュメントで説明されている他の機能の場合）。
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接続を次の図に示します。これにより、ユーザーのノードAがリンク＃1を介してプロバイダーのノードBに接続され、ユーザーのノードZがリンク＃3を介してプロバイダーのノードYに接続され、プロバイダーのノードBとノードYを接続する抽象リンク2を示します。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つのエンドポイント間で提供されるサービスと見なすことができ、それらの間にいくつかの呼び出しが存在する可能性があります。複数の接続が各呼び出しに関連付けられている場合があります。コールコンセプトは、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]で説明されているように、コールがいくつかの制御ドメインを越えたときに、コールセグメンテーションが適用される場合があります。そのため、コールが複数の制御ドメインを通過する場合、エンドツーエンドの呼び出しは複数のコールセグメントで構成されている場合があります。特定のエンドツーエンドコールの場合、各コールセグメントには1つ以上の関連する接続があり、各コールセグメントに関連付けられている接続の数が異なる場合があります。
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.
開始する発信者は、コントロールドメインの境界（つまり、ドメイン間参照ポイント、UNIまたはE-NNI）にある1つまたは複数の中間ネットワークコールコントローラーを使用して、コールパーティと対話します。通話セグメント機能は、これらの参照ポイントに関連付けられているポリシーによって定義されます。
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.
ラベルはGMPLS（[RFC3471]を参照）で定義されており、特定の接続にローカルベースで使用されるリソースに関する情報を提供します。ラベルは、特定のタイムスロットの指定から、特定の波長を示すことから、または特定のポート/ファイバーの識別にまで及びます。ASONコンテキストでは、ラベルの値がリンク全体で一貫していない場合があります。たとえば、以下の図は、2つのGMPLS対応ノード（AおよびZ）が2つの非GMPLS対応ノード（BおよびC）に相互接続されている場合を示しています。これらのノードはすべてSONET/SDHノードであり、たとえば、たとえば提供されます。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でマッピングされる2つの制御プレーン対応ノード間の単純なポイントツーポイント接続で問題を提示しません。ただし、これらのノードの間に非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対応エッジ間のデータプレーン接続がすでに存在するという暗黙の仮定があります。たとえば、[GMPLS-Sonet]で定義されているように、ノードAの発信VC-4のタイムスロット＃1（SUKLMラベル= [1,0,0,0,0]））は、ノードBの発行VC-4にマッピングされる場合があります。Timeslot＃6（label = [6,0,0,0,0]）、またはノードCの発信VC-4のタイムスロット＃4（ラベル= [4,0,0,0,0]）にマッピングされる場合があります。したがって、ノードZがラベル= [1,0,0,0,0,0]を使用してノードAからリクエストを受信するまでに、ノードZのローカルラベルとタイムスロットは、受信したラベルとタイムスロット情報に対応しなくなりました。
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.
どちらの方法も使用できます。動的関連の場合、発見メカニズムは、接続要求がイングレスノードで処理される前にタイムスロット/ラベルレベルで動作します。2つのノードが直接接続されている場合、関連性は不要であることに注意してください。特に、直接接続されたTDMインターフェイスの場合、暗黙のラベル構造のためにマッピング関数は必要ありません（[GMPLS-Sonet]および[GMPLS-OTN]を参照）。これらの例では、ラベルアソシエーション関数は、受信したローカルラベル値に1対1のマッピングを提供します。
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:
- 再ルーティングの試みの制限：接続セットアップの試行の無限の繰り返しを防ぐため（クランクバック情報を使用）、RETRIESの数は厳密に制限される必要があります。許可されているクランクバック再ルーティングの試みの最大数は、接続またはノードごとに制限される場合があります。
- 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.
後方互換性とは、このドキュメントで説明されている機能を容易にするためのGMPLSシグナリング拡張機能をサポートするノードのネットワークでは、任意の任意の任意の間の従来の接続（[RFC3473]で説明されている）を設定することができる必要があることを意味します。ノードのペアと、任意のノードのセットを横断する。さらに、このドキュメントで説明されている機能をサポートする呼び出しまたは接続を設定するために拡張を信号する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.
さらに、このドキュメントに記載されている新しい機能に参加する必要のないトランジットノードは、呼び出しまたは接続のパスにあります。または、セットアップ情報を前に渡すことによる接続、変更されていません。
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]).
このドキュメントでは、GMPLSシグナリングに新しいセキュリティ要件は導入されていません（[RFC3471]を参照）。
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.
著者は、この文書の以前のバージョンであるZhi-Wei Linに貢献してくれたNic Larkin、Osama Aboul-Magd、およびDimitrios Pendarakisに感謝したいと思います。ASONモデル、およびこのドキュメントの一部の削減中の彼の復号化の取り組みのためのGert Grammel。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、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] Berger、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.、ed。、「G.709光学輸送ネットワーク制御の一般化MPLS（GMPLS）シグナル伝達拡張」、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] Swallow、G.、Drake、J.、Ishimatsu、H。、およびY. Rekhter、「Multiprotocol Label Switching（GMPLS）ユーザーネットワークインターフェイス（UNI）：リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）オーバーレイモデルのサポート」、2004年10月、進行中の作業。
[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] Mannie、E。およびD. Papadimitriou、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）同期光学ネットワーク（SONET）および同期デジタル階層（SDH）コントロールの拡張機能」、RFC 3946、2004年10月。
[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] Oould-Brahim、H。およびY. Rekhter、eds。、「GVPNサービス：BGPおよびGMPLS Toolkitを使用した一般化されたVPNサービス」、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は、このG.805推奨コンセプト（管理ドメインと管理ドメインの2つの特定の形式を定義する）を制御ドメインの形式で制御プレーンに適用します。制御ドメインにグループ化されたエンティティは、コントロールプレーンのコンポーネントです。
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
Dimitri Papadimitriou Alcatel Francis Wellesplein 1、B-2018 Antwerpen、ベルギー
Phone: +32 3 2408491
EMail: dimitri.papadimitriou@alcatel.be
John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245
ジョンドレイクボーイング衛星システム2300イーストインペリアルハイウェイエルセグンド、カリフォルニア90245
EMail: John.E.Drake2@boeing.com
Adrian Farrel Old Dog Consulting
エイドリアンファレルオールドドッグコンサルティング
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Gerald R. Ash ATT AT&T Labs, Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA
Gerald R. Ash Att＆T Labs、Room MT D5-2A01 200 Laurel Avenue Middletown、NJ 07748、米国
EMail: gash@att.com
Lyndon Ong Ciena PO Box 308 Cupertino, CA 95015, USA
Lyndon Ong Ciena PO Box 308 Cupertino、CA 95015、米国
EMail: lyong@ciena.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。