Network Working Group D. Papadimitriou, Ed.
Request for Comments: 4652 Alcatel
Category: Informational L.Ong
Ciena
J. Sadler
Tellabs
S. Shew
Nortel
D. Ward
Cisco
October 2006
Evaluation of Existing Routing Protocols against
Automatic Switched Optical Network (ASON) Routing Requirements
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Networks (OTNs).
プロトコルの一般化MPLS（GMPLS）スイートは、異なるスイッチング技術、ならびにさまざまなアプリケーションを制御するために定義されています。これらは、同期光ネットワーク/同期デジタル階層（SONET / SDH）および光トランスポートネットワーク（OTNs）を含むTDM接続を要求するためのサポートが含まれています。
This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T.
この文書では、ITU-Tによって定義されるような自動交換光ネットワーク（ASON）のルーティング要件に対してIETFルーティングプロトコルの評価を提供します。
Certain capabilities are needed to support the ITU-T Automatically Switched Optical Network (ASON) control plane architecture as defined in [G.8080].
特定の機能は[G.8080]で定義されるように自動的に光ネットワーク（ASON）制御プレーンアーキテクチャをスイッチITU-Tをサポートするために必要とされます。
[RFC4258] details the routing requirements for the GMPLS routing suite of protocols to support the capabilities and functionality of ASON control planes identified in [G.7715] and in [G.7715.1]. The ASON routing architecture provides for a conceptual reference architecture, with definition of functional components and common information elements to enable end-to-end routing in the case of protocol heterogeneity and to facilitate management of ASON networks. This description is only conceptual: no physical partitioning of these functions is implied.
[RFC4258]は[G.7715]および[G.7715.1]において同定ASONの制御プレーンの機能と機能をサポートするためのプロトコルのスイートをルーティングGMPLSのルーティング要件を詳述します。 ASONルーティングアーキテクチャは、プロトコルの不均一の場合には、エンドツーエンドルーティングをイネーブルにし、ASONネットワークの管理を容易にするための機能構成要素と共通の情報要素の定義で、概念的な参照アーキテクチャを提供します。この説明は、単に概念的なものであり：これらの機能の物理的な分割は暗示されません。
However, [RFC4258] does not address GMPLS routing protocol applicability or capabilities. This document evaluates the IETF Routing Protocols against the requirements identified in [RFC4258]. The result of this evaluation is detailed in Section 5. Close examination of applicability scenarios and the result of the evaluation of these scenarios are provided in Section 6.
ただし、[RFC4258]はGMPLSルーティングプロトコルの適用性や機能には対応していません。この文書では、[RFC4258]で特定された要件に対して、IETFルーティングプロトコルを評価します。この評価の結果は、5節閉じる適用シナリオの検討及びこれらのシナリオは、第6節で提供されているの評価の結果に詳細です。
ASON (Routing) terminology sections are provided in Appendices A and B.
ASON（ルーティング）用語セクションは付録AおよびBに設けられています。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The reader is expected to be familiar with the terminology introduced in [RFC4258].
読者は、[RFC4258]に導入された用語に精通していることが予想されます。
This document is the result of the CCAMP Working Group ASON Routing Solution design team's joint effort.
この文書では、CCAMPワーキンググループASONルーティングソリューションの設計チームの共同の努力の結果です。
Dimitri Papadimitriou (Alcatel, Team Leader and Editor) EMail: dimitri.papadimitriou@alcatel.be Chris Hopps (Cisco) EMail: chopps@rawdofmt.org Lyndon Ong (Ciena Corporation) EMail: lyong@ciena.com Jonathan Sadler (Tellabs) EMail: jonathan.sadler@tellabs.com
ディミトリPapadimitriou（アルカテル、チームリーダーとエディタ）メール：dimitri.papadimitriou@alcatel.beクリスHoppsが（シスコ）メール：chopps@rawdofmt.orgリンドンオング（シエナコーポレーション）メール：lyong@ciena.comジョナサン・サドラー（テラブス）メール：jonathan.sadler@tellabs.com
Stephen Shew (Nortel Networks) EMail: sdshew@nortel.com Dave Ward (Cisco) EMail: dward@cisco.com
スティーブン供え（ノーテルネットワーク）メール：sdshew@nortel.comデイブ・ワード（シスコ）メール：dward@cisco.com
The following functionality is expected from GMPLS routing protocols to instantiate the ASON hierarchical routing architecture realization (see [G.7715] and [G.7715.1]):
次の機能は、ASON階層ルーティングアーキテクチャの実現を（[G.7715]と[G.7715.1]を参照）をインスタンス化するGMPLSルーティングプロトコルから期待されています。
- Routing Areas (RAs) shall be uniquely identifiable within a carrier's network, each having a unique RA Identifier (RA ID) within the carrier's network.
- ルーティングエリア（RAS）は、キャリアのネットワーク内で一意に識別しなければならない、それぞれがキャリアのネットワーク内で一意の識別子RA（RA ID）を有します。
- Within a RA (one level), the routing protocol shall support dissemination of hierarchical routing information (including summarized routing information for other levels) in support of an architecture of multiple hierarchical levels of RAs; the number of hierarchical RA levels to be supported by a routing protocol is implementation specific.
- RA（1つのレベル）内では、ルーティングプロトコルは、Rasの複数階層のアーキテクチャをサポートするために（他のレベルのための要約ルーティング情報を含む）階層ルーティング情報の普及をサポートしなければなりません。ルーティングプロトコルによってサポートされる階層RAレベルの数は、実装固有です。
- The routing protocol shall support routing information based on a common set of information elements as defined in [G.7715] and [G.7715.1], divided between attributes pertaining to links and abstract nodes (each representing either a sub-network or simply a node). [G.7715] recognizes that the manner in which the routing information is represented and exchanged will vary with the routing protocol used.
- [G.7715]で定義されるようにルーティングプロトコルは、情報要素の共通のセットに基づいてルーティング情報をサポートしなければならないし、[G.7715.1]、（それぞれのいずれかのサブネットワークまたは単に表すリンク及び要約ノードに関連する属性間で分割しますノード）。 [G.7715]は、ルーティング情報を表現及び交換される方法が使用されるルーティングプロトコルに応じて変化することを認識する。
- The routing protocol shall converge such that the distributed Routing DataBases (RDB) become synchronized after a period of time.
- ルーティングプロトコルは、分散型ルーティングデータベース（RDB）は、時間の期間後に同期なるように収束しなければなりません。
To support dissemination of hierarchical routing information, the routing protocol must deliver:
階層型ルーティング情報の普及をサポートするために、ルーティングプロトコルが提供しなければなりません。
- Processing of routing information exchanged between adjacent levels of the hierarchy (i.e., Level N+1 and N), including reachability and (upon policy decision) summarized topology information.
- （ポリシー決定時に）到達可能性を含む階層（即ち、レベルN + 1、N）の隣接するレベル間で交換されるルーティング情報の処理は、トポロジ情報を要約します。
- Self-consistent information at the receiving level resulting from any transformation (filter, summarize, etc.) and forwarding of information from one Routing Controller (RC) to RC(s) at different levels when multiple RCs are bound to a single RA.
- 複数のRCが単一のRAに結合されている場合、任意の変換から得られた受信レベルでの自己一貫性情報（フィルタは、等、要約）と異なるレベルでRC（S）へのルーティングコントローラ（RC）からの情報の転送。
- A mechanism to prevent re-introduction of information propagated into the Level N RA's RC back to the adjacent level RA's RC from which this information has been initially received.
- バックこの情報が最初に受信された隣接するレベルRAのRCにレベルN RAのRCに伝播情報の再導入を防止するための機構。
Note: The number of hierarchical levels to be supported is routing protocol specific and reflects a containment relationship.
注：サポートされる階層の数が特定のプロトコルをルーティングし、包含関係を反映しています。
Reachability information may be advertised either as a set of UNI Transport Resource address prefixes, or as a set of associated Subnetwork Point Pool (SNPP) link IDs/SNPP link ID prefixes, assigned and selected consistently in their applicability scope. The formats of the control plane identifiers in a protocol realization are implementation specific. Use of a routing protocol within a RA should not restrict the choice of routing protocols for use in other RAs (child or parent).
到達可能性情報は、UNIトランスポートリソースアドレスプレフィクスのセットとして、またはそれらの適用範囲内に一貫して割り当てられ、選択された関連するサブネットワークポイントプール（SNPP）リンクID / SNPPリンクIDプレフィックスの組のいずれかアドバタイズすることができます。プロトコル実現における制御プレーン識別子の形式は実装特有です。 RA内のルーティングプロトコルの使用は、他のRA（子または親）で使用するためのルーティングプロトコルの選択を制限するべきではありません。
As ASON does not restrict the control plane architecture choice, either a co-located architecture or a physically separated architecture may be used. A collection of links and nodes, such as a sub-network or RA, must be able to represent itself to the wider network as a single logical entity with only its external links visible to the topology database.
ASONは、制御プレーン・アーキテクチャの選択肢を制限しないように同一位置のアーキテクチャまたは物理的に分離されたアーキテクチャのいずれかを使用することができます。このようなサブネットワークまたはRAなどのリンク及びノードの集合は、トポロジデータベースに見えるだけその外部リンクを持つ単一の論理エンティティとしてより広いネットワークに自分自身を表現することができなければなりません。
This section evaluates support of existing IETF routing protocols with respect to the requirements summarized from [RFC4258] in Section 4. Candidate routing protocols are Interior Gateway Protocol (IGP) (OSPF and Intermediate System to Intermediate System (IS-IS)) and BGP. The latter is not addressed in the current version of this document. BGP is not considered a candidate protocol mainly because of the following reasons:
このセクションは、セクション4候補ルーティングプロトコルに[RFC4258]から要約要件に対してIETFルーティングプロトコルを既存のサポートされているインテリアゲートウェイプロトコル（IGP）（OSPFおよび中間システム中間システムに（IS-IS））およびBGPを評価します。後者は、このドキュメントの現在のバージョンで対処されていません。 BGPは、主に以下の理由の候補プロトコルとはみなされません。
- Non-support of TE information exchange. Each BGP router advertises only its path to each destination in its vector for loop avoidance, with no costs or hop counts; each BGP router knows little about network topology.
- TEの情報交換の非サポート。各BGPルータは、無コストやホップ数とループ回避のためにそのベクトル内の各目的地への唯一のパスを、アドバタイズ。各BGPルータは、ネットワークトポロジについて少し知っています。
- BGP can only advertise routes that are eligible for use (local RIB) or routing loops can occur; there is one best route per prefix, and that is the route that is advertised.
- BGPは、利用（ローカルRIB）またはルーティングループが発生する可能性の対象となるルートをアドバタイズすることができます。そこプレフィックスごとに最良のルートがあり、それが広告を出しているルートです。
- BGP is not widely deployed in optical equipment and networks.
- BGPは広く光学機器とネットワークに配備されていません。
- Pi is a physical (bearer/data/transport plane) node.
- Piは、物理的（ベアラ/データ/搬送面）ノードです。
- Li is a logical control plane entity that is associated to a single data plane (abstract) node. The Li is identified by the TE Router_ID. The latter is a control plane identifier defined as follows:
- Liが単一のデータ・プレーン（要約）ノードに関連付けられている論理制御プレーンエンティティです。リーは、TE ROUTER_IDによって識別されます。後者は、以下のように定義された制御プレーン識別子です。
[RFC3630]: Router_Address (top level) TLV of the Type 1 TE LSA
[RFC3784]: Traffic Engineering Router ID TLV (Type 134)
Note: This document does not define what the TE Router ID is. This document simply states the use of the TE Router ID to identify Li. [RFC3630] and [RFC3784] provide the definitions.
注意：この文書は、TEルータIDが何であるかを定義していません。この文書では、単にリチウムを識別するためのTEルータIDを使用することを述べています。 [RFC3630]及び[RFC3784]は定義を提供します。
- Ri is a logical control plane entity that is associated to a control plane "router". The latter is the source for topology information that it generates and shares with other control plane "routers". The Ri is identified by the (advertising) Router_ID
- Riが制御プレーン「ルータ」に関連付けられている論理制御プレーンエンティティです。後者は、それが生成され、他の制御プレーン「ルータ」と共有するトポロジ情報のソースです。 R 1は（広告）によって識別されROUTER_ID
[RFC2328]: Router ID (32-bit)
[RFC1195]: IS-IS System ID (48-bit)
The Router_ID, which is represented by Ri and which corresponds to the RC_ID [RFC4258], does not enter into the identification of the logical entities representing the data plane resources such as links. The Routing DataBase (RDB) is associated to the Ri. Note that, in the ASON context, an arrangement consisting of multiple Ris announcing routing information related to a single Li is under evaluation.
Riを表されるとRC_ID [RFC4258]に対応しているROUTER_IDは、このようなリンクのようなデータプレーンリソースを表す論理エンティティの識別に入りません。ルーティングデータベース（RDB）はRIに関連しています。 ASONの文脈において、単一のLiに関連する複数Risを発表ルーティング情報からなる配置は評価中であることに留意されたいです。
Aside from the Li/Pi mappings, these identifiers are not assumed to be in a particular entity relationship except that the Ri may have multiple Lis in its scope. The relationship between Ri and Li is simple at any moment in time: an Li may be advertised by only one Ri at any time. However, an Ri may advertise a set of one or more Lis. Thus, the routing protocol MUST be able to advertise multiple TE Router IDs (see Section 5.7).
脇のLi / PIマッピングから、これらの識別子は、Riは、その範囲内に複数のリスを有していてもよいことを除いて、特定のエンティティの関係にあると仮定されていません。 Rおよびリチウムとの関係は、時間の任意の瞬間に簡単である：Liが任意の時点でのみ1個のR 1によって通知されてもよいです。しかし、Riが一つ以上のリスのセットを広告することがあります。したがって、ルーティングプロトコルは、複数のTEルータID（セクション5.7を参照）を広告することができなければなりません。
Note: Si is a control plane signaling function associated with one or more Lis. This document does not assume any specific constraint on the relationship between Si and Li. This document does not discuss issues of control plane accessibility for the signaling function, and it makes no assumptions about how control plane accessibility to the Si is achieved.
注：Siは一つ以上のLisの関連付けられた制御プレーンシグナリング機能です。この文書では、SiとLiとの関係に関する具体的な制約を負いません。この文書では、シグナリング機能のための制御プレーンアクセシビリティの問題を議論していない、そしてそれは、Siにコントロールプレーンのアクセシビリティを達成する方法についての仮定を行いません。
G.7715.1 notes some necessary characteristics for RA identifiers, e.g., that they may provide scope for the Ri, and that they must be provisioned to be unique within an administrative domain. The RA ID format itself is allowed to be derived from any global address space. Provisioning of RA IDs for uniqueness is outside the scope of this document.
G.7715.1は、彼らがRIの範囲を提供し、それらは管理ドメイン内で一意であるようにプロビジョニングされなければならないことができること、例えば、RAの識別子のいくつかの必要な特性を指摘しています。 RA IDフォーマット自体は任意のグローバルアドレス空間に由来すると許可されています。一意性のためのRA IDのプロビジョニングは、この文書の範囲外です。
Under these conditions, GMPLS link state routing protocols provide the capability for RA Identification without further modification.
これらの条件下では、GMPLSのリンクステートルーティングプロトコルは、さらに変更を加えることなくRA識別のための機能を提供します。
In this section, the focus is on routing information exchange Ri entities (through routing adjacencies) within a single hierarchical level. Routing information mapping between levels require specific processing (see Section 5.5).
このセクションでは、焦点は、単一の階層レベル内（ルーティング隣接介して）情報交換Riをエンティティのルーティングです。レベル間の情報のマッピングをルーティング（5.5節を参照）、特定の処理を必要とします。
The control plane does not transport Pi identifiers, as these are data plane addresses for which the Li/Pi mapping is kept (link) local; see, for instance the transport LMP document [RFC4394] where such an exchange is described. Example: The transport plane identifier is the Pi (the identifier assigned to the physical element) that could be, for instance, "666B.F999.AF10.222C", whereas the control plane identifier is the Li (the identifier assigned by the control plane), which could be, for instance, "192.0.2.1".
これらは、Li / PIマッピングが（リンク）ローカルに維持されているデータ・プレーン・アドレスであるように、制御プレーンは、Piの識別子を搬送しません。例えば、参照してそのような交換が記載されて搬送LMP文献[RFC4394]。例：制御プレーン識別子は、Li（制御によって割り当てられた識別子であるのに対し、トランスポート・プレーン識別子は、例えば、「666B.F999.AF10.222C」かもしれないPI（物理的要素に割り当てられた識別子）であります例えば、「192.0.2.1」のために、可能性が平面）、。
The control plane exchanges the control plane identifier information, but not the transport plane identifier information (i.e., not "666B.F999.AF10.222C", but only "192.0.2.1"). The mapping Li/Pi is kept local. So, when the Si receives a control plane message requesting the use of "192.0.2.1", Si knows locally that this information refers to the data plane entity identified by the transport plane identifier "666B.F999.AF10.222C".
制御プレーン交換制御プレーン識別情報ではなく、搬送面識別子情報（すなわち、ない「666B.F999.AF10.222C」だけ「192.0.2.1」）。マッピングのLi / Piがローカルに保持されます。 Siは、「192.0.2.1」の使用を要求する制御プレーンのメッセージを受信したときに、Siがこの情報は、トランスポート・プレーン識別子「666B.F999.AF10.222C」によって識別されるデータプレーンエンティティを指すことがローカルに知っています。
Note also that the Li and Pi addressing spaces may be identical.
Liとパイのアドレッシングスペースは同一であってもよいことにも注意してください。
The control plane carries:
制御プレーンは運び。
1) its view of the data plane link end-points and other link connection end-points.
データプレーンリンクエンドポイントと他のリンクの接続のエンドポイントの1）の図。
2) the identifiers scoped by the Lis, i.e., referred to as an associated IPv4/IPv6 addressing space. Note that these identifiers may be either bundled TE link addresses or component link addresses.
2）すなわちリスによってスコープ識別子は、関連付けられたIPv4 / IPv6のアドレス空間と呼びます。これらの識別子は、どちらかTEリンクアドレスまたはコンポーネントのリンクアドレスを同梱することができることに注意してください。
3) when using OSPF or ISIS as the IGP in support of traffic engineering, [RFC3477] RECOMMENDS that the Li value (referred to the "LSR Router ID") be set to the TE Router ID value.
トラフィックエンジニアリングのサポートにIGPとしてOSPFまたはIS-ISを使用した場合3）、[RFC3477]は「LSRルータID」と呼ばれるのLi値を（）TEルータID値に設定することをお勧めします。
Therefore, OSPF and IS-IS carry sufficient node identification information without further modification.
したがって、OSPFおよびIS-ISは、さらなる改変なしに十分なノード識別情報を運びます。
[RFC4258] provides a list of link attributes and characteristics that need to be advertised by a routing protocol. All TE link attributes and characteristics are currently handled by OSPF and IS-IS (see Table 1) with the exception of Local Adaptation support. Indeed, GMPLS routing does not currently consider the use of dedicated TE link attribute(s) to describe the cross/inter-layer relationships.
[RFC4258]は、リンク属性とルーティングプロトコルによってアドバタイズされる必要がある特性のリストを提供します。すべてのTEリンク属性や特性は、現在、OSPFによって処理し、IS-ISローカル適応支援を除いた（表1参照）されています。確かに、GMPLSルーティングは現在、クロス/レイヤ間の関係を記述するために、専用のTEリンク属性（複数可）の使用を考慮していません。
In addition, the representation of bandwidth requires further consideration. GMPLS Routing defines an Interface Switching Capability Descriptor (ISCD) that delivers information about the (maximum/ minimum) bandwidth per priority of which an LSP can make use. This information is usually used in combination with the Unreserved Bandwidth sub-TLV that provides the amount of bandwidth not yet reserved on a TE link.
また、帯域幅の表現はさらに検討が必要です。 GMPLSルーティングLSPを利用することができるの優先度当たり（最大値/最小値）帯域幅に関する情報を配信するインタフェーススイッチング能力記述子（ISCD）を定義します。この情報は、通常、未TEリンク上で予約された帯域幅の量を提供する未予約帯域幅サブTLVと組み合わせて使用されます。
In the ASON context, other bandwidth accounting representations are possible, e.g., in terms of a set of tuples <signal_type; number of unallocated timeslots>. The latter representation may also require definition of additional signal types (from those defined in [RFC3946]) to represent support of contiguously concatenated signals, i.e., STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.
ASONの文脈において、他の帯域幅アカウンティング表現はタプル<signal_typeの組の点で、例えば、可能です。未割り当てのタイムスロットの数>。後者の表現はまた、連続連結信号、すなわち、STS-（3XN）のC SPE / VC-4-NC、N = 4、16の支持を表すために（[RFC3946]で定義されたものから）追加の信号タイプの定義を必要とするかもしれません64、256。
However, the method proposed in [RFC4202] is the most straightforward without requiring any bandwidth accounting change from an LSR perspective (in particular, when the ISCD sub-TLV information is combined with the information provided by the Unreserved Bandwidth sub-TLV).
しかしながら、[RFC4202]で提案された方法は、（ISCDサブTLV情報が未予約帯域幅サブTLVによって提供された情報と組み合わされ、特に、）LSRの観点から任意の帯域幅アカウンティング変更を必要とせずに最も簡単です。
Link Characteristics GMPLS OSPF
----------------------- ----------
Local SNPP link ID Link-local part of the TE link identifier
sub-TLV [RFC4203]
Remote SNPP link ID Link remote part of the TE link identifier
sub-TLV [RFC4203]
Signal Type Technology specific part of the Interface
Switching Capability Descriptor sub-TLV
[RFC4203]
Link Weight TE metric sub-TLV [RFC3630]
Resource Class Administrative Group sub-TLV [RFC3630]
Local Connection Types Switching Capability field part of the
Interface Switching Capability Descriptor
sub-TLV [RFC4203]
Link Capacity Unreserved bandwidth sub-TLV [RFC3630]
Max LSP Bandwidth part of the Interface
Switching Capability Descriptor sub-TLV
[RFC4203]
Link Availability Link Protection sub-TLV [RFC4203]
Diversity Support SRLG sub-TLV [RFC4203]
Local Adaptation support See above
Table 1. TE link attributes in GMPLS OSPF-TE
GMPLS OSPF-TE表1. TEリンク属性
Link Characteristics GMPLS IS-IS
----------------------- -----------
Local SNPP link ID Link-local part of the TE link identifier
sub-TLV [RFC4205]
Remote SNPP link ID Link-remote part of the TE link identifier
sub-TLV [RFC4205]
Signal Type Technology specific part of the Interface
Switching Capability Descriptor sub-TLV
[RFC4205]
Link Weight TE Default metric [RFC3784]
Resource Class Administrative Group sub-TLV [RFC3784]
Local Connection Types Switching Capability field part of the
Interface Switching Capability Descriptor
sub-TLV [RFC4205]
Link Capacity Unreserved bandwidth sub-TLV [RFC3784]
Max LSP Bandwidth part of the Interface
Switching Capability Descriptor sub-TLV
[RFC4205]
Link Availability Link Protection sub-TLV [RFC4205]
Diversity Support SRLG sub-TLV [RFC4205]
Local Adaptation support See above
Table 2. TE link attributes in GMPLS IS-IS-TE
2. TEリンクがGMPLSの属性表は、IS-IS-TE
Note: Link Attributes represent layer resource capabilities and their utilization i.e. the IGP should be able to advertise these attributes on a per-layer basis.
注：リンク属性、すなわちIGPは、レイヤ単位のベースでこれらの属性を宣伝することができるはず層リソースの機能とその利用率を表します。
Node attributes are the "Logical Node ID" (described in Section 5.1) and the reachability information described in Section 5.3.3.
ノードの属性は、「論理ノードID」（セクション5.1で説明）と、セクション5.3.3で説明した到達可能性情報です。
Advertisement of reachability can be achieved using the techniques described in [OSPF-NODE], where the set of local addresses are carried in an OSPF TE LSA node attribute TLV (a specific sub-TLV is defined per address family, e.g., IPv4 and IPv6). However, [OSPF-NODE] is restricted to advertisement of Host addresses and not prefixes, and therefore it requires enhancement (see below). Thus, in order to advertise blocks of reachable address prefixes a summarization mechanism is additionally required. This mechanism may take the form of a prefix length (which indicates the number of significant bits in the prefix) or a network mask.
到達可能性の広告は、ローカルアドレスのセットを（特定のサブTLVは、例えば、IPv4およびIPv6アドレスファミリごとに定義されているOSPF TE LSAノード属性TLVで搬送される[OSPF-NODE]に記載された技術を用いて達成することができます）。ただし、[OSPF-NODE]ホストアドレスではなくプレフィックスの広告に制限されているので、それは（下記参照）の拡張が必要です。したがって、到達可能なアドレスプレフィックスのブロックをアドバタイズするために、集計機構がさらに必要です。このメカニズムは、（接頭辞の有効ビットの数を示す）プレフィックス長またはネットワークマスクの形態をとることができます。
A similar mechanism does not exist for IS-IS. Moreover, the Extended IP Reachability TLV [RFC3784] focuses on IP reachable end-points (terminating points), as its name indicates.
同様のメカニズムは、IS-ISのために存在していません。その名が示すようにさらに拡張IP到達可能性TLV [RFC3784]は、IP到達可能なエンドポイント（終端点）に焦点を当てています。
G.7715.1 describes both static and dynamic methods for abstraction of routing information for advertisement at a different level of the routing hierarchy. However, the information that is advertised continues to be in the form of link and node advertisements consistent with the link state routing protocol used at that level. Hence, no specific capabilities need to be added to the routing protocol beyond the ability to locally identify when routing information originates outside of a particular RA.
G.7715.1はルーティング階層の異なるレベルでの広告のためのルーティング情報を抽象化するための静的および動的両方の方法を記載しています。しかし、アドバタイズされた情報は、そのレベルで使用されるリンク状態ルーティングプロトコルと一致するリンクとノード広告の形態であり続けています。したがって、具体的な機能は、ルーティング情報が特定のRAの外に発信する場合、ローカルに識別する能力を超えてルーティングプロトコルに追加する必要がありません。
The methods used for abstraction of routing information are outside the scope of GMPLS routing protocols.
ルーティング情報の抽象化のために使用される方法は、GMPLSルーティングプロトコルの範囲外です。
5.5. Dissemination of Routing Information in Support of Multiple Hierarchal Levels of RAs
5.5. Rasの複数の階層レベルのサポートでルーティング情報の普及
G.7715.1 does not define specific mechanisms to support multiple hierarchical levels of RAs beyond the ability to support abstraction as discussed above. However, if RCs bound to adjacent levels of the RA hierarchy are allowed to redistribute routing information in both directions between adjacent levels of the hierarchy without any additional mechanisms, they would not be able to determine looping of routing information.
G.7715.1は、上述のように抽象化をサポートする能力を超えRasの複数の階層レベルをサポートするために特定のメカニズムを定義していません。 RA階層の隣接するレベルに結合したレンジングコードは、任意の付加的な機構なし階層の隣接するレベル間の両方向のルーティング情報を再配布を許可されている場合は、それらは、ルーティング情報のループを決定することはできないであろう。
To prevent this looping of routing information between levels, IS-IS [RFC1195] allows only advertising routing information upward in the level hierarchy and disallows the advertising of routing information downward in the hierarchy. [RFC2966] defines the up/down bit to allow advertising downward in the hierarchy the "IP Internal Reachability Information" TLV (Type 128) and "IP External Reachability Information" TLV (Type 130). [RFC3784] extends its applicability for the "Extended IP Reachability" TLV (Type 135). Using this mechanism, the up/down bit is set to 0 when routing information is first injected into IS-IS. If routing information is advertised from a higher level to a lower level, the up/down bit is set to 1, indicating that it has traveled down the hierarchy. Routing information that has the up/down bit set to 1 may only be advertised down the hierarchy, i.e., to lower levels. This mechanism applies independently of the number of levels. However, this mechanism does not apply to the "Extended IS Reachability" TLV (Type 22) used to propagate the summarized topology (see Section 5.3), traffic engineering information as listed in Table 1, as well as reachability information (see Section 5.3.3).
IS-IS [RFC1195]は、階層内の上方にルーティング情報をアドバタイズ可能、レベル間でルーティング情報のこのループを防止し、階層内の下方ルーティング情報の広告を禁止します。 [RFC2966]は、階層「IP内部到達可能性情報」TLV（タイプ128）と「IP外部到達可能性情報」TLV（タイプ130）に下方広告を可能にするために、アップ/ダウンビットを定義します。 [RFC3784]は "拡張IP到達可能性" TLV（タイプ135）のためにその適用性を拡張します。ルーティング情報が最初に注入されたときに、この機構を使用して、アップ/ダウンビットが0に設定されている、です。ルーティング情報は、低いレベルに上位からアドバタイズされている場合は、アップ/ダウンビットは、それが階層を下り走行したことを示す、1に設定されています。アップ/ダウンビット1に設定されているルーティング情報のみ、すなわち、より低いレベルに、階層を下にアドバタイズされてもよいです。このメカニズムは、独立してレベルの数の適用されます。しかし、このメカニズムは、同様に到達可能性情報（5.3節を参照してくださいとして、表1に記載されているように（セクション5.3を参照）、トラフィックエンジニアリング情報まとめトポロジを伝播するために使用される「IS拡張到達可能性」TLV（タイプ22）には適用されません。 3）。
OSPFv2 [RFC2328] prevents inter-area routes (which are learned from area 0) from being passed back to area 0. However, GMPLS makes use of Type 10 (area-local scope) LSAs to propagate TE information [RFC3630], [RFC4202]. Type 10 Opaque LSAs are not flooded beyond the borders of their associated area. It is therefore necessary to have a means by which Type 10 Opaque LSA may carry the information that a particular piece of routing information has been learned from a higher-level RC when propagated to a lower-level RC. Any downward RC from this level, which receives an LSA with this information would omit the information in this LSA and thus not re-introduce this information back into a higher-level RC.
OSPFv2の[RFC2328]はバックエリア0に渡されてから（エリア0から学習された）エリア間のルートを防止しかし、GMPLSは、タイプ10（エリアローカルスコープ）を利用するTE情報[RFC3630]を伝播するためのLSA、[RFC4202 ]。 10型不透明LSAは、それらに関連する地域の国境を越えてあふれません。タイプ10オペークLSAは、下位レベルのRCに伝播するときルーティング情報の特定の部分は、より高いレベルのRCから学習されたという情報を運ぶことができる手段を有することが必要です。この情報をLSAを受信し、このレベルからの任意の下方RCは、このLSAの情報を省略して、より高いレベルのRCに戻し、この情報を再導入しないであろう。
Link state protocols have been designed to propagate detected topological changes (such as interface failures and link attributes modification). The convergence period is short and involves a minimum of routing information exchange.
リンクステートプロトコルは、（そのようなインタフェースの障害やリンクの変更属性など）トポロジの変更を検出し伝播するように設計されています。収束時間は短く、情報交換ルーティングの最小値を含みます。
Therefore, existing routing protocol convergence involves mechanisms that are sufficient for ASON applications.
したがって、ルーティングプロトコルの収束を既存のASON用途のために十分であるメカニズムを含みます。
The routing protocol MUST support a single Ri advertising on behalf of more than one Li. Since each Li is identified by a unique TE Router ID, the routing protocol MUST be able to advertise multiple TE Router IDs. That is, for [RFC3630], multiple Router Addresses and for [RFC3784] multiple Traffic Engineering Router Ids.
ルーティングプロトコルは、複数のリチウムの代わりに、単一のRi広告をサポートしなければなりません。各Liは一意TEルータIDによって識別されるので、ルーティングプロトコルは、複数のTEルータIDをアドバタイズすることができなければなりません。それは、[RFC3630]、複数のルータアドレスのためにと[RFC3784]複数のトラフィックエンジニアリングルータIDについて、です。
The Link sub-TLV that is currently part of the top level Link TLV associates the link to the Router_ID. However, having the Ri advertising on behalf of multiple Lis creates the following issue, as there is no longer a 1:1 relationship between the Router_ID and the TE Router_ID, but a 1:N relationship is possible (see Section 5.1). As the link-local and link-remote (unnumbered) ID association may not be unique per abstract node (per Li unicity), the advertisement needs to indicate the remote Lj value and rely on the initial discovery process to retrieve the {Li;Lj} relationship(s). In brief, as unnumbered links have their ID defined on per Li bases, the remote Lj needs to be identified to scope the link remote ID to the local Li. Therefore, the routing protocol MUST be able to disambiguate the advertised TE links so that they can be associated with the correct TE Router ID.
現在、トップレベルのリンクTLVの一部であるリンクのサブTLVはROUTER_IDへのリンクを関連付けます。 （セクション5.1を参照）Nの関係が可能です：ROUTER_IDとTE ROUTER_ID間の1の関係が、1：そこに1がもはやしかし、複数のリスに代わってのRi広告を有する、次の問題を作成しません。リンクローカルおよびリンク遠隔（番号なし）IDの関連付けは、リチウム（Liの単一性当たり）抽象ノードごとに一意でなくてもよいように、広告は、リモートLjの値を示し、{リチウムを取得するために最初の発見プロセスに頼る必要がある。Ljを}の関係（S）。簡単に言えば、などアンナンバードリンクは、Li拠点ごとに定義された自分のIDは、リモートLjのスコープにローカルリーへのリンクのリモートIDを識別する必要があります。したがって、ルーティングプロトコルは、彼らが正しいTEルータIDに関連付けることができるようにアドバタイズTEリンクを明確にすることができなければなりません。
Moreover, when the Ri advertises on behalf multiple Lis, the routing protocol MUST be able to disambiguate the advertised reachability information (see Section 5.3.3) so that it can be associated with the correct TE Router ID.
Riは代わっ複数Lisの上にアドバタイズするとき、それは正しいTEルータIDに関連付けることができるように、また、ルーティングプロトコル（セクション5.3.3を参照）アドバタイズ到達可能性情報を明確にすることができなければなりません。
The evaluation scenarios are the following; they are respectively referred to as cases 1, 2, 3, and 4.
評価のシナリオは次のとおりです。彼らは、それぞれのケース1、2、3、及び4と呼ばれます。
In Figure 1, below,
図1に、以下、
- R3 represents an LSR with all components collocated. - R2 shows how the "router" component may be disjoint from the node. - R1 shows how a single "router" may manage multiple nodes.
- R3は、並置すべてのコンポーネントとLSRを表します。 - R2は、「ルータ」コンポーネントがノードから互いに素とすることができる方法を示しています。 - R1は、単一の「ルータ」は複数のノードを管理する方法を示しています。
------------------- -------
|R1 | |R2 |
| | | | ------
| L1 L2 L3 | | L4 | |R3 |
| : : : | | : | | |
| : : : | | : | | L5 |
Control ---+-----+-----+--- ---+--- | : |
Plane : : : : | : |
----------------+-----+-----+-----------+-------+---+--+-
Data : : : : | : |
Plane -- : -- -- | -- |
----|P1|--------|P3|--------|P4|------+-|P5|-+-
-- \ : / -- -- | -- |
\ -- / | |
|P2| ------
--
Figure 1. Evaluation Cases 1, 2, and 3
図1評価ケース1、2、および3
Case 1 as represented refers either to direct links between edges or to "logical links" as shown in Figure 2 (or any combination of them).
図2（又はそれらの任意の組み合わせ）に示すように表されるように、ケース1は、エッジ間又は「論理リンク」への直接リンクのいずれかを指します。
------ ------
| | | |
| L1 | | L2 |
| : | | : |
| : R1| | : R2|
Control Plane --+--- --+---
Elements : :
------------------+-----------------------------+------------------
Data Plane : :
Elements : :
----+-----------------------------+-----
| : : |
| --- --- --- |
| | |----------| P |----------| | |
---+--| | --- | |---+---
| | | | | |
| | P1|-------------------------| P2| |
| --- --- |
----------------------------------------
Figure 2. Case 1 with Logical Links
論理リンク図2.ケース1
Another case (referred to as Case 4) is constituted by the Abstract Node as represented in Figure 3. There is no internal structure associated (externally) to the abstract node.
図3に示すように、別のケース（ケース4と呼ぶ）は抽象ノードで構成されている抽象ノードに（外部から）関連する内部構造はありません。
--------------
|R4 |
| |
| L6 |
| : |
| ...... |
---:------:---
Control Plane : :
+------+------+------+
Data Plane : :
---:------:---
|P8 : : |
| -- -- |
--+-|P |----|P |-+--
| -- -- |
--------------
Figure 3. Case 4: Abstract Node
図3.ケース4：抽象ノード
Note: the "signaling function" referred to as Si, i.e., the control plane entity that processes the signaling messages, is not represented in these figures.
注：Siの、シグナリングメッセージを処理、すなわち、制御プレーンエンティティと称される「シグナル伝達機能」は、これらの図に示されていません。
The following sections summarize the additions to be provided to OSPF and IS-IS in support of ASON routing.
以下のセクションでは、追加がOSPFに提供するとASONルーティングをサポートするIS-IS要約します。
Reachability Extend Node Attribute sub-TLVs to support address prefixes (see Section 5.3.3).
到達可能性は、ノードを拡張します（セクション5.3.3を参照してください）アドレスプレフィックスをサポートするために、サブTLVを属性。
Link Attributes Representation of cross/inter-layer relationships in link top-level link TLV (see Section 5.3.1).
リンクは、リンク、トップレベルのリンクTLV（5.3.1項を参照）で、クロス/層間の関係の表現を属性。
Optionally, provide for per-signal-type bandwidth
accounting (see Section 5.3.1).
Scoping TE link advertisements to allow for retrieving their respective local-remote TE Router_ID relationship(s) (see Section 5.7).
それぞれのローカル・リモートTE ROUTER_ID関係（複数可）を取得するためにできるように、TEリンク広告をスコープ（5.7節を参照してください）。
Prefixes part of the reachability advertisement
(using Node Attribute top-level TLV) needs to be
associated to its respective local TE Router_ID
(see Section 5.7).
Hierarchy Provide a mechanism by which Type 10 Opaque LSA may carry the information that a particular piece of routing information has been learned from a higher-level RC when propagated to a lower-level RC (so as not to re-introduce this information into a higher-level RC).
階層は、下位RC（ように、この情報を再導入しないに伝播するときオペークLSAは、ルーティング情報の特定の部分は、より高いレベルのRCから学習されたという情報を搬送することができるどのタイプ10メカニズムを提供します上位RC）。
Reachability Provide for reachability advertisement (in the form of reachable TE prefixes).
到達可能性は、（到達可能なTEプレフィックスの形で）到達可能性広告を提供します。
Link Attributes Representation of cross/inter-layer relationships in Extended IS Reachability TLV (see Section 5.3.1).
リンクされた延長到達可能性TLV（5.3.1項を参照）で、クロス/レイヤ間の関係の表現を属性。
Optionally, provide for per-signal-type bandwidth
accounting (see Section 5.3.1).
Scoping Extended IS Reachability TLVs to allow for retrieving their respective local-remote TE Router_ID relationship(s) (see Section 5.7).
到達可能性のTLVがそれぞれのローカル・リモートTE ROUTER_ID関係（複数可）を取得するためにできるように拡張されスコープ（5.7節を参照してください）。
Prefixes part of the reachability advertisement
needs to be associated to its respective local TE
Router_ID (see Section 5.7).
Hierarchy Extend the up/down bit mechanisms to propagate the summarized topology (see Section 5.3) and traffic engineering information as listed in Table 1, as well as reachability information (see Section 5.3.3).
階層は、到達可能性情報（セクション5.3.3を参照）と同様に、表1に示すように要約トポロジー（セクション5.3を参照）、トラフィックエンジニアリング情報を伝達するためにアップ/ダウンビットメカニズムを拡張します。
The introduction of a dynamic control plane to an ASON network exposes it to additional security risks that may have been controlled or limited by the use of management plane solutions. The routing protocols play a part in the control plane and may be attacked so that they become unstable or provide incorrect information for use in path computation or by the signaling protocols.
ASONネットワークへの動的制御プレーンの導入を制御又は管理プレーンソリューションの使用によって制限されていてもよい付加的なセキュリティリスクにそれを公開します。ルーティングプロトコルは、制御プレーンにおいて役割を果たし、それらが不安定になったり、経路計算またはシグナリングプロトコルで使用するために誤った情報を提供するように攻撃することができます。
Nevertheless, there is no reason why the control plane components cannot be secured, and the security mechanisms developed for the routing protocol and used within the Internet are equally applicable within an ASON context.
それにもかかわらず、そこに制御プレーンのコンポーネントを確保することができない理由はなく、ルーティングプロトコルのために開発され、インターネット内で使用されるセキュリティメカニズムは、ASONコンテキスト内でも同様に適用可能です。
[RFC4258] describes the requirements for security of routing protocols for the Automatically Switched Optical Network. Reference is made to [M.3016], which lays out the overall security objectives of confidentiality, integrity, and accountability. These are well discussed for the Internet routing protocols in [THREATS].
[RFC4258]は自動的に交換光ネットワークのためのルーティングプロトコルのセキュリティのための要件について説明します。リファレンスは、機密性、完全性、および説明責任の全体的なセキュリティ対策方針をレイアウトする[M.3016]になっています。これらは当[脅威]のインターネットルーティングプロトコルのために議論されています。
A detailed discussion of routing threats and mechanisms that are currently deployed in operational networks to counter these threats is found in [OPSECPRACTICES]. A detailed listing of the device capabilities that can be used to support these practices can be found in [RFC3871].
現在、これらの脅威に対抗するために動作ネットワークに配備されているルーティングの脅威とメカニズムの詳細な議論は、[OPSECPRACTICES]に見出されます。これらの慣行をサポートするために使用することができるデバイスの機能の詳細なリストは、[RFC3871]で見つけることができます。
The authors would like to thank Adrian Farrel for having initiated the proposal of an ASON Routing Solution Design Team and the ITU-T SG15/Q14 for their careful review and input.
著者は、彼らの慎重に検討し、入力のためにASONルーティングソリューション設計チームとITU-T SG15 / Q14の提案を開始したためエードリアンファレルに感謝したいと思います。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[RFC2966]李、T.、Przygienda、T.、およびH.スミット、RFC 2966、2000年10月の "2レベルでドメイン全体のプレフィックス配布は-IS IS"。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K.とY. Rekhter、 "資源予約プロトコルでアンナンバードリンクシグナリング - トラフィックエンジニアリング（RSVP-TE）"、RFC 3477、2003年1月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、2003年9月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング（TE）のための中間システム（IS-IS）への拡張"、RFC 3784、2004年6月。
[RFC3871] Jones, G., Ed., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004.
[RFC3871]ジョーンズ、G.、エド。、RFC 3871 "大規模なインターネットサービスプロバイダー（ISP）IPネットワークインフラの運用セキュリティ要件"、2004年9月。
[RFC3946] 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.
[RFC3946]マニー、E.およびD. Papadimitriou、 "一般化マルチプロトコルラベルスイッチング（GMPLS）同期光ネットワーク（SONET）および同期デジタル階層（SDH）コントロールのための拡張機能"、RFC 3946、2004年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、エド。、およびY. Rekhter、エド。、 "ルーティング拡張一般マルチプロトコルラベルスイッチング（GMPLS）のサポートで"、RFC 4202、2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、エド。、およびY. Rekhter、エド。、RFC 4203、2005年10月 "OSPF拡張一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで"。
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4205] Kompella、K.、エド。、およびY. Rekhter、エド。、 "中間システム（GMPLS）をスイッチング汎用マルチプロトコルラベルの支援における中間システム（IS-IS）への拡張"、RFC 4205、2005年10月。
[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005.
[RFC4258] Brungard、D.、2005年11月、RFC 4258。 "一般マルチプロトコルラベルのための要件は、自動的に光ネットワークを（ASON）スイッチのルーティング（GMPLS）を切り替えます"
[RFC4394] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J., and D. Papadimitriou, "A Transport Network View of the Link Management Protocol (LMP)", RFC 4394, February 2006.
[RFC4394] Fedyk、D.、のAboul-Magd、O.、Brungard、D.、ラング、J.、およびD. Papadimitriou、 "リンク管理プロトコルのトランスポート・ネットワークビュー（LMP）"、RFC 4394、2006年2月。
[OPSECPRACTICES] Kaeo, M., "Operational Security Current Practices", Work in Progress, July 2006.
[OPSECPRACTICES] Kaeoの、M.、 "運用セキュリティの現在のプラクティス"、進歩、2006年7月での作業。
[OSPF-NODE] Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF TE Extensions", Work in Progress, June 2006.
[OSPF-NODE]アガルワル、R.とK. Kompella、 "OSPF TE Extensionsでルータのローカルアドレスをアドバタイズ"、進歩、2006年6月での作業。
[THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[脅威] Barbir、A.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、RFC 4593、2006年10月。
For information on the availability of ITU Documents, please see http://www.itu.int
ITU文書の入手については、http://www.itu.intを参照してください。
[G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and Requirements for the Automatically Switched Optical Network (ASON)", June 2002.
[G.7715] ITU-T勧告。 、2002年6月G.7715 / Y.1306、「自動的に交換光ネットワーク（ASON）のためのアーキテクチャと要件」。
[G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing Architecture and Requirements for Link State Protocols", November 2003.
【G.7715.1] ITU-Tドラフト撮影。 G.7715.1 / Y.1706.1、「ASONルーティングアーキテクチャとリンクステートプロトコルのための要件」、2003年11月。
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)", June 2006.
[G.8080] ITU-T勧告。 G.8080 / Y.1304、2006年6月 "自動的に交換光ネットワーク（ASON）のためのアーキテクチャ"。
[M.3016] ITU-T Rec. M.3016.0, "Security for the Management Plane: Overview", May 2005.
[M.3016] ITU-T勧告。 M.3016.0、「管理プレーンのセキュリティ：概要」、2005年5月。
Appendix A. ASON Terminology
付録A. ASON用語
This document makes use of the following terms:
このドキュメントでは、次の用語を使用します：
Administrative domain (see Recommendation G.805): For the purposes of [G.7715.1], an administrative domain represents the extent of resources that belong to a single player such as a network operator, a service provider, or an end-user. Administrative domains of different players do not overlap amongst themselves.
管理ドメイン（勧告G.805を参照）：[G.7715.1]の目的のために、管理ドメインは、ネットワークオペレータ、サービスプロバイダ、またはエンドユーザとしてシングルプレイヤーに属するリソースの程度を表します。異なるプレイヤーの管理ドメインは、それ自体で重複していません。
Control plane: Performs the call control and connection control functions. Through signaling, the control plane sets up and releases connections and may restore a connection in case of a failure.
コントロールプレーンは、呼制御と接続制御機能を実行します。シグナリングを介して、制御プレーンがセットアップ及びリリース接続が故障した場合の接続を復元することができます。
(Control) Domain: Represents a collection of (control) entities that are grouped for a particular purpose. The control plane is subdivided into domains matching administrative domains. Within an administrative domain, further subdivisions of the control plane are recursively applied. A routing control domain is an abstract entity that hides the details of the RC distribution.
（コントロール）ドメイン：特定の目的のためにグループ化されている（制御）エンティティのコレクションを表します。制御プレーンは、管理ドメインに一致するドメインに細分されます。管理ドメイン内に、制御プレーンのさらなる細分化を再帰的に適用されます。経路制御ドメインは、RC分布の詳細を隠蔽する抽象エンティティです。
External NNI (E-NNI): Interfaces are located between protocol controllers 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): A "topological component" that describes a fixed relationship between a "subnetwork" or "access group" and another "subnetwork" or "access group". Links are not limited to being provided by a single server trail.
リンク（勧告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): A management domain defines a collection of managed objects that are grouped to meet organizational requirements according to geography, technology, policy, or other structure, and for a number of functional areas such as fault, configuration, accounting, performance, and security (FCAPS), for the purpose of providing control in a consistent manner. Management domains can be disjoint, contained, or overlapping. As such, the resources within an administrative domain can be distributed into several possible overlapping management domains.
管理ドメイン（勧告G.805を参照してください）：管理ドメインは、地理、技術、政策、または他の構造に応じて、組織の要件を満たすためにグループ化された管理対象オブジェクトのコレクションを定義し、そのような障害、構成などの機能領域の数について一貫した方法で制御を提供する目的のために、アカウンティング、性能、およびセキュリティ（FCAPS）。管理ドメインが含まれる、互いに素、または重複することができます。このように、管理ドメイン内のリソースは、いくつかの可能な重複管理ドメイン内に分布させることができます。
The same resource can therefore belong to several management domains simultaneously, but a management domain shall not cross the border of an administrative domain.
同じリソースは、したがって、同時に複数の管理ドメインに属することができますが、管理ドメインは、管理ドメインの境界を越えてはなりません。
Subnetwork Point (SNP): The SNP is a control plane abstraction that represents an actual or potential transport plane resource. SNPs (in different subnetwork partitions) may represent the same transport resource. A one-to-one correspondence should not be assumed.
サブネットワークポイント（SNP）：SNPは、実際のまたは潜在的なトランスポート・プレーン・リソースを表す制御プレーン抽象化です。 （異なるサブネットワークパーティション内）SNPは、同じトランスポートリソースを表すことができます。 1対1の対応が想定されるべきではありません。
Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together for the purposes of routing.
サブネットワークポイントプール（SNPP）：ルーティングの目的のために一緒にグループ化されるSNPのセット。
Termination Connection Point (TCP): A TCP represents the output of a Trail Termination function or the input to a Trail Termination Sink function.
終端接続ポイント（TCP）：TCPは、トレイル終端シンク機能にトレイル終端機能または入力の出力を表します。
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; it is equivalent to the Transport Network defined in G.805 Recommendation.
トランスポートプレーンは：一つの場所から別のものに、双方向またはユーザ情報の一方向の移動を提供します。また、いくつかの制御とネットワーク管理情報の転送を提供することができます。トランスポートプレーンは層状です。それは、G.805勧告で定義されたトランスポートネットワークと同等です。
User Network Interface (UNI): Interfaces are located between protocol controllers between a user and a control domain. Note: There is no routing function associated with a UNI reference point.
ユーザネットワークインターフェイス（UNI）：インタフェースは、ユーザーおよび制御ドメインとの間のプロトコル・コントローラとの間に位置しています。注：UNI基準点に関連付けられたルーティング機能はありません。
Appendix B. ASON Routing Terminology
付録B. ASONルーティング用語
This document makes use of the following terms:
このドキュメントでは、次の用語を使用します：
Routing Area (RA): An RA represents a partition of the data plane, and its identifier is used within the control plane as the representation of this partition. Per [G.8080], an RA is defined by a set of sub-networks, the links that interconnect them, and the interfaces representing the ends of the links exiting that RA. An RA may contain smaller RAs inter-connected by links. The limit of subdivision results in an RA that contains two sub-networks interconnected by a single link.
ルーティングエリア（RA）：RAは、データプレーンのパーティションを表し、その識別子は、このパーティションの表現として制御プレーン内で使用されています。 [G.8080]、RAは、サブネットワークのセットによって定義され、それらを相互接続するリンク、及びそのRAを出るリンクの両端を表すインターフェイス。 RAは小さいRAのリンクによって相互接続されているが含まれていてもよいです。単一のリンクによって相互接続された2つのサブネットワークを含んRAにおける細分割結果の限界。
Routing Database (RDB): Repository for the local topology, network topology, reachability, and other routing information that is updated as part of the routing information exchange and that may additionally contain information that is configured. The RDB may contain routing information for more than one Routing Area (RA).
ルーティングデータベース（RDB）：ルーティング情報交換の一部として更新され、それがさらに構成されている情報を含むことができるローカル・トポロジ、ネットワークトポロジ、到達可能性、および他のルーティング情報のリポジトリ。 RDBは、複数のルーティングエリア（RA）のためのルーティング情報を含んでいてもよいです。
Routing Components: ASON routing architecture functions. These functions can be classified as being protocol independent (Link Resource Manager or LRM, Routing Controller or RC) and protocol specific (Protocol Controller or PC).
ルーティングコンポーネント：ASONルーティングアーキテクチャ機能。これらの機能は、プロトコルに依存しない（リンクリソースマネージャまたはLRM、ルーティングコントローラまたはRC）とプロトコルの特定（プロトコル・コントローラまたはPC）に分類することができます。
Routing Controller (RC): Handles (abstract) information needed for routing and the routing information exchange with peering RCs by operating on the RDB. The RC has access to a view of the RDB. The RC is protocol independent.
ルーティングコントローラ（RC）：ルーティングとRDB上で操作してのRCをピアリングとルーティング情報を交換するために必要なハンドル（アブストラクト）情報。 RCは、RDBのビューへのアクセスを持っています。 RCはプロトコルに依存しています。
Note: Since the RDB may contain routing information pertaining to multiple RAs (and possibly to multiple layer networks), the RCs accessing the RDB may share the routing information.
注：RDBは、複数のRA（および場合によっては複数層ネットワークへ）に関連するルーティング情報を含むかもしれないので、RDBにアクセスRCSはルーティング情報を共有することができます。
Link Resource Manager (LRM): Supplies all the relevant component and TE link information to the RC. It informs the RC about any state changes of the link resources it controls.
リンクリソースマネージャ（LRM）：RCに関連するすべてのコンポーネントとTEリンク情報を提供します。それはそれが制御するリンクリソースのいずれかの状態の変化についてのRCを通知します。
Protocol Controller (PC): Handles protocol-specific message exchanges according to the reference point over which the information is exchanged (e.g., E-NNI, I-NNI) and internal exchanges with the RC. The PC function is protocol dependent.
プロトコルコントローラ（PC）（例えば、E-NNI、I-NNI）情報が交換される上の基準点に係るプロトコル固有のメッセージ交換を処理およびRCと内部交換。 PCの機能は、プロトコルに依存しています。
Authors' Addresses
著者のアドレス
Dimitri Papadimitriou, Ed. Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel.be
ディミトリPapadimitriou、ES。 ALCATELフランシスVellensplein 1 B-2018アントワープ、Velgiomボイス：X2 + 3 2408491メールアドレス：δημήτρη.παπαδημητρίου@αλκατελ.βε
Lyndon Ong Ciena Corporation PO Box 308 Cupertino, CA 95015 , USA Phone: +1 408 705 2978 EMail: lyong@ciena.com
リンドン・オングCienaの株式会社私書箱308クパチーノ、CA 95015、USA電話：+1 408 705 2978 Eメール：lyong@ciena.com
Jonathan Sadler Tellabs 1415 W. Diehl Rd Naperville, IL 60563 EMail: jonathan.sadler@tellabs.com
ジョナサン・サドラーテラブス1415 W. DiehlのRdのネーパーヴィル、IL 60563 Eメール：jonathan.sadler@tellabs.com
Stephen Shew Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA K2H 8E9 Phone: +1 613 7632462 EMail: sdshew@nortel.com
スティーブン供えNortel Networksの3500カーリングアベニュー。オタワ、オンタリオ、カナダK2Hの8E9電話：+1 613 7632462 Eメール：sdshew@nortel.com
Dave Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1-408-526-4000 EMail: dward@cisco.com
デイブ・ワードシスコシステムズ170 W.タスマン博士サンノゼ、CA 95134 USA電話：+ 1-408-526-4000 Eメール：dward@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。