One document matched: draft-xia-icn-multiservtag-01.txt
Differences from draft-xia-icn-multiservtag-00.txt
ICN Working Group Xia Yong
INTERNET-DRAFT China SARFT
Intended Status: Informational S. Duan
Expires: May 4, 2017 China CAICT
Shu Liu
China CAICT
Oct 31, 2016
the Consideration for the Design of Multi-Service Tag
draft-xia-icn-multiservtag-01
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
<Xia Yong> Expires May 4, 2017 [Page 1]
INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Oct 31, 2016
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.
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.1 the preliminary design of multi-service tag . . . . . . . . 5
4.2 the workflow of multi-service tag in CDN . . . . . . . . . . 6
5 Analysis of application case . . . . . . . . . . . . . . . . . 6
5.1 service perception by network . . . . . . . . . . . . . . . 6
5.2 intelligent cache . . . . . . . . . . . . . . . . . . . . . 7
5.3 content exchange between little ISPs . . . . . . . . . . . 7
6 Simple Demo . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1 Normative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
<Xia Yong> Expires May 4, 2017 [Page 2]
INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Oct 31, 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 diversified viewing model
modes support watch video in anytime and anywhere,which also results
in 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 handling of
the application traffic is a key factor for network operation. Each
network application uses 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 limitations. 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, especially for http traffic,
the http traffic usually use 80 or 8080 port, so the content in http
traffic is difficult to be identified accurately. 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
<Xia Yong> Expires May 4, 2017 [Page 3]
INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Oct 31, 2016
results. DFI/DPI may lose efficacy or become very complicated with
the more and more encrypted traffic in order to analyze the content
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
parse 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 lacks of protect mechanism and there is
no mechanism verifying 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.
<Xia Yong> Expires May 4, 2017 [Page 4]
INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Oct 31, 2016
This kind of tag is embedded into the content URL according to some
rules, it can transparently transferred in different networks and has
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) the network can adaptively transfer the content according to
the tag information;
f) confidence mechanism against tamper-proofing;
g) decrease the complexity of network management.
4.1 the preliminary design of multi-service tag
Here we give a simple and preliminary design of multi-service tag,
the scheme is not mature and may be changed along with the
development of the new technologies.
The format of multi-service tag is as following:
random code + the content source + the content class + the content
name + copyright information + other
random code: it provides the tag identity and the start bit of the
tag.
the content source: it indicates the source website of the content.
the content class: it indicates the classification codes for the
content which refers to the mainstream Film classification.
the content name: it shows the name of the content or the name of the
live channels.
copyright information:it indicates the copyright information carried
by the content.
For the CP, it can get the standard tag as the above pattern, then
uses symmetrical encryption for the tag and acquires the final
transferred tag.
<Xia Yong> Expires May 4, 2017 [Page 5]
INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Oct 31, 2016
For example, the tag of the film "The Revenant(2015)" is :
amH6lXSG30||CNTV||Story||The Revenant(2015)||1080P MP4||DRM||
The cryptographic tag is :
7tvWwO3L75Zcd9H-1cbCoOJmT5ghBjWG0mPNc7eyY8ZZRQToF9i5heLjLQSbohI7
After the CP get the cryptographic tag, it can use this tag in the
URL, as following:
http://[server-addr]/res/amH6lXSG30&7tvWwO3L75Zcd9H-
1cbCoOJmT5ghBjWG0mPNc7eyY8ZZRQToF9i5heLjLQSbohI7
4.2 the workflow of multi-service tag in CDN Here is a simple workflow
for multi-service tag in CDN:
1.When the new content comes, CP generates the corresponding
cryptographic tag for the content and store the tag into the database
with other related information, such as the bandwidth required for
transmission, target CDN and so on.
2.CP generates the corresponding URL with tag and publishes the URL
to the website.
3.CP pushes the content, the corresponding URL and related
information to the CDN and the CDN stores the relevant information
into its database.
4.When the uses requests for the content, the CP transmits the uses's
request URL to the nearest CDN.
5.The CDN receives the requested URL, identify the feature of the CP
and sends the CP to the user according to its bandwidth demand.
5 Analysis of application case
5.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
<Xia Yong> Expires May 4, 2017 [Page 6]
INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Oct 31, 2016
program flow and demands to network to allocate resource dynamically
for the 4k flow.
5.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
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.
5.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.
6 Simple Demo
We establish a simple demo to validate the availability of multi-
service tag, irrespective of security, network complexity and other
factors. In our demo, we make some simplification for the real
network components and the network structure is shown in Figure 1.
Test Terminal ----- bandwidth controller ------ content server
Figure 1 Demo network structure
<Xia Yong> Expires May 4, 2017 [Page 7]
INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Oct 31, 2016
The content server simulates the CP and CDN, its function
includes:manages the content, generates the tag and URL, publish the
URL, response the user request, maintain the content database. The
content database includes the content tag and its QoE.
When each new content comes, the content server generates the tag,
URL, database item for each content. When the user request for a
content, the content server receives the corresponding URL and finds
out the database item for it. The content server knows the QoE for
this content and sends demands to the bandwidth controller for
resource reservation. we use a H3C S5500 switch as bandwidth
controller.
We do a comparison test for the tag. The bandwidth controller
distributes 10M access bandwidth for each user in default and the
user asks for a h.264 video of 4K 60P. We make two URLs for this
video, one URL is without a tag and the other is with a tag. For the
first time, we can't watch the video smoothly for lack of enough
bandwidth. For the second time, we can watch the video smoothly.
Through this demo, the network can identify the feature of the
traffic through multi-service tag and no need to upgrade the network
devices, the multi-service can work in current network.
7 Security Considerations
TBA.
8 IANA Considerations
There is no IANA action in this document.
9 Acknowledgements
TBA.
<Xia Yong> Expires May 4, 2017 [Page 8]
INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Oct 31, 2016
8 References
8.1 Normative References
<Xia Yong> Expires May 4, 2017 [Page 9]
INTERNET DRAFT<the Consideration for the Design of Multi-Service Tag>Oct 31, 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
Shu Liu
China Academy of Telecommunication Research of MIIT
Email: liushu@catr.cn
<Xia Yong> Expires May 4, 2017 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 06:46:58 |