idnits 2.17.1 draft-zhang-icnrg-hn-05.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 211 instances of too long lines in the document, the longest one being 6 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 21 has weird spacing: '...pted in diffe...' == Line 122 has weird spacing: '...on, and to im...' == Line 200 has weird spacing: '...nstream namin...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 7, 2016) is 2755 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 590 looks like a reference -- Missing reference section? '2' on line 595 looks like a reference -- Missing reference section? '3' on line 598 looks like a reference -- Missing reference section? '4' on line 602 looks like a reference -- Missing reference section? '5' on line 607 looks like a reference -- Missing reference section? '6' on line 611 looks like a reference -- Missing reference section? '7' on line 615 looks like a reference -- Missing reference section? 'RFC2119' on line 183 looks like a reference -- Missing reference section? '8' on line 620 looks like a reference -- Missing reference section? '9' on line 622 looks like a reference -- Missing reference section? '10' on line 625 looks like a reference -- Missing reference section? 'RFC2234' on line 570 looks like a reference -- Missing reference section? '11' on line 629 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG Hongke Zhang 3 Internet Draft Fei Song 4 Intended status: Informational Wei Quan 5 Expires: April 7, 2017 BJTU 6 Jianfeng Guan 7 Changqiao Xu 8 BUPT 9 October 7, 2016 11 Uniform information with a hybrid naming (hn) scheme 12 draft-zhang-icnrg-hn-05.txt 14 Abstract 16 This document defines a hybrid naming scheme for unifying all kinds 17 of information including resources, services and data. With many 18 proposals of novel network architectures emerging, such as DONA, ICN, 19 NDN, the location-based routing starts to transfer to the content-based 20 ones. Currently, it is incompatible that many different information 21 naming schemes are adopted in different network proposals, 22 respectively, i.e. flat names in DONA, hierarchical names in NDN. The 23 proposed naming scheme adopts a hybrid naming structure, which includes 24 hierarchical component, flat component and attribute component. The 25 hybrid naming (hn) scheme enables to identify different routing 26 information uniformly, and provides many great advantages, such as 27 high aggregation, limited length, suffix holes remission, fuzzy 28 matching support, high security and good compatibility with IPv4/IPv6, 29 DONA, CCN/NDN and so on. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 This document may contain material from IETF Documents or IETF 37 Contributions published or made publicly available before November 10, 38 2008. The person(s) controlling the copyright in some of this 39 material may not have granted the IETF Trust the right to allow 40 modifications of such material outside the IETF Standards Process. 41 Without obtaining an adequate license from the person(s) controlling 42 the copyright in such materials, this document may not be modified 43 outside the IETF Standards Process, and derivative works of it may 44 not be created outside the IETF Standards Process, except to format 45 it for publication as an RFC or to translate it into languages other 46 than English. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF), its areas, and its working groups. Note that 50 other groups may also distribute working documents as Internet-Drafts. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 The list of current Internet-Drafts can be accessed at 58 http://www.ietf.org/ietf/1id-abstracts.txt 60 The list of Internet-Draft Shadow Directories can be accessed at 61 http://www.ietf.org/shadow.html 63 This Internet-Draft will expire on April 7, 2017. 65 Copyright Notice 67 Copyright (c) 2014 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (http://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents carefully, 74 as they describe your rights and restrictions with respect to this 75 document. 77 Table of Contents 79 1. Introduction.................................................4 80 1.1. Hierarchical naming.....................................4 81 1.2. Flat naming.............................................4 82 1.3. Attribute naming........................................5 83 2. Conventions used in this document............................5 84 3. Novel hybrid naming (hn) format..............................5 85 3.1. Hierarchical component generating.......................7 86 3.2. Flat component generating...............................7 87 3.3. Attribute component generating..........................7 88 4. Advantages...................................................8 89 4.1. High aggregation........................................8 90 4.2. Limited length..........................................9 91 4.3. Suffix holes remission..................................9 92 4.4. Fuzzy matching support.................................11 93 4.5. Good compatibility.....................................11 94 4.6. High security..........................................11 95 5. Transition from IPv4 and IPv6...............................12 96 5.1. Case one...............................................12 97 5.2. Case two...............................................12 98 6. Compatibility...............................................12 99 6.1. Compatibility with DONA................................13 100 6.2. Compatibility with CCN/NDN.............................14 101 7. Formal Syntax...............................................14 102 8. Security Considerations.....................................14 103 9. Conclusions.................................................15 104 10. References.................................................15 105 11. Acknowledgments............................................16 107 1. Introduction 109 1.1. Hierarchical naming 111 Some emerging network architectures (i.e. Content-Centric Network 112 (CCN)[1]/Named Data Networking (NDN)[2]) have proposed a readable 113 naming mechanism based on the hierarchical structure. This 114 hierarchical name is very similar as identifying a web with a URL, 115 for example "/www.bupt.edu.cn/content/a.avi". In this example, "/" is 116 the separator between adjacent components of the name. 118 We acknowledge that there are some advantages in this naming scheme. 119 First, it has a good compatibility with current applications or 120 systems based on URL, which can reduce the difficulty of deploying 121 the novel network. Second, it has a good aggregation to reduce the 122 number of routing information, and to improve lookup efficiency of 123 routing information. Besides, its lookup mechanism has a good 124 compatibility with the existing classless inter-domain routing 125 (CIDR)[3]. 127 However, the hierarchical name also has some fatal disadvantages. It 128 consists of a series of unlimited components. The number of 129 components is variable, and the length of each component is not 130 restricted. All these features cause the length of names variable 131 and relatively long [4]. In this way, the routing table and 132 forwarding table may be very huge, which results in low lookup 133 efficiency. 135 In addition, when users search for a resource, they might not 136 remember the long name of the resource. For example, users need the 137 resource a.avi, but they might not know the official name 138 "/www.bupt.edu.cn/content/a.avi" or "/www.bupt.edu.cn/movie/a.avi". 139 Hierarchical naming structure is difficult to support a fuzzy 140 matching based on the attributes of names. 142 1.2. Flat naming 144 The flat naming mechanism has been used in other novel network 145 architectures, such as DONA [5] and NetInf [6]. This flat name can be 146 produced by cryptographic hashing of the content or its 147 attributes. 149 As the flat name has not any structure restriction, it can be 150 obtained and used more flexibly. Any string with a fix length, no 151 matter whether it is readable or not, can be used as a flat 152 name. 154 However, the flat name has a low degree of aggregation, which will 155 increase the number of routing entries and reduce the 156 expandability of routing table. Besides, most of flat names are not 157 readable, which increases the probability for users to forget the 158 official names of the desired information. When users want to obtain 159 contents, an additional mapping system needs mapping readable names 160 and unreadable names for users. 162 1.3. Attribute naming 164 The naming mechanism based on attributes of content is used in the 165 CBCB [7]. It enumerates the attribute information of a resource, such 166 as the category, format, date, feature, level and so on. This name is 167 non-uniqueness which is different from the former two mechanisms. The 168 related content can be searched and located by means of the key 169 properties of resource. 171 The advantage of this naming is that it supports searching key words 172 and provides benefits for the fuzzy matching of searching resources. 173 However, there may be many similar properties for a set of certain 174 resources. The uniqueness is hardly guaranteed by a limited number of 175 attributes. Thus, to guarantee the uniqueness, the attributes stored 176 in routing system will be very huge. 178 2. Conventions used in this document 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC-2119 [RFC2119]. 184 In this document, these words will appear with that interpretation 185 only when in ALL CAPS. Lower case uses of these words are not to be 186 interpreted as carrying RFC-2119 significance. 188 In this document, the characters ">>" preceding an indented line(s) 189 indicates a compliance requirement statement using the key words 190 listed above. This convention aids reviewers in quickly identifying 191 or finding the explicit compliance requirements of this RFC. 193 3. Novel hybrid naming (hn) format 195 According to the analysis of above three naming mechanisms 196 in terms of advantages and disadvantages, a hybrid naming is 197 suggested to highlight the advantages of them and weaken their 198 disadvantages. 200 Most importantly, three different mainstream naming schemes are 201 adopted in different novel network architectures, which makes the 202 networks be hardly compatible and implemented complexly. 204 One easy and all-benefit solution is the integrated method for them, 205 taking each of them as a part of the hybrid naming solution. In other 206 words, each of them takes some weight of the novel naming scheme. 208 We proposed a hybrid naming mechanism (named by "hn"), which 209 organizes the three naming mechanisms in a sequence, and builds 210 a more powerful and universal naming format. 212 The hybrid naming format should include three components: 214 o Hierarchical component 216 o Flat component 218 o Attribute component 220 Each part carries different information of name in different formats, 221 which produce an entire name. The hybrid name is started by a symbol 222 "hn://". The order of three parts should be as follows: 224 1. The first part of a name is very important for the aggregation of 225 routing entries. A hierarchical structure is adopted in the first 226 part. The symbol "/" is used to split the hierarchical levels in 227 this part. 229 2. The second part of a name is very important to identify the 230 content uniquely. A flat structure is used in the second part. A 231 string with a fix length can be used by a hash computing. 233 3. The third part of a name is used to represent the extensive 234 information of resources. The attribute-based structure is 235 selected in the third part, which is composed of a set of 236 attribute words. 238 An example of the hybrid name for a movie is shown in Figure 1. 240 +----------------------+---------------+---------------------------+ 241 |hn://www.bjtu.edu.cn/m|u584rnfiur324yh|movie:avi:1024:part1:kongfu| 242 +----------------------+---------------+---------------------------+ 244 Figure 1 An example of hn for a movie 246 An example of the hybrid name for a picture is shown in Figure 2. 248 +--------------------------+---------------+-----------------------+ 249 |hn://www.bjtu.edu.cn/m/pic|fh84rnfiur324ru| jpg:300*500:prairie | 250 +--------------------------+---------------+-----------------------+ 252 Figure 2 An example of hn for a picture 254 3.1. Hierarchical component generating 256 Hierarchical component is the first part of the hn naming format. 257 This part is suggested to be generated by a followed reference 258 standard. 259 This standard should define the string set in top 260 level, string set in second level and so on. This reference standard 261 is very useful to promote its aggregation greatly. One available but 262 not complete reference standard for naming hierarchical component is 263 the naming scheme of DNS. 265 3.2. Flat component generating 267 Flat component is the second part of hn naming scheme. This part is 268 suggested to identify the information using a string with a limited 269 length. This part must identify the information uniquely by combing 270 with the first part. 272 Flat component can be generated by cryptographic hash algorithm by 273 the information itself or some characters of the information. This 274 part has a low probability of aggregation, but it highlights and 275 ensures the uniqueness of name. 277 3.3. Attribute component generating 279 Attribute component is placed as the third part of hn naming scheme. 280 This part will take charge of the fuzzy matching and some advanced 281 search, i.e., QoS guarantee. This part will also contribute to 282 conduct some potential advanced application based on the useful 283 attributes. It can be generated by extracting the features of the 284 information, such as the format, issue time, file size, catalog, 285 location, popularity, privacy level and so on. 287 4. Advantages 289 4.1. High aggregation 291 The aggregation of names is very important for the name lookup and 292 storage. According to Google's report, the number of URLs it indexed 293 was 26 million in 1998, which reached to one billion in 2000, and is 294 currently 1 trillion [8]. In July 2011, these URLs could be 295 aggregated to about 280 million domain names, among which 86 million 296 are active. 298 It is a fact that there is a great aggregation for the first few 299 levels of the hierarchical tree. Therefore, the hierarchical 300 structure is used in the first part of the hn. By this way, the 301 routing entries can be reduced obviously and the aggregation of route 302 can be improved. For example, there are two routing entries 303 "/www.bjtu.edu.cn/m/movie/fhk562nfgjru056:kongfu:avi:1024p:part1 3" 304 and "/www.bjtu.edu.cn/m/picture/fh84rnf213gjrru:jpg:300*500:prairie 305 3" which have the same forwarding port "3" and prefix 306 "/www.bjtu.edu.cn/m". Therefore, the forwarding port and 307 "/www.bjtu.edu.cn/m" can only be stored in routing table. It not only 308 reduces the entries of routing table, but also reduces the length of 309 each routing entries. An example of aggregation process is shown in 310 Figure 3. 312 +----------------------------+---------------+------------------+---+ 313 |hn://www.bjtu.edu.cn/m/movie|fhk562nfgjru056|kongfu 1024p part1| 3 | 314 +----------------------------+---------------+------------------+---+ 316 +------------------------------+-----------------+---------------+--+ 317 |hn://www.bjtu.edu.cn/m/picture| fh84rnf213gjrru |300*500 prairie| 3| 318 +------------------------------+-----------------+---------------+--+ 320 +----------------------+---+ 321 |hn://www.bjtu.edu.cn/m| 3 | 322 +----------------------+---+ 324 Figure 3 An example of aggregation 326 4.2. Limited length 328 The length of name based on hierarchical structure is variable and 329 relatively long because it must be formed by several parts and the 330 number of component is variable. Kelvin [9] has selected 6627999 URL 331 in 78764 different domain names, and the statistics shows that the 332 average length of URL is 76.97 bytes. In the architecture of ICN, the 333 name must be extracted to query in forwarding table or routing table 334 and a long name entry will lead to the query speed becoming low, 335 hance, affecting the performance of routing. 337 The hn naming scheme uses a part of flat component in the name to ease 338 this problem. A fix length flat part is embedded behind the 339 hierarchical part. This design not only can restrict the length of 340 names not too long, but also will affect the aggregation not much. 341 For example, if the average length of hierarchical part is controlled 342 within 30 bytes, adopting a flat part with a fix length of 20 bytes, 343 the whole average length will be restricted within 50 bytes. 344 Comparing to 76.97 bytes, the length is shortened by nearly 35%, 345 which will improve the query speed of name greatly using the length- 346 dependent algorithms. 348 4.3. Suffix holes remission 350 The suffix hole is a well-known problem for the route of prefix 351 matching. For example, a routing entry "/www.bjtu.edu.cn/movie/3" is 352 stored in the route table for prefix matching. In fact, it is 353 aggregated by "/www.bjtu.edu.cn/movie/a.avi/part1 3"and 354 "/www.bjtu.edu.cn/movie/b.avi/part1 3". In this way, the forwarding 355 packets will be forward from port 3, only if the prefix of name is 356 "/www.bjtu.edu.cn/movie/". However, if packets with a name of 357 "/www.bjtu.edu.cn/movie/c.avi" arrive in the router, it will be 358 forwarded from port 3. Actually, the network that port 3 connects 359 only has a.avi and b.avi. This causes the so-called suffix holes [10]. 361 In the proposed hn scheme, the flat part can solve the problem of 362 suffix holes efficiently. For example, there are two resource names 363 "/www.bjtu.edu.cn/movie/s83hho90oxn2783nde4r:kongfu:avi:1024p:part1 364 3" and 365 "/www.bjtu.edu.cn/movie/8uh723k9ng556sgaesgs:love:rmvb:720p:part2:201 366 2-3-4 3". After route aggregation, the routing entry will become 367 "/www.bjtu.edu.cn/movie/ 3". The routing entry will be matched when 368 an packet whose name is "/www.bjtu.edu.cn/movie/a932jfdjf2032942- 369 jdd:control:avi:1024p:part1:part2" arrives at this router. 371 However, it can not be forwarded from the port 3 based on hn scheme 372 due to the incomplete prefix matching. There is a suffix list in each 373 aggregating prefix, and the packet will be forwarded only when the 374 requesting suffix exists in the suffix list. In hn scheme, it must 375 assort a suffix list for each routing entries like 376 "/www.bjtu.edu.cn/movie/ 3" to store the flat parts of names. 377 Although the name of the new packet has been matched to the routing 378 entries, its flat part "a932jfdjf2032942-jdd" does not exist in the 379 suffix list "/www.bjtu.edu.cn/movie/ 3". The plat part will be used 380 to confirm whether it forwards the request packet when the prefix is 381 matched. By this way, the problem of suffix holes can be resolved 382 effectively. The lookup process of hn names is shown in Figure 4. 384 +----------------------------+-----------------+------------------+ 385 |hn://www.bjtu.edu.cn/main/m/| eld624knhgvfded |kongfu 1024p part1| 386 +----------------------------+-----------------+------------------+ 387 | 388 | Prefix match 389 v 390 +-----------------------+---+ +----------------------+ 391 |/www.bjtu.edu.cn/main/m| 3 |------------ | s83hho90oxn2783nde4r;| 392 | | | | 8uh732k9ng556sgaesgs;| 393 +-----------------------+---+ +----------------------+ 394 | 395 | 396 v 397 +-------+ 398 | seek | 399 +-------+ 400 | | 401 succeed| |failed 402 v v 403 +-------+ +-------+ 404 |forward| |discard| 405 +-------+ +-------+ 407 Figure 4 The hn lookup process 409 4.4. Fuzzy matching support 411 In the practical, one important situation is that the users may not 412 know the full official resource name when they search a resource. The 413 hn naming scheme supports the fuzzy matching thanks to the function of 414 the attribute component. For example, the users need the resource 415 a.avi, they need not know the official name 416 "hn://www.bjtu.edu.cn/m/|u584uuj89324ru|kongfu:movie:avi:1024p:part1". 417 In this case, users only publish the information of video "kongfu" 418 and the resolution ratio "1024p", the related resources can be 419 found intelligently by fuzzy matching based on the attribute 420 component matching. This is the benefit about embedding attribute of 421 resource in the end of name. 423 4.5. Good compatibility 425 This naming scheme provides a good compatibility for all three 426 mainstream naming schemes, which are the subset of the hn naming 427 scheme. 429 4.6. High security 431 In the conventional hierarchical naming mechanism, it is very similar 432 as identifying a web with a URL, for example "/www.bjtu.edu.cn/movie 433 /a.avi". Hovever, the name of components is variable. Although it 434 is convenient to know every component of the resources, it results in 435 bad security. 437 In the proposed hn scheme, the flat part can solve this security 438 problem. For example, one hn resource name called "/www.bjtu.edu. 439 cn/s83hho90oxn2783nde4r:kongfu:avi:1024p:part1 3", and another 440 conventional name "/www.bjtu.edu.cn/movie/a.avi 3". The attacker 441 can know every component when he/she sees the conventional name. 442 On the contrary, the hn name does not have this problem. In the 443 hn naming scheme, people can just know the few components of the 444 resources, the attacker can not attack the components easily. 445 Therfore, this naming scheme has a better security than hierarchical 446 naming mechanism. Also, MD5 algorithm can be applied to the hn naming 447 in order to encrypt the resources displayed in the flat component. 449 5. Transition from IPv4 and IPv6 451 5.1. Case one 453 In TCP/IP networks, IPv4 and IPv6 addresses are used to represent the 454 resource locations. Combing with the port information and content 455 directory, IPv4 and IPv6 addresses can also be used to fetch the 456 desired information uniquely. We consider the hybrid naming scheme 457 transiting from IPv4 and IPv6 networks. 459 The IPv4 or IPv6 address is the hierarchical as the first part of the 460 hybrid name. The port number is flat as the second part of the hybrid 461 name. The content directory is a set as the third part of the hybrid 462 name. An illustration of transition from IPv4 and IPv6 is shown in 463 Figure 5. 465 +--------------------+----+-------------------------------------+---+ 466 |hn://192.168.100.100|8080|m:picture:library:west:computer:book | 3 | 467 +--------------------+----+-------------------------------------+---+ 469 +------------------------------------------+----+---------------+---+ 470 |hn://2001.da8.215.a815.c492.d445.3489.ec8c|8080|m:picture:book | 3 | 471 +------------------------------------------+----+---------------+---+ 473 Figure 5 Illustration of case one 475 5.2. Case two 477 Another case of transition from URL is shown in Figure 6. For example, 478 the url is "http://www.baidu.com:80/s?wd=icbc&rsv_bp=0&tn=baidu 479 &spt=3&ie=utf8", in which the symbol "?" is followed by a sequence of 480 attributes information. The hn format is shown as follows. 482 +------------------+-----+---------------------------------------+---+ 483 |hn://www.baidu.com|80/s?|wd:icbc rsvbp:0 tn:baidu spt:3 ie:utf8 | 3 | 484 +------------------+-----+---------------------------------------+---+ 486 Figure 6 Illustration of case two 488 6. Compatibility 489 6.1. Compatibility with DONA 491 Data-Oriented Network Architecture (DONA) transfers the 492 location-based routing to the content-based one. The hybrid naming 493 scheme is well compatible with DONA and the specific transformation 494 process is shown below. 496 (1) The hierarchical component is transferred into a flat id with a 497 shorter length, which is apart from the original flat component. 499 (2) This new flat id can be produced by some relevant authorities, 500 which are an analogue with the domain-name providers. Besides, this 501 flat id enables to represent huge amounts of hierarchical names by 502 constantly increasing its length. However, it is typically much 503 shorter than the previous name. 505 (3) Due to the variable length of hierarchical components, an integer 506 identifier is added to identify the length of transferred component. 507 This mechanism is similar to the partition method of subset. 509 (4) The symbol "/" is used for splitting this identifier with flat 510 component. 512 For example, there is a routing entry "/www.bjtu.edu.cn/m/movie/fhk56 513 2nfgjru056:kongfu:avi:1024p:part1 3". The first component "www.bjtu. 514 edu.cn/m/movie" is transferred to a unique flat name "dllta", which 515 is settled before the flat component. Meanwhile, we get an identifier 516 "5" to indicate that the first 5 characters represent the length of 517 transferred hierarchical name. It is significant to find that the name 518 can be restored easily according to their one-to-one mapping. This 519 transformation process is shown in Figure 7. 521 +----------------------------+---------------+-------------------+---+ 522 |hn://www.bjtu.edu.cn/m/movie|fhk562nfgjru056|kongfu 1024p part1 | 3 | 523 +----------------------------+---------------+-------------------+---+ 525 +---------------------------+-------------------+---+ 526 |dona://dlltafhk562nfgjru056/5|kongfu 1024p part1 | 3 | 527 +---------------------------+-------------------+---+ 529 Figure 7 An example of the transformation for hierarchical name 531 6.2. Compatibility with CCN/NDN 533 CCN or NDN have proposed a readable naming mechanism based on the 534 hierarchical structure. The hybrid naming scheme is also well 535 compatible with CCN/NDN. The specific transformation process 536 is shown below. 538 (1)The hierarchical component of hn structure will be not changed as 539 the first unit. 541 (2)The flat component is transfered to one unit followed by the first 542 unit. The seperation label uses "/". 544 (3)The attributes component is transfered to many units, which are 545 seperated by the label "/". 547 (4)The transformation bwtween the hybrid naming structure and CCN/NDN 548 hierarchical naming structure can easliy accomplish. 550 For example, there is a routing entry hn://www.bjtu.edu.cn/m/picture| 551 fh84rnf213gjrru |300*500 prairie 3". The components "fh84rnf213g 552 jrru|300*500 prairie" is transferred to several unique units 553 "id=fh84rnf213gjrru/300*500prairie". It is significant to find that the 554 name can be restored easily according to their one-to-one mapping. This 555 transformation process is shown in Figure 8. 557 +------------------------------+-----------------+---------------+--+ 558 |hn://www.bjtu.edu.cn/m/picture| fh84rnf213gjrru |300*500 prairie| 3| 559 +------------------------------+-----------------+---------------+--+ 561 +-----------------------------------------------------------------+--+ 562 |ccn://www.bjtu.edu.cn/m/picture/id=fh84rnf213gjrru/300*500prairie| 3| 563 +-----------------------------------------------------------------+--+ 565 Figure 8 An example of the transformation for flat name 567 7. Formal Syntax 569 The following syntax specification uses the augmented Backus-Naur 570 Form (BNF) as described in RFC-2234 [RFC2234]. 572 8. Security Considerations 573 The proposed hn naming scheme has potential benefits for the security. 574 The hierarchical prefix has a high aggregation, which can avoid the 575 security issues of rapid expansion in routing or forwarding table, 576 such as DoS attack. The flat component can protect the users' privacy 577 and the content secrets from readable names. The attributes component 578 can improve the management for the secure contents by using some 579 encryption key. 581 9. Conclusions 583 This document defines a novel hybrid naming scheme for unifying all 584 kinds of information (including resources, services and data). This 585 hybrid naming scheme owns many advantages, which can provide a good 586 compatibility for existing naming schemes. 588 10. References 590 [1] Jacobson, V., Smetters, D., Thornton, J., et al. "Networking 591 named content", Proceedings of the 5th international conference 592 on Emerging networking experiments and technologies. ACM 2009 593 pp. 1-12. 595 [2] Zhang, L., Estrin, D., Jacobson V., et al., "Named Data 596 Networking (NDN) project," Technical Report, NDN-0001, 2010. 598 [3] Yu, J., Varadhan, K., Li, T., et al, "Classless inter-domain 599 routing (CIDR): an address assignment and aggregation strategy", 600 RFC 1519, September 1993. 602 [4] Ding, S., Chen, Z. and Liu, Z., "Parallelizing FIB Lookup in 603 Content Centric Networking", Networking and Distributed 604 Computing (ICNDC), 2012 Third International Conference on. IEEE, 605 2012 pp. 6-10. 607 [5] Koponen, T., Chawla, M., Chun, B., et al, "A data-oriented (and 608 beyond) network architecture", ACM SIGCOMM Computer 609 Communication Review. ACM, 2007 pp. 181-192. 611 [6] Dannewitz, C., "NetInf: An Information-Centric Design for the 612 Future Internet," Proc. 3rd GI/ITGKuVS Workshop on The Future 613 Internet, Munich, Germany, May 2009. 615 [7] Carzaniga, A., Rutherford, M. and Wolf, A., "A routing scheme 616 for content-based networking", INFOCOM 2004. Twenty-third 617 Annual Joint Conference of the IEEE Computer and Communications 618 Societies. IEEE, 2004 pp. 918-928. 620 [8] https://observatorio.iti.upv.es/resources/new/542 622 [9] http://www.supermind.org/blog/740/average-length-of-a-url-part- 623 2 625 [10] Perino D. and Varvello M., "A reality check for content centric 626 networking", in Proc. ACM SIGCOMM workshop on Information 627 centric networking, 2011 pp. 44-49. 629 [11] Liu, H. and Zhang, D., "A TLV-structured data naming scheme for 630 content-oriented networking", Communications (ICC), 2012 IEEE 631 International Conference on. IEEE, 2012 pp. 5822-5827. 633 11. Acknowledgments 635 Meng Zhang and Liang Zhu contributed to discussion and revision of 636 this document whilst working at Beijing University of Posts and 637 Telecommunications, Beijing, China. 639 This document was prepared using 2-Word-v2.0.template.dot. 641 Authors' Addresses 643 Hongke Zhang 644 Beijing Jiaotong University (BJTU) 645 Beijing, 100044, P.R.China 647 Email: hkzhang@bjtu.edu.cn 648 Fei Song 649 Beijing Jiaotong University (BJTU) 650 Beijing, 100044, P.R.China 652 Email: fsong@bjtu.edu.cn 654 Wei Quan 655 Beijing Jiaotong University (BJTU) 656 Beijing, 100044, P.R.China 658 Email: weiquan@bjtu.edu.cn 660 Jianfeng Guan 661 Beijing University of Posts and Telecommunications (BUPT) 662 Beijing, 100876, P.R.China 664 Email: jfguan@bupt.edu.cn 666 Changqiao Xu 667 Beijing University of Posts and Telecommunications (BUPT) 668 Beijing, 100876, P.R.China 670 Email: cqxu@bupt.edu.cn