SAMRG Z. Sun Internet-Draft H. Wang Intended status: Standards Track T. Li Expires: January 13, 2012 J. Mao NUDT July 12, 2011 Labelcast Protocol draft-sunzhigang-sam-labelcast-02 Abstract This document presents a lightweight transport protocol-Labelcast, especially for long-lived connection video streams. This protocol provides a procedure for application programs to send media data to other programs. Like the UDP protocol, the Labelcast does not provide delivery and duplicate protection. However, it provides efficient support for the monitoring of video transmission quality. And, fast forwarding mechanism based on label is also supported by the protocol. Labelcast can coexist and integrate with existing mechanisms, such as IP multicast and RTP/RTCP, while offering more flexible deployment options and scaling to support a greater number of simultaneous multicast groups. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 January 13, 2012. Sun, et al. Expires January 13, 2012 [Page 1] Internet-Draft Labelcast Protocol July 2011 Copyright Notice Copyright (c) 2011 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. Sun, et al. Expires January 13, 2012 [Page 2] Internet-Draft Labelcast Protocol July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Ideas of Labelcast . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Replacing UDP for video streaming delivery . . . . . . . . 5 2.2. Relationship to RTP . . . . . . . . . . . . . . . . . . . 5 2.3. Relationship to IP multicast . . . . . . . . . . . . . . . 6 2.4. Lightweight protocol . . . . . . . . . . . . . . . . . . . 6 3. Labelcast Protocol . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Labelcast header format . . . . . . . . . . . . . . . . . 7 3.2. Forward label table . . . . . . . . . . . . . . . . . . . 8 3.3. The Requirement for IP Protocol Fields . . . . . . . . . . 8 4. Requirement of Protocol . . . . . . . . . . . . . . . . . . . 8 4.1. Processing Requirement . . . . . . . . . . . . . . . . . . 8 4.1.1. Building the Label Paths . . . . . . . . . . . . . . . 8 4.1.2. Requirement of the Source . . . . . . . . . . . . . . 8 4.1.3. Processing Requirement of Labelcast Forwarding Nodes . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.4. Requirement of End Systems . . . . . . . . . . . . . . 9 4.2. Impact on protocol stack . . . . . . . . . . . . . . . . . 9 4.2.1. Source serve . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Client . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. Forwarding Node . . . . . . . . . . . . . . . . . . . 10 5. Application Example . . . . . . . . . . . . . . . . . . . . . 10 5.1. Point-to-Multipoint Data Distribution Based on Labels . . 10 5.2. Video-awre Network Processing . . . . . . . . . . . . . . 11 5.3. Detecting Network Status . . . . . . . . . . . . . . . . . 12 6. Labelcast Deployment . . . . . . . . . . . . . . . . . . . . . 12 6.1. Relationship to Common API . . . . . . . . . . . . . . . . 12 6.2. IP tunnel . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Sun, et al. Expires January 13, 2012 [Page 3] Internet-Draft Labelcast Protocol July 2011 1. Introduction Internet Protocol Television (IPTV) service has emerged as one of the most promising applications in the coming years. IPTV video content is delivered over IP networks and based on IP techniques. However, there is lacking efficient Internet protocols or mechanisms for IPTV services, especially between core network and access network, which is the bottleneck for IPTV data transmission.[I-D.litao-p2mpsmd-problem-statement] Peer-to-Peer based on application layer technology just concerns the logic network rather than real network states and topology, and a great deal of redundant streams pass over the core Internet. Due to lack of administration, P2P reduces the ISPs' benefits and is not feasible to IPTV live broadcast systems. Pure clients P2P can't be further developed to the main delivery technologies. IP multicast is insufficient to deploy largely-scale over the Internet because of their defects in scalability, user management, flow control, etc. The scalability of IP multicast is an important issue and this hampers its implementation. Routers keep every active group states and when the scale is increasing, the burden would be expanded. Another problem in IP multicast is the reliability. The UDP is used as the transport layer in IP multicast and the integrity of data will not be assured. The transport layer protocols TCP/UDP, which are not designed for IPTV service at the beginning, can not achieve the motivation of effective video traffic transmission due to the characteristics of IPTV streams, such as long-time connection, high bandwidth consumption and so on. TS over RTP/UDP RFC 1889 [RFC1889] are the most widely used transmission means for streaming media, however there are two problems. One problem is that RTP/UDP can not provide efficient Point-to-Multipoint IPTV distribution methods. Another is that RTP/ UDP is in lack of support to monitoring the transfer quality of the video. Not only end systems are hard to realize monitoring towards their QoE (Quality of Experience), but also the intermediate routing nodes can't optimize QoS due to the lack of enough information.RFC 3550 [RFC3550] Labelcast is a transport protocol supporting Point-to-Multipoint IPTV data distribution especially for the characteristics of long-lived connection, high bandwidth consumption and continuity. This protocol contains abundant fields that can support Point-to-Multipoint data transmission, and video quality monitoring both for intermediate routing nodes and end systems. Labelcast can efficiently meet the Sun, et al. Expires January 13, 2012 [Page 4] Internet-Draft Labelcast Protocol July 2011 requirements of the video quality transmission monitoring, failure detection and isolation of network failures. 2. Ideas of Labelcast The basic ideas are as follows: 1. IPTV data distribution protocol based on Labelcast can support the stream characteristics of long-lived connection, high bandwidth consumption, real-time and continuity. 2. Simplify the implementation of Point-to-Multipoint data transmission by utilizing labels. 3. Reduce the processing overhead of intermediate routing nodes. 4. Support monitoring of video transmission quality. 2.1. Replacing UDP for video streaming delivery UDP is an unconnected and unreliable transport protocol. In IPTV data transmission, only the destination port field of UDP header is functional, while the field of source port, length and checksum are not used. Labelcast defines some specific fields to support the features important to video traffic transmission, such as bandwidth and timestamp for monitoring. Labelcast sets up the transmission paths between source and receivers through label switching. The protocol supports for the packet priorities, bandwidth reservation, calculating time interval and packets loss rate, etc. Based on the state information, the video transmission quality can be monitored and the scheduling strategy can be optimized. Besides, the evaluation of the video transmission quality at intermediate routing nodes and end systems can take advantage of MDI index RFC 4445 [RFC4445]. DF and MLR values are parts of MDI. DF value reflects the delay jitter of the video traffic and MLR value reflects the loss rates of the video traffic. The bandwidth of the transmission requirement, loss rate and the delay jitters can also be calculated by intermediate routing nodes, and the transmission QoS can be controlled. 2.2. Relationship to RTP RTP is designed for supporting multimedia application, and it can not provide reliable insurance for sequenced data streams, nor flow or congestion control mechanism. These are all implemented by RTCP. RTCP sends periodically control messages to the group members. The Sun, et al. Expires January 13, 2012 [Page 5] Internet-Draft Labelcast Protocol July 2011 members can get the condition of network through feedback data. RTCP control flow increases linearly to the number of participants, and it consumes more bandwidth in larger groups. In this situation, Labelcast can replace UDP to work with RTP/RTCP as a transport layer protocol as it provide aboundant information for video quality monitor, failure detection and flow control . Moreover, Labelcast is responsible for monitoring network nodes (routers/switches) in the Internet, while RTP/RTCP is responsible for monitoring end hosts. Labelcast and RTP/RTCP can work together to get the complete view of the whole network. 2.3. Relationship to IP multicast IP multicast is considered as the most effective technology to solve the bandwidth problem in IPTV data transmission. However, IP multicast is not a network-aware mechanism and can not diagnose the transmission quality. Most streams are concentrated in the minority paths (the shortest ones). In IP multicast, the packets are forwarded through fixed paths, even if there is congestion between two nodes. Besides, IP multicast can not guarantee the quality of transmission as it uses UDP protocol in transport layer. As a supplement of the IP multicast technology, Labelcast can co- exist with IP multicast in the operational network. Routers can be configured to decide whether a packet is forwarded by IP multicast or labelcast labels, with the infomation of protocol field in IP packet. In Labelcast, the forwarding is depend on the label field, and the packets are forwarded by the label switching. Label aggregation techniques can be used to reduce the forwarding states. IP multicast address is considered as different group ID in Labelcast. If the forwarding node is not a Labelcast node, the packets is forwarded based on the layer 3 processing. In this way we are able to combine the two multicast technologies together even though it seems that they are conflicting with each other at the first glance. Labelcast can replace IP multicast if all the intermediate nodes support it. Compare to IP multicast, Labelcast can accelerate the forwarding speed and reduce the total routing overhead among the transmitting path. In a hybrid network of IP multicast and Labelcast, for example, IP tunnel mechanism or gateway mechanism can be utilized for the connection. Two solutions will be described later in chapter 6. 2.4. Lightweight protocol Labelcast is a lightweight protocol with two reasons. Firstly, it can be configured by utilizing Openflow technique [McKeown], and the labels are allocated through an external controller. The way to Sun, et al. Expires January 13, 2012 [Page 6] Internet-Draft Labelcast Protocol July 2011 calculate the label can be either centralized or distributed. Secondly, only a Labelcast module is added into the router, and the protocol stack in the hosts is with minor change. 3. Labelcast Protocol 3.1. Labelcast header format Labelcast header has the length of 8 bytes with seven fields which is illustrated in figure 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|PT | Seq | BW | Aid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | TS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Head Format (1) Ver [0:1] is the version of Labelcast protocol and it is defined "01" initially. (2) PT [0:1] denotes the type of frame, which decides the priority to discard packets. whether the playload it carries is I frame or B frame or P frame reflect the importance of packets. I frames own the highest priority and P frames own the lowest.11: having the highest discarding priority when there is a congestion (The first to be dropped). 00: having the lowest discarding level if there is a congestion (The last to be dropped). When network congestion occurs, flow control based on priorities can be realized. (3) Seq [0:11] denotes the sequences of packets which is used for the detection of the packets loss. It denotes the sequences of packets in the flow. It is used to monitor the packets loss and order. Suppose the sequence field is k bits, the length of packets is n bytes, and the bandwidth of the flow is Mbps, then the period of the sequence is Tseq = 2^k * n/M. (4) BW [0:5] denotes that the average bandwidth of flow is BW*128Kbps. The maximum value is 8Mbps. BW which has the value of 0 denotes that bandwidth is unknown. (5) Aid [0:7] denotes the application ID. (6) Label [0:15] denotes labels related to the packets routing. The Sun, et al. Expires January 13, 2012 [Page 7] Internet-Draft Labelcast Protocol July 2011 processing actions of nodes are determined by this field. The nodes which support the label determine the next hop forwarding nodes by looking up the label table. (7) TS [0:15] denotes the sending timestamp of packets, of which the unit is us(microsecond). It is used to account the delay between two nodes. 3.2. Forward label table The forward label table is composed of four tuples, which include ingress port number, ingress label, egress port number and egress label. The label entry is modified by outside controller through control protocol. In some special conditions, the tuple should be expanded. When there is a non-Labelcast node between two Labelcast nodes, it may receive two different video flows which have the same ingress port and label. However, the two different flows can not be distinguished by the above-mentioned forwarding label table. So some tuples are needed to identify flow ID, such as IP address of the source. 3.3. The Requirement for IP Protocol Fields The value of Labelcast protocol which is identified in IP header field is 123. 4. Requirement of Protocol 4.1. Processing Requirement 4.1.1. Building the Label Paths Similar to ATM and MPLS RFC 5332 [RFC5332], the virtual paths are established between the source and each receiver with extra means before IPTV data transmission. The extra means could be the signaling protocol of MPLS LDP RFC 3031 [RFC3031], or centralized control manners [I-D.kellil-sam-mtocp] of static calculation and configuration. 4.1.2. Requirement of the Source (1) If source is unaware of the contents of applications, the Pri field is filled with 00 uniformly. (2) Seq field could be filled when the packets are sent from source. Sun, et al. Expires January 13, 2012 [Page 8] Internet-Draft Labelcast Protocol July 2011 (3) BW field could be filled when the packets are sent from source. (4) The Aid field should be filled according to the application requirements. (5) Label field could be filled when the packets are sent from source. (6) The TS field could be filled when the packets are sent from source. 4.1.3. Processing Requirement of Labelcast Forwarding Nodes (1) Ver, Pri, Seq, BW and Aid can't be modified by Labelcast forwarding nodes. (2) Label field should be modified according to the next hop distribution nodes. When packets arrive at the Label nodes, Label table is looked up at first. From the label table, the local processing actions and the next egress labels are known . (3) According to the extra configure, TS field could be modified or keep unchanged by the forwarding nodes. (4) The nodes which don't support Labelcast protocol can forward the packets based on IP address. In order to prevent the initial virtual paths being deviated by IP forwarding from their inherent orientations, IP tunnels should be adopted. The packets are encapsulated with the address of next hop Labelcast nodes as the destination address, and then they can be sent to the next hop Label nodes directly. 4.1.4. Requirement of End Systems (1) The end systems submit the payload of packets to different applications according to Aid field. (2) The video transmission quality can be evaluated with BW, Seq, TS parameters etc. 4.2. Impact on protocol stack 4.2.1. Source serve The communication interface will be negotiated between server and client before data transmission, Labelcast packets are identified by Aid. The session manager in Source Server addes the Labelcast module Sun, et al. Expires January 13, 2012 [Page 9] Internet-Draft Labelcast Protocol July 2011 and it can support TCP, UDP and Labelcast. Stream processor can provide RTSP/RTP/UDP/HTTP/Labelcast and it encapsulates the transport layer header with Labelcast protocol form. 4.2.2. Client Client receives Labelcast packets with Raw Socket, it resolves Labelcast packets and sends the payload to the applications. Clients sample the video content and send the related information such as BW, Seq, TS to monitor. 4.2.3. Forwarding Node When a intermediate Labelcast node receives the Labelcast packets, it mainly has three processes: 1. Modify the TTL options in the header and recompute the checksum of IP header. 2. Modify the timestamp of the header, and rewirte the local time. 3. look up the label table, get the next hop, and replace the label. 5. Application Example 5.1. Point-to-Multipoint Data Distribution Based on Labels The label paths are composed of many labelcast nodes in series, and labels are assigned before the transmission of video traffic. The label tables are established according to their forwarding paths. The next hop Label nodes (one or multiple) can be determined by looking up the labels of packets in label table. Sun, et al. Expires January 13, 2012 [Page 10] Internet-Draft Labelcast Protocol July 2011 +--------+--------+--------+--------+ |Ingress |Ingress | Egress | Egress | | port | label | port | label | +--------+--------+--------+--------+ | 1 | 13 | 2 | 26 | +--------+--------+--------+--------+ \ | 3 | 19 | \ +--------+--------+ \ / \ / \ / \ / \ / \ / \ / +----+---------+ ######### +----+---------+ | 13 | Payload |----------# L1 #----------| 26 | Payload | +----+---------+ 1 ######### 2 +----+---------+ | |3 | | +----+---------+ | 19 | Payload | +----+---------+ Figure 2: Label Processing Figure 2 shows the label processing. When the packets with label 13 arrive at port 1 of Labelcast node L1, L1 looks up the lable table,then determine the forwarding ports and their corresponding new labels. Since there are two forwarding ports for packets arriving port 1 with label 13, the packets are replicated at L1, and forwarded to port 2 and port3. Before the forwarding process, the labels of packets are modified with new labels of 26 and 19 respectively. 5.2. Video-awre Network Processing Labelcast protocol can simplify the video traffic identifications at network nodes and can guarantee application-awree QoS through the Pri field which is initilized at the source. The video transmission quality can be monitored through Bw, TS, Seq fields, and correspondingly the distribution paths are optimized by the monitoring results. For example, the arrival intervals can be calculated by the Bw and length of packets, and then the delay jitters of the successive arriving packets can be concluded. Based on this, the processing actions of forwarding nodes can be optimized. Sun, et al. Expires January 13, 2012 [Page 11] Internet-Draft Labelcast Protocol July 2011 5.3. Detecting Network Status The characteristics of video transmission are high bandwidth- occupied, time-orderly, so they have high network requirement for Internet. For its continuity and time-orderly, video traffic itself is a good manner of network measurement, and network information is placed in the header of Labelcast protocol. Network status can be known by the Labelcast protocol. Through the analysis of TS and Seq fields, the performance of network can be acquired. The timestamps are marked by each Label nodes passing by, and whether or not the upstream links are congested can be inferred through the delay jitters between packets. t1,t2 denote the timestamps of two packets with N intervals in previous hop Label node, and the timestamps of local Label node are t3 and t4, then formula a=(t4-t3)/ (t2-t1) reflects the delay jitter of previous hop. 6. Labelcast Deployment Labelcast requires minor modification to the underlay network which can be deployed gradually. Labelcast processing module can be added into router by ISP just like a value-added module.. Labelcast nodes can coexist with the normal IP nodes in the network, which is unlike of MPLS or IP multicast where all the routers must provide support. 6.1. Relationship to Common API Considering a hybrid multicast network, a common multicast API [I-D.waehlisch-sam-common-api] which is suitable for transparent communication in underlay and overlay, and grants access to the different multicast flavors. Common API offers calls to transmit and receive multicast data independent of the supporting layer and the underlying technological details. So the deployment of Labelcast will have little influence for users since it is transparent to application layer if with support of common API. 6.2. IP tunnel IP tunnel can be used in a hybrid network where IP nodes and Labelcast nodes are connected with each other. If a Labelcast node A needs to go through an IP node B to another Labelcast node C, it will firstly look up the unicast or multicast table to get the forwarding port. Then, node A encapsulates the packet with the IP header of destination C and send it to B. Node B will forward the packet to C according to the IP route table. After node C receives the packet, it will remove the encapsulated IP header. Sun, et al. Expires January 13, 2012 [Page 12] Internet-Draft Labelcast Protocol July 2011 6.3. Gateway Gateway can be used to connect an IP multicast network with a Labelcast network. It can map a UDP header to a Labelcast header for transmitting through these two different networks. 7. Security Considerations The security issues brought by Labelcast is what we need take into consideration. 8. IANA Considerations The value of Labelcast protocol which is identified in IP header field is 123. 9. Acknowledgments The authors would like to acknowledge Dilife Tchnology, Inc. for help in Labelcast implementation of server and clients during project. 10. References 10.1. Normative References [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. 10.2. Informative References [I-D.kellil-sam-mtocp] Kellil, M., Janneteau, C., and P. Roux, "Multiparty Transport Overlay Control Protocol(MTOCP)", draft-kellil-sam-mtocp-01 (work in progress), July 2010. [I-D.litao-p2mpsmd-problem-statement] Sun, Z., Li, T., Wang, H., and C. Jia, "P2MP Streaming Sun, et al. Expires January 13, 2012 [Page 13] Internet-Draft Labelcast Protocol July 2011 Media Delivery", draft-litao-p2mpsmd-problem-statement-00 (work in progress), March 2011. [I-D.waehlisch-sam-common-api] Waehlisch, M., Schmidt, T., and S. Venaas, "A Common API for Transparent Hybrid Multicast", draft-waehlisch-sam-common-api-01 (work in progress), October 2009. [McKeown] McKeown, N., Anderson, T., and H. Balakrishnan, "OpenFlow: enabling innovation in campus networks.", Computer Communication Review, Vol38 2008. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4445] Welch, J. and J. Clark, "A Proposed Media Delivery Index (MDI)", RFC 4445, April 2006. [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. Authors' Addresses Zhi Gang. Sun NUDT 47 Yanwachi St Changsha, Hunan 410073 China Phone: +86-13875903721 Email: sunzhigang@nudt.edu.cn Hui. Wang NUDT 47 Yanwachi St Changsha, Hunan 410073 China Phone: +86-13467578342 Email: wanghuinudt@gmail.com Sun, et al. Expires January 13, 2012 [Page 14] Internet-Draft Labelcast Protocol July 2011 Tao. Li NUDT 47 Yanwachi St Changsha, Hunan 410073 China Phone: +86-13487568531 Email: taoli.nudt@gmail.com Jian Biao. Mao NUDT 47 Yanwachi St Changsha, Hunan 410073 China Phone: +86-13618464415 Email: mjn198812@sina.com Sun, et al. Expires January 13, 2012 [Page 15]