Internet Engineering Task Force R. Guerin INTERNET DRAFT D. Kandlur D. Williams IBM 17 September 1996 Extensions to the MARS model for Integrated Services draft-kandlur-issll-rsvp-mars-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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This memo describes an extension to the IP multicast architecture now being developed by the IP over ATM working group, also known as MARS (Multicast Address Resolution Server). This extension expands the responsibilities of the Multicast Server (MCS) to adapt it to the Integrated Services Internet Architecture and related signaling protocols such as RSVP. Guerin,Kandlur,Williams Expires 22 March 1997 [Page i] Internet Draft MARS Extension for RSVP 17 September 1996 1. Introduction The MARS document [Arm96] describes a mechanism for handling IP multicast over ATM. Clusters of endpoints, currently defined by IP subnetwork boundaries, share a MARS and use it to track and disseminate information on membership in multicast groups. This allows endpoints to establish VCCs and to transmit to their multicast group over these VCCs. Multicasting is supported using either meshes of VCs or ATM-level multicast servers (MCSs). The choice is made on a per-group basis and is transparent to the endpoints. 1.1. The Problem In a IP/ATM subnetwork using the MARS protocol for IP multicast address resolution, an Multicast Server (MCS) may be used to forward IP multicast datagrams. This Multicast Server is transparent to the end stations and its operation is further defined in [RT96]. An end station (the MARS client) requests the MARS server for resolution of IP multicast addresses and receives a list of ATM addresses. It then creates a virtual connection to members of this list, which may consist of the MCS or all of the local members of the multicast group, to deliver packets addressed to this multicast address. Currently, this connection is set up with best-effort service class. The purpose of this document is to investigate the operation of the MARS/MCS in the presence of IP Integrated Services and RSVP. We consider the ``classical'' framework for handling RSVP and Integrated Services over ATM described in [Ber96b, Ber96a]. In this model, an RSVP ``flow'' is mapped onto an ATM VCC with QoS attributes. The guidelines for this mapping are described in [BG96]. Specifically, for multicast flows, when a source receives a RESV message for a given multicast session, it is responsible for creating a virtual connection with the appropriate quality-of-service specification to match the service requested in the RESV message. However, when an MCS is used, this virtual connection only extends from the source to the MCS (see Fig. 1). The forwarding path from the MCS to the destination end-stations will continue to be best-effort since the MCS has no knowledge of the QoS information, and the delivery mechanisms currently defined for the MCS only specify UBR VCCs. Moreover, since the MCS does not process RSVP messages, the destination stations would not be able to detect this breach of service. Guerin,Kandlur,Williams Expires 22 March 1997 [Page 1] Internet Draft MARS Extension for RSVP 17 September 1996 Figure 1: Data flow with MCS 2. Possible Solutions One solution is to place IP multicast group information in the ATM setup message when the sender creates an ATM VC (to the MCS). The receiver, in this case the MCS, can then use this information to create a QoS VC towards the receivers of the multicast group. It would derive the QoS parameters from the QoS and traffic information elements received in the ATM SETUP message, and IP multicast group information from the information elements reserved for protocol information. Unfortunately, this approach has several deficiencies: 1. the MCS does not have access to RESV messages so it is not able to distinguish between receivers which have made reservations from those that have not made any reservation 2. the MCS would require additional information to handle shared reservations A second approach would be to apply the SBM mechanism [RY96] to ATM. In this approach, the SBM would be co-located with the MCS and Guerin,Kandlur,Williams Expires 22 March 1997 [Page 2] Internet Draft MARS Extension for RSVP 17 September 1996 receivers would send RESV messages to the SBM/MCS. However, it has some disadvantages in the ATM context: 1. unlike the Ethernet environment, the SBM/MCS is used only for reservations for multicast sessions. This requires special mechanism for differentiating between unicast and multicast sessions. 2. it requires either additional configuration of end-stations (for the SBM address) or a cheap multicast mechanism. A third, and we believe more effective, solution would be to make the MCS participate in RSVP signaling by processing IP/RSVP packets. The MCS would intercept PATH messages and change the RSVP_PHOP field to the address of the MCS. This change would ensure that the RSVP agents on the receivers would direct their RESV responses to the MCS. The MCS would process these RESV responses, perform merging as applicable, and then forward them to the appropriate previous hops. The processing done by the MCS is similar to that performed by an RSVP router, or a subnetwork bandwidth manager (SBM). This approach differs from the SBM approach in that the MCS also processes RSVP PATH messages. There are several advantages to this approach: 1. it is transparent to end-stations 2. it does not require any protocol modifications to RSVP 3. it places responsibility on the MCS, which is part of the data forwarding path and, hence, necessarily involved with the setup of QoS connections. 4. it requires no additional configuration to end-stations or a multicast mechanism for discovery of the MCS. 3. Summary This draft described several approaches to handling IP Integrated Services flows in the presence of an MCS. From the discussion, it is apparent that the preferred solution is one in which the MCS is RSVP aware and participates in the signaling process in a manner that is transparent to end stations. Further specification of this approach will be pursued based on the recommendation of the working group. Guerin,Kandlur,Williams Expires 22 March 1997 [Page 3] Internet Draft MARS Extension for RSVP 17 September 1996 References [Arm96] G. Armitage. Support for Multicast over UNI 3.1 based ATM Networks. Internet Draft, draft-ietf-ipatm-ipmc-12.txt, February 1996. [Ber96a] L. Berger. RSVP over ATM: Framework and UNI 3.0/3.1 Method. Internet Draft, draft-berger-rsvp-over-atm-00.ps, June 1996. [Ber96b] S. Berson. IP Integrated Services Support in ATM. Internet Draft, draft-ietf-issll-atm-support-00.ps, June 1996. [BG96] M. Borden and M. Garrett. Interoperation of Controlled-Load and Guaranteed-Service with ATM. Internet Draft, draft-borden-intserv-atm-mapping-00.txt, June 1996. [RT96] M. Ammar R. Talpade. Multicast Server Architectures for MARS-based ATM multicasting. Internet Draft, draft-ietf-ion-marsmcs-00.txt, June 1996. [RY96] D. Hoffman R. Yavatkar, E. Patki. SBM (Subnet Bandwidth Manager): A Proposal for Admission Control over Ethernet. Internet draft, draft-yavatkar-sbm-ethernet-00.txt, June 1996. 4. Authors' Address Roch Guerin IBM T.J. Watson research Center P.O. Box 704 Yorktown Heights, NY 10598 guerin@watson.ibm.com VOICE +1 914 784-7038 FAX +1 914 784-6318 Dilip Kandlur IBM T.J. Watson research Center P.O. Box 704 Yorktown Heights, NY 10598 kandlur@watson.ibm.com VOICE +1 914 784-7722 FAX +1 914 784-6205 Doug Williams IBM T.J. Watson research Center P.O. Box 704 Guerin,Kandlur,Williams Expires 22 March 1997 [Page 4] Internet Draft MARS Extension for RSVP 17 September 1996 Yorktown Heights, NY 10598 dougw@watson.ibm.com VOICE +1 914 784-5047 FAX +1 914 784-6318 Guerin,Kandlur,Williams Expires 22 March 1997 [Page 5]