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¶

LocalControlHeader ::= LOCAL-CONTROL-HEADER-TYPE TLV-LENGTH
                         IncomingFaceId?
                         NextHopFaceId?
                         CachingPolicy?
                         ...?
                         (Interest | Data)

IncomingFaceId     ::= INCOMING-FACE-ID-TYPE TLV-LENGTH
                          nonNegativeInteger

NextHopFaceId      ::= NEXT-HOP-FACE-ID-TYPE TLV-LENGTH
                          nonNegativeInteger

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:

CachingPolicy ::= CACHING-POLICY-TYPE TLV-LENGTH
                    NoCache

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¶