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