Movatterモバイル変換


[0]ホーム

URL:


ContentsMenuExpandLight modeDark modeAuto light/dark, in light modeAuto light/dark, in dark modeSkip to content
NDN Packet Format Specification v0.3
Logo
NDN Packet Format Specification v0.3
Back to top

Type-Length-Value (TLV) Encoding

Each NDN packet is encoded inTLV format.NDN Interest and Data packets are distinguished by the type number in the first and outermost TLV0.

An NDN packet is mainly a collection of TLVs inside TLV0. Some TLVs may contain sub-TLVs, and each sub-TLV may also be further nested. A guiding design principle is to keep the order of TLVis deterministic, and keep the level of nesting as small as possible to minimize both processing overhead and chances for errors.

Note that NDN packet format does not have a fixed packet header nor does it encode a protocol version number. Instead the design uses the TLV format to provide the flexibility of adding new types and phasing out old types as the protocol evolves over time. The absence of a fixed header makes it possible to support packets of very small sizes efficiently, without the header overhead.There is also no packet fragmentation support at network level.Whenever needed, NDN packets may be fragmented and reassembled hop-by-hop[1].

Variable-Size Encoding for Type and Length

Note

The text below and that in theNDN TLV Encoding section are adapted from an earlier packet specification draft by Mark Stapp.

To minimize the overhead during early deployment and to allow flexibility of future protocol extensions to meet unforeseeable needs, both type (T) and length (L) take a variable size format.For implementation simplicity, both type and length take the same encoding format.

We define a variable-length encoding for numbers in NDN as follows:

VAR-NUMBER-1=%x00-FCVAR-NUMBER-3=%xFD2OCTETVAR-NUMBER-5=%xFE4OCTETVAR-NUMBER-9=%xFF8OCTET

Note

The formal grammar of the NDN packet format in this specification is given usingAugmented BNF for Syntax Specifications.

The first octet of the number either carries the actual number, or signals that a multi-octet encoding is present, as defined below:

  • If the first octet is less than or equal to 252 (0xFC), the number is encoded in that octet.

  • If the first octet is 253 (0xFD), the number is encoded in the following 2 octets, in network byte-order.This number must be greater than 252 (0xFC).

  • If the first octet is 254 (0xFE), the number is encoded in the following 4 octets, in network byte-order.This number must be greater than 65535 (0xFFFF).

  • If the first octet is 255 (0xFF), the number is encoded in the following 8 octets, in network byte-order.This number must be greater than 4294967295 (0xFFFFFFFF).

A number MUST be encoded using the shortest possible format.For example, the number 1024 is encoded as%xFD0400 inVAR-NUMBER-3 format, not%xFE00000400 inVAR-NUMBER-5 format.

NDN TLV Encoding

TLV encoding for NDN packets is defined as follows:

NDN-TLV=TLV-TYPETLV-LENGTHTLV-VALUETLV-TYPE=VAR-NUMBER-1/VAR-NUMBER-3/VAR-NUMBER-5TLV-LENGTH=VAR-NUMBER-1/VAR-NUMBER-3/VAR-NUMBER-5/VAR-NUMBER-9TLV-VALUE=*OCTET

TLV-TYPE MUST be in the range [1, 4294967295].Type 0 is reserved to indicate an invalid TLV element and MUST NOT appear on the wire.TLV-TYPE SHOULD be unique at all nested levels.SectionTLV Type Registry of this document lists the initialTLV-TYPE assignments.

TheTLV-LENGTH field indicates number of bytes thatTLV-VALUE uses.It does not include the number of bytes thatTLV-TYPE andTLV-LENGTH fields themselves occupy.In particular, a TLV element with empty value will haveTLV-LENGTH equal to 0.

This encoding offers a reasonable balance between compactness and flexibility.Most common, standardizedTLV-TYPE numbers will be allocated from a small-integer number-space, and these common types will be able to use the compact, single-byte encoding.

Non-Negative Integer Encoding

A number of TLV elements in the NDN packet format take a non-negative integer as their TLV-VALUE, with the following definition:

NonNegativeInteger=1OCTET/2OCTET/4OCTET/8OCTET

The TLV-LENGTH of the TLV element enclosing aNonNegativeInteger MUST be either 1, 2, 4, or 8.Depending on the TLV-LENGTH, aNonNegativeInteger is encoded as follows:

  • if the length is 1, theNonNegativeInteger is encoded in 1 octet;

  • if the length is 2, theNonNegativeInteger is encoded in 2 octets, in network byte-order;

  • if the length is 4, theNonNegativeInteger is encoded in 4 octets, in network byte-order;

  • if the length is 8, theNonNegativeInteger is encoded in 8 octets, in network byte-order.

The following shows a few examples of TLVs that have aNonNegativeInteger as their value component in hexadecimal format (whereTT represents the TLV-TYPE, followed by the TLV-LENGTH, and then the TLV-VALUE):

0     => TT01001     => TT0101255   => TT01FF256   => TT02010065535 => TT02FFFF65536 => TT0400010000

Considerations for Evolvability of TLV-Based Encoding

To ensure that the TLV-based protocol can evolve over time without requiring flag days, the least significant bit ofTLV-TYPE (unless overridden by the specification of a particular network/library/application TLV element) is reserved to indicate whether that TLV element iscritical ornon-critical.A compliant TLV format decoder should follow the order, quantity, and presence requirements of the recognized elements defined in the corresponding specification.At the same time, if the decoder encounters an unrecognized or out-of-order element, the behavior should be as follows:

  • if the least significant bit of the element’sTLV-TYPE number is 1, abort decoding and report an error;

  • if the least significant bit of the element’sTLV-TYPE number is 0, ignore the element and continue decoding;

  • TLV-TYPE numbers in the range [0, 31] are “grandfathered” and are all designated ascritical for the purposes of packet processing.

Note

A recognized element is considered out-of-order if it appears in the element order that violates a specification. For example:

  • when a specification defines a sequence {F1F2F3}, an elementF3 would be out-of-order in the sequence {F1F3F2};

  • for {F1F2?F3} specification (i.e., whenF2 is optional,F2 would be out-of-order in the same sequence {F1F3F2}.

Footnotes

[1]

“Packet Fragmentation in NDN: Why NDN Uses Hop-By-Hop Fragmentation (NDN Memo)” by A. Afanasyev, J. Shi, L. Wang, B. Zhang, and L. Zhang., NDN Memo, Technical Report NDN-0032

On this page

[8]ページ先頭

©2009-2026 Movatter.jp