idnits 2.17.1 draft-xia-icn-multiservtag-02.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 : ---------------------------------------------------------------------------- ** There are 54 instances of too long lines in the document, the longest one being 23 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 100 has weird spacing: '...pletely depen...' -- The document date (Mar 13, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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: Sept 13, 2017 China CAICT 6 Shu Liu 7 China CAICT 8 R.Huang 9 Huawei 10 Mar 13, 2017 12 the Consideration for the Application of Multi-Service Tag 13 draft-xia-icn-multiservtag-02 15 Abstract 17 This document discusses the consideration for the design of multi- 18 service tag in the current complex network so as to optimize traffic 19 model and improve the transmission efficiency. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2 Brief background . . . . . . . . . . . . . . . . . . . . . . . 3 61 3 The analysis of the limitation of current technologies . . . . 3 62 3.1 Identifying the content . . . . . . . . . . . . . . . . . . 4 63 3.2 Identifying the source . . . . . . . . . . . . . . . . . . . 4 64 4 Consideration for the typical design of multi-service tag in 65 CDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1 the design rules of multi-service tag . . . . . . . . . . . 5 67 4.2 the preliminary design of multi-service tag . . . . . . . . 5 68 4.3 the preliminary design of the multi-service tag system . . . 7 69 4.4 the workflow of multi-service tag in CDN . . . . . . . . . . 8 70 5 Analysis of application case . . . . . . . . . . . . . . . . . 8 71 5.1 service perception by network . . . . . . . . . . . . . . . 8 72 5.2 intelligent cache . . . . . . . . . . . . . . . . . . . . . 8 73 5.3 content exchange between little ISPs . . . . . . . . . . . 9 74 6 Simple Demo . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 76 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 77 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 78 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1 Introduction 84 The document discusses the feasibility of multi-service tag in the 85 current Internet , analyzes the limitation of the related 86 technologies, gives the requirements of the multi-service tag. We 87 give the typical design of multi-service tag in CDN and introduce a 88 demo. 90 2 Brief background 92 Now the network traffic presents a rapid increase trend, the 93 popularization of network video and the diversified viewing model 94 modes support watch video in anytime and anywhere,which also results 95 in the increase of network traffic. The network video Apps must 96 provide terrific Quality of experience(QoE). These trends represent a 97 developing direction of future networks. Recognition and handling of 98 the application traffic is a key factor for network operation. Each 99 network application uses different protocol and is deployed by 100 different ISP, which incompletely depends on the network operaters. 101 The method of the recognition of traffic and applications uses the 102 fuzzy heuristic modes which are based on the port scope and key 103 information of the traffic and are similar with the DPI technology, 104 but this series of technologies have some limitations. The heuristic 105 methods can't effectively solve the problem of traffic recognition 106 because they can't keep up with the synchronization update of 107 application characteristics. The traffic recognition schemes based on 108 the port scope detection face the great challenge because of enormous 109 amount of ports which are discontinuous, especially for http traffic, 110 the http traffic usually use 80 or 8080 port, so the content in http 111 traffic is difficult to be identified accurately. Due to the 112 encryption transmission of more and more traffic, these lead to the 113 great increase of DFI/DPI calculated amount and make these two 114 technologies be faced with invalidation. IP tunneling technology 115 makes the operator's network more complex. So we need a new 116 technology which can rapidly and uniquely recognize the traffic based 117 on its characteristics without resolve the whole package. 119 3 The analysis of the limitation of current technologies 121 The traffic recognition ways based on IP address pool face 122 difficulties. Because IP address is of large amount, dynamic, 123 proprietary or private. According to the CDN protocol (RFC 6770), the 124 content can be transferred to different CDN and this makes it 125 impossible to track the content among different CDN in terms of its 126 IP address. Though the traffic recognition based on IP address is 127 possible in some scenes, it's impossible to exactly identify every 128 flow. Because the same port is maybe repetitively used by different 129 application, the traffic recognition based on port may lead the wrong 130 results. DFI/DPI may lose efficacy or become very complicated with 131 the more and more encrypted traffic in order to analyze the content 132 contained by the traffic. A traffic flow of an application will end 133 at user terminal through different network routes and this will 134 affect the analysis of the traffic flow. There are no unified 135 standards for traffic recognition and analysis and it will lead to 136 different analysis results for the same traffic flow due to the 137 analysis ability and implementation ways. The traffic analysis will 138 parse the payload of the packages, thus it will affect the package 139 processing efficiency which need extra process, and the ever- 140 increasing new protocols also affect the DFI/DPI devices efficiency. 141 The flow tag is defined in RFC6437 and it only applies in IPv6 142 protocols. The flow tag changes along with the specific traffic flow 143 and just like port. The flow tag can't identify the traffic flow 144 independently and it must be used with source/destination IP 145 addresses together. Because the flow tag is fixed in IPv6 header, it 146 can identified easily, but it lacks of protect mechanism and there is 147 no mechanism verifying its integrity. 149 In general, the current traffic recognition ways is limited in the 150 analysis of traffic flows, they can't provide effective feedback 151 data, so they can't support the self-adaptive network processing 152 capability established by the operators. 154 3.1 Identifying the content 156 In order to improve the hit ratio and actively push the hot resources 157 to the local subscribers, the cache system need a succinct way to 158 learn the buffered contents and can judge the hot content according 159 to the actual content information. 161 3.2 Identifying the source 163 To enable flexible reverse charging, we need a third party 164 recognizable tag of the traffic for the charging GW located between 165 the client and server, which helps in recognition of its source and 166 billing model, and other features to enable other cultivated 167 transport services, e.g. QoS for selected content types for a given 168 ICP. 170 4 Consideration for the typical design of multi-service tag in CDN 172 Now the accelerating system is widely used in the Internet, such CDN, 173 the ISP's intelligent cache and P2SP etc. These accelerating systems 174 usually use simple URLs to speed up the access rate without regard to 175 the specific content,bandwidth requirements, global attention etc. So 176 there's blindness to accelerate everything using one way and there's 177 no optimal acceleration aiming at the service requirements. 179 For convenience, we use the CDN conditions to describe the 180 application of the multi-service tag here. 182 4.1 the design rules of multi-service tag 184 we need to design to a new rule to express the service properties and 185 transmission requirements of the content. Every CDN operators can use 186 the same algorithm to apply different accelerating strategies for the 187 different contents so as to provide more professional and accurate 188 accelerating service for every CP. 190 We design a multi-service tag which can help the network better know 191 the traffics which it carries. The multi-service tag design abandons 192 the traditional fuzzy heuristic design idea and directly include the 193 information about the transferred contents and the requirements for 194 the transmission network. 196 This kind of tag is embedded into the content URL according to some 197 rules, it can transparently transferred in different networks and has 198 no impact on existing services, and we call it multi-service tag. It 199 has the following features: 201 a) no relationship with IP address or port number; 203 b) one-to-one correspondence to the transferred content; 205 c) stable in a traffic flow lifecycle; 207 d) easily obtained and handled by the network operator; 209 e) the tag can be recognized by the network, the network can draw 210 up a strategy and adaptively transfer the content according to the 211 tag information; 213 f) confidence mechanism against tamper-proofing; 215 g) decrease the complexity of network management. 217 4.2 the preliminary design of multi-service tag 219 Here we give a simple and preliminary design of multi-service tag, 220 the scheme is not mature and may be changed along with the 221 development of the new technologies. 223 The format of multi-service tag is as following: 225 xlables = base64( CID + content summary + type + file size + [code 226 rate] + priority + timestamp + random number + signature ) 228 xlables: fixed string which identifies tags and encrypts the 229 following information using base64. 231 CID: the identity of CP which is distributed by the tag service 232 system in a unified way. 234 content summary: the summary is extracted according to the file 235 content and corresponding to the file and actually is file hash. This 236 field can be used to identify the same cached content. 238 type: the kinds of the transferred file, such as video, picture, 239 document. 241 file size: the size of the transferred file. 243 code rate: it's specific for the video file. 245 priority: the transferred priority level, such as normal, vip. 247 timestamp: the time which the file is issued. 249 random number: it provides the signature identity 251 signature: it's produced according to the CID+content 252 summary+type+file size+[code rate]+timestamp+random number and used 253 to verify the validity of the tag. 255 The tag can be embedded into the URL and the CDN can extract the tag 256 from the URL. Through the tag service, the CDN can get the 257 corresponding service information. 259 Here is the example: 261 the original URL: 262 http://wx.cvideo.com.cn/labels/video/xvideo4k.mp4 264 the embedded tag URL: 265 http://wx.cvideo.com.cn/labels/video/xvideo4k.mp4?xlabels=Y2lkPTVCRUZ 266 CRTIxNEY3OEJBMjhERjRGRjdFNkY0RkMwRjU5Jmhhc2g9RTFFOEI3MzVFMzM3QkEyQkRCQUM1 267 MjQyRUUxMDc5RkImdHlwZT12aWRlbyZzaXplPTYuMzVHJmR1cmF0aW9uPTE4NjBzJnRpbWVzd 268 GFtcD0xNDg2NjM2MDA3JnJhbmQ9ODkyMjMyMSZzaWduYXR1cmU9UTgwWjZMRFYyQkpWUVBHNl 269 JIMFpXSU5TOU0tUEtKNUo= 271 In fact, the length of URL is limited in CDN, so we put key 272 information into the tag. We also design the tag related information 273 corresponding to each tag which mainly includes tag service 274 information and tag transmission information. The tag service 275 information includes content description,drama series, VIP 276 accelerating and copyright etc. The tag transmission information 277 include image resolution, play software requirements, cache nodes 278 distribution and access interests etc. The CDN extracts the tag, get 279 the corresponding tag related information and then provides 280 corresponding service. 282 4.3 the preliminary design of the multi-service tag system 284 We design a multilevel tree structure multi-service tag system which 285 includes tag service center and tag servers. 287 The tag service center is the core of the system which provides 288 storage, renewal and inquiry service for the whole network tags and 289 the related tag information. 291 The tag server is deployed at the networks of CP or accelerating 292 operators which can provide distributed tag information extraction, 293 resolution and inquiry services. 295 |--------------------------------| 296 | tag service center | 297 |--------------------------------| 298 | | 299 | | 300 |-------| | 301 | | 302 |----| |-------------| |-------------| 303 | CP |----->| tag server |-----| | tag server |--| 304 |----| |-------------| | |-------------| | 305 | | | 306 | |-------------| | 307 | | tag server | |--------------| 308 | |-------------| | P2SP network |---| 309 | | |--------------| | 310 |-----------------| | | | 311 | CDN edge node | | | | 312 |-----------------| | | |---------------------| 313 | |-----------| | P2SP Speedup server | 314 |------------------| | End User | |---------------------| 315 | operator's cache | |-----------| 316 |------------------| 318 Figure 1 the multi-service tag system 320 The related tag information and tag URL are usually stored at the tag server 321 and tag service center, the normal End Users only know the normal URL, so this system 322 has no influence on network devices and End Users. It needs the CDN/cache to do some 323 changes. 325 4.4 the workflow of multi-service tag in CDN 327 The multi-service tag system provide public tag services including tag issuing and tag 328 recognition. The tag service can be distributed deployed so as to provide serving for 329 the whole network accelerating services similar to DNS service. 331 The tag issuing workflow: 333 1)The CP generates the tag through the tag service and embeds it to the corresponding URL; 335 2)The CP publishes the URL to its websites and the tag system; 337 3)The tag system records the tag information and updates the tag service center; 339 4)The tag system provides tag information inquiry service to the CDN operators through 340 the distributed tag inquiry system. 342 The tag recognition workflow: 344 1)The CDN identifies the tag field in the URL; 346 2)The CDN gets the basic information of the content transmission from the tag; 348 3)The CDN gets the tag related information through the tag service interface; 350 4)The CDN stores the tag's basic information and related information. 352 5 Analysis of application case 354 5.1 service perception by network 356 The Internet video traffic becomes the major service traffic and the video traffic has 357 high demands for the transmission network and is sensitive to the network. The 4k programs 358 transmission needs more than 30Mbps bandwidth, it can't guarantee the QoS even though CDN 359 is used for the transmission. The core problem is that the network isn't able to know the 360 carried service and thus allocate resources dynamically. We can use multi-service tag to 361 resolve the problem. Because the tag can contain the information of the carried service, 362 the network operator can use tag to quickly identify and handle 4k program flow and 363 demands to network to allocate resource dynamically for the 4k flow. 365 5.2 intelligent cache 366 The cache technology is always one of the main technological means for decreasing 367 inter-network settlement charge and enhancing QoE. The maximal challenge which the 368 traditional cache technology faces is that the repetitive contents waste the cache resource. 369 The core technology of the traditional cache is to obtain URL contents and store them 370 locally by monitoring the hot program's URLs through DPI. But the URL is not stable and 371 the same contents may have different URLs. Though we can use DPI to decode the content 372 and acquire partial content characteristics to compare, it has major limitations at 373 decreasing the repetitive contents and greatly increases the computation complexity, 374 what is more, the begin of the content is often advertisement or station caption and 375 this makes content comparison different to work well. The multi-service tag contains 376 the attribute information of carried content which is one-to-one correspondence to the 377 content, then the cache system can use the tag as the base of comparison so as to quickly 378 discover the repetitive contents and raise cache efficiency. 380 5.3 content exchange between little ISPs 382 In order to reduce operating costs, little ISPs are apt to interconnect each other to 383 realize the user scale increase and resource sharing. Each little ISP has establish its 384 own cache system or CDN node in order to decrease the inter-network settlement expense 385 with the large ISP. The different little ISP must indicate the location of content storage 386 and content itself, then issue the content URL. The multi-service tag not only include 387 the information of the content and also bound together with the URL to transfer, thus 388 resolve the problem of program content sharing after ISP interconnection. 390 6 Simple Demo 392 We establish a simple demo to validate the availability of multi-service tag, irrespective 393 of security, network complexity and other factors. 395 In our demo, we make some simplification for the real network components and the network 396 structure is shown in Figure 2. 398 Test Terminal --------- content server 400 Figure 2 Demo network structure 402 The content server simulates the CDN edge node, its function includes:extract the tag 403 from URL, get the tag related information, serve the user according to the related 404 information. 406 We store two almost same h.264 video of 4K 60P at the content server, one has normal URL 407 and other has tag URL with VIP priority. We watch these two video files and statistics 408 the output bandwidth. In order to watch the video normally, it needs about 30M bandwidth. 409 For the normal URL, we see about 6M output bandwidth. For the tag URL, we see about 30M 410 output bandwidth. Through this demo, the tag URL can work well. 412 7 Security Considerations 414 TBD. 416 8 IANA Considerations 418 There is no IANA action in this document. 420 9 Acknowledgements 422 TBD. 424 8 References 426 8.1 Normative References 427 Authors' Addresses 429 Yong Xia 430 China SARFT 431 Email: xiayong@abs.ac.cn 433 Shihui Duan 434 China Academy of Telecommunication Research of MIIT 435 Email: duanshihui@catr.cn 437 Shu Liu 438 China Academy of Telecommunication Research of MIIT 439 Email: liushu@catr.cn 441 Rachel Huang 442 Huawei 443 Email: rachel.huang@huawei.com