[要約] RFC 4610は、プロトコル非依存マルチキャスト（PIM）を使用したAnycast-RPに関する要約と目的を提供します。Anycast-RPは、マルチキャストルーティングプロトコルを使用して、複数のルートプロセッサ（RP）に対して同じアドレスを割り当てる方法です。このRFCは、Anycast-RPの設計と実装に関するガイドラインを提供します。
Network Working Group D. Farinacci
Request for Comments: 4610 Y. Cai
Category: Standards Track Cisco Systems
August 2006
Anycast-RP Using Protocol Independent Multicast (PIM)
プロトコル独立マルチキャスト（PIM）を使用したaycast-rp
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP.
この仕様により、Anycast-RP（Rendezvous Point）は、プロトコル独立マルチキャスト（PIM）のみを実行するドメイン内でのみ使用できます。他のマルチキャストプロトコル（この問題を解決するために伝統的に使用されてきたマルチキャストソースディスカバリープロトコル（MSDP）など）は、AnyCast-RPをサポートする必要はありません。
Anycast-RP as described in [I1] is a mechanism that ISP-based backbones have used to get fast convergence when a PIM Rendezvous Point (RP) router fails. To allow receivers and sources to Rendezvous to the closest RP, the packets from a source need to get to all RPs to find joined receivers.
[I1]で説明されているように、Anycast-RPは、PIM Rendezvous Point（RP）ルーターが失敗すると、ISPベースのバックボーンが高速収束を得るために使用したメカニズムです。レシーバーとソースが最も近いRPにランデブーになるようにするために、ソースからのパケットは、すべてのRPSに到達して結合したレシーバーを見つける必要があります。
This notion of receivers finding sources is the fundamental problem of source discovery that MSDP was intended to solve. However, if one would like to retain the Anycast-RP benefits from [I1] with less protocol machinery, removing MSDP from the solution space is an option.
ソースを見つけるレシーバーのこの概念は、MSDPが解決することを意図したソース発見の根本的な問題です。ただし、プロトコル機械の少ない[I1]のAnycast-RPの利点を保持したい場合は、ソリューションスペースからMSDPを削除することがオプションです。
This memo extends the Register mechanism in PIM so Anycast-RP functionality can be retained without using MSDP.
このメモは、MSDPを使用せずにAnycast-RP機能を保持できるように、PIMのレジスタメカニズムを拡張します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [N2].
o A unicast IP address is chosen to use as the RP address. This address is statically configured, or distributed using a dynamic protocol, to all PIM routers throughout the domain.
o ユニキャストIPアドレスは、RPアドレスとして使用するように選択されています。このアドレスは、ドメイン全体のすべてのPIMルーターに静的に構成または動的プロトコルを使用して分布しています。
o A set of routers in the domain is chosen to act as RPs for this RP address. These routers are called the Anycast-RP set.
o ドメイン内のルーターのセットは、このRPアドレスのRPSとして機能するように選択されます。これらのルーターは、Anycast-RPセットと呼ばれます。
o Each router in the Anycast-RP set is configured with a loopback interface using the RP address.
o Anycast-RPセットの各ルーターは、RPアドレスを使用してループバックインターフェイスで構成されています。
o Each router in the Anycast-RP set also needs a separate IP address, to be used for communication between the RPs.
o Anycast-RPセットの各ルーターには、RP間の通信に使用するために、個別のIPアドレスも必要です。
o The RP address, or a prefix that covers the RP address, is injected into the unicast routing system inside of the domain.
o RPアドレス、またはRPアドレスをカバーするプレフィックスは、ドメイン内のユニキャストルーティングシステムに注入されます。
o Each router in the Anycast-RP set is configured with the addresses of all other routers in the Anycast-RP set. This must be consistently configured in all RPs in the set.
o Anycast-RPセットの各ルーターは、AnyCast-RPセットの他のすべてのルーターのアドレスで構成されています。これは、セット内のすべてのRPSで一貫して構成する必要があります。
The following diagram illustrates a domain using 3 RPs where receivers are joining to the closest RP according to where unicast routing metrics take them and 2 sources sending packets to their respective RPs.
次の図は、ユニキャストルーティングメトリックがそれらを使用し、2つのソースをそれぞれのRPに送信する2つのソースに応じて、レシーバーが最も近いRPに結合する3つのRPを使用するドメインを示しています。
The rules described in this section do not override the rules in [N1]. They are intended to blend with the rules in [N1]. If there is any question on the interpretation, precedent is given to [N1].
このセクションで説明したルールは、[n1]のルールを無効にしません。それらは、[N1]のルールとブレンドすることを目的としています。解釈に質問がある場合、[N1]に前例が与えられます。
S1-----RP1 RP2 RP3------S3
/ \ |
/ \ |
R1 R1' R2
Assume the above scenario is completely connected where R1, R1', and R2 are receivers for a group, and S1 and S3 send to that group. Assume RP1, RP2, and RP3 are all assigned the same IP address, which is used as the Anycast-RP address (let's say the IP address is RPA).
上記のシナリオは、R1、R1 '、およびR2がグループの受信機であり、S1とS3がそのグループに送信される場合に完全に接続されていると仮定します。RP1、RP2、およびRP3にはすべて同じIPアドレスが割り当てられていると仮定します。これはAnycast-RPアドレスとして使用されます（IPアドレスがRPAだとします）。
Note, the address used for the RP address in the domain (the Anycast-RP address) needs to be different than the addresses used by the Anycast-RP routers to communicate with each other.
注意してください。ドメイン内のRPアドレス（Anycast-RPアドレス）に使用されるアドレスは、互いに通信するためにAnycast-RPルーターが使用するアドレスとは異なる必要があります。
The following procedure is used when S1 starts sourcing traffic:
S1がトラフィックの調達を開始するときに、次の手順が使用されます。
o S1 sends a multicast packet.
o S1はマルチキャストパケットを送信します。
o The designated router (DR) directly attached to S1 will form a PIM Register message to send to the Anycast-RP address (RPA). The unicast routing system will deliver the PIM Register message to the nearest RP, in this case RP1.
o S1に直接接続された指定されたルーター（DR）は、PIMレジスタメッセージを形成して、AnyCast-RPアドレス（RPA）に送信します。ユニキャストルーティングシステムは、PIMレジスタメッセージを最も近いRP、この場合はRP1に配信します。
o RP1 will receive the PIM Register message, decapsulate it, and send the packet down the shared-tree to get the packet to receivers R1 and R1'.
o RP1はPIMレジスタメッセージを受信し、それを脱カプセル化し、パケットを共有ツリーに送信して、パケットをR1およびR1 'に入手します。
o RP1 is configured with RP2 and RP3's IP address. Since the Register message did not come from one of the RPs in the anycast-RP set, RP1 assumes the packet came from a DR. If the Register is not addressed to the Anycast-RP address, an error has occurred and it should be rate-limited logged.
o RP1は、RP2およびRP3のIPアドレスで構成されています。レジスタメッセージはAnyCast-RPセットのRPSの1つからではなかったため、RP1はパケットがDRから来たと仮定します。レジスタがAnyCast-RPアドレスに宛てられていない場合、エラーが発生し、レート制限記録する必要があります。
o RP1 will then send a copy of the Register message from S1's DR to both RP2 and RP3. RP1 will use its own IP address as the source address for the PIM Register message.
o RP1は、S1のDRからRP2とRP3の両方にレジスタメッセージのコピーを送信します。RP1は、PIMレジスタメッセージのソースアドレスとして独自のIPアドレスを使用します。
o RP1 MAY join back to the source-tree by triggering a (S1,G) Join message toward S1. However, RP1 MUST create (S1,G) state.
o RP1は、A（S1、G）結合メッセージをS1に合わせてトリガーすることにより、ソースツリーに戻ることができます。ただし、RP1は（S1、G）状態を作成する必要があります。
o RP1 sends a Register-Stop back to the DR. If, for some reason, the Register messages to RP2 and RP3 are lost, then when the Register suppression timer expires in the DR, it will resend Registers to allow another chance for all RPs in the Anycast-RP set to obtain the (S,G) state.
o RP1はレジスターストップをDRに送り返します。何らかの理由で、RP2とRP3へのレジスタメッセージが失われた場合、登録抑制タイマーがDRで期限切れになると、レジスタが再送信され、Anycast-RPセットのすべてのRPSが（s、取得する可能性があります。g）状態。
o RP2 receives the Register message from RP1, decapsulates it, and also sends the packet down the shared-tree to get the packet to receiver R2.
o RP2はRP1からレジスタメッセージを受信し、それを脱カプセル化し、パケットを共有ツリーから送信して、パケットを受信機R2に取得します。
o RP2 sends a Register-Stop back to RP1. RP2 MAY wait to send the Register-Stop if it decides to join the source-tree. RP2 should wait until it has received data from the source on the source-tree before sending the Register-Stop. If RP2 decides to wait, the Register-Stop will be sent when the next Register is received. If RP2 decides not to wait, the Register-Stop is sent now.
o RP2はレジスターストップをRP1に送ります。RP2は、ソースツリーに参加することを決定した場合、レジスターストップを送信するのを待つ場合があります。RP2は、レジスタストップを送信する前に、ソースツリーのソースからデータを受信するまで待つ必要があります。RP2が待機することを決定した場合、次のレジスタを受信するとレジスタストップが送信されます。RP2が待たないことを決定した場合、レジスタストップが今送信されます。
o RP2 MAY join back to the source-tree by triggering a (S1,G) Join message toward S1. However, RP2 MUST create (S1,G) state.
o RP2は、A（S1、G）結合メッセージをS1に合わせてトリガーすることにより、ソースツリーに戻ることができます。ただし、RP2は（S1、G）状態を作成する必要があります。
o RP3 receives the Register message from RP1, decapsulates it, but since there are no receivers joined for the group, it can discard the packet.
o RP3はRP1からレジスタメッセージを受信し、それを脱カプセル化しますが、グループに参加するレシーバーがないため、パケットを破棄できます。
o RP3 sends a Register-Stop back to RP1.
o
o RP3 creates (S1,G) state so when a receiver joins after S1 starts sending, RP3 can join quickly to the source-tree for S1.
o RP3は（S1、g）状態を作成するため、S1が送信を開始した後にレシーバーが結合すると、RP3はS1のソースツリーに迅速に結合できます。
o RP1 processes the Register-Stop from each of RP2 and RP3. There is no specific action taken when processing Register-Stop messages.
o RP1は、RP2とRP3のそれぞれからレジスタストップを処理します。レジスタストップメッセージを処理するときに特定のアクションは実行されません。
The procedure for S3 sending follows the same as above but it is RP3 that sends a copy of the Register originated by S3's DR to RP1 and RP2. Therefore, this example shows how sources anywhere in the domain, associated with different RPs, can reach all receivers, also associated with different RPs, in the same domain.
S3送信の手順は上記と同じですが、S3のDRからRP1およびRP2に発信されたレジスタのコピーを送信するのはRP3です。したがって、この例は、異なるRPに関連するドメイン内のどこでも、同じドメインで異なるRPに関連付けられているすべてのレシーバーにどのように到達できるかを示しています。
o An RP will send a copy of a Register only if the Register is received from an IP address not in the Anycast-RP list (i.e., the Register came from a DR and not another RP). An implementation MUST safeguard against inconsistently configured Anycast-RP sets in each RP by copying the Time to Live (TTL) from a Register message to the Register messages it copies and sends to other RPs.
o RPは、レジスタがAnyCast-RPリストにないIPアドレスから受信された場合にのみ、レジスタのコピーを送信します（つまり、レジスタはDRから来たものであり、別のRPではありません）。実装は、レジスタメッセージから他のRPSに送信するレジスタメッセージへのライブ（TTL）をコピーすることにより、各RPでAnycast-RPセットを一貫して構成しないことに対して保護する必要があります。
o Each DR that PIM registers for a source will send the message to the Anycast-RP address (which results in the packet getting to the closest physical RP). Therefore, there are no changes to the DR logic.
o ソースのPIM登録の各DRは、メッセージをAnyCast-RPアドレスに送信します（これにより、パケットが最も近い物理RPに到達します）。したがって、Dr Logicに変更はありません。
o Packets flow to all receivers no matter what RP they have joined to.
o パケットは、参加したRPに関係なく、すべてのレシーバーに流れます。
o The source gets Registered to a single RP by the DR. It's the responsibility of the RP that receives the PIM Register messages from the DR (the closest RP to the DR based on routing metrics) to get the packet to all other RPs in the Anycast-RP set.
o ソースは、DRによって単一のRPに登録されます。Anycast-RPセットの他のすべてのRPにパケットを取得するために、DR（ルーティングメトリックに基づいてDRに最も近いRP）からPIMレジスタメッセージを受信するのはRPの責任です。
o Logic is changed only in the RPs. The logic change is for sending copies of Register messages. Register-Stop processing is unchanged. However, an implementation MAY suppress sending Register-Stop messages in response to a Register received from an RP.
o
o The rate-limiting of Register and Register-Stop messages are done end-to-end. That is from DR -> RP1 -> {RP2 and RP3}. There is no need for specific rate-limiting logic between the RPs.
o レジスタおよびレジスタストップメッセージのレート制限は、エンドツーエンドで行われます。これは、dr-> rp1-> {rp2およびrp3}からです。RPS間に特定のレート制限ロジックは必要ありません。
o When topology changes occur, the existing source-tree adjusts as it does today according to [N1]. The existing shared-trees, as well, adjust as they do today according to [N1].
o トポロジーの変更が発生すると、既存のソースツリーは[N1]に従って今日のように調整されます。既存の共有ツリーも、[N1]に従って今日のように調整します。
o Physical RP changes are as fast as unicast route convergence, retaining the benefit of [I1].
o 物理RPの変化は、ユニキャストルートの収束と同じくらい速く、[I1]の利点を保持しています。
o An RP that doesn't support this specification can be mixed with RPs that do support this specification. However, the non-supporter RP should not have sources registering to it, but may have receivers joined to it.
o この仕様をサポートしていないRPは、この仕様をサポートするRPSと混合できます。ただし、サポーター以外のRPには、ソースが登録されているわけではありませんが、レシーバーが参加している可能性があります。
o If Null Registers are sent (Registers with an IP header and no IP payload), they MUST be replicated to all of the RPs in the Anycast-RP set so that source state remains alive for active sources.
o nullレジスタが送信される場合（IPヘッダーとIPペイロードがないレジスタ）、アクティブソースのためにソース状態が生き続けるように、anycast-RPセットのすべてのRPSに複製する必要があります。
o The number of RPs in the Anycast-RP set should remain small so the amount of non-native replication is kept to a minimum.
o Anycast-RPセットのRPSの数は少ないため、非ネイティブの複製の量が最小限に抑えられます。
o Since the RP, who receives a Register from the DR, will send copies of the Register to the other RPs at the same time it sends a Register-Stop to the DR, there could be packet loss and lost state in the other RPs until the time the DR sends Register messages again.
o DRからレジスタを受け取るRPは、レジスタのコピーを他のRPSに同時に送信するため、DRにレジスタストップを送信するため、他のRPSにパケット損失と失われた状態がある可能性があります。DRが登録メッセージを再度送信する時間。
The objective of this Anycast-PIM proposal is to remove the dependence on using MSDP. This can be achieved by removing MSDP peering between the Anycast-RPs. However, to advertise internal sources to routers outside of a PIM routing domain and to learn external sources from other routing domains, MSDP may still be required.
In this capacity, when there are internal sources that need to be advertised externally, an Anycast-RP that receives a Register message, either from a DR or an Anycast-RP, should process it as described in this specification as well as how to process a Register message as described in [N1]. That means a Source-Active (SA) for the same internal source could be originated by multiple Anycast-RPs doing the MSDP peering. There is nothing inherently wrong with this other than that the source is being advertised into the MSDP infrastructure from multiple places from the source domain. However, if this is not desirable, configuration of one or more (rather than all) Anycast-RP MSDP routers would allow only those routers to originate SAs for the internal source. And in some situations, there is a good possibility not all Anycast-RPs in the set will have MSDP peering sessions so this issue can be mitigated to a certain extent.
この能力では、外部で宣伝する必要がある内部ソースがある場合、DRまたはAnyCast-RPからレジスタメッセージを受信するAnycast-RPは、この仕様と処理方法と同様に処理する必要があります。[N1]で説明されているレジスタメッセージ。つまり、同じ内部ソースのソースアクティブ（SA）は、MSDPピアリングを行う複数のAnyCast-RPSによって発信される可能性があります。ソースがソースドメインの複数の場所からMSDPインフラストラクチャに宣伝されていること以外に、これに本質的に間違ったものはありません。ただし、これが望ましくない場合、1つ以上の（すべてではなく）1つ以上の（すべてではなく）Ruterの構成により、それらのルーターのみが内部ソースのSASを発信することができます。また、一部の状況では、セットのすべてのAnycast-RPSがMSDPピアリングセッションを持っているわけではないため、この問題をある程度緩和することができます。
From an Anycast-RP perspective, a source should be considered internal to a domain when it is discovered by an Anycast-RP through a received Register message, regardless of whether the Register message was sent by a DR, another Anycast-RP member, or the router itself.
Anycast-RPの観点から、ソースは、登録メッセージがDR、別のAnycast-RPメンバーによって送信されたかどうかに関係なく、受信したレジスタメッセージを介してAnycast-RPによって発見される場合、ドメインの内部と見なされる必要があります。ルーター自体。
For learning sources external to a domain, the MSDP SA messages could arrive at multiple MSDP-peering Anycast-RPs. The rules for processing an SA, according to [I1], should be followed. That is, if G is joined in the domain, an (S,G) join is sent towards the source. And if data accompanies the SA, each Anycast-PIM RP doing MSDP peering will forward the data down each of its respective shared-trees.
ドメインの外部の学習ソースの場合、MSDP SAメッセージは複数のMSDPを獲得するAnycast-RPSに到達する可能性があります。[I1]によると、SAを処理するためのルールに従う必要があります。つまり、Gがドメインに結合されている場合、（s、g）結合がソースに送信されます。また、データがSAに付随する場合、MSDP Peeringを実行する各Anycast-PIM RPは、それぞれの共有ツリーをそれぞれ下に転送します。
The above assumes each Anycast-RP has external MSDP peering connections. If this is not the case, the Anycast-PIM routers with the MSDP peering connections would follow the same procedure as if a Data-Register or Null-Register was received from either a DR or another Anycast-RP. That is, they would send Registers to the other members of the Anycast-RP set.
上記は、それぞれのAnycast-RPに外部MSDPピアリング接続があることを前提としています。そうでない場合、MSDPピアリング接続を備えたAnycast-PIMルーターは、DRまたは他のAnycast-RPからデータレジスターまたはnull-registerが受信された場合と同じ手順に従います。つまり、aycast-RPセットの他のメンバーにレジスタを送信します。
If there is a mix of Anycast-RPs that do and do not have external MSDP peering connections, then the ones that do must be configured with the set that do not. So Register messages are sent only to the members of the Anycast-RP set that do not have external MSDP peering connections.
The amount of Register traffic generated by this MSDP-peering RP would be equal to the number of active sources external to the domain. The Source-Active state would have to be conveyed to all other RPs in the Anycast-RP set since the MSDP-peering RP would not know about the group membership associated with the other RPs. To avoid this periodic control traffic, it is recommended that all Anycast-RPs be configured with external MSDP peering sessions so no RP in the Anycast-RP set will have to originate Register messages on behalf of external sources.
このMSDPを提供するRPによって生成されるレジスタトラフィックの量は、ドメインの外部のアクティブソースの数に等しくなります。MSDPを提供するRPが他のRPSに関連付けられているグループメンバーシップについて知らないため、Source-Active状態をAnycast-RPセットの他のすべてのRPSに伝える必要があります。この定期的な制御トラフィックを回避するには、すべてのAnycast-RPを外部MSDPピアリングセッションで構成することをお勧めします。そのため、Anycast-RPセットのRPは外部ソースに代わって登録メッセージを発信する必要がありません。
Within a routing domain, it is recommended that an Anycast-RP set defined in this specification should not be mixed with MSDP peering among the members. In some cases, the source discovery will work but it may not be obvious to the implementations which sources are local to the domain and which are not. This may affect external MSDP advertisement of internal sources.
ルーティングドメイン内では、この仕様で定義されているAnycast-RPセットをメンバー間でMSDPピアリングと混合しないことをお勧めします。場合によっては、ソースの発見は機能しますが、どのソースがドメインにローカルであり、そうでないかを実装することは明らかではないかもしれません。これは、内部ソースの外部MSDP広告に影響を与える可能性があります。
Having said that, this document makes no attempt to connect MSDP peering domains together by using Anycast-PIM inside a transit domain.
そうは言っても、このドキュメントは、Transitドメイン内でAnycast-Pimを使用してMSDPピアリングドメインを結びつけようとはしません。
This section describes the security consideration for Register and Register-Stop messages between Anycast-RPs. For PIM messages between DR and RP, please see [N1].
このセクションでは、Anycast-RPS間のレジスタストップメッセージとレジスタストップメッセージのセキュリティに関する考慮事項について説明します。DRとRPの間のPIMメッセージについては、[N1]を参照してください。
An attacker may forge a Register message using one of the addresses in the Anycast-RP list in order to achieve one or more of the following effects:
攻撃者は、次の1つ以上の効果を達成するために、Anycast-RPリストのアドレスのいずれかを使用してレジスタメッセージを偽造できます。
1. Overwhelm the target RP in a denial-of-service (DoS) attack 2. Inject unauthorized data to receivers served by the RP 3. Inject unauthorized data and create bogus SA entries in other PIM domains if the target RP has external MSDP peerings
1. ターゲットRPをサービス拒否（DOS）攻撃で圧倒します2. RPが提供する受信機に不正なデータを注入します。
An attacker may also forge a Register-Stop message using one of the addresses in the Anycast-RP list. However, besides denial-of-service, the effect of such an attack is limited because an RP usually ignores Register-Stop messages.
攻撃者は、Anycast-RPリストのアドレスのいずれかを使用して、レジスタストップメッセージを偽造することもできます。ただし、サービスの拒否に加えて、RPは通常レジスタストップメッセージを無視するため、このような攻撃の効果は制限されています。
The DoS attack using forged Register or Register-Stop messages cannot be prevented. But the RP can still be protected. For example, the RP can rate-limit incoming messages. It can also choose to refuse to process any Register-Stop messages. The actual protection mechanism is implementation specific.
偽造レジスタまたはレジスタストップメッセージを使用したDOS攻撃を防ぐことはできません。しかし、RPは引き続き保護できます。たとえば、RPは着信メッセージを制限することができます。また、レジスタストップメッセージの処理を拒否することもできます。実際の保護メカニズムは実装固有です。
The distribution of unauthorized data and bogus Register messages can be prevented using the method described in section 6.3.2 of [N1]. When RP1 sends a copy of a register to RP2, RP1 acts as [N1] describes the DR and RP2 acts as [N1] describes the RP.
[N1]のセクション6.3.2で説明した方法を使用して、不正データと偽のレジスタメッセージの分布を防ぐことができます。RP1がRP2にレジスタのコピーを送信すると、RP1は[N1]がDRを記述し、RP2は[N1]がRPを記述します。
As described in [N1], an RP can be configured using a unique SA and Security Parameter Index (SPI) for traffic (Registers or Register-Stops) to each member of Anycast-RPs in the list, but this results in a key management problem; therefore, it may be preferable in PIM domains where all Rendezvous Points are under a single administrative control to use the same authentication algorithm parameters (including the key) for all Registered packets in a domain.
[N1]で説明されているように、RPは、リスト内のAnyCast-RPSの各メンバーにトラフィック（レジスタまたはレジスタストップ）の一意のSAおよびセキュリティパラメーターインデックス（SPI）を使用して構成できますが、これにより重要な管理が得られます。問題;したがって、ドメイン内のすべての登録パケットの同じ認証アルゴリズムパラメーター（キーを含む）を使用するために、すべてのランデブーポイントが単一の管理制御下にあるPIMドメインでは望ましい場合があります。
The authors prototyped this document in the cisco IOS and Procket implementations, respectively.
著者は、Cisco iOSとProckeの実装でそれぞれこのドキュメントをプロトタイプしました。
The authors would like to thank John Zwiebel for doing interoperability testing of the two prototype implementations.
著者は、2つのプロトタイプ実装の相互運用性テストを行ってくれたJohn Zwiebelに感謝したいと思います。
The authors would like to thank Thomas Morin from France Telecom for having an extensive discussion on Multicast the Registers to an SSM-based full mesh among the Anycast-RP set. This idea may come in a subsequent document.
著者は、フランステレコムのThomas Morinに、マルチキャストThe RegistersについてSSMベースのフルメッシュをAnycast-RPセットの中で広範囲に議論してくれたことに感謝します。このアイデアは、後続の文書にあるかもしれません。
And finally, the authors would like to thank the following for their comments on earlier drafts:
そして最後に、著者は以前のドラフトに関するコメントについて以下に感謝したいと思います。
Greg Shepherd (Procket Networks (now Cisco Systems)) Lenny Giuliano (Juniper Networks) Prashant Jhingran (Huawei Technologies) Pekka Savola (CSC/FUNET) Bill Fenner (AT&T) James Lingard (Data Connection) Amit Shukla (Juniper Networks) Tom Pusateri (Juniper Networks)
Greg Shepherd（Procket Networks（現在のCisco Systems））Lenny Giuliano（Juniper Networks）Prashant Jhingran（Huawei Technologies）Pekka Savola（CSC/Funet）Bill Fenner（AT＆T）James Lingard（Data Connection）Amit Shukla（Juniper Networkks Pusateri（ジュニパーネットワーク）
[N1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[N1] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast -Sparse Mode（PIM -SM）：プロトコル仕様（改訂）」、RFC 4601、2006年8月。
[N2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[I1] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 2003.
[I1] Kim、D.、Meyer、D.、Kilmer、H。、およびD. Farinacci、「Anycast Rendevous Point（RP）プロトコル独立マルチキャスト（PIM）およびマルチキャストソースディスカバリープロトコル（MSDP）を使用したメカニズム」、RFC 34466、2003年1月。
Appendix A: Possible Configuration Language
付録A：可能な構成言語
A possible set of commands to be used could be:
使用されるコマンドの可能なセットは、次のとおりです。
ip pim anycast-rp <anycast-rp-addr> <rp-addr>
Where:
ただし：
<anycast-rp-addr> describes the Anycast-RP set for the RP that is assigned to the group range. This IP address is the address that first-hop and last-hop PIM routers use to register and join to.
<aycast-rp-addr>は、グループ範囲に割り当てられたRPのanycast-RPセットについて説明します。このIPアドレスは、登録と結合に最初のホップとラストホップのPIMルーターが使用するアドレスです。
<rp-addr> describes the IP address where Register messages copies are sent to. This IP address is any address assigned to the RP router not including the <anycast-rp-addr>.
<rp-addr>登録メッセージのコピーが送信されるIPアドレスについて説明します。このIPアドレスは、<aycast-rp-addr>を含めないRPルーターに割り当てられたアドレスです。
Example:
例：
From the illustration above, the configuration commands would be:
上記の図から、構成コマンドは次のとおりです。
ip pim anycast-rp RPA RP1 ip pim anycast-rp RPA RP2 ip pim anycast-rp RPA RP3
IP PIM ANYCAST-RP RPA RP1 IP PIM ANYCAST-RP RPA RP2 IP PIM ANYCAST-RP RPA RP3
Comment:
コメント：
It may be useful to include the local router IP address in the command set so the above lines can be cut-and-pasted or scripted into all the RPs in the Anycast-RP set.
上記の行をカットアンドペストでカットしたり、anycast-RPセットのすべてのRPにスクリプト化できるように、コマンドセットにローカルルーターIPアドレスを含めると便利かもしれません。
But the implementation would have to be aware of its own address and not inadvertently send a Register to itself.
しかし、実装はそれ自体の住所を認識し、登録を誤ってそれ自体に送信する必要はありません。
Authors' Addresses
著者のアドレス
Dino Farinacci Cisco Systems
Dino Farinacci Cisco Systems
EMail: dino@cisco.com
Yiqun Cai Cisco Systems
Yiqun Cai Cisco Systems
EMail: ycai@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。