One document matched: draft-armitage-ipatm-mars-unicast-00.txt
Internet-Draft Grenville Armitage
Bellcore
May 1st, 1995
Using the MARS to support IP Unicast over ATM
<draft-armitage-ipatm-mars-unicast-00.txt>
Status of this Memo
This document was submitted to the IETF IP over ATM WG. Publication
of this document does not imply acceptance by the IP over ATM WG of
any ideas expressed within. Comments should be submitted to the ip-
atm@matmos.hpl.hp.com mailing list.
Distribution of this memo is unlimited.
This memo 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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the
"lid-abstracts.txt" listing contained in the Internet-Drafts shadow
directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract.
This memo discusses the relationship between unicast and multicast
service support in the IP over ATM environment, and explores some
implications of noting that unicasting can be considered as a subset
of multicasting. Specifically it is shown how the Multicast Address
Resolution Server (MARS) in draft-ietf-ipatm-ipmc-04.txt might be
used to provide IP unicast address resolution service, acting as a
substitute for an RFC1577 ARP Server. It is also noted that an
RFC1577 ARP Server can be built as a 'front end' to a MARS.
This memo is intended as a companion to the ideas contained in
draft-smith-ipatm-bcast-00.txt, which noted how IP broadcast could be
Armitage Expires November 1st, 1995 [Page 1]
Internet Draft May 1st, 1995
supported by the MARS as a special case of multicast.
1. Introduction.
Unicasting is the process whereby a single source executes a single
transmit operation, and causes a single packet to be delivered to a
single destination. Multicasting involves a single transmit operation
resulting in copies of a single packet being delivered to multiple
(one or more) destinations. The packet copying and distribution is
usually achieved by the underlying packet transport technology in a
manner transparent to the source entity. Applications assume that the
IP layer provides multicast service when the destination addresses
are in the Class D range. The IP layer in turn assumes the underlying
link layer interface performs the necessary actions at the link level
to actually multicast the IP packets it is given.
RFC1577 describes the key parts of the IETF's first solution for
running IP over ATM - the 'Classical IP' model with a central ARP
Server providing address mapping and resolution service for
constrained sets of hosts (constrained into Logial IP Subnets). IP
addresses are mapped to ATM destination addresses with
ARP_REQUEST/REPLY exchanges by hosts wishing to establish a link
level (ATM) path to a desired IP destination. The creation of an {IP
address, ATM address} association within the ARP Server's database is
either through the pre-emptive use of Inverse ARP when a new VC is
established to the ARP Server, or by extracting source information
from each ARP_REQUEST the ARP Server receives.
draft-ietf-ipatm-ipmc-04.txt describes a more general architecture
for supporting IP multicasting. A central server is again established
(known as the Multicast Address Resolution Server) whose key function
is to map IP multicast (Class D) addresses to sets of one or more ATM
addresses. These ATM addresses represent the ATM interfaces of
endpoints wishing to receive traffic being sent to particular
multicast groups. The Host-MARS interaction is a superset of the
Host-ARP Server interaction. MARS_REQUEST is used to pass a Class D
address to the MARS, and one or more MARS_MULTI replies are used to
pass back a non-empty set of ATM address. The creation and
modification of {Multicast address, ATM address.1, ATM address.2,
.... ATM address.N} mappings in the MARS is through the explicit use
of MARS_JOIN and MARS_LEAVE messages by endpoints.
Superficially it might seem these two services are quite distinct.
However, in both cases they are really just databases that create and
track address mappings. The interpretation of the mappings is left up
to the hosts that utilise the services of either the ARP Server or
the MARS. In fact, the MARS does not attempt to parse the {Multicast
Armitage Expires November 1st, 1995 [Page 2]
Internet Draft May 1st, 1995
address} part of each database entry at all - it is simply a variable
length string of up to 255 bytes, whose meaning is understood by the
endpoints in the context of the ar$pro (protocol type) field.
draft-smith-ipatm-bcast-00.txt currently notes how IP broadcast can
be viewed as a special case of multicast, where the set of
destinations is defined as being the entire set of possible
destinations within your 'network' (where the scope of your network
depends on the context). It is also true to say that IP unicast is
the other extreme of multicast - where the 'group' has a membership
of one.
The following section describes how IP unicast over ATM may be
supported using only a MARS and the control messages currently
defined to support IP multicast.
[Some familiarity with the protocols in RFC1577 and draft-ietf-
ipatm-ipmc-04.txt is assumed in the following discussion]
2. Unicast - the multicast group of one.
The Classical IP model assumes that IP hosts are administratively
allocated to Logical IP Subnets (LISs), and that each LIS has a
logically separate (even if physically co-located) ARP Server. Given
the non-existence of auto-configuration support, RFC1577 assumes that
hosts are pre-configured with their unicast IP address and subnet
mask. For the ARP Server to know the {IP address, ATM address}
mappings of the LIS it serves, there must be initial ARP activity
from these hosts (otherwise they would remain invisible to other
hosts in the LIS).
An interesting question is how you might use a MARS compatible IP/ATM
interface driver to establish a similar level of functionality using
just a MARS? One answer would look something like this:
Assume your Classical LIS and MARS Cluster are one and the same
thing.
While booting, every LIS host issues a MARS_JOIN for its own local
IP unicast address. (actually in the form of a block of one -
<local IP unicast, local IP unicast>). The important point here is
that the MARS does not reject the join just because it is not a
Class D address.
When a local IP layer needs to transmit a packet, the IP
destination address is placed in a MARS_REQUEST - regardless of
whether it is Class A, B, C, or D.
Armitage Expires November 1st, 1995 [Page 3]
Internet Draft May 1st, 1995
The MARS_MULTI response is parsed to extract one or more ATM
addresses.
At this point the class of the IP address being queried is
important. If it is Class D, then a point to multipoint VC is
established and managed as per draft-ietf-ipatm-ipmc-04.txt. If it
is Class A, B, or C then a point to point VC is established as per
RFC1577/1755, using the first (presumably _only_) ATM address
returned in the MARS_MULTI reply.
This approach works because the LIS administrator ensures that no two
LIS endpoints will ever MARS_JOIN the same unicast IP address.
Nothing else about the 'Classical IP' behaviour of a hosts needs to
be changed (e.g. idle timers on VCs are still required, etc).
If the concepts in draft-smith-ipatm-bcast-00.txt are used to emulate
IP broadcasts on a MARS based system then one might envision the
following sequence at boot time:
Hosts first register for basic broadcast support with the MARS.
Hosts use standard, broadcast based boot services to establish
their unicast IP identities
Finally hosts register their newly found IP identities with the
MARS as described above.
Some functionality of the MARS may need to re-interpreted or ignored
by endpoints when applied to these single member IP unicast 'groups'.
Two of these are:
If the MARS dies, or a switch from Primary to Secondary MARS
occurs, the endpoint must re-issue the MARS_JOIN for its unicast
IP address.
When group revalidation is triggered through a jump in CSN
(section 10 of ipmc-04), the unicast 'groups' are NOT marked for
revalidation. (The reasoning here is that the continued existence
of the data VC based on that unicast mapping proves its validity.
An alternative would be for revalidation of unicast mappings to be
through issuing Inverse ARP on the associated open data VC.)
3. Keeping unicast mappings up to date.
One example is the requirement for unicast mappings to be revalidated
on a regular basis. In RFC1577 this occurs by having the LIS host to
issue an ARP_REQUEST for its own IP address every 15 minutes (or for
Armitage Expires November 1st, 1995 [Page 4]
Internet Draft May 1st, 1995
the ARP Server to issue an Inverse ARP every 20 minutes if it has a
VC open to the host, but the host has not been heard from). In a
MARS-only environment this would be replaced by a regular MARS_JOIN
from the host every 15 minutes.
The MARS's default behaviour of retransmitting MARS_JOINs on
ClusterControlVC raises an interesting possibility here. LIS hosts
might choose to use incoming MARS_JOINs for unicast IP addresses to
automatically update unicast entries in their ARP caches. This
potentially reduces the need for hosts themselves to initiate regular
revalidation of unicast mappings that they may be using. However,
this phenomenon may not be uniformly observed, as some hosts may
choose not to register as members of ClusterControlVC (one of the
proposed changes between ipmc-04 and ipmc-05 allows endpoints this
option if they believe they'll never be sending on any multicast
groups).
4. Impact of explicit host registration.
The pre-emptive Inverse ARP was initially a reasonable idea for
enabling an ARP Server to explicitly establish the identity of a host
at the end of an incoming VC. However, it has problems in that it is
not particularly suited to a multiprotocol environment (where routers
and ARP Servers share ATM interfaces), and it can suffer from packet
loss when a new VC claims to be established before it really is.
The proposed solution for RFC1577 is to deduce the existence of
certain mappings from the source IP and ATM addresses in each
ARP_REQUEST the ARP Server receives. Whilst this solves the problems
with the pre-emptive Inverse ARP, it adds a peformance hit in that
two searches of the ARP Server's database are required for each
ARP_REQUEST - one to enter/revalidate the source address mapping, and
a second to find the requested target address mapping.
This trade off does not occur with the MARS based approach in section
2, because registration of a source mapping is explicit and separate
from the requests for mapping information.
5. A backwards compatible MARS.
If a MARS-only LIS was being built with mixture of MARS-compatible
hosts, and RFC1577-only hosts, then some form of backward
compatibility is required in the MARS.
It would not be at all difficult for a MARS implementation to include
code to handle ATMARP packets that arrive with ARP_REQUEST in the
Armitage Expires November 1st, 1995 [Page 5]
Internet Draft May 1st, 1995
ar$op field instead of MARS_REQUEST. The ARP_REQUEST would be treated
internally as a MARS_JOIN for the information carried in the source
address fields, and then as a MARS_REQUEST. This is required to
conform to the RFC1577 registration approach of implicitly
revalidating mapping information from incoming ARP_REQUESTs. Note
that the implied MARS_JOIN should NOT result in a real MARS_JOIN
being sent on ClusterControlVC under these circumstances.
Finally, when a mapping has been resolved in response to an
ARP_REQUEST, the result is sent back in an ARP_REPLY rather than a
MARS_MULTI. This will keep the RFC1577-only host interfaces happy.
6. What about Clusters that are bigger than a LIS?
The MARS architecture introduced a new concept of the 'Cluster',
specifically to abstract the scope of multicast support away from the
original unicast concept of LIS. Each MARS serves a single cluster
(or more accurately, the cluster your endpoint is a member of is
determined by the MARS you register with).
The cluster's scope need not be constrained to that of a single LIS.
Indeed, it is possible to have the hosts from multiple Classical LISs
register with the same MARS and all be members of the one cluster. As
a consequence, although inter-LIS unicast traffic would have to
travel through routers, multicast traffic between hosts would use
direct ATM level VCs - cutting through LIS boundaries. Recent
discussion on the Inter-Domain Multicast Routing working group's
email list suggests such a scenario can be coped with by most
protocols such as DVMRP, PIM, MOSPF, etc. The scaling implications
are being worked out in different documents to this one.
However, this raises an interesting implication when using your MARS
for unicast support. When the cluster and LIS boundaries are
identical (as assumed in section 2) there is no problem. On the
surface there is also no problem even if multiple LISs all choose to
use the same MARS, since the unicast addresses will be different
there will be no database entry clashes. Additionally, as the
'Classical IP' model is really a host-side routing discipline there
is no specific MARS_REQUEST handling required of the MARS to 'keep
the LISs separate'.
The possible concern lies with ClusterControlVC, which the MARS
establishes out to every host in the cluster. As noted in section 3
the MARS_JOINs for unicast addresses are retransmitted on
ClusterControlVC, and might be used to help keep enpoint ARP caches
updated. However, if the cluster spans multiple LISs then endpoints
need to be aware that many unicast address mappings carried to them
Armitage Expires November 1st, 1995 [Page 6]
Internet Draft May 1st, 1995
over ClusterControlVC should be ignored and not placed in their local
ARP cache.
Security Consideration
Security consideration are not addressed in this memo.
Author's Address
Grenville Armitage
MRE 2P340, 445 South Street
Morristown, NJ, 07960
USA
Email: gja@thumper.bellcore.com
Armitage Expires November 1st, 1995 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 17:31:32 |