Internet-Draft Grenville Armitage Bellcore September 6th, 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 [1]) and RFC1112 (Host Extensions for IP Multicasting [2]) 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 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 February 6th, 1995 [Page 1] Internet Draft September 6th, 1994 subnets. RFC 1483 [3] defines a mechanism for encapsulating and transmitting IP packets using AAL5 over ATM Virtual Channels (VCs). RFC 1577 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. The operation of the Internet Group Management Protocol (IGMP) is modified, and a new IGMP message type is proposed, to support the distribution of IP group membership information. A multicast-server architecture is used to distribute IGMP 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 IP an 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 Armitage Expires February 6th, 1995 [Page 2] Internet Draft September 6th, 1994 group, it issues JoinLocalGroup. When it no longer wants to receive 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 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 February 6th, 1995 [Page 3] Internet Draft September 6th, 1994 ipatm0 / | \ --------- | --------- | | | .............................. . This draft's functionality . .............................. | | | IP.1 IP.2 IP.3 | | | +++++.......+++++........+++++ ---- 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 single 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,3} are the IP addresses of destinations that the local interface is connected to through VC.{1,2,3}. In a unicast-only LIS these IP addresses map to a single endpoint, and the VCs allow bidirectional flow of IP packets. 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. 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. Armitage Expires February 6th, 1995 [Page 4] Internet Draft September 6th, 1994 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. The ARP Server functions as a 'multicast server' for traffic on the 224.0.0.1 group, in a manner transparent to the IP hosts on the LIS. All other IP multicast groups are supported by meshes of point to multipoint VCs. This avoids the need to implement a new node to function as a multicast server for conventional multicast data traffic. The following generic signalling functions are presumed to be available to AAL Users: [mneumonics subject to change, they're "off the top of my head"] 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. 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_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 Armitage Expires February 6th, 1995 [Page 5] Internet Draft September 6th, 1994 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 source must 'know' its destinations before 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 should be extended to hold 1 or 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 two new fields. Group address 224.0.0.1 is permanently configured as a special case with only one member, the ARP Server itself. 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 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 31 bit integer field y - expressed as ARP_MULTI(x,y). Field y acts as a sequence Armitage Expires February 6th, 1995 [Page 6] Internet Draft September 6th, 1994 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. For a group with n members the following sequence would occur: ARP_MULTI(0,1) carries back ATM.1 ARP_MULTI(0,2) carries back ATM.2 [.......] ARP_MULTI(1,n) carries back ATM.n If n == 1 then only ARP_MULTI(1,1) is sent. Typical failure mode will be losing one or more of ARP_MULTI(0,1) through ARP_MULTI(0,n-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,n). A timer MUST be implemented to flag the failure of the last ARP_MULTI to arrive. [timer value to be decided]. If a 'sequence jump' is detected, the host MUST wait for the ARP_MULTI(1,n), discard all results, and repeat the ARP REQUEST. If a timeout occurs, the host MUST discard all results, and repeat the ARP_REQUEST. 5.2 Format of the ARP_MULTI message. The ATM ARP_MULTI message is based on the ARP_REPLY message, with an additional 32 bit field to hold x and y. An ARP_MULTI is 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$seqxy 32 bits Boolean flag x and sequence number y. ar$sha qoctets source ATM number ar$ssa roctets source ATM subaddress ar$spa soctets source protocol address ar$tha xoctets target ATM number ar$tsa yoctets target ATM subaddress ar$tpa zoctets target protocol address Armitage Expires February 6th, 1995 [Page 7] Internet Draft September 6th, 1994 ar$seqxy is coded with flag x in the leading bit, and sequence number y coded as an unsigned integer in the remaining 31 bits. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x| y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Section 6.6 of RFC 1577 should be consulted for specific details and coding of all other fields. 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 necessary?] 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 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. Special handling of packets transmitted to 224.0.0.1 is left up to the ARP Server. ARP_REQUESTS for this group receive the ARP Server's own ATM address in response, resulting in the ARPing host creating a Armitage Expires February 6th, 1995 [Page 8] Internet Draft September 6th, 1994 unidirectional VC to the ARP Server's IP layer. From the host's perspective it is the root of a normal multicast VC, although it has only one leaf. Section 6 describes how the ARP Server handles 224.0.0.1 and tracks current group membership. Section 7 describes what happens if group membership changes 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. The 224.0.0.1 multicast group plays a key role in distributing information about group membership to the ARP Server and multicast capable hosts in the LIS. For this reason the 224.0.0.1 group is constructed differently. The ARP Server takes an active role and establishes itself as a multicast server for this group, rather than allowing the IP hosts to construct a point to point mesh. RFC1112 expects that routers are capable of behaving 'promiscuously'. This is 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: A new IGMP message type is defined called ATMMC, with two subtypes: ATMMC_JOIN 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). ATMMC_LEAVE carries a Class D IP address and 32 bit mask (to specify a contiguous set of groups being left) and a unicast ATM address (of the node leaving). IGMP ATMMC messages MUST be transmitted to address 224.0.0.1. The Armitage Expires February 6th, 1995 [Page 9] Internet Draft September 6th, 1994 mechanism described in RFC 1112 for redundant transmission of IGMP Reports MUST be applied to IGMP ATMMC messages. The ARP Server contains an IP layer, with an IGMP entity and exception handling for packets received for group 224.0.0.1. JoinLocalGroup allows only a single group to be joined at a time. Two IGMP messages are transmitted: IGMP Report, and IGMP ATMMC_JOIN, identifying the IP group being joined, and the hosts ATM address. LeaveLocalGroup now results in an IGMP ATMMC_LEAVE being transmitted, 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 IGMP ATMMC_JOINs and ATMMC_LEAVEs specifying groups of Class D addresses. An IGMP Report cannot be issued for such an operation. When an IGMP ATMMC_JOIN is received by the ARP Server's IGMP entity, it adds the specified ATM address to the ARP entry for the specified Class D address(es). This includes ATMMC_JOINs for group 224.0.0.1, although these are never reported in response to ARP_REQUESTs. When an IGMP ATMMC_LEAVE is received by the ARP Server's IGMP entity, it removes the specified ATM address(es) from the ARP entry for the specified Class D address. 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. Most IGMP messages arriving from individual hosts are processed locally AND retransmitted on the Point to Multipoint VC. ATMMC_JOINs for group 224.0.0.1 are NOT retransmitted by the ARP Server's IGMP entity. IGMP entities ignore ATMMC_JOIN or ATMMC_LEAVE messages that simply confirm information already held by the entity. Armitage Expires February 6th, 1995 [Page 10] Internet Draft September 6th, 1994 6.1 Format of the IGMP ATMMC Messages. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. IGMP messages start with the following 4 byte header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Subtype | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version = 1 The Type field values are: 1 = Host Membership Query. (Subtype is ignored). 2 = Host Membership Report. (Subtype is ignored). 3 = DVMRP [5]. (4 subtypes defined). 4 = ATMMC. (2 subtypes defined) For ATMMC the Subtype field values shall be: 1 = JOIN. 2 = LEAVE. The ATMMC message contents follow immediately after the IGMP header in the IP packet. The format of ATMMC_JOIN and ATMMC_LEAVE are exactly the same. It borrows fields from the ATM ARP packet format in RFC 1577 to carry a single IP address, an IP address mask, an ATM address, and (optionally) an ATM subaddress: Data: ar$shtl 8 bits Type & length of source ATM number (q). ar$sstl 8 bits Type & length of source ATM subaddress (r). ar$spa 32 bits Class D address of IP multicast group. ar$mask 32 bits Mask defining block of Class D addresses. ar$sha qoctets source ATM number (E.164 or ATM Forum NSAPA). ar$ssa roctets source ATM subaddress (ATM Forum NSAPA). Refer to RFC 1577, section 6.6 for the coding of the ar$shtl and ar$sstl fields. Armitage Expires February 6th, 1995 [Page 11] Internet Draft September 6th, 1994 6.1.1 Construction of the Class D address and Mask. The field ar$spa 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$spa MUST be set to "1110". No bit in ar$spa 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$spa) Some examples: ar$spa = 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$spa = 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. ar$spa = 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 ATMMC_JOIN with the following field values refers to a single Class D address X: ar$spa = 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$spa = 224.0.0.0 and ar$mask = 240.0.0.0 The exception is group 224.0.0.1, which the ARP Server will ONLY ever return its own ATM address for. The use of alternative mask values is discussed in Section 9. Armitage Expires February 6th, 1995 [Page 12] Internet Draft September 6th, 1994 6.2 Establishing the 224.0.0.1 signalling group. Consider that the transmit side functions independently, as described in section 5. The ARP Server only returns itself as a member of 224.0.0.1, no matter what additional hosts it actually knows about. When multicast hosts on the LIS start up RFC1112 requires that they join 224.0.0.1. The first host to execute JoinLocalGroup to 224.0.0.1 must send an IGMP ATMMC_JOIN to 224.0.0.1. The transmit side has no VC to this group, so it queries the ARP Server. The ARP Server returns itself as the only group member. The host then establishes a multicast VC to the ARP Server, marking it as the VC for traffic to 224.0.0.1. (The reason for a multicast VC is explained at the end of this subsection). Finally the IGMP ATMMC_JOIN is sent over the VC. The ARP Server's IGMP entity receives the ATMMC_JOIN and adds the host to its list of members of 224.0.0.1. The ARP Server maintains a multicast VC out to all members of 224.0.0.1, and it adds the new host as a new leaf node. The ATMMC_JOIN message is not propagated. The second host to execute JoinLocalGroup for 224.0.0.1 will perform exactly the same procedure, with the ARP Server still only returning itself as the only member of 224.0.0.1. The second host establishes a multicast VC to the ARP Server and sends the IGMP ATMMC_JOIN for 224.0.0.1. As for the first host, this results in the second host being added to the ARP Server's list of 224.0.0.1 members. The new host is also added as a leaf node of the ARP Server's 224.0.0.1 multicast VC. The second host's ATMMC_JOIN message is not propagated. This process continues for all IP multicast hosts on the LIS (including IP multicast routers). Once initialised, each IP multicast host on the LIS will have a multicast VC to the ARP Server marked as '224.0.0.1', and an incoming VC from the ARP Server on which IGMP traffic from other hosts will arrive. The VC to the ARP Server for 224.0.0.1 traffic is established as a 'multicast' VC for two reasons: The transmit side of each host does not need 'special case' code to handle 224.0.0.1 any differently from other Class D addresses. A multicast VC uses no reverse path resources, which is reasonable as the reverse path is handled by the multicast VC originating from the ARP Server. Armitage Expires February 6th, 1995 [Page 13] Internet Draft September 6th, 1994 6.3 Joining A General Group X. When a host joins any other IP multicast group it sends an IGMP ATMMC_JOIN to 224.0.0.1. Now the ARP Server's IGMP entity handles things slightly differently. It updates the ARP tables (as before) AND retransmits the IGMP message to all other members of 224.0.0.1. This behaviour is used in section 7 to allow nodes that are already members of a given group to note the new member. The transmission of an IGMP Report to the group being joined causes an ARP request to be issued and the establishment of a VC out the group being joined. If the local host does not transmit to the group for a period of time the inactivity timer will trigger the closure of the VC. This will not alter the hosts 'membership' of the group. 6.4 Redundant IGMP Messages. As a weak form of protection from loss, IGMP messages MUST be retransmitted twice. Host and Router IGMP entities MUST silently discard incoming IGMP 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's IGMP entity MUST propagate all IGMP messages (except as noted in section 6.2). 7. Adding A New Leaf to Outgoing Multicast VC. 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 IGMP entity to inspect ATMMC_JOIN and ATMMC_LEAVE messages arriving on 224.0.0.1. If an ATMMC_JOIN 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. Blocking the propagation of ATMMC_JOINs to 224.0.0.1 by the ARP Server's IGMP entity ensures the 224.0.0.1 group remains a special case. 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 Armitage Expires February 6th, 1995 [Page 14] Internet Draft September 6th, 1994 leaving node. Both are the reverse of the 'join' operations described in section 6 and 7. The ARP Server's response: LeaveLocalGroup results in ATMMC_LEAVE messages being sent to 224.0.0.1 using the same procedure as for ATMMC_JOIN. The ARP Server's IGMP entity notes the event, and removes the specified ATM address appropriately. If an IP multicast host issues a LeaveLocalGroup for 224.0.0.1 it will be considered to have ceased membership of all other groups for which it may have joined. The ARP Server MUST flush that hosts's ATM address from any Class D address entries it appears in. Response of an arbitrary host in the LIS: If an ATMMC_LEAVE 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 ATMMC_LEAVE is seen that refers to group 224.0.0.1 then the ATM address of the host issuing the IGMP messages 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 multicast IP hosts to be members of 224.0.0.1, so leaving 224.0.0.1 is considered to indicate cessation of support for IP multicasting. Normally this is not expected to happen. 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]). Armitage Expires February 6th, 1995 [Page 15] Internet Draft September 6th, 1994 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. 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 IGMP entity monitors 224.0.0.1 for IGMP ATMMC_JOIN and ATMMC_LEAVE messages to update the set of leaf nodes it sends to, 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 ATMMC_JOIN 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. Armitage Expires February 6th, 1995 [Page 16] Internet Draft September 6th, 1994 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 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. In this situation the LIS administrator might configure their multicast routers to exclude sections of the Class D address space when issuing ATMMC_JOIN(s). Another scenario involves the product M*N exceeding the capacity of a single router's interface (especially if the same interface must also Armitage Expires February 6th, 1995 [Page 17] Internet Draft September 6th, 1994 support a unicast IP router service). A LIS administrator may choose to add a second node, to function as a 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. All routers are able to track membership changes through the IGMP ATMMC traffic on 224.0.0.1 anyway. Mechanisms for establishing these modes of operation are beyond the scope of this memo. 10. ARP Server Implementation Issues. This memo specifies the ARP Server's required behaviour, without direct reference to internal architecture or implementation. The ARP tables must be carefully constructed to support 'wild card' entries. Interaction between the IGMP entity, the ARP tables, and the retransmission of IGMP messages on the 224.0.0.1 VC has the potential to generate 'race' conditions if implemented poorly. The ARP Server may need to serialise its processing of 'simultaneous' ARP_REQUEST and IGMP messages, to ensure all multicast nodes remain aware of changes to group memberships. 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 one exception is group 224.0.0.1, for which the ARP Server transparently establishes itself as a Multicast Server. ATM ARP Server role extended. Class D IP addresses may be mapped to 0 or more ATM addresses. Class D address 224.0.0.1 returns only the ARP Server's Armitage Expires February 6th, 1995 [Page 18] Internet Draft September 6th, 1994 address. New ARP message type, ARP_MULTI. ATM 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. IGMP entity added to ARP Server, with ability to modify ARP table entries. Specific handling of 224.0.0.1 membership to create a 'multicast server' architecture. 'wild card' ARP table entries possible, where a single ATM address is simultaneously associated with blocks of Class D addresses. IGMP protocol modified and extended. Two new IGMP messages - ATMMC_JOIN and ATMMC_LEAVE. All IGMP ATMMC messages, from hosts or routers, are sent to 224.0.0.1. IGMP entities on all nodes monitor ATMMC traffic to add or remove leaf nodes to active, outgoing, multicast VCs. 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. No attempt has been made to reconcile or optimise the use of IGMP messages. ATMMC_JOIN and ATMMC_LEAVE contain a superset of the information in an IGMP Report. Robustness of IGMP message exchange. Current mechanism inherits Armitage Expires February 6th, 1995 [Page 19] Internet Draft September 6th, 1994 the RFC 1112 approach of "repeat it a couple of times, and pray". 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 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 I would like to thank John Moy of Cascade Communications Corp. for initially suggesting the idea of wild-card entries in the ARP Server. Author's Address Grenville Armitage MRE 2P340, 445 South Street Morristown, NJ, 07960-6438 USA Email: gja@thumper.bellcore.com References [1] Laubach, M., "Classical IP and ARP over ATM", RFC1577, Hewlett- Packard Laboratories, December 1993 Armitage Expires February 6th, 1995 [Page 20] Internet Draft September 6th, 1994 [2] S. Deering, "Host Extensions for IP Multicasting", RFC 1112, Standford University, August 1989. [3] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption Layer 5", RFC 1483, USC/Information Science Institute, July 1993. [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. Appendix A. UNI 3.0 Multicast Support - A Brief Overview. This section provides a summary of point-to-multipoint signaling procedures. Readers are referred to [4]. [...to be written. will be used as a basis for relevant IEs and signalling behaviour...] Armitage Expires February 6th, 1995 [Page 21]