RFC3913 日本語訳
3913 Border Gateway Multicast Protocol (BGMP): Protocol Specification.D. Thaler. September 2004. (Format: TXT=97443 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Thaler Request for Comments: 3913 Microsoft Category: Informational September 2004
ターレルがコメントのために要求するワーキンググループD.をネットワークでつないでください: 3913年のマイクロソフトカテゴリ: 情報の2004年9月
Border Gateway Multicast Protocol (BGMP):
Protocol Specification
ゲートウェイマルチキャストプロトコル(BGMP)に接してください: プロトコル仕様
Status of this Memo
この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).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports "source-specific multicast" (SSM). To also support "any-source multicast" (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) with different domains. Each of these domains then becomes the root of the shared domain- trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants.
このドキュメントは相互ドメインマルチキャストルーティングのためにBorderゲートウェイMulticastプロトコル(BGMP)、プロトコルについて説明します。 BGMPは活動的なマルチキャストグループのために共有された木を建てて、ソース特有の相互ドメインを造るために任意に受信機ドメインを許容して、分配は必要であるところで分岐します。 BGMP nativelyは「ソース特有のマルチキャスト」(SSM)を支持します。 サポート、も「いくらか、-、ソース、」 マルチキャスト(ASM)、BGMPはそれぞれのマルチキャストグループがただ一つの根に関連しているのを必要とします(BGMPでは、それは根のドメインと呼ばれます)。 それは、マルチキャストアドレス空間の異なった範囲が異なったドメインに関連しているのを(例えば、基づくUnicast接頭語Multicastアドレシングがある)必要とします。 そして、それぞれのこれらのドメインは範囲のすべてのグループのための共有されたドメイン木の根になります。 セッション創始者のアドレスアロケータがそれ自身のドメインのスペースの地域からのアドレスを選択すると、一般に、マルチキャスト関係者は、より良いマルチキャストサービスを受けるでしょう、その結果、少なくともセッション関係者のひとりにとって、根のドメインが地方であることを引き起こします。
Thaler Informational [Page 1] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[1ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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
1. 目的。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 用語。 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. 概観について議定書の中で述べてください。 . . . . . . . . . . . . . . . . . . . . . . 5 3.1. 原理. . . . . . . . . . . . . . . . . . . . 7 4を設計してください。 詳細. . . . . . . . . . . . . . . . . . . . . . . 8 4.1について議定書の中で述べてください。 EGP. . . . . . . . . . . . . . . . 8 4.2との相互作用。 マルチキャストデータ・パケット処理. . . . . . . . . . . . 9 4.3。 Join、Pruneメッセージ、および通知のBGMP処理。 . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. 受信は接合します。 . . . . . . . . . . . . . . . . 10 4.3.2. プルーンの通知を受け取ります。 . . . . . . . . . 11 4.3.3. ルート変更届出書. . . . . . 12 4.3.4を受け取ります。 毒逆メッセージを受け取ります(S、G)。 . . . . 12 4.4. M-IGPの部品との相互作用。 . . . . . . . . . . . 13 4.4.1. DVMRPとPIM-DMとの相互作用。 . . . . . . . 14 4.4.2. PIM-Smとの相互作用。 . . . . . . . . . . . . 15 4.4.3. CBT. . . . . . . . . . . . . . 16 4.4.4との相互作用。 MOSPF. . . . . . . . . . . . . 17 4.5との相互作用。 マルチアクセスネットワーク. . . . . . . . . . 17 4.6の上の操作。 (S、G)状態とG-ルート.185の間の相互作用。 メッセージ・フォーマット。 . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. メッセージヘッダー形式。 . . . . . . . . . . . . . . . . . 19 5.2. メッセージ・フォーマットを開いてください。 . . . . . . . . . . . . . . . . . . 19 5.3. メッセージ・フォーマットをアップデートしてください。 . . . . . . . . . . . . . . . . . 23 5.4. 例をコード化します。 . . . . . . . . . . . . . . . . . . . 27 5.5. KEEPALIVEメッセージ・フォーマット. . . . . . . . . . . . . . . . 27 5.6。 通知メッセージ形式。 . . . . . . . . . . . . . . 28 6. BGMPエラー処理。 . . . . . . . . . . . . . . . . . . . . . 30 6.1. メッセージHeaderエラー処理。 . . . . . . . . . . . . . 30 6.2. オープンメッセージエラー処理。 . . . . . . . . . . . . . . 30 6.3. UPDATEメッセージエラー処理。 . . . . . . . . . . . . . 31 6.4. NOTIFICATIONメッセージエラー処理。 . . . . . . . . . . 32 6.5. Timer Expiredエラー処理を保持してください。 . . . . . . . . . . . 32 6.6. 有限州Machineエラー処理。 . . . . . . . . . . 32 6.7. やんでください。 . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.8. 接続衝突検出. . . . . . . . . . . . . 32 7。 BGMPバージョン交渉. . . . . . . . . . . . . . . . . . . 33 7.1。 BGMP能力交渉。 . . . . . . . . . . . . . . 34 8. BGMP Finite州マシン。 . . . . . . . . . . . . . . . . . . 34 9. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 38 10. 承認. . . . . . . . . . . . . . . . . . . . . . . 39 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 39 11.1。 引用規格. . . . . . . . . . . . . . . . . . 39 11.2。 有益な参照. . . . . . . . . . . . . . . . . 40作者のアドレスの.40の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 41
Thaler Informational [Page 2] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[2ページ]のRFC3913BGMP: プロトコル仕様2004年9月
1. Purpose
1. 目的
It has been suggested that inter-domain "any-source" multicast is better supported with a rendezvous mechanism whereby members receive sources' data packets without any sort of global broadcast (e.g., MSDP broadcasts source information, PIM-DM [PIMDM] and DVMRP [DVMRP] broadcast initial data packets, and MOSPF [MOSPF] broadcasts membership information). PIM-SM [PIMSM] and CBT [CBT] use a shared group-tree, to which all members join and thereby hear from all sources (and to which non-members do not join and thereby hear from no sources).
それが示された、その相互ドメイン、「いくらか、-、ソース、」 マルチキャストはメンバーがどんな種類のグローバルな放送なしでもソースのデータ・パケットを受ける(例えば、MSDP放送のソース情報、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 nativelyは「ソース特有のマルチキャスト」(SSM)を支持します。 サポート、も「いくらか、-、ソース、」 マルチキャスト(ASM)、BGMPは活動的なマルチキャストグループのために共有された木を建てて、必要であるところにソース特有の相互ドメイン、分配ブランチを建てるためにドメインを許容します。 PIM-SMとCBTからの概念を当てにして、BGMPは、それぞれのグローバルなマルチキャストグループがただ一つの根に関連しているのを必要とします。 しかしながら、BGMPでは、根は、ただ一つのルータよりむしろ全体の交換かドメインです。
For non-source-specific groups, BGMP assumes that ranges of the multicast address space have been associated (e.g., with Unicast- Prefix-Based Multicast [V4PREFIX,V6PREFIX] addressing) with selected domains. Each such domain then becomes the root of the shared domain-trees for all groups in its range. An address allocator will generally achieve better distribution trees if it takes its multicast addresses from its own domain's part of the space, thereby causing the root domain to be local.
非ソースの詳細グループのために、BGMPは、マルチキャストアドレス空間の範囲が選択されたドメインに関連していると(例えば、Unicastベースの接頭語Multicast[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関係を形成します。 次に、彼らは増加で発信します。グループ会員資格としてのJoin/プルーンのUpdatesは変化します。 BGMPは必要でない、周期的である、個人出場者をリフレッシュしてください。 接続の活性を確実にするために定期的にKeepAliveメッセージを送ります。 誤りか特別な状態に対応して通知メッセージを送ります。 接続がエラー条件に遭遇するなら、通知メッセージを送ります、そして、接続は誤りが致命的なものであるなら閉じます。
Thaler Informational [Page 3] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[3ページ]のRFC3913BGMP: プロトコル仕様2004年9月
2. Terminology
2. 用語
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セットの、より隣接の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-IGPsの典型的な例は以下の通りです。 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: 使用中のinterdomainユニキャストルーティング・プロトコルのための総称。 これはMulticast RIBを支持できるBGPの通常、何らかのバージョンになるでしょう、MBGP[MBGP]などのように、ユニキャストとマルチキャストアドレス接頭語の両方を含んでいて。
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)をそのドメインへ走らせる境界ルータの関連していて(論理的に内面)のa特定のドメインの部分 その結果、各境界ルータは経路ドメインの中にゼロか、より多くのコンポーネントを持っています。 さらに、どんな経路ドメインの中でも転ばない外部のリンクがある各境界ルータには、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.
外部の同輩: (自律システムで、BGPで中古)の別のマルチキャストASの境界ルータ。(BGMP TCP-接続はASにオープンです)。 また、BGPがEGPとして使用されていると、別々の"eBGP"TCP-接続は同じ同輩にとってオープンになるでしょう。
Thaler Informational [Page 4] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[4ページ]のRFC3913BGMP: プロトコル仕様2004年9月
Internal peer:
Another border router of the same multicast AS. If BGP is being
used as the EGP, the border router either speaks iBGP ("internal"
BGP) directly to internal peers in a full mesh, or indirectly
through a route reflector [REFLECT].
内部の同輩: 同じマルチキャストASの別の境界ルータ。 BGPがEGPとして使用されているなら、境界ルータは間接的に完全なメッシュか、ルート反射鏡[REFLECT]を通してiBGP(「内部」のBGP)を直接内部の同輩に話します。
Next-hop peer:
The next-hop peer towards a given IP address is the next EGP
router on the path to the given address, according to multicast
RIB routes in the EGP's routing table (e.g., in MBGP, routes whose
Subsequent Address Family Identifier field indicates that the
route is valid for multicast traffic).
次のホップ同輩: 与えられたIPアドレスに向かった次のホップ同輩は与えられたアドレスへの経路の次のEGPルータです、EGPの経路指定テーブル(例えば、MBGPのSubsequent Address Family Identifier分野がマルチキャスト交通に、ルートが有効であることを示すルート)のマルチキャストRIBルートによると。
target:
Either an EGP peer, or an M-IGP component.
以下を狙ってください。 EGP同輩かM-IGPの部品のどちらか。
Tree State Table:
This is a table of (S-prefix,G) and (*,G-prefix) entries that have
been explicitly joined by a set of targets. Each entry has, in
addition to the source and group addresses and masks, a list of
targets that have explicitly requested data (on behalf of directly
connected hosts or downstream routers). (S,G) entries also have
an "SPT" bit.
木のステートテーブル: これは(S-接頭語、G)のテーブルであり、(*、G接頭語)は1セットの目標によって明らかに参加されたエントリーです。 各エントリーはソースとグループに加えてアドレスとマスク(明らかに、データ(直接接続されたホストか川下のルータを代表した)を要求した目標のリスト)を持っています。 (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].
キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」は中[RFC2119]で説明されるように本書では解釈されることになっているべきです。
3. Protocol Overview
3. プロトコル概観
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の部品からの通知に対応してグループ接頭語状態を維持します。 グループによって共有された木はドメインにグループ接頭語の広告を出すのにおいてそれらのグループをカバーするのにおいて根づいています。 受信機が特定のグループアドレスを接合するとき、根のドメインに向かった境界ルータはグループ特有のJoinメッセージを発生させます(図1を見てください)。(次に、それは、Borderルータごとに根のドメインに向かって転送されます)。 BGMP同輩の間のTCP接続の上にBGMP JoinとPruneメッセージを送ります、そして、定期的にTCPの上に送られたKEEPALIVEメッセージはBGMPプロトコル状態をリフレッシュします。
BGMP routers build group-specific bidirectional forwarding state as they process the BGMP Join messages. Bidirectional forwarding state means that packets received from any target are forwarded to all other targets in the target list without any RPF checks. No group- specific state or traffic exists in parts of the network where there are no members of that group.
BGMP Joinメッセージを処理するとき、BGMPルータはグループ特有の双方向の推進状態を造ります。 双方向の推進州は、どんな目標からも受け取られたパケットが少しもRPFチェックなしで目標リストの他のすべての目標に送られることを意味します。 どんなグループの特定の州も交通もそのグループのメンバーが全くいないネットワークの部分に存在していません。
Thaler Informational [Page 5] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[5ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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-IGPsによって使用されるソースの特定の木(SPTs)と互換性があるか(例えば、DVMRP、PIM-DM、またはPIM-SM)、またはソース特有のグループのために木を組み立てるのに必要であるだけであるところで。 SPTベースのM-IGPを使用するドメインは、その結果「代理」として機能する外部電源と異なった境界ルータ(M-IGP RPFチェックと互換性がある)でマルチキャストパケットを注入する必要があるかもしれません。 例えば、Transit_1ドメインでは、Srcからのデータを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)
根_ドメイン[BR91]--------------------------\ | | [BR32][BR41]トランジット_3トランジット_4[BR31][BR42][BR43]| | | [BR22][BR52][BR53]トランジット_2トランジット_5[BR21][BR51]| | [BR12][BR61]トランジット_1[BR11]----------[BR62]スタッブ_6[BR13](Src)| (Rcvr) ------------------- | | [BR71][BR81]Rcvr_スタッブ_7Src_唯一の_スタッブ_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境界ルータを表します。 トランジット_Xはトランジットドメインネットワークです。 *_スタッブ_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
BGMPとM-IGP規則の組み合わせに基づいてデータ・パケットを進めます。 存在しているなら、合っている(S、G)BGMP木に従った1セットの目標へのルータフォワードはエントリーを述べます。 見つけられないなら、ルータは合っている(*、G)BGMP木の州のエントリーがないかどうかチェックします。 どちらも見つけないなら、Gのためにネイティブに次のホップEGP同輩にパケットを送ります、Multicast RIB(例えば図1のSrc_Bなどの非会員送付者の場合で)によると。 合っているエントリーがそうであったなら、見つけられて、目標の他のすべての目標にパケットを送ります。
Thaler Informational [Page 6] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[6ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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の部品であるなら、推進はそのM-IGPプロトコルの規則を受けることがあります。
3.1. Design Rationale
3.1. デザイン原理
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]の中に共有された木を建てます。 デザイン選択は特にInter-ドメインマルチキャストの私たちの焦点からBGMP結果になりました。 PIM-SMとCBTによってされたデザイン選択は広い領域イントラドメインケースに合うほうがよいです。 BGMPと他の共有された木のプロトコルの間には、3つの主要な違いがあります:
(1) Unidirectional vs. Bidirectional trees
(1) 単方向対Bidirectional木
Bidirectional trees (using bidirectional forwarding state as described above) minimize third party dependence which is essential in the inter-domain context. For example, in Figure 1, stub domains 7 and 8 would like to exchange multicast packets without being dependent on the quality of connectivity of the root domain. However, unidirectional shared trees (i.e., those using RPF checks) have more aggressive loop prevention and share the same processing rules as source-specific entries which are inherently unidirectional.
双方向の木(上で説明されるように双方向の推進状態を使用する)は相互ドメイン文脈で不可欠の第三者の依存を最小にします。 例えば、図1では、根のドメインの接続性の品質に依存していなくて、スタッブドメイン7と8はマルチキャストパケットを交換したがっています。 しかしながら、単方向の共有された木(すなわち、RPFチェックを使用するもの)は、本来単方向であるソース特有のエントリーとして、より攻撃的な輪の防止を持って、同じ処理規則を共有します。
The lack of third party dependence concerns in the INTRA domain case reduces the incentive to employ bidirectional trees. BGMP supports bidirectional trees because it has to, and because it can without excessive cost.
INTRAドメイン場合における第三者依存関心の不足は双方向の木を使う誘因を減少させます。 BGMPは、そうしなければならなくて、過度の費用なしで支持できるので、双方向の木を支持します。
(2) Source-specific distribution trees/branches
(2) ソース特有の分配木/ブランチ
In a departure from other shared tree protocols, source-specific BGMP state is built ONLY where (a) it is needed to pull the multicast traffic down to a BGMP router that has source-specific (S,G) state, and (b) that router is NOT already on the shared tree (i.e., has no (*,G) state), and (c) that router does not want to receive packets via encapsulation from a router which is on the shared tree. BGMP provides source-specific branches because most M-IGP protocols in use today build source-specific trees. BGMP's source-specific branches eliminate the unnecessary overhead of encapsulations for high data rate sources from the shared tree's ingress router to the surrogate injector (e.g., from BR12 to BR11 in Figure 1). Moreover, cases in which shared paths are significantly longer than SPT paths will also benefit.
他の共有された木のプロトコルからの出発では、ソース特有のBGMP状態は(a) それがマルチキャスト交通をソース特有(S、G)の状態を持っているBGMPルータまで引くのに必要であり、(b) 共有された木(すなわち、いいえ(*、G)、状態を持っている)の上にそのルータが既になくて、(c) そのルータが共有された木の上にあるルータからのカプセル化でパケットを受けたがっていないところだけに造られます。 使用中のほとんどのM-IGPプロトコルが今日ソース特有の木を建てるので、BGMPはソース特有のブランチを提供します。 BGMPのソース特有のブランチは共有された木のイングレスルータから代理のインジェクタ(例えば、BR12から図1の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
しかしながら、ソース特有のグループ分配木以外に、(a) 相互ドメインの接続性がイントラドメインより一般に豊かでないので、私たちは一般に、ソース特有の相互ドメイン木を建てません。
Thaler Informational [Page 7] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[7ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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.
(b) 接続性、そのように共有された分配木はイントラドメインケースより相互ドメイン文脈にさらに許容できる経路の長さと交通集中の特性を持っているはずです、そして、共有された木の状態をソースの特定の木の状態の上でいつも優先させることによって、私たちはそうでなければ起こることができるあいまいさを避けます。
In summary, BGMP trees are, in a sense, a hybrid between PIM-SM and CBT trees.
概要では、BGMP木はある意味でPIM-SMとCBT木の間のハイブリッドです。
(3) Method of choosing root of group shared tree
(3) グループの根を選ぶ方法は木を共有しました。
The choice of a group's shared-tree-root has implications for performance and policy. In the intra-domain case it is sometimes assumed that all potential shared-tree roots (RPs/Cores) within the domain are equally suited to be the root for a group that is initiated within that domain. In the INTER-domain case, there is far more opportunity for unacceptably poor locality, and administrative control of a group's shared-tree root. Therefore in the intra-domain case, other protocols sometimes treat all candidate roots (RPs or Cores) as equivalent and emphasize load sharing and stability to maximize performance. In the Inter-Domain case, all roots are not equivalent, and we adopt an approach whereby a group's root domain is not random but is subject to administrative control.
グループの共有された木の根の選択には、性能と方針のための意味があります。 イントラドメイン場合では、時々ドメインの中のすべての潜在的共有された木のルーツ(RPs/コア)がそのドメインの中で開始されるグループのための根になるように等しく合っていると思われます。 INTER-ドメイン場合には、容認できないほど貧しい場所のはるかに多くの機会、およびグループの共有された木の根の運営管理コントロールがあります。 したがって、イントラドメイン場合では、他のプロトコルは、時々同等なすべての候補の同じくらいルーツ(RPsかCores)を処理して、性能を最大にするために負荷分割法と安定性を強調します。 Inter-ドメイン場合では、すべてのルーツが同等であるというわけではありません、そして、私たちはグループの根のドメインが無作為ではありませんが、運営管理コントロールを受けることがあるアプローチを取ります。
4. Protocol Details
4. プロトコルの詳細
In this section, we describe the detailed protocol that border
routers perform. We assume that each border router conforms to the
component-based model described in [INTEROP], modulo one correction
to section 3.2 ("BGMP" Dispatcher), as follows:
このセクションで、私たちは境界ルータが実行する詳細なプロトコルについて説明します。 私たちは、各境界ルータが[INTEROP]で説明されたコンポーネントベースのモデルに従うと思って、法はセクション3.2("BGMP"発送者)への1つの修正です、以下の通りです:
The iif owner of a (*,G) entry is the component owning the next-hop interface towards the nominal root of G, in the multicast RIB.
(*、G)エントリーのiif所有者はGの名目上の根に向かって次のホップインタフェースを所有しているコンポーネントです、マルチキャストRIBで。
4.1. Interaction with the EGP
4.1. EGPとの相互作用
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がMulticast RIBのソースに向かって次のホップを見上げることができなければならない。
(2) For a given non-source-specific group, BGMP will map the group
address to a nominal "root" address, and must be able to look
up the next-hop towards that address in the Multicast RIB.
(2) 当然のことの非ソースの詳細グループにおいて、BGMPは名目上の「根」アドレスにグループアドレスを写像して、Multicast RIBのそのアドレスに向かって次のホップを見上げることができなければなりません。
Thaler Informational [Page 8] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[8ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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接頭語ベースのMulticastアドレスであるなら、名目上の根のアドレスは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であるならそうする名目上の根です:、:. (事実上、このアドレスはサブネットルータanycastアドレス[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接頭語ベースのMulticast Address以外のどんなアドレスも使用するどんなソースマルチキャストのサポートもあります。
4.2. Multicast Data Packet Processing
4.2. マルチキャストデータ・パケット処理
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.
パケットを受け入れるなら、ルータは合っている(S、G)エントリーがないかどうか木のステートテーブルをチェックします。 1つが見つけられますが、パケットを次のホップ目標からSに向かって受け取らなかったか(エントリーのSPTビットがTrueであるなら)、または次のホップ目標からGに向かって受け取らなかったなら(エントリーのSPTビットがFalseであるなら)、パケットを落とします、そして、さらなる行動を全く取りません。 いいえ(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の名目上の根のために次のホップ同輩に向かってパケットを送ります、Multicast RIBによると。 合っているエントリーがそうであったなら、見つけられて、目標リストの他のすべての目標にパケットを送ります。
Thaler Informational [Page 9] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[9ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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の部品が、パケットが進められることを意味するということである目標に進めて、そのコンポーネントのマルチキャスト推進に従ってインタフェースがそのコンポーネントで所有していたいずれも外で統治します。
4.3. BGMP processing of Join and Prune messages and notifications
4.3. Join、Pruneメッセージ、および通知のBGMP処理
4.3.1. Receiving Joins
4.3.1. 受信は接合します。
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.
さもなければ、1つはノー(*、G)か(S、G)エントリーが見つけられたなら作成されます。 a(*、G)の場合では、目標リストはGの名目上の根に向かって次のホップ同輩を含むように初期化されます、それが外部の同輩であるなら。 同輩が内部であるなら、目標リストは、次のホップインタフェースを所有しているM-IGPの部品を含むように初期化されます。 次のホップ同輩が全くいなければ(ドメインの中にGの名目上の根があるので)、目標リストは次のホップコンポーネントを含むように初期化されます。 (*、G)は接合します。(S、G)エントリーが同じGのために存在している、どれ、存在が処理されて、Sに向かった次のホップ同輩とGの名目上の根が異なっていて、BGMPルータは、最初に、(S、G)プルーンのメッセージをソースに向かって送って、(S、G)エントリーのときにSPTビットをきれいにしなければなりません、(*、G)エントリーを起動する前に。
When creating (S,G) state, if the source is internal to the BGMP speaker's domain, a "Poison-Reverse" bit (PR-bit) is set. This bit indicates that the router may receive packets matching (S,G) anyway due to the BGMP speaker being a member of a domain on the path between S and the root domain. (Depending on the M-IGP protocol, it may in fact receive such packets anyway only if it is the best exit for the nominal root of G.)
ソースがBGMPスピーカーのドメインに内部であるなら状態を創設するとき(S、G)、「毒逆」ビット(PRで噛み付いている)は設定されます。 このビットは、ルータがSと根のドメインの間の経路のドメインのメンバーであるBGMPスピーカーのためとにかく(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:
そして、Joinが受け取られた目標は目標リストに追加されます。 そして、ルータは、次のホップEGP同輩を見つけるためにSかMulticast RIBのGの名目上の根を見上げます。 (*、G)エントリーへのGに向かって次のホップ目標を含まない目標リストがその結果非ヌルであるのになるなら、以下の通り次のホップEGP同輩に通知しなければなりません:
a) If the next-hop peer towards the nominal root of G (for a (*,G)
entry) is an external peer, a BGMP (*,G) Join message is unicast
to the external peer. If the next-hop peer towards S (for an
(S,G) entry) is an external peer, and the router does NOT have any
active (*,G) state for that group address G, a BGMP (S,G) Join
message is unicast to the external peer. A BGMP (S,G) Join
a) 次のホップであるなら、G((*、G)エントリーへの)の名目上の根に向かった同輩は外部の同輩です、BGMP(*、G) 接合してください。メッセージは外部の同輩へのユニキャストです。 次のホップであるなら、S((S、G)エントリーへの)に向かった同輩は外部の同輩です、そして、ルータには、そのグループアドレスGのための少しの活動的な(*、G)状態もありません、BGMP(S、G) 接合してください。メッセージは外部の同輩へのユニキャストです。 BGMP(S、G) 接合してください。
Thaler Informational [Page 10] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[10ページ]のRFC3913BGMP: プロトコル仕様2004年9月
message is never sent to an external peer by a router that also
contains active (*,G) state for the same group. If the next-hop
peer towards S (for an (S,G entry) is an external peer and the
router DOES have active (*,G) state for that group G, the SPT bit
is always set to False.
また、同じグループに、活動的な(*、G)状態を含むルータは外部の同輩にメッセージを決して送りません。 Sに向かった次のホップ同輩である、((S、Gエントリー)は外部の同輩であり、ルータDOESには、そのグループGに、活動的な(*、G)状態があって、SPTビットはいつもFalseに設定されます。
b) If the next-hop peer is an internal peer, a (*,G) or (S,G) Join
alert is sent to the M-IGP component owning the next-hop
interface.
b) 次のホップ同輩は内部の同輩であるか、そして、a(*、G)か(S、G) 警戒を接合してください。次のホップインタフェースを所有しながら、M-IGPの部品に送ります。
c) If there is no next-hop peer, a (*,G) or (S,G) Join alert is sent
to the M-IGP component owning the next-hop interface.
c) 同輩、a(*、G)は次に跳んでいるか、そして、(S、G) 警戒を接合してください。次のホップインタフェースを所有しながら、M-IGPの部品に送ります。
Finally, if an (S,G) Join is received from an internal peer, the peer should be stored with the M-IGP component target. If (S,G) state exists with the PR-bit set, and the next-hop towards the nominal root for G is through the M-IGP component, an (S,G) Poison-Reverse message is immediately sent to the internal peer.
最終的である、(S、G)が接合する、内部の同輩から受け取られていて、同輩はM-IGPコンポーネント目標で格納されるべきです。 (S、G)状態がPRビットセットで存在していて、M-IGPの部品を通ってGのための名目上の根に向かった次のホップがあるなら、すぐに、(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)毒逆メッセージを外部の同輩に送ります。
4.3.2. Receiving Prune Notifications
4.3.2. プルーンの通知を受け取ります。
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.
(S、G)はBGMPの部品がa(*、G)を受けるか、別のコンポーネントから警戒を剪定するか、または外部の同輩からBGMP(*、G)か(S、G)プルーンのメッセージを剪定するとき、それは合っているエントリーのための木のステートテーブルを捜します。 いいえ(S、G)、エントリーが(S、G)プルーンのために見つけられましたが、存在しているなら、(*、G)が、述べる(S、G)エントリーは作成されます、目標リストが(*、G)エントリーからコピーされている状態で。 合っているエントリーが全く存在していないか、または目標リストにコンポーネントか同輩を記載しないなら、さらなる行動を全く取りません。
Otherwise, the component or peer is removed from the target list. If the target list becomes null as a result, the next-hop peer towards the nominal root of G (for a (*,G) entry), or towards S (for an (S,G) entry if and only if the BGMP router does NOT have any corresponding (*,G) entry), must be notified as follows.
さもなければ、コンポーネントか同輩が目標リストから取り外されます。 そして、目標リストがG((*、G)エントリーへの)の名目上の根、またはSに関して結果、次のホップ同輩としてヌルになる、((S、G)エントリー、BGMPルータがNOTをする場合にだけ、何か対応(*、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) 次のホップ同輩は内部の同輩であるか、そして、a(*、G)か(S、G) 次のホップインタフェースを所有しているM-IGPの部品にプルーンの警戒を送ります。
Thaler Informational [Page 11] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[11ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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) 同輩、a(*、G)は次に跳んでいるか、そして、(S、G) 次のホップインタフェースを所有しているM-IGPの部品にプルーンの警戒を送ります。
4.3.3. Receiving Route Change Notifications
4.3.3. ルート変更届出書を受け取ります。
When a border router receives a route for a new prefix in the multicast RIB, or a existing route for a prefix is withdrawn, a route change notification for that prefix must be sent to the BGMP component. In addition, when the next hop peer (according to the multicast RIB) changes, a route change notification for that prefix must be sent to the BGMP component.
境界ルータがマルチキャストRIBの新しい接頭語のためにルートを受けるか、または接頭語のための既存のルートがよそよそしいときに、その接頭語のためのルート変更届出書をBGMPの部品に送らなければなりません。 次のホップ同輩(マルチキャストRIBによると)が変化するとき、さらに、その接頭語のためのルート変更届出書をBGMPの部品に送らなければなりません。
In addition, in IPv4 (only), an internal route for each class-D prefix associated with the domain (if any) MUST be injected into the multicast RIB in the EGP by the domain's border routers.
さらに、(単に)のIPv4では、ドメイン(もしあれば)に関連しているそれぞれのクラスD接頭語のための内部のルートをドメインの境界ルータによるEGPのマルチキャストRIBに注がなければなりません。
When a route for a new group prefix is learned, or an existing route for a group prefix is withdrawn, or the next-hop peer for a group prefix changes, a BGMP router updates all affected (*,G) target lists. The router sends a (*,G) Join to the new next-hop target, and a (*,G) Prune to the old next-hop target, as appropriate. In addition, if any (S,G) state exists with the PR-bit set:
新しいグループ接頭語のためのルートが学習されるか、グループ接頭語のための既存のルートがよそよそしいか、またはグループ接頭語のための次のホップ同輩が変化すると、BGMPルータはすべての影響を受ける(*、G)目標リストをアップデートします。 ルータはa(*、G)を送ります。新しい次のホップ目標、および古い次のホップ目標への(*、G)プルーンにつないでください、適宜。 何か(S、G)状態がPRビットで存在するなら、さらに、セットしてください:
o If the BGMP speaker has just become the best exit for the nominal
root of G, an (S,G) Poison Reverse message with the PR-bit set is
sent as noted below.
o BGMPスピーカーがちょうどGの名目上の根のための最も良い出口になったところであるなら、以下に述べられるようにPRビットセットがある(S、G)毒Reverseメッセージを送ります。
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)毒Reverseメッセージを送ります。
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の名目上の根に向かった次のホップインタフェースの同輩を受け取ったということです。
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)を送ります。新しい次のホップ目標、および古い次のホップ目標への(S、G)プルーンにつないでください、適宜。
4.3.4. Receiving (S,G) Poison-Reverse messages
4.3.4. 受信(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
BGMPスピーカーが同輩から(S、G)毒逆メッセージを受け取るとき、それは、メッセージに(S、G)状態のPRビットにPRビットを合わせるように設定して、G.Ifの名目上の根に向かって次のホップを見上げます。次のホップ目標がM-IGPの部品である、それは(S、G)毒Reverseメッセージをそのすべての内部の同輩にコンポーネントで転送します。
Thaler Informational [Page 12] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[12ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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.
それが受けたもの(S、G)は接合します。 次のホップ目標が与えられたインタフェースの外部の同輩であるなら、それはそのインタフェースで(S、G)毒Reverseメッセージをすべての外部の同輩に転送します。
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.
それは、それ自身のもの(S、G)が接合するのを知っています。BGMPスピーカーがPRビットセットで外部の同輩から(S、G)毒逆メッセージを受け取って、スピーカーがいいえと受け取った、(S、G)いかなる他の同輩からも接合する、(例えば、M-IGPだけ、カプセル化のため中で説明されるように状態を持っている、(S、G)5.4、.1、)、不要であり、(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.
(S、G)は接合します。BGMPスピーカーが内部の同輩から(S、G)毒逆メッセージを受け取ったらPRビットで、セットしてください、スピーカーがGの名目上の根のための最も良い出口であり、プルーンの状態を持っている、(S、G)メッセージにプルーンの状態を取り消させて、状態を削除します。
4.4. Interaction with M-IGP components
4.4. M-IGPの部品との相互作用
When an M-IGP component on a border router first learns that there are internally-reached members for a group G (whose scope is larger than that domain), a (*,G) Join alert is sent to the BGMP component. Similarly, when an M-IGP component on a border router learns that there are no longer internally-reached members for a group G (whose scope is larger than a single domain), a (*,G) Prune alert is sent to the BGMP component.
境界ルータのM-IGPの部品が最初に学ぶとき、グループG(範囲はそのドメインより大きいです)の内部的に達しているメンバーがいて、a(*、G)が警戒を接合するのをBGMPの部品に送ります。 境界ルータのM-IGPの部品が、グループG(範囲は単一領域より大きいです)の内部的に達しているメンバーがもういないことを学ぶとき、同様に、(*、G)プルーンの警戒をBGMPの部品に送ります。
At any time, any M-IGP domain MAY decide to join a source-specific branch for some external source S and group G. When the M-IGP component in the border router that is the next-hop router for a particular source S learns that a receiver wishes to receive data from S on a source-specific path, an (S,G) Join alert is sent to the BGMP component. When it is learned that such receivers no longer exist, an (S,G) Prune alert is sent to the BGMP component. Recall that the BGMP component will generate external source-specific Joins only where the source-specific branch does not coincide with the shared tree distribution tree for that group.
(S、G)は警戒を接合します。いつでもどんなM-IGPドメインも、そのa受信機がソース特有の経路にSから受け取りたがっている特定のソースSへの次のホップルータである境界ルータにおけるM-IGPの部品がデータを学ぶいくらかの外部電源のSとグループG.Whenをソース特有のブランチと一緒に楽しむと決めるかもしれない、BGMPの部品に送ります。 そのような受信機がもう存在しないと学習するとき、(S、G)プルーンの警戒をBGMPの部品に送ります。 ソース特有のブランチがそのグループのための共有された木の分配木と同時に起こらないところでBGMPの部品が外部のソース特有のJoinsだけを発生させると思い出してください。
Finally, we will require that the border router that is the next-hop internal peer for a particular address S or the nominal root of G be able to forward data for a matching tree state table entry to all members within the domain. This requirement has implications on specific M-IGPs as follows.
最終的に、私たちは、特定のアドレスSかGの名目上の根のための次のホップの内部の同輩である境界ルータが合っている木のステートテーブルエントリーのためのデータをドメインの中のすべてのメンバーに転送できるのを必要とするつもりです。 この要件で、特定のM-IGPsの上の意味は以下の通りになります。
Thaler Informational [Page 13] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[13ページ]のRFC3913BGMP: プロトコル仕様2004年9月
4.4.1. Interaction with DVMRP and PIM-DM
4.4.1. DVMRPとPIM-DMとの相互作用
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状態が創設されるとき、(*、G)状態が全くその同じグループ((*、G)BGMP状態が存在しているなら(S、G)BGMP州がSPTビットにFalseに設定させるG.)のためになければ、コンポーネントが順番に、BGMP(S、G)を送るBGMPはSに向かった次のホップの外部の同輩でメッセージに加わります。
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に設定して、外部の同輩を示すために入って来るインタフェースをリセットして、BGMP(S、G)プルーンのメッセージをパケットをカプセルに入れっていた境界ルータに送ります(例えば、図1では、BR11は(Src、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.
decapsulatorがPRビットセットで(S、G)毒Reverseメッセージを受け取ると、encapsulator(正常な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は、現在、トランジットドメインで使用されることでそのようなプロトコルをサポートしません。
Thaler Informational [Page 14] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[14ページ]のRFC3913BGMP: プロトコル仕様2004年9月
4.4.2. Interaction with PIM-SM
4.4.2. PIM-Smとの相互作用
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.
次のホップの内部の同輩(RPになる)にGの名目上の根に向かってイントラドメイン木を根づかせるとき、最もわずかなカプセル化/被膜剥離術しかしないでしょう、そのルータが外部電源から最も多くのパケットを一般に受けるので。 これを達成するために、PIM-SMドメインへのそれぞれのBGMP境界ルータはそれが共有されたドメイン木のイングレスルータであるそれらのグループのためにドメインの中でCandidate-RP-広告を送るべきです。 グループGのためのRPである境界ルータが外部のデータ・パケットを受けるとき、M-IGP(すなわち、PIM-SM)の共有された木の送信するインタフェースリストに応じて、それはパケットを進めます。
Other border routers will receive data packets from external sources that are farther down the bidirectional tree of domains. When a border router that is not the RP receives an external packet for which it does not have a source-specific entry, the border router treats it like a local source by creating (S,G) state with a Register flag set, based on normal PIM-SM rules; the Border router then encapsulates the data packets in PIM-SM Registers and unicasts them to the RP for the group. As explained above, the RP for the inter- domain group will be one of the other border routers of the domain.
他の境界ルータはドメインの双方向の木の下側により遠い外部電源からデータ・パケットを受けるでしょう。 RPでない境界ルータがそれがソース特有のエントリーを持っていない外部のパケットを受けるとき、Register旗のセットで状態を創設することによって(S、G)、境界ルータは地元筋のようにそれを扱います、正常なPIM-SM規則に基づいて。 次に、BorderルータはPIM-SM Registersとユニキャストでデータ・パケットをカプセルに入れります。グループのための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は最短パス木に切り替わるかもしれません。 外部電源への最短パスが共有された木のためのグループのイングレスルータであるなら、その境界ルータには状態が既にあるので(*、G)、境界ルータがBGMP(S、G)を引き起こさないBGMPの新しい(S、G)状態は加わります。 しかしながら、外部電源への最短パスがある他の境界ルータであるなら、境界ルータがM-IGP(S、G)に対応してBGMP状態を創設するのが(S、G)警戒を接合します。 それを抑圧するためにどんな地方(*、G)の状態もないので、この場合ルータがBGMP(S、G)を送る境界はSに向かった次のホップの外部の同輩につなぎます、直接データを引き下げるために。 (図1でBR11を見ます。) 通常のPIM-SM操作のように、(*、G)を持って、異なった入って来るインタフェースへの指すことを述べる(S、G)それらのPIM-SMルータが共有された木でそのソースを剪定するでしょう。 したがって、すべての内部のインタフェースが結局、内部の共有された木で剪定されるかもしれません。
Thaler Informational [Page 15] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[15ページ]のRFC3913BGMP: プロトコル仕様2004年9月
After the border router sends a BGMP (S,G) Join, if its (S,G) state has the PR-bit clear, a (S,G) Poison-Reverse message (with the PR-bit clear) is sent to the ingress router for G. The ingress router then creates (S,G) if it does not already exist, and removes the next hop towards the nominal root of G from the target list.
境界ルータがBGMP(S、G)を送った後に、接合してください、(S、G)州がPRビットを明確にして、(S、G)毒逆メッセージ(PRビットが明確の)が既に存在していないなら次にイングレスルータが作成するG.(S、G)のためにイングレスルータに送られて、目標リストからのGの名目上の根に向かって次のホップを移すなら。
If the border router later receives an (S,G) Poison-Reverse message with the PR-bit set, the Poison-Reverse message is forwarded to the ingress router for G. The best-exit router then creates (S,G) state if it does not already exist, and puts the next hop towards the nominal root of G in the target list if not already present.
境界ルータが後でPRビットセットで(S、G)毒逆メッセージを受け取るなら、G.のためにPoison-逆メッセージをイングレスルータに転送します。最も良い出口ルータは、次に、既に存在していないなら状態を創設して(S、G)、Gの目標リストか既に現在の名目上の根に向かって次のホップを置きます。
4.4.3. Interaction with CBT
4.4.3. CBTとの相互作用
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は、パケットを注入しながら、1つ以上の境界ルータを収容できません。 したがって、CBTドメインに複数の外部の接続があるなら、彼らのひとりだけがどんな与えられたソースからのデータも注入するのを保障するのに境界ルータのM-IGPの部品は原因となります。
Second, CBT cannot process source-specific Joins or Prunes. Two options thus exist for each CBT domain:
2番目に、CBTはソース特有のJoinsかPrunesを処理できません。 その結果、2つのオプションがそれぞれのCBTドメインに存在しています:
Option A:
The CBT component interprets a (S,G) Join alert as if it were an
(*,G) Join alert, as described in [INTEROP]. That is, if it is
not already on the core-tree for G, then it sends a CBT (*,G)
JOIN-REQUEST message towards the core for G. Similarly, when the
CBT component receives an (S,G) Prune alert, and the child
interface list for a group is NULL, then it sends a (*,G)
QUIT_NOTIFICATION towards the core for G. This option has the
disadvantage of pulling all data for the group G down to the CBT
domain when no members exist.
オプションA: CBTの部品が解釈する、まるでそれがあるかのようにa(S、G)が警戒を接合する、(*、G)は[INTEROP]で説明されるように警戒を接合します。 CBTの部品が(S、G)プルーンの警戒を受けるとき、すなわち、Gのためのコア木の上に既にないなら、それはG.SimilarlyのためにCBT(*、G)JOIN-REQUESTメッセージをコアに向かって送ります、そして、グループのための子供インタフェースリストがNULLである、次に、G.Thisオプションのためのコアに向かったNOTIFICATIONが持っている(*、G)QUIT_にどんなメンバーも存在しないとグループ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ドメインがMulticast RIBのために彼らの外部の同輩にどんなルートも伝播しない、(例えば、そのドメインへの内部の接頭語のためのルートかコネ、aが単独で家へ帰った、顧客のドメイン、伝播されるかもしれない、) (S、G)は接合します。これが保障する、ソースのデータが既に共有された木の上のドメインを通り抜けない場合、ソース詳細が接合するのを決して受け取りません、その場合とにかく伝播される必要はありません。 その外部の同輩がEGPのソース接頭語の広告を出す場合にだけ、BGMP境界ルータはソース特有のJoinsかPrunesを外部の同輩に送るでしょう。 BGMP-CBT境界ルータが受信される、Prune、(S、G)が接合するか、またはその境界ルータはメッセージを無視するべきです。
Thaler Informational [Page 16] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[16ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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.
反-アン/カプセル化を最小にするために、CBTv2 BRのものはそれが共有された木のイングレスルータであるそれらのグループのためにどのCandidate-コア広告を送るかの上のPIM-SMの下で説明されるのと同じ計画に続くかもしれません。
4.4.4. Interaction with MOSPF
4.4.4. MOSPFとの相互作用
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がソース特有のJoinsかPrunesを処理できないで、同じ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のすべてが警戒を接合して、(S、G)プルーンの警戒、ORに対応してそれに「早まって、年をとらせる」ので、Group会員資格LSAを送ってください。
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: 他の経路が全くその接頭語に存在しないのが知られていない場合、Multicast RIBのために彼らの外部の同輩にどんなルートも伝播しません。(例えば、ルート、そのドメインへの内部の接頭語かaでは、ドメインがそうする顧客のものが単独で家へ帰っていた、伝播されてください、)
4.5. Operation over Multi-access Networks
4.5. マルチアクセスネットワークの上の操作
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.
1接頭語あたり1人の指定された混載業者を選出するために、BGMPは「混載業者好み」値を各接頭語と交換するFWDR_PREFメッセージを使用します。 結びつきが最も低いBGMP Identifierによって壊されている状態で、最も高い混載業者好みをもっている同輩は指定された混載業者になります。 指定された混載業者は、木で推進パケットに原因となるルータであり、どれが接合するかに同輩を送るということです。
When BGMP first learns that a route exists in the multicast RIB whose next-hop interface is NOT the multiaccess link, the BGMP router sends a BGMP FWDR_PREF message for the prefix, to all BGMP peers on the LAN. The FWDR_PREF message contains a "forwarder preference value" for the local router, and the same value MUST be sent to all peers on the LAN. Likewise, when the prefix is no longer reachable, a FWDR_PREF of 0 is sent to all peers on the LAN.
BGMPが、最初にルートが次のホップインタフェースが多重処理リンクでないマルチキャストRIBに存在することを学ぶとき、BGMPルータは接頭語へのBGMP FWDR_PREFメッセージを送ります、LANのすべてのBGMP同輩に。 FWDR_PREFメッセージはローカルルータのための「混載業者好みの価値」を含んでいます、そして、LANで同じ値をすべての同輩に送らなければなりません。 接頭語がもう届いていないとき、同様に、LANで0のFWDR_PREFをすべての同輩に送ります。
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の上で達して、指定された混載業者が代わりに使用されるときはいつも。
Thaler Informational [Page 17] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[17ページ]のRFC3913BGMP: プロトコル仕様2004年9月
When a BGMP router receives a FWDR_PREF message from a peer, it looks up the matching route in its multicast RIB, and calculates the new designated forwarder. If the router has tree state entries whose parent target was the old forwarder, it sends Joins to the new forwarder and Prunes to the old forwarder.
BGMPルータが同輩からFWDR_PREFメッセージを受け取るとき、それは、マルチキャストRIBの合っているルートを調べて、新しい指定された混載業者について計算します。 ルータに親目標が年取った混載業者であった木の州のエントリーがあるなら、それは新しい混載業者へのJoinsと年取った混載業者へのPrunesを送ります。
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の外)。それはそれぞれ完全なじっと見るとのリンクです。 カプセル化をするか、または物理的なメディアを変えて、これは、例えば、異なったリンクレイヤアドレス・マッピングを使用するのを伴うかもしれません。
4.6. Interaction between (S,G) state and G-routes
4.6. (S、G)状態とG-ルートとの相互作用
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ビットはこの目的のために保たれます。(それは、(国連)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と根のドメインの間の経路にあるなら、答えははい(Gは、PRビットがSに設定されると述べる)です。 問題のドメインがSと根のドメインの間の経路にないなら、答えはノー(PRビットはS、G状態に関して明確になる)です。
5. Message Formats
5. メッセージ・フォーマット
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として伝えられて、領収書で無視しなければなりません。
Thaler Informational [Page 18] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[18ページ]のRFC3913BGMP: プロトコル仕様2004年9月
5.1. Message Header Format
5.1. メッセージヘッダー形式
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
This 2-octet unsigned integer indicates the total length of the
message, including the header, in octets. Thus, e.g., it allows
one to locate in the transport-level stream the start of the next
message. The value of the Length field must always be at least 4
and no greater than 4096, and may be further constrained,
depending on the message type. No "padding" of extra data after
the message is allowed, so the Length field must have the smallest
value required given the rest of the message.
長さ: この2八重奏の符号のない整数は八重奏にヘッダーを含むメッセージの全長を示します。 このようにして、そして、例えば、それで、1つは輸送レベルの流れで次のメッセージの始まりの場所を見つけることができます。 Length分野の値は、いつも少なくとも4と、4096以下と、さらに抑制されるかもしれなくて、メッセージタイプに頼ることでなければなりません。 メッセージが許容された後に余分なデータのどんな「詰め物」によっても、メッセージの残りを考えて、Length分野で最も小さい値を必要としてはいけません。
Type:
This 1-octet unsigned integer indicates the type code of the
message. The following type codes are defined:
以下をタイプしてください。 この1八重奏の符号のない整数はメッセージのタイプコードを示します。 以下のタイプコードは定義されます:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
1--開いている2--アップデート3--通知4--KEEPALIVE
5.2. OPEN Message Format
5.2. 開いているメッセージ・フォーマット
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メッセージは返送されます。 いったんオープンを確認すると、UPDATE、KEEPALIVE、およびNOTIFICATIONメッセージを交換するかもしれません。
In addition to the fixed-size BGMP header, the OPEN message contains the following fields:
固定サイズBGMPヘッダーに加えて、オープンメッセージは以下の分野を含んでいます:
Thaler Informational [Page 19] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[19ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| Rsvd| AddrFam| 保持時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGMP Identifier(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + (任意のパラメタ)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:
This 1-octet unsigned integer indicates the protocol version
number of the message. The current BGMP version number is 1.
バージョン: この1八重奏の符号のない整数はメッセージのプロトコルバージョン番号を示します。 現在のBGMPバージョン番号は1です。
AddrFam:
The IANA-assigned address family number of the BGMP Identifier.
These include (among others):
AddrFam: BGMP IdentifierのIANA-割り当てられたアドレスファミリーナンバ。 これらは以下を含んでいます(特に)。
Number Description
------ -----------
1 IP (IP version 4)
2 IPv6 (IP version 6)
数の記述------ ----------- 1 IP(IPバージョン4)2IPv6(IPバージョン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八重奏の符号のない整数は送付者がHold Timerの値のために提案する秒数を示します。 オープンメッセージを受け取り次第、BGMPスピーカーは、オープンメッセージに受け取られた構成されたHold TimeとHold Timeについて、より小さいのを使用することによって、Hold Timerの値について計算しなければなりません。 Hold Timeはゼロか少なくとも3秒のどちらかでなければなりません。 実装はHold Timeに基づいて接続を拒絶するかもしれません。 計算された値は連続したKEEPALIVEの領収書、そして/または、送付者によるUPDATEメッセージの間で経過するかもしれない秒の最大数を示します。
BGMP Identifier:
This 4-octet (for IPv4) or 16-octet (IPv6) unsigned integer
indicates the BGMP Identifier of the sender. A given BGMP speaker
sets the value of its BGMP Identifier to a globally-unique value
assigned to that BGMP speaker (e.g., an IPv4 address). The value
of the BGMP Identifier is determined on startup and is the same
for every BGMP session opened.
BGMP識別子: この4八重奏(IPv4のための)か16八重奏(IPv6)の符号のない整数が送付者のBGMP Identifierを示します。 与えられたBGMPスピーカーはそのBGMPスピーカー(例えば、IPv4アドレス)に割り当てられたグローバルにユニークな値にBGMP Identifierの値を設定します。 BGMP Identifierの値は、始動で決定していて、開かれたあらゆるBGMPセッションのために同じです。
Thaler Informational [Page 20] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[20ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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.
任意のパラメタ: この分野は任意のパラメタのリストを含むかもしれません、Parameter Type、Parameter Value>三つ子。そこでは、各パラメタが<Parameter Lengthとしてコード化されます。 メッセージヘッダーのLength分野からすべての任意のパラメタの結合した長さを得ることができます。
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | Parm。 タイプ| Parm。 長さ| パラメタ価値(可変)の++++++++++++++++++++、-、…
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.
パラメタTypeは明白に個々のパラメタを特定する1つの八重奏分野です。 パラメタLengthは八重奏における、Parameter Value分野の長さを含む1つの八重奏分野です。 パラメタValueはParameter Type分野の値に従って解釈される可変長フィールドです。
This document defines the following Optional Parameters:
このドキュメントは以下の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同輩を認証するのに使用されるかもしれません。 Parameter Value分野は可変長に従ってAuthentication Codeが続いた1八重奏Authentication Dataを含んでいます。
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | Auth。 コード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 認証データ| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Code:
認証コード:
This 1-octet unsigned integer indicates the authentication
mechanism being used. Whenever an authentication mechanism is
specified for use within BGMP, three things must be included in
the specification:
この1八重奏の符号のない整数は使用される認証機構を示します。 認証機構がBGMPの中の使用に指定されるときはいつも、仕様に3つのものを含まなければなりません:
- the value of the Authentication Code which indicates use of the
mechanism, and - the form and meaning of the Authentication Data.
- そして、メカニズムの使用を示すAuthentication Codeの値、--Authentication Dataのフォームと意味。
Note that a separate authentication mechanism may be used in
establishing the transport level connection.
別々の認証機構が輸送レベル接続を確立する際に使用されるかもしれないことに注意してください。
Thaler Informational [Page 21] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[21ページ]のRFC3913BGMP: プロトコル仕様2004年9月
Authentication Data:
認証データ:
The form and meaning of this field is a variable-length field
depend on the Authentication Code.
この分野のフォームと意味は可変長の分野を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-スピーカーによって使用されるOptional Parameterです。 パラメタが1つを含んでいるか、または以上は<Capability Codeを3倍にします、Capability Length、Capability Value>、各三重が以下に示すようにコード化されるところで:
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
+------------------------------+ | 能力Code(1つの八重奏)| +------------------------------+ | 能力Length(1つの八重奏)| +------------------------------+ | 能力値(可変)| +------------------------------+
Capability Code:
能力コード:
Capability Code is a one octet field that unambiguously identifies
individual capabilities.
能力Codeは明白に個々の能力を特定する1つの八重奏分野です。
Capability Length:
能力の長さ:
Capability Length is a one octet field that contains the length of
the Capability Value field in octets.
能力Lengthは八重奏における、Capability Value分野の長さを含む1つの八重奏分野です。
Capability Value:
能力値:
Capability Value is a variable length field that is interpreted
according to the value of the Capability Code field.
能力ValueはCapability Code分野の値に従って解釈される可変長フィールドです。
A particular capability, as identified by its Capability Code, may occur more than once within the Optional Parameter.
Capability Codeによって特定される特定の能力はOptional Parameterの中の一度より起こるかもしれません。
This document reserves Capability Codes 128-255 for vendor-specific applications.
このドキュメントはベンダー特有のアプリケーションのためにCapability Codes128-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.
能力Codes(ベンダー特定的用法のために予約されたものを除いた)は単にIETFコンセンサスを得るためのプロセスとIESG承認で割り当てられます。
Thaler Informational [Page 22] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[22ページ]のRFC3913BGMP: プロトコル仕様2004年9月
5.3. UPDATE Message Format
5.3. アップデートメッセージ・フォーマット
UPDATE messages are used to transfer Join/Prune/FwdrPref information between BGMP peers. The UPDATE message always includes the fixed- size BGMP header, and one or more attributes as described below.
UPDATEメッセージは、Join/プルーン/FwdrPref情報をBGMP同輩の間に移すのに使用されます。 UPDATEメッセージはいつも以下で説明される固定サイズBGMPヘッダー、および1つ以上の属性を含んでいます。
The message format below allows compact encoding of (*,G) Joins and Prunes, while allowing the flexibility needed to do other updates such as (S,G) Joins and Prunes towards sources as well as on the shared tree. In the discussion below, an Encoded-Address-Prefix is of the form:
以下の形式が(*、G)のコンパクトなコード化を許すメッセージは(S、G)が接合するので他のアップデートにそのようなものをするのに必要である柔軟性とPrunesをソースに向かって許容している間と、そして、Prunesと、共有された木の上で接合します。 以下での議論では、Encodedアドレス接頭語はフォームのものです:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マスク(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EnTyp:
0 - All 1's Mask. The Mask field is 0 bytes long.
1 - Mask length included. The Mask field is 4 bytes long, and
contains the mask length, in bits.
2 - Full Mask included. The Mask field is the same length
as the Address field, and contains the full bitmask.
EnTyp: 0--すべての1個のマスク。 Mask分野は0バイト長です。 1--マスクの長さを含んでいます。 Mask分野は、4バイト長であり、ビットのマスクの長さを含んでいます。 2--完全なMaskを含んでいます。 Mask分野は、Address分野と同じ長さであり、完全なビットマスクを含んでいます。
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.
アドレス: アドレスは、コード化されるために与えられた接頭語と交際しました。 長さは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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| タイプ| データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Thaler Informational [Page 23] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[23ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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.
長さ: Lengthは長さ、タイプ、およびデータ・フィールドを含む全体の属性の長さです。 他の属性がデータ・フィールドの中で入れ子にされるなら、長さはそのようなすべての入れ子にされた属性のサイズを含んでいます。
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は「任意」の属性のために予約されます。 必要な属性が認識されていないなら、NOTIFICATIONを送るでしょう、そして、誤りが致命的なものであるなら接続を閉店させるでしょう。 認識されていない任意の属性は単に無視されます。
0 - JOIN
1 - PRUNE
2 - GROUP
3 - SOURCE
4 - FWDR_PREF
5 - POISON_REVERSE
0--1を接合してください--プルーン2--グループ3--ソース4--FWDR_PREF5--毒_は逆になります。
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属性は、JOINオプションのすぐ中で入れ子にされたすべてのGROUPかSOURCEオプションが参加されるべきであるのを示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| =0をタイプしてください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性を入れ子にします… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested within a JOIN attribute.
どんなJOIN、PRUNEも、または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属性のすぐ中で入れ子にされたすべてのGROUPかSOURCE属性余計なものを取り除かれるべきであるのを示します。
Thaler Informational [Page 24] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[24ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| =1をタイプしてください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性を入れ子にします… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested within a PRUNE attribute.
どんなJOIN、PRUNEも、またはFWDR_PREF属性もすぐに、PRUNE属性の中で入れ子にされないかもしれません。
c) GROUP (Type Code 2)
c) グループ(タイプコード2)
The GROUP attribute identifies a given group-prefix. In addition, any attributes nested immediately within the GROUP attribute also apply to the given group-prefix.
GROUP属性は与えられたグループ接頭語を特定します。 また、さらに、GROUP属性のすぐ中で入れ子にされたどんな属性も与えられたグループ接頭語に適用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Encoded-Address-Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| =2をタイプしてください。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | コード化されたアドレス接頭語| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性(任意の)を入れ子にします… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
マルチキャストグループが上で説明された形式で剪定されていた状態でつながれるために前に置くコード化されたアドレス接頭語。 入れ子にされたAttributesノーGROUP、SOURCE、またはFWDR_PREF属性がすぐに、GROUP属性の中で入れ子にされるかもしれません。
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.
SOURCE属性は与えられたソース接頭語を特定します。 また、さらに、SOURCE属性のすぐ中で入れ子にされたどんな属性も与えられたソース接頭語に適用されます。
Thaler Informational [Page 25] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[25ページ]のRFC3913BGMP: プロトコル仕様2004年9月
The SOURCE attribute has the following format:
SOURCE属性に、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Encoded-Address-Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| =2をタイプしてください。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | コード化されたアドレス接頭語| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性(任意の)を入れ子にします… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
形式のSource-接頭語が上で説明したコード化されたアドレス接頭語。 入れ子にされたAttributesノーGROUP、SOURCE、またはFWDR_PREF属性がすぐに、SOURCE属性の中で入れ子にされるかもしれません。
e) FWDR_PREF (Type Code 4)
e) FWDR_PREF(タイプコード4)
The FWDR_PREF attribute provides a forwarder preference value for all GROUP or SOURCE attributes nested immediately within the FWDR_PREF attribute. It is used by a BGMP speaker to inform other BGMP speakers of the originating speaker's degree of preference for a given group or source prefix. Usage of this attribute is described in 5.5.
FWDR_PREF属性はFWDR_PREF属性のすぐ中で入れ子にされたすべてのGROUPかSOURCE属性に混載業者好みの価値を供給します。 それは、起因しているスピーカーの与えられたグループかソース接頭語のための好みの度合いについて他のBGMPスピーカーに知らせるのにBGMPスピーカーによって使用されます。 この属性の用法は5.5で説明されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| =1をタイプしてください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 好みの値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性を入れ子にします… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
好みのValueのA32ビットの非負の整数。 入れ子にされたAttributesノーJOIN、PRUNE、またはFWDR_PREF属性がすぐに、FWDR_PREF属性の中で入れ子にされるかもしれません。
e) POISON_REVERSE (Type Code 5)
e) 毒_は逆になります。(タイプコード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
POISON_REVERSE属性はPOISON_REVERSE属性のすぐ中で入れ子にされたすべてのSOURCE属性に「毒逆」(PRで噛み付かれる)の値を提供します。 それは、知らせるのにBGMPスピーカーによって使用されます。
Thaler Informational [Page 26] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[26ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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.
それが受信された他の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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| =1をタイプしてください。| 予約されます。|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性を入れ子にします… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビット値。 SOURCE以外のドキュメントの入れ子にされたAttributesいいえ属性はすぐに、POISON_REVERSE属性の中で入れ子にされるかもしれません。
5.4. Encoding examples
5.4. 例をコード化します。
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 )
(*、G接頭語) 接合します: (グループ)(*、G接頭語)プルーンに合流してください: プルーンの(グループ)(S、G)はSに向かって接合します: Gの根に向かってプルーンを取り消して、GROUP(JOIN(SOURCE))(S、G)は接合します: グループ((ソース)を接合します)(S、G)はSに向かって以下を剪定します。 GROUP(PRUNE(SOURCE))(S、G)はGの根に向かって以下を剪定します。 グループ(プルーン(ソース))は(*、G)から(S、G)に切り替わります: (S、G)から(*、G)までのスイッチから余計なものを取り除いてください(分類してください((ソース)を接合してください)): JOIN(GROUP)イニシャル(*、G)は剪定されるSに接合します: G-接頭語のためのJOIN(GROUP(PRUNE(SOURCE)))混載業者好みの発表: S-接頭語のためのFWDR_PREF(GROUP)混載業者好みの発表: FWDR_PREF(ソース)
5.5. KEEPALIVE Message Format
5.5. KEEPALIVEメッセージ・フォーマット
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は、同輩が届くかどうか決定するのにどんな輸送のプロトコルベースの生きている生活費メカニズムも使用しません。 代わりに、Hold Timerが期限が切れることを引き起こさないで、同輩の間でKEEPALIVEメッセージをしばしば十分交換します。 KEEPALIVEかUPDATEメッセージが送った最終と、KEEPALIVEメッセージが送られる時の間の妥当な最大の時間はHold Time間隔の1/3でしょう。 1秒あたり1つより頻繁にKEEPALIVEメッセージを送ってはいけません。 実装はそれがHold Time間隔の機能としてメッセージをKEEPALIVEに送るレートを調整するかもしれません。
Thaler Informational [Page 27] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[27ページ]のRFC3913BGMP: プロトコル仕様2004年9月
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
交渉されたHold Time間隔がゼロであるなら、周期的なKEEPALIVEメッセージを送ってはいけません。
A KEEPALIVE message consists of only a message header, and has a length of 4 octets.
KEEPALIVEメッセージは、メッセージヘッダーだけから成って、4つの八重奏の長さを持っています。
5.6. NOTIFICATION Message Format
5.6. 通知メッセージ形式
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.
エラー条件を検出するとき、NOTIFICATIONメッセージを送ります。 誤りが致命的なものであるならそれを送る直後BGMP接続は閉店します。
In addition to the fixed-size BGMP header, the NOTIFICATION message contains the following fields:
固定サイズBGMPヘッダーに加えて、NOTIFICATIONメッセージは以下の分野を含んでいます:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| エラーコード| 誤り部分符号| データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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八重奏の符号のない整数はNOTIFICATIONのタイプを示します。 以下のError Codesは定義されました:
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をやめます。
Thaler Informational [Page 28] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[28ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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八重奏の符号のない整数は報告された誤りの本質の、より特定の情報を提供します。 各Error Codeには、それに関連している1Error Subcodesがあるかもしれません。 どんな適切なError Subcodeも定義されないなら、ゼロはError Subcode分野に使用されます(Unspecific)が、評価する。 以下の記法(M.C.)は、誤りが致命的なものであることを示します、そして、O-ビットは明確であるに違いありません。 非致命的な部分符号SHOULD、O-ビットセットで、送ってください。
Message Header Error subcodes:
メッセージHeader Error部分符号:
2 - Bad Message Length (MC)
3 - Bad Message Type (MC)
2--悪いメッセージ長(M.C.)3--悪いメッセージタイプ(M.C.)
OPEN Message Error subcodes:
オープンMessage Error部分符号:
1 - Unsupported Version (MC)
4 - Unsupported Optional Parameter
5 - Authentication Failure (MC)
6 - Unacceptable Hold Time (MC)
7 - Unsupported Capability (MC)
1--サポートされないバージョン(M.C.)4--サポートされない任意のパラメタ5--認証失敗(M.C.)6--容認できない保持時間(M.C.)7--サポートされない能力(M.C.)
UPDATE Message Error subcodes:
UPDATE Message Error部分符号:
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--奇形の属性リスト(M.C.)2--認識されていない属性タイプ5--属性長さの誤り(M.C.)10--無効のアドレス11--無効のマスク13--認識されていないアドレスファミリーデータ: この可変長の分野は、NOTIFICATIONの理由を診断するのに使用されます。 Data分野の内容はError CodeとError Subcodeによります。 その他の詳細に関して以下のセクション7を見てください。
Note that the length of the Data field can be determined from the
message Length field by the formula:
公式でメッセージLength分野からData分野の長さを測定できることに注意してください:
Message Length = 6 + Data Length
メッセージ長は6+データの長さと等しいです。
The minimum length of the NOTIFICATION message is 6 octets
(including message header).
NOTIFICATIONメッセージの最小の長さは6つの八重奏(メッセージヘッダーを含んでいて)です。
Thaler Informational [Page 29] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[29ページ]のRFC3913BGMP: プロトコル仕様2004年9月
6. BGMP Error Handling
6. BGMPエラー処理
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 Error Handlingは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.
ここで説明された状態のどれかを検出するとき、示されたError Code、Error Subcode、およびData分野があるNOTIFICATIONメッセージを送ります、そして、BGMP接続は誤りが致命的なものであるなら閉じます。 Error Subcodeが全く指定されないなら、ゼロを使用しなければなりません。
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.
明らかに指定されない場合、誤りを示すために送られるNOTIFICATIONメッセージのData分野は人影がありません。
6.1. Message Header error handling
6.1. メッセージHeaderエラー処理
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.
Message Headerを処理している間に検出されたすべての誤りが、Error Code Message Header Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。 Error Subcodeは誤りの特定の本質について詳しく説明します。
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.
メッセージヘッダーのLength分野があるか、4以上より4096オープンメッセージのLength分野がオープンメッセージの最小の長さかそれともUPDATEメッセージのLength分野が、より少ないかどうかよりUPDATEメッセージの最小の長さある、またはKEEPALIVEメッセージのLength分野が4と等しくないなら、Error SubcodeはBad Message Lengthに用意ができています。 Data分野は誤ったLength分野を含んでいます。
If the Type field of the message header is not recognized, then the Error Subcode is set to Bad Message Type. The Data field contains the erroneous Type field.
メッセージヘッダーのType分野が認識されないなら、Error SubcodeはBad Message Typeに用意ができています。 Data分野は誤ったType分野を含んでいます。
6.2. OPEN message error handling
6.2. オープンメッセージエラー処理
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.
オープンメッセージを処理している間に検出されたすべての誤りが、Error CodeオープンMessage Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。 Error Subcodeは誤りの特定の本質について詳しく説明します。
Thaler Informational [Page 30] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[30ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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).
受信されたオープンメッセージのバージョン分野に保管されていたバージョン番号がサポートされないなら、Error SubcodeはUnsupportedバージョンNumberに用意ができています。 Data分野は2八重奏の符号のない整数です。(その符号のない整数はリモート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.
オープンメッセージのHold Time分野が容認できないなら、Error SubcodeはUnacceptable Hold Timeに用意ができなければなりません。 実装は1秒か2秒のHold Time値を拒絶しなければなりません。 実装はどんな提案されたHold Timeも拒絶するかもしれません。 Hold Timeを受け入れる実装はHold Timeに交渉された値を使用しなければなりません。
If one of the Optional Parameters in the OPEN message is not recognized, then the Error Subcode is set to Unsupported Optional Parameters.
オープンメッセージのOptional Parametersの1つが認識されないなら、Error SubcodeはUnsupported Optional Parametersに用意ができています。
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.
オープンメッセージがAuthentication情報(Optional Parameterとしての)を運ぶなら、対応する認証手順は呼び出されます。 認証手順(Authentication CodeとAuthentication Dataに基づいている)が失敗するなら、Error Subcodeは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.
オープンメッセージが、同輩が受信機が必要とする能力をサポートしないのを示すなら、受信機は、NOTIFICATIONメッセージを同輩に送って、じっと見ることを終えるかもしれません。 メッセージのError SubcodeはUnsupported Capabilityに用意ができています。 NOTIFICATIONメッセージのData分野はスピーカーがメッセージを送る能力のセットを記載します。 ずっとそれが受信されたオープンメッセージでコード化されたようにそのような各能力は同じようにコード化されます。
6.3. UPDATE message error handling
6.3. UPDATEメッセージエラー処理
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.
UPDATEメッセージを処理している間に検出されたすべての誤りが、Error Code UPDATE Message Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。 誤り部分符号は誤りの特定の本質について詳しく説明します。
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).
どんな認識された属性にも予想された長さ(属性タイプコードに基づいている)と衝突するAttribute Lengthがあるなら、Error SubcodeはAttribute Length Errorに用意ができています。 Data分野は誤った属性(タイプ、長さ、および値)を含んでいます。
If the Encoded-Address-Prefix field in some attribute is syntactically incorrect, then the Error Subcode is set to Invalid Prefix Field.
何らかの属性におけるEncodedアドレス接頭語分野がシンタクス上不正確であるなら、Error SubcodeはInvalid Prefix Fieldに用意ができています。
Thaler Informational [Page 31] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[31ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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.
属性(無効の巣篭もりなどの)を処理するとき、いかなる他のも遭遇するなら、Error SubcodeはMalformed Attribute Listに用意ができています、そして、問題の多い属性はデータ・フィールドで含められています。
6.4. NOTIFICATION message error handling
6.4. NOTIFICATIONメッセージエラー処理
If a peer sends a NOTIFICATION message, and there is an error in that message, there is unfortunately no means of reporting this error via a subsequent NOTIFICATION message. Any such error, such as an unrecognized Error Code or Error Subcode, should be noticed, logged locally, and brought to the attention of the administration of the peer. The means to do this, however, lies outside the scope of this document.
同輩がNOTIFICATIONメッセージを送って、そのメッセージに誤りがあれば、残念ながら、その後のNOTIFICATIONメッセージでこの誤りを報告する手段が全くありません。 認識されていないError CodeかError Subcodeなどのどんなそのような誤りも、同輩の管理の注意に気付かれていて、局所的に登録されて、もたらされるべきです。 このドキュメントの範囲の外にしかしながら、これをする手段があります。
6.5. Hold Timer Expired error handling
6.5. Timer Expiredエラー処理を保持してください。
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 Time分野で指定された期間中に連続したKEEPALIVE、UPDATE、そして/または、NOTIFICATIONメッセージを受け取らないなら、Hold Timer Expired Error CodeがあるNOTIFICATIONメッセージを送らなければなりませんでした、そして、BGMP接続は閉じました。
6.6. Finite State Machine error handling
6.6. 有限州Machineエラー処理
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 Finite州Machine(例えば、予期せぬ出来事の領収書)によって検出されたどんな誤りも、Error Code Finite州Machine Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。
6.7. Cease
6.7. やんでください。
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同輩は、その時々でError Code Ceaseと共にNOTIFICATIONメッセージを送ることによってBGMP接続を終えるのを選ぶかもしれません。 しかしながら、このセクションによって示された致命的な誤りが存在するとき、Cease NOTIFICATIONメッセージを使用してはいけません。
6.8. Connection collision detection
6.8. 接続衝突検出
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.
1組のBGMPスピーカーが同時にTCP接続を互いに確立しようとするなら、この組のスピーカーの間の2人の並列接続がたぶん形成されるでしょう。 私たちはこの状況を接続衝突と呼びます。 明確に、これらの接続のひとりを閉じなければなりません。
Based on the value of the BGMP Identifier a convention is established for detecting which BGMP connection is to be preserved when a collision does occur. The convention is to compare the BGMP
BGMP Identifierの値に基づいて、コンベンションは、衝突が起こるとき、保存されるためにBGMP接続がどれであるかを検出するために設立されます。 コンベンションはBGMPを比較することになっています。
Thaler Informational [Page 32] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[32ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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 Identifierと共に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 Identifierを知っているなら、BGMPスピーカーはOpenSent状態で接続を調べるかもしれません。 これらの接続の中にBGMP Identifierがオープンメッセージのものと等しいリモート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 IdentifierはリモートシステムのBGMP Identifierと比較されます(オープンメッセージで指定されるように)。
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 Identifierの値がリモートもの以下であるなら、ローカルシステムは、既に存在する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 Identifiersは、(4八重奏の長さ)符号のない整数として彼らを扱うことによって、比較されます。
A connection collision with an existing BGMP connection that is in Established states causes unconditional closing of the newly created connection. Note that a connection collision cannot be detected with connections that are in Idle, or Connect, or Active states.
Established州にある既存のBGMP接続との接続衝突は新たに作成された接続の無条件の閉鎖を引き起こします。 Idle、Connect、またはActive州にある接続と共に接続衝突を検出できないことに注意してください。
Closing the BGMP connection (that results from the collision resolution procedure) is accomplished by sending the NOTIFICATION message with the Error Code Cease.
BGMP接続(それは衝突解決手順から生じる)を終えるのは、Error Code Ceaseと共にNOTIFICATIONメッセージを送ることによって、実行されます。
7. BGMP Version Negotiation
7. 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
BGMPスピーカーはBGMP接続を開く複数の試みをすることによって、プロトコルのバージョンを交渉するかもしれません、それぞれがサポートする中で最も大きいバージョン番号から始まって。 そして開いている試みがError CodeオープンMessage Error、およびError Subcode UnsupportedバージョンNumberと共に失敗するなら、BGMPスピーカーには、それが試みた有効なバージョン番号があります、同輩が試みたバージョン番号、NOTIFICATIONメッセージの同輩によって通過されたバージョン番号。
Thaler Informational [Page 33] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[33ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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.
それがサポートするバージョン番号。 2人の同輩が1つ以上の一般的なバージョンをサポートすると、これで、彼らは急速に最も高い一般的なバージョンを決定できるでしょう。 BGMPがバージョン交渉であるとサポートするために、BGMPの将来のバージョンはオープンとNOTIFICATIONメッセージの形式を保有しなければなりません。
7.1. BGMP Capability Negotiation
7.1. 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.
Capabilitiesは、BGMPスピーカーがオープンメッセージをBGMP同輩に送るとき、メッセージがOptional Parameterを含むかもしれないと呼びました。 パラメタはスピーカーによってサポートされた能力を記載します。
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スピーカーはスピーカーが同輩から受信するというオープンメッセージによって運ばれたCapabilities Optional Parameterの現在の能力のリストを調べることによって同輩によってサポートされた能力を決定します。
8. BGMP Finite State machine
8. BGMP Finite州マシン
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.
このセクションはFinite州Machine(FSM)に関してBGMP操作を指定します。 以下に、このFSMによって決定されるように状態によるBGMP操作の簡潔な概要と概要があります。
Initially BGMP is in the Idle state.
初めは、BGMPがIdle状態にあります。
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接続を拒否します。 リソースを全く同輩に割り当てません。 Startイベント(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムは、すべてのBGMPリソースを初期化して、ConnectRetryタイマを始動して、リモートBGMP同輩によって開始されるかもしれない接続の聞こうとしている間、もう片方のBGMP同輩に輸送接続を開始して、状態をConnectに変えます。 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
BGMPスピーカーが誤りを検出するなら、それは接続と変化の下側にIdleへの状態を閉じます。 Idle状態から出るのはStartイベントを世代に要求します。 そのようなイベントが自動的に生成されるなら、永続的なBGMP誤りはスピーカーについて永続的なばたつくことをもたらすかもしれません。 そのような状態を避けるために、イベントがすぐ以前にそうであった同輩のために生成されるべきでないStartが誤りのためIdleに移行したのは、お勧めです。 誤りのために同輩にとって、それは以前に移行しているIdleであり、間の時間は連続した世代です。
Thaler Informational [Page 34] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[34ページ]のRFC3913BGMP: プロトコル仕様2004年9月
Start events, if such events are generated automatically, shall
exponentially increase. The value of the initial timer shall be
60 seconds. The time shall be doubled for each consecutive retry.
そのようなイベントが自動的に生成されるなら、スタートイベントは指数関数的に増加するものとします。 初期のタイマの値は60秒になるでしょう。 時間はそれぞれの連続した再試行のために倍にされるものとします。
Any other event received in the Idle state is ignored.
Idle状態に受け取られたいかなる他のイベントも無視されます。
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タイマをきれいにして、初期化を終了して、オープンメッセージを同輩に送って、状態をOpenSentに変えます。 プロトコルが接続する輸送が(例えば、再送タイムアウト)に失敗するなら、ローカルシステムは、Active状態に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同輩によって開始されるかもしれない接続の聞こうとし続けて、Connect状態にままでいます。
The Start event is ignored in the Connect state.
StartイベントはConnect状態で無視されます。
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リソースを発表して、状態をIdleに変えます。
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タイマをきれいにして、初期化を終了して、オープンメッセージを同輩に送って、大きい値にHold Timerを設定して、状態をOpenSentに変えます。 4分のHold Timer値は示されます。
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同輩によって開始されるかもしれない接続の聞こうとし続けて、状態をConnectに変えます。
Thaler Informational [Page 35] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[35ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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同輩によって開始されるかもしれない接続の聞こうとし続けて、Active状態にいます。
The Start event is ignored in the Active state.
StartイベントはActive状態で無視されます。
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リソースを発表して、状態をIdleに変えます。
OpenSent state:
OpenSent州:
In this state BGMP waits for an OPEN message from its peer. When
an OPEN message is received, all fields are checked for
correctness. If the BGMP message header checking or OPEN message
checking detects an error (see Section 6.2), or a connection
collision (see Section 6.8) the local system sends a NOTIFICATION
message and changes its state to Idle.
この状態では、BGMPは同輩からのオープンメッセージを待っています。 オープンメッセージが受信されているとき、すべての分野が正当性がないかどうかチェックされます。 BGMPメッセージヘッダーの照合かオープンメッセージの照合がローカルシステムがNOTIFICATIONメッセージを送る誤り(セクション6.2を見る)、または接続衝突(セクション6.8を見る)を検出して、状態をIdleに変えるなら。
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はKEEPALIVEメッセージを送って、KeepAliveタイマを設定します。 Hold Timer(元々、大きい値(上を見る)に用意ができていた)を交渉されたHold Time値に取り替えます(セクション4.2を見てください)。 交渉されたHold Time値がゼロであるなら、Hold TimeタイマとKeepAliveタイマは始動されません。 このじっと見る構成されたリモートAutonomous System値が地方のAutonomous System番号と同じであるなら、接続は「内部」の接続です。 さもなければ、それは「外部です」。 最終的に、状態は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同輩によって開始されるかもしれなくて、Active状態に入る接続の聞こうとし続けてください。
If the Hold Timer expires, the local system sends NOTIFICATION
message with error code Hold Timer Expired and changes its state
to Idle.
Hold Timerが期限が切れるなら、ローカルシステムはエラーコードHold Timer Expiredと変化に伴うNOTIFICATIONメッセージに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イベント(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムはError Code Ceaseと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
The Start event is ignored in the OpenSent state.
StartイベントはOpenSent状態で無視されます。
Thaler Informational [Page 36] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[36ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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.
いかなる他のイベントに対応して、ローカルシステムはError Code Finite州Machine Errorと変化に伴うNOTIFICATIONメッセージに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はKEEPALIVEかNOTIFICATIONメッセージを待っています。
If the local system receives a KEEPALIVE message, it changes its
state to Established.
ローカルシステムがKEEPALIVEメッセージを受け取るなら、それは状態を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 Timerが期限が切れるなら、ローカルシステムはエラーコードHold Timer Expiredと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
If the local system receives a NOTIFICATION message, it changes
its state to Idle.
ローカルシステムがNOTIFICATIONメッセージを受け取るなら、それは状態をIdleに変えます。
If the KeepAlive timer expires, the local system sends a KEEPALIVE
message and restarts its KeepAlive timer.
KeepAliveタイマが期限が切れるなら、ローカルシステムは、KEEPALIVEメッセージを送って、KeepAliveタイマを再開します。
If a disconnect notification is received from the underlying
transport protocol, the local system changes its state to Idle.
基本的なトランスポート・プロトコルから分離通知を受け取るなら、ローカルシステムは状態をIdleに変えます。
In response to the Stop event (initiated by either system or
operator) the local system sends NOTIFICATION message with Error
Code Cease and changes its state to Idle.
Stopイベント(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムはError Code Ceaseと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
The Start event is ignored in the OpenConfirm state.
Startイベントは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.
いかなる他のイベントに対応して、ローカルシステムはError Code Finite州Machine Errorと変化に伴うNOTIFICATIONメッセージに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からIdleに変えるときはいつも、それは、BGMP(そして、輸送レベル)接続を終えて、その接続に関連しているすべてのリソースを発表します。
Established state:
設立された州:
In the Established state BGMP can exchange UPDATE, NOTIFICATION,
and KEEPALIVE messages with its peer.
Established状態では、BGMPは同輩と共にUPDATE、NOTIFICATION、およびKEEPALIVEメッセージを交換できます。
Thaler Informational [Page 37] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[37ページ]のRFC3913BGMP: プロトコル仕様2004年9月
If the local system receives an UPDATE or KEEPALIVE message, it
restarts its Hold Timer, if the negotiated Hold Time value is
non-zero.
ローカルシステムがUPDATEかKEEPALIVEメッセージを受け取るなら、Hold Timerを再開します、交渉されたHold Time値が非ゼロであるなら。
If the local system receives a NOTIFICATION message, it changes
its state to Idle.
ローカルシステムがNOTIFICATIONメッセージを受け取るなら、それは状態をIdleに変えます。
If the local system receives an UPDATE message and the UPDATE
message error handling procedure (see Section 6.3) detects an
error, the local system sends a NOTIFICATION message and changes
its state to Idle.
ローカルシステムがUPDATEメッセージを受け取って、UPDATEメッセージエラー処理手順(セクション6.3を見る)が誤りを検出するなら、ローカルシステムは、NOTIFICATIONメッセージを送って、状態をIdleに変えます。
If a disconnect notification is received from the underlying
transport protocol, the local system changes its state to Idle.
基本的なトランスポート・プロトコルから分離通知を受け取るなら、ローカルシステムは状態をIdleに変えます。
If the Hold Timer expires, the local system sends a NOTIFICATION
message with Error Code Hold Timer Expired and changes its state
to Idle.
Hold Timerが期限が切れるなら、ローカルシステムはError Code Hold Timer Expiredと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
If the KeepAlive timer expires, the local system sends a KEEPALIVE
message and restarts its KeepAlive timer.
KeepAliveタイマが期限が切れるなら、ローカルシステムは、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かUPDATEメッセージを送る各回、KeepAliveタイマを再開します、交渉されたHold Time値がゼロでないなら。
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イベント(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムはError Code Ceaseと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
The Start event is ignored in the Established state.
StartイベントはEstablished状態で無視されます。
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.
いかなる他のイベントに対応して、ローカルシステムはError Code Finite州Machine Errorと変化に伴うNOTIFICATIONメッセージに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が状態をEstablishedからIdleに変えるときはいつも、それは、BGMP(そして、輸送レベル)接続を終えて、その接続に関連しているすべてのリソースを発表して、その接続から得られたすべてのルートを削除します。
9. Security Considerations
9. セキュリティ問題
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メッセージの認証はこの振舞いから守ることができます。
Thaler Informational [Page 38] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[38ページ]のRFC3913BGMP: プロトコル仕様2004年9月
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実装は、コントロールがメッセージであると機密保護するために、Keyed MD5[RFC2385]を実装しなければならなくて、それをサポートしない同輩と共に共同利用できなければなりません。 しかしながら、接続の半面がKeyed MD5によって構成されるか、そして、反対側はそうではありません、接続SHOULD NOT。設立されます。
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において、現在熟練しているセキュリティー対策と同じです。 今後の活動がルーティング・プロトコルで異なったより強いメカニズムをこれらの問題に対処するのに提供すると予期されます。
10. Acknowledgements
10. 承認
In addition to the editor, the following individuals have contributed to the design of BGMP: Cengiz Alaettinoglu, Tony Ballardie, Steve Casner, Steve Deering, Deborah Estrin, Dino Farinacci, Bill Fenner, Mark Handley, Ahmed Helmy, Van Jacobson, Dave Meyer, and Satish Kumar.
エディタに加えて、以下の個人はBGMPのデザインに貢献しました: Cengiz Alaettinoglu、トニーBallardie、スティーブCasner、スティーブ・デアリングデボラEstrin(Dinoファリナッチ、ビル・フェナー)はハンドレー、アフマドHelmy、バンジェーコブソン、デーヴ・マイヤー、およびサティシュ・クマーをマークします。
This document is the product of the IETF BGMP Working Group with Dave Thaler as editor.
このドキュメントはエディタとしてのデーヴThalerがあるIETF BGMP作業部会の製品です。
Rusty Eddy, Isidor Kouvelas, and Pavlin Radoslavov also provided valuable feedback on this document.
また、錆付いているEddy、Isidor Kouvelas、およびパブリン・ラドスラーボフはこのドキュメントの有益なフィードバックを提供しました。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[INTEROP] Thaler, D., "Interoperability Rules for Multicast Routing
Protocols", RFC 2715, October 1999.
[INTEROP] ターレル、D.、「マルチキャストルーティング・プロトコルのための相互運用性規則」、RFC2715、1999年10月。
[RFC2385] Heffernan, A., "Protection of BGP sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションの保護」、RFC2385、1998年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[V6PREFIX] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[V6PREFIX] ハーバーマンとB.とD.ターレル、「ユニキャスト接頭語ベースのIPv6マルチキャストアドレス」、RFC3306、2002年8月。
Thaler Informational [Page 39] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[39ページ]のRFC3913BGMP: プロトコル仕様2004年9月
11.2. Informative References
11.2. 有益な参照
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-
4)", RFC 1771, March 1995.
[BGP] RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP4)」、RFC1771、1995年3月。
[MBGP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[MBGP] ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、2000年6月。」
[CBT] Ballardie, A., "Core Based Trees (CBT version 2) Multicast
Routing -- Protocol Specification", RFC 2189, September
1997.
[CBT]Ballardie、A.、「コアBased Trees(CBTバージョン2)マルチキャストルート設定--Specificationについて議定書の中で述べる」RFC2189、1997年9月。
[DVMRP] Pusateri, T., "Distance Vector Multicast Routing
Protocol", Work in Progress, October 2003.
T.、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」という[DVMRP]Pusateriは進歩、2003年10月に働いています。
[IPv6AA] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[IPv6AA]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994.
[MOSPF] Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、1994年3月。
[PIMDM] Adams, A., Nicholas, J. and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", Work in Progress, September
2003.
[PIMDM] アダムス、A.、ニコラス、J.、およびW.Siadak、「プロトコルの独立しているマルチキャスト--濃いモード(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.、ファリナッチ、D.、Helmy、A.、ターレル、D.、デアリング、S.、ハンドレー、M.、ジェーコブソン、V.、リュウ、C.、シャルマ、P.、およびL.ウェイ、「独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、1998年6月。
[REFLECT] Bates, T. and R. Chandra, "BGP Route Reflection: An
alternative to full mesh IBGP", RFC 1966, June 1996.
[反射します] ベイツ、T.、およびR.チャンドラ、「BGPは反射を発送します」。 「完全なメッシュIBGPへの代替手段」、RFC1966、1996年6月。
[V4PREFIX] Thaler, D., "Unicast-Prefix-based IPv4 Multicast
Addresses", Work in Progress, August 2004.
D.、「ユニキャスト接頭語ベースのIPv4マルチキャストアドレス」という[V4PREFIX]ターレルは進歩、2004年8月に動作します。
Authors' Address
作者のアドレス
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
デーヴターレルマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 98052
EMail: dthaler@microsoft.com
メール: dthaler@microsoft.com
Thaler Informational [Page 40] RFC 3913 BGMP: Protocol Specification September 2004
ターレル情報[40ページ]のRFC3913BGMP: プロトコル仕様2004年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Thaler Informational [Page 41]
ターレル情報です。[41ページ]
一覧
スポンサーリンク
