RFC4652 日本語訳
4652 Evaluation of Existing Routing Protocols against AutomaticSwitched Optical Network (ASON) Routing Requirements. D.Papadimitriou, Ed., L.Ong, J. Sadler, S. Shew, D. Ward. October 2006. (Format: TXT=47179 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループD.Papadimitriou、エドをネットワークでつないでください。コメントのために以下を要求してください。 4652年のアルカテルカテゴリ: 情報のL.のS.シューノーテルD.区シスコオングCiena J.サドラーTellabs2006年10月
Evaluation of Existing Routing Protocols against
Automatic Switched Optical Network (ASON) Routing Requirements
自動切り換えられた光学ネットワーク(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 (2006).
Copyright(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).
プロトコルのGeneralized MPLS(GMPLS)スイートは、異なったアプリケーションと同様に異なった切り換え技術を制御するために定義されました。 これらは同期式光通信網/同期デジタルハイアラーキを含むTDM接続(Sonet/SDH)とOptical Transport Networks(OTNs)を要求するサポートを含んでいます。
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によって定義されるようにAutomatically Switched Optical Network(ASON)のためのルーティング要件に対してIETFルート設定プロトコルの評価を提供します。
Papadimitriou, et al. Informational [Page 1] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[1ページ]のRFC4652評価
1. Introduction
1. 序論
Certain capabilities are needed to support the ITU-T Automatically Switched Optical Network (ASON) control plane architecture as defined in [G.8080].
ある能力が、[G.8080]で定義されるようにITU-T Automatically Switched Optical Network(ASON)規制飛行機構造をサポートするのに必要です。
[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]はプロトコルのGMPLSルーティングスイートが[G.7715]と[G.7715.1]で特定されたASON制御飛行機の能力と機能性を支持するというルーティング要件を詳しく述べます。 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(ルート設定)用語部をAppendices AとBに提供します。
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 RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
The reader is expected to be familiar with the terminology introduced in [RFC4258].
読者が[RFC4258]で紹介される用語によく知られさせると予想されます。
3. Contributors
3. 貢献者
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 クリス・ホップス(シスコ)EMail: chopps@rawdofmt.org リンドン・オング(Ciena社)EMail: lyong@ciena.com ジョナサンサドラー(Tellabs)はメールします: jonathan.sadler@tellabs.com
Papadimitriou, et al. Informational [Page 2] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[2ページ]のRFC4652評価
Stephen Shew (Nortel Networks)
EMail: sdshew@nortel.com
Dave Ward (Cisco)
EMail: dward@cisco.com
スティーブンシュー(ノーテルネットワーク)はメールされます: sdshew@nortel.com デーヴ区(シスコ)EMail: dward@cisco.com
4. Requirements: Overview
4. 要件: 概観
The following functionality is expected from GMPLS routing protocols to instantiate the ASON hierarchical routing architecture realization (see [G.7715] and [G.7715.1]):
GMPLSルーティング・プロトコルから、以下の機能性がASON階層型ルーティング構造実現を例示すると予想されます([G.7715]と[G.7715.1]を見てください):
- 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.
- ルート設定Areas(RAs)はキャリヤーのネットワークの中で唯一身元保証可能になるでしょう、キャリヤーのネットワークの中にそれぞれ、ユニークなRA Identifier(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.
- ルーティング・プロトコルが一点に集まるものとするので、分配されたルート設定DataBases(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.
- ルーティング情報の処理は階層構造の隣接しているレベルの間で(すなわち、Level 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.
- どんな変化からも生じる受信レベルにおける自己一貫した情報、(フィルタ、要約、など) そして、複数のRCsが独身のRAに縛られるときの異なったレベルにおける、情報の1ルート設定Controller(RC)からRC(s)までの推進。
- 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へのLevel N RAのRCに伝播されました。
Papadimitriou, et al. Informational [Page 3] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[3ページ]のRFC4652評価
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).
可到達性情報は、それらの適用性範囲で一貫して1セットのUNI Transport Resourceアドレス接頭語として、または、1セットの関連Subnetwork Point Pool(SNPP)リンクID/SNPPリンクID接頭語として広告を出して、割り当てられて、選択されるかもしれません。 プロトコル実現における、コントロール飛行機識別子の形式は実現特有です。 RAの中のルーティング・プロトコルの使用は他のRAs(子供か親)における使用のためにルーティング・プロトコルの選択を制限するべきではありません。
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などのノードはトポロジーデータベースへの外部のリンクだけが目に見えているただ一つの論理的な実体として、より広いネットワークにそれ自体を表すことができなければなりません。
5. Evaluation
5. 評価
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ルーティング・プロトコルのサポートを評価します。 候補ルーティング・プロトコルがInteriorゲートウェイプロトコル(IGP)である、(Intermediate SystemへのOSPFとIntermediate System、(-、)、そして、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)に、適任のルートの広告を出すことができるだけですか、またはルーティング輪は現れることができます。 1接頭語あたり1つの最も良いルートがあります、そして、それは広告に掲載されているルートです。
- BGP is not widely deployed in optical equipment and networks.
- BGPは光学機器とネットワークで広く配備されません。
5.1. Terminology and Identification
5.1. 用語と識別
- Pi is a physical (bearer/data/transport plane) node.
- パイは物理的な(運搬人/データ/輸送機)ノードです。
- 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:
- 李はただ一つのデータ飛行機(抽象的)のノードに関連づけられる論理的なコントロール飛行機実体です。 李はTE Router_IDによって特定されます。 後者は以下の通り定義されたコントロール飛行機識別子です:
Papadimitriou, et al. Informational [Page 4] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[4ページ]のRFC4652評価
[RFC3630]: Router_Address (top level) TLV of the Type 1 TE LSA
[RFC3784]: Traffic Engineering Router ID TLV (Type 134)
[RFC3630]: Type1TE LSA[RFC3784]のルータ_Address(トップレベル)TLV: 交通工学ルータID TLV(タイプ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 Router IDが何であるかを定義しません。 このドキュメントは、李を特定するために単にTE Router 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はコントロール飛行機「ルータ」に関連づけられる論理的なコントロール飛行機実体です。 後者は、それが発生させるトポロジー情報のためのソースと他のコントロール飛行機「ルータ」へのシェアです。 Riは(広告)ルータ_IDによって特定されます。
[RFC2328]: Router ID (32-bit)
[RFC1195]: IS-IS System ID (48-bit)
[RFC2328]: ルータID(32ビット)[RFC1195]: -、System ID(48ビット)
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.
Router_ID(Riによって表されて、RC_IDに対応します)[RFC4258]はリンクなどのデータ飛行機リソースを表す論理的な実体の識別に入りません。 ルート設定DataBase(RDB)はRiに関連づけられます。 ルーティング情報を発表する複数のリスから成るアレンジメントがASON文脈で独身の李に関連したというメモは評価中であります。
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).
李/パイマッピングは別として、Riには複数の李が範囲にいるかもしれない以外に、特定の実体関係にこれらの識別子があると思われません。 Riと李との関係は時間内に、いつ何時、簡単です: 李はいつでも、1Riだけによって広告を出されるかもしれません。 しかしながら、Riは1セットの1つか、より多くの李の広告を出すかもしれません。 したがって、ルーティング・プロトコルは複数のTE Router 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は1つに関連しているコントロール飛行機シグナル伝達機能であるか以上が李です。 このドキュメントはSiと李との関係における少しの特定の規制も仮定しません。 このドキュメントはシグナル伝達機能のためにコントロール飛行機のアクセシビリティの問題について議論しません、そして、それはSiへのコントロール飛行機のアクセシビリティがどう達成されるかに関する仮定を全くしません。
5.2. RA Identification
5.2. RA識別
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は管理ドメインの中でユニークな状態でRA識別子のためのいくつかの必要な特性、例えば、範囲をRiに供給するかもしれなくて、それらに食糧を供給しなければならないそれに注意します。 RA ID形式自体をどんなグローバルアドレススペースからも派生させることができます。 このドキュメントの範囲の外にユニークさのためのRA IDの食糧を供給することがあります。
Papadimitriou, et al. Informational [Page 5] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[5ページ]のRFC4652評価
Under these conditions, GMPLS link state routing protocols provide the capability for RA Identification without further modification.
これらの条件で、GMPLSリンク州のルーティング・プロトコルはさらなる変更なしで能力をRA Identificationに供給します。
5.3. Routing Information Exchange
5.3. 経路情報交換
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".
制御飛行機はPi識別子を輸送しません、これらが李/パイマッピングが地方に保たれる(リンクします)データ飛行機アドレスであるので。 見てください、そして、例えば、輸送LMPはそのような交換が説明される[RFC4394]を記録します。 例: 輸送機識別子が例えば、コントロール飛行機識別子が例えば、いるかもしれない李(制御飛行機によって割り当てられた識別子)ですが、"666B. F999.AF10.222C"であるかもしれないPi(物理的な要素に割り当てられた識別子)である、「192.0 .2 0.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 0.1インチ)、」 マッピング李/パイは地方であるとして保存されます。 そのように、Siがいつで使用を要求するコントロール飛行機メッセージを受け取るか、「192.0、.2、0.1インチ、Siがこの情報が"666B. F999.AF10.222C"という輸送機識別子によって特定されたデータ飛行機実体について言及するのを局所的に知っている、」
Note also that the Li and Pi addressing spaces may be identical.
また、空間を記述する李とPiが同じであるかもしれないことに注意してください。
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.
3) IGPとして交通工学を支持してOSPFかイシスを使用するとき、李値(「LSR Router ID」について言及する)をある[RFC3477]RECOMMENDSがTE Router ID価値にセットしました。
Therefore, OSPF and IS-IS carry sufficient node identification information without further modification.
そして、したがって、OSPF、-、さらなる変更なしで十分なノード識別情報を運んでください。
Papadimitriou, et al. Informational [Page 6] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[6ページ]のRFC4652評価
5.3.1. Link Attributes
5.3.1. リンク属性
[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によって扱われる、-、(Table1を見ます) Local Adaptationサポートを除いて。 本当に、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ルート設定は1LSPが使用をすることができる優先権あたりの(最大であるか最小)の帯域幅の周りで情報を配布するInterface Switching Capability Descriptor(ISCD)を定義します。 通常、この情報はTEリンクの上にまだ控えられていなかった帯域幅の量を供給するUnreserved Bandwidthサブ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文脈では、他の帯域幅会計表現は例えば、1セットのtuples<信号_タイプで可能です。 unallocated timeslots>の数。 また、後者の表現は、すなわち、近接して連結された信号、STS(3xN)c SPE / VC-4-Nc(N=4、16、64、256)のサポートを表すために追加信号タイプ([RFC3946]で定義されたものからの)の定義を必要とするかもしれません。
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).
しかしながら、LSR見解からの帯域幅会計方針変更を必要としないで、[RFC4202]で提案される中で方法は最も簡単です(ISCDサブTLV情報が特にUnreserved BandwidthサブTLVによって提供される情報に結合されるとき)。
Papadimitriou, et al. Informational [Page 7] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[7ページ]のRFC4652評価
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
リンク特性のGMPLS OSPF----------------------- ---------- 地方のSNPPはInterface Switching Capability DescriptorのサブTLV RFC4203 Link Weight TEのメートル法のサブTLV RFC3630 Resource Class Administrative GroupサブTLV RFC3630 Local ConnectionのTEのリンクの識別子のサブTLV RFC4203 Signal Type Technologyの特定の一部のTEのリンクの識別子のサブTLV RFC4203 Remote SNPPリンクID Linkリモートな一部分のIDのLink地方の一部分をリンクします; 上のInterface Switching Capability DescriptorサブTLV RFC4203 Link Availability Link ProtectionサブTLV RFC4203 Diversity Support SRLGサブTLV RFC4203 Local AdaptationサポートSeeのInterface Switching Capability DescriptorサブTLV RFC4203 Link Capacity Unreserved帯域幅サブTLV RFC3630マックスLSP Bandwidth部分のSwitching Capability分野一部分をタイプします。
Table 1. TE link attributes in GMPLS OSPF-TE
1を見送ってください。 GMPLS OSPF-TEの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
特性のGMPLSをリンクしてください、------------------------ ----------- 地方のSNPPはInterface Switching Capability DescriptorのサブTLV RFC4205 Link Weight TE Defaultのメートル法のRFC3784 Resource Class Administrative GroupサブTLV RFC3784 Local ConnectionのTEのリンクの識別子のサブTLV RFC4205 Signal Type Technologyの特定の一部のTEの識別子のサブTLV RFC4205 Remote SNPPのリンクのIDのLinkリモートなリンク一部分のIDのLink地方の一部分をリンクします; 上のInterface Switching Capability DescriptorサブTLV RFC4205 Link Availability Link ProtectionサブTLV RFC4205 Diversity Support SRLGサブTLV RFC4205 Local AdaptationサポートSeeのInterface Switching Capability DescriptorサブTLV RFC4205 Link Capacity Unreserved帯域幅サブTLV RFC3784マックスLSP Bandwidth部分のSwitching Capability分野一部分をタイプします。
Table 2. TE link attributes in GMPLS IS-IS-TE
2を見送ってください。 GMPLS ISがTEである状態でTEは属性を中にリンクします。
Papadimitriou, et al. Informational [Page 8] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[8ページ]のRFC4652評価
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.
以下に注意してください。 リンクAttributesは層のリソース能力と彼らの利用を表します、すなわち、IGPは1層あたり1個のベースにこれらの属性の広告を出すはずであることができます。
5.3.2. Node Attributes
5.3.2. ノード属性
Node attributes are the "Logical Node ID" (described in Section 5.1) and the reachability information described in Section 5.3.3.
ノード属性は、「論理的なNode ID」(セクション5.1では、説明される)とセクション5.3.3で説明された可到達性情報です。
5.3.3. Reachability Information
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.
ローカルのアドレスのセットがOSPF TE LSAノード属性TLVで運ばれる(特定のサブTLVはアドレス家族、例えば、IPv4、およびIPv6単位で定義されます)[OSPF-NODE]で説明されたテクニックを使用することで可到達性の広告を達成できます。 しかしながら、[OSPF-NODE]は接頭語ではなく、Hostアドレスの広告に制限されます、そして、したがって、それは増進を必要とします(以下を見てください)。 したがって、ブロックの届いているアドレス接頭語の広告を出すために、総括メカニズムがさらに、必要です。 このメカニズムは接頭語の長さ(接頭語の重要なビットの数を示す)のフォームかネットワークマスクを取るかもしれません。
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.
同様のメカニズムが存在していない、- そのうえ、名前が示すようにExtended IP Reachability TLV[RFC3784]はIPの届いているエンドポイント(終わりポイント)に焦点を合わせます。
5.4. Routing Information Abstraction
5.4. 経路情報抽象化
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
G.7715.1は、上で議論するように抽象化を支持する能力を超えてRAsの複数の階層レベルを支持するために特定のメカニズムを定義しません。 しかしながら、RCsであるなら、縛られて、RA階層構造の隣接しているレベルは両方でルーティング情報を再配付できます。
Papadimitriou, et al. Informational [Page 9] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[9ページ]のRFC4652評価
directions between adjacent levels of the hierarchy without any additional mechanisms, they would not be able to determine looping of routing information.
少しも追加メカニズムのない階層構造の隣接しているレベルの間の指示、彼らはルーティング情報のループを決定できないでしょう。
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).
レベルの間のルーティング情報のこのループを防ぐために-、[RFC1195]は、平らな階層構造で上向きに広告ルーティング情報だけを許容して、階層構造で下向きにルーティング情報の広告を禁じます。 [RFC2966]が定義する、上がるか下がる階層構造で下向きに、「IPの内部の可到達性情報」TLV(128をタイプする)と「IPの外部の可到達性情報」TLV(130をタイプする)の広告を出すのを許容するために噛み付かれた。 [RFC3784]は「拡張IPの可到達性」TLVのために適用性を広げています(135をタイプしてください)。 ルーティング情報が最初に注がれるとき、このメカニズムを使用して、噛み付かれた上がるか下がるのが0に設定される、- ルーティング情報が、より高いレベルから下のレベルまで広告に掲載されるなら、噛み付かれた上がるか下がるのが1に設定されます、それが階層構造の下側に移動したのを示して。 上がるか下がるのに噛み付く情報を発送して、階層構造の下側に1へのセットの広告を出すだけであるかもしれません、すなわち、下のレベルに。 このメカニズムはレベルの数の如何にかかわらず適用されます。 しかしながら、このメカニズムはまとめられたトポロジーを伝播するのに使用される「広げられているのは、可到達性です」TLV(22をタイプする)に適用されません(セクション5.3を見てください)、Table1にリストアップされている交通工学情報、可到達性情報と同様に(セクション5.3.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に戻されるのを防ぎます。 [RFC4202]、しかしながら、GMPLSはTE情報[RFC3630]を伝播するのにType10(領域の地方の範囲)LSAsを利用します。 タイプ10Opaque LSAsはそれらの関連領域の境界を超えてあふれません。 したがって、Type10Opaque LSAが低レベルRCに伝播されると特定のルーティング情報が、よりハイレベルのRCから学習されたという情報を運ぶかもしれない手段を持つのが必要です。 このレベルからのどんな下向きのRCでありも、どれがこの情報でLSAを受けるかが、このLSAで情報を省略して、その結果、よりハイレベルのRCにこの情報を再紹介して戻さないでしょう。
5.6. Routing Protocol Convergence
5.6. ルーティング・プロトコル集合
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アプリケーションに十分なメカニズムにかかわります。
Papadimitriou, et al. Informational [Page 10] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[10ページ]のRFC4652評価
5.7. Routing Information Scoping
5.7. 経路情報の見ること
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.
ルーティング・プロトコルは1以上を代表して李の広告を出す独身のRiを支持しなければなりません。 各李がユニークなTE Router IDによって特定されるので、ルーティング・プロトコルは複数のTE Router IDの広告を出すことができなければなりません。 すなわち、[RFC3630]、複数のRouter Addresses、および複数の[RFC3784]Traffic Engineering Router Idsのために。
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.
現在最高平らなLink TLVの一部であるLinkサブTLVはRouter_IDへのリンクを関連づけます。 しかしながら、複数の李を代表してRi広告を出していると、Router_IDとTE Router_IDの間には、1:1関係がもうありませんが、1:Nの関係が立てられるので(セクション5.1を見てください)、以下の問題は作成されます。 リンク地方の、そして、リンクリモートな(無数の)ID協会が抽象的なノード(李独自性あたりの)単位でユニークでないときに、広告がリモートLj値を示して、検索する初期の発見の過程を当てにする必要がある、李;、Lj、関係。 要するに、無数のリンクが李ベース単位でオンに定義されたそれらのIDを持っているとき、リモートLjは、地元の李への範囲のリンクの遠く離れたIDに特定される必要があります。 したがって、ルーティング・プロトコルは、正しいTE Router 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が利益として複数の李の広告を出すとき、そのうえ、ルーティング・プロトコルは、正しいTE Router IDにそれを関連づけることができるように、広告を出している可到達性情報(セクション5.3.3を見る)のあいまいさを除くことができなければなりません。
6. Evaluation Scenarios
6. 評価シナリオ
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は単一の「ルータ」がどう複数のノードを管理するかもしれないかを示しています。
Papadimitriou, et al. Informational [Page 11] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[11ページ]のRFC4652評価
------------------- -------
|R1 | |R2 |
| | | | ------
| L1 L2 L3 | | L4 | |R3 |
| : : : | | : | | |
| : : : | | : | | L5 |
Control ---+-----+-----+--- ---+--- | : |
Plane : : : : | : |
----------------+-----+-----+-----------+-------+---+--+-
Data : : : : | : |
Plane -- : -- -- | -- |
----|P1|--------|P3|--------|P4|------+-|P5|-+-
-- \ : / -- -- | -- |
\ -- / | |
|P2| ------
--
------------------- ------- |R1| |R2| | | | | ------ | L1 L2 L3| | L4| |R3| | : : : | | : | | | | : : : | | : | | L5| コントロール---+-----+-----+--- ---+--- | : | 飛行機: : : : | : | ----------------+-----+-----+-----------+-------+---+--+データ: : : : | : | 飛行機--、: -- -- | -- | ----|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).
表されるとしての1が図2(または、それらのどんな組み合わせ)に示されるように縁の間の直リンクか「論理的なリンク」を参照するケース。
------ ------
| | | |
| L1 | | L2 |
| : | | : |
| : R1| | : R2|
Control Plane --+--- --+---
Elements : :
------------------+-----------------------------+------------------
Data Plane : :
Elements : :
----+-----------------------------+-----
| : : |
| --- --- --- |
| | |----------| P |----------| | |
---+--| | --- | |---+---
| | | | | |
| | P1|-------------------------| P2| |
| --- --- |
----------------------------------------
------ ------ | | | | | L1| | L2| | : | | : | | : R1| | : R2| 制御飛行機--+--- --+--- Elements: : ------------------+-----------------------------+------------------ データ飛行機: : 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.
別のケース(Case4と呼ばれる)は図3に表されるように抽象的なNodeによって構成されます。 (外部的に)抽象的なノードに関連づけられたどんな内部の構造もありません。
Papadimitriou, et al. Informational [Page 12] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[12ページ]のRFC4652評価
--------------
|R4 |
| |
| L6 |
| : |
| ...... |
---:------:---
Control Plane : :
+------+------+------+
Data Plane : :
---:------:---
|P8 : : |
| -- -- |
--+-|P |----|P |-+--
| -- -- |
--------------
-------------- |R4| | | | L6| | : | | ...... | ---:------:--- 飛行機を制御してください: : +------+------+------+ データ飛行機: : ---:------:--- |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と呼ばれた「シグナル伝達機能」(すなわち、シグナリングメッセージを処理するコントロール飛行機実体)はこれらの数字に表されません。
7. Summary of Necessary Additions to OSPF and IS-IS
7. そして、OSPFへの必要な追加の概要、-
The following sections summarize the additions to be provided to OSPF and IS-IS in support of ASON routing.
そして、以下のセクションがOSPFに供給するために追加をまとめる、-、ASONルーティングを支持して。
7.1. OSPFv2
7.1. OSPFv2
Reachability Extend Node Attribute sub-TLVs to support address
prefixes (see Section 5.3.3).
サポートするためにはサブTLVsの可到達性Extend Node Attributeは接頭語を扱います(セクション5.3.3を見てください)。
Link Attributes Representation of cross/inter-layer relationships
in link top-level link TLV (see Section 5.3.1).
リンクトップレベルリンクTLVで相互十字/層の関係のAttributes Representationをリンクしてください(セクション5.3.1を見てください)。
Optionally, provide for per-signal-type bandwidth
accounting (see Section 5.3.1).
任意に、信号単位でタイプしている帯域幅会計に備えてください(セクション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は、それらのそれぞれの地方にリモートなTE Router_ID関係を検索すると考慮するために広告をリンクします(セクション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).
それぞれの地方のTE Router_ID(セクション5.7を見る)に関連づけられるべき可到達性広告(Node AttributeトップレベルTLVを使用する)の必要性の一部を前に置きます。
Papadimitriou, et al. Informational [Page 13] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[13ページ]のRFC4652評価
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).
階層構造Provide aメカニズムはどのType10Opaque LSAで、a低レベルRCに伝播されると(よりハイレベルのRCにこの情報を再紹介しないように)特定のルーティング情報が、よりハイレベルのRCから学習されたという情報を乗せるかもしれないか。
7.2. IS-IS
7.2. IS-IS
Reachability Provide for reachability advertisement (in the form
of reachable TE prefixes).
可到達性広告(届いているTE接頭語の形の)のための可到達性Provide。
Link Attributes Representation of cross/inter-layer relationships
in Extended IS Reachability TLV (see Section
5.3.1).
Extendedでの相互十字/層の関係のリンクAttributes RepresentationはReachability TLV(セクション5.3.1を見る)です。
Optionally, provide for per-signal-type bandwidth
accounting (see Section 5.3.1).
任意に、信号単位でタイプしている帯域幅会計に備えてください(セクション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).
Extendedを見るのは、彼らのそれぞれの地方にリモートなTE Router_ID関係を検索すると考慮するReachability TLVs(セクション5.7を見る)です。
Prefixes part of the reachability advertisement
needs to be associated to its respective local TE
Router_ID (see Section 5.7).
広告がそれぞれの地方のTE Router_IDに関連づけられるために必要とする可到達性(セクション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).
Table1に記載されているようにまとめられたトポロジー(セクション5.3を見る)と交通工学情報を伝播する階層構造の上がるか下がるExtendの噛み付いているメカニズム、および可到達性情報(セクション5.3.3を見ます)。
8. Security Considerations
8. セキュリティ問題
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文脈の中で等しく適切です。
Papadimitriou, et al. Informational [Page 14] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[14ページ]のRFC4652評価
[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]はAutomatically Switched Optical Networkのためにルーティング・プロトコルのセキュリティのための要件について説明します。 [M.3016]を参照します。(それは、秘密性、保全、および責任の総合的なセキュリティ目的を広げます)。 [THREATS]のインターネットルーティング・プロトコルのためにこれらについてよく議論します。
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]でこれらの習慣をサポートするのに使用できるデバイス能力の詳細なリストを見つけることができます。
9. Acknowledgements
9. 承認
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ルート設定ソリューションDesign TeamとITU-T SG15/Q14の提案を開始して頂いて、エードリアン・ファレルに感謝したがっています。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP
and dual environments", RFC 1195, December 1990.
[RFC1195]Callon、R.、「使用、TCP/IPと二元的な環境におけるルーティングのためのOSI IS存在、」、RFC1195、12月1990日
[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.スミット、「2レベルとのドメイン全体の接頭語分配、-、」、RFC2966、10月2000日
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[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月。
[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)」、RFC3477、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.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計するトラフィック、RFC3630、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)のための拡大、」、RFC3784(2004年6月)
Papadimitriou, et al. Informational [Page 15] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[15ページ]のRFC4652評価
[RFC3871] Jones, G., Ed., "Operational Security Requirements
for Large Internet Service Provider (ISP) IP
Network Infrastructure", RFC 3871, September 2004.
[RFC3871] ジョーンズ、G.、エド、「大きいインターネットサービスプロバイダ(ISP)IPネットワークインフラのための操作上のセキュリティ要件」、RFC3871、9月2004日
[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)は、「同期式光通信網(Sonet)と同期デジタルハイアラーキ(SDH)コントロールのためのマルチプロトコルラベルスイッチング(GMPLS)拡大を一般化しました」、RFC3946、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)をラベルします」、RFC4202、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(エド)、「一般化されたマルチプロトコルを支持したOSPF拡張子は切り換え(GMPLS)をラベルします」、RFC4203、2005年10月。
[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)をラベルする、」、RFC4205(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.、「一般化されたマルチプロトコルのための要件は自動的に切り換えられた光学ネットワーク(ASON)のために、切り換え(GMPLS)をルート設定とラベルします」、RFC4258、2005年11月。
10.2. Informative References
10.2. 有益な参照
[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)」、RFC4394(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 Te拡張子でルータのローカルのアドレスの広告を出し」て、[OSPF-ノード]のAggarwal、R.、およびK.Kompellaは進歩、2006年6月に働いています。
[THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic
Threats to Routing Protocols", RFC 4593, October
2006.
[脅威] 2006年10月のBarbirとA.とマーフィー、S.とY.陽、「ルーティング・プロトコルへのジェネリックの脅威」RFC4593。
Papadimitriou, et al. Informational [Page 16] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[16ページ]のRFC4652評価
For information on the availability of ITU Documents, please see http://www.itu.int
ITU Documentsの有用性の情報に関しては、 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 Rec。 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草稿Rec。 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 Rec。 G.8080/Y.1304、「自動的に切り換えられた光学ネットワーク(ASON)のためのアーキテクチャ」、2006年6月。
[M.3016] ITU-T Rec. M.3016.0, "Security for the Management
Plane: Overview", May 2005.
[M.3016]ITU-T Rec。 M.3016.0、「管理のためのセキュリティは平らにします」。 「概要」は2005がそうするかもしれません。
Papadimitriou, et al. Informational [Page 17] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[17ページ]のRFC4652評価
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.
管理ドメイン(Recommendation 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(電子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
管理飛行機: Transport Plane、制御飛行機、および全体でシステムのために管理機能を実行します。 また、それはすべての飛行機の間にコーディネートを供給します。 以下の管理の機能的な領域は管理飛行機で実行されます: 性能、欠点、構成、会計、およびセキュリティ管理
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.
管理ドメイン(Recommendation G.805を見ます): 管理ドメインは地理学、技術、方針、または他の構造、および多くの欠点や、構成や、会計や、性能や、セキュリティなどの機能的な領域のための組織的な必要条件(FCAPS)を満たすために分類される管理オブジェクトの収集を定義します、一貫した方法でコントロールを提供する目的のために。 管理ドメインは、含まれて、ばらばらになることであることができる、または重なっています。 そういうものとして、いくつかの可能な重なっている管理ドメインに管理ドメインの中のリソースを分配できます。
Papadimitriou, et al. Informational [Page 18] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[18ページ]のRFC4652評価
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は実際の、または、潜在的の輸送機リソースを表すコントロール飛行機抽象化です。 SNPs(異なったサブネットワークパーティションにおける)は同じ輸送リソースを表すかもしれません。 1〜1つの通信を想定するべきではありません。
Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together for the purposes of routing.
サブネットワークポイントプール(SNPP): ルーティングの目的のために一緒に分類されるSNPsの1セット。
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はTrail Termination機能か入力の出力をTrail Termination Sink機能に表します。
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.
輸送機: ユーザー情報の1つの位置からもう1つの位置までの双方向か単方向の転送を供給します。 また、それは何らかのコントロールとネットワークマネージメント情報の転送を供給できます。 Transport Planeは層にされます。 それはG.805 Recommendationで定義されたTransport Networkに同等です。
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を出るサブネットワーク、それらとインタコネクトするリンク、およびリンクの端を表すインタフェースの1セットによって定義されます。 RAはリンクによってインタコネクトされたより小さいRAsを含むかもしれません。 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は1ルート設定Area(RA)のためのルーティング情報を含むかもしれません。
Papadimitriou, et al. Informational [Page 19] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[19ページ]のRFC4652評価
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ルーティングアーキテクチャは機能します。 プロトコル独立者(Resourceマネージャ、LRM、ルート設定ControllerまたはRCをリンクする)とプロトコル特有であるとして(プロトコルControllerか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を作動させることによってルーティングとじっと見るRCsとのルーティング情報交換に必要としたハンドル。 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が複数のRAs(そしてことによると複数の層のネットワークに)に関係するルーティング情報を含むかもしれないので、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)をリンクしてください: 供給のすべての関連コンポーネントとTEは情報をRCにリンクします。 それはそれが制御するリンクリソースのどんな州の変化に関しても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機能はプロトコル扶養家族です。
Papadimitriou, et al. Informational [Page 20] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[20ページ]のRFC4652評価
Authors' Addresses
作者のアドレス
Dimitri Papadimitriou, Ed. Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel.be
ディミトリPapadimitriou、エドアルカテルフランシスWellensplein1、B-2018アントウェルペン、ベルギーは以下に電話をします。 +32 3 2408491 メール: dimitri.papadimitriou@alcatel.be
Lyndon Ong Ciena Corporation PO Box 308 Cupertino, CA 95015 , USA Phone: +1 408 705 2978 EMail: lyong@ciena.com
カルパチーノ、リンドンオングCiena社のPO Box308カリフォルニア 95015、米国は以下に電話をします。 +1 2978年の408 705メール: lyong@ciena.com
Jonathan Sadler Tellabs 1415 W. Diehl Rd Naperville, IL 60563 EMail: jonathan.sadler@tellabs.com
ジョナサンサドラーTellabs1415W.ディール・第ナパービル、不-60563はメールされます: jonathan.sadler@tellabs.com
Stephen Shew Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA K2H 8E9 Phone: +1 613 7632462 EMail: sdshew@nortel.com
スティーブンシューノーテルは3500縦梁Aveをネットワークでつなぎます。 オタワ、オンタリオ(カナダ)K2H8E9は以下に電話をします。 +1 613 7632462 メール: 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
サンノゼ、デーヴ区シスコシステムズ170w.タスマン博士カリフォルニア95134米国は以下に電話をします。 +1-408-526-4000 メールしてください: dward@cisco.com
Papadimitriou, et al. Informational [Page 21] RFC 4652 Evaluation of Routing Protocols against ASON October 2006
Papadimitriou、他 ASON2006年10月に対するルーティング・プロトコルの情報[21ページ]のRFC4652評価
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントは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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Papadimitriou, et al. Informational [Page 22]
Papadimitriou、他 情報[22ページ]
一覧
スポンサーリンク
