Internet DRAFT - draft-icn-packet-format-requirements
draft-icn-packet-format-requirements
ICN Research Group A. Afanasyev
Internet-Draft UCLA
Intended status: Informational R. Ravindran
Expires: September 30, 2015 G. Wang
Huawei Technologies
L. Wang
University of Memphis
B. Zhang
University of Arizona
L. Zhang
UCLA
March 29, 2015
ICN Packet Format Design Requirements
draft-icn-packet-format-requirements-01
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 and beyond. To minimize the danger 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 30, 2015.
Afanasyev, et al. Expires September 30, 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 . . . . . . . . . . . . . . . . . . 5
2.3.1. Decoding and Encoding Efficiency . . . . . . . . . . 5
2.3.2. Continuity of Security Envelope . . . . . . . . . . . 6
2.3.3. Preservation of Network-Level Processing . . . . . . 6
2.4. Auditability / Robust Design . . . . . . . . . . . . . . 6
3. Separating Information-Centric and Multi-Hop Forwarding
Element in ICN Packet Format Design . . . . . . . . . . . . . 7
4. ICN Packet Format Success Factors (A Few Lessons from Today's
Internet) . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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 those that
have been identified now and those that are yet to be recognized
further down the road. This document is our first attempt to
Afanasyev, et al. Expires September 30, 2015 [Page 2]
Internet-Draft ICN Packet Format Design Requirements March 2015
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. In this draft we do not discuss any specific
packet format proposals, instead our focus is on identifying
fundamental requirements on the packet format design, 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 with fixed
header format. 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 of IPv6 has long been done,
its deployment is slow in coming. As we discuss later in Section 4,
some earlier sketch of IP protocol design proposed variable address
fields, but was changed to fixed length to ease implementation;
compared to the variable length address design, this ease of
implementation has costed both unnecessarily long IP header when the
Internet was small in its early days, and the global effort of moving
from IPv4 to IPv6 in the last 10 years. As another example, the
design of IPv6 format aimed to provide sufficiently large address
space for foreseeable future, but it leads to the concerns of
excessive overhead when used in emerging low-power constrained
networks (IoT), which were not foreseen in early 1990s when the
Afanasyev, et al. Expires September 30, 2015 [Page 3]
Internet-Draft ICN Packet Format Design Requirements March 2015
initial IPv6 design was sketched out. In turn, IETF had to launch
6LoWPAN effort to address this issue together with a number of others
caused by the constrained environment.
These observations suggest that the ICN format design should avoid
similar issues. We would like to see that the ICN packet format
allows 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. One way to achieve this goal is
to ensure that packet length (as well as the lengths of other packet
format fields) uses a variable-length encoding scheme to allow
different packet sizes.
2.2. Flexibility and Extensibility
Given the experimental nature of the ongoing ICN architectural
research, the packet format should stay flexible in order to allow
new elements to be added to the format as they are identified, as
well as to remove any existing elements that are no longer deemed
necessary. The required fields in the packet format should also be
kept as minimal as possible, as our understanding of the requirements
are likely to change over time.
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 a new function by simply
introducing a new TLV block; old TLV blocks can be deprecated over
time without a flag day for base protocol format alterations.
Thus, the use of TLV encoding can offer the potential to provide
protocol flexibility and extensibility (and the existing ICN protocol
designs do already).
Observations over past protocol design experience also show that to
ease the introduction of new features, one can encode the information
about desired actions to be taken by any 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 to be taken by routers when an unrecognized TLV
is encountered: skip over and continue processing or discard the
packet, and/or send an error report to the source of the packet.
Similarly, SCTP design [12] also reserves two bits to indicate the
desired processing for packets with unrecognized chunks. ICN packet
format may consider to adopt a similar mechanism by reserving some
bits from the type field; an alternative scheme, which does not
Afanasyev, et al. Expires September 30, 2015 [Page 4]
Internet-Draft ICN Packet Format Design Requirements March 2015
require dedicated bits for the purpose, is to split the type code
space into different bins, and to assign each type code into 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 cost as compared to formats with fixed length
encoding. Similarly, if the packet format contains a fixed part,
that part becomes unchangeable, without a global flag day for making
the changes.
Furthermore, when we consider processing efficiency, our thinking
should not be constrained by either the currently available
technology or the currently understood implementation approach.
History showed us that technologies can advance quickly, especially
when there is a high demand from the market. Similarly, new
implementation approaches are also discovered in response to the
need, providing efficient solutions to problems that once were
considered infeasible. For example, the switch to classless inter-
domain routing (CIDR) during 1990's created challenges for line speed
router implementations [TODO: cite], and that challenge was quickly
resolved.
Therefore, although the processing efficiency requirement on the
format design is an important one, we believe it should be put below
the elasticity and flexibility considerations, i.e., the design
should not sacrifice the long-term protocol flexibility 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.
Afanasyev, et al. Expires September 30, 2015 [Page 5]
Internet-Draft ICN Packet Format Design Requirements March 2015
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 cost. 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.
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 potential 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.
Afanasyev, et al. Expires September 30, 2015 [Page 6]
Internet-Draft ICN Packet Format Design Requirements March 2015
3. Separating Information-Centric and Multi-Hop Forwarding Element in
ICN Packet Format Design
In an ICN network, communication is performed using application-level
information units. Therefore, the primary function of ICN packet
format is to include all the elements that are necessary to describe
requests for the data and to describe and secure the data, such as
data name, data name constraints, payload, security context, security
context constraint, 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 protocol elements that
an ICN packet may need to carry in order to aid the information
retrieval over multi-hop environment; these elements are not related
to the requested information itself. For example, a lifetime element
may be needed to avoid a request staying inside the network for too
long; a nonce field in the requests can aid the detection of request
duplication; QoS labels in requests can enable support for
prioritization in retrieving certain information classes; a NACK can
be exchanged between adjacent nodes to notify problems in forward
requests so that the previous hop routers can promptly try
alternatives; and when a packet needs to be fragmented to cross a
small MTU hop, certain fields must be added to the packet to
facilitate the reassembly at the other end. Note that all of such
elements are volatile by nature, they may be needed only in parts of
the network, and the perceived need for some of them may change over
time as we gain deeper understanding of ICN network operations
through trial deployment in coming years.
Given the two separate classes of the elements, the question is how
they should be encoded into an ICN packet format. A variety of
design proposals exist today. One way of thinking is to clearly
separate these two classes of protocol elements. Since the ICN
elements are fundamental in information retrieval, they must be
implemented in all consumers and producers. At the same time, the
need for various forwarding elements may depend on specific
forwarding scenarios and environments. This way of thinking leads to
the consideration of providing the forwarding elements in a separate
shim layer protocol, instead of including them in the base ICN
protocol format.
Another way of thinking is to encode all the protocol elements into
the based ICN protocol format based on their perceived necessity,
and/or based on the processing efficiency consideration, but with no
consideration on identifying and separating the two classes of
protocol elements.
Afanasyev, et al. Expires September 30, 2015 [Page 7]
Internet-Draft ICN Packet Format Design Requirements March 2015
The basic question here is: what should be considered the narrow
waist in an Information-Centric Networking architecture? In
principle, the ICN elements are the minimally required ones to enable
communication in an ICN network. They are the only ones needed for
data flow between directly connected peers or between ICN
applications running on the same node. When information retrieval
crosses wide areas, additional elements become necessary to assist
the information retrieval over multiple hops/networks.
The two ways of encoding information-centric and multi-hop forwarding
elements in ICN packet format would define tradeoffs for
implementation, usability, and future extensibility. The combined
format can be simpler to implement and easier to process, but may
lead to inclusion of unnecessary elements. For example, when data
packets are cached inside the network and retrieved later by
different consumers, most, if not all, forwarding elements may no
longer be meaningful. Encoding the two classes of protocol elements
gives flexibility of evolving the underlying format for transport
function, but also creates a need for standardization, to avoid the
danger of multiple incompatible formats being developed for the same
multi-hop forwarding function.
In this document we intentionally do not nail down any specific
answers to the question of how to combine information-centric and
transport-related elements into the packet format. Our goal is to
define a framework to clearly articulate the general requirements for
the ICN packet format design and describe our understanding 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
The version number field in the IP header did not help much in
incremental introduction of IPv6 deployment.
History of IP address space design: IPv3 used a variable length
encoding of IP addresses (IEN28, February 1978), which was changed to
fixed length due to the implementers complaints that "it would be too
complex to parse the variable length header" and demanded a fixed
length header so they did not have to work their way through the
header. In retrospect, after we saw the cost of IPv6 deployment, it
is no longer clear the choice of fixed length is a good design choice
at that time.
Afanasyev, et al. Expires September 30, 2015 [Page 8]
Internet-Draft ICN Packet Format Design Requirements March 2015
BGP stays with BGP4 after adopting TLV encoding.
Technology moves forward fast, this is an important design factor to
be considered in ICN packet format design.
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.
Afanasyev, et al. Expires September 30, 2015 [Page 9]
Internet-Draft ICN Packet Format Design Requirements March 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.
[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 30, 2015 [Page 10]
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 30, 2015 [Page 11]
