Internet DRAFT - draft-zhao-rtcweb-telesmartpipe

draft-zhao-rtcweb-telesmartpipe



 



RTCWeb Working Group                                             J. Zhao
Internet Draft                                                   X. Yang
                                                                P. Liang
                                                                   H. Ye
Intended status: Informational                             China Telecom
Expires:March 30, 2015                                September 26, 2014

            Considerations with RTCWeb in Telecom Smart Pipe
                   draft-zhao-rtcweb-telesmartpipe-00
                                    
Abstract
   Smart Pipe Service is telecom operator's  opening of network capacities
   to ISPs, which can provide broadband speeding-up and QoS experience to 
   end users. This document describes the mechanism to accelerate media
   stream transport in telecom operator's network of smart pipe for 
   Real-Time Communication in WEB-browsers (WebRTC). Compared with packet
   mark on browser side, this mechanism focus on platform side.


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 March 30, 2015.

Copyright Notice
   Copyright (c) 2013 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.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
 


Zhao, et al.             Expires March 30, 2015                 [Page 1]

Internet-Draft        RTCWeb in Telecom Smart Pipe              Sep 2014


   2. Conventions used in this document . . . . . . . . . . . . . . .  4
   3. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4. RTCWeb OTT Service With Smart Pipe Support  . . . . . . . . . .  4
     4.1. Introduction  . . . . . . . . . . . . . . . . . . . . . . .  4
     4.2. Interaction Procedures  . . . . . . . . . . . . . . . . . .  5
     4.3. Interface Description . . . . . . . . . . . . . . . . . . .  5
     4.4. Outstanding Issues  . . . . . . . . . . . . . . . . . . . .  6
   5. Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   7. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     7.1. Normative References  . . . . . . . . . . . . . . . . . . .  6
     7.2. Informative References  . . . . . . . . . . . . . . . . . .  6
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7



































 


Zhao, et al.             Expires March 30, 2015                 [Page 2]

Internet-Draft        RTCWeb in Telecom Smart Pipe              Sep 2014


1. Introduction

      The WebRTC use-cases and related requirements are defined in  
   [draft-ietf-rtcweb-use-cases-and requirements] that contains use-case
     titled global service provider. For these providers speed-up and
   QoS    ability of RTCWeb OTT service on telecom network is essential
   to their   user experience and also, Telecom operators are very glad
   to cooperate    with ISPs and join the broad band value chain.

      Compared with terminal packet marking approach on transport level
   for QoS   defined in [draft-ietf-rtcweb-qos], this document give a
   way on the    application level. When user make a call in RTCWeb
   supported browser,    the browser will connect with a TURN server or
   media server deployed    by RTCWeb OTT provider, so OTT application
   indeed knows browser's IP    and port in media session , and
   according to such IP info Telecom Smart    Pipe can identify user's
   telecom account and temporary increase bandwidth    only for the
   packet of that application. 

      Standing on end uses' perspective ,they do not need to order an
   costly    annual broadband service of high speed network from
   Telecom, but enjoy    the high speed experience as they needed and
   ISPs will pay for them.


   In order to provide broadband speed-up service and QoS from the
   telecom operator to RTCWeb OTT Service provider, This document
   presents the interaction process of WebRTC browser, OTT platform and
   Telecom Smart Pipe.

   +---------------------------------------------------------------------+
   |                                                                     |
   |                 +------------+       +-------------+                |
   |                 |   OTT      |       | Smart Pipe  |                |
   |          +----->| Web Server |------>|API Platform |----+           |
   |          |      +------------+       +-------------+    |           |
   |          |                                              |           |
   |          |                                              |           |
   |          |                                              |           |
   |          V                                              V           |
   |    +------------+            +------------+      +---------------+  |
   |    | RTCWeb     |<---------->| Smart Pipe |<---->|     IDC       |  |
   |    | Browser    |            |   BRAS     |      |OTT TURN Server|  |
   |    +------------+            +------------+      +---------------+  |
   |                                                                     |
   +---------------------------------------------------------------------+
             Figure 1. WebRTC system for telephony terminal

 


Zhao, et al.             Expires March 30, 2015                 [Page 3]

Internet-Draft        RTCWeb in Telecom Smart Pipe              Sep 2014


2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.
   Terminal: the terminal with browser that is equipped with a WebRTC JS
   application capable of interconnection with the operator server.

   RTCWeb OTT service provider: ISPs to provide emerging business on
   WebRTC supported browsers. They always have a lot of TURN servers or
   Media servers distributed on Telecom IDC.

   Smart Pipe: Smart Pipe is Telecom's openness of network capacities
   mainly used by ISPs, it can temporary increase network speed
   according to ISPs or Telecom users' demands. Smart Pipe consists of
   at least two network elements, one is API Platform and the other is
   BRAS.

   API Platform: a Web Server providing RESTful APIs of intelligent
   speed-up service to Telecom partners of OTT service. 

   BRAS: BRAS is Telecom's broadband remote access system which identify
   user, allocate IP address and control user's Internet speed. In Smart
   Pipe, BRAS is deployed everywhere  and controlled By API Platform.


3. Requirement

   Although OTT provider on RTCWeb service have deploy their TURN
   servers or Media servers with very high bandwidth, users still may
   fail to enjoy HD video calls due to their poor network capacity.
   Consider most RTCWeb service are used by common Internet business not
   enterprise business, this scenario is much worse.



4. RTCWeb OTT Service With Smart Pipe Support

4.1. Introduction

   The transport speed-up  rule in network device depend on network
   session 5-tuple. According to  whether destiny IP address or port is
   restricted,  one speed-up strategy is only the packets belong to
   specific application could be accelerated, the next strategy is all
 


Zhao, et al.             Expires March 30, 2015                 [Page 4]

Internet-Draft        RTCWeb in Telecom Smart Pipe              Sep 2014


   application packet would be accelerated. In this document we only
   talk about the first speed-up strategy commonly enjoyed by OTT
   providers.


4.2. Interaction Procedures

   1. Before user can make a call in Browser, they should first login
   into OTT platform    and connect with platform's RTCWeb signaling
   server using WebSocket in web page.    Of course,user's online info
   of public IP and telecom account should have already    been reported
   to Smart Pipe when they first connected with Internet through BRAS. 

   2. When user choose to make a call with the option of super video
   quality on this web   page, OTT server will launch three main web
   requests to the API Platform of Smart   Pipe. First request's aim is
   to obtain users' max capacity of network speed-up. 

   3. From the request, Smart pipe can obtain both caller and callee
   browser IP address   parameters, and convert them to users telecom
   account by query user online info   previously reported by BRAS . By
   querying network element setting from telecom's    IT and CRM 
   systems using users telecom account, Smart pipe can compute and   
   give a estimate value of users max possible network speed. 

   4. After OTT server get max possible network speed of downlink and
   uplink, it    calculate if this speed can meaningful improve RTCWeb
   video quality between    the two browser or between browser and its
   TURN server, if so it initiate second   request to Smart Pipe to give
   actual speed-up instructions. The request parameters    are composed
   of IP addresses and ports of two media endpoints. In peer to peer
   call   conversation, The destiny endpoint is TURN server or also a
   browser is based on    the notification of JavaScript SDK running on
   Web page provided by RTCWeb OTT    provider after browser's ICE
   negotiation ended.

   5. In the final network speed promoting process, Smart Pipe API
   platform assemble    special telecommunication message and send it
   separately to caller and callee side   BRAS,  and even to IDC where
   TURN server is located. The message has several fields   composed of
   source IP address, source port range, destiny IP and destiny port
   range,   together with channel bandwidth expected.  

   6. After user choose to end the call, OTT server then give the last
   request to Smart    Pipe to stop intelligent speed-up business. 


4.3. Interface Description
 


Zhao, et al.             Expires March 30, 2015                 [Page 5]

Internet-Draft        RTCWeb in Telecom Smart Pipe              Sep 2014


   interfaces below is all called from OTT server to API platform of
   Smart Pipe

   1. interface of getting users max capacity of network speed-up  
   request  fields: ISP id, set of public IPs   response fields: set of:
   user telecom account, used minutes of current month,   current speed
   and max speed of downlink and uplink

   2. interface of speed-up instruction   request  fields: set of: user
   telecom accounts, OTT application expected speed,    source IPs and
   ports with destiny IPs and ports, operation of speed up start or stop
     response fields: set of actual speed-up result

4.4. Outstanding Issues

   1. The approach to identify user's Telecom account in this document
   is from user's    public IP address, but in actual Telecom network
   infrastructure, some BRAS allocate   only Private IP address to the
   broadband user, So Smart Pipe does not know user's   public IP. In
   such situation , OTT provider may ask user to provide his Telecom   
   account or ask him to login into Telecom portal from same Web page.

   2. The approach in this document to control user network speed is
   depending on BRAS    in broadband environment, but not in 3G or LTE
   environment.

   3. The period from OTT send speed-up instruction to BRAS real take
   effect in some real   occasion will be a little longer up to 2
   minutes , so if users' call conversation is   very short, they have
   no feeling of high speed network experience.  


5. Security Considerations

      The interface security mechanism can refer to similar approach
   used by Open Platforms   on Internet.


6. IANA Considerations   There are no IANA considerations associated to
   this memo.

7. References
7.1. Normative References
7.2. Informative References [I-D.ietf-rtcweb-use-cases-and-requirements]
       C. Holmberg, et al., "Web Real-Time Communication Use-cases and  
     Requirements", draft-ietf-rtcweb-use-cases-and-requirements-13    
   (work in progress), February 2014

 


Zhao, et al.             Expires March 30, 2015                 [Page 6]

Internet-Draft        RTCWeb in Telecom Smart Pipe              Sep 2014


   [I-D.draft-ietf-rtcweb-qos]     S. Dhesikan, et al., "DSCP and other
   packet markings for RTCWeb QoS",     draft-dhesikan-tsvwg-rtcweb-qos,
   June 22, 2014

Authors' Addresses

   Jizhuang Zhao
   Beijing Research Institute of China Telecom
   Guanhua Building No 118 Xizhimennei Avenue,Xicheng Distr.
   CHINA
   Email:  zhaojzh@ctbri.com.cn


   Xin Yang
   Beijing Research Institute of China Telecom
   Guanhua Building No 118 Xizhimennei Avenue,Xicheng Distr.
   Email:  yangxin@ctbri.com.cn
   CHINA


   Peng Liang
   Beijing Research Institute of China Telecom
   Guanhua Building No 118 Xizhimennei Avenue,Xicheng Distr.
   CHINA
   Email:  liangpeng@ctbri.com.cn


   Hua Ye
   Beijing Research Institute of China Telecom
   Guanhua Building No 118 Xizhimennei Avenue,Xicheng Distr.
   CHINA
   Email:  yehua@ctbri.com.cn



















Zhao, et al.             Expires March 30, 2015                 [Page 7]