[要約] RFC 4875は、ポイントツーマルチポイントのトラフィックエンジニアリング（RSVP-TE）のための拡張であり、LSP（ラベルスイッチングパス）に関するものです。このRFCの目的は、ポイントツーマルチポイントのLSPをサポートするためのプロトコル拡張を提供することです。
Network Working Group R. Aggarwal, Ed.
Request for Comments: 4875 Juniper Networks
Category: Standards Track D. Papadimitriou, Ed.
Alcatel
S. Yasukawa, Ed.
NTT
May 2007
Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルスイッチドパス（LSP）のトラフィックエンジニアリング（RSVP-TE）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.
このドキュメントでは、マルチプロトコルラベルスイッチング（MPLS）およびマルチプロトコルラベルスイッチング（MPLS）のトラフィックエンジニアリング（TE）ポイントツーマルチポイント（P2MP）ラベルスイッチ付きパス（LSP）のセットアップのためのリソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）への拡張について説明します。一般化されたMPLS（GMPLS）ネットワーク。このソリューションは、サービスプロバイダーコアにマルチキャストルーティングプロトコルを必要とせずにRSVP-TEに依存しています。このソリューションのプロトコル要素と手順について説明します。
There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document.
IPマルチキャストなど、P2MP TE LSPにはさまざまなアプリケーションがあります。このようなアプリケーションがP2MP TE LSPを使用する方法の仕様は、このドキュメントの範囲外です。
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................4
3. Terminology .....................................................4
4. Mechanism .......................................................5
4.1. P2MP Tunnels ...............................................5
4.2. P2MP LSP ...................................................5
4.3. Sub-Groups .................................................5
4.4. S2L Sub-LSPs ...............................................6
4.4.1. Representation of an S2L Sub-LSP ....................6
4.4.2. S2L Sub-LSPs and Path Messages ......................7
4.5. Explicit Routing ...........................................7
5. Path Message ....................................................9
5.1. Path Message Format ........................................9
5.2. Path Message Processing ...................................11
5.2.1. Multiple Path Messages .............................11
5.2.2. Multiple S2L Sub-LSPs in One Path Message ..........12
5.2.3. Transit Fragmentation of Path State Information ....14
5.2.4. Control of Branch Fate Sharing .....................15
5.3. Grafting ..................................................15
6. Resv Message ...................................................16
6.1. Resv Message Format .......................................16
6.2. Resv Message Processing ...................................17
6.2.1. Resv Message Throttling ............................18
6.3. Route Recording ...........................................19
6.3.1. RRO Processing .....................................19
6.4. Reservation Style .........................................19
7. PathTear Message ...............................................20
7.1. PathTear Message Format ...................................20
7.2. Pruning ...................................................20
7.2.1. Implicit S2L Sub-LSP Teardown ......................20
7.2.2. Explicit S2L Sub-LSP Teardown ......................21
8. Notify and ResvConf Messages ...................................21
8.1. Notify Messages ...........................................21
8.2. ResvConf Messages .........................................23
9. Refresh Reduction ..............................................24
10. State Management ..............................................24
10.1. Incremental State Update .................................25
10.2. Combining Multiple Path Messages .........................25
11. Error Processing ..............................................26
11.1. PathErr Messages .........................................27
11.2. ResvErr Messages .........................................27
11.3. Branch Failure Handling ..................................28
12. Admin Status Change ...........................................29
13. Label Allocation on LANs with Multiple Downstream Nodes .......29
14. P2MP LSP and Sub-LSP Re-Optimization ..........................29
14.1. Make-before-Break ........................................29
14.2. Sub-Group-Based Re-Optimization ..........................29
15. Fast Reroute ..................................................30
15.1. Facility Backup ..........................................31
15.1.1. Link Protection ...................................31
15.1.2. Node Protection ...................................31
15.2. One-to-One Backup ........................................32
16. Support for LSRs That Are Not P2MP Capable ....................33
17. Reduction in Control Plane Processing with LSP Hierarchy ......34
18. P2MP LSP Re-Merging and Cross-Over ............................35
18.1. Procedures ...............................................36
18.1.1. Re-Merge Procedures ...............................36
19. New and Updated Message Objects ...............................39
19.1. SESSION Object ...........................................39
19.1.1. P2MP LSP Tunnel IPv4 SESSION Object ...............39
19.1.2. P2MP LSP Tunnel IPv6 SESSION Object ...............40
19.2. SENDER_TEMPLATE Object ...................................40
19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object .......41
19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object .......42
19.3. S2L_SUB_LSP Object .......................................43
19.3.1. S2L_SUB_LSP IPv4 Object ...........................43
19.3.2. S2L_SUB_LSP IPv6 Object ...........................43
19.4. FILTER_SPEC Object .......................................43
19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object ..................43
19.4.2. P2MP LSP_IPv6 FILTER_SPEC Object ..................44
19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) ..............44
19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO) ................44
20. IANA Considerations ...........................................44
20.1. New Class Numbers ........................................44
20.2. New Class Types ..........................................44
20.3. New Error Values .........................................45
20.4. LSP Attributes Flags .....................................46
21. Security Considerations .......................................46
22. Acknowledgements ..............................................47
23. References ....................................................47
23.1. Normative References .....................................47
23.2. Informative References ...................................48
Appendix A. Example of P2MP LSP Setup .............................49
Appendix B. Contributors ..........................................50
[RFC3209] defines a mechanism for setting up point-to-point (P2P) Traffic Engineered (TE) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. [RFC3473] defines extensions to [RFC3209] for setting up P2P TE LSPs in Generalized MPLS (GMPLS) networks. However these specifications do not provide a mechanism for building point-to-multipoint (P2MP) TE LSPs.
[RFC3209]は、マルチプロトコルラベルスイッチング（MPLS）ネットワークで、ポイントツーポイント（P2P）トラフィックエンジニアリング（TE）ラベルスイッチ付きパス（LSP）を設定するメカニズムを定義します。[RFC3473]は、一般化されたMPLS（GMPLS）ネットワークでP2P TE LSPをセットアップするための拡張機能を[RFC3209]に定義します。ただし、これらの仕様は、ポイントツーマルチポイント（P2MP）TE LSPを構築するメカニズムを提供しません。
This document defines extensions to the RSVP-TE protocol ([RFC3209] and [RFC3473]) to support P2MP TE LSPs satisfying the set of requirements described in [RFC4461].
このドキュメントは、[RFC4461]で説明されている一連の要件を満たすP2MP TE LSPをサポートするために、RSVP-TEプロトコル（[RFC3209]および[RFC3473]）への拡張機能を定義します。
This document relies on the semantics of the Resource Reservation Protocol (RSVP) that RSVP-TE inherits for building P2MP LSPs. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress LSRs and are appropriately combined by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. One Path message may signal one or multiple S2L sub-LSPs for a single P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages.
このドキュメントは、RSVP-TEがP2MP LSPを構築するために継承するリソース予約プロトコル（RSVP）のセマンティクスに依存しています。P2MP LSPは、複数のソースから葉（S2L）サブLSPで構成されています。これらのS2LサブLSPは、侵入と出口LSRの間にセットアップされ、RSVPセマンティクスを使用してBranch LSRSによって適切に組み合わされてP2MP TE LSPが生成されます。1つのパスメッセージは、単一のP2MP LSPに対して1つまたは複数のS2LサブLSPを信号する場合があります。したがって、P2MP LSPに属するS2L Sub-LSPは、1つのパスメッセージを使用して信号を送信するか、複数のパスメッセージに分割することができます。
There are various applications for P2MP TE LSPs and the signaling techniques described in this document can be used, sometimes in combination with other techniques, to support different applications.
P2MP TE LSPにはさまざまなアプリケーションがあり、このドキュメントで説明されているシグナル伝達手法を、時には他の手法と組み合わせて使用して、さまざまなアプリケーションをサポートすることができます。
Specification of how applications will use P2MP TE LSPs and how the paths of P2MP TE LSPs are computed is outside the scope of this document.
アプリケーションがP2MP TE LSPを使用する方法とP2MP TE 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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This document uses terminologies defined in [RFC2205], [RFC3031], [RFC3209], [RFC3473], [RFC4090], and [RFC4461].
この文書は、[RFC 2205]、[RFC 3031]、[RFC 3209]、[RFC 3473]、[RFC4090]、および[RFC4461]で定義された用語を使用します。
This document describes a solution that optimizes data replication by allowing non-ingress nodes in the network to be replication/branch nodes. A branch node is an LSR that replicates the incoming data on to one or more outgoing interfaces. The solution relies on RSVP-TE in the network for setting up a P2MP TE LSP.
このドキュメントでは、ネットワーク内の非炎症ノードを複製/分岐ノードにすることにより、データレプリケーションを最適化するソリューションについて説明します。ブランチノードは、着信データを1つ以上の発信インターフェイスに複製するLSRです。このソリューションは、P2MP TE LSPをセットアップするために、ネットワーク内のRSVP-TEに依存しています。
The P2MP TE LSP is set up by associating multiple S2L sub-LSPs and relying on data replication at branch nodes. This is described further in the following sub-sections by describing P2MP tunnels and how they relate to S2L sub-LSPs.
P2MP TE LSPは、複数のS2LサブLSPを関連付け、分岐ノードでのデータ複製に依存することによりセットアップされます。これは、P2MPトンネルとS2LサブLSPとの関係を記述することにより、次のサブセクションでさらに説明します。
The defining feature of a P2MP TE LSP is the action required at branch nodes where data replication occurs. Incoming MPLS labeled data is replicated to outgoing interfaces which may use different labels for the data.
P2MP TE LSPの定義機能は、データ複製が発生するブランチノードで必要なアクションです。データラベルのあるMPLSラベルのあるMPLは、データに異なるラベルを使用する可能性のある発信インターフェイスに複製されます。
A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the identifier of the P2MP Session, which includes the P2MP Identifier (P2MP ID), a tunnel Identifier (Tunnel ID), and an extended tunnel identifier (Extended Tunnel ID). The P2MP ID is a four-octet number and is unique within the scope of the ingress LSR.
P2MP TEトンネルには、1つ以上のP2MP LSPが含まれます。P2MP TEトンネルは、P2MPセッションオブジェクトによって識別されます。このオブジェクトには、P2MP識別子（P2MP ID）、トンネル識別子（トンネルID）、および拡張トンネル識別子（拡張トンネルID）を含むP2MPセッションの識別子が含まれています。P2MP IDは4オクテット番号であり、Ingress LSRの範囲内で一意です。
The <P2MP ID, Tunnel ID, Extended Tunnel ID> tuple provides an identifier for the set of destinations of the P2MP TE Tunnel.
<P2MP ID、トンネルID、拡張トンネルID> Tupleは、P2MP TEトンネルの一連の宛先の識別子を提供します。
The fields of the P2MP SESSION object are identical to those of the SESSION object defined in [RFC3209] except that the Tunnel Endpoint Address field is replaced by the P2MP ID field. The P2MP SESSION object is defined in section 19.1
P2MPセッションオブジェクトのフィールドは、[RFC3209]で定義されているセッションオブジェクトのフィールドと同一です。P2MPセッションオブジェクトは、セクション19.1で定義されています
A P2MP LSP is identified by the combination of the P2MP ID, Tunnel ID, and Extended Tunnel ID that are part of the P2MP SESSION object, and the tunnel sender address and LSP ID fields of the P2MP SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is defined in section 19.2.
P2MP LSPは、P2MPセッションオブジェクトの一部であるP2MP ID、トンネルID、およびP2MP Sender_Templateオブジェクトのトンネル送信者アドレスとLSP IDフィールドの組み合わせによって識別されます。新しいP2MP Sender_Templateオブジェクトは、セクション19.2で定義されています。
As with all other RSVP controlled LSPs, P2MP LSP state is managed using RSVP messages. While the use of RSVP messages is the same, P2MP LSP state differs from P2P LSP state in a number of ways. A P2MP LSP comprises multiple S2L Sub-LSPs, and as a result of this, it may not be possible to represent full state in a single IP packet. It must also be possible to efficiently add and remove endpoints to and from P2MP TE LSPs. An additional issue is that the P2MP LSP must also handle the state "re-merge" problem, see [RFC4461] and section 18.
他のすべてのRSVP制御LSPと同様に、P2MP LSP状態はRSVPメッセージを使用して管理されます。RSVPメッセージの使用は同じですが、P2MP LSP状態はさまざまな方法でP2P LSP状態とは異なります。P2MP LSPは複数のS2LサブLSPで構成されており、その結果、単一のIPパケットで完全状態を表すことはできない場合があります。また、P2MP TE LSPにエンドポイントを効率的に追加および削除することも可能でなければなりません。追加の問題は、P2MP LSPが状態を「再加算」する問題を処理する必要があることです。[RFC4461]およびセクション18を参照してください。
These differences in P2MP state are addressed through the addition of a sub-group identifier (Sub-Group ID) and sub-group originator (Sub-Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC objects. Taken together, the Sub-Group ID and Sub-Group Originator ID are referred to as the Sub-Group fields.
P2MP状態のこれらの違いは、サブグループ識別子（サブグループID）とサブグループオリジネーター（サブグループオリジターターID）をsender_templateおよびfilter_specオブジェクトに追加することで対処されます。まとめると、サブグループIDおよびサブグループオリジネーターIDは、サブグループフィールドと呼ばれます。
The Sub-Group fields, together with the rest of the SENDER_TEMPLATE and SESSION objects, are used to represent a portion of a P2MP LSP's state. This portion of a P2MP LSP's state refers only to signaling state and not data plane replication or branching. For example, it is possible for a node to "branch" signaling state for a P2MP LSP, but to not branch the data associated with the P2MP LSP. Typical applications for generation and use of multiple sub-groups are (1) addition of an egress and (2) semantic fragmentation to ensure that a Path message remains within a single IP packet.
Sender_Templateおよびセッションオブジェクトの残りの部分とともに、サブグループフィールドは、P2MP LSPの状態の一部を表すために使用されます。P2MP LSPの状態のこの部分は、データプレーンの複製または分岐ではなく、シグナリング状態のみを指します。たとえば、ノードがP2MP LSPのシグナリング状態を「分岐」する可能性がありますが、P2MP LSPに関連付けられたデータを分岐しない可能性があります。複数のサブグループの生成と使用のための典型的なアプリケーションは、（1）出口と（2）パスメッセージが単一のIPパケット内に残ることを確認するためのセマンティックフラグメンテーションの追加です。
A P2MP LSP is constituted of one or more S2L sub-LSPs.
P2MP LSPは、1つ以上のS2L Sub-LSPで構成されています。
An S2L sub-LSP exists within the context of a P2MP LSP. Thus, it is identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that are part of the P2MP SESSION, the tunnel sender address and LSP ID fields of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP destination address that is part of the S2L_SUB_LSP object. The S2L_SUB_LSP object is defined in section 19.3.
S2LサブLSPは、P2MP LSPのコンテキスト内に存在します。したがって、P2MPセッションの一部であるP2MP ID、トンネルID、および拡張トンネルID、P2MP Sender_Templateオブジェクトのトンネル送信者アドレスとLSP IDフィールド、および一部であるS2LサブLSP宛先アドレスによって識別されます。S2L_SUB_LSPオブジェクトの。S2L_SUB_LSPオブジェクトは、セクション19.3で定義されています。
An EXPLICIT_ROUTE Object (ERO) or P2MP_SECONDARY_EXPLICIT_ROUTE Object (SERO) is used to optionally specify the explicit route of a S2L sub-LSP. Each ERO or SERO that is signaled corresponds to a particular S2L_SUB_LSP object. Details of explicit route encoding are specified in section 4.5. The SECONDARY_EXPLICIT_ROUTE Object is defined in [RFC4873], a new P2MP SECONDARY_EXPLICIT_ROUTE Object C-type is defined in section 19.5, and a matching P2MP_SECONDARY_RECORD_ROUTE Object C-type is defined in section 19.6.
spricit_routeオブジェクト（ero）またはp2mp_secondary_explicit_routeオブジェクト（sero）を使用して、s2l sub-lspの明示的なルートをオプションで指定します。シグナル伝達される各EROまたはSeroは、特定のS2L_SUB_LSPオブジェクトに対応します。明示的なルートエンコーディングの詳細は、セクション4.5で指定されています。Secondary_explicit_Routeオブジェクトは[RFC4873]で定義され、新しいP2MP Secondary_Explicit_RouteオブジェクトCタイプはセクション19.5で定義され、一致するP2MP_Secondary_Record_RouteオブジェクトCタイプはセクション19.6で定義されています。
The mechanism in this document allows a P2MP LSP to be signaled using one or more Path messages. Each Path message may signal one or more S2L sub-LSPs. Support for multiple Path messages is desirable as one Path message may not be large enough to contain all the S2L sub-LSPs; and they also allow separate manipulation of sub-trees of the P2MP LSP. The reason for allowing a single Path message to signal multiple S2L sub-LSPs is to optimize the number of control messages needed to set up a P2MP LSP.
このドキュメントのメカニズムにより、P2MP LSPを1つ以上のパスメッセージを使用して信号することができます。各パスメッセージは、1つ以上のS2LサブLSPを信号する場合があります。1つのパスメッセージがすべてのS2L Sub-LSPを含めるほど十分に大きくない可能性があるため、複数のパスメッセージのサポートが望ましいです。また、P2MP LSPのサブツリーの個別の操作も許可しています。単一のパスメッセージが複数のS2L Sub-LSPを信号するように許可する理由は、P2MP LSPを設定するために必要なコントロールメッセージの数を最適化するためです。
When a Path message signals a single S2L sub-LSP (that is, the Path message is only targeting a single leaf in the P2MP tree), the EXPLICIT_ROUTE object encodes the path to the egress LSR. The Path message also includes the S2L_SUB_LSP object for the S2L sub-LSP being signaled. The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple represents the S2L sub-LSP and is referred to as the sub-LSP descriptor. The absence of the ERO should be interpreted as requiring hop-by-hop routing for the sub-LSP based on the S2L sub-LSP destination address field of the S2L_SUB_LSP object.
パスメッセージが単一のS2LサブLSP（つまり、パスメッセージはP2MPツリーの単一の葉のみをターゲットにする）を信号する場合、emplicit_routeオブジェクトは出口LSRへのパスをエンコードします。PATHメッセージには、S2LサブLSPのS2L_LSPオブジェクトも含まれています。<[<sfricit_route>]、<s2l_sub_lsp >>タプルはS2LサブLSPを表し、sub-lsp記述子と呼ばれます。EROの欠如は、S2L_SUB_LSPオブジェクトのS2L Sub-LSP宛先アドレスフィールドに基づいて、サブLSPのホップバイホップルーティングを必要とすると解釈する必要があります。
When a Path message signals multiple S2L sub-LSPs, the path of the first S2L sub-LSP to the egress LSR is encoded in the ERO. The first S2L sub-LSP is the one that corresponds to the first S2L_SUB_LSP object in the Path message. The S2L sub-LSPs corresponding to the S2L_SUB_LSP objects that follow are termed as subsequent S2L sub-LSPs.
パスメッセージが複数のS2L Sub-LSPを信号すると、EROで最初のS2LサブLSPのパスがEROでエンコードされます。最初のS2LサブLSPは、パスメッセージ内の最初のS2L_SUB_LSPオブジェクトに対応するものです。以下のS2L_SUB_LSPオブジェクトに対応するS2L Sub-LSPは、後続のS2L Sub-LSPと呼ばれます。
The path of each subsequent S2L sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object (SERO). The format of the SERO is the same as an ERO (as defined in [RFC3209] and [RFC3473]). Each subsequent S2L sub-LSP is represented by tuples of the form < [<P2MP SECONDARY_EXPLICIT_ROUTE>], <S2L_SUB_LSP> >. An SERO for a particular S2L sub-LSP includes only the path from a branch LSR to the egress LSR of that S2L sub-LSP. The branch MUST appear as an explicit hop in the ERO or some other SERO. The absence of an SERO should be interpreted as requiring hop-by-hop routing for that S2L sub-LSP. Note that the destination address is carried in the S2L sub-LSP object. The encoding of the SERO and S2L_SUB_LSP object is described in detail in section 19.
各後続のS2LサブLSPのパスは、P2MP_SECONDARY_EXPLICIT_ROUTEオブジェクト（SERO）でエンコードされています。SEROの形式は、[RFC3209]および[RFC3473]で定義されているEROと同じです。後続の各S2LサブLSPは、フォーム<[<p2mp seconvor_explicit_route>]、<s2l_sub_lsp >>の形式で表されます。特定のS2LサブLSPのSEROには、Branch LSRからそのS2LサブLSPの出力LSRへのパスのみが含まれます。ブランチは、EROまたは他のセロの明示的なホップとして表示されなければなりません。SEROの不在は、そのS2LサブLSPのホップバイホップルーティングを必要とすると解釈する必要があります。宛先アドレスはS2L Sub-LSPオブジェクトに携帯されていることに注意してください。SEROおよびS2L_SUB_LSPオブジェクトのエンコードについては、セクション19で詳しく説明しています。
In order to avoid the potential repetition of path information for the parts of S2L sub-LSPs that share hops, this information is deduced from the explicit routes of other S2L sub-LSPs using explicit route compression in SEROs.
ホップを共有するS2LサブLSPの部分のパス情報の潜在的な繰り返しを回避するために、この情報は、SEROSの明示的なルート圧縮を使用して、他のS2L Sub-LSPの明示的なルートから推定されます。
A
|
|
B
|
|
C----D----E
| | |
| | |
F G H-------I
| |\ |
| | \ |
J K L M
| | | |
| | | |
N O P Q--R
Figure 1. Explicit Route Compression
図1.明示的なルート圧縮
Figure 1 shows a P2MP LSP with LSR A as the ingress LSR and six egress LSRs: (F, N, O, P, Q and R). When all six S2L sub-LSPs are signaled in one Path message, let us assume that the S2L sub-LSP to LSR F is the first S2L sub-LSP, and the rest are subsequent S2L sub-LSPs. The following encoding is one way for the ingress LSR A to encode the S2L sub-LSP explicit routes using compression:
図1は、LSR AとしてLSR Aを含むP2MP LSPと6つの出力LSRを示しています：（f、n、o、p、q、r）。すべての6つのS2LサブLSPが1つのパスメッセージでシグナル伝達される場合、S2L Sub-LSPからLSR Fが最初のS2L Sub-LSPであり、残りはその後のS2L Sub-LSPであると仮定しましょう。次のエンコードは、イングレスLSR Aが圧縮を使用してS2LサブLSP明示的ルートをエンコードする1つの方法です。
S2L sub-LSP-F: ERO = {B, E, D, C, F}, <S2L_SUB_LSP> object-F
S2L sub-LSP-N: SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N
S2L sub-LSP-O: SERO = {E, H, K, O}, <S2L_SUB_LSP> object-O
S2L sub-LSP-P: SERO = {H, L, P}, <S2L_SUB_LSP> object-P
S2L sub-LSP-Q: SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q
S2L sub-LSP-R: SERO = {Q, R}, <S2L_SUB_LSP> object-R
After LSR E processes the incoming Path message from LSR B it sends a Path message to LSR D with the S2L sub-LSP explicit routes encoded as follows:
LSR EがLSR Bからの着信パスメッセージを処理した後、次のようにエンコードされたS2L Sub-LSP明示的ルートを使用してLSR Dにパスメッセージを送信します。
S2L sub-LSP-F: ERO = {D, C, F}, <S2L_SUB_LSP> object-F
S2L sub-LSP-N: SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N
LSR E also sends a Path message to LSR H, and the following is one way to encode the S2L sub-LSP explicit routes using compression:
LSR Eはまた、LSR Hにパスメッセージを送信します。以下は、圧縮を使用してS2LサブLSP明示的ルートをエンコードする1つの方法です。
S2L sub-LSP-O: ERO = {H, K, O}, <S2L_SUB_LSP> object-O
S2L sub-LSP-P: SERO = {H, L, P}, S2L_SUB_LSP object-P
S2L sub-LSP-Q: SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q
S2L sub-LSP-R: SERO = {Q, R}, <S2L_SUB_LSP> object-R
After LSR H processes the incoming Path message from E, it sends a Path message to LSR K, LSR L, and LSR I. The encoding for the Path message to LSR K is as follows:
LSR HがEからの着信パスメッセージを処理した後、LSR K、LSR L、およびLSR Iにパスメッセージを送信します。LSRKへのパスメッセージのエンコードは次のとおりです。
S2L sub-LSP-O: ERO = {K, O}, <S2L_SUB_LSP> object-O
The encoding of the Path message sent by LSR H to LSR L is as follows:
LSR HからLSR Lに送信されたパスメッセージのエンコードは次のとおりです。
S2L sub-LSP-P: ERO = {L, P}, <S2L_SUB_LSP> object-P
The following encoding is one way for LSR H to encode the S2L sub-LSP explicit routes in the Path message sent to LSR I:
次のエンコードは、LSR HがLSR Iに送信されたパスメッセージのS2LサブLSP明示的ルートをエンコードする1つの方法です。
S2L sub-LSP-Q: ERO = {I, M, Q}, <S2L_SUB_LSP> object-Q
S2L sub-LSP-R: SERO = {Q, R}, <S2L_SUB_LSP> object-R
The explicit route encodings in the Path messages sent by LSRs D and Q are left as an exercise for the reader.
LSRS DとQによって送信されたパスメッセージの明示的なルートエンコーディングは、読者の演習として残されています。
This compression mechanism reduces the Path message size. It also reduces extra processing that can result if explicit routes are encoded from ingress to egress for each S2L sub-LSP. No assumptions are placed on the ordering of the subsequent S2L sub-LSPs and hence on the ordering of the SEROs in the Path message. All LSRs need to process the ERO corresponding to the first S2L sub-LSP. An LSR needs to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR. The branch LSR that is the first hop of an SERO propagates the corresponding S2L sub-LSP downstream.
この圧縮メカニズムは、パスメッセージサイズを削減します。また、各S2LサブLSPのイングレスから出口に明示的なルートがエンコードされた場合に生じる可能性のある追加の処理を減らします。後続のS2L Sub-LSPの順序付け、したがってパスメッセージ内のSEROSの順序付けには仮定はありません。すべてのLSRは、最初のS2LサブLSPに対応するEROを処理する必要があります。LSRは、対応するSEROの最初のホップがそのLSRのローカルアドレスである場合にのみ、後続のS2L Sub-LSPのS2L Sub-LSP記述子を処理する必要があります。Seroの最初のホップであるブランチLSRは、対応するS2LサブLSPの下流を伝播します。
This section describes modifications made to the Path message format as specified in [RFC3209] and [RFC3473]. The Path message is enhanced to signal one or more S2L sub-LSPs. This is done by including the S2L sub-LSP descriptor list in the Path message as shown below.
このセクションでは、[RFC3209]および[RFC3473]で指定されているパスメッセージ形式に加えられた変更について説明します。パスメッセージは強化され、1つ以上のS2L Sub-LSPSを信号します。これは、以下に示すように、パスメッセージにS2L Sub-LSP記述子リストを含めることによって行われます。
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[<S2L sub-LSP descriptor list>]
The following is the format of the S2L sub-LSP descriptor list.
以下は、S2L Sub-LSP記述子リストの形式です。
<S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor>
[ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor> ::= <S2L_SUB_LSP>
[ <P2MP SECONDARY_EXPLICIT_ROUTE> ]
Each LSR MUST use the common objects in the Path message and the S2L sub-LSP descriptors to process each S2L sub-LSP represented by the S2L_SUB_LSP object and the SECONDARY-/EXPLICIT_ROUTE object combination.
各LSRは、パスメッセージ内の共通オブジェクトとS2LサブLSP記述子を使用して、S2L_SUB_LSPオブジェクトとセカンダリ/expricit_Routeオブジェクトの組み合わせで表される各S2LサブLSPを処理する必要があります。
Per the definition of <S2L sub-LSP descriptor>, each S2L_SUB_LSP object MAY be followed by a corresponding SERO. The first S2L_SUB_LSP object is a special case, and its explicit route is specified by the ERO. Therefore, the first S2L_SUB_LSP object SHOULD NOT be followed by an SERO, and if one is present, it MUST be ignored.
<s2l sub-lsp記述子>の定義に従って、各S2L_SUB_LSPオブジェクトの後に対応するSEROが続く場合があります。最初のS2L_SUB_LSPオブジェクトは特別なケースであり、その明示的なルートはEROによって指定されています。したがって、最初のS2L_SUB_LSPオブジェクトの後にSeroを使用しないでください。また、存在する場合は無視する必要があります。
The RRO in the sender descriptor contains the upstream hops traversed by the Path message and applies to all the S2L sub-LSPs signaled in the Path message.
送信者記述子のRROには、パスメッセージが通過するアップストリームホップが含まれており、パスメッセージで信号を送られたすべてのS2L Sub-LSPに適用されます。
An IF_ID RSVP_HOP object MUST be used on links where there is not a one-to-one association of a control channel to a data channel [RFC3471]. An RSVP_HOP object defined in [RFC2205] SHOULD be used otherwise.
IF_ID RSVP_HOPオブジェクトは、コントロールチャネルとデータチャネル[RFC3471]との1対1の関連性がないリンクで使用する必要があります。[RFC2205]で定義されているRSVP_HOPオブジェクトは、そうでなければ使用する必要があります。
Path message processing is described in the next section.
パスメッセージ処理については、次のセクションで説明します。
The ingress LSR initiates the setup of an S2L sub-LSP to each egress LSR that is a destination of the P2MP LSP. Each S2L sub-LSP is associated with the same P2MP LSP using common P2MP SESSION object and <Sender Address, LSP-ID> fields in the P2MP SENDER_TEMPLATE object. Hence, it can be combined with other S2L sub-LSPs to form a P2MP LSP. Another S2L sub-LSP belonging to the same instance of this S2L sub-LSP (i.e., the same P2MP LSP) SHOULD share resources with this S2L sub-LSP. The session corresponding to the P2MP TE tunnel is determined based on the P2MP SESSION object. Each S2L sub-LSP is identified using the S2L_SUB_LSP object. Explicit routing for the S2L sub-LSPs is achieved using the ERO and SEROs.
Ingress LSRは、P2MP LSPの宛先である各出力LSRへのS2LサブLSPのセットアップを開始します。各S2LサブLSPは、P2MP Sender_Templateオブジェクトの一般的なP2MPセッションオブジェクトと<Senderアドレス、LSP-ID>フィールドを使用して、同じP2MP LSPに関連付けられています。したがって、他のS2L Sub-LSPと組み合わせてP2MP LSPを形成できます。このS2L Sub-LSP（つまり、同じP2MP LSP）の同じインスタンスに属する別のS2LサブLSPは、このS2L Sub-LSPとリソースを共有する必要があります。P2MP TEトンネルに対応するセッションは、P2MPセッションオブジェクトに基づいて決定されます。各S2LサブLSPは、S2L_SUB_LSPオブジェクトを使用して識別されます。S2L Sub-LSPの明示的なルーティングは、EROとSEROSを使用して達成されます。
As mentioned earlier, it is possible to signal S2L sub-LSPs for a given P2MP LSP in one or more Path messages, and a given Path message can contain one or more S2L sub-LSPs. An LSR that supports RSVP-TE signaled P2MP LSPs MUST be able to receive and process multiple Path messages for the same P2MP LSP and multiple S2L sub-LSPs in one Path message. This implies that such an LSR MUST be able to receive and process all objects listed in section 19.
前述のように、1つ以上のパスメッセージで特定のP2MP LSPのS2L Sub-LSPSを信号することができ、特定のパスメッセージには1つ以上のS2L Sub-LSPを含めることができます。RSVP-TEシグナル付きP2MP LSPをサポートするLSRは、同じP2MP LSPおよび複数のS2L Sub-LSPの複数のパスメッセージを1つのパスメッセージで受信および処理できる必要があります。これは、そのようなLSRがセクション19にリストされているすべてのオブジェクトを受信して処理できる必要があることを意味します。
As described in section 4, either the < [<EXPLICIT_ROUTE>]
<S2L_SUB_LSP> > or the < [<P2MP SECONDARY_EXPLICIT_ROUTE>]
<S2L_SUB_LSP> > tuple is used to specify an S2L sub-LSP. Multiple
Path messages can be used to signal a P2MP LSP. Each Path message
can signal one or more S2L sub-LSPs. If a Path message contains only
one S2L sub-LSP, each LSR along the S2L sub-LSP follows [RFC3209]
procedures for processing the Path message besides the S2L_SUB_LSP
object processing described in this document.
Processing of Path messages containing more than one S2L sub-LSP is described in section 5.2.2.
複数のS2LサブLSPを含むパスメッセージの処理については、セクション5.2.2で説明しています。
An ingress LSR MAY use multiple Path messages for signaling a P2MP LSP. This may be because a single Path message may not be large enough to signal the P2MP LSP. Or it may be that when new leaves are added to the P2MP LSP, they are signaled in a new Path message. Or an ingress LSR MAY choose to break the P2MP tree into separate manageable P2MP trees. These trees share the same root and may share the trunk and certain branches. The scope of this management decomposition of P2MP trees is bounded by a single tree (the P2MP Tree) and multiple trees with a single leaf each (S2L sub-LSPs). Per [RFC4461], a P2MP LSP MUST have consistent attributes across all portions of a tree. This implies that each Path message that is used to signal a P2MP LSP is signaled using the same signaling attributes with the exception of the S2L sub-LSP descriptors and Sub-Group identifier.
Ingress LSRは、P2MP LSPを信号するために複数のパスメッセージを使用する場合があります。これは、単一のパスメッセージがP2MP LSPを通知するほど大きくない可能性があるためかもしれません。または、新しい葉がP2MP LSPに追加されると、新しいパスメッセージで通知される可能性があります。または、侵入LSRは、P2MPツリーを別々の管理可能なP2MPツリーに分割することを選択する場合があります。これらの木は同じ根を共有し、トランクと特定の枝を共有する場合があります。P2MPツリーのこの管理分解の範囲は、単一の木（P2MPツリー）とそれぞれ単一の葉（S2L Sub-LSP）を持つ複数のツリーに囲まれています。[RFC4461]に従って、P2MP LSPは、ツリーのすべての部分にわたって一貫した属性を持たなければなりません。これは、S2LサブLSP記述子とサブグループ識別子を除き、同じシグナル属性を使用してP2MP LSPを信号に信号するために使用される各パスメッセージがシグナル伝達されることを意味します。
The resulting sub-LSPs from the different Path messages belonging to the same P2MP LSP SHOULD share labels and resources where they share hops to prevent multiple copies of the data being sent.
同じP2MP LSPに属する異なるパスメッセージから得られたサブLSPは、送信されるデータの複数のコピーを防ぐためにホップを共有するラベルとリソースを共有する必要があります。
In certain cases, a transit LSR may need to generate multiple Path messages to signal state corresponding to a single received Path message. For instance ERO expansion may result in an overflow of the resultant Path message. In this case, the message can be decomposed into multiple Path messages such that each message carries a subset of the X2L sub-tree carried by the incoming message.
特定の場合、Transit LSRは、単一の受信パスメッセージに対応する信号状態に複数のパスメッセージを生成する必要がある場合があります。たとえば、EROの拡張により、結果のパスメッセージがオーバーフローする場合があります。この場合、メッセージは複数のパスメッセージに分解することができ、各メッセージが着信メッセージによって運ばれるX2Lサブツリーのサブセットを運ぶようにします。
Multiple Path messages generated by an LSR that signal state for the same P2MP LSP are signaled with the same SESSION object and have the same <Source address, LSP-ID> in the SENDER_TEMPLATE object. In order to disambiguate these Path messages, a <Sub-Group Originator ID, Sub- Group ID> tuple is introduced (also referred to as the Sub-Group fields) and encoded in the SENDER_TEMPLATE object. Multiple Path messages generated by an LSR to signal state for the same P2MP LSP have the same Sub-Group Originator ID and have a different sub-Group ID. The Sub-Group Originator ID MUST be set to the TE Router ID of the LSR that originates the Path message. Cases when a transit LSR may change the Sub-Group Originator ID of an incoming Path message are described below. The Sub-Group Originator ID is globally unique. The Sub-Group ID space is specific to the Sub-Group Originator ID.
同じP2MP LSPの信号状態を信号するLSRによって生成された複数のパスメッセージは、同じセッションオブジェクトで信号され、Sender_Templateオブジェクトに同じ<ソースアドレスlsp-id>を持っています。これらのパスメッセージを明確にするために、<サブグループオリジナルID、サブグループID> tupleが導入され（サブグループフィールドとも呼ばれます）、sender_templateオブジェクトでエンコードされます。LSRによって生成された複数のパスメッセージは、同じP2MP LSPに対して信号状態に合わせて同じサブグループオリジネーターIDを持ち、異なるサブグループIDを持っています。サブグループのオリジナルIDは、パスメッセージを発信するLSRのTEルーターIDに設定する必要があります。トランジットLSRが着信パスメッセージのサブグループオリジネーターIDを変更する場合を以下に説明します。サブグループのオリジナルIDはグローバルに一意です。サブグループIDスペースは、サブグループのオリジネーターIDに固有です。
The S2L sub-LSP descriptor list allows the signaling of one or more S2L sub-LSPs in one Path message. Each S2L sub-LSP descriptor describes a single S2L sub-LSP.
S2L Sub-LSP記述子リストは、1つのパスメッセージに1つ以上のS2L Sub-LSPを信号することができます。各S2LサブLSP記述子は、単一のS2LサブLSPを記述します。
All LSRs MUST process the ERO corresponding to the first S2L sub-LSP if the ERO is present. If one or more SEROs are present, an ERO MUST be present. The first S2L sub-LSP MUST be propagated in a Path message by each LSR along the explicit route specified by the ERO, if the ERO is present. Else it MUST be propagated using hop-by-hop routing towards the destination identified by the S2L_SUB_LSP object.
すべてのLSRは、EROが存在する場合、最初のS2LサブLSPに対応するEROを処理する必要があります。1つ以上のSerosが存在する場合、EROが存在する必要があります。EROが存在する場合、最初のS2LサブLSPは、EROで指定された明示的なルートに沿った各LSRによってパスメッセージに伝播する必要があります。それ以外の場合は、S2L_SUB_LSPオブジェクトによって識別される宛先に向けてホップバイホップルーティングを使用して伝播する必要があります。
An LSR MUST process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP as follows:
LSRは、次のように次のS2LサブLSPのS2LサブLSP記述子を処理する必要があります。
If the S2L_SUB_LSP object is followed by an SERO, the LSR MUST check the first hop in the SERO:
S2L_SUB_LSPオブジェクトの後にSEROが続く場合、LSRはSeroの最初のホップを確認する必要があります。
- If the first hop of the SERO identifies a local address of the LSR, and the LSR is also the egress identified by the S2L_SUB_LSP object, the descriptor MUST NOT be propagated downstream, but the SERO may be used for egress control per [RFC4003].
- SEROの最初のホップがLSRのローカルアドレスを識別し、LSRがS2L_SUB_LSPオブジェクトによって識別される出力である場合、記述子を下流に伝播することはできませんが、SEROは[RFC4003]ごとに出口制御に使用できます。
- If the first hop of the SERO identifies a local address of the LSR, and the LSR is not the egress as identified by the S2L_SUB_LSP object, the S2L sub-LSP descriptor MUST be included in a Path message sent to the next-hop determined from the SERO.
- SEROの最初のホップがLSRのローカルアドレスを識別し、LSRがS2L_SUB_LSPオブジェクトで識別された出力ではない場合、S2LサブLSP記述子は、セロ。
- If the first hop of the SERO is not a local address of the LSR, the S2L sub-LSP descriptor MUST be included in the Path message sent to the LSR that is the next hop to reach the first hop in the SERO. This next hop is determined by using the ERO or other SEROs that encode the path to the SERO's first hop.
- SEROの最初のホップがLSRのローカルアドレスではない場合、S2LサブLSP記述子は、SEROの最初のホップに到達する次のホップであるLSRに送信されたパスメッセージに含める必要があります。この次のホップは、Seroの最初のホップへのパスをエンコードするEROまたは他のSerosを使用することによって決定されます。
If the S2L_SUB_LSP object is not followed by an SERO, the LSR MUST examine the S2L_SUB_LSP object:
S2L_SUB_LSPオブジェクトの後にSEROが続いていない場合、LSRはS2L_SUB_LSPオブジェクトを調べる必要があります。
- If this LSR is the egress as identified by the S2L_SUB_LSP object, the S2L sub-LSP descriptor MUST NOT be propagated downstream.
- このLSRがS2L_SUB_LSPオブジェクトで識別される出力である場合、S2LサブLSP記述子を下流に伝播することはできません。
- If this LSR is not the egress as identified by the S2L_SUB_LSP object, the LSR MUST make a routing decision to determine the next hop towards the egress, and MUST include the S2L sub-LSP descriptor in a Path message sent to the next-hop towards the egress. In this case, the LSR MAY insert an SERO into the S2L sub-LSP descriptor.
- このLSRがS2L_SUB_LSPオブジェクトによって識別された出口でない場合、LSRは次のホップを決定するためのルーティング決定を行う必要があり、次のホップに送られたパスメッセージにS2LサブLSP記述子を含める必要があります。出口。この場合、LSRはS2L Sub-LSP記述子にSEROを挿入する場合があります。
Hence, a branch LSR MUST only propagate the relevant S2L sub-LSP descriptors to each downstream hop. An S2L sub-LSP descriptor list that is propagated on a downstream link MUST only contain those S2L sub-LSPs that are routed using that hop. This processing MAY result in a subsequent S2L sub-LSP in an incoming Path message becoming the first S2L sub-LSP in an outgoing Path message.
したがって、分岐LSRは、各下流ホップに関連するS2LサブLSP記述子を伝播するだけです。下流のリンクで伝播されるS2LサブLSP記述子リストには、そのホップを使用してルーティングされるS2LサブLSPのみを含める必要があります。この処理により、着信パスメッセージの後続のS2LサブLSPが発信パスメッセージの最初のS2LサブLSPになる可能性があります。
Note that if one or more SEROs contain loose hops, expansion of such loose hops MAY result in overflowing the Path message size. section 5.2.3 describes how signaling of the set of S2L sub-LSPs can be split across more than one Path message.
1つ以上のSeroがルーズホップが含まれている場合、そのようなルーズホップを拡張すると、パスメッセージサイズが溢れる可能性があることに注意してください。セクション5.2.3では、S2L Sub-LSPのセットのシグナル伝達を複数のパスメッセージに分割する方法について説明します。
The RECORD_ROUTE Object (RRO) contains the hops traversed by the Path message and applies to all the S2L sub-LSPs signaled in the Path message. A transit LSR MUST append its address in an incoming RRO and propagate it downstream. A branch LSR MUST form a new RRO for each of the outgoing Path messages by copying the RRO from the incoming Path message and appending its address. Each such updated RRO MUST be formed using the rules in [RFC3209] (and updated by [RFC3473]), as appropriate.
RECORD_ROUTEオブジェクト（RRO）には、パスメッセージが通過するホップが含まれ、パスメッセージで信号が表示されるすべてのS2L Sub-LSPに適用されます。トランジットLSRは、その住所を着信RROに追加し、下流に伝播する必要があります。ブランチLSRは、着信パスメッセージからRROをコピーし、アドレスを追加することにより、発信パスメッセージのそれぞれに新しいRROを形成する必要があります。必要に応じて、[RFC3209]のルール（および[RFC3473]によって更新）を使用して、そのような更新された各RROを形成する必要があります。
If an LSR is unable to support an S2L sub-LSP in a Path message (for example, it is unable to route towards the destination using the SERO), a PathErr message MUST be sent for the impacted S2L sub-LSP, and normal processing of the rest of the P2MP LSP SHOULD continue. The default behavior is that the remainder of the LSP is not impacted (that is, all other branches are allowed to set up) and the failed branches are reported in PathErr messages in which the Path_State_Removed flag MUST NOT be set. However, the ingress LSR may set an LSP Integrity flag to request that if there is a setup failure on any branch, the entire LSP should fail to set up. This is described further in sections 5.2.4 and 11.
LSRがパスメッセージでS2LサブLSPをサポートできない場合（たとえば、SEROを使用して目的地に向かってルーティングできない場合）P2MP LSPの残りの部分のうち、続行する必要があります。デフォルトの動作は、LSPの残りの影響が影響されないこと（つまり、他のすべてのブランチがセットアップされることが許可されていない）であり、故障したブランチは、path_state_removedフラグを設定してはならないpatherrメッセージで報告されています。ただし、Ingress LSRは、LSP整合性フラグを設定して、ブランチにセットアップ障害がある場合、LSP全体がセットアップに失敗することを要求する場合があります。これについては、セクション5.2.4および11でさらに説明します。
In certain cases, a transit LSR may need to generate multiple Path messages to signal state corresponding to a single received Path message. For instance, ERO expansion may result in an overflow of the resultant Path message. RSVP [RFC2205] disallows the use of IP fragmentation, and thus IP fragmentation MUST be avoided in this case. In order to achieve this, the multiple Path messages generated by the transit LSR are signaled with the Sub-Group Originator ID set to the TE Router ID of the transit LSR and with a distinct Sub-Group ID for each Path message. Thus, each distinct Path message that is generated by the transit LSR for the P2MP LSP carries a distinct <Sub-Group Originator ID, Sub-Group ID> tuple.
特定の場合、Transit LSRは、単一の受信パスメッセージに対応する信号状態に複数のパスメッセージを生成する必要がある場合があります。たとえば、EROの拡張により、結果のパスメッセージがオーバーフローする場合があります。RSVP [RFC2205]はIP断片化の使用を許可するため、この場合はIP断片化を避ける必要があります。これを達成するために、トランジットLSRによって生成された複数のパスメッセージは、トランジットLSRのTEルーターIDに設定されたサブグループオリジナルIDと、各パスメッセージの個別のサブグループIDで信号を送ります。したがって、P2MP LSPのTransit LSRによって生成される各個別のパスメッセージには、異なる<サブグループオリジネーターID、サブグループID> Tupleが含まれます。
When multiple Path messages are used by an ingress or transit node, each Path message SHOULD be identical with the exception of the S2L sub-LSP related descriptor (e.g., SERO), message and hop information (e.g., INTEGRITY, MESSAGE_ID, and RSVP_HOP), and the Sub-Group fields of the SENDER_TEMPLATE objects. Except when a make-before-break operation is being performed (as specified in section 14.1), the tunnel sender address and LSP ID fields MUST be the same in each message. For transit nodes, they MUST be the same as the values in the received Path message.
複数のパスメッセージがイングレスまたはトランジットノードで使用される場合、各パスメッセージは、S2LサブLSP関連記述子（Seroなど）、メッセージ、ホップ情報（Integrity、Message_id、RSVP_HOPなど）を除き、同一である必要があります。、およびsender_templateオブジェクトのサブグループフィールド。ブレイク前の操作が実行されている場合を除き（セクション14.1で指定されているように）、トンネル送信者アドレスとLSP IDフィールドは各メッセージで同じでなければなりません。トランジットノードの場合、それらは受信されたパスメッセージの値と同じでなければなりません。
As described above, one case in which the Sub-Group Originator ID of a received Path message is changed is that of fragmentation of a Path message at a transit node. Another case is when the Sub-Group Originator ID of a received Path message may be changed in the outgoing Path message and set to that of the LSR originating the Path message based on a local policy. For instance, an LSR may decide to always change the Sub-Group Originator ID while performing ERO expansion. The Sub-Group ID MUST not be changed if the Sub-Group Originator ID is not changed.
上記のように、受信したパスメッセージのサブグループオリジネーターIDが変更される1つのケースは、トランジットノードでのパスメッセージの断片化の1つです。別のケースは、受信したパスメッセージのサブグループオリジネーターIDが発信パスメッセージで変更され、ローカルポリシーに基づいてパスメッセージを発信するLSRのそれに設定する場合です。たとえば、LSRは、ERO拡張を実行している間、常にサブグループのオリジネーターIDを変更することを決定する場合があります。サブグループのオリジナルIDが変更されない場合、サブグループIDを変更してはなりません。
An ingress LSR can control the behavior of an LSP if there is a failure during LSP setup or after an LSP has been established. The default behavior is that only the branches downstream of the failure are not established, but the ingress may request 'LSP integrity' such that any failure anywhere within the LSP tree causes the entire P2MP LSP to fail.
Ingress LSRは、LSPセットアップ中またはLSPが確立された後に障害が発生した場合、LSPの動作を制御できます。デフォルトの動作は、故障の下流の分岐のみが確立されていないことですが、侵入は「LSPの完全性」を要求する可能性があり、LSPツリー内のどこにでも障害がP2MP LSP全体を失敗させるようにします。
The ingress LSP may request 'LSP integrity' by setting bit 3 of the Attributes Flags TLV. The bit is set if LSP integrity is required.
Ingress LSPは、属性フラグTLVのビット3を設定することにより、「LSPの整合性」を要求できます。LSPの整合性が必要な場合は、ビットが設定されます。
It is RECOMMENDED to use the LSP_REQUIRED_ATTRIBUTES object [RFC4420].
lsp_required_attributesオブジェクト[RFC4420]を使用することをお勧めします。
A branch LSR that supports the Attributes Flags TLV and recognizes this bit MUST support LSP integrity or reject the LSP setup with a PathErr message carrying the error "Routing Error"/"Unsupported LSP Integrity".
属性Flags TLVをサポートし、このビットを認識するブランチLSRは、LSPの整合性をサポートする必要があるか、「ルーティングエラー」/「サポートされていないLSPの完全性」を掲載したエラーメッセージでLSPセットアップを拒否する必要があります。
The operation of adding egress LSR(s) to an existing P2MP LSP is termed grafting. This operation allows egress nodes to join a P2MP LSP at different points in time.
既存のP2MP LSPに出口LSRを追加する動作は、グラフトと呼ばれます。この操作により、出力ノードはさまざまな時点でP2MP LSPに結合できます。
There are two methods to add S2L sub-LSPs to a P2MP LSP. The first is to add new S2L sub-LSPs to the P2MP LSP by adding them to an existing Path message and refreshing the entire Path message. Path message processing described in section 4 results in adding these S2L sub-LSPs to the P2MP LSP. Note that as a result of adding one or more S2L sub-LSPs to a Path message, the ERO compression encoding may have to be recomputed.
P2MP LSPにS2L Sub-LSPを追加する2つの方法があります。1つ目は、既存のパスメッセージにそれらを追加し、パスメッセージ全体を更新することにより、新しいS2LサブLSPをP2MP LSPに追加することです。セクション4で説明されているパスメッセージ処理により、これらのS2LサブLSPがP2MP LSPに追加されます。パスメッセージに1つ以上のS2LサブLSPを追加した結果、ERO圧縮エンコードを再計算する必要がある場合があることに注意してください。
The second is to use incremental updates described in section 10.1. The egress LSRs can be added by signaling only the impacted S2L sub-LSPs in a new Path message. Hence, other S2L sub-LSPs do not have to be re-signaled.
2つ目は、セクション10.1で説明されている増分更新を使用することです。出力LSRは、新しいパスメッセージで衝撃を受けたS2L Sub-LSPのみを信号することで追加できます。したがって、他のS2LサブLSPは再署名する必要はありません。
The Resv message follows the [RFC3209] and [RFC3473] format:
RESVメッセージは、[RFC3209]および[RFC3473]形式に従います。
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FF flow descriptor>
| <FF flow descriptor list>
<FF flow descriptor>
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
The FF flow descriptor and SE filter spec are modified as follows to identify the S2L sub-LSPs that they correspond to:
FFフロー記述子とSEフィルター仕様は、次のS2LサブLSPを識別するために次のように変更されています。
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<S2L sub-LSP flow descriptor list> ::=
<S2L sub-LSP flow descriptor>
[ <S2L sub-LSP flow descriptor list> ]
<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
[ <P2MP_SECONDARY_RECORD_ROUTE> ]
FILTER_SPEC is defined in section 19.4.
Filter_Specはセクション19.4で定義されています。
The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP descriptor in section 4.1 with the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP SECONDARY_EXPLICIT_ROUTE object. The P2MP_SECONDARY_RECORD_ROUTE objects follow the same compression mechanism as the P2MP SECONDARY_EXPLICIT_ROUTE objects. Note that a Resv message can signal multiple S2L sub-LSPs that may belong to the same FILTER_SPEC object or different FILTER_SPEC objects. The same label SHOULD be allocated if the <Sender Address, LSP-ID> fields of the FILTER_SPEC object are the same.
S2LサブLSPフロー記述子は、P2MP_Secondary_Record_RouteオブジェクトがP2MP Secondary_explicit_Routeオブジェクトの代わりに使用されるという違いを持つ、セクション4.1のS2L Sub-LSP記述子と同じ形式を持っています。P2MP_SECONDARY_RECORD_ROUTEオブジェクトは、P2MP Secondar_Explicit_Routeオブジェクトと同じ圧縮メカニズムに従います。RESVメッセージは、同じfilter_specオブジェクトまたは異なるfilter_specオブジェクトに属する可能性のある複数のS2L Sub-LSPを信号することができることに注意してください。<senderアドレス、lsp-id> filter_specオブジェクトのフィールドが同じ場合、同じラベルを割り当てる必要があります。
However different labels MUST be allocated if the <Sender Address, LSP-ID> of the FILTER_SPEC object is different, as that implies that the FILTER_SPEC refers to a different P2MP LSP.
ただし、filter_specオブジェクトの<senderアドレス、lsp-id>が異なる場合は、異なるラベルを割り当てる必要があります。
The egress LSR MUST follow normal RSVP procedures while originating a Resv message. The format of Resv messages is as defined in section 6.1. As usual, the Resv message carries the label allocated by the egress LSR.
出力LSRは、RESVメッセージを発信しながら、通常のRSVP手順に従う必要があります。RESVメッセージの形式は、セクション6.1で定義されています。いつものように、RESVメッセージには、Egress LSRによって割り当てられたラベルが含まれています。
A node upstream of the egress node MUST allocate its own label and pass it upstream in the Resv message. The node MAY combine multiple flow descriptors, from different Resv messages received from downstream, in one Resv message sent upstream. A Resv message MUST NOT be sent upstream until at least one Resv message has been received from a downstream neighbor. When the integrity bit is set in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent upstream until all Resv messages have been received from the downstream neighbors.
出力ノードの上流のノードは、独自のラベルを割り当て、RESVメッセージに上流を渡す必要があります。ノードは、下流から受信した異なるRESVメッセージから、上流の1つのRESVメッセージから複数のフロー記述子を組み合わせることができます。下流の隣人から少なくとも1つのRESVメッセージが受信されるまで、RESVメッセージを上流に送信しないでください。整合性ビットがlsp_required_attributeオブジェクトに設定されている場合、すべてのRESVメッセージが下流の近隣から受信されるまで、RESVメッセージを上流に送信してはなりません。
Each Fixed-Filter (FF) flow descriptor or Shared-Explicit (SE) filter spec sent upstream in a Resv message includes an S2L sub-LSP descriptor list. Each such FF flow descriptor or SE filter spec for the same P2MP LSP (whether on one or multiple Resv messages) on the same Resv MUST be allocated the same label, and FF flow descriptors or SE filter specs SHOULD use the same label across multiple Resv messages.
RESVメッセージで上流に送信された各固定フィルター（FF）フロー記述子または共有エクスプリティ（SE）フィルター仕様には、S2LサブLSP記述子リストが含まれています。同じP2MP LSP（1つまたは複数のRESVメッセージを使用しているかどうか）のそのようなFFフロー記述子またはSEフィルター仕様それぞれ同じRESVで同じラベルを割り当てる必要があり、FFフロー記述子またはSEフィルター仕様は複数のRESVにわたって同じラベルを使用する必要がありますメッセージ。
The node that sends the Resv message, for a P2MP LSP, upstream MUST associate the label assigned by this node with all the labels received from downstream Resv messages, for that P2MP LSP. Note that a transit node may become a replication point in the future when a branch is attached to it. Hence, this results in the setup of a P2MP LSP from the ingress LSR to the egress LSRs.
P2MP LSPのRESVメッセージを送信するノードは、このノードによって割り当てられたラベルを、そのP2MP LSPの下流のRESVメッセージから受信したすべてのラベルに関連付ける必要があります。トランジットノードは、ブランチが接続されているときに将来的に複製ポイントになる可能性があることに注意してください。したがって、これにより、イングレスLSRから出力LSRへのP2MP LSPが設定されます。
The ingress LSR may need to understand when all desired egresses have been reached. This is achieved using S2L_SUB_LSP objects.
Ingress LSRは、すべての望ましい出力に到達したときに理解する必要がある場合があります。これは、S2L_SUB_LSPオブジェクトを使用して達成されます。
Each branch node MAY forward a single Resv message upstream for each received Resv message from a downstream receiver. Note that there may be a large number of Resv messages at and close to the ingress LSR for an LSP with many receivers. A branch LSR SHOULD combine Resv state from multiple receivers into a single Resv message to be sent upstream (see section 6.2.1). However, note that this may result in overflowing the Resv message, particularly as the number of receivers downstream of any branch LSR increases as the LSR is closer to the ingress LSR. Thus, a branch LSR MAY choose to send more than one Resv message upstream and partition the Resv state between the messages.
各ブランチノードは、ダウンストリームレシーバーから受信したRESVメッセージごとに上流の単一のRESVメッセージを転送できます。多くのレシーバーを備えたLSPのIngress LSRに多数のRESVメッセージが存在する可能性があることに注意してください。Branch LSRは、複数の受信機からRESV状態を単一のRESVメッセージに組み合わせて上流に送信する必要があります（セクション6.2.1を参照）。ただし、特にLSRがイングレスLSRに近いため、Branch LSRの下流のレシーバーの数が増加するため、これによりRESVメッセージがオーバーフローされる可能性があることに注意してください。したがって、Branch LSRは、複数のRESVメッセージを上流に送信し、メッセージ間でRESV状態を分割することを選択できます。
When a transit node sets the Sub-Group Originator field in a Path message, it MUST replace the Sub-Group fields received in the FILTER_SPEC objects of any associated Resv messages with the value that it originally received in the Sub-Group fields of the Path message from the upstream neighbor.
トランジットノードがパスメッセージにサブグループオリジナルフィールドを設定する場合、関連するRESVメッセージのfilter_specオブジェクトで受信したサブグループフィールドを、パスのサブグループフィールドで最初に受信した値に置き換える必要があります。上流の隣人からのメッセージ。
ResvErr message generation is unmodified. Nodes propagating a received ResvErr message MUST use the Sub-Group field values carried in the corresponding Resv message.
RESVERRメッセージの生成は修正されていません。受信したRESVERRメッセージを伝播するノードは、対応するRESVメッセージに掲載されたサブグループフィールド値を使用する必要があります。
A branch node may have to send a revised Resv message upstream whenever there is a change in a Resv message for an S2L sub-LSP received from one of the downstream neighbors. This can result in excessive Resv messages sent upstream, particularly when the S2L sub-LSPs are first established. In order to mitigate this situation, branch nodes can limit their transmission of Resv messages. Specifically, in the case where the only change being sent in a Resv message is in one or more P2MP_SECONDARY_RECORD_ROUTE objects (SRROs), the branch node SHOULD transmit the Resv message only after a delay time has passed since the transmission of the previous Resv message for the same session. This delayed Resv message SHOULD include SRROs for all branches. A suggested value for the delay time is thirty seconds, and delay times SHOULD generally be longer than 1 second. Specific mechanisms for Resv message throttling and delay timer settings are implementation dependent and are outside the scope of this document.
ブランチノードは、下流の近隣の1人から受信したS2LサブLSPのRESVメッセージに変更がある場合は、上流のRESVメッセージを上流に送信する必要がある場合があります。これにより、特にS2L Sub-LSPが最初に確立されたときに、上流に送信される過剰なRESVメッセージが発生する可能性があります。この状況を軽減するために、ブランチノードはRESVメッセージの送信を制限できます。具体的には、RESVメッセージで送信される唯一の変更が1つ以上のP2MP_SECONDARY_RECORD_ROUTEオブジェクト（SRROS）にある場合、ブランチノードは、以前のRESVメッセージの送信以来遅延時間が経過した後にのみRESVメッセージを送信する必要があります。同じセッション。この遅延RESVメッセージには、すべてのブランチのSRROSを含める必要があります。遅延時間の推奨値は30秒であり、遅延時間は通常1秒より長くなるはずです。RESVメッセージのスロットリングおよび遅延タイマー設定の特定のメカニズムは実装に依存し、このドキュメントの範囲外です。
A Resv message for a P2P LSP contains a recorded route if the ingress LSR requested route recording by including an RRO in the original Path message. The same rule is used during signaling of P2MP LSPs. That is, inclusion of an RRO in the Path message used to signal one or more S2L sub-LSPs triggers the inclusion of a recorded route for each sub-LSP in the Resv message.
P2P LSPのRESVメッセージには、元のパスメッセージにRROを含めることにより、Ingress LSRがルート録画を要求した場合、記録されたルートが含まれます。P2MP LSPのシグナル伝達中に同じルールが使用されます。つまり、1つ以上のS2LサブLSPを信号に信号するために使用されるパスメッセージにRROを含めると、RESVメッセージの各サブLSPに記録されたルートが含まれています。
The recorded route of the first S2L sub-LSP is encoded in the RRO. Additional recorded routes for the subsequent S2L sub-LSPs are encoded in P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). Their format is specified in section 19.5. Each S2L_SUB_LSP object in a Resv is associated with an RRO or SRRO. The first S2L_SUB_LSP object (for the first S2L sub-LSP) is associated with the RRO. Subsequent S2L_SUB_LSP objects (for subsequent S2L sub-LSPs) are each followed by an SRRO that contains the recorded route for that S2L sub-LSP from the leaf to a branch. The ingress node can then use the RRO and SRROs to determine the end-to-end path for each S2L sub-LSP.
最初のS2LサブLSPの記録されたルートは、RROでエンコードされています。後続のS2L Sub-LSPの追加の記録されたルートは、P2MP_SECONDARY_RECORD_ROUTEオブジェクト（SRROS）でエンコードされています。それらの形式は、セクション19.5で指定されています。RESVの各S2L_SUB_LSPオブジェクトは、RROまたはSRROに関連付けられています。最初のS2L_SUB_LSPオブジェクト（最初のS2LサブLSP用）はRROに関連付けられています。その後のS2L_SUB_LSPオブジェクト（後続のS2L Sub-LSPの場合）には、それぞれ葉から枝までのS2LサブLSPの記録されたルートを含むSRROが続きます。Ingressノードは、RROとSRROSを使用して、各S2LサブLSPのエンドツーエンドパスを決定できます。
Considerations about the reservation style in a Resv message apply as described in [RFC3209]. The reservation style in the Resv messages can be either FF or SE. All P2MP LSPs that belong to the same P2MP Tunnel MUST be signaled with the same reservation style. Irrespective of whether the reservation style is FF or SE, the S2L sub-LSPs that belong to the same P2MP LSP SHOULD share labels where they share hops. If the S2L sub-LSPs that belong to the same P2MP LSP share labels then they MUST share resources. If the reservation style is FF, then S2L sub-LSPs that belong to different P2MP LSPs MUST NOT share resources or labels. If the reservation style is SE, then S2L sub-LSPs that belong to different P2MP LSPs and the same P2MP tunnel SHOULD share resources where they share hops, but they MUST not share labels in packet environments.
[RFC3209]に記載されているように、RESVメッセージの予約スタイルに関する考慮事項が適用されます。RESVメッセージの予約スタイルは、FFまたはSEのいずれかです。同じP2MPトンネルに属するすべてのP2MP LSPは、同じ予約スタイルで通知する必要があります。予約スタイルがFFまたはSEであるかどうかに関係なく、同じP2MP LSPに属するS2LサブLSPは、ホップを共有する場合にラベルを共有する必要があります。同じP2MP LSP共有ラベルに属するS2LサブLSPがラベルを共有する場合、リソースを共有する必要があります。予約スタイルがFFの場合、異なるP2MP LSPに属するS2LサブLSPは、リソースやラベルを共有してはなりません。予約スタイルがSEの場合、異なるP2MP LSPに属するS2LサブLSPと同じP2MPトンネルは、ホップを共有する場合にリソースを共有する必要がありますが、パケット環境でラベルを共有してはなりません。
The format of the PathTear message is as follows:
PathTearメッセージの形式は次のとおりです。
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
[ [ <MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK> ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
[ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor list> ::= <S2L_SUB_LSP>
[ <S2L sub-LSP descriptor list> ]
The definition of <sender descriptor> is not changed by this document.
<sender descriptor>の定義は、このドキュメントによって変更されません。
The operation of removing egress LSR(s) from an existing P2MP LSP is termed as pruning. This operation allows egress nodes to be removed from a P2MP LSP at different points in time. This section describes the mechanisms to perform pruning.
既存のP2MP LSPから出口LSRを除去する動作は、剪定と呼ばれます。この操作により、出力ノードは、さまざまな時点でP2MP LSPから削除できます。このセクションでは、剪定を実行するメカニズムについて説明します。
Implicit teardown uses standard RSVP message processing. Per standard RSVP processing, an S2L sub-LSP may be removed from a P2MP TE LSP by sending a modified message for the Path or Resv message that previously advertised the S2L sub-LSP. This message MUST list all S2L sub-LSPs that are not being removed. When using this approach, a node processing a message that removes an S2L sub-LSP from a P2MP TE LSP MUST ensure that the S2L sub-LSP is not included in any other Path state associated with session before interrupting the data path to that egress. All other message processing remains unchanged.
暗黙的な涙は、標準のRSVPメッセージ処理を使用します。標準のRSVP処理ごとに、S2LサブLSPまたは以前にS2LサブLSPを宣伝したPATHまたはRESVメッセージの変更されたメッセージを送信することにより、S2LサブLSPをP2MP TE LSPから削除することができます。このメッセージは、削除されていないすべてのS2LサブLSPをリストする必要があります。このアプローチを使用する場合、P2MP TE LSPからS2LサブLSPを削除するメッセージを処理するノードは、その出口へのデータパスを中断する前に、S2LサブLSPがセッションに関連付けられた他のパス状態に含まれていないことを確認する必要があります。他のすべてのメッセージ処理は変更されていません。
When implicit teardown is used to delete one or more S2L sub-LSPs, by modifying a Path message, a transit LSR may have to generate a PathTear message downstream to delete one or more of these S2L sub-LSPs. This can happen if as a result of the implicit deletion of S2L sub-LSP(s) there are no remaining S2L sub-LSPs to send in the corresponding Path message downstream.
暗黙の断片を使用して1つ以上のS2L Sub-LSPを削除する場合、パスメッセージを変更することにより、トランジットLSRは、これらのS2LサブLSPの1つ以上を削除するためにPathTearメッセージを下流に生成する必要がある場合があります。これは、S2L Sub-LSPの暗黙的な削除の結果として、対応するパスメッセージを下に送信するS2LサブLSPが残っていない場合に発生する可能性があります。
Explicit S2L Sub-LSP teardown relies on generating a PathTear message for the corresponding Path message. The PathTear message is signaled with the SESSION and SENDER_TEMPLATE objects corresponding to the P2MP LSP and the <Sub-Group Originator ID, Sub-Group ID> tuple corresponding to the Path message. This approach SHOULD be used when all the egresses signaled by a Path message need to be removed from the P2MP LSP. Other S2L sub-LSPs, from other sub-groups signaled using other Path messages, are not affected by the PathTear.
明示的なS2L Sub-LSP Terowdは、対応するパスメッセージのPathTearメッセージの生成に依存しています。PATHTEARメッセージは、P2MP LSPに対応するセッションおよびSender_Templateオブジェクトと、パスメッセージに対応する<サブグループID>サブグループID>タプルで信号されます。このアプローチは、パスメッセージによって信号を送信するすべての出力をP2MP LSPから削除する必要がある場合に使用する必要があります。他のパスメッセージを使用してシグナル伝達された他のサブグループからの他のS2LサブLSPは、PathTearの影響を受けません。
A transit LSR that propagates the PathTear message downstream MUST ensure that it sets the <Sub-Group Originator ID, Sub-Group ID> tuple in the PathTear message to the values used in the Path message that was used to set up the S2L sub-LSPs being torn down. The transit LSR may need to generate multiple PathTear messages for an incoming PathTear message if it had performed transit fragmentation for the corresponding incoming Path message.
下流のPathTearメッセージを伝播するトランジットLSRは、<サブグループオリジナルID、サブグループID> TupleをS2Lサブサブのセットアップに使用したパスメッセージで使用された値にPATHTEARメッセージに設定することを確認する必要があります。LSPが取り壊されています。Transit LSRは、対応する着信パスメッセージに対してトランジットフラグメンテーションを実行した場合、着信PATHTEARメッセージの複数のPATHTEARメッセージを生成する必要がある場合があります。
When a P2MP LSP is removed by the ingress, a PathTear message MUST be generated for each Path message used to signal the P2MP LSP.
P2MP LSPが侵入によって削除される場合、P2MP LSPを信号にするために使用される各パスメッセージに対してPATHTEARメッセージを生成する必要があります。
The Notify Request object and Notify message are described in [RFC3473]. Both object and message SHALL be supported for delivery of upstream and downstream notification. Processing not detailed in this section MUST comply to [RFC3473].
Notify RequestオブジェクトとNotifyメッセージは[RFC3473]で説明されています。オブジェクトとメッセージの両方が、上流および下流の通知の配信のためにサポートされます。このセクションで詳しく説明していない処理は、[RFC3473]に準拠する必要があります。
1. Upstream Notification
1. 上流の通知
If a transit LSR sets the Sub-Group Originator ID in the SENDER_TEMPLATE object of a Path message to its own address, and the incoming Path message carries a Notify Request object, then this LSR MUST change the Notify node address in the Notify Request object to its own address in the Path message that it sends.
Transit LSRがパスメッセージのSender_TemplateオブジェクトにサブグループオリジネーターIDを独自のアドレスに設定し、着信パスメッセージにNotify Requestオブジェクトを搭載している場合、このLSRはNotifyリクエストオブジェクトの通知ノードアドレスを変更する必要があります。送信するパスメッセージに独自のアドレス。
If this LSR subsequently receives a corresponding Notify message from a downstream LSR, then it MUST:
このLSRがその後、下流のLSRから対応する通知メッセージを受信した場合、次のことをしなければなりません。
- send a Notify message upstream toward the Notify node address that the LSR received in the Path message.
- PATHメッセージでLSRが受信したNotifyノードアドレスに向かって上流の通知メッセージを送信します。
- process the Sub-Group fields of the SENDER_TEMPLATE object on the received Notify message, and modify their values, in the Notify message that is forwarded, to match the Sub-Group field values in the original Path message received from upstream.
- 受信した通知メッセージのsender_templateオブジェクトのサブグループフィールドを処理し、転送される通知メッセージで値を変更して、アップストリームから受信した元のパスメッセージのサブグループフィールド値を一致させます。
The receiver of an (upstream) Notify message MUST identify the state referenced in this message based on the SESSION and SENDER_TEMPLATE.
（上流の）通知メッセージの受信者は、セッションとsender_templateに基づいて、このメッセージで参照されている状態を識別する必要があります。
2. Downstream Notification
2. ダウンストリーム通知
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value that was received in the corresponding Path message. If the incoming Resv message carries a Notify Request object, then:
Transit LSRは、対応するパスメッセージで受信された値にRESVメッセージのfilter_specオブジェクトにサブグループオリジネーターIDを設定します。着信RESVメッセージにNotify Requestオブジェクトが搭載されている場合、
- If there is at least another incoming Resv message that carries a Notify Request object, and the LSR merges these Resv messages into a single Resv message that is sent upstream, the LSR MUST set the Notify node address in the Notify Request object to its Router ID.
- Notify Requestオブジェクトを搭載した少なくとも別の着信RESVメッセージがあり、LSRがこれらのRESVメッセージを上流に送信される単一のRESVメッセージにマージする場合、LSRはNotifyリクエストオブジェクトのNotifyノードアドレスをルーターIDに設定する必要があります。
- Else if the LSR sets the Sub-Group Originator ID (in the outgoing Path message that corresponds to the received Resv message) to its own address, the LSR MUST set the Notify node address in the Notify Request object to its Router ID.
- それ以外の場合、LSRがサブグループのオリジナルID（受信したRESVメッセージに対応する発信パスメッセージ）を独自のアドレスに設定する場合、LSRはNotifyリクエストオブジェクトのNotifyノードアドレスをルーターIDに設定する必要があります。
- Else the LSR MUST propagate the Notify Request object unchanged, in the Resv message that it sends upstream.
- それ以外の場合、LSRは、上流に送信されるRESVメッセージで、Notify Requestオブジェクトを変更せずに伝播する必要があります。
If this LSR subsequently receives a corresponding Notify message from an upstream LSR, then it MUST:
このLSRがその後、上流のLSRから対応する通知メッセージを受信した場合、次のことをしなければなりません。
- process the Sub-Group fields of the FILTER_SPEC object in the received Notify message, and modify their values, in the Notify message that is forwarded, to match the Sub-Group field values in the original Path message sent downstream by this LSR.
- 受信した通知メッセージのfilter_specオブジェクトのサブグループフィールドを処理し、転送される通知メッセージで値を変更して、このLSRによって下流に送信された元のパスメッセージのサブグループフィールド値を一致させます。
- send a Notify message downstream toward the Notify node address that the LSR received in the Resv message.
- LSRがRESVメッセージで受信したNotifyノードアドレスに向かって下流に通知メッセージを送信します。
The receiver of a (downstream) Notify message MUST identify the state referenced in the message based on the SESSION and FILTER_SPEC objects.
（下流の）通知メッセージの受信者は、セッションとFilter_Specオブジェクトに基づいてメッセージで参照されている状態を識別する必要があります。
The consequence of these rules for a P2MP LSP is that an upstream Notify message generated on a branch will result in a Notify being delivered to the upstream Notify node address. The receiver of the Notify message MUST NOT assume that the Notify message applies to all downstream egresses, but MUST examine the information in the message to determine to which egresses the message applies.
P2MP LSPのこれらのルールの結果は、ブランチで生成された上流の通知メッセージが、アップストリームNotifyノードアドレスに通知が配信されることです。Notifyメッセージの受信者は、Notifyメッセージがすべての下流の出口に適用されることを想定してはなりませんが、メッセージの情報の情報を調べて、メッセージが適用される出力を決定する必要があります。
Downstream Notify messages MUST be replicated at branch LSRs according to the Notify Request objects received on Resv messages. Some downstream branches might not request Notify messages, but all that have requested Notify messages MUST receive them.
下流の通知メッセージは、RESVメッセージで受信したNotifyリクエストオブジェクトに従って、Branch LSRSで複製する必要があります。一部の下流のブランチは、通知メッセージのメッセージを要求しない場合がありますが、Notifyメッセージを要求したものはすべてそれらを受信する必要があります。
ResvConf messages are described in [RFC2205]. ResvConf processing in [RFC3473] and [RFC3209] is taken directly from [RFC2205]. An egress LSR MAY include a RESV_CONFIRM object that contains the egress LSR's address. The object and message SHALL be supported for the confirmation of receipt of the Resv message in P2MP TE LSPs. Processing not detailed in this section MUST comply to [RFC2205].
RESVCONFメッセージは[RFC2205]で説明されています。[RFC3473]および[RFC3209]のRESVCONF処理は、[RFC2205]から直接採取されます。出力LSRには、出力LSRのアドレスを含むRESV_CONFIRMオブジェクトが含まれる場合があります。オブジェクトとメッセージは、P2MP TE LSPでのRESVメッセージの受信の確認のためにサポートされます。このセクションで詳しく説明していない処理は、[RFC2205]に準拠する必要があります。
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value that was received in the corresponding Path message. If any of the incoming Resv messages corresponding to a single Path message carry a RESV_CONFIRM object, then the LSR MUST include a RESV_CONFIRM object in the corresponding Resv message that it sends upstream. If the Sub-Group Originator ID is its own address, then it MUST set the receiver address in the RESV_CONFIRM object to this address, else it MUST propagate the object unchanged.
Transit LSRは、対応するパスメッセージで受信された値にRESVメッセージのfilter_specオブジェクトにサブグループオリジネーターIDを設定します。単一のパスメッセージに対応する着信RESVメッセージのいずれかがRESV_CONFIRMオブジェクトを運ぶ場合、LSRには対応するRESVメッセージに上流を送信するRESV_CONFIRMオブジェクトを含める必要があります。サブグループのオリジナルIDが独自のアドレスである場合、RESV_CONFIRMオブジェクトのレシーバーアドレスをこのアドレスに設定する必要があります。
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value that was received in the corresponding Path message. If an incoming Resv message corresponding to a single Path message carries a RESV_CONFIRM object, then the LSR MUST include a RESV_CONFIRM object in the corresponding Resv message that it sends upstream and:
Transit LSRは、対応するパスメッセージで受信された値にRESVメッセージのfilter_specオブジェクトにサブグループオリジネーターIDを設定します。単一のパスメッセージに対応する着信RESVメッセージにRESV_CONFIRMオブジェクトが搭載されている場合、LSRには、上流を送信する対応するRESVメッセージにRESV_CONFIRMオブジェクトを含める必要があります。
- If there is at least another incoming Resv message that carries a RESV_CONFIRM object, and the LSR merges these Resv messages into a single Resv message that is sent upstream, the LSR MUST set the receiver address in the RESV_CONFIRM object to its Router ID.
- RESV_CONFIRMオブジェクトを運ぶ少なくとも別の着信RESVメッセージがあり、LSRがこれらのRESVメッセージを上流に送信される単一のRESVメッセージにマージする場合、LSRはRESV_CONFIRMオブジェクトのレシーバーアドレスをRouter IDに設定する必要があります。
- If the LSR sets the Sub-Group Originator ID (in the outgoing Path message that corresponds to the received Resv message) to its own address, the LSR MUST set the receiver address in the RESV_CONFIRM object to its Router ID.
- LSRがサブグループのオリジナルID（受信したRESVメッセージに対応する発信パスメッセージ）を独自のアドレスに設定する場合、LSRはRESV_CONFIRMオブジェクトのレシーバーアドレスをルーターIDに設定する必要があります。
- Else the LSR MUST propagate the RESV_CONFIRM object unchanged, in the Resv message that it sends upstream.
- それ以外の場合、LSRは、上流に送信されるRESVメッセージで、resv_confirmオブジェクトを変更せずに伝播する必要があります。
If this LSR subsequently receives a corresponding ResvConf message from an upstream LSR, then it MUST:
このLSRがその後、上流のLSRから対応するRESVCONFメッセージを受信した場合、次のことが必要です。
- process the Sub-Group fields of the FILTER_SPEC object in the received ResvConf message, and modify their values, in the ResvConf message that is forwarded, to match the Sub-Group field values in the original Path message sent downstream by this LSR.
- 受信したRESVCONFメッセージのfilter_Specオブジェクトのサブグループフィールドを処理し、転送されるRESVCONFメッセージで値を変更して、このLSRによって下流に送信された元のパスメッセージのサブグループフィールド値と一致します。
- send a ResvConf message downstream toward the receiver address that the LSR received in the RESV_CONFIRM object in the Resv message.
- resvメッセージのRESV_CONFIRMオブジェクトでLSRが受信したレシーバーアドレスに向かって下流のRESVCONFメッセージを送信します。
The receiver of a ResvConf message MUST identify the state referenced in this message based on the SESSION and FILTER_SPEC objects.
RESVCONFメッセージの受信者は、セッションとFilter_Specオブジェクトに基づいて、このメッセージで参照されている状態を識別する必要があります。
The consequence of these rules for a P2MP LSP is that a ResvConf message generated at the ingress will result in a ResvConf message being delivered to the branch and then to the receiver address in the original RESV_CONFIRM object. The receiver of a ResvConf message MUST NOT assume that the ResvConf message should be sent to all downstream egresses, but it MUST replicate the message according to the RESV_CONFIRM objects received in Resv messages. Some downstream branches might not request ResvConf messages, and ResvConf messages SHOULD NOT be sent on these branches. All downstream branches that requested ResvConf messages MUST be sent such a message.
P2MP LSPのこれらのルールの結果は、イングレスで生成されたRESVCONFメッセージがRESVCONFメッセージがブランチに配信され、元のRESV_CONFIRMオブジェクトのレシーバーアドレスに配信されることです。RESVCONFメッセージの受信者は、RESVCONFメッセージをすべての下流の出口に送信する必要があると仮定してはなりませんが、RESVメッセージで受信したRESV_CONFIRMオブジェクトに従ってメッセージを再現する必要があります。一部の下流のブランチでは、resvConfメッセージを要求しない場合があり、これらのブランチにRESVCONFメッセージを送信しないでください。RESVCONFメッセージを要求したすべての下流のブランチは、そのようなメッセージを送信する必要があります。
The refresh reduction procedures described in [RFC2961] are equally applicable to P2MP LSPs described in this document. Refresh reduction applies to individual messages and the state they install/maintain, and that continues to be the case for P2MP LSPs.
[RFC2961]で説明されている更新削減手順は、このドキュメントで説明されているP2MP LSPに等しく適用できます。更新削減は、個々のメッセージとそれらがインストール/維持状態に適用されます。これは、P2MP LSPの場合もあります。
State signaled by a P2MP Path message is identified by a local implementation using the <P2MP ID, Tunnel ID, Extended Tunnel ID> tuple as part of the SESSION object and the <Tunnel Sender Address, LSP ID, Sub-Group Originator ID, Sub-Group ID> tuple as part of the SENDER_TEMPLATE object.
P2MPパスメッセージによって合図された状態は、セッションオブジェクトの一部として<P2MP ID、トンネルID、拡張トンネルID>タプルを使用してローカル実装によって識別されます。-Group ID> sender_templateオブジェクトの一部としてのタプル。
Additional information signaled in the Path/Resv message is part of the state created by a local implementation. This includes PHOP/NHOP and SENDER_TSPEC/FILTER_SPEC objects.
PATH/RESVメッセージに合図された追加情報は、ローカル実装によって作成された状態の一部です。これには、PHOP/NHOPおよびSENDER_TSPEC/FILTER_SPECオブジェクトが含まれます。
RSVP (as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and GMPLS [RFC3473]) uses the same basic approach to state communication and synchronization -- namely, full state is sent in each state advertisement message. Per [RFC2205], Path and Resv messages are idempotent. Also, [RFC2961] categorizes RSVP messages into two types (trigger and refresh messages) and improves RSVP message handling and scaling of state refreshes, but does not modify the full state advertisement nature of Path and Resv messages. The full state advertisement nature of Path and Resv messages has many benefits, but also has some drawbacks. One notable drawback is when an incremental modification is being made to a previously advertised state. In this case, there is the message overhead of sending the full state and the cost of processing it. It is desirable to overcome this drawback and add/delete S2L sub-LSPs to/from a P2MP LSP by incrementally updating the existing state.
RSVP（[RFC2205]で定義されており、RSVP-TE [RFC3209]およびGMPLS [RFC3473]によって拡張されているように）は、状態コミュニケーションと同期に対する同じ基本的なアプローチを使用します。[RFC2205]ごとに、PATHおよびRESVメッセージはiDEMPOTENTです。また、[RFC2961]は、RSVPメッセージを2つのタイプ（トリガーと更新メッセージ）に分類し、RSVPメッセージの処理と状態のリフレッシュのスケーリングを改善しますが、PATHおよびRESVメッセージの完全な状態広告の性質を変更しません。パスとRESVメッセージの完全な広告の性質には多くの利点がありますが、いくつかの欠点もあります。注目すべき欠点の1つは、以前に宣伝されていた状態に増分変更が行われている場合です。この場合、完全な状態を送信するというメッセージとそれを処理するコストがあります。この欠点を克服し、既存の状態を段階的に更新することにより、P2MP LSPにS2LサブLSPを追加/削除することが望ましいです。
It is possible to use the procedures described in this document to allow S2L sub-LSPs to be incrementally added to or deleted from the P2MP LSP by allowing a Path or a PathTear message to incrementally change the existing P2MP LSP Path state.
このドキュメントで説明されている手順を使用して、S2L Sub-LSPをP2MP LSPに段階的に追加または削除できるようにすることができます。
As described in section 5.2, multiple Path messages can be used to signal a P2MP LSP. The Path messages are distinguished by different <Sub-Group Originator ID, Sub-Group ID> tuples in the SENDER_TEMPLATE object. In order to perform incremental S2L sub-LSP state addition, a separate Path message with a new Sub-Group ID is used to add the new S2L sub-LSPs, by the ingress LSR. The Sub-Group Originator ID MUST be set to the TE Router ID [RFC3477] of the node that sets the Sub-Group ID.
セクション5.2で説明されているように、複数のパスメッセージを使用してP2MP LSPを信号することができます。パスメッセージは、sender_templateオブジェクトの異なる<サブグループオリジナルID、サブグループID>タプルによって区別されます。インクリメンタルS2LサブLSP状態の追加を実行するために、新しいサブグループIDを備えた個別のパスメッセージを使用して、イングレスLSRによって新しいS2LサブLSPを追加します。サブグループのオリジナルIDは、サブグループIDを設定するノードのTEルーターID [RFC3477]に設定する必要があります。
This maintains the idempotent nature of RSVP Path messages, avoids keeping track of individual S2L sub-LSP state expiration, and provides the ability to perform incremental P2MP LSP state updates.
これにより、RSVP PATHメッセージの等量性の性質が維持され、個々のS2LサブLSP状態の有効期限の追跡を回避し、増分P2MP LSP状態の更新を実行する機能を提供します。
There is a tradeoff between the number of Path messages used by the ingress to maintain the P2MP LSP and the processing imposed by full state messages when adding S2L sub-LSPs to an existing Path message. It is possible to combine S2L sub-LSPs previously advertised in different Path messages in a single Path message in order to reduce the number of Path messages needed to maintain the P2MP LSP. This can also be done by a transit node that performed fragmentation and that at a later point is able to combine multiple Path messages that it generated into a single Path message. This may happen when one or more S2L sub-LSPs are pruned from the existing Path states.
P2MP LSPを維持するためにイングレスが使用するパスメッセージの数と、既存のパスメッセージにS2L Sub-LSPを追加するときに完全な状態メッセージによって課される処理の間にはトレードオフがあります。P2MP LSPを維持するために必要なパスメッセージの数を減らすために、単一のパスメッセージの異なるパスメッセージで以前に宣伝されていたS2L Sub-LSPを組み合わせることができます。これは、フラグメンテーションを実行したトランジットノードによっても実行でき、後の時点で単一のパスメッセージに生成された複数のパスメッセージを組み合わせることができます。これは、1つ以上のS2LサブLSPが既存のパス状態から剪定された場合に発生する可能性があります。
The new Path message is signaled by the node that is combining multiple Path messages with all the S2L sub-LSPs that are being combined in a single Path message. This Path message MAY contain new Sub-Group ID field values. When a new Path and Resv message that is signaled for an existing S2L sub-LSP is received by a transit LSR, state including the new instance of the S2L sub-LSP is created.
新しいパスメッセージは、単一のパスメッセージに組み合わされている複数のパスメッセージとすべてのS2LサブLSPを組み合わせているノードによって信号を送信されます。このパスメッセージには、新しいサブグループIDフィールド値が含まれる場合があります。既存のS2LサブLSPに対して信号を送信される新しいパスとRESVメッセージがトランジットLSRによって受信されると、S2LサブLSPの新しいインスタンスを含む状態が作成されます。
The S2L sub-LSP SHOULD continue to be advertised in both the old and new Path messages until a Resv message listing the S2L sub-LSP and corresponding to the new Path message is received by the combining node. Hence, until this point, state for the S2L sub-LSP SHOULD be maintained as part of the Path state for both the old and the new Path message (see section 3.1.3 of [RFC2205]). At that point the S2L sub-LSP SHOULD be deleted from the old Path state using the procedures of section 7.
S2LサブLSPは、S2LサブLSPをリストし、新しいパスメッセージに対応するRESVメッセージが結合ノードによって受信されるまで、古いパスメッセージと新しいパスメッセージの両方で引き続き宣伝する必要があります。したがって、この時点まで、S2LサブLSPの状態は、古いパスメッセージと新しいパスメッセージの両方のパス状態の一部として維持する必要があります（[RFC2205]のセクション3.1.3を参照）。その時点で、セクション7の手順を使用して、S2LサブLSPを古い経路状態から削除する必要があります。
A Path message with a Sub-Group_ID(n) may signal a set of S2L sub-LSPs that belong partially or entirely to an already existing Sub-Group_ID(i), or a strictly non-overlapping new set of S2L sub-LSPs. A newly received Path message that matches SESSION object and Sender Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path state carrying the same or different Sub-Group_ID, referred to Sub-Group_ID(n) is processed as follows:
Sub-Group_ID（n）を使用したパスメッセージは、既存のsub-group_id（i）に部分的または完全に属するS2LサブLSPのセット、またはS2L Sub-LSPの厳密に重複しない新しいセットに属するS2LサブLSPのセットを信号する場合があります。セッションオブジェクトおよび送信者トンネルアドレス、LSP ID、サブグループオリジネーターIDを一致させる新たに受信したパスメッセージ>同じまたは異なるサブグループ_IDを運ぶ既存のパス状態を持つサブグループ（n）は次のように処理されます。
1) If Sub-Group_ID(i) = Sub-Group_ID(n), then S2L Sub-LSPs that are in both Sub-Group_ID(i) and Sub-Group_ID(n) are refreshed. New S2L Sub-LSPs are added to Sub-Group_ID(i) Path state and S2L Sub-LSPs that are in Sub-Group_ID(i) but not in Sub-Group_ID(n) are deleted from the Sub-Group_ID(i) Path state.
1) sub-group_id（i）= sub-group_id（n）の場合、sub-group_id（i）とsub-group_id（n）の両方にあるs2l sub-lspsが更新されます。新しいS2L Sub-LSPは、サブグループではないが、サブグループではないSub-Group_id（i）パス状態およびS2L Sub-LSPに追加されますが、sub-group_id（i）パスから削除されます州。
2) If Sub-Group_ID(i) != Sub-Group_ID(n), then a new Sub-Group_ID(n) Path state is created for S2L Sub-LSPs signaled by Sub-Group_ID(n). S2L Sub-LSPs in existing Sub-Group_IDs(i) Path state (that are or are not in the newly received Path message Sub-Group_ID(n)) are left unmodified (see above).
2) sub-group_id（i）！= sub-group_id（n）の場合、sub-group_id（n）によってシグナルとされたS2L Sub-LSPの新しいsub-group_id（n）パス状態が作成されます。既存のsub-group_ids（i）パス状態（新しく受信されたパスメッセージサブグラップ_id（n）に含まれていない、または存在しないS2LサブLSPは、変更されていないままです（上記参照）。
PathErr and ResvErr messages are processed as per RSVP-TE procedures. Note that an LSR, on receiving a PathErr/ResvErr message for a particular S2L sub-LSP, changes the state only for that S2L sub-LSP. Hence other S2L sub-LSPs are not impacted. If the ingress node requests 'LSP integrity', an error reported on a branch of a P2MP TE LSP for a particular S2L sub-LSP may change the state of any other S2L sub-LSP of the same P2MP TE LSP. This is explained further in section 11.3.
PatherrおよびResverrメッセージは、RSVP-TEプロシージャに従って処理されます。LSRは、特定のS2LサブLSPに対してPatherr/Resverrメッセージを受信すると、そのS2LサブLSPに対してのみ状態を変更することに注意してください。したがって、他のS2LサブLSPは影響を受けません。Ingressノードが「LSPの完全性」を要求する場合、特定のS2LサブLSPのP2MP TE LSPのブランチで報告されたエラーは、同じP2MP TE LSPの他のS2LサブLSPの状態を変更する可能性があります。これについては、セクション11.3でさらに説明します。
The PathErr message will include one or more S2L_SUB_LSP objects. The resulting modified format for a PathErr message is:
Patherrメッセージには、1つ以上のS2L_SUB_LSPオブジェクトが含まれます。Patherrメッセージの結果の変更された形式は次のとおりです。
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[ <S2L sub-LSP descriptor list> ]
PathErr message generation is unmodified, but nodes that set the Sub-Group Originator field and propagate a received PathErr message upstream MUST replace the Sub-Group fields received in the PathErr message with the value that was received in the Sub-Group fields of the Path message from the upstream neighbor. Note the receiver of a PathErr message is able to identify the errored outgoing Path message, and outgoing interface, based on the Sub-Group fields received in the PathErr message. The S2L sub-LSP descriptor list is defined in section 5.1.
Patherrメッセージの生成は修正されていませんが、サブグループのオリジネーターフィールドを設定し、受信したPatherrメッセージを上流に伝播するノードは、Pathersメッセージで受信したサブグループフィールドを、パスのサブグループフィールドで受信した値に置き換える必要があります。上流の隣人からのメッセージ。注A Patherrメッセージの受信者は、Patherrメッセージで受信されたサブグループフィールドに基づいて、エラーの発信パスメッセージと発信インターフェイスを識別できます。S2LサブLSP記述子リストは、セクション5.1で定義されています。
The ResvErr message will include one or more S2L_SUB_LSP objects. The resulting modified format for a ResvErr Message is:
RESVERRメッセージには、1つ以上のS2L_SUB_LSPオブジェクトが含まれます。RESVERRメッセージの結果の変更された形式は次のとおりです。
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
ResvErr message generation is unmodified, but nodes that set the Sub-Group Originator field and propagate a received ResvErr message downstream MUST replace the Sub-Group fields received in the ResvErr message with the value that was set in the Sub-Group fields of the Path message sent to the downstream neighbor. Note the receiver of a ResvErr message is able to identify the errored outgoing Resv message, and outgoing interface, based on the Sub-Group fields received in the ResvErr message. The flow descriptor list is defined in section 6.1.
RESVERRメッセージの生成は修正されていませんが、サブグループのオリジナーターフィールドを設定し、受信したRESVERRメッセージを下流に伝播するノードは、RESVERRメッセージで受信したサブグループフィールドを、パスのサブグループフィールドに設定された値に置き換える必要があります。下流の隣人に送信されたメッセージ。注RESVERRメッセージの受信機は、RESVERRメッセージで受信されたサブグループフィールドに基づいて、エラー化された発信RESVメッセージと発信インターフェイスを識別できます。フロー記述子リストは、セクション6.1で定義されています。
During setup and during normal operation, PathErr messages may be received at a branch node. In all cases, a received PathErr message is first processed per standard processing rules. That is, the PathErr message is sent hop-by-hop to the ingress/branch LSR for that Path message. Intermediate nodes until this ingress/branch LSR MAY inspect this message but take no action upon it. The behavior of a branch LSR that generates a PathErr message is under the control of the ingress LSR.
セットアップ中および通常の操作中に、Patherrメッセージはブランチノードで受信される場合があります。すべての場合において、受信したPatherrメッセージは、標準処理ルールごとに最初に処理されます。つまり、Patherrメッセージは、そのパスメッセージのIngress/Branch LSRにホップバイホップを送信されます。このイングレス/ブランチLSRがこのメッセージを検査するまで、中間ノードはこのメッセージを検査する可能性がありますが、アクションはありません。Patherrメッセージを生成するブランチLSRの動作は、Ingress LSRの制御下にあります。
The default behavior is that the PathErr message does not have the Path_State_Removed flag set. However, if the ingress LSR has set the LSP integrity flag on the Path message (see LSP_REQUIRED_ATTRIBUTEs object in section 5.2.4), and if the Path_State_Removed flag is supported, the LSR generating a PathErr to report the failure of a branch of the P2MP LSP SHOULD set the Path_State_Removed flag.
デフォルトの動作は、PatherrメッセージにPATH_STATE_REMOVEDフラグセットがないことです。ただし、Ingress LSRがパスメッセージにLSP整合性フラグを設定している場合（セクション5.2.4のLSP_REQUIRED_ATTRIBUTESオブジェクトを参照）、PATH_STATE_REMOVEDフラグがサポートされている場合、LSRはPATHERを生成してP2MPのブランチの障害を報告しますLSPは、path_state_removedフラグを設定する必要があります。
A branch LSR that receives a PathErr message during LSP setup with the Path_State_Removed flag set MUST act according to the wishes of the ingress LSR. The default behavior is that the branch LSR clears the Path_State_Removed flag on the PathErr and sends it further upstream. It does not tear any other branches of the LSP. However, if the LSP integrity flag is set on the Path message, the branch LSR MUST send PathTear on all other downstream branches and send the PathErr message upstream with the Path_State_Removed flag set.
PATH_STATE_REMOVEDフラグセットを使用してLSPセットアップ中にPATHERRメッセージを受信するブランチLSRは、Ingress LSRの希望に応じて行動する必要があります。デフォルトの動作は、Branch LSRがPatherrのPath_State_Removedフラグをクリアし、さらに上流に送信することです。LSPの他の枝を引き裂くことはありません。ただし、LSPの整合性フラグがPATHメッセージに設定されている場合、Branch LSRは他のすべてのダウンストリームブランチにPATHTEARを送信し、PATHE_STATE_REMOVEDフラグセットでPatherRメッセージを上流に送信する必要があります。
A branch LSR that receives a PathErr message with the Path_State_Removed flag clear MUST act according to the wishes of the ingress LSR. The default behavior is that the branch LSR forwards the PathErr upstream and takes no further action. However, if the LSP integrity flag is set on the Path message, the branch LSR MUST send PathTear on all downstream branches and send the PathErr upstream with the Path_State_Removed flag set (per [RFC3473]).
path_state_removedフラグを使用してpatherrメッセージを受信するブランチLSRは、イングレスLSRの希望に従って行動する必要があります。デフォルトの動作は、Branch LSRがPatherrを上流に転送し、それ以上のアクションを取らないことです。ただし、LSPの整合性フラグがPATHメッセージに設定されている場合、Branch LSRはすべての下流のブランチにPATHTEARを送信し、PATHE_STATE_REMOVEDフラグセット（[RFC3473]）でPatherrを上流に送信する必要があります。
In all cases, the PathErr message forwarded by a branch LSR MUST contain the S2L sub-LSP identification and explicit routes of all branches that are reported by received PathErr messages and all branches that are explicitly torn by the branch LSR.
すべての場合において、Branch LSRによって転送されたPatherRメッセージには、受信したPatherrメッセージおよびブランチLSRによって明示的に引き裂かれたすべてのブランチによって報告されるすべてのブランチのS2LサブLSP識別と明示的なルートを含める必要があります。
A branch node that receives an ADMIN_STATUS object processes it normally and also relays the ADMIN_STATUS object in a Path on every branch. All Path messages may be concurrently sent to the downstream neighbors.
Admin_Statusオブジェクトを受信するブランチノードは、それを正常に処理し、すべてのブランチのパスでadmin_statusオブジェクトを中継します。すべてのパスメッセージは、下流の隣人に同時に送信される場合があります。
Downstream nodes process the change in the ADMIN_STATUS object per [RFC3473], including generation of Resv messages. When the last received upstream ADMIN_STATUS object had the R bit set, branch nodes wait for a Resv message with a matching ADMIN_STATUS object to be received (or a corresponding PathErr or ResvTear message) on all branches before relaying a corresponding Resv message upstream.
ダウンストリームノードは、RESVメッセージの生成を含む[RFC3473]ごとにAdmin_Statusオブジェクトの変更を処理します。最後に受信した上流のadmin_statusオブジェクトがRビットセットを持っていたとき、ブランチノードは、対応するRESVメッセージを上流にリレーする前に、すべてのブランチで一致するadmin_statusオブジェクトが受信される（または対応するpatherrまたはresvtearメッセージ）を備えたRESVメッセージを待ちます。
A branch LSR of a P2MP LSP on an Ethernet LAN segment SHOULD send one copy of the data traffic per downstream LSR connected on that LAN for that P2MP LSP. Procedures for preventing MPLS labeled traffic replication in such a case is beyond the scope of this document.
イーサネットLANセグメント上のP2MP LSPのブランチLSRは、そのP2MP LSPのそのLANに接続された下流LSRごとにデータトラフィックのコピーを1つ送信する必要があります。このような場合のトラフィックレプリケーションとラベル付けされたMPLSを防ぐための手順は、このドキュメントの範囲を超えています。
It is possible to change the path used by P2MP LSPs to reach the destinations of the P2MP tunnel. There are two methods that can be used to accomplish this. The first is make-before-break, defined in [RFC3209], and the second uses the sub-groups defined above.
P2MP LSPによって使用されるパスを変更して、P2MPトンネルの目的地に到達することができます。これを達成するために使用できる2つの方法があります。1つ目は、[RFC3209]で定義されたブレイク前に行われ、2つ目は上記のサブグループを使用します。
In this case, all the S2L sub-LSPs are signaled with a different LSP ID by the ingress LSR and follow the make-before-break procedure defined in [RFC3209]. Thus, a new P2MP LSP is established. Each S2L sub-LSP is signaled with a different LSP ID, corresponding to the new P2MP LSP. After moving traffic to the new P2MP LSP, the ingress can tear down the old P2MP LSP. This procedure can be used to re-optimize the path of the entire P2MP LSP or the paths to a subset of the destinations of the P2MP LSP. When modifying just a portion of the P2MP LSP, this approach requires the entire P2MP LSP to be re-signaled.
この場合、すべてのS2L Sub-LSPは、Ingress LSRによって異なるLSP IDでシグナルにされ、[RFC3209]で定義されている分解前の手順に従います。したがって、新しいP2MP LSPが確立されます。各S2LサブLSPは、新しいP2MP LSPに対応する異なるLSP IDでシグナル伝達されます。新しいP2MP LSPにトラフィックを移動した後、イングレスは古いP2MP LSPを取り壊すことができます。この手順は、P2MP LSP全体のパスまたはP2MP LSPの宛先のサブセットへのパスを再最適化するために使用できます。P2MP LSPの一部のみを変更する場合、このアプローチでは、P2MP LSP全体を再署名する必要があります。
Any node may initiate re-optimization of a set of S2L sub-LSPs by using incremental state update and then, optionally, combining multiple path messages.
任意のノードは、Incremental State Updateを使用してS2L Sub-LSPのセットの再最適化を開始し、オプションで複数のパスメッセージを組み合わせることができます。
To alter the path taken by a particular set of S2L sub-LSPs, the node initiating the path change initiates one or more separate Path messages for the same P2MP LSP, each with a new sub-Group ID. The generation of these Path messages, each with one or more S2L sub-LSPs, follows procedures in section 5.2. As is the case in section 10.2, a particular egress continues to be advertised in both the old and new Path messages until a Resv message listing the egress and corresponding to the new Path message is received by the re-optimizing node. At that point, the egress SHOULD be deleted from the old Path state using the procedures of section 7. Sub-tree re-optimization is then completed.
S2L Sub-LSPの特定のセットによって取られたパスを変更するために、パス変更を開始するノードは、同じP2MP LSPの1つ以上の個別のパスメッセージを開始し、それぞれが新しいサブグループIDを備えています。これらのパスメッセージの生成は、それぞれ1つまたは複数のS2LサブLSPを備えており、セクション5.2の手順に従います。セクション10.2の場合と同様に、特定の出口は、ターフメッセージが出口をリストし、新しいパスメッセージに対応するノードによって受信されるまで、古いパスメッセージと新しいパスメッセージの両方で宣伝され続けます。その時点で、セクション7の手順を使用して、出口を古い経路状態から削除する必要があります。その後、サブツリーの再最適化が完了します。
Sub-Group-based re-optimization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs.
サブグループベースの再最適化は、S2L Sub-LSPのセットの新しいパスメッセージが同じS2L Sub-LSPのセットに対して古いパス状態で1つ以上のノードを通過する可能性があるため、過渡データの複製をもたらす可能性があります。
As is always the case, a node may choose to combine multiple path messages as described in section 10.2.
常にそうであるように、セクション10.2で説明されているように、ノードは複数のパスメッセージを組み合わせることを選択できます。
[RFC4090] extensions can be used to perform fast reroute for the mechanism described in this document when applied within packet networks. GMPLS introduces other protection techniques that can be applied to packet and non-packet environments [RFC4873], but which are not discussed further in this document. This section only applies to LSRs that support [RFC4090].
[RFC4090]拡張機能を使用して、パケットネットワーク内で適用された場合、このドキュメントで説明されているメカニズムに対して高速ルートを実行できます。GMPLSは、パケット環境と非パケット環境に適用できる他の保護技術[RFC4873]を導入しますが、このドキュメントではこれ以上説明していません。このセクションは、[RFC4090]をサポートするLSRにのみ適用されます。
This section uses terminology defined in [RFC4090], and fast reroute procedures defined in [RFC4090] MUST be followed unless specified below. The head-end and transit LSRs MUST follow the SESSION_ATTRIBUTE and FAST_REROUTE object processing as specified in [RFC4090] for each Path message and S2L sub-LSP of a P2MP LSP. Each S2L sub-LSP of a P2MP LSP MUST have the same protection characteristics. The RRO processing MUST apply to SRRO as well unless modified below.
このセクションでは、[RFC4090]で定義されている用語を使用し、[RFC4090]で定義されている高速リルート手順を以下に指定しない限り従う必要があります。ヘッドエンドおよびトランジットLSRは、各パスメッセージとP2MP LSPのS2LサブLSPについて[RFC4090]で指定されているように、session_attributeおよびfast_rerouteオブジェクト処理に従う必要があります。P2MP LSPの各S2LサブLSPには、同じ保護特性が必要です。RRO処理は、以下に変更されない限り、SRROにも適用する必要があります。
The sections that follow describe how fast reroute may be applied to P2MP MPLS TE LSPs in all of the principal operational scenarios. This document does not describe the detailed processing steps for every imaginable usage case, and they may be described in future documents, as needed.
以下のセクションでは、すべての主要な運用シナリオで、P2MP MPLS TE LSPに速度を適用できる速さを説明しています。このドキュメントでは、考えられるすべての使用ケースの詳細な処理手順を説明するものではなく、必要に応じて将来のドキュメントで説明することができます。
Facility backup can be used for link or node protection of LSRs on the path of a P2MP LSP. The downstream labels MUST be learned by the Point of Local Repair (PLR), as specified in [RFC4090], from the label corresponding to the S2L sub-LSP in the RESV message. Processing of SEROs signaled in a backup tunnel MUST follow backup tunnel ERO processing described in [RFC4090].
施設のバックアップは、P2MP LSPの経路でのLSRのリンクまたはノード保護に使用できます。下流のラベルは、RESVメッセージのS2LサブLSPに対応するラベルから[RFC4090]で指定されているように、ローカル修理のポイント（PLR）によって学習する必要があります。バックアップトンネルで信号を送信したSEROの処理は、[RFC4090]で説明されているバックアップトンネルERO処理に従う必要があります。
If link protection is desired, a bypass tunnel MUST be used to protect the link between the PLR and next-hop. Thus all S2L sub-LSPs that use the link SHOULD be protected in the event of link failure. Note that all such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel SHOULD share the same outgoing label on the link between the PLR and the next-hop as per section 5.2.1. This is the P2MP LSP label on the link. Label stacking is used to send data for each P2MP LSP into the bypass tunnel. The inner label is the P2MP LSP label allocated by the next-hop.
リンク保護が必要な場合は、PLRとNext-Hopの間のリンクを保護するために、バイパストンネルを使用する必要があります。したがって、リンクを使用するすべてのS2LサブLSPは、リンク障害の場合に保護する必要があります。P2MPトンネルの特定のインスタンスに属するこのようなS2LサブLSPはすべて、セクション5.2.1に従って、PLRとNext-Hopの間のリンクで同じ発信ラベルを共有する必要があることに注意してください。これは、リンク上のP2MP LSPラベルです。ラベルスタッキングは、各P2MP LSPのデータをバイパストンネルに送信するために使用されます。内側のラベルは、次のホップによって割り当てられたP2MP LSPラベルです。
During failure, Path messages for each S2L sub-LSP that is affected, MUST be sent to the Merge Point (MP) by the PLR. It is RECOMMENDED that the PLR uses the sender template-specific method to identify these Path messages. Hence, the PLR will set the source address in the sender template to a local PLR address.
障害中、影響を受ける各S2LサブLSPのパスメッセージは、PLRによってマージポイント（MP）に送信する必要があります。PLRは、送信者テンプレート固有の方法を使用してこれらのパスメッセージを識別することをお勧めします。したがって、PLRは、送信者テンプレートのソースアドレスをローカルPLRアドレスに設定します。
The MP MUST use the LSP-ID to identify the corresponding S2L sub-LSPs. The MP MUST NOT use the <Sub-Group Originator ID, Sub-Group ID> tuple while identifying the corresponding S2L sub-LSPs. In order to further process an S2L sub-LSP the MP MUST determine the protected S2L sub-LSP using the LSP-ID and the S2L_SUB_LSP object.
MPは、LSP-IDを使用して、対応するS2L Sub-LSPを識別する必要があります。MPは、対応するS2LサブLSPを識別しながら、<サブグループオリジナルID、サブグループID>タプルを使用してはなりません。S2LサブLSPをさらに処理するために、MPはLSP-IDとS2L_SUB_LSPオブジェクトを使用して保護されたS2LサブLSPを決定する必要があります。
If node protection is desired the PLR SHOULD use one or more P2P bypass tunnels to protect the set of S2L sub-LSPs that transit the protected node. Each of these P2P bypass tunnels MUST intersect the path of the S2L sub-LSPs that they protect on an LSR that is downstream from the protected node. This constrains the set of S2L sub-LSPs being backed- up via that bypass tunnel to those S2L sub-LSPs that pass through a common downstream MP. This MP is the destination of the bypass tunnel. When the PLR forwards incoming data for a P2MP LSP into the bypass tunnel, the outer label is the bypass tunnel label and the inner label is the label allocated by the MP to the set of S2L sub-LSPs belonging to that P2MP LSP.
ノード保護が必要な場合、PLRは1つ以上のP2Pバイパストンネルを使用して、保護されたノードを通過するS2LサブLSPのセットを保護する必要があります。これらの各P2Pバイパストンネルは、保護されたノードから下流のLSRで保護するS2LサブLSPの経路を交差する必要があります。これにより、そのバイパストンネルを介して共通の下流MPを通過するS2L Sub-LSPにバックアップされるS2LサブLSPのセットが制約されます。このMPは、バイパストンネルの目的地です。PLRがP2MP LSPの着信データをバイパストンネルに転送する場合、外側ラベルはバイパストンネルラベルであり、内側のラベルはMPによってそのP2MP LSPに属するS2LサブLSPのセットに割り当てられたラベルです。
After detecting failure of the protected node the PLR MUST send one or more Path messages for all protected S2L sub-LSPs to the MP of the protected S2L sub-LSP. It is RECOMMENDED that the PLR use the sender template specific method to identify these Path messages. Hence the PLR will set the source address in the sender template to a local PLR address. The MP MUST use the LSP-ID to identify the corresponding S2L sub-LSPs. The MP MUST NOT use the <Sub-Group Originator ID, Sub-Group ID> tuple while identifying the corresponding S2L sub-LSPs because the Sub-Group Originator ID might be changed by some LSR that is bypassed by the bypass tunnel. In order to further process an S2L sub-LSP the MP MUST determine the protected S2L sub-LSP using the LSP-ID and the S2L_SUB_LSP object.
保護されたノードの障害を検出した後、PLRは保護されたS2LサブLSPのMPに保護されたすべてのS2LサブLSPに対して1つ以上のパスメッセージを送信する必要があります。PLRは、これらのパスメッセージを識別するために送信者テンプレート固有の方法を使用することをお勧めします。したがって、PLRは、送信者テンプレートのソースアドレスをローカルPLRアドレスに設定します。MPは、LSP-IDを使用して、対応するS2L Sub-LSPを識別する必要があります。MPは、サブグループのオリジネーターIDがバイパストンネルによってバイパスされたLSRによって変更される可能性があるため、対応するS2LサブLSPを識別しながら、<サブグループオリジネーターID、サブグループID>タプルを使用してはなりません。S2LサブLSPをさらに処理するために、MPはLSP-IDとS2L_SUB_LSPオブジェクトを使用して保護されたS2LサブLSPを決定する必要があります。
Note that node protection MAY require the PLR to be branch capable in the data plane, as multiple bypass tunnels may be required to back up the set of S2L sub-LSPs passing through the protected node. If the PLR is not branch capable, the node protection mechanism described here is applicable to only those cases where all the S2L sub-LSPs passing through the protected node also pass through a single MP that is downstream from the protected node. A PLR MUST set the Node protection flag in the RRO/SRRO as specified in [RFC4090]. If a PLR is not branch capable, and one or more S2L sub-LSPs are added to a P2MP tree, and these S2L sub-LSPs do not transit the existing MP downstream of the protected node, then the PLR MUST reset this flag.
保護されたノードを通過するS2L Sub-LSPのセットをバックアップするために複数のバイパストンネルが必要になる可能性があるため、ノード保護はPLRがデータプレーンで可能な分岐である必要がある場合があることに注意してください。PLRが分岐できない場合、ここで説明するノード保護メカニズムは、保護されたノードを通過するすべてのS2LサブLSPが、保護されたノードから下流の単一のMPを通過する場合のみに適用できます。PLRは、[RFC4090]で指定されているように、RRO/SRROにノード保護フラグを設定する必要があります。PLRが分岐能力がなく、1つ以上のS2LサブLSPがP2MPツリーに追加され、これらのS2LサブLSPが保護ノードの下流の既存のMPを通過しない場合、PLRはこのフラグをリセットする必要があります。
It is to be noted that procedures in this section require P2P bypass tunnels. Procedures for using P2MP bypass tunnels are for further study.
このセクションの手順には、P2Pバイパストンネルが必要であることに注意してください。P2MPバイパストンネルを使用する手順は、さらなる研究のためです。
One-to-one backup, as described in [RFC4090], can be used to protect a particular S2L sub-LSP against link and next-hop failure. Protection may be used for one or more S2L sub-LSPs between the PLR and the next-hop. All the S2L sub-LSPs corresponding to the same instance of the P2MP tunnel between the PLR and the next-hop SHOULD share the same P2MP LSP label, as per section 5.2.1. All such S2L sub-LSPs belonging to a P2MP LSP MUST be protected.
[RFC4090]で説明されているように、1対1のバックアップを使用して、特定のS2LサブLSPをリンクおよび次のホップ障害から保護できます。PLRとNext-Hopの間の1つまたは複数のS2LサブLSPに保護を使用できます。PLRとNext-Hopの間のP2MPトンネルの同じインスタンスに対応するすべてのS2L Sub-LSPは、セクション5.2.1と同じP2MP LSPラベルを共有する必要があります。P2MP LSPに属するそのようなS2LサブLSPはすべて保護する必要があります。
The backup S2L sub-LSPs may traverse different next-hops at the PLR. Thus, the set of outgoing labels and next-hops for a P2MP LSP, at the PLR, may change once protection is triggered. Consider a P2MP LSP that is using a single next-hop and label between the PLR and the next-hop of the PLR. This may no longer be the case once protection is triggered. This MAY require a PLR to be branch capable in the data plane. If the PLR is not branch capable, the one-to-one backup mechanisms described here are only applicable to those cases where all the backup S2L sub-LSPs pass through the same next-hop downstream of the PLR. Procedures for one-to-one backup when a PLR is not branch capable and when all the backup S2L sub-LSPs do not pass through the same downstream next-hop are for further study.
バックアップS2L Sub-LSPは、PLRで異なるNext-Hopを通過する場合があります。したがって、PLRでのP2MP LSPの発信ラベルとネクストホップのセットは、保護がトリガーされると変化する可能性があります。PLRとPLRの次のホップとの間に単一のネクストホップとラベルを使用しているP2MP LSPを考えてみましょう。これは、保護がトリガーされると、もはや当てはまらない可能性があります。これには、PLRがデータプレーンで可能なブランチを必要とする場合があります。PLRが分岐能力がない場合、ここで説明する1対1のバックアップメカニズムは、すべてのバックアップS2L Sub-LSPがPLRの同じ次のホップ下流を通過する場合にのみ適用できます。PLRが分岐できない場合、およびすべてのバックアップS2L Sub-LSPが同じ下流の次のホップを通過しない場合、1対1のバックアップの手順はさらなる研究のためです。
It is recommended that the path-specific method be used to identify a backup S2L sub-LSP. Hence, the DETOUR object SHOULD be inserted in the backup Path message. A backup S2L sub-LSP MUST be treated as belonging to a different P2MP tunnel instance than the one specified by the LSP-ID. Furthermore multiple backup S2L sub-LSPs MUST be treated as part of the same P2MP tunnel instance if they have the same LSP-ID and the same DETOUR objects. Note that, as specified in section 4, S2L sub-LSPs between different P2MP tunnel instances use different labels.
パス固有の方法を使用して、バックアップS2LサブLSPを識別することをお勧めします。したがって、迂回路オブジェクトはバックアップパスメッセージに挿入する必要があります。バックアップS2LサブLSPは、LSP-IDで指定されたものとは異なるP2MPトンネルインスタンスに属するものとして扱わなければなりません。さらに、同じLSP-IDと同じ迂回オブジェクトがある場合、複数のバックアップS2L Sub-LSPを同じP2MPトンネルインスタンスの一部として扱う必要があります。セクション4で指定されているように、異なるP2MPトンネルインスタンス間のS2LサブLSPSは異なるラベルを使用していることに注意してください。
If there is only one S2L sub-LSP in the Path message, the DETOUR object applies to that sub-LSP. If there are multiple S2L sub-LSPs in the Path message, the DETOUR object applies to all the S2L sub-LSPs.
パスメッセージにS2LサブLSPが1つしかない場合、迂回路オブジェクトはそのサブLSPに適用されます。パスメッセージに複数のS2LサブLSPがある場合、迂回路オブジェクトはすべてのS2LサブLSPに適用されます。
It may be that some LSRs in a network are capable of processing the P2MP extensions described in this document, but do not support P2MP branching in the data plane. If such an LSR is requested to become a branch LSR by a received Path message, it MUST respond with a PathErr message carrying the Error Code "Routing Error" and Error Value "Unable to Branch".
ネットワーク内の一部のLSRは、このドキュメントで説明されているP2MP拡張機能を処理できるが、データプレーンでのP2MP分岐をサポートしていない可能性があります。そのようなLSRが受信したパスメッセージによってブランチLSRになるように要求されている場合、エラーコード「ルーティングエラー」とエラー値「分岐できない」を運ぶPatherメッセージで応答する必要があります。
It is also conceivable that some LSRs, in a network deploying P2MP capability, may not support the extensions described in this document. If a Path message for the establishment of a P2MP LSP reaches such an LSR, it will reject it with a PathErr because it will not recognize the C-Type of the P2MP SESSION object.
また、一部のLSRは、P2MP機能を展開するネットワークで、このドキュメントに記載されている拡張機能をサポートしない場合があると考えられます。P2MP LSPの確立のためのパスメッセージがそのようなLSRに到達すると、P2MPセッションオブジェクトのC型が認識されないため、Patherrで拒否されます。
LSRs that do not support the P2MP extensions in this document may be included as transit LSRs by the use of LSP stitching [LSP-STITCH] and LSP hierarchy [RFC4206]. Note that LSRs that are required to play any other role in the network (ingress, branch or egress) MUST support the extensions defined in this document.
このドキュメントのP2MP拡張機能をサポートしていないLSRは、LSPステッチ[LSPステッチ]およびLSP階層[RFC4206]を使用することにより、輸送LSRとして含めることができます。ネットワークで他の役割を果たすために必要なLSR（イングレス、ブランチ、または出口）は、このドキュメントで定義されている拡張機能をサポートする必要があることに注意してください。
The use of LSP stitching and LSP hierarchy [RFC4206] allows P2MP LSPs to be built in such an environment. A P2P LSP segment is signaled from the last P2MP-capable hop that is upstream of a legacy LSR to the first P2MP-capable hop that is downstream of it. This assumes that intermediate legacy LSRs are transit LSRs: they cannot act as P2MP branch points. Transit LSRs along this LSP segment do not process control plane messages associated with the P2MP LSP. Furthermore, these transit LSRs also do not need to have P2MP data plane capabilities as they only need to process data belonging to the P2P LSP segment. Hence, these transit LSRs do not need to support P2MP MPLS. This P2P LSP segment is stitched to the incoming P2MP LSP. After the P2P LSP segment is established, the P2MP Path message is sent to the next P2MP-capable LSR as a directed Path message. The next P2MP-capable LSR stitches the P2P LSP segment to the outgoing P2MP LSP.
LSPステッチとLSP階層[RFC4206]を使用すると、P2MP LSPをそのような環境に組み込むことができます。P2P LSPセグメントは、レガシーLSRの上流である最後のP2MP対応ホップから、その下流である最初のP2MP対応ホップに合図されます。これは、中間のレガシーLSRが輸送LSRであることを前提としています。P2MPブランチポイントとして機能することはできません。このLSPセグメントに沿ったTransit LSRは、P2MP LSPに関連付けられた制御プレーンメッセージを処理しません。さらに、これらのトランジットLSRは、P2P LSPセグメントに属するデータのみを処理する必要があるため、P2MPデータプレーン機能を持つ必要もありません。したがって、これらの輸送LSRはP2MP MPLSをサポートする必要はありません。このP2P LSPセグメントは、着信P2MP LSPにステッチされています。P2P LSPセグメントが確立された後、P2MPパスメッセージは、指向パスメッセージとして次のP2MP対応LSRに送信されます。次のP2MP対応LSRは、P2P LSPセグメントを発信P2MP LSPにステッチします。
In packet networks, the S2L sub-LSPs may be nested inside the outer P2P LSP. Hence, label stacking can be used to enable use of the same LSP segment for multiple P2MP LSPs. Stitching and nesting considerations and procedures are described further in [LSP-STITCH] and [RFC4206].
パケットネットワークでは、S2L Sub-LSPが外側のP2P LSP内にネストされる場合があります。したがって、ラベルスタッキングを使用して、複数のP2MP LSPで同じLSPセグメントを使用できるようにすることができます。ステッチとネスティングの考慮事項と手順は、[LSP-Stitch]および[RFC4206]でさらに説明されています。
There maybe overhead for an operator to configure the P2P LSP segments in advance, when it is desired to support legacy LSRs. It may be desirable to do this dynamically. The ingress can use IGP extensions to determine P2MP-capable LSRs [TE-NODE-CAP]. It can use this information to compute S2L sub-LSP paths such that they avoid legacy non-P2MP-capable LSRs. The explicit route object of an S2L sub-LSP path may contain loose hops if there are legacy LSRs along the path. The corresponding explicit route contains a list of objects up to the P2MP-capable LSR that is adjacent to a legacy LSR followed by a loose object with the address of the next P2MP-capable LSR. The P2MP-capable LSR expands the loose hop using its Traffic Engineering Database (TED). When doing this it determines that the loose hop expansion requires a P2P LSP to tunnel through the legacy LSR. If such a P2P LSP exists, it uses that P2P LSP. Else it establishes the P2P LSP. The P2MP Path message is sent to the next P2MP-capable LSR using non-adjacent signaling.
オペレーターが、レガシーLSRをサポートすることが望まれる場合、事前にP2P LSPセグメントを構成するためのオーバーヘッドがあるかもしれません。これを動的に行うことが望ましい場合があります。Ingressは、IGP拡張機能を使用して、P2MP対応LSR [TE-Node-Cap]を決定できます。この情報を使用して、S2LサブLSPパスを計算することができ、レガシーが非P2MP対応LSRを避けることができます。S2LサブLSPパスの明示的なルートオブジェクトには、パスに沿ってレガシーLSRがある場合、ルーズホップが含まれる場合があります。対応する明示的なルートには、レガシーLSRに隣接するP2MP対応LSRまでのオブジェクトのリストが含まれており、次のP2MP対応LSRのアドレスを含む緩いオブジェクトが続きます。P2MP対応LSRは、トラフィックエンジニアリングデータベース（TED）を使用してルーズホップを拡張します。これを行うと、ルーズホップ拡張には、レガシーLSRを通過するためにP2P LSPが必要であると判断されます。そのようなP2P LSPが存在する場合、P2P LSPを使用します。そうでなければ、P2P LSPを確立します。P2MPパスメッセージは、非隣接シグナル伝達を使用して次のP2MP対応LSRに送信されます。
The P2MP-capable LSR that initiates the non-adjacent signaling message to the next P2MP-capable LSR may have to employ a fast detection mechanism (such as [BFD] or [BFD-MPLS]) to the next P2MP-capable LSR. This may be needed for the directed Path message head-end to use node protection fast reroute when the protected node is the directed Path message tail.
次のP2MP対応LSRへの非隣接シグナル伝達メッセージを開始するP2MP対応LSRは、次のP2MP対応LSRに高速検出メカニズム（[BFD]や[BFD-MPLS]など）を使用する必要がある場合があります。これは、保護されたノードが方向のパスメッセージテールである場合、指示されたパスメッセージヘッドエンドがノード保護を使用するために必要になる場合があります。
Note that legacy LSRs along a P2P LSP segment cannot perform node protection of the tail of the P2P LSP segment.
P2P LSPセグメントに沿ったレガシーLSRSは、P2P LSPセグメントのテールのノード保護を実行できないことに注意してください。
It is possible to take advantage of LSP hierarchy [RFC4206] while setting up P2MP LSP, as described in the previous section, to reduce control plane processing along transit LSRs that are P2MP capable. This is applicable only in environments where LSP hierarchy can be used. Transit LSRs along a P2P LSP segment, being used by a P2MP LSP, do not process control plane messages associated with the P2MP LSP. In fact, they are not aware of these messages as they are tunneled over the P2P LSP segment. This reduces the amount of control plane processing required on these transit LSRs.
前のセクションで説明されているように、P2MP LSPをセットアップしながら、P2MP LSRに沿ったP2MP対応の輸送LSRに沿ったコントロールプレーン処理を減らしながら、LSP階層[RFC4206]を利用することができます。これは、LSP階層を使用できる環境でのみ適用されます。P2MP LSPで使用されているP2P LSPセグメントに沿ったトランジットLSRは、P2MP LSPに関連付けられた制御プレーンメッセージを処理しません。実際、P2P LSPセグメントにトンネルが付けられているため、これらのメッセージを認識していません。これにより、これらのトランジットLSRに必要なコントロールプレーン処理の量が減少します。
Note that the P2P LSPs can be set up dynamically as described in the previous section or preconfigured. For example, in Figure 2 in section 24, PE1 can set up a P2P LSP to P1 and use that as a LSP segment. The Path messages for PE3 and PE4 can now be tunneled over the LSP segment. Thus, P3 is not aware of the P2MP LSP and does not process the P2MP control messages.
P2P LSPは、前のセクションで説明されているように動的にセットアップできるか、事前に設定できることに注意してください。たとえば、セクション24の図2では、PE1はP2P LSPをP1に設定し、それをLSPセグメントとして使用できます。PE3とPE4のパスメッセージは、LSPセグメントにトンネルを整えることができます。したがって、P3はP2MP LSPを認識せず、P2MP制御メッセージを処理しません。
This section details the procedures for detecting and dealing with re-merge and cross-over. The term "re-merge" refers to the case of an ingress or transit node that creates a branch of a P2MP LSP, a re-merge branch, that intersects the P2MP LSP at another node farther down the tree. This may occur due to such events as an error in path calculation, an error in manual configuration, or network topology changes during the establishment of the P2MP LSP. If the procedures detailed in this section are not followed, data duplication will result.
このセクションでは、再加盟とクロスオーバーを検出して対処する手順について詳しく説明します。「Remerge」という用語とは、ツリーをさらに下にある別のノードでP2MP LSPと交差するP2MP LSPのブランチを作成する侵入またはトランジットノードの場合を指します。これは、PATH計算のエラー、手動構成のエラー、またはP2MP LSPの確立中のネットワークトポロジの変更などのイベントのために発生する可能性があります。このセクションで詳しく説明されている手順に従わない場合、データの複製が生じます。
The term "cross-over" refers to the case of an ingress or transit node that creates a branch of a P2MP LSP, a cross-over branch, that intersects the P2MP LSP at another node farther down the tree. It is unlike re-merge in that, at the intersecting node, the cross-over branch has a different outgoing interface as well as a different incoming interface. This may be necessary in certain combinations of topology and technology; e.g., in a transparent optical network in which different wavelengths are required to reach different leaf nodes.
「クロスオーバー」という用語とは、ツリーのさらに下の別のノードでP2MP LSPと交差するP2MP LSPのブランチを作成する侵入またはトランジットノードの場合を指します。それは、交差するノードでは、クロスオーバーブランチに異なる発信インターフェイスと異なる着信インターフェイスがあるという点とは異なります。これは、トポロジとテクノロジーの特定の組み合わせで必要になる場合があります。たとえば、異なる葉のノードに到達するために異なる波長が必要な透明な光ネットワークで。
Normally, a P2MP LSP has a single incoming interface on which all of the data for the P2MP LSP is received. The incoming interface is identified by the IF_ID RSVP_HOP object, if present, and by the interface over which the Path message was received if the IF_ID RSVP_HOP object is not present. However, in the case of dynamic LSP re-routing, the incoming interface may change.
通常、P2MP LSPには、P2MP LSPのすべてのデータが受信される単一の着信インターフェイスがあります。着信インターフェイスは、if_id rsvp_hopオブジェクトの存在の場合、およびif_id rsvp_hopオブジェクトが存在しない場合にパスメッセージが受信されたインターフェイスによって識別されます。ただし、動的なLSPの再ルーティングの場合、着信インターフェイスが変更される場合があります。
Similarly, in both the re-merge and cross-over cases, a node will receive a Path message for a given P2MP LSP identifying a different incoming interface for the data, and the node needs to be able to distinguish between dynamic LSP re-routing and the re- merge/cross-over cases.
同様に、再加算とクロスオーバーの両方のケースで、ノードはデータの異なる着信インターフェイスを識別する特定のP2MP LSPのパスメッセージを受信し、ノードは動的LSPの再ルーティングを区別できる必要がありますそして、再マージ/クロスオーバーケース。
Make-before-break represents yet another similar but different case, in that the incoming interface associated with the make-before-break P2MP LSP may be different than that associated with the original P2MP LSP. However, the two P2MP LSPs will be treated as distinct (but related) LSPs because they will have different LSP ID field values in their SENDER_TEMPLATE objects.
Make-Brekebrakeは、Make-Be-Beed-Bree-Breake-Bebmp LSPに関連する着信インターフェイスが元のP2MP LSPに関連付けられているものとは異なる可能性があるという点で、さらに別の同様の類似のケースを表しています。ただし、2つのP2MP LSPは、sender_templateオブジェクトに異なるLSP IDフィールド値を持つため、異なる（ただし関連）LSPとして扱われます。
When a node receives a Path message, it MUST check whether it has matching state for the P2MP LSP. Matching state is identified by comparing the SESSION and SENDER_TEMPLATE objects in the received Path message with the SESSION and SENDER_TEMPLATE objects of each locally maintained P2MP LSP Path state. The P2MP ID, Tunnel ID, and Extended Tunnel ID in the SESSION object and the sender address and LSP ID in the SENDER_TEMPLATE object are used for the comparison. If the node has matching state, and the incoming interface for the received Path message is different than the incoming interface of the matching P2MP LSP Path state, then the node MUST determine whether it is dealing with dynamic LSP rerouting or re-merge/cross-over.
ノードがパスメッセージを受信した場合、P2MP LSPの一致状態があるかどうかを確認する必要があります。一致する状態は、受信したパスメッセージ内のセッションとsender_templateオブジェクトを、ローカルで維持されている各P2MP LSPパス状態のセッションとsender_templateオブジェクトと比較することによって識別されます。セッションオブジェクトのP2MP ID、トンネルID、および拡張トンネルIDとSender_Templateオブジェクトの送信者アドレスとLSP IDが比較に使用されます。ノードに一致する状態があり、受信されたパスメッセージの着信インターフェイスが一致するP2MP LSPパス状態の着信インターフェイスとは異なる場合、ノードは動的なLSPのリルートを扱っているか、再構成/クロスを扱っているかを判断する必要があります。以上。
Dynamic LSP rerouting is identified by checking whether there is any intersection between the set of S2L_SUB_LSP objects associated with the matching P2MP LSP Path state and the set of S2L_SUB_LSP objects in the received Path message. If there is any intersection, then dynamic re-routing has occurred. If there is no intersection between the two sets of S2L_SUB_LSP objects, then either re-merge or cross-over has occurred. (Note that in the case of dynamic LSP rerouting, Path messages for the non-intersecting members of set of S2L_SUB_LSPs associated with the matching P2MP LSP Path state will be received subsequently on the new incoming interface.)
動的LSPの再ルーティングは、一致するP2MP LSP PATH状態に関連付けられたS2L_SUB_LSPオブジェクトのセットと、受信パスメッセージ内のS2L_SUB_LSPオブジェクトのセットの間に交差があるかどうかを確認することにより識別されます。交差点がある場合、動的な再ルーティングが発生しました。S2L_SUB_LSPオブジェクトの2つのセットの間に交差がない場合、再マスターまたはクロスオーバーのいずれかが発生しました。（動的LSPの再ルーティングの場合、一致するP2MP LSP PATH状態に関連付けられたS2L_SUB_LSPのセットの非交差メンバーのパスメッセージは、その後新しい着信インターフェイスで受信されます。）
In order to identify the re-merge case, the node processing the received Path message MUST identify the outgoing interfaces associated with the matching P2MP Path state. Re-merge has occurred if there is any intersection between the set of outgoing interfaces associated with the matching P2MP LSP Path state and the set of outgoing interfaces in the received Path message.
Remergeケースを識別するために、ノードの処理受信パスメッセージは、一致するP2MPパス状態に関連付けられた発信インターフェイスを識別する必要があります。一致するP2MP LSP PATH状態に関連付けられた発信インターフェイスのセットと、受信したパスメッセージ内の発信インターフェイスのセットの間に交差がある場合、Remergeが発生しました。
There are two approaches to dealing with the re-merge case. In the first, the node detecting the re-merge case, i.e., the re-merge node, allows the re-merge case to persist, but data from all but one incoming interface is dropped at the re-merge node. In the second, the re-merge node initiates the removal of the re-merge branch(es) via signaling. Which approach is used is a matter of local policy.
再加工されたケースに対処するには、2つのアプローチがあります。1つ目は、再マスターケース、つまり再マスターノードを検出するノードでは、再マスターケースを持続させることができますが、1つの着信インターフェイスを除くすべてのデータが再マスターノードで削除されます。2番目では、Remergeノードは、シグナリングを介して再マスターブランチ（ES）の除去を開始します。どのアプローチが使用されるかは、ローカルポリシーの問題です。
A node MUST support both approaches and MUST allow user configuration of which approach is to be used.
ノードは両方のアプローチをサポートする必要があり、使用するアプローチのユーザー構成を許可する必要があります。
When configured to allow a re-merge case to persist, the re-merge node MUST validate consistency between the objects included in the received Path message and the matching P2MP LSP Path state. Any inconsistencies MUST result in a PathErr message sent to the previous hop of the received Path message. The Error Code is set to "Routing Problem", and the Error Value is set to "P2MP Re-Merge Parameter Mismatch".
Remerge Caseが持続するように構成されている場合、Remergeノードは、受信パスメッセージに含まれるオブジェクトと一致するP2MP LSPパス状態間の一貫性を検証する必要があります。矛盾は、受信したパスメッセージの前のホップに送信されるpatherrメッセージを作成する必要があります。エラーコードは「ルーティングの問題」に設定されており、エラー値は「P2MPがパラメーターの不一致」に設定されています。
If there are no inconsistencies, the node logically merges, from the downstream perspective, the control state of incoming Path message with the matching P2MP LSP Path state. Specifically, procedures related to processing of messages received from upstream MUST NOT be modified from the upstream perspective; this includes processing related to refresh and state timeout. In addition to the standard upstream related procedures, the node MUST ensure that each object received from upstream is appropriately represented within the set of Path messages sent downstream. For example, the received <S2L sub-LSP descriptor list> MUST be included in the set of outgoing Path messages. If there are any NOTIFY_REQUEST objects present, then the procedures defined in section 8 MUST be followed for all Path and Resv messages. Special processing is also required for Resv processing. Specifically, any Resv message received from downstream MUST be mapped into an outgoing Resv message that is sent to the previous hop of the received Path message. In practice, this translates to decomposing the complete <S2L sub-LSP descriptor list> into subsets that match the incoming Path messages, and then constructing an outgoing Resv message for each incoming Path message.
矛盾がない場合、ノードは、下流の観点から、一致するP2MP LSPパス状態を持つ着信パスメッセージの制御状態から論理的にマージされます。具体的には、上流から受信したメッセージの処理に関連する手順は、上流の視点から変更してはなりません。これには、更新と状態のタイムアウトに関連する処理が含まれます。標準のアップストリーム関連手順に加えて、ノードは、上流から受信した各オブジェクトが、下流のパスメッセージのセット内で適切に表されることを確認する必要があります。たとえば、受信した<S2L Sub-LSP記述子リスト>は、発信パスメッセージのセットに含める必要があります。notify_requestオブジェクトが存在する場合は、セクション8で定義されている手順をすべてのパスおよびRESVメッセージに対して実行する必要があります。RESV処理にも特別な処理が必要です。具体的には、下流から受信したRESVメッセージは、受信したパスメッセージの前のホップに送信される発信RESVメッセージにマッピングする必要があります。実際には、これは完全な<S2LサブLSP記述子リスト>を着信パスメッセージに一致するサブセットに分解し、各着信パスメッセージの発信RESVメッセージを作成することに変換されます。
When configured to allow a re-merge case to persist, the re-merge node receives data associated with the P2MP LSP on multiple incoming interfaces, but it MUST only send the data from one of these interfaces to its outgoing interfaces. That is, the node MUST drop data from all but one incoming interface. This ensures that duplicate data is not sent on any outgoing interface. The mechanism used to select the incoming interface is implementation specific and is outside the scope of this document.
Remergeケースが持続するように構成されている場合、再マスターノードは複数の着信インターフェイスでP2MP LSPに関連付けられたデータを受信しますが、これらのインターフェイスのいずれかから発信インターフェイスにデータを送信する必要があります。つまり、ノードは1つの着信インターフェイスを除くすべてのデータをドロップする必要があります。これにより、重複データが発信インターフェイスで送信されないようになります。着信インターフェイスを選択するために使用されるメカニズムは実装固有であり、このドキュメントの範囲外です。
When configured to correct the re-merge branch via signaling, the re-merge node MUST send a PathErr message corresponding to the received Path message. The PathErr message MUST include all of the objects normally included in a PathErr message, as well as one or more S2L_SUB_LSP objects from the set of sub-LSPs associated with the matching P2MP LSP Path state. A minimum of three S2L_SUB_LSP objects is RECOMMENDED. This will allow the node that caused the re-merge to identify the outgoing Path state associated with the valid portion of the P2MP LSP. The set of S2L_SUB_LSP objects in the received Path message MUST also be included. The PathErr message MUST include the Error Code "Routing Problem" and Error Value of "P2MP Re-Merge Detected". The node MAY set the Path_State_Removed flag [RFC3473]. As is always the case, the PathErr message is sent to the previous hop of the received Path message.
シグナリングを介してRemergeブランチを修正するように構成されている場合、再マスターノードは受信パスメッセージに対応するPatherRメッセージを送信する必要があります。Patherrメッセージには、通常Pathersメッセージに含まれるすべてのオブジェクトと、一致するP2MP LSPパス状態に関連付けられたSub-LSPのセットからの1つまたは複数のS2L_SUB_LSPオブジェクトを含める必要があります。最低3つのS2L_SUB_LSPオブジェクトをお勧めします。これにより、RemergeがP2MP LSPの有効な部分に関連付けられた発信パス状態を識別するためのノードが可能になります。受信したパスメッセージ内のS2L_SUB_LSPオブジェクトのセットも含める必要があります。Patherrメッセージには、エラーコード「ルーティングの問題」と「P2MPが検出されたP2MP再マザー」のエラー値を含める必要があります。ノードは、path_state_removedフラグ[RFC3473]を設定する場合があります。常にそうであるように、Patherrメッセージは受信したパスメッセージの前のホップに送信されます。
A node that receives a PathErr message that contains the Error Value "Routing Problem/P2MP Re-Merge Detected" MUST determine if it is the node that created the re-merge case. This is done by checking whether there is any intersection between the set of S2L_SUB_LSP objects associated with the matching P2MP LSP Path state and the set of other-branch S2L_SUB_LSP objects in the received PathErr message. If there is, then the node created the re-merge case. Other-branch S2L_SUB_LSP objects are those S2L_SUB_LSP objects included, by the node detecting the re-merge case, in the PathErr message that were taken from the matching P2MP LSP Path state. Such S2L_SUB_LSP objects are identifiable as they will not be included in the Path message associated with the received PathErr message. See section 11.1 for more details on how such an association is identified.
エラー値「ルーティング問題/P2MP再マスター」を含むPatherRメッセージを受信するノードは、再マスターケースを作成したのがノードかどうかを判断する必要があります。これは、一致するP2MP LSPパス状態に関連付けられたS2L_SUB_LSPオブジェクトのセットと、受信したPatherメッセージに他のブランチS2L_SUB_LSPオブジェクトのセットに交差があるかどうかを確認することによって行われます。ある場合、ノードは再マザーケースを作成しました。その他のブランチS2L_SUB_LSPオブジェクトは、ノードが再マスターケースを検出することに含まれるS2L_SUB_LSPオブジェクトであり、一致するP2MP LSPパス状態から取得されたPatherRメッセージに含まれています。このようなS2L_SUB_LSPオブジェクトは、受信したPatherRメッセージに関連付けられたパスメッセージに含まれないため、識別可能です。そのような関連性の特定の詳細については、セクション11.1を参照してください。
The node SHOULD remove the re-merge case by moving the S2L_SUB_LSP objects included in the Path message associated with the received PathErr message to the outgoing interface associated with the matching P2MP LSP Path state. A trigger Path message for the moved S2L_SUB_LSP objects is then sent via that outgoing interface. If the received PathErr message did not have the Path_State_Removed flag set, the node SHOULD send a PathTear via the outgoing interface associated with the re-merge branch.
ノードは、受信したPATHERRメッセージに関連付けられたパスメッセージに含まれるS2L_SUB_LSPオブジェクトを、一致するP2MP LSP PATH状態に関連付けられた発信インターフェイスに移動することにより、再マスターケースを削除する必要があります。移動したS2L_SUB_LSPオブジェクトのトリガーパスメッセージは、その発信インターフェイスを介して送信されます。受信したPatherrメッセージにPATH_STATE_REMOVEDフラグセットがない場合、ノードはRemergeブランチに関連付けられた発信インターフェイスを介してPATHTEARを送信する必要があります。
If use of a new outgoing interface violates one or more SERO constraints, then a PathErr message containing the associated egresses and any identified S2L_SUB_LSP objects SHOULD be generated with the Error Code "Routing Problem" and Error Value of "ERO Resulted in Re-Merge".
新しい発信インターフェイスの使用が1つ以上のSero制約に違反する場合、関連する出力と識別されたS2L_SUB_LSPオブジェクトを含むPatherRメッセージは、エラーコード「ルーティングの問題」と「EROのエラー値が再構成された」と生成する必要があります。。
The only case where this process will fail is when all the listed S2L_SUB_LSP objects are deleted prior to the PathErr message propagating to the ingress. In this case, the whole process will be corrected on the next (refresh or trigger) transmission of the offending Path message.
このプロセスが失敗する唯一のケースは、リストされているすべてのS2L_SUB_LSPオブジェクトが、侵入に伝播するPatherRメッセージの前に削除された場合です。この場合、プロセス全体が、問題のパスメッセージの次の（更新またはトリガー）送信時に修正されます。
This section presents the RSVP object formats as modified by this document.
このセクションでは、このドキュメントで変更されたRSVPオブジェクト形式を示します。
A P2MP LSP SESSION object is used. This object uses the existing SESSION C-Num. New C-Types are defined to accommodate a logical P2MP destination identifier of the P2MP tunnel. This SESSION object has a similar structure as the existing point-to-point RSVP-TE SESSION object. However the destination address is set to the P2MP ID instead of the unicast Tunnel Endpoint address. All S2L sub-LSPs that are part of the same P2MP LSP share the same SESSION object. This SESSION object identifies the P2MP tunnel.
P2MP LSPセッションオブジェクトが使用されます。このオブジェクトは、既存のセッションC-Numを使用します。新しいCタイプは、P2MPトンネルの論理P2MP宛先識別子に対応するために定義されています。このセッションオブジェクトは、既存のポイントツーポイントRSVP-TEセッションオブジェクトと同様の構造を持っています。ただし、宛先アドレスは、ユニキャストトンネルエンドポイントアドレスの代わりにP2MP IDに設定されます。同じP2MP LSPの一部であるすべてのS2LサブLSPは、同じセッションオブジェクトを共有しています。このセッションオブジェクトは、P2MPトンネルを識別します。
The combination of the SESSION object, the SENDER_TEMPLATE object and the S2L_SUB_LSP object identifies each S2L sub-LSP. This follows the existing P2P RSVP-TE notion of using the SESSION object for identifying a P2P Tunnel, which in turn can contain multiple LSPs, each distinguished by a unique SENDER_TEMPLATE object.
セッションオブジェクト、sender_templateオブジェクト、およびS2L_SUB_LSPオブジェクトの組み合わせは、各S2LサブLSPを識別します。これは、P2Pトンネルを識別するためにセッションオブジェクトを使用するという既存のP2P RSVP-TE概念に従います。
Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13
class = session、p2mp_lsp_tunnel_ipv4 c-type = 13
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P2MP ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. It encodes the P2MP Identifier that is unique within the scope of the ingress LSR.
P2MP ID P2MPトンネルの寿命にわたって一定のままであるセッションオブジェクトで使用される32ビット識別子。Ingress LSRの範囲内で一意のP2MP識別子をコードします。
Tunnel ID A 16-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel.
トンネルID P2MPトンネルの寿命にわたって一定のままであるセッションオブジェクトで使用される16ビット識別子。
Extended Tunnel ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. Ingress LSRs that wish to have a globally unique identifier for the P2MP tunnel SHOULD place their tunnel sender address here. A combination of this address, P2MP ID, and Tunnel ID provides a globally unique identifier for the P2MP tunnel.
拡張トンネルID P2MPトンネルの寿命にわたって一定のままであるセッションオブジェクトで使用される32ビット識別子。P2MPトンネルのグローバルに一意の識別子があることを希望するIngress LSRは、ここにトンネル送信者のアドレスを配置する必要があります。このアドレス、P2MP ID、およびトンネルIDの組み合わせは、P2MPトンネルのグローバルに一意の識別子を提供します。
This is the same as the P2MP IPv4 LSP SESSION object with the difference that the extended tunnel ID may be set to a 16-byte identifier [RFC3209].
これは、拡張トンネルIDが16バイト識別子[RFC3209]に設定される可能性があるという違いを持つP2MP IPv4 LSPセッションオブジェクトと同じです。
Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14
class = session、p2mp_lsp_tunnel_ipv6 c-type = 14
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (16 bytes) |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SENDER_TEMPLATE object contains the ingress LSR source address. The LSP ID can be changed to allow a sender to share resources with itself. Thus, multiple instances of the P2MP tunnel can be created, each with a different LSP ID. The instances can share resources with each other. The S2L sub-LSPs corresponding to a particular instance use the same LSP ID.
Sender_Templateオブジェクトには、Ingress LSRソースアドレスが含まれています。LSP IDを変更して、送信者がリソースを共有できるようにすることができます。したがって、P2MPトンネルの複数のインスタンスを作成することができ、それぞれ異なるLSP IDがあります。インスタンスは互いにリソースを共有できます。特定のインスタンスに対応するS2L Sub-LSPは、同じLSP IDを使用します。
As described in section 4.2, it is necessary to distinguish different Path messages that are used to signal state for the same P2MP LSP by using a <Sub-Group ID Originator ID, Sub-Group ID> tuple. The SENDER_TEMPLATE object is modified to carry this information as shown below.
セクション4.2で説明したように、<サブグループIDオリジナルID、サブグループID>タプルを使用して、同じP2MP LSPの状態を信号するために使用されるさまざまなパスメッセージを区別する必要があります。sender_templateオブジェクトは、以下に示すようにこの情報を携帯するように変更されています。
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12
class = sender_template、p2mp_lsp_tunnel_ipv4 c-type = 12
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Group Originator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel sender address See [RFC3209].
IPv4トンネル送信者アドレス[RFC3209]を参照してください。
Sub-Group Originator ID The Sub-Group Originator ID is set to the TE Router ID of the LSR that originates the Path message. This is either the ingress LSR or an LSR which re-originates the Path message with its own Sub-Group Originator ID.
サブグループオリジナルIDサブグループオリジネーターIDは、パスメッセージを発信するLSRのTEルーターIDに設定されます。これは、イングレスLSRまたはLSRのいずれかで、独自のサブグループオリジネーターIDを使用してパスメッセージを再構成します。
Sub-Group ID An identifier of a Path message used to differentiate multiple Path messages that signal state for the same P2MP LSP. This may be seen as identifying a group of one or more egress nodes targeted by this Path message.
サブグループID同じP2MP LSPに対して状態を信号する複数のパスメッセージを区別するために使用されるパスメッセージの識別子。これは、このパスメッセージを標的とする1つ以上の出力ノードのグループを識別すると見なされる場合があります。
LSP ID See [RFC3209].
LSP ID [RFC3209]を参照してください。
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Sub-Group Originator ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel sender address See [RFC3209].
IPv6トンネル送信者アドレス[RFC3209]を参照してください。
Sub-Group Originator ID The Sub-Group Originator ID is set to the IPv6 TE Router ID of the LSR that originates the Path message. This is either the ingress LSR or an LSR which re-originates the Path message with its own Sub-Group Originator ID.
サブグループオリジナルIDサブグループオリジネーターIDは、パスメッセージを発信するLSRのIPv6 TEルーターIDに設定されます。これは、イングレスLSRまたはLSRのいずれかで、独自のサブグループオリジネーターIDを使用してパスメッセージを再構成します。
Sub-Group ID As above in section 19.2.1.
セクション19.2.1の上記のサブグループID。
LSP ID See [RFC3209].
LSP ID [RFC3209]を参照してください。
An S2L_SUB_LSP object identifies a particular S2L sub-LSP belonging to the P2MP LSP.
S2L_SUB_LSPオブジェクトは、P2MP LSPに属する特定のS2LサブLSPを識別します。
S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = 1
S2L_SUB_LSPクラス= 50、S2L_SUB_LSP_IPV4 C-TYPE = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 S2L Sub-LSP destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Sub-LSP destination address IPv4 address of the S2L sub-LSP destination.
IPv4 Sub-LSP宛先アドレスS2L Sub-LSP宛先のIPv4アドレス。
S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = 2
S2L_SUB_LSPクラス= 50、S2L_SUB_LSP_IPV6 C-TYPE = 2
This is the same as the S2L IPv4 Sub-LSP object, with the difference that the destination address is a 16-byte IPv6 address.
これは、S2L IPv4 Sub-LSPオブジェクトと同じであり、宛先アドレスが16バイトのIPv6アドレスであるという違いがあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 S2L Sub-LSP destination address (16 bytes) |
| .... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE object.
filter_specオブジェクトは、p2mp sender_templateオブジェクトに正規です。
Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12
class = filter_spec、p2mp lsp_ipv4 c-type = 12
The format of the P2MP LSP_IPv4 FILTER_SPEC object is identical to the P2MP LSP_IPv4 SENDER_TEMPLATE object.
p2mp lsp_ipv4 filter_specオブジェクトの形式は、p2mp lsp_ipv4 sender_templateオブジェクトと同一です。
Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13
class = filter_spec、p2mp lsp_ipv6 c-type = 13
The format of the P2MP LSP_IPv6 FILTER_SPEC object is identical to the P2MP LSP_IPv6 SENDER_TEMPLATE object.
The P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) is defined as identical to the ERO. The class of the P2MP SERO is the same as the SERO defined in [RFC4873]. The P2MP SERO uses a new C-Type = 2. The sub-objects are identical to those defined for the ERO.
P2MP Secondary_Explicit_Routeオブジェクト（SERO）は、EROと同一と定義されます。P2MP SEROのクラスは、[RFC4873]で定義されているSEROと同じです。P2MP Seroは、新しいCタイプ= 2を使用します。サブオブジェクトは、EROで定義されたものと同一です。
The P2MP SECONDARY_RECORD_ROUTE Object (SRRO) is defined as identical to the ERO. The class of the P2MP SRRO is the same as the SRRO defined in [RFC4873]. The P2MP SRRO uses a new C-Type = 2. The sub-objects are identical to those defined for the RRO.
IANA has assigned the following Class Numbers for the new object classes introduced. The Class Types for each of them are to be assigned via standards action. The sub-object types for the P2MP SECONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the same IANA considerations as those of the ERO and RRO [RFC3209].
IANAは、導入された新しいオブジェクトクラスに次のクラス番号を割り当てました。それらのそれぞれのクラスタイプは、標準アクションを介して割り当てられます。P2MP seconver_explicit_routeおよびP2MP_Secondary_Record_Routeのサブオブジェクトタイプは、EROおよびRRO [RFC3209]のIANAの考慮事項に従います。
50 Class Name = S2L_SUB_LSP
50クラス名= S2L_SUB_LSP
C-Type 1 S2L_SUB_LSP_IPv4 C-Type 2 S2L_SUB_LSP_IPv6 C-Type
C-Type 1 S2L_SUB_LSP_IPV4 C-TYPE 2 S2L_SUB_LSP_IPV6 C-TYPE
IANA has assigned the following C-Type values:
IANAは次のCタイプの値を割り当てました。
Class Name = SESSION
クラス名=セッション
C-Type 13 P2MP_LSP_TUNNEL_IPv4 C-Type 14 P2MP_LSP_TUNNEL_IPv6 C-Type
c-type 13 p2mp_lsp_tunnel_ipv4 c-type 14 p2mp_lsp_tunnel_ipv6 c-type
Class Name = SENDER_TEMPLATE
クラス名= sender_template
C-Type 12 P2MP_LSP_TUNNEL_IPv4 C-Type 13 P2MP_LSP_TUNNEL_IPv6 C-Type
c-type 12 p2mp_lsp_tunnel_ipv4 c-type 13 p2mp_lsp_tunnel_ipv6 c-type
Class Name = FILTER_SPEC
クラス名= filter_spec
C-Type 12 P2MP LSP_IPv4 C-Type 13 P2MP LSP_IPv6 C-Type
C-Type 12 P2MP LSP_IPV4 C-TYPE 13 P2MP LSP_IPV6 C-Type
Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])
class name = Secondary_explicit_route（[rfc4873]で定義）
C-Type 2 P2MP SECONDARY_EXPLICIT_ROUTE C-Type
C-Type 2 P2MP Secondar_Explicit_Route C-Type
Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])
class name = Secondary_record_route（[rfc4873]で定義）
C-Type 2 P2MP_SECONDARY_RECORD_ROUTE C-Type
c-type 2 p2mp_secondary_record_route c-type
Five new Error Values are defined for use with the Error Code "Routing Problem". IANA has assigned values for them as follows.
エラーコード「ルーティング問題」で使用するために、5つの新しいエラー値が定義されています。IANAは次のようにそれらの値を割り当てました。
The Error Value "Unable to Branch" indicates that a P2MP branch cannot be formed by the reporting LSR. IANA has assigned value 23 to this Error Value.
「分岐できない」エラー値は、レポートLSRによってP2MP分岐が形成できないことを示しています。IANAはこのエラー値に値23を割り当てました。
The Error Value "Unsupported LSP Integrity" indicates that a P2MP branch does not support the requested LSP integrity function. IANA has assigned value 24 to this Error Value.
エラー値「サポートされていないLSP整合性」は、P2MP分岐が要求されたLSP整合性関数をサポートしていないことを示しています。IANAはこのエラー値に値24を割り当てました。
The Error Value "P2MP Re-Merge Detected" indicates that a node has detected re-merge. IANA has assigned value 25 to this Error Value.
「P2MPが検出された」エラー値「P2MPが検出された」は、ノードが再マスターを検出したことを示します。IANAはこのエラー値に値25を割り当てました。
The Error Value "P2MP Re-Merge Parameter Mismatch" is described in section 18. IANA has assigned value 26 to this Error Value.
エラー値「P2MP Remergeパラメーターの不一致」はセクション18で説明されています。IANAはこのエラー値に値26を割り当てています。
The Error Value "ERO Resulted in Re-Merge" is described in section 18. IANA has assigned value 27 to this Error Value.
エラー値「EROの結果は再マスター」をセクション18で説明します。IANAはこのエラー値に値27を割り当てました。
IANA has been asked to manage the space of flags in the Attributes Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES object [RFC4420]. This document defines a new flag as follows:
IANAは、lsp_required_attributesオブジェクト[rfc4420]で運ばれる属性フラグのフラグのスペースを管理するように求められています。このドキュメントでは、新しいフラグを次のように定義しています。
Bit Number: 3 Meaning: LSP Integrity Required Used in Attributes Flags on Path: Yes Used in Attributes Flags on Resv: No Used in Attributes Flags on RRO: No Referenced Section of this Doc: 5.2.4
ビット番号：3意味：属性で使用されるLSPの整合性パス上のフラグ：はいRESVの属性フラグで使用：rroの属性フラグで使用されます：このドキュメントの参照セクションなし：5.2.4
In principle this document does not introduce any new security issues above those identified in [RFC3209], [RFC3473], and [RFC4206]. [RFC2205] specifies the message integrity mechanisms for hop-by-hop RSVP signaling. These mechanisms apply to the hop-by-hop P2MP RSVP-TE signaling in this document. Further, [RFC3473] and [RFC4206] specify the security mechanisms for non hop-by-hop RSVP-TE signaling. These mechanisms apply to the non hop-by-hop P2MP RSVP-TE signaling specified in this document, particularly in sections 16 and 17.
原則として、このドキュメントでは、[RFC3209]、[RFC3473]、および[RFC4206]で特定されたものよりも新しいセキュリティ問題を導入しません。[RFC2205]ホップバイホップRSVPシグナル伝達のメッセージ整合性メカニズムを指定します。これらのメカニズムは、このドキュメントのホップバイホップP2MP RSVP-TEシグナル伝達に適用されます。さらに、[RFC3473]および[RFC4206]は、非ホップバイホップRSVP-TEシグナル伝達のセキュリティメカニズムを指定します。これらのメカニズムは、このドキュメントで指定された非ホップバイホップP2MP RSVP-TEシグナル伝達、特にセクション16および17に適用されます。
An administration may wish to limit the domain over which P2MP TE tunnels can be established. This can be accomplished by setting filters on various ports to deny action on a RSVP path message with a SESSION object of type P2MP_LSP_IPv4 or P2MP_LSP_IPv6.
管理者は、P2MP TEトンネルを確立できるドメインを制限したい場合があります。これは、さまざまなポートにフィルターを設定して、タイプP2MP_LSP_IPV4またはP2MP_LSP_IPV6のセッションオブジェクトを使用してRSVPパスメッセージのアクションを拒否することで実現できます。
The ingress LSR of a P2MP TE LSP determines the leaves of the P2MP TE LSP based on the application of the P2MP TE LSP. The specification of how such applications will use a P2MP TE LSP is outside the scope of this document. Applications MUST provide a mechanism to notify the ingress LSR of the appropriate leaves for the P2MP LSP. Specifications of applications within the IETF MUST specify this mechanism in sufficient detail that an ingress LSR from one vendor can be used with an application implementation provided by another vendor. Manual configuration of security parameters when other parameters are auto-discovered is generally not sufficient to meet security and interoperability requirements of IETF specifications.
P2MP TE LSPの侵入LSRは、P2MP TE LSPの適用に基づいてP2MP TE LSPの葉を決定します。このようなアプリケーションがP2MP TE LSPを使用する方法の仕様は、このドキュメントの範囲外です。アプリケーションは、P2MP LSPに適切な葉を侵入LSRに通知するメカニズムを提供する必要があります。IETF内のアプリケーションの仕様このメカニズムを、あるベンダーからのIngress LSRを別のベンダーが提供するアプリケーション実装で使用できるように、このメカニズムを十分に詳細に指定する必要があります。他のパラメーターが自動検出されている場合のセキュリティパラメーターの手動構成では、一般にIETF仕様のセキュリティおよび相互運用性要件を満たすのに十分ではありません。
This document is the product of many people. The contributors are listed in Appendix B.
このドキュメントは、多くの人々の産物です。貢献者は付録Bにリストされています
Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger, and Nischal Sheth for their suggestions and comments. Thanks also to Dino Farninacci and Benjamin Niven for their comments.
Yakov Rekhter、Der-Hwa Gan、Arthi Ayyanger、Nischal Shethの提案とコメントに感謝します。Dino FarninacciとBenjamin Nivenのコメントにも感謝します。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、RFC 4206、2005年10月。
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
[RFC4420] Farrel、A.、ed。、Papadimitriou、D.、Vasseur、J.-P。、およびA. Ayyangar、「リソース予約を使用したマルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）確立の属性のエンコーディングプロトコルトラフィックエンジニアリング（RSVP-TE） "、RFC 4420、2006年2月。
[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年。
[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月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F。、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、RFC 2961、2001年4月。
[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月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan、P.、Ed。、Ed。、Swallow、G.、Ed。、およびA. Atlas、ed。、「LSP TunnelsのRSVP-TEへの拡張速度」、RFC 4090、2005年5月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K。およびY. Rekhter、「リソース予約プロトコルにおける無数のリンク - トラフィックエンジニアリング（RSVP -TE）」、RFC 3477、2003年1月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, April 2007.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「Gmplsセグメントリカバリー」、RFC 4873、2007年4月。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461] Yasukawa、S.、ed。、「ポイントツーマルチポイントトラフィックエンジニアリングMPLSラベルスイッチドパス（LSP）のシグナリング要件」、RFC 4461、2006年4月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, March 2007.
[BFD] Katz、D。およびD. Ward、「双方向転送検出」、2007年3月、進行中の作業。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD for MPLS LSPs", Work in Progress, March 2007.
[BFD-MPLS] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLS LSPSのbfd」、2007年3月の作業。
[LSP-STITCH] Ayyanger, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", Work in Progress, March 2007.
[LSP-Stitch] Ayyanger、A.、Kompella、K.、Vasseur、Jp。、およびA. Farrel、「一般化されたマルチプロトコルラベルスイッチングトラフィックエンジニアリング（GMPLS TE）を使用したラベルスイッチパスステッチ」、2007年3月の作業。
[TE-NODE-CAP] Vasseur, JP., Ed., Le Roux, JL., Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", Work in Progress, April 2007.
[Te-Node-Cap] Vasseur、JP。、ed。、Le Roux、Jl。、ed。、「IGPルーティングプロトコル拡張機能のためのトラフィックエンジニアリング節型機能の発見」、2007年4月、進行中の作業。
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
[RFC4003] Berger、L。、「GMPLS Signaling Procedure for Eugress Control」、RFC 4003、2005年2月。
The Following is one example of setting up a P2MP LSP using the procedures described in this document.
以下は、このドキュメントで説明されている手順を使用してP2MP LSPをセットアップする例です。
Source 1 (S1)
|
PE1
| |
|L5 |
P3 |
| |
L3 |L1 |L2
R2----PE3--P1 P2---PE2--Receiver 1 (R1)
| L4
PE5----PE4----R3
|
|
R4
Figure 2.
The mechanism is explained using Figure 2. PE1 is the ingress LSR. PE2, PE3, and PE4 are egress LSRs.
メカニズムは図2を使用して説明されています。PE1は侵入LSRです。PE2、PE3、およびPE4は、出口LSRです。
a) PE1 learns that PE2, PE3, and PE4 are interested in joining a P2MP tree with a P2MP ID of P2MP ID1. We assume that PE1 learns of the egress LSRs at different points in time.
a) PE1は、PE2、PE3、およびPE4がP2MP ID1のP2MP IDでP2MPツリーを結合することに関心があることを学びます。PE1は、さまざまな時点で出口LSRを学習すると想定しています。
b) PE1 computes the P2P path to reach PE2.
b) PE1はP2Pパスを計算してPE2に到達します。
c) PE1 establishes the S2L sub-LSP to PE2 along <PE1, P2, PE2>.
c) PE1は、<PE1、P2、PE2>に沿ってS2LサブLSPをPE2に確立します。
d) PE1 computes the P2P path to reach PE3 when it discovers PE3. This path is computed to share the same links where possible with the sub-LSP to PE2 as they belong to the same P2MP session.
d) PE1は、PE3を発見したときにPE3に到達するためにP2Pパスを計算します。このパスは、同じP2MPセッションに属しているため、可能な限り同じリンクをSub-LSPからPE2に共有するように計算されます。
e) PE1 establishes the S2L sub-LSP to PE3 along <PE1, P3, P1, PE3>.
e) PE1は、<PE1、P3、P1、PE3>に沿ってS2LサブLSPをPE3に確立します。
f) PE1 computes the P2P path to reach PE4 when it discovers PE4. This path is computed to share the same links where possible with the sub-LSPs to PE2 and PE3 as they belong to the same P2MP session.
f) PE1は、PE4を発見したときにPE4に到達するためにP2Pパスを計算します。このパスは、同じP2MPセッションに属しているため、可能な限り同じリンクをSub-LSPとPE2およびPE3に共有するように計算されます。
g) PE1 signals the Path message for PE4 sub-LSP along <PE1, P3, P1, PE4>.
g) PE1は、<PE1、P3、P1、PE4>に沿ったPE4サブLSPのパスメッセージを信号します。
h) P1 receives a Resv message from PE4 with label L4. It had previously received a Resv message from PE3 with label L3. It had allocated a label L1 for the sub-LSP to PE3. It uses the same label and sends the Resv messages to P3. Note that it may send only one Resv message with multiple flow descriptors in the flow descriptor list. If this is the case, and FF style is used, the FF flow descriptor will contain the S2L sub-LSP descriptor list with two entries: one for PE4 and the other for PE3. For SE style, the SE filter spec will contain this S2L sub-LSP descriptor list. P1 also creates a label mapping of (L1 -> {L3, L4}). P3 uses the existing label L5 and sends the Resv message to PE1, with label L5. It reuses the label mapping of {L5 -> L1}.
h) P1は、ラベルL4を使用してPE4からRESVメッセージを受信します。以前は、ラベルL3を備えたPE3からRESVメッセージを受信していました。サブLSPのラベルL1をPE3に割り当てていました。同じラベルを使用して、RESVメッセージをP3に送信します。フロー記述子リストに複数のフロー記述子を含む1つのRESVメッセージのみを送信できることに注意してください。この場合、FFスタイルが使用される場合、FFフロー記述子には、2つのエントリを備えたS2LサブLSP記述子リストが含まれます。1つはPE4用、もう1つはPE3用です。SEスタイルの場合、SEフィルター仕様にはこのS2LサブLSP記述子リストが含まれます。P1は、（l1-> {l3、l4}）のラベルマッピングも作成します。P3は既存のラベルL5を使用し、RESVメッセージをラベルL5でPE1に送信します。{l5-> l1}のラベルマッピングを再利用します。
John Drake Boeing EMail: john.E.Drake2@boeing.com
Alan Kullberg Motorola Computer Group 120 Turnpike Road 1st Floor Southborough, MA 01772 EMail: alan.kullberg@motorola.com
Alan Kullberg Motorola Computer Group 120 Turnpike Road 1st Floor Southborough、MA 01772メール：alan.kullberg@motorola.com
Lou Berger LabN Consulting, L.L.C. EMail: lberger@labn.net
Lou Berger Labn Consulting、L.L.C。メール：lberger@labn.net
Liming Wei Redback Networks 350 Holger Way San Jose, CA 95134 EMail: lwei@redback.com
Liming Wei Redback Networks 350 Holger Way San Jose、CA 95134メール：lwei@redback.com
George Apostolopoulos Redback Networks 350 Holger Way San Jose, CA 95134 EMail: georgeap@redback.com
George Apostolopoulos Redback Networks 350 Holger Way San Jose、CA 95134メール：georgeap@redback.com
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: kireeti@juniper.net George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA EMail: swallow@cisco.com
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089メール：kireeti@juniper.net George Swallow Cisco Systems、Inc。
JP Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA EMail: jpv@cisco.com Dean Cheng Cisco Systems Inc. 170 W Tasman Dr. San Jose, CA 95134 Phone 408 527 0677 EMail: dcheng@cisco.com
JP Vasseur Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA -01719 USAメール：jpv@cisco.com Dean Cheng Cisco Systems Inc. 170 W Tasman Dr. San Jose、CA 95134電話408 527 0677メール：dcheng@cisco。com
Markus Jork Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 Phone: +1 978 964 2142 EMail: mjork@avici.com
Markus Jork Avici Systems 101 Billerica Avenue N. Billerica、MA 01862電話：1 978 964 2142メール：mjork@avici.com
Hisashi Kojima NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6070 EMail: kojima.hisashi@lab.ntt.co.jp
ヒサシウジマNTTコーポレーション9-11、Midori-Cho 3-Chome Musashino-Shi、Tokyo 180-8585日本電話：81 422 59 6070メール：kojima.hisashi@lab.ntt.co.jp
Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose, CA 95134 Phone: +1 408 383 7223 EMail: Andy.Malis@tellabs.com
Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose、CA 95134電話：1 408 383 7223電子メール：andy.malis@tellabs.com
Koji Sugisono NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 2605 EMail: sugisono.koji@lab.ntt.co.jp Masanori Uga NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4804 EMail: uga.masanori@lab.ntt.co.jp
Koji Sugisono ntt Corporation 9-11、Midori-Cho 3-Chome Musashino-Shi、Tokyo 180-8585日本電話：81 422 59 2605メール：sugisono.koji@lab.ntt.co.jp masanori uga ntt Corporation 9-11、Midori-Cho 3-Chome Musashino-Shi、Tokyo 180-8585日本電話：81 422 59 4804メール：uga.masanori@lab.ntt.co.jp
Igor Bryskin Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102 ibryskin@movaz.com Adrian Farrel Old Dog Consulting Phone: +44 0 1978 860944 EMail: adrian@olddog.co.uk
Igor Bryskin Movaz Networks、Inc。7926 Jones Branch Drive Suite 615 McLean VA、22102 ibryskin@movaz.com Adrian Farrel Old Dog Consulting電話：44 0 1978 860944メール：adrian@olddog.co.uk
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: jeanlouis.leroux@francetelecom.com
Jean-Louis Le Roux France Telecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex Franceメール：jeanlouis.leroux@francetelecom.com
Editors' Addresses
編集者のアドレス
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: rahul@juniper.net
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089メール：rahul@juniper.net
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
Seisho Yasukawa NTT Corporation 9-11、Midori-Cho 3-Chome Musashino-Shi、Tokyo 180-8585日本電話：81 422 59 4769電子メール：Yasukawa.seisho@lab.ntt.co.jp
Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: Dimitri.Papadimitriou@alcatel-lucent.be
Dimitri Papadimitriou Alcatel Francis Wellesplein 1、B-2018 Antwerpen、Belgium電話：32 3 240-8491メール：dimitri.papadimitriou@alcatel-lucent.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。