Internet DRAFT - draft-stapp-icnrg-ndn-msg-comparison
draft-stapp-icnrg-ndn-msg-comparison
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]
