idnits 2.17.1 draft-detti-conet-ip-option-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 117 has weird spacing: '... legacy int...' -- The document date (September 30, 2011) is 4584 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Detti 3 Internet-Draft S. Salsano 4 Intended status: Informational N. Blefari-Melazzi 5 Expires: April 2, 2012 Univ. of Rome "Tor Vergata" 6 September 30, 2011 8 An IPv4 Option to support Content Networking 9 draft-detti-conet-ip-option-01 11 Abstract 13 The Content Centric Networking paradigm, also known as Named Data 14 Networking, shifts the focus of networking from providing connections 15 between hosts to efficiently providing content to the users. The 16 work on CCN has traditionally been performed looking at "clean-slate" 17 solutions which aims to replace IP with a new paradigm. On the other 18 hand, in this memo we propose an "integration" approach to Content 19 Centric Networking, i.e. we extend the IP protocol using a new IP 20 Option. The new IP option is used by routers to support networking 21 based on content rather than (or better in addition to) end-point 22 addresses. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 2, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. CONET IP Option . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. CONET protocol . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.1. Interest CONET Information Unit (Interest CIU) . . . . . . 10 63 4.1.1. Processing in the end node . . . . . . . . . . . . . . 10 64 4.1.2. Processing in the serving node . . . . . . . . . . . . 10 65 4.1.3. Processing in the border node . . . . . . . . . . . . 11 66 4.1.4. Processing in the intermediate node . . . . . . . . . 11 67 4.1.5. Processing in the legacy routers . . . . . . . . . . . 12 68 4.2. Named data CONET Information Unit (Named data CIU) . . . . 12 69 4.2.1. Processing in the responding node . . . . . . . . . . 12 70 4.2.2. Processing in a border node . . . . . . . . . . . . . 13 71 4.2.3. Processing in an intermediate node . . . . . . . . . . 13 72 4.2.4. Processing in the legacy routers . . . . . . . . . . . 13 73 5. Routing by name framework . . . . . . . . . . . . . . . . . . 14 74 6. CONET default namespaces . . . . . . . . . . . . . . . . . . . 14 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 76 8. Performance Considerations . . . . . . . . . . . . . . . . . . 15 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 In this memo we propose a new approach to Content Centric Networking 87 [Koponen07][Jacobson09], based on extending the IP protocol by using 88 a new IP Option [RFC0791] called CONET IP option. The CONET IP 89 option can be used by routers to support content aware networking, in 90 addition to classical address based networking. The proposed 91 solution has been described in [CONET11]. 93 The CONET IP option is used to identify the content which is the 94 object of the data transfer. Its usage allows efficient in-network 95 caching and replication of content. 97 The architecture foresees end hosts, serving nodes and CONET nodes. 98 End hosts require for content. Serving nodes provide content. CONET 99 nodes: i) route requests from end hosts to serving nodes; ii) deliver 100 content from serving nodes to end hosts; iii) may cache content and 101 therefore provide it to end hosts without contacting the serving 102 node. CONET nodes can be further classified in Border nodes and 103 Internal nodes. Border nodes are able to perform both "routing-by- 104 name" and caching, Internal nodes are not able to perform "routing- 105 by-name" (but only plain IP routing) and can only perform caching. 107 requests for content 108 -------------------> 109 content is provided 110 <------------------- 111 +----+ +----+ +----+ 112 | | --| |------| | 113 +----+\ / +----+ +----+ 114 \ +----+ +----+ / 115 ----| |------| |/ 116 +----+ +----+ 117 end node legacy intermediate border serving 118 router node node node 119 | | 120 +---------CONET next hop----------->+ 122 Figure 1: CONET architecture 124 In addition to the new CONET IP option, the proposed solution needs a 125 new Internet Protocol Number to identify the CONET protocol. 127 2. CONET IP Option 129 The CONET IP option has the following format: 131 +--------+--------+--------+--------+ 132 |100xxxxx|yyyyyyyy|ppppLLCr| NID | 133 +--------+--------+--------+--------+ 134 | NID (variable length) | 135 | ... | 136 +--------+--------+--------+--------+ 137 | CSN |optional CSN cont. ... | 138 +--------+--------+--------+--------+ 140 Figure 2: IP Option 142 Type: 143 Copied flag: 1 (all fragments must carry the option) 144 Option class: 0 (control) 145 Option number: xxxxx (decimal) TO BE ALLOCATED BY IANA 147 Length: 148 yyyyyyyy: variable length of IP option in bytes (including the 149 Type and Length bytes 151 pppp : CONET Information Unit Type - This four bits field is used to 152 differentiate between different types of CONET Information Units 153 (CIUs) 155 0 Reserved 156 1 Interest CONET Information Unit (Interest CIU) 157 2 Named-data CONET Information Unit (Named-data CIU) 158 2-15 Reserved 160 LL : NID Length Specification - This two bits field provides the 161 length of Network Identifier (NID) field or specifies how the NID 162 length is provided. 164 0 16 bytes length 165 1 Reserved 166 2 NID starts with a one byte length field (NID length in bytes) 167 3 Reserved 169 C : cache indication - This one bit field is used to control cache 170 operations. 172 0 No cache 173 1 Cache 175 Within Information Units that request for content (e.g. interest 176 CIU), if the bit is set to "No cache" it indicates to the crossed 177 nodes not to look for the content in the cache, but to forward the 178 request toward the source. Within Information Units that carry 179 content (e.g. named-data CIU), if the bit is set to "No cache" it 180 indicates to the crossed nodes not to cache the content. 182 r : reserved - The last bit of the first byte after the option length 183 is reserved. 185 NID : Network Identifier (NID) field - The NID is a unique identifier 186 for the content. The NID is carried in the NID field. How to 187 determine the length of this field is defined by the NID Length 188 Specification field. If the NID Length Specification field 189 determines the field length, the NID field only carries the NID. If 190 the NID Length Specification field indicates that the field length is 191 carried in the field itself, the NID field starts with a one byte 192 field that determines its length. 194 If NID Length Specification = 0 (i.e. 16 bytes len), 195 the NID field is as follows: 197 +--------+--------+--------+--------+ 198 | NID | 199 +--------+--------+--------+--------+ 200 | | 201 +--------+--------+--------+--------+ 202 | | 203 +--------+--------+--------+--------+ 204 | | 205 +--------+--------+--------+--------+ 207 If NID Length Specification = 2 (i.e. NID starts with a one byte 208 length field), the NID field is as follows: 210 +--------+--------+--------+--------+ 211 | length | NID | 212 +--------+--------+--------+--------+ 213 | ... | 214 +--------+--------+--------+--------+ 215 | ... | 217 The NID starts with a two bytes field called NID namespace ID that 218 determines the structure of the rest of the NID. NID namespace 219 values needs to be assigned by the IANA. Note that in most 220 circumstances, the NID can be processed by the routers as an opaque 221 object, as described in Section 4. This is why the NID namespace ID 222 has been included at the beginning of the NID itself. In other cases 223 the nodes are requested to perform a routing-by-name procedure, which 224 may require a semantic understanding of the NID. 226 +--------+--------+--------+--------+ 227 | NID namespace ID| ... | 228 +--------+--------+--------+--------+ 229 | ... | 230 +--------+--------+--------+--------+ 231 | ... | 232 +--------+--------+--------+--------+ 233 | ... | 234 +--------+--------+--------+--------+ 236 CSN : Chunk Sequence Number - This field carries the Chunk Sequence 237 Number that identifies a portion of the content. The assumption here 238 is that the content is split in a sequence of smaller unit called 239 "chunks". The Chunk Sequence Number is represented with a variable 240 number of bytes. An initial bit pattern determines the length of the 241 CSN field. 243 1 byte CSN (7 bits CSN range) 244 +--------+ 245 |0 | 246 +--------+ 248 2 bytes CSN (15 bit CSN range) 249 +--------+--------+ 250 |10 | 251 +--------+--------+ 253 3 bytes CSN (21 bit CSN range) 254 +--------+--------+--------+ 255 |110 | | | 256 +--------+--------+--------+ 258 4 bytes CSN (28 bit CSN range) 259 +--------+--------+--------+--------+ 260 |1110 | | | | 261 +--------+--------+--------+--------+ 263 5 bytes CSN (32 bit CSN range) 264 +--------+--------+--------+--------+ 265 |11110000| | | | 266 +--------+--------+--------+--------+ 267 | | 268 +--------+ 270 6 bytes CSN (40 bit CSN range) 271 +--------+--------+--------+--------+ 272 |11110001| | | | 273 +--------+--------+--------+--------+ 274 | | | 275 +--------+--------+ 277 Binary patterns from 11110010 to 11111111 are reserved. They can be 278 used to extend the CSN range if needed. With the above defined 279 option, we can have up to 2^40 chunks in a content. Assuming a 280 relatively small chunk size of 1 KBytes, it is possible to have a 281 content of 1099 TeraBytes, while assuming a more reasonable chunk 282 size of 256 Kbyte it is possible to have a content of 281474 283 TeraBytes (218 PetaBytes). 285 The rationale for having a variable length encoding is the following. 286 The CSN range for a given content is determined by the content size 287 divided by the chunk size. As content of very different sizes can be 288 transmitted, the CSN range can be very different. Therefore it is 289 not efficient to dimension this field considering the maximum number 290 of chunks in which a content can be split. 292 3. CONET protocol 294 In the previous section, we have seen the description of the CONET IP 295 option that is carried in the header of IP packets. The payload of 296 IP packets is the CONET protocol and a specific IP protocol number is 297 assigned to it: 299 CONET IP protocol number : xxx (to be assigned by IANA). 301 The figure below shows the CONET protocol stack. CONET protocol is 302 divided in two sub-layers, whose data unit are respectively denoted 303 as "Carrier Packets" and "CONET Information Units". A CONET 304 Information Unit (CIU) can be split into different Carrier Packets. 305 Each Carrier Packet is transported by an IP packet. There are 306 different types of CONET Information Units, the CIU type information 307 is carried in the CONET Information Unit Type field in the CONET IP 308 option. 310 +--------+--------+--------+ \ 311 | CONET Information Units | | 312 +--------+--------+--------+ |- CONET protocol 313 | Carrier Packets | | 314 +--------+--------+--------+ / 315 | IP (with CONET IP option)| 316 +--------+--------+--------+ 318 The generic structure of a Carrier Packet (CP) is reported hereafter: 320 +-------------------------+ 321 | CP Payload header | 322 +-------------------------+ 323 | CP Payload | 324 +-------------------------+ 325 | CP Path state | 326 +-------------------------+ 328 The information contained in the CP Payload header is specific for 329 each CIU type. It will be described in other specification 330 documents. The CP payload header contains the length of the CP 331 Payload and allows to identify the start of the CP Path state field. 332 The CP Path state field is used in end nodes, border nodes and 333 serving nodes to assist in the forwarding operation of carrier 334 packet, therefore it is described here. 336 The CP Path State field stores the end node address and the addresses 337 of the set of crossed border nodes in the path from end node to the 338 serving node (or to a border or intermediate node that provides a 339 requested content). The format of the CP path state field is 340 reported hereafter (assuming that IPv4 addresses are carried). 342 CP Path State field 344 +--------+--------+--------+--------+ 345 |0 len | pointer| ad-type| addr 1 | 346 +--------+--------+--------+--------+ 347 | addr 2 | addr 3 | addr 4 | ad-type| 348 +--------+--------+--------+--------+ 349 | addr 1 | addr 2 | addr 3 | addr 4 | 350 +--------+--------+--------+--------+ 351 | ... | 352 +--------+--------+--------+--------+ 354 +--------+--------+--------+--------+ 355 |1 len | pointer | 356 +--------+--------+--------+--------+ 357 | ad-type| addr 1 | addr 2 | addr 3 | 358 +--------+--------+--------+--------+ 359 | addr 4 | ad-type| addr 1 | addr 2 | 360 +--------+--------+--------+--------+ 361 | addr 3 | addr 4 | 362 +--------+--------+ 364 The length field specifies the length of the CP Path State field in 365 bytes. If the first bit of the len field is 0, the remaining 7 bits 366 of the first byte are used as len field and both the length field and 367 the pointer field are one byte length. In this case the maximum 368 value of the length of the CP Path State field is 127. If the first 369 bit of the len field is 1, both the length field and the pointer 370 field are two bytes length. In this case the maximum value of the 371 length of the CP Path State field is 32767. 373 The pointer field specifies the offset, starting from the start of 374 the CP Path State field where the last address has been inserted. 376 Each address is represented as a couple (ad-type, address) it could 377 be represented by a triple (ad-type, ad-length, address) if the 378 address type is of variable length. The ad-type field is one byte 379 size and currently admitted values are: 381 0 Reserved 382 1 Public IPv4 address (len is 4 bytes, no ad-length needed) 383 2 Public Ipv6 address (len is 16 bytes, no ad-length needed)) 384 3 Ethernet address (len is 6 bytes, no ad-length needed)) 385 4-255 Reserved 387 Note that in the context of this document, only the IPv4 case is 388 covered. The definition of CONET protocols and procedures for IPv6 389 and for direct mapping into Ethernet are out of the scope. 391 4. Procedures 393 4.1. Interest CONET Information Unit (Interest CIU) 395 4.1.1. Processing in the end node 397 An end-node that wants to retrieve a content (or better a Chunk of a 398 content) issues an Interest CIU, the NID and the Chunk Sequence 399 Number of the required Content are respectively transported in the 400 Network Identifier (NID) field and in the CSN field of the CONET IP 401 option. The end-node stores its IP address in CP path state field, 402 initializing the pointer field. Assuming for simplicity that the 403 Interest CIU will fit into a single Carrier Packet, the Interest CIU 404 will be included in the Carrier Packet that in turn is inserted into 405 an IP packet. 407 The end-node must now determine the destination IP address for the 408 Carrier Packet. The end-node performs a routing-by-name, trying to 409 associate the NID with a next hop (i.e. with the IP address of the 410 next hop). The next hop can be the Serving Node (if the Serving node 411 is in the same CONET subnet of the end-node) or a Border Node of the 412 CONET subnet (if the Serving node is in a different CONET subnet). 413 Typically the end-node does not participate to the routing-by-name 414 protocols, therefore it cannot resolve the NID into the address of 415 the next hop, but it has to ask a name server. The name server is a 416 part of the so called Name System. Once this information is 417 retrieved by the name server, the end-note can fill the IP 418 destination address in the IP header and sends the packet. The end- 419 node may cache the mapping (NID -> next hop) into its memory as well. 421 4.1.2. Processing in the serving node 423 If the Serving Node is in the same CONET than the end-node, the 424 serving node IP address will be used a destination IP address by the 425 end-node. The Serving node will receive an IP packet directed to 426 itself, whose IP protocol number is "CONET". Therefore the packet 427 will be internally dispatched toward the "CONET entity" in the 428 Serving Node. The CONET entity reads the CONET information unit type 429 from the CONET IP options and recognizes that the received packet is 430 an interest packet. Then it reads the NID and Chunk Sequence Number 431 in the CONET IP option, the NID will correspond to a content provided 432 by the Serving Node. The CONET entity will then process the CONET 433 transport protocol information carried in the IP payload, which may 434 for example specify a requested offset within the chunk. Finally the 435 CONET entity will respond to the interest packet by sending the 436 requested named-data CIU. 438 4.1.3. Processing in the border node 440 If the Serving Node is in a different CONET than the end-node, the 441 address of a CONET border node will be used a destination IP address 442 by the end-node. The border node will receive an IP packet directed 443 to itself, whose IP protocol number is "CONET". Therefore the packet 444 will be internally dispatched toward the "CONET entity" in the border 445 node. The CONET entity reads the CONET information unit type from 446 the CONET IP options and recognizes that the received packet is an 447 interest packet. Then it reads the NID and Chunk Sequence Number in 448 the CONET IP option and is able to understand which content and which 449 part of the available content it needs to provide. If the Cache 450 indication field is set to "No Cache" or if the field is set to 451 "Cache" but the chunk is not available in the cache, the border node 452 starts the routing-by-name process. It will resolve the next hop of 453 the interest packet, which can be a serving node in a different CONET 454 subnet (with respect to the one from which the interest packet was 455 received) connected to the Border Node, or another Border Node in the 456 path toward the serving node. Before sending out the packet, the 457 border node adds its IP address in the CP Path State field and 458 updates the pointer field. Note that these procedures needs to be 459 performed in the "fast path" of the border node (in this case the 460 CONET entity in the border node can be seen as an integral part of 461 the enhanced IP protocol). If the Cache indication field is set to 462 "Cache" and the border node has found that the chunk corresponding to 463 the NID/CSN is available in its cache, the border node will process 464 the CONET transport protocol information carried in the IP payload, 465 which may for example specify a requested offset within the chunk and 466 it will respond to the interest packet by sending the requested 467 named-data CIU. 469 4.1.4. Processing in the intermediate node 471 When a packet is sent to the CONET next hop (as selected by the end 472 node or by a border node) using the IP destination address of the 473 next hop resolved by the routing-by-name, it can cross different IP 474 routers in the path from the sending node and the next hop. A 475 crossed router that is aware of the CONET IP option, is a CONET 476 intermediate node. This node may have cached the the chunk that is 477 requested by the interest packet. The intermediate node works as 478 follows. When processing the IP header for the received packet, it 479 finds that the packet contains the CONET IP option. If the Cache 480 indication field is set to "No Cache", the intermediate node forwards 481 the packet using the destination IP address. If the Cache indication 482 field is set to "Cache", the intermediate node checks the presence of 483 the chunk in its cache before forwarding the IP packet. Therefore, 484 it reads the NID and Chunk Sequence Number in the CONET IP option and 485 checks if the chunk is present in its cache. If the chunk is not 486 present, the normal IP processing is continued. Note that these 487 operations needs to be performed in the "fast path" of the router and 488 they only require information that is transported in the IP option. 489 If the chunk is present in the CONET router cache, the router will 490 process the CONET transport protocol information carried in the IP 491 payload, which may for example specify a requested offset within the 492 chunk and it will respond to the interest packet by sending the 493 requested named-data CIU. 495 4.1.5. Processing in the legacy routers 497 When a packet is sent to the CONET next hop (as selected by the end 498 node or by a border node) using the IP destination address of the 499 next hop resolved by the routing-by-name, it can cross different IP 500 routers in the path from the sending node and the next hop. If a 501 crossed router is a legacy router not aware of the CONET IP option, 502 it will simply forward the packet looking at the IP destination 503 address. Note that a requirement for such legacy router is to be 504 configured not to drop IP packets carrying unidentified IP options. 506 4.2. Named data CONET Information Unit (Named data CIU) 508 4.2.1. Processing in the responding node 510 The responding node is the node that is able to provide a content 511 (identified by NID and Chunk Sequence Number) to a requesting end- 512 node. Therefore the responding node can be a serving node which 513 provides an original copy of the content, or a border node / 514 intermediate node that provide a cached copy of the content. The 515 responding node will use the Path State information contained in the 516 received carrier packet carrying the Interest CIU to route back the 517 carrier packets containing the named-data CIU towards the requesting 518 end-node. In particular, it will use the pointer field to read the 519 last address in the list and will use it as IP destination address 520 for the Carrier packet carrying the named-data CIU. We can denote 521 this address as "CONET previous hop". Then it will update the 522 pointer field so that the next node will use the previous address in 523 the list. It may choose to strip the used address from the list in 524 the CP Path state, thereby reducing the CP Path State field length. 526 4.2.2. Processing in a border node 528 The border node will receive an IP packet directed to itself, whose 529 IP protocol number is "CONET". Therefore the packet will be 530 internally dispatched toward the "CONET entity" in the border node. 531 The CONET entity reads the CONET information unit type from the CONET 532 IP options and recognizes that the received packet is a named-data 533 packet. Again, we stress that this processing should be performed in 534 the fast path. Being a named-data packet, the border node will read 535 the CP Path State field in the Carrier Packet and by using the 536 pointer field will identify the CONET previous hop in the path 537 towards the requesting end-node. Before sending out the packet, it 538 will update the pointer field in the CP Path State field. The 539 destination IP address of the packet will be set to the CONET 540 previous hop retrieved from the CP Path State field. If the Cache 541 indication bit in the IP option is set to "Cache", the border node 542 may choose to cache the CIU that is transported by the carried 543 packet. In this case, it is reccomended that the border node 544 dispatches the packet as soon as possible and operates on a local 545 copy to perform cache related operations. 547 4.2.3. Processing in an intermediate node 549 An intermediate node, i.e. a router in the path between a serving 550 node or a border node and the CONET previous hop, which is aware of 551 the CONET option, may decide to cache the named data CIU transported 552 by a carrier packet. The intermediate node will receive an IP packet 553 with an IP destination equal to the CONET previous hop and will 554 immediately forward this packet using IP routing. Then, if the Cache 555 indication bit in the IP option is set to "Cache", the intermediate 556 node may choose to cache the CIU that is transported by the carried 557 packet. 559 4.2.4. Processing in the legacy routers 561 When a packet is sent to the CONET previous hop (as selected by the 562 serving node or by a border node) using the IP destination address of 563 the previous hop obtained using the CP Path State information, it can 564 cross different IP routers in the path from the sending node and the 565 previous hop. If a crossed router is a legacy router not aware of 566 the CONET IP option, it will simply forward the packet looking at the 567 IP destination address. Note that a requirement for such legacy 568 router is to be configured not to drop IP packets carrying 569 unidentified IP options. 571 5. Routing by name framework 573 The routing-by-name process is performed in the end-node and in 574 border nodes in order to resolve a NID into the next hop towards a 575 serving node for the given NID. This document provides a framework 576 under which the routing-by-name procedures can be performed, and 577 assures that different routing-by-name procedures and approaches may 578 coexist. These different approaches needs to be separately 579 specified. The format and the semantic of the NID may need to be 580 specified when defining a specific routing-by-name approach. This is 581 made possible by the concept of NID name space ID, which is carried 582 within the NID. 584 The basic procedure that a routing-by-name framework needs to offer 585 is called resolveNID, it takes as input the NID and returns the 586 next_hop_address. This procedure is performed by end-nodes and by 587 border nodes that are not able to provide a cached response for a 588 content requested by an end node. 590 resolveNid (NID) -> next_hop_address 592 The tables on which the routing-by-name procedures are based are 593 populated by serving nodes and by border nodes. The procedure is 594 initiated by serving nodes that advertize the hosted content with the 595 advertizeNID procedure. In turn, the procedure is replicated by the 596 border nodes that spread the received advertising toward other border 597 nodes. This procedure takes as input a NID, the address of the node 598 performing the procedure, and the path information towards the 599 serving node as seen by the node performing the procedure. Depending 600 on the specific routing-by-name approach, the path information can be 601 simply an hop count, or it could be the path list (as in the BGP AS- 602 PATH). 604 advertizeNid (NID, node_address, path_info) 606 In the following section we define two CONET default name spaces. It 607 could be more appropriate that in future version of this document 608 this specification is provided in a separate document. 610 6. CONET default namespaces 612 We define two default NID name spaces for CONET, one is based on 613 variable length strings as NID, as it was proposed in [Jacobson09], 614 the second one is based on fixed length hashes. The two namespaces 615 are assigned the following NID name space IDs. 617 +----------------------------------------------------------------+ 618 | Namespace ID | | 619 +----------------------------------------------------------------+ 620 | 1 | VLL (Variable Length Label) NID namespace | 621 +----------------------------------------------------------------+ 622 | 2 | PLHB (Principal/Label Hash Based) NID namespace | 623 +----------------------------------------------------------------+ 625 In the VLL (Variable Length Label) CONET namespace the NID is simply 626 the string representation of a resource. As described in 627 [Jacobson09] NIDs are hierarchically structured so that an individual 628 name is composed of a number of components (see [Jacobson09] for 629 further details. An authority is needed to ensure the uniqueness of 630 the NIDs. The approach should be similar on how the uniqueness of 631 DNS names is granted in today's Internet. 633 In the Principal/Label Hash Based CONET namespace the NID is the 634 composition of two hash values, as follows: 636 NID = ( hash (Principal) , hash (Label) ) 638 In the Principal/Label Hash Based CONET namespace the Hash(principal) 639 is a 8 bytes hash of a string representing the Principal. The Label 640 is a 6 bytes hash of a string representing the label. A central 641 authority is needed to ensure the uniqueness of the Hash(principal), 642 i.e. a Principal cannot be assigned if its hash collides with an 643 already assigned hash. The Principal is responsible to ensuring that 644 each Hash(Label) belonging to the Principal are unique. Therefore a 645 Label cannot be used by a Principal if its hash collides with the 646 Hash of an already used Label. 648 7. Acknowledgments 650 We acknowledge the financial support by the EU in the context of the 651 CONVERGENCE research project. 653 8. Performance Considerations 655 IP Options have often been criticized because their support in 656 current routers would impose a performance penalty, but we can assume 657 here that routers will be modified to support Content Centric 658 Networking. Compared with "clean slate" approaches where CCN nodes 659 could be completely different with respect to routers, we believe 660 that we are able to provide all the functionality we need for Content 661 Centric Networking, with reasonable modification in router 662 architectures and preserving all the functionality of current IP 663 networking. 665 9. IANA Considerations 667 This document requires the allocation of one IP option by the IANA. 669 This document requires the allocation of one IP protocol number by 670 the IANA. 672 This document requires that IANA will maintain the registry of CONET 673 namespaces. 675 10. Security Considerations 677 Security considerations to be provided 679 11. References 681 11.1. Normative References 683 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 684 September 1981. 686 11.2. Informative References 688 [CONET11] A. Detti, et al., "CONET: A Content Centric Inter- 689 Networking Architecture", ACM SIGCOMM Workshop on 690 Information-Centric Networking (ICN-2011), Toronto, 691 Canada , August 2011. 693 [Jacobson09] 694 V. Jacobson, et al., "Networking named content", Proc. of 695 ACM CoNEXT 2009 , 2009. 697 [Koponen07] 698 T. Koponen et al., "A data-oriented (and beyond) network 699 architecture", Proc. of ACM SIGCOMM 2007 , 2007. 701 Authors' Addresses 703 Andrea Detti 704 Univ. of Rome "Tor Vergata" 705 Via del Politecnico, 1 706 Rome 00133 707 Italy 709 Email: andrea.detti@uniroma2.it 711 Stefano Salsano 712 Univ. of Rome "Tor Vergata" 713 Via del Politecnico, 1 714 Rome 00133 715 Italy 717 Email: stefano.salsano@uniroma2.it 719 Nicola Blefari-Melazzi 720 Univ. of Rome "Tor Vergata" 721 Via del Politecnico, 1 722 Rome 00133 723 Italy 725 Email: blefari@uniroma2.it