Internet DRAFT - draft-ietf-ipatm-encaps
draft-ietf-ipatm-encaps
Internet-Draft Grenville Armitage
Bellcore
April 21st, 1995
Issues surrounding a new encapsulation for IP over ATM.
<draft-ietf-ipatm-encaps-00.txt>
Status of this Memo
[This is purely an informational I-D, to capture the current state of
a somewhat thorny issue and focus further comment.]
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
The Internet Draft draft-ietf-ipatm-ipmc-04.txt ("Support for
Multicast over UNI 3.1 based ATM Networks") describes a mechanism for
handling IP multicast over ATM. In doing so it notes two different
mechanisms for actually achieving the multicasting of packet traffic
at the ATM level. These are meshes of point to multipoint VCs, or ATM
level multicast servers.
Recent developments in the IP-ATM working group have revealed a
Armitage Expires October 21st, 1995 [Page 1]
Internet Draft April 21st, 1995
likely inability of IP multicast routers to cope with packets
reflected back when transmitting to groups supported by ATM level
multicast servers. This memo describes the issue in greater detail,
and suggests a range of new encapsulation options.
1. Introduction.
The general problem can be summarised as follows:
What can an IP layer or IP multicast forwarding entity do when
faced with an underlying link layer interface that sends back
exact copies of the IP packets transmitted by the local IP entity?
(Furthermore, the underlying interface currently provides no
indication of the packet's link layer source.)
More specifically, current IP over ATM encapsulation does not provide
any per-packet information on the source ATM interface. This has not
been an issue for unicast communication, where the ATM source is
either irrelevant or deduced from the IP source address. However,
certain ATM multicast architectures described in draft-ietf-ipatm-
ipmc-04.txt result in packets being reflected back to their sources.
(The problem arises when a multicast server, rather than a VC mesh,
is used to achieve the multicasting of AAL5 SDUs within a Cluster).
In the case of a directly attached IP source, it can check the IP
source address in every incoming packet to discover if the packet has
actually arrived from a remote IP entity, or is just a reflection
from a multicast server.
The case of the IP multicast forwarding entity currently appears to
have no IP level solution. IP multicast routing algorithms do not
allow any time-invariant associations to be made between unicast IP
source identities and their likely arrival interface at the IP
multicast forwarding entity.
One proposed solution is:
Add functionality to the IP/ATM mechanism so that it _is_ possible
to identify the packets actual source within the Cluster to which
the IP/ATM port is 'attached'.
If an AAL_SDU arrives which can be seen to have been originated by
you, drop it _before_ it gets to the overlying IP stack.
This solution has two parts:
Armitage Expires October 21st, 1995 [Page 2]
Internet Draft April 21st, 1995
- Establishing a mechanism for identifying sources within
multicast Clusters.
and
- Carrying this source identification along with each IP multicast
packet.
Section 2 describes a simple extension of the existing MARS protocol
that will allow management of what I'll term Cluster Member IDs
(CMIs). Section 3 will describe some of our options with respect to
carrying the CMI. Finally, the issue of running two different
encapsulations for IP over ATM is raised.
2. Managing the Cluster Member ID.
Each cluster member is dynamically allocated a 16 bit Cluster Member
ID (CMI) by the MARS when they register as a member of
ClusterControlVC.
(This CMI is included in every IP over ATM packet using the new
encapsulation mechanism.)
The ar$resv field in the MARS_JOIN message (expanded to 32 bits as
one of the corrections in the 04 to 05 transition) is subdivided into
two 16 bit fields. These subfields are ar$cmi (the 16 bit CMI), and
ar$resv (16 bits reserved).
When a host sends a MARS_JOIN the ar$cmi is undefined, and should be
zeroed.
When the MARS receives a MARS_JOIN for "0.0.0.0" it adds the source
to ClusterControlVC, allocates a new CMI, fills in the ar$cmi field
with the new value, then retransmits the MARS_JOIN as currently
defined. (The only new step is allocating and filling the ar$cmi
field).
Host receiving its own MARS_JOIN for "0.0.0.0" back extracts the
ar$cmi field. This CMI is then compared with the CMI in every
incoming IP over ATM AAL_SDU. If a match occurs, the packet is deemed
to be a reflection from a multicast server, and is dropped before it
even reaches the local IP layers receive queue.
When a host issues a MARS_LEAVE for "0.0.0.0" it must fill in the
ar$cmi field with its allocated CMI, which the MARS then uses to
deallocate the CMI value.
Armitage Expires October 21st, 1995 [Page 3]
Internet Draft April 21st, 1995
3. Possible encapsulation options.
The bottom line would seem to suggest we are in for a significant
alteration in IP/ATM encapsulation. Ideally we should build on the
existing LLC/SNAP encapsulation, as this would remove any need to
simulatneously change the signalling requirements currently specified
in RFC 1755. (i.e. VCs would still request termination on an
ISO8802/layer 2 LLC entity).
Option 1:
Perhaps we get a whole OUI allocated for IP over ATM, and use the PID
space for the CMI. This would retain the current 32bit packet
boundary.
Multicast:
[0xAA-AA-03][new OUI][2byte CMI][IP packet]
Unicast:
[0xAA-AA-03][0x00-00-00][0x08-00][IP packet]
Option 2:
Or simply allocate a new Ethertype for IPmc packets which defines a
payload consisting of a 16 bit CMI and 16 bit pad field followed
immediately by an IP packet. This is used to define a new PID and
consequential payload format. The AAL5 PDU is 32 bits longer, but the
IP packet is still 32 bit aligned.
Multicast:
[0xAA-AA-03][0x00-00-00][New PID][2byte CMI][2byte pad][IP packet]
Unicast:
[0xAA-AA-03][0x00-00-00][0x08-00][IP packet]
Option 3:
Or get new OUI and include the existing set of PID/Ethertypes to make
it obvious how we encapsulate AppleTalk, IPX, etc too.
Multicast:
[0xAA-AA-03][New OUI][Ethertype][2byte CMI][2byte pad][IP packet]
The question arises as to which of these schemes is most feasible
from the perspective of obtaining the allocation of new OUI or PID
values.
Armitage Expires October 21st, 1995 [Page 4]
Internet Draft April 21st, 1995
Allocating a new PID under OUI 0x00-00-00 (Option 2) is trivial in
that these PID values are inherited from the set of Ethertypes
maintained by Xerox. Xerox registers new Ethertypes for a nominal
fee, and there is obviously no requirement that we actually use the
Ethertype on an actual Ethernet anywhere in the world.
Allocating a new OUI is potentially more flexible, especially if we
use it as shown in Option 3. Call it the "IETF Multicast" OUI, or
some such thing. How do we do this easily?
Are there other easily allocated code points in the LLC and SNAP
extension hierarchy?
4. Transitioning from the existing encapsulation mechanism.
Unicast IP transmissions can still quite happily use [0xAA-AA-
03][0x00-00-00][0x800] encaps, regardless of whether a given LIS has
hosts/routers in it that have been upgraded for IP multicast. The
upgraded, multicast capable, interfaces would _additionally_ use the
new encaps mechanism (perhaps even over the same VC as the unicast
traffic if we use some subset of LLC/SNAP encaps).
At the receiving ends unicast and multicast IP packets could arrive
over the same VC, be demuxed separately by the ip/atm driver, and
then dropped or passed up to the same ip/atm interface.
In LISs where all hosts/routers have multicast capable IP/ATM
interfaces you could send unicast IP packets using the encaps for
multicast packets, or still retain the existing unicast encaps.
Presumably phasing across to use solely the encapsulation being
defined here for IPmc would be desirable.
(We could phase across to the new encaps even for interfaces that
were not multicast capable by defining CMI = 0 to be the default CMI
for unicast transmissions, and not filtering packets arriving with
CMI = 0).
Acknowledgements
This I-D is a distillation of issues raised during discussions, both
in private and on the IP-ATM mailing list.
Security Consideration
Security consideration are not addressed in this memo.
Armitage Expires October 21st, 1995 [Page 5]
Internet Draft April 21st, 1995
Author's Address
Grenville Armitage
MRE 2P340, 445 South Street
Morristown, NJ, 07960-6438
USA
Email: gja@thumper.bellcore.com
Armitage Expires October 21st, 1995 [Page 6]
