idnits 2.17.1 draft-xia-icn-multiservtag-03.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 96 has weird spacing: '...pletely depen...' -- The document date (Jul 3, 2017) is 2460 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: Jan 3, 2018 China CAICT 6 Shu Liu 7 China CAICT 8 R.Huang 9 Huawei 10 Jul 3, 2017 12 the Consideration for the Application of Multi-Service Tag 13 draft-xia-icn-multiservtag-03 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 Analysis of the limitation of current network . . . . . . . . . 3 69 3 Name mechanism for the video contents in ICN . . . . . . . . . 4 70 4 Design of multi-service tag . . . . . . . . . . . . . . . . . . 4 71 4.1 the design rules of multi-service tag . . . . . . . . . . . 5 72 4.2 the preliminary design of multi-service tag . . . . . . . . 5 73 5 System of multi-service tag . . . . . . . . . . . . . . . . . . 6 74 6 Design of routing and route resolution for the multi-service 75 tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7 Some application cases . . . . . . . . . . . . . . . . . . . . 7 77 7.1 content resource sharing across ISP network . . . . . . . . 7 78 7.2 cache according to the content naming information . . . . . 8 79 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 80 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 81 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 82 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 11.1 Normative References . . . . . . . . . . . . . . . . . . . 8 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 86 1 Introduction 88 Now the network traffic presents a rapid increase trend, the 89 popularization of network video and the diversified viewing model 90 modes support watch video in anytime and anywhere,which also results 91 in the increase of network traffic. The network video Apps must 92 provide terrific Quality of experience(QoE). These trends represent a 93 developing direction of future networks. Recognition and handling of 94 the application traffic is a key factor for network operation. Each 95 network application uses different protocol and is deployed by 96 different ISP, which incompletely depends on the network operaters. 97 The method of the recognition of traffic and applications uses the 98 fuzzy heuristic modes which are based on the port scope and key 99 information of the traffic and are similar with the DPI technology, 100 but this series of technologies have some limitations. The heuristic 101 methods can't effectively solve the problem of traffic recognition 102 because they can't keep up with the synchronization update of 103 application characteristics. The traffic recognition schemes based on 104 the port scope detection face the great challenge because of enormous 105 amount of ports which are discontinuous, especially for http traffic, 106 the http traffic usually use 80 or 8080 port, so the content in http 107 traffic is difficult to be identified accurately. Due to the 108 encryption transmission of more and more traffic, these lead to the 109 great increase of DFI/DPI calculated amount and make these two 110 technologies be faced with invalidation. IP tunneling technology 111 makes the operator's network more complex. So we need a new 112 technology which can rapidly and uniquely recognize the traffic based 113 on its characteristics without resolve the whole package. 115 The purpose of this document is to devise a mechanism allowing ICN 116 forwarders, consumers, producers and other ICN nodes to name content 117 identify content find content and share content. 119 2 Analysis of the limitation of current network 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 Name mechanism for the video contents in ICN 156 The ICN includes many Named Data Object (NDO) and it turns the 157 current "end host" network framework into "named information" 158 framework. In ICN, NDO is the core concept and independent of IP 159 address,which is the base of ICN network communication. The video 160 traffic is the highest percentage traffic in the Internet traffics. 161 As the network video gradually changes from standard definition video 162 to high definition and ultra HD video. Some new video applications 163 are rapidly popularized, such as short video application, video 164 social contact application and some related video applications, and 165 the video traffic is constantly growing. So it's necessary that the 166 video content must be regarded as a special NDO class to have 167 specialized design and consideration. The network video transmission 168 mostly uses slice transmission mechanism such as HLS and DASM 169 protocol. Based on the NDO granularity and transmission efficiency, 170 we suggest that the NDO design will use a whole video file or video 171 stream as a data unit and not take a slice as a NDO. 173 4 Design of multi-service tag 174 4.1 the design rules of multi-service tag 176 The design scheme of multi-service tag is a scheme just like URI 177 hierarchy naming scheme and its design follows the following 178 principles: 180 a) no relationship with IP address or port number; 182 b) one-to-one correspondence to the transferred content; 184 c) stable in a traffic flow lifecycle; 186 d) easily obtained and handled by the network operator; 188 e) the tag can be recognized by the network, the network can draw 189 up a strategy and adaptively transfer the content according to the 190 tag information; 192 f) confidence mechanism against tamper-proofing; 194 g) decrease the complexity of network management. 196 4.2 the preliminary design of multi-service tag 198 Here we give a simple and preliminary design of multi-service tag, 199 the scheme is not mature and may be changed along with the 200 development of the new technologies. 202 The format of multi-service tag is as following: 204 xlables = base64( CID + content summary + type + random number + 205 signature ) 207 xlables: fixed string which identifies tags and encrypts the 208 following information using base64. 210 CID: the identity of CP which is distributed by the tag service 211 system in a unified way. 213 content summary: the summary is extracted according to the file 214 content and corresponding to the file and actually is file hash. This 215 field can be used to identify the same cached content. 217 type: the kinds of the transferred file, such as video, picture, 218 document. 220 random number: it provides the signature identity 222 signature: it's produced according to the CID+content 223 summary+type+file size+[code rate]+timestamp+random number and used 224 to verify the validity of the tag. 226 5 System of multi-service tag 228 The system of multi-service tag is mainly made up by two function 229 modulars: 231 1)generating modular: this modular is deployed at the network edge 232 and interfaces with the operators. Its function is to generate multi- 233 service tags aimed at the specific content and establish binding 234 relationship between the video content and multi-service tag. This 235 modular will establish matchup relation between the multi-service tag 236 and video content actual store address in the operator network, and 237 send this matchup information to the assembly modular. 239 2)assembly modular: this modular is deployed at the network center 240 and responsible for collecting the matchup information between the 241 multi-service tag and video content storage location which is sent by 242 the generating modular. This modular will establish the whole network 243 NDO routing table by collecting the multi-service tag and content 244 storage address information all over the whole network and realize 245 the content inquiry service and routing resolution service according 246 naming information. 248 6 Design of routing and route resolution for the multi-service tag 250 The design of routing and route resolution for the multi-service tag 251 will adopt RFC7927 Look-By-Name Routing LBNR scheme which can fully 252 use the current network infrastructure. 254 1) The multi-service tag system will interface with the operator's 255 CDN or cache system firstly, then the generating modular will scan 256 the operator's content resource, establish the binding relationship 257 between content resource and multi-service tag, generate the mapping 258 relation for the network address and multi-service tag, send this 259 information to the assembly modular and form the mapping relation 260 table for the network address and multi-service tag in the assembly 261 modular. 263 2) When the operator receives the user inquiry, it will extract the 264 inquired naming information-multi-service tag through filter 265 mechanism and send it to the assembly modular. 267 3) The assembly modular find the final address information related 268 with the naming information through the mapping relation table of the 269 network address and multi-service tag, and send this information to 270 the user. 272 4) The user acquires the content through the network address. 274 7 Some application cases 276 7.1 content resource sharing across ISP network 278 The Internet video transmission usually uses the CDN technology and 279 cache technology to provide service for users and the CP will deploy 280 the CDN or cache nodes according to the user distribution in the 281 operator network. In order to guarantee QoE, the CP will deploy CDN 282 nodes with full resource in the network center and CDN nodes with hot 283 resource at the network edge which usually locate in the operator's 284 premises network. Each premises network operator has its own IP 285 address field and the user's IP address is allocated by the premises 286 network operator. In the current IP network, the CP can find the 287 nearest resource only according to the IP address in the inquiry and 288 then schedule the corresponding CDN node to serve the user, if the 289 edge CDN node has no the resource asked by the user, the CP will haul 290 the user inquiry back to the center CDN nodes with full resource and 291 schedule the corresponding resource to serve the user, and this can 292 easily form the network congestion of ISP haul-back route and 293 increase the network delay. Though the different ISP premises 294 networks have routing reachability, the content resource can't be 295 sharing among different IPS. 297 Under the video scheduling mechanism based on the IP address, IP 298 address will fragment the network resource and the same content will 299 have many IP address or URL, thus CP or ISP have to use large storage 300 resource to deploy the same hot content. IP address and URL are all 301 the network address information independent of the content and the 302 operator can't share the content through the address information. 304 In ICN, we can use the multi-service tag naming scheme to realize the 305 content resource sharing among ISPs and form larger content resource 306 sharing pool, thus all user can acquire the content in the pool and 307 it breaks the IP-ISP resource closed mechanism. The multi-service tag 308 assembly modular can acquire all ISP network resource information and 309 the user can use this information to find the relevant content. 311 7.2 cache according to the content naming information 313 The cache technology is always one of the main technological means 314 for decreasing inter-network settlement charge and enhancing QoE. The 315 maximal challenge which the traditional cache technology faces is 316 that the repetitive contents waste the cache resource. The core 317 technology of the traditional cache is to obtain URL contents and 318 store them locally by monitoring the hot program's URLs through DPI. 319 But the URL is not stable and the same contents may have different 320 URLs. Though we can use DPI to decode the content and acquire partial 321 content characteristics to compare, it has major limitations at 322 decreasing the repetitive contents and greatly increases the 323 computation complexity, what is more, the begin of the content is 324 often advertisement or station caption and this makes content 325 comparison different to work well. The multi-service tag contains the 326 attribute information of carried content which is one-to-one 327 correspondence to the content, then the cache system can use the tag 328 as the base of comparison so as to quickly discover the repetitive 329 contents and raise cache efficiency. 331 8 Security Considerations 333 TBD. 335 9 IANA Considerations 337 There is no IANA action in this document. 339 10 Acknowledgements 341 TBD. 343 11 References 345 11.1 Normative References 347 [RFC]7927, D. Kutscher, S., "Information-Centric 348 Networking (ICN) Research Challenges", [RFC]7927, July 349 2016, 351 Authors' Addresses 353 Yong Xia 354 China SARFT 355 Email: xiayong@abs.ac.cn 357 Shihui Duan 358 China Academy of Telecommunication Research of MIIT 359 Email: duanshihui@catr.cn 361 Shu Liu 362 China Academy of Telecommunication Research of MIIT 363 Email: liushu@catr.cn 365 Rachel Huang 366 Huawei 367 Email: rachel.huang@huawei.com