| Network Working Group | Z. Sun |
| Internet-Draft | H. Wang |
| Intended status: Standards Track | Z. . Zhang |
| Expires: September 16, 2011 | T. Li |
| NUDT | |
| March 15, 2011 |
Labelcast Protocol
draft-sunzhigang-sam-labelcast-01
This document presents a transport protocol-Labelcast, especially for IPTV data transmission. Labelcast has the functions of point-to-multipoint distribution and video quality monitoring. This document describes why Labelcast protocol is needed in IPTV service. The header format is defined, and the processing requirements of the protocol are specified. Impact on protocol stack is considered in this document Labelcast is a protocol intended for IPTV data distribution and can be deployed in an incremental manner.
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 September 16, 2011.
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.
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.
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 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.
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 requirements of the video quality transmission monitoring, failure detection and isolation of network failures.
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_t diagnose the transmission quality. Most streams are concentrated in the minority paths (the shortest ones). In IP multicast, the packets are just forwarded through the fixed paths, even if there is congestion between two nodes. Besides, IP multicast is uncontrollable.
Video monitor is the basis for market success of IPTV. Transmission information is essential to quality monitor and how the IP packets are carried over networks. It is therefore important for service providers and network providers to monitor the QoE of users when providing an IPTV service.
Now there is lacking efficient data distribution mechanism for IPTV services, especially between core network and access network, which is the bottleneck for IPTV data transmission. The transport technologies are not enough for the IPTV services and can_t satisfy the delays, jitters requirements. It is very urgent and significant to design a new distribution mechanism especially for IPTV video network.
Labelcast is a lightweight protocol and can provide abundant information for video quality monitor, failure detection, flow control, and so on. Many fields are involved in Labelcast header. Labelcast is very suitable for IPTV data transmission.
Labelcast setup the transmission paths between source and receivers through label switching. Labelcast has the functions of identifying packets priorities, bandwidth reservation, calculating time difference, statistics packets loss rate, etc. Based on this video streaming information, the network itself can evaluate the video transmission quality and optimize the scheduling strategies. The basic ideas are as follows:
Besides, the evaluation of the video transmission quality at intermediate routing nodes and end systems can take advantage of MDI index which is defined in RFC 4445. DF and MLR values are included in 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 flow QoS can be controlled.
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|Pri| Seq | BW | Aid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(1) Ver [0:1] is the version of Labelcast protocol and it is defined "01" initially.
(2) Pri[0:1] denotes packets priority of discarding. It is corresponding to the packet types of I frame, B frame and P frame which reflects the importance of packets. 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 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.
The value of Labelcast protocol which is identified in IP header field is 123.
Similar to ATM and MPLS, 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, or centralized control manners of static calculation and configuration.
(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.
(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.
(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.
(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.
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 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.
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.
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.
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.
+--------+--------+--------+--------+
|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 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.
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.
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.
In Labelcast, the forwarding information is embedded into the label field, and the packets are forwarded by the label swapped. Label aggregation techniques can be used to reduce the forwarding states. IP multicast address is identified as different group ID in Labelcast. If the forwarding node is not a Labelcast node, the packets is forwarded as layer 3 processing.
Labelcast changes little to the underlay network, and can be deployed gradually. Labelcast processing module can be added into router by ISP and this value-added module can bring more profits. The normal node can exist in two Labelcast nodes. Unlike in MPLS or IP multicast, all the routers must support them. IP tunnel can be used when the nodes is not a Labelcast node, and it lookup the unicast or multicast table to confirm the forwarding port.
The IANA issues brought by Labelcast is what we need take into consideration.
The security issues brought by Labelcast is what we need take into consideration.
We thank Dilife Tchnology, Inc. for help in Labelcast implementation of server and clients during project.
| [RFC1889] | Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. |
| [RFC3031] | Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. |
| [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. |
| [draft-kellil-sam-mtocp-01] | Rou, P., Kellil, M. and C. Janneteau, "Multiparty transport overlay control protocol(mtocp)", IETF Draft mtocp, July 2010. |