RFC4139 日本語訳

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

Papadimitriouがコメントのために要求するワーキンググループD.をネットワークでつないでください: 4139年のアルカテルカテゴリ: 犬のコンサルティングL.オングCiena2005年7月に年取った情報のJ.のボーイングのJ.灰のATTのA.ドレイクファレル

       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)インターネット協会(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).

プロトコルのGeneralized Multi-プロトコルLabel Switching(GMPLS)スイートは、異なった切り換え技術と異なったアプリケーションを制御するために定義されました。 これらはTime事業部Multiplexing(TDM)接続を要求するサポートを含んでいます、同期式光通信網(Sonet)/同期デジタルハイアラーキ(SDH)とOptical Transport Networks(OTNs)を含んでいて。

   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スイートのシグナリング局面に集中します。 それはAutomatically Switched Optical Network(ASON)の能力をサポートするためにGMPLSシグナリングプロトコルでカバーされるべき特徴を特定します。 このドキュメントは問題声明とGMPLSシグナリングプロトコルがASONが機能性であるとサポートするという追加要件を提供します。

Papadimitriou, et al.        Informational                      [Page 1]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[1ページ]のRFC4139GMPLS

1.  Introduction

1. 序論

   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.

プロトコル仕様のGeneralized Multi-プロトコルLabel Switching(GMPLS)スイートは異なった切り換え技術と異なったアプリケーションを制御するサポートを提供します。 これらはTime事業部Multiplexing(TDM)接続を要求するサポートを含んでいます、同期式光通信網(Sonet)/同期デジタルハイアラーキ(SDH)(それぞれ[ANSI-T1.105]と[ITU-T-G.707]を見る)、およびOptical Transport Networksを含んでいて([ITU-T-G.709]を見てください)。 さらに、Automatically Switched Optical Networksコントロールが飛行機であるとサポートするのに必要である、ある能力があります(それらのアーキテクチャは[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に追加拡大に通じるかもしれないAutomatically Switched Optical Networksをサポートするのに必要である機能条件書について議論します。 ASONシグナリング要件に加えて、このドキュメントは後方の互換性(セクション5)に関係するGMPLSシグナリング要件を含んでいます。 用語部をAppendixに提供します。

2.  Conventions Used in This Document

2. 本書では使用されるコンベンション

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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]がプロトコル仕様と実装に関してこれらのキーワードの解釈について説明している間、それらは、プロトコル拡大のための設計の品質について説明するのに本書では使用されます。

3.  Problem Statement

3. 問題声明

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

Automatically Switched Optical Network(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

ASONモデルは基準点を区別します。(ポイントの情報交換を表します)はユーザ(サービスリクエスタ)とサービスプロバイダー制御領域の間で(1)を定義しました、通称ユーザネットワーク・インターフェース(UNI)、制御領域の間の(2)、通称制御領域の中の外部のそして、ネットワーク・インターフェースをネットワークでつないでいる(E- NNI)(3)、通称インターナル

Papadimitriou, et al.        Informational                      [Page 2]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[2ページ]のRFC4139GMPLS

   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.

ネットワークネットワーク・インターフェース(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)要求とコントロール飛行機の故障(e)の間の拡張再開能力が広げたセグメント(d)が協会(f)crankback能力(g)を追加誤り事件とラベルするという接続分離(c)要求

4.  Requirements for Extending Applicability of GMPLS to ASON

4. GMPLSの適用性をASONに与えるための要件

   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がセクション3に記載されたASON機能をサポートするというシグナリングプロトコル要件を詳しく述べます。 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,

異なった制御領域中のG.8080終わりから終わりへの呼び出しモデルを支持して、終わりから終わりへのシグナリングはネットワークのどんな部分の中でも管理境界、ネットワークの中のプロトコル、または接続の実現のメソッドにかかわらず容易にされるべきです。 これはGMPLS制御領域と非GMPLS制御領域の間のASONシグナリング要求の明確なマッピングの必要性を含意します。 このドキュメントはGMPLSのベースの制御領域(I-NNI)以内とGMPLSのベースの制御領域(E- NNI)の間でGMPLSに基づく分配された呼び出しと接続管理をG.8080のためのシグナリング要件に提供します。 それは、制御領域以内かE-NNIかUNIとして使用されるために他の(非GMPLS)プロトコルの使用を制限しません。 局面を織り込むと、非GMPLSプロトコルの使用は関連しました。

Papadimitriou, et al.        Informational                      [Page 3]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[3ページ]のRFC4139GMPLS

   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.

GMPLSシグナリングプロトコルの範囲の中にUNI、E-NNI、またはI-NNI(対応する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])と共に言いなりになっているUser-ネットワークInterface(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('Extended Label Associationのサポート')はいつ非GMPLSのできるサブネットワークを導入するか、そして、またはノードがいつ何かシグナリングプロトコルをサポートしないか間の要件をカバーします。

4.1.  Support for Soft Permanent Connection (SPC) Capability

4.1. 優しい永久接続には、(SPC)が能力であるとサポートしてください。

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

Soft Permanent Connection(SPC)はソースユーザからネットワークへの側での永久接続、目的地ユーザからネットワークへの側での永久接続、およびネットワークの中の切り換えられた接続の組み合わせです。 Element Management System(EMS)かNetwork Management System(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接続は以下の図で例証されます。 これは、Aがリンク#1でプロバイダーのノードBに接続したのをユーザのノードに示します、そして、ユーザのノードZはリンク#3でプロバイダーのノードYに接続しました、そして、プロバイダーのノードBとノードY.Nodes BとYを接続する抽象的なリンク#2はイングレスと呼ばれました、そして、ネットワークの出口(それぞれ)は接続を切り換えました。

Papadimitriou, et al.        Informational                      [Page 4]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[4ページ]のRFC4139GMPLS

       ---       ---                 ---       ---
      | A |--1--| B |-----2-//------| Y |--3--| Z |
       ---       ---                 ---       ---

--- --- --- --- | 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シグナリングプロトコルSHOULDは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のコントロールの下にあるかもしれなくて、シグナリングプロトコルの範囲の中にない実装問題であることは注意してください。 したがって、このドキュメントの範囲の外にそれはあります。

4.2.  Support for Call and Connection Separation

4.2. 呼び出しのサポートと接続分離

   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つに関連する、または複数の接続であるかもしれません。 同じ呼び出しに、接続は異なったタイプに賛成するかもしれません、そして、各接続は他の接続の如何にかかわらず存在するかもしれません(すなわち、各接続は、セットアップであり、別々のシグナリングでメッセージを発表しました)。

Papadimitriou, et al.        Informational                      [Page 5]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[5ページ]のRFC4139GMPLS

   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.

- 複数の接続の一般処理(接続はいくつかの目的のために関連づけられるかもしれません)。 例えば、1組の働きと回復接続は同じ呼び出しに属すかもしれません。

   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シグナリングSHOULDは呼び出し識別メカニズムを含んでいます、そして、SHOULDは終わりから終わりへの呼び出し能力交換を考慮します。

   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(例えば、国名略号かキャリヤーコードで構成されるかもしれない)を連結するかもしれません。 他のまた、可能で、よっている形式SHALLはパーティーの間の呼び出し識別コンベンションでセットアッププロセスに呼び出しにかかわりました。

4.3.  Support for Call Segments

4.3. 呼び出しセグメントのサポート

   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台以上の中間ネットワーク呼び出しコントローラによって被呼者と対話します。 呼び出しセグメント能力はこれらの基準点で関連している方針で定義されます。

Papadimitriou, et al.        Informational                      [Page 6]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[6ページ]のRFC4139GMPLS

   This capability allows for independent (policy based) choices of
   signaling, concatenation, data plane protection, and control plane
   driven recovery paradigms in different control domains.

この能力はシグナリング、連結、データ飛行機保護、および制御飛行機の独立している(基づく方針)選択のために異なった制御領域にやる気満々の回復パラダイムを許容します。

4.4.  Support for Extended Restart Capabilities

4.4. 拡張再開能力のサポート

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

- 確立した(すなわち、未定の呼び出し/接続設定要求)SHOULDであることの途中にコントロール飛行機の故障からの回復、呼び出し、および接続のときに、リリースされるか続けられてください(セットアップがある)。

   -  Upon recovery from a control plane failure, calls and connections
      in the process of being released MUST be released.

- コントロール飛行機の故障からの回復では、リリースされることの途中に呼び出しと接続を釈放しなければなりません。

4.5.  Support for Extended Label Association

4.5. 拡張ラベル協会のサポート

   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

ラベルは、特定の接続リンクの地方ベースの運用資金の情報を提供するためにGMPLS([RFC3471]を見る)で定義されます。 ラベルは、特定の波長か、指定港/ファイバーを特定することに特定のtimeslot、表示を指定するので、及ぶかもしれません。 ASON文脈では、ラベルの値はリンクの向こう側に一貫していないかもしれません。 例えば、以下の図は例証します。

Papadimitriou, et al.        Informational                      [Page 7]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[7ページ]のRFC4139GMPLS

   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.

2つのGMPLSのできるノード(AとZ)が例えば、提供して、これらのノードのすべてがSonet/SDHノードであるa VC-4が調整する2つの非GMPLSのできるノード(BとC)の向こう側にインタコネクトされるケース。

       -----                     -----
      |     |    ---     ---    |     |
      |  A  |---| B |---| C |---|  Z  |
      |     |    ---     ---    |     |
       -----                     -----

----- ----- | | --- --- | | | 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]に基づいています。 したがって、隣接している規制飛行機ノードでいったん地方のラベルを交換すると、地方のラベルの構造は隣人ノードに重要でないかもしれません、地方のラベルとリモートラベルとの協会が必ず同じであるというわけではないときに。 この問題はtimeslotsが写像される2つの規制の飛行機で可能にされたノードの間の純真な二地点間接続における問題を提示しません。1:1 インタフェースの向こう側に。 しかしながら、非GMPLSのできるサブネットワークがこれらのノードに取り入れられるなら(上図のように)、ラベルの見ることは問題になるかもしれません。そこでは、サブネットワークが配列換え能力をtimeslotsに供給します。

   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のtimeslot#1(SUKLMラベル=[1、0、0、0、0]がある)は、ノードビーズの出発しているVC-4のtimeslot#6(ラベル=[6、0、0、0、0])に写像されるか、またはノードCの出発しているVC4のtimeslot#4(ラベル=[4、0、0、0、0])に写像されるかもしれません。 したがって、ノードZがラベル=[1、0、0、0、0]でノードAから要求を受け取る時までには、ノードZの地方のラベルとtimeslotはもう容認されたラベルとtimeslot情報に対応していません。

   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:

この能力、ラベル連合機能SHOULDをサポートするのに、そういうものとして、規制飛行機ノードによって使用されて、容認された(リモート)ラベルを局所的に重要なラベルに写像してください。 引き出されて、:いくつかの方法で容認されたラベル値から局所的に重要なラベル値まで写像するのを許容するのに必要な情報を引き出すことができます。

   -  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

メソッドは使用されるかもしれません。 接続要求がイングレスノードで処理される前に、ダイナミックな協会の場合には、発見メカニズムはtimeslot/ラベルレベルで動作します。 2つのノードが直接接続される場合では、どんな協会もそうでないことに注意してください。

Papadimitriou, et al.        Informational                      [Page 8]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[8ページ]のRFC4139GMPLS

   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]を見てください)。 これらのインスタンスに、ラベル協会機能は地方のラベル値に受け取られているのに関する1〜1つのマッピングを提供します。

4.6.  Support for Crankback

4.6. Crankbackのサポート

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

Crankbackは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.

また、Crankbackメカニズムは、接続回復の間、失敗したリンクかノードの位置を示すことによって、適用されるかもしれません。 これは失敗した接続のためにうまくいっている回復比をかなり改良するでしょう、特に多くのセットアップ要求が同時に引き起こされる状況で。

   The following mechanisms are assumed during crankback signaling:

以下のメカニズムはcrankbackシグナリングの間、想定されます:

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

以下の特性はcrankbackシグナリングのために予想されます:

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

- エラー情報固執: ブロッキングリソース、接続が首尾よく確立されるか、またはエラーメッセージにみられるように試みを別ルートで送るノード放棄までSHOULDが識別子を保存する(コースを変更すること)代替の経路を計算する実体。 crankbackが特定の接続、歴史を確立している間の一度より起こるかもしれないので、すべてのこの接続SHOULDに、経験豊富な封鎖では、維持されて(ルーティング・プロトコルが少なくともこの情報の状態をアップデートするまで)、すべての封鎖を避ける正確な経路計算を実行してください。

Papadimitriou, et al.        Informational                      [Page 9]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[9ページ]のRFC4139GMPLS

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

- コースを変更するのは制限を試みます: 接続設定試み(crankback情報を使用する)、再試行の数の終わりのない繰り返しを防ぐために、制限されて、SHOULDは厳密にそうです。 試みが許したcrankbackのコースを変更することの最大数は接続かノード単位で制限されるかもしれません:

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

- 特定のノードでの再試行の数が超えられているとき、現在失敗を扱っているノードは、エラーメッセージが次の修理ノードに上流であると報告します。(さらに試みを別ルートで送るのはノードで実行されるかもしれません)。 情報が提供したcrankbackが、このノードを通してコースを変更するのが成功しないのを示すのは、重要です。

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

- 特定の接続のための再試行の最大数が超えられているとき、現在の失敗SHOULDが「超えられていた再routingsの最大数」を示すためにエラーメッセージ上流を送る取り扱いである修理ノードです。 さらに試みを別ルートで送らないで、このエラーメッセージはイングレスノードに返送されるでしょう。 次に、イングレスノードは、ローカルの方針によると、接続設定を再試行するのを選ぶかもしれません、元の経路を使用するか、またはブロッキングリソースを避ける経路を計算して。

      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.

以下に注意してください。 いくつかの再試行の後に、与えられた修理ポイントは封鎖のすべてを避ける目的地ノードに経路を計算できないかもしれません。 この場合、それは次の修理ポイントにエラーメッセージ上流を通り過ぎなければなりません。

4.7.  Support for Additional Error Cases

4.7. 追加誤り事件のサポート

   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.

- 誤りは基本的な呼び出しと柔らかい永久接続サポートと交際しました。 例えば、これらの5月はIDのCallに、不正確な課題か優しい永久接続にとって、無効のインタフェース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.

- 誤りはサービスレベルの不正確な仕様と交際しました。

Papadimitriou, et al.        Informational                     [Page 10]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[10ページ]のRFC4139GMPLS

5.  Backward Compatibility

5. 後方の互換性

   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シグナル伝達機構を全体でネットワークに有害でない方法で先在させることによってそれらを拒絶できるようにものであるに違いありません。

6. Security Considerations

6. セキュリティ問題

   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]を見てください)。

7.  Acknowledgements

7. 承認

   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、彼の貢献のためのこのドキュメントへのZhi-ウェイ・リン、私たちのASONモデルの理解における彼女の入力と指導のためのデボラBrungard、および彼の復号化取り組みのためのゲルトGrammelに感謝したがっています。

Papadimitriou, et al.        Informational                     [Page 11]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[11ページ]のRFC4139GMPLS

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC3471]       Berger, L., "Generalized Multi-Protocol Label
                   Switching (GMPLS) Signaling Functional Description",
                   RFC 3471, January 2003.

[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、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)拡大」、RFC3473、2003年1月。

8.2.  Informative References

8.2. 有益な参照

   [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-オーバレイ]のツバメ、G.、ドレイク、J.、Ishimatsu、H.、およびY.Rekhter、「Multiprotocolラベルの切り換え(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]マニー(E.とD.Papadimitriou)は、「同期式光通信網(Sonet)と同期デジタルハイアラーキ(SDH)コントロールのためのマルチプロトコルラベルの切り換え(GMPLS)拡大を一般化しました」、RFC3946、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]オールド-BrahimとH.とY.Rekhter、Eds、「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月。

Papadimitriou, et al.        Informational                     [Page 12]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[12ページ]のRFC4139GMPLS

   [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(2001年10月)年2月の 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、「転送ネットワークのジェネリック機能的な建築)」、Recommendation G.805、3月2000日の 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] 11月2001(そして、改正、2003年1月)「自動的に光学で切り換えられるアーキテクチャはネットワークでつなASON()」ITU-t、推薦G.8080/Y.1304、 http://www.itu.int

Papadimitriou, et al.        Informational                     [Page 13]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[13ページ]のRFC4139GMPLS

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(電子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.

管理飛行機: Transport Plane、制御飛行機、および全体でシステムのために管理機能を実行します。 また、それはすべての飛行機の間にコーディネートを供給します。 以下の管理の機能的な領域は管理飛行機で実行されます: 性能、欠点、構成、会計、およびセキュリティ管理。

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

輸送機: ユーザー情報の1つの位置からもう1つの位置までの双方向か単方向の転送を供給します。 また、それは何らかのコントロールとネットワークマネージメント情報の転送を供給できます。 Transport Planeは層にされて、G.805[ITU-T-G.805]で定義されたTransport Networkに同等です。

Papadimitriou, et al.        Informational                     [Page 14]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[14ページ]のRFC4139GMPLS

   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アルカテルフランシスWellesplein1、B-2018アントウェルペン(ベルギー)

   Phone: +32 3 2408491
   EMail: dimitri.papadimitriou@alcatel.be

以下に電話をしてください。 +32 3 2408491 メール: dimitri.papadimitriou@alcatel.be

   John Drake
   Boeing Satellite Systems
   2300 East Imperial Highway
   El Segundo, CA 90245

エルセガンド、ジョンドレイクボーイングサテライト・システム2300の東帝国のHighwayカリフォルニア 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はメールされます: 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研究室、余地のMT D5-2A01 200ローレルアベニューミドルタウン、ニュージャージー 07748、米国

   EMail: gash@att.com

メール: gash@att.com

   Lyndon Ong
   Ciena
   PO Box 308
   Cupertino, CA 95015, USA

カルパチーノ、リンドンオングCiena PO Box308カリフォルニア 95015、米国

   EMail: lyong@ciena.com

メール: lyong@ciena.com

Papadimitriou, et al.        Informational                     [Page 15]

RFC 4139     GMPLS Signaling Usage and Extensions for ASON     July 2005

Papadimitriou、他 2005年7月にASONのために用法と拡大に合図する情報[15ページ]のRFC4139GMPLS

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

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

Papadimitriou, et al.        Informational                     [Page 16]

Papadimitriou、他 情報[16ページ]