ICN Working Group Xia Yong INTERNET-DRAFT China SARFT Intended Status: Informational S. Duan Expires: Jan 3, 2018 China CAICT Shu Liu China CAICT R.Huang Huawei Jul 3, 2017 the Consideration for the Application of Multi-Service Tag draft-xia-icn-multiservtag-03 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 Expires Jan 3, 2018 [Page 1] INTERNET DRAFTJul 3, 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 Analysis of the limitation of current network . . . . . . . . . 3 3 Name mechanism for the video contents in ICN . . . . . . . . . 4 4 Design of multi-service tag . . . . . . . . . . . . . . . . . . 4 4.1 the design rules of multi-service tag . . . . . . . . . . . 5 4.2 the preliminary design of multi-service tag . . . . . . . . 5 5 System of multi-service tag . . . . . . . . . . . . . . . . . . 6 6 Design of routing and route resolution for the multi-service tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7 Some application cases . . . . . . . . . . . . . . . . . . . . 7 7.1 content resource sharing across ISP network . . . . . . . . 7 7.2 cache according to the content naming information . . . . . 8 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1 Normative References . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Expires Jan 3, 2018 [Page 2] INTERNET DRAFTJul 3, 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 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 Expires Jan 3, 2018 [Page 3] INTERNET DRAFTJul 3, 2017 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 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. 4 Design of multi-service tag Expires Jan 3, 2018 [Page 4] INTERNET DRAFTJul 3, 2017 4.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: 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. 4.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. Expires Jan 3, 2018 [Page 5] INTERNET DRAFTJul 3, 2017 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. 5 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. 6 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. Expires Jan 3, 2018 [Page 6] INTERNET DRAFTJul 3, 2017 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. 7 Some application cases 7.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. Expires Jan 3, 2018 [Page 7] INTERNET DRAFTJul 3, 2017 7.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 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. 8 Security Considerations TBD. 9 IANA Considerations There is no IANA action in this document. 10 Acknowledgements TBD. 11 References 11.1 Normative References [RFC]7927, D. Kutscher, S., "Information-Centric Networking (ICN) Research Challenges", [RFC]7927, July 2016, Expires Jan 3, 2018 [Page 8] INTERNET DRAFTJul 3, 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 Expires Jan 3, 2018 [Page 9]