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)
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）IETFトラスト（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.
この文書では、予約プロトコルリソースへの拡張を説明 - 交通エンジニア（TE）のセットアップのためのトラフィックエンジニアリング（RSVP-TE）をポイント・ツー・マルチポイント（P2MP）ラベル（MPLS）マルチプロトコルラベルスイッチングにおけるスイッチパス（LSP）と一般化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]は、ポイント・ツー・ポイントを設定するためのメカニズムを定義する（P2P）トラヒックエンジニアリング（TE）ラベル（MPLS）ネットワークをマルチプロトコルラベルスイッチングのパス（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は、入口と出口LSRs間に設定され、適切P2MP TE LSPをもたらすようにRSVPセマンティクスを使用して、分岐のLSRによって合成されます。一つのPathメッセージは、単一のP2MP LSPのための1つまたは複数のS2LサブLSPをシグナリングすることができます。したがってP2MP LSPに属するS2LサブLSPは複数のPathメッセージを横切って一つのパス・メッセージまたは分割を使用してシグナリングすることができます。
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].
このドキュメントは[RFC2205]で定義された用語を使用して、[RFC3031]、[RFC3209]、[RFC3473]、[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.
この文書は、複製/ブランチノードであることを、ネットワーク内の非侵入ノードを可能にすることにより、データの複製を最適化するソリューションを説明しています。ブランチノードは、一つ以上の発信インターフェイスへの着信データを複製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トンネルを記述し、それらがどのようにサブLSPをS2Lに関連して、次のサブセクションにさらに記載されています。
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ラベルされたデータは、データのために異なるラベルを使用することができる発信インターフェイスに複製されます。
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トンネルは、一の以上のP2MP LSPを含みます。 P2MP TEトンネルはP2MPセッションオブジェクトによって識別されます。このオブジェクトは、P2MP識別子（P2MP ID）、トンネル識別子（トンネルID）、および拡張トンネル識別子（拡張トンネルID）を含むP2MPセッションの識別子を含みます。 P2MP IDは4オクテットの数であり、入口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は>タプルは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セッションオブジェクトのフィールドは、トンネルエンドポイントアドレスフィールドはP2MP IDフィールドによって置き換えられることを除いて、[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 ID、トンネルID、および拡張P2MPセッション・オブジェクトの一部であるトンネル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
他のすべてのRSVP制御のLSPと同じように、P2MP LSP状態がRSVPメッセージを使用して管理されています。 RSVPメッセージの使用は同じであるが、P2MP LSPの状態は、多くの方法でP2P LSPの状態とは異なります。 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.
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状態におけるこれらの差異はSENDER_TEMPLATEとFILTER_SPECオブジェクトにサブグループ識別子（サブグループID）とサブグループの発信者（サブグループオリジネータID）の添加によって対処されます。まとめると、サブグループ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とSESSIONオブジェクトの残りの部分と、P2MP LSPの状態の一部を表すために使用されます。 P2MP LSPの状態のこの部分は、状態だけではなく、データプレーン複製シグナリングまたは分岐を指します。例えば、P2MP LSPの状態をシグナリング「ブランチ」のノードのために可能であるが、P2MP LSPに関連するデータを分岐しないこと。複数のサブグループの生成及び使用するための典型的な用途は、出力の（1）の添加およびPathメッセージは、単一のIPパケット内に留まることを確実にする（2）セマンティック断片です。
A P2MP LSP is constituted of one or more S2L sub-LSPs.
P2MP LSPは、一つ以上のS2Lサブ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 ID、トンネルID、および拡張P2MPセッションの一部であるトンネル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.
EXPLICIT_ROUTEオブジェクト（ERO）またはP2MP_SECONDARY_EXPLICIT_ROUTEオブジェクト（SERO）はS2LサブLSPの明示的なルートを指定任意に使用されます。特定S2L_SUB_LSPオブジェクトに対応するシグナリングされる各ERO又はSERO。明示的経路エンコーディングの詳細はセクション4.5で指定されています。 SECONDARY_EXPLICIT_ROUTEオブジェクトが新しいP2MP SECONDARY_EXPLICIT_ROUTEオブジェクトC型は、セクション19.5で定義され、[RFC4873]で定義され、そしてマッチング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つ以上のPathメッセージを使用してシグナリングすることを可能にします。各Pathメッセージは、一つ以上のS2LサブLSPをシグナリングすることができます。複数のPathメッセージのサポートは、すべてのS2LサブLSPを収容するのに十分な大きさではないかもしれない一つのパスメッセージとして望ましいです。そして彼らはまた、P2MP LSPのサブツリーの独立した操作を可能に。単一のPathメッセージは、複数のS2Lサブ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.
Pathメッセージは、単一のS2LサブLSP（すなわち、PathメッセージのみP2MPツリーの単一の葉をターゲットにしている）信号場合、EXPLICIT_ROUTEオブジェクトが出口LSRへのパスを符号化します。 Pathメッセージはまた、シグナリングさS2LサブLSP用S2L_SUB_LSPオブジェクトを含みます。 <<EXPLICIT_ROUTE>]、<S2L_SUB_LSP>>タプルはS2LサブLSPを表し、サブLSP記述子と呼ばれます。 EROの不在はS2L_SUB_LSPオブジェクトのS2Lサブ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.
Pathメッセージは、複数のS2LサブLSPを知らせる場合、出口LSRへの最初のS2LサブLSPの経路は、EROで符号化されます。最初のS2LサブLSPは、Pathメッセージの最初S2L_SUB_LSPオブジェクトに対応するものです。従いS2L_SUB_LSPオブジェクトに対応するS2LサブLSPは、後続のS2Lサブの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 SECONDARY_EXPLICIT_ROUTE>]、<S2L_SUB_LSP>>フォームのタプルで表されます。特定のS2LサブLSPのためのSEROは、S2LサブLSPの出口LSRへの分岐LSRからパスのみを含みます。ブランチはEROまたはいくつかの他のSEROで明示的にホップとして現れなければなりません。 SEROの不在は、S2LサブLSPのためのホップバイホップルーティングを必要とすると解釈されるべきです。宛先アドレスがS2Lサブ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サブ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:
（F、N、O、P、Q及びR）：図1は、入口LSR六の出口LSRsとしてLSR AとP2MP LSPを示しています。すべての6つのS2LサブLSPを1つのパスメッセージで通知されたとき、私たちはLSR FへのS2LサブLSPが最初のS2LサブLSPがあると仮定しましょう、そして残りは、その後のS2LサブLSPをしています。次の符号化は、圧縮を使用してS2LサブLSPの明示的なルートを符号化するための入口LSR Aのための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
S2LサブLSP-F：ERO = {B、E、D、C、F}、<S2L_SUB_LSP>オブジェクト-F S2LサブLSP-N：SERO = {D、G、J、N}、<S2L_SUB_LSP>オブジェクト-N S2LサブLSP-O：SERO = {E、H、K、O}、<S2L_SUB_LSP>オブジェクトO S2LサブLSP-P：SERO = {H、L、P}、<S2L_SUB_LSP>オブジェクト-P S2LサブLSP-Q：SERO = {H、I、M、Q}、<S2L_SUB_LSP>オブジェクト-Q S2LサブLSP-R：SERO = {Q、R}、<S2L_SUB_LSP>オブジェクト-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から受信Pathメッセージを処理した後、それは次のようにエンコードされたS2Lサブ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
S2LサブLSP-F：ERO = {D、C、F}、<S2L_SUB_LSP>オブジェクト-F S2LサブLSP-N：SERO = {D、G、J、N}、<S2L_SUB_LSP>オブジェクト-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にPathメッセージを送信し、次の圧縮を使用して、S2LサブLSPの明示的なルートを符号化する一つの方法です。
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
S2LサブLSP-O：ERO = {H、K、O}、<S2L_SUB_LSP>オブジェクトO S2LサブLSP-P：SERO = {H、L、P}、S2L_SUB_LSPオブジェクト-P S2LサブLSP-Q ：SERO = {H、I、M、Q}、<S2L_SUB_LSP>オブジェクト-Q S2LサブLSP-R：SERO = {Q、R}、<S2L_SUB_LSP>オブジェクト-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からの着信Pathメッセージを処理した後、それはLSR K、LSR L、およびLSR I. LSR KのPathメッセージのエンコードに対するPathメッセージを送信する次の通りであります：
S2L sub-LSP-O: ERO = {K, O}, <S2L_SUB_LSP> object-O
S2LサブLSP-O：ERO = {K、O}、<S2L_SUB_LSP>オブジェクト-O
The encoding of the Path message sent by LSR H to LSR L is as follows:
次のようにLSR LにLSR Hによって送信されたPathメッセージの符号化は、次のとおりです。
S2L sub-LSP-P: ERO = {L, P}, <S2L_SUB_LSP> object-P
S2LサブLSP-P：ERO = {L、P}、<S2L_SUB_LSP>オブジェクト-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に送信されたPathメッセージにS2LサブLSPの明示的経路をコードするための一つの方法です。
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
S2LサブLSP-Q：ERO = {I、M、Q}、<S2L_SUB_LSP>オブジェクト-Q S2LサブLSP-R：SERO = {Q、R}、<S2L_SUB_LSP>オブジェクト-R
The explicit route encodings in the Path messages sent by LSRs D and Q are left as an exercise for the reader.
LSRのDとQによって送信されたPathメッセージで明示的経路エンコーディングは、読者の練習として残しています。
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.
この圧縮機構は、Pathメッセージのサイズが小さくなります。それはまた、明示的なルートが各S2LサブLSPのための出口を入口から符号化される場合に生じ得る余分な処理を減少させます。何の仮定は、後続のS2LサブLSPの順序で、従ってPathメッセージにおけるSEROsの順序に配置されていません。すべてのLSRは、最初のS2LサブLSPに対応するEROを処理する必要があります。 LSRは、対応SEROの最初のホップがそのLSRのローカルアドレスである場合にのみ、その後のS2LサブLSPためS2Lサブ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]で指定されるように、このセクションでは、Pathメッセージフォーマットに行われた変更を記載しています。 Pathメッセージは、一つ以上のS2LサブLSPを通知するために強化されています。これは、以下に示すように、PathメッセージにS2Lサブ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サブ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は、PathメッセージとS2L_SUB_LSPオブジェクトとSECONDARY- / EXPLICIT_ROUTEオブジェクトの組み合わせによって表される各S2LサブLSPを処理する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サブLSP記述子>の定義に従って、各S2L_SUB_LSPオブジェクトは、対応するSEROが続いてもよいです。第S2L_SUB_LSPオブジェクトは特殊なケースであり、その明示的な経路がEROによって指定されます。したがって、第1 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は、Pathメッセージが通過する上流のホップが含まれており、サブのLSPは、Pathメッセージに合図すべてのS2Lに適用されます。
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]への制御チャネルの一対一の関連がないリンクで使用されなければなりません。 [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.
入口LSRは、P2MP LSPの送信先である各出口LSRへS2LサブLSPの設定を開始します。各S2LサブLSPは、共通P2MPセッションオブジェクトとP2MP SENDER_TEMPLATEオブジェクト内の<送信者のアドレス、LSP-ID>フィールドを使用して同一のP2MP LSPに関連しています。したがって、P2MP LSPを形成するために他のS2LサブLSPを組み合わせることができます。このS2LサブLSP（すなわち、同一のP2MP LSP）の同じインスタンスに属する他のS2LサブLSPがこのS2LサブLSPでリソースを共有する必要があります。 P2MP TEトンネルに対応するセッションがP2MPセッションオブジェクトに基づいて決定されます。各S2LサブLSPはS2L_SUB_LSPオブジェクトを使用して識別されます。 S2Lサブ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つ又はそれ以上のPathメッセージで与えられたP2MP LSPのためのS2LサブLSPをシグナリングすることができ、所定のPathメッセージは、一つ以上のS2LサブLSPを含むことができます。 RSVP-TEをサポートするLSRは、P2MPのLSPが同一のP2MP LSP一のPathメッセージ内の複数のS2LサブLSPのためのマルチパスメッセージを受信し、処理できなければなりません合図しました。これは、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.
、セクション4で説明したようにいずれか<[<EXPLICIT_ROUTE> <S2L_SUB_LSP>>または<[<P2MP SECONDARY_EXPLICIT_ROUTE> <S2L_SUB_LSP>>タプルはS2LサブLSPを指定するために使用されます。複数のPathメッセージは、P2MP LSPを知らせるために使用することができます。各Pathメッセージは、一つ以上のS2LサブLSPをシグナリングすることができます。 Pathメッセージには一つだけS2LサブLSP、S2LサブLSPに沿った各LSRが含まれている場合は、この文書に記載さS2L_SUB_LSPオブジェクト処理以外Pathメッセージを処理するための[RFC3209]の手順に従います。
Processing of Path messages containing more than one S2L sub-LSP is described in section 5.2.2.
複数のS2LサブLSPを含むPathメッセージの処理は、セクション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.
入口LSRは、P2MP LSPをシグナリングするための複数のPathメッセージを使用するかもしれません。シングルパスメッセージはP2MP LSPをシグナリングするのに十分な大きさではないかもしれないので、これがあってもよいです。それとも、新しい葉がP2MP LSPに追加されたとき、彼らは新しいPathメッセージで通知されている可能性があります。または入口LSRは、個別の管理可能P2MPツリーにP2MPツリーを破るために選ぶかもしれません。これらの木は同じルートを共有し、トランクや特定の枝を共有することがあります。 P2MPツリーのこの管理分解の範囲は、単一のリーフ毎（S2LサブたLSP）を有する単一のツリー（P2MPツリー）と複数のツリーによって制限されます。 [RFC4461]あたり、P2MP LSPは、ツリーのすべての部分にわたって一貫した属性を持たなければなりません。これはS2LサブLSP記述子およびサブグループ識別子を除いて属性P2MP LSPをシグナリングするために使用される各Pathメッセージが同じシグナリングを使用してシグナリングされることを意味します。
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に属する異なるPathメッセージから得られたサブ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.
ある場合には、中継LSRは、単一の受信したPathメッセージに対応する状態を知らせるために、複数のPathメッセージを生成する必要があるかもしれません。例えばERO拡張が得られたPathメッセージのオーバーフローを生じ得ます。この場合、メッセージは、各メッセージが着信メッセージによって運ばX2Lサブツリーのサブセットを運ぶように、複数のPathメッセージに分解することができます。
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によって生成された複数のPathメッセージは、同じセッションオブジェクトに合図とSENDER_TEMPLATEオブジェクトに同じ<ソースアドレス、LSP-ID>を有しています。これらのPathメッセージを明確にするために、<サブグループオリジネータID、サブ・グループIDは>タプルが導入される（また、サブグループフィールドと呼ばれる）とSENDER_TEMPLATEオブジェクトでエンコード。同じP2MP LSPの状態を知らせるためにLSRによって生成された複数のPathメッセージは、同じサブグループ発信者IDを有し、異なるサブグループIDを有しています。サブグループ創始IDは、Pathメッセージを発信するLSRのTEルータIDを設定しなければなりません。トランジットLSRは、受信Pathメッセージのサブグループ発信者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サブLSP記述子リストは、一のPathメッセージ内の1つまたは複数のS2Lサブ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を処理しなければなりません。一つ以上のSEROsが存在する場合、EROが存在しなければなりません。 EROが存在する場合、最初S2LサブLSPは、EROによって指定された明示的なルートに沿って各LSRによってPathメッセージに伝搬されなければなりません。そうでなければ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記述子は、決定された次のホップに送信されたPathメッセージに含まれなければなりませんSEROから。
- 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に送信されたPathメッセージに含まれなければなりません。この次ホップは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.
- S2L_SUB_LSPオブジェクトによって識別されるように、このLSRが出ている場合は、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は出口に向かって次のホップを決定するためのルーティング決定を行うなければなりません、そして、次のホップに送信されたPathメッセージにS2LサブLSP記述子を含まなければなりません出口に向けました。この場合、LSRはS2Lサブ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を含まなければなりません。この処理は、送信Pathメッセージ内の最初のS2LサブLSPなって着信Pathメッセージに後続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.
一つ以上のSEROsが緩んホップが含まれている場合は、そのようなゆるいホップの拡張は、Pathメッセージのサイズをオーバーフローにつながるかもしれないことに注意してください。セクション5.2.3はS2LサブLSPの組の信号が複数のPathメッセージに分割することができる方法について説明します。
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）は、Pathメッセージによって横断ホップを含み、サブのLSPパスメッセージでシグナリング全てS2Lに適用されます。トランジットLSRは、着信RROにそのアドレスを追加し、下流に伝播しなければなりません。ブランチLSRは、受信PathメッセージからRROをコピーし、そのアドレスを追加することによって、送信するPathメッセージのそれぞれのための新たなRROを形成しなければなりません。各そのような更新されたRROは、必要に応じて、[RFC3209]のルールを使用して形成された（及び[RFC3473]によって更新）されなければなりません。
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は、PathメッセージにS2LサブLSPをサポートすることができない場合（例えば、それはSEROを使用して目的地に向かうルートすることができない）、のPathErrメッセージは影響S2LサブLSP、および通常の処理のために送らなければなりませんP2MP LSPの残りの継続する必要があります。デフォルトの動作は、LSPの残りの部分は影響を受けないということである（つまり、他のすべての支店を設定するために許可されている）、失敗した枝はPath_State_RemovedフラグがセットされてはならないいるのPathErrメッセージで報告されています。しかし、入口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.
ある場合には、中継LSRは、単一の受信したPathメッセージに対応する状態を知らせるために、複数のPathメッセージを生成する必要があるかもしれません。例えば、ERO拡張が得られたPathメッセージのオーバーフローを生じ得ます。 RSVP [RFC2205]はIP断片化の使用を禁止し、したがってIP断片化は、この場合には回避されなければなりません。これを達成するために、中継LSRによって生成された複数のPathメッセージは、中継LSRのTEルータIDに設定サブグループオリジネータIDと、それぞれのPathメッセージのための別個のサブグループIDを用いてシグナリングされます。したがって、P2MP LSPの中継LSRによって生成された各個別のPathメッセージは、異なる<サブグループオリジネータID、サブグループID>タプルを運びます。
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.
複数のPathメッセージを入力またはトランジットノードによって使用されるとき、各PathメッセージはS2LサブLSP関連記述子（例えば、SERO）を除いて同一である必要があり、メッセージ及び情報をホップ（例えば、INTEGRITY、MESSAGE_ID、及びRSVP_HOP） SENDER_TEMPLATEオブジェクトの、およびサブグループフィールド。 （セクション14.1で指定されるように）メーク・ビフォア・ブレーク操作が行われている場合を除いて、トンネルの送信元アドレスとLSP IDフィールドは、各メッセージで同じでなければなりません。トランジットノードの場合、彼らは、受信したPathメッセージにおける値と同じでなければなりません。
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.
上述したように、受信したPathメッセージのサブグループオリジネータIDが変更された一つの場合は、トランジットノードのPathメッセージの断片です。別の場合には、受信したPathメッセージのサブグループオリジネータIDは、発信Pathメッセージに変更し、ローカルポリシーに基づいて、Pathメッセージを発信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.
LSPのセットアップ中またはLSPが確立された後に障害が発生した場合には、入口LSRは、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.
入口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".
属性フラグにTLVをサポートしており、このビットを認識し、分岐LSRは、LSPの整合性をサポートしたり、エラー「ルーティングエラー」/「サポートされていないLSPの整合性」を運ぶのPathErrメッセージで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サブLSPを追加するには、2つの方法があります。最初は、既存のPathメッセージに追加し、全体のPathメッセージをリフレッシュしてP2MP LSPに新しいS2LサブLSPを追加することです。 P2MP LSPこれらS2LサブLSPを追加することでセクション4の結果に記載パスメッセージ処理。 Pathメッセージには一つ以上の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.
第二は、セクション10.1で説明増分更新を使用することです。出口LSRsは、新しいパスメッセージにのみ影響S2Lサブ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サブLSP記述子と同じフォーマットを有します。 P2MP_SECONDARY_RECORD_ROUTEオブジェクトは、P2MP SECONDARY_EXPLICIT_ROUTEオブジェクトと同じ圧縮機構に従ってください。 Resvメッセージが同じFILTER_SPECオブジェクトまたは異なるFILTER_SPECオブジェクトに属することができる複数のS2LサブLSPを知らせることができることに留意されたいです。 FILTER_SPECオブジェクトの<送信者アドレス、LSP-ID>フィールドが同じであれば同一のラベルが割り当てられるべきです。
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異なるP2MP LSPを指すことを意味するようにFILTER_SPECオブジェクトの<送信者アドレス、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.
Resvメッセージを発信しながら、出口LSRは、通常のRSVPの手順に従わなければなりません。セクション6.1で定義されたRESVメッセージのフォーマットがあります。通常通り、Resvメッセージは、出口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メッセージの上流にそれを通過しなければなりません。ノードは、アップストリーム送信された1つのResvメッセージに、下流側から受信した異なるRESVメッセージから、複数の流れ記述子を組み合わせることができます。少なくとも一つの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記述子リストを含みます。同一のResvに同じP2MP LSP（一つまたは複数のResvメッセージのかどうか）のためにこのような各FFフロー記述又はSEフィルタスペックは、同じラベルを割り当てなければならない、と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から出口LSRsへP2MP LSPの設定になります。
The ingress LSR may need to understand when all desired egresses have been reached. This is achieved using S2L_SUB_LSP objects.
入口LSRは、すべての希望egressesに達したときに理解する必要があるかもしれません。これは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メッセージを転送することができます。大型でRESVメッセージの数と多くの受信機とのLSPのための入口LSRに近いがあってもよいことに留意されたいです。分岐LSR（セクション6.2.1を参照）の上流送信する単一のResvメッセージに複数の受信機からのResv状態を組み合わせるべきです。しかし、LSRは、入口LSRに近いほどこれは特に、任意の分岐LSR増加の下流受信機の数として、Resvメッセージをオーバーフローをもたらすことができることに留意されたいです。このように、分岐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.
トランジットノードは、Pathメッセージにサブグループ発信者フィールドを設定すると、それはサブグループフィールドは、それが最初のパスのサブグループフィールドに受信した値と任意の関連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.
ブランチノードは、サブLSP下流ネイバーの1つから受信S2LためのResvメッセージに変更があるたびに、上流改訂Resvメッセージを送信することを有してもよいです。これはS2Lサブた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メッセージは、入口LSRは、元のPathメッセージにRROを含むことによって、ルート記録を要求した場合に記録された経路を含んでいます。同じルールは、P2MP LSPのシグナリングの際に使用されます。すなわち、一つ以上のS2LサブのLSPはResvメッセージの各サブLSPのために記録された経路の包含をトリガー通知するために使用PathメッセージにRROを含むことです。
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サブLSPのための追加記録経路はP2MP_SECONDARY_RECORD_ROUTEオブジェクト（SRROs）で符号化されます。そのフォーマットは、セクション19.5に指定されています。 Resvにおける各S2L_SUB_LSPオブジェクトは、RROまたはSRROに関連付けられています。 （最初のS2LサブLSPのための）第一S2L_SUB_LSPオブジェクトはRROと関連しています。 （後続のS2LサブLSPのための）後続S2L_SUB_LSPオブジェクトが各ブランチに葉からのS2LサブLSPのために記録された経路が含まSRROが続きます。入口ノードは、各S2LサブLSPのためのエンドツーエンドパスを決定するために、RROとSRROsを使用することができます。
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をと同じP2MPトンネルに属し、その後S2LサブLSPは、リソースを共有する必要がありますが、パケット環境でのラベルを共有することはできません。
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.
<送信者記述子>の定義は、この文書では変更されません。
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をアドバタイズパスまたはResvメッセージのための修正されたメッセージを送信することにより、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サブLSPを削除するために使用される場合に、Pathメッセージを修正することによって、中継LSRは、これらのS2LサブLSPの一つ以上を削除する下流PathTearメッセージを生成する必要があります。 S2LサブLSP（S）の暗黙的な欠失の結果として残存S2LサブのLSPが存在しない場合、これは下流の対応するPathメッセージで送信するように起こることができます。
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サブLSPをティアダウンは、対応するPathメッセージのためのPathTearメッセージを生成することに依存します。 PathTearメッセージは、セッションでシグナリングされるとSENDER_TEMPLATEオブジェクトはPathメッセージに対応するタプルP2MP LSPと<サブグループオリジネータID、サブグループID>に対応します。 Pathメッセージによってシグナリング全てegressesはP2MP LSPから除去する必要がある場合、このアプローチを用いるべきです。他のサブグループから他のS2LサブLSPは、PathTearによって影響されない、他のPathメッセージを使用して合図しました。
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メッセージは下流がS2Lサブを設定するために使用されたPathメッセージに使用される値にPathTearメッセージ内の<サブグループオリジネータID、サブグループID>タプルを設定することを保証しなければならない伝播トランジットLSR LSPは取り壊されています。トランジットLSRは、それが対応する受信Pathメッセージの中継の断片化を実行した場合、着信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を入力することにより除去されると、PathTearメッセージは、P2MP LSPをシグナリングするために使用される各Pathメッセージに対して生成されなければなりません。
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].
Requestオブジェクトに通知し、通知メッセージを[RFC3473]に記載されています。オブジェクトとメッセージの両方は、上流と下流の通知の配信のためにサポートされます。このセクションでは詳述しない処理は、[RFC3473]に準拠しなければなりません。
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.
トランジットLSRは、自身のアドレスへのPathメッセージのSENDER_TEMPLATEオブジェクト内のサブグループ発信者IDを設定し、着信Pathメッセージは、通知要求オブジェクトを運ぶ、このLSRはに通知Requestオブジェクトに通知ノードアドレスを変更する必要がある場合それが送信するPathメッセージで自身のアドレス。
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.
- LSRはPathメッセージで受信した通知ノードアドレスに向かって上流に通知メッセージを送信します。
- 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に基づいて、このメッセージで参照状態を識別しなければなりません。
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:
トランジットLSRは、対応するPathメッセージで受信された値にResvメッセージのFILTER_SPECオブジェクト（複数可）にサブグループオリジネータIDを設定します。受信Resvメッセージは、次に、通知要求オブジェクトを搬送する場合：
- 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.
- そこ通知要求オブジェクトを搬送する別の受信Resvメッセージは、少なくともされ、そしてLSRは上流送信される単一のResvメッセージにこれらのRESVメッセージをマージし、LSRは、そのルータへの通知要求オブジェクト内の通知ノードアドレスを設定する必要がある場合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は自身のアドレスを（受信したResvメッセージに対応する発信Pathメッセージにおいて）サブグループ発信者IDを設定しそうであれば、LSRは、そのルータIDに通知要求オブジェクト内の通知ノードアドレスを設定しなければなりません。
- Else the LSR MUST propagate the Notify Request object unchanged, in the Resv message that it sends upstream.
- それ以外のLSRは、それが上流の送信Resvメッセージでは、通知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.
- プロセスの受信メッセージを通知し、その値を変更し、このLSRによって下流送信元のPathメッセージにサブグループフィールドの値と一致するように、転送された通知メッセージ内でFILTER_SPECオブジェクトのサブグループフィールド。
- send a Notify message downstream toward the Notify node address that the LSR received in the Resv message.
- LSRは、Resvメッセージ中で受信された通知ノードアドレスに向かって下流に通知メッセージを送信します。
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のためにこれらのルールの結果はブランチ上で生成上流通知メッセージが上流の通知ノードのアドレスに配信される通知をもたらすことです。通知メッセージの受信側は、通知メッセージがすべての下流egressesに適用されると仮定してはいけませんが、メッセージをegressesれるが適用さを決定するために、メッセージ内の情報を検査しなければなりません。
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メッセージで受信した通知に応じて分岐のLSRで複製されなければなりません。いくつかの下流の枝がNotifyメッセージを要求していないかもしれませんが、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.
トランジットLSRは、対応するPathメッセージで受信された値に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:
トランジットLSRは、対応するPathメッセージで受信された値に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オブジェクトを運び、そしてLSRは上流送信される単一のResvメッセージにこれらのRESVメッセージをマージする別の受信Resvメッセージが少なくとも存在する場合、LSRは、そのルータIDにRESV_CONFIRMオブジェクト内の受信アドレスを設定しなければなりません。
- 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は自身のアドレスを（受信したResvメッセージに対応する発信Pathメッセージにおいて）サブグループ発信者IDを設定した場合、LSRは、そのルータIDにRESV_CONFIRMオブジェクト内の受信アドレスを設定しなければなりません。
- 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オブジェクトの処理サブグループフィールドを、このLSRによって下流送信元のPathメッセージにサブグループフィールドの値と一致するように、転送されたResvConfメッセージに、その値を変更します。
- send a ResvConf message downstream toward the receiver address that the LSR received in the RESV_CONFIRM object in the Resv message.
- LSRは、ResvメッセージにRESV_CONFIRMオブジェクトで受信した受信機アドレスに向けて下流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メッセージがブランチにして、元のRESV_CONFIRMオブジェクト内の受信機アドレスに配信さResvConfメッセージをもたらすことです。 ResvConfメッセージの受信機は、ResvConfメッセージがすべてのダウンストリームegressesに送信されるべきであると仮定してはいけませんが、それはオブジェクトが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.
状態はLSP ID、サブグループオリジネータID、サブ、P2MP Pathメッセージは、<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.
パス/ 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]、パスとRESVメッセージは冪等です。また、[RFC2961]は2種類（トリガーとメッセージをリフレッシュします）にRSVPメッセージを分類し、RSVPメッセージの処理と状態の更新のスケーリングが向上しますが、パスとRESVメッセージの完全な状態アドバタイズメント性を修正しません。パスとRESVメッセージの完全な状態広告性質は、多くの利点を持っていますが、またいくつかの欠点を有しています。増分変更が以前に広告を出し状態になされているときの一つの注目すべき欠点があります。この場合、フル状態と、それを処理するコストを送信するメッセージのオーバーヘッドがあります。この欠点を克服し、インクリメンタル既存の状態を更新することによりに/ 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.
増分既存のP2MP LSPパスの状態を変更するパスまたはPathTearメッセージを可能にすることによって、S2Lサブの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で説明したように、複数のPathメッセージは、P2MP LSPをシグナリングするために使用することができます。 PathメッセージはSENDER_TEMPLATEオブジェクトに異なる<サブグループ創始ID、サブグループID>タプルによって区別されます。増分S2LサブLSP状態加算を行うために、新しいサブグループIDを持つ別Pathメッセージは、入口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を維持するために入力することによって使用されるPathメッセージの数と既存のPathメッセージにS2LサブLSPを追加するときに、完全な状態メッセージによって課される処理の間にトレードオフが存在します。 P2MP LSPを維持するために必要なPathメッセージの数を減らすために、単一のPathメッセージに異なるパスメッセージで以前に広告を出しS2LサブLSPを組み合わせることが可能です。これは、断片化を行うトランジットノードによって行われ、それが後の時点で、それは単一のパスメッセージに生成された複数のPathメッセージを組み合わせることが可能であることができます。一つ以上の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.
新たなPathメッセージは、単一のPathメッセージで結合されているすべてのS2LサブLSPを持つ複数のPathメッセージを組み合わせているノードによって通知されます。このPathメッセージは、新しいサブグループ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.
ResvメッセージがS2LサブLSPをリストし、新しいPathメッセージを組み合わせるノードによって受信さに対応するまで、S2LサブLSPは、新旧両方のPathメッセージでアドバタイズされ続けるべきです。したがって、この時点まで、S2LサブLSPのための状態は古いものと新しいPathメッセージの両方についてパス状態の一部として維持されるべきである（[RFC2205]のセクション3.1.3を参照）。その時点でS2LサブLSPは、セクション7の手順を使用して、古いパス状態から削除されるべきです。
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:
サブGROUP_ID（N）とのPathメッセージは、既存のサブGROUP_ID（I）、又はS2LサブLSPの厳密非重複新しいセットに一部または全部属するS2LサブLSPの組をシグナリングすることができます。同じまたは異なるサブGROUP_IDを運ぶ既存のパスの状態でセッションオブジェクトとSenderトンネルアドレスと一致する新たに受信したPathメッセージ、LSP ID、サブグループオリジネータID>は、サブGROUP_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.
サブGROUP_ID（I）=サブGROUP_ID（n）の場合は1）、次いでS2LサブGROUP_ID（I）の両方にあるサブのLSP及びサブGROUP_ID（n）がリフレッシュされます。新しいS2LサブLSPはサブGROUP_IDサブGROUP_ID（i）であるが、サブGROUP_ID（N）内のサブGROUP_ID（I）のパスから削除されていない（I）パス状態とS2LサブのLSPに追加され状態。
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).
サブGROUP_ID（I）！=サブGROUP_ID（n）の場合は2）、その後、新しいサブGROUP_ID（n）のパスの状態はサブGROUP_ID（n）で合図S2LサブLSPのために作成されます。既存のサブGroup_IDsにおけるS2LサブLSPを（されているか、または新たに受信したPathメッセージサブGROUP_ID（N）に含まれていない）は、（i）パス状態（上記参照）未変性残されます。
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は影響を受けません。入口ノード要求「LSPの整合」の場合、エラーが特定のS2LサブLSPのためのP2MP TE LSPの分岐に報告しても、他のS2LサブLSP同じP2MP TE 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メッセージは、一つ以上の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メッセージがアップストリームサブグループフィールドは、パスのサブグループフィールドに受信された値とのPathErrメッセージで受信した交換しなければならない伝播します上流の隣人からのメッセージ。 PathErrメッセージの受信機は、サブグループのフィールドに基づいて、エラーの発生した発信Pathメッセージと発信インタフェースを識別することができるメモの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メッセージは、一つ以上の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メッセージの受信機は、サブグループのフィールドに基づいて、エラーの発生した発信Resvメッセージ、および発信インターフェイスを識別することができる注ResvErrメッセージで受信。流れ記述子リストは、セクション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メッセージは、Pathメッセージのための進入/ブランチLSRにホップバイホップに送信されています。この進入/ブランチLSRまでの中間ノードは、このメッセージを検査し、それにより何もアクションを取ることはできません。たPathErrメッセージを生成ブランチLSRの動作は入力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フラグが設定されていないということです。入口LSRは、PathメッセージにLSPの整合フラグを設定した場合は、とPath_State_Removedフラグがサポートされている場合、のPathErrを生成するLSRは、P2MPの分岐の失敗を報告する（LSP_REQUIRED_ATTRIBUTEsセクション5.2.4でオブジェクトを参照） 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.
入口LSRの要望に応じて行動しなければならないPath_State_Removedフラグが設定されたLSPセットアップ時のPathErrメッセージを受信ブランチLSR。デフォルトの動作では、分岐がLSRがたPathErrにPath_State_Removedフラグをクリアし、さらに上流に送信することです。これは、LSPの他の枝を引き裂くしません。 LSPの完全性フラグがPathメッセージに設定されている場合は、分岐LSRは、他のすべての下流の枝にPathTearを送らなければなりませんし、Path_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の要望に応じて行動しなければなりません。デフォルトの動作では、ブランチLSRは上流のPathErrを転送し、以降のアクションを実行しませんということです。 LSPの完全性フラグがPathメッセージに設定されている場合は、分岐LSRは、すべての下流のブランチにPathTearを送らなければなりませんし、（[RFC3473]あたり）Path_State_Removedフラグを設定して、上流の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.
全ての場合において、分岐LSRによって転送されたPathErrメッセージはS2LサブLSPを識別し、受信したPathErrメッセージと明示的分岐LSRによって引き裂かれている全ての枝によって報告されたすべての枝の明示的なルートを含まなければなりません。
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オブジェクトを中継します。すべてのPathメッセージは、同時に下流のネイバーに送信することができます。
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メッセージを中継する前に、すべてのブランチに（または対応のPathErrあるいはたResvTearメッセージ）を受信するマッチングADMIN_STATUSオブジェクトと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あたりのデータトラフィックのコピーを送るべきです。このような場合に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トンネルの宛先に到達するためにP2MPのLSPによって使用されるパスを変更することが可能です。これを実現するために使用できる2つの方法があります。最初は、メークビフォアブレーク、[RFC3209]で定義され、そして第二は、上記で定義されたサブグループを使用します。
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サブLSPは、入口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.
任意のノードは、複数のパス・メッセージを組み合わせ、必要に応じて、増分状態更新を用いてS2Lサブ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サブLSPの特定のセットで撮影されたパスを変更するために、経路変更を開始するノードは、新たなサブグループIDと同一のP2MP LSPのための1つ以上の別個のPathメッセージ、それぞれを開始します。これらのPathメッセージの生成、一つ以上のS2LサブLSPを有するそれぞれは、セクション5.2の手順に従います。セクション10.2の場合のように、特定の出口は、Resvメッセージが出力をリストし、新しいPathメッセージを再最適化ノードによって受信さに対応するまで、新旧両方のPathメッセージでアドバタイズされ続けます。その時点で、出口が完了する部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サブLSPの同じセットの古いパスの状態とS2Lサブ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]で定義された高速リルート手順に従わなければなりません。各PathメッセージとP2MP LSPのS2LサブLSPのために[RFC4090]で指定されるようにヘッドエンドとトランジットのLSRは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）によって学習されなければなりません。 SEROsの処理は、[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とネクストホップとの間のリンクを保護するために使用されなければなりません。このようにリンクを使用するすべてのS2LサブLSPは、リンク障害が発生した場合に保護されなければなりません。 P2MPトンネルの特定のインスタンスに属するすべてのこのようなS2LサブLSPをセクション5.2.1に従ってPLRとネクストホップとの間のリンク上の同じ発信ラベルを共有することに留意されたいです。これは、リンク上の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は、これらのPathメッセージを識別するために、送信者のテンプレート特有の方法を使用することを推奨します。したがって、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は、対応するS2LサブLSPを識別するために、LSP-IDを使用しなければなりません。対応S2LサブLSPを識別しながら、MPは、<サブグループオリジネータID、サブグループID>タプルを使用してはいけません。さらにMPをS2LサブLSPを処理するために、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はS2LサブLSPのセットそのトランジット保護ノードを保護するために、1つのまたは複数のP2Pバイパストンネルを使用すべきです。これらP2Pバイパストンネルの各々は、それらが保護されたノードから下流にあるLSRに保護することS2LサブLSPの経路と交差しなければなりません。これは、共通の下流MPを通過するものS2LサブのLSPにそのバイパストンネルを介してバックアップされているS2LサブLSPの組を制約します。このMPは、バイパストンネルの宛先です。バイパストンネルにP2MP LSPのためときPLR転送着信データ、外装ラベルは、バイパストンネルラベルであり、内部ラベルは、P2MP LSPに属するS2LサブLSPのセットにMPによって割り当てられたラベルです。
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つ以上のPathメッセージを送らなければなりません。 PLRは、これらのPathメッセージを識別するために、送信元のテンプレートの特定のメソッドを使用することをお勧めします。したがって、PLRは、ローカルPLRアドレスに送信者テンプレート内の送信元アドレスを設定します。 MPは、対応するS2LサブLSPを識別するために、LSP-IDを使用しなければなりません。サブグループオリジネータIDがバイパストンネルによってバイパスされるいくつかのLSRによって変更される可能性があるため、対応するS2LサブLSPを識別しながら、MPは、<サブグループオリジネータID、サブグループID>タプルを使用してはいけません。さらにMPをS2LサブLSPを処理するために、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サブLSPのセットをバックアップするために必要とされ得るように、そのノードの保護は、データプレーンにおいて可能な分岐であることがPLRを必要とする場合があります。 PLRができる分岐されていない場合は、ここで説明したノード保護機構は、保護されたノードを通過する全てのS2LサブLSPをも保護ノードから下流にある単一のMPを通過するだけの場合にも適用可能です。 [RFC4090]で指定されるようにPLRは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]で説明されるように一対一バックアップ、リンク及び次ホップ障害に対する特定のS2LサブLSPを保護するために使用することができます。保護がPLRとネクストホップの間に1つまたは複数のS2LサブLSPのために使用することができます。 PLRとネクストホップ間P2MPトンネルの同じインスタンスに対応する全てのS2Lサブ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サブLSPはPLRで異なる次のホップを横断することができます。保護がトリガされると、このように、発信ラベルとP2MP LSPのための次のホップのセットは、PLRで、変更することができます。 PLR及びPLRの次のホップの間の単一のネクストホップ及びラベルを使用しているP2MP LSPを考えます。保護がトリガされると、これはもはやそうでないかもしれません。これは、データプレーンで可能ブランチするPLRが必要な場合があります。 PLRが可能な分岐されていない場合は、ここで説明した一対一のバックアップメカニズムは、すべてのバックアップS2LサブLSPをそれらの場合にのみ適用PLRの下流同じ次のホップを通過しています。 PLRができる分岐されていないと、すべてのバックアップS2Lサブ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を識別するために使用することが推奨されます。従って、迂回オブジェクトは、バックアップPathメッセージに挿入します。バックアップS2LサブLSPは、LSP-IDで指定されたものとは異なるP2MPトンネルインスタンスに属するものとして扱わなければなりません。それらが同じLSP-IDと同一の迂回オブジェクトを持っている場合、さらに複数のバックアップS2LサブLSPは同じP2MPトンネルインスタンスの一部として扱われなければなりません。セクション4で指定されるように、異なるP2MPトンネルインスタンス間S2LサブのLSPは、異なるラベルを使用することに留意されたいです。
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.
Pathメッセージで唯一S2LサブLSPがある場合、迂回オブジェクトは、そのサブLSPに適用されます。 Pathメッセージ内に複数の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は、受信したPathメッセージによって分岐LSRになることを要求された場合、それは「ブランチにできません」エラーコード「ルーティングエラー」とエラー値を運ぶのPathErrメッセージで応じなければなりません。
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の確立のためのPathメッセージは、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セグメントは、その下流にある最初のP2MP可能なホップにレガシーLSRの上流にある最後P2MP可能なホップからシグナリングされます。これは、中間レガシーのLSRは、トランジットのLSRであることを前提としています。彼らはP2MPの分岐点として機能することはできません。このLSPセグメントに沿った通過のLSRは、P2MP LSPに関連付けられた制御プレーンメッセージを処理しません。さらに、これらのトランジットのLSRはまた、彼らは唯一のP2P LSPセグメントに属するデータを処理する必要があるとして、P2MPデータプレーン機能を持っている必要はありません。したがって、これらのトランジットのLSRは、P2MP MPLSをサポートする必要はありません。このP2P LSPセグメントは、着信P2MP LSPに縫合されます。 P2P LSPセグメントが確立された後、P2MP Pathメッセージは、有向パスメッセージとして次P2MP可能なLSRに送られます。次P2MP対応LSRは、発信P2MP LSPにP2P 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サブLSPは、外側のP2P LSPの中にネストされてもよいです。したがって、ラベルスタッキングは、複数のP2MPのLSPのための同一のLSPセグメントの使用を可能にするために使用することができます。ステッチとネスティング考慮事項および手順[LSPステッチ]にさらに記載されており、[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セグメントを設定するには、オペレータのためかもしれないオーバーヘッド。動的にこれを実行することが望ましい場合があります。入口は、P2MP対応のLSR [TE-NODE-CAP]を決定するために、IGP拡張機能を使用することができます。それは彼らがレガシー非P2MP対応のLSRを避けるようにS2LサブLSPパスを計算するために、この情報を使用することができます。経路に沿ったレガシーのLSRがある場合S2LサブLSPパスの明示的経路オブジェクトは、ルーズホップを含んでもよいです。対応する明示的なルートは次P2MP可能なLSRのアドレスに緩いオブジェクト続いレガシーLSRに隣接しているP2MP対応LSRまでのオブジェクトのリストを含みます。 P2MP対応のLSRは、そのトラフィックエンジニアリングデータベース（TED）を使用して、ゆるいホップを展開します。これを行う際には、緩いホップ拡張がレガシーLSRを通じてトンネルにP2P LSPが必要であると判断します。そのようなP2P LSPが存在する場合は、そのP2P LSPを使用しています。そうでなければ、それはP2P LSPを確立します。 P2MP Pathメッセージは、非隣接のシグナリングを使用して次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]など）高速検出メカニズムを採用する必要があります。これは、保護されたノードが向けPathメッセージテールであるとき、高速再ルーティングノード保護を使用するように指示Pathメッセージをヘッドエンドのために必要となる場合があります。
Note that legacy LSRs along a P2P LSP segment cannot perform node protection of the tail of the P2P LSP segment.
P2P LSPセグメントに沿ったレガシーのLSRが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
P2MP LSPを設定しながら、前のセクションで説明したようにP2MP可能な中継のLSRに沿って制御プレーン処理を低減するために、LSPの階層[RFC4206]を活用することが可能です。これは、LSPの階層が使用可能な環境に適用されます。 P2MPによって使用されているP2P LSPセグメントに沿った走行のLSR、
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.
LSPは、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がP1にP2P LSPを設定することができ、LSPセグメントとしてそれを使用します。 PE3とPE4のためのPathメッセージは現在、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.
このセクションでは、検出と再合流し、クロスオーバーに対処するための手順を詳述します。用語「再マージ」は遠くツリーダウン別のノードでP2MP LSPと交差P2MP LSPの分岐、再合流分岐を作成し入力またはトランジットノードの場合を指します。これは、経路計算、手動設定の誤り、または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オブジェクトが存在しない場合、Pathメッセージを受信した上インターフェースによって、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は、データの異なる着信インターフェイスを識別するためのPathメッセージを受信すると、ノードが動的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.
メイク・ビフォア・ブレークは、メーク・ビフォア・ブレークに関連付けられた着信インタフェースがP2MP LSPが元のP2MP LSPに関連したものと異なってもよいことに、さらに別の似ているが異なる場合を示します。彼らはSENDER_TEMPLATEオブジェクトの異なるLSP IDフィールド値を有することになるので、しかし、2つのP2MP LSPは異なる（しかし関連）の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.
ノードは、Pathメッセージを受信すると、それはP2MP LSPの状態を一致しているかどうかをチェックしなければなりません。一致状態がそれぞれのSESSIONとSENDER_TEMPLATEオブジェクトがローカルP2MP LSPパスの状態を維持して受信したPathメッセージにSESSIONとSENDER_TEMPLATEオブジェクトを比較することにより同定されます。 SENDER_TEMPLATEオブジェクト内P2MP ID、トンネルID、およびセッション・オブジェクトと送信元アドレスに拡張トンネルIDとLSP IDは、比較のために使用されます。ノードは、状態に一致しており、受信したPathメッセージの着信インターフェイスが一致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オブジェクトの二組の間に共通部分が存在しない場合、再度マージまたはクロスオーバーのいずれかが発生しました。 （新しい着信インターフェイスに続いて受信されるマッチングP2MP LSPパス状態に関連S2L_SUB_LSPsのセットの非交差メンバーに対して、動的LSPの再ルーティングの場合、Pathメッセージをことに注意してください。）
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.
再マージケースを識別するために、受信したPathメッセージを処理するノードがマッチングP2MP路状態に関連付けられている発信インターフェイスを識別しなければなりません。マッチングP2MP LSPパスの状態に関連付けられた発信インターフェースのセットと受信されたPathメッセージにおける発信インターフェイスのセットとの間の任意の交点がある場合、再マージが発生しました。
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つの着信インタフェースが再マージノードでドロップされているが。第二に、再マージノードがシグナリングを介して再合流分岐（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".
持続する再マージケースを許可するように構成された場合、再マージノードは、受信したPathメッセージとマッチングP2MP LSPパス状態に含まれるオブジェクト間の整合性を検証する必要があります。矛盾は、受信したPathメッセージの前のホップに送信された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パス状態の着信Pathメッセージの制御状態。具体的には、上流側から受信したメッセージの処理に関する手順は、上流の観点から変更してはいけません。これは、タイムアウトをリフレッシュし、状態に関連する処理が含まれています。標準的な上流の関連する手順に加えて、ノードは、各オブジェクトは、上流適切下流送信Pathメッセージのセット内に表されてから受信したことを確認しなければなりません。例えば、<S2LサブLSP記述子リスト>受信した発信Pathメッセージのセットに含まれなければなりません。存在する任意のNOTIFY_REQUESTオブジェクトがある場合、セクション8で定義された手順は、すべてのパスとRESVメッセージのために従わなければなりません。特別な処理ものResv処理のために必要です。具体的には、下流側から受信したResvメッセージは、受信したPathメッセージの前のホップに送信される送信Resvメッセージにマッピングされなければなりません。実際には、これは着信Pathメッセージと一致するサブセットに完全<S2LサブLSP記述子リスト>分解に変換し、各受信Pathメッセージの発信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.
再マージケースが持続することを可能にするように構成された場合、再マージノードは、複数の入力インターフェイスで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.
シグナリングを介して再合流分岐を補正する場合、再マージノードは、受信したPathメッセージに対応したPathErrメッセージを送らなければなりません。たPathErrメッセージがマッチングP2MP LSPパスの状態に関連付けられたサブLSPのセットから、通常のPathErrメッセージに含まれるオブジェクトの全て、ならびに1つまたは複数のS2L_SUB_LSPオブジェクトを含まなければなりません。 3つのS2L_SUB_LSPオブジェクトの最小値を推奨します。これは、P2MP LSPの有効部分に関連付けられた送信パスの状態を識別するために再マージを引き起こしたノードを可能にするであろう。受信したPathメッセージにS2L_SUB_LSPオブジェクトのセットも含まなければなりません。たPathErrメッセージは、エラーコード「ルーティング問題」と「P2MP再マージ検出」のエラー値を含まなければなりません。ノードはPath_State_Removedフラグ[RFC3473]を設定してもよいです。常にそうであるように、のPathErrメッセージが受信されたPathメッセージの前のホップに送信されます。
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パスの状態と、受信したPathErrメッセージにおける他の分岐S2L_SUB_LSPオブジェクトのセットに関連付けられS2L_SUB_LSPオブジェクトの集合との間の交差点が存在するか否かをチェックすることによって行われます。ある場合、ノードは再マージケースを作成しました。他の分岐S2L_SUB_LSPオブジェクトは、それらS2L_SUB_LSPオブジェクトがマッチングP2MP LSPパス状態から採取したPathErrメッセージに、再マージケースを検出するノードが含まれます。彼らは、受信したPathErrメッセージに関連付けられたPathメッセージに含まれないので、このようなS2L_SUB_LSPオブジェクトが識別可能です。そのような関連付けが識別される方法の詳細は、セクション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.
ノードS2L_SUB_LSPオブジェクトを移動させることにより、再マージケースを削除する必要があり、マッチングP2MP LSPパスの状態に関連付けられた発信インターフェースに受信たPathErrメッセージに関連付けられたPathメッセージに含まれます。移動S2L_SUB_LSPオブジェクトのトリガPathメッセージはその発信インタフェースを介して送信されます。受信したPathErrメッセージがPath_State_Removedフラグが設定されていなかった場合、ノードは、再マージブランチに関連付けられた発信インターフェースを介し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の制約に違反する場合は、関連するegressesと任意の識別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メッセージに削除された場合、このプロセスが失敗する場合のみです。この場合、全体のプロセスは、問題のPathメッセージの次（リフレッシュまたはトリガー）伝送に修正されるであろう。
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セッション・オブジェクトが使用されます。このオブジェクトは、既存のSESSION 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.
SESSIONオブジェクト、SENDER_TEMPLATEオブジェクトとS2L_SUB_LSPオブジェクトの組み合わせは、各S2LサブLSPを識別する。これは今度は複数のLSPを含むことができるP2Pトンネルを識別するためのセッションオブジェクトを使用して、既存のP2P RSVP-TEの概念に従う、それぞれが固有のSENDER_TEMPLATEオブジェクトによって区別します。
Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13
クラス= SESSION、P2MP_LSP_TUNNEL_IPv4 Cタイプ= 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トンネルの寿命にわたって一定のままでSESSIONオブジェクトで使用P2MP ID A 32ビットの識別子。これは、入口LSRの範囲内で一意であるP2MP識別子を符号化します。
Tunnel ID A 16-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel.
P2MPトンネルの寿命にわたって一定のままでセッション・オブジェクトで使用されるトンネルID 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.
P2MPトンネルの寿命にわたって一定のままでセッション・オブジェクトに使用する拡張トンネルID A 32ビットの識別子。 P2MPトンネルのグローバル一意識別子を持っているしたいイングレスの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 LSPのIPv4セッションオブジェクトと同じです。
Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14
クラス= SESSION、P2MP_LSP_TUNNEL_IPv6 Cタイプ= 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オブジェクトは入力LSRの送信元アドレスが含まれています。 LSP IDは、送信者が自分自身でリソースを共有できるようにするために変更することができます。したがって、P2MPトンネルの複数のインスタンスは、異なるLSP IDをそれぞれ作成することができます。インスタンスは、相互にリソースを共有することができます。特定のインスタンスに対応するS2Lサブ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の状態を知らせるために使用される異なるPathメッセージを区別する必要があります。 SENDER_TEMPLATEオブジェクトは、以下に示すように、この情報を運ぶために修正されます。
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12
クラス= SENDER_TEMPLATE、P2MP_LSP_TUNNEL_IPv4 Cタイプ= 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はPathメッセージを発信するLSRのTEルータIDに設定されています。これは、入口LSRまたは再発信する独自のサブグループ創始者IDとパスメッセージはLSRのいずれかです。
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のために状態を知らせる複数のPathメッセージを区別するために使用されるPathメッセージの識別子。これは、このPathメッセージにより標的一つ以上の出口ノードのグループを識別するように見ることができます。
LSP ID See [RFC3209].
LSP IDは、[RFC3209]を参照してください。
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13
クラス= SENDER_TEMPLATE、P2MP_LSP_TUNNEL_IPv6 Cタイプ= 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はPathメッセージを発信するLSRのIPv6のTEルータIDに設定されています。これは、入口LSRまたは再発信する独自のサブグループ創始者IDとパスメッセージはLSRのいずれかです。
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オブジェクトは、特定のS2L P2MP LSPに属するサブLSPを識別する。
S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = 1
S2L_SUB_LSPクラス= 50、S2L_SUB_LSP_IPv4 Cタイプ= 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.
S2LサブLSP先のIPv4のサブLSP宛先アドレスIPv4アドレス。
S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = 2
S2L_SUB_LSPクラス= 50、S2L_SUB_LSP_IPv6 Cタイプ= 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.
これは、宛先アドレスが16バイトのIPv6アドレスである差分と、S2LのIPv4サブLSPオブジェクトと同じです。
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
クラス= FILTER_SPEC、P2MP LSP_IPv4 Cタイプ= 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
クラス= FILTER_SPEC、P2MP LSP_IPv6 Cタイプ= 13
The format of the P2MP LSP_IPv6 FILTER_SPEC object is identical to the P2MP LSP_IPv6 SENDER_TEMPLATE object.
P2MP LSP_IPv6 FILTER_SPECオブジェクトのフォーマットは、P2MP LSP_IPv6 SENDER_TEMPLATEオブジェクトと同一です。
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は、サブオブジェクトがEROのために定義されたものと同一である新規C型= 2を使用します。
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.
P2MP SECONDARY_RECORD_ROUTEオブジェクト（SRRO）はEROと同じように定義されます。 P2MP SRROのクラスは、[RFC4873]で定義さSRROと同じです。 P2MP SRROは、サブオブジェクトはRROのために定義されたものと同一である新規C型= 2を使用します。
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 SECONDARY_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-1型S2L_SUB_LSP_IPv4 C-2型S2L_SUB_LSP_IPv6 C型
IANA has assigned the following C-Type values:
IANAは、次のC-Type値を割り当てています：
Class Name = SESSION
クラス名= SESSION
C-Type 13 P2MP_LSP_TUNNEL_IPv4 C-Type 14 P2MP_LSP_TUNNEL_IPv6 C-Type
C型13 P2MP_LSP_TUNNEL_IPv4 C型14 P2MP_LSP_TUNNEL_IPv6 C型
Class Name = SENDER_TEMPLATE
クラス名= SENDER_TEMPLATE
C-Type 12 P2MP_LSP_TUNNEL_IPv4 C-Type 13 P2MP_LSP_TUNNEL_IPv6 C-Type
C型12 P2MP_LSP_TUNNEL_IPv4 C型13 P2MP_LSP_TUNNEL_IPv6 C型
Class Name = FILTER_SPEC
クラス名= FILTER_SPEC
C-Type 12 P2MP LSP_IPv4 C-Type 13 P2MP LSP_IPv6 C-Type
C型12 P2MP LSP_IPv4 C型13 P2MP LSP_IPv6 C型
Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])
クラス名= SECONDARY_EXPLICIT_ROUTE（[RFC4873]で定義されます）
C-Type 2 P2MP SECONDARY_EXPLICIT_ROUTE C-Type
C-2型P2MP SECONDARY_EXPLICIT_ROUTE C型
Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])
クラス名= SECONDARY_RECORD_ROUTE（[RFC4873]で定義されます）
C-Type 2 P2MP_SECONDARY_RECORD_ROUTE C-Type
C-2型P2MP_SECONDARY_RECORD_ROUTE C-タイプ
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.
「支店にできません」のエラー値は、P2MPの分岐が報告LSRによって形成することができないことを示しています。 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再マージ」は、ノードが再マージを検出したことを示しています。 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再マージパラメータ不一致」はIANAこのエラー値に値26が割り当てられたセクション18に記載されています。
The Error Value "ERO Resulted in Re-Merge" is described in section 18. IANA has assigned value 27 to this Error Value.
エラー値「ERO再マージをもたらした」とは、IANAは、このエラー値に値27が割り当てられたセクション18に記載されています。
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は、TLVが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シグナリングのためのセキュリティ・メカニズムを指定します。これらの機構は、特にセクション16および図17に、この文書で指定された非ホップバイホップP2MP RSVP-TEシグナリングに適用されます。
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内のアプリケーションの仕様は、あるベンダーから入口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.
彼らの提案やコメントのためのヤコフ・レックター、デア・ファガン、Arthi Ayyanger、およびNischal Shethに感謝します。彼らのコメントにもディノFarninacciとベンジャミン・ニーヴンに感謝します。
[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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[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]ファレル、A.編、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、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]バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、 "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]安川、S.、エド。、2006 4月には、RFC 4461、「ポイントツーマルチポイントトラフィック・エンジニアMPLSラベルのためのシグナリング要件は、スイッチパス（LSP）」。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, March 2007.
[BFD]カッツ、D.とD.ウォード、 "双方向フォワーディング検出"、進歩、2007年3月に作業。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD for MPLS LSPs", Work in Progress, March 2007.
[BFD-MPLS]アガルワル、R.、Kompella、K.、ナドー、T.、およびG.ツバメ、 "MPLS LSPのための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.ファレル、進歩、2007年3月に仕事を "ラベルは、一般マルチプロトコルラベルは、トラフィックエンジニアリング（GMPLS TE）を切り替えるとステッチスイッチパス"。
[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。、エド。、ル・ルー、JL。、エド。、 "トラフィックエンジニアリングノード能力の発見のためのIGPルーティングプロトコルの拡張機能"、進歩、2007年4月に作業。
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
"出力制御のためのGMPLSシグナリング手順" [RFC4003]バーガー、L.、RFC 4003、2005年2月。
Appendix A. Example of P2MP LSP Setup
P2MP LSPセットアップの付録A.例
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.
図2。
The mechanism is explained using Figure 2. PE1 is the ingress LSR. PE2, PE3, and PE4 are egress LSRs.
機構は、PE1は、入口LSRである図2を用いて説明します。 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はPE2に到達するためにP2P経路を計算します。
c) PE1 establishes the S2L sub-LSP to PE2 along <PE1, P2, PE2>.
C）PE1は<PE1、P2、PE2>に沿ってPE2にS2LサブLSPを確立します。
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セッションに属している可能PE2にサブLSPと同じリンクを共有するために計算されます。
e) PE1 establishes the S2L sub-LSP to PE3 along <PE1, P3, P1, PE3>.
E）PE1は<PE1、P3、P1、PE3>に沿ってPE3へS2LサブLSPを確立します。
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セッションに属している可能PE2とPE3にサブのLSPと同じリンクを共有するために計算されます。
g) PE1 signals the Path message for PE4 sub-LSP along <PE1, P3, P1, PE4>.
G）PE1は<PE1、P3、P1、PE4>沿っPE4サブLSPのためのPathメッセージを知らせます。
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メッセージを受け取っていました。これは、PE3サブLSPのためのラベルL1を割り当てられていました。これは、同じラベルを使用し、P3にRESVメッセージを送信します。それは、フロー記述子リスト内の複数のフロー記述子を持つ唯一のResvメッセージを送信することがあります。 PE4用とPE3のための他の：これが事実である、とFFスタイルが使用されている場合は、FFフロー記述子は2つのエントリでS2LサブLSP記述子リストが含まれます。 SEのスタイルについては、SE・フィルタ・スペックは、このS2LサブLSP記述子リストが含まれます。 P1は、（ - > {L3、L4} L1）のラベルマッピングを作成します。 P3は、既存のラベルL5を使用し、ラベルL5と、PE1にResvメッセージを送信します。これは、{ - > L1 L5}のラベルマッピングを再利用します。
Appendix B. Contributors
付録B.協力者
John Drake Boeing EMail: john.E.Drake2@boeing.com
ジョン・ドレイクボーイングEメール：john.E.Drake2@boeing.com
Alan Kullberg Motorola Computer Group 120 Turnpike Road 1st Floor Southborough, MA 01772 EMail: alan.kullberg@motorola.com
アランKullbergモトローラ・コンピュータ・グループ120ターンパイク道路1階サウスボロ、MA 01772 Eメール：alan.kullberg@motorola.com
Lou Berger LabN Consulting, L.L.C. EMail: lberger@labn.net
ルー・バーガーLabnコンサルティング、L.L.C.メール：lberger@labn.net
Liming Wei Redback Networks 350 Holger Way San Jose, CA 95134 EMail: lwei@redback.com
黎明魏レッドバック・ネットワーク350ホルガー・ウェイサンノゼ、CA 95134 Eメール：lwei@redback.com
George Apostolopoulos Redback Networks 350 Holger Way San Jose, CA 95134 EMail: georgeap@redback.com
ジョージApostolopoulosレッドバック・ネットワーク350ホルガー・ウェイサンノゼ、CA 95134 Eメール：georgeap@redback.com
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: kireeti@juniper.net
Kireeti Kompellaジュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089 Eメール：kireeti@juniper.net
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA EMail: swallow@cisco.com
ジョージツバメシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA - 01719 USA電子メール：swallow@cisco.com
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シスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA - 01719 USAメール：jpv@cisco.comディーン・チェンシスコシステムズ株式会社170 Wタスマン博士サンノゼ、CA 95134電話408 527 0677 Eメール：dcheng @シスコ。コム
Markus Jork Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 Phone: +1 978 964 2142 EMail: mjork@avici.com
マルクスJorkのAviciシステム101ビレリカアベニューN.ビレリカ、MA 01862電話：+1 978 964 2142 Eメール：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
ひさし こじま んっｔ こｒぽらちおん ９ー１１、 みどりーちょ ３ーちょめ むさしのーし、 ときょ １８０ー８５８５ じゃぱん Ｐほね： ＋８１ ４２２ ５９ ６０７０ えまいｌ： こじま。ひさし＠ぁｂ。んっｔ。こ。ｊｐ
Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose, CA 95134 Phone: +1 408 383 7223 EMail: Andy.Malis@tellabs.com
アンドリューG. Malisテラブス2730オーチャードパークウェイサンノゼ、CA 95134電話：+1 408 383 7223 Eメール：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
まさのり うが んっｔ こｒぽらちおん ９ー１１、 みどりーちょ ３ーちょめ むさしのーし、 ときょ １８０ー８５８５ じゃぱん Ｐほね： ＋８１ ４２２ ５９ ４８０４ えまいｌ： うが。まさのり＠ぁｂ。んっｔ。こ。ｊｐ
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
イゴールBryskin Movazネットワークス株式会社7926ジョーンズ支店ドライブスイート615マクリーンVA、22102 ibryskin@movaz.comエードリアンファレル老犬のコンサルティング電話：+44 0 1978 860944 Eメール：adrian@olddog.co.uk
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: jeanlouis.leroux@francetelecom.com
ジャン=ルイ・ルーフランステレコム2、大通りピエールMarzin 22307ラニオンCedexのフランス電子メール：jeanlouis.leroux@francetelecom.com
Editors' Addresses
エディタのアドレス
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: rahul@juniper.net
ラウール・アガーウォールジュニパーネットワークスの1194北マチルダアベニュー。サニーベール、CA 94089 Eメール：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
せいしょ やすかわ んっｔ こｒぽらちおん ９ー１１、 みどりーちょ ３ーちょめ むさしのーし、 ときょ １８０ー８５８５ じゃぱん Ｐほね： ＋８１ ４２２ ５９ ４７６９ えまいｌ： やすかわ。せいしょ＠ぁｂ。んっｔ。こ。ｊｐ
Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: Dimitri.Papadimitriou@alcatel-lucent.be
ディミトリPapadimitriouアルカテルフランシスVellesplein 1 B-2018アントワープ、Velgiomボイス：X2 + 3 240から8491 Eメール：Δημήτρη.Παπαδημητρίου@αλκατελ-λυκεντ.βε
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。