INTERNET-DRAFT Michael Smirnov
GMD FOKUS
Expires May, 25, 1997 November 20, 1996
EARTH - EAsy IP multicast Routing THrough ATM clouds
<draft-smirnov-ion-earth-01.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
The EARTH could be positioned between MARS [1] and VENUS [2], however
EARTH deals not only with address resolution but with routing issue
as well. This document describes a solution simplifying distribution
of IP multicast flows over ATM clouds with the use of
point-to-multipoint connections. The EARTH solution includes:
- IP multicast addresses (Class D) resolution to ATM addresses;
- support for a multicast group management and receiver-initiated
quality of service (QoS) specification;
- multiple LISs sharing the same physical ATM network.
Similarly to separation of IP addresses to unicast and multicast
classes, the EARTH proposal separates logical IP subnets as an
option to speed up implementation. EARTH differs from MARS: address
resolution is made only for IP Class D addresses; multiple LISs
could be served by a single EARTH server; EARTH server belongs to a
`multicast LIS'. On contrary to VENUS proposal, EARTH simplifies
bypassing Mrouters and requires no coordination of multiple MARSs.
The EARTH proposal is not intended to solve problems of ATM backbone
for the Internet; it deals with state-of-the-art ATM clouds.
This document, proposing a solution not yet implemented completely,
is intended to help focus ION efforts.
Smirnov [Page 1]
^L
Internet Draft <draft-smirnov-ion-earth-01.txt> November, 20, 1996
1. Introduction
Connection oriented ATM technology is known to have a large spectrum
of differences from that of connectionless IP [3]; address
resolution problem being one of the most serious. Moreover, address
resolution is even more difficult when it is needed to resolve one IP
[multicast] address to a set of ATM addresses. This fact is emphasised
in the description of MARS: "the service provided by the MARS and MARS
Clients are almost orthogonalto the IP unicast service over ATM" [1].
This was the initial motivation to separate IP unicast from IP multicast
addresses resolution to ATM addresses in the EARTH. Actually, for IP
unicast over ATM there is no need to [re]invent something new: IP
unicast ARP is supported fairly well in those ATM products which
conform to the Classical IP over ATM [4].
Architecture described in [4] fits the need of unicast but provides
strong resistance to deployment of IP multicast service model [5]
over ATM clouds. This resistance is due to a restriction for LISs to
interwork over routers only, even if these LISs share the same
physical ATM network [4]. In case of unicast communication
interworking between different LISs with the use of routers makes no
difficulties; ATM connection establishment is supported by ATM ARP
servers - one server per LIS. The content of unicast ARP table is
quasi permanent. On contrary, the multicast ARP table's content
(e.g. for MARS proposal) is dynamic and follows receiver initiated
membership registration messages for particular multicast group[s].
Bypassing routers for inter LIS multicast requires coordination of
multiple MARSs along with propagation of join and leave messages to
all MARS clients [2] which can congest the network.
However, in case of IP multicast flow distribution over ATM cloud
the "cut through" functionality - bypassing routers - is highly
desired. The cut through will help to achieve better performance in
terms of join/leave latency and also provides more flexibility in
selecting different QoS levels based on receiver's preferences
(section 4).
The evolving IP Multicast over ATM solution (the `MARS model' [1])
retains the Classical IP over ATM model and treats LIS as a `MARS
Cluster'. Clusters are interconnected by conventional IP Multicast
routers (Mrouters). An attempt to achieve LIS boundary cut-through,
keeping at the same time the Classical IP over ATM model for both
unicast and multicast communications, has been undertaken in the
VENUS model [2].
In case of MARS routers between LISs make IP multicast over ATM
inefficient. Each Mrouter views the designated LIS as a totally
disjoint subnet, i.e. as if this LIS has no other ways to internetwork
with other LISs. In fact, LISs are fully interconnected (via ATM) when
they share the same cloud.
In case of unicast the overhead of going to the neighbour
Smirnov [Page 2]
^L
Internet Draft <draft-smirnov-ion-earth-01.txt> November, 20, 1996
(in ATM sense) workstation which, however, belongs to another
IP subnet, via the path <sender, Rtr[, Rtr [, ...], receiver> instead
of <sender, switch, receiver> could be conditionally considered not
so high.
But it's clear that in case of multicast this overhead is much higher,
because the IDMR protocols are involved. The IDMR protocols (such as
DVMRP, MOSPF, PIM, etc.) try to establish an efficient multicast
distribution tree (MCT). The MCT efficiency is the basic feature of
multicast technology (i.e. saving network resources via replicating IP
datagrams only at splitting points of the MCT). Hence, to be efficient,
the MCT has to have minimal number of splitting points. In case of MARS
over multiple LISs the number of overhead splitting points is at least
N-1, where N is the number of LISs which have participants of the
multicast group. In EARTH proposal these N-1 overhead splitting points
are eliminated.
The [2] ends with a conclusion that the approach is
too complex to bring reasonable benefits. Instead, "developing
solutions for large clusters using a distributed MARS, and single
clusters spanning multiple Logical IP Subnets, is a much better
focus for ION's work" [2].
This document describes such a solution, which is dabbed `EARTH -
EAsy IP multicast Routing THrough ATM clouds'. The EARTH has
following components described below in a more detailed way:
- Multicast Logical IP Subnet (MLIS) `spanning' the whole physical
ATM network;
- EARTH server providing IP Class D address resolution to ATM
hardware addresses;
- support for a [limited] number of QoS levels for various receivers
of the multicast flow;
- support for IDMR protocols in case of crossings of IP:ATM
boundary.
The scope of this document is an `ATM cloud' - a nickname for
physically connected private ATM network with a uniform management
and signalling throughout the cloud. The hosts are ATM endpoints
with IP addresses. The ATM interworking with other IP networks is
provided by a [set of] egress IP router[s] supporting IP multicast.
Each egress IP router is an ATM endpoint of the ATM cloud and has a
management assignment to operate as a designated Mrouter for a [set
of] particular LISs of the ATM cloud.ATM cloud is supposed to be
able to support point-to-multipoint connections controlled by the
root endpoint via signalling.
The Classical IP over ATM retains because EARTH makes no changes to
IP unicast over ATM. Therefore EARTH implementation will not disturb
any on-going operation of Classical LISs over the ATM cloud.
2. Multicast Logical IP Subnet
Throughout this document a Logical IP Subnet which conforms to [4]
Smirnov [Page 3]
^L
Internet Draft <draft-smirnov-ion-earth-01.txt> November, 20, 1996
will be called Classical LIS. Multicast LIS is a single LIS per a
physical ATM network which normally has no other traffic except IP
multicast ARP traffic (queries, replies). (Note: RSVP over ATM can also
consider the MLIS as a media for RESV and PATH messages, and an
extension of EARTH as an entity to merge reservations within the ATM
cloud). MLIS is shared by all Classical LISs in cases
of IP multicast flow distribution with the use of point-to-
multipoint ATM connections. The MLIS concept implies that each
endpoint should be configured with an IP address for the MLIS. MLIS
could be configured as a private IP network because its scope is
address resolution over a single ATM cloud.
Note that IP multicast over ATM with the use of mesh of point-to-
point connections is still possible with this proposal and does not
affect MLIS or EARTH server operation. However, this proposal
recognizes that the mesh could be a feasible solution for a
multicast within one LIS and a `small' multicast group size.
Historically, IP multicast was enabled with the utilisation of IP
address space separation. Multicast addresses are borrowed from the
previously reserved Class D address space [5,6]. During a multicast
session each participating receiver has at least two IP addresses: one,
permanent, for regular unicast communication, and, second,
temporary, for a multicast communication. However, in this situation
a receiver is not considered to be a multihomed host because all its
multicast communications are controlled/enabled by a multicast
router (Mrouter) designated for a particular subnet. (This could be
called `indirect multihoming'.) Mrouter runs IGMP to make forwarding
decision for a particular multicast flow to the [broadcast] subnet
and also runs IDMR protocols with other Mrouters for a global
distribution of the multicast flow. This architecture fails in case
of NBMA subnets at the `bottom' of multicast distribution tree.
The EARTH solution proposes `direct multihoming' as an option to
enable IP multicast over ATM. (Note, that proposed multihoming above
refers only to the interaction of endpoints with the EARTH server.)
In EARTH scenario during a multicast session each participating
receiver has at least three IP addresses: one, permanent, for
regular unicast communication, second, temporary, Class D, for a
multicast communication, and third, private, - for IP multicast
address resolution. Unicast IP address is resolved to ATM address,
as usual, with the use of Classical ATM ARP. Multicast IP address is
resolved to a set of ATM addresses with the use of MLIS. The EARTH
scenario implies two options of host extensions.
The first host option requires that each ATM endpoint should be
configured to work with one additional LIS - MLIS, and supplied with
the ATM address of EARTH server (see section 3). That is, the EARTH
server could be seen as the ATM ARP server for MLIS (with two notes:
MLIS is shared by all endpoints from all Classical LISs, and ATM ARP
considers here only IP Class D addresses).
The second host extension option requires that ATM adapter driver
Smirnov [Page 4]
^L
Internet Draft <draft-smirnov-ion-earth-01.txt> November, 20, 1996
should be able to distinguish between unicast and multicast
addresses. If it needs to resolve the unicast IP address it should
contact the regular ATM ARP server; in case of multicast it should
contact the EARTH server.
The MLIS scenario makes some assumptions about Mrouters, being
directly connected to the ATM cloud. Each Mrouter is supposed to
know the ATM address of the EARTH server. Each Mrouter has to be
able to distinguish between unicast LISs, i.e. to know which LIS[s]
it is designated for. That is, if the first sender to a multicast
group belongs to, say, LIS_1, and Mrouter Rtr_A is the designated
Mrouter for LIS_1, then Rtr_A is the only gateway for the multicast
flow to go out of the ATM cloud, and, therefore, to get in. More
details could be found in Section 5.
3. EARTH server behaviour
The EARTH server makes IP Class D to ATM addresses resolution of
those ATM endpoints which have registered with the EARTH server for
a particular multicast session as receivers. The information
exchange follows the principles of ARP found in [7], applied for
NBMA.
A potential receiver of IP multicast flow, whatever unicast LIS it
is located, sends its registration message to the EARTH server.The
message contains receiver's ATM address, receiver's IP address (i.e. the
address from the Classical LIS),
receiver LIS's subnet mask, target multicast address, and,
optionally, a QoS level at which the receiver wants to have this
multicast flow.
The EARTH server keeps these membership information in a multicast
address resolution table (MART) in a form of a list (member_list) of
following entries:
member_list_entry: = <ATM_address, IP_address, subnet_mask,
[QoS_level]>.
Member_list is a heap of member_list_entry elements. One member_list
is per each active IP multicast address. Activity of IP multicast
address is defined by the EARTH server with appropriate ageing
functionality. The ageing decision for a particular member_list
depends on communication lifetime between the EARTH server and both
senders and receivers. One member_list_entry is kept for each member
of the multicast group.
Following IP multicast model, a sender to the group needs not to be
a member of the group. However, the EARTH server treats egress
Mrouter, being current [re]sender, as potential receiver for the
next sender to the same group (Section 5 provides this algorithm).
In a connection-oriented ATM cloud new senders to an active IP
Smirnov [Page 5]
^L
Internet Draft <draft-smirnov-ion-earth-01.txt> November, 20, 1996
address will need to establish their own point-to-multipoint
connection to the group members. Note: Phase 1 of UNI 3.1.
specification supports only zero return - from Leaves to Root -
bandwidth [8, p. 154].
A sender to the multicast group queries the EARTH server
periodically to get the membership information and to use it for its
point-to-multipoint connection management.The member_list is sent
by the EARTH server back to the querying endpoint (sender or
Mrouter) as the answer to its EARTH request. An endpoint - sender is
supposed to keep its local cache of the member_list for comparison
and deriving needed changes to the connection.
A case of multiple senders to the same group in EARTH scenario
should be protected from chaotic crossings of the ATM cloud's
boundary. Suppose each sender to the same group will use that
Mrouter which is a designated Mrouter for the sender's LIS to
advertise/forward its traffic to receivers outside of the ATM cloud.
In case of multiple egress Mrouters this will confuse the IDMR
protocols and disbalance the multicast distribution tree. For needed
protection EARTH server implements a single gateway principle (see
section 5).
It should be mentioned that the EARTH server has absolutely passive
behaviour: it simply keeps the registration information and answers
queries. Conceptually, with regard to IGMP, the EARTH server
represents a broadcast media collapsed to the size of a single
point. When, and if, the size of the ATM cloud will require
replications of this point, then, the anycast capability (to contact
this distributed EARTH service) could be employed.
4. Support for various QoS levels
The EARTH server optionally can provide a sender to a multicast
group with a classified membership information. The member_list
could be partitioned into several subgroups reflecting receivers'
preferences of the QoS levels. These QoS levels should be negotiated
with the ATM network administration and should be known to all
potential receivers. The classified member list (member_list_qos) is
a collection of member_lists with equal QoS levels.
It is assumed that each QoS level is supported with a separate
point-to-multipoint connection (ptm_qs); each ptm_qs starts at the
switch under the control provided by sender via signalling.
Upon receiving a member_list_qos a sender updates/creates each
ptm_qs separately, if needed.
As a future research direction a combined implementation of EARTH
and RSVP "reservations merging" entity could be considered.
Smirnov [Page 6]
^L
Internet Draft <draft-smirnov-ion-earth-01.txt> November, 20, 1996
5. Support for IDMR in case of cut through
The EARTH proposal tries to protect IDMR protocols outside the scope
of the ATM cloud from being confused by multiple entry/exit points
at the boundary of the ATM cloud for the same IP multicast group.
This protection is via a single gateway principle implementation.
From a Mrouter's viewpoint the single gateway keeps the whole ATM
cloud as a single subnet, whatever number of LISs it has. However,
this is only true for a single IP multicast group, not for a
collection of multicast groups - each group can have various
gateways. Note, that for unicast communications the Classical IP
over ATM still apply, with partitioning of endpoints to a number of
LISs and with a set of routers designated to these LISs.
A `Single Gateway' principle says that the ATM cloud, whatever LISs
and routers it has, should have a single gateway (router) forwarding
IP multicast packets to and from the ATM cloud for each multicast
session. Suggested implementation is as follows. The single gateway
router is determined either by its designation to the LIS where the
multicast flow first originated or by the fact of forwarding first
multicast flow to the ATM cloud.
For both cases above the `first' denotes that the single gateway
Mrouter is determined by the first sender to the active IP multicast
group. These cases distinguish between the inside-out and outside-in
propagations of the multicast traffic with regard to the ATM cloud
boundaries. The first case uses internal partition of the ATM cloud
into LISs with designated Mrouters. The second case treats the ATM
cloud as a single subnet (without distinctions between LISs).
For example, let us consider an IP multicast session over the ATM
cloud with 4 LISs numbered 1 through 4 and 3 Mrouters - A, B, C -
designated, correspondingly, Rtr_A to LIS_1 and LIS_3, Rtr_B to
LIS_2 and Rtr_C to LIS_4. If the first sender to a group is external
and its flow reaches the ATM cloud via Rtr_B then Rtr_B will retain
the single gateway for the lifetime of the session (depending on the
ageing decision of the EARTH server). If the first sender to a group
is internal with regard to the ATM cloud and comes from LIS_3, then
Rtr_A will retain the gateway for the lifetime of the session, even
if other endpoints will start sending to the group later from LIS_2
or LIS_4.
The paragraph above has two cases (the 1st sender could be
a/.external, then single gateway is defined by the Rtr which was first
to forward the flow to the cloud; and b/. internal - the rest of the
paragraph. If the 1st sender was internal, its LIS defines the gateway.
If now a new sender to the group arrives from outside the cloud and its
traffic will try to go inside the cloud via another Mrouter then this
another Mrouter will contact the EARTH server and will see in the EARTH
reply that the gateway is already defined. This another Mrouter will
have to forward its traffic to this defined gateway.
Smirnov [Page 7]
^L
Internet Draft <draft-smirnov-ion-earth-01.txt> November, 20, 1996
How this information is kept by EARTH server?
According to section 3 the EARTH server is queried by senders
periodically to get updates about the group membership. We require
that EARTH:
- [quasi] permanently keeps a list of ATM addresses of all egress
routers to the ATM cloud and their designation to LISs
(egress_list);
- temporarily keeps ATM address of the current gateway (gateway_atm)
for a particular multicast group (for the session's lifetime),
gateway_atm is linked to a member_list;
- gets sender's ATM address (query_atm) from the query.
Session's lifetime is defined by EARTH with the use of ageing
functionality. After the group membership is dismissed the
gateway_atm is zeroed.
When the first query arrives for a particular group (i.e.
gateway_atm is equal to zero), EARTH compares the query_atm with
the content of egress_list, and, if finds the coincidence (that is
the first sender to the group is one of the egress Mrouters), it
stores this egress router's ATM address in the gateway_atm linked to
the member_list and replies with the current member_list, else (that
is the first sender is a host) automatically adds to the member_list
the ATM address of the egress router designated for the sender's
LIS, stores this router's address in the gateway_atm and replies
with the modified member_list.
With the arrival of any next query for this group the EARTH server
compares query_atm with the content of the gateway_atm. If the
result is positive (i.e., the current query is the refresh query
from the first sender) then the server replies with the current
member_list and makes no changes to it. Otherwise (i.e. it's a query
from a new sender) the server compares query_atm with the content of
egress_list and, if finds coincidence (i.e. a new sender is also an
Mrouter) then replies with the gateway_atm (readdressing external
flow to the group to existing gateway), else (a new sender is
internal endpoint) replies to this new sender with a modified
member_list: it adds the gateway_atm to the member_list.
Example.
CASE1: let us assume that the 1st sender was external:
member_list = {1,2,3,4}; /*list of receivers*/
egress_list = {10,20,30,40} /*list of Mrouters*/
gateway_atm=10 /*sender is Rtr 10*/
/* now arrives a new query */
if query_atm=gateway_atm /*positive result*/
then earth_reply={1,2,3,4}
else if {query_atm in egress_list} /*new sender is external*/
then earth_redirect_reply={10} /*it's redirect type of reply*/
else earth_reply={1,2,3,4,10} /*new sender will have the */
/*gateway in its pt-to-mpt */
Smirnov [Page 8]
^L
Internet Draft <draft-smirnov-ion-earth-01.txt> November, 20, 1996
CASE2: let us assume that the 1st sender was internal
member_list = {1,2,3,4}; /*list of receivers*/
egress_list = {10,20,30,40} /*list of Mrouters*/
gateway_atm=10 /*sender is, say, 5 and */
/* Rtr 10 is the designated*/
/*Mrouter for sender's LIS*/
/* now arrives a new query */
if query_atm=gateway_atm /*positive result*/
/* in this case it could not be positive: new sender is a host*/
then earth_reply={1,2,3,4}
else if {query_atm in egress_list} /*new sender is external*/
then earth_redirect_reply={10} /*it's another type of reply*/
/*it's also is false for the CASE2: query_atm is ATM address of host*/
else earth_reply={1,2,3,4,10} /*new sender will have the */
/*gateway in its pt-to-mpt */
When a host - new sender to the group - receives this list it opens
its own pt-to-mpt connection to the group, i.e. to hosts 1,2,3,4 and
to the Rtr 10 (for possible external members). Important is that Rtr 10
will be used in both cases: when new sender, say, 6 belongs to the same
LIS as old sender (5), and, when 6 belongs to another LIS. That is
Rtr 10 is retained as a single gateway.
This example is provided to show that in both cases above the algorithm
is the same.
Comment: the term `sender' elsewhere in the document should be
treated as a `sender or potential sender'; if the Mrouter's query
results in a zero member_list then no forwarding of the flow takes
place.
6. Applicability Notes (Future Research)
Simulation study of EARTH performance gives promising results - about
one order lower latency than MARS in case of a single LIS and less than
30% of the ATM switch's call establishment capacity (100 calls/sec for
ASX 200).
Though, a number of open issues requires future research. For
example, the case of ptm_qs including egress Mrouter, interworking
with public ATM networks, use of IP switches, influences of IDMR
protocols and RSVP should be studied more carefully.
7. Scalability
In large physical ATM network a single EARTH server could become a
bottleneck. In case of ATM Forum UNI 4.0 implementation this problem
could be readdressed to the ILMI which is supposed to support group
ATM addresses. That is, EARTH server may resolve IP multicast
address to ATM group address while changes to the group within the
ATM network will be managed by ILMI.
Smirnov [Page 9]
^L
Internet Draft <draft-smirnov-ion-earth-01.txt> November, 20, 1996
Currently two other solutions could be proposed for future research:
server synchronisation and server hierarchy.
This draft does not touch the option of several EARTH servers sharing
the ARP load for the ATM cloud - in this case an EARTH client has to
know an anycast address of a distributed EARTH service and doesn't know
which particular server it contacts. Clearly, this requires some
synchronisation protocol like SSCP. However, with the single gateway per
multicast group each EARTH server will forward all registration
information to that particular EARTH server which, so to say, holds the
single gateway. Roughly speaking, multiple EARTH servers will exchange
a very limited amount of information: maybe only triplets like:
<earth_atm; gateway_atm; multicast_group>,
if the group exists, for each multicast group. Based on this information
('I-am-a-holder' message could be broadcasted to all EARTH servers),
each server filters endpoint's
registrations and sender's queries in order to forward them to the
EARTH - server, holder of the gateway.
9. Security Considerations
This document raises no security issues. However, a single gateway
principle could be helpful in controlling access to the ATM cloud.
8. Acknowledgements
Acknowledgements to ion (ipatm) mailing list.
11. References
[1] Armitage, G., Support for Multicast over UNI 3.0/3.1 based ATM
Networks, RFC 2022, November, 1996
[2] Armitage, G., VENUS - Very Extensive Non-Unicast Service,
Internet-Draft <draft-armitage-ion-venus-00.txt>, July, 1996
[3] Cole, R.G., Shur, D.H., Villamizar, C. IP over ATM: A Framework
Document Internet-Draft <draft-ietf-ipatm-framework-doc-06>,
October, 1995
[4] Laubach, M., Classical IP and ARP over ATM, Network Working
Group, Request for Comments: 1577, Category: Standards Track,
January, 1994
[5] Deering, S., Host Extensions for IP Multicasting, IETF, RFC
1112, August, 1989
[6] Deering, S., "Multicast Routing in a Datagram Internetwork",
Ph.D. Thesis, Stanford University, December, 1991.
Smirnov [Page 10]
^L
Internet Draft <draft-smirnov-ion-earth-01.txt> November, 20, 1996
[7] Postel, J., and J. Reynolds, "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, USC/
Information Sciences Institute, February 1988.
[8] ATM User-Network Interface Specification, The ATM Forum, v.3.1,
September, 1994
12. Author's Address
Michael Smirnov
GMD FOKUS
Hardenbergplatz 2, Berlin 10623
Phone: +49 30 25499113
Fax: +49 30 25499202
EMail: smirnow@fokus.gmd.de
Smirnov [Page 10]
^L
Internet Draft <draft-smirnov-ion-earth-01.txt> November, 20, 1996