Network Working Group D. Thaler
Request for Comments: 3913 Microsoft
Category: Informational September 2004
Border Gateway Multicast Protocol (BGMP):
Protocol Specification
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports "source-specific multicast" (SSM). To also support "any-source multicast" (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants.
この文書では、ボーダーゲートウェイマルチキャストプロトコル（BGMP）、ドメイン間マルチキャストルーティングのためのプロトコルを記載しています。 BGMPは、アクティブなマルチキャストグループに対する共有ツリーを構築し、必要に応じてレシーバドメインが必要なソース固有のドメイン間、配信ブランチを構築することを可能にします。 BGMPはネイティブで「ソース固有のマルチキャスト」（SSM）をサポートしています。また、「任意のソースは、マルチキャスト」（ASM）をサポートするために、BGMPは、各マルチキャストグループは、単一のルート（BGMPでは、ルートドメインと呼ばれる）に関連付けられることを要求します。これは、マルチキャストアドレス空間の異なる範囲が異なるドメインで（ユニキャストプレフィックスベースのマルチキャストアドレッシングで、例えば）関連していることを必要とします。これらのドメインの各々は、その範囲内のすべてのグループの共有ドメインツリーのルートとなります。セッション開始者のアドレスアロケータは、それによってルートドメインは、セッション参加者の少なくとも一つにローカルであることを引き起こして、空間の独自のドメインの一部からアドレスを選択した場合、マルチキャスト参加者は、一般的に、より良いマルチキャストサービスを受信します。
Table of Contents
目次
1. Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Design Rationale . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Interaction with the EGP . . . . . . . . . . . . . . . . 8
4.2. Multicast Data Packet Processing . . . . . . . . . . . . 9
4.3. BGMP processing of Join and Prune messages and
notifications. . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Receiving Joins. . . . . . . . . . . . . . . . . 10
4.3.2. Receiving Prune Notifications. . . . . . . . . . 11
4.3.3. Receiving Route Change Notifications . . . . . . 12
4.3.4. Receiving (S,G) Poison-Reverse messages. . . . . 12
4.4. Interaction with M-IGP components. . . . . . . . . . . . 13
4.4.1. Interaction with DVMRP and PIM-DM. . . . . . . . 14
4.4.2. Interaction with PIM-SM. . . . . . . . . . . . . 15
4.4.3. Interaction with CBT . . . . . . . . . . . . . . 16
4.4.4. Interaction with MOSPF . . . . . . . . . . . . . 17
4.5. Operation over Multi-access Networks . . . . . . . . . . 17
4.6. Interaction between (S,G) state and G-routes . . . . . . 18
5. Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Message Header Format. . . . . . . . . . . . . . . . . . 19
5.2. OPEN Message Format. . . . . . . . . . . . . . . . . . . 19
5.3. UPDATE Message Format. . . . . . . . . . . . . . . . . . 23
5.4. Encoding examples. . . . . . . . . . . . . . . . . . . . 27
5.5. KEEPALIVE Message Format . . . . . . . . . . . . . . . . 27
5.6. NOTIFICATION Message Format. . . . . . . . . . . . . . . 28
6. BGMP Error Handling. . . . . . . . . . . . . . . . . . . . . . 30
6.1. Message Header error handling. . . . . . . . . . . . . . 30
6.2. OPEN message error handling. . . . . . . . . . . . . . . 30
6.3. UPDATE message error handling. . . . . . . . . . . . . . 31
6.4. NOTIFICATION message error handling. . . . . . . . . . . 32
6.5. Hold Timer Expired error handling. . . . . . . . . . . . 32
6.6. Finite State Machine error handling. . . . . . . . . . . 32
6.7. Cease. . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.8. Connection collision detection . . . . . . . . . . . . . 32
7. BGMP Version Negotiation . . . . . . . . . . . . . . . . . . . 33
7.1. BGMP Capability Negotiation. . . . . . . . . . . . . . . 34
8. BGMP Finite State machine. . . . . . . . . . . . . . . . . . . 34
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 41
It has been suggested that inter-domain "any-source" multicast is better supported with a rendezvous mechanism whereby members receive sources' data packets without any sort of global broadcast (e.g., MSDP broadcasts source information, PIM-DM [PIMDM] and DVMRP [DVMRP] broadcast initial data packets, and MOSPF [MOSPF] broadcasts membership information). PIM-SM [PIMSM] and CBT [CBT] use a shared group-tree, to which all members join and thereby hear from all sources (and to which non-members do not join and thereby hear from no sources).
メンバーがグローバル放送（例えば、MSDP放送ソース情報、PIMDM [PIMDM]とDVMRPの任意の並べ替えなしにソースのデータパケットを受信することにより、ドメイン間、「任意のソース」マルチキャストが良くランデブーメカニズムでサポートされていることが示唆されています[DVMRP]）初期データパケットをブロードキャストし、MOSPF [MOSPF]放送の会員情報。 PIMSMは[PIMSM]とCBTは、[CBT]すべてのメンバーが参加するグループ共有ツリーを使用することにより、すべてのソースから聞く（およびこれに非会員が参加せず、それによってないソースから聞きます）。
This document describes BGMP, a protocol for inter-domain multicast routing. BGMP natively supports "source-specific multicast" (SSM). To also support "any-source multicast" (ASM), BGMP builds shared trees for active multicast groups, and allows domains to build source-specific, inter-domain, distribution branches where needed. Building upon concepts from PIM-SM and CBT, BGMP requires that each global multicast group be associated with a single root. However, in BGMP, the root is an entire exchange or domain, rather than a single router.
この文書はBGMP、ドメイン間のマルチキャストルーティングのためのプロトコルを記述しています。 BGMPはネイティブで「ソース固有のマルチキャスト」（SSM）をサポートしています。また、「任意のソースマルチキャスト」（ASM）をサポートするために、BGMPは、アクティブなマルチキャストグループに対する共有ツリーを構築し、そして必要な場合ドメインはソース固有の、ドメイン間、配信ブランチを構築することを可能にします。 PIM-SMおよびCBTから概念に構築し、BGMP各グローバルマルチキャストグループは、単一のルートに関連付けられていることが必要です。しかし、BGMPで、根は全体の交換またはドメインではなく、単一のルータです。
For non-source-specific groups, BGMP assumes that ranges of the multicast address space have been associated (e.g., with Unicast-Prefix-Based Multicast [V4PREFIX,V6PREFIX] addressing) with selected domains. Each such domain then becomes the root of the shared domain-trees for all groups in its range. An address allocator will generally achieve better distribution trees if it takes its multicast addresses from its own domain's part of the space, thereby causing the root domain to be local.
非ソース固有のグループの場合、BGMPは、選択されたドメインと（アドレッシング[V6PREFIX、V4PREFIX]ユニキャストプレフィックスベースのマルチキャストを用いて、例えば）マルチキャストアドレス空間の範囲が関連付けられていることを前提としています。このような各ドメインは、その範囲内のすべてのグループの共有ドメインツリーのルートとなります。それは空間の独自のドメインの一部からそのマルチキャストアドレスを取る場合は、アドレスの割り当ては、一般的に、これにより、ルートドメインがローカルであることを引き起こして、より優れたディストリビューションツリーを実現します。
BGMP uses TCP as its transport protocol. This eliminates the need to implement message fragmentation, retransmission, acknowledgement, and sequencing. BGMP uses TCP port 264 for establishing its connections. This port is distinct from BGP's port to provide protocol independence, and to facilitate distinguishing between protocol packets (e.g., by packet classifiers, diagnostic utilities, etc.)
BGMPは、そのトランスポートプロトコルとしてTCPを使用しています。これは、メッセージの断片化、再送信、承認、およびシーケンシングを実装する必要がなくなります。 BGMPは、その接続を確立するためにTCPポート264を使用しています。このポートは、（パケット分類、診断ユーティリティ、等により、例えば）プロトコルの独立性を提供するために、プロトコル・パケットを区別容易にするために、BGPのポートから区別されます
Two BGMP peers form a TCP connection between one another, and exchange messages to open and confirm the connection parameters. They then send incremental Join/Prune Updates as group memberships change. BGMP does not require periodic refresh of individual entries. KeepAlive messages are sent periodically to ensure the liveness of the connection. Notification messages are sent in response to errors or special conditions. If a connection encounters an error condition, a notification message is sent and the connection is closed if the error is a fatal one.
二BGMPピアは、互いの間のTCP接続を形成し、交換メッセージは、接続パラメータを開いて確認します。そして、彼らはグループのメンバーシップが変更と/プルーンのアップデートに参加増分送ります。 BGMPは、個々のエントリの定期的な更新を必要としません。キープアライブメッセージは、接続の生存性を確保するために定期的に送信されます。通知メッセージは、エラーや特殊な状態に応答して送信されます。接続がエラー条件が発生した場合、通知メッセージが送信され、エラーが致命的なものであれば接続が閉じられています。
This document uses the following technical terms:
このドキュメントでは、次の技術用語を使用しています：
Domain: A set of one or more contiguous links and zero or more routers surrounded by one or more multicast border routers. Note that this loose definition of domain also applies to an external link between two domains, as well as an exchange.
ドメイン：1つの以上の連続したリンクと、1つまたは複数のマルチキャスト境界ルータに囲まれたゼロ個以上のルータのセット。ドメインのこの緩い定義はまた、二つのドメイン間の外部リンクと同様に、為替に適用されることに注意してください。
Root Domain: When constructing a shared tree of domains for some group, one domain will be the "root" of the tree. The root domain receives data from each sender to the group, and functions as a rendezvous domain toward which member domains can send inter-domain joins, and to which sender domains can send data.
ルートドメイン：いくつかのグループのためのドメインの共有ツリーを構築する場合、一つのドメインツリーの「ルート」になります。ルートドメインは、グループに各送信機からデータを受信し、会員ドメインはドメイン間に送信できる向かっランデブードメインとして機能する結合、及び送信元ドメインがデータを送信できます。
Multicast RIB: The Routing Information Base, or routing table, used to calculate the "next-hop" towards a particular address for multicast traffic.
マルチキャストRIB：ルーティング情報ベース、またはルーティングテーブルは、マルチキャストトラフィックの特定のアドレスに向かって、「次のホップ」を計算するために使用されます。
Multicast IGP (M-IGP): A generic term for any multicast routing protocol used for tree construction within a domain. Typical examples of M-IGPs are: PIM-SM, PIM-DM, DVMRP, MOSPF, and CBT.
マルチキャストIGP（M-IGP）：ドメイン内のツリー構築のために使用される任意のマルチキャストルーティングプロトコルの総称。 M-のIGPの典型的な例は、PIM-SM、PIM-DM、DVMRP、MOSPF、CBTと。
EGP: A generic term for the interdomain unicast routing protocol in use. Typically, this will be some version of BGP which can support a Multicast RIB, such as MBGP [MBGP], containing both unicast and multicast address prefixes.
EGP：使用中のドメイン間のユニキャストルーティングプロトコルの総称。典型的には、これは、ユニキャストおよびマルチキャストアドレスプレフィクスの両方を含む、そのようなMBGP [MBGP]としてマルチキャストRIBをサポートすることができるBGPのいくつかのバージョンであろう。
Component: The portion of a border router associated with (and logically inside) a particular domain that runs the multicast IGP (M-IGP) for that domain, if any. Each border router thus has zero or more components inside routing domains. In addition, each border router with external links that do not fall inside any routing domain will have an inter-domain component that runs BGMP.
成分：（論理的に内部など）に関連付けられた境界ルータがあれば、そのドメインのマルチキャストIGP（M-IGP）を実行し、特定のドメインの部分。各境界ルータは、このようにルーティングドメイン内のゼロまたはそれ以上の成分を有します。また、任意のルーティングドメイン内で該当しない外部リンクを持つ各境界ルータはBGMPを実行しているドメイン間のコンポーネントを持つことになります。
External peer: A border router in another multicast AS (autonomous system, as used in BGP), to which a BGMP TCP-connection is open. If BGP is being used as the EGP, a separate "eBGP" TCP-connection will also be open to the same peer.
外部ピア：BGMP TCP接続がオープンされている（BGPで使用されるような自律システム）などの別のマルチキャスト、中に境界ルータ。 BGPはEGPとして使用されている場合、別「のeBGP」TCP接続は、同じピアへ開放されます。
Internal peer: Another border router of the same multicast AS. If BGP is being used as the EGP, the border router either speaks iBGP ("internal" BGP) directly to internal peers in a full mesh, or indirectly through a route reflector [REFLECT].
内部ピア：AS同じマルチキャストの別の境界ルータ。 BGPは、EGP、境界ルータとして使用されるいずれかのiBGPを話している場合は直接フルメッシュで内部ピアに（BGP「内部」）、または間接的にルートリフレクタを介し[反映]。
Next-hop peer: The next-hop peer towards a given IP address is the next EGP router on the path to the given address, according to multicast RIB routes in the EGP's routing table (e.g., in MBGP, routes whose Subsequent Address Family Identifier field indicates that the route is valid for multicast traffic).
ネクストホップピア：指定されたIPアドレスに向かうネクストホップピアがMBGPでEGPのルーティングテーブル内のマルチキャストRIB経路（例えば、その次のアドレスファミリー識別子経路に従って、指定されたアドレスへの経路上の次のEGPルータでありますフィールドが）ルートがマルチキャストトラフィックのために有効であることを示しています。
target: Either an EGP peer, or an M-IGP component.
ターゲット：EGPピア、またはM-IGPの成分のいずれか。
Tree State Table: This is a table of (S-prefix,G) and (*,G-prefix) entries that have been explicitly joined by a set of targets. Each entry has, in addition to the source and group addresses and masks, a list of targets that have explicitly requested data (on behalf of directly connected hosts or downstream routers). (S,G) entries also have an "SPT" bit.
ツリー状態表：これは（S-接頭辞、G）のテーブルで、明示的にターゲットのセットで参加してきた（*、G-プレフィックス）のエントリー。各エントリには、ソースとグループアドレスとマスクに加えて、明示的に（直接接続されたホストまたは下流のルータに代わって）データを要求したターゲットのリストを持っています。 （S、G）エントリは、 "SPT" ビットを有しています。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [RFC2119].
[RFC2119]に記載されているようにキーワード "MUST" は、 "MUST NOT"、 "SHOULD NOT"、および本書で解釈されるべきである、 "MAY"、 "SHOULD"。
BGMP maintains group-prefix state in response to messages from BGMP peers and notifications from M-IGP components. Group-shared trees are rooted at the domain advertising the group prefix covering those groups. When a receiver joins a specific group address, the border router towards the root domain generates a group-specific Join message, which is then forwarded Border-Router-by-Border-Router towards the root domain (see Figure 1). BGMP Join and Prune messages are sent over TCP connections between BGMP peers, and BGMP protocol state is refreshed by KEEPALIVE messages periodically sent over TCP.
BGMPはM-IGPコンポーネントからBGMPピアや通知からのメッセージに応じて、グループプレフィックスの状態を維持します。グループ共有ツリーは、それらのグループをカバーするグループプレフィックスを広告するドメインに根ざしています。受信機は、特定のグループアドレスに参加するとき、ルートドメインに向かって境界ルータ（図1参照）をルートドメインに向けボーダールータ・バイ・ボーダールータに転送されるグループ固有の参加メッセージを生成します。 BGMP参加するとプルーンのメッセージはBGMPピア間のTCP接続を介して送信され、BGMPプロトコル状態が定期的にTCP経由で送信されるキープアライブメッセージによって更新されます。
BGMP routers build group-specific bidirectional forwarding state as they process the BGMP Join messages. Bidirectional forwarding state means that packets received from any target are forwarded to all other targets in the target list without any RPF checks. No group-specific state or traffic exists in parts of the network where there are no members of that group.
彼らはBGMP Joinメッセージを処理するようBGMPルータは、グループ固有の双方向フォワーディングステートを構築します。双方向転送状態は、任意のターゲットから受信したパケットは、任意のRPFチェックなしターゲットリスト内の他のすべてのターゲットに転送されることを意味します。いいえグループ固有の状態またはトラフィックは、そのグループのいかなるメンバーが存在しないネットワークの部分に存在しません。
BGMP routers optionally build source-specific unidirectional forwarding state, only where needed, to be compatible with source-specific trees (SPTs) used by some M-IGPs (e.g., DVMRP, PIM-DM, or PIM-SM), or to construct trees for source-specific groups. A domain that uses an SPT-based M-IGP may need to inject multicast packets from external sources via different border routers (to be compatible with the M-IGP RPF checks) which thus act as "surrogates". For example, in the Transit_1 domain, data from Src_A arrives at BR12, but must be injected by BR11. A surrogate router may create a source-specific BGMP branch if no shared tree state exists. Note: stub domains with a single border router, such as Rcvr_Stub_7 in Figure 1, receive all multicast data packets through that router, to which all RPF checks point. Therefore, stub domains never build source-specific state.
BGMPルータは、必要に応じて、いくつかのM-のIGP（例えば、DVMRP、PIM-DM、またはPIM-SM）によって使用されるソース特有ツリー（SPTは）と互換性があるように、または構築する場合にのみ必要で、ソース固有の一方向転送状態を構築しますソース固有のグループのための木。 SPTベースのM-IGPを使用するドメインは、このように「代理」として作用する（M-IGP RPFチェックに適合するように）異なる境界ルータを介して外部ソースからマルチキャストパケットを注入する必要があるかもしれません。例えば、Transit_1ドメインで、Src_AからのデータはBR12に到着したが、BR11で注射しなければなりません。何の共有ツリーの状態が存在しない場合は、代理ルータは、ソース特有のBGMPブランチを作成することができます。注：このような図1のRcvr_Stub_7ような単一のボーダールータとスタブドメインは、そのルータを介してすべてのマルチキャストデータパケットを受信し、すべてのRPFチェックが指しました。したがって、スタブドメインは、ソース固有の状態を構築することはありません。
Root_Domain
[BR91]--------------------------\
| |
[BR32] [BR41]
Transit_3 Transit_4
[BR31] [BR42] [BR43]
| | |
[BR22] [BR52] [BR53]
Transit_2 Transit_5
[BR21] [BR51]
| |
[BR12] [BR61]
Transit_1[BR11]----------[BR62]Stub_6
[BR13] (Src_A)
| (Rcvr_D)
-------------------
| |
[BR71] [BR81]
Rcvr_Stub_7 Src_only_Stub_8
(Rcvr_C) (Src_B)
Figure 1: Example inter-domain topology. [BRxy] represents a BGMP border router. Transit_X is a transit domain network. *_Stub_X is a stub domain network.
図1：例ドメイン間トポロジ。 【BRxy] BGMP境界ルータを表します。 Transit_Xはトランジットドメインネットワークです。 * _Stub_Xはスタブドメインネットワークです。
Data packets are forwarded based on a combination of BGMP and M-IGP rules. The router forwards to a set of targets according to a matching (S,G) BGMP tree state entry if it exists. If not found, the router checks for a matching (*,G) BGMP tree state entry. If neither is found, then the packet is sent natively to the next-hop EGP peer for G, according to the Multicast RIB (for example, in the case of a non-member sender such as Src_B in Figure 1). If a matching entry was found, the packet is forwarded to all other targets in the target list. In this way BGMP trees forward data in a bidirectional manner. If a target is an M-IGP component then forwarding is subject to the rules of that M-IGP protocol.
データパケットはBGMPとM-IGPルールの組み合わせに基づいて転送されます。マッチング（S、G）BGMPツリー状態のエントリが存在する場合に係る一連のターゲットへのルータ転送。見つからない場合は、マッチング（*、G）BGMPツリー状態エントリのルータをチェックします。どちらも見つからない場合、パケットは（図1にそのようなSrc_Bような非メンバー送信者の場合には、例えば、）マルチキャストRIBによれば、GのネクストホップEGPピアにネイティブに送られます。一致するエントリが見つかった場合、パケットは、ターゲットリスト内の他のすべてのターゲットに転送されます。双方向の方法でこのようにしてBGMP木前方データ。ターゲットがM-IGP成分がある場合、転送されたM-IGPプロトコルの規則の対象となります。
Several other protocols, or protocol proposals, build shared trees within domains [PIMSM, CBT]. The design choices made for BGMP result from our focus on Inter-Domain multicast in particular. The design choices made by PIM-SM and CBT are better suited to the wide-area intra-domain case. There are three major differences between BGMP and other shared-tree protocols:
いくつかの他のプロトコル、またはプロトコルの提案、ドメイン[PIMSM、CBT]内で共有ツリーを構築します。 BGMPのために作られた設計上の選択は、特にドメイン間のマルチキャストへの注力に起因します。 PIM-SMとCBTにより作られた設計上の選択は、広域ドメイン内のケースに適しています。 BGMPおよび他の共有ツリープロトコル間の三つの主要な違いがあります。
(1) Unidirectional vs. Bidirectional trees
（1）双方向木対一方向
Bidirectional trees (using bidirectional forwarding state as described above) minimize third party dependence which is essential in the inter-domain context. For example, in Figure 1, stub domains 7 and 8 would like to exchange multicast packets without being dependent on the quality of connectivity of the root domain. However, unidirectional shared trees (i.e., those using RPF checks) have more aggressive loop prevention and share the same processing rules as source-specific entries which are inherently unidirectional.
（上記のように双方向の転送状態を使って）双方向ツリーは、ドメイン間のコンテキストに必須であるサードパーティの依存性を最小限に抑えます。例えば、図1において、スタブ領域7及び8は、ルートドメインの接続性の品質に依存することなく、マルチキャストパケットを交換したいと思います。しかしながら、一方向共有ツリー（すなわち、RPFチェックを使用するもの）は、より積極的なループ防止を有し、本質的に一方向性であるソース固有のエントリと同じ処理ルールを共有します。
The lack of third party dependence concerns in the INTRA domain case reduces the incentive to employ bidirectional trees. BGMP supports bidirectional trees because it has to, and because it can without excessive cost.
INTRAドメインの場合は、サードパーティの依存性の懸念の欠如は、双方向の木を採用するインセンティブを減らします。 BGMPは、それが持っているので、双方向の木をサポートし、それが過度なコストをかけずにできるからです。
(2) Source-specific distribution trees/branches
（2）ソース固有配信ツリー/ブランチ
In a departure from other shared tree protocols, source-specific BGMP state is built ONLY where (a) it is needed to pull the multicast traffic down to a BGMP router that has source-specific (S,G) state, and (b) that router is NOT already on the shared tree (i.e., has no (*,G) state), and (c) that router does not want to receive packets via encapsulation from a router which is on the shared tree. BGMP provides source-specific branches because most M-IGP protocols in use today build source-specific trees. BGMP's source-specific branches eliminate the unnecessary overhead of encapsulations for high data rate sources from the shared tree's ingress router to the surrogate injector (e.g., from BR12 to BR11 in Figure 1). Moreover, cases in which shared paths are significantly longer than SPT paths will also benefit.
他の共有ツリープロトコルからの逸脱で、ソース固有BGMP状態（A）は、それがダウンソース固有の（S、G）状態を有するBGMPルータにマルチキャストトラフィックを引くために必要とされる場合にのみ構築され、及び（B）はそのルータは（つまり、何の（*、G）状態を持っていない）共有ツリーの上にまだ存在しないと、（c）そのルータは共有ツリー上にあるルータからのカプセル化を経由してパケットを受信したくありません。 BGMPは、今日使用されているほとんどのM-IGPプロトコルので、ソース固有の枝をソース特有の木を構築しています。 BGMPのソース固有の枝（図1において、例えば、BR12からBR11）にサロゲートインジェクタへの共有ツリーの入口ルータから高データレート・ソースのためのカプセル化の不要なオーバーヘッドをなくします。また、共有パスがSPTパスよりも有意に長いされた場合にも利益になります。
However, except for source-specific group distribution trees, we do not build source-specific inter-domain trees in general because (a) inter-domain connectivity is generally less rich than intra-domain connectivity, so shared distribution trees should have more acceptable path length and traffic concentration properties in the inter-domain context, than in the intra-domain case, and (b) by having the shared tree state always take precedence over source-specific tree state, we avoid ambiguities that can otherwise arise.
しかし、ソース固有のグループ配信木を除いて、（a）のドメイン間の接続は、一般的に、ドメイン内の接続よりも少ない豊富ですので、我々は、一般的には、ソース固有のドメイン間ツリーを構築していないので、共有配布ツリーは、より受け入れを持っている必要があります経路長及びトラフィック濃度特性のドメイン間コンテキストで、ドメイン内の場合よりも、（b）は共有ツリーの状態は常にソース特有ツリー状態よりも優先有することによって、我々は、そうでなければ発生する可能性が曖昧さを避けます。
In summary, BGMP trees are, in a sense, a hybrid between PIM-SM and CBT trees.
要約すると、BGMP木は、ある意味では、PIM-SMおよびCBT木の間のハイブリッドです。
(3) Method of choosing root of group shared tree
グループ共有ツリーのルートを選択する（3）方法
The choice of a group's shared-tree-root has implications for performance and policy. In the intra-domain case it is sometimes assumed that all potential shared-tree roots (RPs/Cores) within the domain are equally suited to be the root for a group that is initiated within that domain. In the INTER-domain case, there is far more opportunity for unacceptably poor locality, and administrative control of a group's shared-tree root. Therefore in the intra-domain case, other protocols sometimes treat all candidate roots (RPs or Cores) as equivalent and emphasize load sharing and stability to maximize performance. In the Inter-Domain case, all roots are not equivalent, and we adopt an approach whereby a group's root domain is not random but is subject to administrative control.
グループの共有ツリールートの選択は、性能や政策に影響を与えています。それは時々ドメイン内のすべての潜在的な共有ツリーの根（RPS /コア）と仮定されているドメイン内の場合にも同様に、そのドメイン内で開始されたグループのルートであることが適しています。 INTER-ドメインの場合は、許容できないほど貧しい地域のためにはるかに多くの機会、およびグループの共有ツリーのルートの管理制御があります。そのため、ドメイン内の場合には、他のプロトコルは、時々、同等のものとして、すべての候補の根（RPSまたはコア）を治療し、パフォーマンスを最大化するために、負荷分散と安定性を強調する。ドメイン間のケースでは、すべての根は同じではありません、と私たちは、グループのルートドメインがランダムではなく、管理制御の対象となるアプローチを採用します。
In this section, we describe the detailed protocol that border routers perform. We assume that each border router conforms to the component-based model described in [INTEROP], modulo one correction to section 3.2 ("BGMP" Dispatcher), as follows:
このセクションでは、境界ルータが行う詳細なプロトコルを記述します。次のように我々は、各ボーダルータは[INTEROP]に記載のコンポーネントベースのモデルに準拠していることを前提とし、セクション3.2にモジュロ一点の補正（「BGMP」ディスパッチャ）：
The iif owner of a (*,G) entry is the component owning the next-hop interface towards the nominal root of G, in the multicast RIB.
（*、G）エントリのIIFの所有者は、マルチキャストRIBにおけるGの名目上のルートに向かってネクストホップインターフェイスを所有する成分です。
The fundamental requirements imposed by BGMP are that:
BGMPによって課される基本的な要件は、次のとおりです。
(1) For a given source-specific group and source, BGMP must be able to look up the next-hop towards the source in the Multicast RIB, and
（1）所与のソース固有のグループおよびソースについて、BGMPマルチキャストRIBにソースに向かって次のホップをルックアップすることができなければならない、そして
(2) For a given non-source-specific group, BGMP will map the group address to a nominal "root" address, and must be able to look up the next-hop towards that address in the Multicast RIB.
（2）指定された非ソース固有のグループについて、BGMP公称「ルート」アドレスにグループアドレスがマッピングされ、およびマルチキャストRIB内のそのアドレスに向けて次のホップをルックアップすることができなければなりません。
BGMP determines the nominal "root" address as follows. If the multicast address is a Unicast-Prefix-based Multicast address, then the nominal root address is the embedded unicast prefix, padded with a suffix of 0 bits to form a full address.
次のようにBGMPは、名目上の「根」のアドレスを決定します。マルチキャストアドレスがユニキャストプレフィックスベースのマルチキャストアドレスである場合、公称ルートアドレスが埋め込まれたユニキャスト接頭語である、完全なアドレスを形成するために0ビットのサフィックスで埋め。
For example, if the IPv6 group address is ff2e:0100:1234:5678:9abc:def0::123, then the unicast prefix is 1234:5678:9abc:def0/64, and the nominal root address would be 1234:5678:9abc:def0::. (This address is in fact the subnet router anycast address [IPv6AA].)
例えば、IPv6のグループアドレスである場合ff2e：0100：5678：1234 9abc：5678：DEF0 :: 123は、その後、ユニキャストプレフィックスは1234 9abc：DEF0 / 64、および公称ルートアドレス1234のようになります。5678： 9abc：DEF0 ::。 （このアドレスは、実際には、サブネットルータエニーキャストアドレス[IPv6AA]です。）
Support for any-source-multicast using any address other than a Unicast-prefix-based Multicast Address is outside the scope of this document.
ユニキャストプレフィックスベースのマルチキャストアドレス以外のアドレスを使用して、任意のソース・マルチキャストのサポートは、この文書の範囲外です。
For BGMP rules to be applied, an incoming packet must first be "accepted":
BGMPルールが適用されるためには、着信パケットは、最初に「受け入れ」する必要があります。
o If the packet arrived on an interface owned by an M-IGP, the M-IGP component determines whether the packet should be accepted or dropped according to its rules. If the packet is accepted, the packet is forwarded (or not forwarded) out any other interfaces owned by the same component, as specified by the M-IGP.
パケットは、M-IGPによって所有インタフェースに到着した場合は、O、M-IGPコンポーネントは、パケットがその規則に従って受け入れまたは削除すべきかどうかを判断します。パケットが受け入れられた場合、パケットは、M-IGPによって指定されるように、転送（または転送しない）同じ成分が所有する他のインターフェースアウトされています。
o If the packet was received over a point-to-point interface owned by BGMP, the packet is accepted.
パケットがBGMPが所有するポイント・ツー・ポイント・インタフェースを介して受信された場合はO、パケットは受け入れられます。
o If the packet arrived on a multiaccess network interface owned by BGMP, the packet is accepted if it is receiving data on a source-specific branch, if it is the designated forwarder for the longest matching route for S, or for the longest matching route for the nominal root of G.
パケットがBGMPが所有するマルチアクセスネットワークインターフェースに到着した場合、それはソース固有ブランチ上でデータを受信している場合、それはSのための最長一致ルートの、または最長一致ルートの指定フォワーダである場合、O、パケットは受け入れられG.の名目ルートの
If the packet is accepted, then the router checks the tree state table for a matching (S,G) entry. If one is found, but the packet was not received from the next hop target towards S (if the entry's SPT bit is True), or was not received from the next hop target towards G (if the entry's SPT bit is False) then the packet is dropped and no further actions are taken. If no (S,G) entry was found, the router then checks for a matching (*,G) entry.
パケットが受け入れられた場合、ルータはマッチング（S、G）エントリのツリー状態テーブルをチェックします。 1が発見されていますが、パケットがSに向けて次のホップ先から受信されなかった（エントリーのSPTビットがTrueの場合）、または（エントリのSPTビットがFalseの場合）Gに向けて次のホップ先から受信されなかった場合、パケットが破棄され、それ以上のアクションは取られません。いいえ（S、G）エントリが見つからなかった場合、ルータは、次に、マッチング（*、G）エントリをチェック。
If neither is found, then the packet is forwarded towards the next-hop peer for the nominal root of G, according to the Multicast RIB. If a matching entry was found, the packet is forwarded to all other targets in the target list.
どちらが見つかった場合、そのパケットは、マルチキャストRIBによれば、Gの公称ルートのネクストホップピアに向けて転送されます。一致するエントリが見つかった場合、パケットは、ターゲットリスト内の他のすべてのターゲットに転送されます。
Forwarding to a target which is an M-IGP component means that the packet is forwarded out any interfaces owned by that component according to that component's multicast forwarding rules.
M-IGP成分であるターゲットに転送するパケットがそのコンポーネントのマルチキャスト転送ルールに従って、そのコンポーネントが所有するインターフェイスを転送されることを意味します。
When the BGMP component receives a (*,G) or (S,G) Join alert from another component, or a BGMP (S,G) or (*,G) Join message from an external peer, it searches the tree state table for a matching entry. If an entry is found, and that peer is already listed in the target list, then no further actions are taken.
BGMP成分は（*、G）または（S、G）は、他のコンポーネントからのアラートに参加し、又はBGMP（S、G）または（*、G）は、外部ピアからメッセージを参加受信すると、ツリーの状態テーブルを検索します一致するエントリのため。エントリが検出され、そのピアがすでにターゲットリストに表示されている場合は、それ以上のアクションは取られません。
Otherwise, if no (*,G) or (S,G) entry was found, one is created. In the case of a (*,G), the target list is initialized to contain the next-hop peer towards the nominal root of G, if it is an external peer. If the peer is internal, the target list is initialized to contain the M-IGP component owning the next-hop interface. If there is no next-hop peer (because the nominal root of G is inside the domain), then the target list is initialized to contain the next-hop component. If an (S,G) entry exists for the same G for which the (*,G) Join is being processed, and the next-hop peers toward S and the nominal root of G are different, the BGMP router must first send a (S,G) Prune message toward the source and clear the SPT bit on the (S,G) entry, before activating the (*,G) entry.
何（*、G）または（S、G）エントリが見つからなかった場合はそれ以外の場合は、1が作成されます。それは外部ピアである場合に（*、G）の場合には、ターゲットリストは、Gの公称ルートに向かってネクストホップピアを含むように初期化されます。ピアが内部である場合、ターゲットリストは、ネクストホップインターフェイスを所有M-IGP成分を含むように初期化されます。 （Gの公称ルートは、ドメイン内にあるため）は、ネクストホップピアが存在しない場合、ターゲットリストは、ネクストホップ成分を含むように初期化されます。 （S、G）エントリがどの（*、G）に参加するための処理、及びSに向かってネクストホップピアとGの名目上のルートが異なるされているのと同じGに存在する場合、BGMPルータは最初に送信する必要があります（S、G）ソースに向かってプルーンのメッセージと（*、G）エントリをアクティブにする前に、（S、G）エントリにSPTビットをクリアします。
When creating (S,G) state, if the source is internal to the BGMP speaker's domain, a "Poison-Reverse" bit (PR-bit) is set. This bit indicates that the router may receive packets matching (S,G) anyway due to the BGMP speaker being a member of a domain on the path between S and the root domain. (Depending on the M-IGP protocol, it may in fact receive such packets anyway only if it is the best exit for the nominal root of G.)
ソースはBGMP話者のドメインの内部にある場合、（S、G）ステートを作成する場合、「ポイズンリバース」ビット（PRビット）が設定されています。このビットは、ルータが原因BGMPスピーカーがSとルートドメインとの間の経路上のドメインのメンバであることにとにかくパケットマッチング（S、G）を受信することができることを示しています。 （M-IGPプロトコルに依存し、それは実際にはGの公称ルートのための最良の出口である場合にのみ、いずれにせよ、このようなパケットを受信することができます）
The target from which the Join was received is then added to the target list. The router then looks up S or the nominal root of G in the Multicast RIB to find the next-hop EGP peer. If the target list, not including the next-hop target towards G for a (*,G) entry, becomes non-null as a result, the next-hop EGP peer must be notified as follows:
参加が受信されたターゲットは、ターゲットリストに追加されます。その後、ルータは次のホップEGPピアを見つけるために、マルチキャストRIBにSを検索するか、Gの名目上のルート。ターゲットリストは、（*、G）エントリのGに向けて次ホップ対象を含むことは、結果として非ヌルになっていない場合、次のように、ネクストホップEGPピアに通知しなければなりません。
a) If the next-hop peer towards the nominal root of G (for a (*,G) entry) is an external peer, a BGMP (*,G) Join message is unicast to the external peer. If the next-hop peer towards S (for an (S,G) entry) is an external peer, and the router does NOT have any active (*,G) state for that group address G, a BGMP (S,G) Join message is unicast to the external peer. A BGMP (S,G) Join message is never sent to an external peer by a router that also contains active (*,G) state for the same group. If the next-hop peer towards S (for an (S,G entry) is an external peer and the router DOES have active (*,G) state for that group G, the SPT bit is always set to False.
エントリ（（*、G用）Gの公称ルートに向かってネクストホップピア）は、外部ピア、BGMP（*、G）である場合、A）Joinメッセージは、外部ピアへのユニキャストです。 （（S、G）エントリのための）Sに向かってネクストホップピアが外部ピアであり、ルータは、そのグループアドレスG、BGMP（S、G）のためのアクティブな（*、G）ステートを有していない場合Joinメッセージを外部ピアへのユニキャストです。 BGMP（S、G）Joinメッセージはまた、同じグループのためにアクティブ（*、G）ステートを含有するルータによって外部のピアに送信されることはありません。 （S、GエントリのSに向かうネクストホップピア（）外部ピアであり、ルータは、そのグループGのための活性（*、G）ステートを持っている場合、SPTビットは常にFalseに設定されています。
b) If the next-hop peer is an internal peer, a (*,G) or (S,G) Join alert is sent to the M-IGP component owning the next-hop interface.
B）ネクストホップピアが内部ピアである場合、（*、G）または（S、G）警告を参加ネクストホップインターフェイスを所有M-IGPコンポーネントに送られます。
c) If there is no next-hop peer, a (*,G) or (S,G) Join alert is sent to the M-IGP component owning the next-hop interface.
何ネクストホップピアが存在しない場合、C）、（*、G）または（S、G）は、警告を参加ネクストホップインターフェイスを所有M-IGPコンポーネントに送られます。
Finally, if an (S,G) Join is received from an internal peer, the peer should be stored with the M-IGP component target. If (S,G) state exists with the PR-bit set, and the next-hop towards the nominal root for G is through the M-IGP component, an (S,G) Poison-Reverse message is immediately sent to the internal peer.
（S、G）参加は、内部ピアから受信された場合に最後に、ピアはM-IGP成分ターゲットを保存しなければなりません。 （S、G）ステートがPRビットセットで存在し、Gの公称ルートに向かって次のホップがM-IGP成分によるものである場合、（S、G）ポイズンリバースメッセージは直ちに内部に送られます。ピア。
If an (S,G) Join is received from an external peer, and (S,G) state exists with the PR-bit set, and the local BGMP speaker is the best exit for the nominal root of G, and the next-hop towards the nominal root for G is through the interface towards the external peer, an (S,G) Poison-Reverse message is immediately sent to the external peer.
（S、G）が参加した場合、外部ピアから受信し、及び（S、G）状態がPRビットセットで存在し、ローカルBGMPスピーカーはGの公称ルートのための最良の出口であり、ネクストれますGの公称ルートは外部ピアに向かってインタフェースを介して行われ向かっ、（S、G）ポイズンリバースメッセージが直ちに外部のピアに送信されるホップ。
When the BGMP component receives a (*,G) or (S,G) Prune alert from another component, or a BGMP (*,G) or (S,G) Prune message from an external peer, it searches the tree state table for a matching entry. If no (S,G) entry was found for an (S,G) Prune, but (*,G) state exists, an (S,G) entry is created, with the target list copied from the (*,G) entry. If no matching entry exists, or if the component or peer is not listed in the target list, no further actions are taken.
BGMPコンポーネントが別のコンポーネント、またはBGMP（*、G）または（S、G）外部ピアからプルーンメッセージから（*、G）または（S、G）プルーン通知を受信すると、ツリーの状態テーブルを検索します一致するエントリのため。いいえ（S、G）エントリが見つからなかった場合は（S、G）プルーンが、（*、G）ステートが存在するため、（S、G）エントリが（*、G）からコピーされたターゲットリストと、作成されエントリ。一致するエントリが存在しない場合、コンポーネントまたはピアがターゲットリストに記載されていない場合、又は、それ以上のアクションは取られません。
Otherwise, the component or peer is removed from the target list. If the target list becomes null as a result, the next-hop peer towards the nominal root of G (for a (*,G) entry), or towards S (for an (S,G) entry if and only if the BGMP router does NOT have any corresponding (*,G) entry), must be notified as follows.
そうでなければ、コンポーネントまたはピアは、ターゲットリストから削除されます。 Gの公称ルートに向かってターゲットリストは、結果としてゼロになる場合、次ホップ・ピア（（*、G）エントリの場合）、またはSに向かって（（S、G）エントリの場合にのみBGMP場合ルータはどんな対応する（*、G）エントリを）持っていない、次のように、通知しなければなりません。
a) If the peer is an external peer, a BGMP (*,G) or (S,G) Prune message is unicast to it.
ピアが外部ピアの場合A）、BGMP（*、G）または（S、G）プルーンメッセージは、それへのユニキャストです。
b) If the next-hop peer is an internal peer, a (*,G) or (S,G) Prune alert is sent to the M-IGP component owning the next-hop interface.
B）ネクストホップピアが内部ピア、（*、Gである場合）または（S、G）プルーンアラートがネクストホップインターフェイスを所有M-IGPコンポーネントに送られます。
c) If there is no next-hop peer, a (*,G) or (S,G) Prune alert is sent to the M-IGP component owning the next-hop interface.
何ネクストホップピアが存在しない場合、C）、（*、G）または（S、G）プルーンアラートがネクストホップインターフェイスを所有M-IGPコンポーネントに送られます。
When a border router receives a route for a new prefix in the multicast RIB, or a existing route for a prefix is withdrawn, a route change notification for that prefix must be sent to the BGMP component. In addition, when the next hop peer (according to the multicast RIB) changes, a route change notification for that prefix must be sent to the BGMP component.
境界ルータは、マルチキャストRIBの新しいプレフィックスのルートを受信、またはプレフィックスのための既存のルートが引き抜かれると、そのプレフィックスのルート変更通知はBGMPコンポーネントに送信する必要があります。ネクストホップピア（マルチキャストRIBに応じて）が変化した場合に加えて、そのプレフィクスの経路変更通知がBGMPコンポーネントに送信されなければなりません。
In addition, in IPv4 (only), an internal route for each class-D prefix associated with the domain (if any) MUST be injected into the multicast RIB in the EGP by the domain's border routers.
また、IPv4の（のみ）で、ドメイン（存在する場合）に関連付けられた各クラスDのプレフィックスのための内部経路は、ドメインの境界ルータによってEGPにおけるマルチキャストRIBに注射しなければなりません。
When a route for a new group prefix is learned, or an existing route for a group prefix is withdrawn, or the next-hop peer for a group prefix changes, a BGMP router updates all affected (*,G) target lists. The router sends a (*,G) Join to the new next-hop target, and a (*,G) Prune to the old next-hop target, as appropriate. In addition, if any (S,G) state exists with the PR-bit set:
新しいグループプレフィクスのルートが学習されている場合、グループプレフィックスの既存のルートかが引き抜かれ、またはグループのプレフィックスの変更のためのネクストホップピアは、BGMPルータは、影響を受けるすべての（*、G）ターゲットリストを更新します。ルータは、必要に応じて、古いネクストホップ対象にプルーン（*、G）は、新たなネクストホップターゲット、および（*、G）に参加し送信します。また、任意の（S、G）ステートがPRビットセットに存在する場合：
o If the BGMP speaker has just become the best exit for the nominal root of G, an (S,G) Poison Reverse message with the PR-bit set is sent as noted below.
BGMPスピーカーがちょうどGの公称ルートのための最良の出口となっている場合は下記のようにO、PRビットがセットされた（S、G）ポイズンリバースメッセージが送信されます。
o If the BGMP speaker was the best exit for the nominal root of G and is no longer, an (S,G) Poison Reverse message with the PR-bit clear is sent as noted below.
BGMPスピーカーがGの公称ルートのための最良の出口た、もはやである場合、以下に述べたように、O、（S、G）クリアPRビットとポイズンリバースメッセージが送信されます。
The (S,G) Poison-Reverse messages are sent to all external peers on the next-hop interface towards the nominal root of G from which (S,G) Joins have been received.
（S、G）ポイズンリバースメッセージがそこからGの公称ルート（S、G）に向かう次ホップインターフェイス上のすべての外部ピアに送信され受信されたジョイン。
When an existing route for a source prefix is withdrawn, or the next-hop peer for a source prefix changes, a BGMP router updates all affected (S,G) target lists. The router sends a (S,G) Join to the new next-hop target, and a (S,G) Prune to the old next-hop target, as appropriate.
ソース・プレフィックスの既存のルートが取り下げ、またはソースプレフィックス変更のネクストホップピアである場合、BGMPルータは、影響を受けるすべての（S、G）ターゲットリストを更新します。ルータは（S、G）は、新たなネクストホップターゲットに参加して、（S、G）は、必要に応じて、古いネクストホップ対象にプルーン送信します。
When a BGMP speaker receives an (S,G) Poison-Reverse message from a peer, it sets the PR-bit on the (S,G) state to match the PR-bit in the message, and looks up the next-hop towards the nominal root of G. If the next-hop target is an M-IGP component, it forwards the (S,G) Poison Reverse message to all internal peers of that component from which it has received (S,G) Joins. If the next-hop target is an external peer on a given interface, it forwards the (S,G) Poison Reverse message to all external peers on that interface.
BGMPスピーカがピアからの（S、G）ポイズンリバースメッセージを受信すると、メッセージ内のPRビットと一致する（S、G）状態にPRビットをセットし、次のホップを調べG.公称ルートに向かって次のホップの目標は、それが（S、G）毒は、それが（S、G）を受信参加したから、そのコンポーネントのすべての内部ピアにメッセージを逆転送する、M-IGP成分である場合。ネクストホップ対象が所定のインターフェイスの外部ピアである場合、そのインターフェイス上のすべての外部ピアに（S、G）ポイズンリバースメッセージを転送します。
When a BGMP speaker receives an (S,G) Poison-Reverse message from an external peer, with the PR-bit set, and the speaker has received no (S,G) Joins from any other peers (e.g., only from the M-IGP, or has (S,G) state due to encapsulation as described in 5.4.1), it knows that its own (S,G) Join is unnecessary, and should send an (S,G) Prune.
BGMPスピーカーはPRビットセットで、外部ピアからの（S、G）ポイズンリバースメッセージを受信し、スピーカには（S、G）を受信していない唯一Mから他のピア（例えば、より参加したとき-IGP、または（S、G）により、5.4.1で説明したようにカプセル化状態）が、それ自身の（S、G）参加が不要であり、（S、G）プルーンを送るべきであることを知っています。
When a BGMP speaker receives an (S,G) Poison-Reverse message from an internal peer, with the PR-bit set, and the speaker is the best exit for the nominal root of G, and has (S,G) prune state, an (S,G) Join message is sent to cancel the prune state and the state is deleted.
BGMPスピーカーはPRビットを設定して（S、G）内部ピアからポイズンリバースメッセージを受信し、スピーカは、Gの公称ルートのための最良の出口であり、（S、G）プルーン状態を有する場合、（S、G）Joinメッセージがプルーン状態を解除するために送信され、状態が削除されています。
When an M-IGP component on a border router first learns that there are internally-reached members for a group G (whose scope is larger than that domain), a (*,G) Join alert is sent to the BGMP component. Similarly, when an M-IGP component on a border router learns that there are no longer internally-reached members for a group G (whose scope is larger than a single domain), a (*,G) Prune alert is sent to the BGMP component.
境界ルータ上のM-IGP成分は最初（スコープそのドメインより大きい）グループGのために内部に到達メンバーがあることを学習する場合、（*、G）は、警告を参加BGMPコンポーネントに送信されます。境界ルータ上のM-IGP成分が内部に到達部材（そのスコープ単一ドメインより大きい）グループGのためにもはや存在しないことを学習した場合に同様に、（*、G）プルーンアラートがBGMPに送られます成分。
At any time, any M-IGP domain MAY decide to join a source-specific branch for some external source S and group G. When the M-IGP component in the border router that is the next-hop router for a particular source S learns that a receiver wishes to receive data from S on a source-specific path, an (S,G) Join alert is sent to the BGMP component. When it is learned that such receivers no longer exist, an (S,G) Prune alert is sent to the BGMP component. Recall that the BGMP component will generate external source-specific Joins only where the source-specific branch does not coincide with the shared tree distribution tree for that group.
Sが学習特定のソースのネクストホップルータ境界ルータでのM-IGPコンポーネントであるときはいつでも、任意のM-IGPドメインは、いくつかの外部ソースSとグループGのソース固有の枝に参加することを決めることができます受信機は、ソース固有のパス上のSからデータを受信することを望むことが、（S、G）参加警告がBGMPコンポーネントに送信されます。それはそのような受信機がもはや存在しないことを知っている場合、（S、G）プルーンアラートがBGMPコンポーネントに送信されます。 BGMP成分はソース固有の分岐がそのグループの共有ツリー配信ツリーと一致しない場合にのみ外部ソース固有の結合を生成することを想起されたいです。
Finally, we will require that the border router that is the next-hop internal peer for a particular address S or the nominal root of G be able to forward data for a matching tree state table entry to all members within the domain. This requirement has implications on specific M-IGPs as follows.
最後に、我々が必要になり、その特定のアドレスSまたはGの公称ルートドメイン内のすべてのメンバーに一致するツリー状態テーブルエントリのデータを転送できるようにするためのネクストホップ内部ピアである境界ルータ。次のようにこの要件は、特定のM-のIGP上の意味を持っています。
DVMRP and PIM-DM are both "broadcast and prune" protocols in which every data packet must pass an RPF check against the packet's source address, or be dropped. If the border router receiving packets from an external source is the only BR to inject the route for the source into the domain, then there are no problems. For example, this will always be true for stub domains with a single border router (see Figure 1). Otherwise, the border router receiving packets externally is responsible for encapsulating the data to any other border routers that must inject the data into the domain for RPF checks to succeed.
DVMRPおよびPIM-DMは、「放送とプルーン、」すべてのデータパケットは、パケットの送信元アドレスに対してRPFチェックに合格しなければならない、または削除されているプロトコルを両方とも。外部ソースからのパケットを受信した境界ルータがドメインにソースのルートを注入するだけBRであれば、問題はありません。たとえば、これは常に（図1を参照）、単一の境界ルータとスタブドメインのtrueになります。それ以外の場合は、パケットを受信境界ルータは、外部からRPFチェックが成功するためには、ドメインにデータを挿入する必要があり、他の境界ルータにデータをカプセル化する責任があります。
When an intended border router injector for a source receives encapsulated packets from another border router in its domain, it should create source-specific (S,G) BGMP state. Note that the border router may be configured to do this on a data-rate triggered basis so that the state is not created for very low data-rate/intermittent sources. If source-specific state is created, then its incoming interface points to the virtual encapsulation interface from the border router that forwarded the packet, and it has an SPT flag that is initialized to be False.
ソースのための意図された境界ルータインジェクタは、そのドメイン内の他の境界ルータからカプセル化されたパケットを受信すると、ソース固有の（S、G）BGMP状態を作成する必要があります。境界ルータは、データ・レートでこれを行うために構成された状態が非常に低いデータレート/断続ソース用に作成されないように基礎をトリガすることができることに注意してください。ソース固有の状態が生成される場合にパケットを転送し、それが偽に初期化されたSPTフラグを有するボーダルータから仮想カプセル化インターフェースに、その着信インターフェイスポイント。
When the (S,G) BGMP state is created, the BGMP component will in turn send a BGMP (S,G) Join message to the next-hop external peer towards S if there is no (*,G) state for that same group, G. The (S,G) BGMP state will have the SPT bit set to False if (*,G) BGMP state is present.
（S、G）BGMP状態が作成されると、BGMP成分は、順番にBGMP（S、G）を送信することと同じには（*、G）ステートが存在しない場合Sに向かうネクストホップ外部ピアにメッセージを参加基、G.ザ（S、G）BGMP状態はSPTは（*、G）BGMP状態が存在する場合はFalseに設定ビットを有することになります。
When the first data packet from S arrives from the external peer and matches on the BGMP (S,G) state, and IF there is no (*,G) state, the router sets the SPT flag to True, resets the incoming interface to point to the external peer, and sends a BGMP (S,G) Prune message to the border router that was encapsulating the packets (e.g., in Figure 1, BR11 sends the (Src_A,G) Prune to BR12). When the border router with (*,G) state receives the prune for (S,G), it then deletes that border router from its list of targets.
Sから最初のデータパケットが外部ピアから到達しBGMP（S、G）状態に一致し、およびNO（*、G）ステートがない場合、ルータはTrueにSPTフラグを設定すると、への着信インターフェイスをリセット外部ピアをポイントし、（例えば、図1において、BR11は（Src_A、G）はBR12にプルーン送信）パケットをカプセル化した境界ルータにBGMP（S、G）プルーンメッセージを送信します。ボーダールータと（*、G）ステートが（S、G）のためのプルーンを受信すると、次に、ターゲットのリストから、その境界ルータを削除します。
If the decapsulator receives a (S,G) Poison Reverse message with the PR-bit set, it will forward it to the encapsulator (which may again forward it up the shared tree according to normal BGMP rules), and both will delete their BGMP (S,G) state.
カプセル開放装置は、PRビットがセットされた（S、G）ポイズンリバースメッセージを受信した場合、それは（再び前方にアップ通常BGMPルールに従って共有ツリーができる）、そして両方がそれらのBGMPが削除されますカプセル化にそれを転送します（S、G）状態。
PIM-DM and DVMRP present an additional problem, i.e., no protocol mechanism exists for joining and pruning entire groups; only joins and prunes for individual sources are available. As a result, BGMP does not currently support such protocols being used in a transit domain.
PIM-DMとDVMRP、すなわち、何のプロトコルメカニズムがグループ全体を接合し、剪定のために存在していない、追加の問題を提示します。唯一参加し、個々のソースのためのプルーンが用意されています。その結果、BGMPは現在、トランジットドメインで使用されているようなプロトコルをサポートしていません。
Protocols such as PIM-SM build unidirectional shared and source-specific trees. As with DVMRP and PIM-DM, every data packet must pass an RPF check against some group-specific or source-specific address.
このようPIM-SMなどのプロトコルでは、共有単方向とソース特有の木を構築します。 DVMRPおよびPIM-DMと同じように、すべてのデータパケットは、いくつかのグループ固有またはソース固有のアドレスに対してRPFチェックに合格する必要があります。
The fewest encapsulations/decapsulations will be done when the intra-domain tree is rooted at the next-hop internal peer (which becomes the RP) towards the nominal root of G, since in general that router will receive the most packets from external sources. To achieve this, each BGMP border router to a PIM-SM domain should send Candidate-RP-Advertisements within the domain for those groups for which it is the shared-domain tree ingress router. When the border router that is the RP for a group G receives an external data packet, it forwards the packet according to the M-IGP (i.e., PIM-SM) shared-tree outgoing interface list.
イントラドメインツリーはGの公称ルートに向かって（RPとなる）ネクストホップ内部ピアをルートとしたとき、一般に、そのルータは、外部ソースからの大部分のパケットを受信することになるので、最少カプセル化/ decapsulationsが行われます。これを達成するためには、PIM-SMドメインに各BGMP境界ルータは、それが共有ドメインツリー入口ルータであるため、それらのグループのドメイン内の候補-RP-広告を送信する必要があります。グループGのためのRPである境界ルータは、外部データ・パケットを受信すると、M-IGP（すなわち、PIM-SM）共有ツリー発信インターフェイスリストに従ってパケットを転送します。
Other border routers will receive data packets from external sources that are farther down the bidirectional tree of domains. When a border router that is not the RP receives an external packet for which it does not have a source-specific entry, the border router treats it like a local source by creating (S,G) state with a Register flag set, based on normal PIM-SM rules; the Border router then encapsulates the data packets in PIM-SM Registers and unicasts them to the RP for the group. As explained above, the RP for the inter-domain group will be one of the other border routers of the domain.
他の境界ルータは、ドメインの双方向ツリーの下遠くにある外部ソースからのデータパケットを受信します。 RPない境界ルータは、それがソース固有のエントリを持たないため、外部のパケットを受信した場合に、ボーダールータは基づいて、レジスタのフラグを設定して（S、G）ステートを作成することにより、ローカルソースと同じように扱わ通常のPIM-SMのルール。ボーダールータは、PIM-SMレジスタ内のデータ・パケットをカプセル化し、グループのRPにそれらをユニキャストします。以上説明したように、ドメイン間のグループのためのRPは、ドメインの他の境界ルータの1つであろう。
If a source's data rate is high enough, DRs within the PIM-SM domain may switch to the shortest path tree. If the shortest path to an external source is via the group's ingress router for the shared tree, the new (S,G) state in the BGMP border router will not cause BGMP (S,G) Joins because that border router will already have (*,G) state. If however, the shortest path to an external source is via some other border router, that border router will create (S,G) BGMP state in response to the M-IGP (S,G) Join alert. In this case, because there is no local (*,G) state to suppress it, the border router will send a BGMP (S,G) Join to the next-hop external peer towards S, in order to pull the data down directly. (See BR11 in Figure 1). As in normal PIM-SM operation, those PIM-SM routers that have (*,G) and (S,G) state pointing to different incoming interfaces will prune that source off the shared tree. Therefore, all internal interfaces may be eventually pruned off the internal shared tree.
元のデータレートが十分に高い場合、PIM-SMドメイン内のDRSは、最短パスツリーに切り替えることができます。外部ソースへの最短パスが共有ツリーのグループの入口ルータを経由する場合は、BGMP境界ルータの新（S、G）状態が（その境界ルータがすでにありますのでBGMP（S、G）が参加引き起こすことはありません*、G）ステート。しかし、外部ソースへの最短経路は、いくつかの他の境界ルータを介して行われる場合、その境界ルータは、警告を参加M-IGP（S、G）に応答して（S、G）BGMP状態を作成します。それを抑制するためにローカル（*、G）ステートが存在しないため、この場合には、ボーダールータは、ダウン直接データを取得するために、Sに向かう次ホップ外部ピアに参加BGMP（S、G）を送信します。 （図1のBR11を参照）。通常のPIM-SMの動作と同様に、異なる着信インターフェイスを指すものPIM-SMルータている（*、G）および（S、G）ステートを共有ツリーオフそのソースを剪定します。したがって、すべての内部インターフェイスは、最終的に内部共有ツリーをオフに剪定することができます。
After the border router sends a BGMP (S,G) Join, if its (S,G) state has the PR-bit clear, a (S,G) Poison-Reverse message (with the PR-bit clear) is sent to the ingress router for G. The ingress router then creates (S,G) if it does not already exist, and removes the next hop towards the nominal root of G from the target list.
ボーダールータはBGMP（S、G）加入を送信した後、その（S、G）ステートがPRビットクリア有する場合、（S、G）（クリアPRビットを有する）ポイズンリバースメッセージに送られますG.入口ルータの入口ルータは、それが存在しない場合（S、G）を作成し、ターゲットリストからGの公称ルートに向かって次のホップを除去します。
If the border router later receives an (S,G) Poison-Reverse message with the PR-bit set, the Poison-Reverse message is forwarded to the ingress router for G. The best-exit router then creates (S,G) state if it does not already exist, and puts the next hop towards the nominal root of G in the target list if not already present.
ボーダールータは後でPRビットがセットされた（S、G）ポイズンリバースメッセージを受信した場合、ポイズン・リバースメッセージがG.ベスト出口ルータの入口ルータに転送され、次いで（S、G）ステートを作成しますそれはすでに存在し、ターゲットリスト存在していない場合にはGの名目ルートに向けて次のホップを入れていない場合。
CBT builds bidirectional shared trees but must address two points of compatibility with BGMP. First, CBT can not accommodate more than one border router injecting a packet. Therefore, if a CBT domain does have multiple external connections, the M-IGP components of the border routers are responsible for insuring that only one of them will inject data from any given source.
CBTは、双方向の共有ツリーを構築しますが、BGMPとの互換性の二点に対処する必要があります。まず、CBTは、パケットを注入する複数の境界ルータに対応することはできません。 CBTドメインは、複数の外部接続を持っていない場合はそのため、境界ルータのM-IGPコンポーネントは、それらの一方のみが任意のソースからデータを注入することを保証する責任があります。
Second, CBT cannot process source-specific Joins or Prunes. Two options thus exist for each CBT domain:
第二に、CBTは、ソース固有の参加やプルーン処理することができません。二つのオプションは、このように各CBTドメインのために存在します：
Option A: The CBT component interprets a (S,G) Join alert as if it were an (*,G) Join alert, as described in [INTEROP]. That is, if it is not already on the core-tree for G, then it sends a CBT (*,G) JOIN-REQUEST message towards the core for G. Similarly, when the CBT component receives an (S,G) Prune alert, and the child interface list for a group is NULL, then it sends a (*,G) QUIT_NOTIFICATION towards the core for G. This option has the disadvantage of pulling all data for the group G down to the CBT domain when no members exist.
オプションA：[INTEROP]に記載されているようにCBT成分は、それが（*、G）であるかのように（S、G）は、アラート参加解釈は、アラートに参加。すなわち、G用コア木になっていない場合、それはCBT成分は（S、G）プルーンを受信する同様G.用コアに向かってCBT（*、G）に参加要求メッセージを送信し、あります警告、およびグループの子インタフェースリストは、それが送信し、NULLである（*、G）このオプションは、メンバーを持たないときCBTドメインにダウングループGのすべてのデータを引っ張っするという欠点があるG.ためのコアに向けてQUIT_NOTIFICATIONが存在します。
Option B: The CBT domain does not propagate any routes to their external peers for the Multicast RIB unless it is known that no other path exists to that prefix (e.g., routes for prefixes internal to the domain or in a singly-homed customer's domain may be propagated). This insures that source-specific joins are never received unless the source's data already passes through the domain on the shared tree, in which case the (S,G) Join need not be propagated anyway. BGMP border routers will only send source-specific Joins or Prunes to an external peer if that external peer advertises source-prefixes in the EGP. If a BGMP-CBT border router does receive an (S,G) Join or Prune, that border router should ignore the message.
オプションB：他のパスはその接頭辞（例えば、ドメインへの内部接頭辞または単独でホームの顧客のドメイン5月のルートに存在しないことが知られていない限りCBTドメインは、マルチキャストRIBのための彼らの外部ピアへのルートを伝播しません。 ）に伝播すること。これは、ソース固有のソースのデータが既に（S、G）は、とにかく伝播する必要はなく、参加した場合には共有ツリー上のドメインを通過しない限り、受信されることはありません参加することを保証します。その外部ピアはEGPでソース・プレフィックスを広告する場合BGMP境界ルータは、外部ピアにソース固有の参加やプルーンを送信します。 BGMP-CBT境界ルータは（S、G）Joinまたはプルーニングを受信した場合は、その境界ルータは、メッセージを無視すべきです。
To minimize en/de-capsulations, CBTv2 BR's may follow the same scheme as described under PIM-SM above, in which Candidate-Core advertisements are sent for those groups for which it is the shared-tree ingress router.
候補コア広告が、共有ツリー入口ルータであるため、それらのグループに対して送信された上記PIM-SM、下に記載されているように、EN /デcapsulationsを最小限に抑えるために、CBTv2 BRのは、同じスキームに従うことができます。
As with CBTv2, MOSPF cannot process source-specific Joins or Prunes, and the same two options are available. Therefore, an MOSPF domain may either:
CBTv2と同様に、MOSPFは、ソース固有の処理できない結合やプルーン、同じ2つのオプションが利用可能です。したがって、MOSPFドメインは、いずれかの可能性があります。
Option A: send a Group-Membership-LSA for all of G in response to a (S,G) Join alert, and "prematurely age" it out (when no other downstream members exist) in response to an (S,G) Prune alert, OR
オプションA：アラートの参加（S、G）に応じて、Gのすべてのグループ・メンバーシップ-LSAを送信し、（他の下流のメンバーが存在しない場合）（S、G）に応じて、それを「時期尚早時代」プルーンのアラート、OR
Option B: not propagate any routes to their external peers for the Multicast RIB unless it is known that no other path exists to that prefix (e.g., routes for prefixes internal to the domain or in a singly-homed customer's domain may be propagated)
オプションB：他の経路は、その接頭辞に存在しないことが知られていない限りマルチキャストRIBのためのそれらの外部ピアにルートを伝播しない（例えば、ドメインの内部または単独ホーム顧客のドメイン内のプレフィクスの経路が伝播されてもよいです）
Multiaccess links require special handling to prevent duplicates. The following mechanism enables BGMP to operate over multiaccess links which do not run an M-IGP. This avoids broadcast-and-prune behavior and does not require (S,G) state.
マルチアクセスリンクは重複を防ぐために特別な処理を必要とします。以下のようなメカニズムは、M-IGPを実行していないマルチアクセスリンクで動作するようにBGMPを可能にします。これは、ブロードキャスト・アンド・プルーン動作を回避し、（S、G）ステートを必要としません。
To elect a designated forwarder per prefix, BGMP uses a FWDR_PREF message to exchange "forwarder preference" values for each prefix. The peer with the highest forwarder preference becomes the designated forwarder, with ties broken by lowest BGMP Identifier. The designated forwarder is the router responsible for forwarding packets up the tree, and is the peer to which joins will be sent.
プレフィックスごと指定フォワーダを選出する、BGMPは各プレフィックスは、「フォワーダ優先」の値を交換するFWDR_PREFメッセージを使用します。最高フォワーダ好みにピアは最低BGMP識別子によって破壊関係で、指定されたフォワーダとなります。指定フォワーダは、ツリーを、パケットを転送する責任ルータであり、かつ加入が送信されますするピアです。
When BGMP first learns that a route exists in the multicast RIB whose next-hop interface is NOT the multiaccess link, the BGMP router sends a BGMP FWDR_PREF message for the prefix, to all BGMP peers on the LAN. The FWDR_PREF message contains a "forwarder preference value" for the local router, and the same value MUST be sent to all peers on the LAN. Likewise, when the prefix is no longer reachable, a FWDR_PREF of 0 is sent to all peers on the LAN.
BGMPは最初のルートは、そのネクストホップインターフェイスがマルチアクセスリンクではありませんマルチキャストRIBに存在することを学習すると、BGMPルータは、LAN上のすべてのBGMPピアに、プレフィックスのBGMP FWDR_PREFメッセージを送信します。 FWDR_PREFメッセージは、ローカルルータのための「フォワーダの優先値」が含まれ、同じ値は、LAN上のすべてのピアに送らなければなりません。プレフィックスはもはや到達可能でないとき同様に、0のFWDR_PREFは、LAN上のすべてのピアに送信されます。
Whenever a BGMP router calculates the next-hop peer towards a particular address, and that peer is reached over a BGMP-owned multiaccess LAN, the designated forwarder is used instead.
BGMPルータが特定のアドレスへのネクストホップピアを計算し、そのピアがBGMP所有のマルチアクセスLAN上に到達するたびに、指定されたフォワーダが代わりに使用されます。
When a BGMP router receives a FWDR_PREF message from a peer, it looks up the matching route in its multicast RIB, and calculates the new designated forwarder. If the router has tree state entries whose parent target was the old forwarder, it sends Joins to the new forwarder and Prunes to the old forwarder.
BGMPルータがピアからFWDR_PREFメッセージを受信すると、そのマルチキャストRIBに一致するルートを検索し、新たな指定フォワーダを計算します。ルータは、その親対象旧フォワーダだった、それが送信する古いフォワーダーに新しいフォワーダとプルーンに参加ツリーステートエントリを持っている場合。
When a BGMP router which is NOT the designated forwarder receives a packet on the multiaccess link, it is silently dropped.
指定フォワーダではありませんBGMPルータがマルチアクセスリンク上でパケットを受信すると、それは黙って落とされます。
Finally, this mechanism prevents duplicates where full peering exists on a "logical" link. Where full peering does not exist, steps must be taken (outside of BGMP) to present separate logical interfaces to BGMP, each of which is a link with full peering. This might entail, for example, using different link-layer address mappings, doing encapsulation, or changing the physical media.
最後に、このメカニズムは、完全なピアリングは「論理」リンク上に存在する重複を防ぐことができます。完全なピアが存在しない場合、手順は、完全なピアとのリンクであり、その各々は、BGMPに別個の論理インタフェースを提示する（BGMPの外側）に注意しなければなりません。これは、異なるリンク層アドレスのマッピングを使用してカプセル化を行う、または物理的なメディアを変える、例えば、伴うかもしれません。
As discussed earlier, routers with (*,G) state will not propagate (S,G) joins. However, a special case occurs when (S,G) state coincides with the G-route (or route towards the nominal root of G). When this occurs, care must be taken so that the data will reach the root domain without causing duplicates or black holes. For this reason, (S,G) state on the path between the source and the root domain is annotated as being "poison-reversed". A PR-bit is kept for this purpose, which is updated by (UN)POISON_REVERSE messages.
前述したように、（*、G）ステートを持つルータは（S、G）が加入伝播しないであろう。 （S、G）ステートがG-経路（又はGの公称ルートに向かってルート）と一致する場合しかし、特殊なケースが発生します。これが発生すると、データが重複またはブラックホールを生じることなく、ルートドメインに到達するように、注意を払わなければなりません。この理由のために、ソースとルートドメインとの間の経路上の（S、G）ステートを「ポイズン反転」であると注釈されています。 PRビットは（UN）POISON_REVERSEメッセージによって更新され、この目的のために保たれています。
The PR-bit indicates to BGMP nodes whether they need to forward packets up towards the root domain. For example, in a case where an (S,G) branch exists, a transit domain may get packets along the (S,G) branch, and needs to know whether to (also) forward them up towards the root domain. If the domain in question is on the path between S and the root domain, then the answer is yes (and the PR bit will be set on the S,G state). If the domain in question is not on the path between S and the root domain, then the answer is no (and the PR bit will be clear on the S,G state).
PRビットは、彼らがルートドメインに向けてパケットを転送する必要があるかどうかのノードをBGMPすることを示しています。例えば、（S、G）分岐が存在する場合には、トランジットドメインは、（S、G）の枝に沿ってパケットを取得し、（も）ルートドメインに向けてそれらを転送するかどうかを知る必要があります。問題のドメインはSとルートドメイン間のパス上にある場合、その答えはイエスである（とPRビットはS、G状態に設定されます）。問題のドメインはSとルートドメイン間のパス上にない場合は、答えはノーです（とPRビットはS、Gの状態に明らかであろう）。
This section describes message formats used by BGMP.
このセクションでは、BGMPで使用されるメッセージフォーマットを説明しています。
Messages are sent over a reliable transport protocol connection. A message is processed only after it is entirely received. The maximum message size is 4096 octets. All implementations are required to support this maximum message size.
メッセージは、信頼性の高いトランスポートプロトコル接続を介して送信されます。メッセージは、それが完全に受信された後にのみ処理されます。メッセージの最大サイズは4096オクテットです。すべての実装は、この最大メッセージサイズをサポートする必要があります。
All fields labelled "Reserved" below must be transmitted as 0, and ignored upon receipt.
以下の「予約済み」と表示されたすべてのフィールドは0として送信され、受信時に無視されなければなりません。
Each message has a fixed-size (4-byte) header. There may or may not be a data portion following the header, depending on the message type. The layout of these fields is shown below:
各メッセージは固定サイズ（4バイト）のヘッダを有します。またはメッセージタイプに応じて、ヘッダに続くデータ部分があってもなくてもよいです。これらのフィールドのレイアウトを以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: This 2-octet unsigned integer indicates the total length of the message, including the header, in octets. Thus, e.g., it allows one to locate in the transport-level stream the start of the next message. The value of the Length field must always be at least 4 and no greater than 4096, and may be further constrained, depending on the message type. No "padding" of extra data after the message is allowed, so the Length field must have the smallest value required given the rest of the message.
長さ：この2オクテットの符号なし整数をオクテット単位で、ヘッダを含むメッセージの全長を示します。従って、例えば、それは1つが、トランスポート・レベル・ストリーム内の次のメッセージの開始を見つけることを可能にします。 Lengthフィールドの値は常に4096よりも少なくとも4と大きくないなければならず、さらにメッセージの種類に応じて、拘束されてもよいです。余分なデータのない「パディングん」のメッセージが許可された後に、その長さフィールドは、メッセージの残り与えられた必要な最小値を持っている必要があります。
Type: This 1-octet unsigned integer indicates the type code of the message. The following type codes are defined:
タイプ：この1オクテットの符号なし整数は、メッセージのタイプコードを示します。以下のタイプコードが定義されています。
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
After a transport protocol connection is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged.
トランスポートプロトコル接続が確立された後、それぞれの側によって送信された最初のメッセージはオープンメッセージです。 OPENメッセージが許容される場合は、OPENを確認するKEEPALIVEメッセージが返送されます。 OPENが確認されると、UPDATE、KEEPALIVE、および通知メッセージを交換することができます。
In addition to the fixed-size BGMP header, the OPEN message contains the following fields:
固定サイズBGMPヘッダに加えて、OPENメッセージは、次のフィールドが含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Rsvd| AddrFam | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGMP Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: This 1-octet unsigned integer indicates the protocol version number of the message. The current BGMP version number is 1.
バージョン：この1オクテットの符号なし整数は、メッセージのプロトコルバージョン番号を示します。現在BGMPのバージョン番号は1です。
AddrFam: The IANA-assigned address family number of the BGMP Identifier. These include (among others):
AddrFam：BGMP識別子のIANAによって割り当てられたアドレスファミリ番号。これらは、（特に）次のとおりです。
Number Description
------ -----------
1 IP (IP version 4)
2 IPv6 (IP version 6)
Hold Time: This 2-octet unsigned integer indicates the number of seconds that the sender proposes for the value of the Hold Timer. Upon receipt of an OPEN message, a BGMP speaker MUST calculate the value of the Hold Timer by using the smaller of its configured Hold Time and the Hold Time received in the OPEN message. The Hold Time MUST be either zero or at least three seconds. An implementation may reject connections on the basis of the Hold Time. The calculated value indicates the maximum number of seconds that may elapse between the receipt of successive KEEPALIVE, and/or UPDATE messages by the sender.
ホールド時間：この2オクテットの符号なし整数は、送信者がホールドタイマーの値を提案している秒数を示します。 OPENメッセージを受信すると、BGMPスピーカは、その構成ホールド時間の小さく、OPENメッセージで受信されたホールド時間を使用して、ホールドタイマーの値を計算しなければなりません。ホールド時間がゼロまたは少なくとも3秒のいずれかでなければなりません。実装は、ホールド時間に基づいて接続を拒否することができます。算出された値は、送信者によって連続KEEPALIVEの受信、及び/又はUPDATEメッセージ間で経過することができる最大秒数を示しています。
BGMP Identifier: This 4-octet (for IPv4) or 16-octet (IPv6) unsigned integer indicates the BGMP Identifier of the sender. A given BGMP speaker sets the value of its BGMP Identifier to a globally-unique value assigned to that BGMP speaker (e.g., an IPv4 address). The value of the BGMP Identifier is determined on startup and is the same for every BGMP session opened.
BGMP識別子：この4オクテット（IPv4の場合）または16オクテット（IPv6）の符号なし整数は、送信者のBGMP識別子を示します。所与BGMPスピーカーはそのBGMPスピーカ（例えば、IPv4アドレス）に割り当てられたグローバルに一意の値にそのBGMP識別子の値を設定します。 BGMP識別子の値は、起動時に決定され、すべてのBGMPセッションが開かれたために同じです。
Optional Parameters: This field may contain a list of optional parameters, where each parameter is encoded as a <Parameter Length, Parameter Type, Parameter Value> triplet. The combined length of all optional parameters can be derived from the Length field in the message header.
オプションパラメータ：このフィールドは、各パラメータは、<パラメータ長、パラメータタイプ、パラメータ値>トリプレットとしてエンコードされたオプションのパラメータのリストが含まれていてもよいです。すべてのオプションパラメータの組み合わせた長さは、メッセージヘッダの長さフィールドから導出することができます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Type | Parm. Length | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Parameter Type is a one octet field that unambiguously identifies individual parameters. Parameter Length is a one octet field that contains the length of the Parameter Value field in octets. Parameter Value is a variable length field that is interpreted according to the value of the Parameter Type field.
パラメータタイプは明確に個々のパラメータを特定する1つのオクテットのフィールドです。パラメータ長は、オクテット単位でパラメータ値フィールドの長さを含む1つのオクテットのフィールドです。パラメータ値は、パラメータタイプフィールドの値に従って解釈される可変長フィールドです。
This document defines the following Optional Parameters:
このドキュメントでは、次のオプションパラメータを定義します。
a) Authentication Information (Parameter Type 1): This optional parameter may be used to authenticate a BGMP peer. The Parameter Value field contains a 1-octet Authentication Code followed by a variable length Authentication Data.
a）は、認証情報（パラメータタイプ1）：このオプションパラメータはBGMPピアを認証するために使用されてもよいです。パラメータ値フィールドは、可変長認証データに続く1オクテットの認証コードを含みます。
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Code:
認証コード：
This 1-octet unsigned integer indicates the authentication mechanism being used. Whenever an authentication mechanism is specified for use within BGMP, three things must be included in the specification:
この1オクテットの符号なし整数が使用される認証機構を示しています。認証機構がBGMP内で使用するために指定されるたびに、三つのことは、仕様に含まれている必要があります
- the value of the Authentication Code which indicates use of the mechanism, and - the form and meaning of the Authentication Data.
- 機構の使用を示し、および認証コードの値 - フォームと認証データの意味。
Note that a separate authentication mechanism may be used in establishing the transport level connection.
別の認証メカニズムは、トランスポートレベルの接続を確立する際に使用されてもよいことに留意されたいです。
Authentication Data:
認証データ：
The form and meaning of this field is a variable-length field depend on the Authentication Code.
このフィールドの形式と意味は認証コードに依存して可変長フィールドです。
The minimum length of the OPEN message is 12 octets (including message header).
OPENメッセージの最小の長さは、（メッセージヘッダーを含む）12オクテットです。
b) Capability Information (Parameter Type 2): This is an Optional Parameter that is used by a BGMP-speaker to convey to its peer the list of capabilities supported by the speaker. The parameter contains one or more triples <Capability Code, Capability Length, Capability Value>, where each triple is encoded as shown below:
b）のCapability情報（パラメータタイプ2）：これは、そのピアにスピーカーでサポートされている機能のリストを伝えるためにBGMPスピーカーで使用されるオプションのパラメータです。パラメーターは、一つ以上のトリプル以下に示すように、各トリプルが符号化された<機能コード、機能長、能力値>を、含まれています。
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
Capability Code:
能力コード：
Capability Code is a one octet field that unambiguously identifies individual capabilities.
能力コードは、明確に、個々の能力を特定する1つのオクテットのフィールドです。
Capability Length:
能力の長さ：
Capability Length is a one octet field that contains the length of the Capability Value field in octets.
能力の長さはオクテット単位で能力値フィールドの長さを含む1つのオクテットのフィールドです。
Capability Value:
能力値：
Capability Value is a variable length field that is interpreted according to the value of the Capability Code field.
能力値は、機能コード・フィールドの値に応じて解釈される可変長フィールドです。
A particular capability, as identified by its Capability Code, may occur more than once within the Optional Parameter.
特定の機能は、その能力コードにより識別されるように、任意パラメータ内で複数回発生する可能性があります。
This document reserves Capability Codes 128-255 for vendor-specific applications.
このドキュメントの埋蔵機能コードベンダー固有のアプリケーションのための128-255。
This document reserves value 0.
この文書では、値0を留保します。
Capability Codes (other than those reserved for vendor specific use) are assigned only by the IETF consensus process and IESG approval.
（ベンダー固有の使用のために予約以外の）機能コードのみIETFコンセンサスプロセスとIESG承認によって割り当てられます。
UPDATE messages are used to transfer Join/Prune/FwdrPref information between BGMP peers. The UPDATE message always includes the fixed-size BGMP header, and one or more attributes as described below.
UPDATEメッセージはBGMPピア間の結合/プルーン/ FwdrPref情報を転送するために使用されています。 UPDATEメッセージは常に固定サイズBGMPヘッダを含み、以下に説明するように1つまたは複数の属性。
The message format below allows compact encoding of (*,G) Joins and Prunes, while allowing the flexibility needed to do other updates such as (S,G) Joins and Prunes towards sources as well as on the shared tree. In the discussion below, an Encoded-Address-Prefix is of the form:
このような（S、G）のような他の更新を行うために必要な柔軟性を可能にしながら、以下のメッセージ・フォーマットは、ジョインとプルーン（G、*）のコンパクトな符号化を可能にする源に向かって、ならびに共有ツリーに参加し、プルーン。以下の議論では、エンコード・アドレス・プレフィックスの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+
|EnTyp| AddrFam |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EnTyp: 0 - All 1's Mask. The Mask field is 0 bytes long. 1 - Mask length included. The Mask field is 4 bytes long, and contains the mask length, in bits. 2 - Full Mask included. The Mask field is the same length as the Address field, and contains the full bitmask.
EnTyp：0 - すべて1のマスク。 Maskフィールドは0バイトの長さです。 1 - マスクの長さは含ま。マスクフィールドは、4バイト長であり、ビットで、マスクの長さを含んでいます。 2 - フルマスクが含まれています。 Maskフィールドは、アドレスフィールドと同じ長さで、フルビットマスクが含まれています。
AddrFam: The IANA-assigned address family number of the encoded prefix.
AddrFam：エンコードされたプレフィックスのIANAによって割り当てられたアドレスファミリ番号。
Address: The address associated with the given prefix to be encoded. The length is determined based on the Address Family.
住所：指定された接頭辞に関連付けられたアドレスをエンコードします。長さは、アドレスファミリに基づいて決定されます。
Mask: The mask associated with the given prefix. The format (or absence) of this field is determined by the EnTyp field.
マスク：指定された接頭辞に関連付けられたマスク。このフィールドのフォーマット（または不在）がEnTypフィールドによって決定されます。
Each attribute is of the form:
各属性の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All attributes are 4-byte aligned.
すべての属性4バイトが並んでいます。
Length: The Length is the length of the entire attribute, including the length, type, and data fields. If other attributes are nested within the data field, the length includes the size of all such nested attributes.
長さ：長さは、長さ、タイプ、およびデータ・フィールドを含む、属性全体の長さです。他の属性は、データ・フィールド内にネストされている場合、長さは、すべてのそのようなネストされた属性のサイズを含みます。
Type:
タイプ：
Types 128-255 are reserved for "optional" attributes. If a required attribute is unrecognized, a NOTIFICATION will be sent and the connection will be closed if the error is a fatal one. Unrecognized optional attributes are simply ignored.
タイプ128-255は、「オプション」の属性のために予約されています。必要な属性が認識されない場合は、通知が送信され、エラーが致命的なものであれば接続が閉じられます。認識されない任意の属性は、単に無視されます。
0 - JOIN 1 - PRUNE 2 - GROUP 3 - SOURCE 4 - FWDR_PREF 5 - POISON_REVERSE
0 - PRUNE 2 - - グループ3 - SOURCE 4 - FWDR_PREF 5 - POISON_REVERSE 1 JOIN
a) JOIN (Type Code 0)
A）に参加（タイプコード0）
The JOIN attribute indicates that all GROUP or SOURCE options nested immediately within the JOIN option should be joined.
JOINの属性すべてのGROUPまたはすぐ登録しよオプション内にネストされたSOURCEオプションが参加しなければならないことを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested within a JOIN attribute.
JOINを、PRUNE、またはFWDR_PREF属性はすぐ登録しよ属性内にネストすることはできないん。
b) PRUNE (Type Code 1)
B）PRUNE（タイプコード1）
The PRUNE attribute indicates that all GROUP or SOURCE attributes nested immediately within the PRUNE attribute should be pruned.
PRUNE属性は、PRUNE属性の中にすぐにネストされて、すべてのグループまたはSOURCE属性が剪定されなければならないことを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested within a PRUNE attribute.
JOINを、PRUNE、またはFWDR_PREF属性は、直ちにPRUNE属性内にネストすることはできないん。
c) GROUP (Type Code 2)
C）GROUP（タイプコード2）
The GROUP attribute identifies a given group-prefix. In addition, any attributes nested immediately within the GROUP attribute also apply to the given group-prefix.
GROUP属性が与えられたグループプレフィックスを識別します。また、グループ属性の中にすぐにネストされた任意の属性も与えられたグループプレフィクスに適用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Encoded-Address-Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoded-Address-Prefix The multicast group prefix to be joined to pruned, in the format described above. Nested Attributes No GROUP, SOURCE, or FWDR_PREF attributes may be immediately nested within a GROUP attribute.
エンコードされた・アドレス・プレフィックスマルチキャストグループのプレフィックスは、上述した形式で、プルーニングに結合されます。ネストされたなしGROUP、SOURCE属性ない、またはFWDR_PREF属性すぐGROUP属性内にネストすることができます。
d) SOURCE (Type Code 3):
D）SOURCE（タイプコード3）：
The SOURCE attribute identifies a given source-prefix. In addition, any attributes nested immediately within the SOURCE attribute also apply to the given source-prefix.
SOURCE属性が与えられたソース・プレフィックスを識別します。また、SOURCE属性の中にすぐにネストされた任意の属性も与えられたソース・プレフィックスに適用されます。
The SOURCE attribute has the following format:
SOURCE属性の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Encoded-Address-Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoded-Address-Prefix The Source-prefix in the format described above. Nested Attributes No GROUP, SOURCE, or FWDR_PREF attributes may be immediately nested within a SOURCE attribute.
エンコード・アドレス・プレフィックスは、上記の形式のソースプレフィックス。ネストされたなしGROUP、SOURCE属性ない、またはFWDR_PREF属性すぐSOURCE属性内にネストすることができます。
e) FWDR_PREF (Type Code 4)
E）FWDR_PREF（タイプコード4）
The FWDR_PREF attribute provides a forwarder preference value for all GROUP or SOURCE attributes nested immediately within the FWDR_PREF attribute. It is used by a BGMP speaker to inform other BGMP speakers of the originating speaker's degree of preference for a given group or source prefix. Usage of this attribute is described in 5.5.
FWDR_PREF属性は、直ちにFWDR_PREF属性内にネストされたすべてのグループまたはSOURCE属性のフォワーダの優先値を提供します。特定のグループまたはソース接頭辞の優先の元の話の学位の他BGMPスピーカーを知らせるためにBGMPスピーカーによって使用されます。この属性の使用方法は、5.5に記載されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preference Value A 32-bit non-negative integer. Nested Attributes No JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested within a FWDR_PREF attribute.
優先度値32ビットの負でない整数。ネストされたが、何のJOIN PRUNE属性ない、またはFWDR_PREFは、直ちにFWDR_PREF属性内にネストすることができる属性。
e) POISON_REVERSE (Type Code 5)
E）POISON_REVERSE（タイプコード5）
The POISON_REVERSE attribute provides a "poison-reverse" (PR-bit) value for all SOURCE attributes nested immediately within the POISON_REVERSE attribute. It is used by a BGMP speaker to inform other BGMP speakers from which it has received (S,G) Joins that they are on the path of domains between the source and the root domain.
POISON_REVERSE属性はPOISON_REVERSE属性の中にすぐにネストされた全てのソース属性の「ポイズンリバース」（PRビット）値を提供します。 （S、G）を受信し、それらがソースとルートドメインの間のドメインのパス上にあることを参加したから他のBGMPスピーカーを通知するBGMPスピーカーによって使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P The PR-bit value. Nested Attributes No attributes in the document other than SOURCE may be immediately nested within a POISON_REVERSE attribute.
Pザ・PRビットの値。ネストされたソース以外の文書のいかなる属性はすぐPOISON_REVERSE属性内にネストすることはできない属性。
Below are enumerated examples of how various updates are built using nested attributes, where A ( B ) denotes that attribute B is nested within attribute A.
下記（B）は、属性Bは属性A内にネストされていることを示し、ネストされた属性を使用して、様々な更新が構築される方法の例を列挙しています
(*,G-prefix) Join: JOIN ( GROUP ) (*,G-prefix) Prune: PRUNE ( GROUP ) (S,G) Join towards S : GROUP ( JOIN ( SOURCE ) ) (S,G) Join cancelling prune towards root of G: GROUP ( JOIN ( SOURCE ) ) (S,G) Prune towards S: GROUP ( PRUNE ( SOURCE ) ) (S,G) Prune towards root of G: GROUP ( PRUNE ( SOURCE ) ) Switch from (*,G) to (S,G): PRUNE ( GROUP ( JOIN ( SOURCE ) ) ) Switch from (S,G) to (*,G): JOIN ( GROUP ) Initial (*,G) Join with S pruned: JOIN ( GROUP ( PRUNE ( SOURCE ) ) ) Forwarder preference announcement for G-prefix: FWDR_PREF ( GROUP ) Forwarder preference announcement for S-prefix: FWDR_PREF ( SOURCE )
（*、G-プレフィックス）参加：（GROUP）JOIN（*、G-プレフィックス）プルーン：PRUNE（GROUP）（S、G）Sに向かって参加：グループ（JOIN（SOURCE））（S、G）プルーンを解除参加Gのルートに向かって：GROUP（（ソース）JOIN）（S、G）Sに向かってプルーン：GROUP（PRUNE（SOURCE））（S、G）はGのルートに向かってプルーン：GROUP（PRUNE（SOURCE））スイッチ（から* G）（S、G）：PRUNE（GROUP（登録しよう（SOURCE）は））に（S、G）（*、G）からスイッチ：剪定、JOIN（GROUP）初期（*、G）はSと結合：結合します（GROUP（PRUNE（SOURCE）））フォワーダ優先アナウンスG-プレフィックスの：S-プレフィックスのFWDR_PREF（GROUP）フォワーダ選好発表：FWDR_PREF（SOURCE）
BGMP does not use any transport protocol-based keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough as not to cause the Hold Timer to expire. A reasonable maximum time between the last KEEPALIVE or UPDATE message sent, and the time at which a KEEPALIVE message is sent, would be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more frequently than one per second. An implementation MAY adjust the rate at which it sends KEEPALIVE messages as a function of the Hold Time interval.
BGMPは、ピアが到達可能であるかどうかを判断するために、任意のトランスポート・プロトコルベースのキープアライブメカニズムを使用していません。代わりに、キープアライブメッセージは、ホールドタイマーが期限切れに生じないよう十分な頻度でピア間で交換されています。最後KEEPALIVEまたは送信UPDATEメッセージ、およびKEEPALIVEメッセージが送信される時刻との間の合理的な最大時間は、保留時間間隔の三分の一であろう。キープアライブメッセージは、毎秒1よりも頻繁に送ってはいけません。実装は、それが保持時間間隔の関数として、キープアライブメッセージを送信する速度を調整することができます。
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
ネゴシエートされた保留時間間隔がゼロであれば、定期的にキープアライブメッセージを送ってはいけません。
A KEEPALIVE message consists of only a message header, and has a length of 4 octets.
KEEPALIVEメッセージは、メッセージヘッダで構成され、4つのオクテットの長さを有しています。
A NOTIFICATION message is sent when an error condition is detected. The BGMP connection is closed immediately after sending it if the error is a fatal one.
エラー状態が検出されたときに通知メッセージが送信されます。 BGMP接続がエラーが致命的なものであれば、それを送信した直後に閉じられています。
In addition to the fixed-size BGMP header, the NOTIFICATION message contains the following fields:
固定サイズBGMPヘッダに加えて、通知メッセージは、次のフィールドが含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O| Error code | Error subcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O-bit: Open-bit. If clear, the connection will be closed. If set, indicates the error is not fatal.
Oビット：オープンビット。明確な場合は、接続が閉じられます。設定した場合、エラーが致命的ではないことを示します。
Error Code: This 1-octet unsigned integer indicates the type of NOTIFICATION. The following Error Codes have been defined:
エラーコード：この1オクテットの符号なし整数は、通知の種類を示します。以下のエラーコードが定義されています。
Error Code Symbolic Name Reference
エラーコードシンボリック名リファレンス
1 Message Header Error Section 9.1
1メッセージヘッダのエラー9.1節
2 OPEN Message Error Section 9.2
2 OPENメッセージエラー9.2節
3 UPDATE Message Error Section 9.3
3 UPDATEメッセージエラーセクション9.3
4 Hold Timer Expired Section 9.5
4ホールドタイマー期限切れのセクション9.5
5 Finite State Machine Error Section 9.6
5有限ステートマシンのエラーセクション9.6
6 Cease Section 9.7
6シーズセクション9.7
Error subcode: This 1-octet unsigned integer provides more specific information about the nature of the reported error. Each Error Code may have one or more Error Subcodes associated with it. If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field. The notation (MC) below indicates the error is a fatal one and the O-bit must be clear. Non-fatal subcodes SHOULD be sent with the O-bit set.
エラーサブコード：この1オクテットの符号なし整数は、報告されたエラーの性質についてのより具体的な情報を提供します。各エラーコードは、それに関連する1つのまたは複数のエラーサブコードを有することができます。いかなる適切なエラーサブコードが定義されていない場合、ゼロ（非特異的）値は、エラーサブコードフィールドに使用されます。以下の表記法（MC）は、エラーが致命的な一つであり、O-ビットがクリアでなければならない示します。非致命的なサブコードは、Oビットのセットで送ってください。
Message Header Error subcodes:
メッセージヘッダのエラーサブコード：
2 - Bad Message Length (MC)
3 - Bad Message Type (MC)
OPEN Message Error subcodes:
OPENメッセージエラーサブコード：
1 - Unsupported Version (MC)
4 - Unsupported Optional Parameter
5 - Authentication Failure (MC)
6 - Unacceptable Hold Time (MC)
7 - Unsupported Capability (MC)
UPDATE Message Error subcodes:
UPDATEメッセージエラーサブコード：
1 - Malformed Attribute List (MC) 2 - Unrecognized Attribute Type 5 - Attribute Length Error (MC) 10 - Invalid Address 11 - Invalid Mask 13 - Unrecognized Address Family Data: This variable-length field is used to diagnose the reason for the NOTIFICATION. The contents of the Data field depend upon the Error Code and Error Subcode. See Section 7 below for more details.
1 - 不正な形式の属性リスト（MC）2 - 認識できない属性タイプ5 - 属性の長エラー（MC）10 - 無効なアドレス11 - 無効なマスク13 - 認識されないアドレスファミリデータ：この可変長フィールドには、通知の理由を診断するために使用されます。データフィールドの内容は、エラーコードとエラーサブコードに依存しています。詳細については、下記のセクション7を参照してください。
Note that the length of the Data field can be determined from the message Length field by the formula:
データフィールドの長さが、式によって、メッセージ長フィールドから決定することができることに留意されたいです。
Message Length = 6 + Data Length
メッセージ長= 6 +データ長
The minimum length of the NOTIFICATION message is 6 octets (including message header).
通知メッセージの最小の長さは、（メッセージヘッダーを含む）6つのオクテットです。
This section describes actions to be taken when errors are detected while processing BGMP messages. BGMP Error Handling is similar to that of BGP [BGP].
このセクションでは、BGMPメッセージの処理中にエラーが検出されたときに取るべきアクションについて説明します。 BGMPエラー処理は、BGP [BGP]と同様です。
When any of the conditions described here are detected, a NOTIFICATION message with the indicated Error Code, Error Subcode, and Data fields is sent, and the BGMP connection is closed if the error is a fatal one. If no Error Subcode is specified, then a zero must be used.
ここに記載のいずれかの条件が検出されると、指示されたエラーコード、エラーサブコード、及びデータフィールドを持つ通知メッセージが送信され、エラーが致命的なものであればBGMP接続が閉じられます。何のエラーサブコードが指定されていない場合は、ゼロを使用する必要があります。
The phrase "the BGMP connection is closed" means that the transport protocol connection has been closed and that all resources for that BGMP connection have been deallocated. The remote peer is removed from the target list of all tree state entries.
フレーズが「閉じているBGMP接続は、」トランスポートプロトコル接続が閉じられたことと、そのBGMP接続用のすべてのリソースの割り当てが解除されていることを意味します。リモートピアは、すべてのツリーステートエントリのターゲットリストから削除されます。
Unless specified explicitly, the Data field of the NOTIFICATION message that is sent to indicate an error is empty.
明示的に指定しない限り、エラーを示すために送信される通知メッセージのデータフィールドは空です。
All errors detected while processing the Message Header are indicated by sending the NOTIFICATION message with Error Code Message Header Error. The Error Subcode elaborates on the specific nature of the error.
メッセージヘッダを処理している間に検出されたすべてのエラーは、エラーコードメッセージヘッダエラーでNOTIFICATIONメッセージを送ることによって示されています。エラーサブコードはエラーの特定の性質について詳しく説明します。
If the Length field of the message header is less than 4 or greater than 4096, or if the Length field of an OPEN message is less than the minimum length of the OPEN message, or if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or if the Length field of a KEEPALIVE message is not equal to 4, then the Error Subcode is set to Bad Message Length. The Data field contains the erroneous Length field.
メッセージヘッダの長さフィールドには4096より4以上より小さい場合、又はOPENメッセージの長さフィールドは、オープンメッセージの最小長さより小さい場合、又はUPDATEメッセージの長さフィールドがより小さい場合UPDATEメッセージの最小の長さ、またはKEEPALIVEメッセージの長さフィールドは4に等しくない場合、エラーサブコードはバートメッセージ長に設定されています。データフィールドは誤った長さフィールドが含まれています。
If the Type field of the message header is not recognized, then the Error Subcode is set to Bad Message Type. The Data field contains the erroneous Type field.
メッセージヘッダのTypeフィールドが認識されない場合は、エラーサブコードはバートメッセージタイプに設定されています。データフィールドは誤ったTypeフィールドが含まれています。
All errors detected while processing the OPEN message are indicated by sending the NOTIFICATION message with Error Code OPEN Message Error. The Error Subcode elaborates on the specific nature of the error.
OPENメッセージの処理中に検出されたすべてのエラーはエラーコードOPENメッセージエラーと通知メッセージを送信することにより示されています。エラーサブコードはエラーの特定の性質について詳しく説明します。
If the version number contained in the Version field of the received OPEN message is not supported, then the Error Subcode is set to Unsupported Version Number. The Data field is a 2-octet unsigned integer, which indicates the largest locally supported version number less than the version the remote BGMP peer bid (as indicated in the received OPEN message).
受信OPENメッセージのバージョンフィールドに含まれているバージョン番号がサポートされていない場合は、エラーサブコードはサポートされていないバージョン番号に設定されています。データフィールドは、バージョンリモートBGMPピア入札（受信したオープンメッセージに示されるように）よりも小さい最大ローカルサポートされるバージョン番号を示す2オクテットの符号なし整数です。
If the Hold Time field of the OPEN message is unacceptable, then the Error Subcode MUST be set to Unacceptable Hold Time. An implementation MUST reject Hold Time values of one or two seconds. An implementation MAY reject any proposed Hold Time. An implementation which accepts a Hold Time MUST use the negotiated value for the Hold Time.
OPENメッセージのホールドタイムフィールドが受け入れられない場合は、エラーサブコードは受け入れられないホールド時間を設定しなければなりません。実装では、1または2秒のホールド時間値を拒絶しなければなりません。実装は、任意の提案ホールド時間を拒否することがあります。ホールド時間を受け入れる実装は、ホールド時間のために交渉した値を使用しなければなりません。
If one of the Optional Parameters in the OPEN message is not recognized, then the Error Subcode is set to Unsupported Optional Parameters.
OPENメッセージ内のオプションパラメータの一つが認識されない場合は、エラーサブコードはサポートされないオプションパラメータに設定されています。
If the OPEN message carries Authentication Information (as an Optional Parameter), then the corresponding authentication procedure is invoked. If the authentication procedure (based on Authentication Code and Authentication Data) fails, then the Error Subcode is set to Authentication Failure.
OPENメッセージは、（オプションのパラメータとして）認証情報を搬送する場合、対応する認証手順が呼び出されます。 （認証コードと認証データに基づいて）認証手続きが失敗した場合、エラーサブコードは、認証失敗に設定されています。
If the OPEN message indicates that the peer does not support a capability which the receiver requires, the receiver may send a NOTIFICATION message to the peer, and terminate peering. The Error Subcode in the message is set to Unsupported Capability. The Data field in the NOTIFICATION message lists the set of capabilities that cause the speaker to send the message. Each such capability is encoded the same way as it was encoded in the received OPEN message.
OPENメッセージは、ピアが受信機に必要な機能をサポートしていないことを示す場合、受信機は、ピアに通知メッセージを送信し、ピアリングを終了することができます。メッセージ中のエラーサブコードはサポートされていない機能に設定されています。通知メッセージにデータフィールドは、メッセージを送信するためにスピーカーを引き起こす機能のセットを示しています。各そのような能力は、それが受信したオープンメッセージに符号化されたのと同じ方法で符号化されます。
All errors detected while processing the UPDATE message are indicated by sending the NOTIFICATION message with Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error.
更新メッセージを処理している間に検出されたすべてのエラーは、エラーコード更新メッセージエラーによる通知メッセージを送信することによって示されています。エラーサブコードはエラーの特定の性質について詳しく説明します。
If any recognized attribute has Attribute Length that conflicts with the expected length (based on the attribute type code), then the Error Subcode is set to Attribute Length Error. The Data field contains the erroneous attribute (type, length and value).
任意の認識属性は（属性タイプコードに基づいて）予想される長さと競合する長さ属性がある場合は、エラーサブコードは長エラーを属性に設定されています。データフィールドは誤った属性（タイプ、長さ、および値）が含まれています。
If the Encoded-Address-Prefix field in some attribute is syntactically incorrect, then the Error Subcode is set to Invalid Prefix Field.
いくつかの属性でエンコード・アドレス・プレフィックスフィールドが文法的に間違っている場合は、エラーサブコードは無効な接頭辞フィールドに設定されています。
If any other is encountered when processing attributes (such as invalid nestings), then the Error Subcode is set to Malformed Attribute List, and the problematic attribute is included in the data field.
（無効なネストなど）の属性を処理するとき、他に遭遇した場合、エラーサブコードは、不正な形式の属性リストに設定され、問題の属性は、データ・フィールドに含まれています。
If a peer sends a NOTIFICATION message, and there is an error in that message, there is unfortunately no means of reporting this error via a subsequent NOTIFICATION message. Any such error, such as an unrecognized Error Code or Error Subcode, should be noticed, logged locally, and brought to the attention of the administration of the peer. The means to do this, however, lies outside the scope of this document.
ピアが通知メッセージを送信し、そのメッセージにエラーがある場合には、残念ながらその後のNOTIFICATIONメッセージを介してこのエラーを報告する手段がありません。こうした認識できないエラーコードまたはエラーサブコードなどの任意のこのようなエラーは、ローカルログオン、およびピアの管理の注意を喚起、留意すべきです。これを行うための手段が、しかし、この文書の範囲外にあります。
If a system does not receive successive KEEPALIVE and/or UPDATE and/or NOTIFICATION messages within the period specified in the Hold Time field of the OPEN message, then the NOTIFICATION message with Hold Timer Expired Error Code must be sent and the BGMP connection closed.
システムがOPENメッセージのホールド時間フィールドで指定された期間内に連続したKEEPALIVEおよび/またはUPDATEおよび/または通知メッセージを受信しない場合には、ホールドタイマー期限切れエラーコードで通知メッセージが送信されなければならないとBGMP接続が閉じました。
Any error detected by the BGMP Finite State Machine (e.g., receipt of an unexpected event) is indicated by sending the NOTIFICATION message with Error Code Finite State Machine Error.
BGMP有限状態マシンによって検出されたエラー（例えば、予期しないイベントの受信）はエラーコード有限状態機械エラーでNOTIFICATIONメッセージを送ることによって示されています。
In absence of any fatal errors (that are indicated in this section), a BGMP peer may choose at any given time to close its BGMP connection by sending the NOTIFICATION message with Error Code Cease. However, the Cease NOTIFICATION message must not be used when a fatal error indicated by this section does exist.
（このセクションで示されている）任意の致命的なエラーが存在しない状態で、BGMPピアはエラーコードシーズを有する通知メッセージを送信することによって、そのBGMP接続を閉じるために、任意の所与の時点で選択してもよいです。このセクションで示される致命的なエラーが存在しない場合しかし、シーズ通知メッセージを使用してはなりません。
If a pair of BGMP speakers try simultaneously to establish a TCP connection to each other, then two parallel connections between this pair of speakers might well be formed. We refer to this situation as connection collision. Clearly, one of these connections must be closed.
BGMPスピーカーのペアが互いへのTCP接続を確立することを同時にしようとすると、スピーカーのこのペアの間に2つの並列接続がうまく形成される可能性があります。私たちは、接続衝突とこのような状況を参照してください。明らかに、これらの接続の一つが閉じなければなりません。
Based on the value of the BGMP Identifier a convention is established for detecting which BGMP connection is to be preserved when a collision does occur. The convention is to compare the BGMP
BGMP識別子の値に基づいて、大会は衝突が発生したときにBGMP接続が維持される検出のために確立されています。大会はBGMPを比較することです
Identifiers of the peers involved in the collision and to retain only the connection initiated by the BGMP speaker with the higher-valued BGMP Identifier.
より高い値BGMP識別子とBGMPスピーカによって開始された接続のみを保持するための衝突に関与するピアの識別子と。
Upon receipt of an OPEN message, the local system must examine all of its connections that are in the OpenConfirm state. A BGMP speaker may also examine connections in an OpenSent state if it knows the BGMP Identifier of the peer by means outside of the protocol. If among these connections there is a connection to a remote BGMP speaker whose BGMP Identifier equals the one in the OPEN message, then the local system performs the following collision resolution procedure:
OPENメッセージを受信すると、ローカルシステムはOpenConfirm状態にあるそのすべての接続を調べる必要があります。それはプロトコルの外部手段によってピアのBGMP識別子を知っている場合BGMPスピーカもOpenSent状態の接続を検査することができます。これらの接続のうちBGMP識別子OPENメッセージ内の1つに等しいリモートBGMPスピーカへの接続がある場合、ローカルシステムは、次の衝突解決手順を実行します。
1. The BGMP Identifier of the local system is compared to the BGMP Identifier of the remote system (as specified in the OPEN message).
1.ローカルシステムのBGMP識別子は、リモート・システムのBGMP識別子（OPENメッセージで指定されるように）と比較されます。
2. If the value of the local BGMP Identifier is less than the remote one, the local system closes BGMP connection that already exists (the one that is already in the OpenConfirm state), and accepts BGMP connection initiated by the remote system.
2.ローカルBGMP識別子の値は、リモート1未満である場合、ローカル・システムが既に存在BGMP接続（OpenConfirm状態に既にあるもの）を閉じ、リモートシステムによって開始さBGMP接続を受け付けます。
3. Otherwise, the local system closes newly created BGMP connection (the one associated with the newly received OPEN message), and continues to use the existing one (the one that is already in the OpenConfirm state).
3.それ以外の場合は、ローカルシステムは、新たに作成されたBGMP接続（新たに受信したオープンメッセージに関連付けられたもの）を閉じ、既存の（OpenConfirm状態に既にあるもの）を使用し続けます。
Comparing BGMP Identifiers is done by treating them as (4-octet long) unsigned integers.
BGMP識別子を比較する（4オクテット長い）符号なし整数として扱うことによって行われます。
A connection collision with an existing BGMP connection that is in Established states causes unconditional closing of the newly created connection. Note that a connection collision cannot be detected with connections that are in Idle, or Connect, or Active states.
設立の状態にある既存のBGMP接続との接続衝突は、新しく作成された接続の無条件の閉鎖を引き起こします。接続衝突がアイドル、または接続、またはActive状態にある接続を検出できないことに注意してください。
Closing the BGMP connection (that results from the collision resolution procedure) is accomplished by sending the NOTIFICATION message with the Error Code Cease.
BGMP接続を閉じる（つまり、衝突解決手順に起因する）エラーコードシーズでNOTIFICATIONメッセージを送ることによって達成されます。
BGMP speakers may negotiate the version of the protocol by making multiple attempts to open a BGMP connection, starting with the highest version number each supports. If an open attempt fails with an Error Code OPEN Message Error, and an Error Subcode Unsupported Version Number, then the BGMP speaker has available the version number it tried, the version number its peer tried, the version number passed by its peer in the NOTIFICATION message, and the version numbers that it supports. If the two peers do support one or more common versions, then this will allow them to rapidly determine the highest common version. In order to support BGMP version negotiation, future versions of BGMP must retain the format of the OPEN and NOTIFICATION messages.
BGMPスピーカーは、最も高いバージョン番号を各サポートを開始、BGMP接続を開くために複数の試行を行うことで、プロトコルのバージョンを交渉することができます。オープン試みがエラーコードOPENメッセージエラー、およびエラーサブコードサポートされていないバージョン番号で失敗した場合は、BGMPスピーカーは、それが試さ可能なバージョン番号、そのピアが試みたバージョン番号、通知にそのピアから渡されたバージョン番号を持っていますメッセージ、およびそれがサポートするバージョン番号。 2つのピアが1つの以上の共通のバージョンをサポートしている場合、これは彼らが急速に最高の共通のバージョンを確認することができます。 BGMPバージョンネゴシエーションをサポートするために、BGMPの将来のバージョンでは、OPENおよび通知メッセージの形式を保持しなければなりません。
When a BGMP speaker sends an OPEN message to its BGMP peer, the message may include an Optional Parameter, called Capabilities. The parameter lists the capabilities supported by the speaker.
BGMPスピーカーはそのBGMPピアにOPENメッセージを送信すると、メッセージは、能力と呼ばれるオプションのパラメータを含むことができます。パラメータは、スピーカーでサポートされている機能を示しています。
A BGMP speaker may use a particular capability when peering with another speaker only if both speakers support that capability. A BGMP speaker determines the capabilities supported by its peer by examining the list of capabilities present in the Capabilities Optional Parameter carried by the OPEN message that the speaker receives from the peer.
他のスピーカーとピアリングときBGMPのスピーカーは、両方のスピーカーがその機能をサポートしている場合にのみ、特定の機能を使用することができます。 BGMPスピーカーはスピーカーがピアから受け取るOPENメッセージによって運ば能力任意パラメータに存在する機能のリストを調べることによって、そのピアでサポートされている機能を決定します。
This section specifies BGMP operation in terms of a Finite State Machine (FSM). Following is a brief summary and overview of BGMP operations by state as determined by this FSM.
このセクションでは、有限状態機械（FSM）の観点でBGMP操作を指定します。このFSMによって決定されるような状態によってBGMP操作の簡単な要約と概要は次のとおり。
Initially BGMP is in the Idle state.
当初BGMPはアイドル状態になっています。
Idle state:
アイドル状態：
In this state BGMP refuses all incoming BGMP connections. No resources are allocated to the peer. In response to the Start event (initiated by either system or operator) the local system initializes all BGMP resources, starts the ConnectRetry timer, initiates a transport connection to the other BGMP peer, while listening for a connection that may be initiated by the remote BGMP peer, and changes its state to Connect. The exact value of the ConnectRetry timer is a local matter, but should be sufficiently large to allow TCP initialization.
この状態ではBGMPは、すべての着信BGMP接続を拒否します。何リソースがピアに割り当てられません。遠隔BGMPによって開始することができる接続のリスニングをしながら（いずれかのシステムまたはオペレータによって開始される）開始イベントに応答して、ローカルシステムは、全てBGMPリソースを初期化接続リトライタイマを開始し、他のBGMPピアへのトランスポート接続を開始しますピアと接続し、その状態を変更します。接続リトライタイマの正確な値は、ローカルの問題であるが、TCPの初期化を可能にするために十分に大きくなければなりません。
If a BGMP speaker detects an error, it shuts down the connection and changes its state to Idle. Getting out of the Idle state requires generation of the Start event. If such an event is generated automatically, then persistent BGMP errors may result in persistent flapping of the speaker. To avoid such a condition it is recommended that Start events should not be generated immediately for a peer that was previously transitioned to Idle due to an error. For a peer that was previously transitioned to Idle due to an error, the time between consecutive generation of
BGMPスピーカーがエラーを検出した場合、それは接続をシャットダウンし、Idleにその状態を変更します。アイドル状態から抜け出すことは開始イベントの生成を必要とします。そのようなイベントが自動的に生成されている場合は、永続的なBGMPエラーがスピーカーの永続的な羽ばたきをもたらすことができます。このような状態を避けるために、スタートイベントが以前のエラーが原因Idleに移行したピアのためにすぐに生成されるべきではないことをお勧めします。以前に、エラーの連続発生の間の時間を伴うIdleに遷移したピアの
Start events, if such events are generated automatically, shall exponentially increase. The value of the initial timer shall be 60 seconds. The time shall be doubled for each consecutive retry.
イベントを起動し、このようなイベントが自動的に生成されている場合は、指数関数的に増加するものとします。初期タイマ値は60秒でなければなりません。時間は、連続する各再試行のために倍増されなければなりません。
Any other event received in the Idle state is ignored.
アイドル状態で受信された他のイベントは無視されます。
Connect state:
状態を接続します。
In this state BGMP is waiting for the transport protocol connection to be completed.
この状態ではBGMPが完了するトランスポートプロトコル接続を待っています。
If the transport protocol connection succeeds, the local system clears the ConnectRetry timer, completes initialization, sends an OPEN message to its peer, and changes its state to OpenSent. If the transport protocol connect fails (e.g., retransmission timeout), the local system restarts the ConnectRetry timer, continues to listen for a connection that may be initiated by the remote BGMP peer, and changes its state to Active state.
トランスポートプロトコル接続が成功した場合、ローカルシステムは、接続リトライタイマをクリアして初期化を完了し、そのピアにOPENメッセージを送信し、OpenSentにその状態を変化させます。トランスポート・プロトコル（例えば、再送タイムアウト）失敗、ローカルシステムに接続リトライタイマを再起動接続した場合、リモートBGMPピアによって開始され、アクティブ状態にその状態を変化させることができる接続を待機し続けます。
In response to the ConnectRetry timer expired event, the local system restarts the ConnectRetry timer, initiates a transport connection to the other BGMP peer, continues to listen for a connection that may be initiated by the remote BGMP peer, and stays in the Connect state.
接続リトライタイマ期限切れのイベントに応答して、ローカルシステムは、接続リトライタイマを再起動し、他のBGMPピアへのトランスポート接続を開始し、リモートBGMPピアによって開始され、接続状態のままにすることができる接続を待機し続けます。
The Start event is ignored in the Connect state.
スタートイベントは、接続状態では無視されます。
In response to any other event (initiated by either system or operator), the local system releases all BGMP resources associated with this connection and changes its state to Idle.
（いずれかのシステムまたはオペレータによって開始される）他のイベントに応答して、ローカルシステムは、この接続に関連付けられたすべてのBGMPリソースを解放し、アイドルために、その状態を変化させます。
Active state:
アクティブ状態：
In this state BGMP is trying to acquire a peer by listening for an incoming transport protocol connection.
この状態でBGMP着信転送プロトコル接続をリッスンすることによってピアを取得しようとしています。
If the transport protocol connection succeeds, the local system clears the ConnectRetry timer, completes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and changes its state to OpenSent. A Hold Timer value of 4 minutes is suggested.
トランスポートプロトコル接続が成功した場合、ローカルシステムは接続リトライタイマをクリアし、初期化を完了し、OPENメッセージをピアに送信し、そのホールドタイマが大きな値に設定し、OpenSentにその状態を変化させます。 4分のホールドタイマーの値が推奨されます。
In response to the ConnectRetry timer expired event, the local system restarts the ConnectRetry timer, initiates a transport connection to other BGMP peer, continues to listen for a connection that may be initiated by the remote BGMP peer, and changes its state to Connect.
接続リトライタイマ期限切れのイベントに応答して、ローカルシステムは、接続リトライタイマを再起動し、他のBGMPピアへのトランスポート接続を開始し、リモートBGMPピアによって開始され、そして接続するために、その状態を変化させることができる接続を待機し続けます。
If the local system detects that a remote peer is trying to establish BGMP connection to it, and the IP address of the remote peer is not an expected one, the local system restarts the ConnectRetry timer, rejects the attempted connection, continues to listen for a connection that may be initiated by the remote BGMP peer, and stays in the Active state.
ローカルシステムがリモートピアがそれにBGMP接続を確立しようとしていることを検出し、リモートピアのIPアドレスが期待されるものではない、ローカルシステムは接続リトライタイマを再起動し、接続試行を拒否した場合、をリッスンし続けリモートBGMPピアによって開始され、アクティブ状態のままにすることができる接続。
The Start event is ignored in the Active state.
スタートイベントは、アクティブ状態では無視されます。
In response to any other event (initiated by either system or operator), the local system releases all BGMP resources associated with this connection and changes its state to Idle.
（いずれかのシステムまたはオペレータによって開始される）他のイベントに応答して、ローカルシステムは、この接続に関連付けられたすべてのBGMPリソースを解放し、アイドルために、その状態を変化させます。
OpenSent state:
OpenSent状態：
In this state BGMP waits for an OPEN message from its peer. When an OPEN message is received, all fields are checked for correctness. If the BGMP message header checking or OPEN message checking detects an error (see Section 6.2), or a connection collision (see Section 6.8) the local system sends a NOTIFICATION message and changes its state to Idle.
この状態でBGMPは、そのピアからOPENメッセージを待ちます。 OPENメッセージを受信すると、すべてのフィールドが正しいかどうかチェックされます。 BGMPメッセージヘッダチェックまたはOPENメッセージチェックがエラーを検出した場合、ローカルシステムは、通知メッセージを送信し、アイドルために、その状態を変更する（セクション6.2を参照）、または接続衝突（セクション6.8を参照）。
If there are no errors in the OPEN message, BGMP sends a KEEPALIVE message and sets a KeepAlive timer. The Hold Timer, which was originally set to a large value (see above), is replaced with the negotiated Hold Time value (see section 4.2). If the negotiated Hold Time value is zero, then the Hold Time timer and KeepAlive timers are not started. If the configured remote Autonomous System value for this peering is the same as the local Autonomous System number, then the connection is an "internal" connection; otherwise, it is "external". Finally, the state is changed to OpenConfirm.
OPENメッセージでエラーがない場合は、BGMPはKEEPALIVEメッセージを送信し、キープアライブタイマーを設定します。元々大きな値に設定されたホールドタイマは、（上記参照）、（セクション4.2を参照）ネゴシエートホールド時間値に置き換えられます。ネゴシエートされた保留時間値がゼロの場合は、ホールド時間タイマーおよびキープアライブタイマーが開始されていません。このピアリングのための構成されたリモート自律システム値は、ローカル自律システム番号と同じである場合、接続は「内部」接続です。それ以外の場合は、「外部」です。最後に、状態がOpenConfirmに変更されます。
If a disconnect notification is received from the underlying transport protocol, the local system closes the BGMP connection, restarts the ConnectRetry timer, while continue listening for connection that may be initiated by the remote BGMP peer, and goes into the Active state.
切断通知は、基礎となるトランスポートプロトコルから受信した場合、ローカルシステムは、リモートBGMPピアによって開始することができる接続のリスニングを続けながらBGMP接続は、接続リトライタイマを再開閉じ、アクティブ状態になります。
If the Hold Timer expires, the local system sends NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle.
ホールドタイマーの期限が切れた場合は、ローカルシステムは、エラーコードで通知メッセージを送信タイマーが満了し、Idleにその状態を変更するホールド。
In response to the Stop event (initiated by either system or operator) the local system sends NOTIFICATION message with Error Code Cease and changes its state to Idle.
（システムまたはオペレータのいずれかによって開始）ストップイベントに応答して、ローカルシステムは、エラーコードのシーズとの通知メッセージを送信し、Idleにその状態を変更します。
The Start event is ignored in the OpenSent state.
スタートイベントはOpenSent状態では無視されます。
In response to any other event the local system sends NOTIFICATION message with Error Code Finite State Machine Error and changes its state to Idle.
他のイベントに応答して、ローカルシステムは、エラーコード有限ステートマシンのエラーで通知メッセージを送信し、Idleにその状態を変更します。
Whenever BGMP changes its state from OpenSent to Idle, it closes the BGMP (and transport-level) connection and releases all resources associated with that connection.
BGMPがIdleにOpenSentから、その状態を変更するたびに、それはBGMP（およびトランスポート・レベル）接続を解放、その接続に関連付けられているすべてのリソースを閉じます。
OpenConfirm state:
OpenConfirm状態：
In this state BGMP waits for a KEEPALIVE or NOTIFICATION message.
この状態でBGMPはKEEPALIVEまたは通知メッセージを待ちます。
If the local system receives a KEEPALIVE message, it changes its state to Established.
ローカルシステムがKEEPALIVEメッセージを受信した場合、それは設立にその状態を変更します。
If the Hold Timer expires before a KEEPALIVE message is received, the local system sends NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle.
KEEPALIVEメッセージが受信される前に、ホールドタイマーの期限が切れた場合は、ローカルシステムは、エラーコードで通知メッセージを送信タイマーが満了し、Idleにその状態を変更するホールド。
If the local system receives a NOTIFICATION message, it changes its state to Idle.
ローカルシステムがNOTIFICATIONメッセージを受信した場合、それはIdleにその状態を変更します。
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer.
キープアライブタイマーが満了した場合は、ローカルシステムがKEEPALIVEメッセージを送信し、そのキープアライブタイマーを再起動します。
If a disconnect notification is received from the underlying transport protocol, the local system changes its state to Idle.
切断通知が、基礎となるトランスポートプロトコルから受信された場合、ローカルシステムがIdleにその状態を変化させます。
In response to the Stop event (initiated by either system or operator) the local system sends NOTIFICATION message with Error Code Cease and changes its state to Idle.
（システムまたはオペレータのいずれかによって開始）ストップイベントに応答して、ローカルシステムは、エラーコードのシーズとの通知メッセージを送信し、Idleにその状態を変更します。
The Start event is ignored in the OpenConfirm state.
スタートイベントはOpenConfirm状態では無視されます。
In response to any other event the local system sends NOTIFICATION message with Error Code Finite State Machine Error and changes its state to Idle.
他のイベントに応答して、ローカルシステムは、エラーコード有限ステートマシンのエラーで通知メッセージを送信し、Idleにその状態を変更します。
Whenever BGMP changes its state from OpenConfirm to Idle, it closes the BGMP (and transport-level) connection and releases all resources associated with that connection.
BGMPがIdleにOpenConfirmから、その状態を変更するたびに、それはBGMP（およびトランスポート・レベル）接続を解放、その接続に関連付けられているすべてのリソースを閉じます。
Established state:
設立の状態：
In the Established state BGMP can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer.
確立された状態でBGMPはピアとUPDATE、NOTIFICATION、およびKEEPALIVEメッセージを交換することができます。
If the local system receives an UPDATE or KEEPALIVE message, it restarts its Hold Timer, if the negotiated Hold Time value is non-zero.
ローカルシステムがUPDATEまたはKEEPALIVEメッセージを受信した場合に交渉ホールドタイム値がゼロであれば、それは、そのホールドタイマーを再起動します。
If the local system receives a NOTIFICATION message, it changes its state to Idle.
ローカルシステムがNOTIFICATIONメッセージを受信した場合、それはIdleにその状態を変更します。
If the local system receives an UPDATE message and the UPDATE message error handling procedure (see Section 6.3) detects an error, the local system sends a NOTIFICATION message and changes its state to Idle.
ローカルシステムがUPDATEメッセージとUPDATEメッセージエラー処理手順（セクション6.3を参照）にエラーを検出した受信した場合、ローカルシステムは、通知メッセージを送信し、アイドルために、その状態を変化させます。
If a disconnect notification is received from the underlying transport protocol, the local system changes its state to Idle.
切断通知が、基礎となるトランスポートプロトコルから受信された場合、ローカルシステムがIdleにその状態を変化させます。
If the Hold Timer expires, the local system sends a NOTIFICATION message with Error Code Hold Timer Expired and changes its state to Idle.
ホールドタイマーの期限が切れた場合は、ローカルシステムは、エラーコードと通知メッセージはタイマーが満了し、Idleにその状態を変更するホールド送信します。
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer.
キープアライブタイマーが満了した場合は、ローカルシステムがKEEPALIVEメッセージを送信し、そのキープアライブタイマーを再起動します。
Each time the local system sends a KEEPALIVE or UPDATE message, it restarts its KeepAlive timer, unless the negotiated Hold Time value is zero.
ネゴシエートされた保留時間の値がゼロでない限り、ローカルシステムがKEEPALIVEまたはUPDATEメッセージを送信するたびに、それは、そのキープアライブタイマーを再起動します。
In response to the Stop event (initiated by either system or operator), the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle.
（いずれかのシステムまたはオペレータによって開始される）停止イベントに応答して、ローカルシステムエラーコードシーズで通知メッセージを送信し、アイドルために、その状態を変化させます。
The Start event is ignored in the Established state.
スタートイベントが設立された状態に無視されます。
In response to any other event, the local system sends NOTIFICATION message with Error Code Finite State Machine Error and changes its state to Idle.
他のイベントに応答して、ローカルシステムは、エラーコード有限ステートマシンのエラーで通知メッセージを送信し、Idleにその状態を変更します。
Whenever BGMP changes its state from Established to Idle, it closes the BGMP (and transport-level) connection, releases all resources associated with that connection, and deletes all routes derived from that connection.
BGMPがIdleに確立されたから、その状態を変更するたびに、それはBGMP（および転送レベル）接続は、その接続に関連付けられているすべてのリソースを解放閉じ、その接続に由来するすべてのルートを削除します。
If a BGMP speaker accepts unauthorized or altered BGMP messages, denial of service due to excess bandwidth consumption or lack of multicast connectivity can result. Authentication of BGMP messages can protect against this behavior.
BGMPスピーカーが不正または変更BGMPメッセージを受け入れた場合、マルチキャスト接続の超過帯域幅の消費量や不足によるサービス拒否が発生することがあります。 BGMPメッセージの認証は、この動作から保護することができます。
A BGMP implementation MUST implement Keyed MD5 [RFC2385] to secure control messages, and MUST be capable of interoperating with peers that do not support it. However, if one side of the connection is configured with Keyed MD5 and the other side is not, the connection SHOULD NOT be established.
BGMPの実装では、制御メッセージを確保するためにキー付きMD5 [RFC2385]を実装しなければならない、とそれをサポートしていないピアとの相互運用が可能でなければなりません。接続の一方の側は鍵付きMD5で構成されており、他の側ではない場合は、接続が確立されるべきではありません。
This provides a weak security mechanism, as it is still possible for denial of service to occur as a result of messages relayed through a trusted peer. However, this model is the same as the currently practiced security mechanism for BGP. It is anticipated that future work will provide different stronger mechanisms for dealing with these issues in routing protocols.
これは、サービス拒否が信頼できるピアを通じて中継されたメッセージの結果として発生することはまだ可能であるとして、弱いセキュリティメカニズムを提供します。しかし、このモデルでは、BGPのために現在実施セキュリティ・メカニズムと同じです。今後の作業は、ルーティングプロトコルで、これらの問題に対処するための別の強力なメカニズムを提供することが予想されます。
In addition to the editor, the following individuals have contributed to the design of BGMP: Cengiz Alaettinoglu, Tony Ballardie, Steve Casner, Steve Deering, Deborah Estrin, Dino Farinacci, Bill Fenner, Mark Handley, Ahmed Helmy, Van Jacobson, Dave Meyer, and Satish Kumar.
エディタに加えて、以下の個人がBGMPの設計に貢献した：Cengiz Alaettinoglu、トニーBallardie、スティーブCasner、スティーブデアリング、デボラ・エストリン、ディノファリナッチ、ビルフェナー、マーク・ハンドリー、アーメド・ヘルミー、バン・ジェイコブソン、デイブ・マイヤー、そしてサティシュ・クマール。
This document is the product of the IETF BGMP Working Group with Dave Thaler as editor.
この文書では、編集者としてデーブターラーとIETF BGMPワーキンググループの製品です。
Rusty Eddy, Isidor Kouvelas, and Pavlin Radoslavov also provided valuable feedback on this document.
ラスティエディ、イジドールKouvelas、およびPavlin Radoslavovも、この文書に関する貴重なフィードバックを提供します。
[INTEROP] Thaler, D., "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999.
[INTEROP]ターラー、D.、 "マルチキャストルーティングプロトコルの相互運用性規則"、RFC 2715、1999年10月。
[RFC2385] Heffernan, A., "Protection of BGP sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[V6PREFIX] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[V6PREFIX]ハーバーマン、B.とD.ターラー、 "ユニキャストプレフィックスベースのIPv6マルチキャストアドレス"、RFC 3306、2002年8月。
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[MBGP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
【MBGP]ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.カッツ、 "BGP-4のためのマルチプロトコルの拡張"、RFC 2858、2000年6月。
[CBT] Ballardie, A., "Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification", RFC 2189, September 1997.
[CBT] Ballardie、A.、 "コアベースツリー（CBTバージョン2）マルチキャストルーティング - プロトコル仕様"、RFC 2189、1997年9月。
[DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress, October 2003.
[DVMRP] Pusateri、T.、 "距離ベクトルマルチキャストルーティングプロトコル"、進歩、2003年10月に作業。
[IPv6AA] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[IPv6AA] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[MOSPF]モイ、J.、 "OSPFへのマルチキャスト拡張機能"、RFC 1584、1994年3月。
[PIMDM] Adams, A., Nicholas, J. and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", Work in Progress, September 2003.
[PIMDM]アダムス、A.、ニコラス、J.とW. Siadak、 "プロトコル独立マルチキャスト - 稠密モード（PIMDM）：プロトコル仕様（改訂）"、進歩、2003年9月の作業。
[PIMSM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
【PIMSM] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL 。魏、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様"、RFC 2362、1998年6月。
[REFLECT] Bates, T. and R. Chandra, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.
[REFLECT]ベイツ、T.、およびR.チャンドラ、 "BGPルートリフレクション：フルメッシュIBGPへの代替"、RFC 1966、1996年6月。
[V4PREFIX] Thaler, D., "Unicast-Prefix-based IPv4 Multicast Addresses", Work in Progress, August 2004.
[V4PREFIX]ターラー、D.、「ユニキャストプレフィックスベースのIPv4マルチキャストアドレス」、進歩、2004年8月での作業。
Authors' Address
著者の住所
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
デーブターラーマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052
EMail: dthaler@microsoft.com
メールアドレス：dthaler@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。