LocalControlHeader » History » Revision 25
Revision 24 (Junxiao Shi, 03/22/2014 03:29 PM) → Revision 25/26 (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 [[FaceMgmt#Enable a LocalControlHeader feature|faces/enable-local-control]] command to enable a LocalControlHeader feature,
and invoke [[FaceMgmt#Disable a LocalControlHeader feature|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 [[StrategyChoice|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
Type | Assigned value | Assigned value (hex)
------------------------------------------- | ----------------- | --------------------
LocalControlHeader | 80 | 0x50
IncomingFaceId | 81 | 0x51
NextHopFaceId | 82 | 0x52
CachingPolicy | 83 | 0x53
NoCache | 96 | 0x60