Internet DRAFT - draft-he-msnip-igmp-proxy-ext
draft-he-msnip-igmp-proxy-ext
Internet Engineering Task Force Haixiang He
INTERNET-DRAFT Nortel Networks
Expire: January, 2002 July, 2001
MSNIP Extension for IGMP Proxying
<draft-he-msnip-igmp-proxy-ext-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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
IGMP Proxying can be used to forward multicast data traffic in
certain network topologies. Due to the limitation of the IGMP
Proxying, a Proxy has to forward multicast packets received from
downstream interfaces to upstream interface. In this document, we
proposed a solution to solve this inefficiency by using an extension
to MSNIP.
1. Introduction
IGMP Proxying [1][2] can be used by IPv4 system to forward multicast
traffic in certain network topologies. A device (Proxy) performing
He [Page 1]
Internet Draft MSNIP Extension for IGMP Proxying January, 2002
IGMP Proxying has a single upstream interface and one or more
downstream interface(s). It performs IGMP host portion on its
upstream interface and IGMP router portion on its downstream
interfaces.
MSNIP(Multicast Source Notification of Interest Protocol)[3] is an
extension to IGMPv3 [4]. It is proposed to enable multicast sources
to avoid the work of sending packets when there are no receivers.
In IGMP Proxying, a Proxy has to forward packets received on any
downstream interface to the upstream interface. This is because the
Proxy lacks the abilities to find out whether there is any receiver
that is interested in receiving the packets through the upstream
interface. This is inefficient for the Proxy.
In this document, we proposed a solution to improve the inefficiency
of IGMP Proxying by using an extension to MSNIP.
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 RFC 2119.
2. Packets Forwarding to Upstream Issues and Solutions
In IGMP Proxying, a Proxy forwards every multicast packet received
from downstream interfaces to upstream interface even there is no
receiver upstream. From the upstream network point of view, a Proxy
behaves like a system that wishes to source multicast traffic.
Compared to multicast sources, the only difference here is that the
packets' source addresses are not the address of the Proxy's upstream
interface. Same as other systems that wish to source multicast
traffic, there are inefficiencies for the Proxy as well as the
upstream link if there are no receiver upstream.
The same concept of MSNIP can also be used here between the Proxy and
the upstream router to remove the inefficiency. Like any multicast
source that uses MSNIP, when a Proxy first receives packets from
downstream interfaces, it forwards them to upstream interface. Then
when the Proxy is informed by MSNIP that there is no receiver
upstream, it stop forwarding packets to upstream interface. It will
resume forwarding packets when it is informed by upstream router.
But the current MSNIP specification has to be extended to accommodate
the communication of receiver membership information between the
Proxy and the upstream router. This is because the Proxy is not the
original source of the multicast packets. So the current MSNIP
specification won't work in that the receiver membership information
He [Page 2]
Internet Draft MSNIP Extension for IGMP Proxying January, 2002
is unicast to the original multicast source directly. Also a Proxy
cannot use the current MSNIP specification to solicit interest of
receiver membership information for specific multicast sources.
We proposed two new MSNIP messages to accommodate the communication.
The new messages allow a Proxy to solicit its interest of receiver
membership information for specific sources. And they also enable a
multicast router to send the receiver membership information for
specific sources to a Proxy that interests in receiving this
information instead of the original multicast source.
A Proxy MUST have the ability to know the source address of the
packets it forwards to upstream interface. The upstream router should
follow the requirements for first hop router specified in MSNIP [3].
We define that SOURCE is a system that source multicast packets. We
also define that PROXY is a device that forwards multicast packets. A
device can be both a PROXY and a SOURCE.
3. New MSNIP Messages
The two new MSNIP messages are Source Interest Solicitation message
and Source Group Membership Report message. Like other MSNIP
messages, these two new messages should follows the requirements
specified in [3].
The new message types are:
+-------------------+-----------------------------------------+
| Type Number (hex) | Message Name |
+-------------------+-----------------------------------------+
| 0x26 | Source Interest Solicitation |
+-------------------+-----------------------------------------+
| 0x27 | Source Group Receiver Membership Report |
+-------------------+-----------------------------------------+
3.1. Source Interest Solicitation Packet
Like Interest Solicitation, the Source Interest Solicitation packet
is also periodically multicast by MSNIP capable systems. But it is
used by PROXYs to solicit interest in Receiver Membership Reports for
specific multicast source(s) from multicast router on the link.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
He [Page 3]
Internet Draft MSNIP Extension for IGMP Proxying January, 2002
| Type = 0x26 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime | GenID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Count
The number of source addresses presented in the message.
Source-Address-1
The first multicast source address in the message.
Other fields
Same as described in [3].
3.2. Source Group Membership Report Packet
The Group Membership Report message is unicast by the first-hop
multicast routers, in this document upstream routers, to communicate
the existence or not of receivers for specific source and group
pairs. The destination address is the IP address of a system that has
interest of receiving the information.
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 = 0x27 | Source Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group-Count-1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record-Type-1-1| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group-Address-1-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Count
He [Page 4]
Internet Draft MSNIP Extension for IGMP Proxying January, 2002
The number of source records present in the packet.
Group-Count-1
The number of group records present in the first source record.
Source-Address-1
The multicast source address for the first source record in the
message.
Record-Type-1-1
The type of the first group record of the first source record.
Valid values are the same as in MSNIP specification [3].
Group-Address-1-1
The multicast group address of the first group record in the
first source record.
4. MSNIP Extension Description
A PROXY and an upstream router still follow the behavior of the Group
Range Negotiation to communicate a range of MSNIP managed groups as
specified in [3].
4.1. Source Interest Solicitation
PROXYs periodically transit Source Interest Solicitation messages
following the requirements to transit Interest Solicitation messages.
The upstream routers that receive an Source Interest Solicitation
message maintain a system interest record of the form:
(destination address, holdtime timer, source address list)
where the destination address is the IP address of the upstream
interface of a PROXY and each source address s in the source address
list is one of the multicast source that a PROXY forwards its packets
and it has interest to receive its membership report information.
The upstream routers may also choose to maintain a system interest
record per multicast source of the form:
(source address, destination address, holdtime timer)
where the source address is the multicast source and the destination
address is the address of a PROXY that has interest to receive
membership report information for this source. Which form of record
to use is an implementation issue.
He [Page 5]
Internet Draft MSNIP Extension for IGMP Proxying January, 2002
The router responds to the Source Interest Solicitation message with
a Source Group Membership Report Message described in section 3.2.
The message contains a TRANSMIT group record for each of the group
addresses within the MSNIP managed range for which the routing
protocol indicates there are receivers for source(s) in the source
list.
4.2. Source Group Membership Reports
When receiving a Source Interest Solicitation message, or when the
receiver membership status changes for a specific source and group,
routers send Source Group Membership Reports. Such reports are only
sent if the group is managed by MSNIP and the source address is
interested by a PROXY.
The receiver membership information is unicast to the PROXY that has
interest of the information. The destination address is the IP
address of the upstream interface of the PROXY. It can be acquired
through the system interest record maintained by the upstream router.
When a PROXY receives a Source Group Membership Report message, for
each of the TRANSMIT source group records listed in the message, it
creates or updates a source group record of the form:
(interface, router address, src, group address, holdtime timer)
where the src is the multicast source address and other fields are
the same as in MSNIP specification. For each of the HOLD source group
records in the message, the PROXY deletes the relevant source group
record from its state.
4.3. Upstream Router State Information
To maintain only one format of the system interest record, the
upstream routers that receive an Interest Solicitation message MAY
maintain a record for a SOURCE system like below:
(IP address(des), holdtime timer, IP address(src))
or
(IP address(src), IP address(des), holdtime timer)
where IP address is the SOURCE's IP address.
In this case, when the routers needs to send the receiver membership
He [Page 6]
Internet Draft MSNIP Extension for IGMP Proxying January, 2002
information for a specific source address, the source address is used
to search the system records. If the source address is find in the
source lists or source fields, then the corresponding destination
address is retrieved. If the destination address equals the source
address, then the Group Membership Report message is sent. Otherwise,
the Source Group Membership Report message is sent.
4.4. Proxy's State Information
A Proxy can be a PROXY that forwards multicast packets and it can
also be a SOURCE that sends multicast packets. If a Proxy is both a
PROXY and a SOURCE, it uses both Interest Solicitation and Source
Interest Solicitation messages. It may use just Source Interest
Solicitation message with its upstream interface IP address as one of
the source address in the message.
To maintain just one format of the record, when it receives an
Interest Solicitation message, it also maintain a record as described
in section 4.2. The source address is the IP address of the upstream
interface.
5. Changes of API for Request Membership Notification
If the IGMP Proxying is considered an application to MSNIP and uses
the APIs to request membership notification, the current MSNIP APIs
need to be modified. The new API must support the following operation
or any logical equivalent:
IPMulticastSourceRegister(socket, if, source-addr, multicast-addr)
IPMulticastSourceDeregister(socket, if, source-addr, multicast-addr)
In addition the IGMP Proxying or other applications must provide the
following API for receiving notifications:
IPMulticastSourceStart(socket, if, source-addr, multicast-addr)
IPMulticastSourceStop(socket, if, source-addr, multicast-addr)
where:
source-addr
is the IP multicast source address to which the request
pertains. If transmission to more than one source address on a
given interface is desired, IPMulticastSourceRegister is invoked
separately for each desired source address.
Other fields are the same as described in MSNIP specification.
He [Page 7]
Internet Draft MSNIP Extension for IGMP Proxying January, 2002
6. Membership Information Relay
The PROXY may choose to relay the membership report information to
downstream sources. In this case, the MSNIP should be performed
between downstream interface(s) and the downstream IP systems (direct
source or others). How and to what degree to relay the membership
information is beyond the scope of this document.
7. Security Considerations
Security considerations will be provided later.
References
[1] Fenner, W., "IGMP-based Multicast Forwarding ("IGMP Proxying")",
<draft-ietf-idmr-igmp-proxy-00.txt>, April, 2001.
[2] He, H., Haberman, B., and Sandick, H., "IGMP Mixed Version
Proxying", <draft-he-mixed-igmp-proxy-00.txt>, February, 2001.
[3] Fenner, W., Holbrook, H., and Kouvelas, I., "Multicast Source
Notification of Interest Protocol (MSNIP)", <draft-ietf-idmr-
msnip-00.txt>, February, 2001.
[4] Cain, B., Deering, S., Fenner, W., Kouvelas, I., Thyagarajan, A.,
"Internet Group Management Protocol, Version 3", <draft-ietf-
idmr-igmp-v3-07.txt>, March, 2001.
Author's Address:
Haixiang He
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
Phone: 978-288-7482
Email: haixiang@nortelnetworks.com
He [Page 8]
