4.1. Extensions to the IP Module Interface
4.1. Extensions to the IP Module Interface
The IP module interface to upper-layer protocols is extended to allow protocols to request reception of all datagrams sent to a particular channel.
Subscribe ( socket, source-address, group-address, interface )
Unsubscribe ( socket, source-address, group-address, interface )
where
"socket" is as previously defined in Section 2,
and, paraphrasing [IGMPv3],
"interface" is a local identifier of the network interface on
which reception of the channel identified by the (source-
address,group-address) pair is to be enabled or disabled. A
special value may be used to indicate a "default" interface. If
reception of the same channel is desired on multiple interfaces,
Subscribe is invoked once for each.
Holbrook & Cain Standards Track [Page 7] RFC 4607 Source-Specific Multicast August 2006
The above are strictly abstract functional interfaces -- the functionality can be provided in an implementation-specific way. On a host that supports the multicast source filtering application programming interface of [MSFAPI], for instance, the Subscribe and Unsubscribe interfaces may be supported via that API. When a host has been configured to know the SSM address range (whether the configuration mechanism is manual or through a protocol), the host's operating system SHOULD return an error to an application that makes a non-source-specific request to receive multicast sent to an SSM destination address.
A host that does not support these IP module interfaces (e.g., ASM- only hosts) and their underlying protocols cannot expect to reliably receive traffic sent on an SSM channel. As specified below in Section 5.2, routers will not set up SSM forwarding state or forward datagrams in response to an ASM join request.
Widespread implementations of the IP packet reception interface (e.g., the recvfrom() system call in BSD Unix) do not allow a receiver to determine the destination address to which a datagram was sent. On a host with such an implementation, the destination address of a datagram cannot be inferred when the socket on which the datagram is received is Subscribed to multiple channels. Host operating systems SHOULD provide a way for a host to determine both the source and the destination address to which a datagram was sent. (As one example, the Linux operating system provides the destination of a packet as part of the response to the recvmsg() system call.) Until this capability is present, applications may be forced to use higher-layer mechanisms to identify the channel to which a datagram was sent.