The taxonomy described below 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 amongst session participants.
In the control plane, there are two distinct types of session establishment: rooted and non-rooted. In the case of rooted control, there exists a special participant, called c_root, that is different from the rest of the members of this multipoint session, each of which is called a c_leaf. The c_root must remain present for the whole duration of the multipoint session, as the session will be 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 non-rooted control plane, all the members belonging to a multipoint session are leaves, i.e., no special participant acting as a c_root exists. Each c_leaf needs to add itself to a pre-existing multipoint session that either is always available (as in the case of an IP multicast address), or has been set up through some out-of-band mechanism which is outside the scope of this discussion (and hence not addressed in the proposed Windows Sockets extensions). 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 non-rooted 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 a H.320 video conference, etc.
In the data plane, there are also two types of data transfer styles: rooted and non-rooted. 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 is referred to as a d_leaf. The traffic could be uni-directional, or bi-directional. The data sent out from the d_root will be duplicated (if required) and delivered to every d_leaf, while the data from d_leafs will only go to the d_root. In the case of a rooted data plane, there is no traffic allowed among d_leafs. An example of a protocol that is rooted in the data plane is ST-II.
In a non-rooted data plane, all the participants are equal in the sense that any data they send will be delivered to all the other participants in the same multipoint session. Likewise each d_leaf node will be able to receive data from all other d_leafs, and in some cases, from other nodes which are not participating in the multipoint session as well. No special d_root node exists. IP-multicast is non-rooted 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 are irrelevant to the interface the client would use to perform multipoint communications. Therefore these issues are not addressed by 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 does not appear to be any multipoint schemes that employ a non-rooted control plane along with a rooted data plane.
rooted control plane | non-rooted (implicit rooted) control plane | |
---|---|---|
rooted data plane | ATM, ST-II | No known examples |
non-rooted data plane | T.120 | IP-multicast, H.320 (MCU) |