idnits 2.17.1 draft-detti-conet-ip-option-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 date (June 20, 2013) is 3955 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: December 22, 2013 Univ. of Rome "Tor Vergata" 6 June 20, 2013 8 IP protocol suite extensions to support CONET Information Centric 9 Networking 10 draft-detti-conet-ip-option-05 12 Abstract 14 The Information Centric Networking (ICN) paradigm shifts the focus of 15 networking from providing connections between hosts to efficiently 16 providing content to the users. The work on ICN has traditionally 17 been performed looking at "clean-slate" solutions which aims to 18 replace IP with a new paradigm. On the other hand, in this memo we 19 propose an "integration" approach to Information Centric Networking, 20 i.e. we extend the IP protocol suite by defining a new IP Protocol 21 type (CONET). Then we propose two ways of carring ICN related 22 information in IP packets, one uses a new IP Option (both for IPv4 23 and IPv6), the other one only relies on the IP payload. The ICN 24 related information is used by network nodes and end nodes to support 25 networking based on content rather than (or better in addition to) 26 end-point addresses. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 22, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. ICN information header . . . . . . . . . . . . . . . . . . . 4 64 3. CONET protocol . . . . . . . . . . . . . . . . . . . . . . . 8 65 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1. Interest CONET Information Unit (Interest CIU) . . . . . 11 67 4.1.1. Processing in the End-Node . . . . . . . . . . . . . 11 68 4.1.2. Processing in the Serving Node . . . . . . . . . . . 11 69 4.1.3. Processing in the Border Node . . . . . . . . . . . . 12 70 4.1.4. Processing in the Intermediate Node . . . . . . . . . 12 71 4.1.5. Processing in the legacy routers . . . . . . . . . . 13 72 4.2. Named data CONET Information Unit (Named data CIU) . . . 13 73 4.2.1. Processing in the responding node . . . . . . . . . . 13 74 4.2.2. Processing in a Border Node . . . . . . . . . . . . . 13 75 4.2.3. Processing in an Intermediate Node . . . . . . . . . 14 76 4.2.4. Processing in the legacy routers . . . . . . . . . . 14 77 5. Forward-by-name framework . . . . . . . . . . . . . . . . . . 14 78 6. CONET default namespaces . . . . . . . . . . . . . . . . . . 15 79 7. Two ways of carrying ICN information in IP packets . . . . . 16 80 7.1. Using CONET IP Option to carry ICN information . . . . . 16 81 7.2. IPv6 handling of CONET option . . . . . . . . . . . . . . 17 82 7.3. Comparison among the two ways . . . . . . . . . . . . . . 18 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 87 10.2. Informative References . . . . . . . . . . . . . . . . . 19 88 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 20 89 Appendix B. Document history . . . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 92 1. Introduction 94 In this memo we propose two variants of a solution to support 95 Information Centric Networking [Koponen07][Jacobson09] in IP 96 networks. The proposed solution needs a new Internet Protocol Number 97 to identify the ICN protocol (that we call CONET). The first variant 98 of the solution is based on extending the IP protocol by using a new 99 IP Option called CONET IP option (defined both for IPv4 [RFC0791] and 100 IPv6 [RFC2460]). The CONET IP option can be used by routers to 101 support content aware networking, in addition to classical address 102 based networking. The CONET IP option is used to identify the 103 content which is the object of the data transfer. Its usage allows 104 efficient in-network caching and replication of content. This 105 solution has been described in [CONET11] and was the only one 106 proposed in previous versions of this draft, up to version 04. The 107 second variant of the solution carries all ICN related information 108 within the IP payload, with no need to extend the IP protocol itself. 110 The CONET reference architecture foresees End-Nodes, Serving Nodes 111 and CONET nodes (see Figure 1). End-Nodes request for content. 112 Serving Nodes provide content. CONET nodes: i) forward content 113 requests from End-Nodes to Serving Nodes; ii) deliver content from 114 Serving Nodes to End-Nodes; iii) may cache content and therefore 115 provide it to End-Nodes without contacting the Serving Node. CONET 116 nodes can be further classified in Border Nodes and Internal nodes. 117 Border Nodes are able to perform both "forward-by-name" and caching, 118 Internal nodes are not able to perform "forward-by-name" (but only 119 plain IP routing) and can only perform caching. 121 requests for content 122 -------------------> 123 content is provided 124 <------------------- 125 +----+ +----+ +----+ 126 | | --| |------| | 127 +----+\ / +----+ +----+ 128 \ +----+ +----+ / 129 ----| |------| |/ 130 +----+ +----+ 131 End-Node legacy Intermediate Border Serving 132 IP router Node Node Node 133 | | 134 +---------CONET next hop----------->+ 135 | CONET Sub System (CCS) x | CCS y | 137 Figure 1: CONET architecture 139 As shown in Figure 1, the CONET Information Centric Network can be 140 seen as the inteconnection of CONET Sub Systems (CSSs). A CSS 141 contains CONET nodes and exploits an under-CONET technology to 142 transfer data among CONET nodes. A CSS could be: i) a couple of 143 nodes interconnected by a point-to-point link, e.g. a PPP link or a 144 UDP/IP overlay link; ii) a layer-2 network, e.g. Ethernet; iii) a 145 layer-3 network, e.g. a private/public IPv4 or IPv6 network, or a 146 whole IP Autonomous System, or even the whole current Internet. 148 2. ICN information header 150 In this section we present the information header that contains the 151 ICN related information. In the first variant of our solution, this 152 information will be carried in the IP options, while in the second 153 variant it will be included at the beginning of the IP payload. 155 The ICN information header has the following format and content: 157 +--------+--------+--------+--------+ 158 |pppLLSCr| DS&T | ICN-ID | 159 +--------+--------+--------+--------+ 160 | optional ICN-ID continuation | 161 | (variable length) ... | 162 +--------+--------+--------+--------+ 163 |CSN(opt)|optional CSN cont. ... | 164 +--------+--------+--------+--------+ 165 | optional extensions (TLV fields) | 166 +--------+--------+--------+--------+ 168 Figure 2: ICN information 170 ppp : CONET Information Unit Type - This three bits field is used to 171 differentiate between different types of CONET Information Units 172 (CIUs) 174 0 Reserved 175 1 Interest CONET Information Unit (Interest CIU) 176 2 Named-data CONET Information Unit (Named-data CIU) 177 3-7 Reserved 179 LL : ICN-ID Length Specification - This two bits field provides the 180 length of ICN Identifier (ICN-ID) field or specifies how the ICN-ID 181 length is provided. 183 0 16 bytes length 184 1 Reserved 185 2 ICN-ID field starts with a one byte length field 186 (ICN-ID length in bytes) 187 3 Reserved 189 S : Sequence number indication - This one bit field tells if a chunk 190 Sequence Number fiels is present in the Option after the ICN-ID field 192 0 No Chunk Sequence Number field is present 193 1 Chunk Sequence Number field is present after the ICN-ID field 195 C : cache indication - This one bit field is used to control cache 196 operations. 198 0 No cache 199 1 Cache 201 Within Information Units that request for content (e.g. interest 202 CIU), if the bit is set to "No cache" it indicates to the crossed 203 nodes not to look for the content in the cache, but to forward the 204 request toward the source. Within Information Units that carry 205 content (e.g. named-data CIU), if the bit is set to "No cache" it 206 indicates to the crossed nodes not to cache the content. 208 r : reserved - This one bit field in the first byte after the option 209 length is reserved. 211 DS&T : Diffserv and Type - This one byte field is used to 212 differentiate quality of services that can be provided by the network 213 to the delivered content and to identify the content type. This 214 field can be used to encode the content type and the priority as 215 follows: 217 +--------+ 218 |Fxxxxxxx| 219 +--------+ 221 +--------+ 222 |0TTTTPPP| 223 +--------+ 225 +--------+ 226 |1TTTTTTT| 227 +--------+ 229 The righmost bit can be considere as a flag F. If the flag bit F is 230 set to 0 the three rightmost bits encode 8 priority levels and other 231 4 bits are for the content-type. If the flag bit is set to one, no 232 preallocated semantic to the remaining bits is given. 234 ICN-ID : ICN Identifier (ICN-ID) field - The ICN-ID is a unique 235 identifier for the content. The ICN-ID is carried in the ICN-ID 236 field. How to determine the length of this field is defined by the 237 ICN-ID Length Specification field. If the ICN-ID Length 238 Specification field determines the field length, the ICN-ID field 239 only carries the ICN-ID. If the ICN-ID Length Specification field 240 indicates that the field length is carried in the field itself, the 241 ICN-ID field starts with a one byte field that determines its length. 243 If ICN-ID Length Specification = 0 (i.e. 16 bytes len), 244 the ICN-ID field is as follows: 246 +--------+--------+--------+--------+ 247 | ICN-ID | 248 +--------+--------+--------+--------+ 249 | | 250 +--------+--------+--------+--------+ 251 | | 252 +--------+--------+--------+--------+ 253 | | 254 +--------+--------+--------+--------+ 256 If ICN-ID Length Specification = 2 (i.e. ICN-ID starts with a one 257 byte length field), the ICN-ID field is as follows: 259 +--------+--------+--------+--------+ 260 | length | ICN-ID | 261 +--------+--------+--------+--------+ 262 | ... | 263 +--------+--------+--------+--------+ 264 | ... | 266 The ICN-ID starts with a two bytes field called ICN-ID namespace ID 267 that determines the structure of the rest of the ICN-ID. ICN-ID 268 namespace values needs to be assigned by the IANA. Note that in most 269 circumstances, the ICN-ID can be processed by the routers as an 270 opaque object, as described in Section 4. This is why the ICN-ID 271 namespace ID has been included at the beginning of the ICN-ID itself. 272 In other cases the nodes are requested to perform a forward-by-name 273 procedure, which may require a semantic understanding of the ICN-ID. 275 +--------+--------+--------+--------+ 276 | ICN-ID namesp ID| ... | 277 +--------+--------+--------+--------+ 278 | ... | 279 +--------+--------+--------+--------+ 280 | ... | 281 +--------+--------+--------+--------+ 282 | ... | 283 +--------+--------+--------+--------+ 285 CSN : Chunk Sequence Number - This optional field carries the Chunk 286 Sequence Number that identifies a portion of the content. When a 287 content is split in a sequence of smaller unit called "chunks", this 288 field can explitly carry the sequence number of the chunk (another 289 solution is obvioulsy to embed the chunk number in the ICN-ID). The 290 Chunk Sequence Number is represented with a variable number of bytes. 291 An initial bit pattern determines the length of the CSN field. 293 1 byte CSN (7 bits CSN range) 294 +--------+ 295 |0 | 296 +--------+ 298 2 bytes CSN (14 bit CSN range) 299 +--------+--------+ 300 |10 | 301 +--------+--------+ 303 3 bytes CSN (21 bit CSN range) 304 +--------+--------+--------+ 305 |110 | | | 306 +--------+--------+--------+ 308 4 bytes CSN (28 bit CSN range) 309 +--------+--------+--------+--------+ 310 |1110 | | | | 311 +--------+--------+--------+--------+ 313 5 bytes CSN (32 bit CSN range) 314 +--------+--------+--------+--------+ 315 |11110000| | | | 316 +--------+--------+--------+--------+ 317 | | 318 +--------+ 320 6 bytes CSN (40 bit CSN range) 321 +--------+--------+--------+--------+ 322 |11110001| | | | 323 +--------+--------+--------+--------+ 324 | | | 325 +--------+--------+ 327 Binary patterns from 11110010 to 11111111 are reserved. They can be 328 used to extend the CSN range if needed. With the above defined 329 option, we can have up to 2^40 chunks in a content. Assuming a 330 relatively small chunk size of 1 KBytes, it is possible to have a 331 content of 1099 TeraBytes, while assuming a more reasonable chunk 332 size of 256 Kbyte it is possible to have a content of 281474 333 TeraBytes (218 PetaBytes). 335 The rationale for having a variable length encoding is the following. 336 The CSN range for a given content is determined by the content size 337 divided by the chunk size. As content of very different sizes can be 338 transmitted, the CSN range can be very different. Therefore it is 339 not efficient to dimension this field considering the maximum number 340 of chunks in which a content can be split. 342 3. CONET protocol 344 A specific IP protocol number needs to be assigned to the CONET 345 protocol: 347 CONET IP protocol number : xxx (to be assigned by IANA). 349 The figure below shows the CONET protocol stack. CONET protocol is 350 divided in two sub-layers, whose data unit are respectively denoted 351 as "Carrier Packets" and "CONET Information Units". A CONET 352 Information Unit (CIU) can be split into different Carrier Packets. 353 Each Carrier Packet is transported by an IP packet. There are 354 different types of CONET Information Units, the CIU type information 355 is carried in the CONET Information Unit Type field in the CONET IP 356 option. 358 +--------+--------+--------+ \ 359 | CONET Information Units | | 360 +--------+--------+--------+ | 361 | 362 +--------+--------+--------+ |- CONET protocol 363 | Carrier Packets | | 364 +--------+--------+--------+ | 365 | 366 +--------+--------+--------+ / 367 | IP (opt. CONET IP option)| 368 +--------+--------+--------+ 370 Figure 3: CONET protocol layers 372 The generic structure of a Carrier Packet (CP) is reported hereafter: 374 +-------------------------+ 375 | CP Payload header | 376 +-------------------------+ 377 | CP Payload | 378 +-------------------------+ 379 | CP Path state | 380 +-------------------------+ 382 The ICN information described in the previous section can be 383 transported either in the IP Option or at the beginning of the CP 384 Payload header. The CP Payload header includes specific information 385 for each CIU type and can depend on the "transport" protocol. It 386 will be described in other specification documents. The definition 387 of a receiver driven ICN transport protocol called ICTP (Information 388 Centric Transport Protocol) is proposed in [I-D.ICTP] (see also 389 [ICTP12]). The CP payload header contains the length of the CP 390 Payload and allows to identify the start of the CP Path state field. 391 The CP Path state field can be used in End-Nodes, Border Nodes and 392 Serving Nodes to assist in the forwarding operation of carrier 393 packet, therefore it is described here. 395 The CP Path State field stores the End-Node address and the addresses 396 of the set of crossed Border Nodes in the path from End-Node to the 397 Serving Node (or to a border or Intermediate Node that provides a 398 requested content). The format of the CP path state field is 399 reported hereafter (assuming that IPv4 addresses are carried). The 400 use of CP Path state is optional, as the path from End-Node to 401 Serving Node can be stored in the so called PIT (Pending Interest 402 Table) in the crossed nodes [Jacobson09]. A node crossed by an 403 Interest packet can either add its address to the CP Path State (and 404 create the CP Path State field if not present) or store the pending 405 interest in the PIT. 407 CP Path State field 409 +--------+--------+--------+--------+ 410 |0 len | pointer| ad-type| addr 1 | 411 +--------+--------+--------+--------+ 412 | addr 2 | addr 3 | addr 4 | ad-type| 413 +--------+--------+--------+--------+ 414 | addr 1 | addr 2 | addr 3 | addr 4 | 415 +--------+--------+--------+--------+ 416 | ... | 417 +--------+--------+--------+--------+ 419 +--------+--------+--------+--------+ 420 |1 len | pointer | 421 +--------+--------+--------+--------+ 422 | ad-type| addr 1 | addr 2 | addr 3 | 423 +--------+--------+--------+--------+ 424 | addr 4 | ad-type| addr 1 | addr 2 | 425 +--------+--------+--------+--------+ 426 | addr 3 | addr 4 | 427 +--------+--------+ 429 The length field specifies the length of the CP Path State field in 430 bytes. If the first bit of the len field is 0, the remaining 7 bits 431 of the first byte are used as len field and both the length field and 432 the pointer field are one byte length. In this case the maximum 433 value of the length of the CP Path State field is 127. If the first 434 bit of the len field is 1, both the length field and the pointer 435 field are two bytes length. In this case the maximum value of the 436 length of the CP Path State field is 32767. 438 The pointer field specifies the offset, starting from the start of 439 the CP Path State field where the last address has been inserted. 441 Each address is represented as a couple (ad-type, address) it could 442 be represented by a triple (ad-type, ad-length, address) if the 443 address type is of variable length. The ad-type field is one byte 444 size and currently admitted values are: 446 0 Reserved 447 1 Public IPv4 address (len is 4 bytes, no ad-length needed) 448 2 Public Ipv6 address (len is 16 bytes, no ad-length needed)) 449 3 Ethernet address (len is 6 bytes, no ad-length needed)) 450 4-255 Reserved 452 4. Procedures 454 4.1. Interest CONET Information Unit (Interest CIU) 456 4.1.1. Processing in the End-Node 458 An end-node that wants to retrieve a content (or better a Chunk of a 459 content) issues an Interest CIU, the ICN-ID and the Chunk Sequence 460 Number of the required Content are respectively transported in the 461 ICN Identifier (ICN-ID) field and in the CSN field of the ICN 462 information header. The end-node stores its IP address in CP path 463 state field, initializing the pointer field. Assuming for simplicity 464 that the Interest CIU will fit into a single Carrier Packet, the 465 Interest CIU will be included in the Carrier Packet that in turn is 466 inserted into an IP packet. 468 The end-node must now determine the destination IP address for the 469 Carrier Packet. The end-node performs a forward-by-name operation, 470 trying to associate the ICN-ID with a next hop (i.e. with the IP 471 address of the next hop). The next hop can be the Serving Node (if 472 the Serving Node is in the same CONET Sub System of the end-node) or 473 a Border Node of the CONET Sub System (if the Serving Node is in a 474 different CONET Sub System). Typically the End-Node does not 475 participate to the content routing protocols, therefore it cannot 476 resolve the ICN-ID into the address of the next hop, but it has to 477 ask an external entity, behaving in a similar way of a current name 478 server (such external entity could be a part of a system that handles 479 the content routing, called Routing Name System). Once this 480 information is retrieved, the end-note can fill the IP destination 481 address in the IP header and sends the packet. The end-node may 482 cache the mapping (ICN-ID -> next hop) into its memory as well. 484 4.1.2. Processing in the Serving Node 486 If the Serving Node is in the same CONET than the end-node, the 487 Serving Node IP address will be used a destination IP address by the 488 end-node. The Serving Node will receive an IP packet directed to 489 itself, whose IP protocol number is "CONET". Therefore the packet 490 will be internally dispatched toward the "CONET entity" in the 491 Serving Node. The CONET entity reads the CONET information unit type 492 from the CONET IP options and recognizes that the received packet is 493 an interest packet. Then it reads the ICN-ID and Chunk Sequence 494 Number in the ICN information header, the ICN-ID will correspond to a 495 content provided by the Serving Node. The CONET entity will then 496 process the CONET transport protocol information carried in the IP 497 payload, which may for example specify a requested offset within the 498 chunk. Finally the CONET entity will respond to the interest packet 499 by sending the requested named-data CIU. 501 4.1.3. Processing in the Border Node 503 If the Serving Node is in a different CONET Sub System than the end- 504 node, the address of a CONET Border Node will be used a destination 505 IP address by the end-node. The Border Node will receive an IP 506 packet directed to itself, whose IP protocol number is "CONET". 507 Therefore the packet will be internally dispatched toward the "CONET 508 entity" in the Border Node. The CONET entity reads the CONET 509 information unit type from the ICN information header and recognizes 510 that the received packet is an interest packet. Then it reads the 511 ICN-ID and Chunk Sequence Number in the ICN information header and is 512 able to understand which content and which part of the available 513 content it needs to provide. If the Cache indication field is set to 514 "No Cache" or if the field is set to "Cache" but the chunk is not 515 available in the cache, the Border Node starts the forward-by-name 516 process. It will resolve the next hop of the interest packet, which 517 can be a Serving Node in a different CONET Sub System (with respect 518 to the one from which the interest packet was received) connected to 519 the Border Node, or another Border Node in the path toward the 520 Serving Node. Before sending out the packet, the Border Node adds 521 its IP address in the CP Path State field and updates the pointer 522 field. Note that these procedures needs to be performed in the "fast 523 path" of the Border Node (in this case the CONET entity in the Border 524 Node can be seen as an integral part of the enhanced IP protocol). 525 If the Cache indication field is set to "Cache" and the Border Node 526 has found that the chunk corresponding to the ICN-ID/CSN is available 527 in its cache, the Border Node will process the CONET transport 528 protocol information carried in the IP payload, which may for example 529 specify a requested offset within the chunk and it will respond to 530 the interest packet by sending the requested named-data CIU. 532 4.1.4. Processing in the Intermediate Node 534 When a packet is sent to the CONET next hop (as selected by the End- 535 Node or by a Border Node) using the IP destination address of the 536 next hop resolved by the forward-by-name, it can cross different IP 537 routers in the path from the sending node and the next hop. A 538 crossed router that is aware of the ICN information header, is a 539 CONET Intermediate Node. This node may have cached the the chunk 540 that is requested by the interest packet. The Intermediate Node 541 works as follows. When processing the IP header for the received 542 packet, it finds that the packet contains the CONET IP protocol. If 543 the Cache indication field is set to "No Cache", the Intermediate 544 Node forwards the packet using the destination IP address. If the 545 Cache indication field is set to "Cache", the Intermediate Node 546 checks the presence of the chunk in its cache before forwarding the 547 IP packet. Therefore, it reads the ICN-ID and Chunk Sequence Number 548 in the ICN information header and checks if the chunk is present in 549 its cache. If the chunk is not present, the normal IP processing is 550 continued. Note that these operations needs to be performed in the 551 "fast path" of the router and they only require information that is 552 transported in the IP option. If the chunk is present in the CONET 553 router cache, the router will process the CONET transport protocol 554 information carried in the IP payload, which may for example specify 555 a requested offset within the chunk and it will respond to the 556 interest packet by sending the requested named-data CIU. 558 4.1.5. Processing in the legacy routers 560 When a packet is sent to the CONET next hop (as selected by the End- 561 Node or by a Border Node) using the IP destination address of the 562 next hop resolved by the forward-by-name, it can cross different IP 563 routers in the path from the sending node and the next hop. If a 564 crossed router is a legacy router not aware of the CONET protocol, it 565 will simply forward the packet looking at the IP destination address. 566 If the ICN information header is carried in the IP Option, a 567 requirement for such legacy router is to be configured not to drop IP 568 packets carrying unidentified IP options. 570 4.2. Named data CONET Information Unit (Named data CIU) 572 4.2.1. Processing in the responding node 574 The responding node is the node that is able to provide a content 575 (identified by ICN-ID and Chunk Sequence Number) to a requesting end- 576 node. Therefore the responding node can be a Serving Node which 577 provides an original copy of the content, or a Border Node / 578 Intermediate Node that provide a cached copy of the content. The 579 responding node will use the Path State information contained in the 580 received carrier packet carrying the Interest CIU to forward back the 581 carrier packets containing the named-data CIU towards the requesting 582 end-node. In particular, it will use the pointer field to read the 583 last address in the list and will use it as IP destination address 584 for the Carrier packet carrying the named-data CIU. We can denote 585 this address as "CONET previous hop". Then it will update the 586 pointer field so that the next node will use the previous address in 587 the list. It may choose to strip the used address from the list in 588 the CP Path state, thereby reducing the CP Path State field length. 590 4.2.2. Processing in a Border Node 592 The Border Node will receive an IP packet directed to itself, whose 593 IP protocol number is "CONET". Therefore the packet will be 594 internally dispatched toward the "CONET entity" in the Border Node. 595 The CONET entity reads the CONET information unit type from the ICN 596 information header and recognizes that the received packet is a 597 named-data packet. Again, we stress that this processing should be 598 performed in the fast path. Being a named-data packet, the Border 599 Node will read the CP Path State field in the Carrier Packet and by 600 using the pointer field will identify the CONET previous hop in the 601 path towards the requesting end-node. Before sending out the packet, 602 it will update the pointer field in the CP Path State field. The 603 destination IP address of the packet will be set to the CONET 604 previous hop retrieved from the CP Path State field. If the Cache 605 indication bit in the IP option is set to "Cache", the Border Node 606 may choose to cache the CIU that is transported by the carried 607 packet. In this case, it is reccomended that the Border Node 608 dispatches the packet as soon as possible and operates on a local 609 copy to perform cache related operations. 611 4.2.3. Processing in an Intermediate Node 613 An Intermediate Node, i.e. a router in the path between a Serving 614 Node or a Border Node and the CONET previous hop, which is aware of 615 the CONET option, may decide to cache the named data CIU transported 616 by a carrier packet. The Intermediate Node will receive an IP packet 617 with an IP destination equal to the CONET previous hop and will 618 immediately forward this packet using IP routing. Then, if the Cache 619 indication bit in the IP option is set to "Cache", the Intermediate 620 Node may choose to cache the CIU that is transported by the carried 621 packet. 623 4.2.4. Processing in the legacy routers 625 When a packet is sent to the CONET previous hop (as selected by the 626 Serving Node or by a Border Node) using the IP destination address of 627 the previous hop obtained using the CP Path State information, it can 628 cross different IP routers in the path from the sending node and the 629 previous hop. If a crossed router is a legacy router not aware of 630 the CONET IP protocol, it will simply forward the packet looking at 631 the IP destination address. If the ICN information header is carried 632 in the IP Option, a requirement for such legacy router is to be 633 configured not to drop IP packets carrying unidentified IP options. 635 5. Forward-by-name framework 637 The forward-by-name process is performed in the end-node and in 638 Border Nodes in order to resolve a ICN-ID into the next hop towards a 639 Serving Node for the given ICN-ID. This document provides a 640 framework under which the forward-by-name procedures can be 641 performed, and assures that different forward-by-name procedures and 642 approaches may coexist. These different approaches needs to be 643 separately specified. The format and the semantic of the ICN-ID may 644 need to be specified when defining a specific forward-by-name 645 approach. This is made possible by the concept of ICN-ID name space 646 ID, which is carried within the ICN-ID. 648 The basic procedure that a forward-by-name framework needs to offer 649 is called resolveICN-ID, it takes as input the ICN-ID and returns the 650 next_hop_address. This procedure is performed by end-nodes and by 651 Border Nodes that are not able to provide a cached response for a 652 content requested by an End-Node. 654 resolveICN-ID (ICN-ID) -> next_hop_address 656 The tables on which the forward-by-name procedures are based are 657 populated by Serving Nodes and by Border Nodes. The procedure is 658 initiated by Serving Nodes that advertize the hosted content with the 659 advertizeICN-ID procedure. In turn, the procedure is replicated by 660 the Border Nodes that spread the received advertising toward other 661 Border Nodes. This procedure takes as input a ICN-ID, the address of 662 the node performing the procedure, and the path information towards 663 the Serving Node as seen by the node performing the procedure. 664 Depending on the specific content routing approach, the path 665 information can be simply an hop count, or it could be the path list 666 (as in the BGP AS-PATH). 668 advertizeICN-ID (ICN-ID, node_address, path_info) 670 In the following section we define two CONET default name spaces. It 671 could be more appropriate that in future version of this document 672 this specification is provided in a separate document. 674 6. CONET default namespaces 676 We define two default ICN-ID name spaces for CONET, one is based on 677 variable length strings as ICN-ID, as it was proposed in 678 [Jacobson09], the second one is based on fixed length hashes. The 679 two namespaces are assigned the following ICN-ID name space IDs. 681 +----------------------------------------------------------------+ 682 | Namespace ID | | 683 +----------------------------------------------------------------+ 684 | 1 | VLL (Variable Length Label) ICN-ID namespace | 685 +----------------------------------------------------------------+ 686 | 2 | PLHB (Principal/Label Hash Based) ICN-ID namesp.| 687 +----------------------------------------------------------------+ 688 In the VLL (Variable Length Label) CONET namespace the ICN-ID is 689 simply the string representation of a resource. As described in 690 [Jacobson09] ICN-IDs are hierarchically structured so that an 691 individual name is composed of a number of components (see 692 [Jacobson09] for further details. An authority is needed to ensure 693 the uniqueness of the ICN-IDs. The approach should be similar on how 694 the uniqueness of DNS names is granted in today's Internet. 696 In the Principal/Label Hash Based CONET namespace the ICN-ID is the 697 composition of two hash values, as follows: 699 ICN-ID = ( hash (Principal) , hash (Label) ) 701 In the Principal/Label Hash Based CONET namespace the Hash(principal) 702 is a 8 bytes hash of a string representing the Principal. The Label 703 is a 6 bytes hash of a string representing the label. A central 704 authority is needed to ensure the uniqueness of the Hash(principal), 705 i.e. a Principal cannot be assigned if its hash collides with an 706 already assigned hash. The Principal is responsible to ensuring that 707 each Hash(Label) belonging to the Principal are unique. Therefore a 708 Label cannot be used by a Principal if its hash collides with the 709 Hash of an already used Label. 711 7. Two ways of carrying ICN information in IP packets 713 Two ways of carrying the ICN information in IP packets have been 714 considered. The first way introduces new IP Options to be included 715 in IPv4 and IPv6 headers, the second option simply includes the ICN 716 information header at the beginning of the CP payload header, that is 717 within the IP payload. Hereafter, the details related to the 718 definition and use of the IP Options are given, then the two ways are 719 compared. 721 7.1. Using CONET IP Option to carry ICN information 723 The CONET IPv4 option has the following format: 725 +--------+--------+--------+--------+ 726 |100xxxxx|yyyyyyyy|pppLLSCr| DS&T | 727 +--------+--------+--------+--------+ 728 | ICN-ID (variable length) | 729 | ... | 730 +--------+--------+--------+--------+ 731 |CSN(opt)|optional CSN cont. ... | 732 +--------+--------+--------+--------+ 733 | optional extensions (TLV fields) | 734 +--------+--------+--------+--------+ 735 Figure 4: CONET IP Option for IPv4 737 The CONET IPv6 option has the following format: 739 +--------+--------+--------+--------+ 740 |001xxxxx|yyyyyyyy|pppLLSCr| DS&T | 741 +--------+--------+--------+--------+ 742 | ICN-ID (variable length) | 743 | ... | 744 +--------+--------+--------+--------+ 745 |CSN(opt)|optional CSN cont. ... | 746 +--------+--------+--------+--------+ 747 | optional extensions (TLV fields) | 748 +--------+--------+--------+--------+ 750 Figure 5: CONET IP Option for IPv6 752 For IPv4 the first byte (the option type) is as follows: 754 Type: 755 Copied flag: 1 (all fragments must carry the option) 756 Option class: 0 (control) 757 Option number: xxxxx (decimal) TO BE ALLOCATED BY IANA 759 For IPv6 the first byte (the option tyep) is as follows: 761 Type: 762 Unrecognized option action : 00 763 (skip option, process the rest of the header) 764 Change allowed flag : 0 765 (option data cannot change while the datagram is en route) 766 Option number: xxxxx (decimal) TO BE ALLOCATED BY IANA 768 Length: 769 yyyyyyyy: variable length of IP option in bytes (including the 770 Type and Length bytes 772 7.2. IPv6 handling of CONET option 774 The IPv6 CONET option has to be interpreted by all routers in the 775 path that are ICN capable. Therefore we it naturally fits into the 776 the IPv6 Hop-by-hop header, which is the first extension header that 777 can be present after the fixed part of the header. The Hop-by-hop 778 header is meant to be read by all routers in the path. 780 7.3. Comparison among the two ways 782 If the IP Option is used, a CONET ICN packet can be identified by the 783 presence of the IP option. Otherwise, it has to be identified by 784 looking at the IP Protocol type information in the IP header. 786 The first advantage of the solution based on IP options is 787 conceptual: it allows an ICN Node to take routing decision by 788 considering the information contained in the layer 3 (IP) header. 789 Moreover, is a packet gets fragmented at IP level, each fragment 790 keeps the IP Option in its IP header, allowing the processing of the 791 single fragments at ICN level. The disadvantages are: legacy IP 792 nodes could have some problems with unrecognized IP options 793 (experiencing higher processing times or even dropping such packets); 794 a more complex implementation in end nodes, as it requires changes in 795 the IP layer. In [CONET11] we investigated (with practical 796 experiments on PlanetLab) how our unrecognized IP option is handled 797 by current routers in the Internet. In the large majority of tests 798 it was possible to add unrecognized options and achieve end-to-end 799 CONET connectivity among arbitrary PlanetLab nodes, while in few 800 cases some routers in the path have dropped the packets. IP Options 801 have often been criticized because their support in current routers 802 would impose a performance penalty, but may be we can assume here 803 that routers will be modified to support Information Centric 804 Networking so this performance issue may not be critical. 806 The advantages of the other approach (not using the IP options) are 807 complementary: the implementation in terminals is simpler and legacy 808 IP nodes are not affected by the ICN information carried in the IP 809 payload. A disadvantage of this solution is that when IP packets 810 gets fragmented, the IP fragments loose the ICN information header. 811 Strictly speaking, a node operating in this approach is not just a 812 router, as it is using layer 4 information to process the packets so 813 it can be seen as a middlebox [RFC3234] capable of performing ICN 814 routing (and caching) functionality. This disadvantage is not 815 critical in nodes that are in any case capable of operating with 816 transport layer information (e.g. a node with an SDN/OpenFlow 817 architecture [ICN-SDN13]). 819 8. IANA Considerations 821 This document requires the allocation of one IP protocol number by 822 the IANA. 824 This document requires the allocation of one IP option by the IANA if 825 the solution of using IP options is adopted 826 This document requires that IANA will maintain the registry of CONET 827 namespaces. 829 9. Security Considerations 831 Security considerations to be provided 833 10. References 835 10.1. Normative References 837 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 838 1981. 840 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 841 (IPv6) Specification", RFC 2460, December 1998. 843 10.2. Informative References 845 [CONET11] A. Detti, et al., ., "CONET: A Content Centric Inter- 846 Networking Architecture", ACM SIGCOMM Workshop on 847 Information-Centric Networking (ICN-2011), Toronto, Canada 848 , August 2011. 850 [I-D.ICTP] 851 Salsano, S., Detti, A., Blefari-Melazzi, N., and M. 852 Cancellieri, "ICTP - Information Centric Transport 853 Protocol for CONET ICN", draft-salsano-ictp-02 (work in 854 progress), June 2012. 856 [ICN-SDN13] 857 Blefari-Melazzi, N., Detti, A., Morbito, G., Salsano, S., 858 and L. Veltri, "Information Centric Networking over SDN 859 and OpenFlow: Architectural Aspects and Experiments on the 860 OFELIA Testbed", conditionally accepted (minor revisions) 861 to Elsevier Computer Networks special issue on 862 Information-Centric Networking - arXiv preprint 863 arXiv:1301.5933 , 2013. 865 [ICTP12] S. Salsano, et al., ., "Transport-layer issues in 866 Information Centric Networks", ACM SIGCOMM Workshop on 867 Information-Centric Networking (ICN-2012), Helsinki, 868 Finland , August 2012. 870 [Jacobson09] 871 V. Jacobson, et al., ., "Networking named content", Proc. 872 of ACM CoNEXT 2009 , 2009. 874 [Koponen07] 875 T. Koponen et al., ., "A data-oriented (and beyond) 876 network architecture", Proc. of ACM SIGCOMM 2007 , 2007. 878 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 879 Issues", RFC 3234, February 2002. 881 Appendix A. Acknowledgments 883 We acknowledge the financial support by the EU in the context of the 884 CONVERGENCE and OFELIA research projects 886 Appendix B. Document history 888 draft-detti-conet-ip-option-05 890 o new title "IP protocol suite extensions to support CONET 891 Information Centric Networking" 893 o added the generic ICN information header and a second variant of 894 the solution not using the IP Option 896 draft-detti-conet-ip-option-03 898 o new title "IPv4 and IPv6 Options to support Information Centric 899 Networking" 901 o added IPv6 support with IPv6 Option 903 Authors' Addresses 905 Andrea Detti 906 Univ. of Rome "Tor Vergata" 907 Via del Politecnico, 1 908 Rome 00133 909 Italy 911 Email: andrea.detti@uniroma2.it 913 Stefano Salsano 914 Univ. of Rome "Tor Vergata" 915 Via del Politecnico, 1 916 Rome 00133 917 Italy 919 Email: stefano.salsano@uniroma2.it 920 Nicola Blefari-Melazzi 921 Univ. of Rome "Tor Vergata" 922 Via del Politecnico, 1 923 Rome 00133 924 Italy 926 Email: blefari@uniroma2.it