LocalControlHeader » History » Version 25

« Previous - Version 25/26 (diff) - Next » - Current version
Junxiao Shi, 10/19/2014 01:46 PM

NFD Local Control Header

NFD LocalControlHeader is used between application and local forwarding daemon to exchange various NFD-specific local information that is not part of Interest and Data packet.

For example, LocalControlHeader allows applications to specify FaceId to which the Interest should be forwarded.

Enabling and disabling LocalControlHeader

LocalControlHeader is not enabled initially.

Application can invoke faces/enable-local-control command to enable a LocalControlHeader feature,
and invoke faces/disable-local-control command to disable a LocalControlHeader feature,

NFD MUST NOT deliver packets with LocalControlHeader to an application unless the application has enabled at least one LocalControlHeader feature.
NFD SHOULD ignore a LocalControlHeader field if the corresponding feature is not enabled.

An enable or disable command MAY NOT take effect immediately.
Packets scheduled for transmission before processing the enable or disable command could be delivered or processed in the old state.

LocalControlHeader structure

                         (Interest | Data)



Although all fields before (Interest | Data) in LocalControlHeader are marked optional, at least one of them must be present.

IncomingFaceId feature

This feature allows application to learn the incoming face of each Interest and Data packet.

If this feature is enabled,
when an incoming Interest or Data is delivered to application,
the packet is encapsulated in LocalControlHeader, with IncomingFaceId field is set to the incoming FaceId.

However, Datas from the ContentStore won't have a IncomingFaceId field.

NextHopFaceId feature

This feature allows application to pick a nexthop for its Interest.

If this feature is enabled,
application can encapsulate an Interest in LocalControlHeader, and set NextHopFaceId field to the desired nexthop.

ClientControl strategy SHOULD be chosen as the effective strategy on the Interest's namespace.
It will honor NextHopFaceId field, and forward Interest to the desired nexthop.

If other strategy is being used, NextHopFaceId has no effect.

CachingPolicy feature

This feature allows application to give ContentStore an instruction about whether/how to cache the Data packet.

If this feature is enabled,
application MAY attach a CachingPolicy field on a Data packet to NFD,
which has the following structure:


NoCache       ::= NO-CACHE-TYPE TLV-LENGTH(=0)

The CachingPolicy field contains exactly one sub-TLV as the instruction.

Currently only one instruction TLV is defined:

  • NoCache: ContentStore SHOULD NOT cache the Data packet. This instruction TLV has no parameter and therefore is empty.

Instruction TLVs defined in the future MAY need have parameter as its TLV-VALUE.

Caching field MUST NOT be attached to a packet from NFD to application, or to a non-Data packet.

TLV-TYPE assignments

Type Assigned value Assigned value (hex)
LocalControlHeader 80 0x50
IncomingFaceId 81 0x51
NextHopFaceId 82 0x52
CachingPolicy 83 0x53
NoCache 96 0x60