Simple Multicast - building a case for a BOF or WG

[Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>]

we are interested to see if there is sufficient case to have a BOF, or
even to propose a WG in the IETF - part of the case is the requirement
that there is user dfemand (obviosuly other parts are
feasibility and implementatiuon effort - both SM and Express have
these)

here is a provider contribition, fyi.

comments in general here are just for the sm interest and for the
purpose outlined above
- i assume that
comments to sprint can be made via their representatives in the maddog
community.

again let me remind you: sm is evolutionary, not revolutionary, so
technical suggestions identifying stages or changes or enhancements to current 
protocols and architectures (and including ipv6 enabled ones), are encouraged.

------- Forwarded Message
Subject: Sprint contribution to maddog
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is a Sprint corporate contribution to maddog wrt new IP multicast
services prepared by the operation, marketing, and research entities of
Sprint. Please forward to maddog.

============================================================================

Requirements for the Definition of New IP Multicast Services 

  Christophe Diot, Bryan Lyles, Sprint ATL 
  Brian Neil Levine, Consultant, Sprint ATL 
  Ramanan Shanmugam, Amir Tabdili, Hassan Kassem, Sprintlink 

  IP offers point-to-multipoint and multipoint-to-multipoint best-effort 
  delivery of datagrams by means of the IP Multicast service and 
  architecture. The current IP multicast architecture deployed by
carriers and 
  ISPs is complex and has a limited scalability. This complexity is
mostly due 
  to an unsuitable service model that requires complex mechanisms and 
  protocols to be implemented to solve the following problems: 

  1. Group management (host join authorization, group creation, sending
to 
     a group). 
  2. Security for controlling route computation (i.e., tree
construction) 
     or for avoiding denial-of-service attacks. 
  3. Multicast class-D address allocation. 
  4. Providing accounting information. 
  5. Support for service-level agreements (and for VPN management). 
  6. Providing network-level management capabilities. 

  In the long term, if the current IP multicast service model is used,
such 
  limitations may make successful commercial deployment difficult. 

  The current service model in IP multicast was not defined with a 
  commercial service explicitly in mind. Trying to generalize multicast 
  from this service model may be difficult or, in the worst case, 
  endanger network stability. 

  As a carrier, Sprint consequently encourages the IETF to study 
  network-level IP multicast architectural issues that consider the 
  above mentioned problems. In particular, we recommend: 

  1. Definition of new service models that correspond to carrier 
  and ISP requirements of security and manageability. 

  2. Modification of existing or introduction of new protocols
(including 
  routing) that implement these service models. 

- -- 
=======================================================

christophe Diot         | tel: 1(650)375.4539
Sprint ATL              | fax: 1(650)375.4490
1 Adrian Court          | cdiot@sprintlabs.com
Burlingame CA 94010     | www.sprintlabs.com
USA                     |

------- End of Forwarded Message