One document matched: draft-xia-icn-multiservtag-00.txt

 



ICN Working Group                                               Xia Yong
INTERNET-DRAFT                                               China SARFT
Intended Status: Informational                                   S. Duan
Expires: Jan 6, 2017                                         China CAICT
                                                             Jul 6, 2016


         the Consideration for the Design of Multi-Service Tag
                     draft-xia-icn-multiservtag-00

Abstract

   This document discusses the consideration for the design of multi-
   service tag in the current complex network so as to optimize traffic
   model and improve the transmission efficiency.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License 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
 


<Xia Yong>                Expires Jan 6, 2017                   [Page 1]

INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Jul 6, 2016


   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  Brief background  . . . . . . . . . . . . . . . . . . . . . . .  3
   3  The analysis of the limitation of current technologies  . . . .  3
     3.1 Identifying the content  . . . . . . . . . . . . . . . . . .  4
     3.2 Identifying the source . . . . . . . . . . . . . . . . . . .  4
   4 Consideration for the design of multi-service tag  . . . . . . .  4
   4  Analysis of application case  . . . . . . . . . . . . . . . . .  5
     4.1  service perception by network . . . . . . . . . . . . . . .  5
     4.2  intelligent cache . . . . . . . . . . . . . . . . . . . . .  5
     4.3  content exchange between little ISPs  . . . . . . . . . . .  6
   5  Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   7  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  6
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.1  Normative References  . . . . . . . . . . . . . . . . . . .  7
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8























 


<Xia Yong>                Expires Jan 6, 2017                   [Page 2]

INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Jul 6, 2016


1  Introduction

   The document discusses the feasibility of multi-service tag in the
   current internet , analyzes the limitation of the related
   technologies, gives the requirements of the multi-service tag and the
   corresponding use cases.

2  Brief background

   Now the network traffic presents a rapid increase trend, the
   popularization of network video and the watch model in anytime and
   anywhere also advance the increase of network traffic. The network
   video Apps must provide terrific Quality of experience(QoE). These
   trends represent a developing direction of future networks.
   Recognition and dispose of the application traffic is a key factor
   for network operation. Each network application use different
   protocol and is deployed by different ISP, which incompletely 
   depends on the network operaters. The method of the recognition of
   traffic and applications uses the fuzzy heuristic modes which are
   based on the port scope and key information of the traffic and are
   similar with the DPI technology, but this series of technologies have
   some limits. The heuristic methods can't effectively solve the
   problem of traffic recognition because they can't keep up with the
   synchronization update of application characteristics. The traffic
   recognition schemes based on the port scope detection face the great
   challenge because of enormous amount of ports which are
   discontinuous. Due to the encryption transmission of more and more
   traffic, these lead to the great increase of DFI/DPI calculated
   amount and make these two technologies be faced with invalidation. IP
   tunneling technology makes the operator's network more complex. So we
   need a new technology which can rapidly and uniquely recognize the
   traffic based on its characteristics without resolve the whole
   package.


3  The analysis of the limitation of current technologies

   The traffic recognition ways based on IP address pool face
   difficulties. Because IP address is of large amount, dynamic,
   proprietary or private. According to the CDN protocol (RFC 6770), the
   content can be transferred to different CDN and this makes it
   impossible to track the content among different CDN in terms of its
   IP address. Though the traffic recognition based on IP address is
   possible in some scenes, it's impossible to exactly identify every
   flow. Because the same port is maybe repetitively used by different
   application, the traffic recognition based on port may lead the wrong
   results. DFI/DPI may lose efficacy or become very complicated with
   the more and more encrypted traffic in order to analyze the content
 


<Xia Yong>                Expires Jan 6, 2017                   [Page 3]

INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Jul 6, 2016


   contained by the traffic. A traffic flow of an application will end
   at user terminal through different network routes and this will
   affect the analysis of the traffic flow. There are no unified
   standards for traffic recognition and analysis and it will lead to
   different analysis results for the same traffic flow due to the
   analysis ability and implementation ways. The traffic analysis will
   resolve the payload of the packages, thus it will affect the package
   processing efficiency which need extra process, and the ever-
   increasing new protocols also affect the DFI/DPI devices efficiency.
   The flow tag is defined in RFC6437 and it only applies in IPv6
   protocols. The flow tag changes along with the specific traffic flow
   and just like port. The flow tag can't identify the traffic flow
   independently and it must be used with source/destination IP
   addresses together. Because the flow tag is fixed in IPv6 header, it
   can identified easily, but it lack of protect mechanism and there no
   mechanism ti verify its integrity.

   In general, the current traffic recognition ways is limited in the
   analysis of traffic flows, they can't provide effective feedback
   data, so they can't support the self-adaptive network processing
   capability established by the operators.

3.1 Identifying the content

   In order to improve the hit ratio and actively push the hot resources
   to the local subscribers, the cache system need a succinct way to
   learn the buffered contents and can judge the hot content according
   to the actual content information. 

3.2 Identifying the source

   To enable flexible reverse charging, we need a third party
   recognizable tag of the traffic for the charging GW located between
   the client and server, which helps in recognition of its source and
   billing model, and other features to enable other cultivated
   transport services, e.g. QoS for selected content types for a given
   ICP.

4 Consideration for the design of multi-service tag

   We design a multi-service tag which can help the network better know
   the traffics which it carries. The multi-service tag design abandons
   the traditional fuzzy heuristic design idea and directly include the
   information about the transferred contents and the requirements for
   the transmission network. 

   This kind of tag is embedded into the content URL according to some
   rules, it can transparently transferred in different networks and has
 


<Xia Yong>                Expires Jan 6, 2017                   [Page 4]

INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Jul 6, 2016


   no impact on existing services, and we call it multi-service tag. It
   has the following features:   a) no relationship with IP address or
   port number;

      b) one-to-one correspondence to the transferred content;

      c) stable in a traffic flow lifecycle;

      d) easily obtained and handled by the network operator;

      e) clearly distinguish IP flow and its class;

      f) the network can adaptively transfer the content according to
   the tag information;

      g) confidence mechanism against tamper-proofing;

      h) decrease the complexity of network management.



4  Analysis of application case

4.1  service perception by network

   The Internet video traffic becomes the major service traffic and the
   video traffic has high demands for the transmission network and is
   sensitive to the network. The 4k programs transmission needs more
   than 30Mbps bandwidth, it can't guarantee the QoS even though CDN is
   used for the transmission. The core problem is that the network isn't
   able to know the carried service and thus allocate resources
   dynamically. We can use multi-service tag to resolve the problem.
   Because the tag can contain the information of the carried service,
   the network operator can use tag to quickly identify and handle 4k
   program flow and demands to network to allocate resource dynamically
   for the 4k flow.

4.2  intelligent cache

   The cache technology is always one of the main technological means
   for decreasing inter-network settlement charge and enhancing QoE. The
   maximal challenge which the traditional cache technology faces is
   that the repetitive contents waste the cache resource. The core
   technology of the traditional cache is to obtain URL contents and
   store them locally by monitoring the hot program's URLs through DPI.
   But the URL is not stable and the same contents may have different
   URLs. Though we can use DPI to decode the content and acquire partial
   content characteristics to compare, it has major limitations at
 


<Xia Yong>                Expires Jan 6, 2017                   [Page 5]

INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Jul 6, 2016


   decreasing the repetitive contents and greatly increases the
   computation complexity, what is more, the begin of the content is
   often advertisement or station caption and this makes content
   comparison different to work well. The multi-service tag contains the
   attribute information of carried content which is one-to-one
   correspondence to the content, then the cache system can use the tag
   as the base of comparison so as to quickly discover the repetitive
   contents and raise cache efficiency.


4.3  content exchange between little ISPs

   In order to reduce operating costs, little ISPs are apt to
   interconnect each other to realize the user scale increase and
   resource sharing. Each little ISP has establish its own cache system
   or CDN node in order to decrease the inter-network settlement expense
   with the large ISP. The different little ISP must indicate the
   location of content storage and content itself, then issue the
   content URL. The multi-service tag not only include the information
   of the content and also bound together with the URL to transfer, thus
   resolve the problem of program content sharing after ISP
   interconnection.


5  Security Considerations

   TBA.


6  IANA Considerations

   There is no IANA action in this document.

7  Acknowledgements

   TBA.












 


<Xia Yong>                Expires Jan 6, 2017                   [Page 6]

INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Jul 6, 2016


8  References

8.1  Normative References













































 


<Xia Yong>                Expires Jan 6, 2017                   [Page 7]

INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Jul 6, 2016


Authors' Addresses


   Yong Xia
   China SARFT

   Email: xiayong@abs.ac.cn




   Shihui Duan
   China Academy of Telecommunication Research of MIIT

   Email: duanshihui@catr.cn




































<Xia Yong>                Expires Jan 6, 2017                   [Page 8]