Subject: New Internet Draft on IP multicasting over ATM

From: [email-masked] (Ajay Bakre)
Date: Wed, 26 Nov 1997 11:14:25 -0800

Hi,

The following Internet Draft was submitted to the IETF, but it 
probably missed the deadline by a few minutes. I am sending a
copy to the ION and ISSLL mailing lists, as the draft is relevant
to the charter of both working groups. Any comments, questions
and suggestions will be appreciated.

Thanks.

--Ajay Bakre

C&C Research Labs, NEC USA, Inc.
110 Rio Robles, San Jose, CA 95134.
Phone: 408-943-3034, Fax: 408-943-3099
Email: [email-masked]

------------------------------------------------------------------------

Internet Draft 	                                              Ajay Bakre
File: draft-bakre-mcast-atm-00.txt                       Takeshi Nishida
Expiration: May 1998                                   C&C Research Labs
                                                           NEC USA, Inc.
                                                           November 1997

       IP Multicast over ATM Networks with Cut-through Forwarding
			for Inter LIS Traffic

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. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet 
   Drafts as reference material or to cite them other than as a 
   "working draft" or "work in progress."
 
   To learn the current status of any Internet-Draft, please check the
   "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 document proposes a scheme for IP multicasting in ATM networks, 
   which can achieve cut-through forwarding for inter LIS multicast 
   traffic using ATM protocols. 

1. Introduction

   The emergence of NHRP [8] as an alternative to hop-by-hop routing for
   IP unicast traffic has given rise to hopes that a similar solution 
   can be developed for IP multicast as well. The problems associated 
   with extending multicast address resolution to the inter LIS case 
   have been well documented in [3] and [4]. In particular, scalability 
   and VC management issues make it impractical to extend multicast 
   address resolution to inter LIS multicast routing.

   This document proposes an alternate scheme based on ATM protocols,
   which can provide true shortcut paths for inter LIS multicast traffic
   in a multi-LIS ATM cloud. By true shortcut paths we mean the paths
   resulting from the use of ATM signaling without regard to the way
   LISs are interconnected. The proposed scheme is described informally.
   The primary goal of this document is to encourage a renewed 
   discussion on the feasibility of cut-through forwarding for inter LIS
   multicast traffic.

Bakre, Nishida	           Expires: May 1998                    [Page 1]

Internet Draft            Inter LIS Multicast             November, 1997

2. Proposed Scheme

   The proposed IP multicasting scheme is based on multicast switches. 
   A multicast switch is somewhat similar to a switch-router in the 
   sense that it is capable of packet level forwarding as well as cell 
   level forwarding. However, a multicast switch also has some important
   differences from a switch-router. First, unlike a router, which can 
   be a part of multiple LISs, a multicast switch is part of exactly one
   LIS. Thus instead of multiple IP interfaces, a multicast switch 
   essentially has only two "sides" - on one are the IP/ATM hosts within
   its LIS, on the other are all other multicast switches and IP/ATM
   hosts in the ATM cloud. Second, instead of using one of the IP based
   multicast routing protocols for hop-by-hop forwarding of multicast
   traffic, multicast switches treat the ATM cloud as a shared network
   where each multicast switch is just one hop away from all other
   multicast switches.

   Using the features mentioned above allows achieving many important
   objectives. First, it allows aggregation of receivers inside an LIS,
   these receivers being represented in the ATM cloud by the multicast 
   switch in the LIS. Second, for inter-LIS multicast forwarding, VCs 
   are established among multicast switches using ATM signaling giving 
   true shortcuts regardless of how individual LISs are interconnected.
   Third, multicast switches can concatenate intra LIS VCs with inter 
   LIS VCs to achieve cut-through forwarding through those switches. 
   Fourth, multicast forwarding within the ATM cloud can be separated
   from the traditional routing considerations of "reverse shortest
   path". This greatly simplifies inter LIS multicast forwarding.

3. Intra LIS Multicasting

   For multicasting within an LIS, the designated multicast switch in
   the LIS can also function as a multicast server (MCS), albeit with
   an important difference. Unlike the MCS proposed in [9], which only
   uses packet level forwarding, a multicast switch can support both 
   cell level and packet level forwarding. Which method is used for a 
   given multicast group depends on considerations such as the number of
   senders and receivers for that group within the LIS and the need for
   QoS based multicast using RSVP. A multicast switch thus takes over 
   the VC management function from individual senders, but leaves the 
   option open for either concentrating the traffic from multiple 
   senders on a single point to multipoint intra-LIS data VC or 
   establishing a separate VC for each sender. As an example, if the 
   number of senders within the LIS is small, separate VC trees may be 
   established for each sender by the multicast switch (also see the 
   section on QoS considerations below).

Bakre, Nishida	           Expires: May 1998                    [Page 2]

Internet Draft            Inter LIS Multicast             November, 1997

4. Inter LIS Multicasting

   For multicasting across LIS boundaries, multicast switches in
   individual LISs form a control tree among themselves. This control
   tree may consist of point to multipoint VCs, one rooted at each
   multicast switch with all other multicast switches added as leaves.
   Another possibility is to have a mesh of point to point VCs
   interconnecting pairs of multicast switches, which may be the method
   of choice for QoS multicast (see the section on QoS considerations).
   Scalability issues are considered in another section later. A
   multicast switch can learn about other multicast switches in the ATM
   cloud through various mechanisms, e.g. by tagging and propagating
   such information via PNNI updates.

   The control tree is used by multicast switches to exchange group 
   membership information about their respective LISs. Multicast 
   switches can learn about the existence of senders and receivers 
   within their LISs from their local MARSs. On discovering a sender 
   within its LIS, a multicast switch can learn about the existence of 
   receivers in other LISs from the information exchanged with other 
   multicast switches in the ATM cloud. To form an inter LIS multicast 
   tree, a multicast switch that has a sender within its LIS, 
   establishes a point to multipoint data VC to all other multicast 
   switches that have receivers within their LISs. ATM signaling is used
   to establish the inter LIS VC ensuring true shortcut paths to all 
   downstream multicast switches. Multicast switches added as leaves to
   this inter LIS VC in turn form intra LIS data VCs within their 
   respective LISs for distribution of the multicast traffic originating
   at senders within as well as outside their LISs. Whether a multicast 
   switch aggregates traffic from multiple senders within its LIS on a 
   single outgoing inter LIS VC or whether different inter LIS VCs are 
   formed for each local sender, can be decided by individual switches.
   The latter method allows cell level forwarding and may be suitable
   for QoS traffic, but can be wasteful if the number of senders in an 
   LIS is large. Downstream (receiving) multicast switches in turn 
   determine how to distribute traffic from multiple senders (both local
   and external). The alternatives range from aggregating all traffic 
   for local receivers on a single intra LIS VC to having a separate VC
   for each sender.

   If separate intra and inter LIS VCs are established by each multicast
   switch for each sender, individual multicast switches can concatenate
   incoming and outgoing VCs to form a complete multicast tree for each
   sender. This allows cell level (cut-through) forwarding from the
   sender to all the receivers. Any aggregation of senders on the other
   hand, will involve packet level forwarding at the point of 
   aggregation to prevent cell interleaving, although no routing lookup
   is needed at the multicast switches once the VCs are established.

Bakre, Nishida	           Expires: May 1998                    [Page 3]

Internet Draft            Inter LIS Multicast             November, 1997

5. Interoperation with External Mrouters

   Interoperation with Mrouters outside the ATM cloud is achieved by
   edge multicast switches. A multicast switch configured as an edge
   switch participates in one or more IDMR protocols that may be in
   use on its non-ATM interfaces. In addition, all edge switches in
   an ATM cloud cooperate to partition the external networks in a way
   that allows one of the edge switches to become the designated
   forwarder for each external subnet (or IP network). What this means
   is that if traffic from an outside sender arrives at one or more
   edge switches, only one of them (the designated forwarder for the
   sender's subnet) will establish an inter LIS data tree within the 
   ATM cloud. All the edge switches can forward traffic originating
   inside the ATM cloud to outside Mrouters however. This includes 
   multicast traffic that uses the ATM cloud as a transit network 
   (possibly with some receivers in the ATM cloud as well).

6. Scalability Issues for Multicast Switches

   If the number of LISs (and multicast switches) in an ATM cloud is
   large, the requirement in the proposed scheme that each multicast 
   switch exchange multicast group membership information with all other
   multicast switches in the ATM cloud, may be hard to implement. In 
   such a case, a hierarchy of multicast switches analogous to the PNNI
   hierarchy may be used such that multicast switches in a PNNI domain 
   exchange complete group membership information with each other, but 
   only summarized information is exchanged at the higher levels. In 
   such a case, an inter LIS multicast tree will consist of individual 
   inter LIS trees in each PNNI domain together with any VCs required to
   interconnect such trees across domain boundaries. One proposal for 
   using the PNNI hierarchy for multicasting in ATM networks can be 
   found in [10].

7. QoS Considerations

   To support IP Integrated Services over ATM networks using RSVP [5], 
   multicast switches also provide termination points for RSVP messages
   originating in their respective LISs. Aggregate QoS requests based on
   RESV messages from individual LISs can be forwarded to one or more 
   multicast switches that have local senders. These multicast switches
   can then establish inter LIS data VCs with sufficiently large QoS 
   parameters, to satisfy all downstream reservations. 

   Additional control VCs are needed within each LIS for propagating
   RSVP control messages. A single point to multipoint control VC from
   a multicast switch to all registered multicast receivers in an LIS
   can be shared by all multicast groups for the distribution of PATH
   messages from local and external senders. QoS receivers will need 

Bakre, Nishida	           Expires: May 1998                    [Page 4]

Internet Draft            Inter LIS Multicast             November, 1997

   additional point to point control VCs to send RESV messages back to 
   the local multicast switch.

8. Related Work

   Cell switch routers (CSRs) [7] can provide shortcut paths through
   IP routers. One problem associated with CSRs is that simple
   concatenation of intra LIS VCs does not necessarily yield a true
   shortcut path from a sender to one or more receivers, as these VCs
   are formed individually using IP routing information. Another scheme
   proposed for shortcut multicast routing is the IMSS proposal [1], 
   which uses two different protocols, namely CONGRESS and IP-SENATE, to
   resolve IP multicast addresses to ATM addresses of downstream routers
   and to establish inter-LIS shortcut paths to such routers. This 
   scheme consists of fairly complex protocols and attempts to solve a 
   very general problem of IP multicasting in ATM, using a mix of 
   routers that are capable of shortcut forwarding as well as hop-by-hop
   forwarding. By contrast, the scheme proposed in this document focuses
   on providing a simple shortcut forwarding solution for inter LIS 
   multicast traffic in an ATM cloud that uses IDMR protocols only at 
   the edge switches.

9. Conclusion

   A scheme for IP multicasting was proposed in this document that 
   allows cut-through forwarding of inter LIS multicast traffic. The
   scheme is based on multicast switches and includes methods of
   establishing intra and inter LIS VCs for data and control traffic.

10. Security Considerations

   Security considerations are not addressed in this document.

11. Intellectual Property Considerations

   NEC may seek patent or other intellectual property protection for
   some aspects discussed in this document.

12. Acknowledgments

   The authors have benefitted from discussions with the following
   persons in preparing this document: Dipankar Raychaudhuri, Arup
   Acharya, Rajiv Dighe, Kunihiro Taniguchi, Hiromitsu Sakamoto and 
   Bala Rajagopalan.

13. References

   [1] Anker, T., et al., "IMSS: IP Multicast Shortcut Service", Work
       in Progress, July 1997.

Bakre, Nishida	           Expires: May 1998                    [Page 5]

Internet Draft            Inter LIS Multicast             November, 1997

   [2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM 
       Networks", RFC 2022, November 1996.

   [3] Armitage, G., "Issues affecting MARS Cluster Size", RFC 2121,
       March 1997.

   [4] Armitage, G., "VENUS - Very Extensive Non-Unicast Service", RFC 
       2191, September 1997.

   [5] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) -- 
       Version 1 Functional Specification", RFC 2205, September 1997.

   [6] Crawley, E., et al., "A Framework for Integrated Services and 
       RSVP over ATM", Work in Progress, November 1997.

   [7] Katsube, Y., et al., "Toshiba's Router Architecture Extensions 
       for ATM : Overview", RFC 2098, February 1997.

   [8] Luciani, J., et al., "NBMA Next Hop Resolution Protocol (NHRP)",
       Work in Progress, September 1997.

   [9] Talpade, R. and Ammar, M., "Multicast Server Architectures for 
       MARS-based ATM multicasting", RFC 2149, May 1997.

   [10] Venkateswaran, R. and Raghavendra, C.S., "Hierarchical Multicast
       Routing in Wide-Area ATM Networks", Proc. ICC '96, June 1996.

   [11] ATM Forum, "ATM User-Network Interface (UNI) Signalling
       Specification Version 4.0", af-sig-0061.000, July, 1996.

   [12] ATM Forum PNNI subworking group, "Private Network-Network
       Interface Specification Version 1.0 (PNNI 1.0)", afpnni-0055.000,
       March 1996.

14. Authors' Addresses

   Ajay Bakre
   C&C Research Labs, NEC USA, Inc.
   110 Rio Robles, San Jose
   CA 95132, USA.
   Phone: +1-408-943-3034
   Email: [email-masked]

   Takeshi Nishida
   C&C Research Labs, NEC USA, Inc.
   110 Rio Robles, San Jose
   CA 95132, USA.
   Phone: +1-408-943-3030
   Email: [email-masked]

Bakre, Nishida	           Expires: May 1998                    [Page 6]

---

From: Joel Halpern <[email-masked]>
Date: Wed, 26 Nov 1997 15:02:17 -0500 (EST)

Your section 5 (Interworking with External Mrouters) and in particular the
section where you say "the border routers will cooperate to make sure that
only one of them is the ATM entry for any given IP source network" is the
tricky part.  If we could pull that off, many schemes for IP/ATM multicast
shortcuts would become possible.
Can you explain how you propose to do that?

Yours,
Joel M. Halpern                         [email-masked]
Newbridge Networks Inc.