idnits 2.17.1 draft-irtf-icnrg-ipoc-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([Shannigrahi]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2, 2019) is 1730 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC8609' is defined on line 590, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG G. White 3 Internet-Draft CableLabs 4 Intended status: Experimental S. Shannigrahi 5 Expires: February 3, 2020 C. Fan 6 Colorado State University 7 August 2, 2019 9 Internet Protocol Tunneling over Content Centric Mobile Networks 10 draft-irtf-icnrg-ipoc-00 12 Abstract 14 This document describes a protocol that enables tunneling of Internet 15 Protocol traffic over a Content Centric Network (CCN) or a Named Data 16 Network (NDN). The target use case for such a protocol is to provide 17 an IP mobility plane for mobile networks that might otherwise use IP- 18 over-IP tunneling, such as the GPRS Tunneling Protocol (GTP) used by 19 the Evolved Packet Core in LTE networks (LTE-EPC). By leveraging the 20 elegant, built-in support for mobility provided by CCN or NDN, this 21 protocol achieves performance on par with LTE-EPC, equivalent 22 efficiency, and substantially lower implementation and protocol 23 complexity [Shannigrahi]. Furthermore, the use of CCN/NDN for this 24 purpose paves the way for the deployment of ICN native applications 25 on the mobile network. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 3, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 63 3. CCN/NDN Overview . . . . . . . . . . . . . . . . . . . . . . 3 64 4. IPoC Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. Use of Interest Payloads . . . . . . . . . . . . . . . . 5 66 5. Client Interest Table and Interest Deficit Report . . . . . . 5 67 6. Handling PIT Entry Lifetimes . . . . . . . . . . . . . . . . 6 68 7. Managing the CIT, PIT lifetimes and the in-flight message 69 count . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8. Establishing Communication . . . . . . . . . . . . . . . . . 8 71 9. IPoC Naming Conventions . . . . . . . . . . . . . . . . . . . 8 72 10. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 9 73 11. Packet Sequencer . . . . . . . . . . . . . . . . . . . . . . 10 74 11.1. Packet Sequencer Example Algorithm . . . . . . . . . . . 10 75 12. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 76 13. Gateway Behavior . . . . . . . . . . . . . . . . . . . . . . 12 77 14. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 16.1. Normative References . . . . . . . . . . . . . . . . . . 13 81 16.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 Content Centric Networking provides some key advantages over IP 87 networking that make it attractive as a replacement for IP for 88 wireless networking. In particular, by employing stateful 89 forwarding, CCN elegantly supports information retrieval by mobile 90 client devices without the need for tunneling or a location 91 registration protocol. Furthermore, CCN supports a client device 92 utilizing multiple network attachments (e.g. multiple radio links) 93 simultaneously in order to provide greater reliability or greater 94 performance. Finally, CCN is optimized for content retrieval, where 95 content can be easily retrieved from an on-path cache. 97 A significant hurdle that stands in the way of deploying a CCN-only 98 wireless network is that all of the applications in use today (both 99 client and server) are built to use IP. 101 This hurdle could be addressed by requiring that all applications be 102 rewritten to use CCN natively, however, this is a tall order in a 103 world with millions of smartphone apps. Another approach could be to 104 deploy a hybrid network in which the routers support forwarding both 105 IP and CCN. However, this adds cost and complexity to the network, 106 both in the equipment and in operations. 108 The protocol described in this document provides a way to eliminate 109 this hurdle, by establishing an IP over CCN tunneling protocol that 110 is transparent to the IP applications on either end. In a sense, 111 this protocol replaces the IP-over-GTP tunnels or IP-over-GRE tunnels 112 that would exist in a traditional IP-based wireless network such as 113 LTE or Community WiFi, but by using a networking plane (CCN) that 114 natively supports mobility, application developers have the option to 115 update their applications to run directly over CCN, gaining all of 116 the advantages that come with this new protocol. 118 2. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 3. CCN/NDN Overview 126 In the CCN (or NDN) protocol, communication is achieved by an 127 application sending an Interest packet that identifies, by name, a 128 piece of content that it wishes to receive. The network routes 129 Interest messages toward a producer of content corresponding to the 130 name in the Interest, leaving a "breadcrumb" trail of state in the 131 routers along that path. Once the Interest arrives at a node where 132 the named piece of content is present, that node returns a Content 133 Object message containing the named piece of content. The Content 134 Object follows (and consumes) the breadcrumb trail back to the 135 originating application. This process is commonly referred to as 136 stateful forwarding. An application that only sends Interest 137 messages is referred to as a consumer, whereas an application that 138 only sends Content Object messages (in response to Interests) is 139 referred to as a producer. 141 Producers need to advertise the name prefixes for the content that 142 they can provide, and this information needs to propagate to the 143 routers of the network, much in the same way that IP prefixes need to 144 propagate to routers in an IP network. However, consumers don't need 145 to advertise their presence or location at all, they can simply send 146 Interest messages from wherever they are in the network, and the 147 resulting Content Objects will make it back to them via the stateful 148 forwarding process. Furthermore, a consumer that is mobile can 149 redirect data in flight to the its new location by resending Interest 150 messages for those in-flight content objects using its new network 151 attachment point. As a result, mobile consumer applications (which 152 would be the majority of mobile applications) are handled very 153 elegantly by the CCN protocol. 155 In addition, if a mobile device has multiple network attachment 156 points, e.g. both a WiFi and a 5G/LTE connection, it can choose to 157 send Interests via both of those network paths. This capability can 158 be used to enable higher capacity (by load balancing the Interests in 159 an attempt to fully utilize multiple links simultaneously), higher 160 reliability (by sending each Interest on multiple links), or seamless 161 handover (by switching to a new link for all future Interest 162 messages, while still waiting to receive Content Objects on an older 163 link). 165 4. IPoC Overview 167 While consumer mobility and multipath connectivity is elegantly 168 handled by the CCN protocol, producer mobility (where a mobile device 169 makes its resident content available to outside devices), is 170 currently not. As a result, the IPoC protocol relies solely on 171 consumer behavior on the client device. 173 This protocol defines two entities: an IPoC Client and an IPoC 174 Gateway. The IPoC Client (henceforth referred to as the Client) 175 would exist on the mobile device, and as mentioned above, only sends 176 Interest messages. The IPoC Gateway (henceforth referred to as the 177 Gateway) exists at a fixed location in the network, and publishes a 178 prefix that can be routed to via the CCN network. In general, a 179 network may have many Clients, and possibly several Gateways. 181 The switches and routers that exist in the path between the Client(s) 182 and the Gateway(s) are assumed to provide CCN forwarding, and are not 183 required to support IP forwarding. 185 From the perspective of the IP applications running on the mobile 186 device, the Client implementation functions as a tunnel endpoint, 187 much in the same way that a VPN application does. All IP packets 188 generated by applications on the mobile device are forwarded via this 189 tunnel endpoint, which encapsulates them in CCN Interest messages, 190 and then sends them into the CCN network. Similarly, the Gateway 191 implementation also acts as a tunnel endpoint, in this case on an IP 192 routing node. It receives Interest messages, unpacks the IP packets 193 inside, and forwards them into an IP network. IP return traffic 194 arriving at the Gateway is encapsulated into CCN Content Object 195 messages, and then launched into the CCN network to follow the 196 stateful forwarding path left by the associated Interest message. 198 4.1. Use of Interest Payloads 200 As described above, IPoC capitalizes on the consumer mobility 201 features of CCN, and as a result uses the optional interest payload 202 mechanism described in the "Consumer Behavior" section of [RFC8569]. 203 This behavior preserves the basic hop-by-hop flow balancing principle 204 of ICN, in that intermediate routers can control traffic flow by 205 delaying Interest messages as appropriate. Additionally, the 206 interest payload allows transport of information in Interests outside 207 of the name field, which can significantly reduce router complexity 208 (memory and memory bandwidth), as the name field is stored in the 209 router's Pending Interest Table. 211 5. Client Interest Table and Interest Deficit Report 213 In this communication model, the Client is able to send "upstream" 214 packets at any time, by sending Interest messages. The Gateway on 215 the other hand, can only send "downstream" packets when it has a 216 pending Interest (i.e. it has received an Interest message and has 217 not yet responded with an associated Content Object). As a result, 218 the Client and Gateway work together to ensure that the Gateway is 219 receiving Interests sufficiently to support the downstream 220 communication. 222 For each Client, the Gateway MUST maintain a FIFO queue of names for 223 which it has received Interests from the Client. This queue is 224 referred to as the Client Interest Table (CIT). As this is a FIFO 225 queue, the order in which Interest names are received is the order in 226 which the associated Content Object responses will be sent. 228 The typical behavior of a Client (described in more detail below) is 229 to send an Interest message for every Content Object it receives, 230 thus maintaining a constant number of CCN packets "in flight". The 231 Interest Deficit Report (IDR) is a message element sent in a Content 232 Object from the Gateway to the Client in order to adjust the number 233 of packets in flight and thus maintain an appropriate CIT size. The 234 IDR can take the value +1, to request an increase (by one) of the in- 235 flight count; 0 to indicate no change to the in-flight count; or -1 236 to request a decrease (by one) of the in-flight count. The IDR can 237 be included in a Content Object that carries a packet payload, or in 238 a Content Object that is otherwise empty. 240 The IDR is an unacknowledged message element, and as such is an 241 inherently unreliable communication. Since the IDR values are small, 242 the impact of a Content Object loss is minimal. 244 The Client MUST maintain an Interest Deficit Count (IDC) which it 245 uses to maintain the in-flight count in response to sent Interests 246 and received Content Objects. The Client MUST decrement by one the 247 IDC upon transmission of a new Interest message. The Client MUST 248 update the IDC by adding IDR+1 to its value upon receipt of a new 249 Content Object. 251 The Gateway SHOULD NOT discard Interest names from the CIT, and thus 252 SHOULD always respond to a received Interest with a Content Object in 253 order to clear the associated PIT state in the intermediate routers. 254 If a new Interest arrives and the CIT is full, the gateway MUST 255 consume the name at the head of the CIT by sending an empty content 256 object. In this case, the IDR value of the empty Content Object 257 SHOULD be set to -1. 259 6. Handling PIT Entry Lifetimes 261 Intermediate routers between the Client and the gateway, as well as 262 CCN forwarder implementations within the two IPoC endpoints will 263 store PIT entries for the Client's Interests for a finite lifetime, 264 and will age-out (purge) Interests that exceed that lifetime. Since 265 the CIT at the gateway stores Interest names for a time in 266 anticipation of downstream packets, it would be possible, when there 267 is a gap in the flow of downstream packets, that the name at the head 268 of the CIT queue is associated with entries that have been aged-out 269 of the PIT in one or more of the intermediate forwarders. If the 270 gateway were to use this aged-out name in an attempt to deliver a 271 downstream packet, the packet transmission would fail when the 272 Content Object arrived at the PIT that no longer held an entry for 273 this name. 275 To avoid this situation, the Gateway MUST record the arrival time of 276 each CIT entry, and compare it against a CIT lifetime value. When 277 the CIT entry at the head of the CIT "expires", the gateway MUST send 278 a Content Object using that CIT entry, thereby cleaning up the PIT 279 state in the intervening forwarders, and potentially triggering a new 280 Interest to be sent by the Client (as discussed further below). 282 7. Managing the CIT, PIT lifetimes and the in-flight message count 284 At any instant in time, a certain number of Interest names can be 285 considered "in-flight" from the Client's perspective (these in-flight 286 Interests correspond to the entries in the Client's PIT). Some 287 fraction of the in-flight Interest names will correspond to Interest 288 messages (possibly containing IP packets) that are in transit to the 289 gateway, some fraction will correspond to Content Object messages 290 (also possibly containing IP packets) that are in transit to the 291 Client, and the remainder correspond to the entries in the gateway's 292 CIT or to messages that were lost in transit. The gateway controls 293 the number of these in-flight messages via the IDR, which can either 294 trigger or suppress the Client sending Interests. 296 Since the gateway cannot send a downstream packet to the Client 297 unless it has a CIT entry, it would ideally like to ensure that it 298 always has at least one CIT entry every time a downstream packet 299 arrives. However, due to the round trip time between the gateway and 300 the Client, and the fluctuation of downstream and upstream packet 301 arrival rates, the number of in-transit messages (Interests or 302 Content Objects) will fluctuate. If the only goal was that the CIT 303 never becomes empty, the gateway could simply use the IDR to build a 304 very high in-flight message count. This would ensure that the CIT 305 never drains completely, even in the case where the upstream path and 306 the downstream path are both saturated with in-transit messages. The 307 problem with this approach is that when the connection becomes idle, 308 ALL of the in-flight messages would then exist in the CIT, which 309 could be a large memory burden on the gateway and on the PIT in each 310 intervening router. Furthermore, since each of these CIT entries has 311 a certain lifetime, driven by the PIT lifetime, they will shortly 312 expire, triggering the gateway to transmit Content Objects that 313 heavily utilize the downstream and upstream links for approximately 314 one RTT. This pattern of unnecessary network traffic would then 315 periodically repeat at a period equal to the CIT lifetime. 317 So, it is important that the gateway adjust the in-flight message 318 count continuously, to minimize the times that the CIT is starved or 319 flooded. 321 The gateway MUST establish a target minimum value for the number of 322 CIT entries. This value "n" provides a bound on the number of 323 downstream packets that can be sent in the first IPoC RTT (between 324 gateway and client) after an idle period, and also establishes the 325 quiescent IPoC message refresh rate during idle periods (this rate r 326 = n/L, where L is the CIT lifetime). Selecting a low value of n 327 minimizes the quiescent load on the network, but has the downside of 328 reducing the size of packet burst that the IPoC connection can handle 329 with low latency. 331 Whenever the gateway sends a Content Object and there are fewer than 332 n CIT entries, it MUST include an IDR in the CO, with the value 1, 333 triggering the Client to send two Interest messages in response to 334 the CO. 336 The gateway also MUST establish a maximum CIT size "N". Whenever the 337 gateway receives a new Interest while the CIT contains N entries, it 338 MUST make room for the new CIT entry by using the head of line CIT 339 entry to send an empty Content Object containing an IDR with the 340 value -1, triggering the Client to suppress sending an Interest in 341 response. 343 Further, whenever the CIT entry at the head of line expires (reaches 344 its CIT lifetime), the Gateway MUST consume that CIT entry by sending 345 an empty Content Object. The expiration of a CIT entry is a good 346 indication that the CIT contains more entries than are needed to 347 support the current data rate. In this situation, the Gateway SHOULD 348 use the IDR to reduce the in-flight count. One mechanism for doing 349 this is described here: 351 If the number of CIT entries is less than n, the empty Content Object 352 sent to consume the expiring CIT entry will contain an IDR with the 353 value 1. If the number of CIT entries is greater than n, the CO will 354 contain an IDR with value -1, and if it is equal to n, the value 0. 355 The result of this process is that during idle periods, the CIT will 356 drain down to the point of having n entries, and will refresh those 357 entries as they expire. 359 8. Establishing Communication 361 Communication is established by the Client sending an Interest to a 362 Gateway, where the name in the Interest message includes a Gateway 363 prefix followed by /init/. For example, if the 364 established Gateway prefix is ccnx:/ipoc, the name might be 365 ccnx:/ipoc/init/2Fhwte2452g5shH4. The Gateway has a process that 366 will respond to the ccnx:/ipoc/init prefix by sending IP 367 configuration information, similar to the information contained in a 368 DHCP Offer, including an assigned IP address. 370 Upon configuring itself using the information in the init response, 371 the Client can begin IP communication. The naming convention for 372 subsequent Interest messages is described in the next section. 374 9. IPoC Naming Conventions 376 The IPoC protocol doesn't assign any relationship between the 377 Interest / Content Object names and the contents of the encapsulated 378 IP packets. Rather, the name only identifies the Client instance of 379 the IPoC application, and provides a sequence number that 380 disambiguates Interests and Content Objects and provides for in-order 381 delivery of IP packets. 383 The Client and Gateway can use one of the following data naming 384 conventions, the appropriate naming convention is chosen by the 385 Gateway via configuration, and is communicated to the Client during 386 the Establishing Communication protocol. 388 ccnx:/ipoc// 390 ccnx:/ipoc/// 392 The various components of an IPoC name are described in more detail 393 below: 395 o ccnx:/ipoc - The name prefix used in all IPoC messages 397 o zone_id - An optional zone identifier to allow for zone-based IP 398 address re-use. 400 o hex_ipaddr - For IPv4 addresses, this field comprises 4 separate 401 name segments, each representing a single octet of an IPv4 address 402 encoded as a hexadecimal string. For example, a message from a 403 Client with IPv4 address 192.0.2.100 would use: "c0/00/02/64" for 404 this name component. For IPv6 addresses, the textual convention 405 defined in Section 2.2 paragraph 1 of [RFC4291] is used, with each 406 colon replaced by a CCN name segment delimiter. For example a 407 Client with the IPv6 address: 2001:DB8::fe21:67cf would use 408 "2001/DB8/0/0/0/0/fe21/67cf" for this name component. 410 o b64_seq - This a base64-encoded value representing the Upstream 411 Sequence Number for this upstream Interest message 413 An example Interest name is: ccnx:/ipoc/c0/00/02/64/AAAAGw== 415 10. Sequence Numbers 417 Upstream Sequence Numbers (USN) are monotonically increasing unsigned 418 32-bit integer values embedded in the Interest names to indicate the 419 proper ordering for upstream data packets. Since Interest messages 420 may arrive out-of-order due to the use of multiple network paths, the 421 Gateway uses the USN to ensure that upstream IP packets are delivered 422 in the proper order. 424 Content Objects that carry IP packet payloads include Downstream 425 Sequence Numbers (DSN), which are monotonically increasing unsigned 426 32-bit integer values that indicate the proper ordering of downstream 427 data packets. DSN are used by the Client to ensure that downstream 428 IP packets are delivered in the proper order. 430 The USN and DSN are independent sequence numbers and thus have no 431 relationship to one another. 433 11. Packet Sequencer 435 The Packet Sequencer (PS or Sequencer) is a FIFO queue that exists 436 both at the Client and Gateway to ensure in-order delivery of IP 437 packets contained in upstream Interests and downstream Content 438 Objects. The order in which the packets are delivered is decided by 439 the Packet Sequence Number (PSN) embedded in the Interest or Content 440 Object names. 442 The client MUST implement a Packet Sequencer to ensure in-order 443 delivery of IP packets. The gateway MUST implement a Packet 444 Sequencer to ensure in-order delivery of IP packets. 446 11.1. Packet Sequencer Example Algorithm 448 The first PSN (FPSN) delivered to the Sequencer establishes a 449 baseline to which all subsequent PSNs are evaluated based on an 450 expected ascending incremental order. The Sequencer also notes the 451 last PSN (LPSN) it forwarded, and for the first packet, FPSN is equal 452 to LPSN. If an arriving packet has the expected sequence number 453 (LPSN + 1), the sequencer does not queue the packet and simply 454 forwards it. The Sequencer also tracks the highest sequence number 455 that has arrived (MAXPSN). 457 Discontinuities in the sequence order result in a "gap" in the 458 sequence. If the arriving packet has a sequence number LPSN + n, 459 where n > 1, we declare this as a gap. For example, if the last 460 forwarded PSN had a sequence number 6 (LPSN), and a new packet 461 arrives with sequence number 10 (MAXPSN), a new gap is created which 462 represents the sequence numbers 7, 8, and 9. A timer with a validity 463 window is started providing a limited amount of time for the sequence 464 numbers in the gap to arrive. 466 Each time a packet with a sequence number in the gap arrives, the 467 Sequencer tries to do a partial release of the queue; this releases 468 any consecutive packets between LPSN and MAXPSN. In our example, if 469 sequence 8 arrives first, the Sequencer sees there are no consecutive 470 packets to send and does nothing. If sequence 7 arrives after that, 471 the Sequencer releases both 7 and 8 but waits for sequence 9. When 472 sequence 9 arrives, it releases 9 and 10. If a packet does not 473 arrive and the validity window expires, the Sequencer releases all 474 packets up to MAXPSN and reset the LPSN. 476 The sequencer removes data packets from the queue in sequence-order 477 (lowest PSN first). If the queue exceeds capacity, the Sequencer 478 discards the packet with the lowest PSN. Any IP packets in those 479 Interests or content objects are discarded. 481 Ideally, the gap validity window should be set to the RTT between the 482 Client and the Gateway. However, since packets can take multiple 483 paths and the Sequencer may not know the RTT for each of these paths, 484 it should dynamically adjust the validity window based on the inter- 485 arrival time between consecutive packets. 487 12. Client Behavior 489 The three main functions of the Client are: 491 1. Send Interest messages containing upstream IP packets whenever 492 they arrive 494 2. Send Interest messages to the gateway in order to keep the 495 appropriate in-flight count 497 3. Receive downstream IP packet data in Content Object messages 499 Content Object messages containing downstream IP packet data are 500 added to the Packet Sequencer and then forwarded to the IP stack on 501 the device. 503 Once an IP address is acquired using the initialization process 504 described above, the startup sequence for a particular Client looks 505 like this: 507 o Initialize IDC to a startup value: INIT_IDC. 509 o Send Interest messages to the Gateway containing the initial 510 upstream IP packets (e.g. TCP SYN packets or DNS queries), 511 decrementing IDC for each Interest sent. 513 The client MUST decrement the IDC upon transmission of any Interest 514 message, whether or not it contains an upstream packet. 516 Whenever the client receives a Content Object, it MUST increment the 517 IDC by IDR+1 to ensure that the appropriate in-flight count is 518 maintained. 520 The Client MUST maintain two internal timer intervals. A short timer 521 (T0) is used to pace Interest messages when there are outstanding 522 interests to be sent as per the Interest Deficit Counter. The long 523 timer (T1) is used as a keep-alive when the Client has no outstanding 524 Interests to be sent. Whenever the client sends an Interest message, 525 it restarts the T0 and T1 timers. When the T0 timer expires, if the 526 IDC is greater than zero, the Client MUST send an empty Interest 527 message. When the T1 timer expires, the Client MUST send an empty 528 Interest message (regardless of the IDC value). 530 13. Gateway Behavior 532 IPoC gateway behavior is slightly more complex since it must manage 533 connections with multiple Clients simultaneously. The standard 534 process for on-boarding a new Client looks something like this: 536 o An Interest is received with the /init/ name. 538 o The gateway establishes new CIT (and other Client-specific) 539 structures for this Client and responds with a Content Object 540 containing the IP parameters (yiaddr, giaddr, etc.) to configure 541 the Client's IP stack. 543 o The gateway enters a normal processing loop in which it receives 544 Interests from the Client and responds with Content Objects. 546 Interests received from the Client may contain IP packets that the 547 gateway will add to its upstream Packet Sequencer using the PSN found 548 in the Interest name. The Interest name will then be added the 549 Client-specific CIT for later use in creating Content Objects. If 550 the CIT is full, the gateway will immediately send an empty Content 551 Object back to the Client, removing the first name from the CIT, and 552 therefore making room for the new name to be added. 554 When downstream IP packets become available, the gateway will remove 555 the first name from the CIT queue and use it to create a Content 556 Object containing the IP packets. If the CIT is empty, IP packets 557 are buffered by the gateway. 559 If IP packets are waiting in buffer when a new Interest (CIT entry) 560 arrives, the gateway will immediately dequeue the waiting packets (up 561 to a maximum CO size limit), form and transmit a Content Object using 562 the newly arrived CIT name. 564 14. Security Considerations 566 TBD. 568 15. IANA Considerations 570 This document has no actions for IANA. 572 16. References 574 16.1. Normative References 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, 578 DOI 10.17487/RFC2119, March 1997, 579 . 581 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 582 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 583 2006, . 585 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 586 Networking (CCNx) Semantics", RFC 8569, 587 DOI 10.17487/RFC8569, July 2019, 588 . 590 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 591 Networking (CCNx) Messages in TLV Format", RFC 8609, 592 DOI 10.17487/RFC8609, July 2019, 593 . 595 16.2. Informative References 597 [Shannigrahi] 598 Shannigrahi, S., Fan, C., and G. White, "Bridging the ICN 599 Deployment Gap with IPoC: An IP-over-ICN protocol for 5G 600 Networks", SIGCOMM NEAT Workshop , August 2018, 601 . 603 Authors' Addresses 605 Greg White 606 CableLabs 607 858 Coal Creek Circle 608 Louisville, CO 80027 609 US 611 Email: g.white@cablelabs.com 612 Susmit Shannigrahi 613 Colorado State University 614 Computer Sc. Dept. 615 1100 Center Ave Mall 616 Ft. Collins, CO 80523 617 US 619 Email: susmit.shannigrahi@gmail.com 621 Chengyu Fan 622 Colorado State University 623 Computer Sc. Dept. 624 1100 Center Ave Mall 625 Ft. Collins, CO 80523 626 US 628 Email: chengyu.fan@colostate.edu