switch
Click on the red underlined text to get to the source
... multicast traffic. It dynamically establishes
and terminates multicast group specific forwarding in switches that
support this feature.
...
... Snooping is that it can only restrict
multicast traffic onto switch ports where receiving hosts ...
... Snooping on IGMP messages alone is an
intrinsic limitation. Through it, a switch can only learn which
multicast flows ...
... multicast flows are being requested by hosts. A switch can not learn
through IGMP which traffic flows ...
... load. Nor will it assist in increasing internal bandwidth through
the use of switches in the network.
...
... ports. To effectively restrict traffic, it must be
supported by both the switches and the routers in the network.
...
... IGMPv2 message format so that
existing switches, capable of IGMP Snooping, can easily be enhanced
...
... To keep RGMP simple, efficient and easy to implement, it is designed
for switches to expect RGMP messages from only one source per port.
...
... be connected directly to a port of an RGMP enabled switch. Such a
topology should be customary when connecting routers ...
... 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 ...
... RGMP messages are sent by routers to switches. The source IPv4
address of an RGMP packet is the sending interface ...
... IPv4 address of an RGMP
packet is 224.0.0.25. Switches supporting RGMP need to listen to
packets to this group ...
... Multicast routers use RGMP to pass such information
to the switches. Only routers send RGMP messages. They ignore
...
... RGMP Leave message for
that group to the switch. These messages are called data-triggered
RGMP Leave messages and the router ...
... network and processes them as described
below. If enabled for RGMP, the switch must NOT forward/flood
received RGMP ...
... 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 ...
... 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 ...
... By default, connecting two or more RGMP enabled routers to a switch
port will cause intermittent black holing of IPv4 ...
... port. Upon acceptance of an RGMP Leave message, the
switch SHOULD stop forwarding traffic for the group to that port ...
... destination MAC based forwarding in
the switch. Therefore, it is necessary for the switch to always
forward traffic ...
... MAC based forwarding in
the switch. Therefore, it is necessary for the switch to always
forward traffic for all MAC ...
... group in the event of lost RGMP
Leave message(s), a switch MAY time out RGMP forwarding state on a
...
... flood multicast traffic to all ports. If a switch
does actually run one or more mechanisms beside RGMP to filter ...
... multicast traffic to all ports anymore. Instead,
the switch will try to determine which ports still needs to receive
all IPv4 ...
... ports do not.
Compliance with this specification requires that a switch MUST be
able to elect a port for flooding ...
... 4] arriving from the port and also through a manual
configuration option. In addition, the switch SHOULD recognize a
port connected to a router ...
...
To be simple to implement on switches and resilient in face of
potential layer 2 network topology ...
... to restrict multicast traffic on links connecting switches amongst
each other. With just RGMP being used, multicast traffic ...
... RGMP being used, multicast traffic will thus
be flooded on inter-switch links within a network if at least one
...
... network if at least one
router is connected to each of the switches.
This happens implicitly because the switch ...
... flood/forward
received RGMP messages out to the inter-switch link and thus the
switch on the other end will only recognize the port ...
... 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 ...
... port
via the PIM Hello messages flooded by the switches. Manual
configuration for inter-switch links ...
... 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.
If appropriate, a switch ...
... it look like an RGMP enabled router to a potential switch at the
other end of the link. This would constrain IPv4 ...
... switches, but this type of "RGMP Spoofing" by the switch is
outside the scope of this specification.
...
... RGMP-enabled router to an RGMP-enabled switch for a given
group address. Default: 60 seconds.
...
... 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
...
... RGMP capable port on a switch, then forged messages from this system
itself can take effect. Such forged messages ...
... hardware filtering
support in the switch (to differentiate between hosts membership
reports and actual IPv4 ...
... 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 ...
... GMRP can not necessarily be expected to
be supported by layer 2 switches. In addition, GARP/GMRP does not
...
... 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.
...
... IPv4 multicast groups. Today this
is even beyond the capabilities of typical switch platforms used
as layer2 switches. Extensions to support further entities are
...
... 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
...
... version 2) and is
as such easy to add to router and switch platforms that already
support IGMP and IGMP ...
... IGMP Snooping respectively. This is especially
true for switches that in hardware can differentiate between IGMP
...
... GARP/GMRP supports more than one system (host/router) on a switch
port which is one reason for its complexity. In RGMP ...
... per switched port is not only not a common scenario in today's
switches layer 2 networks, it is also an undesired configuration
...
... 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
...
... 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 ...
... IPv4
multicast are moved today are typically single switch
MIX - Multicast Internet eXchange points ...
...
o Avoiding congestion on inter-switch links in general is more
complex than simply constraining IPv4 ...
... multicast, the
aggregate bandwidth needed between switches can easily be the
aggregate required bandwidth to routers ...
... bandwidth to routers on either sides. For
this reason, inter-switch bandwidth is most often appropriately
over provisioned. In addition, the likelihood for receiving ...
... receiving
routers to be only on the sources side of an inter-switch link
is in general deployments rather low. The cases where traffic ...
... 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.
...
... 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 ...
... MLD/IPv6 packet format. This was not done
for this specification because most switches today do not even
support MLD snooping ...
... 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 ...
... 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 ...
... routing with PIM in itself is extremely complex for a
switch to snoop into. PIM has two main versions ...
... 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 ...
... protocol extensions unless support for layer 2 switches is explicitly
considered in moving PIM protocols forward.
...