Multipoint and Multicast Semantics

From MSDN

In considering how to support multipoint and multicast semantics in Windows Sockets 2 (Winsock), a number of existing and proposed schemes (including IP-multicast, ATM point-to-multipoint connection, ST-II, T.120, H.320-MCU) were examined. To enable a coherent discussion of the various schemes, it is valuable to first create a taxonomy that characterizes the essential attributes of each. In this document, the term multipointrepresents both multipoint and multicast.

Multipoint Taxonomy

The taxonomy described in this section first distinguishes the control plane that concerns itself with the way a multipoint session is established, from the data plane that deals with the transfer of data among session participants.

Session Establishment in the Control Plane

In the control plane there are two distinct types of session establishment:

• rooted
• nonrooted

In the case of rooted control, a special participant, c_root, exists that is different from the rest of the members of this multipoint session, each of which are called a c_leaf. The c_root must remain present for the whole duration of the multipoint session, as the session is broken up in the absence of the c_root. The c_root usually initiates the multipoint session by setting up the connection to a c_leaf, or a number of c_leafs. The c_root may add more c_leafs, or (in some cases) a c_leaf can join the c_root at a later time. Examples of the rooted control plane can be found in ATM and ST-II.

For a nonrooted control plane, all the members belonging to a multipoint session are leaves, that is, no special participant acting as a c_root exists. Each c_leaf must add itself to a preexisting multipoint session that is always available (as in the case of an IP multicast address), or has been set up through some out-of-band (OOB) mechanism that is outside the scope of the Windows Sockets specification.

Another way to look at this is that a c_root still exists, but can be considered to be in the network cloud as opposed to one of the participants. Because a control root still exists, a nonrooted control plane could also be considered to be implicitly rooted. Examples for this kind of implicitly rooted multipoint schemes are:

• A teleconferencing bridge.
• The IP multicast system.
• A Multipoint Control Unit (MCU) in an H.320 video conference.

Data Transfer in the Data Plane

In the data plane, there are two types of data transfer styles:

• rooted
• nonrooted

In a rooted data plane, a special participant called d_root exists. Data transfer only occurs between the d_root and the rest of the members of this multipoint session, each of which are referred to as a d_leaf. The traffic could be unidirectional or bidirectional. The data sent out from the d_root is duplicated (if required) and delivered to every d_leaf, while the data from d_leafs only goes to the d_root. In the case of a rooted data plane, no traffic is allowed among d_leafs. An example of a protocol that is rooted in the data plane is ST-II.

In a nonrooted data plane, all the participants are equal, that is, any data they send is delivered to all the other participants in the same multipoint session. Likewise each d_leaf node can receive data from all other d_leafs, and in some cases, from other nodes that are not participating in the multipoint session. No special d_root node exists. IP-multicast is nonrooted in the data plane.

Note that the question of where data unit duplication occurs, or whether a shared single tree or multiple shortest-path trees are used for multipoint distribution are protocol issues, and irrelevant to the interface the application would use to perform multipoint communications. Therefore these issues are not addressed in this appendix or the Windows Sockets interface.

The following table depicts the taxonomy described above and indicates how existing schemes fit into each of the categories. Note that there do not appear to be any existing schemes that employ a nonrooted control plane along with a rooted data plane.

Windows Sockets 2 Interface Elements for Multipoint and Multicast

The mechanisms that have been incorporated into Windows Sockets 2 for utilizing multipoint capabilities can be summarized as follows:

• Three attribute bits in the WSAPROTOCOL_INFO structure.
• Four flags defined for the dwFlags parameter of WSASocket.
• One function, WSAJoinLeaf, for adding leaf nodes into a multipoint session.
• Two WSAIoctl command codes for controlling multipoint loopback and the scope of multicast transmissions.

The following sections describe these interface elements in more detail:

• Semantics for Joining Multipoint Leaves
• How Existing Multipoint Protocols Support These Extensions

Semantics for Joining Multipoint Leaves

In the following, a multipoint socket is frequently described by defining its role in one of the two planes (control or data). It should be understood that this same socket has a role in the other plane, but this is not mentioned in order to keep the references short. For example when a reference is made to a "c_root socket", this could be either a c_root/d_root or a c_root/d_leaf socket.

In rooted control plane schemes, new leaf nodes are added to a multipoint session in one or both of two different ways. In the first method, the root usesWSAJoinLeaf to initiate a connection with a leaf node and to invite it to become a participant. On the leaf node, the peer application must have created a c_leaf socket and used listen to set it into listen mode. The leaf node receives an FD_ACCEPT indication when invited to join the session, and signals its willingness to join by calling WSAAccept. The root application then receives an FD_CONNECT indication when the join operation has been completed.

In the second method, the roles are essentially reversed. The root application creates a c_root socket and sets it into listen mode. A leaf node wishing to join the session creates a c_leaf socket and uses WSAJoinLeaf to initiate the connection and request admittance. The root application receives FD_ACCEPT when an incoming admittance request arrives, and admits the leaf node by calling WSAAccept. The leaf node receives FD_CONNECT when it has been admitted.

In a nonrooted control plane, where all nodes are c_leaf’s, the WSAJoinLeaf is used to initiate the inclusion of a node into an existing multipoint session. An FD_CONNECT indication is provided when the join has been completed and the returned socket descriptor is usable in the multipoint session. In the case of IP multicast, this would correspond to the IP_ADD_MEMBERSHIP socket option.

(Readers familiar with IP multicast’s use of the connectionless UDP protocol may be concerned by the connection-oriented semantics presented here. In particular the notion of using WSAJoinLeaf on a UDP socket and waiting for an FD_CONNECT indication may be troubling. There is, however, ample precedent for applying connection-oriented semantics to connectionless protocols. It is allowed and sometimes useful, for example, to invoke the standard connect function on a UDP socket. The general result of applying connection-oriented semantics to connectionless sockets is a restriction in how such sockets may be used, and this is the case here, as well. A UDP socket used in WSAJoinLeaf will have certain restrictions, and waiting for an FD_CONNECT indication (which in this case simply indicates that the corresponding IGMP message has been sent) is one such limitation.)

There are therefore, three instances where an application would use WSAJoinLeaf acting as a:

• Multipoint root and inviting a new leaf to join the session
• Leaf making an admittance request to a rooted multipoint session
• Leaf seeking admittance to a nonrooted multipoint session (for example, IP multicast)

Semantic Differences Between Multipoint Sockets and Regular Sockets

In the control plane, there are some significant semantic differences between a c_root socket and a regular point-to-point socket:

• The c_root socket can be used in WSAJoinLeaf to join a new a leaf.
• Placing a c_root socket into listening mode (by calling listen) does not preclude the c_root socket from being used in a call to WSAJoinLeaf to add a new leaf, or for sending and receiving multipoint data.
• The closing of a c_root socket causes all of the associated c_leaf sockets to get FD_CLOSE notification.

There are no semantic differences between a c_leaf socket and a regular socket in the control plane, except that the c_leaf socket can be used in WSAJoinLeaf, and the use of c_leaf socket in listen indicates that only multipoint connection requests should be accepted.

In the data plane, the semantic differences between the d_root socket and a regular point-to-point socket are:

• The data sent on the d_root socket is delivered to all the leaves in the same multipoint session.
• The data received on the d_root socket may be from any of the leaves.

The d_leaf socket in the rooted data plane has no semantic difference from the regular socket, however, in the nonrooted data plane, the data sent on the d_leaf socket goes to all the other leaf nodes, and the data received could be from any other leaf nodes. As mentioned earlier, the information about whether the d_leaf socket is in a rooted or nonrooted data plane is contained in the corresponding WSAPROTOCOL_INFOstructure for the socket.

How Existing Multipoint Protocols Support These Extensions

The following topics indicate how IP multicast and ATM point-to-multipoint capabilities can be accessed through the Windows Sockets 2 multipoint functions. We chose these two as examples because they are popular and well understood.

• IP Multicast
• ATM Point to Multipoint

IP Multicast

IP multicast falls into the category of nonrooted data plane and nonrooted control plane. All applications play a leaf role. Currently, most IP multicast implementations use a set of socket options proposed by Steve Deering to the Internet Engineering Task Force (IETF). Five operations are thus made available:

• IP_MULTICAST_TTL — Sets time-to-live, controls scope of a multicast session.
• IP_MULTICAST_IF — Determines interface to be used for multicasting.
• IP_ADD_MEMBERSHIP — Joins a specified multicast session.
• IP_DROP_MEMBERSHIP — Drops out of a multicast session.
• IP_MULTICAST_LOOP — Controls loopback of multicast traffic.

Setting the time-to-live for an IP-multicast socket maps directly to using the SIO_MULTICAST_SCOPE command code for WSAIoctl.

The method for determining the IP interface to be used for multicasting is through a TCP/IP-specific socket option as described in the Windows Sockets 2 Protocol-Specific Annex. The remaining three operations are covered well with the Windows Sockets 2 semantics described here.

The application would open sockets with c_leaf/d_leaf flags in WSASocket. It would useWSAJoinLeaf to add itself to a multicast group on the default interface designated for multicast operations. If the flag in WSAJoinLeaf indicates that this socket is only a sender, then the join operation is essentially a no-op and no IGMP messages need to be sent. Otherwise, an IGMP packet is sent out to the router to indicate interests in receiving packets sent to the specified multicast address. Since the application created special c_leaf/d_leaf sockets used only for performing multicast, the standard closesocketfunction would be used to drop out of the multicast session. The SIO_MULTIPOINT_LOOPBACK command code for WSAIoctl provides a generic control mechanism for determining whether data sent on a d_leaf socket in a nonrooted multipoint scheme can also be received on the same socket.

Note  The Winsock version of the IP_MULTICAST_LOOP option is semantically different than the UNIX version of the IP_MULTICAST_LOOP option:

• In Winsock, the IP_MULTICAST_LOOP option applies only to the receive path.
• In the UNIX version, the IP_MULTICAST_LOOP option applies to the send path.

For example, applications ON and OFF (which are easier to track than X and Y) join the same group on the same interface; application ON sets the IP_MULTICAST_LOOP option on, application OFF sets the IP_MULTICAST_LOOP option off. If ON and OFF are Winsock applications, OFF can send to ON, but ON cannot sent to OFF. In contrast, if ON and OFF are UNIX applications, ON can send to OFF, but OFF cannot send to ON.

ATM Point to Multipoint

ATM falls into the category of rooted data and rooted control planes. An application acting as the root would create c_root sockets and counterparts running on leaf nodes would utilize c_leaf sockets. The root application uses WSAJoinLeaf to add new leaf nodes. The corresponding applications on the leaf nodes will have set their c_leaf sockets into listen mode. WSAJoinLeaf with a c_root socket specified is mapped to the Q.2931 ADDPARTY message. The leaf-initiated join is not supported in ATM UNI 3.1, but is supported in ATM UNI 4.0. Thus WSAJoinLeaf with a c_leaf socket specified is mapped to the appropriate ATM UNI 4.0 message.

There are additional considerations to bear in mind for ATM point-to-multipoint:

• The addition of new leaves to the ATM point-to-multipoint session is invitation-based only. The root invites leaves — which have already their accept function call — by calling the WSAJoinLeaf function.
• The flow of data in an ATM point-to-multipoint session is from root-to-leaves only; leaves cannot use the same session to send information to the root.
• Only one leaf per ATM adapter is allowed.

Attributes in WSAPROTOCOL_INFO Structure

In support of the taxonomy described above, three attribute parameters in theWSAPROTOCOL_INFO structure are used to distinguish the schemes used in the control and data planes respectively:

• XP1_SUPPORT_MULTIPOINT with a value of 1 indicates this protocol entry supports multipoint communications, and that the following two parameters are meaningful.
• XP1_MULTIPOINT_CONTROL_PLANE indicates whether the control plane is rooted (value = 1) or nonrooted (value = 0).
• XP1_MULTIPOINT_DATA_PLANE indicates whether the data plane is rooted (value = 1) or nonrooted (value = 0).

Note that two WSAPROTOCOL_INFO entries would be present if a multipoint protocol supported both rooted and nonrooted data planes, one entry for each.

The application can use WSAEnumProtocols to discover whether multipoint communications is supported for a given protocol and, if so, how it is supported with respect to the control and data planes, respectively.

Flag Bits for WSASocket

In some instances sockets joined to a multipoint session may have some differences in behavior from point-to-point sockets. For example, a d_leaf socket in a rooted data plane scheme can only send information to the d_root participant. This creates a need for the application to be able to indicate the intended use of a socket coincident with its creation. This is done through four-flag bits that can be set in the dwFlags parameter toWSASocket:

• WSA_FLAG_MULTIPOINT_C_ROOT, for the creation of a socket acting as a c_root, and only allowed if a rooted control plane is indicated in the correspondingWSAPROTOCOL_INFO entry.
• WSA_FLAG_MULTIPOINT_C_LEAF, for the creation of a socket acting as a c_leaf, and only allowed if XP1_SUPPORT_MULTIPOINT is indicated in the correspondingWSAPROTOCOL_INFO entry.
• WSA_FLAG_MULTIPOINT_D_ROOT, for the creation of a socket acting as a d_root, and only allowed if a rooted data plane is indicated in the correspondingWSAPROTOCOL_INFO entry.
• WSA_FLAG_MULTIPOINT_D_LEAF, for the creation of a socket acting as a d_leaf, and only allowed if XP1_SUPPORT_MULTIPOINT is indicated in the correspondingWSAPROTOCOL_INFO entry.

Note that when creating a multipoint socket, exactly one of the two control-plane flags, and one of the two data-plane flags must be set in WSASocket‘s dwFlagsparameter. Thus, the four possibilities for creating multipoint sockets are:

• "c_root/d_root"
• "c_root/d_leaf"
• "c_leaf/d_root"
• "c_leaf /d_leaf"

SIO_MULTIPOINT_LOOPBACK Command Code for WSAIoctl

When d_leaf sockets are used in a nonrooted data plane, it is desirable to have traffic that is sent out received back on the same socket. The SIO_MULTIPOINT_LOOPBACK command code for WSAIoctl is used to enable or disable loopback of multipoint traffic.

SIO_MULTICAST_SCOPE Command Code for WSAIoctl

When multicasting is employed, it is usually necessary to specify the scope over which the multicast should occur. Scope is defined as the number of routed network segments to be covered. A scope of zero would indicate that the multicast transmission would not be placed on the wire but could be disseminated across sockets within the local host. A scope value of 1 (the default) indicates that the transmission will be placed on the wire, but will not cross any routers. Higher scope values determine the number of routers that may be crossed. Note that this corresponds to the time-to-live (TTL) parameter in IP multicasting.

The function WSAJoinLeaf is used to join a leaf node into the multipoint session. See the following for a discussion on how this function is utilized.