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): and . 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 for the input connection of ON, and o 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]