idnits 2.17.1 draft-irtf-icnrg-ipoc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (January 31, 2020) is 1540 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5268 (Obsoleted by RFC 5568) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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: August 3, 2020 Tennessee Tech University 6 C. Fan 7 Colorado State University 8 January 31, 2020 10 Internet Protocol Tunneling over Content Centric Mobile Networks 11 draft-irtf-icnrg-ipoc-01 13 Abstract 15 This document describes a protocol that enables tunneling of Internet 16 Protocol traffic over a Content Centric Network (CCNx) or a Named 17 Data Network (NDN). The target use case for such a protocol is to 18 provide an IP mobility plane for mobile networks that might otherwise 19 use IP-over-IP tunneling, such as the GPRS Tunneling Protocol (GTP) 20 used by the Evolved Packet Core in LTE networks (LTE-EPC). By 21 leveraging the elegant, built-in support for mobility provided by 22 CCNx or NDN, this protocol achieves performance on par with LTE-EPC, 23 equivalent efficiency, and substantially lower implementation and 24 protocol complexity [Shannigrahi]. Furthermore, the use of CCNx/NDN 25 for this purpose paves the way for the deployment of ICN native 26 applications on the mobile network. 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 https://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 August 3, 2020. 45 Copyright Notice 47 Copyright (c) 2020 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 (https://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. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 64 3. CCNx Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. IPoC Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Use of Interest Payloads . . . . . . . . . . . . . . . . 5 67 5. Client Interest Table and Interest Deficit Report . . . . . . 6 68 6. Handling PIT Entry Lifetimes . . . . . . . . . . . . . . . . 7 69 7. Managing the CIT, PIT lifetimes and the in-flight message 70 count . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8. Establishing Communication . . . . . . . . . . . . . . . . . 9 72 9. IPoC Naming Conventions . . . . . . . . . . . . . . . . . . . 9 73 10. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 10 74 11. Packet Sequencer . . . . . . . . . . . . . . . . . . . . . . 10 75 11.1. Packet Sequencer Example Algorithm . . . . . . . . . . . 11 76 12. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 77 13. Gateway Behavior . . . . . . . . . . . . . . . . . . . . . . 12 78 14. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 16.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 16.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 Content Centric Networking (such as CCNx or NDN, though CCNx is used 88 for the rest of the document) provides some key advantages over IP 89 networking that make it attractive as a replacement for IP for 90 wireless networking. In particular, by employing stateful 91 forwarding, CCNx elegantly supports information retrieval by mobile 92 client devices without the need for tunneling or a location 93 registration protocol. Furthermore, CCNx supports a client device 94 utilizing multiple network attachments (e.g. multiple radio links) 95 simultaneously in order to provide greater reliability or greater 96 performance. Finally, CCNx is optimized for content retrieval, where 97 content can be easily retrieved from an on-path cache. 99 From an incremental deployment perspective, it may be attractive to 100 consider supporting CCNx as an overlay, i.e. tunneled over an IP- 101 based mobile core network. But doing so diminishes the value that 102 the CCNx protocol could provide, for example by limiting the ability 103 to utilize on-path caching, native mobility and multiple network 104 attachments. Ultimately, a more powerful approach, one that retains 105 these benefits, is to utilize CCNx as a replacement for IP and IP- 106 over-IP tunneling as the mobility plane for the mobile network. 108 A significant hurdle that stands in the way of deploying a CCNx-only 109 wireless network is that all of the applications in use today (both 110 client and server) are built to use IP. 112 This hurdle could be addressed by requiring that all applications be 113 rewritten to use CCNx natively, however, this is a tall order in a 114 world with millions of smartphone apps. Another approach could be to 115 deploy a hybrid network in which the routers support forwarding both 116 IP and CCNx. However, this adds cost and complexity to the network, 117 both in the equipment and in operations. 119 The protocol described in this document provides a way to eliminate 120 this hurdle, by establishing an IP over CCNx tunneling protocol that 121 is transparent to the IP applications on either end. In a sense, 122 this protocol replaces the IP-over-GTP tunnels or IP-over-GRE tunnels 123 that would exist in a traditional IP-based wireless network such as 124 LTE or Community WiFi, but by using a networking plane (CCNx) that 125 natively supports mobility, application developers have the option to 126 update their applications to run directly over CCNx, gaining all of 127 the advantages that come with this new protocol. 129 IPoC supports IP mobility within a domain in a manner similar to that 130 supported by LTE-EPC, i.e. the mobile node utilizes an IP address 131 associated with the mobile network to which it is connected, and a 132 stationary gateway device (P-GW in the case of LTE-EPC, IPoC Gateway 133 in the case of IPoC) takes care of forwarding IP packets to the 134 mobile node via the mobile network. [Shannigrahi] compares IPoC to 135 GTP from the perspective of complexity and performance. Other 136 mobility solutions, such as MIPv6 [RFC3775] exist that aim for a 137 broader definition of IP mobility, and support efficient routing even 138 when the mobile device retains an IP address that is not associated 139 with the network to which it is connected. However, all these 140 solutions still inherit the shortcomings of IP networking for 141 mobility - for example, handover latency and packet loss are known 142 problems with MIPv6 [RFC5268]. 144 This protocol specification does not currently address support for IP 145 multicast connectivity. Support can be achieved via unicast 146 forwarding of IP multicast packets to group members. Other 147 approaches that take CCNx features (such as multicast forwarding 148 strategy and caching) into account could help improve efficiency for 149 IP multicast connectivity. 151 2. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 3. CCNx Overview 159 In the CCNx protocol, communication is achieved by an application 160 sending an Interest packet that identifies, by name, a piece of 161 content that it wishes to receive. The network routes Interest 162 messages toward a producer of content corresponding to the name in 163 the Interest, leaving a "breadcrumb" trail of state in the routers 164 along that path. Once the Interest arrives at a node where the named 165 piece of content is present, that node returns a Content Object 166 message containing the named piece of content. The Content Object 167 follows (and consumes) the breadcrumb trail back to the originating 168 application. This process is commonly referred to as stateful 169 forwarding. An application that only sends Interest messages is 170 referred to as a consumer, whereas an application that only sends 171 Content Object messages (in response to Interests) is referred to as 172 a producer. 174 Producers need to advertise the name prefixes for the content that 175 they can provide, and this information needs to propagate to the 176 routers of the network, much in the same way that IP prefixes need to 177 propagate to routers in an IP network. However, consumers don't need 178 to advertise their presence or location at all, they can simply send 179 Interest messages from wherever they are in the network, and the 180 resulting Content Objects will make it back to them via the stateful 181 forwarding process. Furthermore, a consumer that is mobile can 182 redirect data in flight to the its new location by resending Interest 183 messages for those in-flight content objects using its new network 184 attachment point. As a result, mobile consumer applications (which 185 would be the majority of mobile applications) are handled very 186 elegantly by the CCNx protocol. 188 In addition, if a mobile device has multiple network attachment 189 points, e.g. both a WiFi and a 5G/LTE connection, it can choose to 190 send Interests via both of those network paths. This capability can 191 be used to enable higher capacity (by load balancing the Interests in 192 an attempt to fully utilize multiple links simultaneously), higher 193 reliability (by sending each Interest on multiple links), or seamless 194 handover (by switching to a new link for all future Interest 195 messages, while still waiting to receive Content Objects on an older 196 link). 198 4. IPoC Overview 200 While consumer mobility and multipath connectivity is elegantly 201 handled by the CCNx protocol, producer mobility (where a mobile 202 device makes its resident content available to outside devices), is 203 currently not. As a result, the IPoC protocol relies solely on 204 consumer behavior on the client device. 206 This protocol defines two entities: an IPoC Client and an IPoC 207 Gateway. The IPoC Client (henceforth referred to as the Client) 208 would exist on the mobile device, and as mentioned above, only sends 209 Interest messages. The IPoC Gateway (henceforth referred to as the 210 Gateway) exists at a fixed location in the network, and publishes a 211 prefix that can be routed to via the CCNx network. In general, a 212 network may have many Clients, and possibly several Gateways. 214 The switches and routers that exist in the path between the Client(s) 215 and the Gateway(s) are assumed to provide CCNx forwarding, and are 216 not required to support IP forwarding. 218 From the perspective of the IP applications running on the mobile 219 device, the Client implementation functions as a tunnel endpoint, 220 much in the same way that a VPN application does. All IP packets 221 generated by applications on the mobile device are forwarded via this 222 tunnel endpoint, which encapsulates them in CCNx Interest messages, 223 and then sends them into the CCNx network. Similarly, the Gateway 224 implementation also acts as a tunnel endpoint, in this case on an IP 225 routing node. It receives Interest messages, unpacks the IP packets 226 inside, and forwards them into an IP network. IP return traffic 227 arriving at the Gateway is encapsulated into CCNx Content Object 228 messages, and then launched into the CCNx network to follow the 229 stateful forwarding path left by the associated Interest message. 231 4.1. Use of Interest Payloads 233 As described above, IPoC capitalizes on the consumer mobility 234 features of CCNx, and as a result uses the optional interest payload 235 mechanism described in the "Consumer Behavior" section of [RFC8569]. 237 This behavior preserves the basic hop-by-hop flow balancing principle 238 of ICN, in that intermediate routers can control traffic flow by 239 delaying Interest messages as appropriate. Additionally, the 240 interest payload allows transport of information in Interests outside 241 of the name field, which can significantly reduce router complexity 242 (memory and memory bandwidth), as the name field is stored in the 243 router's Pending Interest Table. 245 5. Client Interest Table and Interest Deficit Report 247 In this communication model, the Client is able to send "upstream" 248 packets at any time, by sending Interest messages. The Gateway on 249 the other hand, can only send "downstream" packets when it has a 250 pending Interest (i.e. it has received an Interest message and has 251 not yet responded with an associated Content Object). As a result, 252 the Client and Gateway work together to ensure that the Gateway is 253 receiving Interests sufficiently to support the downstream 254 communication. 256 For each Client, the Gateway MUST maintain a FIFO queue of names for 257 which it has received Interests from the Client. This queue is 258 referred to as the Client Interest Table (CIT). As this is a FIFO 259 queue, the order in which Interest names are received is the order in 260 which the associated Content Object responses will be sent. 262 The typical behavior of a Client (described in more detail below) is 263 to send an Interest message for every Content Object it receives, 264 thus maintaining a constant number of CCNx packets "in flight". The 265 Interest Deficit Report (IDR) is a message element sent in a Content 266 Object from the Gateway to the Client in order to adjust the number 267 of packets in flight and thus maintain an appropriate CIT size. The 268 IDR can take the value +1, to request an increase (by one) of the in- 269 flight count; 0 to indicate no change to the in-flight count; or -1 270 to request a decrease (by one) of the in-flight count. The IDR can 271 be included in a Content Object that carries a packet payload, or in 272 a Content Object that is otherwise empty. 274 The IDR is an unacknowledged message element, and as such is an 275 inherently unreliable communication. Since the IDR values are small, 276 the impact of a Content Object loss is minimal. 278 The Client MUST maintain an Interest Deficit Count (IDC) which it 279 uses to maintain the in-flight count in response to sent Interests 280 and received Content Objects. The Client MUST decrement by one the 281 IDC upon transmission of a new Interest message. The Client MUST 282 update the IDC by adding IDR+1 to its value upon receipt of a new 283 Content Object. 285 The Gateway SHOULD NOT discard Interest names from the CIT, and thus 286 SHOULD always respond to a received Interest with a Content Object in 287 order to clear the associated PIT state in the intermediate routers. 288 If a new Interest arrives and the CIT is full, the gateway MUST 289 consume the name at the head of the CIT by sending an empty content 290 object. In this case, the IDR value of the empty Content Object 291 SHOULD be set to -1. 293 6. Handling PIT Entry Lifetimes 295 Intermediate routers between the Client and the gateway, as well as 296 CCNx forwarder implementations within the two IPoC endpoints will 297 store PIT entries for the Client's Interests for a finite lifetime, 298 and will age-out (purge) Interests that exceed that lifetime. Since 299 the CIT at the gateway stores Interest names for a time in 300 anticipation of downstream packets, it would be possible, when there 301 is a gap in the flow of downstream packets, that the name at the head 302 of the CIT queue is associated with entries that have been aged-out 303 of the PIT in one or more of the intermediate forwarders. If the 304 gateway were to use this aged-out name in an attempt to deliver a 305 downstream packet, the packet transmission would fail when the 306 Content Object arrived at the PIT that no longer held an entry for 307 this name. 309 To avoid this situation, the Gateway MUST record the arrival time of 310 each CIT entry, and compare it against a CIT lifetime value. When 311 the CIT entry at the head of the CIT "expires", the gateway MUST send 312 a Content Object using that CIT entry, thereby cleaning up the PIT 313 state in the intervening forwarders, and potentially triggering a new 314 Interest to be sent by the Client (as discussed further below). 316 7. Managing the CIT, PIT lifetimes and the in-flight message count 318 At any instant in time, a certain number of Interest names can be 319 considered "in-flight" from the Client's perspective (these in-flight 320 Interests correspond to the entries in the Client's PIT). Some 321 fraction of the in-flight Interest names will correspond to Interest 322 messages (possibly containing IP packets) that are in transit to the 323 gateway, some fraction will correspond to Content Object messages 324 (also possibly containing IP packets) that are in transit to the 325 Client, and the remainder correspond to the entries in the gateway's 326 CIT or to messages that were lost in transit. The gateway controls 327 the number of these in-flight messages via the IDR, which can either 328 trigger or suppress the Client sending Interests. 330 Since the gateway cannot send a downstream packet to the Client 331 unless it has a CIT entry, it would ideally like to ensure that it 332 always has at least one CIT entry every time a downstream packet 333 arrives. However, due to the round trip time between the gateway and 334 the Client, and the fluctuation of downstream and upstream packet 335 arrival rates, the number of in-transit messages (Interests or 336 Content Objects) will fluctuate. If the only goal was that the CIT 337 never becomes empty, the gateway could simply use the IDR to build a 338 very high in-flight message count. This would ensure that the CIT 339 never drains completely, even in the case where the upstream path and 340 the downstream path are both saturated with in-transit messages. The 341 problem with this approach is that when the connection becomes idle, 342 ALL of the in-flight messages would then exist in the CIT, which 343 could be a large memory burden on the gateway and on the PIT in each 344 intervening router. Furthermore, since each of these CIT entries has 345 a certain lifetime, driven by the PIT lifetime, they will shortly 346 expire, triggering the gateway to transmit Content Objects that 347 heavily utilize the downstream and upstream links for approximately 348 one RTT. This pattern of unnecessary network traffic would then 349 periodically repeat at a period equal to the CIT lifetime. 351 So, it is important that the gateway adjust the in-flight message 352 count continuously, to minimize the times that the CIT is starved or 353 flooded. 355 The gateway MUST establish a target minimum value for the number of 356 CIT entries. This value "n" provides a bound on the number of 357 downstream packets that can be sent in the first IPoC RTT (between 358 gateway and client) after an idle period, and also establishes the 359 quiescent IPoC message refresh rate during idle periods (this rate r 360 = n/L, where L is the CIT lifetime). Selecting a low value of n 361 minimizes the quiescent load on the network, but has the downside of 362 reducing the size of packet burst that the IPoC connection can handle 363 with low latency. 365 Whenever the gateway sends a Content Object and there are fewer than 366 n CIT entries, it MUST include an IDR in the CO, with the value 1, 367 triggering the Client to send two Interest messages in response to 368 the CO. 370 The gateway also MUST establish a maximum CIT size "N". Whenever the 371 gateway receives a new Interest while the CIT contains N entries, it 372 MUST make room for the new CIT entry by using the head of line CIT 373 entry to send an empty Content Object containing an IDR with the 374 value -1, triggering the Client to suppress sending an Interest in 375 response. 377 Further, whenever the CIT entry at the head of line expires (reaches 378 its CIT lifetime), the Gateway MUST consume that CIT entry by sending 379 an empty Content Object. The expiration of a CIT entry is a good 380 indication that the CIT contains more entries than are needed to 381 support the current data rate. In this situation, the Gateway SHOULD 382 use the IDR to reduce the in-flight count. One mechanism for doing 383 this is described here: 385 If the number of CIT entries is less than n, the empty Content Object 386 sent to consume the expiring CIT entry will contain an IDR with the 387 value 1. If the number of CIT entries is greater than n, the CO will 388 contain an IDR with value -1, and if it is equal to n, the value 0. 389 The result of this process is that during idle periods, the CIT will 390 drain down to the point of having n entries, and will refresh those 391 entries as they expire. 393 8. Establishing Communication 395 Communication is established by the Client sending an Interest to a 396 Gateway, where the name in the Interest message includes a Gateway 397 prefix followed by /init/. For example, if the 398 established Gateway prefix is ccnx:/ipoc, the name might be 399 ccnx:/ipoc/init/2Fhwte2452g5shH4. The Gateway has a process that 400 will respond to the ccnx:/ipoc/init prefix by sending IP 401 configuration information, similar to the information contained in a 402 DHCP Offer, including an assigned IP address. 404 Upon configuring itself using the information in the init response, 405 the Client can begin IP communication. The naming convention for 406 subsequent Interest messages is described in the next section. 408 9. IPoC Naming Conventions 410 The IPoC protocol doesn't assign any relationship between the 411 Interest / Content Object names and the contents of the encapsulated 412 IP packets. Rather, the name only identifies the Client instance of 413 the IPoC application, and provides a sequence number that 414 disambiguates Interests and Content Objects and provides for in-order 415 delivery of IP packets. 417 The Client and Gateway can use one of the following data naming 418 conventions, the appropriate naming convention is chosen by the 419 Gateway via configuration, and is communicated to the Client during 420 the Establishing Communication protocol. 422 ccnx:/ipoc// 424 ccnx:/ipoc/// 426 The various components of an IPoC name are described in more detail 427 below: 429 o ccnx:/ipoc - The name prefix used in all IPoC messages 431 o zone_id - An optional zone identifier to allow for zone-based IP 432 address re-use. 434 o hex_ipaddr - For IPv4 addresses, this field comprises 4 separate 435 name segments, each representing a single octet of an IPv4 address 436 encoded as a hexadecimal string. For example, a message from a 437 Client with IPv4 address 192.0.2.100 would use: "c0/00/02/64" for 438 this name component. For IPv6 addresses, the textual convention 439 defined in Section 2.2 paragraph 1 of [RFC4291] is used, with each 440 colon replaced by a CCNx name segment delimiter. For example a 441 Client with the IPv6 address: 2001:DB8::fe21:67cf would use 442 "2001/DB8/0/0/0/0/fe21/67cf" for this name component. 444 o b64_seq - This a base64-encoded value representing the Upstream 445 Sequence Number for this upstream Interest message 447 An example Interest name is: ccnx:/ipoc/c0/00/02/64/AAAAGw== 449 10. Sequence Numbers 451 Upstream Sequence Numbers (USN) are monotonically increasing unsigned 452 32-bit integer values embedded in the Interest names to indicate the 453 proper ordering for upstream data packets. Since Interest messages 454 may arrive out-of-order due to the use of multiple network paths, the 455 Gateway uses the USN to ensure that upstream IP packets are delivered 456 in the proper order. 458 Content Objects that carry IP packet payloads include Downstream 459 Sequence Numbers (DSN), which are monotonically increasing unsigned 460 32-bit integer values that indicate the proper ordering of downstream 461 data packets. DSN are used by the Client to ensure that downstream 462 IP packets are delivered in the proper order. 464 The USN and DSN are independent sequence numbers and thus have no 465 relationship to one another. 467 11. Packet Sequencer 469 The Packet Sequencer (PS or Sequencer) is a FIFO queue that exists 470 both at the Client and Gateway to ensure in-order delivery of IP 471 packets contained in upstream Interests and downstream Content 472 Objects. The order in which the packets are delivered is decided by 473 the Packet Sequence Number (PSN) embedded in the Interest or Content 474 Object names. 476 The client MUST implement a Packet Sequencer to ensure in-order 477 delivery of IP packets. The gateway MUST implement a Packet 478 Sequencer to ensure in-order delivery of IP packets. 480 11.1. Packet Sequencer Example Algorithm 482 The first PSN (FPSN) delivered to the Sequencer establishes a 483 baseline to which all subsequent PSNs are evaluated based on an 484 expected ascending incremental order. The Sequencer also notes the 485 last PSN (LPSN) it forwarded, and for the first packet, FPSN is equal 486 to LPSN. If an arriving packet has the expected sequence number 487 (LPSN + 1), the sequencer does not queue the packet and simply 488 forwards it. The Sequencer also tracks the highest sequence number 489 that has arrived (MAXPSN). 491 Discontinuities in the sequence order result in a "gap" in the 492 sequence. If the arriving packet has a sequence number LPSN + n, 493 where n > 1, we declare this as a gap. For example, if the last 494 forwarded PSN had a sequence number 6 (LPSN), and a new packet 495 arrives with sequence number 10 (MAXPSN), a new gap is created which 496 represents the sequence numbers 7, 8, and 9. A timer with a validity 497 window is started providing a limited amount of time for the sequence 498 numbers in the gap to arrive. 500 Each time a packet with a sequence number in the gap arrives, the 501 Sequencer tries to do a partial release of the queue; this releases 502 any consecutive packets between LPSN and MAXPSN. In our example, if 503 sequence 8 arrives first, the Sequencer sees there are no consecutive 504 packets to send and does nothing. If sequence 7 arrives after that, 505 the Sequencer releases both 7 and 8 but waits for sequence 9. When 506 sequence 9 arrives, it releases 9 and 10. If a packet does not 507 arrive and the validity window expires, the Sequencer releases all 508 packets up to MAXPSN and reset the LPSN. 510 The sequencer removes data packets from the queue in sequence-order 511 (lowest PSN first). If the queue exceeds capacity, the Sequencer 512 discards the packet with the lowest PSN. Any IP packets in those 513 Interests or content objects are discarded. 515 Ideally, the gap validity window should be set to the RTT between the 516 Client and the Gateway. However, since packets can take multiple 517 paths and the Sequencer may not know the RTT for each of these paths, 518 it should dynamically adjust the validity window based on the inter- 519 arrival time between consecutive packets. 521 12. Client Behavior 523 The three main functions of the Client are: 525 1. Send Interest messages containing upstream IP packets whenever 526 they arrive 528 2. Send Interest messages to the gateway in order to keep the 529 appropriate in-flight count 531 3. Receive downstream IP packet data in Content Object messages 533 Content Object messages containing downstream IP packet data are 534 added to the Packet Sequencer and then forwarded to the IP stack on 535 the device. 537 Once an IP address is acquired using the initialization process 538 described above, the startup sequence for a particular Client looks 539 like this: 541 o Initialize IDC to a startup value: INIT_IDC. 543 o Send Interest messages to the Gateway containing the initial 544 upstream IP packets (e.g. TCP SYN packets or DNS queries), 545 decrementing IDC for each Interest sent. 547 The client MUST decrement the IDC upon transmission of any Interest 548 message, whether or not it contains an upstream packet. 550 Whenever the client receives a Content Object, it MUST increment the 551 IDC by IDR+1 to ensure that the appropriate in-flight count is 552 maintained. 554 The Client MUST maintain two internal timer intervals. A short timer 555 (T0) is used to pace Interest messages when there are outstanding 556 interests to be sent as per the Interest Deficit Counter. The long 557 timer (T1) is used as a keep-alive when the Client has no outstanding 558 Interests to be sent. Whenever the client sends an Interest message, 559 it restarts the T0 and T1 timers. When the T0 timer expires, if the 560 IDC is greater than zero, the Client MUST send an empty Interest 561 message. When the T1 timer expires, the Client MUST send an empty 562 Interest message (regardless of the IDC value). 564 13. Gateway Behavior 566 IPoC gateway behavior is slightly more complex since it must manage 567 connections with multiple Clients simultaneously. The standard 568 process for on-boarding a new Client looks something like this: 570 o An Interest is received with the /init/ name. 572 o The gateway establishes new CIT (and other Client-specific) 573 structures for this Client and responds with a Content Object 574 containing the IP parameters (yiaddr, giaddr, etc.) to configure 575 the Client's IP stack. 577 o The gateway enters a normal processing loop in which it receives 578 Interests from the Client and responds with Content Objects. 580 Interests received from the Client may contain IP packets that the 581 gateway will add to its upstream Packet Sequencer using the PSN found 582 in the Interest name. The Interest name will then be added the 583 Client-specific CIT for later use in creating Content Objects. If 584 the CIT is full, the gateway will immediately send an empty Content 585 Object back to the Client, removing the first name from the CIT, and 586 therefore making room for the new name to be added. 588 When downstream IP packets become available, the gateway will remove 589 the first name from the CIT queue and use it to create a Content 590 Object containing the IP packets. If the CIT is empty, IP packets 591 are buffered by the gateway. 593 If IP packets are waiting in buffer when a new Interest (CIT entry) 594 arrives, the gateway will immediately dequeue the waiting packets (up 595 to a maximum CO size limit), form and transmit a Content Object using 596 the newly arrived CIT name. 598 14. Security Considerations 600 This protocol is designed for use within a trusted domain (i.e. a 601 mobile core network). This protocol definition does not address 602 authentication between clients and gateway devices, nor does it 603 address privacy of communications (beyond that already provided by 604 the IP applications themselves). The CCNx protocol does provide for 605 Interest message and Content Object message authentication (signing) 606 [RFC8609], which can be utilized if desired. 608 15. IANA Considerations 610 This document has no actions for IANA. 612 16. References 613 16.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, 617 DOI 10.17487/RFC2119, March 1997, 618 . 620 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 621 in IPv6", RFC 3775, DOI 10.17487/RFC3775, June 2004, 622 . 624 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 625 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 626 2006, . 628 [RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, 629 DOI 10.17487/RFC5268, June 2008, 630 . 632 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 633 Networking (CCNx) Semantics", RFC 8569, 634 DOI 10.17487/RFC8569, July 2019, 635 . 637 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 638 Networking (CCNx) Messages in TLV Format", RFC 8609, 639 DOI 10.17487/RFC8609, July 2019, 640 . 642 16.2. Informative References 644 [Shannigrahi] 645 Shannigrahi, S., Fan, C., and G. White, "Bridging the ICN 646 Deployment Gap with IPoC: An IP-over-ICN protocol for 5G 647 Networks", SIGCOMM NEAT Workshop , August 2018, 648 . 650 Authors' Addresses 652 Greg White 653 CableLabs 654 858 Coal Creek Circle 655 Louisville, CO 80027 656 US 658 Email: g.white@cablelabs.com 659 Susmit Shannigrahi 660 Tennessee Tech University 661 Computer Sc. Dept. 662 Cookeville, TN 38501 663 US 665 Email: sshannigrahi@tntech.edu 667 Chengyu Fan 668 Colorado State University 669 Computer Sc. Dept. 670 1100 Center Ave Mall 671 Ft. Collins, CO 80523 672 US 674 Email: chengyu.fan@colostate.edu