Internet Draft INTERNET-DRAFT Norihiro Ishikawa Expires: January 1998 NTT July, 1997 IP Multicast over ATM MLIS using ATM Multicast Routers <draft-ishikawa-ion-mcatm-mlis-00.txt> Status of this Memo This document 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes the specification for IP multicast over ATM MLIS using ATM multicast routers. This memo specifies the protocol for providing the functions of IGMP [1] over the ATM networks. This is the simplest approach among various proposals for IP multicast over the ATM networks including MARS [2], and it is easy to implement this specification compared with other proposals. Ishikawa Expires January 1998 [Page 1] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 1. Introduction This memo describes the specification for IP multicast over ATM MLIS (Multicast Logical IP Subnetwork) using ATM multicast routers. The requirements for this specification for IP multicasting over ATM MLIS are as follows: - To interwork with the MBONE (an experimental multicasting network on the Internet), the specification should be compatible with the basic specifications for IP multicasting such as RFC 1112 [1] and the multicast routing protocols such as RFC 1075 [3]. It should also interwork with routers and hosts in which such specifications are implemented. - To be compatible with RFC 1112 on the service interface level with upper-layer protocol modules so that the existing multicast applications can operate over ATM networks. - To accomplish IP multicasting over ATM networks efficiently, the specification should be able to effectively use the point-to- multipoint connection that ATM networks provide. - It should be compatible with the specifications for IP over ATM networks such as RFC 1577 [4] and RFC1755 [5] and be able to use these protocols when necessary. As a mechanism to satisfy above requirements, this memo describes the specification for IP multicasting over ATM MLIS using ATM multicast routers. This memo assumes that "The ATM Forum UNI Specification, V 3.0/3.1" is used as the interface with ATM networks. 2. Model A model for IP multicasting over ATM MLIS using ATM multicast routers is described below. A sending host sends multicast IP datagrams to an ATM multicast router, using an ATM point-to-point connection. An ATM multicast router distributes received multicast IP datagrams toward multiple receiving hosts, using an ATM point-to-multipoint connection. A receiving host receives multicast IP datagrams from an ATM multicast router. An ATM multicast router may send received multicast IP datagrams to existing IP multicast networks such as MBone, if it has an existing router function (e.g. by implementing RFC 1075). When an ATM multicast router with the existing router functions has interfaces with both ATM networks and the existing LANs such as Ethernet, the IP multicast communication between those networks becomes possible. Ishikawa Expires January 1998 [Page 2] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 3. Overview of IP Multicasting The overview of IP multicasting specified in RFC 1112 is described below. The purpose of IP multicasting is to transfer IP datagrams to host groups (0 or more hosts identified by a single IP destination address). Multicast IP datagrams are transferred to all hosts in the host group. The membership of a host group is dynamic; that is, hosts may join or leave groups at any time. A multicast IP datagram is transferred to other networks by a multicast router in the same way as regular IP datagrams. There are three levels in the implementation of IP multicasting in hosts. (1) Level 0: no support for IP multicasting. There is obviously no requirement regarding the support. Level 0 hosts discard multicast IP datagrams with class D destination addresses. (2) Level 1: support for sending multicast IP datagrams only. Implementations of Level 1 hosts are relatively easy. (3) Level 2: full support for IP multicasting. Level 2 hosts can join or leave host groups. Implementation of the IGMP (Internet Group Management Protocol) is required. Host groups are identified by class D IP addresses, i.e., those starting with 110 Class D IP addresses range from 224.0.0.0 to 239.255.255.255. The address of 224.0.0.0, however, is not assigned to any group. The address of 224.0.0.1 is always assigned to a group that includes all hosts in the subnetwork. 4. Overview of Point-to-Multipoint Connection of ATM Networks The overview of the point-to-multipoint connection specified in the ATM Forum UNI 3.0/3.1 is described below. The following restrictions apply in the point-to-multipoint connection specified in the ATM Forum UNI 3.0/3.1. - Only a root can set up a point-to-multipoint connection and add a leaf. - ATM cells are transferred from the root to the leaves only. Ishikawa Expires January 1998 [Page 3] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 The specification for IP multicasting over ATM MLIS should be designed based on the above restrictions. NOTE: These restrictions may be relaxed in future versions of the ATM Forum UNI. The setup and release procedures of the point-to-multipoint connection are as follows. (1) The first connection from the root to the leaf is set using a SET UP/CONNECT message as in the point-to-point connection. (2) After that, the root can add new leaves at any time using an ADD PARTY/ADD PARTY RESPONSE message. (3) The root or leaf can delete new leaves at any time using a DROP PARTY/DROP PARTY RESPONSE message. 5. Implementation Model The implementation model of the IP multicasting over ATM MLIS on a host and an ATM multicast router is shown below. This model is for expository purpose only, and should not be construed as constrainind an actual implementation. | | | Upper-Layer Protocol Modules | |______________________________________________________| --------------- IP Service Interface ----------------------- _______________________________________________________ | | | | | | ICMP | IGMP-ATM | | IP |___________|_______________| | Modules | |_____________________________________________________| ------------- ATM Service Interface ------------------------ _______________________________________________________ | | | | | RFC 1577 (IP/ATM | RFC 1755 (ATM | RFC 1483 (IP | | Address Resolution) | Signalling | Encapsulation)| |_____________________________________________________| | | | ATM | Ishikawa Expires January 1998 [Page 4] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 The IGMP-ATM is a protocol for IP multicasting over ATM MLIS, based on IGMP. RFC 1577 is used to resolve IP addresses to ATM addresses. The LLC encapsulation specified in RFC 1483 is used for IP encapsulation over ATM networks. Level 1 hosts must be implemented with the transmission of multicast IP datagrams. In addition, Level 2 hosts and ATM multicast routers must be implemented with the reception of multicast IP datagrams. The transmission and reception procedures of multicast IP datagrams are described below. 6. Transmission Procedures of Multicast IP Datagrams The transmission procedures of multicast IP datagrams are the same as in unicast IP datagrams from the point of view of the upper-layer protocol module. When transmitting a multicast IP datagram, upper- layer protocol modules designate a class D IP address identifying a host group as a destination address. The IP module of the sending host that has received a request to transmit a multicast IP datagram sends a multicast IP datagram in the following procedure: (1) The ATM address is resolved from the IP address of an ATM multicast router in the following procedure: (a) The ATM address is resolved from the IP address by accessing to the ATMARP server according to RFC 1577. (2) When a VCC for data transfer has not been set with an ATM multicast router, a VCC for data transfer will be set between the sending host and the ATM multicast router using the ATM address of the ATM multicast router. (3) A multicast IP datagram is sent using the VCC for data transfer. If the sending host is also an ATM multicast router, it omits the above procedure and executes the following: Ishikawa Expires January 1998 [Page 5] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 The operation of the IP module of the ATM multicast router that has received a multicast IP datagram from a sending host or a request to transmit a multicast IP datagram from an upper-layer protocol module is as follows: (1) The IP module retrieves the conversion table of the destination address of the multicast IP datagram (that is, the class D address that identifies the host group) and the VCC for data transfer, in order to check whether the VCC for data transfer that transfer the received multicast IP datagram has been set up. (2) If the VCC for data transfer has been set up, the multicast IP datagram will be sent by using the VCC. If the VCC for data transfer has not been set up, the multicast IP datagram will be discarded. NOTE: When there are more than one VCCs for the transfer of the multicast IP datagram, the multicast IP datagram will be sent to each of them. The multicast IP datagram will be locally looped back only when the sending host is an ATM multicast router and a receiving host at the same time. NOTE: When the sending host is also a receiving host but not an ATM multicast router, the multicast IP datagram will not be locally looped back. Instead, the transmitted multicast IP datagram is received from the ATM multicast router. In addition, when the ATM multicast router also has an existing multicast router function (e.g. by implementing RFC 1075), it may send a multicast IP datagram to existing IP multicast networks, according to the specification for routing of multicast IP datagrams (e.g. RFC 1075). NOTE: The specification of interworking with existing IP multicast networks is out of the scope of this memo. 7. Reception Procedures of Multicast IP Datagrams The reception procedures of multicast IP datagrams are the same as in unicast IP datagrams from the point of view of the upper-layer protocol module. Selection of the upper layer protocol is based on the protocol field in the IP header, regardless of the IP destination address. However, before any multicast IP datagrams are received, an upper-layer protocol must notify the IP module that it will join the host group. Thus, the IP service interface must be extended to provide two operations: - JoinHostGroup (group-address, ATM interface) - LeaveHostGroup (group-address, ATM interface) Ishikawa Expires January 1998 [Page 6] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 The JoinHostGroup operation requests that this host becomes a member of the host group identified by the group-address on the ATM interface. More than one high layer protocols may request to become members of the same host group. The LeaveHostGroup operation requests that this host give up its membership in the host group identified by the group-address on the ATM interface. Both operations should return immediately (i.e., they are non-blocking operations), indicating success or failure. They may fail due to an invalid group-address or ATM interface. The JoinHostGroup operation may fail due to lack of local or remote resources. The LeaveHostGroup operation fails when the receiving host does not belong to the host group identified by the given group-address on the ATM interface. The IP module of the receiving host should keep the list of host groups on each ATM interface to support the reception of multicast IP datagrams. When a received multicast IP datagram has a destination address that is not registered in the list of host groups, it will be discarded. When a eceived multicast IP datagram has a class D IP address identifies the host group as the source IP address, it will be discarded. In this case, an ICMP error message will not be generated as a response. The list of host groups is updated in response to JoinHostGroup and LeaveHostGroup requests from upper-layer protocol modules. Each host group has a counter mechanism to handle multiple requests to join and leave the same group. The value of the counter increases by one when a JoinHostGroup request is received and decreases by one when a LeaveHostGroup request is received. When the value of the counter becomes zero, the host group will be deleted from the list. The operation of the IP module that has received a JoinHostGroup request is as follows: (1) The IP module will increase the value of the counter by one and end the operation if the host group that is identified by the group-address already exists in the list. (2) The operation in the case where the host group that is identified by the group-address does not exist in the list is as follows: (3) When a VCC for control is not set up with the ATM multicast router, the IP module will set up a VCC for control between the receiving host and the ATM multicast router by using the ATM address of the ATM multicast router. Ishikawa Expires January 1998 [Page 7] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 NOTE: The resolution procedure of the IP address of the ATM multicast router into its ATM address is the same as the the procedure specified in section 6. (4) The IP module sends a Join message of the IGMP-ATM specified in section 8 using the VCC for control. (5) The IP module adds the host group that is identified by the group-address to the list and sets the value of the counter to 1. The operation of the IP module that has received a LeaveHostGroup request is as follows: (1) The IP module decreases the value of the counter of the host group that is identified by the group-address by one. If the value of the counter is one or larger, the operation ends here. (2) The operation in the case where the value of the counter becomes 0 is as follows: (3) The IP module sends a Host Membership Leave message of the IGMP-ATM specified in section 8 using the VCC for control. (4) It deletes the host group that is identified by the group-address from the list. (5) When the number of members included in the list becomes zero, the VCC for control may be released. NOTE: Whether the VCC for control should be released or not shall be locally determined by the receiving host. The ATM multicast router manages the list of the IP addresses of the hosts joined in the host group for each host group. The operation of the ATM multicast router that has received a Join message of the IGMP-ATM is as follows: (1) The ATM multicast router retrieves the conversion table of the group-address (i.e. the class D IP address that identifies the host group) and the VCC for data transfer, in order to check whether the VCC for data transfer corresponding to the received group-address exists Ishikawa Expires January 1998 [Page 8] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 (2) If the VCC for data transfer exists, the ATM multicast router adds the receiving host as a leaf of the VCC for data transfer by using the ADD PARTY/ADD PARTY ACK procedure. It also adds the IP address of the receiving host to the list of the IP addresses of the hosts that have joined the host group identified by the received group address. NOTE: It may set up a new VCC for data transfer for such reasons as the QOS control. (3) If the VCC for data transfer does not exist, the ATM multicast router sets up a VCC for data transfer between the ATM multicast router and the receiving host by using the ATM address of the receiving host. NOTE: The VCC shall be a point-to-multipoint connection. (4) If the setup of the VCC for data transfer succeeds, the ATM multicast router sends a Join Ack message of the IGMP-ATM to the receiving host and adds the relation of the group address with the VCC for data transfer to the conversion table. It creates a list of the IP addresses of the hosts that have joined the host group and adds the IP address of the receiving host to it. (5) If the setup of the VCC for data transfer fails due to some reason (e.g. lack of resources etc.), the ATM multicast router sends a Join Nak message of the IGMP-ATM to the receiving host. The operation of the ATM multicast router that has received a Host Membership Leave message of the IGMP-ATM is as follows: (1) The ATM multicast router deletes the leaf to the receiving host from the VCC for data transfer that is set up for the received group address, by using the DROP PARTY/DROP PARTY ACK procedure. (2) The ATM multicast router deletes the IP address of the receiving host from the list of the IP addresses of the hosts that have joined the host group identified by the received group-address. (3) If the number of members in the list becomes zero as a result, the ATM multicast router deletes the list and releases the VCC for data transfer. It also deletes the the relation of the group-address with the VCC for data transfer from the conversion table. NOTE: The above is the operation in the case where all leaves are deleted from the VCC for data transfer. Ishikawa Expires January 1998 [Page 9] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 8. Protocol Specification (IGMP-ATM) The protocol (IGMP-ATM) used for IP multicasting over ATM MLIS using the ATM multicast router is described below. IGMP-ATM is a protocol for IP multicasting over ATM MLIS, based on IGMP specified in RFC 1112 and hence compatible with IGMP. IGMP-ATM is used between receiving hosts and ATM multicast routers. Therefore, Level 2 hosts and ATM multicast routers must implement IGMP-ATM. IGMP-ATM messages are encapsulated in IP datagrams, with an IP protocol number of 2 as in IGMP. 8.1 Format of IGMP-ATM Messages The format of IGMP-ATM messages is as follows: 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 | Unused | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (1) Version The version of this specification shall be ?. (2) Type The types of IGMP-ATM messages are as follows: 2= Host Membership Join 3= Join Ack 4= Join Nak 5= Host Membership Leave NOTE: The Host Membership Join (2) is called the Host Membership Report (2) in IGMP specified in RFC 1112. (3) Unused Unused field, zeroed when sent, ignored when received. (4) Checksum The checksum is the 16-bit one's complement of the one's complement sum of the IGMP-ATM message. For computing the checksum, the checksum field is zeroed. Ishikawa Expires January 1998 [Page 10] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 (5) Group Address In the case of Host Membership Join (2), the address of the host group requesting the receiving host to join will be set. In the case of Join Ack (3) and Join Nak (4), the address of the host group requested to join by the receiving host will be set. In the case of Host Membership Leave (5), the address of the host group requesting the receiving host to leave will be set. (6) Reason The reason why joining a host group has failed. This field (including unused) exists in the case of Join Nak (4) only. 1= Not specified 2= Lack of resources at the ATM multicast router 3= Data of this group-address not received at the ATM multicast router 4= Authentication of the receiving host has failed. NOTE: Other values may be defined in future. (7) Options The following optional parameters may be set following the fixed parameters described above. The format of the optional parameters is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option1 | Option2 | ... | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thus, padding is added in the end, in order to complete them in 32-bit boundary. The value of padding is zero. The format of each optional parameter is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Data Length | Option Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type: An 8-bit identifier of the option type Option Data Length: Length of the option data in octet (8 bits) Option Data: Data specific to each option with variable length Ishikawa Expires January 1998 [Page 11] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 The following optional parameters are specified in this memo. (a) Authentication This parameter is used to authenticate receiving hosts and users on them. This parameter can only be used in the case of Host Membership Join (2). Option Type: 1 The format of the option data is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Type | Authentication Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication Type: An 8-bit identifier of the type of authentication Authentication Data: Data specific to each authentication type with variable length NOTE: The definition of specific authentication types is for further study. 8.2 Operation of the Protocol The IP module of the receiving host that has received a JoinHostGroup request transmits a Join message to the ATM multicast router. The IP address of the ATM multicast router is set in the IP destination address. The address of the host group which the receiving host requests to join is set in the Group Address field of the Join message. The ATM multicast router that has received a Join message sends a Join Ack message to the receiving host that has transmitted the Join message, if it succeeds to set up a VCC for data transfer. It sends a Join Nak message to the receiving host, if it fails to set up a VCC for data transfer. The IP address of the receiving host that has transmitted the Join message is set in the IP destination address field. The same value as that of the Group Address field in the received Join message is set in the Group Address field of the Join Ack/Join Nak message. The reason why the setting of the VCC for data transfer has failed is set in the Reason field of the Join Nak message. The ATM multicast router fails to set up a VCC for data transfer in the following cases: Ishikawa Expires January 1998 [Page 12] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 - The ATM multicast router could not get enough resources necessary to set up a VCC for data transfer - The ATM multicast router could not receive the data toward the designated group address. - Authentication of the receiving host failed. etc The IP module of the receiving host that has received a LeaveHostGroup request sends a Host Membership Leave message to the ATM multicast router. The IP address of the ATM multicast router is set in its IP destination address field. The address of the host group which the receiving host requests to leave is set in the Group Address field of the Host Membership Leave message. When invalid IGMP-ATM messages as shown below are received, they will be discarded: - IGMP-ATM messages with invalid fields - IGMP-ATM messages received in invalid conditions 9. Security Considerations The authentication parameter is added to the Host Membership Join message, so that unauthorized receiving hosts can not join the host group. However, the definition of the format of the authentication parameter for the specific authentication mechanism is for further study. Ishikawa Expires January 1998 [Page 13] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 Appendix 1: Differences between IGMP and IGMP-ATM This appendix describes major differences between IGMP and IGMP-ATM. (1) Sending and receiving of IP multicast datagrams via an ATM multicast router Since IGMP is designed assuming that shared media LANs such as Ethernet is usually used, a receiving host receives IP multicast datagrams directly from a sending host on the same local network. A sending host sends IP multicast datagrams to receiving hosts via an ATM multicast router in IGMP-ATM, even if receiving hosts reside on the same MLIS as the sending host. IGMP-ATM does not support the multicast VC mesh, because the multicast VC mesh lacks the scalability. (2) Hard state approach vs Soft state approach Since IGMP adopts the soft state approach, a multicast router sends Host Membership Query messages periodically using the all-hosts group (address 224.0.0.1), to discover which host groups have members on its attached local network. Since ATM is a connection oriented network, IGMP-ATM adopts the hard state approach. IGMP-ATM does not send Host Membership Query messages. Instead, IGMP-ATM manages receiving hosts on the attached ATM network, based on the reception of Host Membership Join messages and Host Membership Leave messages from receiving hosts. (3) Authentication of receiving hosts IGMP does not provide any security functions. IGMP-ATM defines the authentication parameter as an option parameter of the Host Membership Join message, so that unauthorized receiving hosts can not join the host group. Ishikawa Expires January 1998 [Page 14] INTERNET-DRAFT IP Multicast over ATM using MRouters July, 1997 References [1] S. Deering, "Host Extensions for IP Multicasting", RFC 1112, Stanford University, August 1989. [2] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, Bellcore, November 1996. [3] D. Waitzman, C. Partridge, S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988. [4] M. Laubach, "Classical IP and ARP over ATM", RFC 1577, Hewlett-Packard Laboratories, December 1993. [5] M. Perez, F. Liaw, D. Grossman, A. Mankin, E. Hoffman, A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755 February 1995. Acknowledgements The author would like to thank Brian Carpenter and Yakov Rekhter for their comments and suggestions. Authors' Address: Norihiro Ishikawa NTT Information and Communication Systems Laboratory 1-1 Hikarino-oka Yokosuka-Shi Kanagawa 239 Japan isic@isl.ntt.co.jp +81 468 59 2434 (tel) +81 468 59 3796 (fax) Ishikawa Expires January 1998 [Page 15]