Network Working Group T. Zhu Internet-Draft F. Wang Intended status: Informational D. Feng Expires: March 31, 2016 Q. Shi Y. Xie Huazhong University of Science and Technology September 28, 2015 Congestion-Aware and Robust MultiCast TCP in Software-Defined Networks draft-tingwei-mctcp-00 Abstract Reliable group communication is required in distributed applications, such as distributed file systems (HDFS, GFS and Ceph), where such group communication is defined by the sender and the group members are small (e.g. three). However, existing standards for reliable multicast transport are receiver-initiated and suffer from inefficiency in either host-side protocols or multicast routing. This draft proposes a sender-initiated, efficient, congestion-aware and robust reliable multicast solution in Software-Defined Networks (SDN), called MCTCP (MultiCast TCP). The main idea behind MCTCP is to manage the multicast groups in a centralized manner, and reactively schedule multicast flows to active and low-utilized links, and it is implemented by extending TCP as the host-side protocol and managing multicast groups in SDN-controller. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on March 31, 2016. Zhu, et al. Expires March 31, 2016 [Page 1] Internet-Draft MultiCast TCP September 2015 Copyright Notice Copyright (c) 2015 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. An Example Application . . . . . . . . . . . . . . . . . . . 5 5. MCTCP Architecture . . . . . . . . . . . . . . . . . . . . . 6 5.1. Host Side Protocol . . . . . . . . . . . . . . . . . . . 7 5.1.1. Session Establishment . . . . . . . . . . . . . . . . 7 5.1.2. Data Transmission . . . . . . . . . . . . . . . . . . 10 5.1.3. Session Close . . . . . . . . . . . . . . . . . . . . 10 5.1.4. Packet Format . . . . . . . . . . . . . . . . . . . . 10 5.1.4.1. Control Packet . . . . . . . . . . . . . . . . . 10 5.1.4.2. Data Packet . . . . . . . . . . . . . . . . . . . 11 5.1.5. Programming APIs . . . . . . . . . . . . . . . . . . 13 5.2. Multicast Group Manager . . . . . . . . . . . . . . . . . 13 5.2.1. Session Manager . . . . . . . . . . . . . . . . . . . 13 5.2.2. Link Monitor . . . . . . . . . . . . . . . . . . . . 13 5.2.3. Routing Manager . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative references . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Traditional reliable multicast schemes are mainly designed for very large multicast groups, such as PGM [RFC3208], NORM [RFC5740]. They are not suitable for the sender-defined small group multicast scenarios mainly for the following reasons. Zhu, et al. Expires March 31, 2016 [Page 2] Internet-Draft MultiCast TCP September 2015 1. Traditional reliable multicast schemes are receiver-initiated application-layer protocols (based on UDP), which suffer from high software overhead on end hosts and mismatch to the sender- initiated mode. 2. Traditional IP multicast routing algorithms, such as PIM-SM [RFC4601], are not designed to build optimal routing trees. They are not aware of link congestion, and thus apt to cause significant performance degradation in burst and unpredictable traffic environment. 3. Traditional multicast group management protocols, such as IGMP [RFC3376],MLD [RFC2710], are not aware of link failures. Any failure in multicast spanning trees can suspend transmission and lead to significant performance loss or business interruption. The emergence of SDN (Software-Defined Networking), brings new ideas for solving routing efficiency issues of reliable multicast in data centers. A centralized control plane called SDN-controller provides global visibility of the network, rather than localized switch level visibility in traditional IP networks. Therefore, multicast routing algorithms can leverage topology information and link utilization to build optimal (near-optimal) routing trees, and be robust against link congestion and failures. This memo proposes an SDN-based sender-initiated, efficient, congestion-aware and robust reliable multicast scheme, called MCTCP, which mainly designed for small groups. The main idea behind MCTCP is to manage the multicast groups in a centralized manner, and reactively schedule multicast flows to active and low-utilized links. Therefore, the multicast routing can be efficient and robust. To eliminate the high overhead on end hosts and achieve reliability, MCTCP extends TCP as the host-side protocol, which is a transport- layer protocol. 2. Terminology 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 [RFC2119]. Software Defined Networking (SDN): defined in RFC 7426 [RFC7426] Sender: A sender is a node which can start up a multicast communication and send data to several other nodes. Zhu, et al. Expires March 31, 2016 [Page 3] Internet-Draft MultiCast TCP September 2015 Receiver: A receiver can only wait for connection from a sender and receive data. It does not need to subscribe a multicast group in advance, but just keep listening for connection. Multicast Session: A multicast session contains a sender and several receivers. MST: Multicast Spanning Tree. HSP: Host Side Protocol. MGM: Multicast Group Manager. 3. Motivation MCTCP is designed for the sender-defined small group scenarios, which are very common in distributed systems like distributed file systems. MCTCP can make full use of the advantage of the SDN technology, and provide a framework for other intelligent or user-defined functions. Compared to traditional reliable multicast schemes, MCTCP has the following advantages: 1. Easier programming in upper-level applications. MCTCP provides common socket APIs, so that a programmer can use MCTCP easily. 2. More efficient. MCTCP can process the packets more efficient in host-side protocol (Transport-Layer), and can forward the packets via more efficient multicast spanning trees. 3. More robust. MCTCP can be aware of link failures, so the loss caused by a link failure decreases greatly. 4. More secure. MCTCP is inherent secure as the sender keeps the information of all receivers. Moreover, the centralized admission control in MGM helps achieve security. 5. Require no assistance from network devices. Different from the network-equipment scheme Xcast [RFC5058], which supports a very large number of small multicast sessions by explicitly encoding the list of destinations in the data packets, MCTCP can deploy on common SDN-enabled network devices and need no assistance from network devices. Zhu, et al. Expires March 31, 2016 [Page 4] Internet-Draft MultiCast TCP September 2015 4. An Example Application The HDFS data replication process is a typical one-to-many data transmission, during which the client gets the list of DNs (Data Nodes) from a NN (Name Node), and then delivers the data chunks to them. We assume the replication factor is three. +------+ Packets +---+ +---+ +---+ | |----------->| |---------->| |---------->| | |Client| |DN0| |DN1| |DN2| | |<-----------| |<----------| |<----------| | +------+ ACKs +---+ +---+ +---+ (a) Pipeline-based data replication Packets(Multicast) ------------->--------------> --> -- -- +------+ -- -- +---+ -- +---+ -- +---+ | |-- -->| | -->| | -->| | |Client| |DN0| |DN1| |DN2| | |<-- ---| | ---| | ---| | +------+ - -- +---+ -- +---+ -- +---+ <-- -- -- ------------<----------<--- ACKs (b) Multicast-based data replication Illustration of Pipeline-based and Multicast-based data replication. Figure 1 As shown in Figure 1(a), the original HDFS employs a pipeline-based replication method. The data transmission unit is a packet, which is usually 64KB. For each packet, the client first transfers it to DN0; then the DN0 stores and passes it to DN1; finally the DN1 stores and transfers it to DN2. After the DN2 receives the packet, it returns an acknowledgment to DN1; then the DN1 returns an acknowledgment to DN0; finally the DN0 returns an acknowledgment to the Client. Therefore, the whole process can be regarded as a six-stage pipeline. Let O-HDFS denote the original HDFS. O-HDFS has 2*n stages when configured as n replicas, resulting in long delay in packet transmission. In addition, O-HDFS delivers data in unicast, which will generate a large number of duplicated packets into the network and reduce the overall transmission performance. Zhu, et al. Expires March 31, 2016 [Page 5] Internet-Draft MultiCast TCP September 2015 Let M-HDFS denote the multicast-based HDFS, which using MCTCP for data replication. As shown in Figure 1(b), the client divides the data into packets, and then delivers them to three data nodes DN0, DN1, DN2 in multicast. For each packet, the client transfers it to DN0, DN1, DN2 simultaneously using MCTCP, and then all the data nodes return acknowledgements to the client directly. Therefore, M-HDFS's data replication procedure can be regarded as a two-stage pipeline. Compared with O-HDFS, M-HDFS has less stages (two stages to six stages), thus resulting in lower latency. Meanwhile, M-HDFS delivers data in multicast, so redundant packets in network are reduced greatly. 5. MCTCP Architecture MCTCP consists of two modules, the HSP (Host-Side Protocol) and the MGM (Multicast Group Manager). The HSP is an extension of TCP, leveraging the three-way handshake connection mechanism, cumulative acknowledge mechanism, data retransmission mechanism and congestion control mechanism to achieve reliable multipoint data delivery. The MGM, located in SDN-controller, is responsible for calculating, adjusting and maintaining the MSTs for each multicast session. It keeps monitoring the network status (e.g. link congestion and link failures) and creates maximal possibility to avoid network congestion and to be robust against link failures. Zhu, et al. Expires March 31, 2016 [Page 6] Internet-Draft MultiCast TCP September 2015 +--------------------------------------------------------------+ | Multicast Group Manager | | | | +---------------+ +---------------+ +---------------+ | | |Session Manager| |Routing Manager| | Link Monitor | | | +---------------+ +---------------+ +---------------+ | | SDN-Controller | +--------------------------------------------------------------+ ^ || ^ /|\ || /|\ |Establish/ || MST Link status| |Close || | | \||/ | | \/ | +--------------------------------------------------------------+ | +--+ | | -----|S2|----- | | Switch ----- +--+ ----- | | +--+ ----- ----- +--+ | | |S1|---- Network Devices -------|S4| | | +--+------ +--+ -------+--+ | | | ------ |S3| -------- | | | | ------+--+-------- | | +-------|------------------------------------------------|-----+ | +---+ +---+ | | |H1 | Host Host Side Protocol | H2| | | +---+ +---+ | +--------------------------------------------------------------+ The architecture of MCTCP. Figure 2 The sender establishes connection with multiple receivers explicitly before data transmission. First, the sender requests to the MGM for calculating the MST. Second, the MGM calculates and installs the MST. Third, the sender starts three-way handshake with receivers, and begins data transmission after that. Fourth, the MGM adjusts the MST once link congestion or failure detected. Fifth, the sender notifies the MGM after data transmission finishes. 5.1. Host Side Protocol 5.1.1. Session Establishment The sender requests to MGM for calculating MST when establishing a new session. Since the receivers do not obtain the multicast address in advance, the first handshake must be realized by using unicast Zhu, et al. Expires March 31, 2016 [Page 7] Internet-Draft MultiCast TCP September 2015 address. The multicast address is placed in the SYN packet. After receiving the SYN packet, the receivers get the specific multicast address, and join the group (just put the multicast address into the interested list, but not send IGMP messages), so that they can receive the multicast messages. Sender MGM Receivers --------------| +-|-+ | | | |-------->| | | | | | Initialization| | | | | | | |<------- |*| | | | | | +-|-+ | | | --------------| | SYN | | | |-----------|---------->| | | |-----------|-----------|--->| | |-----------|-----------|----|--->| | | SYN+ACK | | | |<----------|-----------| | | Three-way |<----------|-----------|----| | Handshake |<----------|-----------|----|----| | | | | | | | ACK | | | |---->*-----|---------->| | | | *---|-----------|--->| | | *-|-----------|----|--->| --------------| | | | | | Data | Packets | | | |---->*-----|---------->| | | Data | *---|-----------|--->| | Transmission| *-|-----------|----|--->| | | ACK | | | |<----------|-----------| | | |<----------|-----------|----| | |<----------|-----------|----|----| | | | | | (a) Out-band scheme Sender MGM Receivers --------------| +-|-+ | | | |-------->| | | SYN | | | | | |*|-------->| | | | | |*|---------|--->| | | | |*|---------|----|--->| | +-|-+ | | | Zhu, et al. Expires March 31, 2016 [Page 8] Internet-Draft MultiCast TCP September 2015 | | SYN+ACK | | | Three-way |<----------|-----------| | | Handshake |<----------|-----------|----| | |<----------|-----------|----|----| | | | | | | | ACK | | | |---->*-----|---------->| | | | *---|-----------|--->| | | *-|-----------|----|--->| --------------| | | | | | Data | Packets | | | |---->*-----|---------->| | | | *---|-----------|--->| | | *-|-----------|----|--->| Data | | ACK | | | Transmission|<----------|-----------| | | |<----------|-----------|----| | |<----------|-----------|----|----| | | | | | | | | | | (b) In-band scheme The Procedure of Session Establishment and Data transmission. There are three receivers. Figure 3 There are two alternative schemes, the out-band and the in-band schemes. For the out-band scheme, the sender requests to the MGM before three-way handshake. After calculating the MST, the MGM notifies the sender to start three-way handshake. For the in-band scheme, the SYN packet is used to request MST for calculation, and redirected to the MGM. After receiving the SYN packet and calculating MST, the MGM dispatches the SYN packet to all the receivers in unicast. Figure 3 illustrates the procedure of connection establishment and data transmission. The out-band scheme suffers from time overhead of an extra RTT to the SDN controller. Hence, this scheme is suitable for the large amount data transmission scenes, in which the overhead of session establishment is negligible. The in-band scheme has no extra time overhead, but brings much pressure on the SDN controller. This scheme is more suitable for extremely small membership and delay- sensitive scenes. Zhu, et al. Expires March 31, 2016 [Page 9] Internet-Draft MultiCast TCP September 2015 5.1.2. Data Transmission When a session is established, data transmission begins. Packet Acknowledgement. The sender maintains a sliding window and processes the acknowledgement from receivers. The send window advancement is decided by the slowest receiver. As MCTCP is mainly designed for small group scenarios, the ACK-implosion problem in traditional large member reliable multicast is negligible. Packet Retransmission. The sender does multicast retransmission when the timer expires or a packet loss is detected. Since the efficient and robust multicast forwarding achieved by MGM can greatly reduce the packet loss, the emergence of retransmission in MCTCP will be largely decreased. Congestion Control. A large amount of congestion control algorithms can be used in MCTCP, such as TFMCC [RFC4654], pgmcc [PGMCC]. Node failure. A receiver is considered as failed if the sender does not receive any acknowledgement from it within a threshold time. The failed receiver, which may encounter crash or network failure, should be cleaned out from the multicast session in order to ensure the transmission of the rest receivers. Therefore, the upper-level applications should be responsible for fault recovery. 5.1.3. Session Close After data transmission is completed, the sender closes the multicast session initiatively, and then notifies the MGM. 5.1.4. Packet Format There are two kinds of packets in MCTCP, the control packets and the data packets. The Control Packets are used to maintain the session states. The Data Packets are the regular packets. 5.1.4.1. Control Packet Zhu, et al. Expires March 31, 2016 [Page 10] Internet-Draft MultiCast TCP September 2015 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 +-------------+---------------+-------------------------------+ | Op=Establish| Number | RESERVED | +-------------+---------------+-------------------------------+ | Multicast Address | +-------------------------------------------------------------+ | Receiver Address1 | +-------------------------------------------------------------+ | ... | +-------------------------------------------------------------+ | Receiver AddressN | +-------------------------------------------------------------+ (a) Establish Session Packet 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 +-------------+-----------------------------------------------+ | Op=Close | RESERVED | +-------------+-----------------------------------------------+ | Multicast Address | +-------------------------------------------------------------+ (b) Close Session Packet Control packet Figure 4 There are at least two control packets: o SessionEstablish packet: If a sender wants to start a multicast session, it MUST assign a multicast address and a set of receivers, then send them to the MGM for MST calculation. As shown in Figure 4, the packet MUST contain the multicast address, the receiver number and the address of each receivers. o SessionClose packet: When a multicast session is closed, the sender MUST tell the MGM. 5.1.4.2. Data Packet Zhu, et al. Expires March 31, 2016 [Page 11] Internet-Draft MultiCast TCP September 2015 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 +-------------+---------------+---------------+----------------+ | Type | Length | Sub_type | | +-------------+---------------+---------------+ + | Info | +-------------+---------------+---------------+----------------+ Options Field in MCTCP Data Packets Figure 5 MCTCP is a new transport-layer protocol. To simplify the complexity of implementation and ensure compatibility of the protocol, the packet format of MCTCP is the same as TCP, and the related features for MCTCP are implemented in TCP options. The options field of MCTCP are depicted in Figure 5, where the 'type' is the option type, namely defined by TCPOPT_MCTCP, the 'sub_type' is the sub-options of MCTCP, INCLUDING OPTION_MCTCP_XID, OPTION_MCTCP_MCADDR, OPTION_MCTCP_SENDER, etc. The 'info' is the contents for corresponding sub-types. o OPTION_MCTCP_XID, used to identify a unique group, with length of 7 bytes, 4 bytes for XID. The XID is generated by the sender, delivered to receivers during connection establishment for identifying the multicast session, defined as the shared initial sequence number of all receivers as well. o OPTION_MCTCP_MCADDR, used to deliver the current multicast address, with length of 8 bytes, 1 byte for receiver ID and 4 bytes for multicast address. This option is used in the SYN packet for delivering the multicast address to receivers, and in all packets which the receivers send to the sender for identifying which group the packets belong to. The receiver ID identifies which receiver the packet comes from, and is set NULL in the SYN packet. o OPTION_MCTCP_SENDER, used to identify whether the packet is sent out by the sender, with the length of 3 bytes. In the sender, the five-tuples is used to identify a session instead of . Therefore it is different from the receivers in processing a receiving packet in the sender. The host has to know whether a packet is coming from a sender or a receiver before processing it. Zhu, et al. Expires March 31, 2016 [Page 12] Internet-Draft MultiCast TCP September 2015 5.1.5. Programming APIs The HSP uses the common socket APIs for programming. When programming using MCTCP, the receivers call the listen() system call for listening, just the same as TCP. At the sender, the user can specify a multicast address for the multicast session, otherwise a random multicast address will be allocated automatically by the HSP. Then the sender should call setsockopt() function to specify the address list of the receivers before connect(), as shown below. #define PEER_NUM 3 struct sockaddr_mc{ uint16_t sin_port; struct in addr_sin addr; } struct sockaddr_mc mc_addr[PEER_NUM]; setsockopt(fd, IPPROTO_MCTCP, MCTCP_ADDR, mc_addr, sizeof(mc_addr)); 5.2. Multicast Group Manager MCTCP uses a logically centralized approach to manage multicast groups. The MGM, located in SDN controller, manages the multicast sessions and MSTs. By keeping the global view of the network topology and monitoring the link status in real-time, the MGM can adjust the MSTs in case of link congestion or failures. Specifically, the MGM consists of three sub-modules, the session manager, the link monitor and the routing manager, as shown in Figure 2. 5.2.1. Session Manager The session manager is responsible for maintaining the states of all groups. When establishing or closing a multicast session, the sender informs the session manager. Hence, the session manager can keep track of all the active multicast sessions. If a multicast session is closed, the MST will not be cleared immediately, but just be marked inactive. Therefore, a session with the same sender and receivers can reuse the MST. The session manager periodically cleans up the inactive MSTs. 5.2.2. Link Monitor Link Monitor is responsible for monitoring network link status, and estimating the weight of each link periodically. This can be achieved easily by sFlow, NetFlow or "port-status" interface in OpenFlow [OpenFlow] protocol. Zhu, et al. Expires March 31, 2016 [Page 13] Internet-Draft MultiCast TCP September 2015 5.2.3. Routing Manager The routing manager is responsible for calculating and adjusting MSTs. When establishing a new multicast session, the routing manager calculates the minimum cost MST based on the current link utilization. When a link overloads or failure occurs, the adjustment for all MSTs over the link will be triggered. The routing manager is divided into two parts, the routing calculation and the routing adjustment. The MST should be calculated quickly during session establishment. In the case of link congestion, the MST should be adjusted in the best-effort way. When a link fails, all the relevant MST should be quickly updated. o Routing calculation. The members of a group are assigned by the sender, and no dynamically join/leave is allowed in MCTCP once the session begins. So a lot of static multicast routing algorithm can be used, the minimum-cost path heuristic algorithm (MPH)[MPH], for example. The MPH algorithm inputs a set of sender/receiver nodes and all-pairs shortest paths which are calculated by Floyd- Warshall algorithm, and outputs a minimum cost MST. o Routing adjustment. When the link monitor detects link overloading, i.e. the link weight is larger than a preset threshold, the routing adjustment will be triggered. In routing adjustment, the relevant MSTs should be recalculated. Zhu, et al. Expires March 31, 2016 [Page 14] Internet-Draft MultiCast TCP September 2015 +---+ +---+ +---+ +---+ +---+ +---+ |H1 | |H2 | |H1 | |H2 | |H1 | |H2 | +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | +--+ +--+ +--+ +--+ +--+ +--+ |S1|------>|S2| |S1|------>|S2| |S1|------>|S2| +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | | | =====> | | =====> X | V | V V | V +--+ +--+ +--+ +--+ +--+ +--+ |S3|------>|S4| |S3|-------|S4| |S3|<------|S4| +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | +---+ +---+ +---+ +---+ +---+ +---+ |H3 | |H5 | |H3 | |H5 | |H3 | |H5 | +---+ +---+ +---+ +---+ +---+ +---+ |H4 | |H6 | |H4 | |H6 | |H4 | |H6 | +---+ +---+ +---+ +---+ +---+ +---+ (a) (b) (c) An example for MST adjustment. A multicast group G1:H1-->{H2,H3,H5} in (a). Then H4 starts sending data to H6 with TCP in (b). A link down between S1 and S3 happens in (c). Figure 6 For example, consider a simple network topology which consists of four switches, as shown in Figure 6. At time T0, there is one group G1:H1->{H2,H3,H5}, and the current MST is MST1:{S1->S2, S1->S3, S3->S4}. At time T1, H4 start to send data to H6, causing plenty of TCP traffic on link S3->S4, resulting in confliction with group G1 at link S3->S4. Once the link monitor detects the congestion, the routing manager will start to adjust the MST of G1. So the new MST will be MST2:{S1->S2, S1->S3, S2->S4}. At time T2, link S1->S3 fails. Then the routing manager will adjust the MST of G1 to MST3:{S1->S2, S2->S4, S4->S3}. 6. Security Considerations MCTCP is more secure than traditional reliable multicast schemes, mainly for the following two reasons. Zhu, et al. Expires March 31, 2016 [Page 15] Internet-Draft MultiCast TCP September 2015 First, MCTCP is a sender-defined scheme, all the receivers are specified by the sender. Therefore, eavesdroppers can not join or leave a multicast session freely. It is hard to steal data from a multicast session. Second, all the multicast sessions are under control of the MGM, so it is easy to enable admission control and policy enforcement. For example, the MGM can enable authentication for each senders and receivers, so that a malicious sender is hard to start up a multicast session. Some forms of denial-of-service attack which wants to enlarge by using multicast can be prevent. 7. IANA Considerations TBD 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, . [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone, R., Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport Protocol Specification", RFC 3208, DOI 10.17487/RFC3208, December 2001, . [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, . [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, DOI 10.17487/RFC4601, August 2006, . Zhu, et al. Expires March 31, 2016 [Page 16] Internet-Draft MultiCast TCP September 2015 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, DOI 10.17487/RFC4654, August 2006, . [RFC5058] Boivie, R., Feldman, N., Imai, Y., Livens, W., and D. Ooms, "Explicit Multicast (Xcast) Concepts and Options", RFC 5058, DOI 10.17487/RFC5058, November 2007, . [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, . [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . 8.2. Informative references [MPH] Takahashi, H. and A. Matsuyama, "An approximate solution for the steiner problem in graphs", Math. Japonica, vol. 24, no. 6, pp. 575-577, April 1980. [OpenFlow] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., and L. Peterson, "OpenFlow: Enabling Innovation in Campus Networks", ACM SIGCOMM, vol. 38, no. 2, pp. 69-74, April 2008. [PGMCC] Rizzo, L., "Pgmcc: A TCP-friendly Single-rate Multicast Congestion Control Scheme", ACM SIGCOMM, p: 17--28, October 2000, . Authors' Addresses Tingwei Zhu Huazhong University of Science and Technology WuHan 430074 P.R.China Email: twzh@hust.edu.cn Zhu, et al. Expires March 31, 2016 [Page 17] Internet-Draft MultiCast TCP September 2015 Fang Wang Huazhong University of Science and Technology WuHan 430074 P.R.China Email: wangfang@mail.hust.edu.cn Dan Feng Huazhong University of Science and Technology WuHan 430074 P.R.China Email: dfeng@hust.edu.cn Qingyu Shi Huazhong University of Science and Technology WuHan 430074 P.R.China Email: qingyushi@hust.edu.cn Yanwen Xie Huazhong University of Science and Technology WuHan 430074 P.R.China Email: ywxie@hust.edu.cn Zhu, et al. Expires March 31, 2016 [Page 18]