[SAM] New Version Notification for draft-sunzhigang-sam-labelcast-02.txt

zhigang sun <sunzhigang.nudt@gmail.com> Thu, 14 July 2011 05:36 UTC

MIME-Version: 1.0
Date: Thu, 14 Jul 2011 13:36:54 +0800
Message-ID: <CAE==51RdkmC59VAL4REMKHe3vPuU9P6g7rk7g+MzK0Z2avSABQ@mail.gmail.com>
From: zhigang sun <sunzhigang.nudt@gmail.com>
To: sam@irtf.org
Content-Type: multipart/alternative; boundary="000e0cd28680af487f04a800eba3"
Subject: [SAM] New Version Notification for draft-sunzhigang-sam-labelcast-02.txt
Precedence: list

Hello everyone,

We have undated labelcast draft according to the questions and advices in
last IETF meeting.

The main change include:
(1) Labelcast does not exclude RTP/RTCP.
RTP/RTCP is an excellent protocol for multimedia data transportatiaphy on
and RTCP based feedback can not only provide receiver's QoE information, but
also support network tomography that can deduce network status(but not real
time).
Labelcast replaces or updates the UDP header, It can implement three
functions using its 8 byte header. Application mux/dex, in-network
measurement and label-based multicast forwarding control.

(2)labelcast can coexist with IP multicast Charter of sam says "new
protocols are expected to coexist and integrate with native IP multicast
protocols while offering more flexible deployment options and scaling to
support a greater number of simultaneous multicast groups."
So we consider labelcast can coexist with ip multicast or it is a supplement
to IP multicast. Multicast control table(or labelcast table) is configured
by external controllers while IP multicast FIB is generated by existing
routing protocols.
I think it is more like openflow. Labelcast provide a policy interface to
outside of network devices. But how to generate labelcast table by a outside
controller and the management interface define of labelcast is beyond this
draft.

(3)labelcast deployment problem is discussed We discuss its relationship to
"common API", and use IP tunnel and gateways to implement incremental
deployment. We suppose application developments are based on common API, and
middleware on the sender host can encapsulate payload into labelcast packet
and vice versa at the receiver end.

Any comments is welcome on the list, and we hope to get more feedback in the
meeting.

Best Regards.

Sun zhigang



-----邮件原件-----
发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
发送时间: 2011年7月12日7:23
收件人: sunzhigang@263.net
抄送: sunzhigang@nudt.edu.cn; wanghuinudt@gmail.com; sunzhigang@263.net;
taoli.nudt@gmail.com; mjn198812@sina.com
主题: New Version Notification for draft-sunzhigang-sam-labelcast-02.txt

A new version of I-D, draft-sunzhigang-sam-labelcast-02.txt has been
successfully submitted by Zhigang Sun and posted to the IETF repository.

Filename:          draft-sunzhigang-sam-labelcast
Revision:  02
Title:                  Labelcast Protocol
Creation date:2011-07-12
WG ID:              Individual Submission
Number of pages: 15

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.





The IETF Secretariat

[SAM] New Version Notification for draft-sunzhiga… zhigang sun