Task #1168
closedDefine LocalControlHeader specification
100%
Description
An application can request forwarder to use LocalControlHeader
to notify the application about various information, such as FaceId on which incoming Interest or Data packet is received. Forwarder MUST NOT send a local control header until after application requests for it.
The application can use LocalControlHeader
(if it has permission) to indicate to which FaceIds an expressed Interest should be forwarder, bypassing strategy decision.
Specification should be define on redmine wiki: NFD local control header
Updated by Alex Afanasyev almost 11 years ago
- Status changed from New to In Progress
Updated by Alex Afanasyev almost 11 years ago
- Status changed from In Progress to Feedback
Please review preliminary spec NFD local control header
Updated by Junxiao Shi almost 11 years ago
LocalControlInfo contains FaceId
which is ambiguous. It could mean:
- the FaceId on which this Interest / Data arrives in forwarder
- the FaceId of the source face in a packet sniffing session
- the FaceId through which this Interest should be sent out
FaceId
shall be renamed IncomingFaceId
for the first meaning.
Updated by Alex Afanasyev almost 11 years ago
Hmm.. I agree that there is ambiguity, but not sure that we need to define a separate type for faces.. May be there should be explicit type or description of the context (ControlType)?
Also. If we allow specifying faceid for outgoing interests, do we want to allow a list of faceIDs as well?
Updated by Junxiao Shi almost 11 years ago
Alex Afanasyev wrote:
Also. If we allow specifying faceid for outgoing interests, do we want to allow a list of faceIDs as well?
Yes, to specify nexthops, a non-empty set of FaceIds should be supplied.
Updated by Yingdi Yu almost 11 years ago
do we have the concept of direction here? i.e., for all the packets received from applications, the FaceId is interpreted as outgoing face, for all the packets received by application, the FaceId is interpreted as the arriving face. I did not quite understand "the source face in a packet sniffing session"? any more details?
Updated by Junxiao Shi almost 11 years ago
Yingdi Yu wrote:
do we have the concept of direction here? i.e., for all the packets received from applications, the FaceId is interpreted as outgoing face, for all the packets received by application, the FaceId is interpreted as the arriving face. I did not quite understand "the source face in a packet sniffing session"? any more details?
Yes, FaceId can have three different semantics, so that it should be given better names for those purposes:
- IncomingFaceId indicates the Face on which this packet arrives at the local forwarder
- NextHopFaceId indicates an app-chosen nexthop of an Interest. This field can be repeated to specify multiple nexthops. These app-chosen nexthops is a suggestion to the strategy on the namespace; if the strategy supports this field, it will forward Interests according to this suggestion.
- SnifferSourceFaceId indicates the Face on which the captured packet is transmitted. A separate SnifferDirection field indicates the direction on which the captured packet is transmitted.
Updated by Alex Afanasyev over 10 years ago
I'm leaving out specification for Sniffer, but keeping it general. I feel that in sniffer mode, the daemon may tell something else about the incoming packets, besides the FaceId.
Updated by Junxiao Shi over 10 years ago
- Target version changed from Mock to v0.1
Comment on revision 8:
NextHopFaceId should be repeatable: one or more nexthops can be specified in the header.
NextHopFaceId should use NEXT-HOP-FACE-ID-TYPE
, not INCOMING-FACE-ID-TYPE
.
Don't define sniffing currently, because it's not part of first release.
I will write up a spec for sniffing after first release.
Updated by Alex Afanasyev over 10 years ago
Updated. I commented out the sniffer-related info and reserved TLV type code for it.
Updated by Junxiao Shi over 10 years ago
Comment on revision 12:
Add a section header for LocalControlHeader enabling protocol.
"the control header allows applications to request bypassing the Interest forwarding strategy by directly specify FaceId to which the Interest should be forwarded" is inaccurate, because NextHopFaceIds are passed to the effective strategy as a suggestion, and the Interest does not bypass the strategy.
Updated by Junxiao Shi over 10 years ago
I updated the document to revision 16 to make the enabling procedure more clear.
Updated by Junxiao Shi over 10 years ago
- Status changed from Feedback to Closed
- % Done changed from 90 to 100
20140216 conference call reviewed and approved this document.