Internet-Draft Grenville Armitage Bellcore May 1st, 1995 Using the MARS to support IP Unicast over ATM 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 - ). 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]