[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/