ICNRG M. Stapp Internet-Draft Cisco Systems, Inc. Intended status: Experimental January 8, 2015 Expires: July 12, 2015 NDN Message Format Comparison draft-stapp-icnrg-ndn-msg-comparison-00 Abstract Several on-the-wire formats have been proposed for Named-data Networking (NDN) protocol messages. This memo compares the properties of four of these proposals, attempting to provide a framework for discussion and eventual consensus. 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 July 12, 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. Stapp Expires July 12, 2015 [Page 1] Internet-Draft NDN Message Format Comparison January 2015 This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Table of Contents 1. Requirements Terminology . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Base TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 3 4. Message Header . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. ALU . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. PARC . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 6 5. Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. ALU . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.4. PARC . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 6. Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 7. Nack Message . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 8. Mutable Fields . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 12. Normative References . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Introduction Named-data Networking (NDN) [TODO cite Van], one of a family of Information-centric Networking protocols, proposes the replacement of IP's endpoint-to-endpoint communication model with one centered around named objects. In NDN networks, a client issues an Interest message that names an object. No destination address is present: the network routes the Interest message based on the name itself. When a device - a server, a cache engine, or a router with built-in storage Stapp Expires July 12, 2015 [Page 2] Internet-Draft NDN Message Format Comparison January 2015 - determines that it can satisfy the Interest, it replies with a Data message containing some data and a cryptographic signature. No source address is present in any message - the network maintains sufficient state to route a Data message back to the client. This model gives an NDN network a number of interesting properties, and NDN approaches have attracted interest from the networking research community in recent years. This memo examines four message format and encoding proposals from four different organizations: Alcatel/Lucent (ALU), Cisco, the NSF/ FIA NDN project team (NDN), and Xerox PARC. This memo's goal is to summarize these proposals, and suggest some general questions as a way of encouraging focussed discussion. For reference, I've used the ALU slides presented at IETF89, draft- stapp-ndn-messages-02, the NDN project website at http://www.named- data.net, and the CCNX 1.0 project documents available at http://www.ccnx.org. Any mis-representations are accidental. 3. Base TLV Encoding All of the proposals define basic message encodings that use TLV tuples. ALU: T+L support for 1+1, 1+2, 2+1, 2+2; reserves first 2 MSB bits of the T for discriminator, so that's really in bits: 6+8, 6+16, 14+8, 14+16. Cisco: T+L fixed size 2+2 only. NDN: T+L support for [1,3,5,9]+[1,3,5,9]; three reserved values in the first octet of each T and L indicate size, so single-octet T or L is limited to 252 values. PARC: T+L fixed size: 2+2 only. 3.1. Discussion Some discussion questions: 1. Is support for more than 16 bits for T or L important? 2. Is support for single-octet T or L important? 3. Is the complexity of variable-length encoding worthwhile? 4. What are the tradeoffs between variable-length encoding and aliasing risk? Stapp Expires July 12, 2015 [Page 3] Internet-Draft NDN Message Format Comparison January 2015 5. Are there specialized environments with very limited message sizes, or very limited processing capabilities, where an extremely compact encoding may be useful? Do we have to _start_ there, or can we formulate that alternative when we understand the environments better? 4. Message Header The ALU and PARC message proposals include fixed-size headers for each message. The proposals are distinct, though, with several different properties. We try to summarize the proposals here. 4.1. ALU ALU proposes an eight-octet fixed header for Interest messages and for Data messages. The Name field follows the fixed header. A ttl field is included for loop detection. ALU Message header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg | ttl | message-size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | hdr len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name | . . . . . . 4.2. Cisco Cisco proposes a fixed packet header used for all packet types. A hop-by-hop options area follows the fixed-size area. The packet carries a message TLV, then the Name TLV is the first child TLV in the message. Any other TLVs follow the Name. The packet header includes a hop limit for loop detection. Stapp Expires July 12, 2015 [Page 4] Internet-Draft NDN Message Format Comparison January 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ver | pkt type | packet-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hop lim | flags | err code/resv | hlen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-hop TLVs | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg type | msg len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name | . . . . . . 4.3. PARC PARC proposes an eight-octet fixed header for all CCNX packets. PARC also proposes a variable-length header-options area for hop-by-hop options; the size of the header-options area is included in the overall header length field. A CCNX message follows the header- options area (if present). The first TLV within the message must be the Name TLV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ver | pkt type | packet-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | hdr len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-hop TLVs | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg type | msg len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name | . . . . . . Stapp Expires July 12, 2015 [Page 5] Internet-Draft NDN Message Format Comparison January 2015 4.4. NDN NDN does not propose any fixed-size header. The entire NDN "packet" (Interest or Data) is itself a single TLV. The Name TLV is always the first child TLV within the overall packet TLV. The NDN proposal requires a Nonce TLV in Interests. 4.5. Discussion Some discussion questions: 1. What are the tradeoffs in using fixed message headers? 2. Is the Nonce valuable enough to be mandatory? And ... does it even work? 3. If fixed headers are used, is it better to have a single consistent header, or per-message-type headers? 4. If fixed headers are used, is it useful to include the possibility of hop-by-hop options? 5. The PARC inner message proposal offers some interesting properties: is this kind of 'encapsulation' something that should be supported as part of the base definition? 5. Name The message format proposals contain significant differences in their encodings of Names. 5.1. ALU The ALU proposal represents the entire Name as a single flat TLV. There are no name-component separators of any kind within the actual Name TLV. Optional additional TLVs are defined to hold offsets of name-components within the actual Name. Another optional TLV is defined to carry the offset of the segment value within the Name. A node that needs to parse the Name must parse these additional TLVs. The offset TLVs carry only offsets - there are no typed name components. The offset TLVs are optional: if they are not present, nodes cannot parse the Name components at all. 5.2. Cisco The Cisco proposal encodes the Name as a TLV with typed child TLVs for the name components. Cisco suggests a number of name-component type codes, including segment number and version. The proposal Stapp Expires July 12, 2015 [Page 6] Internet-Draft NDN Message Format Comparison January 2015 reserves a range of name-component type code points for application- specific use. 5.3. NDN The NDN proposal encodes the Name as a TLV with generic NameComponent child TLVs for the name components. NDN reserves several values within a name component - within the value itself - as 'markers' that identify certain important components. Marker values are reserved for segment number, version, byte-offset, collection sequence number, and timestamp. 5.4. PARC The PARC proposal encodes the Name as a TLV with typed sub-TLVs for the name components. PARC suggests a number of name-component type codes, including serial number, timestamp, segment number, content object hash. The proposal reserves a range of name-component type code points for application-specific use. 5.5. Discussion 1. Can information about the boundaries of name components be optional? What would the system look like if no name components were present? For example, would there be aliasing problems in FIB prefix-matching? 2. Is it useful to identify specific name component types? What alternatives exist to provide commonly-used information such as segment number? 3. Is it viable to depend on the data bytes within name components to signal their purposes? Are there aliasing issues between application-specific binary data and the use of 'marker' octets? 6. Selectors PARC and NDN both include various 'selectors' for Interest messages. Selectors are data that act as filters or query parameters that affect the matching behavior at network nodes. An example might be an Interest carrying a selector that specifies a specific producer key identifier. Routers would be expected to filter potential matches so that only cached content using the specified producer key would be returned. Stapp Expires July 12, 2015 [Page 7] Internet-Draft NDN Message Format Comparison January 2015 6.1. Discussion 1. Would the presence of selectors introduce any packet encoding issues? Is there any reason that selectors could not be represented with TLVs, for example? 7. Nack Message Several different groups have suggested adding a way to convey network error information. Cisco and PARC propose adding a distinct, new NACK packet type, rather than overloading one of the existing message types. Example use-cases include congestion notification, and 'no-route' notification. 7.1. Discussion 1. Are there any implications for packet encoding introduced by this kind of messaging? 2. Is there any reason this kind of messaging would not be able to use, or would be compromised in some way by, the kind of packet encoding used for Interest and Content messages? 8. Mutable Fields Another potential question concerns data that may be changed hop-by- hop. A couple of examples might be a hop-count field, modified at each hop, and a QOS specification field, which might be re-marked or removed at an administrative boundary. 8.1. Discussion 1. Are there any implications for packet encoding introduced by mutable fields? Is there a need for a special format of any kind when this kind of data is present? 2. Is the 'header options' area a viable approach to this issue? Is there an alternative? 9. Acknowledgements TODO -- acknowledge some folks here... 10. IANA Considerations All drafts must have an IANA section. This memo includes no requests to IANA. Stapp Expires July 12, 2015 [Page 8] Internet-Draft NDN Message Format Comparison January 2015 11. Security Considerations All drafts must have a security considerations section. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Mark Stapp Cisco Systems, Inc. 55 Cambridge Pkwy. Cambridge, MA 02142 USA Phone: +1 978 936 0000 Email: mjs@cisco.com Stapp Expires July 12, 2015 [Page 9]