| ICN Research Group | A. Afanasyev |
| Internet-Draft | UCLA |
| Intended status: Informational | R. Ravindran |
| Expires: September 10, 2015 | G. Wang |
| Huawei Technologies | |
| L. Wang | |
| University of Memphis | |
| B. Zhang | |
| University of Arizona | |
| L. Zhang | |
| UCLA | |
| March 9, 2015 |
ICN Packet Format Design Requirements
draft-icn-packet-format-requirements-00
It is a great challenge to design the right packet format for the Information-Centric Networking (ICN), because this new architecture is still in its research stage. We do not have good prediction regarding either the technology advances or the application needs may involve in next 10 years. To minimize the chance of premature constraints in the packet format design, we believe it is important to first clearly identify the design requirements, so that we can use the requirements to guide the design effort. In this document we describe our understanding of the design requirements and their tradeoffs.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The proposed Information-Centric Networking (ICN) architectures (TRIAD [4], DONA [5], NDN [6] [7] [8] [3], CCNx [9], and others) put forward an objective to become a new universal narrow waist for local and global communication. However, all these proposals are still in research stage with many details yet to be specified, many questions yet to be answered, and many more issues yet to be identified and resolved through experimentation.
It is a great challenge to design the right packet format for ICN that can satisfy all desired research goals including both that have been identified now and those that may appear in the future. This document is our first attempt to formalize the general requirements for the ICN packet format design by leveraging past experience and following the framework defined in [1]. Clearly identifying the design requirements can help guiding the decision process in evaluating design tradeoffs and avoiding premature constraints. We do not discuss any specific packet format proposals in this draft, instead our focus is on identifying fundamental requirements of the format, and on understanding different design tradeoffs.
Some of the requirements listed in Section 2 may conflict with each other; how to prioritize such conflicting requirements determines the outcome of the packet format design. In this draft we list our identified requirements and put them in a priority order as the best match to the current and future needs of ICN protocols as we can see at this time. We hope that this draft contributes to the ongoing discussion about ICN packet format design.
This section presents an ordered list of identified requirements for the ICN packet format. In each sub-section we briefly describe potential design space that satisfies the requirement and discuss the tradeoffs between different design choices.
As the new narrow waist of the Internet, the packet format must be able to support a diversity of usage scenarios and underlying network technologies: from highly constrained IoT environments [2] to ultra high-speed network channels [13].
A single IP packet format has served us well in the past. However, continued expansion of Internet usage frontier in recent years has shown the constraints of the existing IP packet formats. As one example: due to its fixed length and limited size, the shortage of IPv4 address space called for the design and deployment of IPv6; although the design has long been done, the deployment is slow in coming. As another example, the design of IPv6 format provides sufficiently large address space for foreseeable future, but it leads to the concerns of excessive overhead when used in emerging low-power network environment (IoT), which were not foreseen in early 1990s when IPv6 design was sketched out. In turn, IETF had to launch 6LoWPAN effort to address the issue.
These observations suggest us to avoid similar issues in the ICN format design. We would like to see the ICN packet format to allow applications to choose their packet size in whichever way as they see fit, from a few tens of bytes in constrained environments to jumbograms to take advantage of future high capacity transport and increase in network MTU capability. The way to achieve this goal is to ensure that packet length (and optionally lengths of packet format fields) is encoded as a variable length number (variable-length encoding or alternative encodings for different packet lengths).
Given the experimental nature of the ongoing ICN architectural research, the packet format should stay flexible in providing ability to add new elements to the format, as well as to remove elements that are no longer deemed necessary. The required fields in the packet format should also be kept as minimal as possible.
BGP [10] is one of the successful protocols that has gone through a series of evolutionary changes. ([TODO: cite other examples]) After going through a few rapid version changes in its early days, BGP4 adopted the flexible protocol encoding format of type-length-value (TLV), which allows BGP to encode new function by simply introducing a new TLV block; old TLV blocks can be deprecated over time without requiring a flag day or base protocol format alterations.
Thus the use of TLV encoding can offer the potential to provide protocol flexibility and extensibility (as the current designs do already).
Our past protocol design experience also shows that to ease the introduction of new features, one should also encode the information about desired actions to take by the entity which does not recognize the newly defined feature. For example, optional TLVs in the extension header of IPv6 [11] reserve first two bits of the type to specify the action for routers to take when an unrecognized TLV is encountered: skip over and continue processing or discard the packet. Similarly, SCTP [12] reserves two bits to indicate the desired processing for packets with unrecognized chunks. ICN packet format can adopt a similar mechanism, either by reserving some bits from the type field or by splitting the type space into different bins in certain ways, assigning a type code to the bin based on the desired actions to be taken by entities which do not recognize the new TLV type.
It is desirable to design the ICN packet format in a way that allows efficient packet processing to the extent possible. However making the format for processing efficiency often runs into conflict with elasticity and flexibility requirements. For example, the latter leads the format to contain variable parts, which in turn lead to higher processing complexity. Similarly, if the packet format is designed to contain a fixed part, that part becomes unchangeable, without a global flag day for making the changes.
Furthermore, when we consider processing efficiency, we should not constrain our thinking by either the currently available technology or the currently understood implementation approach. History showed us that technologies can advance quickly, especially when there are high demands. New implementation approaches are also discovered over time, providing efficient solutions to problems that once were considered infeasible. For example, switching to classless inter-domain routing (CIDR) created challenges for line rate router implementations [TODO: cite], and that challenge was soon resolved.
Therefore, we believe the processing efficiency requirement on the format design should be put at lower priority than the elasticity and flexibility considerations (i.e., we should not sacrifice long-term flexibility in the design for short-term efficiency gains).
The rest of this section discussions a few specific approaches to improve processing efficiency.
Decoding and encoding of ICN packet format should be as efficient as possible. Packet format should allow partial decoding of the packet, efficient access to individual fields, and efficient skipping over unprocessed (e.g., application-defined or unrecognized) fields. It is also desirable for the key fields needed to make packet forwarding decision (e.g., name) to appear in the beginning of the packet.
Cryptographic operations should be defined over a continuous packet block, containing one or multiple complete TLV elements. In other words, the security envelope must be defined over a continuous sequence of whole TLV elements.
Application-defined elements added to the packet format should not increase routers' processing requirements. For example, when an application adds custom elements into the packet format, these elements must go to an application-specific group that is always skipped by routers, or should be clearly separated from router-processed elements and can be easily skipped without processing.
Generally speaking, TLV-encoded packet format includes multiple nested TLV blocks. To provide ability to audit packet encoding without requiring full understanding of semantics of each nested TLV level, it is highly desirable to assign unique type codes to each element in the packet format that is processed by routers. In other words, we would like to require unique type code assignment to all network level TLV elements. This requirement may not apply to vendor-specific or application-specific type codes, whether they may, or may not reuse type code space.
One of the advantages of using unique type code assignment is reduction of implementation errors. Unique types across multiple TLV levels is also important for network traffic debugging tools similar to tcpdump and wireshark: with unique type codes for all network-level elements, implementation of those tools would be simple with potential of decoding known TLV types at any level of nesting. When the same type codes are reuse (at different TLV nesting levels), such tools also can still be implemented, but potentially with increased complexity, as it would be required to define semantical contexts for each nested TLV block.
The tradeoff of the unique type code assignment is the coordination required in ensuring the type code uniqueness when doing code assignments.
In an ICN network, communication is performed using application-level information units. Therefore, the primary function of ICN packet format is to include all elements that are needed to describe and secure the data and elements to describe request for the data, such as data name, data name constraints, payload, security context, security context constraints, application context, etc. Note that these information-centric elements define the data as requested by consumers and enable communication between ICN consumers and producers in terms of the desired data.
At the same time, there is a separate class of elements (functions) that may be needed to aid the information retrieval process (to guide multi-hop packet forwarding function), but is not related to the information itself. For example, hop limit element may be needed to avoid information requests to uncontrollably loop inside the network; nonce field in the requests may be needed to detect reception of the same request multiple times for error reporting and loop detection; QoS labels in requests can enable support for prioritization of certain retrieval processes, etc. Note that all such elements are volatile by nature and/or may be needed only in parts of the network.
Given the two separate classes of the elements, the question is how should they be organized in the packet format: combine these classes of elements under a single format or separate into two complementary specifications. The question here: what actually is the narrow waist of Information-Centric Networking? In principle, application-level information and application-level requests for information is the narrow waist in ICN, as it is minimally required element to enable communication, e.g., between directly connected peers or between ICN applications on the same node. However, when a multi-hop forwarding is performed, additional elements may be necessary to improve efficiency of information retrieval.
The two ways of enabling information-centric and multi-hop forwarding functions in ICN packet format would define tradeoffs for implementation, usability, and future extensibility. The combined format may be simpler to implement, but may require inclusion of unnecessary elements, e.g., when caching information inside the network. The separated way gives flexibility of evolving the underlying format for transport function, but creates a danger of creation of multiple incompatible formats implementing the same multi-hop forwarding function.
In this document we intentionally do not try to answer the question of how to combine information-centric and transport-related elements into the packet format. The goal of the document is to define a framework to clearly understand the general requirements for the packet format and define our position about the tradeoffs in the design space. We hope that a set of agreed upon requirements can provide a guideline to packet format design that can serve us many years in the future.
TODO
IP version number did not help much in introducing IPv6.
History of IP address space design: the choice of fixed length is not a good design choice.
BGP stays with BGP4 after adopting TLV encoding.
Technology moves forward fast, this is an important design factor.
Given the diversity of the requirements, a single packet format may not be able to satisfy to the full extent all of the listed requirements. Depending on which requirement is prioritized, the resulting design for the packet format would have different tradeoffs between universality, flexibility, and efficiency.
TODO