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)
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.
著作権（C）インターネット協会（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）について説明します。このプロトコルは、シスコシステムズによって開発された、パケットが必要とされ得るそれらのルータにスイッチにマルチキャストパケットの転送を制限するマルチキャストルータとスイッチの間で使用されています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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スヌーピングは、マルチキャストトラフィックを受信したいこれらのポートに、スイッチドネットワークでは、マルチキャストトラフィックを制限するために人気が、十分に文書ではない仕組みです。これは、動的に確立し、この機能をサポートするスイッチでは、マルチキャストグループの特定の転送を終了します。
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].
IGMPスヌーピングの可能な既存のスイッチは、容易にこの機能を用いて向上させることができるように、RGMPメッセージフォーマットは、IGMPv2のメッセージフォーマットに類似しています。そのメッセージは2のプロトコル番号、IGMPと同じでのIPv4データグラムにカプセル化されます。すべてのRGMPメッセージは、宛先アドレス224.0.0.25に、TTL 1で送信されます。このアドレスは、スイッチへのルータからのメッセージを運ぶために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を=こんにちは0xFEの=さようなら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およびそれのためのアドレス224.0.0.25のIANA割り当ては以前から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に記載されているようにIGMPメッセージのためのものと同じである[5]。
In an RGMP Hello or Bye message, the group address field is set to zero.
RGMPハローまたはバイバイメッセージでは、グループアドレスフィールドはゼロに設定されます。
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.
インタフェース定期[ハロー間隔]にRGMPのための対応ルータは、RGMPが有効であることを示すために接続されたネットワークにRGMP Helloメッセージを送信します。 RGMPは、ルータインターフェイス上で無効になっている場合、それは再びそのインターフェイスから無差別IPv4マルチキャストトラフィックを受信したいことを示し、そのインターフェイス上でRGMP Byeメッセージを送信します。
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をサポートしているルータは、RGMP参加やグループ224.0.0.X（X = 0〜255）、224.0.1.39および224.0.1.40のためのメッセージを残す送ってはいけません。後者の二つは、[3] CISCO-RP-発表として知られており、CISCO-RP-発見されています。
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 Leaveメッセージを送信しません。堅牢性のために、ルータは、複数のそのようなメッセージを送信することができます。
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 Leaveメッセージを送信することができます。これらのメッセージは、データ・トリガRGMP残すメッセージと呼ばれ、ルータがそれらをレート制限すべきです。それは望ましくないグループと同じMAC宛先アドレスを有する所望の基を有する場合、データの送信を抑制することができるルータは、RGMP Leaveメッセージをトリガー。サポートされている場合（[6] MAC曖昧性のためにRFC 1112を参照。）データのような抑制がトリガ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 Helloメッセージを受信すると、RGMP対応ポートに戻り、タイマーが[5 *ハロー間隔]は開始されます。このタイマーは、ポートに着信した各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の発信元アドレスを追跡することもできます。それは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.
デフォルトでは、これらのルータへのIPv4マルチキャストトラフィックの断続的なブラックホールが発生しますスイッチポートに二つ以上のRGMP対応ルータを接続します。他のルータがまだ参加している間にRGMP休暇を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をサポートするルータは、送信する必要はありませんのでRGMP参加やグループ224.0.0.X（X = 0〜255）、224.0.1.39および224.0.1.40のためのメッセージを残す、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 Leaveメッセージを受け付けると、スイッチはそのポートへのグループのトラフィックの転送を停止する必要があります。グループのトラフィックの転送を停止するスイッチの能力は、例えば、スイッチであるため、宛先のMACベースの転送制限することができます。したがって、それはすべてのMAC-曖昧IPv4マルチキャストグループのために常に順方向トラフィックへの切り替えのために必要である（MAC-曖昧さのために[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 Leaveメッセージ（S）のイベントでグループへのトラフィックの転送を停止するには、スイッチは[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マルチキャストフィルタリング方法を実行せずに、スイッチはすべてのポートにマルチキャストトラフィックをフラッディングする必要があります。スイッチは、実際に、このようなIGMPスヌーピング[10]としてIPv4マルチキャストトラフィックをフィルタリングするためにRGMPの横一の以上のメカニズムを実行しない場合、デフォルトではそれはもはや、すべてのポートにIPv4マルチキャストトラフィックをフラッディングされません。その代わり、スイッチはポートがまだデフォルトですべての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.
この仕様に準拠するには、スイッチが[4]ポートから到着しても、手動設定オプションを使用してPIM Helloメッセージの存在による洪水のためのポートを選ぶことができなければならないことが必要です。また、スイッチは、MRDISC [11]のような他の適切なプロトコルのパケットまたは専用IPv4マルチキャストルータ発見機構によってルータに接続されたポートを認識すべきです。手動設定は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が使用されていると少なくとも一つのルータ、スイッチの各々に接続されている場合、マルチキャストトラフィックは、このようにネットワーク内のスイッチ間のリンク上でフラッディングされます。
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の簡略化の一つの結果は、特定のルーティングプロトコルをサポートする上で、その制限があります。次の段落では、いくつかの既知の制限をリストします。
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.
それが明示的に（これらのグループは3.1に浸水することが指定した範囲以外の）JoinメッセージをRGMPを経由して、それを要求しない限り、スイッチドネットワーク上でRGMPを実行しているルータは、マルチキャストグループのトラフィックを受信しません。このため、RGMPを越えPIMデンスモードまたはDVMRPなどのプロトコルを実行することはできませんRGMP対応ルータとのネットワークを有効に。
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.
それは無条件にRPに向けたネットワークから受信したトラフィックを転送する必要があるため、双方向PIM-では、DFように選定されたルータは、ネットワーク上でRGMPのために有効にすることはできません。ルータは、ネットワーク上の任意のグループのための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.
このDRは無条件DRにPIM-SMの登録プロセスを起動するために、直接接続された送信元からのトラフィックを受信する必要があるため、選出されたDRは、RGMPを実行している場合、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の両方で、スイッチドネットワークにトラフィックを転送するアップストリームルータは、RGMPを送信する必要がPIMアサートプロセスの支援にグループの参加。
The Hello Interval is the interval between RGMP Hello messages sent by an RGMP-enabled router to an RGMP-enabled switch. Default: 60 seconds.
ハロー間隔は、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対応ルータとして動作する一つのシステムに接続されていることを確認することを意味します。また、これは最高のレバレッジの推奨構成です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スイッチのポートに接続されている場合、一つのシステムは、RGMPメッセージを偽造し、同じポート上の他のシステム（S）の動作に影響を与える可能性があります。これは、潜在的なセキュリティリスクです。
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.
物理的なセキュリティが唯一のシステムは、スイッチ上で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 Leaveメッセージは、ポートに向けて、個々のグループのIPv4マルチキャストトラフィックを制限することができます。効果は、それがすべてのIPv4マルチキャストトラフィックに影響を与えるだけで、その偽造メッセージに示されたグループのないことを除けばRGMPのHelloメッセージに類似の可能なブラックホールDoS攻撃です。公式にそれに接続された唯一のRGMP対応ルータ（すなわち、ポートはRGMPが有効になっている場合）がある場合にもポートのみに影響します。
Bye Message:
BYEメッセージ：
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.
RGMPが設定され、RGMPの利益を無効化していなかったかのようにDoS攻撃のこのタイプは、単にポートの動作を再確立します。これは、しかし、最初の場所で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 Joinメッセージは、それがから受信されたポートへの望ましくないマルチキャストパケットを引き付けることができます。効果は、それが唯一のグループが偽造メッセージに示されているすべてのIPv4マルチキャストトラフィックには影響しないことを除いてRGMPのByeメッセージに似ています。正式に（ポートがある場合、すなわち、RGMPが有効になって）それに接続された唯一のRGMP対応ルータがある場合にのみ、メッセージは、ポートに影響します。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL.魏、 "プロトコル独立マルチキャスト - スパースモード（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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、W.およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[6] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[6]デアリング、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標準802.1D 1998版、 "メディアアクセス制御（MAC）ブリッジ"、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]ファリナッチD.、Tweedly D.、スピークマンT.、 "シスコグループ管理プロトコル（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]フェナー、B.、RFC 3228、2002年2月 "IPv4インターネットグループ管理プロトコル（IGMP）のためのIANAの考慮事項"。
[10] Christensen, M. and F. Solensky, "IGMP and MLD snooping switches", Work In Progress.
[10]クリステンセン、M.およびF. Solensky、 "IGMPやMLDスヌーピングスイッチ"、進行中の作業。
[11] Biswas, S., Cain, B. and B. Haberman, "IGMP Multicast Router Discovery", Work In Progress.
[11]ビスワス、S.、カイン、B.、およびB.ハーバーマン、 "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、ビルフェナー、ジョヴァンニ・メオ、マイク・ノートン、Pavlin Radoslavovおよびアレックスジニンに感謝したいと思います。
Appendix A. Intellectual Property Rights
付録A.知的財産権
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
GARP / GMRPと付録B.比較
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]）ブリッジイーサネットネットワークでのイーサネット・マルチキャストトラフィックを制限するための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は、ホストスタックソフトウェアへの変更を必要とせずに問題を解決するが、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スヌーピングをやって、それが望ましいIGMPスヌーピングでより多くの境界で可能なよりRGMPにグループ当たりの処理とメモリの要件の量を維持することと表示されますGARP / 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.
入出力GARP / GMRPは、IEEEからのイーサネット・レベル・プロトコルです。これは、イーサネットアドレス（グループ）のトラフィックを制限するためにサポートしています。 RGMPは、IPv4マルチキャストグループのトラフィックを制限しません。今日、これも、レイヤ2スイッチとして使用される典型的なスイッチプラットフォームの能力を超えています。さらにエンティティをサポートするための拡張機能は、おそらく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の状態を単純に起因し、スイッチのIPv4マルチキャスト制御および転送プレーンでIGMPスヌーピングおよびRGMP操作を統合することは容易です。
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は、その複雑さのために一つの理由であるスイッチポートで複数のシステム（ホスト/ルータ）をサポートしています。 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:
入出力GARP / GMRPは、スイッチ間の複雑さのために別の理由は、マルチキャストトラフィックを制限する方法を定義します。 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スプーフィング」約4.1を参照）は、この機能をサポートすることを決定することができるので、RGMPプロトコル記述の一部としてこの機能を含む必要はありません。
o Important deployments through which large amounts of IPv4 multicast are moved today are typically single switch MIX - Multicast Internet eXchange points.
OのIPv4マルチキャスト大量の今日移動され、それを通して重要な展開は、通常、単一のスイッチMIXです - マルチキャストインターネットエクスチェンジポイント。
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マルチキャストの有無にかかわらず、スイッチの間に必要な総帯域幅を容易に両側のルータに集約必要な帯域幅とすることができます。このため、スイッチ間の帯域幅がプロビジョニング上で最も頻繁に適切です。加えて、唯一のスイッチ間リンクのソース側上にあるルータを受信するための可能性はかなり低い一般的な展開です。スイッチ間リンク上のトラフィックconstrainmentが必要で親切された場合は、このように限られており、ほとんどの場合、回避または回避することができます。 （セクション4.1を参照してください）3ルーティングされたネットワークは、RGMPスプーフィングをサポートし、多くの場合、最善の解決策である層にネットワークを移動すると、別のものです。
Appendix C. Possible future extensions / comparison to PIM Snooping
PIMスヌーピングの付録C.可能な将来の拡張/比較
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スプーフィング」、章4.1および付録BのGARP / GMRPの比較で説明したように
o Support for SSM
SSM用Oサポート
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）チャネルに参加するルータのための明確なメッセージを持っていません。代わりに、ルータは、葉/参加RGMPは（S、G）を含むように拡張Gに結合することによって、すべてのシリコン（Si、G）チャネルに参加RGMPなければならないことは可能です。しかし、現在のスイッチの大半は、チャネルごとに制約実際のトラフィックをサポートしていません。 SSMが完全に展開されたときに加えて、実際のチャネル衝突（同じグループを使用して、2つのSSMチャネル）のための可能性は、問題となるであろう。
o Support for IPv6
IPv6のOサポート
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ルータは、効率的なマルチキャストトラフィックconstrainmentには不適切です。
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稠密モード、DVMRPまたは双方向-PIM DFルータなどのプロトコルのために、追加のRGMPメッセージは、ルータがその特定のグループを示すために可能にするために添加されてもよい（範囲）は、トラフィックニーズは（稠密モード）または双方向-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を実装すると、単純なレイヤ2スイッチをサポートしやすいように設計されました。上記のすべての可能な将来の拡張は、そのようなプロトコルは、実際にレイヤ3 IPv4ルーティングプロトコルにスヌーピングよりも任意の少ない複雑になることができるかどうかは疑問だろうRGMPの進化によってサポートされていた場合、実装はまた、層2を超えたスイッチにも適用することができますスイッチド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つの主ルーティングプロトコルが存在するにもかかわらず、PIMは、IPv4のマルチキャストに、それ自体がPIMとルーティングにスヌープするスイッチの非常に複雑です。 （グループのモードに応じて）疎、密な、双方向、SSM、参加/プルーン/グラフトメッセージ、各種PIMハローオプション、アサートの異なるバージョン、2つの動的モードの告知プロトコル（BSR - PIMは、2つの主要なバージョン、異なるモードを有します、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にスヌーピングスイッチは、明確な仕様が実装（またはより良い方法自体のために存在しない限り達成された実際のトラフィックconstrainmentのレベルを決定するために、ユーザーのために非常に懸命にそれを作る、この機能セットのサブセットだけを実装する可能性が非常に高いです。）。また、（彼らは予測できなかったので、おそらく）などスヌーピングの実装は、それが処理するように設計されていなかったルーティングプロトコルの新しい機能を壊す恐れが常にあります。例えば、これは、IGMP（V2）を使用して、スイッチIGMPバージョン3つのメッセージに供されてスヌーピング実装で起こることができる - 彼らにIGMPv3を破ります。
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
イシャン呉シスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134
Phone: (408) 526-5673 EMail: iwu@cisco.com
電話：（408）526-5673 Eメール：iwu@cisco.com
Toerless Eckert cisco Systems 170 West Tasman Drive San Jose, CA 95134
Toerlessエッカートシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134
Phone: (408) 853-5856 Email: eckert@cisco.com
電話：（408）853-5856 Eメール：eckert@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。