Cisco Systems Router-port Group Management Protocol (RGMP)
RFC 3488
Document | Type |
RFC - Informational
(March 2003; No errata)
Was draft-wu-rgmp (rtg)
|
|
---|---|---|---|
Authors | Toerless Eckert , Ishan Wu | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 3488 (Informational) | |
Telechat date | |||
Responsible AD | Alex Zinin | ||
Send notices to | <Toerless.Eckert@informatik.uni-erlangen.de> |
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. 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 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 BCP 14, RFC 2119 [2]. 2. Introduction 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. Wu & Eckert Informational [Page 1] RFC 3488 Cisco Systems RGMP February 2003 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. 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. 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. 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 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. The RGMP protocol specifies operations only for IP version 4 multicast routing. IP version 6 is not considered. 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. Wu & Eckert Informational [Page 2] RFC 3488 Cisco Systems RGMP February 2003 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Show full document text