< draft-white-icnrg-ipoc-01.txt   draft-white-icnrg-ipoc-02.txt >
ICNRG G. White ICNRG G. White
Internet-Draft CableLabs Internet-Draft CableLabs
Intended status: Experimental S. Shannigrahi Intended status: Experimental S. Shannigrahi
Expires: December 27, 2018 C. Fan Expires: December 22, 2019 C. Fan
Colorado State University Colorado State University
June 25, 2018 June 20, 2019
Internet Protocol Tunneling over Content Centric Mobile Networks Internet Protocol Tunneling over Content Centric Mobile Networks
draft-white-icnrg-ipoc-01 draft-white-icnrg-ipoc-02
Abstract Abstract
This document describes a protocol that enables tunneling of Internet This document describes a protocol that enables tunneling of Internet
Protocol traffic over a Content Centric Network (CCN) or a Named Data Protocol traffic over a Content Centric Network (CCN) or a Named Data
Network (NDN). The target use case for such a protocol is to provide Network (NDN). The target use case for such a protocol is to provide
an IP mobility plane for mobile networks that might otherwise use IP- an IP mobility plane for mobile networks that might otherwise use IP-
over-IP tunneling, such as the GPRS Tunneling Protocol (GTP) used by over-IP tunneling, such as the GPRS Tunneling Protocol (GTP) used by
the Evolved Packet Core in LTE networks (LTE-EPC). By leveraging the the Evolved Packet Core in LTE networks (LTE-EPC). By leveraging the
elegant, built-in support for mobility provided by CCN or NDN, this elegant, built-in support for mobility provided by CCN or NDN, this
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2018. This Internet-Draft will expire on December 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. IPoC Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 3. CCN/NDN Overview . . . . . . . . . . . . . . . . . . . . . . 3
4. Client Interest Table and Interest Deficit Report . . . . . . 5 4. IPoC Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Handling PIT Entry Lifetimes . . . . . . . . . . . . . . . . 6 4.1. Use of Interest Payloads . . . . . . . . . . . . . . . . 5
6. Managing the CIT, PIT lifetimes and the in-flight message 5. Client Interest Table and Interest Deficit Report . . . . . . 5
6. Handling PIT Entry Lifetimes . . . . . . . . . . . . . . . . 6
7. Managing the CIT, PIT lifetimes and the in-flight message
count . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 count . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Establishing Communication . . . . . . . . . . . . . . . . . 8 8. Establishing Communication . . . . . . . . . . . . . . . . . 8
8. IPoC Naming Conventions . . . . . . . . . . . . . . . . . . . 8 9. IPoC Naming Conventions . . . . . . . . . . . . . . . . . . . 8
9. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 9 10. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 9
10. Packet Sequencer . . . . . . . . . . . . . . . . . . . . . . 9 11. Packet Sequencer . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Packet Sequencer Example Algorithm . . . . . . . . . . . 9 11.1. Packet Sequencer Example Algorithm . . . . . . . . . . . 10
11. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 12. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 11
12. Gateway Behavior . . . . . . . . . . . . . . . . . . . . . . 11 13. Gateway Behavior . . . . . . . . . . . . . . . . . . . . . . 12
13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 14. Security Considerations . . . . . . . . . . . . . . . . . . . 12
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
15. Normative References . . . . . . . . . . . . . . . . . . . . 12 16. Normative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Content Centric Networking provides some key advantages over IP Content Centric Networking provides some key advantages over IP
networking that make it attractive as a replacement for IP for networking that make it attractive as a replacement for IP for
wireless networking. In particular, by employing stateful wireless networking. In particular, by employing stateful
forwarding, CCN elegantly supports information retrieval by mobile forwarding, CCN elegantly supports information retrieval by mobile
client devices without the need for tunneling or a location client devices without the need for tunneling or a location
registration protocol. Furthermore, CCN supports a client device registration protocol. Furthermore, CCN supports a client device
utilizing multiple network attachments (e.g. multiple radio links) utilizing multiple network attachments (e.g. multiple radio links)
skipping to change at page 3, line 10 skipping to change at page 3, line 14
A significant hurdle that stands in the way of deploying a CCN-only A significant hurdle that stands in the way of deploying a CCN-only
wireless network is that all of the applications in use today (both wireless network is that all of the applications in use today (both
client and server) are built to use IP. client and server) are built to use IP.
This hurdle could be addressed by requiring that all applications be This hurdle could be addressed by requiring that all applications be
rewritten to use CCN natively, however, this is a tall order in a rewritten to use CCN natively, however, this is a tall order in a
world with millions of smartphone apps. Another approach could be to world with millions of smartphone apps. Another approach could be to
deploy a hybrid network in which the routers support forwarding both deploy a hybrid network in which the routers support forwarding both
IP and CCN. However, this adds cost and complexity to the network, IP and CCN. However, this adds cost and complexity to the network,
both in terms of equipment and in terms of operations. both in the equipment and in operations.
The protocol described in this document provides a way to eliminate The protocol described in this document provides a way to eliminate
this hurdle, by establishing an IP over CCN tunneling protocol that this hurdle, by establishing an IP over CCN tunneling protocol that
is transparent to the IP applications on either end. In a sense, is transparent to the IP applications on either end. In a sense,
this protocol replaces the IP-over-GTP tunnels or IP-over-GRE tunnels this protocol replaces the IP-over-GTP tunnels or IP-over-GRE tunnels
that would exist in a traditional IP-based wireless network such as that would exist in a traditional IP-based wireless network such as
LTE or Community WiFi, but by using a networking plane (CCN) that LTE or Community WiFi, but by using a networking plane (CCN) that
natively supports mobility, application developers have the option to natively supports mobility, application developers have the option to
update their applications to run directly over CCN, gaining all of update their applications to run directly over CCN, gaining all of
the advantages that come with this new protocol. the advantages that come with this new protocol.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. IPoC Overview 3. CCN/NDN Overview
In the CCN (or NDN) protocol, communication is achieved by an In the CCN (or NDN) protocol, communication is achieved by an
application sending an Interest packet that identifies, by name, a application sending an Interest packet that identifies, by name, a
piece of content that it wishes to receive. The network routes piece of content that it wishes to receive. The network routes
Interest messages toward a producer of content corresponding to the Interest messages toward a producer of content corresponding to the
name in the Interest, leaving a "breadcrumb" trail of state in the name in the Interest, leaving a "breadcrumb" trail of state in the
routers along that path. Once the Interest arrives at a node where routers along that path. Once the Interest arrives at a node where
the named piece of content is present, that node returns a Content the named piece of content is present, that node returns a Content
Object message containing the named piece of content. The Content Object message containing the named piece of content. The Content
Object follows (and consumes) the breadcrumb trail back to the Object follows (and consumes) the breadcrumb trail back to the
skipping to change at page 4, line 20 skipping to change at page 4, line 24
In addition, if a mobile device has multiple network attachment In addition, if a mobile device has multiple network attachment
points, e.g. both a WiFi and a 5G/LTE connection, it can choose to points, e.g. both a WiFi and a 5G/LTE connection, it can choose to
send Interests via both of those network paths. This capability can send Interests via both of those network paths. This capability can
be used to enable higher capacity (by load balancing the Interests in be used to enable higher capacity (by load balancing the Interests in
an attempt to fully utilize multiple links simultaneously), higher an attempt to fully utilize multiple links simultaneously), higher
reliability (by sending each Interest on multiple links), or seamless reliability (by sending each Interest on multiple links), or seamless
handover (by switching to a new link for all future Interest handover (by switching to a new link for all future Interest
messages, while still waiting to receive Content Objects on an older messages, while still waiting to receive Content Objects on an older
link). link).
4. IPoC Overview
While consumer mobility and multipath connectivity is elegantly While consumer mobility and multipath connectivity is elegantly
handled by the CCN protocol, producer mobility (where a mobile device handled by the CCN protocol, producer mobility (where a mobile device
makes its resident content available to outside devices), is makes its resident content available to outside devices), is
currently not. As a result, the IPoC protocol relies solely on currently not. As a result, the IPoC protocol relies solely on
consumer behavior on the client device. consumer behavior on the client device.
This protocol defines two entities: an IPoC Client and an IPoC This protocol defines two entities: an IPoC Client and an IPoC
Gateway. The IPoC Client (henceforth referred to as the Client) Gateway. The IPoC Client (henceforth referred to as the Client)
would exist on the mobile device, and as mentioned above, only sends would exist on the mobile device, and as mentioned above, only sends
Interest messages. The IPoC Gateway (henceforth referred to as the Interest messages. The IPoC Gateway (henceforth referred to as the
Gateway) exists at a fixed location in the network, and publishes a Gateway) exists at a fixed location in the network, and publishes a
prefix that can be routed to via the CCN network. In general, a prefix that can be routed to via the CCN network. In general, a
network may have many Clients, and possibly several Gateways. network may have many Clients, and possibly several Gateways.
The switches and routers that exist in the path between the Client(s) The switches and routers that exist in the path between the Client(s)
and the Gateway(s) are assumed to provide CCN forwarding, and are not and the Gateway(s) are assumed to provide CCN forwarding, and are not
required to support IP forwarding. required to support IP forwarding.
From the perspective of the applications running on the mobile From the perspective of the IP applications running on the mobile
device, the Client implementation functions as a tunnel endpoint, device, the Client implementation functions as a tunnel endpoint,
much in the same way that a VPN application does. All IP traffic much in the same way that a VPN application does. All IP packets
generated by applications on the mobile device are forwarded via this generated by applications on the mobile device are forwarded via this
tunnel endpoint, which encapsulates them in CCN Interest messages, tunnel endpoint, which encapsulates them in CCN Interest messages,
and then sends them into the CCN network. Similarly, the Gateway and then sends them into the CCN network. Similarly, the Gateway
implementation also acts as a tunnel endpoint, in this case on an IP implementation also acts as a tunnel endpoint, in this case on an IP
routing node. It receives Interest messages, unpacks the IP packets routing node. It receives Interest messages, unpacks the IP packets
inside, and forwards them into an IP network. IP return traffic inside, and forwards them into an IP network. IP return traffic
arriving at the Gateway is encapsulated into CCN Content Object arriving at the Gateway is encapsulated into CCN Content Object
messages, and then launched into the CCN network to follow the messages, and then launched into the CCN network to follow the
stateful forwarding path left by the associated Interest message. stateful forwarding path left by the associated Interest message.
4. Client Interest Table and Interest Deficit Report 4.1. Use of Interest Payloads
As described above, IPoC capitalizes on the consumer mobility
features of CCN, and as a result uses the optional interest payload
mechanism described in the "Consumer Behavior" section of
[I-D.irtf-icnrg-ccnxsemantics]. This behavior preserves the basic
hop-by-hop flow balancing principle of ICN, in that intermediate
routers can control traffic flow by delaying Interest messages as
appropriate. Additionally, the interest payload allows transport of
information in Interests outside of the name field, which can
significantly reduce router complexity (memory and memory bandwidth),
as the name field is stored in the router's Pending Interest Table.
5. Client Interest Table and Interest Deficit Report
In this communication model, the Client is able to send "upstream" In this communication model, the Client is able to send "upstream"
packets at any time, by sending Interest messages. The Gateway on packets at any time, by sending Interest messages. The Gateway on
the other hand, can only send "downstream" packets when it has a the other hand, can only send "downstream" packets when it has a
pending Interest (i.e. it has received an Interest message and has pending Interest (i.e. it has received an Interest message and has
not yet responded with an associated Content Object). As a result, not yet responded with an associated Content Object). As a result,
the Client and Gateway work together to ensure that the Gateway is the Client and Gateway work together to ensure that the Gateway is
receiving Interests sufficiently to support the downstream receiving Interests sufficiently to support the downstream
communication. communication.
skipping to change at page 6, line 5 skipping to change at page 6, line 24
Content Object. Content Object.
The Gateway SHOULD NOT discard Interest names from the CIT, and thus The Gateway SHOULD NOT discard Interest names from the CIT, and thus
SHOULD always respond to a received Interest with a Content Object in SHOULD always respond to a received Interest with a Content Object in
order to clear the associated PIT state in the intermediate routers. order to clear the associated PIT state in the intermediate routers.
If a new Interest arrives and the CIT is full, the gateway MUST If a new Interest arrives and the CIT is full, the gateway MUST
consume the name at the head of the CIT by sending an empty content consume the name at the head of the CIT by sending an empty content
object. In this case, the IDR value of the empty Content Object object. In this case, the IDR value of the empty Content Object
SHOULD be set to -1. SHOULD be set to -1.
5. Handling PIT Entry Lifetimes 6. Handling PIT Entry Lifetimes
Intermediate routers between the Client and the gateway, as well as Intermediate routers between the Client and the gateway, as well as
CCN forwarder implementations within the two IPoC endpoints will CCN forwarder implementations within the two IPoC endpoints will
store PIT entries for the Client's Interests for a finite lifetime, store PIT entries for the Client's Interests for a finite lifetime,
and will age-out (purge) Interests that exceed that lifetime. Since and will age-out (purge) Interests that exceed that lifetime. Since
the CIT at the gateway stores Interest names for a time in the CIT at the gateway stores Interest names for a time in
anticipation of downstream packets, it would be possible, when there anticipation of downstream packets, it would be possible, when there
is a gap in the flow of downstream packets, that the name at the head is a gap in the flow of downstream packets, that the name at the head
of the CIT queue is associated with entries that have been aged-out of the CIT queue is associated with entries that have been aged-out
of the PIT in one or more of the intermediate forwarders. If the of the PIT in one or more of the intermediate forwarders. If the
skipping to change at page 6, line 28 skipping to change at page 6, line 47
Content Object arrived at the PIT that no longer held an entry for Content Object arrived at the PIT that no longer held an entry for
this name. this name.
To avoid this situation, the Gateway MUST record the arrival time of To avoid this situation, the Gateway MUST record the arrival time of
each CIT entry, and compare it against a CIT lifetime value. When each CIT entry, and compare it against a CIT lifetime value. When
the CIT entry at the head of the CIT "expires", the gateway MUST send the CIT entry at the head of the CIT "expires", the gateway MUST send
a Content Object using that CIT entry, thereby cleaning up the PIT a Content Object using that CIT entry, thereby cleaning up the PIT
state in the intervening forwarders, and potentially triggering a new state in the intervening forwarders, and potentially triggering a new
Interest to be sent by the Client (as discussed further below). Interest to be sent by the Client (as discussed further below).
6. Managing the CIT, PIT lifetimes and the in-flight message count 7. Managing the CIT, PIT lifetimes and the in-flight message count
At any instant in time, a certain number of Interest names can be At any instant in time, a certain number of Interest names can be
considered "in-flight" from the Client's perspective (these in-flight considered "in-flight" from the Client's perspective (these in-flight
Interests correspond to the entries in the Client's PIT). Some Interests correspond to the entries in the Client's PIT). Some
fraction of the in-flight Interest names will correspond to Interest fraction of the in-flight Interest names will correspond to Interest
messages (possibly containing IP packets) that are in transit to the messages (possibly containing IP packets) that are in transit to the
gateway, some fraction will correspond to Content Object messages gateway, some fraction will correspond to Content Object messages
(also possibly containing IP packets) that are in transit to the (also possibly containing IP packets) that are in transit to the
Client, and the remainder correspond to the entries in the gateway's Client, and the remainder correspond to the entries in the gateway's
CIT or to messages that were lost in transit. The gateway controls CIT or to messages that were lost in transit. The gateway controls
skipping to change at page 8, line 4 skipping to change at page 8, line 24
an empty Content Object. The expiration of a CIT entry is a good an empty Content Object. The expiration of a CIT entry is a good
indication that the CIT contains more entries than are needed to indication that the CIT contains more entries than are needed to
support the current data rate. In this situation, the Gateway SHOULD support the current data rate. In this situation, the Gateway SHOULD
use the IDR to reduce the in-flight count. One mechanism for doing use the IDR to reduce the in-flight count. One mechanism for doing
this is described here: this is described here:
If the number of CIT entries is less than n, the empty Content Object If the number of CIT entries is less than n, the empty Content Object
sent to consume the expiring CIT entry will contain an IDR with the sent to consume the expiring CIT entry will contain an IDR with the
value 1. If the number of CIT entries is greater than n, the CO will value 1. If the number of CIT entries is greater than n, the CO will
contain an IDR with value -1, and if it is equal to n, the value 0. contain an IDR with value -1, and if it is equal to n, the value 0.
The result of this process is that during idle periods, the CIT will The result of this process is that during idle periods, the CIT will
drain down to the point of having n entries, and will refresh those drain down to the point of having n entries, and will refresh those
entries as they expire. entries as they expire.
7. Establishing Communication 8. Establishing Communication
Communication is established by the Client sending an Interest to a Communication is established by the Client sending an Interest to a
Gateway, where the name in the Interest message includes a Gateway Gateway, where the name in the Interest message includes a Gateway
prefix followed by /init/<random_string>. For example, if the prefix followed by /init/<random_string>. For example, if the
established Gateway prefix is ccnx:/ipoc, the name might be established Gateway prefix is ccnx:/ipoc, the name might be
ccnx:/ipoc/init/2Fhwte2452g5shH4. The Gateway has a process that ccnx:/ipoc/init/2Fhwte2452g5shH4. The Gateway has a process that
will respond to the ccnx:/ipoc/init prefix by sending IP will respond to the ccnx:/ipoc/init prefix by sending IP
configuration information, similar to the information contained in a configuration information, similar to the information contained in a
DHCP Offer, including an assigned IP address. DHCP Offer, including an assigned IP address.
Upon configuring itself using the information in the init response, Upon configuring itself using the information in the init response,
the Client can begin IP communication. The naming convention for the Client can begin IP communication. The naming convention for
subsequent Interest messages is described in the next section. subsequent Interest messages is described in the next section.
8. IPoC Naming Conventions 9. IPoC Naming Conventions
The IPoC protocol doesn't assign any relationship between the
Interest / Content Object names and the contents of the encapsulated
IP packets. Rather, the name only identifies the Client instance of
the IPoC application, and provides a sequence number that
disambiguates Interests and Content Objects and provides for in-order
delivery of IP packets.
The Client and Gateway can use one of the following data naming The Client and Gateway can use one of the following data naming
conventions, the appropriate naming convention is chosen by the conventions, the appropriate naming convention is chosen by the
Gateway via configuration, and is communicated to the Client during Gateway via configuration, and is communicated to the Client during
the Establishing Communication protocol. the Establishing Communication protocol.
ccnx:/ipoc/<hex_ipaddr>/<b64_seq> ccnx:/ipoc/<hex_ipaddr>/<b64_seq>
ccnx:/ipoc/<zone_id>/<hex_ipaddr>/<b64_seq> ccnx:/ipoc/<zone_id>/<hex_ipaddr>/<b64_seq>
skipping to change at page 9, line 10 skipping to change at page 9, line 37
defined in Section 2.2 paragraph 1 of [RFC4291] is used, with each defined in Section 2.2 paragraph 1 of [RFC4291] is used, with each
colon replaced by a CCN name segment delimiter. For example a colon replaced by a CCN name segment delimiter. For example a
Client with the IPv6 address: 2001:DB8::fe21:67cf would use Client with the IPv6 address: 2001:DB8::fe21:67cf would use
"2001/DB8/0/0/0/0/fe21/67cf" for this name component. "2001/DB8/0/0/0/0/fe21/67cf" for this name component.
o b64_seq - This a base64-encoded value representing the Upstream o b64_seq - This a base64-encoded value representing the Upstream
Sequence Number for this upstream Interest message Sequence Number for this upstream Interest message
An example Interest name is: ccnx:/ipoc/c0/00/02/64/AAAAGw== An example Interest name is: ccnx:/ipoc/c0/00/02/64/AAAAGw==
9. Sequence Numbers 10. Sequence Numbers
Upstream Sequence Numbers (USN) are monotonically increasing unsigned Upstream Sequence Numbers (USN) are monotonically increasing unsigned
32-bit integer values embedded in the Interest names to indicate the 32-bit integer values embedded in the Interest names to indicate the
proper ordering for upstream data packets. Since Interest messages proper ordering for upstream data packets. Since Interest messages
may arrive out-of-order due to the use of multiple network paths, the may arrive out-of-order due to the use of multiple network paths, the
Gateway uses the USN to ensure that upstream IP packets are delivered Gateway uses the USN to ensure that upstream IP packets are delivered
in the proper order. in the proper order.
Content Objects that carry IP packet payloads include Downstream Content Objects that carry IP packet payloads include Downstream
Sequence Numbers (DSN), which are monotonically increasing unsigned Sequence Numbers (DSN), which are monotonically increasing unsigned
32-bit integer values that indicate the proper ordering of downstream 32-bit integer values that indicate the proper ordering of downstream
data packets. DSN are used by the Client to ensure that downstream data packets. DSN are used by the Client to ensure that downstream
IP packets are delivered in the proper order. IP packets are delivered in the proper order.
The USN and DSN are independent sequence numbers and thus have no The USN and DSN are independent sequence numbers and thus have no
relationship to one another. relationship to one another.
10. Packet Sequencer 11. Packet Sequencer
The Packet Sequencer (PS or Sequencer) is a FIFO queue that exists The Packet Sequencer (PS or Sequencer) is a FIFO queue that exists
both at the Client and Gateway to ensure in-order delivery of IP both at the Client and Gateway to ensure in-order delivery of IP
packets contained in upstream Interests and downstream Content packets contained in upstream Interests and downstream Content
Objects. The order in which the packets are delivered is decided by Objects. The order in which the packets are delivered is decided by
the Packet Sequence Number (PSN) embedded in the Interest or Content the Packet Sequence Number (PSN) embedded in the Interest or Content
Object names. Object names.
The client MUST implement a Packet Sequencer to ensure in-order The client MUST implement a Packet Sequencer to ensure in-order
delivery of IP packets. The gateway MUST implement a Packet delivery of IP packets. The gateway MUST implement a Packet
Sequencer to ensure in-order delivery of IP packets. Sequencer to ensure in-order delivery of IP packets.
10.1. Packet Sequencer Example Algorithm 11.1. Packet Sequencer Example Algorithm
The first PSN (FPSN) delivered to the Sequencer establishes a The first PSN (FPSN) delivered to the Sequencer establishes a
baseline to which all subsequent PSNs are evaluated based on an baseline to which all subsequent PSNs are evaluated based on an
expected ascending incremental order. The Sequencer also notes the expected ascending incremental order. The Sequencer also notes the
last PSN (LPSN) it forwarded, and for the first packet, FPSN is equal last PSN (LPSN) it forwarded, and for the first packet, FPSN is equal
to LPSN. If an arriving packet has the expected sequence number to LPSN. If an arriving packet has the expected sequence number
(LPSN + 1), the sequencer does not queue the packet and simply (LPSN + 1), the sequencer does not queue the packet and simply
forwards it. The Sequencer also tracks the highest sequence number forwards it. The Sequencer also tracks the highest sequence number
that has arrived (MAXPSN). that has arrived (MAXPSN).
skipping to change at page 10, line 35 skipping to change at page 11, line 13
(lowest PSN first). If the queue exceeds capacity, the Sequencer (lowest PSN first). If the queue exceeds capacity, the Sequencer
discards the packet with the lowest PSN. Any IP packets in those discards the packet with the lowest PSN. Any IP packets in those
Interests or content objects are discarded. Interests or content objects are discarded.
Ideally, the gap validity window should be set to the RTT between the Ideally, the gap validity window should be set to the RTT between the
Client and the Gateway. However, since packets can take multiple Client and the Gateway. However, since packets can take multiple
paths and the Sequencer may not know the RTT for each of these paths, paths and the Sequencer may not know the RTT for each of these paths,
it should dynamically adjust the validity window based on the inter- it should dynamically adjust the validity window based on the inter-
arrival time between consecutive packets. arrival time between consecutive packets.
11. Client Behavior 12. Client Behavior
The three main functions of the Client are: The three main functions of the Client are:
1. Send Interest messages containing upstream IP packets whenever 1. Send Interest messages containing upstream IP packets whenever
they arrive they arrive
2. Send Interest messages to the gateway in order to keep the 2. Send Interest messages to the gateway in order to keep the
appropriate in-flight count appropriate in-flight count
3. Receive downstream IP packet data in Content Object messages 3. Receive downstream IP packet data in Content Object messages
skipping to change at page 11, line 32 skipping to change at page 12, line 8
The Client MUST maintain two internal timer intervals. A short timer The Client MUST maintain two internal timer intervals. A short timer
(T0) is used to pace Interest messages when there are outstanding (T0) is used to pace Interest messages when there are outstanding
interests to be sent as per the Interest Deficit Counter. The long interests to be sent as per the Interest Deficit Counter. The long
timer (T1) is used as a keep-alive when the Client has no outstanding timer (T1) is used as a keep-alive when the Client has no outstanding
Interests to be sent. Whenever the client sends an Interest message, Interests to be sent. Whenever the client sends an Interest message,
it restarts the T0 and T1 timers. When the T0 timer expires, if the it restarts the T0 and T1 timers. When the T0 timer expires, if the
IDC is greater than zero, the Client MUST send an empty Interest IDC is greater than zero, the Client MUST send an empty Interest
message. When the T1 timer expires, the Client MUST send an empty message. When the T1 timer expires, the Client MUST send an empty
Interest message (regardless of the IDC value). Interest message (regardless of the IDC value).
12. Gateway Behavior 13. Gateway Behavior
IPoC gateway behavior is slightly more complex since it must manage IPoC gateway behavior is slightly more complex since it must manage
connections with multiple Clients simultaneously. The standard connections with multiple Clients simultaneously. The standard
process for on-boarding a new Client looks something like this: process for on-boarding a new Client looks something like this:
o An Interest is received with the /init/<random_string> name. o An Interest is received with the /init/<random_string> name.
o The gateway establishes new CIT (and other Client-specific) o The gateway establishes new CIT (and other Client-specific)
structures for this Client and responds with a Content Object structures for this Client and responds with a Content Object
containing the IP parameters (yiaddr, giaddr, etc.) to configure containing the IP parameters (yiaddr, giaddr, etc.) to configure
skipping to change at page 12, line 17 skipping to change at page 12, line 42
When downstream IP packets become available, the gateway will remove When downstream IP packets become available, the gateway will remove
the first name from the CIT queue and use it to create a Content the first name from the CIT queue and use it to create a Content
Object containing the IP packets. If the CIT is empty, IP packets Object containing the IP packets. If the CIT is empty, IP packets
are buffered by the gateway. are buffered by the gateway.
If IP packets are waiting in buffer when a new Interest (CIT entry) If IP packets are waiting in buffer when a new Interest (CIT entry)
arrives, the gateway will immediately dequeue the waiting packets (up arrives, the gateway will immediately dequeue the waiting packets (up
to a maximum CO size limit), form and transmit a Content Object using to a maximum CO size limit), form and transmit a Content Object using
the newly arrived CIT name. the newly arrived CIT name.
13. Security Considerations 14. Security Considerations
TBD. TBD.
14. IANA Considerations 15. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
15. Normative References 16. Normative References
[I-D.irtf-icnrg-ccnxmessages] [I-D.irtf-icnrg-ccnxmessages]
Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
Format", draft-irtf-icnrg-ccnxmessages-06 (work in Format", draft-irtf-icnrg-ccnxmessages-09 (work in
progress), October 2017. progress), January 2019.
[I-D.irtf-icnrg-ccnxsemantics] [I-D.irtf-icnrg-ccnxsemantics]
Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", Mosko, M., Solis, I., and C. Wood, "CCNx Semantics",
draft-irtf-icnrg-ccnxsemantics-06 (work in progress), draft-irtf-icnrg-ccnxsemantics-10 (work in progress),
October 2017. January 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
 End of changes. 28 change blocks. 
42 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/