RFC4726 日本語訳
4726 A Framework for Inter-Domain Multiprotocol Label SwitchingTraffic Engineering. A. Farrel, J.-P. Vasseur, A. Ayyangar. November 2006. (Format: TXT=53076 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Farrel
Request for Comments: 4726 Old Dog Consulting
Category: Informational J.-P. Vasseur
Cisco Systems, Inc.
A. Ayyangar
Nuova Systems
November 2006
コメントを求めるワーキンググループA.ファレル要求をネットワークでつないでください: 4726年の古い犬のコンサルティングカテゴリ: 情報のJ.-P。 VasseurシスコシステムズInc.A.Ayyangarヌオーヴァシステム2006年11月
A Framework for Inter-Domain Multiprotocol Label Switching
Traffic Engineering
相互ドメインMultiprotocolラベル切り換え交通工学のための枠組み
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 IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
Abstract
要約
This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks.
このドキュメントはマルチドメインネットワークでMultiprotocol Label Switching(MPLS)とGeneralized MPLS(GMPLS)交通Engineered(TE)ラベルSwitched Paths(LSPs)を設立して、制御するのに枠組みを提供します。
For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes).
このドキュメントの目的のために、ドメインはアドレス管理か経路のコンピュータの責任の一般的な球の中のネットワーク要素のどんな収集であるとも考えられます。 そのようなドメインに関する例はInteriorゲートウェイプロトコル(IGP)部門とAutonomous Systems(ASes)を含んでいます。
Farrel, et al. Informational [Page 1] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[1ページ]のRFC4726枠組み
Table of Contents
目次
1. Introduction ....................................................3
1.1. Nested Domains .............................................3
2. Signaling Options ...............................................4
2.1. LSP Nesting ................................................4
2.2. Contiguous LSP .............................................5
2.3. LSP Stitching ..............................................5
2.4. Hybrid Methods .............................................6
2.5. Control of Downstream Choice of Signaling Method ...........6
3. Path Computation Techniques .....................................6
3.1. Management Configuration ...................................7
3.2. Head-End Computation .......................................7
3.2.1. Multi-Domain Visibility Computation .................7
3.2.2. Partial Visibility Computation ......................7
3.2.3. Local Domain Visibility Computation .................8
3.3. Domain Boundary Computation ................................8
3.4. Path Computation Element ...................................9
3.4.1. Multi-Domain Visibility Computation ................10
3.4.2. Path Computation Use of PCE When Preserving
Confidentiality ....................................10
3.4.3. Per-Domain Computation Elements ....................10
3.5. Optimal Path Computation ..................................11
4. Distributing Reachability and TE Information ...................11
5. Comments on Advanced Functions .................................12
5.1. LSP Re-Optimization .......................................12
5.2. LSP Setup Failure .........................................13
5.3. LSP Repair ................................................14
5.4. Fast Reroute ..............................................14
5.5. Comments on Path Diversity ................................15
5.6. Domain-Specific Constraints ...............................16
5.7. Policy Control ............................................17
5.8. Inter-Domain Operations and Management (OAM) ..............17
5.9. Point-to-Multipoint .......................................17
5.10. Applicability to Non-Packet Technologies .................17
6. Security Considerations ........................................18
7. Acknowledgements ...............................................19
8. Normative References ...........................................19
9. Informative References .........................................20
1. 序論…3 1.1. ドメインを入れ子にします…3 2. シグナリングオプション…4 2.1. LSP巣篭もり…4 2.2. 隣接のLSP…5 2.3. LSPステッチ…5 2.4. ハイブリッド方法…6 2.5. 方法に合図することの川下の選択のコントロール…6 3. 経路計算のテクニック…6 3.1. 管理構成…7 3.2. ギヤエンドの計算…7 3.2.1. マルチドメイン目に見えること計算…7 3.2.2. 部分的な目に見えること計算…7 3.2.3. 局所領域目に見えること計算…8 3.3. ドメイン境界計算…8 3.4. 経路計算要素…9 3.4.1. マルチドメイン目に見えること計算…10 3.4.2. 秘密性を保存するときのPCEの経路計算使用…10 3.4.3. 1ドメインあたりのComputation Elements…10 3.5. 最適経路計算…11 4. 可到達性とTe情報を分配します…11 5. 拡張機能のコメント…12 5.1. LSP再最適化…12 5.2. LSPは失敗をセットアップします…13 5.3. LSPは修理します…14 5.4. 速くコースを変更してください…14 5.5. 経路の多様性のコメント…15 5.6. ドメイン特有の規制…16 5.7. 方針コントロール…17 5.8. 相互ドメイン操作と管理(OAM)…17 5.9. ポイントツーマルチポイント…17 5.10. 非パケット技術への適用性…17 6. セキュリティ問題…18 7. 承認…19 8. 標準の参照…19 9. 有益な参照…20
Farrel, et al. Informational [Page 2] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[2ページ]のRFC4726枠組み
1. Introduction
1. 序論
The Traffic Engineering Working Group has developed requirements for inter-area and inter-AS Multiprotocol Label Switching (MPLS) Traffic Engineering in [RFC4105] and [RFC4216].
Traffic Engineering作業部会は[RFC4105]と[RFC4216]で相互領域と相互AS Multiprotocol Label Switching(MPLS)交通Engineeringのための要件を開発しました。
Various proposals have subsequently been made to address some or all of these requirements through extensions to the Resource Reservation Protocol Traffic Engineering extensions (RSVP-TE) and to the Interior Gateway Protocols (IGPs) (i.e., Intermediate System to Intermediate System (IS-IS) and OSPF).
次にResource予約プロトコルTraffic Engineering拡張子(RSVP-TE)と、そして、Interiorゲートウェイプロトコル(IGPs)への拡大でこれらの要件のいくつかかすべてを記述するのを様々な提案をした、(すなわち、Intermediate SystemへのIntermediate System、(-、)、OSPF)
This document introduces the techniques for establishing Traffic Engineered (TE) Label Switched Paths (LSPs) across multiple domains. In this context and within the remainder of this document, we consider all source-based and constraint-based routed LSPs and refer to them interchangeably as "TE LSPs" or "LSPs".
このドキュメントは複数のドメインの向こう側にTraffic Engineered(TE)ラベルSwitched Paths(LSPs)を設立するためのテクニックを導入します。 このような関係においてはとこのドキュメントの残りの中では、私たちは、すべてのソースベースの、そして、規制ベースの発送されたLSPsを考えて、「Te LSPs」か「LSPs」と彼らを互換性を持って呼びます。
The functional components of these techniques are separated into the mechanisms for discovering reachability and TE information, for computing the paths of LSPs, and for signaling the LSPs. Note that the aim of this document is not to detail each of those techniques, which are covered in separate documents referenced from the sections of this document that introduce the techniques, but rather to propose a framework for inter-domain MPLS Traffic Engineering.
これらのテクニックの機能部品は可到達性とTE情報を発見するためにメカニズムに切り離されます、LSPsの経路を計算して、LSPsに合図するために。 このドキュメントの目的がテクニックを導入するこのドキュメントのセクションから参照をつけられる別々のドキュメントでカバーされているそれぞれのそれらのテクニックを詳しく述べるのではなく、相互ドメインMPLS Traffic Engineeringのためにむしろ枠組みを提案することであることに注意してください。
Note that in the remainder of this document, the term "MPLS Traffic
Engineering" is used equally to apply to MPLS and Generalized MPLS
(GMPLS) traffic. Specific issues pertaining to the use of GMPLS in
inter-domain environments (for example, policy implications of the
use of the Link Management Protocol [RFC4204] on inter-domain links)
are covered in separate documents such as [GMPLS-AS].
このドキュメントの残りに、「MPLS交通工学」という用語がMPLSとGeneralized MPLS(GMPLS)交通に適用するのに等しく使用されることに注意してください。 相互ドメイン環境(例えば、相互ドメインリンクにおけるLink Managementプロトコル[RFC4204]の使用の政策的含意)におけるGMPLSの使用に関係する特定の問題が[GMPLS-AS]などの別々のドキュメントでカバーされています。
For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. Wholly or partially overlapping domains (e.g., path computation sub-domains of areas or ASes) are not within the scope of this document.
このドキュメントの目的のために、ドメインはアドレス管理か経路のコンピュータの責任の一般的な球の中のネットワーク要素のどんな収集であるとも考えられます。 そのようなドメインに関する例はIGP領域とAutonomous Systemsを含んでいます。このドキュメントの範囲の中に完全か部分的に重なっているドメイン(例えば、領域かASesに関する経路計算サブドメイン)がありません。
1.1. Nested Domains
1.1. 入れ子にされたドメイン
Nested domains are outside the scope of this document. It may be that some domains that are nested administratively or for the purposes of address space management can be considered as adjacent domains for the purposes of this document; however, the fact that the domains are nested is then immaterial. In the context of MPLS TE, domain A is considered to be nested within domain B if domain A is
このドキュメントの範囲の外に入れ子にされたドメインがあります。 多分、このドキュメントの目的のための隣接しているドメインであると行政上かアドレス空間管理の目的のために入れ子にされるいくつかのドメインをみなすことができます。 しかしながら、ドメインが入れ子にされるという事実はその時、重要でないです。 MPLS TEの文脈では、ドメインAがあるなら、ドメインBの中でドメインAが入れ子にされると考えられます。
Farrel, et al. Informational [Page 3] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[3ページ]のRFC4726枠組み
wholly contained in domain B, and domain B is fully or partially aware of the TE characteristics and topology of domain A.
ドメインに完全に保管されていて、B、およびドメインBは完全にそうです。ドメインAのTEの特性とトポロジーを部分的に知っています。
2. Signaling Options
2. シグナリングオプション
Three distinct options for signaling TE LSPs across multiple domains are identified. The choice of which options to use may be influenced by the path computation technique used (see section 3), although some path computation techniques may apply to multiple signaling options. The choice may further depend on the application to which the TE LSPs are put and the nature, topology, and switching capabilities of the network.
複数のドメインの向こう側にTE LSPsに合図するための3つの異なったオプションが特定されます。 テクニックが使用した経路計算で選択はどのオプションを使用するかを影響を及ぼされるかもしれません(セクション3を見てください)、いくつかの経路計算のテクニックが複数のシグナリングオプションに適用されるかもしれませんが。 この選択はさらにTE LSPsが置かれるアプリケーション、自然、トポロジー、およびネットワークのスイッチング能力次第であるかもしれません。
A comparison of the usages of the different signaling options is beyond the scope of this document and should be the subject of a separate applicability statement.
異なったシグナリングオプションの用法の比較は、このドキュメントの範囲を超えていて、別々の適用性証明の対象であるべきです。
2.1. LSP Nesting
2.1. LSP巣篭もり
Hierarchical LSPs form a fundamental part of MPLS [RFC3031] and are discussed in further detail in [RFC4206]. Hierarchical LSPs may optionally be advertised as TE links. Note that a hierarchical LSP that spans multiple domains cannot be advertised in this way because there is no concept of TE information that spans domains.
階層的なLSPsについてMPLS[RFC3031]の基本的な部分を形成して、[RFC4206]の詳細で議論します。 TEがリンクするとき、任意に階層的なLSPsの広告を出すかもしれません。 ドメインにかかるTE情報の概念が全くないので複数のドメインにかかる階層的なLSPがこのように広告を出すことができないことに注意してください。
Hierarchical LSPs can be used in support of inter-domain TE LSPs. In particular, a hierarchical LSP may be used to achieve connectivity between any pair of Label Switching Routers (LSRs) within a domain. The ingress and egress of the hierarchical LSP could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain.
相互ドメインTE LSPsを支持して階層的なLSPsを使用できます。 特に、階層的なLSPは、ドメインの中のどんな組のLabel Switching Routers(LSRs)の間の接続性を達成するのに使用されるかもしれません。 階層的なLSPのイングレスと出口はケースの接続性が全体のドメインの向こう側に達成されるドメインの縁のノードであるかもしれませんかそれらがそのドメインのLSRsのいかなる他の組であるかもしれません。
The technique of carrying one TE LSP within another is termed LSP nesting. A hierarchical LSP may provide a TE LSP tunnel to transport (i.e., nest) multiple TE LSPs along a common part of their paths. Alternatively, a TE LSP may carry (i.e., nest) a single LSP in a one-to-one mapping.
別のものの中で1TE LSPを運ぶテクニックはLSP巣篭もりと呼ばれます。 階層的なLSPは、彼らの経路の一般的な地域に沿った複数の(すなわち、巣)TE LSPsを輸送するためにTE LSPトンネルを提供するかもしれません。 あるいはまた、TE LSPは1〜1つのマッピングで独身のLSPを運ぶかもしれません(すなわち、巣)。
The signaling trigger for the establishment of a hierarchical LSP may be the receipt of a signaling request for the TE LSP that it will carry, or may be a management action to "pre-engineer" a domain to be crossed by TE LSPs that would be used as hierarchical LSPs by the traffic that has to traverse the domain. Furthermore, the mapping (inheritance rules) between attributes of the nested and the hierarchical LSPs (including bandwidth) may be statically pre- configured or, for on-demand hierarchical LSPs, may be dynamic
階層的なLSPの設立のためのシグナリング引き金はTE LSPを求めるそれが運ぶか、または階層的なLSPsとしてドメインを横断しなければならない交通で使用されるTE LSPsによって交差されるようにドメインを「プレ設計する」ためには管理活動であるかもしれないというシグナリング要求の領収書であるかもしれません。 その上、入れ子にすることの属性と階層的なLSPs(帯域幅を含んでいる)の間のマッピング(遺産規則)は、静的にあらかじめ構成されるかもしれないか、または要求次第の階層的なLSPsに、ダイナミックであるかもしれません。
Farrel, et al. Informational [Page 4] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[4ページ]のRFC4726枠組み
according to the properties of the nested LSPs. Even in the dynamic case, inheritance from the properties of the nested LSP(s) can be complemented by local or domain-wide policy rules.
入れ子にされたLSPsの特性に従って。 ダイナミックな場合ではさえ、入れ子にされたLSP(s)の特性からの遺産は地方の、または、ドメイン全体の政策ルールで補足となることができます。
Note that a hierarchical LSP may be constructed to span multiple domains or parts of domains. However, such an LSP cannot be advertised as a TE link that spans domains. The end points of a hierarchical LSP are not necessarily on domain boundaries, so nesting is not limited to domain boundaries.
階層的なLSPが複数のドメインかドメインの地域にかかるために組み立てられるかもしれないことに注意してください。 しかしながら、そのようなLSPはドメインにかかるTEリンクとして広告を出すことができません。 階層的なLSPのエンドポイントが必ずドメイン境界にあるというわけではないので、巣篭もりはドメイン境界に制限されません。
Note also that the Interior/Exterior Gateway Protocol (IGP/EGP) routing topology is maintained unaffected by the LSP connectivity and TE links introduced by hierarchical LSPs even if they are advertised as TE links. That is, the routing protocols do not exchange messages over the hierarchical LSPs, and LSPs are not used to create routing adjacencies between routers.
また、Interior/外のゲートウェイプロトコル(IGP/EGP)ルーティングトポロジーがTEがリンクするとき彼らが広告に掲載されても階層的なLSPsによって紹介されたLSPの接続性とTEリンクによって影響を受けなく維持されることに注意してください。 すなわち、ルーティング・プロトコルは階層的なLSPsの上とメッセージを交換しません、そして、LSPsは、ルータの間でルーティング隣接番組を作成するのに使用されません。
During the operation of establishing a nested LSP that uses a hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain unchanged along the entire length of the nested LSP, as do all other objects that have end-to-end significance.
階層的なLSPを使用する入れ子にされたLSPを設立する操作の間、SENDER_TEMPLATEとSESSION物は入れ子にされたLSPの全長に沿って変わりがありません、終わりから終わりへの意味を持っている他のすべての物のように。
2.2. Contiguous LSP
2.2. 隣接のLSP
A single contiguous LSP is established from ingress to egress in a single signaling exchange. No further LSPs are required to be established to support this LSP so that hierarchical or stitched LSPs are not needed.
独身の隣接のLSPはイングレスから出口までただ一つのシグナリング交換に設立されます。 このLSPを支持するために一層のLSPsが全く設立される必要はないので、階層的であるかステッチされたLSPsは必要ではありません。
A contiguous LSP uses the same Session/LSP ID along the whole of its path (that is, at each LSR). The notions of "splicing" together different LSPs or of "shuffling" Session or LSP identifiers are not considered.
隣接のLSPは経路(すなわち、各LSRの)の全体に沿って同じSession/LSP IDを使用します。 一緒に「継ぐこと」の異なったLSPsかSessionかLSP識別子の「シャッフル」であるという概念は考えられません。
2.3. LSP Stitching
2.3. LSPステッチ
LSP Stitching is described in [STITCH]. In the LSP stitching model, separate LSPs (referred to as a TE LSP segments) are established and are "stitched" together in the data plane so that a single end-to-end Label Switched Path is achieved. The distinction is that the component LSP segments are signaled as distinct TE LSPs in the control plane. Each signaled TE LSP segment has a different source and destination.
LSP Stitchingは[STITCH]で説明されます。 LSPのステッチしているモデルでは、別々のLSPs(TE LSPセグメントと呼ばれる)が設立されて、データ飛行機で一緒に「ステッチされる」ので、ただ一つの終わりから終わりへのLabel Switched Pathは達成されます。 区別はコンポーネントLSPセグメントが異なったTE LSPsとして制御飛行機で合図されるということです。 それぞれの合図されたTE LSPセグメントには、異なったソースと目的地があります。
LSP stitching can be used in support of inter-domain TE LSPs. In particular, an LSP segment may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the LSP segment could be the edge nodes of the domain in which case
相互ドメインTE LSPsを支持してLSPステッチを使用できます。 特に、LSPセグメントは、ドメインの中のどんな組のLSRsの間の接続性を達成するのに使用されるかもしれません。 LSPセグメントのイングレスと出口はその場合ドメインの縁のノードであるかもしれません。
Farrel, et al. Informational [Page 5] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[5ページ]のRFC4726枠組み
connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain.
接続性は全体のドメインの向こう側に達成されるか、それらがそのドメインのLSRsのいかなる他の組であるかもしれません。
The signaling trigger for the establishment of a TE LSP segment may be the establishment of the previous TE LSP segment, the receipt of a setup request for TE LSP that it plans to stitch to a local TE LSP segment, or a management action.
TE LSPセグメントの設立のためのシグナリング引き金は、前のTE LSPセグメントの設立、TE LSPを求める地方のTE LSPセグメントにステッチするのを計画しているというセットアップ要求の領収書、または管理活動であるかもしれません。
LSP segments may be managed and advertised as TE links.
TEがリンクするとき、LSPセグメントを管理して、広告を出すかもしれません。
2.4. Hybrid Methods
2.4. ハイブリッド法
There is nothing to prevent the mixture of signaling methods described above when establishing a single, end-to-end, inter-domain TE LSP. It may be desirable in this case for the choice of the various methods to be reported along the path, perhaps through the Record Route Object (RRO).
相互ドメインTE LSP、シングル、終わらせる終わりを確立するとき、何も上で説明されたシグナリング方法の混合物を防ぐものがありません。 経路に沿って報告されるべき様々な方法の選択に、それはこの場合望ましいかもしれません、恐らくRecord Route Object(RRO)を通して。
If there is a desire to restrict which methods are used, this must be signaled as described in the next section.
制限するそれの方法が使用されている願望があれば、次のセクションで説明されるようにこれに合図しなければなりません。
2.5. Control of Downstream Choice of Signaling Method
2.5. 方法に合図することの川下の選択のコントロール
Notwithstanding the previous section, an ingress LSR may wish to restrict the signaling methods applied to a particular LSP at domain boundaries across the network. Such control, where it is required, may be achieved by the definition of appropriate new flags in the SESSION-ATTRIBUTE object or the Attributes Flags TLV of the LSP_ATTRIBUTES object [RFC4420]. Before defining a mechanism to provide this level of control, the functional requirement to control the way in which the network delivers a service must be established. Also, due consideration must be given to the impact on interoperability since new mechanisms must be backwards compatible, and care must be taken to avoid allowing standards-conformant implementations that each supports a different functional subset in such a way that they are not capable of establishing LSPs.
前項にもかかわらず、LSRがシグナリング方法を制限したがっているかもしれないイングレスはネットワークの向こう側のドメイン境界の特定のLSPに適用されました。 そのようなコントロールはSESSION-ATTRIBUTE物との適切な新しい旗の定義かLSP_ATTRIBUTES物[RFC4420]のAttributes Flags TLVによってそれが必要であるところに実現されるかもしれません。 この管理水準を提供するためにメカニズムを定義する前に、ネットワークがサーブする方法を制御するという機能条件書を確立しなければなりません。 また、新しいメカニズムがコンパチブル、と注意の遅れているカビであるに違いないので、当然の考慮を相互運用性への影響に対して払わなければなりません。取って、それぞれそれらができないLSPsを設立するそのような方法で異なった機能的な部分集合をサポートする規格-conformant実現を許すのを避けてください。
3. Path Computation Techniques
3. 経路計算のテクニック
The discussion of path computation techniques within this document is limited significantly to the determination of where computation may take place and what components of the full path may be determined.
計算がどこで行われるかもしれないか、そして、フルパスのどんなコンポーネントが決定しているかもしれないかに関する決断はこのドキュメントの中の経路計算のテクニックの議論にかなり制限されます。
The techniques used are closely tied to the signaling methodologies described in the previous section in that certain computation techniques may require the use of particular signaling approaches and vice versa.
使用されるテクニックは密接に、ある計算のテクニックが逆もまた同様に特定のシグナリングアプローチの使用を必要とするかもしれないので前項で説明されたシグナリング方法論に結ばれます。
Farrel, et al. Informational [Page 6] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[6ページ]のRFC4726枠組み
Any discussion of the appropriateness of a particular path computation technique in any given circumstance is beyond the scope of this document and should be described in a separate applicability statement.
どんな与えられた状況でも、特定の経路計算のテクニックの適切さのどんな議論も、このドキュメントの範囲を超えていて、別々の適用性証明で説明されるべきです。
Path computation algorithms are firmly out of the scope of this document.
しっかりこのドキュメントの範囲の外に経路計算アルゴリズムがあります。
3.1. Management Configuration
3.1. 管理構成
Path computation may be performed by offline tools or by a network planner. The resultant path may be supplied to the ingress LSR as part of the TE LSP or service request, and encoded by the ingress LSR as an Explicit Route Object (ERO) on the Path message that is sent out.
経路計算はオフラインツールかネットワーク立案者によって実行されるかもしれません。 結果の経路は、TE LSPかサービスのリクエストの一部としてイングレスLSRに供給されて、Explicit Route Object(ERO)として出されるPathメッセージでイングレスLSRによってコード化されるかもしれません。
There is no reason why the path provided by the operator should not span multiple domains if the relevant information is available to the planner or the offline tool. The definition of what information is needed to perform this operation and how that information is gathered, is outside the scope of this document.
関連情報が立案者かオフラインツールに利用可能であるならオペレータによって提供された経路が複数のドメインにかかるべきでない理由が全くありません。 どんな情報がこの操作を実行するのに必要であるか、そして、その情報がどのように推測されるかに関する定義はこのドキュメントの範囲の外のそうです。
3.2. Head-End Computation
3.2. ギヤエンドの計算
The head-end, or ingress, LSR may assume responsibility for path computation when the operator supplies part or none of the explicit path. The operator must, in any case, supply at least the destination address (egress) of the LSP.
オペレータが部分か明白な経路のいずれも供給しないとき、ギヤエンド、またはイングレス、LSRが経路計算への責任を負うかもしれません。 どのような場合でも、オペレータは少なくともLSPの送付先アドレス(出口)を供給しなければなりません。
3.2.1. Multi-Domain Visibility Computation
3.2.1. マルチドメイン目に見えること計算
If the ingress has sufficient visibility of the topology and TE information for all of the domains across which it will route the LSP to its destination, then it may compute and provide the entire path. The quality of this path (that is, its optimality as discussed in section 3.5) can be better if the ingress has full visibility into all relevant domains rather than just sufficient visibility to provide some path to the destination.
イングレスにそれがLSPを目的地に発送するドメインのすべてのためのトポロジーとTE情報の十分な目に見えることがあるなら、それは、全体の経路を計算して、提供するかもしれません。 イングレスがまさしく何らかの経路を目的地に提供できるくらいの目に見えることよりむしろすべての関連ドメインに完全な目に見えることを持っているなら、この経路(すなわち、最適セクション3.5で議論する)の品質は、より良い場合があります。
Extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4.
必要なTE情報の分配を考慮して極端な警告を運動させなければなりません。 セクション4を見てください。
3.2.2. Partial Visibility Computation
3.2.2. 部分的な目に見えること計算
It may be that the ingress does not have full visibility of the topology of all domains, but does have information about the connectedness of the domains and the TE resource availability across the domains. In this case, the ingress is not able to provide a
イングレスは、多分、すべてのドメインのトポロジーの完全な目に見えることを持っていませんが、ドメインの向こう側にドメインの連結性とTEリソースの有用性の情報を持っています。 この場合、イングレスはaを提供できません。
Farrel, et al. Informational [Page 7] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[7ページ]のRFC4726枠組み
fully specified strict explicit path from ingress to egress. However, for example, the ingress might supply an explicit path that comprises:
完全に指定された厳しい明白なイングレスから出口までの経路。 しかしながら、例えば、イングレスは以下を包括する明白な経路を供給するかもしれません。
- explicit hops from ingress to the local domain boundary
- loose hops representing the domain entry points across the
network
- a loose hop identifying the egress.
- 明白なイングレスから局所領域境界までのホップ--ネットワークの向こう側にドメインエントリー・ポイントを表すホップを発射してください--出口を特定するゆるいホップ。
Alternatively, the explicit path might be expressed as:
あるいはまた、明白な経路は以下として言い表されるかもしれません。
- explicit hops from ingress to the local domain boundary
- strict hops giving abstract nodes representing each domain in
turn
- a loose hop identifying the egress.
- 明白なイングレスから局所領域境界までのホップ--順番に各ドメインを表す抽象的なノードを与える厳しいホップ--出口を特定するゆるいホップ。
These two explicit path formats could be mixed according to the information available resulting in different combinations of loose hops and abstract nodes.
利用可能な情報によると、これらの2つの明白な経路形式が、ゆるいホップと抽象的なノードの異なった組み合わせをもたらしながら、複雑であることができました。
This form of explicit path relies on some further computation technique being applied at the domain boundaries. See section 3.3.
このフォームの明白な経路はドメイン境界で適用されるさらなる何らかの計算のテクニックを当てにします。 セクション3.3を見てください。
As with the multi-domain visibility option, extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4.
マルチドメイン目に見えることオプションなら、必要なTE情報の分配を考慮して極端な警告を運動させなければなりません。 セクション4を見てください。
3.2.3. Local Domain Visibility Computation
3.2.3. 局所領域目に見えること計算
A final possibility for ingress-based computation is that the ingress LSR has visibility only within its own domain, and connectivity information only as far as determining one or more domain exit points that may be suitable for carrying the LSP to its egress.
イングレスベースの計算のための最終的な可能性はイングレスLSRが1つ以上の出口までLSPを運ぶのに適当であるかもしれないドメインエキジットポイントを決定するのと同じくらい遠くにだけそれ自身のドメイン、および接続性情報だけの中に目に見えることを持っているということです。
In this case, the ingress builds an explicit path that comprises just:
この場合イングレスがそれが包括する明白な経路を造る、まさしく:
- explicit hops from ingress to the local domain boundary
- a loose hop identifying the egress.
- 明白なイングレスから局所領域境界までのホップ--出口を特定するゆるいホップ。
3.3. Domain Boundary Computation
3.3. ドメイン境界計算
If the partial explicit path methods described in sections 3.2.2 or 3.2.3 are applied, then the LSR at each domain boundary is responsible for ensuring that there is sufficient path information added to the Path message to carry it at least to the next domain boundary (that is, out of the new domain).
セクション3.2.2か3.2で説明されて、.3が部分的な明白な経路方法であるなら適用されている、その時、少なくとも次のドメイン境界(すなわち、新しいドメインからの)までそれを運ぶPathメッセージに追加された十分な経路情報があるのを確実にするのに各ドメイン境界のLSRは責任があります。
Farrel, et al. Informational [Page 8] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[8ページ]のRFC4726枠組み
If the LSR at the domain boundary has full visibility to the egress then it can supply the entire explicit path. Note, however, that the ERO processing rules of [RFC3209] state that it should only update the ERO as far as the next specified hop (that is, the next domain boundary if one was supplied in the original ERO) and, of course, must not insert ERO subobjects immediately before a strict hop.
ドメイン境界のLSRが完全な目に見えることを出口に持っているなら、それは全体の明白な経路を供給できます。 しかしながら、[RFC3209]のERO処理規則が次の指定されたホップ(1であるならオリジナルのEROですなわち、次のドメイン境界を供給した)と同じくらい遠くにEROをアップデートするだけであるべきであり、厳しいホップの直前もちろんERO subobjectsを挿入してはいけないと述べることに注意してください。
If the LSR at the domain boundary has only partial visibility (using the definitions of section 3.2.2), it will fill in the path as far as the next domain boundary, and will supply further domain/domain boundary information if not already present in the ERO.
ドメイン境界のLSRに部分的な目に見えることしかないと(セクション3.2.2の定義を使用して)、それは、次のドメイン境界と同じくらい遠くに経路に記入して、EROでさらなるドメイン/ドメイン境界情報か既にプレゼントを提供するでしょう。
If the LSR at the domain boundary has only local visibility into the immediate domain, it will simply add information to the ERO to carry the Path message as far as the next domain boundary.
ドメイン境界のLSRが即座のドメインに地方の目に見えることしか持っていないと、それは、次のドメイン境界と同じくらい遠くにPathメッセージを伝えるために単にEROに情報を加えるでしょう。
Domain boundary path computations are performed independently from each other. Domain boundary LSRs may have different computation capabilities, run different path computation algorithms, apply different sets of constraints and optimization criteria, and so forth, which might result in path segment quality that is unpredictable to and out of the control of the ingress LSR. A solution to this issue lies in enhancing the information signaled during LSP setup to include a larger set of constraints and to include the paths of related LSPs (such as diverse protected LSPs) as described in [GMPLS-E2E].
ドメイン境界経路計算は互いから独自に実行されます。 ドメイン境界LSRsには、異なった計算能力があるかもしれなくて、異なった経路計算アルゴリズムを走らせてください、そして、コントロールとイングレスLSRのコントロールから予測できない経路セグメント品質をもたらすかもしれない異なった規制、最適化評価基準などを適用してください。 [2GMPLS EのE]で説明されるようにLSPセットアップの間に、より大きい規制を含んで、関連するLSPs(さまざまの保護されたLSPsなどの)の経路を含めるように合図された情報を高めるのにおいてこの問題の解決があります。
It is also the case that paths generated on domain boundaries may produce loops. Specifically, the paths computed may loop back into a domain that has already been crossed by the LSP. This may or may not be a problem, and might even be desirable, but could also give rise to real loops. This can be avoided by using the recorded route (RRO) to provide exclusions within the path computation algorithm, but in the case of lack of trust between domains it may be necessary for the RRO to indicate the previously visited domains. Even this solution is not available where the RRO is not available on a Path message. Note that when an RRO is used to provide exclusions, and a loop-free path is found to be not available by the computation at a downstream border node, crankback [CRANKBACK] may enable an upstream border node to select an alternate path.
また、ドメイン境界で発生する経路が輪を生産するかもしれないのは、事実です。 明確に、計算された経路はLSPによって既に交差されたドメインに輪にして戻られるかもしれません。 これは、問題であるかもしれなく、望ましくさえあるかもしれませんが、また、実際の輪をもたらすかもしれません。 経路計算アルゴリズムの中で除外を提供するのに、記録されたルート(RRO)を使用することによって、これを避けることができますが、ドメインの間の信用の不足の場合では、RROが以前に訪問されたドメインを示すのが必要であるかもしれません。 この解決策さえRROがPathメッセージで入手できないところで利用可能ではありません。 RROが除外を提供するのに使用されて、無輪の経路が川下の境界ノードで計算で利用可能でないことがわかっているとき、crankback[CRANKBACK]が、上流の境界ノードが代替パスを選択するのを可能にするかもしれないことに注意してください。
3.4. Path Computation Element
3.4. 経路計算要素
The computation techniques in sections 3.2 and 3.3 rely on topology and TE information being distributed to the ingress LSR and those LSRs at domain boundaries. These LSRs are responsible for computing paths. Note that there may be scaling concerns with distributing the required information; see section 4.
セクション3.2と3.3の計算のテクニックはドメイン境界でイングレスLSRとそれらのLSRsに分配されるトポロジーとTE情報を当てにします。 これらのLSRsは経路を計算するのに責任があります。 必須情報を分配するのに関心をスケーリングするのがあるかもしれないことに注意してください。 セクション4を見てください。
Farrel, et al. Informational [Page 9] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[9ページ]のRFC4726枠組み
An alternative technique places the responsibility for path computation with a Path Computation Element (PCE) [RFC4655]. There may be either a centralized PCE, or multiple PCEs (each having local visibility and collaborating in a distributed fashion to compute an end-to-end path) across the entire network and even within any one domain. The PCE may collect topology and TE information from the same sources as would be used by LSRs in the previous paragraph, or though other means.
代替のテクニックはPath Computation Element(PCE)[RFC4655]に経路計算への責任を置きます。 全体のネットワークの向こう側にどんなドメインの中にさえも集結されたPCEか複数のPCEsのどちらかがあるかもしれません(終わりから端への経路を計算するためにそれぞれ地方の目に見えることを持って、分配されたファッションで共同します)。 前のパラグラフのLSRsによって使用されるだろうか、または他の手段ですが、PCEは同じソースからトポロジーとTE情報を集めるかもしれません。
Each LSR called upon to perform path computation (and even the offline management tools described in section 3.1) may abdicate the task to a PCE of its choice. The selection of PCE(s) may be driven by static configuration or the dynamic discovery.
経路計算(そして、セクション3.1で説明されたオフライン管理ツールさえ)を実行するのが要求された各LSRは選択のPCEにタスクについて放棄するかもしれません。 PCE(s)の選択は静的な構成かダイナミックな発見で追い立てられるかもしれません。
3.4.1. Multi-Domain Visibility Computation
3.4.1. マルチドメイン目に見えること計算
A PCE may have full visibility, perhaps through connectivity to multiple domains. In this case, it is able to supply a full explicit path as in section 3.2.1.
PCEは恐らく接続性を通して複数のドメインに完全な目に見えることを持っているかもしれません。 この場合、それはセクション3.2.1のように完全な明白な経路を供給できます。
3.4.2. Path Computation Use of PCE When Preserving Confidentiality
3.4.2. 秘密性を保存するときのPCEの経路計算使用
Note that although a centralized PCE or multiple collaborative PCEs may have full visibility into one or more domains, it may be desirable (e.g., to preserve topology confidentiality) that the full path not be provided to the ingress LSR. Instead, a partial path is supplied (as in section 3.2.2 or 3.2.3), and the LSRs at each domain boundary are required to make further requests for each successive segment of the path.
集結されたPCEか複数の協力的なPCEsが1つ以上のドメインに完全な目に見えることを持っているかもしれませんが、フルパスがイングレスLSRに提供されないのが、望ましいかもしれないことに(例えばトポロジー秘密性を保存する)注意してください。 代わりに、部分的な経路を供給します。(セクション3.2のように、.3、)および各ドメイン境界のLSRsが作っていなければならない.2か3.2が経路のそれぞれの連続したセグメントを求める要求を促進します。
In this way, an end-to-end path may be computed using the full network capabilities, but confidentiality between domains may be preserved. Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests, or it may recompute each leg of the path on each request or at regular intervals until requested by the LSRs establishing the LSP.
このように、終わりから端への経路は完全なネットワーク能力を使用することで計算されますが、ドメインの間の秘密性は保存されるかもしれません。 任意に、PCE(s)が最初の要求によって全体の経路を計算して、その後の要求のための格納にそれを保持するかもしれませんか、またはそれはそれぞれが急いで歩く各要求か一定のLSPを設立するLSRsによって要求されるまでの間隔で、経路のrecomputeを保持するかもしれません。
It may be the case that the centralized PCE or the collaboration between PCEs may define a trust relationship greater than that normally operational between domains.
集結されたPCEかPCEsの間の共同がそんなに通常、ドメインの間で操作上であるよりすばらしい信用関係を定義するかもしれないのは、事実であるかもしれません。
3.4.3. Per-Domain Computation Elements
3.4.3. 1ドメインあたりのComputation Elements
A third way that PCEs may be used is simply to have one (or more) per domain. Each LSR within a domain that wishes to derive a path across the domain may consult its local PCE.
PCEsが使用されるかもしれない3番目の方法はドメイン単位で1つを単に持つ(さらに)ことです。 ドメインの中のドメインの向こう側に経路を引き出したがっている各LSRは地方のPCEに相談するかもしれません。
Farrel, et al. Informational [Page 10] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[10ページ]のRFC4726枠組み
This mechanism could be used for all path computations within the domain, or specifically limited to computations for LSPs that will leave the domain where external connectivity information can then be restricted to just the PCE.
このメカニズムをドメインの中のすべての経路計算に使用したか、または次に外部の接続性情報がまさしくPCEに制限される場合があるドメインを出るLSPsのために明確に計算に制限できました。
3.5. Optimal Path Computation
3.5. 最適経路計算
There are many definitions of an optimal path depending on the constraints applied to the path computation. In a multi-domain environment, the definitions are multiplied so that an optimal route might be defined as the route that would be computed in the absence of domain boundaries. Alternatively, another constraint might be applied to the path computation to reduce or limit the number of domains crossed by the LSP.
経路計算に適用された規制による最適経路の多くの定義があります。 マルチドメイン環境で、定義は、ドメイン境界がないとき計算されるルートと最適のルートを定義できるように掛けられます。 あるいはまた、別の規制は、LSPによって交差されたドメインの数を減少するか、または制限するために経路計算に適用されるかもしれません。
It is easy to construct examples that show that partitioning a network into domains, and the resulting loss or aggregation of routing information may lead to the computation of routes that are other than optimal. It is impossible to guarantee optimal routing in the presence of aggregation / abstraction / summarization of routing information.
ネットワークをドメインに仕切るそれを示している例を構成するのが簡単であり、ルーティング情報の結果として起こる損失か集合が最適であるのを除いて、あるルートの計算につながるかもしれません。 ルーティング情報の集合/抽象化/総括があるとき最適ルーティングを保証するのは不可能です。
It is beyond the scope of this document to define what is an optimum path for an inter-domain TE LSP. This debate is abdicated in favor of requirements documents and applicability statements for specific deployment scenarios. Note, however, that the meaning of certain computation metrics may differ between domains (see section 5.6).
それは、相互ドメインTE LSPのために最適な経路であることを定義するためにこのドキュメントの範囲を超えています。 要件ドキュメントと適用性証明を支持して特定の展開シナリオのためにこの討論について放棄します。 しかしながら、ある計算測定基準の意味がドメインの間で異なるかもしれないことに注意してください(セクション5.6を見てください)。
4. Distributing Reachability and TE Information
4. 可到達性とTe情報を分配します。
Traffic Engineering information is collected into a TE Database (TED) on which path computation algorithms operate either directly or by first constructing a network graph.
交通Engineering情報は経路計算アルゴリズムがネットワークグラフを作図しながら直接か最初にで作動するTE Database(TED)に集められます。
The path computation techniques described in the previous section make certain demands upon the distribution of reachability information and the TE capabilities of nodes and links within domains as well as the TE connectivity across domains.
前項で説明された経路計算のテクニックはドメイン中のTEの接続性と同様にドメインの中で可到達性情報の分配とノードとリンクのTE能力で要求を確実にします。
Currently, TE information is distributed within domains by additions to IGPs [RFC3630], [RFC3784].
[RFC3784]、現在、TE情報はドメインの中でIGPs[RFC3630]への追加で分配されます。
In cases where two domains are interconnected by one or more links (that is, the domain boundary falls on a link rather than on a node), there should be a mechanism to distribute the TE information associated with the inter-domain links to the corresponding domains. This would facilitate better path computation and reduce TE-related crankbacks on these links.
2つのドメインが1個以上のリンクによってインタコネクトされる(すなわち、ドメイン境界はノードの上でというよりむしろリンクに落下します)場合には、対応するドメインへの相互ドメインリンクに関連しているTE情報を分配するメカニズムがあるはずです。 これは、これらのリンクで、より良い経路計算を容易にして、TE関連のcrankbacksを減少させるでしょう。
Farrel, et al. Informational [Page 11] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[11ページ]のRFC4726枠組み
Where a domain is a subset of an IGP area, filtering of TE information may be applied at the domain boundary. This filtering may be one way or two way.
ドメインがIGP領域の部分集合であるところでは、TE情報のフィルタリングはドメイン境界で適用されるかもしれません。 このフィルタリングは、1つの方法かツーウェイであるかもしれません。
Where information needs to reach a PCE that spans multiple domains, the PCE may snoop on the IGP traffic in each domain, or play an active part as an IGP-capable node in each domain. The PCE might also receive TED updates from a proxy within the domain.
情報が、複数のドメインにかかるPCEに達する必要があるところでは、PCEは各ドメインのIGP交通のときに詮索するか、またはIGPできるノードとして各ドメインでアクティブな役割を果たすかもしれません。 また、PCEはドメインの中のプロキシからTEDアップデートを受けるかもしれません。
It is possible that an LSR that performs path computation (for example, an ingress LSR) obtains the topology and TE information of not just its own domain, but other domains as well. This information may be subject to filtering applied by the advertising domain (for example, the information may be limited to Forwarding Adjacencies (FAs) across other domains, or the information may be aggregated or abstracted).
経路計算(例えば、イングレスLSR)を実行するLSRがそれ自身のドメインだけではなく、また、他のドメインのトポロジーとTE情報を得るのは、可能です。 この情報は広告ドメインによって適用されたフィルタリングを受けることがあるかもしれません(例えば、情報が他のドメインの向こう側にForwarding Adjacencies(FAs)に制限されるかもしれないか、または情報は、集められるか、抜き取られるかもしれません)。
Before starting work on any protocols or protocol extensions to enable cross-domain reachability and TE advertisement in support of inter-domain TE, the requirements and benefits must be clearly established. This has not been done to date. Where any cross-domain reachability and TE information needs to be advertised, consideration must be given to TE extensions to existing protocols such as BGP, and how the information advertised may be fed to the IGPs. It must be noted that any extensions that cause a significant increase in the amount of processing (such as aggregation computation) at domain boundaries, or a significant increase in the amount of information flooded (such as detailed TE information) need to be treated with extreme caution and compared carefully with the scaling requirements expressed in [RFC4105] and [RFC4216].
どんなプロトコルやプロトコル拡大のときにも相互ドメインTEを支持して交差しているドメインの可到達性とTE広告を可能にするために就業する前に、明確に要件と利益を確立しなければなりません。 これまでこれをしていません。 どんな交差しているドメインの可到達性とTE情報も、広告を出す必要があるところでは、BGPや、どう広告に掲載された情報をIGPsに入れなどであるかもしれないかなどの既存のプロトコルへのTE拡張子に対して考慮を払わなければなりません。 それがドメイン境界で処理(集合計算などの)の量のかなりの増加を引き起こしたか、または情報量のかなりの増加が(詳細なTE情報などの)必要性をあふれさせたどんな拡大も細心の注意を払って扱われて、慎重に[RFC4105]と[RFC4216]で言い表されたスケーリング要件と比べられることに注意しなければなりません。
5. Comments on Advanced Functions
5. 拡張機能のコメント
This section provides some non-definitive comments on the constraints placed on advanced MPLS TE functions by inter-domain MPLS. It does not attempt to state the implications of using one inter-domain technique or another. Such material is deferred to appropriate applicability statements where statements about the capabilities of existing or future signaling, routing, and computation techniques to deliver the functions listed should be made.
このセクションは相互ドメインMPLSによって高度なMPLS TE機能に置かれた規制のいくつかの非決定的なコメントを提供します。 それは、何らかの相互ドメインのテクニックを使用する含意を述べるのを試みません。 そのような材料は、存在か将来のシグナリングと、ルーティングと、計算のテクニックが記載された機能を送る能力に関する声明が出されるべきである適用性証明を当てるために延期されます。
5.1. LSP Re-Optimization
5.1. LSP再最適化
Re-optimization is the process of moving a TE LSP from one path to another, more preferable path (where no attempt is made in this document to define "preferable" as no attempt was made to define "optimal"). Make-before-break techniques are usually applied to ensure that traffic is disrupted as little as possible. The Shared
再最適化は1つの経路から別のものへTE LSPを移す過程です、より望ましい経路(試みが全くどんな試みも「望ましくはありません」が、「最適」が定義させられて、定義するこのドキュメントでされないところ)。 通常、以前開閉しているテクニックは、交通ができるだけ少ししか中断しないのを保証するために適用されます。 共有
Farrel, et al. Informational [Page 12] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[12ページ]のRFC4726枠組み
Explicit style is usually used to avoid double booking of network resources.
通常、明白なスタイルは、ネットワーク資源のダブルブッキングを避けるのに使用されます。
Re-optimization may be available within a single domain. Alternatively, re-optimization may involve a change in route across several domains or might involve a choice of different transit domains.
再最適化は単一領域の中で利用可能であるかもしれません。 あるいはまた、再最適化は、いくつかのドメインの向こう側にルートの変化にかかわるか、または異なったトランジットドメインの選択にかかわるかもしれません。
Re-optimization requires that all or part of the path of the LSP be re-computed. The techniques used may be selected as described in section 3, and this will influence whether the whole or part of the path is re-optimized.
再最適化は、LSPの経路のすべてか一部が再計算されるのを必要とします。 使用されるテクニックはセクションで説明されて、3、およびこれがそうするように選択されて、影響が経路の全体か地域であることにかかわらず再最適化されているということであるかもしれません。
The trigger for path computation and re-optimization may be an operator request, a timer, information about a change in availability of network resources, or a change in operational parameters (for example, bandwidth) of an LSP. This trigger must be applied to the point in the network that requests re-computation and controls re- optimization and may require additional signaling.
経路計算と再最適化のための引き金は、オペレータ要求、タイマ、ネットワーク資源の有用性における変化の情報、またはLSPの操作上のパラメタ(例えば、帯域幅)において変化であるかもしれません。 この引き金は、再計算とコントロール再最適化を要求するネットワークでポイントに適用しなければならなくて、追加シグナリングを必要とするかもしれません。
Note also that where multiple mutually-diverse paths are applied end-to-end (i.e., not simply within protection domains; see section 5.5) the point of calculation for re-optimization (whether it is PCE, ingress, or domain entry point) needs to know all such paths before attempting re-optimization of any one path. Mutual diversity here means that a set of computed paths has no commonality. Such diversity might be link, node, Shared Risk Link Group (SRLG), or even domain disjointedness according to circumstances and the service being delivered.
また、再最適化(それがPCE、イングレス、またはドメインエントリー・ポイントであることにかかわらず)のための計算のポイントが、複数の互いに多様な経路が適用された終わりから終わり(すなわち、単にどんな保護ドメインの中でもそうしません; セクション5.5を見る)であるところでどんな経路の再最適化も試みる前にそのようなすべての経路を知る必要に注意してください。 ここの互いの多様性は、1セットの計算された経路には共通点が全くないことを意味します。 そのような多様性は、場合によってリンク、ノード、Shared Risk Link Group(SRLG)、またはドメインばらばらでさえあるかもしれなく、サービスは渡すことです。
It may be the case that re-optimization is best achieved by recomputing the paths of multiple LSPs at once. Indeed, this can be shown to be most efficient when the paths of all LSPs are known, not simply those LSPs that originate at a particular ingress. While this problem is inherited from single domain re-optimization and is out of scope within this document, it should be noted that the problem grows in complexity when LSPs wholly within one domain affect the re- optimization path calculations performed in another domain.
すぐに複数のLSPsの経路を再計算することによって再最適化を達成するのが最も良いのは、事実であるかもしれません。 本当に、すべてのLSPsの経路が単に特定のイングレスで由来するそれらのLSPsではなく知られているとき、最も効率的になるようにこれを示すことができます。 この問題が単一領域再最適化から引き継がれて、このドキュメントの中に範囲の外にある間、完全に1つのドメインの中のLSPsが別のドメインで実行された再最適化経路計算に影響すると問題が複雑さに生えていることに注意されるべきです。
5.2. LSP Setup Failure
5.2. LSPセットアップの故障
When an inter-domain LSP setup fails in some domain other than the first, various options are available for reporting and retrying the LSP.
相互ドメインLSPセットアップが1番目を除いた何らかのドメインに失敗するとき、様々なオプションはLSPを報告して、再試行するのに利用可能です。
Farrel, et al. Informational [Page 13] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[13ページ]のRFC4726枠組み
In the first instance, a retry may be attempted within the domain that contains the failure. That retry may be attempted by nodes wholly within the domain, or the failure may be referred back to the LSR at the domain boundary.
まず、再試行は失敗を含むドメインの中で試みられるかもしれません。 その再試行がドメインの中でノードによって完全に試みられるかもしれませんか、または失敗はドメイン境界のLSRへ差し戻されるかもしれません。
If the failure cannot be bypassed within the domain where the failure occurred (perhaps there is no suitable alternate route, perhaps rerouting is not allowed by domain policy, or perhaps the Path message specifically bans such action), the error must be reported back to the previous or head-end domain.
失敗が失敗が起こった(どんな適当な代替経路も恐らくないか、恐らく、コースを変更することがドメイン方針で許されていないか、または恐らく、Pathメッセージは明確にそのような動作を禁止します)ドメインの中で迂回できないなら、前であるかギヤエンドのドメインに誤りの報告を持ちかえらなければなりません。
Subsequent repair attempts may be made by domains further upstream, but will only be properly effective if sufficient information about the failure and other failed repair attempts is also passed back upstream [CRANKBACK]. Note that there is a tension between this requirement and that of topology confidentiality although crankback aggregation may be applicable at domain boundaries.
その後の修理試みは、ドメインによってさらに上流へ作られるかもしれませんが、また、失敗と他の失敗した修理試みに関する十分な情報が上流へ戻される場合にだけ[CRANKBACK]、適切に有効になるでしょう。 crankback集合がドメイン境界で適切であるかもしれませんが、トポロジー秘密性の様々な要件の間には、緊張があることに注意してください。
Further attempts to signal the failed LSP may apply the information about the failures as constraints to path computation, or may signal them as specific path exclusions [EXCLUDE].
失敗したLSPに合図するさらなる試みは、規制として失敗の情報を経路計算に適用するか、または特定の経路除外[EXCLUDE]としてそれらを示すかもしれません。
When requested by signaling, the failure may also be systematically reported to the head-end LSR.
また、シグナリングによって要求されると、失敗は系統的にギヤエンドLSRに報告されるかもしれません。
5.3. LSP Repair
5.3. LSP修理
An LSP that fails after it has been established may be repaired dynamically by re-routing. The behavior in this case is either like that for re-optimization, or for handling setup failures (see previous two sections). Fast Reroute may also be used (see below).
それが設立された後に失敗するLSPは、コースを変更することによって、ダイナミックに修理されるかもしれません。 この場合、振舞いが再最適化のためのそれ、または取り扱いセットアップ失敗によってあります(前の2つのセクションを見てください)。 また、速く、Rerouteは使用されるかもしれません(以下を見てください)。
5.4. Fast Reroute
5.4. 速くコースを変更してください。
MPLS Traffic Engineering Fast Reroute ([RFC4090]) defines local protection schemes intended to provide fast recovery (in 10s of msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node failure. A backup TE LSP is configured and signaled at each hop, and activated upon detecting or being informed of a network element failure. The node immediately upstream of the failure (called the PLR, or Point of Local Repair) reroutes the set of protected TE LSPs onto the appropriate backup tunnel(s) and around the failed resource.
MPLS Traffic Engineering Fast Reroute([RFC4090])はリンク/SRLG/ノード障害での速い「別ルートで送-可能」のパケットベースのTE LSPsの速い回復(msecのコネ10年代)を供給することを意図する地方の保護計画を定義します。 バックアップTE LSPは各ホップで構成されて、合図されて、ネットワーク要素の故障について検出するか、または知識があるとき動きます。 ノード、すぐに、失敗(PLR、またはLocal RepairのPointと呼ばれる)の上流は適切なバックアップトンネルと、そして、失敗したリソースの周りで保護されたTE LSPsのセットを別ルートで送ります。
In the context of inter-domain TE, there are several different failure scenarios that must be analyzed. Provision of suitable solutions may be further complicated by the fact that [RFC4090] specifies two distinct modes of operation referred to as the "one to one mode" and the "facility back-up mode".
相互ドメインTEの文脈には、分析しなければならないいくつかの異なった失敗シナリオがあります。 [RFC4090]が「1〜1つのモード」と「施設バックアップモード」と呼ばれた2つの異なった運転モードを指定するという事実によって適当な解決策に関する条項はさらに複雑にされるかもしれません。
Farrel, et al. Informational [Page 14] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[14ページ]のRFC4726枠組み
The failure scenarios specific to inter-domain TE are as follows:
相互ドメインTEに特定の失敗シナリオは以下の通りです:
- Failure of a domain edge node that is present in both domains.
There are two sub-cases:
- 両方のドメインに存在しているドメイン縁のノードの失敗。 2つのサブケースがあります:
- The Point of Local Repair (PLR) and the Merge Point (MP) are in
the same domain.
- Local RepairのPoint(PLR)とMerge Point(MP)が同じドメインにあります。
- The PLR and the MP are in different domains.
- PLRとMPは異なったドメインにいます。
- Failure of a domain edge node that is only present in one of the
domains.
- ドメインの1つだけに存在しているドメイン縁のノードの失敗。
- Failure of an inter-domain link.
- 相互ドメインリンクの失敗。
Although it may be possible to apply the same techniques for Fast Reroute (FRR) to the different methods of signaling inter-domain LSPs described in section 2, the results of protection may be different when it is the boundary nodes that need to be protected, and when they are the ingress and egress of a hierarchical LSP or stitched LSP segment. In particular, the choice of PLR and MP may be different, and the length of the protection path may be greater. These uses of FRR techniques should be explained further in applicability statements or, in the case of a change in base behavior, in implementation guidelines specific to the signaling techniques.
Fast Reroute(FRR)のためにセクション2で説明された相互ドメインLSPsに合図する異なった方法に同じテクニックを適用するのが可能であるかもしれませんが、それらが階層的なLSPかステッチされたLSPセグメントのそれが保護される必要がある境界ノードであり、イングレスと出口であるときに、保護の結果は異なっているかもしれません。 PLRとMPの選択は特に、異なるかもしれません、そして、保護経路の長さは、より大きいかもしれません。 FRRのテクニックのこれらの用途は適用性証明かベースの振舞いにおける変化に関するケースの中でシグナリングのテクニックに特定の実施要綱で、より詳しく説明されるべきです。
Note that after local repair has been performed, it may be desirable to re-optimize the LSP (see section 5.1). If the point of re- optimization (for example, the ingress LSR) lies in a different domain to the failure, it may rely on the delivery of a PathErr or Notify message to inform it of the local repair event.
局部的修繕が実行された後にLSPを再最適化するのが望ましいかもしれないことに注意してください(セクション5.1を見てください)。 失敗に再最適化(例えば、イングレスLSR)のポイントが異なったドメインにあるなら、それはPathErrか局部的修繕出来事についてそれを知らせるNotifyメッセージの配送に依存するかもしれません。
It is important to note that Fast Reroute techniques are only applicable to packet switching networks because other network technologies cannot apply label stacking within the same switching type. Segment protection [GMPLS-SEG] provides a suitable alternative that is applicable to packet and non-packet networks.
他のネットワーク技術が同じ切り換えタイプの中のラベルの積み重ねを当てはまることができないのでFast Rerouteのテクニックが単にパケット交換網に適切であることに注意するのは重要です。 セグメント保護[GMPLS-SEG]はパケットに適切な適当な代替手段と非パケット網を提供します。
5.5. Comments on Path Diversity
5.5. 経路の多様性のコメント
Diverse paths may be required in support of load sharing and/or protection. Such diverse paths may be required to be node diverse, link diverse, fully path diverse (that is, link and node diverse), or SRLG diverse.
さまざまの経路が負荷分割法、そして/または、保護を支持して必要であるかもしれません。 そのようなさまざまの経路が、ノードさまざまであるか、リンクさまざまであるか、完全に経路多様(それはそうです、リンクとノードさまざまである)か、またはSRLGさまざまになるのに必要であるかもしれません。
Diverse path computation is a classic problem familiar to all graph theory majors. The problem is compounded when there are areas of "private knowledge" such as when domains do not share topology
さまざまの経路計算はすべてのグラフ理論専攻に身近な古典的な問題です。 ドメインがトポロジーを共有しない時などの「個人的な知識」の領域があるとき、問題は悪化します。
Farrel, et al. Informational [Page 15] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[15ページ]のRFC4726枠組み
information. The problem can be resolved more efficiently (e.g., avoiding the "trap problem") when mutually resource disjoint paths can be computed "simultaneously" on the fullest set of information.
情報。 問題はリソースが互いにばらばらになるとき、より効率的(例えば、「罠問題」を避ける)に決議されて、「同時」最もふくよかな情報で経路を計算できるということであるかもしれません。
That being said, various techniques (out of the scope of this document) exist to ensure end-to-end path diversity across multiple domains.
それが言われていて、様々なテクニック(このドキュメントの範囲からの)は、複数のドメインの向こう側に終わりから終わりへの経路多様性を確実にするために存在しています。
Many network technologies utilize "protection domains" because they fit well with the capabilities of the technology. As a result, many domains are operated as protection domains. In this model, protection paths converge at domain boundaries.
技術の能力をよく与えるので、多くのネットワーク技術が「保護ドメイン」を利用します。 その結果、多くのドメインが保護ドメインとして操作されます。 このモデルでは、保護経路はドメイン境界で一点に集まります。
Note that the question of SRLG identification is not yet fully answered. There are two classes of SRLG:
SRLG識別の問題がまだ完全に答えられるというわけではないことに注意してください。 SRLGの2つのクラスがあります:
- those that indicate resources that are all contained within one
domain
- 1つのドメインの中にすべて保管されているリソースを示すもの
- those that span domains.
- ドメインにかかるもの。
The former might be identified using a combination of a globally scoped domain ID, and an SRLG ID that is administered by the domain. The latter requires a global scope to the SRLG ID. Both schemes, therefore, require external administration. The former is able to leverage existing domain ID administration (for example, area and AS numbers), but the latter would require a new administrative policy.
前者は、グローバルに見られたドメインIDの組み合わせ、およびドメインによって管理されるSRLG IDを使用することで特定されるかもしれません。 後者はグローバルな範囲をSRLG IDに必要とします。 したがって、両方の計画は外部の管理を必要とします。 前者は既存のドメインID管理(例えば、領域とAS番号)に投機できますが、後者は新しい施政方針を必要とするでしょう。
5.6. Domain-Specific Constraints
5.6. ドメイン特有の規制
While the meaning of certain constraints, like bandwidth, can be assumed to be constant across different domains, other TE constraints (such as resource affinity, color, metric, priority, etc.) may have different meanings in different domains and this may impact the ability to support Diffserv-aware MPLS, or to manage preemption.
帯域幅のようにある規制の意味が異なったドメインの向こう側に一定であると思うことができる間、他のTE規制(色の、そして、メートル法のリソースの親近感、優先権などの)は異なったドメインに異なった意味を持っているかもしれません、そして、これはDiffserv意識しているMPLSを支持するか、または先取りを管理する能力に影響を与えるかもしれません。
In order to achieve consistent meaning and LSP establishment, this fact must be considered when performing constraint-based path computation or when signaling across domain boundaries.
ドメイン境界の向こう側に合図しながら規制ベースの経路計算かいつを実行するかとき、一貫した意味とLSP設立を達成するために、この事実を考えなければなりません。
A mapping function can be derived for most constraints based on policy agreements between the domain administrators. The details of such a mapping function are outside the scope of this document, but it is important to note that the default behavior must either be that a constant mapping is applied or that any requirement to apply these constraints across a domain boundary must fail in the absence of explicit mapping rules.
ドメイン管理者の間の政策協定に基づくほとんどの規制のためにマッピング機能を引き出すことができます。 このドキュメントの範囲の外にそのようなマッピング機能の詳細がありますが、デフォルトの振舞いが一定のマッピングが適用されていなければならないか、またはドメイン境界の向こう側にこれらの規制を適用するというどんな要件も明白な配置規則がないとき失敗しなければならないということであるに違いないことに注意するのは重要です。
Farrel, et al. Informational [Page 16] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[16ページ]のRFC4726枠組み
5.7. Policy Control
5.7. 方針コントロール
Domain boundaries are natural points for policy control. There is little to add on this subject except to note that a TE LSP that cannot be established on a path through one domain because of a policy applied at the domain boundary may be satisfactorily established using a path that avoids the demurring domain. In any case, when a TE LSP signaling attempt is rejected due to non- compliance with some policy constraint, this should be reflected to the ingress LSR.
ドメイン境界は方針コントロールのための自然なポイントです。 ドメイン境界で適用された方針のために1つのドメインを通して経路に設立できないTE LSPが異議ドメインを避ける経路を使用することで満足に設立されるかもしれないことに注意する以外に、この対象を加えるために、少ししかありません。 どのような場合でも、TE LSPシグナリング試みが何らかの方針規制への非コンプライアンスのため拒絶されるとき、これはイングレスLSRに反映されるべきです。
5.8. Inter-Domain Operations and Management (OAM)
5.8. 相互ドメイン操作と管理(OAM)
Some elements of OAM may be intentionally confined within a domain. Others (such as end-to-end liveness and connectivity testing) clearly need to span the entire multi-domain TE LSP. Where issues of topology confidentiality are strong, collaboration between PCEs or domain boundary nodes might be required in order to provide end-to- end OAM, and a significant issue to be resolved is to ensure that the end-points support the various OAM capabilities.
OAMのいくつかの要素が故意にドメインの中に閉じ込められるかもしれません。 他のもの(終わりから終わりへの活性や接続性テストなどの)は、明確に全体のマルチドメインTE LSPにかかる必要があります。 トポロジー秘密性の問題が強いところでは、PCEsの間の共同かドメイン境界ノードが終わりから終わりへのOAMを提供するのに必要であるかもしれません、そして、決議されるべき重要な問題はエンドポイントが様々なOAM能力を支持するのを保証することです。
The different signaling mechanisms described above may need refinements to [RFC4379], [BFD-MPLS], etc., to gain full end-to-end visibility. These protocols should, however, be considered in the light of topology confidentiality requirements.
上で説明された異なったシグナル伝達機構は[RFC4379]への気品、利得終わりから終わりへの完全な目に見えることへの[BFD-MPLS]などを必要とするかもしれません。 しかしながら、これらのプロトコルはトポロジー機密保持の要求事項の見地から考えられるべきです。
Route recording is a commonly used feature of signaling that provides OAM information about the path of an established LSP. When an LSP traverses a domain boundary, the border node may remove or aggregate some of the recorded information for topology confidentiality or other policy reasons.
ルート録音は確立したLSPの経路の情報をOAMに供給するシグナリングの一般的に使用された特徴です。 LSPがドメイン境界を横断するとき、境界ノードは、取り外すか、またはトポロジー秘密性か他の方針理由による記録情報のいくつかに集めるかもしれません。
5.9. Point-to-Multipoint
5.9. ポイントツーマルチポイント
Inter-domain point-to-multipoint (P2MP) requirements are explicitly out of the scope of this document. They may be covered by other documents dependent on the details of MPLS TE P2MP solutions.
相互ドメインポイントツーマルチポイント(P2MP)要件は明らかにそうです。このドキュメントの範囲から。 それらはMPLS TE P2MP解決策の詳細に依存する他のドキュメントで覆われているかもしれません。
5.10. Applicability to Non-Packet Technologies
5.10. 非パケット技術への適用性
Non-packet switching technologies may present particular issues for inter-domain LSPs. While packet switching networks may utilize control planes built on MPLS or GMPLS technology, non-packet networks are limited to GMPLS.
非パケット交換技術は相互ドメインLSPsのために特定の問題を提示するかもしれません。 パケット交換網がMPLSかGMPLS技術に造られた制御飛行機を利用しているかもしれない間、非パケット網はGMPLSに制限されます。
Farrel, et al. Informational [Page 17] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[17ページ]のRFC4726枠組み
On the other hand, some problems such as Fast Reroute on domain boundaries (see section 5.4) may be handled by the GMPLS technique of segment protection [GMPLS-SEG] that is applicable to both packet and non-packet switching technologies.
他方では、ドメイン境界(セクション5.4を見る)のFast Rerouteなどのいくつかの問題が両方のパケットと非パケット交換技術に適切なセグメント保護[GMPLS-SEG]のGMPLSのテクニックで扱われるかもしれません。
The specific architectural considerations and requirements for inter-domain LSP setup in non-packet networks are covered in a separate document [GMPLS-AS].
非パケット網における相互ドメインLSPセットアップのための特定の建築問題と要件は別々のドキュメント[GMPLS-AS]で含まれています。
6. Security Considerations
6. セキュリティ問題
Requirements for security within domains are unchanged from [RFC3209] and [RFC3473], and from [RFC3630] and [RFC3784]. That is, all security procedures for existing protocols in the MPLS context continue to apply for the intra-domain cases.
ドメインの中のセキュリティのための要件は[RFC3209]と[RFC3473]と、[RFC3630]と[RFC3784]から変わりがありません。 MPLS文脈の既存のプロトコルのためのすなわちすべてのセキュリティ手順が、イントラドメインケースに申し込み続けています。
Inter-domain security may be considered as a more important and more sensitive issue than intra-domain security since in inter-domain traffic engineering control and information may be passed across administrative boundaries. The most obvious and most sensitive case is inter-AS TE.
相互ドメイン交通工学では、コントロールと情報が管理境界の向こう側に通過されるかもしれないので、相互ドメインセキュリティはイントラドメインセキュリティよりさらに重要で敏感な問題であるとみなされるかもしれません。 最も明白で最も敏感なケースは相互AS TEです。
All of the intra-domain security measures for the signaling and routing protocols are equally applicable in the inter-domain case. There is, however, a greater likelihood of them being applied in the inter-domain case.
シグナリングとルーティング・プロトコルのためのイントラドメイン安全策のすべてが相互ドメイン場合で等しく適切です。 しかしながら、相互ドメイン場合で適用されるそれらのより大きな見込みがあります。
Security for inter-domain MPLS TE is the subject of a separate document that analyzes the security deployment models and risks. This separate document must be completed before inter-domain MPLS TE solution documents can be advanced.
相互ドメインMPLS TEのためのセキュリティはセキュリティ展開モデルと危険を分析する別々のドキュメントの対象です。 相互ドメインMPLS TE解決策ドキュメントを進めることができる前にこの別々のドキュメントを完成しなければなりません。
Similarly, the PCE procedures [RFC4655] are subject to security measures for the exchange computation information between PCEs and for LSRs that request path computations from a PCE. The requirements for this security (set out in [RFC4657]) apply whether the LSR and PCE (or the cooperating PCEs) are in the same domain or lie across domain boundaries.
同様に、PCEsの間の交換計算情報とPCEから経路計算を要求するLSRsにおいて、PCE手順[RFC4655]は安全策を受けることがあります。 このセキュリティ([RFC4657]では、始める)のための要件は、LSRとPCE(または、協力関係を持っているPCEs)が同じドメインにあるか否かに関係なく、適用するか、またはドメイン境界の向こう側にあります。
It should be noted, however, that techniques used for (for example) authentication require coordination of secrets, keys, or passwords between sender and receiver. Where sender and receiver lie within a single administrative domain, this process may be simple. But where sender and receiver lie in different administrative domains, cross- domain coordination between network administrators will be required in order to provide adequate security. At this stage, it is not proposed that this coordination be provided through an automatic process or through the use of a protocol. Human-to-human
しかしながら、(例えば、)認証に使用されるテクニックが送付者と受信機の間の秘密、キー、またはパスワードのコーディネートを必要とすると述べられるべきです。送付者と受信機がただ一つの管理ドメインに属すところでは、この過程は簡単であるかもしれません。 しかし、送付者と受信機が異なった管理ドメインにあるところでは、ネットワーク管理者の間の十字ドメインコーディネートが、十分な安全性を提供するのに必要でしょう。 現在のところ、このコーディネートが自動過程を通して、または、プロトコルの使用を通して提供されるよう提案されません。 人間から人間
Farrel, et al. Informational [Page 18] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[18ページ]のRFC4726枠組み
coordination is more likely to provide the required level of confidence in the inter-domain security.
コーディネートは必要なレベルの信用を相互ドメインセキュリティにより供給しそうです。
One new security concept is introduced by inter-domain MPLS TE. This is the preservation of confidentiality of topology information. That is, one domain may wish to keep secret the way that its network is constructed and the availability (or otherwise) of end-to-end network resources. This issue is discussed in sections 3.4.2, 5.2, and 5.8 of this document. When there is a requirement to preserve inter- domain topology confidentiality, policy filters must be applied at the domain boundaries to avoid distributing such information. This is the responsibility of the domain that distributes information, and it may be adequately addressed by aggregation of information as described in the referenced sections.
1つの新しいセキュリティ概念が相互ドメインMPLS TEによって紹介されます。 これはトポロジー情報の機密保持です。 すなわち、1つのドメインがネットワークが構成される方法と終わりからエンドへのネットワーク資源の有用性(そうでなければ)を秘密にしたがっているかもしれません。 セクション3.4 .2、5.2、およびこの5.8通のドキュメントでこの問題について議論します。 相互ドメイントポロジー秘密性を保存するという要件があるとき、そのような情報を分配するのを避けるためにドメイン境界で方針フィルタを適用しなければなりません。 これは情報を分配するドメインの責任です、そして、それは参照をつけられたセクションで説明されるように情報の集合によって適切に記述されるかもしれません。
Applicability statements for particular combinations of signaling, routing, and path computation techniques to provide inter-domain MPLS TE solutions are expected to contain detailed security sections.
シグナリング、ルーティング、および相互ドメインMPLS TE解決法を提供する経路計算のテクニックの特定の組み合わせのための適用性証明が詳細なセキュリティ部を含むと予想されます。
7. Acknowledgements
7. 承認
The authors would like to extend their warmest thanks to Kireeti Kompella for convincing them to expend effort on this document.
作者はこのドキュメントの上に努力するように彼らに納得させるためのKireeti Kompellaのおかげで彼らの最も暖かさを広げたがっています。
Grateful thanks to Dimitri Papadimitriou, Tomohiro Otani, and Igor Bryskin for their review and suggestions on the text.
テキストにおける彼らのレビューと提案のためのディミトリPapadimitriou、智宏・オータニ、およびイーゴリBryskinへの感謝している感謝。
Thanks to Jari Arkko, Gonzalo Camarillo, Brian Carpenter, Lisa Dusseault, Sam Hartman, Russ Housley, and Dan Romascanu for final review of the text.
テキストの最終審査をヤリArkko、ゴンサロ・キャマリロ、ブライアンCarpenter、リサDusseault、サム・ハートマン、ラスHousley、およびダンRomascanuをありがとうございます。
8. Normative References
8. 引用規格
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC3473] エドバーガー、L.、RFC3473、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は資源予約プロトコル交通工学(RSVP-Te)拡大を示す」1月2003日
Farrel, et al. Informational [Page 19] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[19ページ]のRFC4726枠組み
[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月)
9. Informative References
9. 有益な参照
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"BFD For MPLS LSPs", Work in Progress, June 2006.
[BFD-MPLS] Aggarwal、R.、Kompella、K.、ナドー、T.、およびG.ツバメ、「MPLS LSPsのためのBFD」は進歩、2006年6月に働いています。
[CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for
MPLS Signaling", Work in Progress, May 2005.
[CRANKBACK] ファレル、A.、他、「MPLSシグナリングのための拡大に合図するCrankback」、Progress、2005年5月のWork。
[EXCLUDE] Lee, CY., Farrel, A., and DeCnodder, "Exclude Routes -
Extension to RSVP-TE", Work in Progress, August 2005.
[除きます] リー、CY、8月2005、ファレル、A.、およびDeCnodder、「RSVP-Teまでルート--拡大を除いてください」が進行中で働いています。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
[RFC4090]のなべ、P.、ツバメ、G.、およびA.Atlas(「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ってください」、RFC4090)は2005がそうするかもしれません。
[GMPLS-AS] Otani, T., Kumaki, K., Okamoto, S., and W. Imajuku,
"GMPLS Inter-domain Traffic Engineering Requirements",
Work in Progress, August 2006.
[GMPLS、-、]、「GMPLS相互ドメイン交通工学要件」というImajukuが進歩、8月に2006に働かせるオータニ、T.、Kumaki、K.、岡本、S.、およびW.
[GMPLS-E2E] Lang, J.P., Rekhter, Y., and D. Papadimitriou, Editors,
"RSVP-TE Extensions in support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)-
based Recovery", Work in Progress, April 2005.
Progress(2005年4月)の[2GMPLS EのE]ラングとJ.P.とRekhter、Y.とD.Papadimitriou、エディターズ、「Endから終わりへのGeneralized Multi-プロトコルLabel Switching(GMPLS)--Recoveryを基礎づけることを支持したRSVP-TE Extensions」Work。
[GMPLS-SEG] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Farrel, "GMPLS Based Segment Recovery", Work in
Progress, May 2005.
[GMPLS-SEG] バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、「GMPLSのベースのセグメント回復」は進歩、2005年5月に働いています。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
[RFC4206]Kompella(K.とY.Rekhter)は「一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学(Te)で切り換えられた経路(LSP)を階層構造とラベルします」、RFC4206、2005年10月。
[RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle,
"Requirements for Inter-Area MPLS Traffic Engineering",
RFC 4105, June 2005.
[RFC4105]ル・ルー、J.-L.、Vasseur、J.-P.、およびJ.ボイル、「相互領域MPLS交通工学のための要件」、RFC4105、2005年6月。
[RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204,
October 2005.
[RFC4204] ラング、J.、「リンク管理プロトコル(LMP)」、RFC4204、2005年10月。
Farrel, et al. Informational [Page 20] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[20ページ]のRFC4726枠組み
[RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous
System (AS) Traffic Engineering (TE) Requirements", RFC
4216, November 2005.
[RFC4216] チャン、R.、およびJ.-P。 Vasseur、「MPLS相互自律システム(AS)交通工学(Te)要件」、RFC4216、2005年11月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4379] Kompella、K.、およびG.は2006年2月に「マルチプロトコルのラベルの切り換えられた(MPLS)データ飛行機の故障を検出すること」でのRFC4379を飲み込みます。
[RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J.-P., and A.
Ayyangar, "Encoding of Attributes for Multiprotocol
Label Switching (MPLS) Label Switched Path (LSP)
Establishment Using Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4420, February
2006.
[RFC4420] ファレル、A.、Papadimitriou、D.、Vasseur、J.-P.、およびA.Ayyangar、「(MPLS)がラベルするMultiprotocolラベルの切り換えのための属性のコード化は資源予約プロトコル交通工学(RSVP-Te)を使用することで経路(LSP)設立を切り換えました」、RFC4420、2006年2月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC
4655, August 2006.
[RFC4655] ファレル、A.、Vasseur、J.-P.、およびJ.灰、「経路の計算の要素の(PCE)ベースの構造」、RFC4655、2006年8月。
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
[RFC4657] 灰とJ.とJ.ル・ルー、「経路計算要素(PCE)通信プロトコルジェネリック要件」、RFC4657、2006年9月。
[STITCH] Ayyangar, A. and J.-P. Vasseur, "LSP Stitching with
Generalized MPLS TE", Work in Progress, September 2005.
[ステッチ] Ayyangar、A.、およびJ.-P。 「一般化されたMPLS TeでステッチするLSP」というVasseurは進歩、2005年9月に働いています。
Authors' Addresses
作者のアドレス
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンのファレルの古い犬のコンサルティングメール: adrian@olddog.co.uk
Jean-Philippe Vasseur Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: jpv@cisco.com
ジャンフィリップVasseurシスコシステムズ、Inc1414マサチューセッツ通りBoxborough、MA01719米国はメールされます: jpv@cisco.com
Arthi Ayyangar Nuova Systems EMail: arthi@nuovasystems.com
Arthi Ayyangarヌオーヴァシステムはメールされます: arthi@nuovasystems.com
Farrel, et al. Informational [Page 21] RFC 4726 Framework for Inter-Domain TE November 2006
ファレル、他 相互ドメインTe2006年11月のための情報[21ページ]のRFC4726枠組み
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(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, THE IETF TRUST, 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信用、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Farrel, et al. Informational [Page 22]
ファレル、他 情報[22ページ]
一覧
スポンサーリンク
