Internet-Draft Grenville Armitage Bellcore October 3rd, 1994 IP Multicast over UNI 3.0 based ATM Networks. 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". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This memo describes extensions to RFC1577 (Classical IP over ATM) and RFC1112 (Host Extensions for IP Multicasting) to allow present generation IP multicasting on ATM networks that support Version 3.0 of the ATM Forum's UNI signalling specification. 1. Overview RFC 1112 [1] introduces the concept of IP multicasting and defines the required behaviour of hosts desiring to send to, or receive from, IP multicast groups. The example link layer technology given in that RFC is Ethernet, a technology that directly supports multicasting. ATM is a new link layer technology being utilised to support IP Armitage Expires March 6th, 1995 [Page 1] Internet Draft October 3rd, 1994 subnets. RFC 1483 [2] defines a mechanism for encapsulating and transmitting IP packets using AAL5 over ATM Virtual Channels (VCs). RFC 1577 [3] defines the basic 'Classical' model of IP subnets mapped to restricted groups of ATM-connected nodes - the Logical IP Subnet (LIS). The currently published signalling specification from the ATM Forum is Version 3.0 [4] (UNI 3.0). In addition to the Bidirectional Unicast VCs used to provide the basic Classical model, UNI 3.0 also provides support for Unidirectional, Point to Multipoint VCs. This memo will describe how IP multicasting within a LIS may be achieved using meshes of UNI 3.0 point to multipoint VCs. It will also describe how IP multicast routers may extend IP multicast beyond the LIS. The ARP Server's role in the LIS is extended to keep track of IP multicast groups that are active within the LIS. New ATMARP message types are proposed, to support the distribution of IP group membership information. A multicast-server architecture is used to distribute the new ATMARP messages within the LIS. Each multicast host establishes a VC to the ARP Server, and the ARP Server establishes a multicast VC back to all multicast hosts in the LIS. This memo assumes an understanding of concepts explained in greater detail in RFC 1112, RFC 1577, UNI 3.0, and . 2. Review of RFC 1112 and IP Multicast over Ethernet. In RFC 1112 the behaviour of the transmit and receive sides are quite independent. This makes the concept of being a 'member' of an IP multicast group imprecise at the link layer interface. The interface must support the transmission of IP packets to an IP multicast group address, whether or not the node considers itself a 'member' of that group. Consequently, group membership is effectively irrelevant to the transmit side of the link layer interfaces. No address resolution is required to transmit packets - an algorithmic mapping from IP multicast address to Ethernet multicast address is performed locally before the packet is sent out the local interface in the same 'send and forget' manner as a unicast IP packet. Joining and Leaving an IP multicast group is more explicit on the receive side - with the primitives JoinLocalGroup and LeaveLocalGroup affecting what groups the local link layer interface should accept packets from. When the IP layer wants to receive packets from a group, it issues JoinLocalGroup. When it no longer wants to receive Armitage Expires March 6th, 1995 [Page 2] Internet Draft October 3rd, 1994 packets, it issues LeaveLocalGroup. The role of IGMP in RFC 1112 is to support IP multicast routers attached to a given subnet. Hosts issue IGMP Report messages when they perform a JoinLocalGroup, or in response to an IP multicast router sending an IGMP Query. The sole function is to allow routers to identify what IP multicast groups have non-zero membership on the subnet. A specific IP multicast address, 224.0.0.1, is allocated for the transmission of IGMP Query messages. All IP multicast hosts must issue JoinLocalGroup for 224.0.0.1 during their initialisation. Each host keeps a list of IP multicast groups it has been JoinLocalGroup'd to. When a router issues an IGMP Query on 224.0.0.1 each host begins to send IGMP Reports for each group it is a member of. IGMP Reports are sent to the group address, not 224.0.0.1, "so that other members of the same group on the same network can overhear the Report" and not bother sending one of their own. Under RFC 1112 multicast IP routers are expected to passively receive packets on all groups. IP multicast routers conclude that a group no longer has members on the subnet when IGMP Queries no longer elict replies for a group. 3. Model of an IP over ATM endpoint. LLC/SNAP encapsulated IP packets are the default specified by RFC 1577. This model implies that IP over ATM endpoints should be viewed as having LLC entities terminating VCs on behalf of higher layer protocols (e.g. IP or ARP). The LLC entity encapsulates/multiplexes outgoing packets according to RFC 1483, and demultiplexes incoming packets. It is a client of the endpoint's AAL and UNI 3.0 signalling services. Only VCs directed at ISO 8802/2 Layer 2 endpoints are terminated on the LLC entity. Armitage Expires March 6th, 1995 [Page 3] Internet Draft October 3rd, 1994 ipatm0 | | --------- | arp | | | .............................. . This draft's functionality . .............................. | | | IP.1 IP.2 | | | | +++++.......+++++........+++++ ---- LLC +L.1+ +L.2+ +L.3+ ====>| U | +++++.......+++++........+++++ | N | AAL to AAL-User | | | | I | interface VC.1 VC.2 VC.3 | | | | | | 3 | +++++.......+++++........+++++ | . | AAL +A5 + +A5 + +A5 + <====| 0 | +++++.......+++++........+++++ ---- | | | --------- | --------- \ | / atm Figure 1. A unicast host's IP interface may have multiple VCs open to different destinations. Each VC is mapped through separate instances of the LLC layer and AAL5 service. Figure 1 attempts to show this relationship, where IP.{1,2} are the IP addresses of destinations that the local interface is connected to through VC.{1,2}. In a unicast-only LIS these IP addresses map to a single endpoint, and the VCs allow bidirectional flow of IP packets. The ARP entity is also shown in Figure 1, with a VC to the ARP Server for the LIS. This VC is not associated with an IP address, although the ARP client exists within and below the IP layer. The goal of this memo is to add multicast support to the model shown in Figure 1 that closely resembles the spirit of RFC 1112. References to 'transmit' and 'receive' sides refer to sections of the LLC and IP interface that handle outgoing and incoming packets respectively. In the abscence of explicit text to the contrary a few key phrases are used in the following manner within this document: "...the ARP Server..." This refers to the actual ARP entity that acts as a centralised cache of address mappings for an RFC 1577 LIS. This entity is a Armitage Expires March 6th, 1995 [Page 4] Internet Draft October 3rd, 1994 local client of the LLC entity on an arbitrary node addressable at the ATM level by members of the LIS. The node supporting the ARP Server entity may or may not have a co-resident entities supporting IP or other protocols. "...a VC to the ARP Server..." This actually denotes a VC established to the LLC entity of the node on which the ARP Server entity exists. As the default is to establish VCs to carry LLC/SNAP encapsulated traffic, the VC may then carry packets of a range of protocols. 4. Multicast VCs under UNI 3.0. This memo will describe its operation in terms of 'generic' functions that should be available to clients of a UNI 3.0 signalling entity in a given ATM endpoint. The most fundamental limitations of UNI 3.0's multicast support are: Only point to multipoint, unidirectional VCs may be established. Only the root node of a given VC may add or remove leaf nodes. Within these constraints, multicast group members can communicate by the use of full meshes, or a Multicast Server. With a mesh each transmitting host is the Root of an ATM multicast tree that has every other host in the group as a Leaf. The Multicast Server model has every group member establish a point to point VC to the Server. The Server then receives packets from members and retransmits copies to all other members. This memo utilises both models. All IP multicast groups are supported by meshes of point to multipoint VCs. For LIS members that register as multicast IP hosts the ARP Server behaves as a 'multicast server' for ARP traffic, in addition to its conventional use of unicast VCs in accordance with RFC1577. The following generic signalling functions are presumed to be available to AAL Users: [mneumonics TBD] L_CALL_RQ - Establish a unicast VC to a specific endpoint. L_MULTI_RQ - Establish multicast VC to a specific endpoint. L_MULTI_ADD - Add new leaf node to previously established VC. L_MULTI_DROP - Remove specific leaf node from established VC. L_RELEASE - Release unicast VC, or all Leaves of a multicast VC. Armitage Expires March 6th, 1995 [Page 5] Internet Draft October 3rd, 1994 The UNI 3.0 signalling exchanges that occur as a consequence of these functions are described in Appendix A. The local information passed between AAL User and UNI 3.0 signalling entity with these functions is currently beyond the scope of this memo. The following indications are assumed to be available to AAL Users, generated by by the local UNI 3.0 signalling entity: L_ACK - Succesful completion of a request to signalling entity. L_REMOTE_CALL - A new VC has been established to the AAL User. ERR_L_RQFAILED - A remote ATM endpoint rejected an L_CALL_RQ, L_MULTI_RQ, or L_MULTI_ADD. ERR_L_RELEASE - A remote ATM endpoint has elected to terminate a pre-existing VC. The UNI 3.0 signalling exchanges that occur to cause these indications are described in Appendix A. The local information passed between UNI 3.0 signalling entity and AAL User by these indications is currently beyond the scope of this memo. UNI 3.0 defines two ATM address formats - E.164 and ISO NSAP. UNI 3.0 defines an 'ATM Number' to identify an ATM endpoint using either format. Some public networks may only understand E.164 formatted addresses, so the ISO NSAP formatted address is included as an additional 'ATM Subaddress'. For the rest of this memo the term 'ATM Address' will be used to mean either a single 'ATM Number' or an 'ATM Number' combined with an 'ATM Subaddress'. 5. Transmitting IP packets to Multicast groups. The IP layer must be able to send a packet to an IP multicast group at any time, without prior warning. This implies a mechanism for keeping track of group membership (because unlike Ethernet multicast the ATM source must 'know' its destinations before a VC can be established for transmissions). The RFC 1577 ARP Server is an ideal candidate for extension to provide this mechanism. It keeps a table of {IP,ATM} address pairs for all IP endpoints in the LIS (hosts, or routers with other interfaces outside the LIS). It can either be configured with certain table entries, or 'learn' entries from the ARPing activity of hosts on the LIS. The extension for multicast is as follows: Table entries for Class D IP addresses MUST contain space for 1 or Armitage Expires March 6th, 1995 [Page 6] Internet Draft October 3rd, 1994 more ATM addresses, i.e. {IP, ATM.1, ATM.2, .... ATM.n} A new ARP message type is added - ARP_MULTI. This is based on ARP_REPLY but includes new fields to allow one or more ATM addresses to be returned in a single reply. The ARP_MULTI message MUST be sent back to the requesting host on a previously established unicast VC between the host and the ARP Server. 5.1 Retrieving Group Membership from the ARP Server. When a host is required to transmit a packet to a Class D address it issues an ARP_REQUEST to the ARP Server in exactly the same manner as for a unicast packet. If the ARP Server had no mapping for the desired Class D address an ARP_NAK will be returned. In this case the IP packet MUST be discarded silently. If a match is found in the ARP Server's tables it proceeds to return addresses ATM.1 through ATM.n in a sequence of one or more ARP_MULTIs. A simplistic mechanism is used to detect and recover from loss of ARP_MULTI messages. Each ARP_MULTI carries a new boolean field x, and a 15 bit integer field y - expressed as ARP_MULTI(x,y). Field y acts as a sequence number, starting at 1 and incrementing for each ARP_MULTI sent. Field x acts as an 'end of reply' marker. When x == 1 the ARP procedure is considered complete. In addition, each ARP_MULTI may carry multiple ATM addresses from the set {ATM.1, ATM.2, .... ATM.n}. An ARP Server MUST minimise the number of ARP_MULTIs transmitted by placing as many group member's addresses in a single ARP_MULTI as possible. The limit on ARP_MULTI message length MUST be the MTU of the underlying VC. Assume n ATM addresses must be returned, each ARP_MULTI is limited to only p ATM addresses, and p << n. This would require a sequence of k ARP_MULTI messages (where k = (n/p)+1, using integer arithmetic), transmitted as follows: ARP_MULTI(0,1) carries back {ATM.1 ... ATM.p} ARP_MULTI(0,2) carries back {ATM.(p+1) ... ATM.(2p)} [.......] ARP_MULTI(1,k) carries back { ... ATM.n} If k == 1 then only ARP_MULTI(1,1) is sent. Typical failure mode will be losing one or more of ARP_MULTI(0,1) Armitage Expires March 6th, 1995 [Page 7] Internet Draft October 3rd, 1994 through ARP_MULTI(0,k-1). This is detected when y jumps by more than one between consecutive ARP_MULTI's. An alternative failure mode is losing ARP_MULTI(1,k). A timer MUST be implemented to flag the failure of the last ARP_MULTI to arrive. [timer value TBD]. If a 'sequence jump' is detected, the host MUST wait for the ARP_MULTI(1,k), discard all results, and repeat the ARP REQUEST. If a timeout occurs, the host MUST discard all results, and repeat the ARP_REQUEST. Where n < p, k = 1, only one ARP_MULTI is ever sent in response to an ARP_REQUEST. This removes the possibility of cell loss causing undetected loss of a group member's address. 5.2 Format of the ARP_MULTI message. The ATM ARP_MULTI message is based on the ARP_REPLY message, indicated by an 'operation type value' of 11 (decimal). The message format is: Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$shtl 8 bits Type & length of source ATM number (q) ar$sstl 8 bits Type & length of source ATM subaddress (r) ar$op 16 bits Operation code (request, reply, or NAK) ar$spln 8 bits Length of source protocol address (s) ar$thtl 8 bits Type & length of target ATM number (x) ar$tstl 8 bits Type & length of target ATM subaddress (y) ar$tpln 8 bits Length of target protocol address (z) ar$tnum 16 bits Number of target ATM addresses returned (N). ar$seqxy 16 bits Boolean flag x and sequence number y. ar$assn 32 bits ARP Server Sequence Number. ar$sha qoctets source ATM number ar$ssa roctets source ATM subaddress ar$spa soctets source protocol address ar$tha.1 xoctets target ATM number 1 ar$tsa.1 yoctets target ATM subaddress 1 ar$tpa zoctets target protocol address ar$tha.2 xoctets target ATM number 2 ar$tsa.2 yoctets target ATM subaddress 2 [.......] ar$tha.N xoctets target ATM number N ar$tsa.N yoctets target ATM subaddress N ar$seqxy is coded with flag x in the leading bit, and sequence number y coded as an unsigned integer in the remaining 15 bits. Armitage Expires March 6th, 1995 [Page 8] Internet Draft October 3rd, 1994 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x| y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ar$tnum is an unsigned integer indicating how many pairs of {ar$tha,ar$tsa} (i.e. how many group member's ATM addresses) are present in the message. Section 6.6 of RFC 1577 should be consulted for specific details and coding of all other fields. ar$assn is an unsigned 32 bit number filled in by the ARP Server before transmitting each ARP_MULTI. Its use is described further in section 10. As an example, assume we have a LIS using 4 byte protocol addresses, 20 byte ATM numbers, and 0 byte ATM subaddresses. For n group members in a single ARP_MULTI we require a (44 + 20n) byte message. If we assume the default MTU of 9180 bytes, we can return a maximum of 456 group member's addresses in a single ARP_MULTI. 5.3 Establishing the Multicast VC. An L_MULTI_RQ is then issued for ATM.n, followed by an L_MULTI_ADD for every member of the set {ATM.1, ....ATM.(n-1)} (assuming the set is non-null). The packet is then transmitted over the newly created VC just as it would be for a unicast VC. After transmitting the packet the local interface holds the VC open and marks it as the active path out of the host for any subsequent IP packets being sent to that Class D address. When establishing a new multicast VC is is possible that one or more ostensible group members may reject an L_MULTI_RQ or L_MULTI_ADD. If this occurs then the ATM address of the node responsible is dropped from the set {ATM.1, ATM.2, .... ATM.n} returned by the ARP Server, and the creation of the multicast VC continues. [Further action? TBD] 5.4 Managing the Multicast VC. Multicast VCs have the potential to be expensive in their use of resources. Therefore each VC MUST have a configurable inactivity timer associated with it. If the timer expires, an L_RELEASE is issued for that VC, and the Class D address is no longer considered to have an active path out of the local host. Choice of timer period is beyond the scope of this memo. During the life of a multicast VC an ERR_L_RELEASE may be received indicating that a leaf node has terminated its participation at the Armitage Expires March 6th, 1995 [Page 9] Internet Draft October 3rd, 1994 ATM level. The ATM endpoint associated with the ERR_L_RELEASE MUST be removed from the locally held set {ATM.1, ATM.2, .... ATM.n} associated with the VC. Section 7 describes what happens if group membership changes while the VC is open. Section 10 describes the mechanism for ensuring hosts remain up to date with changes that occur while the VC is open. 6. Joining an IP Multicast Group to Receive packets. A host is a 'group member', in the sense that a member receives packets directed at the group, when its ATM address appears in the ARP Server's table entry for the group's IP address. A key function within the LIS is the distribution of group membership information to the ARP Server and multicast capable hosts in the LIS. The ARP Server's links to multicast hosts in the LIS differs from its links to unicast hosts. The ARP Server maintains an outgoing, one- to-many multicast VC, with each multicast host as a leaf node. Two new ATMARP messages are defined: ARP_MCJOIN and ARP_MCLEAVE. These are sent to the ARP Server by hosts joining or leaving a group, and the ARP Server propagates them to other hosts to ensure the knowledge is distributed in a timely fashion. RFC1112 expects that routers are capable of behaving 'promiscuously'. This functionality may achieved by allowing routers to register with the ARP Server to be returned as 'wild card' members of all Class D addresses. However, a problem inherent in the current ATM model is that such behaviour may be wasteful of reassembly resources on the router's ATM interface. This draft proposes a generalisation to the notion of 'wild card' entries, enabling routers to limit themselves to 'blocks' of the Class D address space. The application of this facility is described in greater detail in Section 9. A block can be as small as 1 (a single group) or as large as the entire Class D address space (default 'promiscuous' behaviour). The key extensions required to manage the ARP Server table entries are: Two new ATMARP message types are defined: ARP_MCJOIN carries a Class D IP address and 32 bit mask (to specify a contiguous block of groups being joined) and a unicast ATM address (of the node joining). ARP_MCLEAVE carries a Class D IP address and 32 bit mask (to specify a contiguous set of groups being left) and a unicast Armitage Expires March 6th, 1995 [Page 10] Internet Draft October 3rd, 1994 ATM address (of the node leaving). JoinLocalGroup results in two messages being transmitted: ARP_MCJOIN, sent over a VC to the ARP Server. It identifyies the IP group being joined, a mask indicating a single group is being joined, and the hosts ATM address. An IGMP Report, except for 224.0.0.1 (in accordance with RFC1112). LeaveLocalGroup now results in an ARP_MCLEAVE being sent over a VC to the ARP Server, identifying the IP group being left, and the host's ATM address. IP endpoints with special requirements (e.g. IP multicast routers) may directly issue ARP_MCJOINs and ARP_MCLEAVEs specifying groups of Class D addresses. No IGMP Report is issued for such operations. When an ARP_MCJOIN is received by the ARP Server it adds the specified ATM address to the ARP entry for the specified Class D address(es). When an ARP_MCLEAVE is received by the ARP Server it removes the specified ATM address from the ARP entry for the specified Class D address(es). The ARP Server maintains a single Point to Multipoint VC out to every IP multicast host. When they join group 224.0.0.1 they are added as a leaf, when they leave group 224.0.0.1 they are dropped. ARP_MCJOIN and ARP_MCLEAVE messages arriving from individual hosts are processed locally by the ARP Server AND retransmitted on the Point to Multipoint VC to all multicast hosts. All host ARP entities ignore ARP_MCJOINN or ARP_MCLEAVE messages that simply confirm information already held by the entity. The ARP Server retransmits redundant messages, but otherwise takes no action. 6.1 Format of the ARP_MCJOIN and ARP_MCLEAVE Messages. The ATM ARP_MCJOIN message is a variation on the ARP_REPLY message, indicated by an 'operation type value' of 12 (decimal). ARP_MCLEAVE has the same format and operation type value of 13 (decimal). The message format is: Armitage Expires March 6th, 1995 [Page 11] Internet Draft October 3rd, 1994 Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$shtl 8 bits Type & length of source ATM number (q) ar$sstl 8 bits Type & length of source ATM subaddress (r) ar$op 16 bits Operation code ( = 12 or 13, JOIN or LEAVE) ar$spln 8 bits Length of source protocol address (s) ar$tpln 8 bits Length of multicast group address (z) ar$assn 32 bits ARP Server Sequence Number. ar$sha qoctets source ATM number (E.164 or ATM Forum NSAPA). ar$ssa roctets source ATM subaddress (ATM Forum NSAPA). ar$spa soctets source protocol address ar$gpa zoctets multicast group address. ar$mask zoctets multicast group mask. Refer to RFC 1577, section 6.6 for the coding of the ar$shtl and ar$sstl fields. For conventional IPv4 environments ar$spln and ar$tpln are both set to 4. Note that the message format differs from ARP_REPLY in the fields after ar$op. ar$assn is an unsigned 32 bit number filled in by the ARP Server before re-transmitting an ARP_MCJOIN or ARP_MCLEAVE. The originating host SHOULD set it to zero, although it will be ignored by the ARP Server. Its use is described further in section 10. 6.1.1 Construction of the Class D address and Mask. The field ar$gpa specifies a base address of a block containing one or more Class D addresses. Class D addresses are in the range 224.0.0.0 to The high-order four bits of ar$gpa MUST be set to "1110". No bit in ar$gpa may be set to 1 if the corresponding bit in ar$mask is set to 0. The high-order four bits in ar$mask MUST be set to "1111". A 'block' is the set of IP addresses that conform to the following equation: (IP address) AND (ar$mask) == (ar$gpa) Some examples: ar$gpa = 224.0.0.32 and ar$mask = 255.255.255.224 refers to the block between 224.0.0.32 and 224.0.0.63. ar$gpa = 224.0.0.0 and ar$mask = 255.255.255.224 refers to the block between 224.0.0.0 and 224.0.0.31. Armitage Expires March 6th, 1995 [Page 12] Internet Draft October 3rd, 1994 ar$gpa = 224.0.20.0 and ar$mask = 255.255.252.0 refers to the block between 224.0.20.0 and 224.0.23.255. 6.1.2 Important Default Values. JoinLocalGroup and LeaveLocalGroup MUST specify a mask value of 255.255.255.255. An ARP_MCJOIN with the following field values refers to a single Class D address X: ar$gpa = X and ar$mask = 255.255.255.255 A router choosing to behave strictly in accordance with RFC1112 MUST specify a mask value of 240.0.0.0. The following field values encompass the entire Class D space: ar$gpa = 224.0.0.0 and ar$mask = 240.0.0.0 The use of alternative mask values is discussed in Section 9. 6.2 Registering with the ARP Server as a Multicast Host. Unicast IP hosts exchange ARP traffic with the ARP Server over a bidirectional unicast VC. Multicast IP hosts receive an additional incoming VC from the ARP Server, which is used to receive group membership updates. This VC is maintained by the ARP Server as a point to multipoint undirectional VC, with each multicast host as a leaf node. In order for the ARP Server to maintain a list of multicast hosts on the LIS there must be a mechanism for 'registering' hosts. A solution is found in the requirements of RFC 1112. A multicast host must explicitly issue a JoinLocalGroup for group 224.0.0.1 when it initialises. This act of joining group 224.0.0.1 is sufficient to register the host with the ARP Server. The host's JoinLocalGroup to 224.0.0.1 will result in an ARP_MCJOIN being transmitted from the host to the ARP Server. The ARP Server monitors the membership of 224.0.0.1 and ensures each listed member is added as a leaf to its outgoing multicast VC. 6.3 Joining A General Group X. Two things occur when a host joins an arbitrary group X by sending an ARP_MCJOIN to the ARP Server. First the ARP Server updates its ARP tables. Then it retransmits the ARP_MCJOIN message on the multicast VC it has established out to other multicast IP hosts on the LIS. This behaviour is used in section 7 to allow nodes that are already Armitage Expires March 6th, 1995 [Page 13] Internet Draft October 3rd, 1994 members of a given group to note the new member. 6.4 Redundant ATM_MCJOIN and ATM_MCLEAVE Messages. Host and Router ARP entities MUST silently discard incoming ATM_MCJOIN and ATM_MCLEAVE messages that appear redundant (e.g. declaring a new host has left a group when that host is not listed as being a member). The ARP Server MUST retransmit ATM_MCJOIN and ATM_MCLEAVE messages even if they appear redundant. 7. Adding A New Leaf to Outgoing Multicast VC. Just updating the ARP Server's tables does not account for hosts who have already established multicast VCs for transmission to the group's previous members. The solution to this problem is for every host's ARP entity to inform the host's transmit side of ARP_MCJOIN and ARP_MCLEAVE messages it receives. These messages will be received from the ARP Server when other hosts change their group membership status, as described in section 6. If an ARP_MCJOIN is seen that refers to (or encompasses) an IP group for which the transmit side already has a VC open, the new member's ATM address is extracted and an L_MULTI_ADD issued locally. This ensures that hosts already sending to a given group will immediately add the new member to their list of recipients. It also ensures that routers joining a 'block' of groups are added by all hosts sending to groups within the block. Section 10 deals with the possibility of lost ARP messages causing hosts to miss membership additions. 8. Leaving an IP Multicast Group. Leaving an IP multicast group involves removing the local hosts entry from the ARP Server, and ensuring that hosts stop sending to the leaving node. Both are the reverse of the 'join' operations described in section 6 and 7. The ARP Server's response: LeaveLocalGroup results in ARP_MCLEAVE messages being sent to the ARP Server. The ARP Server removes the specified ATM address from the specified group(s) and retransmits the message to all other multicast hosts. If an IP multicast host issues a LeaveLocalGroup for 224.0.0.1 it will also be considered to have ceased membership of all other groups for which it may have joined. The ARP Server MUST flush Armitage Expires March 6th, 1995 [Page 14] Internet Draft October 3rd, 1994 that hosts's ATM address from any Class D address entries it appears in. Finally, the host is released as a Leaf node from the ARP Server's outgoing multicast VC. Response of an arbitrary host in the LIS: If an ARP_MCLEAVE is seen that refers to (or encompasses) an IP group for which the transmit side already has a VC open, the leaving member's ATM address is extracted and an L_MULTI_DROP issued locally. This ensures that hosts already sending to a given group will immediately delete the leaving member from their list of recipients (Leaf nodes). If an ARP_MCLEAVE is seen that refers to group 224.0.0.1 then the ATM address of the host originating the message MUST be removed from every multicast VC on the local host that it may be a Leaf of. The transmit side of the interface MUST NOT shut down an active VC to a group for which the receive side has just executed a LeaveLocalGroup. This behaviour is consistent with the model of hosts transmitting to groups regardless of their own membership status. RFC 1112 requires all active multicast IP hosts to be members of 224.0.0.1. Leaving this group seems a reasonable indication that a given host has ceased support for IP multicasting. Section 10 deals with the possibility of lost ARP messages causing hosts to miss membership additions. 9. Beyond the LIS - Multicast IP Router behaviour. Multicast routers are required for an IP multicast group to span more than the local LIS. The multicast router may be a tunneling router, or may have direct connection to another multicast-capable link layer. Decisions by routers to receive packets from given multicast groups will depend on algorithms or policies beyond the scope of this memo (e.g. DVMRP [5]). It is assumed that the IP multicast router will be implemented over the same sort of IP-ATM interface that a multicast host's IP layer would use. They will use the basic services described in the preceeding sections to join and leave IP multicast groups as necessary. Armitage Expires March 6th, 1995 [Page 15] Internet Draft October 3rd, 1994 9.1 Sending to a Group. If the router needs to transmit a packet to a group within the LIS it opens a multicast VC in the same manner as a normal host would. Once a VC is open, the router's ARP entity watches for ARP_MCJOIN and ARP_MCLEAVE messages and responds to them as a normal host would. The IP multicast router's transmit side MUST implement inactivity timers to shut down idle outgoing VCs, as for normal hosts. As with normal host, the router does not need to be a member of a group it is sending to. 9.2 Promiscuously Joining Groups. Once initialised, the simplest model of router operation is that it issues an ARP_MCJOIN encompassing the entire Class D address space. In effect it becomes 'promiscuous', as it will be a leaf node to all present and future multicast VCs established on the LIS. How a router chooses which groups to propagate outside the LIS is beyond the scope of this memo. Consistent with RFC 1112, IP multicast routers may retain the use of IGMP Query and IGMP Report messages to ascertain group membership. 9.3 Forward Multicast Traffic Across the LIS. Under some circumstances the LIS may simply be another hop between IP subnets that have participants in a multicast group. [LAN.1] ----- IPmcR.1 -- [LIS] -- IPmcR.2 ----- [LAN.2] LAN.1 and LAN.2 are subnets (such as Ethernet) with attached hosts that are members of group X. IPmcR.1 and IPmcR.2 are multicast routers with interfaces to the LIS. A traditional solution would be to treat the LIS as a unicast subnet, and use tunneling routers. However, this would not allow hosts on the LIS to participate in the cross-LIS traffic. Assume IPmcR.1 is receiving packets promiscuously on its LAN.1 interface. Assume further it is configured to propagate multicast traffic to all attached interfaces. In this case that means the LIS. When a packet for group X arrives on its LAN.1 interface, IPmcR.1 simply sends the packet to group X on the LIS interface as a normal Armitage Expires March 6th, 1995 [Page 16] Internet Draft October 3rd, 1994 host would (ARPing for group X, creating the VC, sending the packet). Assuming IPmcR.2 initialised itself as a wild-card entry in the ARP Server's tables, it will have been returned as a member of X, even if no other nodes on the LIS were members. All packets for group X received on its LIS interface may be retransmitted on LAN.2. If IPmcR.1 is similarly initialised the reverse process will apply for multicast traffic from LAN.2 to LAN.1, for any multicast group. The benefit of this scenario is that other hosts directly attached to the LIS may also join and leave group X at anytime. 9.4 Restricted 'promiscous' Operation. Both Unicast and Multicast IP routers have a common problem. Each will suffer from limitations on the number of reassembly engines available at their ATM interfaces. For the unicast router this will limit the number of destinations outside the RFC 1577 LIS that hosts may be sending to at any one time. Each destination IP address results in a new VC to the router (and because of the bidirectional nature of a unicast VC, this consumes a segmentation engine too). The problem is magnified in the multicast situation. Being 'promiscuous' in the RFC 1112 sense means that for every M hosts sending to N groups, the router's ATM interface will have M*N incoming reassembly engines tied up. It is not hard to envisage situations where a number of multicast groups are active within the LIS but are not required to be propagated beyond the LIS itself. An example might be a distributed simulation system specifically designed to use the high speed IP/ATM environment. There may be no practical way its traffic could be utilised on 'the other side' of the multicast router, yet under the conventional scheme the router would have to be a leaf to each participating host anyway. As this problem occurs at the Link Layer, it is worth noting that 'scoping' mechanisms at the IP level are not a solution. In this situation the LIS administrator might configure their multicast routers to exclude sections of the Class D address space when issuing ARP_MCJOIN(s). Another scenario involves the product M*N exceeding the capacity of a single router's interface (especially if the same interface must also support a unicast IP router service). A LIS administrator may choose to add a second node, to function as a Armitage Expires March 6th, 1995 [Page 17] Internet Draft October 3rd, 1994 parallel IP multicast router to the same 'out of LIS' networks. Each router would be configured to be 'promiscuous' over separate parts of the Class D address space, thus sharing the load. This sharing would be completely transparent to IP hosts within the LIS. Restricted promiscuous mode does not break RFC 1112's use of IGMP Report messages. If the router is configured to serve a given block of Class D addresses, it will receive the IGMP Report. If the router is not configured to support a given block, then the existence of an IGMP Report for a group in that block is irrelevant to the router. All routers are able to track membership changes through the ARP_MCJOIN and ARP_MCLEAVE traffic anyway. Mechanisms for establishing these modes of operation are beyond the scope of this memo. 10. Robustness of interaction with the ARP Server. Transient problems on the path between ARP clients and the ARP Server may result in lost ARP messages. There are two problem scenarios that are addressed in this document. The first is the loss of an ARP_MCJOIN or ARP_MCLEAVE between the host originating the message and the ARP Server itself. In this case the host is the only member of the LIS that is aware of the change. The second is with the ARP_MCJOIN and ARP_MCLEAVE messages re- transmitted from the ARP Server. If a host currently sending to a group misses an ARP_MCJOIN, the newly joined member misses out on that host's traffic to the group. If a host currently sending to a group misses an ARP_MCLEAVE, the host that left will continue to receive packets unecessarily. 10.1 Ensuring the ARP Server hears you. A simple algorithm solves the first problem. Simply retransmit ARP_MCJOIN and ARP_MCLEAVE messages at regular intervals until you receive a copy back again on the multicast VC from the ARP Server. At this point the local host's ARP entity can be certain that at least the ARP Server received it, and can signal successful completion of the operation to the IP layer. An appropriate interval is [TBD - 5 seconds?]. After [TBD - 30?] retransmissions the attempt should be flagged locally as a failure. 10.2 The ARP Server Sequence Number. In each ARP_MULTI, ARP_MCJOIN, and ARP_MCLEAVE there is a 32 bit sequence number identified as ar$assn. The following extensions Armitage Expires March 6th, 1995 [Page 18] Internet Draft October 3rd, 1994 govern its use: The ARP Server keeps a central counter, ASSN, and increments it each time a single ARP_MCJOIN or ARP_MCLEAVE results in a change to the Class D address mapping table. When the ARP Server receives an ARP_REQUEST for a Class D address, the current value of ASSN is noted and copied into the as$assn field of every ARP_MULTI sent in response. After the ARP Server processes an ARP_MCJOIN or ARP_MCLEAVE message it copies the new ASSN value into the ar$assn field of the message before retransmitting it. Every host's ARP entity keeps its own 32 bit Host Sequence Number (HSN) to track the ARP Server's sequence number. Whenever an ARP_MULTI, ARP_MCJOIN, or ARP_MCLEAVE is received the following check is then performed on the ar$assn field of the new message: Seq.diff = ar$assn - HSN ar$assn -> HSN {...process ARP message as appropriate...} if ((Seq.diff != 1) && (Seq.diff != 0)) then {...revalidate group membership information...} Revalidating group membership information involves re-executing an ARP_REQUEST for every IP multicast group that the local host is currently sending to. The basic result is that the host attempts to keep locked in step with membership changes noted by the ARP Server. If it ever detects that a membership change occurred (in any group) without the local host noticing, at re-validates the membership of all groups it currently has multicast VCs open to. One implication of this mechanism is that the ARP Server should serialize its processing of 'simultaneous' ARP_REQUEST, ARP_MCJOIN and ARP_MCLEAVE messages. Join and Leave operations should be queued within the ARP Server along with ARP_REQUESTS, and not processed until all the ARP_MULTIs of a preceeding ARP_REQUEST have been transmitted. The ARP Server is free to choose a value of ASSN. When a new host starts up it should initialise HSN to zero. When the host sends the ARP_MCJOIN for 224.0.0.1 the HSN will be correctly set when it receives a copy of its ARP_MCJOIN from the ARP Server. If Seq.diff > Armitage Expires March 6th, 1995 [Page 19] Internet Draft October 3rd, 1994 1 when the ARP_MCJOIN returns no action will be taken anyway, as the host will not have any multicast VCs established at this point. If a host notices a sequence number jump when establishing a new group's VC it should not revalidate the membership of the group it just established. The membership returned in the ARP_MULTIs that carried the new ar$assn field should be considered already validated. When more than one ARP_MULTI is sent in response to an ARP_REQUEST the ar$assn field of consecutive ARP_MULTIs must be constant. If the ar$assn field changes then all the messages MUST be discarded at the completion of the response, and the ARP_REQUEST re-issued. An ARP Server should be carefully designed to minimise the possibility of the ASSN jumping unecessarily. Under normal operation only hosts that are affected by transient link problems will miss ar$assn updates and be forced to revalidate. If the ARP Server itself glitches it will be innundated with ARP requests for a period as every multicast host in the LIS attempts to revalidate. 10.3 Why a Gobal sequence number? The ASSN is global in that it counts the number of ARP_MCJOIN or ARP_MCLEAVE operations it has processed, without reference to group(s) affected. This may be perceived as a limitation, because there is no way for LIS hosts to isolate exactly which Class D group they may have missed an update for. An alternative was to try and provide a per-group sequence number. Unfortunately per-group sequence numbers are not practical. The current mechanism allows sequence information to be piggy-backed onto ARP messages already in transit for other reasons. The ability to specify blocks of Class D addresses with a single ARP_MCJOIN or ARP_MCLEAVE means that a single message can refer to membership change for multiple groups simultaneously. A single ar$assn field cannot provide meaningful information about each group's sequence. Multiple ar$assn fields would have been unwieldy. 11. Summary of Key Decisions. The key decisions this memo proposes: General IP multicast in the LIS is through mesh of Point to Multipoint VCs rather than a central Multicast Server. The ARP Server transparently establishes itself as a Multicast Server for certain classes of ARP traffic from itself to multicast hosts on the LIS. Armitage Expires March 6th, 1995 [Page 20] Internet Draft October 3rd, 1994 ATM ARP Server role extended. Class D IP addresses may be mapped to 0 or more ATM addresses. New ARP message type, ARP_MULTI. ARP_REQUESTS issued for Class D addresses may get 1 or more ARP_MULTI messages as the ARP Server passes back all group member's ATM addresses. New ARP message type, ARP_MCJOIN. Issued by LIS hosts to inform the ARP Server they are now members of a group or block of groups. New ARP message type, ARP_MCLEAVE. Issued by LIS hosts to inform the ARP Server they are no longer members of a group or block of groups. Specific interpretation of 224.0.0.1 membership to register LIS hosts and support a 'multicast server' architecture. 'wild card' ARP table entries possible, where a single ATM address is simultaneously associated with blocks of Class D addresses. ATM endpoint model. Attempted decoupling of IP-ATM interface, local UNI 3.0 signalling service, and local ATM/AAL service descriptions. Explicitly identifies an LLC 'entity' that terminates or originates VCs for RFC 1483 compliant LLC/SNAP encapsulated traffic. 12. Open Issues. Some issues have not been addressed, although they may be in future revisions. Quality of Service has not been addressed. This is a current issue for both unicast and multicast IP over ATM. ARP Server has no mechanism for realising group members have silently died. [This probably should be attended to as a priority]. Using a mesh of point to multipoint VCs to connect group members places a high load on both the switch and the ATM reassembly engines of each host receiving group transmissions. When an IP host joins a group, every host transmitting to that group adds it Armitage Expires March 6th, 1995 [Page 21] Internet Draft October 3rd, 1994 as a new leaf. This results in a new incoming VC and reassembly instance at the receiver for every VC it has become a leaf to. If an IP host joins multiple groups the situation is exacerbated. Implementations might consider reusing VCs if a destination ATM node's IP interface is a member of multiple groups. No attempt is made to utilise indications from the ATM layer that remote nodes have either added the local node as a leaf, or dropped themselves from a VC originating at the local node. The future development of ATM Group Addresses and Leaf Initiated Join to ATM Forum's UNI specification has not been addressed. The problems identified in this memo with respect to VC scarcity and impact on receive side reassembly engines will not be fixed by such developments in the signalling protocol. Security Consideration Security consideration are not addressed in this memo. Acknowledgments The discussions within the IP over ATM Working Group have helped clarify the ideas expressed in this document. John Moy of Cascade Communications Corp. initially suggested the idea of wild-card entries in the ARP Server. Drew Perkins of Fore Systems provided rigorous and useful critique of early proposed mechanisms for distributing and validating group membership information. Author's Address Grenville Armitage MRE 2P340, 445 South Street Morristown, NJ, 07960-6438 USA Email: gja@thumper.bellcore.com References [1] S. Deering, "Host Extensions for IP Multicasting", RFC 1112, Standford University, August 1989. [2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption Layer 5", RFC 1483, USC/Information Science Institute, July 1993. [3] Laubach, M., "Classical IP and ARP over ATM", RFC1577, Hewlett- Packard Laboratories, December 1993 Armitage Expires March 6th, 1995 [Page 22] Internet Draft October 3rd, 1994 [4] ATM Forum, "ATM User-Network Interface Specification Version 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993 [5] D. Waitzman, C. Partridge, S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988. [6] M. Perez, F. Liaw, D. Grossman, A. Mankin, E. Hoffman, A. Malis, "ATM Signaling Support for IP over ATM", Internet Draft, IP over ATM Working Group, draft-ietf-ipatm-sig-02.txt, August 14, 1994. Armitage Expires March 6th, 1995 [Page 23] Internet Draft October 3rd, 1994 Appendix A. UNI 3.0 Multicast Support - A Brief Overview. This section provides a general description of point-to-multipoint signaling procedures. Readers are referred to [4] for details of UNI 3.0 signalling elements, and to [6] (or later versions) for descriptions of ATM signalling for unicast services within the LIS. In section 4 a list of 'generic' functions were suggested for the interface between the ATM network and an AAL User (e.g. the LLC entity) within each LIS host. The interaction between the LLC entity and its clients (e.g. IP and ARP entities) is discussed in some further detail in Appendix B. It is vital to note that this document specifies the interface between the LLC entity and higher layer protocols in a completely indirect fashion. For example, where the text refers to the IP entity issuing an L_MULTI_ADD, it is implicit that some local mechanism is in place for the IP entity to cause the LLC entity to issue an L_MULTI_ADD on its behalf. A.1 The Unicast case - Originating action on a VC. L_CALL_RQ is issued by the LLC entity to the local UNI 3.0 entity. This initiates a signalling exchange between the local host's UNI 3.0 entity and the ATM network to establish a new VC. The L_CALL_RQ is passed with sufficient information so that the initial SETUP message can be constructed as outlined in [6]. If the signalling exchange is successful an L_ACK is returned to the LLC entity The signalling sequence may be represented as: [AAL User] [UNI 3.0 entity] [The Network] L_CALL_RQ -----> SETUP ------> (stuff happens) (optionally <------ CALL PROCEEDING) <------ CONNECT CONNECT ACK ------> <----- L_ACK (AAL User now assumes VC is active) If the network rejects the call setup an ERR_L_RQFAILED is returned. This sequence may be represented as: [AAL User] [UNI 3.0 entity] [The Network] Armitage Expires March 6th, 1995 [Page 24] Internet Draft October 3rd, 1994 L_CALL_RQ -----> SETUP ------> (stuff happens) <------ RELEASE COMPLETE <----- ERR_L_RQFAILED A more complex failure sequence (if the network first passed back a CALL PROCEEDING) may be represented by: [AAL User] [UNI 3.0 entity] [The Network] L_CALL_RQ -----> SETUP ------> <------ CALL PROCEEDING (stuff happens) <------ RELEASE RELEASE COMPLETE ------> <----- ERR_L_RQFAILED Both L_ACK and ERR_L_RQFAILED indications should carry enough information to identify the local request being responded to. L_RELEASE is similar to L_CALL_RQ except that it initiates a signalling exchange to release the VC. Sufficient information is passed so that the RELEASE message can be constructed appropriately. The signalling sequence may be represented as: [AAL User] [UNI 3.0 entity] [The Network] L_RELEASE -----> RELEASE ------> (stuff happens) <------ RELEASE COMPLETE It is implementation specific how the local host's UNI 3.0 entity associates the VC terminating in the underlying AAL service with the AAL User that issued the L_CALL_RQ. A.2 The Unicast case - Reacting to action on a VC. The process of binding an AAL User to the general services of the AAL and UNI 3.0 entity are implementation specific. However, the interface between the UNI 3.0 entity and AAL Users should allow an AAL User to request indication of remotely originated requests to establish or tear down VCs. L_REMOTE_CALL is issued to the AAL User when the UNI 3.0 entity has accepted a remotely originated call on its behalf (based on information provided by the AAL User during binding). The signalling Armitage Expires March 6th, 1995 [Page 25] Internet Draft October 3rd, 1994 sequence may be represented as: [AAL User] [UNI 3.0 entity] [The Network] <------ SETUP CONNECT ------> <------ CONNECT ACK <----- L_REMOTE_CALL The L_REMOTE_CALL is expected to carry back sufficient locally significant information for the AAL User to identify and utilise the newly terminated VC. An extended interface would also allow AAL Users to such as the LLC entity to block VC establishment requests if necessary. We can postulate the following signalling exchange: [AAL User] [UNI 3.0 entity] [The Network] <------ SETUP CALL PROCEEDING ------> <----- L_REMOTE_RQ L_REMOTE_ACK -----> CONNECT ------> <------ CONNECT ACK <----- L_REMOTE_CALL In this scenario the UNI 3.0 entity informs the network that the request is being processed, then passes information about the call request to the appropriate AAL User in an L_REMOTE_RQ indication. If the conditions are acceptable, an L_REMOTE_ACK is passed back, allowing the UNI 3.0 entity to complete the acceptance procedure. Finally the call is formally announced with L_REMOTE_CALL. When the remote node terminates the VC, the AAL User receives an appropriate ERR_L_RELEASE indication (the analog of L_REMOTE_CALL). No mechanism is required to query the AAL User before releasing a VC. The signalling sequence may be represented as: [AAL User] [UNI 3.0 entity] [The Network] <------ RELEASE RELEASE COMPLETE ------> <----- ERR_L_RELEASE Armitage Expires March 6th, 1995 [Page 26] Internet Draft October 3rd, 1994 A.3 The Multicast case - Originating action on a VC. A point to multipoint VC begins with a SETUP being issued to establish a multicast call to a single destination - the first Leaf node. However, the SETUP differs from that used in the unicast case. An additional Endpoint reference Information Element (IE) is added, and the Broadband Bearer Capability IE is set to indicate point to multipoint instead of point to point. L_CALL_RQ's functionality is provided by L_MULTI_RQ when first establishing the VC. The signalling sequence may be represented as: [AAL User] [UNI 3.0 entity] [The Network] L_MULTI_RQ -----> SETUP ------> (stuff happens) (optionally <------ CALL PROCEEDING) <------ CONNECT CONNECT ACK ------> <----- L_ACK (AAL User now assumes VC is active) The Endpoint IE is set to zero for this SETUP. The node initiating the VC is the Root node. Adding new Leaf nodes requires the UNI 3.0 entity to issue an ADD PARTY message, which is initiated by the receipt of an L_MULTI_ADD from the AAL User. Mechanisms to associate L_MULTI_ADDs with a given multicast VC are implementation specific. The signalling sequence for successfully adding a new Leaf node may be represented by: [AAL User] [UNI 3.0 entity] [The Network] L_MULTI_ADD -----> ADD PARTY ------> (stuff happens) <------ ADD PARTY ACK <----- L_ACK (AAL User now assumes new Leaf is active) The Endpoint IE is set to a non-zero value before transmission of the ADD PARTY to uniquely identify the new Leaf node (section 5.4.8.1 [4]). Dropping a Leaf node requires an DROP PARTY from the UNI 3.0 entity, Armitage Expires March 6th, 1995 [Page 27] Internet Draft October 3rd, 1994 which is generated in response to an L_MULTI_DROP from the AAL User. The signalling sequence for successfully dropping a Leaf node may be represented by: [AAL User] [UNI 3.0 entity] [The Network] L_MULTI_DROP -----> DROP PARTY ------> (stuff happens) <------ DROP PARTY ACK A.4 The Multicast case - Reacting to action on a VC. From the Leaf node's perspective there is little difference between reacting to a remotely originated unicast VC, and being made a Leaf to a remotely originated multicast VC. The main difference will be the lack of return bandwidth to the Root node, so the UNI 3.0 entity will need some local mechanism to indicate to the AAL User that it cannot return traffic to the remote AAL User on this VC. If the L_REMOTE_RQ and L_REMOTE_CALL indications are capable of carrying information specifying zero bandwidth in the Leaf to Root direction, then the signalling sequences are as described in section A.2. A.5 Signalling Elements. Information Element codings will be based completely on their unicast counterparts described in [6], with only minimal variations as required by section 5.6 [4]. Armitage Expires March 6th, 1995 [Page 28] Internet Draft October 3rd, 1994 Appendix B. Thoughts on the behaviour of ARP entities. The ARP Server model contains a few pitfalls for the unwary, as it marks a departure from the familiar 'peer client' model generally used in environments such as Ethernet subnets. Some of the consequences of following the RFC 1577 model, and extending it further as described in this document, are gradually being clarified. An additional source of difficulty lies in the implications of using LLC/SNAP encapsulation to enable 'multiprotocol' traffic on AAL5 VCs. The major issues may be summarised as follows: The ARP Server is strictly nothing more than an ARP entity attached to an LLC entity. Unlike the traditional case where an ARP entity was always co-resident with an IP entity over the same link layer interface, this can no longer be assumed. However, in order to perform InARP according to RFC 1577, the ARP entity needs to be assigned an IP address from the pool available to the LIS. The signalling method described in [6] supports the identification of the ATM endpoint, and a layer 2 endpoint within the ATM endpoint. It does not allow the layer 2 client (a layer 3 endpoint) to be explicitly identified (although such a facility does exist within UNI 3.0). However, RFC 1577 requires the ARP Server entity to pre-emptively perform InARP on any new VCs that are remotely originated to its underlying LLC entity. (In effect the ARP Server entity makes an assumption that new VCs are intended for carrying ARP traffic and were initiated by a remote IP/ARP protocol stack.) This requires that the LLC/LLC-client interface supports the passage of indications to LLC clients when a new VC 'arrives'. The first issue is easily solved (just allocate an unused IP address within the LIS), but requires clear understanding that the ARP Server's apparent IP address does not imply the existence of a co- resident IP stack. The second issue is of interest to implementors of IP multicast hosts. In addition to sending ARP_REQUESTs, the ARP entity in a multicast LIS hosts will also be sending ARP_MCJOINs and ARP_MCLEAVEs at various unrelated times. Implementations must be ready to respond correctly to InARPs everytime they open or re-open a VC to the ARP Server node during group membership changes. They must also be ready to use any VC that is already open to the ARP Server's LLC entity when possible. The second issue may also cause problems in true multiprotocol environments. Consider the ARP Server entity sharing an LLC entity Armitage Expires March 6th, 1995 [Page 29] Internet Draft October 3rd, 1994 with a non-IP protocol stack. If a client of the non-IP protocol stack initiates a VC to the LLC entity shared by the ARP Server entity, it will receive InARP request(s) from the ARP Server entity. The handling of this scenario is one for careful thought by ARP Server implementors, as the InARP Request(s) will most likely go unanswered. Finally, all LIS hosts must be capable of sensibly terminating VCs that are remotely originated and have zero reverse bandwidth. Without this capacity they cannot become Leaf nodes to any multicast VCs. The most important multicast VC in this document is the one from the ARP Server's ARP entity out to all registered multicast hosts. Host implementations must be careful not to mistake this VC from the ARP Server as an open VC they can send ARP_REQUESTs, ARP_MCJOINs, or ARP_MCLEAVEs on. When a multicast host is registered, its ARP entity will send ARP messages over a normal unicast VC, and receive ARP_MCJOIN and ARP_MCLEAVE messages over the multicast VC it is a Leaf on. ARP Server's should return ARP_MULTIs on the VC that the ARP_REQUEST arrived on, even if the requesting host is already a registered multicast host. Armitage Expires March 6th, 1995 [Page 30] Internet Draft October 3rd, 1994 Appendix C. Hidden Multicast Servers. The architecture described here is primarily arranged around the assumption that the ARP Server will return all the group member's ATM addresses, and that a transmitting host will be part of a full mesh. However, in some environments the consumption of reassembly contexts and VC space may be too high for all groups to be full meshes. Using multicast servers has been proposed at times as a solution in these cases. Provided that all multicast hosts on the LIS are designed in accordance with this document, it is possible to construct a hybrid network where some Class D groups are based on a mesh of VCs between the participating hosts, and other Class D groups are supported through a separate node acting as a multicast server. And it will be all quite transparent to the individual hosts. The 'trick' is in the ARP Server. [possible solution to be written later...it is a hack.] Armitage Expires March 6th, 1995 [Page 31]