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