idnits 2.17.1 draft-zhang-icnrg-hn-08.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 == 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 10, 2018) is 2207 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5234' is mentioned on line 568, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 12, 2018 BJTU 5 Jianfeng Guan 6 Changqiao Xu 7 BUPT 8 April 10, 2018 10 Uniform information with a hybrid naming (hn) scheme 11 draft-zhang-icnrg-hn-08.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 This document may contain material from IETF Documents or IETF 19 Contributions published or made publicly available before November 20 10, 2008. The person(s) controlling the copyright in some of this 21 material may not have granted the IETF Trust the right to allow 22 modifications of such material outside the IETF Standards Process. 23 Without obtaining an adequate license from the person(s) controlling 24 the copyright in such materials, this document may not be modified 25 outside the IETF Standards Process, and derivative works of it may 26 not be created outside the IETF Standards Process, except to format 27 it for publication as an RFC or to translate it into languages other 28 than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on October 12, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. 59 Abstract 61 This document defines a hybrid naming scheme for unifying all kinds 62 of information including resources, services and data. With many 63 proposals of novel network architectures emerging, such as DONA, ICN 64 NDN, the location-based routing starts to transfer to the content 65 based ones. Currently, it is incompatible that many different 66 information naming schemes are adopted in different network 67 proposals, respectively, i.e. flat names in DONA, hierarchical names 68 in NDN. The proposed naming scheme adopts a hybrid naming structure, 69 which includes hierarchical component, flat component and attribute 70 component. The hybrid naming (hn) scheme enables to identify 71 different routing information uniformly, and provides many great 72 advantages, such as high aggregation, limited length, suffix holes 73 remission, fuzzy matching support, high security and good 74 compatibility with IPv4/IPv6, DONA, CCN/NDN and so on. 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 ..........................7 87 4. Advantages .................................................. 7 88 4.1. High aggregation........................................ 7 89 4.2. Limited length ......................................... 8 90 4.3. Suffix holes remission.................................. 8 91 4.4. Fuzzy matching support.................................. 9 92 4.5. Good compatibility..................................... 10 93 4.6. High security ......................................... 10 94 5. Transition form 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. IANA Considerations ........................................ 13 103 10. Conclusions ............................................... 13 104 11. References ................................................ 13 105 11.1. Normative References.................................. 13 106 11.2. Informative References................................ 14 107 12. Acknowledgments ........................................... 15 108 Authors' Addresses ............................................ 15 110 1. Introduction 112 1.1. Hierarchical naming 114 It has proposed a readable naming mechanism based on the 115 hierarchical structure by some emerging network architectures (i.e. 116 Content-Centric Network (CCN) [1]/Named Data Networking (NDN) [2]). 117 This kind of hierarchical name is very similar as identifying a web 118 with a URL for example "/www.bupt.edu.cn/content/a.avi". In this 119 example, "/" is the separator between adjacent components of the 120 name. 122 It's known that there are many advantages in this naming scheme. 123 First, it is well compatible with current applications or systems 124 based on URL, which can reduce the difficulty of deploying the novel 125 network. Second, it has a good aggregation to reduce the number of 126 routing information, thus, to improve lookup efficiency of routing 127 information. Besides, its lookup mechanism has a good compatibility 128 with the existing classless inter-domain routing (CIDR) [3]. 130 However, the hierarchical name also has some fatal disadvantages. 131 Because it consists of a series of unlimited components. The number 132 of components is changeable, and the length of each component is not 133 restricted. All these features cause the length of names variable 134 and relatively long [4]. In this way, the routing table and 135 forwarding table may be very huge, which results in low lookup 136 efficiency. 138 In addition, when users search for a resource, they might not 139 remember the long name of the resource. For example, users need the 140 resource a.avi, but they might not know the official name 141 "/www.bupt.edu.cn/content/a.avi" or "/www.bupt.edu.cn/movie/a.avi". 142 Thus, hierarchical naming structure is difficult to support a fuzzy 143 matching based on the attributes of names. 145 1.2. Flat naming 147 The flat naming mechanism has been used in other novel network 148 architectures, such as DONA [5] and NetInf [6]. It can be produced 149 by cryptographic hashing of the content or its attributes. 151 As the flat name has not any structure restriction, it can be 152 obtained and used more flexibly. Any string with a fix length, no 153 matter whether it is readable or not, can be used as a flat name. 155 However, the flat name has a low degree of aggregation, which will 156 increase the number of routing entries and reduce the expandability 157 of routing table. Besides, it increases the probability for users to 158 forget the official names of the desired information for most of 159 flat names being not readable. When users want to obtain contents, 160 it needs an additional mapping system to map readable names and 161 unreadable names for users. 163 1.3. Attribute naming 165 The naming mechanism based on attributes of content is used in the 166 CBCB [7]. It enumerates the attribute information of a resource, 167 such as the category, format, date, feature, level and so on. This 168 name is non-uniqueness which is different from the former two 169 mechanisms. The related content can be searched and located by means 170 of the key properties of resource. 172 The advantage of this naming mechanism is that, it supports 173 searching key words and provides benefits for the fuzzy matching of 174 searching resources. However, there may be many similar properties 175 for a set of certain resources. A number of attributes is hardly 176 ensure the uniqueness of naming. Thus, to guarantee the uniqueness, 177 the attributes stored in routing system will be very huge. 179 2. Conventions used in this document 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in RFC 2119 [RFC2119]. 185 In this document, these words will appear with that interpretation 186 only when in ALL CAPS. Lower case uses of these words are not to be 187 interpreted as carrying significance described in RFC 2119. 189 In this document, the characters ">>" preceding an indented line(s) 190 indicates a statement using the key words listed above. This 191 convention aids reviewers in quickly identifying or finding the 192 portions of this RFC covered by these keywords. 194 3. Novel hybrid naming (hn) format 196 According to the analysis of above three naming mechanisms in terms 197 of advantages and disadvantages, a hybrid naming is suggested to 198 highlight the benefits of them and weaken their demerits. 200 Most importantly of all, three different mainstream naming schemes 201 are adopted in different novel network architectures, which makes 202 the networks be hardly compatible and implemented complexly. 204 There's one easy and all-benefit solution is to integrate them, and 205 to take each of them as a part of the hybrid naming solution. In 206 other words, each of them takes some weight of the novel naming 207 scheme. 209 We proposed a hybrid naming mechanism (named by "hn"), which 210 organizes the three naming mechanisms in a sequence, and builds a 211 more powerful and universal naming format. 213 The hybrid naming format should include three components: 215 o Hierarchical component 217 o Flat component 219 o Attribute component 221 Each part carries different information of name in different 222 formats, which combined to an entire name. The hybrid name is 223 started by a symbol "hn://". The order of three parts should be as 224 follows: 226 1. The first part of a name is very essential for the aggregation of 227 routing entries. A hierarchical structure is adopted in the first 228 part. The symbol "/" is used to split the hierarchical levels in 229 this part. 231 2. The second part of a name is very important to identify the 232 content uniquely. The second part uses a flat structure and a 233 string with a fix length through hash computing. 235 3. The third part of a name is used to represent the extensive 236 information of resources. The attribute-based structure is 237 selected in the third part, which is composed of a set of 238 attribute words. An example of the hybrid name for a movie is 239 shown in Figure 1. 241 +----------------------+---------------+---------------------------+ 242 |hn://www.bjtu.edu.cn/m|u584rnfiur324yh|movie:avi:1024:part1:kongfu| 243 +----------------------+---------------+---------------------------+ 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 +--------------------------+---------------+-----------------------+ 251 Figure 2 An example of hn for a picture 253 3.1. Hierarchical component generating 255 Hierarchical component is the first part of the hn naming format. 256 This part is suggested to be generated by a followed reference 257 standard. 259 The string set in top level, string set in second level and so on is 260 defined by this standard. It is very useful to promote its 261 aggregation greatly. One available but not complete reference 262 standard for naming hierarchical component is the naming scheme of 263 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, and it must combine with the first part to identify the 270 information uniquely. 272 Flat component can be generated by cryptographic hash algorithm by 273 the information itself or some characters of the information. Even 274 though this part has a low probability of aggregation, it highlights 275 and 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 302 route can be improved. For example, there are two routing 303 entries"/www.bjtu.edu.cn/m/movie/fhk562nfgjru056:kongfu:avi:1024p:pa 304 rt1 3" and 305 "/www.bjtu.edu.cn/m/picture/fh84rnf213gjrru:jpg:300*500:prairie 3" 306 which have the same forwarding port "3" and prefix 307 "/www.bjtu.edu.cn/m". Therefore, the forwarding port and 308 "/www.bjtu.edu.cn/m" can only be stored in routing table. Above all, 309 it not only reduces the entries of routing table, but also reduces 310 the length of each routing entries. An example of aggregation 311 process is shown in Figure 3. 313 +----------------------------+---------------+------------------+--+ 314 |hn://www.bjtu.edu.cn/m/movie|fhk562nfgjru056|kongfu 1024p part1|3 | 315 +----------------------------+---------------+------------------+--+ 317 +------------------------------+-----------------+---------------+-+ 318 |hn://www.bjtu.edu.cn/m/picture| fh84rnf213gjrru |300*500 prairie|3| 319 +------------------------------+-----------------+---------------+-+ 320 +----------------------+---+ 321 |hn://www.bjtu.edu.cn/m| 3 | 322 +----------------------+---+ 323 Figure 3 An example of aggregation 325 4.2. Limited length 327 The length of name based on hierarchical structure is variable and 328 relatively long, because it must be formed by several parts and the 329 number of component is changeable. Kelvin [9] has selected 6627999 330 URL in 78764 different domain names, and the statistics shows that 331 the average length of URL is 76.97 bytes. In the architecture of 332 ICN, the name must be extracted to query in forwarding table or 333 routing table and a long name entry will lead to the query speed 334 becoming lower, hence, affecting the performance of routing. 336 The hn naming scheme uses a part of flat component in the name to 337 ease this problem. A fix length flat part is embedded behind the 338 hierarchical part. This design not only can restrict the length of 339 names not too long, but also will reduce the effect of the 340 aggregation. For example, if the average length of hierarchical part 341 is controlled within 30 bytes, adopting a flat part with a fix 342 length of 20 bytes, then, the whole average length will be 343 restricted within 50 bytes. Comparing to 76.97 bytes, the length is 344 shortened by nearly 35%, which will improve the query speed of name 345 greatly using the length dependent algorithms. 347 4.3. Suffix holes remission 349 The suffix hole is a well-known problem for the route of prefix 350 matching. For example, a routing entry "/www.bjtu.edu.cn/movie/3" is 351 stored in the route table for prefix matching. In fact, it is 352 aggregated by "/www.bjtu.edu.cn/movie/a.avi/part1 3"and 353 "/www.bjtu.edu.cn/movie/b.avi/part1 3". In this way, the forwarding 354 packets will be forward from port 3, only if the prefix of name is 355 "/www.bjtu.edu.cn/movie/". However, if packets with a name of 356 "/www.bjtu.edu.cn/movie/c.avi" arrive in the router, it will also be 357 forwarded from port 3. In fact, the network that port 3 connects 358 only has a.avi and b.avi. This causes the so-called suffix holes 359 [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:20 366 12-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 a packet whose name is "/www.bjtu.edu.cn/movie/a932jfdjf2032942-jdd: 369 control: avi: 1024p: part1: part2" arrives at this router. 371 However, it could not be forwarded from the port 3 based on hn 372 scheme due to the incomplete prefix matching. There is a suffix list 373 in each aggregating prefix, and the packet will be forwarded only 374 when the requesting suffix exists in the suffix list. In hn scheme, 375 it must assort a suffix list for each routing entries like 376 "/www.bjtu.edu.cn/movie/ 3" to store the flat part 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 +-------+ +-------+ 406 Figure 4 The hn lookup process 408 4.4. Fuzzy matching support 410 In the practical, it's an important situation that the users may not 411 know the full official resource name when they search a resource. 412 The hn naming scheme supports the fuzzy matching according to the 413 function of the attribute component. For example, if the users need 414 the resource a.avi, they don't need to know the official name 415 "hn://www.bjtu.edu.cn/m/|u584uuj89324ru|kongfu:movie:avi:1024p:part1 416 ". In this case, users only publish the information of video 417 "kongfu" and the resolution ratio "1024p". Then the related 418 resources can be found intelligently by fuzzy matching based on the 419 attribute component matching. This is the benefit about embedding 420 attribute of resource in the end of name. 422 4.5. Good compatibility 424 This naming scheme provides a good compatibility for all three 425 mainstream naming schemes, which are the subset of the hn naming 426 scheme. 428 4.6. High security 430 It is very similar as identifying a web with a URL in the 431 conventional hierarchical naming mechanism, for example 432 "/www.bjtu.edu.cn/movie/a.avi". However, the name of components is 433 variable. Although it is convenient to know every component of the 434 resources, it results in bad security. 436 In the proposed hn scheme, this security problem can be solved. For 437 example, one hn resource name called "/www.bjtu.edu.cn/ 438 s83hho90oxn2783nde4r: kongfu: avi: 1024p: part1 3", and another 439 conventional name "/www.bjtu.edu.cn/movie/a.avi 3". The attacker can 440 know every component when he/she sees the conventional name. On the 441 contrary, the hn name does not have this problem. In the hn naming 442 scheme, people can just know the few components of the resources, 443 thus, the attacker could not attack the components easily. 444 Therefore, this naming scheme has a better security than 445 hierarchical naming mechanism. Also, MD5 algorithm can be applied to 446 the hn naming in order to encrypt the resources displayed in the 447 flat component. 449 5. Transition form IPv4 and IPv6 451 5.1. Case one 453 In TCP/IP networks, IPv4 and IPv6 addresses are used to represent 454 the resource locations. IPv4 and IPv6 addresses can also be used to 455 fetch the desired information uniquely combing with the port 456 information and content directory. We consider the hybrid naming 457 scheme transiting from IPv4 and IPv6 networks. 459 The IPv4 or IPv6 address is the hierarchical as the first part of 460 the hybrid name. The port number is flat as the second part of the 461 hybrid name. The third part of hybrid name is the content directory 462 set. 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 +--------------------+----+-------------------------------------+--+ 468 +------------------------------------------+----+---------------+--+ 469 |hn://2001.da8.215.a815.c492.d445.3489.ec8c|8080|m:picture:book |3 | 470 +------------------------------------------+----+---------------+--+ 471 Figure 5 Illustration of case one 473 5.2. Case two 475 Another case of transition from URL is shown in Figure 6. For 476 example, the url is 477 "http://www.baidu.com:80/s?wd=icbc&rsv_bp=0&tn=baidu 478 &spt=3&ie=utf8", in which the symbol "?" is followed by a sequence 479 of attributes information. The hn format is shown as following. 481 +------------------+-----+--------------------------------------+--+ 482 |hn://www.baidu.com|80/s?|wd:icbc rsvbp:0 tn:baidu spt:3 ie:utf8|3 | 483 +------------------+-----+--------------------------------------+--+ 484 Figure 6 Illustration of case two 486 6. Compatibility 488 6.1. Compatibility with DONA 490 Data-Oriented Network Architecture (DONA) transfers the location- 491 based routing to the content-based one. The hybrid naming scheme is 492 well compatible with DONA and the specific transformation process is 493 shown as below. 495 (1)The hierarchical component is transferred into a flat id with a 496 shorter length, which is apart from the original flat component. 498 (2)This new flat id can be produced by some relevant authorities, 499 which is an analogue with the domain-name providers. Besides, this 500 flat id enables to represent huge amounts of hierarchical names by 501 constantly increasing its length. However, it is typically much 502 shorter than the previous name. 504 (3)Due to the variable length of hierarchical components, an integer 505 identifier is added to identify the length of transferred 506 component. This mechanism is similar to the partition method of 507 subset. 509 (4)The symbol "/" is used for splitting this identifier with flat 510 component. 512 For example, there is a routing entry 513 "/www.bjtu.edu.cn/m/movie/fhk562nfgjru056:kongfu:avi:1024p:part1 3". 514 The first component "www.bjtu.edu.cn/m/movie" is transferred to a 515 unique flat name "dllta", which is settled before the flat 516 component. Meanwhile, we get an identifier "5" to indicate that the 517 first 5 characters represent the length of transferred hierarchical 518 name. It is significant that the name can be restored easily 519 according to their one-to-one mapping. This transformation process 520 is shown in Figure 7. 522 +---------------------------+---------------+-------------------+--+ 523 |hn://www.bjtu.edu.cn/m/movie|fhk562nfgjru056|kongfu 1024p part1|3 | 524 +---------------------------+---------------+-------------------+--+ 525 +---------------------------+--------------------+---+ 526 |dona://dlltafhk562nfgjru056/5|kongfu 1024p part1| 3 | 527 +---------------------------+--------------------+---+ 528 Figure 7 An example of the transformation for hierarchical name 530 6.2. Compatibility with CCN/NDN 532 CCN or NDN have proposed a readable naming mechanism based on the 533 hierarchical structure. The hybrid naming scheme is also well 534 compatible with CCN/NDN. The specific transformation process is 535 shown as below. 537 (1)The hierarchical component of hn structure will not be changed as 538 the first unit. 540 (2)The flat component is transferred to one unit followed by the 541 first unit, and uses "/" as separation label. 543 (3)The attributes component is transferred to many units, which are 544 separated by the label "/". 546 (4)The transformation between the hybrid naming structure and 547 CCN/NDN hierarchical naming structure can easily accomplish. 549 For example, there is a routing entry 550 hn://www.bjtu.edu.cn/m/picture|fh84rnf213gjrru|300*500 prairie 3". 551 The components "fh84rnf213gjrru|300*500 prairie" is transferred to 552 several unique units "id=fh84rnf213gjrru/300*500prairie". It is 553 significant that the name can be restored easily according to their 554 one-to-one mapping. This transformation process is shown in Figure 555 8. 557 +------------------------------+-----------------+----------------+-+ 558 |hn://www.bjtu.edu.cn/m/picture| fh84rnf213gjrru |300*500 prairie |3| 559 +------------------------------+-----------------+----------------+-+ 560 +-----------------------------------------------------------------+-+ 561 |ccn://www.bjtu.edu.cn/m/picture/id=fh84rnf213gjrru/300*500prairie|3| 562 +-----------------------------------------------------------------+-+ 563 Figure 8 An example of the transformation for flat name 565 7. Formal Syntax 567 The following syntax specification uses the augmented Backus-Naur 568 Form (BNF) as described in RFC 5234 [RFC5234]. 570 8. Security Considerations 572 The proposed hn naming scheme has potential benefits for the 573 security. The hierarchical prefix has a high aggregation, which can 574 avoid the security issues of rapid expansion in routing or 575 forwarding table, such as DoS attack. The users' privacy and the 576 content secrets can be protected by the flat component from readable 577 names. The attributes component can improve the management for the 578 secure contents by using some encryption key. 580 9. IANA Considerations 582 This document presents no IANA considerations. 584 10. Conclusions 586 This document defines a novel hybrid naming scheme for unifying all 587 kinds of information (including resources, services and data). This 588 hybrid naming scheme owns many advantages, which can provide a 589 better compatibility for existing naming schemes. 591 11. References 593 11.1. Normative References 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, DOI 597 10.17487/RFC2119, March 1997, . 600 11.2. Informative References 602 [1] Jacobson, V., Smetters, D., Thornton, J., et al. "Networking 603 named content", Proceedings of the 5th international 604 conference on Emerging networking experiments and 605 technologies. ACM 2009 pp. 1-12. 607 [2] Zhang, L., Estrin, D., Jacobson V., et al., "Named Data 608 Networking (NDN) project," Technical Report, NDN-0001, 2010. 610 [3] Yu, J., Varadhan, K., Li, T., et al, "Classless inter-domain 611 routing (CIDR): an address assignment and aggregation 612 strategy", RFC 4632, September 1993. 614 [4] Ding, S., Chen, Z. and Liu, Z., "Parallelizing FIB Lookup in 615 Content Centric Networking", Networking and Distributed 616 Computing (ICNDC), 2012 Third International Conference on. 617 IEEE, 2012 pp. 6-10. 619 [5] Koponen, T., Chawla, M., Chun, B., et al, "A data-oriented 620 (and beyond) network architecture", ACM SIGCOMM Computer 621 Communication Review. ACM, 2007 pp. 181-192. 623 [6] Dannewitz, C., "NetInf: An Information-Centric Design for the 624 Future Internet," Proc. 3rd GI/ITGKuVS Workshop on The Future 625 Internet, Munich, Germany, May 2009. 627 [7] Carzaniga, A., Rutherford, M. and Wolf, A., "A routing scheme 628 for content-based networking", INFOCOM 2004. Twenty-third 629 Annual Joint Conference of the IEEE Computer and 630 Communications Societies. IEEE, 2004 pp. 918-928. 632 [8] https://observatorio.iti.upv.es/resources/new/542 634 [9] http://www.supermind.org/blog/740/average-length-of-a-url- 635 part-2 637 [10] Perino D. and Varvello M., "A reality check for content 638 centric networking", in Proc. ACM SIGCOMM workshop on 639 Information centric networking, 2011 pp. 44-49. 641 12. Acknowledgments 643 Meng Zhang and Liang Zhu contributed to discussion and revision of 644 this document whilst working at Beijing University of Posts and 645 Telecommunications, Beijing, China. 647 This document was prepared using 2-Word-v2.0.template.dot. 649 Authors' Addresses 651 Hongke Zhang 652 Beijing Jiaotong University (BJTU) 653 Beijing, 100044, P.R.China 655 Email: hkzhang@bjtu.edu.cn 657 Fei Song 658 Beijing Jiaotong University (BJTU) 659 Beijing, 100044, P.R.China 661 Email: fsong@bjtu.edu.cn 663 Wei Quan 664 Beijing Jiaotong University (BJTU) 665 Beijing, 100044, P.R.China 667 Email: weiquan@bjtu.edu.cn 669 Jianfeng Guan 670 Beijing University of Posts and Telecommunications (BUPT) 671 Beijing, 100876, P.R.China 673 Email: jfguan@bupt.edu.cn 674 Changqiao Xu 675 Beijing University of Posts and Telecommunications (BUPT) 676 Beijing, 100876, P.R.China 678 Email: cqxu@bupt.edu.cn