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
Abstract
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.
Status of This Memo
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.
Afanasyev, et al. Expires September 10, 2015 [Page 1]
Internet-Draft ICN Packet Format Design Requirements March 2015
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements for ICN Packet Format Design . . . . . . . . . . 3
2.1. Universality (Elasticity) . . . . . . . . . . . . . . . . 3
2.2. Flexibility and Extensibility . . . . . . . . . . . . . . 4
2.3. Processing Efficiency . . . . . . . . . . . . . . . . . . 4
2.3.1. Decoding and Encoding Efficiency . . . . . . . . . . 5
2.3.2. Continuity of Security Envelope . . . . . . . . . . . 5
2.3.3. Preservation of Network-Level Processing . . . . . . 5
2.4. Auditability / Robust Design . . . . . . . . . . . . . . 6
3. Separate Classes of Information (Functions) in ICN:
Information-Centric and Multi-Hop Forwarding . . . . . . . . 6
4. ICN Packet Format Success Factors (A Few Lessons from Today's
Internet) . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
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
Afanasyev, et al. Expires September 10, 2015 [Page 2]
Internet-Draft ICN Packet Format Design Requirements March 2015
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.
2. Requirements for 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.
2.1. Universality (Elasticity)
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
Afanasyev, et al. Expires September 10, 2015 [Page 3]
Internet-Draft ICN Packet Format Design Requirements March 2015
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).
2.2. Flexibility and Extensibility
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.
2.3. Processing Efficiency
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
Afanasyev, et al. Expires September 10, 2015 [Page 4]
Internet-Draft ICN Packet Format Design Requirements March 2015
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.
2.3.1. Decoding and Encoding 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.
2.3.2. Continuity of Security Envelope
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.
2.3.3. Preservation of Network-Level Processing
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.
Afanasyev, et al. Expires September 10, 2015 [Page 5]
Internet-Draft ICN Packet Format Design Requirements March 2015
2.4. Auditability / Robust Design
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.
3. Separate Classes of Information (Functions) in ICN: Information-
Centric and Multi-Hop Forwarding
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
Afanasyev, et al. Expires September 10, 2015 [Page 6]
Internet-Draft ICN Packet Format Design Requirements March 2015
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.
4. ICN Packet Format Success Factors (A Few Lessons from Today's
Internet)
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.
Afanasyev, et al. Expires September 10, 2015 [Page 7]
Internet-Draft ICN Packet Format Design Requirements March 2015
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.
5. Security Considerations
TODO
6. Informative References
[1] Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", Proceedings of SIGCOMM'88, August 1988.
[2] "IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access
Control (MAC) and Physical Layer (PHY) Specifications for
Low-Rate Wireless Personal Area Networks", June 2011.
[3] NSF FIA project, NDN., "http://www.named-data.net/", 2010.
[4] Cheriton, D. and M. Gritter, "TRIAD: A new next-generation
Internet architecture", 2000.
[5] Koponen, T. and et al., "A data-oriented (and beyond)
network architecture", ACM SIGCOMM Computer Communication
Review, Vol. 37, No. 4, 2007.
[6] Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
Briggs, N., and R. Braynard, "Networking named content",
Proc. of CoNEXT, 2009.
[7] Zhang, L. and et al., "Named data networking (NDN)
project", NDN Tech. Rep. NDN-0001, October 2010.
[8] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., claffy,
kc., Crowley, P., Papadopoulos, C., Wang, L., and B.
Zhang, "Named Data Networking", ACM Computer Communication
Reviews, July 2014.
[9] M. Mosko, , "CCNx Semantics, draft-mosko-icnrg-
ccnxsemantics-00", January 2015.
[10] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Afanasyev, et al. Expires September 10, 2015 [Page 8]
Internet-Draft ICN Packet Format Design Requirements March 2015
[12] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007.
[13] ITU-T, , "Interface for the Optical Transport Network
(OTN)", G.709 Recommendation, February 2012.
Authors' Addresses
Alexander Afanasyev
UCLA
4809 Boelter Hall, UCLA
Los Angeles, CA 90095
US
Email: afanasev@cs.ucla.edu
Ravishankar Ravindran
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
US
Email: ravi.ravindran@huawei.com
Guoqiang Wang
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
US
Email: gq.wang@huawei.com
Lan Wang
University of Memphis
318 Dunn Hall
Memphis, TN 38152
US
Email: lanwang@memphis.edu
Afanasyev, et al. Expires September 10, 2015 [Page 9]
Internet-Draft ICN Packet Format Design Requirements March 2015
Beichuan Zhang
University of Arizona
Gould-Simpson 723
Tucson, AZ 85721
US
Phone: +1 520 621 4817
Email: bzhang@cs.arizona.edu
Lixia Zhang
UCLA
3713 Boelter Hall, UCLA
Los Angeles, CA 90095
US
Phone: +1 310 825 2695
Email: lixia@cs.ucla.edu
Afanasyev, et al. Expires September 10, 2015 [Page 10]