[要約] RFC 4461は、1つの送信元から複数の受信先へパスを構築する「ポイントツーマルチポイント（P2MP）」のトラフィックエンジニアリングMPLSにおいて、パスの確立と制御に必要なシグナリング要件をまとめた文書です。マルチキャスト配信の効率化と帯域制御を両立させるための、プロトコル拡張の基盤となる要件を提示しています。
Network Working Group S. Yasukawa, Ed.
Request for Comments: 4461 NTT
Category: Informational April 2006
Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)
ポイントツーマルチポイント・トラフィックエンジニアリングMPLSラベルスイッチパス（LSP）のシグナリング要件
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）The Internet Society（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).
本書は、ポイントツーマルチポイント（P2MP）トラフィックエンジニアリング（TE）マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチパス（LSP）の確立および維持に関する一連の要件を示します。
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プロトコルが制御するパケット交換ネットワークだけでなく、Generalized MPLS（GMPLS）プロトコルが管理するLayer Two Switching（L2SC）、Time Division Multiplexing（TDM）、ラムダ、ポートスイッチングの各ネットワークにも適用されます。本書の要件を満たすために開発されるプロトコルソリューションは、MPLSとGMPLSの双方に同等に適用できるよう努める必要があります。
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. Introduction ....................................................3
1. はじめに ........................................................3
1.1. Non-Objectives .............................................6
1.1. 非目的 .....................................................6
2. Definitions .....................................................6
2. 定義 ............................................................6
2.1. Acronyms ...................................................6
2.1. 頭字語 .....................................................6
2.2. Terminology ................................................6
2.2. 用語 .......................................................6
2.2.1. Terminology for Partial LSPs ........................8
2.2.1. 部分LSPの用語 .......................................8
2.3. Conventions ................................................9
2.3. 規約 .......................................................9
3. Problem Statement ...............................................9
3. 問題文 ..........................................................9
3.1. Motivation .................................................9
3.1. モチベーション .............................................9
3.2. Requirements Overview ......................................9
3.2. 要件の概要 .................................................9
4. Detailed Requirements for P2MP TE Extensions ...................11
4. P2MP TE拡張機能の詳細な要件 ....................................11
4.1. P2MP LSP ..................................................11
4.1. P2MP LSP ..................................................11
4.2. P2MP Explicit Routing .....................................12
4.2. P2MP明示的ルーティング ....................................12
4.3. Explicit Path Loose Hops and Widely Scoped
Abstract Nodes ............................................13
4.3. 明示経路のルーズホップと広域スコープの抽象ノード ..........13
4.4. P2MP TE LSP Establishment, Teardown, and
Modification Mechanisms ...................................14
4.4. P2MP TE LSPの確立、解除、変更の機構 .......................14
4.5. Fragmentation .............................................14
4.5. 断片化 ....................................................14
4.6. Failure Reporting and Error Recovery ......................15
4.6. 障害の報告とエラー回復 ....................................15
4.7. Record Route of P2MP TE LSP ...............................16
4.7. P2MP TE LSPのレコードルート ...............................16
4.8. Call Admission Control (CAC) and QoS Control
Mechanism of P2MP TE LSPs .................................17
4.8. P2MP TE LSPの呼受付制御（CAC）とQoS制御機構 ...............17
4.9. Variation of LSP Parameters ...............................17
4.9. LSPパラメーターの変動 .....................................17
4.10. Re-Optimization of P2MP TE LSPs ..........................18
4.10. P2MP TE LSPの再最適化 ....................................18
4.11. Merging of Tree Branches .................................18
4.11. 木の枝のマージ ...........................................18
4.12. Data Duplication .........................................19
4.12. データの複製 .............................................19
4.13. IPv4/IPv6 Support ........................................20
4.13. IPv4/IPv6サポート ........................................20
4.14. P2MP MPLS Label ..........................................20
4.14. P2MP MPLSラベル ..........................................20
4.15. Advertisement of P2MP Capability .........................20
4.15. P2MP機能の広告 ...........................................20
4.16. Multi-Access LANs ........................................21
4.16. マルチアクセスラン .......................................21
4.17. P2MP MPLS OAM ............................................21
4.17. P2MP MPLS OAM ............................................21
4.18. Scalability ..............................................21
4.18. スケーラビリティ .........................................21
4.18.1. Absolute Limits ..................................22
4.18.1. 絶対制限 .........................................22
4.19. Backwards Compatibility ..................................24
4.19. 後方互換性 ...............................................24
4.20. GMPLS ....................................................24
4.20. gmpls ....................................................24
4.21. P2MP Crankback Routing ...................................25
4.21. P2MPクランクバックルーティング ...........................25
5. Security Considerations ........................................25
5. セキュリティに関する考慮事項 ...................................25
6. Acknowledgements ...............................................26
6. 謝辞 ...........................................................26
7. References .....................................................26
7. 参考文献 .......................................................26
7.1. Normative References ......................................26
7.1. 引用文献 ..................................................26
7.2. Informative References ....................................26
7.2. Informative References ....................................26
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）LSPに限定されます。トラフィックエンジニアリングLSPを使用して、Point-to-Multipoint（P2MP）サービスをサポートしたいという願望があります。これは、P2MP MPLS-TE LSPをサポートするために、ベース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は、[RFC2702]および[RFC3031]で定義されるTE LSPであり、単一のイングレスLSRと1つ以上のイグレスLSRを持つ単方向のLSPです。P2MPサービス（単一の送信元から1つ以上の受信先へデータを届けるサービス）は、ネットワーク内で必要とされる最適化の度合いに応じて、P2P LSPとP2MP LSPの任意の組み合わせでサポートできます。また、ネットワークの要件に応じて、それらのLSPをトラフィックエンジニアリングすることもできます。さらに、マルチポイントツーマルチポイント（MP2MP）サービス（複数の送信元から1つ以上の受信先へデータを届けるサービス）も、P2P LSPとP2MP LSPの組み合わせでサポートできます。
[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. LSPは効率よく維持できる可能性があります。 3. トラフィックトランクを生成し、LSPに対応付けられます。 4. トラフィックトランクに、その動作特性を調整する一連の属性を関連付けられます。 5. LSPやトラフィックトランクの配置を制約する一連の属性をリソースに関連付けられます。 6. MPLSではトラフィックの集約と分散の両方が可能ですが、従来の宛先ベースのみのIP転送で可能なのは集約だけです。 7. MPLSには「制約ベースルーティング」の枠組みを比較的容易に統合できます。 8. MPLSを適切に実装すれば、トラフィックエンジニアリングの他の方式に比べて大幅に低いオーバーヘッドを実現できます。
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 LSPによってサポートされている（またはマッピングされた）ことを意味することに注意してください。
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.
使用する明示経路は、さまざまな制約に基づくアルゴリズムで計算し、多様な形状のツリーを作成できます。たとえば、明示経路はコスト最小化に基づくもの（[STEINER]）、最短経路、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.
このドキュメントでは、マルチプロトコルラベルスイッチング（MPLS）へのポイントツーマルチポイント（P2MP）トラフィックエンジニアリング（TE）拡張の要件を提示します。P2MP TE LSPを提供するためのソリューションの機能要件を指定します。
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セットアップの手順を指定するソリューションは、これらの要件を満たさなければなりません (MUST)。このドキュメントで、ソリューション固有の詳細またはアプリケーション固有の要件を指定する意図はありません。
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の双方に同等に適用できるよう努めなければなりません (MUST)。
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 LSPをサポートしないため、新たな機構を開発する必要があります。その際は、既存のMPLSプロトコルを最大限再利用して実現すべきです (SHOULD)。
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のパスは、トラフィックエンジニアリングデータベース（TED）で制約ベースの計算（CSPFなど）を実行することにより決定されます。TEDの内容は、さまざまなメカニズムを通じて収集される場合があります。
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 LSPを確立および維持するための要件に焦点を当てています。ルーティングプロトコルは範囲外です。P2MP LSPのパス計算の基礎として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制約に従って設定され、ネットワーク内の各分岐点でパケットまたはデータを効率的に複製できます。複製自体はデータプレーンの処理ですが、効率的に複製できるようにネットワークへLSPを設定する責任は、経路計算機能と連携する制御プレーンにあります。「効率的」な複製の意味は相対的であり、目的によって異なる点に注意してください（第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にイグレスLSRを追加または削除して変更します。P2MP TE LSPはTEアプリケーションに使われるため、P2MP LSPのリーフが変化する頻度（新たなイグレスLSRの参加や既存イグレスLSRの離脱の頻度）は「それほど高くない」と想定します。この点は第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 P2MP TE LSPの属性（帯域幅など）は、データトラフィックに影響を与えずにP2MPサービスの属性変更に対応するため、make-before-breakなどの機構で変更される場合があります。この点は第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.
Ingress 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機能をスケーラブルな方法で運用しなければならない (MUST) ということです。
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が把握しているものとします。たとえば、イングレスLSRはP2MP TE LSPのイグレスLSRを識別する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を用いないLSP（ホップ単位またはルーティングベースのLSPなど）。 - P2MP LSPのイグレスリーフの検出。 - 階層型P2MP LSP。 - P2MP LSPのOAM。 - エリア間およびAS間のP2MP TE LSP。 - P2MP MPLS TE LSPをサービスシナリオに適用する方法。 - 特定のアプリケーションやアプリケーション要件。 - P2MP配信ツリーを計算するアルゴリズム。 - マルチポイントツーポイントLSP。 - マルチポイントツーマルチポイントLSP。 - ルーティングプロトコル。 - トラフィックエンジニアリングデータベースの構築。 - トラフィックエンジニアリングデータベースの構築に用いる情報の配布。
P2P: Point-to-point
P2P: ポイントツーポイント
P2MP: Point-to-multipoint
P2MP: ポイントツーマルチポイント
The following terms are defined for use in the context of P2MP TE LSPs only.
次の用語は、P2MP TE LSPのみのコンテキストで使用するために定義されています。
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からすべてのイグレスLSRに至るP2MP TE LSPの経路を構成する、LSRとTEリンクの順序付き集合です。
ingress LSR:
Ingress 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つです。イグレスLSRはリーフノードまたはリーフとも呼ばれます。
bud LSR:
バッドLSR：
An LSR that is an egress LSR, but also has one or more directly connected downstream LSRs.
出口LSRであるが、1つ以上の直接接続された下流LSRもあるLSR。
branch LSR:
ブランチLSR：
An LSR that has more than one directly connected downstream LSR.
2つ以上の直接接続された下流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.
枝や葉の数に関係なく、LSP全体で一定のP2MP TE 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とは限りません。特定のイグレスLSRを介して、受信先が0個、1個、または複数個のデータを受信する場合があります。
It is convenient to sub-divide P2MP trees for functional and representational reasons. A tree may be divided in two dimensions:
機能的および表現的な理由から、P2MPツリーを下位にすると便利です。ツリーは2次元で分割される場合があります。
- 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.
- ツリーの長さに沿って分割できます。たとえば、イングレスLSRからそれぞれ異なるイグレスLSR群へ至る2つの部分に分割できます。上流LSR（イングレス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（または任意のトランジットLSR）でツリーを分割し、その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 リーフ（イグレス）LSR - L 分岐LSR - B トランジットLSR - X（送信元、リーフ、分岐のいずれでもない任意の単一LSR） すべて - A 一部（すべてではない） - 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のLSRの1つから他のLSRの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 Sub-LSP：ソースから葉のセットへのパス。
B2AL sub-LSP: The path from a branch LSR to all downstream leaves.
B2ALサブLSP：ブランチLSRからすべての下流の葉へのパス。
X2X sub-LSP: A component of the P2MP LSP that is a simple path that does not branch.
x2x sub-lsp：分岐しない単純なパスであるP2MP LSPのコンポーネント。
Note that the S2AL sub-LSP is equivalent to the P2MP LSP.
S2ALサブLSPはP2MP LSPと同等であることに注意してください。
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"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、[RFC2119] で説明されているように解釈されるものとします。
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節で述べたように、トラフィックエンジニアリングと制約ベースルーティング（コール受付制御（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.
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サービスを十分に効率よく提供するには、具体的な要件を規定する必要があります。この要件は、既存プロトコルの利用、既存プロトコルの拡張、または新しいプロトコルのための機構を定義する際に活用できます。
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 LSPを設定するための基本要件を示します。要件が適用されるのはシグナリング方式だけです。ネットワーク内で使われるルーティングプロトコルや、トラフィックエンジニアリングデータベース（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 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.
P2MP TE LSPパス計算では、帯域幅、親和性、必要なレベルの保護などのさまざまな制約が考慮されます。ソリューションは、遅延、ネットワーク内の帯域幅消費、その他の組み合わせなどのさまざまな最適化基準をサポートする目的で、制約を満たすP2MP TE LSPパスの計算を可能にしなければなりません (MUST)。これには、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のマルチプロトコルラベルスイッチング（MPLS）ワーキンググループは、トラフィックエンジニアリングアプリケーション用MPLSシグナリングプロトコルとして「Resource Reservation Protocol（RSVP）-TE: Extensions to RSVP for Label-Switched Paths（LSP）Tunnels」（RFC 3209）に取り組みを集中させることで合意した…
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にイグレスLSRを追加または削除する機能を備えなければならず (MUST)、P2P TE LSP向けにすでに定義されているすべてのTE LSP管理手順をサポートしなければなりません (MUST)。さらに、P2P TE LSP向けに新しい手順を開発する場合は、P2MP TE LSP向けにも同等または同一の手順を開発すべきです (SHOULD)。
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
Figure 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は、1つのイングレスLSR（I-LSR1）と4つのイグレスLSR（E-LSR2、E-LSR3、E-LSR4、E-LSR5）を示します。I-LSR1は、P2MPアプリケーション用のトラフィックを生成する送信元に接続されています。
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.
一般的な制約には、帯域幅要件、リソースクラスのアフィニティ、高速再ルーティング、プリエンプションがあります。P2P TE LSP向けにすでに定義されている制約群をサポートできる可能性を制限すべきではありません。LSRの機能やネットワーク上の制約を考慮するため、P2MP LSPの分岐LSRとして使用するLSRを新たな制約で指定する場合があります。
b) A P2MP TE LSP is set up from I-LSR1 to E-LSR2, E-LSR3, and E-LSR4 using the tree information.
b) ツリー情報を使い、I-LSR1からE-LSR2、E-LSR3、E-LSR4へP2MP TE LSPを設定します。
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へのB2LサブLSPをP2MP TE LSPに追加します。これによりLSR2は分岐LSRになります。
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拡張は、異なるスイッチング方式のLSPシグナリングに適用できなければなりません (MUST)。たとえば、パケット方式か非パケット方式か（フレーム、セル、TDM、ラムダなど）を問わず、あらゆるスイッチング媒体でP2MP TE LSPをシグナリングできなければなりません (MUST)。
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ツリーを通らなければなりません (MUST)。
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.
多数の分岐にスケーリングするには、ブランチや葉の数に関係なく、LSP全体で一定の一意の識別子（P2MP IDまたはP2ID）によってP2MP TE LSPを識別すべきです (SHOULD)。
Various optimizations in P2MP tree formation need to be applied to meet various QoS requirements and operational constraints.
さまざまなQoS要件や運用上の制約を満たすため、P2MPツリーの形成には各種の最適化が必要です。
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ツリーを要求する場合があります。また、一部のオペレーターは、ブランチLSRを明示的に指定することにより、コスト最小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.
したがって、P2MP TEソリューションは、外部ツリー計算プロセス、経路設定プロセス、またはイングレスLSR上の動的ツリー計算プロセスの制御下で、任意のP2MPツリーを確立する手段を提供しなければなりません (MUST)。図2に典型例を2つ示します。
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
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.
例の1つは、Steiner P2MPツリー（コスト最小P2MPツリー）[STEINER]です。このツリーは、コアネットワーク内の帯域幅消費を最小限に抑えるコスト最小ツリーの構築に適しています。このツリーを実現するには、複数の中間LSRがMPLSデータを終端するLSRとトランジットLSRの両方を兼ねる必要があります（図2のLSR E、F、G、H、I、J、K）。したがって、P2MP TEソリューションは、イングレスLSRとイグレスLSRの間にこの種のbud LSRを設定する機構をサポートしなければなりません (MUST)。これには、送信元から各受信先までの遅延上限など、他の制約を満たしながら最小コストツリーを計算する制約付きSteinerツリーも含まれます。
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.
もう1つの例は、制約付き最短経路優先（CSPF）によるP2MPツリーです。遅延や帯域幅、またはそれらの組み合わせなど、任意の基準に基づいて最短経路のP2MPツリーを計算できます。このツリーはリアルタイムトラフィックの伝送に適しています。
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.
ソリューションは、オペレーターが任意のツリー計算手法を利用できるようにしなければなりません (MUST)。前者の場合、効率的または最適なツリーは最小コストツリー（Steinerツリー）です。後者の場合は、送信元から各受信先までの最短経路を提供するツリーです。
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.
妥当な形状のP2MPツリーを任意に明示設定できるよう、P2MP TEソリューションは、特定のLSRを分岐LSRとして明示的に含められる、送信元によるツリー制御機構をサポートしなければなりません (MUST)。イングレスLSRはこの機構を使ってP2MP TE LSPを設定できます。たとえば、P2MP TE LSPをツリー全体として、または個々の分岐として表現できます。
A P2MP tree is completely specified if all the required branches and hops between a sender and leaf LSR are indicated.
送信元からリーフLSRまでの必要な分岐とホップがすべて示されている場合、P2MPツリーは完全に指定されています。
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.
中間の分岐やホップの一部だけが示されている場合、P2MPツリーは部分的に指定されています。明示経路のルーズホップや、32ビット未満のIPv4プレフィックス、AS番号など、広い範囲を表す抽象ノード（[RFC3209]における単純な抽象ノードではないもの）を使って部分指定できます。部分指定されたP2MPツリーは、エリア間やAS間で特に有用な場合があります。ただし、それらの環境におけるP2MPの要件は本書の対象外です。
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.
前節で定義したP2MPツリーの送信元制御機構では、プロトコルソリューションがルーズホップと広域スコープの抽象ノードを指定する方法を含めるべきです (SHOULD)。この機能を提供する場合、下流LSRがさらに明示的な制御をP2MPツリーに適用し、部分指定されたツリーをより完全に指定されたツリーにできるようにしなければなりません (MUST)。
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.
完全なツリーを計算するための十分な情報がイングレスLSRにあり、経路上のポリシー（ドメイン境界など）が完全指定を許す場合、プロトコルソリューションはイングレスLSRでP2MPツリー全体を指定できなければなりません (MUST)。
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.
いずれの場合も、P2MP TE LSPのイグレスLSRは個別に、または共通の識別子を使って完全に指定する必要があります。この情報がなければ、TE LSPの経路先を決定できません。
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).
下流LSRがツリーを計算する場合（たとえば、ホップをルーズホップとして指定した場合）、ソリューションはP2MP TE LSPのイングレスLSRがP2MPツリー全体を把握するためのプロトコル機構を提供しなければなりません (MUST)。ポリシー上の理由でこの情報を常に取得できるとは限りませんが、経路の一部を機密にする場合は、集約した形（たとえばAS番号）で報告しなければなりません (MUST)。
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.
P2MP TEソリューションは、少なくとも線形にスケールする方法でP2MP TE LSPの確立、維持、解除をサポートしなければなりません (MUST)。これは、多数のLSPが同時に存在する場合と、1つのP2MP LSPに多数の宛先が存在する場合の両方に対応しなければなりません (MUST)。
In addition to P2MP TE LSP establishment and teardown mechanisms, the solution SHOULD support a partial P2MP tree modification mechanism.
確立および解除の機構に加えて、ソリューションはP2MPツリーの一部を変更する機構をサポートすべきです (SHOULD)。
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.
既存のP2MP TE LSPにサブP2MP TE LSPを追加するため、拡張はgrafting（枝の追加）機構をサポートすべきです (SHOULD)。既存のP2MP TE LSPからサブP2MP TE LSPを削除するため、pruning（枝の削除）機構をサポートすべきです (SHOULD)。
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.
grafting（枝の追加）およびpruning（枝の削除）の処理では、追加・削除対象ノードへの経路上にないノードや、追加・削除対象ノードから対象リーフまでの下流にあるノードで追加処理を発生させないことが望ましいです (SHOULD)。また、いずれの処理も、P2MPツリー上で現在転送中のトラフィックを中断してはなりません (MUST NOT)。
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.
枝の追加や削除が何度か行われた後も、明示経路で設定されたP2MP LSPが最適な経路を維持するとは限りません。ここでいうスケーラビリティはP2MP TE LSPのシグナリング処理を指します。LSPがTE LSPであるため、LSPを最適な状態に戻す再最適化を適宜行えます。
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.
単一のプロトコルメッセージにP2MP LSPの確立に必要な情報をすべて含められない場合に、P2MP TEソリューションは対処できなければなりません (MUST)。そのような場合でもLSPを確立できなければなりません (MUST)。
This situation may arise in either of the following circumstances.
この状況は、次のいずれかの場合に発生します。
a. The ingress LSR cannot signal the whole tree in a single message.
a. イングレスLSRが1つのメッセージでツリー全体をシグナリングできません。
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 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.
これらの問題を解決するためにプロトコルメッセージのIP断片化に依存すべきではありません (SHOULD NOT)。また、シグナリングソリューション固有のプロトコル手順に依存することが推奨されます (SHOULD)。
In the event that fragmented IP packets containing protocol messages are received, it is NOT RECOMMENDED that they are reassembled at the receiving LSR.
プロトコルメッセージを含むIP断片を受信した場合、受信側LSRで再構成することは推奨されません (SHOULD NOT)。
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.
障害によって、イグレスLSRまたはサブP2MP LSPがP2MP TE LSPから切り離される場合があります。そのような事象は、P2P LSPの場合と同様に上流へ報告しなければなりません (MUST)。
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.
ソリューションは、影響を受けたサブP2MP TE LSPを復旧できるよう、保護や回復などの復旧技術を提供すべきです (SHOULD)。特に、P2P TE LSP向けの[RFC4090]に記載された方式と同様の高速保護機構をP2MP TE LSP向けに提供しなければなりません (MUST)。P2MP TE LSPのバックアップ経路をP2P TE LSPのバックアップ経路と共有するかどうかについて、前提は設けません。
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.
本書の要件はすべてのMPLS TE P2MPシグナリングに共通する一般要件であり、これを満たすソリューションも汎用的なものになります。特定のアプリケーションには追加要件がある場合や、本書の要件の一部を緩和したい場合があります。その結果、ソリューションに違いが生じることがあります。
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.
ソリューションは、帯域幅保護や、障害時にバックアップ経路上で増加する伝搬遅延の上限設定など、他のネットワーク復旧要件を満たす機能もサポートすべきです (SHOULD)。
A P2MP TE solution MUST support the P2MP fast protection mechanism to handle P2MP applications sensitive to traffic disruption.
P2MP TEソリューションは、トラフィックの混乱に敏感なP2MPアプリケーションを処理するために、P2MP高速保護メカニズムをサポートしなければなりません (MUST)。
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.
すべてのイグレスLSRのうち一部への配送障害がイングレスLSRに通知されても、それを理由にP2MP TE LSPを自動解除すべきではありません (SHOULD NOT)。一部のイグレスLSRがP2MPツリーに接続されたままである場合にP2MP LSPを維持するかどうかは、イングレスLSRのローカルポリシーで決めるべきです (SHOULD)。
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.
分岐LSRの下流にあるすべてのイグレスLSRがP2MPツリーから切断され、分岐LSRが回復機構や保護機構によっていずれのイグレスLSRとの接続も回復できない場合、その分岐LSR自身がイグレスLSR（すなわちbud）でもなければ、P2MPツリーから離脱してもかまいません (MAY)。下流の各イグレスLSRを切断した障害はそれぞれ異なる可能性があるため、分岐LSRはそのようなエラーをすべて上流隣接LSRに報告しなければなりません (MUST)。その後、上流LSRまたはイングレスLSRが、障害箇所を迂回するよう該当するイグレスLSRへの経路を再計算できます。
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.
ソリューションには、トランジットLSR、とりわけ分岐LSRが障害後にサブP2MPツリーを再計算して復旧させる機能が含まれてもかまいません (MAY)。修復に成功した場合、エラー通知は上流ノードへ報告すべきではありません (SHOULD NOT)。ただし、経路記録を使用している場合は新しい経路を報告します。クランクバック要件については第4.21節で説明します。
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.
管理や、Fast Reroute [RFC4090]などの局所復旧機構の運用では、確立されたP2MP TE LSPのトポロジを把握することが重要です。ネットワークオペレーターは、この情報を使ってP2MP TE LSPを管理します。
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.
したがって、P2MP TEソリューションは、P2MP LSPの確立や変更の後にP2MPツリーのトポロジ情報を収集し、更新する機構をサポートしなければなりません (MUST)。
It is RECOMMENDED that the information is collected in a data format that allows easy recognition of the P2MP tree topology.
P2MPツリーのトポロジを容易に認識できるデータ形式で情報を収集することが推奨されます (SHOULD)。
The solution MUST support mechanisms for the recording of both outgoing interfaces and node-ids.
ソリューションは、送出インターフェイスとノードIDの両方を記録する機構をサポートしなければなりません (MUST)。
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.
ソリューションは、収集した情報が1つのプロトコルメッセージに収まらない場合を含め、P2MPツリー情報の収集に伴うスケーラビリティの問題に適切に対処しなければなりません (MUST)。
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 LSPはP2P TE LSPとネットワークリソースを共有する場合があります。そのため、運用を容易にし、スケーラブルにするには、P2P TE LSPの場合と同様にCACとQoSを扱うことが重要です。
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ソリューションは、同じ宛先に向かう他のLSPとの共存を容易にするため、リソース共有とリソースの排他的利用の両方をサポートしなければなりません (MUST)。
P2MP TE solutions MUST be applicable to DiffServ-enabled networks that can provide consistent QoS control in P2MP LSP traffic.
P2MP TEソリューションは、P2MP LSPのトラフィックに一貫したQoS制御を提供できるDiffServ対応ネットワークに適用できなければなりません (MUST)。
Any solution SHOULD also satisfy the DS-TE requirements [RFC3564] and interoperate smoothly with current P2P DS-TE protocol specifications.
ソリューションはDS-TE要件[RFC3564]も満たし、現行のP2P DS-TEプロトコル仕様と円滑に相互運用できることが望ましいです (SHOULD)。
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.
本要件文書は、P2MP TE LSPに使用する帯域幅プールの種類について前提を設けません。帯域幅プールはP2P TE LSPと共有することも、P2MP専用にすることもできます。
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.
優先度や帯域幅などのパラメーターがLSPに関連付けられます。これらのパラメーターは、LSPの確立や維持に伴うシグナリングのやり取りによって設定されます。
Any solution MUST NOT allow for variance of these parameters within a single P2MP LSP. That is:
いかなるソリューションでも、単一のP2MP LSP内のこれらのパラメーターの分散を許可してはなりません (MUST NOT)。あれは：
- 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.
- P2MP LSPのイングレスLSRが設定してシグナリングした属性は、下流LSRが変更できません。 - 単一のP2MP LSPでは、ルートからすべてのリーフまで均一なQoSを提供しなければなりません (MUST)。
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.
ツリー全体のパラメーターを変更するとサポートされる場合があります (MAY)が、変化はイングレスLSRからすべての出力LSRまでツリー全体に適用しなければなりません (MUST)。
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.
より最適な経路（たとえば、総コストの低い経路）が見つかると、P2MP TE LSPの再ルーティングが必要になる場合があります。再ルーティング中に重要なのは、リソース共有を利用して旧LSPと新LSPの共通部分で帯域幅を二重に予約しないことです。
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.
P2MP TE LSPを再ルーティングする際のトラフィック中断を最小限に抑えるため、make-before-break方式をサポートしなければなりません (MUST)。
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.
P2MPツリーの他の部分のデータ転送に影響を与えずに、サブP2MPツリーだけを対象とするmake-before-breakをサポートしなければなりません (MUST)。
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.
ソリューションは、P2MP LSPの任意の部分（S2PLサブLSP、S2XサブLSP、S2LサブLSP、X2ALサブLSP、B2PLサブLSP、X2ALサブLSP、またはB2ALツリー）をmake-before-breakで再最適化できるようにすべきです (SHOULD)。また、P2MP LSPの他の部分へのシグナリングの影響を最小限に抑え、管理プレーンによるLSP管理機能に影響を与えずに実現すべきです (SHOULD)。
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.
また、ソリューションは、イングレスLSRが再最適化プロセスを厳密に制御できるようにすべきです (SHOULD)。イングレスLSRは、再最適化をすべて送信元起動に限定できるべきです (SHOULD)。
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.
イングレスLSRがサブLSPの再最適化を許可している場合、再最適化対象のサブLSPの起点である下流LSRがそれを開始してもかまいません (MAY)。下流LSRが開始するサブLSPの再最適化でも、前述の他の再最適化と同じく、稼働中のトラフィックへの影響を最小限に抑えなければなりません (MUST)。
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.
単一のトランジットLSRは、同じP2MP LSPであるが、異なる宛先セットに対して複数のシグナリングメッセージを受信する可能性があります。これらのメッセージは、同じまたは異なる上流ノードから受信される場合があり、同じまたは異なる下流ノードに渡す必要がある場合があります。
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).
この状況は、シグナリングソリューションの仕様や、そのソリューション内の実装方式によって生じる場合があります。また、make-before-breakによる再最適化（第4.10節）の際にも起こり得ます。
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).
GMPLSが管理する特定のスイッチング技術では、適切なラベルを選択するために上流側で別々の分岐を構成する必要が生じる場合もあります。たとえば、下流分岐で使用するラムダを選択できるのが別々の上流スイッチに限られるフォトニッククロスコネクトが該当します。
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.
ソリューションは、同じP2MP LSPの複数のシグナル伝達メッセージが単一のトランジットLSRで受信され、同じ上流インターフェイスを参照する場合をサポートしなければなりません (MUST)。この場合、プロトコル手順の結果は、上流インターフェイスの単一のデータフローであるべきです (SHOULD)。
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.
ソリューションは、同じP2MP LSPの複数のシグナル伝達メッセージが単一のトランジットLSRで受信され、異なる上流インターフェイスを参照する場合、および各シグナリングメッセージの結果、異なる下流インターフェイスの使用が得られる場合をサポートすべきです (SHOULD)。このケースは、LSRで横断するが合併しないデータフローを表しています。
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.
このソリューションは、同じP2MP LSPの複数のシグナル伝達メッセージが単一のトランジットLSRで受信され、異なる上流インターフェイスを参照し、下流のインターフェイスが受信シグナリングメッセージ間で共有される場合をサポートする場合があります (MAY)。このケースは、データフローのマージを表しています。このケースをサポートするソリューションは、データがダウンストリームインターフェイスで複製されないようにしなければなりません (MUST)。
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.
このケースをサポートする代わりに、シグナリングプロトコルがエラーを通知し、上流LSRがマージを解決できるようにしてもかまいません。
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.
非パケット環境では、信号の一部が複製され、その結果としてデータが重複したり、データが乱れたりすることをデータ複製と呼びます。
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.
前節で述べた稼働中LSPの再最適化やLSP保護など、さまざまな状況で正当にデータ複製が発生する場合があります。そのため、本書でデータ複製を一律に禁止するのは現実的ではありません。
Instead, the solution:
その代わり、ソリューションには次の要件を課します。
- SHOULD limit to bounded transitory conditions the cases where network bandwidth is wasted by the existence of duplicate delivery paths.
- 重複する配送経路によってネットワーク帯域幅が浪費される状態を、限定された一時的な場合に抑えるべきです (SHOULD)。
- MUST limit the cases where duplicate data is delivered to an application to bounded transitory conditions.
- アプリケーションに重複データが配送される状態を、限定された一時的な場合に抑えなければなりません (MUST)。
Any P2MP TE solution MUST support IPv4 and IPv6 addressing.
P2MP TEソリューションはIPv4およびIPv6のアドレス方式をサポートしなければなりません (MUST)。
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.
P2MP TEソリューションは、同じネットワーク内でP2P LSP（TE LSPを含む）を確立する既存の手法を引き続き利用できるようにしなければならず (MUST)、P2MP TE LSPとP2P LSPが同じネットワーク内で共存できるようにしなければなりません (MUST)。
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.
P2MP TEソリューションは、P2MP LSPとP2P TE LSPを同じインターフェイス上でシグナリングできるように仕様化しなければなりません (MUST)。
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.
P2MPネットワーク内のLSRの機能を決定するために、いくつかの高レベルの要件が特定されています。このような情報の目的は、P2MPシグナル伝達とデータ転送に関してすべてが同じ機能レベルを持っているわけではないLSRを含むネットワーク内のTE制約を使用して、P2MPツリーの計算を促進することです。
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.
- LSRが分岐をサポートする能力。 - LSRが同一LSPのイグレスLSRと分岐LSRを兼ねる能力。 - LSRがP2MP MPLS-TEシグナリングをサポートする能力。
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は、イーサネットなどのマルチアクセス媒体で構成されるネットワークセグメントを通過するために使われる場合があります。この場合、ネットワークセグメントへの入口がP2MP LSPの分岐LSRになることもあります。
Two options clearly exist:
2つのオプションが明らかに存在します：
- 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.
- 分岐LSRがデータを複製し、複数のコピーをセグメントへ送信します。 - 分岐LSRがデータのコピーを1つだけセグメントへ送信し、受信して転送するかどうかは各出口ノードに判断を委ねます。
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.
1つ目の方式にはデータプレーンの大きなスケーラビリティ上の問題があります。複製したデータをすべて同一ポートから送信し、同じセグメントに載せる必要があるためです。したがって、分岐LSRがデータのコピーを1つだけマルチアクセスネットワークへ送信し、隣接する複数の下流ノードへ届ける機構をソリューションは提供すべきです (SHOULD)。2つ目の方式では制御プレーンのスケーラビリティに問題が生じる場合があります。
The MPLS and GMPLS MIB modules MUST be enhanced to provide P2MP TE LSP management in line with whatever signaling solutions are developed.
MPLSおよびGMPLSのMIBモジュールは、開発されるシグナリングソリューションに沿ってP2MP TE LSPを管理できるよう拡張しなければなりません (MUST)。
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.
適切に管理できるよう、P2MP TE LSPには一意の識別子を付与しなければなりません (MUST)。そうでなければ、どのLSPを管理しているか特定できません。
Further discussions of OAM are out of scope for this document. See [P2MP-OAM] for more details.
OAMについての詳細な議論は本書の対象外です。詳細は[P2MP-OAM]を参照してください。
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:
スケーラビリティはP2MP MPLSシステムの重要な要件です。ソリューションは、次のいずれかの数が増えても適切にスケールするよう設計しなければなりません (MUST)。
- the number of recipients - the number of egress LSRs - the number of branch LSRs - the number of branches
- 受信先の数 - イグレスLSRの数 - 分岐LSRの数 - 分岐の数
Both scalability of control plane operation (setup, maintenance, modification, and teardown) MUST be considered.
制御プレーン動作（設定、維持、変更、解除）のスケーラビリティも考慮しなければなりません (MUST)。
Key considerations MUST include:
重要な考慮事項を含めなければなりません (MUST)。
- 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.
- P2MP TE LSPの維持に伴うリフレッシュ処理の量。 - P2MPツリー上のイングレスLSRとトランジットLSRが維持するプロトコル状態の量。 - イグレスLSR数に応じて、P2MP LSPの設定または解除に必要となるプロトコルメッセージ数。 - 障害後のP2MP LSPの修復やmake-before-breakに必要となるプロトコルメッセージ数。 - P2MP TE LSPの管理に送信するプロトコル情報の量（メッセージサイズ）。 - ルーティング拡張で追加配布されるデータの量。 - 新しい分岐の追加・削除が必要かどうかを検出するためにネットワークで必要となる追加の制御プレーン処理量。特に、追加・削除要求がない定常状態での処理量。 - 既存のP2MP LSPにブランチLSPを追加・削除するために、イングレス、トランジット、イグレスLSRで必要となる制御プレーン処理量。
It is expected that the applicability of each solution will be evaluated with regards to the aforementioned scalability criteria.
各ソリューションの適用性は、前述のスケーラビリティ基準に照らして評価されることが想定されています。
In order to achieve the best solution for the problem space, it is helpful to clarify the boundaries for P2MP TE LSPs.
問題空間に最適なソリューションを実現するために、P2MP TE LSPの境界を明確にすることが役立ちます。
- Number of egress LSRs.
- 出力LSRの数。
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.
ソリューションの機構は、イグレスLSRが1台に減った場合、P2MP TE LSPがP2P LSPと同等のスケーラビリティになるようにしなければなりません (MUST)。すなわち、イグレスLSRが1台のP2MP TE LSPを確立するコストは、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.
トラフィックエンジニアリングの観点からスケーリングの問題を分類することが重要です。P2MP TE LSPの初期導入ではイグレスLSR数は最大でも約100台と予想されますが、5年以内には数百台に増え、将来の導入ではさらに大きな数が必要になる可能性があります。
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.
したがって、許容可能なソリューションの上限は、イグレスLSR数に対して線形にスケールすることです。ソリューションは線形を上回るスケーラビリティを実現すると期待されます。
Solutions that scale worse than linearly (that is, exponentially or polynomially) are not acceptable whatever the number of egress LSRs they could support.
線形（つまり、指数関数的または多項式的に）よりも悪いスケーリングは、サポートできる出力LSRの数が何であれ、受け入れられません。
- Number of branch LSRs.
- ブランチLSRの数。
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.
ソリューションは、1台の分岐LSRから各リーフへそれぞれ枝分かれする構成から、イグレスLSRがn台のとき分岐LSRが最大n-1台となる構成まで、あらゆるトポロジをサポートしなければなりません (MUST)。どのトポロジが一般的かについて前提を置いてはなりません (MUST NOT)。また、すべてのトポロジでスケーラビリティを確保できるよう設計しなければなりません (MUST)。
- 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.
どの出力LSRをLSPに追加するかを決定するためのメカニズムと、そのグループからの出力LSRを追加および除去するためのメカニズムは、このドキュメントの範囲外であることを思い出してください。それにもかかわらず、これがソリューション技術の選択に影響を与える可能性があるため、出力LSRの到着と出発の予想率を理解することは有用です。
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出力LSRの変化率は、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.
ソリューションのスケーラビリティを判断するうえでは、参加・離脱するイグレスLSRの絶対数が重要です。割合のほうが把握しやすい場合もありますが、受信先が少ないLSPでは割合はそれほど重要ではありません。
A working figure for an established P2MP TE LSP is less than 10% churn per day; that is, a relatively slow rate of churn.
確立済みのP2MP TE LSPについては、変化率の目安を1日あたり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.
ソリューションは、このような比較的低い変化率に合わせて最適化しなければなりません (MUST)。大幅に高い変化率に合わせて最適化する必要はありません。
- 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 failures, and it can be re-optimized to take advantage of newly available network resources.
ネットワーク内の変化に対するスケーラビリティを把握することも重要です。P2MP TE LSPは、ネットワーク障害に対する堅牢性や保護を備え、新たに利用可能になったネットワークリソースを活用するために再最適化できます。
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.
P2MPはTEツールとして使用されるため、出口LSRの変化よりもLSPの回復と再最適化に関するスケーリングのためにソリューションを最適化することがより重要です。
The solution MUST follow this distinction and optimize accordingly.
ソリューションはこの区別に従い、それに応じて最適化しなければなりません (MUST)。
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.
可能な限り高い後方互換性を実現することを、P2MPソリューションの目標とすべきです (SHOULD)。ネットワーク内のLSRを一切変更せずにレガシーMPLSネットワーク全体でP2MPサービスを提供できれば理想的ですが、おそらく実現できません。
If this ideal cannot be achieved, the aim SHOULD be to use legacy nodes as both transit non-branch LSRs and egress LSRs.
この理想を実現できない場合は、レガシーノードを非分岐トランジットLSRおよびイグレスLSRとして利用することを目標とすべきです (SHOULD)。
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.
ソリューションを実装するLSRであっても、そのことを理由に、既存のシグナリング機構によるP2P TE LSPのサポートを禁止してはなりません (MUST NOT)。つまり、管理上禁止されている場合を除き、P2MPネットワークを通じてP2P TE LSPをサポートしなければなりません (MUST)。
Also, it is a requirement that P2MP TE LSPs MUST be able to coexist with IP unicast and IP multicast networks.
また、P2MP TE LSPがIPユニキャストおよびIPマルチキャストのネットワークと共存できなければならない (MUST) ことも要件です。
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.
非パケットスイッチインターフェイス向けP2MPサービスの要件は、Packet-Switch Capable（PSC）インターフェイス向けの要件と類似しています。したがって、MPLS P2MP TE LSPを実現するために定義する機能、機構、プロトコル拡張は、P2MP PSC TE-LSPと非PSC TE-LSPの双方に等しく適用できるよう、合理的な努力を払う必要があります。非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:
MPLS P2MP TE-LSPのソリューションは、GMPLS P2MP PSCまたは非PSC TE-LSPに適用された場合、次のようなGMPLSの他の機能と互換性がなければなりません (MUST)。
- 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;
- 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.
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-LSPは「P2MP機能」が限られる環境で処理される場合があるため、P2MP TEの経路計算に技術固有の制約が適用されることがあります。技術固有の制約は本書の対象外です。ただし、技術に依存しない制約（LSPクラスにかかわらず適用できる制約）は、P2MP TE LSPのメッセージ処理時に適用できるべきです (SHOULD)。経路計算と管理の手法は、PSCのP2P TE LSPおよびP2MP TE LSPで用いる手法に可能な限り近づける必要があります。
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ソリューションは[CRANKBACK]で定義されるクランクバック要件をサポートすべきです (SHOULD)。特に、ネットワーク内の障害や問題を迂回してサブLSPを再ルーティングできるよう、下流LSRから分岐LSRへ十分な情報を提供すべきです (SHOULD)。
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 LSPを安全に確立・管理する機構を含めなければなりません (MUST)。これには、次の機構などが含まれます。
- 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;
- 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と複数のイグレスLSRとの間でセキュリティ関係を維持する必要が生じるP2MP環境では、こうした問題がさらに深刻になる可能性があります。この問題はIPマルチキャストのセキュリティ問題に類似しています。
It is a requirement that documents offering solutions for P2MP LSPs MUST have detailed security sections.
P2MP LSPのソリューションを提案する文書には、詳細なセキュリティ節を設けなければなりません (MUST)。
The authors would like to thank George Swallow, Ichiro Inoue, Dean Cheng, Lou Berger, and Eric Rosen for their review and suggestions.
レビューと提案を寄せてくれたGeorge Swallow、Ichiro Inoue、Dean Cheng、Lou Berger、Eric Rosenに著者らは感謝します。
Thanks to Loa Andersson for his help resolving the final issues in this document and to Harald Alvestrand for a thorough GenArt review.
本書の最終的な課題の解決に協力したLoa Anderssonと、徹底したGenArtレビューを行ったHarald Alvestrandに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[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., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003.
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[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. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 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.
[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.
[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. Farrel, A. Satyanarayana, A. Iwata, N. Fujita, G. Ash, S. Marshall, "Crankback Signaling Extensions for MPLS Signaling", Work in Progress, May 2005.
[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. Farrel, D. King, and T. Nadeau, "OAM Requirements for Point-to-Multipoint MPLS Networks", Work in Progress, February 2006.
Editor's Address
編集者のアドレス
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan
Phone: +81 422 59 4769
EMail: yasukawa.seisho@lab.ntt.co.jp
Authors' Addresses
著者のアドレス
Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium
Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel.be
JP Vasseur Cisco Systems, Inc. 300 Beaver Brook Road
JP Vasseur Cisco Systems, Inc. 300 Beaver Brook Road
Boxborough, MA 01719, USA
Boxborough, MA 01719, USA
EMail: 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 Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan
EMail: y.kamite@ntt.com
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
EMail: rahul@juniper.net
Alan Kullberg Motorola Computer Group 120 Turnpike Rd. Southborough, MA 01772 EMail: alan.kullberg@motorola.com
Alan Kullberg Motorola Computer Group 120 Turnpike Rd. Southborough, MA 01772 EMail: alan.kullberg@motorola.com
Adrian Farrel Old Dog Consulting
Adrian Farrel Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Markus Jork Quarry Technologies 8 New England Executive Park Burlington, MA 01803
Markus Jork Quarry Technologies 8 New England Executive Park Burlington, MA 01803
EMail: mjork@quarrytech.com
Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose, CA 95134
Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose, CA 95134
Phone: +1 408 383 7223
EMail: andy.malis@tellabs.com
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
EMail: jeanlouis.leroux@francetelecom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本書はBCP 78に定める権利、ライセンス、制限の適用を受けます。同文書に別段の定めがある場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本書およびここに含まれる情報は「現状有姿」で提供されます。貢献者、その代表組織またはスポンサー組織（該当する場合）、Internet SocietyおよびInternet Engineering Task Forceは、明示または黙示を問わず、すべての保証を否認します。これには、本書の情報を使用しても権利を侵害しないことに関する保証や、商品性または特定目的への適合性に関する黙示の保証が含まれますが、これらに限定されません。
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は、本書に記載された技術の実装または使用に関係すると主張される知的財産権その他の権利の有効性や範囲について、いかなる見解も示しません。また、そのような権利に基づくライセンスが利用可能かどうかについても見解を示しません。IETFがそのような権利を独自に特定する努力を行ったことを表明するものでもありません。RFC文書に関する権利の手続きについては、BCP 78およびBCP 79を参照してください。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に提出されたIPR開示の写し、利用可能となるライセンスに関する保証、または本仕様の実装者や利用者が当該権利を利用するための一般ライセンスや許可を得ようとした結果は、IETFのオンラインIPRリポジトリ http://www.ietf.org/ipr で確認できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある方に対し、本標準の実装に必要となる可能性のある技術を対象とする著作権、特許、特許出願、その他の所有権があれば、IETFに知らせるよう求めています。情報はietf-ipr@ietf.org宛てにお送りください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。