[要約] RFC 3913は、Border Gateway Multicast Protocol（BGMP）のプロトコル仕様を定義しています。このRFCの目的は、マルチキャストトラフィックの効率的な配信を実現するために、BGMPプロトコルを提供することです。
Network Working Group D. Thaler
Request for Comments: 3913 Microsoft
Category: Informational September 2004
Border Gateway Multicast Protocol (BGMP): Protocol Specification
Border Gatewayマルチキャストプロトコル（BGMP）：プロトコル仕様
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）The Internet Society（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.
このドキュメントでは、ドメイン間マルチキャストルーティングのプロトコルであるBorder Gateway Multicast Protocol（BGMP）について説明します。BGMPは、アクティブなマルチキャストグループ向けに共有ツリーを構築し、オプションでレシーバードメインが、必要に応じてソース固有の分布分岐を構築できるようにします。BGMPは、「ソース固有のマルチキャスト」（SSM）をネイティブにサポートしています。また、「任意のソースマルチキャスト」（ASM）をサポートするために、BGMPでは、各マルチキャストグループを単一のルートに関連付ける必要があります（BGMPではルートドメインと呼ばれます）。マルチキャストアドレス空間のさまざまな範囲が関連付けられている（例えば、ユニキャストとペルフィックスベースのマルチキャストアドレス指定）異なるドメインに関連する必要があります。これらの各ドメインは、その範囲のすべてのグループの共有ドメインツリーのルートになります。マルチキャスト参加者は、セッションイニシエーターのアドレスアロケーターがスペースの独自のドメイン部分からアドレスを選択し、それによりルートドメインをセッション参加者の少なくとも1人にローカルにする場合、通常、より良いマルチキャストサービスを受け取ります。
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).
ドメイン間の「Any-Source」マルチキャストは、メンバーがグローバルブロードキャストなしでソースのデータパケットを受け取るランデブーメカニズムでよりよくサポートされることが示唆されています（例：MSDPブロードキャストソース情報、PIM-DM [PIMDM]、DVMRP[DVMRP]初期データパケットをブロードキャストし、MOSPF [MOSPF]はメンバーシップ情報をブロードキャストします）。PIM-SM [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）をネイティブにサポートしています。また、「Any-Source Multicast」（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は、マルチキャストアドレス空間の範囲が関連付けられていると想定しています（たとえば、Unicast-Prefixベースのマルチキャスト[V4Prefix、V6Prefix]アドレス指定）。そのような各ドメインは、その範囲のすべてのグループの共有ドメインツリーのルートになります。アドレスアロケーターは、一般に、スペースの独自のドメインの一部からマルチキャストアドレスを取得し、ルートドメインをローカルにする場合、より良い配布ツリーを実現します。
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.
2つの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つ以上の連続したリンクとゼロ以上のルーターのセット。ドメインのこのゆるい定義は、2つのドメイン間の外部リンクと交換にも適用されることに注意してください。
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.
ルートドメイン：一部のグループ用にドメインの共有ツリーを構築する場合、1つのドメインがツリーの「ルート」になります。ルートドメインは、各送信者からグループへのデータを受信し、メンバードメインがドメイン間結合を送信できるランデブードメインとして機能し、送信者ドメインがデータを送信できるように機能します。
Multicast RIB: The Routing Information Base, or routing table, used to calculate the "next-hop" towards a particular address for multicast traffic.
マルチキャストリブ：ルーティング情報ベース、またはルーティングテーブルは、マルチキャストトラフィックの特定のアドレスに向けて「次のホップ」を計算するために使用されます。
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]などのマルチキャストリブをサポートできる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接続が開かれている別のマルチキャストAS（自律システム、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].
内部ピア：同じマルチキャストの別のボーダールーター。BGPがEGPとして使用されている場合、Borderルーターは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).
Next-Hop Peer：特定のIPアドレスに向けた隣のホップピアは、EGPのルーティングテーブルのマルチキャストリブルートに従って、指定されたアドレスへのパス上の次のEGPルーターです（例：MBGPでは、後続のアドレスファミリ識別子のルートフィールドは、ルートがマルチキャストトラフィックに有効であることを示します）。
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.
ツリーステートテーブル：これは、一連のターゲットによって明示的に結合された（*、g）および（*、g-prefix）エントリのテーブルです。各エントリには、ソースおよびグループアドレスとマスクに加えて、明示的にデータを要求したターゲットのリストがあります（直接接続されたホストまたはダウンストリームルーターに代わって）。（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]で説明されているように解釈されるべきです。
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は、BGMPピアからのメッセージとM-IGPコンポーネントからの通知に応じて、グループ-Prefix状態を維持します。グループ共有の木は、それらのグループをカバーするグループプレフィックスを宣伝するドメインに根ざしています。受信者が特定のグループアドレスに結合すると、ルートドメインに向かってボーダールーターがグループ固有の結合メッセージを生成します。これは、ルートドメインに向かってボーダールーターごとに転送されます（図1を参照）。BGMP結合およびプルーンメッセージは、BGMPピア間のTCP接続を介して送信され、BGMPプロトコル状態は、TCPを介して定期的に送信されるKeepAliveメッセージによって更新されます。
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ルーターは、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はTransitドメインネットワークです。*_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などの非会員送信者の場合）によると、パケットはGのNext-Hop 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と他の共有ツリープロトコルには3つの大きな違いがあります。
(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.
ドメイン内ケースにおけるサードパーティの依存の懸念の欠如は、双方向の木を採用するインセンティブを減らします。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ルーターにマルチキャストトラフィックを引き下げる必要がある場合にのみ構築されます。そのルーターはまだ共有ツリー上にありません（つまり、（*、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/コア）は、そのドメイン内で開始されるグループのルートに等しく適していると想定されることがあります。ドメイン間のケースでは、容認できないほど貧弱な地域、およびグループの共有ツリールートの管理的制御の機会がはるかに多くあります。したがって、ドメイン内の場合、他のプロトコルは、すべての候補の根（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]、modulo one correstion on one corse on one corse based mode、modulo one correstionに準拠していると想定しています。
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.
A（*、g）エントリのIIF所有者は、マルチキャストリブの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はマルチキャストリブのソースに向かって次のホップを調べることができなければなりません。
(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はグループアドレスを公称「ルート」アドレスにマッピングし、マルチキャストリブのそのアドレスに向けて次のホップを検索できる必要があります。
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は、次のように公称の「ルート」アドレスを決定します。マルチキャストアドレスがUnicast-Prefixベースのマルチキャストアドレスである場合、名目上のルートアドレスは、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：1234：5678：9ABC：def0 :: 123の場合、ユニキャストプレフィックスは1234：5678：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.
Unicast-Prefixベースのマルチキャストアドレス以外のアドレスを使用した任意のソースマルチャストのサポートは、このドキュメントの範囲外です。
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.
o パケットがM-IGPが所有するインターフェイスに到着した場合、M-IGPコンポーネントは、パケットをそのルールに従って受け入れるか削除するかを決定します。パケットが受け入れられた場合、パケットはM-IGPで指定されているように、同じコンポーネントが所有する他のインターフェイスを転送（または転送しません）。
o If the packet was received over a point-to-point interface owned by BGMP, the packet is accepted.
o BGMPが所有するポイントツーポイントインターフェイスでパケットを受信した場合、パケットは受け入れられます。
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.
o パケットがBGMPが所有するマルチアクセスネットワークインターフェイスに到着した場合、ソース固有のブランチのデータを受信している場合、Sの最長のマッチングルートの指定されたフォワーダーである場合、または最長のマッチングルートの場合、パケットは受け入れられます。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.
パケットが受け入れられた場合、ルーターは1つのマッチング（s、g）エントリのツリーステートテーブルをチェックします。1つが見つかったが、パケットは次のホップターゲットからSに向かって受信されなかった場合（エントリのSPTビットが真実である場合）、またはgに向かって次のホップターゲットから受信されなかった（エントリのSPTビットがfalse）、パケットがドロップされ、それ以上のアクションは行われません。no（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.
どちらも見つからない場合、マルチキャストリブによると、パケットは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コンポーネントが別のコンポーネントからa（*、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.
それ以外の場合、no（*、g）または（s、g）エントリが見つかった場合、1つが作成されます。A（*、g）の場合、ターゲットリストは初期化され、外部ピアの場合、Gの名目上のルートに向かって次のホップピアを含むようになります。ピアが内部の場合、ターゲットリストは初期化され、次のホップインターフェイスを所有するM-IGPコンポーネントが含まれています。Next-Hopピアがない場合（Gの公称ルートがドメイン内にあるため）、ターゲットリストは初期化されてネクストホップコンポーネントが含まれます。（*、g）結合が処理されている同じgに対して（s、g）エントリが存在し、sに向かってnexthopのピアがgの公称ルートが異なる場合、bgmpルーターは最初にaを送信する必要があります。（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.)
（s、g）状態を作成する場合、ソースがBGMPスピーカーのドメインの内部である場合、「毒物リバース」ビット（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:
結合が受信されたターゲットがターゲットリストに追加されます。次に、ルーターがマルチキャストリブのGのsまたは公称ルートを検索して、next-hop EGPピアを見つけます。ターゲットリストが（*、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.
a) Gの名目上のルート（（*、g）エントリの場合）に向かって次のホップピアが外部ピアである場合、BGMP（*、g）の結合メッセージは外部ピアのユニキャストです。s（an（s、g）エントリの場合）に向けたnext-hopピアが外部ピアであり、ルーターにそのグループアドレスgのアクティブ（*、g）状態がない場合参加メッセージは、外部ピアのユニキャストです。BGMP（s、g）結合メッセージは、同じグループのアクティブ（*、g）状態も含まれるルーターによって外部ピアに送信されることはありません。s（s、gエントリの場合）に向けたnexthopピアが外部ピアであり、ルーターにそのグループGのアクティブ（*、g）状態がある場合、SPTビットは常にfalsに設定されます。
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) Next-Hopピアが内部ピアである場合、A（*、g）または（s、g）結合アラートは、Next-Hopインターフェイスを所有する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) Next-Hopピアがない場合、A（*、g）または（s、g）結合アラートは、Next-Hopインターフェイスを所有する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コンポーネントが別のコンポーネントから（*、g）または（s、g）プルーンアラートを受信した場合、またはBGMP（*、g）または（s、g）の外部ピアからプルーンメッセージを受信すると、ツリーステートテーブルを検索します一致するエントリ用。an（s、g）pruneのno（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.
それ以外の場合、コンポーネントまたはピアがターゲットリストから削除されます。結果としてターゲットリストがnullになる場合、g（*、g）エントリの場合、またはs（an（s、g）エントリの場合、bgmpの場合にのみsに向かって、次のホップのピアがnullになります。ルーターには対応する（*、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) Next-Hopピアが内部ピアである場合、A（*、G）または（S、G）PruneアラートがNext-Hopインターフェイスを所有する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) Next-Hopピアがない場合、（*、G）または（S、G）Pruneアラートが、Next-Hopインターフェイスを所有する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.
ボーダールーターがマルチキャストリブの新しいプレフィックスのルートを受け取る場合、またはプレフィックスの既存のルートが撤回される場合、そのプレフィックスのルート変更通知をBGMPコンポーネントに送信する必要があります。さらに、次のホップピア（マルチキャストリブによる）が変更されると、そのプレフィックスのルート変更通知を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のマルチキャストリブに注入する必要があります。
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）ターゲットリストを更新します。ルーターは、必要に応じて、新しいNext-Hop Targetに（*、G）結合を送信し、A a（*、g）は古いNext-Hopターゲットに剪定します。さらに、PRビットセットに存在する（s、g）状態が存在します。
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.
o BGMPスピーカーがGの公称ルートに最適な出口になったばかりの場合、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.
o BGMPスピーカーがGの公称ルートに最適な出口であり、もはやない場合、PRビットクリアを使用した（s、g）毒の逆メッセージは、以下に示すように送信されます。
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）毒リバースメッセージは、（s、g）結合が受信されたgの名目上のルートに向かって、next-hopインターフェイス上のすべての外部ピアに送信されます。
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）ターゲットリストを更新します。ルーターは、a（s、g）の結合を新しいNext-Hopターゲットに送信し、必要に応じて古いNext-HopターゲットにA（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の公称ルートに向かって。次のホップターゲットがM-IGPコンポーネントである場合、（S、G）結合（S、G）が結合したコンポーネントのすべての内部ピアに（s、G）逆逆メッセージを転送します。Next-Hopターゲットが特定のインターフェイス上の外部ピアである場合、そのインターフェイスのすべての外部ピアに（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からのみmから結合します。-IGP、または5.4.1に記載されているカプセル化による（s、g）状態を持っている）、独自の（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）結合メッセージが送信され、プルーン状態がキャンセルされ、状態が削除されます。
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.
Border RouterのM-IGPコンポーネントが最初に、グループG（そのスコープがそのドメインよりも大きい）に内部到達したメンバーがいることを学習すると、A（*、G）結合アラートがBGMPコンポーネントに送信されます。同様に、境界線ルーターのM-IGPコンポーネントが、グループG（スコープが単一のドメインよりも大きい）に内部到着したメンバーがなくなっていることを知ると、a（*、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.
いつでも、M-IGPドメインは、特定のソースSの次のホップルーターであるボーダールーターのM-IGPコンポーネントが、Sが学習する場合、外部ソース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.
最後に、特定のアドレスのネクストホップ内部ピアであるBorderルーターまたは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を参照）。それ以外の場合、外部でパケットを受け取るボーダールーターは、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状態を作成する必要があります。ボーダールーターは、非常に低いデータレート/断続的なソースのために状態が作成されないように、データレートトリガーベースでこれを行うように構成される場合があることに注意してください。ソース固有の状態が作成されている場合、その着信インターフェイスは、パケットを転送した境界ルーターからの仮想カプセル化インターフェイスを指し、falseに初期化された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）を送信します。Group、G。（s、g）bgmp状態は、（*、g）bgmp状態が存在する場合、sptビットを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）状態で一致し、（*、g）状態がある場合、ルーターはSPTフラグをtrueに設定し、着信インターフェイスをリセットします。外部ピアを指して、パケットをカプセル化しているBorderルーターにBGMP（S、G）プルーンメッセージを送信します（たとえば、図1では、BR11は（SRC_A、G）プルーンをBR12に送信します）。（*、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になる）に根付いている場合、ドメイン内のツリーがnext-Hop内部ピアに根付いている場合、最も少ないカプセル化/脱カプセル化は行われます。これは、ルーターが外部ソースからほとんどのパケットを受け取るためです。これを達成するために、各BGMPボーダールーターはPIM-SMドメインに境界線ルーターを送信する必要があります。それが共有ドメインツリーイングレスルーターであるグループのドメイン内に候補RP宣伝を送信する必要があります。グループGのRPであるBorder Routerが外部データパケットを受信すると、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ルール。Border Routerは、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）状態がないため、ボーダールーターは、データを直接引き下ろすために、次のホップの外部ピアにBGMP（s、g）の結合をsに向けて送信します。（図1のBR11を参照）。通常のPIM-SM操作と同様に、異なる入ってくるインターフェイスを指す（*、g）および（s、g）状態を持つPIM-SMルーターが共有ツリーからそのソースを整えます。したがって、すべての内部インターフェイスは、最終的に内部共有ツリーから剪定される可能性があります。
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ビットクリアを持っている場合、a（s、g）毒逆メッセージ（prビットクリア）が送信されますGのIngressルーターは、まだ存在しない場合に（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の侵入ルーターに転送されます。まだ存在しておらず、次のホップをターゲットリストの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との互換性の2つのポイントに対処する必要があります。まず、CBTはパケットを注入する複数のボーダールーターを収容できません。したがって、CBTドメインに複数の外部接続がある場合、境界線ルーターのM-IGPコンポーネントは、特定のソースからデータの1つだけがデータを注入することを保証する責任があります。
Second, CBT cannot process source-specific Joins or Prunes. Two options thus exist for each CBT domain:
第二に、CBTはソース固有の結合またはプルーンを処理できません。したがって、CBTドメインごとに2つのオプションが存在します。
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：CBTコンポーネントは、[Interop]で説明されているように、A（*、g）結合アラートのようにA（s、g）結合アラートを解釈します。つまり、Gのコアツリーにまだ載っていない場合、CBT（*、g）の結合メッセージをGのコアに向けて送信します。同様に、CBTコンポーネントが（s、g）プルーンを受信したときにアラートとグループの子インターフェイスリストはnullです。その後、Gのコアに（*、g）quit_notificationを送信します。このオプションは、メンバーがいない場合にグループGのすべてのデータをCBTドメインに引き下げるという不利な点があります。存在する。
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：CBTドメインは、そのプレフィックスへの他のパスが存在しないことがわかっていない限り、マルチキャストリブの外部ピアへのルートを伝播しません（たとえば、ドメインの内部または単独で蒸留された顧客のドメイン内のルート伝播する）。これにより、ソースのデータがすでに共有ツリー上のドメインを通過しない限り、ソース固有の結合が受信されないことを保証します。その場合、（s、g）結合はとにかく伝播する必要はありません。BGMPボーダールーターは、その外部ピアがEGPのソースペルフィックスを宣伝する場合にのみ、ソース固有の結合またはプルーンを外部ピアに送信します。BGMP-CBTボーダールーターが（s、g）結合またはプルーンを受信した場合、そのボーダールーターはメッセージを無視する必要があります。
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.
EN/deCapsulationを最小限に抑えるために、CBTV2 BRは、上記のPIM-SMで説明されているのと同じスキームに従うことができます。このスキームでは、候補コア広告が共有ツリーイングレスルーターであるグループに送信されます。
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：a（s、g）結合アラートに応じてすべてのgに対してグループメンバーシップLSAを送信し、（他の下流メンバーが存在しない場合）（s、g）に応答して「早期に老化」します。プルーンアラート、または
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：そのプレフィックスへの他のパスが存在しないことがわかっていない限り、マルチキャストリブの外部ピアへのルートを伝播しない（例えば、ドメインの内部または単独でホームの顧客のドメイン内のプレフィックスのルートが伝播される可能性がある）
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.
マルチアクセスリンクには、重複を防ぐために特別な取り扱いが必要です。次のメカニズムにより、BGMPはM-IGPを実行しないマルチアクセスリンクを介して動作できます。これにより、放送とプルーネの動作が回避され、（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が最初にルートがマルチキャストリブに存在することを知ると、次のホップインターフェイスがマルチアクセスリンクではないマルチキャストリブにルートが存在することを知ると、BGMPルーターはプレフィックスのBGMP FWDR_PREFメッセージをLAN上のすべてのBGMPピアに送信します。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メッセージを受信すると、マルチキャストリブのマッチングルートを検索し、新しい指定されたフォワーダーを計算します。ルーターに、親のターゲットが古い転送者であるツリーステートエントリがある場合、新しいフォワーダーに結合し、プルーンを古いフォワーダーに送信します。
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とルートドメインの間のパス上にある場合、答えはYESです（そして、PRビットはS、G状態に設定されます）。問題のドメインがSとルートドメインの間のパス上にない場合、答えはNOです（そして、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-OCTET符号なし整数は、オクテットのヘッダーを含むメッセージの全長を示します。したがって、たとえば、次のメッセージの開始をトランスポートレベルのストリームに配置できます。長さフィールドの値は、常に少なくとも4で4096以下でなければならず、メッセージタイプに応じてさらに制約される場合があります。メッセージが許可された後、追加データの「パディング」はないため、長さのフィールドは、メッセージの残りの部分を考慮して、必要な最小値を持つ必要があります。
Type: This 1-octet unsigned integer indicates the type code of the message. The following type codes are defined:
タイプ：この1-OCTET Unsigned Integerは、メッセージのタイプコードを示します。次のタイプコードが定義されています。
1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
1-オープン2-更新3-通知4-キープライブ
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.
トランスポートプロトコル接続が確立された後、各側から送信された最初のメッセージは開かれたメッセージです。オープンメッセージが許容できる場合、オープンを確認するキープライブメッセージが返送されます。オープンが確認されると、更新、KeepAlive、および通知メッセージが交換される場合があります。
In addition to the fixed-size BGMP header, the OPEN 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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-OCTET Unsigned Integerは、メッセージのプロトコルバージョン番号を示します。現在の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-OCTETの署名されていない整数は、送信者がホールドタイマーの値を提案する秒数を示します。開いたメッセージを受信すると、BGMPスピーカーは、構成された保留時間の小さいと開いたメッセージで受信された保留時間を使用して、ホールドタイマーの値を計算する必要があります。保留時間はゼロまたは少なくとも3秒でなければなりません。実装は、保留時間に基づいて接続を拒否する場合があります。計算された値は、連続したキープライブの受領と送信者による更新メッセージの間に経過する可能性のある最大秒数を示します。
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-OCTET（IPv4用）または16-OCTET（IPv6）unsigned Integerは、送信者のBGMP識別子を示します。与えられたBGMPスピーカーは、BGMP識別子の値を、そのBGMPスピーカーに割り当てられたグローバルに不一致の値に設定します（例：IPv4アドレス）。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-OCTET認証コードが含まれ、その後に変数長さ認証データが含まれます。
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-OCTET符号なし整数は、使用されている認証メカニズムを示します。BGMP内で使用するために認証メカニズムが指定されている場合はいつでも、仕様に3つのことを含める必要があります。
- 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).
開いたメッセージの最小長は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) 機能情報（パラメータータイプ2）：これは、BGMPスピーカーがスピーカーがサポートする機能のリストをピアに伝えるために使用されるオプションのパラメーターです。パラメーターには、1つ以上のトリプル<機能コード、機能の長さ、機能値>が含まれています。各トリプルは、以下に示すようにエンコードされます。
+------------------------------+
| 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.
更新メッセージは、BGMPピア間でJoin/Prune/FWDRPREF情報を転送するために使用されます。更新メッセージには、常に固定サイズの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:
以下のメッセージ形式では、（*、g）結合とプルーンのコンパクトなエンコードを使用すると、（s、g）がソースや共有ツリーに合わせて結合してプルーンするなどの他の更新を実行するために必要な柔軟性を可能にします。以下の議論では、エンコードされたアドレス-Prefixが形式です。
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のマスク。マスクフィールドの長さは0バイトです。1-マスク長が含まれています。マスクフィールドの長さは4バイトで、ビットのマスクの長さが含まれています。2-完全なマスクが含まれています。マスクフィールドはアドレスフィールドと同じ長さで、フルビットマスクが含まれています。
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-参加1 -Prune 2-グループ3-ソース4 -FWDR_PREF 5-POISON_REVERSE
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オプション内に直ちにネストされているすべてのグループまたはソースオプションを結合する必要があることを示します。
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.
結合、プルーン、またはFWDR_PREFの属性は、JOIN属性内に直ちにネストされる場合があります。
b) PRUNE (Type Code 1)
b) プルーン（タイプコード1）
The PRUNE attribute indicates that all GROUP or SOURCE attributes nested immediately within the PRUNE attribute should be pruned.
Prune属性は、Prune属性内に直ちにネストされたすべてのグループまたはソース属性を剪定する必要があることを示しています。
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.
結合、プルーン、またはFWDR_PREF属性は、プルーン属性内に直ちにネストされる場合があります。
c) GROUP (Type Code 2)
c) グループ（タイプコード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.
グループ属性は、特定のグループ-Prefixを識別します。さらに、グループ属性内に直ちにネストされた属性は、指定されたGroup-Prefixにも適用されます。
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.
エンコード-Address-Prefix上記の形式で、プルーニングされるマルチキャストグループプレフィックス。ネストされた属性グループ、ソース、またはFWDR_PREFの属性は、グループ属性内に直ちにネストされない場合があります。
d) SOURCE (Type Code 3):
d) ソース（タイプコード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.
ソース属性は、特定のソース-Prefixを識別します。さらに、Source属性内に直ちにネストされた属性は、指定されたソース-Prefixにも適用されます。
The SOURCE attribute has the following format:
ソース属性には次の形式があります。
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.
上記の形式のecoded-Address-Prefixソース-Prefix。ネストされた属性グループ、ソース、またはFWDR_PREF属性は、ソース属性内に直ちにネストされることはありません。
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属性内に直ちにネストされたすべてのグループまたはソース属性に対してフォワーダー優先値を提供します。これは、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.
選好値A 32ビットの非陰性整数。ネストされた属性結合、プルーン、または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ビット）値を提供します。これは、BGMPスピーカーによって使用され、受け取った他のBGMPスピーカー（s、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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ビット値。ネストされた属性ソース以外のドキュメント内の属性は、毒属性属性内に直ちにネストされる場合があります。
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.
以下は、ネストされた属性を使用してさまざまな更新がどのように構築されるかの列挙例です。ここで、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 )
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メッセージはピア間で十分なほど十分に交換されます。送信された最後のKeepAliveまたは更新メッセージの間の合理的な最大時間、およびKeepaliveメッセージが送信される時間は、保留時間間隔の3分の1になります。KeepAliveメッセージは、1秒あたり1秒よりも頻繁に送信してはなりません。実装は、保留時間間隔の関数としてKeepAliveメッセージを送信するレートを調整する場合があります。
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
ネゴシエートされた保持時間間隔がゼロの場合、定期的なkeepAliveメッセージを送信する必要はありません。
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-OCTET Unsigned Integerは、通知のタイプを示します。次のエラーコードが定義されています。
Error Code Symbolic Name Reference
エラーコードシンボリック名参照
1 Message Header Error Section 9.1
1メッセージヘッダーエラーセクション9.1
2 OPEN Message Error Section 9.2
2オープンメッセージエラーセクション9.2
3 UPDATE Message Error Section 9.3
3更新メッセージエラーセクション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-OCTET Unsigned Integerは、報告されたエラーの性質に関するより具体的な情報を提供します。各エラーコードには、1つ以上のエラーサブコードが関連付けられている場合があります。適切なエラーサブコードが定義されていない場合、エラーサブコードフィールドにゼロ（非特異的）値が使用されます。以下の表記（MC）は、エラーが致命的なものであり、Oビットが明確でなければならないことを示しています。Obitセットでは、脂肪性以外のサブコードを送信する必要があります。
Message Header Error subcodes:
メッセージヘッダーエラーサブコード：
2 - Bad Message Length (MC) 3 - Bad Message Type (MC)
2-悪いメッセージの長さ（MC）3-悪いメッセージタイプ（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)
1-サポートされていないバージョン（MC）4-サポートされていないオプションパラメーター5-認証障害（MC）6-受け入れられない保留時間（MC）7-サポートされていない機能（MC）
UPDATE Message Error subcodes:
メッセージエラーサブコードを更新：
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-認識されていないアドレスファミリデータ：この可変長さのフィールドは、通知の理由を診断するために使用されます。データフィールドの内容は、エラーコードとエラーサブコードによって異なります。詳細については、以下のセクション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.
メッセージヘッダーの処理中に検出されたすべてのエラーは、エラーコードメッセージヘッダーエラーを使用して通知メッセージを送信することにより示されます。エラーサブコードは、エラーの特定の性質について詳しく説明します。
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未満または4096を超える場合、または開いたメッセージの長さフィールドが開いているメッセージの最小長より少ない場合、または更新メッセージの長さフィールドがより少ない場合更新メッセージの最小長さ、または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.
メッセージヘッダーのタイプフィールドが認識されていない場合、エラーサブコードは悪いメッセージタイプに設定されます。データフィールドには、誤ったタイプフィールドが含まれています。
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.
オープンメッセージの処理中に検出されたすべてのエラーは、エラーコードを開くメッセージエラーを使用して通知メッセージを送信することにより示されます。エラーサブコードは、エラーの特定の性質について詳しく説明します。
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).
受信したオープンメッセージのバージョンフィールドに含まれるバージョン番号がサポートされていない場合、エラーサブコードはサポートされていないバージョン番号に設定されます。データフィールドは2-OCTET Unsigned Integerです。これは、リモートBGMPピア入札（受信したオープンメッセージに示されているように）よりもローカルでサポートされている最大のバージョン数が少ないことを示しています。
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.
開いたメッセージの保持時間フィールドが受け入れられない場合、エラーサブコードは許容できない保留時間に設定する必要があります。実装は、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.
オープンメッセージのオプションパラメーターの1つが認識されていない場合、エラーサブコードはサポートされていないオプションパラメーターに設定されます。
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.
オープンメッセージに認証情報（オプションのパラメーターとして）が含まれている場合、対応する認証手順が呼び出されます。認証手順（認証コードと認証データに基づく）が失敗した場合、エラーサブコードは認証障害に設定されます。
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.
開いたメッセージが、ピアが受信者が必要とする機能をサポートしていないことを示している場合、受信者はピアに通知メッセージを送信し、ピアリングを終了することができます。メッセージのエラーサブコードは、サポートされていない機能に設定されています。通知メッセージのデータフィールドには、スピーカーがメッセージを送信する一連の機能がリストされています。そのような各機能は、受信したオープンメッセージでエンコードされたのと同じ方法でエンコードされます。
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.
ある属性のエンコードされたアドレス-Prefixフィールドが構文的に間違っている場合、エラーサブコードは無効なプレフィックスフィールドに設定されます。
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.
ピアが通知メッセージを送信し、そのメッセージにエラーがある場合、残念ながら後続の通知メッセージを介してこのエラーを報告する手段はありません。認識されていないエラーコードやエラーサブコードなどのこのようなエラーは、注意し、ローカルにログに記録し、ピアの管理に注意を払う必要があります。ただし、これを行う手段は、このドキュメントの範囲外です。
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.
システムが開かれたメッセージの保留時間フィールドで指定された期間内に継続的なキープライブおよび/または更新および/または通知メッセージを受信しない場合、Hold Timerの有効期限が切れたエラーコードを持つ通知メッセージを送信し、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有限状態マシンによって検出されたエラー（予期しないイベントの受領など）は、エラーコード有限状態マシンエラーを使用して通知メッセージを送信することにより示されます。
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つの並列接続が形成される可能性があります。この状況を接続衝突と呼びます。明らかに、これらの接続の1つを閉じる必要があります。
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 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接続を保存するかを検出するための規則が確立されます。条約は、衝突に関与するピアのBGMP識別子を比較し、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:
オープンメッセージを受信すると、ローカルシステムは、OpenConfirm状態にあるすべての接続を調べなければなりません。BGMPスピーカーは、プロトコルの外側の手段でピアのBGMP識別子を知っている場合、オープンな状態での接続を調べることもできます。これらの接続の中に、BGMP識別子がオープンメッセージのものと等しいリモート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識別子と比較されます（オープンメッセージで指定されています）。
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識別子の値がリモートのものよりも小さい場合、ローカルシステムは既に存在する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-OCTET Long）unsigned Integerとして扱うことによって行われます。
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接続との接続衝突により、新しく作成された接続が無条件の閉鎖を引き起こします。アイドル状態、接続、またはアクティブ状態の接続では、接続衝突を検出できないことに注意してください。
Closing the BGMP connection (that results from the collision resolution procedure) is accomplished by sending the NOTIFICATION message with the Error Code Cease.
BGMP接続（衝突解決手順から生じる）を閉じることは、エラーコードが停止して通知メッセージを送信することで実現されます。
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接続を開くために複数の試みを行うことにより、各サポートを開始することにより、プロトコルのバージョンをネゴシエートする場合があります。オープン試行がエラーコードオープンメッセージエラーとエラーサブコードのサポートバージョン番号で失敗した場合、BGMPスピーカーは試したバージョン番号、ピアを試したバージョン番号、通知でピアによって渡されたバージョン番号を使用できます。メッセージ、およびサポートするバージョン番号。2人のピアが1つ以上の一般的なバージョンをサポートしている場合、これにより、最高の一般的なバージョンを迅速に決定できます。BGMPバージョンのネゴシエーションをサポートするために、BGMPの将来のバージョンは、オープンおよび通知メッセージの形式を保持する必要があります。
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ピアに開かれたメッセージを送信すると、メッセージには機能と呼ばれるオプションのパラメーターが含まれる場合があります。パラメーターは、スピーカーによってサポートされる機能をリストします。
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スピーカーは、スピーカーがピアから受信するオープンメッセージによって伝達される機能に存在する機能に存在する機能のリストを調べることにより、ピアがサポートする機能を決定します。
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リソースを初期化し、ConnectRetryタイマーを開始し、他のBGMPピアへのトランスポート接続を開始し、リモートBGMPによって開始される可能性のある接続をリッスンしますピア、そしてその状態を変更して接続します。ConnectRetryタイマーの正確な値はローカルな問題ですが、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 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.
BGMPスピーカーがエラーを検出した場合、接続をシャットダウンし、状態をアイドル状態に変更します。アイドル状態から抜け出すには、スタートイベントの生成が必要です。このようなイベントが自動的に生成された場合、永続的なBGMPエラーは、スピーカーの永続的な羽ばたきになる場合があります。このような状態を避けるために、エラーのために以前にアイドル状態に移行していたピアについて、開始イベントをすぐに生成しないことをお勧めします。エラーのために以前にアイドルに移行したピアの場合、そのようなイベントが自動的に生成された場合、開始イベントの連続した生成の間の時間は指数関数的に増加します。初期タイマーの値は60秒でなければなりません。連続した再試行ごとに時間が2倍になります。
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.
トランスポートプロトコル接続が成功した場合、ローカルシステムはConnectRetryタイマーをクリアし、初期化を完了し、ピアに開かれたメッセージを送信し、その状態をオープンに変更します。Transport Protocol Connectが失敗した場合（たとえば、再送信タイムアウトなど）、ローカルシステムがConnectRetryタイマーを再起動し、リモート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.
ConnectRetryタイマーの期限切れイベントに応じて、ローカルシステムはConnectRetryタイマーを再起動し、他の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.
トランスポートプロトコル接続が成功した場合、ローカルシステムはConnectRetryタイマーをクリアし、初期化を完了し、ピアに開かれたメッセージを送信し、ホールドタイマーを大きな価値に設定し、状態をオープンに変更します。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.
ConnectRetryタイマーの期限切れイベントに応じて、ローカルシステムはConnectRetryタイマーを再起動し、他の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アドレスが予想されるものではない場合、ローカルシステムはConnectRetryタイマーを再起動し、試行された接続を拒否し、聞き続けます。リモート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:
オープンな状態：
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はピアからの開かれたメッセージを待ちます。開いたメッセージが受信されると、すべてのフィールドに正確さが確認されます。BGMPメッセージヘッダーのチェックまたは開きメッセージチェックがエラー（セクション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.
オープンメッセージにエラーがない場合、BGMPはキープライブメッセージを送信し、キープライブタイマーを設定します。もともと大きな値（上記参照）に設定されていたホールドタイマーは、交渉された保留時間値に置き換えられます（セクション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接続を閉じ、ConnectRetryタイマーを再起動し、リモートBGMPピアによって開始される可能性のある接続を聞き続け、アクティブ状態に入ります。
If the Hold Timer expires, the local system sends NOTIFICATION message with error code Hold Timer Expired and changes its state to 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.
STOPイベント（システムまたはオペレーターのいずれかによって開始される）に応じて、ローカルシステムはエラーコードの停止で通知メッセージを送信し、状態をアイドル状態に変更します。
The Start event is ignored in the OpenSent 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.
他のイベントに応じて、ローカルシステムはエラーコードの有限状態マシンエラーを使用して通知メッセージを送信し、状態をアイドル状態に変更します。
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が状態をOpensentからIDLEに変更すると、BGMP（および輸送レベル）接続を閉じ、その接続に関連するすべてのリソースをリリースします。
OpenConfirm state:
OpenConfirm州：
In this state BGMP waits for a KEEPALIVE or NOTIFICATION message.
この状態では、BGMPはキープライブまたは通知メッセージを待ちます。
If the local system receives a KEEPALIVE message, it changes its state to Established.
ローカルシステムがキープライブメッセージを受信した場合、状態を確立するまで変更します。
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メッセージが受信される前にHoldタイマーが期限切れになった場合、ローカルシステムはError Code Hold Timerの有効期限が切れ、その状態をアイドル状態に変更します。
If the local system receives a NOTIFICATION message, it changes its state to Idle.
ローカルシステムが通知メッセージを受信した場合、状態をアイドル状態に変更します。
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer.
Keepalive Timerが期限切れになった場合、ローカルシステムはKeepAliveメッセージを送信し、KeepAliveタイマーを再起動します。
If a disconnect notification is received from the underlying transport protocol, the local system changes its state to 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.
STOPイベント（システムまたはオペレーターのいずれかによって開始される）に応じて、ローカルシステムはエラーコードの停止で通知メッセージを送信し、状態をアイドル状態に変更します。
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.
他のイベントに応じて、ローカルシステムはエラーコードの有限状態マシンエラーを使用して通知メッセージを送信し、状態をアイドル状態に変更します。
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がOpenConfirmからアイドル状態に状態を変更すると、BGMP（および輸送レベル）接続を閉じ、その接続に関連するすべてのリソースをリリースします。
Established state:
確立された州：
In the Established state BGMP can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer.
確立された状態では、BGMPはピアと更新、通知、およびキープリベーションメッセージを交換できます。
If the local system receives an UPDATE or KEEPALIVE message, it restarts its Hold Timer, if the negotiated Hold Time value is non-zero.
ローカルシステムが更新またはKeepaliveメッセージを受信した場合、交渉された保留時間値がゼロでない場合、ホールドタイマーを再起動します。
If the local system receives a NOTIFICATION message, it changes its state to 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.
ローカルシステムが更新メッセージを受信し、更新メッセージエラー処理手順（セクション6.3を参照）がエラーを検出すると、ローカルシステムは通知メッセージを送信し、状態をアイドル状態に変更します。
If a disconnect notification is received from the underlying transport protocol, the local system changes its state to 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.
ホールドタイマーの有効期限が切れた場合、ローカルシステムはエラーコードの有効期限が切れ、その状態をアイドル状態に変更して通知メッセージを送信します。
If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer.
Keepalive Timerが期限切れになった場合、ローカルシステムはKeepAliveメッセージを送信し、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または更新メッセージを送信するたびに、交渉された保持時間値がゼロでない限り、KeepAliveタイマーを再起動します。
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.
STOPイベント（システムまたはオペレーターのいずれかによって開始された）に応じて、ローカルシステムはエラーコードが停止した通知メッセージを送信し、状態をアイドル状態に変更します。
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.
他のイベントに応じて、ローカルシステムはエラーコードの有限状態マシンエラーを備えた通知メッセージを送信し、その状態をアイドル状態に変更します。
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が確立された状態からアイドル状態まで状態を変更すると、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、Tony Ballardie、Steve Casner、Steve Deering、Deborah Estrin、Dino Farinacci、Bill Fenner、Mark Handley、Ahmed Helmy、Van Jacobson、Dave Meyer、そしてサティシュ・クマール。
This document is the product of the IETF BGMP Working Group with Dave Thaler as editor.
このドキュメントは、Dave Thalerを編集者としてIETF BGMPワーキンググループの製品です。
Rusty Eddy, Isidor Kouvelas, and Pavlin Radoslavov also provided valuable feedback on this document.
Rusty Eddy、Isidor Kouvelas、およびPavlin Radoslavovも、この文書に関する貴重なフィードバックを提供しました。
[INTEROP] Thaler, D., "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999.
[Interop] Thaler、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[V6PREFIX] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[V6Prefix] Haberman、B。およびD. Thaler、「Unicast-Prefixベースの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. Li、「Border Gateway Protocol 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] Bates、T.、Rekhter、Y.、Chandra、R。、およびD. Katz、「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。and S. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[Mospf] Moy、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] Adams、A.、Nicholas、J。and W. Siadak、「プロトコル独立マルチキャスト - 濃度モード（PIM -DM）：プロトコル仕様（改訂）」、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.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M.、Jacobson、V.、Liu、C.、Sharma、P。、およびL。Wei、「プロトコル独立したマルチキャストスパールモード（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.
[反射] Bates、T。およびR. Chandra、「BGPルートリフレクション：フルメッシュIBGPの代替」、RFC 1966、1996年6月。
[V4PREFIX] Thaler, D., "Unicast-Prefix-based IPv4 Multicast Addresses", Work in Progress, August 2004.
[V4Prefix] Thaler、D。、「Unicast-PrefixベースのIPv4マルチキャストアドレス」、2004年8月、Work in Progress。
Authors' Address
著者の住所
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
Dave Thaler Microsoft One Microsoft Way Redmond、WA 98052
EMail: dthaler@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。