[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Submitted to RAMA Working Group                                  D. Ooms
INTERNET DRAFT                                                 W. Livens
<draft-ooms-cl-multicast-00.txt>                                 Alcatel

                                                              June, 1999
                                                  Expires December, 1999

                        Connectionless Multicast


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This draft proposes a new mechanism for multipoint-to-multipoint
   (mp2mp) communication in IP networks, namely Connectionless Multicast
   (CLM).  Instead of a group address, a list of member addresses is
   encoded in the data packets.

   The current Host Group Model [DEER] for IP multicast requires a
   globally unique address for each session.  To support this model,
   multicast routing protocols create state per group in the routers.
   Like any connection oriented protocol, it suffers from scalability
   problems in backbone networks where the number of groups to be
   maintained can be huge.  CLM does not have this problem, and
   additionally has some other advantages.  Its limitation lies in the
   number of members per multicast session.




Ooms, et al.             Expires December 1999                  [Page 1]


Internet Draft       draft-ooms-cl-multicast-00.txt            June 1999


   The pros and cons of CLM are described and some suggestions are made
   to alleviate the disadvantages.  Furthermore different modes of
   operation are described: an end-to-end mode as well as an
   interworking mode with PIM-SM and Simple Multicast.  Both IPv4 and
   IPv6 are considered.


Table of Contents

   1. Introduction
   2. Description
   3. Working modes
   3.1. Simple Multicast
   3.2. PIM-SM
   3.3. End-to-end
   4. IP Protocol extensions
   4.1. IPv4
   4.2. IPv6
   5. Caching
   6. Compression
   7. Security Considerations
   8. Acknowledgements




   Table of Abbreviations

   CLM     ConnectionLess Multicast
   IRC     Internet Relay Chat
   mp2mp   multipoint-to-multipoint
   PIM-SM  Protocol Independent Multicast Sparse Mode
   RUN     Receiver Update Notification
   SM      Simple Multicast


1. Introduction

   The current IP multicast model is based on the Host Group Model
   [DEER].  In this model a group of hosts is identified by a multicast
   address.  This address is used both for subscription and forwarding
   purposes.

   Current multicast routing protocols which use this model suffer two
   major problems:

   - Multicast Address Allocation.  The creator of a multicast group
   must allocate a global unique multicast address.  This issue is



Ooms, et al.             Expires December 1999                  [Page 2]


Internet Draft       draft-ooms-cl-multicast-00.txt            June 1999


   addressed in the malloc working group: a set of Multicast Address
   Allocation Servers (MAAS) and three protocols (MASC, AAP, MADCAP) are
   proposed.

   - Scalability.  Within the framework of the Host Group Model several
   multicast routing protocols are proposed.  These multicast routing
   protocols have messages which create state for each multicast group
   in all the on-tree routers (or non-on-tree routers in case of dense
   mode).  This can be viewed as signaling that creates multicast
   connection state ,yielding huge multicast forwarding tables in the
   backbone.  Moreover for the sparse mode protocols (CBT, PIM-SM) the
   global core advertisement poses additional scalability issues, while
   the dense mode protocols (PIM-DM, DVMRP) suffer from the flood&prune
   nature.

   Recently, changes to the Host Group Model were proposed to address
   these drawbacks.

   Simple Multicast [PERL] uses the couple of core and multicast
   addresses as the group identifier.  In this way core advertisement
   and multicast address allocation can be avoided.  Furthermore, state
   can be avoided in parts of the network by creating tunnels.  Note
   however that these tunnels are point-to-point and if e.g. a link has
   n tunnels for a certain group it will still carry n times the same
   data.

   In Express [HOLB], a multicast channel is identified by source and
   multicast addresses.  Thus address allocation is not required and
   since there is no core, there is no core advertisement either.
   Creating a multicast session with multiple changing sources is
   implemented by using a session manager and a set of multicast
   channels.  Note that each on-tree node still keeps state for each
   source of the multicast session.


2. Description

   In the Host Group Model the packet carries a multicast address as a
   logical identifier of all group members.  In Connectionless Multicast
   (CLM) the packet carries all the IP addresses of the multicast
   session members (in the context of CLM the term 'multicast session'
   will be used instead of 'multicast group' to avoid the strong
   association of multicast group with multicast address in traditional
   IP multicast).

   In each router the next hop for each destination is determined and
   for every distinct next hop a new header is constructed.  This header
   only contains the destinations for which that next hop is on the



Ooms, et al.             Expires December 1999                  [Page 3]


Internet Draft       draft-ooms-cl-multicast-00.txt            June 1999


   shortest path to these destinations.  When there is only one
   destination left in the CLM packet, this destination will be put in
   the normal destination address field and the packet can be forwarded
   as a unicast packet along the remainder of the route.

   Although not restricted to this type of multicast session, the most
   beneficial application of CLM is for sessions with a limited number
   of members (super-sparse).  For sessions with a large number of
   members, CLM can be used as an interdomain multicast routing
   mechanism between domains which run either PIM-SM or Simple
   Multicast.

   In practice, traditional multicast routing protocols impose
   limitations on the number of groups and the size of the network in
   which they are deployed.  For CLM these limitations do not exist.

   CLM has the following advantages:

   1) No multicast address allocation required.

   2) Routers do not have to maintain state per session (or per source-
   session).

   3) No symmetrical paths required.  Current multicast routing
   protocols assume (for optimal functioning) symmetrical paths, i.e.
   the shortest path from A to B is the same as the shortest path from B
   to A.  This is a false assumption in the current Internet and it is
   expected that this statement will become even more false when traffic
   engineering and more policy routing is introduced in the Internet.

   4) Fast reaction to unicast reroutes.  CLM will react immediately to
   unicast route changes.  This is not the case for e.g. PIM-SM: if a
   link fails, the multicast routes will only be updated when a new
   periodic Join message is sent upstream, which can take several
   minutes.

   5) Easy security and accounting.  In contrast with the Host Group
   Model, in CLM all the sources know the members of the multicast
   session, which gives the sources the means to e.g. reject certain
   members or count the traffic going to certain members quite easily.
   Not only a source, but also a border router is able to determine how
   many times a packet will be duplicated in its domain.  It becomes
   also more easy to restrict the number of senders or the bandwidth per
   sender.

   6) Heterogeneous receivers.  Besides the list of destinations, the
   packet can also contain a list of DiffServ bytes.  While traditional
   multicast protocols have to create separate groups for each service



Ooms, et al.             Expires December 1999                  [Page 4]


Internet Draft       draft-ooms-cl-multicast-00.txt            June 1999


   class, CLM incorporates the possibility of having receivers with
   different service requirements within one multicast session.

   7) Policy routing via BGP.  No need for a specific multicast policy
   routing protocol (extension).

   Beside these advantages CLM has a number of disadvantages:

   1) Overhead.  Each packet contains all remaining destinations, but
   the total amount of data is still much less than for the unicast.   A
   method to compress the list of destination addresses might be useful.

   2) More complex header processing.  Each destination in the packet
   needs a routing table lookup.  So a CLM packet with n destinations
   requires the same number of routing table lookups as n unicast
   headers.  Additionally, a different header has to be constructed per
   next hop.  Remark however that:

   a) Since CLM will typically be used for super-sparse sessions, there
   will be a limited number of branching points, compared to non-
   branching points.  By using a simple caching mechanism (see section
   5) in these non-branching points, the classical forwarding method can
   be used and therefore the same performance achieved.

   b) Among the non-branching points, a lot of them will contain only
   one destination.  In these cases normal unicast forwarding can be
   applied.

   c) The forwarding in the branching points can also be enhanced by a
   caching mechanism (section 5).

   d) By using compression on the list of destinations in combination
   with the aggregation in the forwarding tables the forwarding can be
   accelerated.

   3) Multi-access networks.  A multi-access network will carry
   duplicate packets, one for each next hop.  Note however that the main
   application area for CLM is interdomain multicast.  In this area
   point-to-point links outnumber the multi-access links.


3. Working modes

   As mentioned before CLM can be used for interdomain multicast routing
   or it can be used end-to-end for super-sparse sessions.  For
   interdomain multicast routing, CLM interoperates nicely with Simple
   Multicast and PIM-SM.




Ooms, et al.             Expires December 1999                  [Page 5]


Internet Draft       draft-ooms-cl-multicast-00.txt            June 1999


3.1. Simple Multicast

   Simple Multicast provides a tunnel mechanism.  This tunnel is used
   either to cross non Simple Multicast domains or to limit the
   multicast forwarding state in parts of the network.  When the tunnel
   is used for the latter purpose, the bandwidth saving of multicast is
   lost, i.e. parallel tunnels for the same group can exist on a
   specific link (Figure 1).  Assume ERi are Simple Multicast Exit
   Routers and BRi are Backbone Routers in which one wants to avoid
   multicast forwarding state.  S is a sender to the group and Ri are
   receivers.  For this topology Simple Multicast will construct a first
   tunnel from ER1 to ER2 and a second tunnel from ER1 to ER3, yielding
   duplicate traffic on the link ER1-BR1.


                         +--------BR2--------ER2------R1
                         |
                         |
        S------ER1------BR1-------BR3--------ER3------R2

                                 Figure 1

   If the BRi are CLM routers the duplicate traffic can be avoided
   without building multicast state in the BRi.  Since ER1 knows the
   endpoints of both tunnels it can send the multicast packet in CLM
   mode by putting ER2 and ER3 as destinations in the packet.


3.2. PIM-SM

   With MSDP [FARI] the Rendezvous Points (RPs) of PIM-SM discover which
   RPs have sources for a certain group in their domain.  Based on the
   same principles a Multicast Receiver Distribution Protocol (MRDP) can
   be created.  MRDP allows RPs to discover which RPs have receivers for
   a certain group in their domain.  If MRDP is running and an RP has a
   source for a group, it can send the data in a CLM mode to the RPs
   which have receivers for this group.


3.3 End-to-end

   If CLM is used end-to-end, it is especially useful for super-sparse
   sessions, e.g. video conferences.

   In the current Internet two approaches to establish multipoint-to-
   multipoint communication can be identified:

   - IRC-like approach [OIKA].  In this approach a set of servers keeps



Ooms, et al.             Expires December 1999                  [Page 6]


Internet Draft       draft-ooms-cl-multicast-00.txt            June 1999


   track of the created channels and the members of these channels.  The
   servers are also responsible for forwarding the channel data towards
   the members.  The servers rely on a unicast routing protocol.

   - IP Multicast.  In this approach the creation of the group, mainly
   the multicast address allocation, is the responsibility of a set of
   servers, while both the member state and the data forwarding is
   distributed over the network by running a multicast routing protocol.

   The end-to-end CLM mode combines aspects of both.  The creation of
   the session and the member state will be handled by servers, while
   the data forwarding is distributed.  The routing is relying
   completely on the unicast routing protocol.

   A set of servers will have a list of all created sessions with its
   senders and receivers.  Senders and receivers have to announce
   themselves periodically to the server.  If the periodic announcement
   stops this is interpreted as a sender or receiver leaving the
   multicast session.  The server will send receiver-update messages to
   the senders when the list of receivers changes.  If the receiver-
   update message is on top of a non-reliable transport protocol,
   periodic receiver-update messages can be added.

   1) New receiver.  If a receiver wants to join the multicast session
   it sends a first announcement to the server.  Then the server will
   send receiver-update messages to all senders (or in CLM mode: one
   receiver-update message to the list of senders).  It is easy to build
   in some policy rules here: the receiver is only added when it
   fulfills certain conditions.

   2) New sender.  A new sender announces itself to the server, which in
   return sends a receiver-update message with the list of current
   receivers to the new sender.  The sender then starts sending its data
   to the list of these receivers.  Once again it is easy in this phase
   to check who is sending and to allow only certain senders to receive
   the list of receivers.

   3) Leaving receiver.  A receiver that wants to leave a multicast
   session just stops sending announcements or sends an explicit
   unannounce message.

   4) Leaving sender.  A sender that decides to stop sending to the
   multicast session removes itself from the server by halting its
   announcement messages or by sending an explicit unannounce message.


4. IP Protocol extensions




Ooms, et al.             Expires December 1999                  [Page 7]


Internet Draft       draft-ooms-cl-multicast-00.txt            June 1999


4.1. IPv4

   In IPv4 two approaches can be followed to include the list of
   destination addresses.  Either one adds a new IPv4 option or one adds
   an extra header between the network and the transport layer.

   Since the IPv4 option field is limited to 40 bytes (of which 4 bytes
   are used for the option type field) only 9 (or 10 if the destination
   field of the IP header is also used) destination addresses can be
   included.  If the number of receivers is larger than 9 (or 10)
   multiple packets can be sent.  Although for a different purpose,
   [AGUI] and [GRAF] already proposed an IPv4 option to carry multiple
   destinations.  We propose the new IP option depicted in Figure 2.


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 0 0|   TYPE  |    LENGTH     |D|   COMPR     |    UNUSED     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           (Compressed) List of DS Bytes and Addresses         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

   TYPE = number for this IPv4 option

   LENGTH = total length of the option in bytes

   D = if this bit is set the packet will contain a (compressed) DS-byte
   for each destination.

   COMPR = compression method used on the list of DS bytes and
   destination addresses.  Following compression methods are defined:
                 0 = no compression

   Figure 3. shows the 'List of DS Bytes and Addresses' in case the D-
   bit is set and COMPR = 0.













Ooms, et al.             Expires December 1999                  [Page 8]


Internet Draft       draft-ooms-cl-multicast-00.txt            June 1999


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   DS byte 1   |         destination address 1                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |dst add 1 (cnt)|  DS byte 2    |      ...                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  destination address N                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 3


   Instead of using the IP option field one could add an extra header
   between the network and the transport layer.  This header is depicted
   in Figure 4.  The IP header will carry the protocol number PROTO_CLM.


     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|UNUSED |    PROT ID    |           LENGTH              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          CHECKSUM             |D|   COMPR     |    UNUSED     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           (Compressed) List of DS Bytes and Addresses         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 4

   VERSION = CLM version number

   PROT ID = specifies the protocol on the transport layer

   LENGTH = length in bytes of the CLM header.

   CHECKSUM = it is not clear yet whether a checksum is needed (ffs).
   If only one bit is wrong it can still be useful to forward the packet
   to N-1 correct destinations and 1 incorrect destination.  On the
   other hand when the header info is used to install a cache (see
   section 5) one can not allow that packets are permanently forwarded
   wrongly.  One approach could be to provide a checksum per
   destination.

   D = if this bit is set the packet will contain a (compressed) DS-byte
   for each destination.

   COMPR = compression method used on the list of DS bytes and



Ooms, et al.             Expires December 1999                  [Page 9]


Internet Draft       draft-ooms-cl-multicast-00.txt            June 1999


   destination addresses.  Following compression methods are defined:
                 0 = no compression

4.2. IPv6

   Since IPv6 allows more flexibility in adding options (no limitation
   on the size), there is no limitation in terms of encoding on the
   number of destinations that can be put in a packet.  However, since a
   packet can only be sent after all the destinations have been
   processed, packets with a lot of addresses will experience a lot of
   delay.

   For IPv6 the overhead will be larger since the addresses are longer.
   Note however that IPv6 probably allows stronger compression because
   of the geographical/provider distribution of addresses.  Moreover if
   CLM is used as an interdomain multicast mechanism only the locator
   part of the address needs to be considered.


5. Caching

   The increased forwarding complexity is the main problem of CLM:
   packet headers have to be constructed at wirespeed.  It was already
   mentioned that in major parts of the tree the normal unicast
   forwarding can be applied (from the moment there is only one
   destination address left in the packet).

   A method for further enhancing the forwarding is building a cache for
   the highest bandwidth sources.  For this purpose the source will put
   a number (from the multicast address range) in the destination
   address: the Receiver Update Notification (RUN).  Each time the set
   of destinations changes the source will indicate this to the
   downstream routers by changing the RUN.  The cache will contain
   entries for (S, RUN).  If the router receives a high bandwidth flow
   with a new (S, RUN) it will create a new cache entry.  Unused cache
   entries will time out.

   There are two ways of keeping a cache:

   1) Each (S, RUN) entry has a list of next hops with the associated
   outgoing IP option or CLM header (or list of destinations).

   2) Only (S, RUN) which have one next-hop (still multiple
   destinations) are cached.  These packets do not have to change their
   IP option or CLM header, so the latter information should not be kept
   in the cache.

   Both ways of applying a cache can be used in parallel.



Ooms, et al.             Expires December 1999                 [Page 10]


Internet Draft       draft-ooms-cl-multicast-00.txt            June 1999


6. Compression

   Compression methods allow to reduce the packet overhead.  If a common
   prefix compression method is applied this can beneficial for the
   forwarding as well.

   Compression methods are ffs.


7. Security Considerations

   Since a packet contains every destination, it is much more easy to
   restrict multicast sessions to certain receivers.  It also allows
   ISPs to check, when a packet enters their network, how much resources
   this packet packet will consume in their network.

   In the end-to-end mode it is also easy to restrict the number of
   senders or to restrict/monitor the bandwidth of a sender.


8. Acknowledgements

   The authors would like to thank Emmanuel Desmet, Hans De Neve and
   Miroslav Vrana for the fruitful discussions and/or their thorough
   revision of this document.


References


[AGUI]  L. Aguilar, "Datagram Routing for Internet Multicasting",
        Sigcomm84, March 1984.

[DEER]  S. Deering, "Multicast Routing in a datagram internetwork", PhD
        thesis, December 1991.

[FARI]  D. Farinacci, "Multicast Source Discovery Protocol", draft-
        farinacci-msdp-00.txt, June 1998.

[GRAF]  C. Graff, "IPv4 Option for Sender Directed Multi-Destination
        Delivery", RFC1770, March 1995.

[HOLB]  H. Holbrook, "Express Multicast: Making Multicast Economically
        Viable".

[OIKA]  J. Oikarinen, D. Reed, "Internet Relay Chat Protocol", RFC1459,
        May 1993.




Ooms, et al.             Expires December 1999                 [Page 11]


Internet Draft       draft-ooms-cl-multicast-00.txt            June 1999


[PERL]  R. Perlman, "Simple Multicast: A design for Simple, Low-overhead
        Multicast", draft-perlman-simple-multicast-02.txt, February
        1999.


Authors Addresses

   Dirk Ooms
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Phone : 32-3-240-4732
   Fax   : 32-3-240-9932
   E-mail: Dirk.Ooms@alcatel.be

   Wim Livens
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Phone : 32-3-240-7570
   E-mail: Wim.Livens@alcatel.be
































Ooms, et al.             Expires December 1999                 [Page 12]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/