idnits 2.17.1 draft-xia-icn-multiservtag-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 97 has weird spacing: '...pletely depen...' -- The document date (Oct 30, 2017) is 2363 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Working Group Xia Yong 3 INTERNET-DRAFT China SARFT 4 Intended Status: Informational S. Duan 5 Expires: Apr 30, 2018 China CAICT 6 Shu Liu 7 China CAICT 8 R.Huang 9 Huawei 10 Oct 30, 2017 12 the Consideration for the Application of Multi-Service Tag 13 draft-xia-icn-multiservtag-04 15 Abstract 17 According to the significant concepts and research challenges 18 described in RFC7927, we think that the multi-service tag technology 19 is a effective name mechanism for video contents in ICN. Because the 20 video traffic is the primary traffic transferred in the Internet, it 21 will tremendously promote the current Internet architecture to the 22 ICN architecture that the name mechanism for the video contents is 23 established. This document discusses the consideration for the design 24 of multi-service tag in ICN and how to use the multi-service tag 25 technology to establish the name mechanism for the video contents. 26 This document also gives the typical cases which use the above name 27 mechanism to improve the content distribution efficiency and cache 28 system efficiency. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2 Brief background . . . . . . . . . . . . . . . . . . . . . . . 3 69 3 Analysis of the limitation of current network . . . . . . . . . 4 70 4 Name mechanism for the video contents in ICN . . . . . . . . . 5 71 5 Design of multi-service tag . . . . . . . . . . . . . . . . . . 5 72 5.1 the design rules of multi-service tag . . . . . . . . . . . 5 73 5.2 the preliminary design of multi-service tag . . . . . . . . 6 74 6 System of multi-service tag . . . . . . . . . . . . . . . . . . 7 75 7 Design of routing and route resolution for the multi-service 76 tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 8 Some application cases . . . . . . . . . . . . . . . . . . . . 8 78 8.1 content resource sharing across ISP network . . . . . . . . 8 79 8.2 cache according to the content naming information . . . . . 8 80 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 81 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 83 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 12.1 Normative References . . . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 87 1 Introduction 89 Now the network traffic presents a rapid increase trend, the 90 popularization of network video and the diversified viewing model 91 modes support watch video in anytime and anywhere,which also results 92 in the increase of network traffic. The network video Apps must 93 provide terrific Quality of experience(QoE). These trends represent a 94 developing direction of future networks. Recognition and handling of 95 the application traffic is a key factor for network operation. Each 96 network application uses different protocol and is deployed by 97 different ISP, which incompletely depends on the network operaters. 98 The method of the recognition of traffic and applications uses the 99 fuzzy heuristic modes which are based on the port scope and key 100 information of the traffic and are similar with the DPI technology, 101 but this series of technologies have some limitations. The heuristic 102 methods can't effectively solve the problem of traffic recognition 103 because they can't keep up with the synchronization update of 104 application characteristics. The traffic recognition schemes based on 105 the port scope detection face the great challenge because of enormous 106 amount of ports which are discontinuous, especially for http traffic, 107 the http traffic usually use 80 or 8080 port, so the content in http 108 traffic is difficult to be identified accurately. Due to the 109 encryption transmission of more and more traffic, these lead to the 110 great increase of DFI/DPI calculated amount and make these two 111 technologies be faced with invalidation. IP tunneling technology 112 makes the operator's network more complex. So we need a new 113 technology which can rapidly and uniquely recognize the traffic based 114 on its characteristics without resolve the whole package. 116 The purpose of this document is to devise a mechanism allowing ICN 117 forwarders, consumers, producers and other ICN nodes to name content 118 identify content find content and share content. 120 2 Brief background 122 Now vast Internet video resources are concentrated in minority large 123 operators. If other operator hope to operate the Internet video, they 124 must buy the Internet traffics from the minority large operators. 125 therefore inter-network settlement is a big cost for the Internet 126 video operation and maybe over a half for the small operators. In 127 order to reduce the cost, the small operators spend lots of 128 expenditure to establish cache or CDN and thus each small operator 129 has many caches and CDN. These caches and CDN distribute in the 130 network just like some islands which stored data is repetitive for 131 more than 90 percent, thus the operation effect isn't desired and the 132 maintain cost is high. From the view of resource scheduling 133 mechanism, the content schedule relies on IP address under current 134 technique system, but many small operators don't have enough public 135 network IP address which leads to scheduling failure for OTT video 136 services though they have own caches and CDN. 138 So the operators imminently hope a technical solution to help 139 integrating the decentralized and repetitive content in the network 140 and get rid of the limiting condition of IP address. We think that 141 the name mechanism of Multi-Service Tag and ICN can effectively 142 resolve this problem. We plan to establish an ICN network in ICN-as- 143 an-overlay mode over different operators' network, get through the 144 content switching channels between different small operators and 145 realize unified schedule and sharing for the video resources through 146 the name mechanism of Multi-Service Tag. For the Implementation, 147 different small operators' networks distribute around ICN network 148 like islands and have sole interface to ICN. This interface collects 149 the information of content resource URL and its attributes and then 150 generate only name for the content according to some rules and 151 establish the mapping table between multi-service tag and URL for 152 content addressing. We broadcast the content addressing based mapping 153 tables to all ISPs through the ICN network and then all the operators 154 connecting the ICN will know the content distribution all over the 155 network, they can integrate the storage fragmentization and reduce 156 the content repetitive storage, the large amount of content can be 157 obtained by ICN sharing and decrease the cost spent on the Internet 158 traffic purchase from the large operators. 160 3 Analysis of the limitation of current network 162 The traffic recognition ways based on IP address pool face 163 difficulties. Because IP address is of large amount, dynamic, 164 proprietary or private. According to the CDN protocol (RFC 6770), the 165 content can be transferred to different CDN and this makes it 166 impossible to track the content among different CDN in terms of its 167 IP address. Though the traffic recognition based on IP address is 168 possible in some scenes, it's impossible to exactly identify every 169 flow. Because the same port is maybe repetitively used by different 170 application, the traffic recognition based on port may lead the wrong 171 results. DFI/DPI may lose efficacy or become very complicated with 172 the more and more encrypted traffic in order to analyze the content 173 contained by the traffic. A traffic flow of an application will end 174 at user terminal through different network routes and this will 175 affect the analysis of the traffic flow. There are no unified 176 standards for traffic recognition and analysis and it will lead to 177 different analysis results for the same traffic flow due to the 178 analysis ability and implementation ways. The traffic analysis will 179 parse the payload of the packages, thus it will affect the package 180 processing efficiency which need extra process, and the ever- 181 increasing new protocols also affect the DFI/DPI devices efficiency. 182 The flow tag is defined in RFC6437 and it only applies in IPv6 183 protocols. The flow tag changes along with the specific traffic flow 184 and just like port. The flow tag can't identify the traffic flow 185 independently and it must be used with source/destination IP 186 addresses together. Because the flow tag is fixed in IPv6 header, it 187 can identified easily, but it lacks of protect mechanism and there is 188 no mechanism verifying its integrity. 190 In general, the current traffic recognition ways is limited in the 191 analysis of traffic flows, they can't provide effective feedback 192 data, so they can't support the self-adaptive network processing 193 capability established by the operators. 195 4 Name mechanism for the video contents in ICN 197 The ICN includes many Named Data Object (NDO) and it turns the 198 current "end host" network framework into "named information" 199 framework. In ICN, NDO is the core concept and independent of IP 200 address,which is the base of ICN network communication. The video 201 traffic is the highest percentage traffic in the Internet traffics. 202 As the network video gradually changes from standard definition video 203 to high definition and ultra HD video. Some new video applications 204 are rapidly popularized, such as short video application, video 205 social contact application and some related video applications, and 206 the video traffic is constantly growing. So it's necessary that the 207 video content must be regarded as a special NDO class to have 208 specialized design and consideration. The network video transmission 209 mostly uses slice transmission mechanism such as HLS and DASM 210 protocol. Based on the NDO granularity and transmission efficiency, 211 we suggest that the NDO design will use a whole video file or video 212 stream as a data unit and not take a slice as a NDO. 214 5 Design of multi-service tag 216 5.1 the design rules of multi-service tag 218 The design scheme of multi-service tag is a scheme just like URI 219 hierarchy naming scheme and its design follows the following 220 principles: 222 a) no relationship with IP address or port number; 224 b) one-to-one correspondence to the transferred content; 226 c) stable in a traffic flow lifecycle; 228 d) easily obtained and handled by the network operator; 230 e) the tag can be recognized by the network, the network can draw 231 up a strategy and adaptively transfer the content according to the 232 tag information; 234 f) confidence mechanism against tamper-proofing; 236 g) decrease the complexity of network management. 238 5.2 the preliminary design of multi-service tag 240 Here we give a simple and preliminary design of multi-service tag, 241 the scheme is not mature and may be changed along with the 242 development of the new technologies. 244 The format of multi-service tag is as following: 246 xlables = base64( CID + content summary + type + random number + 247 signature ) 249 xlables: fixed string which identifies tags and encrypts the 250 following information using base64. 252 CID: the identity of CP which is distributed by the tag service 253 system in a unified way. 255 content summary: the summary is extracted according to the file 256 content and corresponding to the file and actually is file hash. This 257 field can be used to identify the same cached content. 259 type: the kinds of the transferred file, such as video, picture, 260 document. 262 random number: it provides the signature identity 264 signature: it's produced according to the CID+content 265 summary+type+file size+[code rate]+timestamp+random number and used 266 to verify the validity of the tag. 268 6 System of multi-service tag 270 The system of multi-service tag is mainly made up by two function 271 modulars: 273 1)generating modular: this modular is deployed at the network edge 274 and interfaces with the operators. Its function is to generate multi- 275 service tags aimed at the specific content and establish binding 276 relationship between the video content and multi-service tag. This 277 modular will establish matchup relation between the multi-service tag 278 and video content actual store address in the operator network, and 279 send this matchup information to the assembly modular. 281 2)assembly modular: this modular is deployed at the network center 282 and responsible for collecting the matchup information between the 283 multi-service tag and video content storage location which is sent by 284 the generating modular. This modular will establish the whole network 285 NDO routing table by collecting the multi-service tag and content 286 storage address information all over the whole network and realize 287 the content inquiry service and routing resolution service according 288 naming information. 290 7 Design of routing and route resolution for the multi-service tag 292 The design of routing and route resolution for the multi-service tag 293 will adopt RFC7927 Look-By-Name Routing LBNR scheme which can fully 294 use the current network infrastructure. 296 1) The multi-service tag system will interface with the operator's 297 CDN or cache system firstly, then the generating modular will scan 298 the operator's content resource, establish the binding relationship 299 between content resource and multi-service tag, generate the mapping 300 relation for the network address and multi-service tag, send this 301 information to the assembly modular and form the mapping relation 302 table for the network address and multi-service tag in the assembly 303 modular. 305 2) When the operator receives the user inquiry, it will extract the 306 inquired naming information-multi-service tag through filter 307 mechanism and send it to the assembly modular. 309 3) The assembly modular find the final address information related 310 with the naming information through the mapping relation table of the 311 network address and multi-service tag, and send this information to 312 the user. 314 4) The user acquires the content through the network address. 316 8 Some application cases 318 8.1 content resource sharing across ISP network 320 The Internet video transmission usually uses the CDN technology and 321 cache technology to provide service for users and the CP will deploy 322 the CDN or cache nodes according to the user distribution in the 323 operator network. In order to guarantee QoE, the CP will deploy CDN 324 nodes with full resource in the network center and CDN nodes with hot 325 resource at the network edge which usually locate in the operator's 326 premises network. Each premises network operator has its own IP 327 address field and the user's IP address is allocated by the premises 328 network operator. In the current IP network, the CP can find the 329 nearest resource only according to the IP address in the inquiry and 330 then schedule the corresponding CDN node to serve the user, if the 331 edge CDN node has no the resource asked by the user, the CP will haul 332 the user inquiry back to the center CDN nodes with full resource and 333 schedule the corresponding resource to serve the user, and this can 334 easily form the network congestion of ISP haul-back route and 335 increase the network delay. Though the different ISP premises 336 networks have routing reachability, the content resource can't be 337 sharing among different IPS. 339 Under the video scheduling mechanism based on the IP address, IP 340 address will fragment the network resource and the same content will 341 have many IP address or URL, thus CP or ISP have to use large storage 342 resource to deploy the same hot content. IP address and URL are all 343 the network address information independent of the content and the 344 operator can't share the content through the address information. 346 In ICN, we can use the multi-service tag naming scheme to realize the 347 content resource sharing among ISPs and form larger content resource 348 sharing pool, thus all user can acquire the content in the pool and 349 it breaks the IP-ISP resource closed mechanism. The multi-service tag 350 assembly modular can acquire all ISP network resource information and 351 the user can use this information to find the relevant content. 353 8.2 cache according to the content naming information 355 The cache technology is always one of the main technological means 356 for decreasing inter-network settlement charge and enhancing QoE. The 357 maximal challenge which the traditional cache technology faces is 358 that the repetitive contents waste the cache resource. The core 359 technology of the traditional cache is to obtain URL contents and 360 store them locally by monitoring the hot program's URLs through DPI. 361 But the URL is not stable and the same contents may have different 362 URLs. Though we can use DPI to decode the content and acquire partial 363 content characteristics to compare, it has major limitations at 364 decreasing the repetitive contents and greatly increases the 365 computation complexity, what is more, the begin of the content is 366 often advertisement or station caption and this makes content 367 comparison different to work well. The multi-service tag contains the 368 attribute information of carried content which is one-to-one 369 correspondence to the content, then the cache system can use the tag 370 as the base of comparison so as to quickly discover the repetitive 371 contents and raise cache efficiency. 373 9 Security Considerations 375 TBD. 377 10 IANA Considerations 379 There is no IANA action in this document. 381 11 Acknowledgements 383 TBD. 385 12 References 387 12.1 Normative References 389 [RFC]7927, D. Kutscher, S., "Information-Centric 390 Networking (ICN) Research Challenges", [RFC]7927, July 391 2016, 393 Authors' Addresses 395 Yong Xia 396 China SARFT 397 Email: xiayong@abs.ac.cn 399 Shihui Duan 400 China Academy of Telecommunication Research of MIIT 401 Email: duanshihui@catr.cn 403 Shu Liu 404 China Academy of Telecommunication Research of MIIT 405 Email: liushu@catr.cn 407 Rachel Huang 408 Huawei 409 Email: rachel.huang@huawei.com