Internet DRAFT - draft-xia-icn-multiservtag
draft-xia-icn-multiservtag
ICN Working Group Xia Yong
INTERNET-DRAFT China SARFT
Intended Status: Informational S. Duan
Expires: Apr 30, 2018 China CAICT
Shu Liu
China CAICT
R.Huang
Huawei
Oct 30, 2017
the Consideration for the Application of Multi-Service Tag
draft-xia-icn-multiservtag-04
Abstract
According to the significant concepts and research challenges
described in RFC7927, we think that the multi-service tag technology
is a effective name mechanism for video contents in ICN. Because the
video traffic is the primary traffic transferred in the Internet, it
will tremendously promote the current Internet architecture to the
ICN architecture that the name mechanism for the video contents is
established. This document discusses the consideration for the design
of multi-service tag in ICN and how to use the multi-service tag
technology to establish the name mechanism for the video contents.
This document also gives the typical cases which use the above name
mechanism to improve the content distribution efficiency and cache
system 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
<Xia Yong> Expires Apr 30, 2018 [Page 1]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Oct 30, 2017
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
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 Analysis of the limitation of current network . . . . . . . . . 4
4 Name mechanism for the video contents in ICN . . . . . . . . . 5
5 Design of multi-service tag . . . . . . . . . . . . . . . . . . 5
5.1 the design rules of multi-service tag . . . . . . . . . . . 5
5.2 the preliminary design of multi-service tag . . . . . . . . 6
6 System of multi-service tag . . . . . . . . . . . . . . . . . . 7
7 Design of routing and route resolution for the multi-service
tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8 Some application cases . . . . . . . . . . . . . . . . . . . . 8
8.1 content resource sharing across ISP network . . . . . . . . 8
8.2 cache according to the content naming information . . . . . 8
9 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
12 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1 Normative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
<Xia Yong> Expires Apr 30, 2018 [Page 2]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Oct 30, 2017
1 Introduction
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.
The purpose of this document is to devise a mechanism allowing ICN
forwarders, consumers, producers and other ICN nodes to name content
identify content find content and share content.
2 Brief background
Now vast Internet video resources are concentrated in minority large
operators. If other operator hope to operate the Internet video, they
must buy the Internet traffics from the minority large operators.
therefore inter-network settlement is a big cost for the Internet
video operation and maybe over a half for the small operators. In
order to reduce the cost, the small operators spend lots of
expenditure to establish cache or CDN and thus each small operator
has many caches and CDN. These caches and CDN distribute in the
network just like some islands which stored data is repetitive for
more than 90 percent, thus the operation effect isn't desired and the
<Xia Yong> Expires Apr 30, 2018 [Page 3]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Oct 30, 2017
maintain cost is high. From the view of resource scheduling
mechanism, the content schedule relies on IP address under current
technique system, but many small operators don't have enough public
network IP address which leads to scheduling failure for OTT video
services though they have own caches and CDN.
So the operators imminently hope a technical solution to help
integrating the decentralized and repetitive content in the network
and get rid of the limiting condition of IP address. We think that
the name mechanism of Multi-Service Tag and ICN can effectively
resolve this problem. We plan to establish an ICN network in ICN-as-
an-overlay mode over different operators' network, get through the
content switching channels between different small operators and
realize unified schedule and sharing for the video resources through
the name mechanism of Multi-Service Tag. For the Implementation,
different small operators' networks distribute around ICN network
like islands and have sole interface to ICN. This interface collects
the information of content resource URL and its attributes and then
generate only name for the content according to some rules and
establish the mapping table between multi-service tag and URL for
content addressing. We broadcast the content addressing based mapping
tables to all ISPs through the ICN network and then all the operators
connecting the ICN will know the content distribution all over the
network, they can integrate the storage fragmentization and reduce
the content repetitive storage, the large amount of content can be
obtained by ICN sharing and decrease the cost spent on the Internet
traffic purchase from the large operators.
3 Analysis of the limitation of current network
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
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
<Xia Yong> Expires Apr 30, 2018 [Page 4]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Oct 30, 2017
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.
4 Name mechanism for the video contents in ICN
The ICN includes many Named Data Object (NDO) and it turns the
current "end host" network framework into "named information"
framework. In ICN, NDO is the core concept and independent of IP
address,which is the base of ICN network communication. The video
traffic is the highest percentage traffic in the Internet traffics.
As the network video gradually changes from standard definition video
to high definition and ultra HD video. Some new video applications
are rapidly popularized, such as short video application, video
social contact application and some related video applications, and
the video traffic is constantly growing. So it's necessary that the
video content must be regarded as a special NDO class to have
specialized design and consideration. The network video transmission
mostly uses slice transmission mechanism such as HLS and DASM
protocol. Based on the NDO granularity and transmission efficiency,
we suggest that the NDO design will use a whole video file or video
stream as a data unit and not take a slice as a NDO.
5 Design of multi-service tag
5.1 the design rules of multi-service tag
The design scheme of multi-service tag is a scheme just like URI
hierarchy naming scheme and its design follows the following
principles:
<Xia Yong> Expires Apr 30, 2018 [Page 5]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Oct 30, 2017
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 tag can be recognized by the network, the network can draw
up a strategy and adaptively transfer the content according to the
tag information;
f) confidence mechanism against tamper-proofing;
g) decrease the complexity of network management.
5.2 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:
xlables = base64( CID + content summary + type + random number +
signature )
xlables: fixed string which identifies tags and encrypts the
following information using base64.
CID: the identity of CP which is distributed by the tag service
system in a unified way.
content summary: the summary is extracted according to the file
content and corresponding to the file and actually is file hash. This
field can be used to identify the same cached content.
type: the kinds of the transferred file, such as video, picture,
document.
random number: it provides the signature identity
signature: it's produced according to the CID+content
summary+type+file size+[code rate]+timestamp+random number and used
to verify the validity of the tag.
<Xia Yong> Expires Apr 30, 2018 [Page 6]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Oct 30, 2017
6 System of multi-service tag
The system of multi-service tag is mainly made up by two function
modulars:
1)generating modular: this modular is deployed at the network edge
and interfaces with the operators. Its function is to generate multi-
service tags aimed at the specific content and establish binding
relationship between the video content and multi-service tag. This
modular will establish matchup relation between the multi-service tag
and video content actual store address in the operator network, and
send this matchup information to the assembly modular.
2)assembly modular: this modular is deployed at the network center
and responsible for collecting the matchup information between the
multi-service tag and video content storage location which is sent by
the generating modular. This modular will establish the whole network
NDO routing table by collecting the multi-service tag and content
storage address information all over the whole network and realize
the content inquiry service and routing resolution service according
naming information.
7 Design of routing and route resolution for the multi-service tag
The design of routing and route resolution for the multi-service tag
will adopt RFC7927 Look-By-Name Routing LBNR scheme which can fully
use the current network infrastructure.
1) The multi-service tag system will interface with the operator's
CDN or cache system firstly, then the generating modular will scan
the operator's content resource, establish the binding relationship
between content resource and multi-service tag, generate the mapping
relation for the network address and multi-service tag, send this
information to the assembly modular and form the mapping relation
table for the network address and multi-service tag in the assembly
modular.
2) When the operator receives the user inquiry, it will extract the
inquired naming information-multi-service tag through filter
mechanism and send it to the assembly modular.
3) The assembly modular find the final address information related
with the naming information through the mapping relation table of the
network address and multi-service tag, and send this information to
the user.
4) The user acquires the content through the network address.
<Xia Yong> Expires Apr 30, 2018 [Page 7]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Oct 30, 2017
8 Some application cases
8.1 content resource sharing across ISP network
The Internet video transmission usually uses the CDN technology and
cache technology to provide service for users and the CP will deploy
the CDN or cache nodes according to the user distribution in the
operator network. In order to guarantee QoE, the CP will deploy CDN
nodes with full resource in the network center and CDN nodes with hot
resource at the network edge which usually locate in the operator's
premises network. Each premises network operator has its own IP
address field and the user's IP address is allocated by the premises
network operator. In the current IP network, the CP can find the
nearest resource only according to the IP address in the inquiry and
then schedule the corresponding CDN node to serve the user, if the
edge CDN node has no the resource asked by the user, the CP will haul
the user inquiry back to the center CDN nodes with full resource and
schedule the corresponding resource to serve the user, and this can
easily form the network congestion of ISP haul-back route and
increase the network delay. Though the different ISP premises
networks have routing reachability, the content resource can't be
sharing among different IPS.
Under the video scheduling mechanism based on the IP address, IP
address will fragment the network resource and the same content will
have many IP address or URL, thus CP or ISP have to use large storage
resource to deploy the same hot content. IP address and URL are all
the network address information independent of the content and the
operator can't share the content through the address information.
In ICN, we can use the multi-service tag naming scheme to realize the
content resource sharing among ISPs and form larger content resource
sharing pool, thus all user can acquire the content in the pool and
it breaks the IP-ISP resource closed mechanism. The multi-service tag
assembly modular can acquire all ISP network resource information and
the user can use this information to find the relevant content.
8.2 cache according to the content naming information
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
<Xia Yong> Expires Apr 30, 2018 [Page 8]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Oct 30, 2017
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.
9 Security Considerations
TBD.
10 IANA Considerations
There is no IANA action in this document.
11 Acknowledgements
TBD.
12 References
12.1 Normative References
[RFC]7927, D. Kutscher, S., "Information-Centric
Networking (ICN) Research Challenges", [RFC]7927, July
2016, <https://www.rfc-editor.org/rfc/rfc7927.txt>
<Xia Yong> Expires Apr 30, 2018 [Page 9]
INTERNET DRAFT<the Consideration for the Application of Multi-Service Tag>Oct 30, 2017
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
Rachel Huang
Huawei
Email: rachel.huang@huawei.com
<Xia Yong> Expires Apr 30, 2018 [Page 10]
