RFC3488 日本語訳
3488 Cisco Systems Router-port Group Management Protocol (RGMP). I.Wu, T. Eckert. February 2003. (Format: TXT=37152 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group I. Wu
Request for Comments: 3488 T. Eckert
Category: Informational Cisco Systems
February 2003
コメントを求めるワーキンググループI.ウー要求をネットワークでつないでください: 3488年のT.エッケルトカテゴリ: 情報のシスコシステムズ2003年2月
Cisco Systems
Router-port Group Management Protocol (RGMP)
シスコシステムズルータポートグループ管理プロトコル(RGMP)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
このドキュメントはRouter-ポートGroup Managementプロトコル(RGMP)について説明します。 このプロトコルは、シスコシステムズによって開発されて、それらのルータへのパケットが必要であるかもしれないスイッチでマルチキャストパケット推進を制限するのにマルチキャストルータとスイッチの間で使用されます。
RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected.
RGMPは複数の、そして、高い速度ルータがインタコネクトされるバックボーン交換網のために設計されています。
1. Conventions used in this document
1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。
2. Introduction
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はマルチキャストトラフィックを制限するポピュラーな、しかし、よく記録されなかったメカニズムです、交換網で、マルチキャストトラフィックを受けたがっているそれらのポートに。 それは、この特徴をサポートするスイッチで、ダイナミックにマルチキャストのグループの特定の推進を確立して、終えます。
Wu & Eckert Informational [Page 1] RFC 3488 Cisco Systems RGMP February 2003
[1ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
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 Snoopingの主な限界はマルチキャストトラフィックを受信ホストが直接か間接的に他のスイッチを通して接されるスイッチポートに制限するだけである場合があるということです。 IGMP Snoopingはマルチキャストトラフィックを少なくとも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 Snoopingはマルチキャストトラヒック負荷を減少させないでしょう。 また、それは、ネットワークにおけるスイッチの使用で内部の帯域幅を増強するのを助けないでしょう。
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メッセージ・フォーマットは、この特徴で容易に既存のIGMP Snoopingができるスイッチを機能アップできるようにIGMPv2メッセージ・フォーマットに類似しています。 メッセージはIPv4データグラムで2のIGMPのものと同じプロトコル番号でカプセル化されます。 TTL1と共に目的地アドレス224.0.0.25にすべてのRGMPメッセージを送ります。 このアドレスは、ルータからスイッチ[3]までメッセージを伝えるためにIANAによって割り当てられました。
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ポートあたり1つのソースだけからのRGMPメッセージを予想するように、それが設計されます。 この理由で、RGMPは直接RGMPのポートに接続されて、RGMPがルータは可能にしたシングルに可能にされたスイッチを支えるだけです。 そのようなトポロジーは、バックボーンスイッチにルータを接続するとき、通例であり、その結果、RGMPの展開のときに制限を引き起こすべきではありません。
Wu & Eckert Informational [Page 2] RFC 3488 Cisco Systems RGMP February 2003
[2ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 予約されます。| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The reserved field in the message MUST be transmitted as zeros and ignored on receipt.
メッセージの予約された野原をゼロとして伝えられて、領収書の上で無視しなければなりません。
2.1 Type
2.1 タイプ
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とそれのための.25が前に起こるアドレス224.0.0のIANA課題、RFC3228[9]。 RGMPはテストと実験について議定書の中で述べるためにRFC3228で割り当てられるType値を定義します。 RGMPパケットだけがIPv4送付先アドレスを使用するのでこれがRGMP自身のための操作上の問題でない、224.0、.0、.25 上で定義されたType値はその結果、RGMP送付先アドレスに関連して有効であるだけです。
2.2. Checksum
2.2. チェックサム
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ペイロード)をカバーしています。 チェックサムのアルゴリズムと取り扱いはRFC3376[5]で説明されるIGMPメッセージのためのそれらと同じです。
Wu & Eckert Informational [Page 3] RFC 3488 Cisco Systems RGMP February 2003
[3ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
2.3. Group Address
2.3. グループアドレス
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 JoinかLeaveメッセージでは、グループアドレス・フィールドは加わられるか、または残されるグループのIPv4マルチキャストグループアドレスを保持します。
2.4 IPv4 header
2.4 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をサポートするスイッチは、このグループにおいてパケットを聞く必要があります。
3. RGMP Protocol Description
3. RGMPプロトコル記述
3.1 RGMP Router side Protocol Description
3.1 RGMP Routerサイドプロトコル記述
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のために定期的に有効にされたRouter[こんにちは、Interval]は、それが有効にされたRGMPであることを示すためにRGMP Helloメッセージを付属ネットワークに送ります。 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 Joinメッセージを出します。 グループがマルチキャストトラフィックを受ける継続的な願望を示すように、定期的[Intervalを接合する]へのルータの必要性はRGMP Joinを再送します。
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 MUST NOTをサポートするルータがRGMP Joinを送るか、またはLeaveがグループ224.0.0.x(x=0...255)、224.0のために.1を通信させる、.39、224.0 .1 .40。 後者の2はrpが発表するコクチマスとコクチマス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 Leaveメッセージを送ります。 丈夫さのために、そのようなメッセージの1つ以上はルータで行くかもしれません。
Wu & Eckert Informational [Page 4] RFC 3488 Cisco Systems RGMP February 2003
[4ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
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 Leaveメッセージと呼ばれます、そして、ルータSHOULDはそれらをレートで制限します。 それに望まれないグループと同じMAC送付先アドレスを持っている必要なグループがあるならデータの引き起こされたRGMP Leaveメッセージを送って、ルータは抑圧されるかもしれません。 (MACのあいまいさのためのRFC1112[6]を見てください。) データのそのような秘匿はRGMP LeaveメッセージSHOULDの引き金となりました。サポートされるなら、構成可能であってください。
3.2 RGMP Switch side Protocol Description
3.2 RGMP Switchサイドプロトコル記述
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はポート基礎あたりのaを作動させます。 RGMPへのポート復帰者はポートに関するRGMP Helloメッセージを受け取り次第ポートを可能にしました、そして、タイマ[こんにちは、5*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をサポートするスイッチの上のポートに接続された可能にされた1RGMPのルータです。 スイッチの上のポートはそれがそのポートの上に受け取るRGMP HelloとByeメッセージのIPv4創始者アドレスの動向をおさえたがっているかもしれません。 イベントでは、RGMPメッセージの1つのポートに関するアドレスを溯源する複数の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マルチキャストトラフィックの間欠黒い穴を引き起こすスイッチに可能にされました。 まだもう片方のルータを接合していますが、1つのルータからRGMP Leaveを受け取るとき、黒い穴は起こります。
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
この不調はルータを通して接された実施している者によって容易に認められるだけではありませんが、また、それは失敗状況が以上より少ないトラフィックを引き起こすという原則を固く守ります。 容易に氾濫に戻るのはすべてが完全に働いているという幻想を維持します。 例外はトラフィック抑制が利益を得るということです。
Wu & Eckert Informational [Page 5] RFC 3488 Cisco Systems RGMP February 2003
[5ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
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は実感されません。 これは、混雑が1時間misconfigurationよりはるかに後半に起こるのを示します、そして、次に、容易に、それ以上原因で関連できません。
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 Joinを送るのに必要でない、またはLeaveがグループ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 JoinとLeaveメッセージはRGMPで到着するなら受け入れて、可能にされたポート、そうでなければそれらが捨てられるということです。 RGMP Joinメッセージの承認を、スイッチは、グループのためにトラフィックをポートに送り始めなければなりません。 RGMP Leaveメッセージの承認のときに、スイッチSHOULDは、グループのためにそのポートにトラフィックを送るのを止めます。 例えば、グループのためにトラフィックを進めるのを止めるスイッチの性能は目的地の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 Leaveメッセージの場合、トラフィックの推進、スイッチ5月のタイムアウトRGMP推進を止めるために、それのための最後のRGMP Joinが分類した後にポートの上にグループ[5*はIntervalを接合する]のためのポートの状態を受け取りました。
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マルチキャストがなければ、メソッドをフィルターにかけるのが稼働していて、スイッチは、すべてのポートへマルチキャストトラフィックをあふれさせる必要があります。 スイッチが次に、デフォルトで[10]について詮索するIGMPなどのIPv4マルチキャストトラフィックをフィルターにかけるために実際にRGMPの横の1つ以上のメカニズムを動かすと、それはそれ以上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.
この仕様への承諾は、スイッチがポートと手動の設定オプションを通しても到着しながらPIM Helloの存在を通した氾濫のためのポートをメッセージ[4]に選出できなければならないのを必要とします。 さらに、スイッチSHOULDは、ポートが他の適切なプロトコルパケットでルータに接続したか、または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で使用されるかもしれないので、さらなるメカニズムはポートを可能にしました。 この場合、どちらのメカニズムもそれを必要として、どんなメカニズムもそれ以上それを必要としないならそれを取り除くだけでよいなら、ポートに関するグループのための推進を確立しなければなりません。
Wu & Eckert Informational [Page 6] RFC 3488 Cisco Systems RGMP February 2003
[6ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
4. Operational Notes
4. 操作上の注意
4.1. Support for networks with multiple switches
4.1. 複数のスイッチがあるネットワークのサポート
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は互いの中でスイッチを接続しながらリンクの上にマルチキャストトラフィックを制限する方法を指定しません。 その結果、少なくとも1つのルータがそれぞれのスイッチに接続されると、まさしく使用される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スプーフィング」があります。
4.2. Interoperability with RGMP-incapable routers
4.2. 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不可能なルータはすべてのマルチキャストグループのためにマルチキャストトラフィックを受けるでしょう。
4.3. RGMP and multicast routing protocols
4.3. 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 Joinメッセージ(3.1で水につかるように指定されたそれらのグループ範囲以外に)で明らかにそれを要求しないと、RGMPを交換網に実行するルータはマルチキャストグループのためにトラフィックを受けないでしょう。 この理由で、RGMPの向こう側のPIM Dense-モードかDVMRPがRGMPと共にネットワークを可能にしたようにプロトコルを実行するのがルータを可能にしたのは、可能ではありません。
Wu & Eckert Informational [Page 7] RFC 3488 Cisco Systems RGMP February 2003
[7ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
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を有効にしてはいけません、ネットワークからRPに向かって受け取られたトラフィックを進めるのが無条件に必要であるのでことであることを選びました。 ルータがネットワークに関するどんなグループのための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 Joinsを送る交換網の必要性にトラフィックを送る上流のルータがプロセスについて断言します。
5. List of timers and default values
5. タイマとデフォルト値のリスト
5.1. Hello Interval
5.1. こんにちは、間隔
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 IntervalはRGMPによって可能にされたルータによってRGMPによって可能にされたスイッチに送られたRGMP Helloメッセージの間隔です。 デフォルト: 60秒。
5.2. Join Interval
5.2. 間隔を接合してください。
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.
Join Intervalは与えられたグループアドレスのためにRGMPによって可能にされたルータによってRGMPによって可能にされたスイッチに送られた周期的なRGMP Joinメッセージの間隔です。 デフォルト: 60秒。
6. Security Considerations
6. セキュリティ問題
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メッセージから起こります。 1台以上のシステムがRGMPスイッチのポートに接続されるなら、当時の1台のシステムが、RGMPメッセージを作り出して、同じポートにおける他のシステムの操作に影響するかもしれません。 これは潜在的セキュリティリスクです。
Wu & Eckert Informational [Page 8] RFC 3488 Cisco Systems RGMP February 2003
[8ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
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の可能にされたルータに向かって制限する場合があります。 事実上、これはblackholing 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 Messageと同様の可能なblackholing DoS攻撃です。 また、それに接続された可能にされた1RGMPだけのルータが公式にある場合にだけ(ポートがすなわち、有効にされた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 Joinメッセージは望まれないマルチキャストパケットをそれが受け取られるポートに引き付けるかもしれません。 グループだけが偽造メッセージで示したすべてのIPv4マルチキャストトラフィックに影響しないのを除いて、効果はRGMP Bye Messageと同様です。 それに接続された可能にされた1RGMPだけのルータが公式にある場合にだけ(ポートがすなわち、有効にされたRGMPであるなら)、メッセージはポートに影響するでしょう。
Wu & Eckert Informational [Page 9] RFC 3488 Cisco Systems RGMP February 2003
[9ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
7. Normative References
7. 引用規格
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、ファリナッチ、D.、Helmy、A.、ターレル、D.、デアリング、S.、ハンドレー、M.、ジェーコブソン、V.、リュウ、C.、シャルマ、P.、およびL.ウェイ、「独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、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インチ、RFC3376、2002年10月。」
[6] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[6] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[7] ANSI/IEEE Std 802.1D 1998 Edition, "Media Access Control (MAC)
Bridges", 1998.
[7] 1998年のANSI/IEEE Std 802.1D版、「メディアアクセス制御(MAC)ブリッジ」、1998。
8. Informative References
8. 有益な参照
[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.、Speakman 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.、「IPv4インターネットグループ管理プロトコル(IGMP)のためのIANA問題」、RFC3228、2002年2月。
[10] Christensen, M. and F. Solensky, "IGMP and MLD snooping
switches", Work In Progress.
[10]クリステンセンとM.とF.Solensky、「IGMPとMLD詮索は切り替わる」Work In Progress。
[11] Biswas, S., Cain, B. and B. Haberman, "IGMP Multicast Router
Discovery", Work In Progress.
[11] 「IGMPマルチキャストルータ発見」というビスワス、S.、カイン、B.、およびB.ハーバーマンは進行中で働いています。
9. Acknowledgments
9. 承認
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.
作者はドキュメントと彼らの提案に関する彼らのレビューについてゴーリーFairhurst、ビル・フェナー、ジョバンニMeo、マイクノートン、パブリン・ラドスラーボフ、およびアレックス・ジニンに感謝したがっています。
Wu & Eckert Informational [Page 10] RFC 3488 Cisco Systems RGMP February 2003
[10ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
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
ガープ/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.
ガープ/GMRP、(IEEE 802.1D[7])で定義されているのは、ブリッジしているイーサネットネットワークでイーサネットマルチキャストトラフィックを抑制するANSI/ISO/IEC/IEEEプロトコル群です。 そういうものとして、また、それはルータポートに向かってマルチキャストトラフィックを抑制する目的のためのRGMPへの可能な代替手段です。 この付録で、ガープ/GMRPを当てにしない動機とガープ/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.
ガープ/GMRPを押して伸ばすことにおける主要因はIGMP Snoopingを完全に取り替えるだろうことでした。 これはガープ/GMRPのデザイン目標でした。 効率的な操作のために、IGMP Snoopingはスイッチ(ホストの間で会員資格レポートと実際のIPv4マルチキャストトラフィックを差別化する)でサポートをフィルターにかけるハードウェアを必要とします。 特に多くの、より古いスイッチでは、このサポートは存在していません。 ベンダーは、より高価なスイッチハードウェアを組立てる必要はなくてIPv4マルチキャストトラフィックを抑制する利益を切り換えられたLANに提供するこの問題の周りの方法を見つけようとしました。 ガープ/GMRPはこれから生じる1つのプロトコルです。 シスコからのCGMPは別の1つです。 CGMPはホストスタックソフトウェアへの釣り銭がいることのない問題を解決しますが、ガープ/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.
最新に、ガープ/GMRPは今までのところ、配布しているソリューションに重要な侵害を作りかえていません。 IGMP Snooping(そして、CGMP)はこの環境のための標準です。 結果では、必ず層2のスイッチによってガープ/GMRPがサポートされることを期待できるというわけではありません。 さらに、ガープ/GMRPは明確にRGMPが解決しようとする問題を扱いません。 一方では、ガープ/GMRPはすぐに必要であるようにずっと多くの機能性とそういうものとして複雑さを提供します。 他方では、ガープ/GMRPは、イーサネット範囲の支配的に規格であることで制限されます。
Wu & Eckert Informational [Page 11] RFC 3488 Cisco Systems RGMP February 2003
[11ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
Beyond the process and applicability reasons, the main differences between GARP/GMRP and RGMP are as follows:
プロセスと適用性理由を超えて、ガープ/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 ガープ/GMRPスイッチ/システムは、ガープ/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 Snoopingとガープ/GMRPで可能であるというよりもさらに領域で次に、より多くの州がRGMPをそれをグループ処理単位で量を保つために望ましくして、IGMP Snoopingをする縁だけとメモリ要件で動いているのをおそらく見るでしょう: ガープ/GMRPでは、(複数の)タイマはイーサネットグループアドレスあたりのaで維持されるべき州マシンの必要性を基礎づけました、そして、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 ガープ/GMRPはIEEEからのイーサネットレベルプロトコルです。 それは、イーサネットアドレス(グループ)のためにトラフィックを抑制するとサポートします。 RGMPはIPv4マルチキャストグループのためにトラフィックを抑制します。 今日、これはlayer2が切り替わっている間に使用される典型的なスイッチプラットホームの能力を超えてさえいます。 さらに実体をサポートする拡大はガープ/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 Snoopingをサポートするルータとスイッチプラットホームに加えやすいです。 ハードウェアで同じで(a MACあいまい)のグループに送られたIGMPプロトコルタイプパケットと他のIPv4マルチキャストトラフィックを区別できるスイッチに、これは特に本当です。 さらに、RGMPの州の簡単さのために、スイッチのIPv4マルチキャストコントロールと推進飛行機でIGMP Snoopingと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 ガープ/GMRPは複雑さの1つの理由であるスイッチポートの上の1台以上のシステム(ホスト/ルータ)をサポートします。 RGMPでは、この構成は明らかにサポートされません: 切り換えられたポートあたり1つ以上のルータは共通したシナリオだけが今日層の2ネットワークを切り換えないで、また、求められていないIPv4マルチキャストトラフィックがルータから遠ざけられることであるときにそれが望まれない構成であるということではありません。
Wu & Eckert Informational [Page 12] RFC 3488 Cisco Systems RGMP February 2003
[12ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
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 ガープ/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です--マルチキャストインターネットeXchangeポイント。
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が必要であって、役立っているケースは、このようにして制限して、多くの場合、避けることができたか、または問題に取りかかりました。 ネットワークを層に動かして、しばしば3の発送されたネットワークが最も良いソリューションである、RGMP-スプーフィング(セクション4.1を見る)をサポートするのは、別の1つです。
Appendix C. Possible future extensions / comparison to PIM Snooping
PIM Snoopingとの付録のC.のPossibleの今後の拡大/比較
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.
Appendix Bで「RGMPスプーフィング」、第4.1章、およびガープ/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
RGMPがPIM-SSMと共に働いている間、それには、ルータが選択的に個別にチャンネルにつなぐ(S、G)明白なメッセージがありません。 代わりに、ルータ必須RGMPはチャンネルで加わります。
Wu & Eckert Informational [Page 13] RFC 3488 Cisco Systems RGMP February 2003
[13ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
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.
インクルード(S、G)へのExtending RGMPが接合するか、または残すG.につなぐのは可能です。 しかしながら、現在のスイッチの大部分がチャンネル基礎あたりのaでの実際のトラフィック抑制をサポートしません。 SSMが完全に配布されるときだけ、さらに、実際のチャンネル衝突(同じグループを使用している2個の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パケット・フォーマットに写像することによって、サポートIPv6に容易にRGMPを広げることができるでしょう。 今日のほとんどのスイッチがMLD詮索をサポートさえしないので、この仕様のためにこれをしませんでした。
o Support for multiple routers per port
o 複数の1ポートあたりのルータのサポート
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.
Appendixで議論するように、B.Thisはたぶん避けられるべきである1つの拡大です。 効率的なマルチキャストトラフィックconstrainmentに、複数の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の濃いモード、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.
Multicast Exchange Points(MIXes)では、環境状況は方針理由による異なった川下のルータが異なった上流のルータからの同じ交通の流れを受ける必要があるところに存在しています。
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 Join/休暇の上流の隣人分野にメッセージを提供することによって、この問題を解決できるでしょう。 そして、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の発展によってサポートされることであるなら、プロトコルが実際に切り換えられたLANにおけるルータの間で実行されたlayer3 IPv4ルーティング・プロトコルをせんさくするのといくらか同じくらい複雑であるかもしれないかどうかは、どんな疑わしくはありません。
Wu & Eckert Informational [Page 14] RFC 3488 Cisco Systems RGMP February 2003
[14ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
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やガープ/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があるルーティングは本来非常に複雑です。 PIMが2つの主なバージョン、まばらで、濃くて、bidirであって、ssmな異なったモードがメッセージ(グループのモードに依存する)、様々なPIM Helloオプション、異なった見解を接合するか、剪定する、または接ぎ木するのをさせる、断言、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をせんさくするスイッチはまさしくこの特徴セットの部分集合を非常に実装しそうです、ユーザが、明確な仕様が実装のために存在していない場合(そういうものとしてメソッドを改善してください)実際のトラフィックconstrainmentのどんなレベルが達成されるかを決心しているのを非常に困難にして。 さらに、そのような詮索実装がそれが扱う(それらを予測できなかったのでありそうな)ように設計されなかったルーティング・プロトコルの、より新しい特徴を知らせるかもしれないという危険がいつもあります。 例えば、スイッチがIGMPバージョン3メッセージにかけられている実装について詮索しながらIGMP(v2)を使用している状態で、これは起こることができます--彼らは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.
概要では、記載されたものが実需に間に合うように考えられるべきであるようにRGMPによって取られたアプローチは手元の手近な問題、および拡大のためのPIMがまだ発展している、最も安全なものです。 (PIM) サポートされる必要がある特徴の総量が一度それをひたむきなプロトコルへの等しく魅力的な解決(複雑さに関する)にして、機能が効果を予測するのを許容するためによく定義されるなら、詮索は有効な代替手段ですが、いつも今度のPIMがある可能な非互換性の価格では、層2のスイッチのサポートがPIMプロトコルを前方へ動かせる際に明らかに考えられない場合、拡大について議定書の中で述べてください。
Wu & Eckert Informational [Page 15] RFC 3488 Cisco Systems RGMP February 2003
[15ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
Authors' Addresses
作者のアドレス
Ishan Wu cisco Systems 170 West Tasman Drive San Jose, CA 95134
IshanウーコクチマスのSystems170の西タスマン・Driveサンノゼ、カリフォルニア 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エッケルトコクチマスのSystems170の西タスマン・Driveサンノゼ、カリフォルニア 95134
Phone: (408) 853-5856 Email: eckert@cisco.com
以下に電話をしてください。 (408) 853-5856 メールしてください: eckert@cisco.com
Wu & Eckert Informational [Page 16] RFC 3488 Cisco Systems RGMP February 2003
[16ページ]RFC3488シスコシステムズRGMP2003年2月の情報のウーとエッケルト
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Wu & Eckert Informational [Page 17]
ウーとエッケルトInformationalです。[17ページ]
一覧
スポンサーリンク
