[要約] RFC 4461は、ポイントツーマルチポイントのトラフィックエンジニアリングMPLSラベルスイッチパス（LSP）のシグナリング要件に関するものです。このRFCの目的は、ポイントツーマルチポイントLSPの設定と制御に関する要件を定義することです。
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プロトコルの制御に基づくパケットスイッチネットワークに適用されるだけでなく、レイヤー2スイッチング（L2SC）、時代分割多重化（TDM）、ラムダ、および一般化によって管理されたポートスイッチングネットワークの要件も含まれます。MPLS（GMPLS）プロトコル。このドキュメントに記載されている要件を満たすために開発されたプロトコルソリューションは、MPLSおよびGMPLに等しく適用できるようにしなければなりません。
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
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は、単一の侵入LSRと1つ以上の出力LSRを備えたTE LSP（[RFC2702]および[RFC3031]ごと）であり、単方向です。P2MPサービス（単一のソースから1つ以上のレシーバーにデータを配信する）は、ネットワーク内で必要な最適化の程度に応じてP2PとP2MP LSPの任意の組み合わせによってサポートされる場合があり、そのようなLSPは、交通エンジニアリングされている場合があります。ネットワークの要件。さらに、Multipoint-to-MultiPoint（MP2MP）サービス（複数のソースから1つ以上のレシーバーにデータを提供する）は、P2Pと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. MPLは、トラフィックの集約と分解の両方を可能にしますが、古典的な宛先のみの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セットアップの手順を指定するソリューションは、これらの要件を満たす必要があります。このドキュメントで、ソリューション固有の詳細またはアプリケーション固有の要件を指定する意図はありません。
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プロトコルの制御下でパケットスイッチされたネットワーク、および一般化されたMPLS（GMPLS）プロトコルによって管理されるパケットスイッチ、TDM、Lambda、およびポートスイッチングネットワークに等しく適用されます。このドキュメントに記載されている要件を満たすために開発されたプロトコルソリューションは、MPLSおよびGMPLに等しく適用できるようにしなければなりません。
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プロトコルの最大再利用で達成する必要があります。
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 LSPの葉の変化速度（つまり、新しい出口LSRが結合する速度、または古い出口LSRが剪定される）は「それほど高くない」と想定されています。TEアプリケーション。この問題については、セクション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-Be-Bebreakなど）によって変更される場合があります。これらの問題については、セクション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機能をスケーラブルな方法で操作する必要があることです。
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に知られていると想定されています。たとえば、Ingress LSRSは、P2MP TE LSPの出力LSRを識別するIPアドレスを知っています。Ingress 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.
- 非LSP（ホップ、ルーティングベースのLSPなど）。 - P2MP LSPの出力葉の発見。 - 階層P2MP LSP。-P2MP LSPのOAM。 - エリア間およびP2MP TE LSPSとしてのインターインター。 - サービスシナリオへのP2MP MPLS TE LSPの適用性。 - 特定のアプリケーションまたはアプリケーション要件。-P2MP分布ツリーを計算するためのアルゴリズム。-Multipoint-to-Point LSP。-Multipoint-to-MultiPoint LSP。 - ルーティングプロトコル。 - トラフィックエンジニアリングデータベースの構築。 - トラフィックエンジニアリングデータベースの構築に使用される情報の配布。
P2P: Point-to-point
P2P：ポイントツーポイント
P2MP: Point-to-multipoint
P2MP：ポイントツーマルチポイント
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 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ではありません。ゼロ、1つ、またはそれ以上の受信機は、特定の出力LSRを介してデータを受信できます。
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（たとえば、Ingress 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）すべて - 部分的（つまり、すべてではない）-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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
既存のMPLS TEメカニズム[RFC3209]およびGMPLS TEメカニズム[RFC3473]は、P2P TE LSPのサポートのみを提供します。P2P TE LSPを使用してP2MP TEサービスを提供することは可能ですが、そのようなアプローチは、Ingress 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サービスを完全に効率的に提供するには、特定の要件を指定する必要があります。これらの要件は、既存のプロトコルおよび/または既存のプロトコルおよび/または新しいプロトコルに拡張を使用するためのメカニズムを定義するときに使用できます。
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パスの計算を可能にする必要があります。これには、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）ワーキンググループが「リソース予約プロトコル（RSVP）-TE：ラベルスイッチパス（LSP）トンネルのRSVPへの拡張」（RFC 3209に焦点を合わせて到達したコンセンサス（RFC 3209）トラフィックエンジニアリングアプリケーションのMPLSシグナリングプロトコルとして...
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を追加/除去する機能を含める必要があり、P2P TE LSPに対して既に定義されているすべてのTE LSP管理手順のサポートを可能にする必要があります。さらに、P2P TE LSPの新しいTE LSP手順が開発される場合、P2MP TE LSPに対して同等または同一の手順を開発する必要があります。
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
図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つの出力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によって計算されるかについての仮定は行われないことに注意してください。また、ソリューションは、ルーティングを緩めて部分的なパスのサポートを可能にする必要があります。
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 LSPに対して既に定義されている制約のセットをサポートする可能性について制限はありません。新しい制約は、LSR機能またはネットワーク制約を考慮に入れるために、P2MP LSRの分岐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) P2MP TE LSPは、ツリー情報を使用してI-LSR1からE-LSR2、E-LSR3、および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) この場合、Branch 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はBranch 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のシグナルに適用する必要があります。たとえば、パケットまたは非パケットベース（フレーム、セル、TDM、ラムダなどを含む）であろうと、スイッチング媒体でP2MP TE LSPを信号を送信することが可能です。
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ツリーに従う必要があります。
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を識別する必要があります。
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ソリューションは、外部ツリー計算プロセス、パス構成プロセス、またはIngress LSRにある動的ツリー計算プロセスの制御下で任意のP2MPツリーを確立する手段を提供する必要があります。図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
シュタイナーP2MPツリーSPF P2MPツリー
Figure 2: Examples of P2MP TE LSP topology
図2：P2MP TE LSPトポロジの例
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]です。このP2MPツリーは、コアの帯域幅の消費を最小限に抑えるために、コスト最小P2MPツリーの構築に適しています。このP2MPツリーを実現するには、いくつかの中間LSRがLSRSとトランジットLSRを終了させるMPLSデータの両方でなければなりません（図2のLSRS E、F、G、G、I、J、およびK）。したがって、P2MP TEソリューションは、この種の芽LSRを侵入LSRと出口LSRの間にセットアップできるメカニズムをサポートする必要があります。これには、ソースとすべての受信機の間の境界遅延など、他の制約を伴う最小コストツリーの計算を可能にする制約付きシュタイナーツリーが含まれていることに注意してください。
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ツリーを計算できます。この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.
このソリューションは、オペレーターが任意のツリー計算手法を使用できるようにする必要があります。前者の場合、効率的/最適なツリーは最小コストツリー（シュタイナーツリー）として定義されますが、後の場合は、ソースとレシーバーの間に最短経路を提供するツリーとして定義されます。
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をBranch LSRとして明示的に含めることができるP2MPツリーの何らかの形式のソースベースの制御をサポートする必要があります。これは、P2MP TE LSPをセットアップするために、Ingress LSRによって使用できます。たとえば、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ツリーは部分的に指定されています。これは、明示的なパスのルーズホップを使用して、または広くスコープされた抽象ノード（つまり、単純ではない抽象ノード[RFC3209]）を使用して達成できます。部分的に指定されたP2MPツリーは、エリア間およびAS間の状況で特に役立つ可能性がありますが、エリア間および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ツリーの明示的なソースベースの制御に、ルーズホップと広くスコープされた抽象ノードを指定する方法を含める必要があります。このサポートが提供される場合、プロトコルソリューションは、下流のLSRがP2MPツリーにさらに明示的な制御を適用して、部分的に指定されたツリーを（より）完全に指定されたツリーに解決できるようにする必要があります。
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.
プロトコルソリューションでは、完全なツリーを計算できるように十分な情報が存在し、パスに沿ったポリシー（ドメイン境界など）が完全な仕様をサポートするのに十分な情報が存在するIngress LSRで、P2MPツリーを完全に指定する必要があります。
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ツリーを学習する必要があります。この情報は、ポリシーの考慮事項のために常に取得できるとは限らないが、パスの一部が機密のままである場合、集約を通じて報告する必要があることに注意してください（たとえば、AS数を使用して）。
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の確立、メンテナンス、および分解をサポートする必要があります。これには、非常に多くのLSPの存在と、単一のP2MP LSPに対する非常に多くの目的地の存在の両方を含める必要があります。
In addition to P2MP TE LSP establishment and teardown mechanisms, the solution SHOULD support a partial P2MP tree modification mechanism.
P2MP TE LSPの確立および分解メカニズムに加えて、ソリューションは部分的なP2MPツリー修正メカニズムをサポートする必要があります。
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.
Sub-P2MP TE LSPを既存のP2MP TE LSPに追加する目的で、拡張機能は移植メカニズムをサポートする必要があります。既存のP2MP TE LSPからサブP2MP TE LSPを削除する目的で、拡張機能は剪定メカニズムをサポートする必要があります。
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.
これらのグラフトおよび剪定操作は、接ぎ木や剪定ノードへのパスに沿っていないノードに追加の処理を引き起こさないこと、またはグラフトまたは剪定された葉に向かって移植または剪定ノードの下流であることをお勧めします。さらに、移植操作と剪定操作の両方が、P2MPツリーに沿って現在転送されているトラフィックを混乱させてはなりません。
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の性質は、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 TEソリューションは、単一のプロトコルメッセージがP2MP LSPの確立を通知するために必要なすべての情報を含めることができない状況を処理する必要があります。これらの状況でLSPを確立することは可能でなければなりません。
This situation may arise in either of the following circumstances.
この状況は、次の状況のいずれかで発生する可能性があります。
a. The ingress LSR cannot signal the whole tree in a single message.
a. Ingress 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断片化に依存するべきではなく、シグナル伝達ソリューションに固有のプロトコル手順に依存することをお勧めします。
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で再組み立てされることは推奨されません。
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.
障害イベントにより、出力LSRSまたはSub-P2MP LSPがP2MP TE LSPから分離される可能性があります。これらのイベントは、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.
このソリューションは、保護や回復などの回復技術を提供し、影響を受けたサブP2MP TE LSPの回復を可能にする必要があります。特に、ソリューションは、P2P TE LSPの[RFC4090]で指定された溶液と同様のP2MP TE LSPに適用可能な高速保護メカニズムを提供する必要があります。また、P2MP TE LSPのバックアップパスをP2P TE LSPSバックアップパスと共有すべきかどうかについての仮定は行われないことに注意してください。
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.
[RFC4090]で指定されている関数は現在、パケット環境に固有であり、非パケット環境には適用されないことに注意してください。したがって、ソリューションは[RFC4090]で指定されているものと同様の高速保護メカニズムを提供する必要がありますが、この要件は、パケットスイッチネットワークのみに適用されるソリューションスペースのサブセットに限定されます。
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.
このソリューションは、帯域幅保護や故障中のバックアップパスに沿って伝播遅延の境界増加など、他のネットワーク回復要件を満たす能力もサポートする必要があります。
A P2MP TE solution MUST support the P2MP fast protection mechanism to handle P2MP applications sensitive to traffic disruption.
P2MP TEソリューションは、トラフィックの混乱に敏感なP2MPアプリケーションを処理するために、P2MP高速保護メカニズムをサポートする必要があります。
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の自動分解を引き起こすべきではありません。つまり、一部の出力LSRはP2MPツリーに接続されたままですが、P2MP LSPが保持されているかどうかは、Ingress LSRのローカルポリシーの問題である必要があります。
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が回復または保護メカニズムによってそれらのいずれかへの接続を回復できない場合、Branch LSRは提供されたP2MPツリーからそれ自体を除去する場合があります。それは出口LSR（つまり芽）でもないこと。P2MPツリーからさまざまな下流の出口LSRを切断した断層は異なる可能性があるため、ブランチLSRはそのようなすべてのエラーを上流の隣人に報告する必要があります。上流の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.
ソリューションには、サブP2MPツリーを再計算するために故障後に復元するための輸送LSR、特に支店LSRの施設が含まれる場合があります。修理が成功した場合、エラー通知は上流ノードに報告されるべきではありませんが、ルート記録が使用されている場合は新しいパスが報告されます。クランクバックの要件については、セクション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.
P2MP TE LSPの確立されたトポロジを特定できることは、Fast Reroute [RFC4090]などのいくつかの局所回復メカニズムの管理や運用など、さまざまな目的にとって非常に重要です。ネットワークオペレーターは、この情報を使用して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ツリートポロジー情報を収集および更新できるメカニズムをサポートする必要があります。
It is RECOMMENDED that the information is collected in a data format that allows easy recognition of the P2MP tree topology.
情報は、P2MPツリートポロジを簡単に認識できるように、データ形式で収集することをお勧めします。
The solution MUST support mechanisms for the recording of both outgoing interfaces and node-ids.
このソリューションは、発信インターフェイスとノードIDの両方の記録のメカニズムをサポートする必要があります。
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.
このソリューションは、収集された情報が大きすぎて単一のプロトコルメッセージで伝えるには大きすぎる場合を含む、P2MPツリー情報の収集に関するスケーリングの問題を優雅に処理する必要があります。
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との共存を促進する必要があります。
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対応ネットワークに適用する必要があります。
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プロトコル仕様とスムーズに相互運用する必要があります。
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に使用される帯域幅プールのタイプについて仮定しないことに注意してください。
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内のこれらのパラメーターの分散を許可してはなりません。あれは：
- 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が必要です。
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.
ツリー全体のパラメーターを変更するとサポートされる場合がありますが、変化はイングレスLSRからすべての出力LSRまでツリー全体に適用する必要があります。
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が再ルーティングされたときにトラフィックの混乱が最小限に抑えることを保証するために、P2MP TE LSPの前後にブレークをサポートする必要があります。
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ツリーにのみ適用されるブレイク前にサポートする必要があります。
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 Sub-LSP、S2X Sub-LSP、S2L Sub-LSP、X2AL Sub-LSP、B2PL Sub-LSP、X2AL Sub-LSPのサブディビジョンの破壊前の再最適化を可能にする必要があります。、またはB2ALツリー）。さらに、P2MP LSPの残りの部分へのシグナル伝達への影響を最小限に抑え、管理面が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.
また、このソリューションは、Ingress LSRが再最適化プロセスを厳密に制御できるようにする能力を提供する必要があります。侵入LSRは、すべての再最適化をソース開始に制限できるはずです。
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によって開始される場合があります。下流のLSRによって開始されたサブLSPの再最適化は、他の再最適化について上記のように、アクティブトラフィックへの影響を最小限に抑えることと同じ点で実行する必要があります。
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).
この状況は、シグナリングソリューションの定義またはシグナリングソリューション内の実装オプションの結果として発生する可能性があります。さらに、ブレイク前の再最適化中に発生する可能性があります（セクション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で受信され、同じ上流インターフェイスを参照する場合をサポートする必要があります。この場合、プロトコル手順の結果は、上流インターフェイスの単一のデータフローである必要があります。
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で受信され、異なる上流インターフェイスを参照する場合、および各シグナリングメッセージの結果、異なる下流インターフェイスの使用が得られる場合をサポートする必要があります。このケースは、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で受信され、異なる上流インターフェイスを参照し、下流のインターフェイスが受信シグナリングメッセージ間で共有される場合をサポートする場合があります。このケースは、データフローのマージを表しています。このケースをサポートするソリューションは、データがダウンストリームインターフェイスで複製されないようにする必要があります。
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.
- 制限された一時的な条件に制限する必要があります。ネットワーク帯域幅が重複する配信パスの存在によって無駄になる場合。
- MUST limit the cases where duplicate data is delivered to an application to bounded transitory conditions.
- 重複したデータが境界された一時的な条件にアプリケーションに配信される場合を制限する必要があります。
Any P2MP TE solution MUST support IPv4 and IPv6 addressing.
P2MP TEソリューションは、IPv4およびIPv6アドレス指定をサポートする必要があります。
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およびその他）を確立することを可能にし、P2MP TE LSPと同じネットワーク内のP2P LSPの共存を許可する必要があります。
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およびP2P TE LSPを同じインターフェイスで信号するように指定する必要があります。
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の能力。-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.
- Branch LSRはデータを複製し、複数のコピーをセグメントに送信します。-Branch LSRはデータの単一のコピーをセグメントに送信し、出口ポイントに依存して、データを受信して転送するかどうかを判断します。
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.
最初のオプションには、すべての複製されたデータを同じポートから送信し、同じセグメントに搭載する必要があるため、重要なデータプレーンスケーリングの問題があります。したがって、ソリューションは、Branch LSRがデータの単一のコピーをマルチアクセスネットワークに送信して、複数の（隣接する）ダウンストリームノードに到達するメカニズムを提供する必要があります。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管理を開発したものと並んで提供する必要があります。
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には一意の識別子が必要です。そうしないと、どの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システムの重要な要件です。ソリューションは、次のいずれかの数の増加とともに十分にスケーリングするように設計する必要があります。
- 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.
コントロールプレーンの動作のスケーラビリティ（セットアップ、メンテナンス、修正、断片）を考慮する必要があります。
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.
- P2MP TE LSPの維持に関連する更新処理の量。-P2MPツリーに沿ったIngressおよびTransit LSRによって維持する必要があるプロトコル状態の量。 - 出力LSRの数の関数としてP2MP LSPを設定または解体するために必要なプロトコルメッセージの数。 - 障害後にP2MP LSPを修復するために必要なプロトコルメッセージの数、またはブレイク前に実行するために必要な数。-P2MP TE LSP（つまり、メッセージサイズ）を管理するために送信されるプロトコル情報の量。 - 潜在的なルーティング拡張機能で配布される追加データの量。 - 新しいブランチの追加/削除が必要かどうかを検出するためにネットワークで必要な追加のコントロールプレーン処理の量、特に追加/削除が要求されない場合の定常状態の処理量 - コントロールプレーンの量既存のP2MP LSPにBranch 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.
スケーリングバウンドは、P2MP TE LSPが出力LSRの数が1に減少する場合、P2P LSPと同様のスケーリング特性に減らす必要があるように、ソリューションメカニズムに配置されます。つまり、P2MP TE LSPを単一の出力LSRに確立することは、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の初期展開は、最大約100の出口LSRに制限されると予想されていますが、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の1つの極端な可能性を、別のブランチのすべての葉に分岐する1つの極端なLSRから、n出口LSRの（n-1）の最大数の分岐LSRまで、すべての可能性をサポートする必要があります。どのトポロジーがより一般的であるかに関するソリューションで仮定を作成してはなりません。また、すべてのトポロジのスケーラビリティを確保するためにソリューションを設計する必要があります。
- 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.
出入りする出入りの出入りの絶対数は、ソリューションのスケーラビリティを決定するための重要な要素ですが、パーセンテージはより理解しやすい尺度である可能性がありますが、これは少数のレシピエントを持つ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.
ソリューションは、このような比較的低い変化率のために最適化する必要があり、大幅に高い変化率のために最適化する必要はありません。
- 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の機能の1つは、ネットワーク障害に対して堅牢または保護されている可能性があり、新しく利用可能なネットワークリソースを利用するために再最適化できることです。
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.
ソリューションはこの区別に従い、それに応じて最適化する必要があります。
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ソリューションの目的でなければなりません。おそらく達成するのが不可能な理想は、ネットワーク内の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の両方としてレガシーノードを使用することです。
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をサポートすることを禁止しないという解決策のさらなる要件です。つまり、そうすることが管理上禁止されていない限り、P2P TE LSPはP2MPネットワークを介してサポートする必要があります。
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マルチキャストネットワークと共存できる必要があることが要件です。
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サービスの要件は、パケットスイッチCapable（PSC）インターフェイスの要件に似ています。したがって、MPLS P2MP TE LSPをP2MP PSCおよび非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の他の機能と互換性がなければなりません。
- 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リンクの完全なサポート。 - 特定のテクノロジーの任意のラベルとラベルの使用、および必要に応じて、限られたラベル処理とスワッピング機能をサポートするために、ラベルのネゴシエーション。
- 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に到達した後のデータの次のホップラベル/ポート/インターフェイスを制御する機能。 - LSPの優雅でアラームのない有効化と終了のサポート。 - リンクレベルの保護、エンドツーエンドの保護、セグメント保護を含む保護の完全なサポート。 - 特に、Egress LSRから下流のLSRからLSPを分解する能力。 - 優雅な削除手順の処理。および - データプレーンの混乱なしに、制御プレーンの故障と再接続のサポート。
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.
さらに、「P2MP機能」が制限される可能性のある環境では、非PSC TE-LSPを処理する必要がある場合があるため、P2MP TEパス計算中に特定の制約も適用される場合があります。テクノロジー特有であるため、これらの制約はこのドキュメントの範囲外です。ただし、P2MP TE LSPメッセージ処理中に、テクノロジーに依存しない制約（つまり、LSPクラスとは無関係に適用可能な制約）を許可する必要があります。PATH計算と管理手法は、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ソリューションは、[クランクバック]で定義されているクランクバック要件をサポートする必要があります。特に、ネットワーク内の障害や問題についてサブLSPを再ルーティングできるように、下流のLSRSからのブランチLSRに十分な情報を提供する必要があります。
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の安全な確立と管理を可能にするメカニズムを含める必要があることが要件です。これには含まれますが、以下に限定されません。
- 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が特定されることを保証するメカニズム。 - 信号エンティティを通信することが互いのアイデンティティを検証できるようにするメカニズム。 - 制御プレーンメッセージがスプーフィングと改ざんから保護されることを保証するメカニズム。
- 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のソリューションを提供するドキュメントが詳細なセキュリティセクションを持たなければならないことが要件です。
The authors would like to thank George Swallow, Ichiro Inoue, Dean Cheng, Lou Berger, and Eric Rosen for their review and suggestions.
著者は、レビューと提案について、ジョージ・スワロー、イチロ・イノウエ、ディーン・チェン、ルー・バーガー、エリック・ローゼンに感謝したいと思います。
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がこの文書の最終的な問題を解決してくれたことに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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.、Malcolm、J.、Agogbua、J.、O'dell、M。、およびJ. McManus、「MPLS上のトラフィックエンジニアリングの要件」、RFC 2702、1999年9月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月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。およびG. Swallow、「MPLSシグナリングプロトコルに関するマルチプロトコルラベルスイッチング（MPLS）ワーキンググループの決定」、RFC 3468、2003年2月。
[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。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナルリソースリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、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. Lai、「差別化されたサービス認識MPLSトラフィックエンジニアリングのサポートの要件」、RFC 3564、2003年7月。
[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。、およびA. Atlas、「LSPトンネルのRSVP-TEへの高速拡張式」、RFC 4090、2005年5月。
[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。、「高速ネットワークでのリアルタイム通信のためのマルチキャストルーティングアルゴリズムの評価」、Communicationsの選択された領域に関するIEEEジャーナル、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.
[クランクバック] A.ファレル、A。サティヤナラヤナ、A。岩田、N。藤田、G。アッシュ、S。マーシャル、「MPLSシグナル伝達のためのクランクバックシグナリング拡張」、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。Farrel、D。King、およびT. Nadeau、「ポイントツーマルチポイントMPLSネットワークのOAM要件」、2006年2月、Work in Progress。
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、日本
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、ベルギー
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
ボックスボロー、マサチューセッツ州01719、米国
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、東京163-1421、日本
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。サウスボロー、マサチューセッツ州01772メール：alan.kullberg@motorola.com
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ニューイングランドエグゼクティブパークバーリントン、マサチューセッツ州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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。