INTERNET-DRAFT Expire in six months
Chang Won Son
Soo Hyoung Oh
Ji Yeon Son
ETRI
ver. 1. April 1996
Distributed Dynamic Multicast Address(DDMA) Assignment in Internet
<draft-son-ddma-00.txt>
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document presents a dynamic multicast address allocation and
distribution scheme in the Internet address space. By the scheme
a multcast address for a multicasted session is chosen by a host
based on its own host address and port number of the session.
I. Introduction
Unlike a host address, which identifies a host in a network, a
multicast address identifies a group of hosts. Theologically, the
number of possible groups by the hosts have an exponential relationship
to the number of hosts in a network. Thus, it is impractical to assign
a multicast address for each possible groups. More attractive
approaches are dynamical allocation schemes, by which a multicast
address is allocated when a group is in session, then the address is
released during dismantle of the session. The address can be reclaimed
by other group sessions. While a multicast address is temporal address
in the dynamic allocation schemes, the address should be allocated on
demand. There are two distinguishable approaches. First, the address
can be allocated by a multicast name server. The server is responsible
to provide a globally unique multicast address by maintaining
allocated address list. The list can be managed by a single server, or
it can be distributed in multiple servers. Secondly, the address can
be allocated by individual hosts. One of the simple solutions of the
later approach is the random pick approach. With this approach, a host
choose a multicast address randomly, then it advertises the address to
find out that whether or not the address is claimed by any other hosts.
If not, the address can be used by the host. Otherwise, the host picks
another address. The process continues until an usable address can be
found.
The above approaches have significant address resolution delay and
traffic. A distributed multicast allocation scheme proposed by [Pej]
fixes the problems. In the approach, each individual host selects a
multicast address which is based on its host address and port number
of the multicast address requesting session. Since the tuple of host
address and port number is globally unique, the uniqueness of the
address can be achievable. The original scheme by [Pej] has some
limitations, such as all multicast addresses which allocated within a
subnetwork have same multicast network address, so that the multicast
address can not be distinguishable by network layer, unless every
hosts and gateways are modified to take the port number. This paper
defines a distributed dynamic multicast addressing scheme, which is
based on [Pej].
II. Distributed Multicast Address Allocation
In the Internet environment, a host address is used to identify a node
within a network, then port address is used to identify an endpoint of
a data stream within the host. The host address and port address tuple
identifies a globally unique endpoint of a data stream. Thus, a
multicast address assigned by a host with the tuple should be globally
unique. Currently, the host address consists of 4 octets and the port
number consists of 2 octets. To be identified as a multicast address,
the first octet of the Internet address should be chosen from 224 to
239. With the address components, globally unique multicast address
can be assigned by 7 octets.
As figure 1, the multicast address is constructed with multicast
network address(1) and multicast port number(2). The highest octet of
multicast network address is in [224-239] to indicate that the address
is a multicast address. Then the other octets are taken from lower 3
octets of host network address. The highest octet of the host network
address is used for low octet of the multicast port number. For the
compatibility with existing address scheme, the 2 octets of port space
is mapped into high octet of the multicast port number. If we consider
that there are 16 choices in the highest octet of multicast network
address for each hosts, each host can assign at most 4096 globally
unique multicasted sessions without external assistance.
Host IP Address Port
+---------+ +-- ---+
| a.b.c.d | | u.v |
+---------+ +------+
| |
| |
V V
+---------------------------------------------------+
| +--------------+ (1) +--------+ (2) |
| |224-239.b.c.d | |(u*v).a | |
| +--------------+ +--------+ |
+---------------------------------------------------+
Figure 1. Multicast Address allocation from Host Address
Internet address is composed of domain and host address fields. In
each domain all hosts have the same value in domain address field. The
domain is classified as A, B, C and D. All hosts within a class C
domain have the same address value in highest 3 octets of the address.
All hosts within a class B domain have the same address value in
highest 2 octets of the address. All hosts within a class A domain
have the same address value in highest 1 octets of the address. The
class D domain is assigned for multicast address. By using last 3
octets for multicast addressing, each host can assign locally unique
multicast network address within a domain(A,B,C).
III. Single Domain network
Multicast sessions which are assigned by
different hosts do not interfere each other
within a domain.
In figure 2, hosts A, B and C has an established multicast session
with a multicast network address a which is allocated by host A. And
host C, D, and E has an established multicast session with a multicast
network address c which is allocated by host C. Then host A and B only
receives multicasted data with multicast network address a. The host D
and E only receives multicasted data with multicast network address c.
And host C receives multicasted data with multicast network address a
and c. As the result, the multicast network traffic between host A, B,
and C with multicast network address assigned by host A does not
interfere with the multicast network traffic between host C, D, and E
with multicast network address assigned by host C.
A B C D E
| | | | |
| | | | |
|(a) |(a) |(a,c) |(c) |(c)
------+--------------+----------+---------+--------------+---
Network Address 10.x.x.x
Figure 2. Single Domain Network
IV. Network with Sub-domains
Multicast sessions which are assigned by
different hosts do not interfere each other
within sub-domains from class A or class B
network.
Suppose above network has sub-domains, and the sub-domains are
connected by routers. Then the multicast network addresses which are
assigned by individual hosts in the domain still have different values
each other. By that, the above statement is also true. In figure 3,
hosts A, B, C, and D has an established multicast session with a
multicast network address a which is allocated by host A. And host D,
E, and F has an established multicast session with a multicast network
address e which is allocated by host E. Then host A, B, and C only
receives multicasted data with multicast address a. The host E and F
only receives multicasted data with multicast network address e. And
the host D receives multicasted data with multicast network address a
and e. As the result, the multicast network traffic between host A, B,
C, and D with multicast network address assigned by host A, does not
interfere with the multicast network traffic between host D, E, and F
with multicast network address assigned by host E. More importantly,
the router between the subnetwork 10.1.x.x and 10.2.x.x does not route
unnecessary multicast traffic.
A B C D
| | | |
| | | |
|(a) |(a) |(a) |(a,e)
------+--------------+--------+--------+-------+---
Network Address 10.1.x.x |
|(e)
R (router)
|(e) 10.2.x.x
------+---------+-------+------
|(e) |(e)
| |
| |
E F
Figure 3. Network with Sub-domains
V. Inter-domain Network
Multicast sessions which are assigned by
different hosts may interfere each other over
inter domain routers.
Suppose, subnetworks from different domains are connected by routers.
Then there are possibilities that multiple hosts assign the identical
multicast network address. In figure 4, there is a router R which
interconnects networks in domain address 10.1.x.x, and domain address
132.1.x.x. As previous example in figure 3, hosts A, B, C, and D has
an established multicast session with a multicast network address a
which is allocated by host A. And host D, E, and F has an established
multicast session with a multicast network address e which is
allocated by host E, and both hosts pick the same multicast address
prefix(230). Now, if the host address of A is 10.1.10.1, the host
address of E is 132.1.10.1 then the multicast network address a and e
become 230.1.10.1. As the result, the multicast sessions can not be
distinguishable by network layer. That involves two problems: 1)
Unnecessary multicasted traffic may cross the router. 2) Each
multicasting host receives unwanted multicasted traffic. The first
problem can be fixed by modifying router R. So that, the router uses
multicast port number to route the multicasted session. We need to
notice that modification of routers is only required on the inter-
domain routers. All internal routers do not need to be modified for
the purpose. It is quite important that the number of inter-domain
routers is a fraction of total number of routers in a large domained
network. The second problem has no simple solution, unless each host
is modified in network layer protocol to use the multicast port number
to decide whether or not it accepts and delivers multicast traffic to
higher layer. However, the possibility is not large by the reasons as
follow: 1) There exists only 256 or smaller number of hosts which has
same value in lower 3 octets of the host address in whole Internet
environment. 2) It is more likely that most multicasted sessions are
retained within an organization or domain.
A B C D
| | | |
| | | |
|(a) |(a) |(a) |(a,e)
------+--------------+--------+--------+------+---
Network Address 10.1.x.x |
|(e)
R (router)
|(e) 132.1.x.x
-----+---------+-------+-----
|(e) |(e)
| |
| |
E F
Figure 4 . Inter-domain Network
VI. Limitations
The limitation of the proposed scheme not yet stated is as follow: If
a host has multiple concurrent multicast sessions, then the sessions
have identical multicast network address. Suppose in figure 1, a host
A has multicast sessions S1 and S2. The session S1 has established
between host A, C, and E. The session S2 has established between host
A, B, and D. If the two sessions has the same value in the highest
octet of the multicast address. Then the multicast network address of
session S1 and S2 become identical. Therefore, the hosts B,C,D, and E
can not distinguish the session S1 and S2 by multicast network address
alone. That makes the host C and E receives unnecessary multicasted
traffic of session S2, and the host B and D receives unnecessary
multicasted traffic of session S1. It could be quite burden to each
host especially when a host generates a large number of multicast
sessions. There are two possible solutions for this problem. First,
the network layer protocol can be modified as stated above by that
network layer can filter out unnecessary multicast traffic with
multicast port number. Secondly, we can provide fair chance to
allocate a multicast address to every hosts in a network. In general a
local area network is a group of interconnected hosts, some of them
are high powered machines and the others are less powerful hosts such
as workstations. Most less powered hosts only have a few multicast
sessions at any moment. If a host has a large number of multicast
sessions, the host is more likely be a high powered machine which is
used as a server for applications. To resolve the problem, multicast
address for a session can be allocated one of the clients for each
multicast session. If the second scheme is used properly, it is the
most effective and acceptable solution for the most of networking
environment.
VII. Multicast Address distribution in Internet
The multicast address(session address) allocated by one of the hosts
in a multicasted connection can not be used until the address is
distributed to every hosts in the connection, then the hosts bind
themselves to the address. For the purpose, a secondary address is
introduced, multicasted application address is the one. The
multicasted application address provides similar function to the well
known port number in the Internet. With the address each hosts can
accept any incoming session establishment requests, in the request the
multicast session address is distributed to every hosts in the session.
For the distributed multicast address allocation scheme, a part of
Internet multicast address can be reserved, for instance, 225.x.x.x is
used for multicasted application addresses, and 226.x.x.x is used for
multicasted session addresses. With 225.x.x.x, Internet can define at
most 2**24 applications. And with 226.x.x.x each host can assign 256
concurrent multicast sessions. Internet already assigned some parts of
224.x.x.x for special purpose. Therefore, multicast address [257-
239].x.x.x is still available for other multicast addressing schemes.
The distributed multicast address allocation scheme is also applicable
for the immersing Internet addressing scheme (IPV6), by extending the
size of each field.
References
[Pej] Sassan Pejhan, Alexandros Eleftheriadis, and Dimitris
Anastassiou, "Distributed Multicast Address Management in the Global
Internet," IEEE Journal on Selected Areas in Communications. Vol. 13,
No. 3, pp. 1445-1456, October 1995.
[Postel] J. Reynolds and J. Postel, "Assigned numbers," RFC1340, July
1992.
[Elef] Eleftheriadis, A., Pejhan, S. and Anastassiou, D., "Address
Management and Connection Control for Multicast Communication
Application," Proceedings of IEEE INFOCOM, pp. 386-393, April 1995.
[Deer] Deering, S., "Host Groups: A Multicast Extention for Datagram
Internetworks," RFC1112, Stanford University, July 1989.
Author's Address
Chang Won Son
Soo Hyoung Oh
Ji Yeon Son
Computer Communications Section
Electronics and Telecommunications Research Institute
P.O.Box 106, Yusong, Taejon, 305-600 Korea
Tel: 082-42-860-5583 Fax: 082-42-860-6671
Email: son@com1.etri.re.kr