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

Versions: 00 01

SAM Research Group                                             M. Kellil
Internet Draft                                              C. Janneteau
Intended status: Informational                                   P. Roux
Expires: January 27, 2011                                       CEA LIST
                                                           July 26, 2010




            Multiparty Transport Overlay Control Protocol(MTOCP)
                       draft-kellil-sam-mtocp-01.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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

   This Internet-Draft will expire on January 27, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.






Kellil et al.         Expires January 27, 2011                [Page 1]


Internet-Draft                  MTOCP                        July 2010


Abstract

   To cope with the lack of IP multicast support in today's Internet, a
   multiparty transport overlay architecture is presented in this
   document. The goal behind placing the overlay paradigm at the
   transport layer is to support both multicast-capable and non-
   multicast IP networks while providing an application-agnostic
   delivery service for group communications. In particular, this
   document specifies the Multiparty Transport Overlay Control Protocol
   (MTOCP) used to create, update and remove multiparty transport trees
   in an IP network.



Table of Contents


   1. Introduction.................................................3
   2. MTO Architecture Components..................................4
      2.1. MTO Tree................................................4
      2.2. MTO Controller..........................................5
   3. MTO Controller Operations....................................6
      3.1. Connection Addition.....................................7
      3.2. Connection Removal......................................7
      3.3. Connection Flush........................................8
   4. ON Operations................................................8
      4.1. Control Plane...........................................8
      4.2. Data Plane..............................................8
   5. Message Structure............................................9
      5.1. Command Message Structure...............................9
      5.2. Response Message Structure.............................10
      5.3. Connection Option......................................12
   6. Security Considerations.....................................14
   7. IANA Considerations.........................................14
   8. Conclusions.................................................14
   9. References..................................................14
      9.1. Normative References...................................14
      9.2. Informative References.................................15
   10. Acknowledgments............................................15










Kellil et al.         Expires January 27, 2011                [Page 2]


Internet-Draft                  MTOCP                        July 2010


   Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [1].

1. Introduction

   A Multiparty Transport Overlay (MTO) is generic, scalable, and
   efficient transport service for group communications. MTO allows
   hiding the heterogeneity of underlying networks in terms of IP
   multicast capabilities and IPv4/v6 support; thus allowing any user to
   participate in a multiparty delivery session irrespective of the
   network he/she is attached to and in a transparent manner to the
   application.

   The MTO applies the overlay paradigm at the transport layer, while
   most of the existing multiparty overlay solutions, whether in the
   conceptual stage or deployed in today's networks, either use some
   form of IP tunnelling (e.g. AMT [6]) or specify application layer
   protocols [7]. The study of the prior art raised the lack of generic
   MTO (some multiparty technologies are application-dependent while
   others do not support IP multicast [2]) as well as the lack of
   dynamic transport group management functionalities.

   Conceptually, an MTO is a transport tree made up of overlay nodes
   (ONs). The root of the tree represents the source overlay node; the
   closest overlay node to the data source. The leaf of the tree (the
   leaf overlay node) is the closest overlay node to the receiver.

   The branches of the MTO tree are made of transport connections. Each
   transport connection is identified by a unicast source address and
   port, and a unicast/multicast destination address and port.  Each ON
   forwards data from one incoming transport connection to one or
   multiple transport connections based on its own forwarding table.

   In addition, each overlay node has to maintain mapping information
   between the multiparty transport connection ID (actually, equivalent
   to MTO tree ID) and the IDs of associated multicast and unicast
   transport connections forming the branches of the MTO tree.

   In the proposed design, The MTO tree ID is only used to manage the
   transport connections of a given MTO tree (i.e. addition or removal
   of multicast/unicast transport connections of an MTO tree). In
   particular, the MTO tree ID is not included in the data packets and
   it is not explicitly used by the packet forwarding process on the
   ONs. Indeed, each ON forwards data packets based on local information


Kellil et al.         Expires January 27, 2011                [Page 3]


Internet-Draft                  MTOCP                        July 2010


   of its forwarding table indicating that packets received on a given
   "input" unicast/multicast transport connection are to be forwarded
   to one or more "output" unicast/multicast transport connections.
   Thus, the proposed design allows avoiding any extra overhead in data
   packets related to identifying which MTO tree the data packets will
   be delivered through.

   To properly manage the MTO tree, an MTO controller entity is defined.
   In particular, this entity is in charge of creating, updating and
   removing multiparty transport trees in an IP network. All those
   operations are enabled by the Multiparty Transport Overlay Control
   Protocol (MTOCP) defined in the present document. The proposed design
   is centralized and typically applies to a single operator domain, but
   it could also apply to a multi-operator scenario. A decentralized
   design, encompassing collaboration between multiple MTO Controllers,
   is out of the scope of the present document.

   Comments are solicited and should be addressed to the working group's
   mailing list at fecframe@ietf.org and/or the authors.

2. MTO Architecture Components

2.1. MTO Tree

   An MTO tree is made up of a set of ONs interconnected through
   multicast or unicast connections. There are three types of ONs in an
   MTO tree (see Figure 1):

   o Source Overlay Node (S-ON): it represents the functional component
      of the MTO tree that receives the application data flow directly
      from the source.

   o Leaf Overlay Node (L-ON): it represents the functional component
      of the MTO tree that is the last hop ON from the source to the
      receiver.

   o On-tree Overlay Node (O-ON): it represents the functional
      component of the MTO tree that is on the path between the S-ON and
      L-ON.

   Figure 1 shows an example of an MTO tree made of 5 overlay nodes and
   connecting a source to 5 receivers. The tree is made of 2 multicast
   transport connections and 5 unicast transport connections.






Kellil et al.         Expires January 27, 2011                [Page 4]


Internet-Draft                  MTOCP                        July 2010


            +------------------------------------------------+
            |                                                |
            |                    Source                      |
            |                       |                        |
            |                    Ucast1                      |
            |                       |                        |
            |                    +-----+                     |
            |                    |S-ON |                     |
            |                    +-----+                     |
            |                       |                        |
            |                    Ucast2                      |
            |                       |                        |
            |                    +-----+                     |
            |                    |O-ON |                     |
            |                    +-----+                     |
            |                      ||                        |
            |                     Mcast1                     |
            |                   /        \                   |
            |             +-----+       +-----+              |
            |             |L-ON1|       |L-ON2|              |
            |             +-----+       +-----+              |
            |             //   \         /    \              |
            |           Mcas2  Ucast3 Ucast4  Ucast5         |
            |           //       \     /        \            |
            |        -+----+-     +    +        +            |
            |         |    |      |    |        |            |
            |        R1    R2     R3   R4       R5           |
            |                                                |
            +------------------------------------------------+

          Figure 1 : Example of Multiparty Transport Overlay Tree.

2.2. MTO Controller

   The MTO controller (MTO-Ctrl) represents the functional component
   that is in charge of managing the configuration of an MTO tree in the
   network (i.e. creation/update/removal of the MTO tree). This
   basically consists in what follows:

   o Management of port numbers for transport connections of the MTO
      tree: each time a new MTO tree is to be created, the MTO-Ctrl
      SHOULD assign a couple of unique ports (source and destination
      ports) per MTO tree. These ports SHOULD be used for all transport
      connections belonging to a same MTO tree. This avoids any possible
      conflicts among different MTO trees for data transmission. For
      instance, one ON serving two different MTO trees (i.e. ON is bound
      to two different MTO tree IDs) SHOULD have two couples of unique


Kellil et al.         Expires January 27, 2011                [Page 5]


Internet-Draft                  MTOCP                        July 2010


      ports (one couple per MTO tree): <SrcPort1, DstPort1> and
      <SrcPort2, DstPort2>. The MTO-Ctrl MAY choose to use a different
      destination port for a given connection of an MTO tree. In such a
      case the MTO-Ctrl MAY learn the destination port through a
      mechanism which is out of the scope of the present document. For
      example, the MTO-Ctrl MAY obtain the destination port of a unicast
      connection terminating at a receiver from the receiver itself.

   o Management of MTO tree ID: the MTO-Ctrl SHOULD manage the MTO tree
      ID and ensure that a unique ID is assigned for each different MTO
      tree.

   o Push to (and further update for) each ON its MTO Tree-specific
      forwarding table in the form of a list of input and output
      transport connections.

            +------------------------------------------------+
            |                                                |
            |   +----------+                                 |
            |   |          |-- MTOCP Command --> +------+    |
            |   |          |<--MTOCP Response -- |  ON1 |    |
            |   |          |                     +------+    |
            |   | MTO-Ctrl |                                 |
            |   |          |                                 |
            |   |          |-- MTOCP Command --> +------+    |
            |   |          |<--MTOCP Response -- |  ON2 |    |
            |   +----------+                     +------+    |
            |                                                |
            +------------------------------------------------+

          Figure 2 : Example of Multiparty Transport Overlay Tree.

   As shown in Figure 2, the Multiparty Transport Overlay Control
   Protocol (MTOCP) is used by the MTO controller to configure the
   overlay nodes of the MTO tree.

   The message exchange between MTO-Ctrl and ONs is carried over TCP to
   avoid packet loss. This TCP connection is initiated by MTO-Ctrl.

   In addition, the default listening port at ON for MTOCP protocol is
   11224.

3. MTO Controller Operations

   The management of multiparty transport connections is ensured by the
   MTO controller. This entity communicates with the different ONs of



Kellil et al.         Expires January 27, 2011                [Page 6]


Internet-Draft                  MTOCP                        July 2010


   the MTO tree (source ON, on-tree ONs, and leaf ONs) to enable them
   configuring their respective input and output transport connections.

   A connection is defined in MTO-Ctrl's command as follows:

   o <IP source address, source port, IP destination/listening address,
      destination/listening port> for the input connection of ON, and

   o <IP source/forwarding address, source/forwarding port, IP
      destination address, destination port> for ON' output connection.

   For data transport over these connections, UDP protocol is used.

   In the following section, the different message exchange types
   between MTO-Ctrl and ON are described. Note that in each command
   message it sends to ON, the MTO-Ctrl includes the MTO Tree ID to
   indicate which MTO tree it is referring to. Likewise, in each
   response sent to MTO-Ctrl, the ON indicates the ID of the MTO tree it
   is referring to.

3.1. Connection Addition

   When the MTO-Ctrl wants to add one or multiple connections to an ON
   (on session setup or update), it sends to this ON a CONNECTION_START
   command including the parameters of the input and/or output
   connection(s) to be added along with the MTO tree ID of the concerned
   overlay tree.

   On reception of this command the ON configures its input and/or
   output connections (as described in section 4.1. ) and replies the
   MTO-Ctrl with an ACK_CONNECTION_START message including the result of
   the connection configuration operation (success/failure).

3.2. Connection Removal

   When the MTO-ctrl wants to remove one or multiple connections of an
   ON (e.g., on session termination or update), it sends to this ON a
   CONNECTION_STOP command including the parameters of the input and/or
   output connections to be deleted. On reception of this command the ON
   deletes the entries of the concerned connections (as described in
   section 4.1. ) and replies the MTO-Ctrl with an ACK_CONNECTION_STOP
   message including the result of the connection deletion operation
   (success/failure).






Kellil et al.         Expires January 27, 2011                [Page 7]


Internet-Draft                  MTOCP                        July 2010


3.3. Connection Flush

   The last type of command that could be sent by MTO-Ctrl to an ON is a
   CONNECTION_FLUSH to inform the ON that it should delete all the
   connections it has for a given MTO tree ID. On reception of such a
   command, the ON flushes its connections list related to the MTO tree
   ID mentioned in MTO-Ctrl's command (cf. section 4.1. ). The ON then
   replies the MTO-ctrl with an ACK_CONNECTION_FLUSH message including
   the result of the connection deletion operation (success/failure).

4. ON Operations

4.1. Control Plane

   When an ON receives a CONNECTION_START command from MTO-Ctrl, it sets
   up new input and/or output connections and updates its forwarding
   table so as to consider the added connections. If MTO-Ctrl's command
   is a CONNECTION_STOP or a CONNECTION_FLUSH, the ON stops receiving
   from and/or forwarding traffic to the concerned connections, and
   removes the concerned entries from the forwarding table. Also,
   whatever the command type, the ON replies back to the MTO-Ctrl with
   an ACK (ACK CONNECTION START, ACK CONNECTION STOP, or ACK CONNECTION
   FLUSH). In its reply to MTO-Ctrl, the ON includes the result of the
   operations it performed upon receiving MTO-Ctrl's command. If a
   CONNECTION START or a CONNECTION STOP fails, the ON includes in its
   response the list of connections that it could not add or remove for
   some reason (e.g., the connection to be added does not correspond to
   ON's IP address, the connection to be removed does not exist, etc).

4.2. Data Plane

   For a given MTO tree, the data forwarding process on ON consists in
   receiving the traffic from an input transport connection and
   forwarding this traffic to the appropriate output transport
   connection(s) as indicated by its MTO Tree-specific forwarding table.

   To receive or send multicast traffic, the ON uses the source address
   of the multicast input (respectively, output) connection to select
   the downstream (respectively upstream) interface. Of course, the
   source address of the multicast input/output connection is mentioned
   by MTO-Ctrl. ON is also an IGMP/MLD listener [4][5]. So, as such, it
   sends an IGMP/MLD report whenever it should receive multicast packets
   from other ONs or from the source.






Kellil et al.         Expires January 27, 2011                [Page 8]


Internet-Draft                  MTOCP                        July 2010


5. Message Structure

5.1. Command Message Structure

   The command message is sent from MTO-Ctrl to ON. It includes a
   command header (Command_Number, Command_Type, Command_Length, and
   MTO_Tree_ID), possibly followed by zero, one or multiple connection
   options.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Command_Number                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Command_Type  |        Command_Length         |    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           MTO_Tree_ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Connection Option(s)...
      +-+-+-+-+-+-+-+-


      Command Number

                A 32-bit unsigned integer incremented for each command.
                It allows to match ON's responses to MTO-Ctrl's
                commands.

      Command_Type

               A 8-bit unsigned integer indicating the type of command
               sent by MTO-Ctrl to ON (CONNECTION_START,
               CONNECTION_STOP and CONNECTION_FLUSH). The following
               table gives the values of the different command types.

                       +----------------------------+
                       | Command Type         Value |
                       |                            |
                       | CONNECTION_START     1     |
                       | CONNECTION_STOP      2     |
                       | CONNECTION FLUSH     3     |
                       +----------------------------+



Kellil et al.         Expires January 27, 2011                [Page 9]


Internet-Draft                  MTOCP                        July 2010


      Command_length

               A 16-bit unsigned integer that represents the length (in
               bytes) of the data field following the command header.


      MTO_Tree_ID

               A 32-bit unsigned integer serving as the unique
               identifier of an MTO tree corresponding to a unique
               multiparty session.

5.2. Response Message Structure

   As shown hereafter, ON's response message structure is almost the
   same as that of MTO-Ctrl's command message structure. The response
   message is sent from ON to MTO-Ctrl. It includes a response header
   (Response_Number, Response_Type, Response_Length, Status, and
   MTO_Tree_ID), possibly followed by zero, one or multiple connection
   options.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Response_Number                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Response_Type  |        Response_Length         |    Status   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           MTO_Tree_ID                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Connection Option(s)...
     +-+-+-+-+-+-+-+-

      Response Number

                A 32-bit unsigned integer set to the same value as the
                command number of the command which this response
                replies to. It allows to match ON's responses to MTO-
                Ctrl's commands.






Kellil et al.         Expires January 27, 2011               [Page 10]


Internet-Draft                  MTOCP                        July 2010


      Response_Type

               A 8-bit unsigned integer. It indicates the type of
               response sent by ON to MTO-Ctrl (ACK_CONNECTION_START,
               ACK_CONNECTION_STOP and ACK_CONNECTION_FLUSH). The
               following table gives the values of the different
               response types.

                     +--------------------------------+
                     | Response Type            Value |
                     |                                |
                     | ACK_CONNECTION_START     4     |
                     | ACK_CONNECTION_STOP      5     |
                     | ACK_CONNECTION FLUSH     6     |
                     |                                |
                     +--------------------------------+


      Response_length

               A 16-bit unsigned integer. It represents the length (in
               bytes) of the data field following the response header.


      Status
               A 8-bit unsigned integer. It is set to zero if ON
               detects no error upon execution of MTO-Ctrl's command.
               Otherwise, it is set to an error value. This value
               is followed by a list of connections concerned by the
               failure if the response concerns an add/delete command
               (i.e. not an ACK_CONNECTION_FLUSH). One type only of
               error value is defined in this document: 1, for command
               failure.


      MTO_Tree_ID

               A 32-bit unsigned integer serving as the unique
               identifier of an MTO tree corresponding to a unique
               multiparty session.



Kellil et al.         Expires January 27, 2011               [Page 11]


Internet-Draft                  MTOCP                        July 2010


5.3. Connection Option

   This field is optional, and concerns both command and response
   messages. A connection option field contains the description of one
   transport connection of the MTO tree. As mentioned in section 5.1. ,
   one or multiple connection options can follow the command header of a
   CONNECTION_START or a CONNECTION_STOP command message. On the other
   hand, this option is useless in the CONNECTION_FLUSH command message.

   Also, connection options SHOULD be included in the response message
   only in case of operation failure on ON when processing a
   CONNECTION_START or a CONNECTION_STOP command.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Connect Type  |            Src Port           | Src IP @ Type |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                        Src IP @ Value                         +
     |                                                               |
     +                                                               +
     |                                                               |
     +                                                               +
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Reserved    |            Dst Port           | Dst IP @ Type |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                        Dst IP @ Value                         +
     |                                                               |
     +                                                               +
     |                                                               |
     +                                                               +
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Connect Type

               A 8-bit unsigned integer indicating the type of
               connection (input or output).


Kellil et al.         Expires January 27, 2011               [Page 12]


Internet-Draft                  MTOCP                        July 2010


      Src Port

               A 16-bit unsigned integer indicating the source port
               number of the transport connection.



      Src IP @ Type

               A 8-bit unsigned integer. It indicates the type of the
               source IP address of the connection. Two values are
               defined for this field: 0 for IPv4 and 1 for IPv6.


      Src IP @ Value

               A 16-byte field indicating the source IP address of the
               connection.


      Reserved

               Set to zero; ignored on reception
.

      Dst Port

               A 16-bit unsigned integer that indicates the destination
               port number of the transport connection.


      Dst IP @ Type

               A 8-bit unsigned integer indicating the type of the
               destination IP address of the connection. Two values are
               defined for this field: 0 for IPv4 and 1 for IPv6.


      Dst IP @ Value

               A 16-byte field indicating the destination IP address of


Kellil et al.         Expires January 27, 2011               [Page 13]


Internet-Draft                  MTOCP                        July 2010


               the connection.


6. Security Considerations

   As the present documents deals with the MTO architecture, only the
   control plan security (security of the message exchange between the
   MTO controller and ONs) will be considered.

   To protect the message exchange between the MTO controller and ONs,
   the MTO Controller SHOULD establish an IPsec SA with each ON. IPsec
   AH [3] MAY be used during the exchange. This protection offers data
   origin authentication and data integrity.

7. IANA Considerations

   This document recommends the reservation of port 11224 for the
   exchange of command/response messages between the MTO-Ctrl and ON.

8. Conclusions

   This document has described the Multiparty Transport Overlay Control
   Protocol (MTOCP) and related operations. The goal behind designing
   such a protocol is to hide the heterogeneity of underlying networks
   in terms of IP multicast capabilities and IPv4/v6 support; thus
   allowing any user to participate in a multiparty delivery session
   irrespective of the network he/she is attached to and in a
   transparent manner to the application.

9. References

9.1. Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]  Deering, S., "Host extensions for IP multicasting", RFC 1112,
         August 1989.

   [3]  Kent, S., "IP Authentication Header", RFC 4302, December 2005.

   [4]  Cain, B., et al., "Internet Group Management Protocol, Version
         3", RFC 3376, October 2002.

   [5]  Vida, R., et al., "Multicast Listener Discovery Version 2
         (MLDv2) for IPv6", June 2004.



Kellil et al.         Expires January 27, 2011               [Page 14]


Internet-Draft                  MTOCP                        July 2010


9.2. Informative References

   [6]  Thaler, D., et al., "Automatic IP Multicast Without Explicit
         Tunnels (AMT)", IETF, draft-ietf-mboned-auto-multicast-10.txt,
         December 2008, (Work in Progress).

   [7]  Moen, D., "Overview of overlay multicast protocols", available
         at http://netlab.gmu.edu.

10. Acknowledgments

   The work presented in this document has been supported by the
   European FP7 ICT project C-CAST which aims at evolving mobile
   multimedia multicasting to exploit the increasing integration of
   mobile devices with our everyday physical world and environment.

Authors' Addresses

   Mounir Kellil
   CEA, LIST, Communicating Systems Laboratory,
   Point Courrier 94, Gif-sur-Yvette, F-91191 France
   Email : mounir.kellil@cea.fr


   Christophe Janneteau
   CEA, LIST, Communicating Systems Laboratory,
   Point Courrier 94, Gif-sur-Yvette, F-91191 France
   Email: christophe.janneteau@cea.fr


   Pierre Roux
   CEA, LIST, Communicating Systems Laboratory,
   Point Courrier 94, Gif-sur-Yvette, F-91191 France
   Email: pierre.roux@cea.fr














Kellil et al.         Expires January 27, 2011               [Page 15]


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