Internet-Draft Grenville Armitage Bellcore April 21st, 1995 Issues surrounding a new encapsulation for IP over ATM. 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]