Internet DRAFT - draft-stapp-icnrg-ndn-msgs
draft-stapp-icnrg-ndn-msgs
ICNRG M. Stapp
Internet-Draft Cisco Systems, Inc.
Intended status: Experimental January 8, 2015
Expires: July 12, 2015
NDN Message Format Proposal
draft-stapp-icnrg-ndn-msgs-00
Abstract
This memo defines an on-the-wire format for Named-data Networking
(NDN) protocol messages. NDN packets begin with a fixed-size header.
After the header, the remainder of the message is composed of type-
length-value (TLV) tuples. The Type and Length fields use a compact,
fixed-size encoding scheme. The TLVs for message attributes that are
standardized are defined in a registry. Part of the TLV number-space
is reserved for standardized attributes. Other parts of the number-
space are set aside for experimental use.
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
Stapp Expires July 12, 2015 [Page 1]
Internet-Draft NDN Message Format Proposal January 2015
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.
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. NDN Packets and Messages . . . . . . . . . . . . . . . . . . 4
2.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Packet Header Options . . . . . . . . . . . . . . . . . . 7
2.3. NDN Names . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Vendor-specific TLVs . . . . . . . . . . . . . . . . . . 9
2.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Interest Packets . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Message Header . . . . . . . . . . . . . . . . . . . . . 10
3.2. TLV Section . . . . . . . . . . . . . . . . . . . . . . . 10
4. Data Packets . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Message Header . . . . . . . . . . . . . . . . . . . . . 11
4.2. TLV Section . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Data Signatures . . . . . . . . . . . . . . . . . . . . . 11
5. Nack Packets . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Packet Header . . . . . . . . . . . . . . . . . . . . . . 13
5.2. TLV Section . . . . . . . . . . . . . . . . . . . . . . . 13
6. NDN TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. NDN Name . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. ContentData . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Certificate . . . . . . . . . . . . . . . . . . . . . . . 14
6.4. PublisherPublicKeyDigest . . . . . . . . . . . . . . . . 14
6.5. PublisherPublicKeyName . . . . . . . . . . . . . . . . . 14
6.6. ContentDigest . . . . . . . . . . . . . . . . . . . . . . 14
6.7. PublicKey . . . . . . . . . . . . . . . . . . . . . . . . 15
6.8. KeyName . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.9. Signature . . . . . . . . . . . . . . . . . . . . . . . . 15
6.10. SignatureBits . . . . . . . . . . . . . . . . . . . . . . 15
6.11. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 15
6.12. Witness . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.13. DigestAlgorithm . . . . . . . . . . . . . . . . . . . . . 16
6.14. ContentExpiration . . . . . . . . . . . . . . . . . . . . 16
6.15. CacheTTL . . . . . . . . . . . . . . . . . . . . . . . . 16
6.16. TLV Type Codes . . . . . . . . . . . . . . . . . . . . . 16
7. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Message Header Number Assignments . . . . . . . . . . . . 17
7.2. Flag Bit Assignments . . . . . . . . . . . . . . . . . . 17
7.3. Error Code Assignments . . . . . . . . . . . . . . . . . 17
Stapp Expires July 12, 2015 [Page 2]
Internet-Draft NDN Message Format Proposal January 2015
7.4. TLV Number Ranges . . . . . . . . . . . . . . . . . . . . 17
8. The CCNx Scheme . . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Normative References . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. 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
packet which names an object. No destination address is present: the
network routes the Interest based on the name it carries. When a
device - a server, a cache engine, or a router with built-in storage
- determines that it can satisfy the Interest, it replies with a Data
packet containing a Content object, and a cryptographic signature.
No source address is present in any message - the network maintains
sufficient state to route a Data packet back to the client. This
model gives an NDN network a number of attractive properties, and NDN
approaches have attracted interest from the networking research
community over the last couple of years.
NDN researchers have proposed a wide range of infrastructure and
network services. This memo attempts to describe a somewhat limited
baseline that can form the basis for more complex and sophisticated
services. The baseline is composed of the fundamental packet
transport definition, a set of mandatory-to-implement TLVs, and a
definition of the basic security mechanisms.
The work required to process each NDN packet at each network node
(router) differs significantly from IP datagram handling. Each NDN
router must examine the variable-length name in order to make
forwarding decisions. Each NDN router must maintain state in order
to be able to correlate Data packets from 'upstream' with
'downstream' clients; other data in packets may also need to be
processed in order to support this requirement. Some routers may
verify the signatures on some or all Data messages, as a means of
detecting spoofing attempts. Some routers may cache Content objects;
the network infrastructure itself becomes capable of acting as a
distributed cache for popular or valuable data. The obligation to be
stateful offers routers the opportunity to take an active role in
congestion control. For all of these reasons, an efficient, clear
NDN message encoding is central to the success of the overall NDN
architecture.
Stapp Expires July 12, 2015 [Page 3]
Internet-Draft NDN Message Format Proposal January 2015
An NDN packet begins with a small header area; the body of the
message is mainly composed of TLV tuples. The Name TLV always
appears first in the message, so it's easy to locate in any message.
All TLVs contain a length field, so routers and applications can
navigate through messages efficiently. The TLV type-code number-
space is divided into several ranges: a range for standardized
attributes, a range for vendor-specific use, and a range for
experimental use.
This is still very much a work-in-progress. There are plenty of
TODOs, including:
o I've tried to develop a minimal set of TLVs and behavior: have I
left out something crucial to a baseline client?
o Details of content signature computation and verification
o I've avoided discussion of other control or hop-by-hop messages
(if any), OAM, neighbor discovery/adjacency establishment, etc.
1.1. Requirements Language
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. NDN Packets and Messages
At present, there are two NDN message types: the Interest message,
and the Data message. On the wire, an NDN message is carried in an
NDN packet, which includes a fixed-size packet header. There are
three types of NDN packets: Interest packets, Data packets and Nack
packets. Each packet type is discussed in detail below. All NDN
packets share several properties:
o Packets begin with a fixed-size header, including a protocol
version, the header size, and the size of the entire message
o Optional header type-length-value (TLV) tuples are available for
information designed for hop-by-hop processing
o After the packet header and header options, the message begins;
the message is itself a TLV
o The Name TLV always appears first within the message TLV
o TLVs may contain sub-TLVs
Stapp Expires July 12, 2015 [Page 4]
Internet-Draft NDN Message Format Proposal January 2015
o Each TLV includes the length of the entire TLV, even if sub-TLVs
are present
The NDN Packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ver | pkt type | packet-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hop lim | flags | error/resvd | hlen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
ver The protocol version. The current value is 1.
pkt type The packet type. The current packet types are
Interest (1), Content (2), Nack (3).
packet-size The number of octets in the packet, encoded
as a 16-bit integer in network byte-order.
hop lim A hop limit field, available for loop detection.
flags Header bitflags field.
error/ Reserved field; used for error return code in
reserved Nack packets.
hlen The number of octets in the header area,
including any header option TLVs.
All NDN packets begin with a protocol version and a packet-type. A
standards action is REQUIRED in order to increment the protocol
version or to assign a new packet-type. Routers MUST discard packets
with protocol versions they do not support. In general, we expect
that nodes may be able to process packets with some small range of
protocol versions. NDN nodes that do not understand how to process a
packet based on its version must discard the packet.
The NDN packet size is represented as a 16-bit integer in network
byte-order. At this point in the evolution of the NDN protocol, this
offers a reasonable range of sizes while allowing for a compact
Stapp Expires July 12, 2015 [Page 5]
Internet-Draft NDN Message Format Proposal January 2015
fixed-size representation. The packet-size field includes the size
of the header and all of the packet TLVs.
A one-octet hop-limit field is available for loop detection. Routers
MUST decrement the value by one before forwarding a message, and MUST
NOT forward a message whose hop limit has reached zero. The initial
hop limit value is still a topic of active discussion. We expect
that common-sense values like 64 or 128 will be recommended
eventually. Other loop detection schemes (such a Nonce value) may be
available through use of header options.
The flags field contains single-bit flags for use during hop-by-hop
processing.
TODO - define flags here, or below with assigned numbers?
The reserved field is used to carry an error or status code when an
Interest packet is returned as a Nack packet. The field is reserved
in other packet types at this time.
The header-length field contains the size of the entire header area.
This is essentially the offset of the Message TLV in the packet,
since the Message TLV always begins immediately after the packet
header area. The header-length permits use of variable-sized and
optional header option TLVs for a variety of purposes. Header
options are described below.
2.1. TLV Encoding
We propose a simple NDN TLV encoding that uses 2 octets for Type code
and 2 octets for TLV Length.
The TLV Type number space and initial assignments are specified in
Section 7.4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stapp Expires July 12, 2015 [Page 6]
Internet-Draft NDN Message Format Proposal January 2015
The TLV Length field contains the number of octets in the Value
field. This implies that a Length of zero may be valid for some TLV
Types. The specification of a TLV may include restrictions or
validation rules for the TLV's Length field.
DISCUSSION:
We feel that this encoding offers a reasonable balance between
efficiency and flexibility. More complicated variable-length
schemes introduce additional validation and processing complexity,
as well as canonicalization requirements. Are there use-cases
where this simple encoding is inadequate?
2.2. Packet Header Options
Header options offer information beyond that available in the fixed
header area. The header option facility supports experimentation
with various hop-by-hop processing extensions during this period of
NDN evolution. Header options are encoded as TLVs. The header
option type-codes use a dedicated number space, distinct from the
TLVs in the message body.
We propose several possible header option TLVs, for use with
alternative loop-detection methods and for Quality-of-Service (QOS)
marking. These seem to be viable candidates for experimentation with
hop-by-hop processing.
Nonce option example:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'Nonce' | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stapp Expires July 12, 2015 [Page 7]
Internet-Draft NDN Message Format Proposal January 2015
Diffserv option example:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'DSCP' | 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP bits |
+-+-+-+-+-+-+-+-+
Flow-label option example:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'Flow' | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3. NDN Names
Every NDN message, unsurprisingly, contains a Name TLV: the Name is
required for processing at each NDN node. NDN Names can contain
several types of information:
o Information needed to route an Interest towards a publisher
o Information about a specific object, such as a file name
o A segment or 'chunk' number, used when a client retrieves part of
a large data object
o Other standardized data that may be used by client/host stacks, or
during network processing.
o Application-specific or session-specific data that is meaningful
to applications running at the client and publisher.
NDN Names contain sub-TLVs, which demarcate the boundaries between
these various constituent components. Each 'label' in a publisher
name and each element in a filename is represented as a NameComponent
TLV, for example. The segment number is represented in a NameSegment
Stapp Expires July 12, 2015 [Page 8]
Internet-Draft NDN Message Format Proposal January 2015
TLV. By convention, the NameSegment appears last in the collection
of Name sub-TLVs.
DISCUSSION:
Is it really necessary to continue to force all of the information
in Interests into the Name? Wouldn't it be clearer to use the
Name only for publisher/routing info, object name info, and
segment/sequence number? An InterestData or InterestAppData TLV
could hold any other data: session information, encrypted fields,
application-specific parameters that are not used in forwarding or
caching. There would be benefits there for the routers, who
wouldn't need to process data in the "Name" that are entirely
unrelated to the forwarding or cacheing functions. Currently, the
routers incur processing cost for both Interest and Content
messages when large Name fields are present. App session data
wouldn't often be cacheable in any case: it would likely be
encrypted with a session key. The Name would still need to be
unique, but that could be accomplished with a single NameComponent
containing ... a timestamp and a random number, or a (reasonably
strong) hash value.
2.4. Vendor-specific TLVs
A vendor or industry group can introduce its own NDN TLV space using
the vendor-specific encapsulation TLV with type code
NDN_TLV_VendorSpecific (Section 7.4). The VendorSpecific TLV MUST
contain a vendor identifier in the NDN_TLV_VendorId (Section 7.4)
TLV. Any other contents of the container TLV are determined by the
organization identified. Typically these will be further TLVs -
that's our recommendation - but that is not mandatory. The VendorId
must be unique and controlled by the organization using this
mechanism. Example VendorIds include an OID, or a DNS name. The
VendorId TLV must occur first in the VendorSpecific contents:
implementations have to be able to decode the identifier in order to
determine whether they can proceed and decode the remainder of the
TLV's data.
2.5. Examples
TODO -- add a couple of encoding examples.
3. Interest Packets
Stapp Expires July 12, 2015 [Page 9]
Internet-Draft NDN Message Format Proposal January 2015
The NDN Interest packet is specified as:
INTEREST-PACKET := PACKET-HEADER
INTEREST-TLV
NAME-TLV [ NDN-TLV ... ]
PACKET-HEADER := Common packet header area defined above, with
packet-type == Interest
INTEREST-TLV := NDN-TLV with Type == InterestMessage
NAME-TLV := NDN-TLV with Type == Name
3.1. Message Header
TODO -- brief overview; describe any special header options
3.2. TLV Section
The Name TLV is always the first TLV inside the message TLV; this
allows network nodes to find the Name easily. Another TLV that is
processed at network nodes is the InterestLifetime. Note that we
have specified the units used in the InterestLifetime as
milliseconds. Nodes should validate any InterestLifetime value
presented by a client: we'd expect that routers would have maximum
and minimum lifetime values that would bound the lifetime values in
Interest messages.
DISCUSSION:
We propose an Interest message simpler than the CCNx 0.x scheme.
The selectors such as Min- and MaxSuffixComponents, Exclude bloom
filter, ChildSelector, etc. are all ... excluded. Routers perform
prefix-based matching on Names as they examine their FIBs, and
exact-match in their PITs and CSes. Applications that want to
offer complex query syntax or filtering need to use application-
specific data for those purposes. See Section 2.3 for some
discussion about arbitrary application data in Interests.
4. Data Packets
Stapp Expires July 12, 2015 [Page 10]
Internet-Draft NDN Message Format Proposal January 2015
The NDN Data packet is specified as:
DATA-PACKET := PACKET-HEADER
DATA-TLV
NAME-TLV [ NDN-TLV ... ]
PACKET-HEADER := Common packet header area defined above, with
packet-type == Data
DATA-TLV := NDN-TLV with Type == DataMessage
NAME-TLV := NDN-TLV with Type == Name
4.1. Message Header
TODO -- describe any header options etc.
4.2. TLV Section
The Name TLV must be present, and must be the first child of the Data
message TLV.
The Data message contains an opaque blob of data in the ContentData
TLV accompanied by a cryptographic signature. We propose continuing
to use the CCNx approach here, with a few adjustments:
o We allocate new TLV type codes for name information used in the
KeyLocator's KeyName, rather than reusing the message-level Name
TLVs.
o The Timestamp is specified to use units of milliseconds.
o For multi-segment content objects, the FinalSegmentID must be
present in every Content message.
4.3. Data Signatures
TODO -- Each Data message contains a digital signature. This section
describes the process used to produce an NDN signature, encode it in
a Data packet payload, and verify it at another node.
5. Nack Packets
Stapp Expires July 12, 2015 [Page 11]
Internet-Draft NDN Message Format Proposal January 2015
The NDN Nack packet is specified as:
NACK-PACKET := PACKET-HEADER
INTEREST-TLV
NAME-TLV [ NDN-TLV ... ]
PACKET-HEADER := Common packet header area defined above, with
packet-type == Nack
INTEREST-TLV := NDN-TLV with Type == InterestMessage
NAME-TLV := NDN-TLV with Type == Name
We believe that error-signalling offers value for NDN routers and for
NDN end clients. We only specify a mechanism for errors resulting
from routers' processing of Interest messages. NDN routers must
maintain state about Interests they have forwarded, and they may be
able to take advantage of that state to aid in congestion management
and traffic engineering. When a node determines not to forward an
Interest, it MAY generate an error message. It is possible to
transform the original Interest packet into an error packet in a very
direct way: the receiving node changes the packet-type to Nack, sets
the packet header error code field to indicate the specific error
encountered, and transmits the packet out the face on which the
Interest arrived.
This error message offers a basic level of value to other routers
and, potentially, to the original client application or protocol
stack. Routers on the return path are able to clear their PIT state,
without waiting for a timeout. Routers may be able to attempt to re-
route the original Interest if they have alternative forwarding paths
available. A router can re-produce the original Interest simply
clearing the error information from the header and re-transmitting
it. A router that does not re-route an Interest after receiving an
error may propagate the error by forwarding the Nack packet out the
face associated with its entry for the Interest in its own PIT.
TODO: should that 'may' be a 'should'?
As the NDN routers propagate a Nack packet, it can make its way along
the path from the node encountering an error back to the original
client. The basic error message helps the client manage its own
sense of the state of the network, identifying congestion issues or
NDN names experiencing reachability problems.
The error response to an Interest can also include a hint about the
name prefix where the error condition was detected. We expect that
the NDN router detecting an error may have a more-specific FIB entry
Stapp Expires July 12, 2015 [Page 12]
Internet-Draft NDN Message Format Proposal January 2015
than routers farther away. An NDN router should include a header
option containing the number of name components in its FIB entry that
most-closely matched the Interest's name. This hint may allow a
router along the path the error will traverse back to the client to
attempt to re-route the Interest if it has an alternative path. The
name-prefix hint may also be useful to the original client stack (if
the error propagates that far).
NDN routers have to be careful not to allow malicious clients to
inject fabricated error messages. An NDN Router must only accept or
propagate error messages that arrive via faces associated with
neighboring routers, and must not process or propagate an error
message that does not match an entry in its PIT.
DISCUSSION:
There are some concerns about introducing a new Error or Nack
message-type; some might feel that that threatens the NDN
architectural principle permitting only Interest and Data
messages. But ... it seems clearer than overloading either of the
existing message types, so I'd like to offer it for discussion.
5.1. Packet Header
The Nack packet header includes a field that carries a specific error
code. Some
5.2. TLV Section
The Nack message echoes back the Interest TLV message that provoked
an error.
6. NDN TLVs
TODO -- add a nice tidy table with info about which T codes can or
can't appear in Interest vs Content messages.
'Freshness' vs. 'ContentExpiration': one is an interval, one an
explicit wall-clock time.
TODO better spec of signing procedure -- 'SignedFlags' -- allow the
sender to include flags that can be signed?
6.1. NDN Name
The NDN Name is represented as a series of NameComponent TLVs inside
a Name TLV. The contents of each NameComponent are opaque octets.
Stapp Expires July 12, 2015 [Page 13]
Internet-Draft NDN Message Format Proposal January 2015
Large data items are transmitted using multiple Interest,Content
exchanges for a single name. The NameSegment TLV carries an integer
that is appended to the name to identify a specific sub-section of
the data. The NameSegment data is a four-byte integer in network
byte order. If a NameSegment sub-TLV is present, it must be the last
sub-TLV in the Name TLV. More than one NameSegment sub-TLV must not
be present in a Name TLV.
TODO -- are four bytes enough: might there be very large files that
are presented as very many 1KB or 4KB or 8KB messages? we could a)
add a bigger TLV later, b) add a second 'generation' field that
expands the range of the segment tlv, or c) specify the segment tlv
to be eight bytes from the start.
6.2. ContentData
The data in a Content message is represented as an opaque blob in a
ContentData TLV. The data is application-specific.
6.3. Certificate
Seems like something that should be supported - ccnx (0.6x) just
bails. We'll need this...
6.4. PublisherPublicKeyDigest
The PublisherPublicKeyDigest identifies the content publisher that
signed the content data. The value is a SHA-256 digest of the public
key of the publisher. This TLV must be present in each Content
message. Its use in signatures and verification is described in
Section 4.3.
6.5. PublisherPublicKeyName
The PublisherPublicKeyName identifies the content publisher that
signed the content data. The value is an NDN Name that can be used
to retrieve the publisher key used to sign a Content object. Its use
in signatures and verification is described in Section 4.3.
6.6. ContentDigest
The ContentDigest TLV is optional in Content messages. If present,
it contains the SHA-256 hash of the contents of the ContentData TLV,
including the TLV Type and Length.
Stapp Expires July 12, 2015 [Page 14]
Internet-Draft NDN Message Format Proposal January 2015
6.7. PublicKey
The PublicKey TLV is optional in Content messages. If present, it
contains a public key corresponding to the private key used to sign
the ContentData. Its use in signatures and verification is described
in Section 4.3.
6.8. KeyName
The KeyName TLV is optional in Content messages. If present, it
contains an NDN name that can be used to retrieve keying information
that can in turn be used to verify the signature of the ContentData.
If present, the KeyName TLV only contains KeyNameComponent sub-TLVs.
At least one KeyNameComponent TLV must be present in a KeyName TLV.
Its use in signatures and verification is described in Section 4.3.
6.9. Signature
The Signature TLV is a container for other TLVs that carry actual
content signature data. The use of a container TLV also allows NDN
nodes to skip past a group of related signature data TLVs efficiently
if the node is not validating a particular signature. The container
may also allow multiple signatures to be present, which may be useful
in key agility or crypto algorithm agility. See Section 4.3 for
details about content signatures.
6.10. SignatureBits
The SignatureBits TLV contains the actual digital signature in a
Content message. See Section 4.3 for details about content
signatures.
6.11. Timestamp
TODO -- what's the signed timestamp really for - what does it add? it
gets stuck into the 'ccn_btree_content_payload' struct, but not used?
and no one in ccnx seems to use the DTAG_Timestamp in their
templates, so...
6.12. Witness
TODO -- should we allocate the code-point for Merkle info,
explicitly? then any future "extra" info would also get explicit
types...
Stapp Expires July 12, 2015 [Page 15]
Internet-Draft NDN Message Format Proposal January 2015
6.13. DigestAlgorithm
TODO -- default to sha-256. should we allocate more values?
6.14. ContentExpiration
TODO -- prefer to have an absolute expiration time available, seems
like it would be useful in some cases?
6.15. CacheTTL
TODO -- ccnx's "freshness" acts like a cache TTL, seems worth
keeping, maybe we should just ... give it a clearer name? and prefer
less eccentric units: is seconds good enough? do we need millisecond
resolution (really?)
6.16. TLV Type Codes
enum ndn_tlv_e {
NDN_TLV_Name = 1,
NDN_TLV_NameComponent = 1,
NDN_TLV_NameSegment = 2,
NDN_TLV_ContentData = 4,
NDN_TLV_Certificate = 5,
NDN_TLV_SignedInfo = 6,
NDN_TLV_ContentDigest = 7,
NDN_TLV_PublicKey = 8,
NDN_TLV_KeyName = 9,
NDN_TLV_KeyNameComponent = 1,
NDN_TLV_Signature = 10,
NDN_TLV_Timestamp = 11,
NDN_TLV_Witness = 12,
NDN_TLV_SignatureBits = 13,
NDN_TLV_DigestAlgorithm = 14,
NDN_TLV_FinalSegmentID = 15,
NDN_TLV_PublisherPublicKeyDigest = 16,
NDN_TLV_PublisherPublicKeyName = 17,
NDN_TLV_ContentExpiration = 18,
NDN_TLV_CacheTTL = 19,
NDN_TLV_VendorSpecific = 20,
NDN_TLV_VendorId = 21
};
7. Assigned Numbers
Stapp Expires July 12, 2015 [Page 16]
Internet-Draft NDN Message Format Proposal January 2015
7.1. Message Header Number Assignments
The protocol Version is 1.
The Packet Types are Interest (1), Content (2), and Nack (3).
7.2. Flag Bit Assignments
One flag is defined for the Flags field in the Content message:
NoCache (0x01). This flag is a hint to routers and caches that the
message is not suitable for cacheing (a real-time interactive
exchange for example.)
7.3. Error Code Assignments
Several Error-code values are defined for the Nack message: NOROUTE
(1), CONGESTED (2), NORESOURCE (3), POLICY (4). The NOROUTE error
indicates that an NDN node was unable to forward the original
Interest because it did not have a route to a publisher matching the
message's Name. The CONGEST error indicates that a node did not
forward the Interest because it detected congestion on the link
associated with the FIB entry that matched the Name. The NORESOURCE
error indicates that the node was unable to forward the Interest
because of a shortage of internal resources. The POLICY error
indicates that local administrative policy prevented further
processing of the Interest.
7.4. TLV Number Ranges
The standardized Type-code number space is partitioned into three
regions:
1. Type code zero is reserved and must not be used.
2. Standardized values from 1 to 0x7fff
3. Experimental values from 0x8000 to 0xffff
The vendor-specific TLV mechanism in Section 2.4 allows
implementations additional flexibility.
8. The CCNx Scheme
The CCNx project at PARC [TODO citation] has made a significant
investment in an on-the-wire scheme, from which the community has
learned a great deal. Subsequent experimentation has identified a
number of drawbacks to the CCNx scheme that have led us to reconsider
some of their choices. We aren't making an exhaustive analysis of
Stapp Expires July 12, 2015 [Page 17]
Internet-Draft NDN Message Format Proposal January 2015
the CCNx scheme here, but it seems useful to list some of the key
points.
o Inconsistent location of the NDN Name
o Ambiguous use of Name-components (within the Name) for multiple
purposes
o Inefficient "versioning" and "meta-data" protocol extensions
o Inefficient double-layer encoding
o Confusion between data needed to operate the NDN protocol and
application-specific functions
o Multiple encodings for integers, timestamps, etc.
o Reliance on specific byte-values within TLV values for critical
protocol control functions
o Issues producing error messages in response to Interests
9. Acknowledgements
TODO -- acknowledge some folks here...
10. IANA Considerations
All drafts must have an IANA section. This memo includes no requests
to IANA.
11. Security Considerations
TODO -- point back to signature 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
Stapp Expires July 12, 2015 [Page 18]
Internet-Draft NDN Message Format Proposal January 2015
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 19]
