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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   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",
   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
   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

   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  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), and
   The latter two are known as cisco-rp-announce and cisco-rp-discovery

   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), and, 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

     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

   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

                    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

   Leave Message:

      A forged RGMP Leave message from a machine could restrict
      multicast data toward itself.  It has no adverse effect to other

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,

   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

   Toerless Eckert
   cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134
   Phone: (408) 853-5856

                    Informational - Expires June 2001                  7