[要約] RFC 3488は、Cisco Systems Router-port Group Management Protocol（RGMP）に関する規格です。RGMPは、ルーターポートグループの管理を目的としており、ポートグループの状態の通知や制御を提供します。
Network Working Group I. Wu
Request for Comments: 3488 T. Eckert
Category: Informational Cisco Systems
February 2003
Cisco Systems Router-port Group Management Protocol (RGMP)
シスコシステムルーターポートグループ管理プロトコル（RGMP）
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes the Router-port Group Management Protocol (RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed.
このドキュメントでは、ルーターポートグループ管理プロトコル（RGMP）について説明します。このプロトコルはCisco Systemsによって開発され、マルチキャストルーターとスイッチ間で使用され、スイッチのマルチキャストパケット転送をパケットが必要になる可能性のあるルーターに制限します。
RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected.
RGMPは、複数の高速ルーターが相互接続されているバックボーンスイッチ付きネットワーク用に設計されています。
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 BCP 14, RFC 2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、 BCP 14、RFC 2119 [2]に記載されているように解釈される。
IGMP Snooping is a popular, but not well documented mechanism to restrict multicast traffic, in switched networks, to those ports that want to receive the multicast traffic. It dynamically establishes and terminates multicast group specific forwarding in switches that support this feature.
IGMP Snoopingは、スイッチされたネットワークでマルチキャストトラフィックを受信したいポートに、マルチキャストトラフィックを制限するための人気がありますが、十分に文書化されていないメカニズムです。この機能をサポートするスイッチのマルチキャストグループ固有の転送を動的に確立および終了します。
The main limitation of IGMP Snooping is that it can only restrict multicast traffic onto switch ports where receiving hosts are connected directly or indirectly via other switches. IGMP Snooping can not restrict multicast traffic to ports where at least one multicast router is connected. It must instead flood multicast traffic to these ports. Snooping on IGMP messages alone is an intrinsic limitation. Through it, a switch can only learn which multicast flows are being requested by hosts. A switch can not learn through IGMP which traffic flows need to be received by router ports to be routed because routers do not report these flows via IGMP.
IGMPスヌーピングの主な制限は、受信ホストが他のスイッチを介して直接または間接的に接続されているスイッチポートにマルチキャストトラフィックを制限できることです。IGMPスヌーピングは、少なくとも1つのマルチキャストルーターが接続されているポートにマルチキャストトラフィックを制限することはできません。代わりに、これらのポートへのマルチキャストトラフィックをあふれさせなければなりません。IGMPメッセージだけでスヌーピングすることは、本質的な制限です。それを通して、スイッチは、どのマルチキャストフローがホストによって要求されているかを学習することができます。ルーターはIGMPを介してこれらのフローを報告しないため、スイッチはIGMPを介してルーターポートがルーティングする必要があるトラフィックフローをルーターで受信する必要があります。
In situations where multiple multicast routers are connected to a switched backbone, IGMP Snooping will not reduce multicast traffic load. Nor will it assist in increasing internal bandwidth through the use of switches in the network.
複数のマルチキャストルーターがスイッチ付きバックボーンに接続されている状況では、IGMPスヌーピングはマルチキャストトラフィック負荷を減らしません。また、ネットワーク内のスイッチを使用して内部帯域幅を増やすのにも役立ちません。
In switched backbone networks or exchange points, where predominantly routers are connected with each other, a large amount of multicast traffic may lead to unexpected congestion. It also leads to more resource consumption in the routers because they must discard the unwanted multicast traffic.
主にルーターが互いに接続されているスイッチされたバックボーンネットワークまたは交換ポイントでは、大量のマルチキャストトラフィックが予期しない混雑につながる可能性があります。また、不要なマルチキャストトラフィックを破棄する必要があるため、ルーターのリソース消費量が増えます。
The RGMP protocol described in this document restricts multicast traffic to router ports. To effectively restrict traffic, it must be supported by both the switches and the routers in the network.
このドキュメントで説明されているRGMPプロトコルは、ルーターポートへのマルチキャストトラフィックを制限しています。トラフィックを効果的に制限するには、ネットワーク内のスイッチとルーターの両方でサポートする必要があります。
The RGMP message format resembles the IGMPv2 message format so that existing switches, capable of IGMP Snooping, can easily be enhanced with this feature. Its messages are encapsulated in IPv4 datagrams, with a protocol number of 2, the same as that of IGMP. All RGMP messages are sent with TTL 1, to destination address 224.0.0.25. This address has been assigned by IANA to carry messages from routers to switches [3].
RGMPメッセージ形式は、IGMP2メッセージ形式に似ているため、IGMPスヌーピングが可能な既存のスイッチをこの機能で簡単に強化できます。そのメッセージはIPv4データグラムにカプセル化されており、プロトコル番号はIGMPと同じです。すべてのRGMPメッセージは、TTL 1で宛先アドレス224.0.0.25に送信されます。このアドレスは、ルーターからスイッチへのメッセージを伝えるためにIANAによって割り当てられています[3]。
RGMP is designed to work in conjunction with multicast routing protocols where explicit join/prune to the distribution tree is performed. PIM-SM [4] is an example of such a protocol.
RGMPは、分布ツリーに明示的な結合/プルーンが実行されるマルチキャストルーティングプロトコルと組み合わせて動作するように設計されています。PIM-SM [4]は、このようなプロトコルの例です。
The RGMP protocol specifies operations only for IP version 4 multicast routing. IP version 6 is not considered.
RGMPプロトコルは、IPバージョン4マルチキャストルーティングのみの操作を指定します。IPバージョン6は考慮されていません。
To keep RGMP simple, efficient and easy to implement, it is designed for switches to expect RGMP messages from only one source per port. For this reason, RGMP only supports a single RGMP enabled router to be connected directly to a port of an RGMP enabled switch. Such a topology should be customary when connecting routers to backbone switches and thus not pose a limitation on the deployment of RGMP.
RGMPをシンプルで効率的で実装しやすくするために、ポートごとに1つのソースからのみRGMPメッセージを期待するスイッチ用に設計されています。このため、RGMPは、RGMP対応スイッチのポートに直接接続する単一のRGMP対応ルーターのみをサポートしています。このようなトポロジーは、ルーターをバックボーンスイッチに接続するときに慣習的である必要があり、したがって、RGMPの展開に制限を与えません。
All RGMP messages have the following format:
すべてのRGMPメッセージには、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The reserved field in the message MUST be transmitted as zeros and ignored on receipt.
メッセージ内の予約済みフィールドは、ゼロとして送信され、受領時に無視する必要があります。
There are four types of RGMP messages of concern to the router-switch interaction. The type codes are defined to be the highest values in an octet to avoid the re-use of already assigned IGMP type codes.
ルータースイッチの相互作用には、懸念のあるRGMPメッセージには4種類のタイプがあります。タイプコードは、すでに割り当てられているIGMPタイプコードの再利用を避けるために、オクテットの最高値であると定義されています。
0xFF = Hello 0xFE = Bye 0xFD = Join a group 0xFC = Leave a group
0xff = hello 0xfe = bye 0xfd =グループに参加する0xfc =グループを残す
Unrecognized message types should be silently ignored.
認識されていないメッセージタイプは静かに無視する必要があります。
Note:
注記：
RGMP and the IANA assignment of address 224.0.0.25 for it predates RFC 3228 [9]. RGMP defines Type values which in RFC 3228 are assigned to protocol testing and experimentation. This is not an operational issue for RGMP itself because only RGMP packets use the IPv4 destination address 224.0.0.25. The Type values defined above are thus ONLY valid in conjunction with the RGMP destination address.
RGMPおよびITのINAのINAの割り当て224.0.0.25は、RFC 3228より前のものです[9]。RGMPは、RFC 3228でプロトコルテストと実験に割り当てられているタイプ値を定義します。これは、RGMPパケットのみがIPv4宛先アドレス224.0.0.25を使用しているため、RGMP自体の運用上の問題ではありません。したがって、上記のタイプ値は、RGMP宛先アドレスと組み合わせてのみ有効です。
Checksum covers the RGMP message (the entire IPv4 payload). The algorithm and handling of checksum are the same as those for IGMP messages as described in RFC 3376 [5].
チェックサムは、RGMPメッセージ（IPv4ペイロード全体）をカバーします。チェックサムのアルゴリズムと取り扱いは、RFC 3376 [5]に記載されているように、IGMPメッセージのアルゴリズムと同じです。
In an RGMP Hello or Bye message, the group address field is set to zero.
RGMP HelloまたはByeメッセージでは、グループアドレスフィールドがゼロに設定されています。
In an RGMP Join or Leave message, the group address field holds the IPv4 multicast group address of the group being joined or left.
RGMPの結合または去るメッセージで、グループアドレスフィールドは、結合または左になっているグループのIPv4マルチキャストグループアドレスを保持します。
RGMP messages are sent by routers to switches. The source IPv4 address of an RGMP packet is the sending interface IPv4 address of the originating router. The destination IPv4 address of an RGMP packet is 224.0.0.25. Switches supporting RGMP need to listen to packets to this group.
RGMPメッセージは、ルーターによってスイッチに送信されます。RGMPパケットのソースIPv4アドレスは、発信ルーターの送信インターフェイスIPv4アドレスです。RGMPパケットの宛先IPv4アドレスは224.0.0.25です。RGMPをサポートするスイッチは、このグループにパケットを聴く必要があります。
Backbone switches use RGMP to learn which groups are desired at each of their ports. Multicast routers use RGMP to pass such information to the switches. Only routers send RGMP messages. They ignore received RGMP messages.
バックボーンスイッチはRGMPを使用して、各ポートでどのグループが望ましいグループを学習します。マルチキャストルーターはRGMPを使用して、そのような情報をスイッチに渡します。ルーターのみがRGMPメッセージを送信します。受信したRGMPメッセージを無視します。
A Router enabled for RGMP on an interface periodically [Hello Interval] sends an RGMP Hello message to the attached network to indicate that it is RGMP enabled. When RGMP is disabled on a routers interface, it will send out an RGMP Bye message on that interface, indicating that it again wishes to receive IPv4 multicast traffic promiscuously from that interface.
定期的に[Hello Interval]インターフェイス上のRGMPのルーターが有効になっているため、RGMPが添付されたネットワークにRGMPのハローメッセージを送信して、RGMPが有効であることを示します。RGMPがルーターインターフェイスで無効になっている場合、そのインターフェイスにRGMP Byeメッセージが送信され、再びそのインターフェイスからIPv4マルチキャストトラフィックを乱交で受け取ることを望んでいることが示されます。
When an interface is RGMP enabled, a router sends an RGMP Join message out through this interface to each group that it wants to receive traffic for from the interface. The router needs to periodically [Join Interval] re-send an RGMP Join for a group to indicate its continued desire to receive multicast traffic.
インターフェイスがRGMPを有効にすると、ルーターはこのインターフェイスを介して各グループにRGMPの結合メッセージを送信し、インターフェイスからトラフィックを受け取りたいと考えています。ルーターは定期的に[インターバル]インターバルを再送信する必要があります。RGMP結合は、マルチキャストトラフィックを受けたいという継続的な欲求を示すためにグループに参加します。
Routers supporting RGMP MUST NOT send RGMP Join or Leave messages for groups 224.0.0.x (x=0...255), 224.0.1.39 and 224.0.1.40. The latter two are known as cisco-rp-announce and cisco-rp-discovery [3].
RGMPをサポートするルーターは、グループ224.0.0.x（x = 0 ... 255）、224.0.1.39および224.0.1.40のRGMP結合または残しメッセージを送信してはなりません。後者の2つは、Cisco-RP-AnnounceおよびCisco-RP発見として知られています[3]。
When a router no longer needs to receive traffic for a particular group, it sends an RGMP Leave message for the group. For robustness, the router MAY send more than one such message.
ルーターが特定のグループのトラフィックを受信する必要がなくなった場合、グループにRGMPの残しメッセージを送信します。堅牢性のために、ルーターはそのようなメッセージを複数送信する場合があります。
If IPv4 multicast packets for an undesired group are received at a router from a switch, the router MAY send a RGMP Leave message for that group to the switch. These messages are called data-triggered RGMP Leave messages and the router SHOULD rate-limit them. The router MAY suppress sending a data triggered RGMP Leave message if it has a desired group that has the same MAC destination address as the undesired group. (See RFC 1112 [6] for MAC ambiguity.) Such suppression of data triggered RGMP Leave messages SHOULD be configurable if supported.
望ましくないグループ用のIPv4マルチキャストパケットがスイッチからルーターで受信された場合、ルーターはそのグループにRGMPの残しメッセージをスイッチに送信する場合があります。これらのメッセージは、データトリガーされたRGMPの残しメッセージと呼ばれ、ルーターはそれらをレートに制限する必要があります。ルーターは、望ましくないグループと同じMAC宛先アドレスを持つ目的のグループがある場合、データトリガーされたRGMP休暇メッセージの送信を抑制する場合があります。（MACのあいまいさについてはRFC 1112 [6]を参照してください。）データのそのような抑制がトリガーされたRGMP残りメッセージは、サポートされている場合は設定可能である必要があります。
A switch enabled for RGMP on a network consumes RGMP messages received from ports of the network and processes them as described below. If enabled for RGMP, the switch must NOT forward/flood received RGMP messages out to other ports of the network.
ネットワーク上のRGMPのスイッチは、ネットワークのポートから受信したRGMPメッセージを消費し、以下に説明するようにそれらを処理します。RGMPで有効になっている場合、スイッチはフォワード/フラッドがネットワークの他のポートにRGMPメッセージを受信してはなりません。
RGMP on a switch operates on a per port basis, establishing per-group forwarding state on RGMP enabled ports. A port reverts into an RGMP enabled port upon receipt of an RGMP Hello message on the port, and a timer [5 * Hello Interval] is started. This timer is restarted by each RGMP Hello message arriving on the port. If this timer expires or if it is removed by the arrival of an RGMP Bye message, then the port reverts to its prior state of multicast traffic forwarding.
スイッチのRGMPはポートごとに動作し、RGMP対応ポートにグループごとの転送状態を確立します。ポートは、ポートでRGMPハローメッセージを受信すると、RGMP対応のポートに戻り、タイマー[5 * Hello interval]が開始されます。このタイマーは、ポートに到着する各RGMP Helloメッセージによって再起動されます。このタイマーが期限切れになった場合、またはRGMP Byeメッセージの到着によって削除された場合、ポートは以前のマルチキャストトラフィック転送の状態に戻ります。
Correct deployment of RGMP is one RGMP enabled router directly connected to a port on a switch that supports RGMP. The port on the switch MAY want to keep track of the IPv4 originator address of the RGMP Hello and Bye messages it receives on that port. In the event it receives multiple IPv4 originating addresses in RGMP messages on one port, the switch MAY generate an alert to notify the administrator. The switch MAY also have a configuration option that will allow for the operator to disable RGMP and have the switch fall back to flooding IPv4 multicast on that port, although this is a potentially dangerous option.
RGMPの正しい展開は、RGMPをサポートするスイッチ上のポートに直接接続された1つのRGMP対応ルーターです。スイッチ上のポートは、RGMPのIPv4オリジナーターアドレスを追跡し、そのポートで受け取ったByeメッセージを追跡したい場合があります。1つのポートのRGMPメッセージで複数のIPv4発信アドレスを受信した場合、スイッチは管理者に通知するアラートを生成する場合があります。また、スイッチには、オペレーターがRGMPを無効にし、スイッチをそのポートのフラッディングIPv4マルチキャストに戻すことができる構成オプションがある場合がありますが、これは潜在的に危険なオプションです。
By default, connecting two or more RGMP enabled routers to a switch port will cause intermittent black holing of IPv4 multicast traffic towards these routers. Black holing occurs when a RGMP Leave is received from one router while the other router is still joined.
デフォルトでは、2つ以上のRGMPを有効にするルーターをスイッチポートに接続すると、これらのルーターにIPv4マルチキャストトラフィックが断続的にブラックホーリングされます。Black Holingは、RGMP休暇を1つのルーターから受信し、もう1つのルーターがまだ結合されている場合に発生します。
This malfunction is not only easily recognized by the actual users connected through the routers, but it also adheres to the principle that a failure situation causes less traffic than more. Reverting to flooding easily maintains the illusion that everything is working perfectly. The exception is that the traffic constraining benefits of RGMP are not realized. This suggests that congestion happens at a much later time than the misconfiguration and can then not easily be correlated with the cause anymore.
この誤動作は、ルーターを介して接続されている実際のユーザーによって簡単に認識されるだけでなく、障害の状況がより少ないトラフィックを引き起こすという原則にも準拠しています。洪水に戻ることは、すべてが完全に機能しているという幻想を容易に維持します。例外は、RGMPのトラフィック制約の利点が実現されていないことです。これは、混雑が誤解よりもはるかに遅れて発生することを示唆しており、もはや原因と簡単に相関することはありません。
Because routers supporting RGMP are not required to send RGMP Join or Leave messages for groups 224.0.0.x (x=0...255), 224.0.1.39 and 224.0.1.40, RGMP enabled ports always need to receive traffic for these groups. Traffic for other groups is initially not forwarded to an RGMP enabled port.
RGMPをサポートするルーターは、グループ224.0.0.x（x = 0 ... 255）、224.0.1.39および224.0.1.40にRGMPの参加または残しメッセージを送信する必要がないため、RGMP対応ポートは常にこれらのグループのトラフィックを受信する必要があります。。他のグループのトラフィックは、最初はRGMP対応ポートに転送されません。
RGMP Join and Leave messages are accepted if they arrive on an RGMP enabled port, otherwise they will be discarded. Upon acceptance of an RGMP Join message, the switch MUST start forwarding traffic for the group to the port. Upon acceptance of an RGMP Leave message, the switch SHOULD stop forwarding traffic for the group to that port. The switch's ability to stop forwarding traffic for a group may be limited, for example, because of destination MAC based forwarding in the switch. Therefore, it is necessary for the switch to always forward traffic for all MAC-ambiguous IPv4 multicast groups (see [6] for MAC-ambiguity).
RGMP結合およびリフェストメッセージは、RGMP対応のポートに到着した場合に受け入れられます。それ以外の場合は、破棄されます。RGMP結合メッセージを受け入れると、スイッチはグループのトラフィックの転送をポートに転送する必要があります。RGMPの残しメッセージを受け入れると、スイッチはそのポートへのグループのトラフィックの転送を停止する必要があります。たとえば、スイッチ内の宛先Macベースの転送のため、グループのトラフィックの転送を停止するスイッチの機能は制限される場合があります。したがって、すべてのMac-Ambigous IPv4マルチキャストグループのスイッチが常に転送される必要があります（Mac-Ambiguityについては[6]を参照）。
To stop forwarding of traffic to a group in the event of lost RGMP Leave message(s), a switch MAY time out RGMP forwarding state on a port for a group [5 * Join Interval] after the last RGMP Join for that group has been received on the port.
失われたRGMP残しメッセージが発生した場合にグループへのトラフィックの転送を停止するために、そのグループの最後のRGMP結合の後、グループのポート[5 *結合間隔]のスイッチタイムアウトRGMP転送状態があります。ポートで受け取った。
Without any layer 2 IPv4 multicast filtering methods running, a switch needs to flood multicast traffic to all ports. If a switch does actually run one or more mechanisms beside RGMP to filter IPv4 multicast traffic, such as IGMP snooping [10], then by default it will not flood IPv4 multicast traffic to all ports anymore. Instead, the switch will try to determine which ports still needs to receive all IPv4 multicast traffic by default, and which ports do not.
レイヤー2 IPv4マルチキャストフィルタリングメソッドが実行されていないため、スイッチはすべてのポートにマルチキャストトラフィックを浸水させる必要があります。スイッチが実際にRGMPの横に1つ以上のメカニズムを実行してIGMPスヌーピングなどのIPv4マルチキャストトラフィックをフィルタリングした場合、デフォルトでは、すべてのポートにIPv4マルチキャストトラフィックをflood濫させることはありません。代わりに、スイッチは、デフォルトですべてのIPv4マルチキャストトラフィックを受け取る必要があるポートを決定しようとします。
Compliance with this specification requires that a switch MUST be able to elect a port for flooding through the presence of PIM Hello messages [4] arriving from the port and also through a manual configuration option. In addition, the switch SHOULD recognize a port connected to a router by other appropriate protocol packets or dedicated IPv4 multicast router discovery mechanisms such as MRDISC [11]. The manual configuration is required to support routers not supporting PIM or other methods recognized by the switch.
この仕様のコンプライアンスには、PIM Helloメッセージ[4]がポートから到着し、手動構成オプションを介して浸水するためのポートをスイッチを選択できる必要があります。さらに、スイッチは、他の適切なプロトコルパケットまたはMRDISCなどの専用のIPv4マルチキャストルーター発見メカニズムによってルーターに接続されたポートを認識する必要があります[11]。手動構成は、PIMまたはスイッチによって認識されたその他の方法をサポートしないルーターをサポートするために必要です。
Further mechanisms for IPv4 multicast traffic restriction may also be used on RGMP enabled ports. In this case, forwarding for a group on the port must be established if either mechanism requires it, and it must only be removed if no mechanism requires it anymore.
IPv4マルチキャストトラフィック制限のさらなるメカニズムは、RGMP対応ポートでも使用できます。この場合、いずれかのメカニズムがそれを必要とする場合は、ポート上のグループの転送を確立する必要があり、メカニズムがもう必要ない場合にのみ削除する必要があります。
To be simple to implement on switches and resilient in face of potential layer 2 network topology changes, RGMP does not specify how to restrict multicast traffic on links connecting switches amongst each other. With just RGMP being used, multicast traffic will thus be flooded on inter-switch links within a network if at least one router is connected to each of the switches.
潜在的なレイヤー2ネットワークトポロジの変更に直面してスイッチを簡単に実装し、回復力があるため、RGMPは互いにスイッチを接続するリンクでマルチキャストトラフィックを制限する方法を指定しません。したがって、RGMPのみが使用されているため、少なくとも1つのルーターが各スイッチに接続されている場合、ネットワーク内のスイッチ間リンクにマルチキャストトラフィックがあふれます。
This happens implicitly because the switch will not flood/forward received RGMP messages out to the inter-switch link and thus the switch on the other end will only recognize the port as a router port via the PIM Hello messages flooded by the switches. Manual configuration for inter-switch links may be required if non-PIM routers are being used, depending on the other capabilities of the switch.
これは暗黙的に発生します。スイッチが洪水/前方にRGMPメッセージをスイッチ間リンクに送信しないため、反対側のスイッチは、スイッチによって浸水したPIM Helloメッセージを介してルーターポートとしてポートを認識します。スイッチの他の機能に応じて、非PIMルーターが使用されている場合、スイッチ間リンクの手動構成が必要になる場合があります。
If appropriate, a switch can send out RGMP messages on ports to make it look like an RGMP enabled router to a potential switch at the other end of the link. This would constrain IPv4 multicast traffic between switches, but this type of "RGMP Spoofing" by the switch is outside the scope of this specification.
必要に応じて、スイッチはポートでRGMPメッセージを送信して、RGMP有効なルーターのように見えるようにし、リンクの反対側の潜在的なスイッチになります。これにより、スイッチ間のIPv4マルチキャストトラフィックが制約されますが、スイッチによるこのタイプの「RGMPスプーフィング」は、この仕様の範囲外です。
Since RGMP messages received at a switch only affect the state of their ingress ports, the traffic restriction is applied there only. RGMP-incapable routers will receive multicast traffic for all multicast groups.
スイッチで受信したRGMPメッセージは、入り口ポートの状態にのみ影響するため、トラフィックの制限はそこでのみ適用されます。RGMPに入れられないルーターは、すべてのマルチキャストグループのマルチキャストトラフィックを受け取ります。
One result of the simplicity of RGMP are its restrictions in supporting specific routing protocols. The following paragraphs list a few known restrictions.
RGMPの単純さの結果の1つは、特定のルーティングプロトコルをサポートする上での制限です。次の段落には、いくつかの既知の制限がリストされています。
A router running RGMP on a switched network will not receive traffic for a multicast group unless it explicitly requests it via RGMP Join messages (besides those group ranges specified to be flooded in 3.1). For this reason, it is not possible to run a protocol like PIM Dense-Mode or DVMRP across an RGMP enabled network with RGMP enabled routers.
スイッチネットワークでRGMPを実行しているルーターは、RGMP参加メッセージを介して明示的に要求しない限り、マルチキャストグループのトラフィックを受け取りません（3.1で浸水するように指定されたグループ範囲を除く）。このため、RGMP対応のルーターを使用してRGMP対応ネットワーク全体でPIM Dense-ModeやDVMRPなどのプロトコルを実行することはできません。
In Bidir-PIM, a router elected to be the DF must not be enabled for RGMP on the network, because it unconditionally needs to forward traffic received from the network towards the RP. If a router is not the DF for any group on the network, it can be enabled for RGMP on that network.
Bidir-PIMでは、ネットワーク上のRGMPでDFに選出されたルーターを有効にしてはなりません。ルーターがネットワーク上のどのグループのDFでない場合、そのネットワーク上のRGMPで有効にすることができます。
In PIM-SM, directly connected sources on the network can not be supported if the elected DR is running RGMP, because this DR needs to unconditionally receive traffic from directly connected sources to trigger the PIM-SM registering process on the DR. In PIM-SSM, directly connected sources can be supported with RGMP enabled routers.
PIM-SMでは、選出されたDRがRGMPを実行している場合、ネットワーク上の直接接続されたソースをサポートできません。このDRは、DRのPIM-SM登録プロセスをトリガーするために、直接接続されたソースから無条件にトラフィックを受け取る必要があるためです。PIM-SSMでは、直接接続されたソースをRGMP対応ルーターでサポートできます。
Both in PIM-SM and PIM-SSM, upstream routers forwarding traffic into the switched network need to send RGMP Joins for the group in support of the PIM assert process.
PIM-SMとPIM-SSMの両方で、アップストリームルーターがスイッチネットワークにトラフィックを転送する上流ルーターは、PIMアサートプロセスをサポートするためにグループにRGMP結合を送信する必要があります。
The Hello Interval is the interval between RGMP Hello messages sent by an RGMP-enabled router to an RGMP-enabled switch. Default: 60 seconds.
Hello間隔は、RGMP対応のルーターからRGMP対応スイッチに送信されたRGMP Helloメッセージ間の間隔です。デフォルト：60秒。
The Join Interval is the interval between periodic RGMP Join messages sent by an RGMP-enabled router to an RGMP-enabled switch for a given group address. Default: 60 seconds.
結合間隔は、特定のグループアドレスのRGMP対応ルーターによって送信されたRGMP対応ルーターによって送信されたメッセージの定期的なRGMP結合メッセージ間の間隔です。デフォルト：60秒。
The RGMP protocol assumes that physical port security can be guaranteed for switch ports from which RGMP messages are accepted. Physical port security for RGMP means that physical measures will ensure that such ports are dedicatedly connected to one system which acts as an RGMP capable router. This is also the recommended configuration to best leverage the benefits of the RGMP protocol (e.g., avoiding unwanted third-party IPv4 multicast traffic arriving on said ports).
RGMPプロトコルは、RGMPメッセージが受け入れられるスイッチポートに対して物理ポートセキュリティを保証できると想定しています。RGMPの物理的なポートセキュリティは、物理的な測定により、そのようなポートがRGMP対応ルーターとして機能する1つのシステムに専用に接続されることを保証することを意味します。これは、RGMPプロトコルの利点を最適に活用するための推奨構成でもあります（たとえば、そのポートに到着する不要なサードパーティのIPv4マルチキャストトラフィックを回避します）。
RGMP specific DoS attacks arise from forged RGMP messages. If more than one system is connected to a port of the RGMP switch, then one system may forge RGMP messages and affect the operations of the other system(s) on the same port. This is a potential security risk.
RGMP固有のDOS攻撃は、偽造されたRGMPメッセージから発生します。複数のシステムがRGMPスイッチのポートに接続されている場合、1つのシステムがRGMPメッセージを偽造し、同じポートの他のシステムの操作に影響を与える可能性があります。これは潜在的なセキュリティリスクです。
When physical security ensures that only one system is connected to a RGMP capable port on a switch, then forged messages from this system itself can take effect. Such forged messages can always be avoided by system local measures.
物理的なセキュリティにより、1つのシステムのみがスイッチ上のRGMP対応ポートに接続されていることを保証すると、このシステム自体からの偽造メッセージが有効になります。このような偽造メッセージは、システムローカルメジャーによっていつでも回避できます。
We consider the ramifications of a forged message of each type:
各タイプの偽造メッセージの影響を検討します。
Hello Message:
こんにちはメッセージ：
A forged RGMP Hello message can restrict multicast data towards a non-RGMP enabled router on the same port. This effectively introduces a blackholing DoS attack.
偽造されたRGMP Helloメッセージは、同じポートの非RGMP対応ルーターにマルチキャストデータを制限できます。これにより、ブラックホールのDOS攻撃が効果的に導入されます。
Leave Message:
メッセージを残す：
A forged RGMP Leave message can restrict IPv4 multicast traffic for individual groups toward the port. The effect is a possible blackholing DoS attack similar to an RGMP Hello Message except that it does not affect all IPv4 multicast traffic but only that of the groups indicated in the forged messages. It will also only affect a port if there officially is only one RGMP enabled router connected to it (i.e., if the port is RGMP enabled).
偽造されたRGMP残しメッセージは、ポートに向かって個々のグループのIPv4マルチキャストトラフィックを制限できます。効果は、すべてのIPv4マルチキャストトラフィックに影響を与えないが、偽造メッセージに示されているグループのみに影響することを除いて、RGMP Helloメッセージに似たBlackholing DOS攻撃の可能性です。また、公式には1つのRGMP有効なルーターのみが接続されている場合にのみポートに影響します（つまり、ポートがRGMPを有効にしている場合）。
Bye Message:
さようならメッセージ：
A forged RGMP Bye message can turn the port into being RGMP-disabled. This could, indirectly, cause a DoS attack based on the port getting overloaded with IPv4 multicast traffic if the network bandwidth of the port was provisioned with the expectation that RGMP will suppress unwanted IPv4 multicast messages.
偽造されたRGMP Byeメッセージは、ポートをRGMPに変えることができるようになります。これにより、ポートのネットワーク帯域幅がRGMPが不要なIPv4マルチキャストメッセージを抑制するという期待を持ってプロビジョニングされた場合、ポートがIPv4マルチキャストトラフィックで過負荷になることに基づくDOS攻撃を間接的に引き起こす可能性があります。
This type of DoS attack simply re-establishes a port behavior as if RGMP was not configured and invalidates the benefit of RGMP. This, however, does not introduce an issue that would not have been there without RGMP in the first place.
このタイプのDOS攻撃は、RGMPが構成されていないかのように、単にポート動作を再確立し、RGMPの利点を無効にします。ただし、これは、そもそもRGMPがなければそこにいなかった問題を導入するものではありません。
Join Message:
メッセージに参加：
A forged RGMP Join message could attract undesired multicast packets to the port where it is received from. The effect is similar to an RGMP Bye Message except that it does not affect all IPv4 multicast traffic only the groups indicated in the forged messages. The message will affect a port only if there officially is only one RGMP enabled router connected to it (i.e., if the port is RGMP enabled).
偽造されたRGMP結合メッセージは、受信したポートに望ましくないマルチキャストパケットを引き付ける可能性があります。効果は、すべてのIPv4マルチキャストトラフィックに影響を与えないことを除いて、RGMP Byeメッセージに似ています。メッセージは、正式に1つのRGMP有効なルーターのみが接続されている場合にのみポートに影響します（つまり、ポートがRGMPを有効にしている場合）。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] 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.
[4] 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モード（PIM-SM）：プロトコル仕様」、RFC 2362、1998年6月。
[5] Cain, B., Deering, S., Kouvelas, I., Fenner, W. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[5] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、W。and A. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[6] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[6] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[7] ANSI/IEEE Std 802.1D 1998 Edition, "Media Access Control (MAC) Bridges", 1998.
[7] ANSI/IEEE STD 802.1d 1998エディション、「Media Access Control（Mac）Bridges」、1998。
[3] Internet Multicast Addresses, http://www.iana.org/assignments/multicast-addresses
[3] インターネットマルチキャストアドレス、http：//www.iana.org/assignments/multicast-addresses
[8] Farinacci D., Tweedly D., Speakman T., "Cisco Group Management Protocol (CGMP)", 1996/1997 ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[8] Farinacci D.、Tweedly D.、Speakman T。、「Cisco Group Management Protocol（CGMP）」、1996/1997 ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[9] Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", RFC 3228, February 2002.
[9] Fenner、B。、「IPv4インターネットグループ管理プロトコル（IGMP）のIANA考慮事項」、RFC 3228、2002年2月。
[10] Christensen, M. and F. Solensky, "IGMP and MLD snooping switches", Work In Progress.
[10] Christensen、M。and F. Solensky、「IGMPおよびMLD Snooping Switches」、進行中の作業。
[11] Biswas, S., Cain, B. and B. Haberman, "IGMP Multicast Router Discovery", Work In Progress.
[11] Biswas、S.、Cain、B。and B. Haberman、「IGMPマルチキャストルーターディスカバリー」、作業進行中。
The authors would like to thank Gorry Fairhurst, Bill Fenner, Giovanni Meo, Mike Norton, Pavlin Radoslavov and Alex Zinin for their review of the document and their suggestions.
著者は、Gorry Fairhurst、Bill Fenner、Giovanni Meo、Mike Norton、Pavlin Radoslavov、Alex Zininの文書と提案のレビューに感謝します。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、請求権のオンラインリストを参照してください。
Appendix B. Comparison with GARP/GMRP
付録B. GARP/GMRPとの比較
This appendix is not part of the RGMP specification but is provided for information only.
この付録は、RGMP仕様の一部ではなく、情報のみを提供しています。
GARP/GMRP (defined in IEEE 802.1D [7]) is the ANSI/ISO/IEC/IEEE protocol suite to constrain ethernet multicast traffic in bridged ethernet networks. As such it is also a possible alternative to RGMP for the purpose of constraining multicast traffic towards router ports. This appendix will explain the motivation not to rely on GARP/GMRP and how GARP/GMRP and RGMP differ.
GARP/GMRP（IEEE 802.1d [7]で定義）は、Bridged Ethernet Networksのイーサネットマルチキャストトラフィックを制約するANSI/ISO/IEC/IEEEプロトコルスイートです。そのため、ルーターポートにマルチキャストトラフィックを制限する目的で、RGMPの代替品でもあります。この付録では、GARP/GMRPに依存しない動機と、GARP/GMRPとRGMPがどのように異なるかを説明します。
The key factor in rolling out GARP/GMRP would have been to completely replace IGMP Snooping. This was the design goal of GARP/GMRP. For efficient operations, IGMP Snooping requires hardware filtering support in the switch (to differentiate between hosts membership reports and actual IPv4 multicast traffic). Especially in many older switches this support does not exist. Vendors tried to find a way around this issue to provide the benefit of constraining IPv4 multicast traffic in a switched LAN without having to build more expensive switch hardware. GARP/GMRP is one protocol resulting from this. CGMP from Cisco is another one. While CGMP solves the problem without requiring changes to the host stack software, GARP/GMRP requires support for it by the host stack.
GARP/GMRPを展開する重要な要因は、IGMPスヌーピングを完全に置き換えることでした。これがGARP/GMRPの設計目標でした。効率的な操作のために、IGMPスヌーピングでは、スイッチでのハードウェアフィルタリングサポートが必要です（ホストメンバーシップレポートと実際のIPv4マルチキャストトラフィックを区別するため）。特に多くの古いスイッチでは、このサポートは存在しません。ベンダーは、より高価なスイッチハードウェアを構築することなく、切り替えられたLANにIPv4マルチキャストトラフィックを制約するという利点を提供するために、この問題を回避する方法を見つけようとしました。GARP/GMRPは、これに起因する1つのプロトコルです。シスコのCGMPは別のCGMPです。CGMPはホストスタックソフトウェアの変更を必要とせずに問題を解決しますが、GARP/GMRPはホストスタックによるサポートを必要とします。
Up to date GARP/GMRP has so far not made significant inroads into deployed solutions. IGMP Snooping (and CGMP) are the norm for this environment. In result, GARP/GMRP can not necessarily be expected to be supported by layer 2 switches. In addition, GARP/GMRP does not address clearly the issues RGMP tries to solve. On one hand, GARP/GMRP provides much more functionality and as such complexity as immediately required. On the other hand, GARP/GMRP is limited by being a standard predominantly for the Ethernet scope.
最新のGARP/GMRPは、これまでのところ、展開されたソリューションに大きな侵入を行っていません。IGMPスヌーピング（およびCGMP）は、この環境の標準です。その結果、GARP/GMRPがレイヤー2スイッチによって必ずしもサポートされるとは期待できません。さらに、GARP/GMRPは、RGMPが解決しようとする問題について明確に対処していません。一方では、GARP/GMRPは、はるかに多くの機能を提供し、すぐに必要なような複雑さを提供します。一方、GARP/GMRPは、主にイーサネットスコープの標準であることにより制限されます。
Beyond the process and applicability reasons, the main differences between GARP/GMRP and RGMP are as follows:
プロセスと適用性の理由を超えて、GARP/GMRPとRGMPの主な違いは次のとおりです。
o GARP/GMRP switches/systems need to send and listen/react to GARP/GMRP messages. In RGMP, routers only need to send RGMP messages and switches only need to listen to them. This protocol approach is meant to simplify implementation, operations and troubleshooting.
o GARP/GMRPスイッチ/システムは、GARP/GMRPメッセージを送信および聞く/反応する必要があります。RGMPでは、ルーターはRGMPメッセージを送信するだけで、スイッチはそれらに耳を傾けるだけです。このプロトコルアプローチは、実装、操作、トラブルシューティングを簡素化することを目的としています。
o The same switch running RGMP in a backbone network will likely see more states then running on the edge only doing IGMP Snooping, making it preferable to keep the amount of per group processing and memory requirements in RGMP more in bounds than possible in IGMP Snooping and GARP/GMRP: In GARP/GMRP, a (multiple) timer based state-machines needs to be maintained on a per ethernet group address, in RGMP timer maintenance is completely optional and there are only two states per group (joined or not joined).
o バックボーンネットワークでRGMPを実行している同じスイッチでは、IGMPスヌーピングのみを実行するエッジで実行されるより多くの状態が見られる可能性があります。/GMRP：GARP/GMRPでは、（複数の）タイマーベースの状態マシンをイーサネットグループアドレスごとに維持する必要があります。RGMPタイマーのメンテナンスは完全にオプションであり、グループごとに2つの状態しかありません（結合または結合されていません）。
o GARP/GMRP is an ethernet level protocol from the IEEE. It supports to constrain traffic for ethernet addresses (groups). RGMP does constrain traffic for IPv4 multicast groups. Today this is even beyond the capabilities of typical switch platforms used as layer2 switches. Extensions to support further entities are likely easier to come by through extensions to RGMP than to GARP/GMRP.
o GARP/GMRPは、IEEEのイーサネットレベルのプロトコルです。イーサネットアドレス（グループ）のトラフィックを制限することをサポートします。RGMPは、IPv4マルチキャストグループのトラフィックを制約します。今日、これはlayer2スイッチとして使用される典型的なスイッチプラットフォームの機能を超えています。さらなるエンティティをサポートするための拡張は、GARP/GMRPよりもRGMPへの拡張を介して簡単に到達することができます。
o RGMP shares the basic packet format with IGMP (version 2) and is as such easy to add to router and switch platforms that already support IGMP and IGMP Snooping respectively. This is especially true for switches that in hardware can differentiate between IGMP protocol type packets and other IPv4 multicast traffic sent to the same (or a MAC ambiguous) group. In addition, due to the state simplicity of RGMP it is easy to integrate IGMP Snooping and RGMP operations in the IPv4 multicast control and forwarding plane of a switch.
o RGMPは、基本的なパケット形式をIGMP（バージョン2）と共有しており、それぞれIGMPとIGMPのスヌーピングをサポートするルーターおよびスイッチプラットフォームに簡単に追加できます。これは、ハードウェア内のIGMPプロトコルタイプパケットと、同じ（またはMacの曖昧な）グループに送信される他のIPv4マルチキャストトラフィックを区別できるスイッチに特に当てはまります。さらに、RGMPの状態のシンプルさにより、IGMPスヌーピングとRGMP操作をIPv4マルチキャスト制御とスイッチの転送面で簡単に統合することは簡単です。
o GARP/GMRP supports more than one system (host/router) on a switch port which is one reason for its complexity. In RGMP, this configuration is explicitly not supported: More than one router per switched port is not only not a common scenario in today's switches layer 2 networks, it is also an undesired configuration when unwanted IPv4 multicast traffic is to be kept away from routers.
o GARP/GMRPは、スイッチポートで複数のシステム（ホスト/ルーター）をサポートしています。これは、その複雑さの1つの理由です。RGMPでは、この構成は明示的にサポートされていません。スイッチされたポートごとに複数のルーターが今日のスイッチレイヤー2ネットワークの一般的なシナリオではなく、不要なIPv4マルチキャストトラフィックがルーターから遠ざけられている場合に望ましくない構成でもありません。
o GARP/GMRP defines how to constrain multicast traffic between switches, another reason for its complexity. RGMP does not explicitly support this as part of the protocol because of the following reasons:
o GARP/GMRPは、スイッチ間でマルチキャストトラフィックを制約する方法を定義します。これは、その複雑さのもう1つの理由です。RGMPは、次の理由により、プロトコルの一部としてこれを明示的にサポートしていません。
o It is not necessary to include this function as part of the RGMP protocol description because switch implementations can transparently decide to support this function (see 4.1 about this "RGMP Spoofing").
o スイッチの実装はこの関数をサポートすることを透過的に決定できるため、この関数をRGMPプロトコル説明の一部として含める必要はありません（この「RGMPスプーフィング」については4.1を参照）。
o Important deployments through which large amounts of IPv4 multicast are moved today are typically single switch MIX - Multicast Internet eXchange points.
o 大量のIPv4マルチキャストが今日移動される重要な展開は、通常、シングルスイッチミックス - マルチキャストインターネット交換ポイントです。
o Avoiding congestion on inter-switch links in general is more complex than simply constraining IPv4 multicast traffic to paths where it is needed. With or without IPv4 multicast, the aggregate bandwidth needed between switches can easily be the aggregate required bandwidth to routers on either sides. For this reason, inter-switch bandwidth is most often appropriately over provisioned. In addition, the likelihood for receiving routers to be only on the sources side of an inter-switch link is in general deployments rather low. The cases where traffic constrainment on inter-switch links is required and helpful is thus limited and can in most cases be avoided or worked around. Moving the network to a layer 3 routed network is often the best solution, supporting RGMP-Spoofing (see section 4.1) is another one.
o 一般的にスイッチ間リンクの混雑を避けることは、必要な場所にIPv4マルチキャストトラフィックを単に制約するよりも複雑です。IPv4マルチキャストの有無にかかわらず、スイッチ間で必要な集計帯域幅は、どちらかの側のルーターに必要な帯域幅を簡単に容易にすることができます。このため、スイッチ間帯域幅は、ほとんどの場合、プロビジョニング上で適切に適切に行われます。さらに、スイッチ間リンクのソース側にのみルーターを受信する可能性は、一般的に展開がかなり低いです。したがって、スイッチ間リンクの交通制約が必要であり、役立つ場合は限られているため、ほとんどの場合、回避または回避できます。ネットワークをレイヤー3ルーティングネットワークに移動することが最良のソリューションであることが多く、RGMPスプーフィングをサポートします（セクション4.1を参照）。
Appendix C. Possible future extensions / comparison to PIM Snooping
付録C. 将来の拡張 / PIMスヌーピングとの比較の可能性
This appendix is not part of the RGMP specification but is provided for information only.
この付録は、RGMP仕様の一部ではなく、情報のみを提供しています。
This appendix presents a discussion of possible extensions to RGMP. Included are points on why the extensions are not included and in addition a motivation for RGMP in comparison to (PIM) snooping.
この付録は、RGMPの可能な拡張機能の議論を示しています。拡張機能が含まれていない理由に関するポイントと、（PIM）スヌーピングと比較してRGMPの動機付けが含まれています。
o Support for multiple switches
o 複数のスイッチのサポート
As discussed in "RGMP Spoofing", chapter 4.1 and GARP/GMRP comparison in Appendix B.
「RGMPスプーフィング」で説明したように、付録Bの第4.1章とGARP/GMRPの比較
o Support for SSM
o SSMのサポート
While RGMP works with PIM-SSM, it does not have explicit messages for the router to selectively join to (S,G) channels individually. Instead the router must RGMP join to all (Si,G) channels by joining to G. Extending RGMP to include (S,G) Join/Leaves is feasible. However, currently the majority of switches do not support actual traffic constraining on a per channel basis. In addition, the likelihood for actual channel collision (two SSM channels using the same group) will only become an issue when SSM is fully deployed.
RGMPはPIM-SSMで動作しますが、ルーターが（s、g）チャネルに個別に選択的に結合する明示的なメッセージはありません。代わりに、ルーターはG.を拡張して（s、g）結合/葉を含めることにより、rgmpがすべて（si、g）チャネルに結合する必要があります。ただし、現在、スイッチの大部分は、チャネルごとの実際のトラフィックをサポートしていません。さらに、実際のチャネル衝突（同じグループを使用して2つのSSMチャネル）の可能性は、SSMが完全に展開された場合にのみ問題になります。
o Support for IPv6
o IPv6のサポート
RGMP could easily be extended to support IPv6 by mapping the RGMP packet format into the MLD/IPv6 packet format. This was not done for this specification because most switches today do not even support MLD snooping.
RGMPパケット形式をMLD/IPv6パケット形式にマッピングすることにより、RGMPをIPv6をサポートするために簡単に拡張できます。今日のほとんどのスイッチはMLDスヌーピングさえサポートしていないため、これはこの仕様では行われませんでした。
o Support for multiple routers per port
o ポートあたりの複数のルーターのサポート
As discussed in Appendix B. This is probably one extension that should be avoided. Multiple RGMP router per port are inappropriate for efficient multicast traffic constrainment.
付録Bで説明したように、これはおそらく避けるべき1つの拡張機能です。ポートあたりの複数のRGMPルーターは、効率的なマルチキャストトラフィックの制約には不適切です。
o Support for non-join based protocols / protocol elements
o 非結合ベースのプロトコル /プロトコル要素のサポート
For protocols like PIM dense-mode, DVMRP or Bidir-PIM DF routers, additional RGMP messages may be added to allow routers to indicate that certain group (ranges) traffic need to be flooded from (dense-mode) or to (Bidir-PIM) them.
PIM Dense-Mode、DVMRP、Bidir-PIM DFルーターなどのプロトコルの場合、RGMPメッセージを追加すると、特定のグループ（範囲）トラフィックを（密なモード）または（Bidir-Pim）に浸水させる必要があることを示すことができます。） 彼ら。
o Support for multi-policy switching
o マルチポリシースイッチングのサポート
In Multicast Exchange Points (MIXes) environments situations exist where different downstream routers for policy reasons need to receive the same traffic flow from different upstream routers.
マルチキャスト交換ポイント（ミックス）環境では、政策上の理由で異なる下流のルーターが異なる上流ルーターから同じトラフィックフローを受信する必要がある場合があります。
This problem could be solved by actually providing an upstream neighbor field in RGMP Join/Leave messages. The RGMP switch would then forward traffic from one upstream router only to those downstream routers who want to have the traffic from exactly this upstream router. This extension would best go in hand with changes to the layer 3 routing protocol run between the routers.
この問題は、RGMPの結合/残すメッセージに実際に上流の隣接フィールドを提供することで解決できます。RGMPスイッチは、1つのアップストリームルーターから、まさにこのアップストリームルーターからトラフィックを持ちたい下流のルーターにのみ転送します。この拡張機能は、ルーター間で実行されるレイヤー3ルーティングプロトコルの変更に最適です。
As previously mentioned, RGMP was designed to be easy to implement and to support simple layer2 switches. Implementations could also be applied to switches beyond layer 2. If all the above possible future extensions were to be supported by an evolution of RGMP, it would be questionable whether such a protocol could be any less complex than actually snooping into the layer3 IPv4 routing protocol run between routers in a switched LAN.
前述のように、RGMPは、実装が簡単で、単純なlayer2スイッチをサポートできるように設計されています。実装は、レイヤー2を超えたスイッチにも適用できます。上記のすべての将来の拡張がRGMPの進化によってサポートされる場合、そのようなプロトコルが実際にlayer3 IPv4ルーティングプロトコルにスヌーピングするよりも複雑ではないかどうかは疑わしいでしょう。スイッチされたLANのルーター間を走ります。
From the perspective of protocol architecture it is certainly more appropriate to have a separate protocol like RGMP or GARP/GMRP for this purpose. Then again, the more complex the requirements are, the more duplication of effort is involved and snooping seems to become a more attractive option.
プロトコルアーキテクチャの観点からは、この目的のためにRGMPやGARP/GMRPのような別のプロトコルを持つことが確かに適切です。繰り返しになりますが、要件が複雑になるほど、努力の重複がより多くなり、スヌーピングがより魅力的な選択肢になるように見えます。
Even though there exists one predominant routing Protocol, PIM, in IPv4 multicast, routing with PIM in itself is extremely complex for a switch to snoop into. PIM has two main versions, different modes - sparse, dense, bidir, ssm, join / prune / graft messages (depending on the mode of the group), various PIM Hello options, different versions of asserts, two dynamic mode announcement protocols (BSR, AutoRP), and finally supports both IPv4 and IPv6.
1つの主要なルーティングプロトコルが1つ存在しますが、PIMはIPv4マルチキャストで、PIM自体を使用したルーティングは、スヌープするためのスイッチに非常に複雑です。PIMには2つのメインバージョン、異なるモード、スパース、密度、Bidir、SSM、結合 /プルーン /グラフトメッセージ（グループのモードによって異なります）、さまざまなPIM Hello Options、さまざまなバージョンのアサート、2つのダイナミックモードアナウンスプロトコル（BSR）、autorp）、そして最後にIPv4とIPv6の両方をサポートします。
A switch snooping into PIM is very likely to implement just a subset of this feature set, making it very hard for the user to determine what level of actual traffic constrainment is achieved unless a clear specification exists for the implementation (or better the method per se.). In addition, there is always the danger that such a snooping implementation may break newer features of the routing protocol that it was not designed to handle (likely because they could not have been predicted). For example, this can happen with switches using IGMP (v2) snooping implementations that are being subjected to IGMP version 3 messages - they break IGMPv3.
PIMにスヌーピングするスイッチは、この機能セットのサブセットのみを実装する可能性が非常に高いため、実装の明確な仕様が存在しない限り、ユーザーが実際のトラフィック制約のレベルを決定するのが非常に困難になります（または、それ自体がより良い方法。）。さらに、このようなスヌーピングの実装が、処理するように設計されていないルーティングプロトコルの新しい機能を破る可能性があるという危険が常にあります（おそらく予測できなかったためです）。たとえば、これは、IGMPバージョン3メッセージにさらされているIGMP（V2）スヌーピング実装を使用したスイッチで発生する可能性があります。
In summary, with PIM still evolving, the approach taken by RGMP is the safest one for the immediate problems at hand, and extensions like those listed should be considered in time for actual demand. (PIM) snooping is a valid alternative once the total amount of features that need to be supported makes it an equally attractive solution (with respect to complexity) to a dedicated protocol and if its functions are well defined to allow predicting its effects - but always at the price of possible incompatibilities with upcoming PIM protocol extensions unless support for layer 2 switches is explicitly considered in moving PIM protocols forward.
要約すると、PIMがまだ進化しているため、RGMPが採用したアプローチは、当面の問題の最も安全なアプローチであり、リストされているような拡張は実際の需要に間に合うように考慮する必要があります。（PIM）スヌーピングは、サポートする必要がある機能の合計量が専用のプロトコルに対する等しく魅力的なソリューション（複雑さに関して）と、その機能がその効果を予測できるように十分に定義されている場合、しかし常に常に定義されていれば、有効な代替手段です。レイヤー2スイッチのサポートがPIMプロトコルを前方に移動する際に明示的に考慮されない限り、今後のPIMプロトコル拡張との互換性の可能性のある価格で。
Authors' Addresses
著者のアドレス
Ishan Wu cisco Systems 170 West Tasman Drive San Jose, CA 95134
Ishan Wu Cisco Systems 170 West Tasman Drive San Jose、CA 95134
Phone: (408) 526-5673 EMail: iwu@cisco.com
電話：（408）526-5673メール：iwu@cisco.com
Toerless Eckert cisco Systems 170 West Tasman Drive San Jose, CA 95134
Toerless Eckert Cisco Systems 170 West Tasman Drive San Jose、CA 95134
Phone: (408) 853-5856 Email: eckert@cisco.com
電話：（408）853-5856メール：eckert@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。