Project

General

Profile

Actions

Task #1168

closed

Define LocalControlHeader specification

Added by Alex Afanasyev almost 11 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Category:
Protocol
Target version:
Start date:
01/30/2014
Due date:
% Done:

100%

Estimated time:
3.00 h

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


Related issues 3 (0 open3 closed)

Blocks ndn-cxx - Task #1169: Mock implementation for LocalControlHeader abstractionClosedYingdi Yu01/30/2014

Actions
Precedes NFD - Task #1214: Forward Interest according to app-chosen nexthopsClosedJunxiao Shi

Actions
Precedes NFD - Task #1210: LocalControlHeader enabler (manager)Closed

Actions
Actions #1

Updated by Junxiao Shi almost 11 years ago

  • Description updated (diff)
Actions #2

Updated by Alex Afanasyev almost 11 years ago

  • Assignee set to Alex Afanasyev
Actions #3

Updated by Alex Afanasyev almost 11 years ago

  • Status changed from New to In Progress
Actions #4

Updated by Alex Afanasyev almost 11 years ago

  • Status changed from In Progress to Feedback

Please review preliminary spec NFD local control header

Actions #5

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.

Actions #6

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?

Actions #7

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.

Actions #8

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?

Actions #9

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.
Actions #10

Updated by Alex Afanasyev over 10 years ago

  • % Done changed from 0 to 90
Actions #11

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.

Actions #12

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.

Actions #13

Updated by Alex Afanasyev over 10 years ago

Updated. I commented out the sniffer-related info and reserved TLV type code for it.

Actions #14

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.

Actions #15

Updated by Junxiao Shi over 10 years ago

  • Category set to Protocol
Actions #16

Updated by Junxiao Shi over 10 years ago

I updated the document to revision 16 to make the enabling procedure more clear.

Actions #17

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.

Actions

Also available in: Atom PDF