idnits 2.17.1 draft-icn-packet-format-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3329 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-mosko-icnrg-ccnxsemantics-00 -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '11') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '12') (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group A. Afanasyev 3 Internet-Draft UCLA 4 Intended status: Informational R. Ravindran 5 Expires: September 10, 2015 G. Wang 6 Huawei Technologies 7 L. Wang 8 University of Memphis 9 B. Zhang 10 University of Arizona 11 L. Zhang 12 UCLA 13 March 9, 2015 15 ICN Packet Format Design Requirements 16 draft-icn-packet-format-requirements-00 18 Abstract 20 It is a great challenge to design the right packet format for the 21 Information-Centric Networking (ICN), because this new architecture 22 is still in its research stage. We do not have good prediction 23 regarding either the technology advances or the application needs may 24 involve in next 10 years. To minimize the chance of premature 25 constraints in the packet format design, we believe it is important 26 to first clearly identify the design requirements, so that we can use 27 the requirements to guide the design effort. In this document we 28 describe our understanding of the design requirements and their 29 tradeoffs. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 10, 2015. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Requirements for ICN Packet Format Design . . . . . . . . . . 3 67 2.1. Universality (Elasticity) . . . . . . . . . . . . . . . . 3 68 2.2. Flexibility and Extensibility . . . . . . . . . . . . . . 4 69 2.3. Processing Efficiency . . . . . . . . . . . . . . . . . . 4 70 2.3.1. Decoding and Encoding Efficiency . . . . . . . . . . 5 71 2.3.2. Continuity of Security Envelope . . . . . . . . . . . 5 72 2.3.3. Preservation of Network-Level Processing . . . . . . 5 73 2.4. Auditability / Robust Design . . . . . . . . . . . . . . 6 74 3. Separate Classes of Information (Functions) in ICN: 75 Information-Centric and Multi-Hop Forwarding . . . . . . . . 6 76 4. ICN Packet Format Success Factors (A Few Lessons from Today's 77 Internet) . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 6. Informative References . . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 The proposed Information-Centric Networking (ICN) architectures 85 (TRIAD [4], DONA [5], NDN [6] [7] [8] [3], CCNx [9], and others) put 86 forward an objective to become a new universal narrow waist for local 87 and global communication. However, all these proposals are still in 88 research stage with many details yet to be specified, many questions 89 yet to be answered, and many more issues yet to be identified and 90 resolved through experimentation. 92 It is a great challenge to design the right packet format for ICN 93 that can satisfy all desired research goals including both that have 94 been identified now and those that may appear in the future. This 95 document is our first attempt to formalize the general requirements 96 for the ICN packet format design by leveraging past experience and 97 following the framework defined in [1]. Clearly identifying the 98 design requirements can help guiding the decision process in 99 evaluating design tradeoffs and avoiding premature constraints. We 100 do not discuss any specific packet format proposals in this draft, 101 instead our focus is on identifying fundamental requirements of the 102 format, and on understanding different design tradeoffs. 104 Some of the requirements listed in Section 2 may conflict with each 105 other; how to prioritize such conflicting requirements determines the 106 outcome of the packet format design. In this draft we list our 107 identified requirements and put them in a priority order as the best 108 match to the current and future needs of ICN protocols as we can see 109 at this time. We hope that this draft contributes to the ongoing 110 discussion about ICN packet format design. 112 2. Requirements for ICN Packet Format Design 114 This section presents an ordered list of identified requirements for 115 the ICN packet format. In each sub-section we briefly describe 116 potential design space that satisfies the requirement and discuss the 117 tradeoffs between different design choices. 119 2.1. Universality (Elasticity) 121 As the new narrow waist of the Internet, the packet format must be 122 able to support a diversity of usage scenarios and underlying network 123 technologies: from highly constrained IoT environments [2] to ultra 124 high-speed network channels [13]. 126 A single IP packet format has served us well in the past. However, 127 continued expansion of Internet usage frontier in recent years has 128 shown the constraints of the existing IP packet formats. As one 129 example: due to its fixed length and limited size, the shortage of 130 IPv4 address space called for the design and deployment of IPv6; 131 although the design has long been done, the deployment is slow in 132 coming. As another example, the design of IPv6 format provides 133 sufficiently large address space for foreseeable future, but it leads 134 to the concerns of excessive overhead when used in emerging low-power 135 network environment (IoT), which were not foreseen in early 1990s 136 when IPv6 design was sketched out. In turn, IETF had to launch 137 6LoWPAN effort to address the issue. 139 These observations suggest us to avoid similar issues in the ICN 140 format design. We would like to see the ICN packet format to allow 141 applications to choose their packet size in whichever way as they see 142 fit, from a few tens of bytes in constrained environments to 143 jumbograms to take advantage of future high capacity transport and 144 increase in network MTU capability. The way to achieve this goal is 145 to ensure that packet length (and optionally lengths of packet format 146 fields) is encoded as a variable length number (variable-length 147 encoding or alternative encodings for different packet lengths). 149 2.2. Flexibility and Extensibility 151 Given the experimental nature of the ongoing ICN architectural 152 research, the packet format should stay flexible in providing ability 153 to add new elements to the format, as well as to remove elements that 154 are no longer deemed necessary. The required fields in the packet 155 format should also be kept as minimal as possible. 157 BGP [10] is one of the successful protocols that has gone through a 158 series of evolutionary changes. ([TODO: cite other examples]) After 159 going through a few rapid version changes in its early days, BGP4 160 adopted the flexible protocol encoding format of type-length-value 161 (TLV), which allows BGP to encode new function by simply introducing 162 a new TLV block; old TLV blocks can be deprecated over time without 163 requiring a flag day or base protocol format alterations. 165 Thus the use of TLV encoding can offer the potential to provide 166 protocol flexibility and extensibility (as the current designs do 167 already). 169 Our past protocol design experience also shows that to ease the 170 introduction of new features, one should also encode the information 171 about desired actions to take by the entity which does not recognize 172 the newly defined feature. For example, optional TLVs in the 173 extension header of IPv6 [11] reserve first two bits of the type to 174 specify the action for routers to take when an unrecognized TLV is 175 encountered: skip over and continue processing or discard the packet. 176 Similarly, SCTP [12] reserves two bits to indicate the desired 177 processing for packets with unrecognized chunks. ICN packet format 178 can adopt a similar mechanism, either by reserving some bits from the 179 type field or by splitting the type space into different bins in 180 certain ways, assigning a type code to the bin based on the desired 181 actions to be taken by entities which do not recognize the new TLV 182 type. 184 2.3. Processing Efficiency 186 It is desirable to design the ICN packet format in a way that allows 187 efficient packet processing to the extent possible. However making 188 the format for processing efficiency often runs into conflict with 189 elasticity and flexibility requirements. For example, the latter 190 leads the format to contain variable parts, which in turn lead to 191 higher processing complexity. Similarly, if the packet format is 192 designed to contain a fixed part, that part becomes unchangeable, 193 without a global flag day for making the changes. 195 Furthermore, when we consider processing efficiency, we should not 196 constrain our thinking by either the currently available technology 197 or the currently understood implementation approach. History showed 198 us that technologies can advance quickly, especially when there are 199 high demands. New implementation approaches are also discovered over 200 time, providing efficient solutions to problems that once were 201 considered infeasible. For example, switching to classless inter- 202 domain routing (CIDR) created challenges for line rate router 203 implementations [TODO: cite], and that challenge was soon resolved. 205 Therefore, we believe the processing efficiency requirement on the 206 format design should be put at lower priority than the elasticity and 207 flexibility considerations (i.e., we should not sacrifice long-term 208 flexibility in the design for short-term efficiency gains). 210 The rest of this section discussions a few specific approaches to 211 improve processing efficiency. 213 2.3.1. Decoding and Encoding Efficiency 215 Decoding and encoding of ICN packet format should be as efficient as 216 possible. Packet format should allow partial decoding of the packet, 217 efficient access to individual fields, and efficient skipping over 218 unprocessed (e.g., application-defined or unrecognized) fields. It 219 is also desirable for the key fields needed to make packet forwarding 220 decision (e.g., name) to appear in the beginning of the packet. 222 2.3.2. Continuity of Security Envelope 224 Cryptographic operations should be defined over a continuous packet 225 block, containing one or multiple complete TLV elements. In other 226 words, the security envelope must be defined over a continuous 227 sequence of whole TLV elements. 229 2.3.3. Preservation of Network-Level Processing 231 Application-defined elements added to the packet format should not 232 increase routers' processing requirements. For example, when an 233 application adds custom elements into the packet format, these 234 elements must go to an application-specific group that is always 235 skipped by routers, or should be clearly separated from router- 236 processed elements and can be easily skipped without processing. 238 2.4. Auditability / Robust Design 240 Generally speaking, TLV-encoded packet format includes multiple 241 nested TLV blocks. To provide ability to audit packet encoding 242 without requiring full understanding of semantics of each nested TLV 243 level, it is highly desirable to assign unique type codes to each 244 element in the packet format that is processed by routers. In other 245 words, we would like to require unique type code assignment to all 246 network level TLV elements. This requirement may not apply to 247 vendor-specific or application-specific type codes, whether they may, 248 or may not reuse type code space. 250 One of the advantages of using unique type code assignment is 251 reduction of implementation errors. Unique types across multiple TLV 252 levels is also important for network traffic debugging tools similar 253 to tcpdump and wireshark: with unique type codes for all network- 254 level elements, implementation of those tools would be simple with 255 potential of decoding known TLV types at any level of nesting. When 256 the same type codes are reuse (at different TLV nesting levels), such 257 tools also can still be implemented, but potentially with increased 258 complexity, as it would be required to define semantical contexts for 259 each nested TLV block. 261 The tradeoff of the unique type code assignment is the coordination 262 required in ensuring the type code uniqueness when doing code 263 assignments. 265 3. Separate Classes of Information (Functions) in ICN: Information- 266 Centric and Multi-Hop Forwarding 268 In an ICN network, communication is performed using application-level 269 information units. Therefore, the primary function of ICN packet 270 format is to include all elements that are needed to describe and 271 secure the data and elements to describe request for the data, such 272 as data name, data name constraints, payload, security context, 273 security context constraints, application context, etc. Note that 274 these information-centric elements define the data as requested by 275 consumers and enable communication between ICN consumers and 276 producers in terms of the desired data. 278 At the same time, there is a separate class of elements (functions) 279 that may be needed to aid the information retrieval process (to guide 280 multi-hop packet forwarding function), but is not related to the 281 information itself. For example, hop limit element may be needed to 282 avoid information requests to uncontrollably loop inside the network; 283 nonce field in the requests may be needed to detect reception of the 284 same request multiple times for error reporting and loop detection; 285 QoS labels in requests can enable support for prioritization of 286 certain retrieval processes, etc. Note that all such elements are 287 volatile by nature and/or may be needed only in parts of the network. 289 Given the two separate classes of the elements, the question is how 290 should they be organized in the packet format: combine these classes 291 of elements under a single format or separate into two complementary 292 specifications. The question here: what actually is the narrow waist 293 of Information-Centric Networking? In principle, application-level 294 information and application-level requests for information is the 295 narrow waist in ICN, as it is minimally required element to enable 296 communication, e.g., between directly connected peers or between ICN 297 applications on the same node. However, when a multi-hop forwarding 298 is performed, additional elements may be necessary to improve 299 efficiency of information retrieval. 301 The two ways of enabling information-centric and multi-hop forwarding 302 functions in ICN packet format would define tradeoffs for 303 implementation, usability, and future extensibility. The combined 304 format may be simpler to implement, but may require inclusion of 305 unnecessary elements, e.g., when caching information inside the 306 network. The separated way gives flexibility of evolving the 307 underlying format for transport function, but creates a danger of 308 creation of multiple incompatible formats implementing the same 309 multi-hop forwarding function. 311 In this document we intentionally do not try to answer the question 312 of how to combine information-centric and transport-related elements 313 into the packet format. The goal of the document is to define a 314 framework to clearly understand the general requirements for the 315 packet format and define our position about the tradeoffs in the 316 design space. We hope that a set of agreed upon requirements can 317 provide a guideline to packet format design that can serve us many 318 years in the future. 320 4. ICN Packet Format Success Factors (A Few Lessons from Today's 321 Internet) 323 TODO 325 IP version number did not help much in introducing IPv6. 327 History of IP address space design: the choice of fixed length is not 328 a good design choice. 330 BGP stays with BGP4 after adopting TLV encoding. 332 Technology moves forward fast, this is an important design factor. 334 Given the diversity of the requirements, a single packet format may 335 not be able to satisfy to the full extent all of the listed 336 requirements. Depending on which requirement is prioritized, the 337 resulting design for the packet format would have different tradeoffs 338 between universality, flexibility, and efficiency. 340 5. Security Considerations 342 TODO 344 6. Informative References 346 [1] Clark, D., "The Design Philosophy of the DARPA Internet 347 Protocols", Proceedings of SIGCOMM'88, August 1988. 349 [2] "IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access 350 Control (MAC) and Physical Layer (PHY) Specifications for 351 Low-Rate Wireless Personal Area Networks", June 2011. 353 [3] NSF FIA project, NDN., "http://www.named-data.net/", 2010. 355 [4] Cheriton, D. and M. Gritter, "TRIAD: A new next-generation 356 Internet architecture", 2000. 358 [5] Koponen, T. and et al., "A data-oriented (and beyond) 359 network architecture", ACM SIGCOMM Computer Communication 360 Review, Vol. 37, No. 4, 2007. 362 [6] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 363 Briggs, N., and R. Braynard, "Networking named content", 364 Proc. of CoNEXT, 2009. 366 [7] Zhang, L. and et al., "Named data networking (NDN) 367 project", NDN Tech. Rep. NDN-0001, October 2010. 369 [8] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., claffy, 370 kc., Crowley, P., Papadopoulos, C., Wang, L., and B. 371 Zhang, "Named Data Networking", ACM Computer Communication 372 Reviews, July 2014. 374 [9] M. Mosko, , "CCNx Semantics, draft-mosko-icnrg- 375 ccnxsemantics-00", January 2015. 377 [10] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 378 Protocol 4 (BGP-4)", RFC 4271, January 2006. 380 [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 381 (IPv6) Specification", RFC 2460, December 1998. 383 [12] Stewart, R., "Stream Control Transmission Protocol", RFC 384 4960, September 2007. 386 [13] ITU-T, , "Interface for the Optical Transport Network 387 (OTN)", G.709 Recommendation, February 2012. 389 Authors' Addresses 391 Alexander Afanasyev 392 UCLA 393 4809 Boelter Hall, UCLA 394 Los Angeles, CA 90095 395 US 397 Email: afanasev@cs.ucla.edu 399 Ravishankar Ravindran 400 Huawei Technologies 401 2330 Central Expressway 402 Santa Clara, CA 95050 403 US 405 Email: ravi.ravindran@huawei.com 407 Guoqiang Wang 408 Huawei Technologies 409 2330 Central Expressway 410 Santa Clara, CA 95050 411 US 413 Email: gq.wang@huawei.com 415 Lan Wang 416 University of Memphis 417 318 Dunn Hall 418 Memphis, TN 38152 419 US 421 Email: lanwang@memphis.edu 422 Beichuan Zhang 423 University of Arizona 424 Gould-Simpson 723 425 Tucson, AZ 85721 426 US 428 Phone: +1 520 621 4817 429 Email: bzhang@cs.arizona.edu 431 Lixia Zhang 432 UCLA 433 3713 Boelter Hall, UCLA 434 Los Angeles, CA 90095 435 US 437 Phone: +1 310 825 2695 438 Email: lixia@cs.ucla.edu