One document matched: draft-wu-rgmp-00.txt
Ishan Wu
Internet Draft Toerless Eckert
Document: <draft-wu-rgmp-00.txt> cisco Systems
Category: Informational
November 2000
Expires: June 2001
Router-port Group Management Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1] except that the right to
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This draft documents RGMP, a protocol used between multicast routers
and switches to restrict multicast packet forwarding in switches to
those routers where the packets may be needed.
RGMP is designed for backbone switched networks where multiple, high
speed routers are interconnected.
1. Conventions used in this document
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 RFC2119 [2].
Informational - Expires June 2001 1
Router-ports Group Management Protocol November 2000
2. Introduction
IGMP Snooping is a popular, but not well documented, mechanism to
restrict multicast traffic in switched networks to those ports that
may need to receive the multicast traffic. It dynamically
establishes and terminates multicast group specific forwarding in
switches that support this feature. It restricts traffic on those
ports of switches to which only hosts are connected and does not
restrict traffic to ports to which at least one multicast router is
connected. With IGMP Snooping, any multicast traffic sourced by any
router or host on a switched network will be forwarded to all
routers. This is an intrinsic limitation because by snooping on
just IGMP messages, a switch can only learn which multicast traffic
is requested by hosts, but not which traffic needs to get forwarded
to routers for the purpose of being routed by it.
In situations where multiple multicast routers are connected to a
switched backbone, IGMP Snooping will thus not have the desired
effect of reducing multicast traffic and increasing the internal
bandwidth through the use of switches in the network.
In switched backbone networks or exchange points, where
predominantly routers are connected with each others, large amount
of multicast traffic may thus lead to unexpected congestion on the
router ports and to a waste of CPU-cycles in the routers needed to
discard the unwanted multicast traffic.
RGMP is described in this document to restrict multicast traffic to
router ports. To effectively restrict traffic, it must be supported
both by the switches and the routers in the network.
The message format of RGMP resembles that of IGMPv2 so existing
switches that are capable of IGMP Snooping could be easily enhanced
with this feature. Its messages are encapsulated in IP datagrams,
with an IP protocol number of 2, the same as that of IGMP. All RGMP
messages are sent with IP 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 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.
To keep RGMP simple, efficient and easy to implement, it is designed
to expect RGMP messages from only one source per port. For this
reason, RGMP only supports a single RGMP enabled router or RGMP
enabled switch to be connected directly to a port of an RGMP
enabled switch or indirectly to such a port via one or more
non-RGMP enabled switches. Such a topology should be customary
when connecting routers to backbone switches and thus not pose a
limitation on the deployment of RGMP.
Informational - Expires June 2001 2
Router-ports Group Management Protocol November 2000
All RGMP messages have the following format:
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.
2.1 Type
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.
0xFF = Hello
0xFE = Bye
0xFD = Join a group
0xFC = Leave a group
Unrecognized message types should be silently ignored.
2.2. Checksum
Checksum covers the RGMP message (the entire IP payload). The
algorithm and handling of checksum are the same as those for IGMP
messages as described in RFC2236 [5].
2.3. Group Address
In an RGMP Hello or Bye message, the group address field is set to
zero.
In an RGMP Join or Leave message, the group address field holds the
IP multicast group address of the group being joined or left.
2.4 IP header
RGMP messages are sent by routers to switches. The source ip address
of an RGMP packet is the emitting interface IP address of the
originating router. The destination ip address of an RGMP packet is
224.0.0.25. Switches supporting RGMP need to listen to packets to
this group.
Informational - Expires June 2001 3
Router-ports Group Management Protocol November 2000
3. RGMP Protocol Description
3.1 RGMP Router side Protocol Description
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.
A Router enabled for RGMP on an interface periodically [Hello
Interval] sends an RGMP Hello message to the attached switched
network to indicate that it is RGMP enabled. When RGMP is disabled
on a router's interface, it will send out an RGMP Bye message on
that interface, indicating that it again wishes to receive ip
multicast traffic promiscously from that interface.
When running RGMP on an interface, a router sends an RGMP Join
message out the interface for each group that it wants to receive
traffic from the interface. The router needs to periodically
[Join Interval] resend an RGMP Join for a group to indicate its
continued desire to receive multicast traffic for the given group.
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.
The latter two are known as cisco-rp-announce and cisco-rp-discovery
[3].
When a router no longer needs to receive traffic for a particular
group, it sends an RGMP Leave message for the group.
If undesired multicast packets are received at a router from a
switch, the router may send an RGMP Leave message to the switch.
This message should be rate-limited. Before the RGMP Leave message
is sent in this situation, a router should check that the data is
not needed for the group and any other groups that share the same
MAC layer multicast destination address. This MAC/IP multicast
address ambiguity is described in RFC1112 [6].
3.2 RGMP Switch side Protocol Description
RGMP on a switch operates on a per port basis, establishing per-group
forwarding state on RGMP capable ports. A port reverts into an
RGMP capable 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.
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 capable ports always need to receive traffic for
these groups. Traffic for other groups is initially not forwarded
to an RGMP capable ports.
Informational - Expires June 2001 4
Router-ports Group Management Protocol November 2000
RGMP Join and Leave messages are accepted if they arrive on an
RGMP enabled port, otherwise it will be discarded. Upon
acceptance of an RGMP Join message, a timer [5 * Join Interval]
is started, which is coupled with the forwarding state for this group
on this port. This timer is restarted by further RGMP Join messages
for the group arriving on the port. If the timer expires or if it is
removed by the arrival of an RGMP Leave message for the group on this
port, then the forwarding state for this group is removed from
this port as far as RGMP is concerned.
By default a switch will flood multicast traffic to all ports. If
a switch supporting RGMP does concurrently also provide for other
mechanisms to restrict multicast traffic forwarding, then the switch
must be able to get ip multicast traffic also flooded to a port
connected directly or indirectly to an ip multicast router.
Compliance with this specification requires such a switch to be
able to elect a port for flooding through the presence of PIM Hello
messages [4] arriving from a port and through a configuration option.
Further mechanisms for ip multicast traffic restriction may also be
used on RGMP capable 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.
4. Operational Notes
4.1 Support for networks with multiple switches
To be simple and resilient in face of possible network topology
changes, RGMP does not try to restrict multicast traffic on links
connecting switches amongst each other. If another mechanism to
restrict multicast traffic in the network is used in conjunction
with RGMP, then the mechanism to detect routers and flood to their
ports is used as part of RGMP to ensure flooding of multicast
traffic between switches. For routers running PIM and thus sending
PIM Hello messages, no manual configuration is required to set up
a network with multiple switches.
4.2. Interoperability with RGMP-incapable routers
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.
4.3 RGMP and multicast routing protocols
One result of the simplicity of RGMP are its restrictions in
supporting specific routing protocols. The following paragraphs
list a few known restrictions.
Informational - Expires June 2001 5
Router-ports Group Management Protocol November 2000
A router running RGMP on a switched LAN 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
LAN with RGMP enabled routers.
In Bidir-PIM, a router elected to be the DF must not be enabled
for RGMP on the LAN, because it unconditionally needs to forward
traffic received from the LAN towards the RP. If a router is not
the DF for any group on the LAN, it can be enabled for RGMP on
that LAN.
In PIM-SM, directly connected sources on the LAN are not 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.
Both in PIM-SM and PIM-SSM, upstream routers forwarding traffic
into the switched LAN need to send RGMP Joins for the group in
support of the PIM assert process.
5. List of timers and default values
5.1. Hello Interval
The Hello Interval is the interval between RGMP Hello messages sent
by an RGMP-enabled router to an RGMP-enabled switch. Default:
60 seconds.
5.2. Join Interval
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.
6. Security Considerations
We consider the ramifications of a forged message of each type.
Hello Message:
A forged RGMP Hello message from a machine could restrict
multicast data toward itself. It has no adverse effect to other
machines.
Bye Message:
A forged RGMP Bye message from a machine could turn a segment of
a switched network to be RGMP-incapable. Even then, this segment
will get no more multicast data than what it may get without this
protocol.
Informational - Expires June 2001 6
Router-ports Group Management Protocol November 2000
Join Message:
A forged RGMP Join message from a machine could attract undesired
multicast packets to the port where it is received. Even then,
this port will get no more data than what it may get without this
protocol.
Leave Message:
A forged RGMP Leave message from a machine could restrict
multicast data toward itself. It has no adverse effect to other
machines.
7. References
1 Bradner, S., "The Internet Standards Process -- Revision 3",
RFC2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC2119, March 1997.
3 Internet Multicast Addresses,
ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses
4 Estrin, D., et al, "Protocol Independent Multicast-Sparse Mode
(PIM-SM): Protocol Specification", RFC2362, June 1998
5 Fenner, W., "Internet Group Management Protocol, Version 2",
RFC2236, November 1997
6 Deering, S., "Host Extensions for IP Multicasting", RFC1112,
August 1989.
8. Acknowledgments
9. Author's Addresses
Ishan Wu
cisco Systems
170 West Tasman Drive
San Jose, CA 95134
Phone: (408) 526-5673
Email: iwu@cisco.com
Toerless Eckert
cisco Systems
170 West Tasman Drive
San Jose, CA 95134
Phone: (408) 853-5856
Email: eckert@cisco.com
Informational - Expires June 2001 7
| PAFTECH AB 2003-2026 | 2026-04-24 01:15:30 |