Network Working Group Z. Sun Internet-Draft H. Wang Intended status: Standards Track Z. Zhang Expires: April 20, 2011 NUDT October 17, 2010 Labelcast Protocol draft-sunzhigang-sam-labelcast-00.txt Abstract This document presents a light-weight, point-to-multipoint transport layer protocol named Labelcast, which utilizes a fix-length transport layer label to forward multicast packets. Labelcast is not a universal solution for Internet multicast, but aims to give an efficient point-to-multipoint data distribution protocol deployed in medium or small scale edge networks. Since Labelcast provides rich functions of quality monitoring, it's suitable to be applied in streaming data distribution systems. 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 April 20, 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 Sun, et al. Expires April 20, 2011 [Page 1] Internet-Draft Labelcast Protocol October 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Labelcast Header . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Header Definition . . . . . . . . . . . . . . . . . . . . . 4 2.2. Processing Requirement . . . . . . . . . . . . . . . . . . 5 3. Labelcast Packet Forwarding . . . . . . . . . . . . . . . . . . 5 3.1. Forwarding Principles . . . . . . . . . . . . . . . . . . . 5 3.2. Forward Processing Model . . . . . . . . . . . . . . . . . 6 3.3. Label Table Management . . . . . . . . . . . . . . . . . . 7 4. More Discussions . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Push-based Multicast . . . . . . . . . . . . . . . . . . . 7 4.2. Out-of-Band Management Model . . . . . . . . . . . . . . . 7 4.3. Support to Network Measurement . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Informative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Sun, et al. Expires April 20, 2011 [Page 2] Internet-Draft Labelcast Protocol October 2010 1. Introduction Nowadays point-to-multipoint streaming data distribution is one of the most popular applications in the Internet. Unfortunately, we have no suitable transport protocol and multicast mechanism to support it. Current transport protocol, such as TCP [RFC 793] and UDP[RFC 768], are not design for streaming data at the beginning, so they cannot provide transport services which streaming data need, e.g., real-time, equal-delay and continuity. On the other hand, IP multicast has not been well deployed in nearly twenty years from its birth. So many application layer techniques, such as RTP [RFC 3550], overlay multicast and P2P, are widely used. As a result, Internet becomes more and more ineffective and unmanageable. Content localization is an efficient way to solve this problem. As a result, most streaming data distribution applications, such IPTV, are restricted in network edge now. And networks which connect IPTV front end with end user, belong to the same management domains. So it is practical to adopt centralized mechanism to redesign transport protocol and multicast mechanism for local data distribution applications. This document proposes a new light-weight transport layer point-to- multipoint protocol named Labelcast. Labelcast use a fix-length label to identify transport layer connection in data distribution path. Each Labelcast packet carries a transport layer header, named Labelcast header, which contains a label and other information, between its IP header and application payload. In packet forwarding path, label-based forwarding table, abbreviated as label-table below, is used. Because Labelcast protocol is only used in a simple edge network environment, label assignment and label-tables calculation could be done in a centralized mode. Labelcast is a transport layer protocol because it is independent of IP layer techniques. No matter IPv4 or IPv6, and no matter IP multicast enabled or not, the behavior of Labelcast is not influenced. On the other hand, Labelcast is transparent to applications. The same as TCP and UDP service, applications can also use Labelcast transport service through socket interface. Labelcast is a light-weight protocol because it is unidirectional and easy to be implemented in the protocol stack of end system. Like RTP, Labelcast itself doesn't provide QoS guarantee and congest control, but it provides applocations with rich support to be aware of network state and QoS control. Sun, et al. Expires April 20, 2011 [Page 3] Internet-Draft Labelcast Protocol October 2010 2. Labelcast Header 2.1. Header Definition Labelcast header has the length of 8 bytes with seven fields which is illustrated in figure 1. 2-bit field Ver describes protocol version, and MUST be marked as "01" at present. Two-bit field Pri denotes packets priority of discarding. "11" has the highest discarding priority during congestion while "00" has the lowest discarding priority. For instance, in streaming video packet, Pri field could be marked corresponding to the payload types of I/B/P frame, which reflects the importance of packets. 12-bit field Seq records the sequence of a packet in data flow, which is used for packets loss detection. 8-bit field BW declares bandwidth requirement of the flow which equal to BW*128Kbps. Value 0 denotes bandwidth is unknown while value 255 represents that 32Mbps bandwidth is required. 8-bit field Aid denotes the application ID at the receiver, which is used to identify different applications just like the port number in TCP and UDP protocols. 16-bit Label field is designed for packets forwarding in the network. Functions and processing rules of this label resembles the label used in ATM and MPLS networks. 16-bit TS records time stamp of packet and unit of this field is microsecond. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Head Format Unlike the other transport protocols, some fields in Labelcast header MUST be rewritten in networks. Very similar to the label operation in MPLS network, label will be rewritten in each Labelcast enabled forwarding node. Besides, Labelcast forwarding node also marks its local time in TS field before the packet forwarding. In summary, Labelcast packet header contains two class of information, one class is used for packet forwarding and the other is for quality monitoring. Loss rate, delay jitter and some other QoS parameters could be calculated at any point of packet's forwarding path. Sun, et al. Expires April 20, 2011 [Page 4] Internet-Draft Labelcast Protocol October 2010 2.2. Processing Requirement If data distribution source node is unaware of the content of applications, the Pri field is filled with 00. BW field SHOULD be filled to declare bandwidth requirement. Seq, Aid, Label and TS field MUST be filled with the right value. Field of Ver, Pri, Seq, BW and Aid can't be modified by Labelcast forwarding nodes. Label field MUST be rewritten according to the label table and TS field MUST be updated to local time. The receiver SHOULD submit the payload of packets to different applications according to the Aid field. The usage of other fields at the receiver is optional. 3. Labelcast Packet Forwarding 3.1. Forwarding Principles Each Lablecast forwarding node has a label table, which is configured by a centralized manager in the network. Figure 2 shows the principles of point-to-multipoint forwarding process. When a packet with label 13 arrives at port 1 of forwarding node L1, Input port number (1) and incoming label (13) are utilized in lable table lookup to obtain output ports and their corresponding new labels. Since there are two output ports, port 2 and 3, the coming packet should be replicated and sent to port 2 and 3. Before these two packets' transmit, label should be replaced with new values of 26 and 19 respectively. Meanwhile, TS field should also be rewritten to local time. Sun, et al. Expires April 20, 2011 [Page 5] Internet-Draft Labelcast Protocol October 2010 +--------+--------+--------+--------+ |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 3.2. Forward Processing Model Incoming packets must be checked whether they are Labelcast packets or not first of all. Then Labelcast packets are sent to Labelcast forwarding plane and the other packets are sent to traditional IP forwarding plane. Packets are processed in two steps on Labelcast forwarding plane. At the ingress side, label and input port number are utilized to obtain the output bitmap by looking up label table, which guides the switch fabric to duplicate the packet. Some optional functions may also be implemented at the ingress side, such as loss rate and delay jitter calculation, and even Media Delivery Index (MDI) [RFC 4445] evaluation for streaming data. After duplication is done in switch fabric, packets are sent to corresponding egress side for processing. Then label table should be lookup again to obtain the new label which is rewritten to the packet. Obviously, before packet is transmitted, TS field MUST be updated to the current local time. Sun, et al. Expires April 20, 2011 [Page 6] Internet-Draft Labelcast Protocol October 2010 3.3. Label Table Management Label tables control packet forwarding. These tables are configured by a centralized Labelcast manager. Communication protocol between Labelcast manager and Labelcast enabled forwarding node should be further studied and standardized. 4. More Discussions 4.1. Push-based Multicast As we know, current multicast, no matter IP multicast or application layer multicast, are pull-based multicast. In pull-based multicast, multicast tree is constructed completely according to the receiver distribution and management policies can hardly impact data distribution behaviors. In push-based multicast, multicast tree is setup based on some policies. For instance, in IPTV systems, centralized management can direct data flows to everywhere in the network easily, no matter whether receiver exists or not. This is very useful to shorten the waiting time for a new receiver from sending a join message to the time that video data flow actually arrives. Besides, push-based multicast is well controlled. Traffic engineering and load balance is convenient to be deployed. 4.2. Out-of-Band Management Model Labelcast is a transport layer protocol, but all session control functions, including session setup, session close, QoS and congestion control, are left to application. This management model not only simplifies the complexities of protocol design and deployment, but also gives application developers more space to innovate and design their own characteristics. 4.3. Support to Network Measurement Streaming data has characteristics of continuity and time-orderly, so streaming data itself could be used as network measurement data. By the analysis of TS and Seq fields, network status is evaluated. For instance, link congestion status between two Labelcast enabled forwarding node could be deduced by delay jitters and analyzed between packets. Let t1, t2 denote timestamps of two packets marked in previous node, and these two packets arrive at the local node at local time t3 and t4, then formula a=(t4-t3)/(t2-t1) reflects the Sun, et al. Expires April 20, 2011 [Page 7] Internet-Draft Labelcast Protocol October 2010 delay jitter of previous hop. 5. IANA Considerations Because Labelcast is a new transport protocol, IANA should assign a protocol number to Labelcast, just as TCP has a number of 6 and UDP has a number of 17. Currently, we use number 253 for Labelcast protocol experiment and test. 6. Security Considerations The security issues brought by Labelcast is what we need take into consideration. 7. Acknowledgments We would like to thank Prof. Gong Zhenghu and Su Jinshu at NUDT, as well as Dr. Cui Yong at Tsinghua University. 8. Informative References [RFC 3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Application", RFC 3550, July 2003. [RFC 4445] Welch, J. and J. Clark, "A Proposed Media Delivery Index (MDI)", RFC 4445, April 2006. [RFC 768] Postel, J., "User Datagram Protocol", RFC 768, August 1980. [RFC 793] "Transmission Control Protocol", RFC 793, September 1981. Sun, et al. Expires April 20, 2011 [Page 8] Internet-Draft Labelcast Protocol October 2010 Authors' Addresses Zhi Gang. Sun NUDT 47 Yanwachi St Changsha China Phone: +86-13875903721 Email: sunzhigang@nudt.edu.cn Hui. Wang NUDT 47 Yanwachi St Changsha China Phone: +86-13467578342 Email: wanghuinudt@gmail.com Zi Wen. Zhang NUDT 47 Yanwachi St Changsha China Phone: +86-13975137411 Email: ziwen@nudt.edu.cn Sun, et al. Expires April 20, 2011 [Page 9]