[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
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
                                                           March 9, 2015

                 ICN Packet Format Design Requirements


   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

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

   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

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

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


   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


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
   4809 Boelter Hall, UCLA
   Los Angeles, CA  90095

   Email: afanasev@cs.ucla.edu

   Ravishankar Ravindran
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: ravi.ravindran@huawei.com

   Guoqiang Wang
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: gq.wang@huawei.com

   Lan Wang
   University of Memphis
   318 Dunn Hall
   Memphis, TN  38152

   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

   Phone: +1 520 621 4817
   Email: bzhang@cs.arizona.edu

   Lixia Zhang
   3713 Boelter Hall, UCLA
   Los Angeles, CA  90095

   Phone: +1 310 825 2695
   Email: lixia@cs.ucla.edu

Afanasyev, et al.      Expires September 10, 2015              [Page 10]