RFC4875 日本語訳
4875 Extensions to Resource Reservation Protocol - Traffic Engineering(RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs). R.Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.. May 2007. (Format: TXT=125394 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループR.Aggarwal、エドをネットワークでつないでください。コメントのために以下を要求してください。 4875年の杜松はカテゴリをネットワークでつなぎます: エド標準化過程D.Papadimitriou、エドアルカテルS.Yasukawa、NTT2007年5月
Extensions to
Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
for Point-to-Multipoint TE Label Switched Paths (LSPs)
資源予約プロトコルへの拡大--ポイントツーマルチポイントのTeのラベルの切り換えられた経路への交通工学(RSVP-Te)(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはResource予約プロトコルに拡大について説明します--MultiプロトコルLabel Switching(MPLS)とGeneralized MPLS(GMPLS)ネットワークでTraffic Engineered(TE)ポイントツーマルチポイント(P2MP)ラベルSwitched Paths(LSPs)を上がっているセットのための交通Engineering(RSVP-TE)。 Service Providerコアでマルチキャストルーティング・プロトコルを必要としないで、解決策は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 LSPsの様々な利用があることができます。 このドキュメントの範囲の外にそのようなアプリケーションがどうP2MP TE LSPを使用するかに関する仕様があります。
Aggarwal, et al. Standards Track [Page 1] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[1ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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
1. 序論…4 2. このドキュメントで中古のコンベンション…4 3. 用語…4 4. メカニズム…5 4.1. P2MPはトンネルを堀ります…5 4.2. P2MP LSP…5 4.3. サブグループ…5 4.4. S2LサブLSPs…6 4.4.1. S2LサブLSPの表現…6 4.4.2. S2LサブLSPsと経路メッセージ…7 4.5. 明白なルート設定…7 5. 経路メッセージ…9 5.1. 経路メッセージ・フォーマット…9 5.2. 経路メッセージ処理…11 5.2.1. 複数の経路メッセージ…11 5.2.2. 1つの経路メッセージのサブLSPsの複数のS2L…12 5.2.3. 経路州の情報のトランジット断片化…14 5.2.4. 支店運命共有のコントロール…15 5.3. 植皮…15 6. Resvメッセージ…16 6.1. Resvメッセージ・フォーマット…16 6.2. Resvメッセージ処理…17 6.2.1. Resvメッセージ阻止…18 6.3. 録音を発送してください…19 6.3.1. RRO処理…19 6.4. 予約様式…19 7. PathTearメッセージ…20 7.1. PathTearメッセージ・フォーマット…20 7.2. 剪定します。20 7.2.1. 暗黙のS2LサブLSP分解…20 7.2.2. 明白なS2LサブLSP分解…21 8. 通知してください。そうすれば、ResvConfは通信します…21 8.1. メッセージに通知してください…21 8.2. ResvConfメッセージ…23 9. 減少をリフレッシュしてください…24 10. 管理を述べてください…24 10.1. 増加の州のアップデート…25 10.2. 複数の経路メッセージを結合します…25 11. エラー処理…26 11.1. PathErrメッセージ…27 11.2. ResvErrメッセージ…27 11.3. 支店失敗取り扱い…28 12. アドミン状態変化…29 13. LANを複数の川下のノードで配分をラベルしてください…29
Aggarwal, et al. Standards Track [Page 2] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[2ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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
14. P2MP LSPとサブLSP再最適化…29 14.1. 以前、開閉してください…29 14.2. サブグループベースの再最適化…29 15. 速くコースを変更してください…30 15.1. 施設バックアップ…31 15.1.1. 保護をリンクしてください…31 15.1.2. ノード保護…31 15.2. 1〜1つのバックアップ…32 16. できるP2MPでないLSRsのために、支持します。33 17. LSP階層構造とのコントロール飛行機処理の減少…34 18. P2MP LSP再合併とクロスオーバー…35 18.1. 手順…36 18.1.1. 手順を再合併してください…36 19. 新しくてアップデートされたメッセージ物…39 19.1. セッション物…39 19.1.1. P2MP LSPはIPv4セッション物にトンネルを堀ります…39 19.1.2. P2MP LSPはIPv6セッション物にトンネルを堀ります…40 19.2. 送付者_テンプレート物…40 19.2.1. P2MP LSPはIPv4送付者_テンプレート物にトンネルを堀ります…41 19.2.2. P2MP LSPはIPv6送付者_テンプレート物にトンネルを堀ります…42 19.3. S2L_潜水艦_LSPは反対します…43 19.3.1. S2L_潜水艦_LSP IPv4は反対します…43 19.3.2. S2L_潜水艦_LSP IPv6は反対します…43 19.4. _仕様物をフィルターにかけてください…43 19.4.1. P2MP LSP_IPv4は_仕様物をフィルターにかけます…43 19.4.2. P2MP LSP_IPv6は_仕様物をフィルターにかけます…44 19.5. P2MPの二次_明白な_ルート物(SERO)…44 19.6. P2MPの二次_記録_は物(SRRO)を発送します…44 20. IANA問題…44 20.1. 新しいクラス番号…44 20.2. 新しいクラスはタイプされます…44 20.3. 新しい誤り値…45 20.4. LSP属性旗…46 21. セキュリティ問題…46 22. 承認…47 23. 参照…47 23.1. 標準の参照…47 23.2. 有益な参照…P2MP LSPセットアップに関する48付録A.の例…49 付録B.貢献者…50
Aggarwal, et al. Standards Track [Page 3] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[3ページ]RFC4875の拡張子をRSVP-Teに追跡します。
1. Introduction
1. 序論
[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]は、Multi-プロトコルLabel Switching(MPLS)ネットワークでポイントツーポイント(P2P)交通Engineered(TE)ラベルSwitched Paths(LSPs)をセットアップするためにメカニズムを定義します。 [RFC3473]は、Generalized MPLS(GMPLS)ネットワークでP2P TE LSPsをセットアップするために[RFC3209]と拡大を定義します。 しかしながら、これらの仕様はビルポイントツーマルチポイント(P2MP)TE LSPsにメカニズムを供給しません。
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 LSPsを支持するために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 LSPsのために引き継ぐResource予約プロトコル(RSVP)の意味論を当てにします。 P2MP LSPは複数のソースから葉(S2L)へのサブLSPsから成ります。 これらのS2LサブLSPsは、イングレスと出口LSRsの間でセットアップされて、ブランチLSRsによってP2MP TE LSPをもたらすのにRSVP意味論を使用することで適切に結合されます。 1つのPathメッセージが独身のP2MP LSPのためのサブLSPsの1か複数のS2Lを示すかもしれません。 したがって、P2MP LSPに属すS2LサブLSPsを1つのPathメッセージを使用することで合図するか、または複数の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 LSPsの様々な利用があります、そして、時々他のテクニックと組み合わせて異なったアプリケーションを支持するのに本書では説明されたシグナリングのテクニックは使用できます。
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 LSPsを使用するだろうか、そして、P2MP TE LSPsの経路がどのように計算されるかに関する仕様があります。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Terminology
3. 用語
This document uses terminologies defined in [RFC2205], [RFC3031], [RFC3209], [RFC3473], [RFC4090], and [RFC4461].
このドキュメントは[RFC2205]、[RFC3031]、[RFC3209]、[RFC3473]、[RFC4090]、および[RFC4461]で定義された用語を使用します。
Aggarwal, et al. Standards Track [Page 4] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[4ページ]RFC4875の拡張子をRSVP-Teに追跡します。
4. Mechanism
4. メカニズム
This document describes a solution that optimizes data replication by allowing non-ingress nodes in the network to be replication/branch nodes. A branch node is an LSR that replicates the incoming data on to one or more outgoing interfaces. The solution relies on RSVP-TE in the network for setting up a P2MP TE LSP.
このドキュメントはネットワークにおける非イングレスノードが模写/ブランチノードであることを許容することによってデータ模写を最適化する解決策を説明します。 ブランチノードは1つ以上の外向的なインタフェースに受信データを模写するLSRです。 解決策は、P2MP TE LSPをセットアップするためにネットワークでRSVP-TEを当てにします。
The P2MP TE LSP is set up by associating multiple S2L sub-LSPs and relying on data replication at branch nodes. This is described further in the following sub-sections by describing P2MP tunnels and how they relate to S2L sub-LSPs.
P2MP TE LSPは、複数のS2LサブLSPsを関連づけて、ブランチノードでデータ模写に依存することによって、セットアップされます。 これは以下の小区分でP2MPトンネルとそれらがどうS2LサブLSPsに関連するかを説明することによって、より詳しく説明されます。
4.1. P2MP Tunnels
4.1. P2MP Tunnels
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 Tunnelは1P2MP LSPsを包括します。 P2MP TE TunnelはP2MP SESSION物によって特定されます。 この物はP2MP Sessionに関する識別子を含んでいます。(P2MP SessionはP2MP Identifier(P2MP ID)、トンネルIdentifier(Tunnel ID)、および拡張トンネル識別子(拡張Tunnel ID)を含んでいます)。 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、Tunnel ID、Extended Tunnel ID>tupleはP2MP TE Tunnelの目的地のセットのための識別子を提供します。
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 SESSION物の分野はTunnel Endpoint Address野原をP2MP ID分野に取り替えるのを除いて、[RFC3209]で定義されたSESSION物のものと同じです。 P2MP SESSION物はセクション19.1で定義されます。
4.2. P2MP LSP
4.2. P2MP LSP
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 SENDER_TEMPLATE物のP2MP SESSION物の一部と、トンネル送付者アドレスとLSP ID分野であるP2MP ID、Tunnel ID、およびExtended Tunnel IDの組み合わせで特定されます。 新しいP2MP SENDER_TEMPLATE物はセクション19.2で定義されます。
4.3. Sub-Groups
4.3. サブグループ
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がLSPsを制御したので、P2MP LSP状態はRSVPメッセージを使用することで経営されます。 RSVPメッセージの使用は同じですが、P2MP LSP状態は多くの方法でP2P LSP状態と異なっています。 A
Aggarwal, et al. Standards Track [Page 5] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[5ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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 Sub-LSPsを包括します、そして、これの結果、単一のIPパケットに完全な状態を表すのは可能でないかもしれません。 また、P2MP TE LSPsとP2MP TE LSPsから終点を効率的に加えて、取り除くのも可能であるに違いありません。 [RFC4461]とセクション18は、追加設定がまた、P2MP LSPが州の「再マージ」問題を扱わなければならないということであることを見ます。
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状態のこれらの違いはサブグループ識別子(サブGroup ID)とサブグループの創始者(サブGroup Originator ID)のSENDER_TEMPLATEとFILTER_SPEC物への追加で記述されます。 一緒に取って、Sub-グループIDとSub-グループOriginator IDはSub-グループ分野と呼ばれます。
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.
Sub-グループ分野は、P2MP LSPの状態の一部を表すのにSENDER_TEMPLATEとSESSION物の残りと共に使用されます。 P2MP LSPの状態のこの一部がデータ飛行機模写か分岐ではなく、シグナリング状態だけについて言及します。 例えば、それはP2MP LSPのための「ブランチ」シグナリング状態へのノードが、データがP2MP LSPに関連づけたどんなブランチにも可能ではありません。 複数のサブグループの世代と使用のための主用途は確実にする出口と(2)の意味断片化のPathメッセージが単一のIPパケットの中に残っている(1)添加です。
4.4. S2L Sub-LSPs
4.4. S2LサブLSPs
A P2MP LSP is constituted of one or more S2L sub-LSPs.
P2MP LSPは1S2LサブLSPsについて構成されます。
4.4.1. Representation of an S2L Sub-LSP
4.4.1. 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 SESSIONの一部と、P2MP SENDER_TEMPLATE物のトンネル送付者アドレスとLSP ID分野と、S2L_SUB_LSP物の一部であるS2LサブLSP送付先アドレスであるP2MP ID、Tunnel ID、およびExtended Tunnel IDによって特定されます。 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 Object(ERO)かP2MP_SECONDARY_EXPLICIT_ROUTE Object(SERO)が、任意にS2LサブLSPの明白なルートを指定するのに使用されます。 合図される各EROかSEROが特定のS2L_SUB_LSP物に対応しています。 明白なルートコード化の詳細はセクション4.5で指定されます。 SECONDARY_EXPLICIT_ROUTE Objectは[RFC4873]で定義されます、そして、新しいP2MP SECONDARY_EXPLICIT_ROUTE Object C-タイプはセクション19.5で定義されます、そして、合っているP2MP_SECONDARY_RECORD_ROUTE Object C-タイプはセクション19.6で定義されます。
Aggarwal, et al. Standards Track [Page 6] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[6ページ]RFC4875の拡張子をRSVP-Teに追跡します。
4.4.2. S2L Sub-LSPs and Path Messages
4.4.2. S2LサブLSPsと経路メッセージ
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メッセージは1S2LサブLSPsを示すかもしれません。 1つのPathメッセージがすべてのS2LサブLSPsを含むことができるくらいには大きくないかもしれないように複数のPathメッセージのサポートは望ましいです。 そして、また、彼らはP2MP LSPの下位木の別々の操作を許します。 複数のS2LサブLSPsに合図するただ一つのPathメッセージを許容する理由はP2MP LSPをセットアップするのに必要であるコントロールメッセージの数を最適化することです。
4.5. Explicit Routing
4.5. 明白なルート設定
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>>tupleは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サブLSPsを示すと、出口LSRへのサブLSPの最初のS2Lの経路はEROでコード化されます。 最初のS2LサブLSPはPathメッセージにおける最初のS2L_SUB_LSP物に対応するものです。 従うS2L_SUB_LSP物に対応するS2LサブLSPsはその後のS2LサブLSPsとして呼ばれます。
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の形式はEROと同じです([RFC3209]と[RFC3473]で定義されるように)。 それぞれのその後のS2LサブLSPはフォーム<[<P2MP SECONDARY_EXPLICIT_ROUTE>]のtuplesによって表されます、<S2L_SUB_LSP>>。特定のS2LサブLSPのためのSEROはブランチLSRからそのS2LサブLSPの出口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サブLSPsの部分のための経路情報の潜在的反復を避けるために、この情報は他のS2LサブLSPsの明白なルートからSEROsで明白なルート圧縮を使用することで推論されます。
Aggarwal, et al. Standards Track [Page 7] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[7ページ]RFC4875の拡張子をRSVP-Teに追跡します。
A
|
|
B
|
|
C----D----E
| | |
| | |
F G H-------I
| |\ |
| | \ |
J K L M
| | | |
| | | |
N O P Q--R
A| | B| | C----D----E| | | | | | F G H-------I| |\ | | | \ | J K L M| | | | | | | | N O P Q--R
Figure 1. Explicit Route Compression
図1。 明白なルート圧縮
Figure 1 shows a P2MP LSP with LSR A as the ingress LSR and six egress LSRs: (F, N, O, P, Q and R). When all six S2L sub-LSPs are signaled in one Path message, let us assume that the S2L sub-LSP to LSR F is the first S2L sub-LSP, and the rest are subsequent S2L sub- LSPs. The following encoding is one way for the ingress LSR A to encode the S2L sub-LSP explicit routes using compression:
図1はLSR Aと共にイングレスLSRと6出口LSRsとしてP2MP LSPを示しています: (F、N、O、P、Q、およびR。) すべての6S2LサブLSPsが1つのPathメッセージで合図されるとき、LSR FへのサブLSPのS2Lが最初のS2LサブLSPであり、残りがその後のS2LサブLSPsであると仮定しましょう。 イングレスLSR Aが圧縮を使用することでS2LのサブLSPの明白なルートをコード化することにおいて以下のコード化は一方通行です:
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: <S2L_潜水艦_LSP>物-F S2LサブLSP-N、EROはB、E、D、C、Fと等しいです: <S2L_潜水艦_LSP>物-N S2LサブLSP-O、SEROはD、G、J、Nと等しいです: <S2L_潜水艦_LSP>物-O S2LサブLSP-P、SEROはE、H、K、Oと等しいです: <S2L_潜水艦_LSP>物-P S2LサブLSP-Q、SEROはH、L、Pと等しいです: <S2L_潜水艦_LSP>物-Q S2LサブLSP-R、SEROはH、I、M、Qと等しいです: <S2L_潜水艦_LSP>物R、SEROはQ、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の明白なルートが以下の通りコード化されている状態で、Pathメッセージを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: <S2L_潜水艦_LSP>物-F S2LサブLSP-N、EROはD、C、Fと等しいです: <S2L_潜水艦_LSP>物N、SEROはD、G、J、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:
またEがLSR H、および以下へのPathメッセージを送るLSRは圧縮を使用することで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: <S2L_潜水艦_LSP>物-O S2LサブLSP-P、EROはH、K、Oと等しいです: S2L_潜水艦_LSP物-P S2LサブLSP-Q、SEROはH、L、Pと等しいです: <S2L_潜水艦_LSP>物-Q S2LサブLSP-R、SEROはH、I、M、Qと等しいです: <S2L_潜水艦_LSP>物R、SEROはQ、Rと等しいです。
Aggarwal, et al. Standards Track [Page 8] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[8ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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.にPathメッセージを送ります。LSR KへのPathメッセージのためのコード化は以下の通りです:
S2L sub-LSP-O: ERO = {K, O}, <S2L_SUB_LSP> object-O
S2LサブLSP-O: <S2L_潜水艦_LSP>物O、EROはK、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: <S2L_潜水艦_LSP>物P、EROはL、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: <S2L_潜水艦_LSP>物-Q S2LサブLSP-R、EROはI、M、Qと等しいです: <S2L_潜水艦_LSP>物R、SEROはQ、Rと等しいです。
The explicit route encodings in the Path messages sent by LSRs D and Q are left as an exercise for the reader.
メッセージが送ったPathの明白なルートencodingsは読者のための運動としてLSRs DとQによって残されます。
This compression mechanism reduces the Path message size. It also reduces extra processing that can result if explicit routes are encoded from ingress to egress for each S2L sub-LSP. No assumptions are placed on the ordering of the subsequent S2L sub-LSPs and hence on the ordering of the SEROs in the Path message. All LSRs need to process the ERO corresponding to the first S2L sub-LSP. An LSR needs to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR. The branch LSR that is the first hop of an SERO propagates the corresponding S2L sub-LSP downstream.
この圧縮機構はPathメッセージサイズを減少させます。 また、それは明白なルートがそれぞれのS2LサブLSPのためにイングレスから出口までコード化されるなら結果として生じることができる余分な処理を抑えます。 仮定は全くその後のS2LサブLSPsの注文であることと、そして、したがって、Pathメッセージにおける、SEROsの注文であることに置かれません。 すべてのLSRsが、最初のS2LサブLSPに対応するEROを処理する必要があります。 LSRは、対応するSEROにおける最初のホップがそのLSRのローカルアドレスである場合にだけその後のS2LサブLSPのためのS2LサブLSP記述子を処理する必要があります。 SEROの最初のホップであるブランチLSRは川下のサブLSPの対応するS2Lを伝播します。
5. Path Message
5. 経路メッセージ
5.1. Path Message Format
5.1. 経路メッセージ・フォーマット
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メッセージは、1S2LサブLSPsに合図するために高められます。 Pathメッセージに以下に示すようにS2LサブLSP記述子リストを含んでいることによって、これをします。
Aggarwal, et al. Standards Track [Page 9] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[9ページ]RFC4875の拡張子をRSVP-Teに追跡します。
<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>]
<経路メッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>] <セッション><RSVP_ホップ><時間_は>[<の明白な_ルート>]<ラベル_要求>[<保護>]を評価します[<ラベル_は>を…設定しました]。 [<セッション_属性>] [<は_要求>に通知します] [<アドミン_状態>] [<方針_データ>] <送付者記述子>。[<S2LサブLSP記述子リスト>]
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サブLSP記述子リスト>:、:= <S2LサブLSP記述子>。[<S2LサブLSP記述子リスト>]
<S2L sub-LSP descriptor> ::= <S2L_SUB_LSP>
[ <P2MP SECONDARY_EXPLICIT_ROUTE> ]
<S2LサブLSP記述子>:、:= <S2L_潜水艦_LSP>。[<のP2MPの二次_明白な_ルート>]
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 MUSTは、S2L_SUB_LSP物とSECONDARY/EXPLICIT_ROUTE物の組み合わせで表されたそれぞれのS2LサブLSPを処理するのにPathメッセージと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によって指定されます。 したがって、SEROであって1つが存在しているかどうかが最初のS2L_SUB_LSP物のSHOULD NOTを支えていて、それを無視しなければなりません。
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メッセージによって横断された上流のホップを含んでいて、Pathメッセージで合図されたすべてのS2LサブLSPsに適用します。
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.
_データ・チャンネル[RFC3471]の制御チャンネルの1〜1つの協会がないリンクの上にID RSVP_HOP物を使用しなければならないなら。 RSVP_HOP物は[RFC2205]でSHOULDを定義しました。別の方法で使用されます。
Path message processing is described in the next section.
経路メッセージ処理は次のセクションで説明されます。
Aggarwal, et al. Standards Track [Page 10] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[10ページ]RFC4875の拡張子をRSVP-Teに追跡します。
5.2. Path Message Processing
5.2. 経路メッセージ処理
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へのサブLSPのS2Lのセットアップに着手します。 それぞれのS2LサブLSPはP2MP SENDER_TEMPLATE物で一般的なP2MP SESSION物と<Sender Address、LSP-ID>分野を使用する同じP2MP LSPに関連しています。 したがって、他のS2LがP2MP LSPを形成するためにサブLSPsである状態でそれを結合できます。 このS2LがサブLSPである状態でこのS2LサブLSP(すなわち、同じP2MP LSP)SHOULDの同じ例に属す別のS2LサブLSPがリソースを共有します。 P2MP TEトンネルに対応するセッションはP2MP SESSION物に基づいて決定しています。 それぞれのS2LサブLSPは、S2L_SUB_LSP物を使用することで特定されます。 S2LサブLSPsのための明白なルーティングは、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のためのサブLSPsのS2Lに合図するのが可能であり、与えられたPathメッセージは1S2LサブLSPsを含むことができます。 RSVP-TEを支持するLSRは受信できて、過程倍数が1つのPathメッセージのサブLSPsの同じP2MP LSPと複数のS2LへのPathメッセージであったに違いないならP2MP LSPsに合図しました。 これは、そのようなLSR MUSTがセクション19で記載されたすべての物を受けて、処理できるのを含意します。
5.2.1. Multiple Path Messages
5.2.1. 複数の経路メッセージ
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>>tupleのどちらかがS2LサブLSPを指定するのに使用されます。 P2MP LSPに合図するのに複数のPathメッセージを使用できます。 それぞれのPathメッセージは1S2LサブLSPsを示すことができます。 Pathメッセージが1S2Lサブ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.
1S2Lサブ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
LSR MAYがP2MP LSPに合図しながら複数のPathメッセージを使用するイングレス。 これはただ一つのPathメッセージがP2MP LSPに合図できるくらいには大きくないかもしれないからです。 新葉がP2MP LSPに加えられるとき、または、多分、それらは新しいPathメッセージで合図されます。 または、LSR MAYが選ぶイングレスはP2MP木を別々の処理しやすいP2MP木に細かく分けます。 これらの木は、同じ根を共有して、トランクとあるブランチを共有するかもしれません。 P2MP木のこの管理分解の範囲はそれぞれ単葉(S2LサブLSPs)がある単一の木(P2MP Tree)で境界があって複数の木です。 [RFC4461]に従って、P2MP LSP MUSTは木のすべての一部の向こう側に一貫した属性を持っています。 これは、同じシグナリング属性を使用することでP2MP LSPに合図するのに使用されるそれぞれのPathメッセージが合図されるのを含意します。
Aggarwal, et al. Standards Track [Page 11] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[11ページ]RFC4875の拡張子をRSVP-Teに追跡します。
with the exception of the S2L sub-LSP descriptors and Sub-Group identifier.
S2LサブLSP記述子とSub-グループ識別子を除いて。
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 SHOULDに属す異なったPathメッセージからの結果として起こるサブLSPsはそれらがデータの複本が送られるのを防ぐためにホップを共有するラベルとリソースを共有します。
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メッセージのオーバーフローをもたらすかもしれません。 この場合複数のPathメッセージにメッセージを分解できるので、各メッセージは入力メッセージによって運ばれたX2L下位木の部分集合を運びます。
Multiple Path messages generated by an LSR that signal state for the same P2MP LSP are signaled with the same SESSION object and have the same <Source address, LSP-ID> in the SENDER_TEMPLATE object. In order to disambiguate these Path messages, a <Sub-Group Originator ID, Sub- Group ID> tuple is introduced (also referred to as the Sub- Group fields) and encoded in the SENDER_TEMPLATE object. Multiple Path messages generated by an LSR to signal state for the same P2MP LSP have the same Sub-Group Originator ID and have a different sub- Group ID. The Sub-Group Originator ID MUST be set to the TE Router ID of the LSR that originates the Path message. Cases when a transit LSR may change the Sub-Group Originator ID of an incoming Path message are described below. The Sub-Group Originator ID is globally unique. The Sub-Group ID space is specific to the Sub-Group Originator ID.
LSRによって発生したそれが同じSESSION物で示されて、同じ<Sourceアドレスを持っていると同じP2MP LSPのための状態に合図する複数のPathメッセージ、SENDER_TEMPLATEのLSP-ID>は反対します。 これらのPathメッセージのあいまいさを除くために、<Sub-グループOriginator SubグループID(ID)>tupleは導入されて(また、Subグループ分野と呼ばれます)、SENDER_TEMPLATE物でコード化されます。 LSRによって同じP2MP LSPのために状態に合図するために発生した複数のPathメッセージが、同じSub-グループOriginator IDを持っていて、異なったサブGroup IDを持っています。 Pathメッセージを溯源するLSRのTE Router IDにSub-グループOriginator IDを設定しなければなりません。 トランジットLSRが入って来るPathメッセージのSub-グループOriginator IDを変えるとき、ケースは以下で説明されます。 Sub-グループOriginator IDはグローバルにユニークです。 Sub-グループIDスペースはSub-グループOriginator IDに特定です。
5.2.2. Multiple S2L Sub-LSPs in One Path Message
5.2.2. 1つの経路メッセージのサブLSPsの複数のS2L
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記述子リストは1つのPathメッセージのサブLSPsの1S2Lのシグナリングを許容します。 それぞれの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.
EROが存在しているなら、すべてのLSRsが最初のS2LサブLSPに対応するEROを処理しなければなりません。 1であるなら、より多くのSEROsがプレゼント、ERO MUSTです。存在してください。 サブLSP MUSTであることは、伝播されたコネです。最初のS2L、明白なルートに沿った各LSRによるPathメッセージはEROで指定しました、EROが存在しているなら。 ほかに、S2L_SUB_LSP物によって特定された目的地に向かってホップごとのルーティングを使用して、それを伝播しなければなりません。
An LSR MUST process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP as follows:
LSR MUSTは以下のその後の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 MUSTはSEROにおける最初のホップをチェックします:
Aggarwal, et al. Standards Track [Page 12] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[12ページ]RFC4875の拡張子をRSVP-Teに追跡します。
- 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物によって特定されるように出口でないなら、SEROから断固とした次のホップに送られたPathメッセージにS2LサブLSP記述子を含まなければなりません。
- If the first hop of the SERO is not a local address of the LSR,
the S2L sub-LSP descriptor MUST be included in the Path message
sent to the LSR that is the next hop to reach the first hop in
the SERO. This next hop is determined by using the ERO or other
SEROs that encode the path to the SERO's first hop.
- SEROの最初のホップがLSRのローカルアドレスでないなら、SEROにおける最初のホップに達するように次のホップであるLSRに送られたPathメッセージにS2LサブLSP記述子を含まなければなりません。 この次のホップは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 MUSTはS2L_SUB_LSP物を調べます:
- If this LSR is the egress as identified by the S2L_SUB_LSP
object, the S2L sub-LSP descriptor MUST NOT be propagated
downstream.
- このLSRがS2L_SUB_LSP物によって特定されるように出口であるなら、S2LサブLSP記述子を川下に伝播してはいけません。
- If this LSR is not the egress as identified by the S2L_SUB_LSP
object, the LSR MUST make a routing decision to determine the
next hop towards the egress, and MUST include the S2L sub-LSP
descriptor in a Path message sent to the next-hop towards the
egress. In this case, the LSR MAY insert an SERO into the S2L
sub-LSP descriptor.
- このLSRがS2L_SUB_LSP物によって特定される出口、LSR MUSTが次のホップを出口に向かって決定するというルーティング決定をするということでなく、次のホップに送られたPathメッセージでS2LサブLSP記述子を出口に向かって含めなければならないなら。 この場合、LSR MAYは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 MUSTは、川下をそれぞれ跳ぶために関連S2LサブLSP記述子を伝播するだけです。 川下のリンクの上に伝播されるS2LサブLSP記述子リストはそのホップを使用することで発送されるそれらのS2LサブLSPsを入れてあるだけでよいです。 送信するPathメッセージのサブLSPの最初のS2Lになって、この処理は入って来る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.
1SEROsがゆるいホップを含んでいるなら、そのようなゆるいホップの拡大がPathメッセージサイズからはみ出すのに結果として生じるかもしれないことに注意してください。セクション5.2.3は1つ以上のPathメッセージの向こう側にどうS2LサブLSPsのセットのシグナリングを分けることができるかを説明します。
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
RECORD_ROUTE Object(RRO)はPathメッセージによって横断されたホップを含んでいて、Pathメッセージで合図されたすべてのS2LサブLSPsに適用します。 トランジットLSR MUSTは入って来るRROのアドレスを追加して、それを川下に伝播します。 AブランチLSR MUSTはRROをコピーするのによるそれぞれの送信するPathメッセージのための新しいRROを形成します。
Aggarwal, et al. Standards Track [Page 13] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[13ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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.
入って来るPathメッセージとアドレスを追加すること。 それぞれ、そのようなものは形成使用が[RFC3209](そして、[RFC3473]がアップデートされる)の規則であったなら適宜RRO MUSTをアップデートしました。
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メッセージのサブLSPのS2Lを支持できないなら(例えば、それは目的地使用に向かってSEROを発送できません)、影響を与えられたS2LサブLSPのためにPathErrメッセージを送らなければなりません、そして、P2MP LSP SHOULDの残りの正常処理は続きます。 デフォルトの振舞いはLSPの残りに影響を与えられないという(他のすなわちすべてのブランチがセットアップできます)ことです、そして、失敗したブランチはPath_州_Removed旗を設定してはいけないPathErrメッセージで報告されます。 しかしながら、イングレスLSRは、LSP Integrity旗にセットアップ失敗がどんな支店にもあれば、全体のLSPがセットアップするはずがないよう要求するように設定するかもしれません。 これはセクション5.2.4と11で、より詳しく説明されます。
5.2.3. Transit Fragmentation of Path State Information
5.2.3. 経路州の情報のトランジット断片化
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メッセージがIDがトランジットLSRのTE Router IDに設定したSub-グループOriginatorとそれぞれのPathメッセージのための異なったSub-グループIDで合図されます。 したがって、P2MP LSPのためのトランジットLSRによって発生するそれぞれの異なったPathメッセージは異なった<Sub-グループOriginator ID(Sub-グループID>tuple)を運びます。
When multiple Path messages are used by an ingress or transit node, each Path message SHOULD be identical with the exception of the S2L sub-LSP related descriptor (e.g., SERO), message and hop information (e.g., INTEGRITY, MESSAGE_ID, and RSVP_HOP), and the Sub-Group fields of the SENDER_TEMPLATE objects. Except when a make-before-break operation is being performed (as specified in section 14.1), the tunnel sender address and LSP ID fields MUST be the same in each message. For transit nodes, they MUST be the same as the values in the received Path message.
複数のPathメッセージがイングレスかトランジットノードによって使用されるとき、SHOULDがS2LのサブLSPの関連する記述子(例えば、SERO)を除いて、同じであり、通信して、情報を飛び越すというそれぞれのPathメッセージ(例えば、INTEGRITY、MESSAGE_IDとRSVP_HOP)と、SENDER_TEMPLATE物のSub-グループ分野です。 以前開閉している操作が実行されている(セクション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
上で説明されるように、受信されたPathメッセージのSub-グループOriginator IDが変えられるある場合はトランジットノードのPathメッセージの断片化のものです。 別のケースは受信されたPathメッセージのSub-グループOriginator IDが送信するPathメッセージで変えられて、ローカルの方針に基づくPathメッセージをLSR由来のものに設定するかもしれない時です。 例えば、LSRは、決めるかもしれません。
Aggarwal, et al. Standards Track [Page 14] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[14ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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.
ERO拡大を実行している間、いつもSub-グループOriginator IDを変えてください。 Sub-グループOriginator IDを変えないなら、Sub-グループIDを変えてはいけません。
5.2.4. Control of Branch Fate Sharing
5.2.4. 支店運命共有のコントロール
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は、Attributes Flags TLVのビット3を設定することによって、'LSP保全'を要求するかもしれません。 LSP保全が必要であるなら、ビットは設定されます。
It is RECOMMENDED to use the LSP_REQUIRED_ATTRIBUTES object [RFC4420].
それはLSP_REQUIRED_ATTRIBUTES物[RFC4420]を使用するRECOMMENDEDです。
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".
Attributes Flags TLVを支持して、このビットを認識するブランチLSRはLSP保全を支持しなければならないか、またはPathErrメッセージが誤り「ルート設定誤り」/「サポートされないLSP Integrity」を運んでいるLSPセットアップを拒絶しなければなりません。
5.3. Grafting
5.3. 植皮
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(s)を加える操作は植皮と呼ばれます。 この操作で、出口ノードは時間内に、異なったポイントで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へのサブLSPsのS2Lを加える2つの方法があります。 1番目は既存のPathメッセージに彼らを追加して、全体のPathメッセージをリフレッシュするのによるP2MP LSPへのサブLSPsの新しいS2Lを加えることです。 セクション4で説明された経路メッセージ処理はこれらのS2LサブLSPsをP2MP LSPに加えるのに結果として生じます。 PathメッセージへのサブLSPsの1S2Lを加えることの結果、ERO圧縮コード化が再計算されなければならないかもしれないことに注意してください。
The second is to use incremental updates described in section 10.1. The egress LSRs can be added by signaling only the impacted S2L sub- LSPs in a new Path message. Hence, other S2L sub-LSPs do not have to be re-signaled.
2番目はセクション10.1で説明されたアップデート増加を使用することです。 新しいPathメッセージのサブLSPsの影響を与えられたS2Lだけに合図することによって、出口LSRsを加えることができます。 したがって、他のS2LサブLSPsは再合図される必要はありません。
Aggarwal, et al. Standards Track [Page 15] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[15ページ]RFC4875の拡張子をRSVP-Teに追跡します。
6. Resv Message
6. Resvメッセージ
6.1. Resv Message Format
6.1. Resvメッセージ・フォーマット
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>
<Resvメッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>] <セッション><RSVP_ホップ><時間_は>を評価します[<RESV_は>を確認します][<範囲>][<は_要求>に通知します][<アドミン_状態>][<方針_データ>…]。 <様式><流れ記述子リスト>。
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<流れ記述子リスト>:、:= <FF流れ記述子リスト>。| <SE流れ記述子>。
<FF flow descriptor list> ::= <FF flow descriptor>
| <FF flow descriptor list>
<FF flow descriptor>
<FF流れ記述子リスト>:、:= <FF流れ記述子>。| <FF流れ記述子リスト><FF流れ記述子>。
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE流れ記述子>:、:= <FLOWSPEC><SEフィルタ仕様リスト>。
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SEは仕様リスト>をフィルターにかけます:、:= <SEフィルタ仕様>。| <SEフィルタ仕様リスト><SEフィルタ仕様>。
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サブLSPsを特定するように以下の通り変更されます:
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<FF流れ記述子>:、:= [<FLOWSPEC>]<フィルタ_仕様><ラベル>[<記録_ルート>][<S2LサブLSP流れ記述子リスト>]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<SEは仕様>をフィルターにかけます:、:= <フィルタ_仕様><ラベル>[<記録_ルート>][<S2LサブLSP流れ記述子リスト>]
<S2L sub-LSP flow descriptor list> ::=
<S2L sub-LSP flow descriptor>
[ <S2L sub-LSP flow descriptor list> ]
<S2LサブLSP流れ記述子リスト>:、:= <S2LサブLSP流れ記述子>。[<S2LサブLSP流れ記述子リスト>]
<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
[ <P2MP_SECONDARY_RECORD_ROUTE> ]
<S2LサブLSP流れ記述子>:、:= <S2L_潜水艦_LSP>。[<のP2MPの_の二次_記録_ルート>]
FILTER_SPEC is defined in section 19.4.
FILTER_SPECはセクション19.4で定義されます。
Aggarwal, et al. Standards Track [Page 16] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[16ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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サブLSPsを示すことができることに注意してください。 <Sender Addressであるなら同じラベルSHOULDを割り当てて、>がさばく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.
しかしながら、<Sender Address、FILTER_SPEC物のLSP-ID>が異なるなら、異なったラベルを割り当てなければなりません、それが、FILTER_SPECが異なったP2MP LSPについて言及するのを含意するとき。
6.2. Resv Message Processing
6.2. Resvメッセージ処理
The egress LSR MUST follow normal RSVP procedures while originating a Resv message. The format of Resv messages is as defined in section 6.1. As usual, the Resv message carries the label allocated by the egress LSR.
出口LSR MUSTはResvメッセージを溯源している間、正常なRSVP手順に従います。 Resvメッセージの形式がセクション6.1で定義されるようにあります。 いつものように、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メッセージからの複数の流れ記述子を結合するかもしれません。 川下の隣人から少なくとも1つのResvメッセージを受け取るまで上流へResvメッセージを送ってはいけません。 LSP_REQUIRED_ATTRIBUTE物に保全ビットを設定するとき、川下の隣人からすべてのResvメッセージを受け取るまで上流へResvメッセージを送ってはいけません。
Each Fixed-Filter (FF) flow descriptor or Shared-Explicit (SE) filter spec sent upstream in a Resv message includes an S2L sub-LSP descriptor list. Each such FF flow descriptor or SE filter spec for the same P2MP LSP (whether on one or multiple Resv messages) on the same Resv MUST be allocated the same label, and FF flow descriptors or SE filter specs SHOULD use the same label across multiple Resv messages.
それぞれのFixed-フィルタ(FF)流れ記述子かShared明白な(SE)フィルタ仕様が、ResvメッセージがS2LサブLSP記述子リストを含んでいるのを上流へ送りました。 同じResvの上の同じP2MP LSP(1か複数のResvメッセージにかかわらず)のためのそのようなそれぞれのFF流れ記述子かSEフィルタ仕様に同じラベルを割り当てなければなりません、そして、FF流れ記述子かSEフィルタ眼鏡SHOULDが複数の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.
Resvメッセージを送るノード、P2MP LSPに関して、上流はこのノードによって川下のResvメッセージからすべてのラベルを受け取っていて割り当てられたラベルを関連づけなければなりません、そのP2MP LSPのために。 トランジットノードがブランチがそれに付けられる未来に模写ポイントになるかもしれないことに注意してください。 したがって、これはP2MP LSPのイングレスLSRから出口LSRsまでのセットアップをもたらします。
Aggarwal, et al. Standards Track [Page 17] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[17ページ]RFC4875の拡張子をRSVP-Teに追跡します。
The ingress LSR may need to understand when all desired egresses have been reached. This is achieved using S2L_SUB_LSP objects.
イングレスLSRは、すべての必要な出口にいつ達したかを理解する必要があるかもしれません。 これは、S2L_SUB_LSP物を使用することで達成されます。
Each branch node MAY forward a single Resv message upstream for each received Resv message from a downstream receiver. Note that there may be a large number of Resv messages at and close to the ingress LSR for an LSP with many receivers. A branch LSR SHOULD combine Resv state from multiple receivers into a single Resv message to be sent upstream (see section 6.2.1). However, note that this may result in overflowing the Resv message, particularly as the number of receivers downstream of any branch LSR increases as the LSR is closer to the ingress LSR. Thus, a branch LSR MAY choose to send more than one Resv message upstream and partition the Resv state between the messages.
それぞれのブランチノードはそれぞれの受信されたResvメッセージのために川下の受信機から単一のResvメッセージ上流を進めるかもしれません。LSRと多くの受信機があるLSPのためのイングレスLSRの近くに多くのResvメッセージがあるかもしれないことに注意してください。 上流へ(セクション6.2.1を見る)送られるべきただ一つのResvメッセージへの複数の受信機からのブランチLSR SHOULDコンバインResv状態。 しかしながら、これがResvメッセージからはみ出すのに結果として生じるかもしれないことに注意してください、特にLSRがイングレスLSRの、より近くにあるのに従ってどんなブランチLSRの受信機川下の数も増加するように。 その結果、送るLSR MAYが1つ以上の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.
トランジットノードがSub-グループOriginator分野をPathメッセージにはめ込むとき、それはどんな関連ResvメッセージのFILTER_SPEC物にも受け取られたSub-グループ野原を元々PathメッセージのSub-グループ分野で上流の隣人から受けた値に取り替えなければなりません。
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メッセージで運ばれたSub-グループ分野値を使用しなければなりません。
6.2.1. Resv Message Throttling
6.2.1. 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.
川下の隣人のひとりから受け取られたS2LサブLSPへのResvメッセージにおける変化があるときはいつも、ブランチノードは改訂されたResvメッセージ上流を送らなければならないかもしれません。 これはS2LサブLSPsが最初に特に設立されるとき上流へ送られた過度のResvメッセージをもたらすことができます。 この状況を緩和するために、ブランチノードは彼らのResvメッセージの伝達を制限できます。 同じセッションへの前のResvメッセージの伝達以来遅延時間が過ぎている後にだけ、明確に、Resvメッセージで送られる唯一の変化が1個以上のP2MP_SECONDARY_RECORD_ROUTE物(SRROs)にある場合では、ブランチノードSHOULDはResvメッセージを送ります。 この遅れたResvメッセージSHOULDはすべてのブランチのためのSRROsを含んでいます。 遅延時間の間の提案された値は、30秒と、遅れ回のSHOULDです。一般に、1 2番目より長くいてください。 Resvメッセージ阻止のための特定のメカニズムとディレイタイマ設定は、実現に依存していて、このドキュメントの範囲の外にあります。
Aggarwal, et al. Standards Track [Page 18] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[18ページ]RFC4875の拡張子をRSVP-Teに追跡します。
6.3. Route Recording
6.3. ルート録音
6.3.1. RRO Processing
6.3.1. RRO処理
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.
イングレスLSRがオリジナルのPathメッセージにRROを含んでいることによってルート録音を要求したなら、P2P LSPへのResvメッセージは記録されたルートを含んでいます。 同じ規則はP2MP LSPsのシグナリングの間、使用されます。 すなわち、1S2LサブLSPsに合図するのに使用されるPathメッセージでのRROの包含はResvメッセージのそれぞれのサブLSPのための記録されたルートの包含の引き金となります。
The recorded route of the first S2L sub-LSP is encoded in the RRO. Additional recorded routes for the subsequent S2L sub-LSPs are encoded in P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). Their format is specified in section 19.5. Each S2L_SUB_LSP object in a Resv is associated with an RRO or SRRO. The first S2L_SUB_LSP object (for the first S2L sub-LSP) is associated with the RRO. Subsequent S2L_SUB_LSP objects (for subsequent S2L sub-LSPs) are each followed by an SRRO that contains the recorded route for that S2L sub-LSP from the leaf to a branch. The ingress node can then use the RRO and SRROs to determine the end-to-end path for each S2L sub-LSP.
最初のS2LサブLSPの記録されたルートはRROでコード化されます。 その後のS2LサブLSPsのための追加記録されたルートはP2MP_SECONDARY_RECORD_ROUTE物(SRROs)でコード化されます。 それらの形式はセクション19.5で指定されます。 ResvのそれぞれのS2L_SUB_LSP物はRROかSRROに関連しています。 最初のS2L_SUB_LSP物(最初のS2LサブLSPのための)はRROに関連しています。 その後のS2L_SUB_LSP物(その後のS2LサブLSPsのための)は葉からブランチまでのサブLSPのそのS2Lのための記録されたルートを含むSRROによってそれぞれ従われています。 そして、イングレスノードは、それぞれのS2LサブLSPのために終わりから端への経路を決定するのにRROとSRROsを使用できます。
6.4. Reservation Style
6.4. 予約様式
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.
Resvメッセージにおける予約スタイルに関する問題は[RFC3209]で説明されるように適用されます。 Resvメッセージにおける予約スタイルは、FFかSEのどちらかであるかもしれません。 同じ予約スタイルで同じP2MP Tunnelに属すすべてのP2MP LSPsに合図しなければなりません。 予約スタイルがFFかそれともSEであるかにおいて関係ありません、同じP2MP LSP SHOULDに属すS2LサブLSPsはそれらがホップを共有するラベルを共有します。 同じP2MP LSPに属すS2LサブLSPsがラベルを共有するなら、それらはリソースを共有しなければなりません。 予約スタイルがFFであるなら、異なったP2MP LSPsに属すS2LサブLSPsはリソースかラベルを共有してはいけません。 予約スタイルがSEであるなら、異なったP2MP LSPsと同じP2MPトンネルSHOULDに属すS2LサブLSPsがそれらがホップを共有するリソースを共有しますが、それらはパケット環境でラベルを共有してはいけません。
Aggarwal, et al. Standards Track [Page 19] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[19ページ]RFC4875の拡張子をRSVP-Teに追跡します。
7. PathTear Message
7. PathTearメッセージ
7.1. PathTear Message Format
7.1. PathTearメッセージ・フォーマット
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> ]
<PathTearメッセージ>:、:= <の一般的なHeader>[<INTEGRITY>][_<MESSAGE_ID ACK>| _<MESSAGE_IDナック>…][<MESSAGE_ID>]<SESSION><RSVP_HOP>[<送付者記述子>][<S2LサブLSP記述子リスト>]
<S2L sub-LSP descriptor list> ::= <S2L_SUB_LSP>
[ <S2L sub-LSP descriptor list> ]
<S2LサブLSP記述子リスト>:、:= <S2L_潜水艦_LSP>。[<S2LサブLSP記述子リスト>]
The definition of <sender descriptor> is not changed by this document.
<送付者記述子>の定義はこのドキュメントによって変えられません。
7.2. Pruning
7.2. 刈り込み
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(s)を取り外す操作は刈り込みとして呼ばれます。 この操作は、出口ノードが時間内にP2MP LSPと異なったポイントで取り除かれるのを許容します。 このセクションは、刈り込みを実行するためにメカニズムについて説明します。
7.2.1. Implicit S2L Sub-LSP Teardown
7.2.1. 暗黙のS2LサブLSP分解
Implicit teardown uses standard RSVP message processing. Per standard RSVP processing, an S2L sub-LSP may be removed from a P2MP TE LSP by sending a modified message for the Path or Resv message that previously advertised the S2L sub-LSP. This message MUST list all S2L sub-LSPs that are not being removed. When using this approach, a node processing a message that removes an S2L sub-LSP from a P2MP TE LSP MUST ensure that the S2L sub-LSP is not included in any other Path state associated with session before interrupting the data path to that egress. All other message processing remains unchanged.
暗黙の分解は標準のRSVPメッセージ処理を使用します。 標準のRSVP処理に従って、S2LサブLSPは以前にS2LサブLSPの広告を出したPathかResvメッセージへの変更されたメッセージを送るのによるP2MP TE LSPから取り外されるかもしれません。 このメッセージは取り外されていないすべてのS2LサブLSPsを記載しなければなりません。 このアプローチを使用するとき、いかなる他のPath状態にもS2LサブLSPがP2MP TE LSP MUSTからのサブLSPが確実にするS2Lですが、取り除かれるメッセージを処理するのを含んでいるノードはその出口にデータ経路を中断する前のセッションと交際しました。 他のすべてのメッセージ処理が変わりがあるというわけではありません。
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.
暗黙の分解がPathメッセージを変更するのによるサブLSPsの1S2Lを削除するのに使用されるとき、これらのS2LサブLSPsの1つ以上を削除するために川下でPathTearメッセージを発生させるようにLSRにはあるかもしれない通過します。 対応するPathメッセージを送るためにはサブLSPsの残っているS2Lが全くS2LサブLSP(s)の暗黙の削除の結果、川下になければ、これは起こることができます。
Aggarwal, et al. Standards Track [Page 20] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[20ページ]RFC4875の拡張子をRSVP-Teに追跡します。
7.2.2. Explicit S2L Sub-LSP Teardown
7.2.2. 明白なS2LサブLSP分解
Explicit S2L Sub-LSP teardown relies on generating a PathTear message for the corresponding Path message. The PathTear message is signaled with the SESSION and SENDER_TEMPLATE objects corresponding to the P2MP LSP and the <Sub-Group Originator ID, Sub-Group ID> tuple corresponding to the Path message. This approach SHOULD be used when all the egresses signaled by a Path message need to be removed from the P2MP LSP. Other S2L sub-LSPs, from other sub-groups signaled using other Path messages, are not affected by the PathTear.
明白なS2L Sub-LSP分解は対応するPathメッセージへのPathTearメッセージを発生させるのを当てにします。 PathTearメッセージはSESSION、P2MP LSPに対応するSENDER_TEMPLATE物、および<Sub-グループOriginator ID(Pathメッセージに対応するSub-グループID>tuple)と共に合図されます。 これはSHOULDにアプローチします。Pathメッセージによって合図されたすべての出口が、P2MP LSPから取り除かれる必要があるときには、使用されてください。 他のPathメッセージを使用することで合図された他のサブグループから、他のS2LサブLSPsはPathTearで影響を受けません。
A transit LSR that propagates the PathTear message downstream MUST ensure that it sets the <Sub-Group Originator ID, Sub-Group ID> tuple in the PathTear message to the values used in the Path message that was used to set up the S2L sub-LSPs being torn down. The transit LSR may need to generate multiple PathTear messages for an incoming PathTear message if it had performed transit fragmentation for the corresponding incoming Path message.
PathTearメッセージ川下を伝播するトランジットLSRは、<Sub-グループOriginator ID(S2LサブLSPsをセットアップするのに取りこわしながら使用されたPathメッセージで使用される値へのPathTearメッセージのSub-グループID>tuple)を設定するのを確実にしなければなりません。 対応する入って来るPathメッセージのためのトランジット断片化を実行したなら、トランジットLSRは、入って来るPathTearメッセージへの複数のPathTearメッセージを発生させる必要があるかもしれません。
When a P2MP LSP is removed by the ingress, a PathTear message MUST be generated for each Path message used to signal the P2MP LSP.
P2MP LSPがイングレスによって取り外されるとき、PathTearメッセージはP2MP LSPに合図するのに使用されるそれぞれのPathメッセージのために発生しなければなりません。
8. Notify and ResvConf Messages
8. 通知してください。そうすれば、ResvConfは通信します。
8.1. Notify Messages
8.1. メッセージに通知してください。
The Notify Request object and Notify message are described in [RFC3473]. Both object and message SHALL be supported for delivery of upstream and downstream notification. Processing not detailed in this section MUST comply to [RFC3473].
Notify Request物とNotifyメッセージは[RFC3473]で説明されます。 両方が、反対して、SHALLを通信させます。上流の、そして、川下の通知の配送のために、支持されます。 このセクションで詳しく述べられなかった処理は[RFC3473]に応じなければなりません。
1. Upstream Notification
1. 上流の通知
If a transit LSR sets the Sub-Group Originator ID in the SENDER_TEMPLATE object of a Path message to its own address, and the incoming Path message carries a Notify Request object, then this LSR MUST change the Notify node address in the Notify Request object to its own address in the Path message that it sends.
トランジットであるなら、LSRはそれ自身のアドレスへのPathメッセージのSENDER_TEMPLATE物にSub-グループOriginator IDをはめ込みます、そして、入って来るPathメッセージはNotify Request物を運びます、そして、次に、このLSR MUSTはそれ自身のアドレスへの発信するというPathメッセージのNotify Request物のNotifyノードアドレスを変えます。
If this LSR subsequently receives a corresponding Notify message from a downstream LSR, then it MUST:
このLSRが次に川下のLSRから対応するNotifyメッセージを受け取るなら、そうしなければなりません:
- send a Notify message upstream toward the Notify node address
that the LSR received in the Path message.
- LSRがPathメッセージに受け取ったNotifyノードアドレスに向かってNotifyメッセージ上流を送ってください。
Aggarwal, et al. Standards Track [Page 21] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[21ページ]RFC4875の拡張子をRSVP-Teに追跡します。
- 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物のSub-グループ分野を受信されたNotifyメッセージに処理してください、そして、それらの値を変更してください、上流から受け取られたオリジナルのPathメッセージのSub-グループ分野値を合わせるために転送されるNotifyメッセージで。
The receiver of an (upstream) Notify message MUST identify the state referenced in this message based on the SESSION and SENDER_TEMPLATE.
SESSIONとSENDER_TEMPLATEに基づくこのメッセージで参照をつけられる状態を特定しなければなりません(上流)の受信機が、メッセージに通知する。
2. Downstream Notification
2. 川下の通知
A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value that was received in the corresponding Path message. If the incoming Resv message carries a Notify Request object, then:
トランジットLSRは対応するPathメッセージに受け取られた値へのResvメッセージのFILTER_SPEC物にSub-グループOriginator IDをはめ込みます。 次に、入って来るResvメッセージがNotify Request物を運ぶなら:
- If there is at least another incoming Resv message that carries
a Notify Request object, and the LSR merges these Resv messages
into a single Resv message that is sent upstream, the LSR MUST
set the Notify node address in the Notify Request object to its
Router ID.
- 少なくともNotify Request物を運ぶ別の入って来るResvメッセージがあって、LSRが上流へ送られるただ一つのResvメッセージにこれらのResvメッセージを合併するなら、LSR MUSTはRouter IDへのNotify Request物にNotifyノードアドレスをはめ込みます。
- 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がSub-グループOriginator ID(受信されたResvメッセージに対応する送信するPathメッセージの)をそれ自身のアドレスに設定するなら、LSR MUSTはRouter IDへのNotify Request物にNotifyノードアドレスをはめ込みます。
- Else the LSR MUST propagate the Notify Request object unchanged,
in the Resv message that it sends upstream.
- ほかに、LSR MUSTは上流へ発信するというResvメッセージで変わりのないNotify Request物を伝播します。
If this LSR subsequently receives a corresponding Notify message from an upstream LSR, then it MUST:
このLSRが次に上流のLSRから対応するNotifyメッセージを受け取るなら、そうしなければなりません:
- 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.
- 受信されたNotifyメッセージでFILTER_SPEC物のSub-グループ分野を処理してください、そして、それらの値を変更してください、このLSRによって川下に送られたオリジナルのPathメッセージのSub-グループ分野値を合わせるために転送されるNotifyメッセージで。
- send a Notify message downstream toward the Notify node address
that the LSR received in the Resv message.
- LSRがResvメッセージに受け取ったNotifyノードアドレスに向かってNotifyメッセージ川下を送ってください。
The receiver of a (downstream) Notify message MUST identify the state referenced in the message based on the SESSION and FILTER_SPEC objects.
SESSIONと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
P2MP LSPのためのこれらの規則の結果は支店で発生する上流のNotifyメッセージが上流のNotifyノードアドレスに届けられるNotifyをもたらすということです。 Notifyメッセージの受信機は、Notifyメッセージがすべてに適用されると仮定してはいけません。
Aggarwal, et al. Standards Track [Page 22] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[22ページ]RFC4875の拡張子をRSVP-Teに追跡します。
downstream egresses, but MUST examine the information in the message to determine to which egresses the message applies.
メッセージがどの出口に適用されるかを決定するメッセージの情報を調べなければならないのを除いた川下の出口。
Downstream Notify messages MUST be replicated at branch LSRs according to the Notify Request objects received on Resv messages. Some downstream branches might not request Notify messages, but all that have requested Notify messages MUST receive them.
Resvメッセージに受け取られたNotify Request物に従って、川下のNotifyメッセージをブランチLSRsに模写しなければなりません。 いくつかの川下のブランチはNotifyメッセージを要求するのではなく、Notifyメッセージがそれらを受けなければならないよう要求したすべてを要求するかもしれません。
8.2. ResvConf Messages
8.2. ResvConfメッセージ
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]で説明されます。 直接[RFC2205]から[RFC3473]と[RFC3209]でのResvConf処理を取ります。 出口LSR MAYは出口LSRのアドレスを含むRESV_CONFIRM物を含んでいます。 反対してください、そして、SHALLを通信させてください。P2MP TE LSPsでの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物にSub-グループOriginator IDをはめ込みます。 ただ一つのPathメッセージに対応する入って来るResvメッセージのどれかがRESV_CONFIRM物を運ぶなら、LSR MUSTは上流へ発信するという対応するResvメッセージにRESV_CONFIRM物を含んでいます。 Sub-グループOriginator 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物にSub-グループOriginator IDをはめ込みます。 そして、ただ一つのPathメッセージに対応する入って来るResvメッセージがRESV_CONFIRM物を運ぶならLSR MUSTが上流へ発信するという対応するResvメッセージにRESV_CONFIRM物を含んでいる、:
- If there is at least another incoming Resv message that carries
a RESV_CONFIRM object, and the LSR merges these Resv messages
into a single Resv message that is sent upstream, the LSR MUST
set the receiver address in the RESV_CONFIRM object to its
Router ID.
- 少なくともRESV_CONFIRM物を運ぶ別の入って来るResvメッセージがあって、LSRが上流へ送られるただ一つのResvメッセージにこれらのResvメッセージを合併するなら、LSR MUSTはRouter 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がSub-グループOriginator ID(受信されたResvメッセージに対応する送信するPathメッセージの)をそれ自身のアドレスに設定するなら、LSR MUSTはRouter IDへのRESV_CONFIRM物に受信機アドレスをはめ込みます。
- Else the LSR MUST propagate the RESV_CONFIRM object unchanged,
in the Resv message that it sends upstream.
- ほかに、LSR MUSTは上流へ発信するというResvメッセージで変わりのないRESV_CONFIRM物を伝播します。
Aggarwal, et al. Standards Track [Page 23] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[23ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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物のSub-グループ分野を処理してください、そして、それらの値を変更してください、このLSRによって川下に送られたオリジナルのPathメッセージのSub-グループ分野値を合わせるために転送される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メッセージの受信機はSESSIONに基づくこのメッセージと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メッセージがすべての川下の出口に送られるべきであると仮定してはいけませんが、Resvメッセージに受け取られたRESV_CONFIRM物に従って、それはメッセージを模写しなければなりません。 いくつかの川下のブランチは、ResvConfメッセージ、およびResvConfメッセージSHOULD NOTがこれらのブランチで送られるよう要求しないかもしれません。 ResvConfメッセージを要求したすべての川下のブランチにそのようなメッセージを送らなければなりません。
9. Refresh Reduction
9. 減少をリフレッシュしてください。
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 LSPsに適切です。 リフレッシュしてください。減少は彼らがインストールするか、または維持する個々のメッセージと状態に申し込まれます、そして、P2MP LSPsのためにそれはずっとケースです。
10. State Management
10. 国家管理
State signaled by a P2MP Path message is identified by a local implementation using the <P2MP ID, Tunnel ID, Extended Tunnel ID> tuple as part of the SESSION object and the <Tunnel Sender Address, LSP ID, Sub-Group Originator ID, Sub-Group ID> tuple as part of the SENDER_TEMPLATE object.
P2MP Pathメッセージによって合図された状態はSESSION物と<Tunnel Sender Addressの一部として<P2MP ID、Tunnel ID、Extended Tunnel ID>tupleを使用しながら、地方の実現で特定されます、LSP ID、Sub-グループOriginator ID、SENDER_TEMPLATE物の一部としてのSub-グループID>tuple。
Additional information signaled in the Path/Resv message is part of the state created by a local implementation. This includes PHOP/NHOP and SENDER_TSPEC/FILTER_SPEC objects.
Path/Resvメッセージで合図された追加情報は地方の実現で創設された状態の一部です。 これはPHOP/NHOPとSENDER_TSPEC/FILTER_SPEC物を含んでいます。
Aggarwal, et al. Standards Track [Page 24] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[24ページ]RFC4875の拡張子をRSVP-Teに追跡します。
10.1. Incremental State Update
10.1. 増加の州のアップデート
RSVP (as defined in [RFC2205] and as extended by RSVP-TE [RFC3209] and GMPLS [RFC3473]) uses the same basic approach to state communication and synchronization -- namely, full state is sent in each state advertisement message. Per [RFC2205], Path and Resv messages are idempotent. Also, [RFC2961] categorizes RSVP messages into two types (trigger and refresh messages) and improves RSVP message handling and scaling of state refreshes, but does not modify the full state advertisement nature of Path and Resv messages. The full state advertisement nature of Path and Resv messages has many benefits, but also has some drawbacks. One notable drawback is when an incremental modification is being made to a previously advertised state. In this case, there is the message overhead of sending the full state and the cost of processing it. It is desirable to overcome this drawback and add/delete S2L sub-LSPs to/from a P2MP LSP by incrementally updating the existing state.
RSVP([RFC2205]で定義されて、RSVP-TE[RFC3209]とGMPLSで広がるように[RFC3473])はコミュニケーションと同期を述べるのに同じ基本的なアプローチを使用します--すなわち、それぞれの州の広告メッセージで完全な状態を送ります。 [RFC2205]あたりPathとResvメッセージはベキ等元です。 また、[RFC2961]がRSVPメッセージを2つのタイプ(メッセージの引き金となって、リフレッシュする)に分類して、RSVPメッセージハンドリングを改良して、状態のスケーリングは、リフレッシュしますが、PathとResvメッセージの完全な州の広告本質を変更しません。 PathとResvメッセージの完全な州の広告本質には、多くの利益を持っていますが、いくつかの欠点がまたあります。 1つの注目に値する欠点が増加の変更が以前に広告を出した状態にされている時です。 この場合、完全な状態を送るメッセージオーバーヘッドとそれを処理する費用があります。 現状を増加してアップデートするのによるP2MP LSPからの/へのサブLSPsのS2Lにこの欠点に打ち勝って、加えるか、または削除するのが望ましいです。
It is possible to use the procedures described in this document to allow S2L sub-LSPs to be incrementally added to or deleted from the P2MP LSP by allowing a Path or a PathTear message to incrementally change the existing P2MP LSP Path state.
S2LサブLSPsはP2MP LSP Pathが述べる存在を増加して加えられるか、またはPathを許容するのによるP2MP LSPか増加して変化するPathTearメッセージから削除されるのを許容するために本書では説明された手順を用いるのが可能です。
As described in section 5.2, multiple Path messages can be used to signal a P2MP LSP. The Path messages are distinguished by different <Sub-Group Originator ID, Sub-Group ID> tuples in the SENDER_TEMPLATE object. In order to perform incremental S2L sub-LSP state addition, a separate Path message with a new Sub-Group ID is used to add the new S2L sub-LSPs, by the ingress LSR. The Sub-Group Originator ID MUST be set to the TE Router ID [RFC3477] of the node that sets the Sub-Group ID.
セクション5.2で説明されるように、P2MP LSPに合図するのに複数のPathメッセージを使用できます。 SENDER_TEMPLATEのSub-グループID>tuplesは、Pathメッセージが異なった<Sub-グループOriginator IDによって区別されるのを反対します。 増加のS2LサブLSP州の添加を実行して、新しいSub-グループIDがある別々のPathメッセージは新しいS2LサブLSPsを加えるのに使用されます、イングレスLSR。 Sub-グループIDを設定するノードのTE Router ID[RFC3477]にSub-グループOriginator IDを設定しなければなりません。
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州のアップデートを履行能力に前提とします。
10.2. Combining Multiple Path Messages
10.2. 複数の経路メッセージを結合します。
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メッセージへのサブLSPsのS2Lを加えるとき完全な州のメッセージによって課された処理の間には、見返りがあります。 以前にP2MP LSPを維持するのに必要であるPathメッセージの数を減少させるためにただ一つのPathメッセージの異なったPathメッセージの広告に掲載されたS2LサブLSPsを結合するのは可能です。 また、断片化を実行して、後のポイントでそれがただ一つのPathメッセージに発生させた複数のPathメッセージを結合できるトランジットノードはこれができます。 1S2LサブLSPs Pathが述べる存在から余計なものを取り除かれるとき、これは起こるかもしれません。
Aggarwal, et al. Standards Track [Page 25] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[25ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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にただ一つのPathメッセージで結合されている結合するのがサブLSPsであると合図されます。 このPathメッセージは新しいSub-グループID分野値を含むかもしれません。 新しいPathとResvであるときに、既存のS2LサブLSPのために合図されるメッセージはトランジットLSRによって受け取られて、S2LサブLSPの新しい例を含む州が創設されます。
The S2L sub-LSP SHOULD continue to be advertised in both the old and new Path messages until a Resv message listing the S2L sub-LSP and corresponding to the new Path message is received by the combining node. Hence, until this point, state for the S2L sub-LSP SHOULD be maintained as part of the Path state for both the old and the new Path message (see section 3.1.3 of [RFC2205]). At that point the S2L sub-LSP SHOULD be deleted from the old Path state using the procedures of section 7.
S2LサブLSP SHOULDは、両方の古くて新しいPathメッセージに結合ノードで新しいPathメッセージにサブLSPの、そして、対応するS2Lを記載するResvメッセージを受け取るまで広告を出し続けています。 したがって、S2LサブLSP SHOULDのために老人と新しいPathメッセージの両方のためにPath状態の一部として維持される(.3セクション3.1[RFC2205]を見る)ようにこのポイントまで述べてください。 おまけに、S2LサブLSP SHOULDは指します。古いPath状態から、セクション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:
Subグループ_ID(n)があるPathメッセージは既に既存のSubグループ_ID(i)に部分的か完全に属すS2LサブLSPsの1セット、またはS2LサブLSPsの厳密に非重なっている新しいセットを示すかもしれません。 マッチのSESSION物とSender Tunnel Address(LSP ID、同じであるか異なったSubグループ_IDを運ぶPathが述べる存在があるSub-グループOriginator ID>)がSubグループ_ID(n)について言及したという新たに受け取られたPathメッセージは以下の通り処理されます:
1) If Sub-Group_ID(i) = Sub-Group_ID(n), then S2L Sub-LSPs that are
in both Sub-Group_ID(i) and Sub-Group_ID(n) are refreshed. New
S2L Sub-LSPs are added to Sub-Group_ID(i) Path state and S2L Sub-
LSPs that are in Sub-Group_ID(i) but not in Sub-Group_ID(n) are
deleted from the Sub-Group_ID(i) Path state.
1) サブグループ_ID(i)です。 = サブGroup_IDの(n)、当時のSubグループ_ID(i)とリフレッシュされたSubグループ_ID(n)の両方にあるS2L Sub-LSPs。 新しいS2L Sub-LSPsはSubグループ_ID(i)に加えられます。 Subグループ_ID(i)にありますが、Subグループ_ID(n)にあるというわけではない経路州とS2L Sub- LSPsはSubグループ_ID(i)から削除されます。 経路州。
2) If Sub-Group_ID(i) != Sub-Group_ID(n), then a new Sub-Group_ID(n)
Path state is created for S2L Sub-LSPs signaled by Sub-
Group_ID(n). S2L Sub-LSPs in existing Sub-Group_IDs(i) Path state
(that are or are not in the newly received Path message Sub-
Group_ID(n)) are left unmodified (see above).
2) サブグループ_ID(i)です。 =次に、新しいSubサブGroup_ID(n)(ID)のグループ_(n) 経路州はSubグループ_ID(n)によって合図されたS2L Sub-LSPsのために創設されます。 既存のSubグループ_ID(i)におけるサブLSPsのS2L 経路州、(それは、あるか、またはグループ_ID(n))が変更されていないままにされるという(上を見てください)新たに受け取られたPathメッセージSubにいません。
11. Error Processing
11. エラー処理
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手順に従って処理されます。 特定のS2LサブLSPへのPathErr/ResvErrメッセージを受け取るときLSRがそのS2LサブLSPのためだけに状態を変えることに注意してください。 したがって、他のS2LサブLSPsは影響を与えられません。 イングレスノードが'LSP保全'を要求するなら、特定のS2LサブLSPのためにP2MP TE LSPのブランチに関して報告された誤りは同じP2MP TE LSPのいかなる他のS2LサブLSPの州も変えるかもしれません。 これはセクション11.3で、より詳しく説明されます。
Aggarwal, et al. Standards Track [Page 26] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[26ページ]RFC4875の拡張子をRSVP-Teに追跡します。
11.1. PathErr Messages
11.1. PathErrメッセージ
The PathErr message will include one or more S2L_SUB_LSP objects. The resulting modified format for a PathErr message is:
PathErrメッセージは1個以上のS2L_SUB_LSP物を含むでしょう。 PathErrメッセージのための結果として起こる変更された形式は以下の通りです。
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[ <S2L sub-LSP descriptor list> ]
<PathErrメッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>]<セッション><誤り_仕様>[<の許容できる_ラベル_は>を…設定します] [<方針_データ>] <送付者記述子>。[<S2LサブLSP記述子リスト>]
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メッセージ世代は変更されていませんが、Sub-グループOriginator分野を設定して、容認されたPathErrメッセージ上流を伝播するノードはPathErrメッセージに受け取られたSub-グループ野原をPathメッセージのSub-グループ分野に上流の隣人から受け取られた値に取り替えなければなりません。 PathErrメッセージに受け取られたSub-グループ野原に基づいてPathErrメッセージの受信機がerrored送信するPathメッセージ、および外向的なインタフェースを特定できることに注意してください。 S2LサブLSP記述子リストはセクション5.1で定義されます。
11.2. ResvErr Messages
11.2. ResvErrメッセージ
The ResvErr message will include one or more S2L_SUB_LSP objects. The resulting modified format for a ResvErr Message is:
ResvErrメッセージは1個以上のS2L_SUB_LSP物を含むでしょう。 ResvErr Messageのための結果として起こる変更された形式は以下の通りです。
<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メッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>]<セッション><RSVP_ホップ><誤り_仕様>[<範囲>][<の許容できる_ラベル_は>を…設定します] [<方針_データ>] <様式><流れ記述子リスト>。
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
ResvErrメッセージ世代は変更されていませんが、Sub-グループOriginator分野を設定して、受信されたResvErrメッセージを川下に伝播するノードはResvErrメッセージに受け取られたSub-グループ野原を川下の隣人に送られたPathメッセージのSub-グループ分野に設定された値に取り替えなければなりません。 ResvErrメッセージの受信機がerrored出発しているResvを特定できることに注意してください。
Aggarwal, et al. Standards Track [Page 27] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[27ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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メッセージに受け取られたSub-グループ野原に基づいた外向的なインタフェース。 流れ記述子リストはセクション6.1で定義されます。
11.3. Branch Failure Handling
11.3. 支店失敗取り扱い
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メッセージは最初に、標準の処理規則単位で処理されます。 そのPathメッセージのためにイングレス/ブランチへのホップごとのLSRをすなわち、PathErrメッセージに送ります。 中間的このイングレス/ブランチLSR MAYまでのノードは、このメッセージを点検しますが、それへの行動を全く取りません。 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_州_Removed旗を設定しないということです。 しかしながら、イングレスLSRがLSP保全旗をPathメッセージにけしかけて(ATTRIBUTEsがセクション5.2.4で反対させるLSP_REQUIRED_を見てください)、Path_州_Removed旗が支えられるなら、P2MP LSP SHOULDのブランチの失敗を報告するためにPathErrを発生させるLSRはPath_州_Removed旗を設定します。
A branch LSR that receives a PathErr message during LSP setup with the Path_State_Removed flag set MUST act according to the wishes of the ingress LSR. The default behavior is that the branch LSR clears the Path_State_Removed flag on the PathErr and sends it further upstream. It does not tear any other branches of the LSP. However, if the LSP integrity flag is set on the Path message, the branch LSR MUST send PathTear on all other downstream branches and send the PathErr message upstream with the Path_State_Removed flag set.
イングレスの願望に従って、Path_州_Removed旗のセットによるLSPセットアップの間にPathErrメッセージを受け取るブランチLSRはLSRを活動させなければなりません。 デフォルトの振舞いはブランチLSRが上流へPathErrでPath_州_Removed旗をきれいにして、さらにそれを送るということです。 それはLSPのいかなる他のブランチも引き裂きません。 しかしながら、LSP保全旗がPathメッセージに設定されるなら、ブランチLSR MUSTは他のすべての川下のブランチでPathTearを送って、Path_州_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_州_Removed旗が明確な状態でPathErrメッセージを受け取るブランチLSRはLSRを活動させなければなりません。 デフォルトの振舞いはブランチLSRが上流へPathErrを進めて、これ以上行動を取らないということです。 しかしながら、LSP保全旗がPathメッセージに設定されるなら、ブランチLSR MUSTはPath_州_Removed旗のセット([RFC3473]あたりの)ですべての川下のブランチでPathTearを送って、上流へ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.
すべてのケース、ブランチによって転送されたPathErrメッセージでは、LSR MUSTは受信されたPathErrメッセージによって報告されるすべてのブランチとブランチLSRによって明らかに引き裂かれるすべてのブランチのS2LサブLSP識別と明白なルートを含んでいます。
Aggarwal, et al. Standards Track [Page 28] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[28ページ]RFC4875の拡張子をRSVP-Teに追跡します。
12. Admin Status Change
12. アドミン状態変化
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物を受けるブランチノードは、通常、それを処理して、また、あらゆる支店でPathの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メッセージを待ちます。
13. Label Allocation on LANs with Multiple Downstream Nodes
13. 複数の川下のノードのLANにおけるラベル配分
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.
SHOULDが川下のLSRあたりのデータ通信量のコピー1部を送るイーサネットLANセグメントのP2MP LSPのブランチLSRはそのP2MP LSPのためにそのLANで接続しました。 MPLSを防ぐための手順はそのようなものの範囲を超えてケースがある交通模写をこのドキュメントとラベルしました。
14. P2MP LSP and Sub-LSP Re-Optimization
14. P2MP LSPとサブLSP再最適化
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 LSPsによって使用された経路を変えるのは可能です。 これを達成するのに使用できる2つの方法があります。 第1は、以前、開閉していて、[RFC3209]で定義されています、そして、秒は上で定義されたサブグループを使用します。
14.1. Make-before-Break
14.1. 以前、開閉してください。
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サブLSPsが異なったLSP IDと共にイングレスLSRによって合図されて、[RFC3209]で定義された以前開閉している手順に従います。 したがって、新しいP2MP LSPは設立されます。 新しいP2MP LSPに対応している、それぞれのS2LサブLSPは異なったLSP IDと共に合図されます。 交通を新しいP2MP LSPに動かした後に、イングレスは古いP2MP LSPを取りこわすことができます。 全体のP2MP LSPの経路か経路をP2MP LSPの目的地の部分集合に再最適化するのにこの手順を用いることができます。 まさしくP2MP LSPの一部を変更するとき、このアプローチは、全体のP2MP LSPが再合図されるのを必要とします。
14.2. Sub-Group-Based Re-Optimization
14.2. サブグループベースの再最適化
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.
どんなノードも、増加の状態を使用するのによるサブLSPsがアップデートするS2Lの1セットの再最適化を開始して、次に、複数の任意に結合した経路メッセージを開始するかもしれません。
Aggarwal, et al. Standards Track [Page 29] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[29ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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サブLSPsの特定のセットによって取られた経路を変更するために、経路変化を起こすノードは同じP2MP LSPへの1つ以上の別々のPathメッセージを開始します、それぞれ新しいサブGroup IDと共に。 これらのPathメッセージの世代(1S2LがサブLSPsであるそれぞれ)はセクション5.2で手順に従います。 セクション10.2のケースのように、特定の出口は、両方の古くて新しいPathメッセージに再最適化ノードで出口を記載して、新しいPathメッセージに対応するResvメッセージを受け取るまで広告を出し続けています。 ポイント、出口SHOULDは、古い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サブLSPsの1セットへの新しいPathメッセージはS2LサブLSPsの同じセットのための古いPath状態とのより多くのトランジット1ノードをもたらすとき、サブGroupベースの再最適化が一時的なデータ複製をもたらすかもしれません。
As is always the case, a node may choose to combine multiple path messages as described in section 10.2.
いつものことだが、ノードは、セクション10.2で説明されるように複数の経路メッセージを結合するのを選ぶかもしれません。
15. Fast Reroute
15. 速くコースを変更してください。
[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]をLSRsに当てはまるだけです。
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]で定義された手順を別ルートで送るこのセクションに従わなければなりません。 ギヤエンドとトランジットLSRsはP2MP LSPのそれぞれのPathメッセージとS2LサブLSPのための[RFC4090]での指定されるとしてのSESSION_ATTRIBUTEとFAST_REROUTE物の処理に続かなければなりません。 P2MP LSP MUSTのサブLSPのそれぞれのS2Lには、同じ保護の特性があります。 以下で変更されない場合、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 LSPsに適用されるかもしれません。 このドキュメントはあらゆる想像可能な用法ケースのための詳細な処理ステップについて説明しません、そして、それらは将来のドキュメントで説明されるかもしれません、必要に応じて。
Aggarwal, et al. Standards Track [Page 30] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[30ページ]RFC4875の拡張子をRSVP-Teに追跡します。
15.1. Facility Backup
15.1. 施設バックアップ
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の経路におけるLSRsのリンクかノード保護に施設バックアップを使用できます。 Local Repair(PLR)のPointは川下のラベルについて学習しなければなりません、[RFC4090]で指定されるように、RESVメッセージのサブLSPのS2Lに対応するラベルから。 バックアップトンネルで合図されたSEROsの処理は[RFC4090]で説明されたバックアップトンネルERO処理に続かなければなりません。
15.1.1. Link Protection
15.1.1. リンク保護
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と次のホップとのリンクを保護するのに迂回トンネルを使用しなければなりません。 その結果、リンクSHOULDを使用するすべてのS2LサブLSPs、リンクの故障の場合、保護されてください。 P2MPトンネルSHOULDの特定の例に属すそのようなすべてのS2LサブLSPsがセクション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へのPathメッセージの間、PLRはMerge Point(MP)に送らなければなりません。 PLRがこれらのPathメッセージを特定する送付者のテンプレート特有の方法を使用するのは、RECOMMENDEDです。 したがって、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サブLSPsを特定するのにLSP-IDを使用しなければなりません。 MPは対応するS2LサブLSPsを特定している間、<Sub-グループOriginator ID、Sub-グループID>tupleを使用してはいけません。 さらにS2LサブLSPを処理するために、LSP-IDとS2L_SUB_LSP物を使用して、MPは保護されたS2LサブLSPを決定しなければなりません。
15.1.2. Node Protection
15.1.2. ノード保護
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 SHOULDは、保護されたノードを通過するS2LサブLSPsのセットを保護するのに1つ以上のP2P迂回トンネルを使用します。 それぞれのこれらのP2P迂回トンネルは横切られなければなりません。彼らが川下で保護されたノードから来ているLSRに保護するS2LサブLSPsの経路。 これは一般的な川下のMPを通り抜けるそれらのS2LサブLSPsへのその迂回トンネルを通って支持されるS2LサブLSPsのセットを抑制します。 このMPは迂回トンネルの目的地です。 PLRがP2MP LSPのための受信データを迂回トンネルに転送するとき、外側のラベルは迂回トンネルラベルです、そして、内側のラベルはそのP2MP LSPに属しながらMPによってS2LサブLSPsのセットに割り当てられたラベルです。
Aggarwal, et al. Standards Track [Page 31] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[31ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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 MUSTが送る保護されたノードの失敗を検出した後に、すべてへの1つ以上のPathメッセージが保護されたS2LサブLSPのMPへのサブLSPsのS2Lを保護しました。 PLRがこれらのPathメッセージを特定する送付者のテンプレートの特定の方法を使用するのは、RECOMMENDEDです。 したがって、PLRはローカルのPLRアドレスへの送付者テンプレートにソースアドレスをはめ込むでしょう。 MPは、対応するS2LサブLSPsを特定するのにLSP-IDを使用しなければなりません。 MPは<Sub-グループOriginator IDを使用してはいけなくて、Sub-グループID>tupleはSub-グループOriginator IDが迂回によって迂回させられるいくらかのLSRによって変えられるかもしれないので対応するS2LサブLSPsを特定している間、トンネルを堀ります。 さらにS2LサブLSPを処理するために、LSP-IDとS2L_SUB_LSP物を使用して、MPは保護された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.
ノード保護が、PLRがデータ飛行機でできるブランチであることを必要とするかもしれないことに注意してください、複数の迂回トンネルが保護されたノードを通り抜けながらS2LサブLSPsのセットを支援するのに必要であるときに。 PLRがブランチできないなら、ここで説明されたノード保護メカニズムはまた保護されたノードを通り抜けるすべてのS2LサブLSPsが保護されたノードから川下にいる独身のMPを通り抜けるそれらのケースだけに適切です。 PLR MUSTは[RFC4090]の指定されるとしてのRRO/SRROのNode保護旗を設定しました。 PLRがブランチできないで、また1S2LサブLSPsがP2MP木に加えられて、これらのS2LサブLSPsが保護されたノードの既存のMP川下をどんなトランジットにもしないなら、PLR MUSTはこの旗をリセットしました。
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迂回トンネルを使用するための手順があります。
15.2. One-to-One Backup
15.2. 一対一バックアップ
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.
リンクと次のホップ失敗に対してサブLSPの特定のS2Lを保護するのに[RFC4090]で説明される1〜1つのバックアップは使用できます。 保護はPLRと次のホップの間のサブLSPsの1S2Lに使用されるかもしれません。 PLRと次のホップSHOULDの間のP2MPトンネルの同じ例に対応するすべてのS2LサブLSPsが同じP2MP LSPラベルを共有します、セクション5.2.1に従って。 P2MP LSP MUSTに属すそのようなすべてのS2LサブLSPs、保護されてください。
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
バックアップS2LサブLSPsはPLRで異なった次のホップを横断するかもしれません。 したがって、保護がいったん引き起こされると、出発しているラベルのセットとPLRのP2MP LSPのための次のホップは変化するかもしれません。 PLRとPLRの次のホップの間の単一の次のホップとラベルを使用しているP2MP LSPを考えてください。 保護がいったん引き起こされると、これはもうそうでないかもしれません。 これは、PLRがデータ飛行機でできるブランチであることを必要とするかもしれません。 PLRがブランチできないなら、ここで説明された1〜1つのバックアップメカニズムが単にすべてのバックアップS2LサブLSPsが同じ次のホップを川下に通り抜けるそれらのケースに適切です。
Aggarwal, et al. Standards Track [Page 32] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[32ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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.
PLRについて。 PLRができるブランチとすべてのバックアップS2LサブLSPsがいつ同じ川下の次のホップを通り抜けないかということでないときに、さらなる研究には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を特定するのに使用されるのは、お勧めです。 したがって、DETOUR、SHOULDは挿入されたコネがバックアップPathメッセージであったなら反対します。 AはLSP-IDによって指定されたものより異なったP2MPトンネル例に属すとして扱われた状態でS2LサブLSP MUSTのバックアップをとります。 その上、彼らが同じLSP-IDと同じDETOUR物を持っているなら、同じP2MPトンネル例の一部として複数のバックアップS2LサブLSPsを扱わなければなりません。 異なったP2MPトンネル例の間のサブLSPsのS2Lがセクション4で指定されるように異なったラベルを使用することに注意してください。
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メッセージのサブLSPの1S2Lしかなければ、DETOUR物はそのサブLSPに適用されます。 PathメッセージのサブLSPsの複数のS2Lがあれば、DETOUR物はすべてのS2LサブLSPsに適用されます。
16. Support for LSRs That Are Not P2MP Capable
16. できるP2MPでないLSRsのサポート
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".
多分、ネットワークにおけるいくつかのLSRsはP2MP拡張子が本書では説明した処理ができますが、データ飛行機で分岐するP2MPを支持しないでください。 そのようなLSRが受信されたPathメッセージでブランチLSRになるよう要求されるなら、PathErrメッセージがError Code「ルート設定誤り」を運んで、Error Valueが「分岐できない」状態で、それは応じなければなりません。
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.
また、いくつかのLSRsがP2MP能力を配備するネットワークで本書では説明された拡大を支持しないのが想像できます。 P2MP LSPの設立へのPathメッセージがそのようなLSRに達すると、それは、P2MP SESSION物の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拡張子をサポートしないLSRsはトランジットLSRsとしてLSPステッチ[LSP-STITCH]とLSP階層構造[RFC4206]の使用で本書では含まれるかもしれません。 ネットワーク(イングレス、ブランチまたは出口)におけるいかなる他の役割も果たさなければならないLSRsが本書では定義された拡大を支持しなければならないことに注意してください。
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
LSPステッチとLSP階層構造[RFC4206]の使用は、P2MP LSPsがそのような環境で造られるのを許容します。 P2P LSPセグメントはP2MPできる1日へのLSRが飛び越す川下にあるそれの遺産の最後の上流であるP2MPできるホップから合図されます。 これは、中間的遺産LSRsがトランジットLSRsであると仮定します: それらはP2MPブランチポイントとして機能できません。 このLSPセグメントに沿ったトランジットLSRsはP2MP LSPに関連している飛行機メッセージをどんな工程管理にもしません。 その上、これらのトランジットLSRsもP2MPデータを必要としません。
Aggarwal, et al. Standards Track [Page 33] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[33ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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.
P2P LSPセグメントに属しながらデータを処理するのが必要であるだけであるときに、能力を平らにしてください。 したがって、これらのトランジットLSRsはP2MP MPLSを支持する必要はありません。 このP2P LSPセグメントは入って来るP2MP LSPにステッチされます。 P2P LSPセグメントを確立した後に、指示されたPathメッセージとして次のP2MPできるLSRにP2MP Pathメッセージを送ります。 次の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サブLSPsは外側のP2P LSPの中で入れ子にされるかもしれません。 したがって、同じLSPセグメントの複数のP2MP LSPsの使用を可能にするのにラベルの積み重ねを使用できます。 問題と手順をステッチして、入れ子にするのは[LSP-STITCH]と[RFC4206]で、より詳しく説明されます。
There maybe overhead for an operator to configure the P2P LSP segments in advance, when it is desired to support legacy LSRs. It may be desirable to do this dynamically. The ingress can use IGP extensions to determine P2MP-capable LSRs [TE-NODE-CAP]. It can use this information to compute S2L sub-LSP paths such that they avoid legacy non-P2MP-capable LSRs. The explicit route object of an S2L sub-LSP path may contain loose hops if there are legacy LSRs along the path. The corresponding explicit route contains a list of objects up to the P2MP-capable LSR that is adjacent to a legacy LSR followed by a loose object with the address of the next P2MP-capable LSR. The P2MP-capable LSR expands the loose hop using its Traffic Engineering Database (TED). When doing this it determines that the loose hop expansion requires a P2P LSP to tunnel through the legacy LSR. If such a P2P LSP exists, it uses that P2P LSP. Else it establishes the P2P LSP. The P2MP Path message is sent to the next P2MP-capable LSR using non-adjacent signaling.
そこでは、あらかじめP2P LSPセグメントを構成するオペレータそれであるときに時多分オーバーヘッドが遺産LSRsを支持することが望まれています。 ダイナミックにこれをするのは望ましいかもしれません。 イングレスは、P2MPできるLSRs[TE-NODE-CAP]を決定するのにIGP拡張子を使用できます。 それがS2LサブLSP経路を計算するのにこの情報を使用できるので、それらは遺産できる非P2MP LSRsを避けます。 経路に沿って遺産LSRsがあれば、S2LサブLSP経路の明白なルート物はゆるいホップを含むかもしれません。 対応する明白なルートは物のリストをLSRが次のP2MPできるLSRのアドレスと共にゆるい物を続けた遺産に隣接しているP2MPできるLSRまで含んでいます。 P2MPできるLSRは、Traffic Engineering Database(TED)を使用することでゆるいホップを広げます。 これをするとき、それは、ゆるいホップ拡大が、P2P LSPが遺産LSRを通してトンネルを堀るのを必要とすることを決定します。 そのようなP2P LSPが存在しているなら、それはそのP2P LSPを使用します。 ほかに、それはP2P LSPを設立します。 非隣接しているシグナリングを使用することで次のP2MPできるLSRにP2MP Pathメッセージを送ります。
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は速い検出メカニズム([BFD]か[BFD-MPLS]などの)を次のP2MPのできるLSRに使わなければならないかもしれません。 保護されたノードが指示された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セグメントに沿った遺産LSRsがP2P LSPセグメントのテールのノード保護を実行できないことに注意してください。
17. Reduction in Control Plane Processing with LSP Hierarchy
17. LSP階層構造とのコントロール飛行機処理の減少
It is possible to take advantage of LSP hierarchy [RFC4206] while setting up P2MP LSP, as described in the previous section, to reduce control plane processing along transit LSRs that are P2MP capable. This is applicable only in environments where LSP hierarchy can be used. Transit LSRs along a P2P LSP segment, being used by a P2MP
LSP階層構造[RFC4206]を利用するのはP2MP LSPをセットアップしている間、可能です、できるP2MPであるトランジットLSRsに沿ってコントロール飛行機処理を抑えるために前項で説明されるように。 これはLSP階層構造を使用できるところで環境だけで適切です。 P2MPによって使用されるP2P LSPセグメントに沿ったトランジットLSRs
Aggarwal, et al. Standards Track [Page 34] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[34ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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セグメントの上でトンネルを堀られるとき、それらはこれらのメッセージを意識していません。 これはこれらのトランジットLSRsのときに必要であったコントロール飛行機処理の量を減少させます。
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 LSPsをセットアップできることに注意してください。 例えば、セクション24の図2では、PE1はP1にP2P LSPをセットアップして、LSPセグメントとしてそれを使用できます。 現在、LSPセグメントの上でPE3とPE4へのPathメッセージにトンネルを堀ることができます。 したがって、P3はP2MP LSPを意識していなくて、またP2MPコントロールメッセージを処理しません。
18. P2MP LSP Re-Merging and Cross-Over
18. P2MP LSP再合併とクロスオーバー
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のためのデータのすべてが受け取られている単一の入って来るインタフェースがあります。 入って来るインタフェースが特定される、_ID RSVP_HOPが存在しているなら反対して、Pathメッセージが受け取られたインタフェースのそばでそうする、_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のコースを変更するのと再マージの間で区別するか、またはケースの上で交差できる必要があります。
Aggarwal, et al. Standards Track [Page 35] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[35ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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分野値を持つので、2P2MP LSPsが異なった(しかし、関係づけられる)LSPsとして扱われるでしょう。
18.1. Procedures
18.1. 手順
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がある受信されたPathメッセージとそれぞれの局所的に維持されたP2MP LSP Path状態のSENDER_TEMPLATE物でSESSIONとSENDER_TEMPLATE物を比較することによって、特定されます。 SENDER_TEMPLATE物の送付者のP2MP ID、Tunnel ID、SESSION物のExtended Tunnel ID、アドレス、およびLSP IDは比較に使用されます。 ノードには合っている状態があって、受信されたPathメッセージのための入って来るインタフェースが合っているP2MP LSP Path状態の入って来るインタフェースと異なるなら、ノードは、それがダイナミックな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.)
合っているP2MP LSP Path状態に関連しているS2L_SUB_LSP物のセットとS2L_SUB_LSP物のセットの間には、受信されたPathメッセージにいくつかの交差点があるかをチェックすることによって、ダイナミックなLSPのコースを変更することは特定されます。 何か交差点があれば、ダイナミックなコースを変更することは起こりました。 2セットのS2L_SUB_LSP物の間には、交差点が全くなければ、どちらかが再合併するか、または交差するその時は起こりました。 (ダイナミックなLSPのコースを変更することの場合では、LSPsが合っているP2MP LSP Path状態に関連づけたS2L_SUB_のセットの非交差しているメンバーへの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 Path状態に関連している外向的なインタフェースを特定しなければなりません。 合っているP2MP LSP Path状態に関連している外向的なインタフェースのセットと外向的なインタフェースのセットの間には、受信されたPathメッセージに何か交差点があれば、再マージは起こりました。
18.1.1. Re-Merge Procedures
18.1.1. 手順を再合併してください。
There are two approaches to dealing with the re-merge case. In the first, the node detecting the re-merge case, i.e., the re-merge node, allows the re-merge case to persist, but data from all but one incoming interface is dropped at the re-merge node. In the second, the re-merge node initiates the removal of the re-merge branch(es) via signaling. Which approach is used is a matter of local policy.
再マージケースに対処することへの2つのアプローチがあります。 すなわち、再マージケースを検出する1番目、ノードの再マージノードで再マージケースは持続しますが、1つの入って来るインタフェース以外のすべてからのデータは再マージノードで落とされます。 2番目では、再マージノードはシグナリングで再マージブランチ(es)の取り外しを開始します。 どのアプローチが使用されているかは、ローカルの方針の問題です。
Aggarwal, et al. Standards Track [Page 36] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[36ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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状態に物を含んでいることの間の一貫性を有効にしなければなりません。 どんな矛盾も受信されたPathメッセージの前のホップに送られたPathErrメッセージをもたらさなければなりません。 Error Codeは「ルート設定問題」に用意ができています、そして、Error Valueは「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メッセージのコントロール状態。 明確に、上流の見解から上流から受け取られたメッセージの処理に関連する手順を変更してはいけません。 これは、タイムアウトをリフレッシュして、述べるために処理するのを関連していた状態で含んでいます。 標準の上流の関連する手順に加えて、ノードは、上流から受け取られた各物が川下に送られたPathメッセージのセットの中に適切に表されるのを確実にしなければなりません。 例えば、送信するPathメッセージのセットに受信された<S2LサブLSP記述子リスト>を含まなければなりません。 何か存在しているNOTIFY_REQUEST物があれば、すべてのPathとResvメッセージのためにセクション8で定義された手順に従わなければなりません。 また、特別な処理がResv処理に必要です。 明確に、受信されたPathメッセージの前のホップに送られる送信するResvメッセージに川下から受け取られたどんなResvメッセージも写像しなければなりません。 実際には、これは完全な<S2LサブLSP記述子リスト>を入って来るPathメッセージに合っている部分集合に分解して、次に、それぞれの入って来る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つ〜外向的なインタフェースにデータを送るだけでよいです。 すなわち、ノードは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
シグナリングで再マージブランチを修正するために構成されると、再マージノードは受信されたPathメッセージに対応するPathErrメッセージを送らなければなりません。 PathErrメッセージは通常、PathErrメッセージに含まれていた物のすべてを含まなければなりません、合っているP2MP LSP Path状態に関連しているサブLSPsのセットからの1個以上のS2L_SUB_LSP物と同様に。 最低3S2L_SUBは_LSPが、反対するRECOMMENDEDです。 これは再マージが州が有効な部分と交際した出発しているPathを特定したノードを許容するでしょう。
Aggarwal, et al. Standards Track [Page 37] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[37ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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.
P2MP LSP。 また、受信されたPathメッセージのS2L_SUB_LSP物のセットを含まなければなりません。 PathErrメッセージは「検出されたP2MP再マージ」のError Code「ルート設定問題」とError Valueを含まなければなりません。 ノードはPath_州_Removed旗[RFC3473]を設定するかもしれません。 いつものことだが、受信されたPathメッセージの前のホップにPathErrメッセージを送ります。
A node that receives a PathErr message that contains the Error Value "Routing Problem/P2MP Re-Merge Detected" MUST determine if it is the node that created the re-merge case. This is done by checking whether there is any intersection between the set of S2L_SUB_LSP objects associated with the matching P2MP LSP Path state and the set of other-branch S2L_SUB_LSP objects in the received PathErr message. If there is, then the node created the re-merge case. Other-branch S2L_SUB_LSP objects are those S2L_SUB_LSP objects included, by the node detecting the re-merge case, in the PathErr message that were taken from the matching P2MP LSP Path state. Such S2L_SUB_LSP objects are identifiable as they will not be included in the Path message associated with the received PathErr message. See section 11.1 for more details on how such an association is identified.
Error Value「検出されたルート設定P2MP再問題/マージ」を含むPathErrメッセージを受け取るノードは、それが再マージケースを引き起こしたノードであるかどうか決定しなければなりません。 合っているP2MP LSP Path状態に関連しているS2L_SUB_LSP物のセットと他のブランチS2L_SUB_LSP物のセットの間には、受信されたPathErrメッセージにいくつかの交差点があるかをチェックすることによって、これをします。 あれば、ノードは再マージケースを引き起こしました。 S2L_SUB_LSP物を含んでいて、他のブランチS2L_SUB_LSP物はそれらです、ノード検出による再マージケース、合っているP2MP LSP Path状態から受け取られた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.
ノードSHOULDは、_受信されたPathErrメッセージに関連しているPathメッセージで合っているP2MP LSP Path状態に関連している外向的なインタフェースにSUB_LSP物を含めて、S2Lを動かすことによって、再マージケースを取り外します。 そして、その外向的なインタフェースを通して動くS2L_SUB_LSP物への引き金のPathメッセージを送ります。 受信されたPathErrメッセージでPath_州_Removed旗を設定しなかったなら、ノードSHOULDは再マージブランチに関連している外向的なインタフェースを通して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規制に違反して、その時が関連出口を含むPathErrメッセージであり、どれか特定されたS2L_SUB_LSP物がSHOULDであるなら、「もたらされるEROは再合併する」Error Code「ルート設定問題」とError Valueと共に発生してください。
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メッセージの次の(リフレッシュするか、または引き金となります)伝達のときに修正されるでしょう。
Aggarwal, et al. Standards Track [Page 38] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[38ページ]RFC4875の拡張子をRSVP-Teに追跡します。
19. New and Updated Message Objects
19. 新しくてアップデートされたメッセージ物
This section presents the RSVP object formats as modified by this document.
このセクションは変更されるとしてのこのドキュメントによるRSVP物の形式を提示します。
19.1. SESSION Object
19.1. セッション物
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物は使用されています。 この物は既存のSESSION C-ヌムを使用します。 新しいC-タイプは、P2MPトンネルの論理的なP2MP目的地識別子に対応するために定義されます。 このSESSION物には、既存の二地点間RSVP-TE SESSIONが反対するように類似構造物があります。 しかしながら、送付先アドレスはユニキャストTunnel Endpointアドレスの代わりにP2MP IDに設定されます。 同じP2MP LSPの一部であるすべてのS2LサブLSPsが同じSESSION物を共有します。 このSESSION物は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を特定します。 これはP2P Tunnelを特定するのにSESSION物を使用するという既存のP2P RSVP-TE概念に従います。順番に、P2P Tunnelは複数のLSPs(ユニークなSENDER_TEMPLATE物によって区別されたそれぞれ)を含むことができます。
19.1.1. P2MP LSP Tunnel IPv4 SESSION Object
19.1.1. P2MP LSPトンネルIPv4セッション物
Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13
クラス=セッション、P2MP_LSP_トンネル_IPv4C-タイプ=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロでなければなりません。| トンネルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡張Tunnel ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P2MP ID
A 32-bit identifier used in the SESSION object that remains
constant over the life of the P2MP tunnel. It encodes the P2MP
Identifier that is unique within the scope of the ingress LSR.
P2MP IDのA32ビットの識別子はP2MPトンネルの人生の間、SESSION物でその残り定数を使用しました。 それはイングレスLSRの範囲の中でユニークなP2MP Identifierをコード化します。
Tunnel ID
A 16-bit identifier used in the SESSION object that remains
constant over the life of the P2MP tunnel.
P2MPトンネルの人生の間に一定のままで残っているSESSION物で使用されるIDのA16ビットの識別子にトンネルを堀ってください。
Aggarwal, et al. Standards Track [Page 39] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[39ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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.
拡張Tunnel ID A32ビットの識別子はP2MPトンネルの人生の間、SESSION物でその残り定数を使用しました。 P2MPトンネルSHOULDに、グローバルにユニークな識別子を持ちたがっているイングレスLSRsが彼らのトンネル送付者アドレスをここに置きます。 このアドレス、P2MP ID、およびTunnel IDの組み合わせはP2MPトンネルのためのグローバルにユニークな識別子を提供します。
19.1.2. P2MP LSP Tunnel IPv6 SESSION Object
19.1.2. P2MP LSPトンネルIPv6セッション物
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].
これはP2MP IPv4 LSP SESSIONが、違いで拡張トンネルIDが16バイトの識別子[RFC3209]に設定されるかもしれないのを反対するのと同じです。
Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14
クラス=セッション、P2MP_LSP_トンネル_IPv6C-タイプ=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) |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロでなければなりません。| トンネルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡張Tunnel ID(16バイト)| | | | ....... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19.2. SENDER_TEMPLATE Object
19.2. 送付者_テンプレート物
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を変えることができます。 したがって、異なったLSP IDと共にP2MPトンネルの複数の例をそれぞれ作成できます。 例は互いとリソースを共有できます。 特定の例に対応するS2LサブLSPsは同じ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で説明されるように、<Sub-グループID Originator IDを使用することによって同じP2MP LSPのために状態に合図するのに使用される異なったPathメッセージを区別するのが必要です、Sub-グループID>tuple。 SENDER_TEMPLATE物は、以下に示すようにこの情報を運ぶように変更されます。
Aggarwal, et al. Standards Track [Page 40] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[40ページ]RFC4875の拡張子をRSVP-Teに追跡します。
19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object
19.2.1. P2MP LSPトンネルIPv4送付者_テンプレート物
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12
クラス=送付者_テンプレート、P2MP_LSP_トンネル_IPv4C-タイプ=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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トンネル送付者アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| LSP ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブグループの創始者ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| サブグループID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel sender address
See [RFC3209].
IPv4は送付者アドレスSee[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.
サブGroup Originator ID Sub-グループOriginator IDはPathメッセージを溯源するLSRのTE Router IDに設定されます。 これは、それ自身のSubグループOriginator IDと共にPathメッセージを再溯源するイングレスLSRか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.
Pathメッセージに関するサブGroup ID An識別子は以前はよく同じP2MP LSPのために状態を示す複数のPathメッセージを微分していました。 これはこのPathメッセージで狙う1つ以上の出口ノードのグループを特定するのが見られるかもしれません。
LSP ID
See [RFC3209].
LSP IDは[RFC3209]を見ます。
Aggarwal, et al. Standards Track [Page 41] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[41ページ]RFC4875の拡張子をRSVP-Teに追跡します。
19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object
19.2.2. P2MP LSPトンネルIPv6送付者_テンプレート物
Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13
クラス=送付者_テンプレート、P2MP_LSP_トンネル_IPv6C-タイプ=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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トンネル送付者アドレス| + + | (16バイト) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| LSP ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | サブグループの創始者ID| + + | (16バイト) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| サブグループID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel sender address
See [RFC3209].
IPv6は送付者アドレスSee[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.
サブGroup Originator ID Sub-グループOriginator IDはPathメッセージを溯源するLSRのIPv6 TE Router IDに設定されます。 これは、それ自身のSub-グループOriginator IDでPathメッセージを再溯源するイングレスLSRかLSRのどちらかです。
Sub-Group ID
As above in section 19.2.1.
セクション19.2.1における上のサブGroup ID As。
LSP ID
See [RFC3209].
LSP IDは[RFC3209]を見ます。
Aggarwal, et al. Standards Track [Page 42] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[42ページ]RFC4875の拡張子をRSVP-Teに追跡します。
19.3. S2L_SUB_LSP Object
19.3. S2L_潜水艦_LSP物
An S2L_SUB_LSP object identifies a particular S2L sub-LSP belonging to the P2MP LSP.
S2L_SUB_LSP物は、P2MP LSPに属しながら、特定のS2LサブLSPを特定します。
19.3.1. S2L_SUB_LSP IPv4 Object
19.3.1. S2L_潜水艦_LSP IPv4物
S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = 1
S2L_潜水艦_LSPのクラスは50、S2L_潜水艦_LSP_IPv4C-タイプ=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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送付先アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Sub-LSP destination address
IPv4 address of the S2L sub-LSP destination.
S2LサブLSPの目的地のIPv4 Sub-LSP送付先アドレスIPv4アドレス。
19.3.2. S2L_SUB_LSP IPv6 Object
19.3.2. S2L_潜水艦_LSP IPv6物
S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = 2
S2L_潜水艦_LSPのクラスは50、S2L_潜水艦_LSP_IPv6C-タイプ=2と等しいです。
This is the same as the S2L IPv4 Sub-LSP object, with the difference that the destination address is a 16-byte IPv6 address.
これがS2L IPv4 Sub-LSPが反対するのと同じである、目的地が記述する違いと共に、16バイトのIPv6アドレスがあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 S2L Sub-LSP destination address (16 bytes) |
| .... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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送付先アドレス(16バイト)| | .... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19.4. FILTER_SPEC Object
19.4. フィルタ_仕様物
The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE object.
FILTER_SPEC物はP2MP SENDER_TEMPLATE物に正準です。
19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object
19.4.1. P2MP LSP_IPv4フィルタ_仕様物
Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12
クラス=フィルタ_仕様、P2MP LSP_IPv4C-タイプ=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物と同じです。
Aggarwal, et al. Standards Track [Page 43] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[43ページ]RFC4875の拡張子をRSVP-Teに追跡します。
19.4.2. P2MP LSP_IPv6 FILTER_SPEC Object
19.4.2. P2MP LSP_IPv6フィルタ_仕様物
Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13
クラス=フィルタ_仕様、P2MP LSP_IPv6C-タイプ=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物と同じです。
19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)
19.5. P2MPの二次_明白な_ルート物(SERO)
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 Object(SERO)はEROと同じであると定義されます。 P2MP SEROのクラスは[RFC4873]で定義されたSEROと同じです。 P2MP SEROは新しいC-タイプ=2を使用します。 サブ物はEROのために定義されたものと同じです。
19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO)
19.6. P2MPの二次_記録_ルート物(SRRO)
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 Object(SRRO)はEROと同じであると定義されます。 P2MP SRROのクラスは[RFC4873]で定義されたSRROと同じです。 P2MP SRROは新しいC-タイプ=2を使用します。 サブ物はRROのために定義されたものと同じです。
20. IANA Considerations
20. IANA問題
20.1. New Class Numbers
20.1. 新しいクラス番号
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はクラスが紹介した新しい物のために以下のClass民数記を割り当てました。 それぞれの彼らのためのClass Typesは規格動作で割り当てられることになっています。 P2MP SECONDARY_EXPLICIT_ROUTEとP2MP_SECONDARY_RECORD_ROUTEのためのサブオブジェクト・タイプはEROとRRO[RFC3209]のものと同じIANA問題に従います。
50 Class Name = S2L_SUB_LSP
_50クラス名前=S2L_潜水艦LSP
C-Type
1 S2L_SUB_LSP_IPv4 C-Type
2 S2L_SUB_LSP_IPv6 C-Type
1隻のS2L_潜水艦のC-タイプ_LSP_IPv4C-タイプ2S2L_潜水艦_LSP_IPv6C-タイプ
20.2. New Class Types
20.2. 新しいクラスタイプ
IANA has assigned the following C-Type values:
IANAは以下のC-タイプ値を割り当てました:
Class Name = SESSION
クラス名前=セッション
C-Type
13 P2MP_LSP_TUNNEL_IPv4 C-Type
14 P2MP_LSP_TUNNEL_IPv6 C-Type
C-タイプ13P2MP_LSP_トンネル_IPv4C-タイプ14P2MP_LSP_トンネル_IPv6C-タイプ
Aggarwal, et al. Standards Track [Page 44] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[44ページ]RFC4875の拡張子をRSVP-Teに追跡します。
Class Name = SENDER_TEMPLATE
クラス名前=送付者_テンプレート
C-Type
12 P2MP_LSP_TUNNEL_IPv4 C-Type
13 P2MP_LSP_TUNNEL_IPv6 C-Type
C-タイプ12P2MP_LSP_トンネル_IPv4C-タイプ13P2MP_LSP_トンネル_IPv6C-タイプ
Class Name = FILTER_SPEC
クラス名前=フィルタ_仕様
C-Type
12 P2MP LSP_IPv4 C-Type
13 P2MP LSP_IPv6 C-Type
C-タイプ12P2MP LSP_IPv4は13P2MP LSP_IPv6C-タイプをCでタイプします。
Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])
クラス=二次_明白な_名前ルート([RFC4873]では、定義されます)
C-Type
2 P2MP SECONDARY_EXPLICIT_ROUTE C-Type
C-タイプの二次_明白な_ルート2P2MP C-タイプ
Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])
クラス=二次_名前記録_ルート([RFC4873]では、定義されます)
C-Type
2 P2MP_SECONDARY_RECORD_ROUTE C-Type
C-タイプのP2MPの_の二次_記録_ルート2C-タイプ
20.3. New Error Values
20.3. 新しい誤り値
Five new Error Values are defined for use with the Error Code "Routing Problem". IANA has assigned values for them as follows.
5新しいError ValuesがError Code「ルート設定問題」との使用のために定義されます。 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.
「分岐できない」Error Valueは、報告しているLSRがP2MPブランチを形成できないのを示します。 IANAはこのError Valueに割り当てられた値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.
Error Value「サポートされないLSP保全」は、P2MPブランチが要求されたLSP保全機能をサポートしないのを示します。 IANAはこのError Valueに割り当てられた値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.
Error Value「検出されたP2MP再マージ」がノードが再マージを検出したのを示します。 IANAはこのError Valueに割り当てられた値25を持っています。
The Error Value "P2MP Re-Merge Parameter Mismatch" is described in section 18. IANA has assigned value 26 to this Error Value.
Error Value「P2MP再マージパラメタミスマッチ」はセクション18で説明されます。 IANAはこのError Valueに割り当てられた値26を持っています。
The Error Value "ERO Resulted in Re-Merge" is described in section 18. IANA has assigned value 27 to this Error Value.
Error Value「もたらされるEROは再合併すること」がセクション18で説明されます。 IANAはこのError Valueに割り当てられた値27を持っています。
Aggarwal, et al. Standards Track [Page 45] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[45ページ]RFC4875の拡張子をRSVP-Teに追跡します。
20.4. LSP Attributes Flags
20.4. LSP属性旗
IANA has been asked to manage the space of flags in the Attributes Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES object [RFC4420]. This document defines a new flag as follows:
IANAがLSP_REQUIRED_ATTRIBUTES物[RFC4420]で運ばれたAttributes Flags TLVの旗のスペースを管理するように頼まれました。 このドキュメントは以下の新しい旗を定義します:
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で以下に旗を揚げさせます。 このDocのReferencedセクションがありません: 5.2.4
21. Security Considerations
21. セキュリティ問題
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のSESSION物で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 MUSTの中のアプリケーションの仕様は別の業者によって提供されるアプリケーション実現と共に1つの業者からのイングレスLSRを使用できるという十分な詳細にこのメカニズムを指定します。 他のパラメタが自動発見されているとき、一般に、セキュリティパラメタの手動の構成は、IETF仕様に関するセキュリティと相互運用性必要条件を満たすために十分ではありません。
Aggarwal, et al. Standards Track [Page 46] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[46ページ]RFC4875の拡張子をRSVP-Teに追跡します。
22. Acknowledgements
22. 承認
This document is the product of many people. The contributors are listed in Appendix B.
このドキュメントは多くの人々の製品です。 貢献者はAppendix 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.
彼らの提案とコメントをヤコフRekhter、Der-Hwaガン、Arthi Ayyanger、およびNischal Shethをありがとうございます。 また、彼らのコメントをディーノFarninacciとベンジャミン・ニーヴンをありがとうございます。
23. References
23. 参照
23.1. Normative References
23.1. 引用規格
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
[RFC4206]Kompella(K.とY.Rekhter)は「一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学(Te)で切り換えられた経路(LSP)を階層構造とラベルします」、RFC4206、2005年10月。
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and
A. Ayyangar, "Encoding of Attributes for Multiprotocol
Label Switching (MPLS) Label Switched Path (LSP)
Establishment Using Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4420, February
2006.
[RFC4420]ファレル、A.(エド)、Papadimitriou、D.、Vasseur、J.-P.、およびA.Ayyangar、「(MPLS)がラベルするMultiprotocolラベルの切り換えのための属性のコード化は資源予約プロトコル交通工学(RSVP-Te)を使用することで経路(LSP)設立を切り換えました」、RFC4420、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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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の機能的な仕様」、RFC2205、1997年9月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3471] エドバーガー、L.、RFC3471、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は機能的な記述を示す」1月2003日
[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.、RFC3473、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は資源予約プロトコル交通工学(RSVP-Te)拡大を示す」1月2003日
Aggarwal, et al. Standards Track [Page 47] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[47ページ]RFC4875の拡張子をRSVP-Teに追跡します。
[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.、トンマージ、F.、およびS.Molendini、「RSVPは全般的な減少拡大をリフレッシュする」RFC2961(2001年4月)。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[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.Atlas(エド)は「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ります」、RFC4090、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)」、RFC3477、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セグメント回復」、RFC4873、2007年4月。
23.2. Informative References
23.2. 有益な参照
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-
to-Multipoint Traffic-Engineered MPLS Label Switched
Paths (LSPs)", RFC 4461, April 2006.
[RFC4461] エドYasukawa、S.、RFC4461、「ポイントの多点への交通で設計されたMPLSラベルの切り換えられた経路(LSPs)のための要件に合図すること」での4月2006日
[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] Aggarwal、R.、Kompella、K.、ナドー、T.、およびG.ツバメ、「MPLS LSPsのためのBFD」は進歩、2007年3月に働いています。
[LSP-STITCH] Ayyanger, A., Kompella, K., Vasseur, JP., and A.
Farrel, "Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering
(GMPLS TE)", Work in Progress, March 2007.
[LSP-ステッチ]Ayyanger(A.、Kompella、K.、Vasseur(JP)、およびA.ファレル)は「一般化されたMultiprotocolラベル切り換え交通工学(GMPLS Te)でステッチされる切り換えられた経路をラベルします」、処理中の作業、2007年3月。
[TE-NODE-CAP] Vasseur, JP., Ed., Le Roux, JL., Ed., "IGP Routing
Protocol Extensions for Discovery of Traffic
Engineering Node Capabilities", Work in Progress, April
2007.
[Teノードキャップ]Vasseur(JP)、エド、ル・ルー(JL)、エド「IGPは交通工学ノード能力の発見のためのプロトコル拡大を発送すること」での仕事が中で進歩をします、4月2007
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress
Control", RFC 4003, February 2005.
[RFC4003] バーガー、L.、「出口コントロールのためのGMPLSシグナリング手順」、RFC4003、2005年2月。
Aggarwal, et al. Standards Track [Page 48] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[48ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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.
Followingは本書では説明された手順を用いることでP2MP LSPをセットアップする1つの例です。
Source 1 (S1)
|
PE1
| |
|L5 |
P3 |
| |
L3 |L1 |L2
R2----PE3--P1 P2---PE2--Receiver 1 (R1)
| L4
PE5----PE4----R3
|
|
R4
ソース1(S1)| PE1| | |L5| P3| | | L3|L1|L2 R2----PE3--P1 P2---PE2--受信機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.
メカニズムは、図2を使用することで説明されます。 PE1はイングレスLSRです。 PE2、PE3、およびPE4は出口LSRsです。
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が時間内に異なったポイントで出口LSRsを知っていると思います。
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はPE2への<PE1、P2、PE2>に沿ったサブLSPのS2Lを設立します。
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経路を計算します。 この経路は、PE2へのサブLSPで可能であるところで同じP2MPセッションに属して同じリンクを共有するために計算されます。
e) PE1 establishes the S2L sub-LSP to PE3 along <PE1, P3, P1, PE3>.
e) PE1はPE3への<PE1、P3、P1、PE3>に沿ったサブLSPのS2Lを設立します。
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へのサブLSPsで可能であるところで同じリンクを共有するために計算されます。
g) PE1 signals the Path message for PE4 sub-LSP along <PE1, P3, P1,
PE4>.
g) PE1は<PE1、P3、P1、PE4>に沿ったサブLSPのPE4へのPathメッセージに合図します。
Aggarwal, et al. Standards Track [Page 49] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[49ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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を割り当てました。 それは、同じラベルを使用して、ResvメッセージをP3に送ります。 複数の流れ記述子が流れ記述子リストにある状態で1つのResvメッセージだけを送るかもしれないことに注意してください。 これがそうであり、FFスタイルが使用されていると、FF流れ記述子は2つのエントリーがあるS2LサブLSP記述子リストを含むでしょう: PE4のための1つとPE3のためのもう片方。 SEスタイルのために、SEフィルタ仕様はこのS2LサブLSP記述子リストを含むでしょう。 また、P1がラベルマッピングを作成する、(L1->、L3、L4) P3は既存のラベルL5を使用して、ラベルL5と共にResvメッセージをPE1に送ります。 それはL5->L1に関するラベルマッピングを再利用します。
Appendix B. Contributors
付録B.貢献者
John Drake Boeing EMail: john.E.Drake2@boeing.com
ジョンドレイクボーイングEMail: 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の有料道路の最初の床のSouthborough、MA 01772はメールされます: alan.kullberg@motorola.com
Lou Berger LabN Consulting, L.L.C. EMail: lberger@labn.net
ルウバーガーLabN Consulting、L.L.C.はメールされます: lberger@labn.net
Liming Wei Redback Networks 350 Holger Way San Jose, CA 95134 EMail: lwei@redback.com
ウェイRedbackに石灰をまくと、サンノゼ、カリフォルニア 95134がメールされる350オルガーWayはネットワークでつながれます: lwei@redback.com
George Apostolopoulos Redback Networks 350 Holger Way San Jose, CA 95134 EMail: georgeap@redback.com
ジョージApostolopoulos Redbackはサンノゼ、カリフォルニア 95134がメールされる350オルガーWayをネットワークでつなぎます: georgeap@redback.com
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: kireeti@juniper.net
Aveサニーベル、カリフォルニア 94089がメールするKireeti Kompella杜松ネットワーク1194N.マチルダ: kireeti@juniper.net
Aggarwal, et al. Standards Track [Page 50] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[50ページ]RFC4875の拡張子をRSVP-Teに追跡します。
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA EMail: swallow@cisco.com
ジョージツバメシスコシステムズInc.300ビーバーブルック道路Boxborough、MA--01719 米国メール: 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シスコシステムズInc.300ビーバーブルック道路Boxborough、MA--01719 米国メール: jpv@cisco.com ディーンチェンシスコシステムズInc.170Wタスマンサンノゼ博士(カリフォルニア)95134電話408 527 0677はメールされます: dcheng@cisco.com
Markus Jork Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 Phone: +1 978 964 2142 EMail: mjork@avici.com
N.ビルリカ、MA 01862が電話をするマーカスJork Avici Systems101ビルリカアベニュー: +1 2142年の978 964メール: mjork@avici.com
Hisashi Kojima NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6070 EMail: kojima.hisashi@lab.ntt.co.jp
久小島NTT社の9-11テロ、日本東京180-8585が電話をする美土里町の3丁目の武蔵野市: +81 422 59 6070はメールされます: kojima.hisashi@lab.ntt.co.jp
Andrew G. Malis Tellabs 2730 Orchard Parkway San Jose, CA 95134 Phone: +1 408 383 7223 EMail: Andy.Malis@tellabs.com
Parkwayサンノゼ、アンドリューG.Malis Tellabs2730Orchardカリフォルニア 95134は以下に電話をします。 +1 7223年の408 383メール: 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
Koji Sugisono NTT社の9-11テロ、日本東京180-8585が電話をする美土里町の3丁目の武蔵野市: +81 422 59 2605はメールされます: sugisono.koji@lab.ntt.co.jp
Aggarwal, et al. Standards Track [Page 51] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[51ページ]RFC4875の拡張子をRSVP-Teに追跡します。
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
将憲Uga NTT社の9-11テロ、日本東京180-8585が電話をする美土里町の3丁目の武蔵野市: +81 422 59 4804はメールされます: uga.masanori@lab.ntt.co.jp
Igor Bryskin Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102 ibryskin@movaz.com Adrian Farrel Old Dog Consulting Phone: +44 0 1978 860944 EMail: adrian@olddog.co.uk
イーゴリBryskin MovazはInc.7926ジョーンズ支店ドライブスイート615マクリーン・ヴァージニアをネットワークでつないで、22102 ibryskin@movaz.com エードリアン・ファレルは古い犬のコンサルティング電話です: +44 0 1978 860944はメールされます: adrian@olddog.co.uk
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: jeanlouis.leroux@francetelecom.com
ジャン・ルイル・ルーフランステレコム2、大通りピアー-Marzin22307Lannion CedexフランスEMail: jeanlouis.leroux@francetelecom.com
Editors' Addresses
エディタのアドレス
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: rahul@juniper.net
Rahul Aggarwal杜松は1194の北のマチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089はメールされます: rahul@juniper.net
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4769 EMail: yasukawa.seisho@lab.ntt.co.jp
Seisho Yasukawa NTT社の9-11テロ、日本東京180-8585が電話をする美土里町の3丁目の武蔵野市: +81 422 59 4769はメールされます: yasukawa.seisho@lab.ntt.co.jp
Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: Dimitri.Papadimitriou@alcatel-lucent.be
ディミトリPapadimitriouアルカテルフランシスWellesplein1、B-2018アントウェルペン(ベルギー)は以下に電話をします。 +32 3 240-8491 メールしてください: Dimitri.Papadimitriou@alcatel-lucent.be
Aggarwal, et al. Standards Track [Page 52] RFC 4875 Extensions to RSVP-TE for P2MP TE LSPs May 2007
Aggarwal、他 規格はTe LSPs2007年5月にP2MPのために[52ページ]RFC4875の拡張子をRSVP-Teに追跡します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Aggarwal, et al. Standards Track [Page 53]
Aggarwal、他 標準化過程[53ページ]
一覧
スポンサーリンク
