RFC4461 日本語訳
4461 Signaling Requirements for Point-to-Multipoint Traffic-EngineeredMPLS Label Switched Paths (LSPs). S. Yasukawa, Ed.. April 2006. (Format: TXT=64542 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Yasukawa, Ed. Request for Comments: 4461 NTT Category: Informational April 2006
ワーキンググループS.Yasukawa、エドをネットワークでつないでください。コメントのために以下を要求してください。 4461年のNTTカテゴリ: 情報の2006年4月
Signaling Requirements for Point-to-Multipoint
Traffic-Engineered MPLS Label Switched Paths (LSPs)
ポイントツーマルチポイントの交通で設計されたMPLSのための要件がラベルするシグナリングは経路を切り換えました。(LSPs)
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
要約
This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).
このドキュメントは設立のための1セットの要件とPointから多点(P2MP)への(TE)交通で設計されたMultiprotocol Label Switching(MPLS)ラベルSwitched Paths(LSPs)の維持を提示します。
There is no intent to specify solution-specific details or application-specific requirements in this document.
本書では解決策特有の詳細かアプリケーション決められた一定の要求を指定する意図が全くありません。
The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS.
本書では提示された要件はMPLSプロトコルのコントロールの下におけるパケット交換網に適用するだけではなく、Layer Two Switching(L2SC)(Generalized MPLS(GMPLS)プロトコルによって経営されたTime事業部Multiplexing(TDM)、λ、およびポートの切り換えネットワーク)の要件を取り囲みもします。 出された必要条件を満たすために見いだされたプロトコル解決策は、等しくMPLSとGMPLSに適切であることを本書では試みなければなりません。
Yasukawa Informational [Page 1] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[1ページ]のRFC4461
Table of Contents
目次
1. Introduction ....................................................3
1.1. Non-Objectives .............................................6
2. Definitions .....................................................6
2.1. Acronyms ...................................................6
2.2. Terminology ................................................6
2.2.1. Terminology for Partial LSPs ........................8
2.3. Conventions ................................................9
3. Problem Statement ...............................................9
3.1. Motivation .................................................9
3.2. Requirements Overview ......................................9
4. Detailed Requirements for P2MP TE Extensions ...................11
4.1. P2MP LSP ..................................................11
4.2. P2MP Explicit Routing .....................................12
4.3. Explicit Path Loose Hops and Widely Scoped
Abstract Nodes ............................................13
4.4. P2MP TE LSP Establishment, Teardown, and
Modification Mechanisms ...................................14
4.5. Fragmentation .............................................14
4.6. Failure Reporting and Error Recovery ......................15
4.7. Record Route of P2MP TE LSP ...............................16
4.8. Call Admission Control (CAC) and QoS Control
Mechanism of P2MP TE LSPs .................................17
4.9. Variation of LSP Parameters ...............................17
4.10. Re-Optimization of P2MP TE LSPs ..........................18
4.11. Merging of Tree Branches .................................18
4.12. Data Duplication .........................................19
4.13. IPv4/IPv6 Support ........................................20
4.14. P2MP MPLS Label ..........................................20
4.15. Advertisement of P2MP Capability .........................20
4.16. Multi-Access LANs ........................................21
4.17. P2MP MPLS OAM ............................................21
4.18. Scalability ..............................................21
4.18.1. Absolute Limits ..................................22
4.19. Backwards Compatibility ..................................24
4.20. GMPLS ....................................................24
4.21. P2MP Crankback Routing ...................................25
5. Security Considerations ........................................25
6. Acknowledgements ...............................................26
7. References .....................................................26
7.1. Normative References ......................................26
7.2. Informative References ....................................26
1. 序論…3 1.1. 非目的…6 2. 定義…6 2.1. 頭文字語…6 2.2. 用語…6 2.2.1. 部分的なLSPsのための用語…8 2.3. コンベンション…9 3. 問題声明…9 3.1. 動機…9 3.2. 要件概観…9 4. P2MP Te拡張子のための要件を詳しく述べます…11 4.1. P2MP LSP…11 4.2. P2MPの明白なルート設定…12 4.3. 明白な経路ゆるいホップと広く見られた要約ノード…13 4.4. P2MP Te LSP設立、分解、および変更メカニズム…14 4.5. 断片化…14 4.6. 失敗報告とエラー回復…15 4.7. P2MP Te LSPのルートを記録してください…16 4.8. P2MP Teの入場コントロール(CAC)とQoS制御機構をLSPsと呼んでください…17 4.9. LSPパラメタの変化…17 4.10. P2MP Te LSPsの再最適化…18 4.11. 木の合併は分岐します…18 4.12. データ複製…19 4.13. IPv4/IPv6サポート…20 4.14. P2MP MPLSラベル…20 4.15. P2MP能力の広告…20 4.16. マルチアクセスLAN…21 4.17. P2MP MPLS OAM…21 4.18. スケーラビリティ…21 4.18.1. 絶対限界…22 4.19. 遅れている互換性…24 4.20. GMPLS…24 4.21. P2MP Crankbackルート設定…25 5. セキュリティ問題…25 6. 承認…26 7. 参照…26 7.1. 標準の参照…26 7.2. 有益な参照…26
Yasukawa Informational [Page 2] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[2ページ]のRFC4461
1. Introduction
1. 序論
Existing MPLS traffic engineering (MPLS-TE) allows for strict QoS guarantees, resource optimization, and fast failure recovery, but it is limited to point-to-point (P2P) LSPs. There is a desire to support point-to-multipoint (P2MP) services using traffic-engineered LSPs, and this clearly motivates enhancements of the base MPLS-TE tool box in order to support P2MP MPLS-TE LSPs.
既存のMPLS交通工学(MPLS-TE)は厳しいQoS保証、リソース最適化、および速い失敗回復を考慮しますが、それはポイントツーポイント(P2P)LSPsに制限されます。 交通で設計されたLSPsを使用することでポイントツーマルチポイント(P2MP)サービスを支持する願望があります、そして、これはP2MP MPLS-TE LSPsを支持するために明確にベースMPLS-TE道具箱の増進を動機づけます。
A P2MP TE LSP is a TE LSP (per [RFC2702] and [RFC3031]) that has a single ingress LSR and one or more egress LSRs, and is unidirectional. P2MP services (that deliver data from a single source to one or more receivers) may be supported by any combination of P2P and P2MP LSPs depending on the degree of optimization required within the network, and such LSPs may be traffic-engineered again depending on the requirements of the network. Further, multipoint- to-multipoint (MP2MP) services (which deliver data from more than one source to one or more receivers) may be supported by a combination of P2P and P2MP LSPs.
P2MP TE LSPはただ一つのイングレスLSRと1を持っているTE LSP([RFC2702]と[RFC3031]あたりの)か、より多くの出口LSRsであり、単方向です。 P2MPサービス(それは単独のソースから1台以上の受信機までデータを送る)はP2Pのどんな組み合わせでも支持されるかもしれません、そして、最適化の度合いに依存するP2MP LSPsがネットワークの中で必要であり、再びネットワークの要件によって、そのようなLSPsは交通によって設計されているかもしれません。 さらに、多点に対する多点(MP2MP)サービス(1つ以上のソースから1台以上の受信機までデータを送る)はP2PとP2MP LSPsの組み合わせで支持されるかもしれません。
[RFC2702] specifies requirements for traffic engineering over MPLS. In Section 2, it describes traffic engineering in some detail, and those definitions are equally applicable to traffic engineering in a point-to-multipoint service environment. They are not repeated here, but it is assumed that the reader is fully familiar with them.
[RFC2702]はMPLSの上の交通工学のための要件を指定します。 セクション2では、何らかの詳細に交通工学について説明します、そして、それらの定義は等しくポイントツーマルチポイントサービス環境における交通工学に適切です。 それらはここで繰り返されませんが、読者がそれらに完全に詳しいと思われます。
Section 3.0 of [RFC2702] also explains how MPLS is particularly suited to traffic engineering; it presents the following eight reasons.
また、[RFC2702]のセクション3.0はMPLSがどう特に交通工学に合っているかを説明します。 それは以下の8つの理由を提示します。
1. Explicit label switched paths that are not constrained by the
destination-based forwarding paradigm can be easily created
through manual administrative action or through automated
action by the underlying protocols.
2. LSPs can potentially be maintained efficiently.
3. Traffic trunks can be instantiated and mapped onto LSPs.
4. A set of attributes can be associated with traffic trunks that
modulate their behavioral characteristics.
5. A set of attributes can be associated with resources that
constrain the placement of LSPs and traffic trunks across them.
6. MPLS allows for both traffic aggregation and disaggregation,
whereas classical destination-only-based IP forwarding permits
only aggregation.
7. It is relatively easy to integrate a "constraint-based routing"
framework with MPLS.
8. A good implementation of MPLS can offer significantly lower
overhead than competing alternatives for traffic engineering.
1. 明白なラベルは基本的なプロトコルで目的地ベースの推進で抑制されないで、手動の管理動きを通して、または、自動化された動作を通して容易にパラダイムを作成できるということである経路を切り換えました。 2. 潜在的に効率的にLSPsを維持できます。 3. 交通トランクスをLSPsに例示して、写像できます。 4. それらの行動の特性を調節する交通トランクスに1セットの属性を関連づけることができます。 5. それらの向こう側にLSPsと交通トランクスのプレースメントを抑制するリソースに1セットの属性を関連づけることができます。 6. 古典的ですが、MPLSが交通集合と非集計の両方を考慮する、目的地、ベースだけ、IP推進は集合だけを可能にします。 7. 「規制ベースのルーティング」枠組みをMPLSと統合するのは比較的簡単です。 8. MPLSの良い実現は交通工学のために競争している代替手段よりかなり低いオーバーヘッドを提供できます。
Yasukawa Informational [Page 3] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[3ページ]のRFC4461
These points are equally applicable to point-to-multipoint traffic engineering. Points 1 and 7 are particularly important. Note that point 3 implies that the concept of a point-to-multipoint traffic trunk is defined and is supported by (or mapped onto) P2MP LSPs.
これらのポイントは等しくポイントツーマルチポイント交通工学に適切です。 ポイント1と7は特に重要です。 または、ポイント3が、ポイントツーマルチポイント交通トランクの概念が定義されて、支持されるのを含意することに注意してください、(写像される、)、P2MP LSPs。
That is, the traffic flow for a point-to-multipoint LSP is not constrained to the path or paths that it would follow during multicast routing or shortest path destination-based routing, but it can be explicitly controlled through manual or automated action.
ポイントツーマルチポイントLSPのためのすなわち、交通の流れはそれがマルチキャストルーティングか最短パスの目的地ベースのルーティングの間に続く経路か経路に抑制されませんが、手動の、または、自動化された動きで明らかにそれを制御できます。
Further, the explicit paths that are used may be computed using algorithms based on a variety of constraints to produce all manner of tree shapes. For example, an explicit path may be cost-based [STEINER], shortest path, or QoS-based, or it may use some fair-cost QoS algorithm.
さらに、使用された明白な経路は、木の形のすべての方法を作成するというさまざまな規制に基づくアルゴリズムを使用することで計算されるかもしれません。 例えば、明白な経路が、費用ベースである[スタイナー]、最短パス、QoSベースであるかもしれません、またはそれは何らかの公正な費用QoSアルゴリズムを使用するかもしれません。
[RFC2702] also describes the functional capabilities required to fully support traffic engineering over MPLS in large networks.
また、[RFC2702]はMPLSの上で大きいネットワークで交通工学を完全にサポートするのに必要である機能的な能力について説明します。
This document presents a set of requirements for Point-to-Multipoint (P2MP) traffic engineering (TE) extensions to Multiprotocol Label Switching (MPLS). It specifies functional requirements for solutions to deliver P2MP TE LSPs.
このドキュメントはPointから多点(P2MP)への交通工学(TE)拡大のための1セットの要件をMultiprotocol Label Switching(MPLS)に提示します。 それは解決策がP2MP TE LSPsを届けるという機能条件書を指定します。
Solutions that specify procedures for P2MP TE LSP setup MUST satisfy these requirements. There is no intent to specify solution-specific details or application-specific requirements in this document.
P2MP TE LSPセットアップのための手順を指定するソリューションはこれらの要件を満たさなければなりません。 本書では解決策特有の詳細かアプリケーション決められた一定の要求を指定する意図が全くありません。
The requirements presented in this document apply equally to packet- switched networks under the control of MPLS protocols and to packet- switched, TDM, lambda, and port-switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document MUST attempt to be equally applicable to MPLS and GMPLS.
本書では提示された要件は等しくMPLSプロトコルのコントロールの下におけるパケット交換網と、そして、Generalized MPLS(GMPLS)プロトコルによって経営された切り換えられたパケットと、TDMと、λと、ポートを切り換えるネットワークに適用されます。 出された必要条件を満たすために見いだされたプロトコル解決策は、等しくMPLSとGMPLSに適切であることを本書では試みなければなりません。
Existing MPLS TE mechanisms such as [RFC3209] do not support P2MP TE LSPs, so new mechanisms need to be developed. This SHOULD be achieved with maximum re-use of existing MPLS protocols.
[RFC3209]などの既存のMPLS TEメカニズムがP2MP TE LSPsを支持しないので、新しいメカニズムは、開発される必要があります。 このSHOULD、既存のMPLSプロトコルの最大の再使用で、達成されてください。
Note that there is a separation between routing and signaling in MPLS TE. In particular, the path of the MPLS TE LSP is determined by performing a constraint-based computation (such as CSPF) on a traffic engineering database (TED). The contents of the TED may be collected through a variety of mechanisms.
MPLS TEのルーティングとシグナリングの間には、分離があることに注意してください。 MPLS TE LSPの経路は特に、規制ベースの計算を実行することによって交通工学で決定している(CSPFなどの)データベース(TED)です。 TEDのコンテンツはさまざまなメカニズムを通して集められるかもしれません。
Yasukawa Informational [Page 4] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[4ページ]のRFC4461
This document focuses on requirements for establishing and maintaining P2MP MPLS TE LSPs through signaling protocols; routing protocols are out of scope. No assumptions are made about how the TED used as the basis for path computations for P2MP LSPs is formed.
このドキュメントはシグナリングプロトコルを通してP2MP MPLS TE LSPsを設立して、維持するための要件に焦点を合わせます。 範囲の外にルーティング・プロトコルがあります。 P2MP LSPsに経路計算の基礎として使用されるTEDがどう形成されるかに関して仮定は全くされません。
This requirements document assumes the following conditions for P2MP MPLS TE LSP establishment and maintenance:
この要件ドキュメントはP2MP MPLS TE LSP設立とメンテナンスのための以下の条件を仮定します:
o A P2MP TE LSP will be set up with TE constraints and will allow
efficient packet or data replication at various branching points in
the network. Although replication is a data plane issue, it is the
responsibility of the control plane (acting in conjunction with the
path computation component) to install LSPs in the network such
that replication can be performed efficiently. Note that the
notion of "efficient" replication is relative and may have
different meanings depending on the objectives (see Section 4.2).
o P2MP TE LSPはTE規制でセットアップされて、様々な分岐ポイントでネットワークで効率的なパケットかデータ模写を許容するでしょう。 模写はデータ飛行機問題ですが、それは制御飛行機(経路計算コンポーネントに関連して、活動する)が効率的に模写を実行できるようにLSPsをネットワークにインストールする責任です。 「効率的な」模写の概念が相対的であり、目的による異なった意味を持っているかもしれないことに注意してください(セクション4.2を見てください)。
o P2MP TE LSP setup mechanisms must include the ability to add/remove
receivers to/from the P2MP service supported by an existing P2MP TE
LSP.
o P2MP TE LSPセットアップメカニズムは既存のP2MP TE LSPによって支持されたP2MPサービスからの/に受信機を加えるか、または取り外す能力を含まなければなりません。
o Tunnel endpoints of P2MP TE LSP will be modified by adding/removing
egress LSRs to/from an existing P2MP TE LSP. It is assumed that
the rate of change of leaves of a P2MP LSP (that is, the rate at
which new egress LSRs join, or old egress LSRs are pruned) is "not
so high" because P2MP TE LSPs are assumed to be utilized for TE
applications. This issue is discussed at greater length in Section
4.18.1.
o P2MP TE LSPのトンネル終点は、既存のP2MP TE LSPからの/に出口LSRsを加えるか、または取り外すことによって、変更されるでしょう。 P2MP TE LSPsによってTEアプリケーションに利用されると思われるのでP2MP LSP(すなわち、それの新しい出口でLSRsが接合するか、または古い出口LSRs余計なものを取り除かれるレート)の葉の増減率が「それほど高くない」と思われます。 セクション4.18.1における、より大きい長さでこの問題について議論します。
o A P2MP TE LSP may be protected by fast error recovery mechanisms to
minimize disconnection of a P2MP service.
o P2MP TE LSPは速いエラー回復メカニズムによって保護されて、P2MPサービスの断線を最小にするかもしれません。
o A set of attributes of the P2MP TE LSP (e.g., bandwidth, etc.) may
be modified by some mechanism (e.g., make-before-break, etc.) to
accommodate attribute changes to the P2MP service without impacting
data traffic. These issues are discussed in Sections 4.6 and 4.10.
o データ通信量に影響を与えないで、何らかのメカニズム(例えば、以前造中断など)によって1セットのP2MP TE LSPの属性(例えば、帯域幅など)は変更されて、P2MPサービスへの属性変化を収容するかもしれません。 セクション4.6と4.10でこれらの問題について議論します。
It is not a requirement that the ingress LSR must control the addition or removal of leaves from the P2MP tree.
それはイングレスLSRがP2MP木から葉の添加か取り外しを制御しなければならないという要件ではありません。
It is this document's objective that a solution compliant to the requirements set out in this document MUST operate these P2MP TE capabilities in a scalable fashion.
それは要件への対応することの解決策がスケーラブルなファッションで本書ではこれらのP2MP TE能力を操作しなければならないのを出すこのドキュメントの目的です。
Yasukawa Informational [Page 5] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[5ページ]のRFC4461
1.1. Non-Objectives
1.1. 非目的
For clarity, this section lists some items that are out of scope of this document.
明快ために、このセクションはこのドキュメントの範囲の外にある数個の項目を記載します。
It is assumed that some information elements describing the P2MP TE LSP are known to the ingress LSR prior to LSP establishment. For example, the ingress LSRs know the IP addresses that identify the egress LSRs of the P2MP TE LSP. The mechanisms by which the ingress LSR obtains this information is outside the scope of P2MP TE signaling and so is not included in this document. Other documents may complete the description of this function by providing automated, protocol-based ways of passing this information to the ingress LSR.
P2MP TE LSPについて説明するいくつかの情報要素がLSP設立の前にイングレスLSRにおいて知られていると思われます。 例えば、イングレスLSRsはP2MP TE LSPについて出口LSRsを特定するIPアドレスを知っています。 イングレスLSRがこの情報を得るメカニズムは、P2MP TEシグナリングの範囲の外にあるので、本書では含まれていません。 他のドキュメントは、この情報をイングレスLSRに通過する自動化されて、プロトコルベースの方法を提供することによって、この機能の記述を終了するかもしれません。
This document does not specify any requirements for the following functions.
このドキュメントは以下の機能のためのどんな要件も指定しません。
- Non-TE LSPs (such as per-hop, routing-based LSPs).
- Discovery of egress leaves for a P2MP LSP.
- Hierarchical P2MP LSPs.
- OAM for P2MP LSPs.
- Inter-area and inter-AS P2MP TE LSPs.
- Applicability of P2MP MPLS TE LSPs to service scenarios.
- Specific application or application requirements.
- Algorithms for computing P2MP distribution trees.
- Multipoint-to-point LSPs.
- Multipoint-to-multipoint LSPs.
- Routing protocols.
- Construction of the traffic engineering database.
- Distribution of the information used to construct the traffic
engineering database.
- 非TE LSPs(ホップ、ルーティングベースのLSPsなどの)。 - 出口の発見はP2MP LSPに向けて発ちます。 - 階層的なP2MP LSPs。 - P2MP LSPsのためのOAM。 - そして、相互領域、相互、P2MP Te LSPs。 - サービスシナリオへのP2MP MPLS TE LSPsの適用性。 - 特定のアプリケーションかアプリケーション要件。 - P2MP分配木を計算するためのアルゴリズム。 - 多点からポイントへのLSPs。 - 多点から多点へのLSPs。 - プロトコルを発送します。 - 交通工学データベースの工事。 - 情報の分配は以前はよく交通工学データベースを構成していました。
2. Definitions
2. 定義
2.1. Acronyms
2.1. 頭文字語
P2P: Point-to-point
P2P: ポイントツーポイント
P2MP: Point-to-multipoint
P2MP: ポイントツーマルチポイント
2.2. Terminology
2.2. 用語
The reader is assumed to be familiar with the terminology in [RFC3031] and [RFC3209].
読者が[RFC3031]と[RFC3209]の用語によく知られさせると思われます。
The following terms are defined for use in the context of P2MP TE LSPs only.
次の用語はP2MP TE LSPsだけの文脈における使用のために定義されます。
Yasukawa Informational [Page 6] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[6ページ]のRFC4461
P2MP tree:
P2MP木:
The ordered set of LSRs and TE links that comprise the path of a
P2MP TE LSP from its ingress LSR to all of its egress LSRs.
イングレスLSRから出口LSRsのすべてまでP2MP TE LSPの経路を包括するLSRsとTEリンクの順序集合。
ingress LSR:
イングレスLSR:
The LSR that is responsible for initiating the signaling messages
that set up the P2MP TE LSP.
P2MP TE LSPをセットアップするシグナリングメッセージを開始するのに責任があるLSR。
egress LSR:
出口LSR:
One of potentially many destinations of the P2MP TE LSP. Egress
LSRs may also be referred to as leaf nodes or leaves.
P2MP TE LSPの潜在的に多くの目的地の1つ。 出口LSRsはまた、葉のノードと呼ばれるかもしれないか、またはいなくなります。
bud LSR:
芽のLSR:
An LSR that is an egress LSR, but also has one or more directly
connected downstream LSRs.
出口LSRですが、1か川下で直接より接続されたLSRsがまたあるLSR。
branch LSR:
ブランチLSR:
An LSR that has more than one directly connected downstream LSR.
1つ以上を持っているLSRは直接川下のLSRを接続しました。
P2MP-ID (P2ID):
P2MP-ID(P2ID):
A unique identifier of a P2MP TE LSP, which is constant for the
whole LSP regardless of the number of branches and/or leaves.
P2MP TE LSPのユニークな識別子。(P2MP TE LSPはブランチの数にかかわらず全体のLSPに一定である、そして/または、いなくなります)。
source:
ソース:
The sender of traffic that is carried on a P2MP service supported
by a P2MP LSP. The sender is not necessarily the ingress LSR of
the P2MP LSP.
P2MP LSPによって支持されたP2MPサービスまで運ばれる交通の送付者。 送付者はP2MP LSPの必ずイングレスLSRではありません。
receiver:
受信機:
A recipient of traffic carried on a P2MP service supported by a
P2MP LSP. A receiver is not necessarily an egress LSR of the P2MP
LSP. Zero, one, or more receivers may receive data through a
given egress LSR.
交通の受取人はP2MP LSPによって支持されたP2MPサービスまで運びました。 受信機は必ずP2MP LSPの出口LSRであるというわけではありません。 ゼロ、1台以上の受信機が与えられた出口LSRを通してデータを受け取るかもしれません。
Yasukawa Informational [Page 7] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[7ページ]のRFC4461
2.2.1. Terminology for Partial LSPs
2.2.1. 部分的なLSPsのための用語
It is convenient to sub-divide P2MP trees for functional and representational reasons. A tree may be divided in two dimensions:
機能的で具象主義の理由でP2MP木を細分するのは便利です。 木は二次元で分割されるかもしれません:
- A division may be made along the length of the tree. For example,
the tree may be split into two components each running from the
ingress LSR to a discrete set of egress LSRs. Upstream LSRs (for
example, the ingress LSR) may be members of both components.
- 木の長さに沿って分割をするかもしれません。 例えば、木はLSRsをそれぞれイングレスLSRから離散的な出口まで走らせる2つのコンポーネントに分けられるかもしれません。 上流のLSRs(例えば、イングレスLSR)は両方のコンポーネントのメンバーであるかもしれません。
- A tree may be divided at a branch LSR (or any transit LSR) to
produce a component of the tree that runs from the branch (or
transit) LSR to all egress LSRs downstream of this point.
- 木は、ブランチ(または、トランジット)LSRからすべての出口LSRsまで川下へ走るこのポイントの木のコンポーネントを生産するためにブランチLSR(または、どんなトランジットLSRも)で分割されるかもしれません。
These two methods of splitting the P2MP tree can be combined, so it is useful to introduce some terminology to allow the partitioned trees to be clearly described.
P2MP木を分けるこれらの2つの方法を結合できるので、仕切られた木が明確に説明されるのを許容するために何らかの用語を紹介するのは役に立ちます。
Use the following designations:
以下の名称を使用してください:
Source (ingress) LSR - S
Leaf (egress) LSR - L
Branch LSR - B
Transit LSR - X (any single, arbitrary LSR that is not a source,
leaf or branch)
All - A
Partial (i.e., not all) - P
ソース(イングレス)LSR--S Leaf(出口)LSR--L支店LSR--B Transit LSR--X(ソースでなくて、また葉でなくて、またブランチでもないどんな単一の、そして、任意のLSRも)はすべて、--Partial(すなわち、すべてでない)--Pです。
Define a new term:
新学期を定義してください:
Sub-LSP:
A segment of a P2MP TE LSP that runs from one of the LSP's LSRs
to one or more of its other LSRs.
サブLSP: LSPのLSRsの1つから他のLSRsの1つ以上へ走るP2MP TE LSPのセグメント。
Using these new concepts, we can define any combination or split of the P2MP tree. For example:
これらの新しい概念を使用して、私たちはP2MP木のどんな組み合わせか分裂も定義できます。 例えば:
S2L sub-LSP:
The path from the source to one specific leaf.
S2LサブLSP: ソースからの1枚の特定の葉への経路。
S2PL sub-LSP:
The path from the source to a set of leaves.
S2PLサブLSP: ソースから1セットの葉までの経路。
B2AL sub-LSP:
The path from a branch LSR to all downstream leaves.
B2ALサブLSP: ブランチLSRからすべての川下までの経路はいなくなります。
Yasukawa Informational [Page 8] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[8ページ]のRFC4461
X2X sub-LSP:
A component of the P2MP LSP that is a simple path that does not
branch.
X2XサブLSP: 分岐しない簡単な経路であるP2MP LSPの部品。
Note that the S2AL sub-LSP is equivalent to the P2MP LSP.
S2ALサブLSPがP2MP LSPに同等であることに注意してください。
2.3. Conventions
2.3. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Problem Statement
3. 問題声明
3.1. Motivation
3.1. 動機
As described in Section 1, traffic engineering and constraint-based routing (including Call Admission Control (CAC), explicit source routing, and bandwidth reservation) are required to enable efficient resource usage and strict QoS guarantees. Such mechanisms also make it possible to provide services across a congested network where conventional "shortest path first" forwarding paradigms would fail.
セクション1で説明されるように、交通工学と規制ベースのルーティング(Call Admission Control(CAC)、明白なソースルーティング、および帯域幅の予約を含んでいる)が、効率的なリソース用法と厳しいQoS保証を可能にするのに必要です。 また、そのようなメカニズムで混雑しているネットワークの向こう側に従来であるところにサービスを提供するのが可能になる、「」 最初に、推進パラダイムが失敗する最短パス。
Existing MPLS TE mechanisms [RFC3209] and GMPLS TE mechanisms [RFC3473] only provide support for P2P TE LSPs. While it is possible to provide P2MP TE services using P2P TE LSPs, any such approach is potentially suboptimal since it may result in data replication at the ingress LSR, or in duplicate data traffic within the network.
既存のMPLS TEメカニズム[RFC3209]とGMPLS TEメカニズム[RFC3473]はP2P TE LSPsのサポートを提供するだけです。 P2P TE LSPsを使用するサービスをP2MP TEに供給するのが可能ですが、ネットワークの中でイングレスLSRにおける、または、重複データ交通におけるデータ模写をもたらすかもしれないので、そのようなどんなアプローチも潜在的に準最適です。
Hence, to provide P2MP MPLS TE services in a fully efficient manner, it is necessary to specify specific requirements. These requirements can then be used when defining mechanisms for the use of existing protocols and/or extensions to existing protocols and/or new protocols.
したがって、完全に効率的な方法でサービスをP2MP MPLS TEに供給するために、決められた一定の要求を指定するのが必要です。 そして、既存のプロトコル、そして/または、拡張子の使用のために既存のプロトコル、そして/または、新しいプロトコルとメカニズムを定義するとき、これらの要件を使用できます。
3.2. Requirements Overview
3.2. 要件概観
This document states basic requirements for the setup of P2MP TE LSPs. The requirements apply to the signaling techniques only, and no assumptions are made about which routing protocols are run within the network, or about how the information that is used to construct the Traffic Engineering Database (TED) is distributed. These factors are out of the scope of this document.
このドキュメントはP2MP TE LSPsのセットアップのための基本的な要件を述べます。 要件はシグナリングのテクニックだけに適用されます、そして、仮定は全くどのルーティング・プロトコルがネットワークの中を走るかの周り、または、Traffic Engineering Database(TED)を組み立てるのに使用される情報がどう分配されているかの周りに関してされません。 このドキュメントの範囲の外にこれらの要素があります。
A P2MP TE LSP path computation will take into account various constraints such as bandwidth, affinities, required level of protection and so on. The solution MUST allow for the computation of P2MP TE LSP paths that satisfy constraints, with the objective of
P2MP TE LSP経路計算は帯域幅、親近感、必要なレベルの保護などなどの様々な規制を考慮に入れるでしょう。 解決策はそれが目的がある規制を満たすP2MP TE LSP経路の計算を考慮しなければなりません。
Yasukawa Informational [Page 9] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[9ページ]のRFC4461
supporting various optimization criteria such as delays, bandwidth consumption in the network, or any other combinations. This is likely to require the presence of a TED, as well as the ability to signal the explicit path of an LSP.
遅れ、ネットワークにおける帯域幅消費、またはいかなる他の組み合わせなどの様々な最適化評価基準も支持します。 これは存在にTEDを要求しそうです、LSPの明白な経路に合図する能力と同様に。
A desired requirement is also to maximize the re-use of existing MPLS TE techniques and protocols where doing so does not adversely impact the function, simplicity, or scalability of the solution.
必要な要件はまた、既存のMPLS TEのテクニックとそうするのが逆に解決策の機能、簡単さ、またはスケーラビリティに影響を与えないプロトコルの再使用を最大にすることです。
This document does not restrict the choice of signaling protocol used to set up a P2MP TE LSP, but note that [RFC3468] states
このドキュメントはP2MP TE LSPをセットアップしますが、それ[RFC3468]に注意するのにおいて中古のプロトコルが述べるシグナリングの選択を制限しません。
...the consensus reached by the Multiprotocol
Label Switching (MPLS) Working Group within the IETF to focus its
efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to
RSVP for Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS
signalling protocol for traffic engineering applications...
...主力を注ぐIETFの中のMultiprotocol Label Switching(MPLS)作業部会によって達せられたコンセンサス、「資源予約プロトコル(RSVP)Te:」 MPLS合図としての「Labelによって切り換えられたPaths(LSP)TunnelsのためのRSVPへの拡大」(RFC3209)は交通工学アプリケーションのために議定書を作ります…
The P2MP TE LSP setup mechanism MUST include the ability to add/remove egress LSRs to/from an existing P2MP TE LSP and MUST allow for the support of all the TE LSP management procedures already defined for P2P TE LSP. Further, when new TE LSP procedures are developed for P2P TE LSPs, equivalent or identical procedures SHOULD be developed for P2MP TE LSPs.
P2MP TE LSPセットアップメカニズムは、既存のP2MP TE LSPからの/に出口LSRsを加えるか、または取り外す能力を含まなければならなくて、P2P TE LSPのために既に定義されたすべてのTE LSP管理手順のサポートを考慮しなければなりません。 さらに、新しいTE LSP手順がP2P TE LSPsのために開発されたか、同等であるか同じ手順SHOULDであるときにはP2MP TE LSPsのために開発されてください。
The computation of P2MP trees is implementation dependent and is beyond the scope of the solutions that are built with this document as a guideline.
P2MP木の計算は、実現に依存していて、ガイドラインとしてこのドキュメントで築き上げられる解決策の範囲を超えています。
Consider the following figure.
以下の図を考えてください。
Source 1 (S1)
|
I-LSR1
| |
| |
R2----E-LSR3--LSR1 LSR2---E-LSR2--Receiver 1 (R1)
| :
R3----E-LSR4 E-LSR5
| :
| :
R4 R5
ソース1(S1)| I-LSR1| | | | R2----電子LSR3--LSR1 LSR2---電子LSR2--受信機1(R1)| : R3----電子LSR4電子LSR5| : | : R4 R5
Figure 1
図1
Figure 1 shows a single ingress LSR (I-LSR1), and four egress LSRs (E-LSR2, E-LSR3, E-LSR4, and E-LSR5). I-LSR1 is attached to a traffic source that is generating traffic for a P2MP application.
図1は単一のイングレスLSR(I-LSR1)、および4出口LSRs(E- LSR2、E-LSR3、E-LSR4、およびE-LSR5)を示しています。 I-LSR1はP2MPアプリケーションのための交通を発生させている交通源に取り付けられます。
Yasukawa Informational [Page 10] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[10ページ]のRFC4461
Receivers R1, R2, R3, and R4 are attached to E-LSR2, E-LSR3, and E-LSR4.
受信機のR1、R2、R3、およびR4はE-LSR2、E-LSR3、およびE-LSR4に取り付けられます。
The following are the objectives of P2MP LSP establishment and use.
↓これはP2MP LSP設立と使用の目的です。
a) A P2MP tree that satisfies various constraints is pre-
determined, and details are supplied to I-LSR1.
a) 様々な規制を満たすP2MP木はプレ断固としています、そして、詳細をI-LSR1に提供します。
Note that no assumption is made about whether the tree is
provided to I-LSR1 or computed by I-LSR1. The solution SHOULD
also allow for the support of a partial path by means of loose
routing.
木をI-LSR1に提供するか、またはI-LSR1が計算するかに関して仮定が全くされないことに注意してください。 また、解決策SHOULDはゆるいルーティングによって部分的な経路のサポートを考慮します。
Typical constraints are bandwidth requirements, resource class
affinities, fast rerouting, and preemption. There should not
be any restriction on the possibility of supporting the set of
constraints already defined for point-to-point TE LSPs. A new
constraint may specify which LSRs should be used as branch LSRs
for the P2MP LSR in order to take into account LSR capabilities
or network constraints.
典型的な規制は、帯域幅要件と、リソースクラスの親近感と、速いコースを変更するのと、先取りです。 少しの制限もポイントツーポイントTE LSPsのために既に定義された規制のセットを支える可能性にあるべきではありません。 新しい規制は、LSR能力かネットワーク規制を考慮に入れて、どのLSRsがP2MP LSRにブランチLSRsとして使用されるべきであるかを指定するかもしれません。
b) A P2MP TE LSP is set up from I-LSR1 to E-LSR2, E-LSR3, and
E-LSR4 using the tree information.
b) P2MP TE LSPはE-LSR2、E-LSR3、およびI-LSR1から木の情報を使用するE-LSR4までセットアップされます。
c) In this case, the branch LSR1 should replicate incoming packets
or data and send them to E-LSR3 and E-LSR4.
c) この場合、ブランチLSR1は入って来るパケットかデータを模写して、E-LSR3とE-LSR4にそれらを送るはずです。
d) If a new receiver (R5) expresses an interest in receiving
traffic, a new tree is determined, and a B2L sub-LSP from LSR2
to E-LSR5 is grafted onto the P2MP TE LSP. LSR2 becomes a
branch LSR.
d) 新しい受信機(R5)が交通を受けることへの関心を示すなら、新しい木は断固としています、そして、LSR2からE-LSR5までのサブLSPのB2LはP2MP TE LSPに接ぎ木されます。 LSR2はブランチLSRになります。
4. Detailed Requirements for P2MP TE Extensions
4. P2MP Te拡張子のための詳細な要件
4.1. P2MP LSP
4.1. P2MP LSP
The P2MP TE extensions MUST be applicable to the signaling of LSPs for different switching types. For example, it MUST be possible to signal a P2MP TE LSP in any switching medium, whether it is packet or non-packet based (including frame, cell, TDM, lambda, etc.).
異なった切り換えタイプに、P2MP TE拡張子はLSPsのシグナリングに適切であるに違いありません。 例えば、どんな切り換え媒体でもP2MP TE LSPに合図するのは可能であるに違いありません、それがパケットか非パケットに基づいている(フレーム、セル、TDM、λなどを含んでいて)か否かに関係なく。
As with P2P MPLS technology [RFC3031], traffic is classified with a FEC in this extension. All packets that belong to a particular FEC and that travel from a particular node MUST follow the same P2MP tree.
P2P MPLS技術[RFC3031]のように、交通はFECと共にこの拡大で分類されます。 特定のFECに属すすべてのパケットと特定のノードからのその旅行は同じP2MP木に続かなければなりません。
Yasukawa Informational [Page 11] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[11ページ]のRFC4461
In order to scale to a large number of branches, P2MP TE LSPs SHOULD be identified by a unique identifier (the P2MP ID or P2ID) that is constant for the whole LSP regardless of the number of branches and/or leaves.
多くのブランチに比例するように、P2MP TE LSPs SHOULDは全体のLSPに、ブランチの数にかかわらず一定のユニークな識別子(P2MP IDかP2ID)によって特定される、そして/または、いなくなります。
4.2. P2MP Explicit Routing
4.2. P2MPの明白なルート設定
Various optimizations in P2MP tree formation need to be applied to meet various QoS requirements and operational constraints.
P2MP木の構成における様々な最適化は、様々なQoS必要条件と操作上の規制を満たすために適用される必要があります。
Some P2MP applications may request a bandwidth-guaranteed P2MP tree that satisfies end-to-end delay requirements. And some operators may want to set up a cost-minimum P2MP tree by specifying branch LSRs explicitly.
いくつかのP2MPアプリケーションが終わりから終わりへの遅れ要件を満たす帯域幅で保証されたP2MP木を要求するかもしれません。 そして、何人かのオペレータが、明らかにブランチLSRsを指定することによって、コスト・ミニマムP2MP木をセットアップしたがっているかもしれません。
The P2MP TE solution therefore MUST provide a means of establishing arbitrary P2MP trees under the control of an external tree computation process, path configuration process, or dynamic tree computation process located on the ingress LSR. Figure 2 shows two typical examples.
The P2MP TE solution therefore MUST provide a means of establishing arbitrary P2MP trees under the control of an external tree computation process, path configuration process, or dynamic tree computation process located on the ingress LSR. Figure 2 shows two typical examples.
A A
| / \
B B C
| / \ / \
C D E F G
| / \ / \/ \ / \
D--E*-F*-G*-H*-I*-J*-K*--L H I J KL M N O
A A | / \ B B C | / \ / \ C D E F G | / \ / \/ \ / \ D--E*-F*-G*-H*-I*-J*-K*--L H I J KL M N O
Steiner P2MP tree SPF P2MP tree
Steiner P2MP tree SPF P2MP tree
Figure 2: Examples of P2MP TE LSP topology
Figure 2: Examples of P2MP TE LSP topology
One example is the Steiner P2MP tree (cost-minimum P2MP tree) [STEINER]. This P2MP tree is suitable for constructing a cost- minimum P2MP tree so as to minimize the bandwidth consumption in the core. To realize this P2MP tree, several intermediate LSRs must be both MPLS data terminating LSRs and transit LSRs (LSRs E, F, G, H, I, J, and K in Figure 2). Therefore, the P2MP TE solution MUST support a mechanism that can set up this kind of bud LSR between an ingress LSR and egress LSRs. Note that this includes constrained Steiner trees that allow for the computation of a minimal cost trees with some other constraints such as a bounded delay between the source and every receiver.
One example is the Steiner P2MP tree (cost-minimum P2MP tree) [STEINER]. This P2MP tree is suitable for constructing a cost- minimum P2MP tree so as to minimize the bandwidth consumption in the core. To realize this P2MP tree, several intermediate LSRs must be both MPLS data terminating LSRs and transit LSRs (LSRs E, F, G, H, I, J, and K in Figure 2). Therefore, the P2MP TE solution MUST support a mechanism that can set up this kind of bud LSR between an ingress LSR and egress LSRs. Note that this includes constrained Steiner trees that allow for the computation of a minimal cost trees with some other constraints such as a bounded delay between the source and every receiver.
Yasukawa Informational [Page 12] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Yasukawa Informational [Page 12] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Another example is a CSPF (Constraint Shortest Path First) P2MP tree. By some metric (which can be set upon any specific criteria like the delay, bandwidth, or a combination of those), one can calculate a shortest-path P2MP tree. This P2MP tree is suitable for carrying real-time traffic.
Another example is a CSPF (Constraint Shortest Path First) P2MP tree. By some metric (which can be set upon any specific criteria like the delay, bandwidth, or a combination of those), one can calculate a shortest-path P2MP tree. This P2MP tree is suitable for carrying real-time traffic.
The solution MUST allow the operator to make use of any tree computation technique. In the former case, an efficient/optimal tree is defined as a minimal cost tree (Steiner tree), whereas in the later case, it is defined as the tree that provides shortest path between the source and any receiver.
The solution MUST allow the operator to make use of any tree computation technique. In the former case, an efficient/optimal tree is defined as a minimal cost tree (Steiner tree), whereas in the later case, it is defined as the tree that provides shortest path between the source and any receiver.
To support explicit setup of any reasonable P2MP tree shape, a P2MP TE solution MUST support some form of explicit source-based control of the P2MP tree that can explicitly include particular LSRs as branch LSRs. This can be used by the ingress LSR to set up the P2MP TE LSP. For instance, a P2MP TE LSP can be represented simply as a whole tree or by its individual branches.
To support explicit setup of any reasonable P2MP tree shape, a P2MP TE solution MUST support some form of explicit source-based control of the P2MP tree that can explicitly include particular LSRs as branch LSRs. This can be used by the ingress LSR to set up the P2MP TE LSP. For instance, a P2MP TE LSP can be represented simply as a whole tree or by its individual branches.
4.3. Explicit Path Loose Hops and Widely Scoped Abstract Nodes
4.3. Explicit Path Loose Hops and Widely Scoped Abstract Nodes
A P2MP tree is completely specified if all the required branches and hops between a sender and leaf LSR are indicated.
A P2MP tree is completely specified if all the required branches and hops between a sender and leaf LSR are indicated.
A P2MP tree is partially specified if only a subset of intermediate branches and hops is indicated. This may be achieved using loose hops in the explicit path, or using widely scoped abstract nodes (that is, abstract nodes that are not simple [RFC3209]) such as IPv4 prefixes shorter than 32 bits, or AS numbers. A partially specified P2MP tree might be particularly useful in inter-area and inter-AS situations, although P2MP requirements for inter-area and inter-AS are beyond the scope of this document.
A P2MP tree is partially specified if only a subset of intermediate branches and hops is indicated. This may be achieved using loose hops in the explicit path, or using widely scoped abstract nodes (that is, abstract nodes that are not simple [RFC3209]) such as IPv4 prefixes shorter than 32 bits, or AS numbers. A partially specified P2MP tree might be particularly useful in inter-area and inter-AS situations, although P2MP requirements for inter-area and inter-AS are beyond the scope of this document.
Protocol solutions SHOULD include a way to specify loose hops and widely scoped abstract nodes in the explicit source-based control of the P2MP tree as defined in the previous section. Where this support is provided, protocol solutions MUST allow downstream LSRs to apply further explicit control to the P2MP tree to resolve a partially specified tree into a (more) completely specified tree.
Protocol solutions SHOULD include a way to specify loose hops and widely scoped abstract nodes in the explicit source-based control of the P2MP tree as defined in the previous section. Where this support is provided, protocol solutions MUST allow downstream LSRs to apply further explicit control to the P2MP tree to resolve a partially specified tree into a (more) completely specified tree.
Protocol solutions MUST allow the P2MP tree to be completely specified at the ingress LSR where sufficient information exists to allow the full tree to be computed and where policies along the path (such as at domain boundaries) support full specification.
Protocol solutions MUST allow the P2MP tree to be completely specified at the ingress LSR where sufficient information exists to allow the full tree to be computed and where policies along the path (such as at domain boundaries) support full specification.
Yasukawa Informational [Page 13] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Yasukawa Informational [Page 13] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
In all cases, the egress LSRs of the P2MP TE LSP must be fully specified either individually or through some collective identifier. Without this information, it is impossible to know where the TE LSP should be routed to.
In all cases, the egress LSRs of the P2MP TE LSP must be fully specified either individually or through some collective identifier. Without this information, it is impossible to know where the TE LSP should be routed to.
In case of a tree being computed by some downstream LSRs (e.g., the case of hops specified as loose hops), the solution MUST provide protocol mechanisms for the ingress LSR of the P2MP TE LSP to learn the full P2MP tree. Note that this information may not always be obtainable owing to policy considerations, but where part of the path remains confidential, it MUST be reported through aggregation (for example, using an AS number).
In case of a tree being computed by some downstream LSRs (e.g., the case of hops specified as loose hops), the solution MUST provide protocol mechanisms for the ingress LSR of the P2MP TE LSP to learn the full P2MP tree. Note that this information may not always be obtainable owing to policy considerations, but where part of the path remains confidential, it MUST be reported through aggregation (for example, using an AS number).
4.4. P2MP TE LSP Establishment, Teardown, and Modification Mechanisms
4.4. P2MP TE LSP Establishment, Teardown, and Modification Mechanisms
The P2MP TE solution MUST support establishment, maintenance, and teardown of P2MP TE LSPs in a manner that is at least scalable in a linear way. This MUST include both the existence of very many LSPs at once, and the existence of very many destinations for a single P2MP LSP.
The P2MP TE solution MUST support establishment, maintenance, and teardown of P2MP TE LSPs in a manner that is at least scalable in a linear way. This MUST include both the existence of very many LSPs at once, and the existence of very many destinations for a single P2MP LSP.
In addition to P2MP TE LSP establishment and teardown mechanisms, the solution SHOULD support a partial P2MP tree modification mechanism.
In addition to P2MP TE LSP establishment and teardown mechanisms, the solution SHOULD support a partial P2MP tree modification mechanism.
For the purpose of adding sub-P2MP TE LSPs to an existing P2MP TE LSP, the extensions SHOULD support a grafting mechanism. For the purpose of deleting a sub-P2MP TE LSPs from an existing P2MP TE LSP, the extensions SHOULD support a pruning mechanism.
For the purpose of adding sub-P2MP TE LSPs to an existing P2MP TE LSP, the extensions SHOULD support a grafting mechanism. For the purpose of deleting a sub-P2MP TE LSPs from an existing P2MP TE LSP, the extensions SHOULD support a pruning mechanism.
It is RECOMMENDED that these grafting and pruning operations cause no additional processing in nodes that are not along the path to the grafting or pruning node, or that are downstream of the grafting or pruning node toward the grafted or pruned leaves. Moreover, both grafting and pruning operations MUST NOT disrupt traffic currently forwarded along the P2MP tree.
It is RECOMMENDED that these grafting and pruning operations cause no additional processing in nodes that are not along the path to the grafting or pruning node, or that are downstream of the grafting or pruning node toward the grafted or pruned leaves. Moreover, both grafting and pruning operations MUST NOT disrupt traffic currently forwarded along the P2MP tree.
There is no assumption that the explicitly routed P2MP LSP remains on an optimal path after several grafts and prunes have occurred. In this context, scalable refers to the signaling process for the P2MP TE LSP. The TE nature of the LSP allows that re-optimization may take place from time to time to restore the optimality of the LSP.
There is no assumption that the explicitly routed P2MP LSP remains on an optimal path after several grafts and prunes have occurred. In this context, scalable refers to the signaling process for the P2MP TE LSP. The TE nature of the LSP allows that re-optimization may take place from time to time to restore the optimality of the LSP.
4.5. Fragmentation
4.5. Fragmentation
The P2MP TE solution MUST handle the situation where a single protocol message cannot contain all the information necessary to signal the establishment of the P2MP LSP. It MUST be possible to establish the LSP in these circumstances.
The P2MP TE solution MUST handle the situation where a single protocol message cannot contain all the information necessary to signal the establishment of the P2MP LSP. It MUST be possible to establish the LSP in these circumstances.
Yasukawa Informational [Page 14] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Yasukawa Informational [Page 14] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
This situation may arise in either of the following circumstances.
This situation may arise in either of the following circumstances.
a. The ingress LSR cannot signal the whole tree in a single
message.
a. The ingress LSR cannot signal the whole tree in a single message.
b. The information in a message expands to be too large (or is
discovered to be too large) at some transit node. This may
occur because of some increase in the information that needs to
be signaled or because of a reduction in the size of signaling
message that is supported.
b. The information in a message expands to be too large (or is discovered to be too large) at some transit node. This may occur because of some increase in the information that needs to be signaled or because of a reduction in the size of signaling message that is supported.
The solution to these problems SHOULD NOT rely on IP fragmentation of protocol messages, and it is RECOMMENDED to rely on some protocol procedures specific to the signaling solution.
The solution to these problems SHOULD NOT rely on IP fragmentation of protocol messages, and it is RECOMMENDED to rely on some protocol procedures specific to the signaling solution.
In the event that fragmented IP packets containing protocol messages are received, it is NOT RECOMMENDED that they are reassembled at the receiving LSR.
In the event that fragmented IP packets containing protocol messages are received, it is NOT RECOMMENDED that they are reassembled at the receiving LSR.
4.6. Failure Reporting and Error Recovery
4.6. Failure Reporting and Error Recovery
Failure events may cause egress LSRs or sub-P2MP LSPs to become detached from the P2MP TE LSP. These events MUST be reported upstream as for a P2P LSP.
Failure events may cause egress LSRs or sub-P2MP LSPs to become detached from the P2MP TE LSP. These events MUST be reported upstream as for a P2P LSP.
The solution SHOULD provide recovery techniques, such as protection and restoration, allowing recovery of any impacted sub-P2MP TE LSPs. In particular, a solution MUST provide fast protection mechanisms applicable to P2MP TE LSP similar to the solutions specified in [RFC4090] for P2P TE LSPs. Note also that no assumption is made about whether backup paths for P2MP TE LSPs should or should not be shared with P2P TE LSPs backup paths.
The solution SHOULD provide recovery techniques, such as protection and restoration, allowing recovery of any impacted sub-P2MP TE LSPs. In particular, a solution MUST provide fast protection mechanisms applicable to P2MP TE LSP similar to the solutions specified in [RFC4090] for P2P TE LSPs. Note also that no assumption is made about whether backup paths for P2MP TE LSPs should or should not be shared with P2P TE LSPs backup paths.
Note that the functions specified in [RFC4090] are currently specific to packet environments and do not apply to non-packet environments. Thus, while solutions MUST provide fast protection mechanisms similar to those specified in [RFC4090], this requirement is limited to the subset of the solution space that applies to packet-switched networks only.
Note that the functions specified in [RFC4090] are currently specific to packet environments and do not apply to non-packet environments. Thus, while solutions MUST provide fast protection mechanisms similar to those specified in [RFC4090], this requirement is limited to the subset of the solution space that applies to packet-switched networks only.
Note that the requirements expressed in this document are general to all MPLS TE P2MP signaling, and any solution that meets them will therefore be general. Specific applications may have additional requirements or may want to relax some requirements stated in this document. This may lead to variations in the solution.
Note that the requirements expressed in this document are general to all MPLS TE P2MP signaling, and any solution that meets them will therefore be general. Specific applications may have additional requirements or may want to relax some requirements stated in this document. This may lead to variations in the solution.
Yasukawa Informational [Page 15] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Yasukawa Informational [Page 15] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
The solution SHOULD also support the ability to meet other network recovery requirements such as bandwidth protection and bounded propagation delay increase along the backup path during failure.
The solution SHOULD also support the ability to meet other network recovery requirements such as bandwidth protection and bounded propagation delay increase along the backup path during failure.
A P2MP TE solution MUST support the P2MP fast protection mechanism to handle P2MP applications sensitive to traffic disruption.
A P2MP TE solution MUST support the P2MP fast protection mechanism to handle P2MP applications sensitive to traffic disruption.
If the ingress LSR is informed of the failure of delivery to fewer than all the egress LSRs, this SHOULD NOT cause automatic teardown of the P2MP TE LSP. That is, while some egress LSRs remain connected to the P2MP tree, it SHOULD be a matter of local policy at the ingress LSR whether the P2MP LSP is retained.
If the ingress LSR is informed of the failure of delivery to fewer than all the egress LSRs, this SHOULD NOT cause automatic teardown of the P2MP TE LSP. That is, while some egress LSRs remain connected to the P2MP tree, it SHOULD be a matter of local policy at the ingress LSR whether the P2MP LSP is retained.
When all egress LSRs downstream of a branch LSR have become disconnected from the P2MP tree, and some branch LSR is unable to restore connectivity to any of them by means of some recovery or protection mechanisms, the branch LSR MAY remove itself from the P2MP tree provided that it is not also an egress LSR (that is, a bud). Since the faults that severed the various downstream egress LSRs from the P2MP tree may be disparate, the branch LSR MUST report all such errors to its upstream neighbor. An upstream LSR or the ingress LSR can then decide to re-compute the path to those particular egress LSRs around the failure point.
When all egress LSRs downstream of a branch LSR have become disconnected from the P2MP tree, and some branch LSR is unable to restore connectivity to any of them by means of some recovery or protection mechanisms, the branch LSR MAY remove itself from the P2MP tree provided that it is not also an egress LSR (that is, a bud). Since the faults that severed the various downstream egress LSRs from the P2MP tree may be disparate, the branch LSR MUST report all such errors to its upstream neighbor. An upstream LSR or the ingress LSR can then decide to re-compute the path to those particular egress LSRs around the failure point.
Solutions MAY include the facility for transit LSRs and particularly branch LSRs to recompute sub-P2MP trees to restore them after failures. In the event of successful repair, error notifications SHOULD NOT be reported to upstream nodes, but the new paths are reported if route recording is in use. Crankback requirements are discussed in Section 4.21.
Solutions MAY include the facility for transit LSRs and particularly branch LSRs to recompute sub-P2MP trees to restore them after failures. In the event of successful repair, error notifications SHOULD NOT be reported to upstream nodes, but the new paths are reported if route recording is in use. Crankback requirements are discussed in Section 4.21.
4.7. Record Route of P2MP TE LSP
4.7. Record Route of P2MP TE LSP
Being able to identify the established topology of P2MP TE LSP is very important for various purposes such as management and operation of some local recovery mechanisms like Fast Reroute [RFC4090]. A network operator uses this information to manage P2MP TE LSPs.
Being able to identify the established topology of P2MP TE LSP is very important for various purposes such as management and operation of some local recovery mechanisms like Fast Reroute [RFC4090]. A network operator uses this information to manage P2MP TE LSPs.
Therefore, the P2MP TE solution MUST support a mechanism that can collect and update P2MP tree topology information after the P2MP LSP establishment and modification process.
Therefore, the P2MP TE solution MUST support a mechanism that can collect and update P2MP tree topology information after the P2MP LSP establishment and modification process.
It is RECOMMENDED that the information is collected in a data format that allows easy recognition of the P2MP tree topology.
It is RECOMMENDED that the information is collected in a data format that allows easy recognition of the P2MP tree topology.
The solution MUST support mechanisms for the recording of both outgoing interfaces and node-ids.
The solution MUST support mechanisms for the recording of both outgoing interfaces and node-ids.
Yasukawa Informational [Page 16] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Yasukawa Informational [Page 16] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
The solution MUST gracefully handle scaling issues concerned with the collection of P2MP tree information, including the case where the collected information is too large to be carried in a single protocol message.
The solution MUST gracefully handle scaling issues concerned with the collection of P2MP tree information, including the case where the collected information is too large to be carried in a single protocol message.
4.8. Call Admission Control (CAC) and QoS Control Mechanism of
P2MP TE LSPs
4.8. Call Admission Control (CAC) and QoS Control Mechanism of P2MP TE LSPs
P2MP TE LSPs may share network resource with P2P TE LSPs. Therefore, it is important to use CAC and QoS in the same way as P2P TE LSPs for easy and scalable operation.
P2MP TE LSPs may share network resource with P2P TE LSPs. Therefore, it is important to use CAC and QoS in the same way as P2P TE LSPs for easy and scalable operation.
P2MP TE solutions MUST support both resource sharing and exclusive resource utilization to facilitate coexistence with other LSPs to the same destination(s).
P2MP TE solutions MUST support both resource sharing and exclusive resource utilization to facilitate coexistence with other LSPs to the same destination(s).
P2MP TE solutions MUST be applicable to DiffServ-enabled networks that can provide consistent QoS control in P2MP LSP traffic.
P2MP TE solutions MUST be applicable to DiffServ-enabled networks that can provide consistent QoS control in P2MP LSP traffic.
Any solution SHOULD also satisfy the DS-TE requirements [RFC3564] and interoperate smoothly with current P2P DS-TE protocol specifications.
Any solution SHOULD also satisfy the DS-TE requirements [RFC3564] and interoperate smoothly with current P2P DS-TE protocol specifications.
Note that this requirement document does not make any assumption on the type of bandwidth pool used for P2MP TE LSPs, which can either be shared with P2P TE LSP or be dedicated for P2MP use.
Note that this requirement document does not make any assumption on the type of bandwidth pool used for P2MP TE LSPs, which can either be shared with P2P TE LSP or be dedicated for P2MP use.
4.9. Variation of LSP Parameters
4.9. Variation of LSP Parameters
Certain parameters (such as priority and bandwidth) are associated with an LSP. The parameters are installed by the signaling exchanges associated with establishing and maintaining the LSP.
Certain parameters (such as priority and bandwidth) are associated with an LSP. The parameters are installed by the signaling exchanges associated with establishing and maintaining the LSP.
Any solution MUST NOT allow for variance of these parameters within a single P2MP LSP. That is:
Any solution MUST NOT allow for variance of these parameters within a single P2MP LSP. That is:
- No attributes set and signaled by the ingress LSR of a P2MP LSP may
be varied by downstream LSRs.
- There MUST be homogeneous QoS from the root to all leaves of a
single P2MP LSP.
- No attributes set and signaled by the ingress LSR of a P2MP LSP may be varied by downstream LSRs. - There MUST be homogeneous QoS from the root to all leaves of a single P2MP LSP.
Changing the parameters for the whole tree MAY be supported, but the change MUST apply to the whole tree from ingress LSR to all egress LSRs.
Changing the parameters for the whole tree MAY be supported, but the change MUST apply to the whole tree from ingress LSR to all egress LSRs.
Yasukawa Informational [Page 17] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Yasukawa Informational [Page 17] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
4.10. Re-Optimization of P2MP TE LSPs
4.10. Re-Optimization of P2MP TE LSPs
The detection of a more optimal path (for example, one with a lower overall cost) is an example of a situation where P2MP TE LSP re- routing may be required. While re-routing is in progress, an important requirement is to avoid double bandwidth reservation (over the common parts between the old and new LSP) thorough the use of resource sharing.
The detection of a more optimal path (for example, one with a lower overall cost) is an example of a situation where P2MP TE LSP re- routing may be required. While re-routing is in progress, an important requirement is to avoid double bandwidth reservation (over the common parts between the old and new LSP) thorough the use of resource sharing.
Make-before-break MUST be supported for a P2MP TE LSP to ensure that there is minimal traffic disruption when the P2MP TE LSP is re- routed.
Make-before-break MUST be supported for a P2MP TE LSP to ensure that there is minimal traffic disruption when the P2MP TE LSP is re- routed.
Make-before-break that only applies to a sub-P2MP tree without impacting the data on all the other parts of the P2MP tree MUST be supported.
Make-before-break that only applies to a sub-P2MP tree without impacting the data on all the other parts of the P2MP tree MUST be supported.
The solution SHOULD allow for make-before-break re-optimization of any subdivision of the P2MP LSP (S2PL sub-LSP, S2X sub-LSP, S2L sub- LSP, X2AL sub-LSP, B2PL sub-LSP, X2AL sub-LSP, or B2AL tree). Further, it SHOULD do so by minimizing the signaling impact on the rest of the P2MP LSP, and without affecting the ability of the management plane to manage the LSP.
The solution SHOULD allow for make-before-break re-optimization of any subdivision of the P2MP LSP (S2PL sub-LSP, S2X sub-LSP, S2L sub- LSP, X2AL sub-LSP, B2PL sub-LSP, X2AL sub-LSP, or B2AL tree). Further, it SHOULD do so by minimizing the signaling impact on the rest of the P2MP LSP, and without affecting the ability of the management plane to manage the LSP.
The solution SHOULD also provide the ability for the ingress LSR to have strict control over the re-optimization process. The ingress LSR SHOULD be able to limit all re-optimization to be source- initiated.
The solution SHOULD also provide the ability for the ingress LSR to have strict control over the re-optimization process. The ingress LSR SHOULD be able to limit all re-optimization to be source- initiated.
Where sub-LSP re-optimization is allowed by the ingress LSR, such re-optimization MAY be initiated by a downstream LSR that is the root of the sub-LSP that is to be re-optimized. Sub-LSP re-optimization initiated by a downstream LSR MUST be carried out with the same regard to minimizing the impact on active traffic as was described above for other re-optimization.
Where sub-LSP re-optimization is allowed by the ingress LSR, such re-optimization MAY be initiated by a downstream LSR that is the root of the sub-LSP that is to be re-optimized. Sub-LSP re-optimization initiated by a downstream LSR MUST be carried out with the same regard to minimizing the impact on active traffic as was described above for other re-optimization.
4.11. Merging of Tree Branches
4.11. Merging of Tree Branches
It is possible for a single transit LSR to receive multiple signaling messages for the same P2MP LSP but for different sets of destinations. These messages may be received from the same or different upstream nodes and may need to be passed on to the same or different downstream nodes.
It is possible for a single transit LSR to receive multiple signaling messages for the same P2MP LSP but for different sets of destinations. These messages may be received from the same or different upstream nodes and may need to be passed on to the same or different downstream nodes.
This situation may arise as the result of the signaling solution definition or implementation options within the signaling solution. Further, it may happen during make-before-break re-optimization (Section 4.10).
This situation may arise as the result of the signaling solution definition or implementation options within the signaling solution. Further, it may happen during make-before-break re-optimization (Section 4.10).
Yasukawa Informational [Page 18] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Yasukawa Informational [Page 18] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
It is even possible that it is necessary to construct distinct upstream branches in order to achieve the correct label choices in certain switching technologies managed by GMPLS (for example, photonic cross-connects where the selection of a particular lambda for the downstream branches is only available on different upstream switches).
It is even possible that it is necessary to construct distinct upstream branches in order to achieve the correct label choices in certain switching technologies managed by GMPLS (for example, photonic cross-connects where the selection of a particular lambda for the downstream branches is only available on different upstream switches).
The solution MUST support the case where multiple signaling messages for the same P2MP LSP are received at a single transit LSR and refer to the same upstream interface. In this case, the result of the protocol procedures SHOULD be a single data flow on the upstream interface.
The solution MUST support the case where multiple signaling messages for the same P2MP LSP are received at a single transit LSR and refer to the same upstream interface. In this case, the result of the protocol procedures SHOULD be a single data flow on the upstream interface.
The solution SHOULD support the case where multiple signaling messages for the same P2MP LSP are received at a single transit LSR and refer to different upstream interfaces, and where each signaling message results in the use of different downstream interfaces. This case represents data flows that cross at the LSR but that do not merge.
The solution SHOULD support the case where multiple signaling messages for the same P2MP LSP are received at a single transit LSR and refer to different upstream interfaces, and where each signaling message results in the use of different downstream interfaces. This case represents data flows that cross at the LSR but that do not merge.
The solution MAY support the case where multiple signaling messages for the same P2MP LSP are received at a single transit LSR and refer to different upstream interfaces, and where the downstream interfaces are shared across the received signaling messages. This case represents the merging of data flows. A solution that supports this case MUST ensure that data is not replicated on the downstream interfaces.
The solution MAY support the case where multiple signaling messages for the same P2MP LSP are received at a single transit LSR and refer to different upstream interfaces, and where the downstream interfaces are shared across the received signaling messages. This case represents the merging of data flows. A solution that supports this case MUST ensure that data is not replicated on the downstream interfaces.
An alternative to supporting this last case is for the signaling protocol to indicate an error such that the merge may be resolved by the upstream LSRs.
An alternative to supporting this last case is for the signaling protocol to indicate an error such that the merge may be resolved by the upstream LSRs.
4.12. Data Duplication
4.12. Data Duplication
Data duplication refers to the receipt by any recipient of duplicate instances of the data. In a packet environment, this means the receipt of duplicate packets. Although small-scale packet duplication (that is, a few packets over a relatively short period of time) should be a harmless (if inefficient) situation, certain existing and deployed applications will not tolerate packet duplication. Sustained packet duplication is, at best, a waste of network and processing resources and, at worst, may cause congestion and the inability to process the data correctly.
Data duplication refers to the receipt by any recipient of duplicate instances of the data. In a packet environment, this means the receipt of duplicate packets. Although small-scale packet duplication (that is, a few packets over a relatively short period of time) should be a harmless (if inefficient) situation, certain existing and deployed applications will not tolerate packet duplication. Sustained packet duplication is, at best, a waste of network and processing resources and, at worst, may cause congestion and the inability to process the data correctly.
In a non-packet environment, data duplication means the duplication of some part of the signal that may lead to the replication of data or to the scrambling of data.
In a non-packet environment, data duplication means the duplication of some part of the signal that may lead to the replication of data or to the scrambling of data.
Yasukawa Informational [Page 19] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Yasukawa Informational [Page 19] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Data duplication may legitimately arise in various scenarios including re-optimization of active LSPs as described in the previous section, and protection of LSPs. Thus, it is impractical to regulate against data duplication in this document.
Data duplication may legitimately arise in various scenarios including re-optimization of active LSPs as described in the previous section, and protection of LSPs. Thus, it is impractical to regulate against data duplication in this document.
Instead, the solution:
Instead, the solution:
- SHOULD limit to bounded transitory conditions the cases where
network bandwidth is wasted by the existence of duplicate delivery
paths.
- SHOULD limit to bounded transitory conditions the cases where network bandwidth is wasted by the existence of duplicate delivery paths.
- MUST limit the cases where duplicate data is delivered to an
application to bounded transitory conditions.
- MUST limit the cases where duplicate data is delivered to an application to bounded transitory conditions.
4.13. IPv4/IPv6 Support
4.13. IPv4/IPv6 Support
Any P2MP TE solution MUST support IPv4 and IPv6 addressing.
Any P2MP TE solution MUST support IPv4 and IPv6 addressing.
4.14. P2MP MPLS Label
4.14. P2MP MPLS Label
A P2MP TE solution MUST allow the continued use of existing techniques to establish P2P LSPs (TE and otherwise) within the same network, and MUST allow the coexistence of P2P LSPs within the same network as P2MP TE LSPs.
A P2MP TE solution MUST allow the continued use of existing techniques to establish P2P LSPs (TE and otherwise) within the same network, and MUST allow the coexistence of P2P LSPs within the same network as P2MP TE LSPs.
A P2MP TE solution MUST be specified in such a way that it allows P2MP and P2P TE LSPs to be signaled on the same interface.
A P2MP TE solution MUST be specified in such a way that it allows P2MP and P2P TE LSPs to be signaled on the same interface.
4.15. Advertisement of P2MP Capability
4.15. Advertisement of P2MP Capability
Several high-level requirements have been identified to determine the capabilities of LSRs within a P2MP network. The aim of such information is to facilitate the computation of P2MP trees using TE constraints within a network that contains LSRs that do not all have the same capability levels with respect to P2MP signaling and data forwarding.
Several high-level requirements have been identified to determine the capabilities of LSRs within a P2MP network. The aim of such information is to facilitate the computation of P2MP trees using TE constraints within a network that contains LSRs that do not all have the same capability levels with respect to P2MP signaling and data forwarding.
These capabilities include, but are not limited to:
These capabilities include, but are not limited to:
- The ability of an LSR to support branching.
- The ability of an LSR to act as an egress LSR and a branch LSR for
the same LSP.
- The ability of an LSR to support P2MP MPLS-TE signaling.
- The ability of an LSR to support branching. - The ability of an LSR to act as an egress LSR and a branch LSR for the same LSP. - The ability of an LSR to support P2MP MPLS-TE signaling.
Yasukawa Informational [Page 20] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Yasukawa Informational [Page 20] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
4.16. Multi-Access LANs
4.16. Multi-Access LANs
P2MP MPLS TE may be used to traverse network segments that are provided by multi-access media such as Ethernet. In these cases, it is also possible that the entry point to the network segment is a branch LSR of the P2MP LSP.
P2MP MPLS TE may be used to traverse network segments that are provided by multi-access media such as Ethernet. In these cases, it is also possible that the entry point to the network segment is a branch LSR of the P2MP LSP.
Two options clearly exist:
Two options clearly exist:
- the branch LSR replicates the data and transmits multiple copies
onto the segment.
- the branch LSR sends a single copy of the data to the segment and
relies on the exit points to determine whether to receive and
forward the data.
- the branch LSR replicates the data and transmits multiple copies onto the segment. - the branch LSR sends a single copy of the data to the segment and relies on the exit points to determine whether to receive and forward the data.
The first option has a significant data plane scaling issue since all replicated data must be sent through the same port and carried on the same segment. Thus, a solution SHOULD provide a mechanism for a branch LSR to send a single copy of the data onto a multi-access network to reach multiple (adjacent) downstream nodes. The second option may have control plane scaling issues.
The first option has a significant data plane scaling issue since all replicated data must be sent through the same port and carried on the same segment. Thus, a solution SHOULD provide a mechanism for a branch LSR to send a single copy of the data onto a multi-access network to reach multiple (adjacent) downstream nodes. The second option may have control plane scaling issues.
4.17. P2MP MPLS OAM
4.17. P2MP MPLS OAM
The MPLS and GMPLS MIB modules MUST be enhanced to provide P2MP TE LSP management in line with whatever signaling solutions are developed.
The MPLS and GMPLS MIB modules MUST be enhanced to provide P2MP TE LSP management in line with whatever signaling solutions are developed.
In order to facilitate correct management, P2MP TE LSPs MUST have unique identifiers, since otherwise it is impossible to determine which LSP is being managed.
In order to facilitate correct management, P2MP TE LSPs MUST have unique identifiers, since otherwise it is impossible to determine which LSP is being managed.
Further discussions of OAM are out of scope for this document. See [P2MP-OAM] for more details.
Further discussions of OAM are out of scope for this document. See [P2MP-OAM] for more details.
4.18. Scalability
4.18. Scalability
Scalability is a key requirement in P2MP MPLS systems. Solutions MUST be designed to scale well with an increase in the number of any of the following:
Scalability is a key requirement in P2MP MPLS systems. Solutions MUST be designed to scale well with an increase in the number of any of the following:
- the number of recipients - the number of egress LSRs - the number of branch LSRs - the number of branches
- the number of recipients - the number of egress LSRs - the number of branch LSRs - the number of branches
Both scalability of control plane operation (setup, maintenance, modification, and teardown) MUST be considered.
Both scalability of control plane operation (setup, maintenance, modification, and teardown) MUST be considered.
Yasukawa Informational [Page 21] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Yasukawa Informational [Page 21] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Key considerations MUST include:
Key considerations MUST include:
- the amount of refresh processing associated with maintaining a P2MP
TE LSP.
- the amount of protocol state that must be maintained by ingress and
transit LSRs along a P2MP tree.
- the number of protocol messages required to set up or tear down a
P2MP LSP as a function of the number of egress LSRs.
- the number of protocol messages required to repair a P2MP LSP after
failure or to perform make-before-break.
- the amount of protocol information transmitted to manage a P2MP TE
LSP (i.e., the message size).
- the amount of additional data distributed in potential routing
extensions.
- the amount of additional control plane processing required in the
network to detect whether an add/delete of a new branch is
required, and in particular, the amount of processing in steady
state when no add/delete is requested
- the amount of control plane processing required by the ingress,
transit, and egress LSRs to add/delete a branch LSP to/from an
existing P2MP LSP.
- the amount of refresh processing associated with maintaining a P2MP TE LSP. - the amount of protocol state that must be maintained by ingress and transit LSRs along a P2MP tree. - the number of protocol messages required to set up or tear down a P2MP LSP as a function of the number of egress LSRs. - the number of protocol messages required to repair a P2MP LSP after failure or to perform make-before-break. - the amount of protocol information transmitted to manage a P2MP TE LSP (i.e., the message size). - the amount of additional data distributed in potential routing extensions. - the amount of additional control plane processing required in the network to detect whether an add/delete of a new branch is required, and in particular, the amount of processing in steady state when no add/delete is requested - the amount of control plane processing required by the ingress, transit, and egress LSRs to add/delete a branch LSP to/from an existing P2MP LSP.
It is expected that the applicability of each solution will be evaluated with regards to the aforementioned scalability criteria.
It is expected that the applicability of each solution will be evaluated with regards to the aforementioned scalability criteria.
4.18.1. Absolute Limits
4.18.1. Absolute Limits
In order to achieve the best solution for the problem space, it is helpful to clarify the boundaries for P2MP TE LSPs.
In order to achieve the best solution for the problem space, it is helpful to clarify the boundaries for P2MP TE LSPs.
- Number of egress LSRs.
- Number of egress LSRs.
A scaling bound is placed on the solution mechanism such that a
P2MP TE LSP MUST reduce to similar scaling properties as a P2P LSP
when the number of egress LSRs reduces to one. That is,
establishing a P2MP TE LSP to a single egress LSR should cost
approximately as much as establishing a P2P LSP.
A scaling bound is placed on the solution mechanism such that a P2MP TE LSP MUST reduce to similar scaling properties as a P2P LSP when the number of egress LSRs reduces to one. That is, establishing a P2MP TE LSP to a single egress LSR should cost approximately as much as establishing a P2P LSP.
It is important to classify the issues of scaling within the
context of traffic engineering. It is anticipated that the initial
deployments of P2MP TE LSPs will be limited to a maximum of around
a hundred egress LSRs, but that within five years deployments may
increase this to several hundred, and that future deployments may
require significantly larger numbers.
It is important to classify the issues of scaling within the context of traffic engineering. It is anticipated that the initial deployments of P2MP TE LSPs will be limited to a maximum of around a hundred egress LSRs, but that within five years deployments may increase this to several hundred, and that future deployments may require significantly larger numbers.
An acceptable upper bound for a solution, therefore, is one that
scales linearly with the number of egress LSRs. It is expected
that solutions will scale better than linearly.
An acceptable upper bound for a solution, therefore, is one that scales linearly with the number of egress LSRs. It is expected that solutions will scale better than linearly.
Yasukawa Informational [Page 22] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[22ページ]のRFC4461
Solutions that scale worse than linearly (that is, exponentially or
polynomially) are not acceptable whatever the number of egress LSRs
they could support.
直線的(それは指数関数的か多項式的にいる)よりひどく比例するソリューションは彼らが支持できた出口LSRsの数が何であっても許容できません。
- Number of branch LSRs.
- ブランチLSRsの数。
Solutions MUST support all possibilities from one extreme of a
single branch LSR that forks to all leaves on a separate branch, to
the greatest number of branch LSRs which is (n-1) for n egress
LSRs. Assumptions MUST NOT be made in the solution regarding which
topology is more common, and the solution MUST be designed to
ensure scalability in all topologies.
ソリューションは分岐する独身のブランチLSRの1つの極端から別々の支店のすべての葉まですべての可能性を支持しなければなりません、n出口LSRsにはある(n-1)ブランチLSRsの最大数に。 トポロジーが、より一般的である解決策で仮定をしてはいけません、そして、すべてのtopologiesでスケーラビリティを確実にするように解決策を設計しなければなりません。
- Dynamics of P2MP tree.
- P2MP木の力学。
Recall that the mechanisms for determining which egress LSRs should
be added to an LSP and for adding and removing egress LSRs from
that group are out of the scope of this document. Nevertheless, it
is useful to understand the expected rates of arrival and departure
of egress LSRs, since this can impact the selection of solution
techniques.
どの出口を決定して、LSRsがそのグループから出口LSRsをLSPと加えて、取り外すために加えられるべきであるのでこのドキュメントの範囲の外にメカニズムがあったと思い出してください。 それにもかかわらず、到着の予想された速度と出口LSRsの出発を理解しているのは役に立ちます、これが解決策のテクニックの品揃えに影響を与えることができるので。
Again, this document is limited to traffic engineering, and in this
model the rate of change of LSP egress LSRs may be expected to be
lower than the rate of change of recipients in an IP multicast
group.
一方、このドキュメントは、交通工学に制限されて、このLSP出口LSRsの増減率のモデルでIPマルチキャストグループにおける、受取人の増減率より低いと予想されるかもしれません。
Although the absolute number of egress LSRs coming and going is the
important element for determining the scalability of a solution,
note that a percentage may be a more comprehensible measure, but
that this is not as significant for LSPs with a small number of
recipients.
出口LSRsの来て行くことの無名数は解決策のスケーラビリティを決定するための重要な要素ですが、割合が、より分かりやすい測定であるかもしれませんが、LSPsには、少ない数の受取人には、これが重要でないことに注意してください。
A working figure for an established P2MP TE LSP is less than 10%
churn per day; that is, a relatively slow rate of churn.
1日あたり確立したP2MP TE LSPのための働く図は10%未満の攪乳器です。 すなわち、攪乳器の比較的遅いレート。
We could say that a P2MP LSP would be shared by multiple multicast
groups, so the dynamics of the P2MP LSP would be relatively small.
私たちが、P2MP LSPが複数のマルチキャストグループによって共有されると言うことができたので、P2MP LSPの力学は比較的小さいでしょう。
Solutions MUST optimize for such relatively low rates of change and
are not required to optimize for significantly higher rates of
change.
ソリューションは、変化のそのような比較的低い率のために最適化しなければならなくて、変化のかなり高い率のために最適化するのに必要ではありません。
- Rate of change within the network.
- ネットワークの中の増減率。
It is also important to understand the scaling with regard to
changes within the network. That is, one of the features of a P2MP
TE LSP is that it can be robust or protected against network
また、ネットワークの中で変化に関してスケーリングを理解しているのも重要です。 すなわち、P2MP TE LSPの特徴の1つはネットワークに対して強健であるか保護できるということです。
Yasukawa Informational [Page 23] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[23ページ]のRFC4461
failures, and it can be re-optimized to take advantage of newly
available network resources.
失敗、およびそれはそうであることができます。新たに利用するために再最適化された利用可能なネットワーク資源。
It is more important that a solution be optimized for scaling with
respect to recovery and re-optimization of the LSP than for change
in the egress LSRs, because P2MP is used as a TE tool.
解決策がLSPの回復と再最適化に関して比例するように最適化されるのは、出口LSRsの変化より重要です、P2MPがTEツールとして使用されるので。
The solution MUST follow this distinction and optimize accordingly.
解決策は、この区別に続いて、それに従って、最適化されなければなりません。
4.19. Backwards Compatibility
4.19. 遅れている互換性
It SHOULD be an aim of any P2MP solution to offer as much backward compatibility as possible. An ideal that is probably impossible to achieve would be to offer P2MP services across legacy MPLS networks without any change to any LSR in the network.
それ、SHOULD、できるだけ後方の多くの互換性を提供するどんなP2MP解決策の目的になってください。 達成するのがたぶん不可能な理想は遺産MPLSネットワークの向こう側にネットワークにおけるどんなLSRへの少しも変化なしでもサービスをP2MPに提供するだろうことです。
If this ideal cannot be achieved, the aim SHOULD be to use legacy nodes as both transit non-branch LSRs and egress LSRs.
この理想を達成できないなら、目的SHOULDはトランジット非ブランチLSRsと出口LSRsの両方として遺産ノードを使用することになっています。
It is a further requirement for the solution that any LSR that implements the solution SHALL NOT be prohibited by that act from supporting P2P TE LSPs using existing signaling mechanisms. That is, unless doing so is administratively prohibited, P2P TE LSPs MUST be supported through a P2MP network.
それは解決策のための解決策SHALL NOTを実行するどんなLSRもメカニズムに合図しながら存在を使用することでP2P TE LSPsを支持するのがその行為で禁止されているというさらなる要件です。すなわち、禁止されていて、そうするのが、行政上そうでないなら、P2MPネットワークを通してP2P TE LSPsを支持しなければなりません。
Also, it is a requirement that P2MP TE LSPs MUST be able to coexist with IP unicast and IP multicast networks.
また、それはP2MP TE LSPsがIPユニキャストとIPマルチキャストネットワークと共存できなければならないという要件です。
4.20. GMPLS
4.20. GMPLS
The requirement for P2MP services for non-packet switch interfaces is similar to that for Packet-Switch Capable (PSC) interfaces. Therefore, it is a requirement that reasonable attempts must be made to make all the features/mechanisms (and protocol extensions) that will be defined to provide MPLS P2MP TE LSPs equally applicable to P2MP PSC and non-PSC TE-LSPs. If the requirements of non-PSC networks over-complicate the PSC solution a decision may be taken to separate the solutions.
Packet-スイッチCapable(PSC)インタフェースに、非パケット交換機インタフェースのためのP2MPサービスのための要件はそれと同様です。 したがって、等しくP2MP PSCに適切なMPLS P2MP TE LSPsと非PSC TE-LSPsを提供するために定義されるのは、すべての特徴/メカニズムを作るのを合理的な試みをしなければならないという(拡大について議定書の中で述べてください)要件です。 非PSCネットワークの要件がPSC解決策を複雑にし過ぎるなら、解決策を切り離すために決定を取るかもしれません。
Solutions for MPLS P2MP TE-LSPs, when applied to GMPLS P2MP PSC or non-PSC TE-LSPs, MUST be compatible with the other features of GMPLS including:
互換性があることので、:GMPLS P2MP PSCか非PSC TE-LSPsに適用されると、MPLS P2MP TE-LSPsのためのソリューションはGMPLSの他の特徴と互換性があるに違いありません。
- control and data plane separation;
- full support of numbered and unnumbered TE links;
- use of the arbitrary labels and labels for specific technologies,
as well as negotiation of labels, where necessary, to support
limited label processing and swapping capabilities;
- コントロールとデータ修正面分離。 - 番号付の、そして、無数のTEの全面的な支援はリンクされます。 - 任意のラベルとラベルの独自技術、ラベルの交渉が必要であるところでラベル処理をサポートに制限したのと同じくらい良くてスワップしている能力の使用。
Yasukawa Informational [Page 24] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[24ページ]のRFC4461
- the ability to apply external control to the labels selected on
each hop of the LSP, and to control the next hop
label/port/interface for data after it reaches the egress LSR;
- support for graceful and alarm-free enablement and termination of
LSPs;
- full support for protection including link-level protection,
end-to-end protection, and segment protection;
- the ability to teardown an LSP from a downstream LSR, in
particular, from the egress LSR;
- handling of Graceful Deletion procedures; and
- support for failure and restart or reconnection of the control
plane without any disruption of the data plane.
- LSPの各ホップの上で選択されたラベルに外部のコントロールを適用して、それの後にデータのために次のホップラベル/ポート/インタフェースを制御する能力は出口LSRに達します。 - LSPsの優雅、そして、無アラームの権能割賦と終了のサポート。 - リンク・レベル保護、終わりから終わりへの保護、およびセグメント保護を含む保護の全面的な支援。 - 能力、出口LSRから特定の川下のLSRからの分解へのLSP。 - Graceful Deletion手順の取り扱い。 そして、--制御飛行機の失敗と再開か再接続のために、データ飛行機の少しも分裂なしで支持します。
In addition, since non-PSC TE-LSPs may have to be processed in environments where the "P2MP capability" could be limited, specific constraints may also apply during the P2MP TE Path computation. Being technology specific, these constraints are outside the scope of this document. However, technology-independent constraints (i.e., constraints that are applicable independently of the LSP class) SHOULD be allowed during P2MP TE LSP message processing. It has to be emphasized that path computation and management techniques shall be as close as possible to those being used for PSC P2P TE LSPs and P2MP TE LSPs.
さらに、また、非PSC TE-LSPsが「P2MP能力」を制限できた環境で処理されなければならないかもしれないので、特定の規制はP2MP TE Path計算の間、適用されるかもしれません。 技術特有であることで、このドキュメントの範囲の外にこれらの規制があります。 しかしながら、技術から独立している規制(すなわち、LSPのクラスの如何にかかわらず適切な規制)SHOULD、P2MP TE LSPメッセージ処理の間、許容されてください。 経路計算と管理技術ができるだけPSC P2P TE LSPsとP2MP TE LSPsに使用されるものの近くにあると強調されなければなりません。
4.21. P2MP Crankback Routing
4.21. P2MP Crankbackルート設定
P2MP solutions SHOULD support crankback requirements as defined in [CRANKBACK]. In particular, they SHOULD provide sufficient information to a branch LSR from downstream LSRs to allow the branch LSR to re-route a sub-LSP around any failures or problems in the network.
P2MP解決策SHOULDは[CRANKBACK]で定義されるようにcrankback要件を支持します。 特にそれら、SHOULDは、ブランチLSRがネットワークにおけるどんな失敗や問題の周りでもサブLSPを別ルートで送るのを許容するために十分な情報を川下のLSRsからブランチLSRに供給します。
5. Security Considerations
5. セキュリティ問題
This requirements document does not define any protocol extensions and does not, therefore, make any changes to any security models.
この要件ドキュメントは、少しのプロトコル拡大も定義しないで、またしたがって、どんな機密保護モデルへのどんな変更も行いません。
It is a requirement that any P2MP solution developed to meet some or all of the requirements expressed in this document MUST include mechanisms to enable the secure establishment and management of P2MP MPLS-TE LSPs. This includes, but is not limited to:
それは要件のいくつかかすべてに会うために見いだされたどんなP2MP解決策もP2MP MPLS-TE LSPsの安全な設立と管理を可能にするために本書ではメカニズムを含まなければならないと言い表した要件です。 含んでいますが、これは制限されません:
- mechanisms to ensure that the ingress LSR of a P2MP LSP is
identified;
- mechanisms to ensure that communicating signaling entities can
verify each other's identities;
- mechanisms to ensure that control plane messages are protected
against spoofing and tampering;
- P2MP LSPのイングレスLSRが特定されるのを保証するメカニズム。 - シグナリング実体を伝えながらそれを確実にするメカニズムは互いのアイデンティティについて確かめることができます。 - 飛行機メッセージを制御する確実にするメカニズムはだまして、いじらないように保護されます。
Yasukawa Informational [Page 25] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[25ページ]のRFC4461
- mechanisms to ensure that unauthorized leaves or branches are not
added to the P2MP LSP; and
- mechanisms to protect signaling messages from snooping.
- 権限のない葉かブランチがあるのを保証するメカニズムはP2MP LSPに加えませんでした。 そして、--詮索からメッセージを示す保護するメカニズム。
Note that P2MP signaling mechanisms built on P2P RSVP-TE signaling are likely to inherit all the security techniques and problems associated with RSVP-TE. These problems may be exacerbated in P2MP situations where security relationships may need to maintained between an ingress LSR and multiple egress LSRs. Such issues are similar to security issues for IP multicast.
P2P RSVP-TEシグナリングに造られたP2MPシグナル伝達機構がRSVP-TEに関連しているすべてのセキュリティのテクニックと問題を引き継ぎそうに注意してください。 これらの問題はセキュリティ関係がイングレスLSRと複数の出口LSRsの間で維持されていた状態で必要があるかもしれないP2MP状況で悪化させられるかもしれません。 IPマルチキャストに、そのような問題は安全保障問題と同様です。
It is a requirement that documents offering solutions for P2MP LSPs MUST have detailed security sections.
それはP2MP LSPsの解決策を提供するドキュメントがセキュリティ部について詳述したに違いないという要件です。
6. Acknowledgements
6. 承認
The authors would like to thank George Swallow, Ichiro Inoue, Dean Cheng, Lou Berger, and Eric Rosen for their review and suggestions.
作者は彼らのレビューと提案についてジョージSwallow、井上一郎、ディーン・チェン、ルウ・バーガー、およびエリック・ローゼンに感謝したがっています。
Thanks to Loa Andersson for his help resolving the final issues in this document and to Harald Alvestrand for a thorough GenArt review.
本書では最終的な問題を解決する彼のご協力のためのLoaアンデションと、そして、徹底的なGenArtのためのハラルドAlvestrandへの感謝は論評します。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[RFC2702]AwducheとD.とマルコムとJ.とAgogbuaとJ.とオデル、M.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
[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月。
7.2. Informative References
7.2. 有益な参照
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS
signaling protocols", RFC 3468, February 2003.
[RFC3468]アンデションとL.とG.Swallow、「MPLSシグナリングプロトコルのMultiprotocol Label Switching(MPLS)作業部会の決定」、RFC3468、2003年2月。
Yasukawa Informational [Page 26] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[26ページ]のRFC4461
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
[RFC3473] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support
of Differentiated Services-aware MPLS Traffic
Engineering", RFC 3564, July 2003.
[RFC3564] Le FaucheurとF.とW.レイ、「微分されたサービス意識しているMPLS交通工学のサポートのための要件」、RFC3564、2003年7月。
[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がそうするかもしれません。
[STEINER] H. Salama, et al., "Evaluation of Multicast Routing
Algorithm for Real-Time Communication on High-Speed
Networks," IEEE Journal on Selected Area in
Communications, pp.332-345, 1997.
[スタイナー] H.サラマ、他、「高速度ネットワークにおけるリアルタイムのコミュニケーションのためのマルチキャストルーティング・アルゴリズムの評価」、Communications、pp.332-345、1997年のSelected Areaの上のIEEE Journal。
[CRANKBACK] A. Farrel, A. Satyanarayana, A. Iwata, N. Fujita, G.
Ash, S. Marshall, "Crankback Signaling Extensions for
MPLS Signaling", Work in Progress, May 2005.
[CRANKBACK]A.ファレル、A.Satyanarayana、A.磐田、N.フジタ、G.灰、S.マーシャル、「MPLSシグナリングのためのCrankbackシグナリング拡張子」は進行中(2005年5月)で働いています。
[P2MP-OAM] S. Yasukawa, A. Farrel, D. King, and T. Nadeau, "OAM
Requirements for Point-to-Multipoint MPLS Networks",
Work in Progress, February 2006.
[P2MP-OAM]S.Yasukawa、A.ファレル、D.キング、およびT.ナドー、「ポイントツーマルチポイントMPLSネットワークのためのOAM要件」は進行中(2006年2月)で働いています。
Yasukawa Informational [Page 27] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[27ページ]のRFC4461
Editor's Address
エディタのアドレス
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan
Seisho Yasukawa NTT社の9-11テロ、美土里町の3丁目の武蔵野市、東京180-8585、日本
Phone: +81 422 59 4769 EMail: yasukawa.seisho@lab.ntt.co.jp
以下に電話をしてください。 +81 422 59 4769はメールされます: yasukawa.seisho@lab.ntt.co.jp
Authors' Addresses
作者のアドレス
Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルフランシスWellensplein1、B-2018アントウェルペン(ベルギー)
Phone : +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel.be
以下に電話をしてください。 +32 3 240 8491はメールされます: dimitri.papadimitriou@alcatel.be
JP Vasseur Cisco Systems, Inc. 300 Beaver Brook Road
JP VasseurシスコシステムズInc.300ビーバーブルック道路
Boxborough, MA 01719, USA
Boxborough、MA 01719、米国
EMail: jpv@cisco.com
メール: jpv@cisco.com
Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan
新宿、新宿区、Yuji Kamite NTTコミュニケーションズ株式会社オペラ市の西東京日本塔3-20-2東京163-1421
EMail: y.kamite@ntt.com
メール: y.kamite@ntt.com
Yasukawa Informational [Page 28] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[28ページ]のRFC4461
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089
Rahul Aggarwal杜松は1194の北のマチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089
EMail: rahul@juniper.net
メール: rahul@juniper.net
Alan Kullberg Motorola Computer Group 120 Turnpike Rd. Southborough, MA 01772 EMail: alan.kullberg@motorola.com
アランKullbergモトローラコンピュータグループ120Turnpike通り Southborough、MA 01772はメールされます: alan.kullberg@motorola.com
Adrian Farrel Old Dog Consulting
エードリアンのファレルの古い犬のコンサルティング
Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
以下に電話をしてください。 +44 (0) 1978 860944はメールされます: adrian@olddog.co.uk
Markus Jork Quarry Technologies 8 New England Executive Park Burlington, MA 01803
マーカスJork石切り場技術8ニューイングランド幹部社員公園バーリントン、MA 01803
EMail: mjork@quarrytech.com
メール: mjork@quarrytech.com
Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose, CA 95134
Parkwayサンノゼ、アンドリューG.Malis Tellabs2730Orchardカリフォルニア 95134
Phone: +1 408 383 7223 EMail: andy.malis@tellabs.com
以下に電話をしてください。 +1 7223年の408 383メール: andy.malis@tellabs.com
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
ジャン・ルイル・ルーフランステレコム2、大通りピアー-Marzin22307Lannion Cedexフランス
EMail: jeanlouis.leroux@francetelecom.com
メール: jeanlouis.leroux@francetelecom.com
Yasukawa Informational [Page 29] RFC 4461 Signaling Requirements for P2MP TE MPLS LSPs April 2006
Te MPLS LSPs2006年4月にP2MPのための要件に合図するYasukawaの情報[29ページ]のRFC4461
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)によって提供されます。
Yasukawa Informational [Page 30]
Yasukawa情報です。[30ページ]
一覧
スポンサーリンク
