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 amongst session participants.
In the control plane there are two distinct types of session establishment: 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 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 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 two types of data transfer styles: 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
undsi-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 application
would use to perform multipoint communications. Therefore these issues are not
addressed either in this appendix or 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 existing 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
||No known examples.
|non-rooted data plane
||IP-multicast, H.320 (MCU)
- Software for developers
Software for Android Developers
- More information resources
Unix Manual Pages
- Databases for Amazon shops developers
Amazon Categories Database
Browse Nodes Database