Project

General

Profile

Actions

Feature #2587

closed

Link and forwarding hint

Added by Spyros Mastorakis about 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Category:
Base
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

Implement Link and forwarding hint, according to SNAMP techreport.

This Feature includes:

  • the Link object, as a subtype and subclass of Data
  • add fields to Interest to support forwarding hint

Files

design_v2.pdf (16.1 KB) design_v2.pdf Spyros Mastorakis, 03/20/2015 10:47 AM
link.pdf (85.5 KB) link.pdf Spyros Mastorakis, 03/31/2015 10:37 PM

Related issues 1 (1 open0 closed)

Related to NFD - Feature #3000: Design mobility with forwarding hintFeedback

Actions
Actions #1

Updated by Spyros Mastorakis about 9 years ago

  • File Link_design.pdf added
  • File Link.jpg added
  • Status changed from New to In Progress
  • Assignee set to Spyros Mastorakis
  • Target version set to 2.1
  • % Done changed from 0 to 10
Actions #2

Updated by Spyros Mastorakis about 9 years ago

  • File deleted (Link_design.pdf)
Actions #3

Updated by Spyros Mastorakis about 9 years ago

  • File deleted (Link.jpg)
Actions #4

Updated by Spyros Mastorakis about 9 years ago

  • File link.jpg added
  • File Link Design.pdf added

Updated Design

Actions #5

Updated by Spyros Mastorakis about 9 years ago

  • % Done changed from 10 to 50
Actions #6

Updated by Spyros Mastorakis about 9 years ago

  • % Done changed from 50 to 70
Actions #7

Updated by Junxiao Shi about 9 years ago

Please define the TLV wire format for an link object, including TLV-TYPE code assignments.

Link Design.pdf lacks the exact encoding of Content.

Actions #8

Updated by Spyros Mastorakis about 9 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 70 to 90

I think that this task should be moved to ndn-cxx. Link is something that we will need quite soon. :)

Actions #9

Updated by Spyros Mastorakis about 9 years ago

  • File deleted (link.jpg)
Actions #10

Updated by Spyros Mastorakis about 9 years ago

  • File deleted (Link Design.pdf)
Actions #11

Updated by Spyros Mastorakis about 9 years ago

Actions #12

Updated by Junxiao Shi about 9 years ago

As I see in link.pdf, a Link in section 1 is encoded as:

<Data>
  <Name>
    <NameComponent>net</NameComponent>
    <NameComponent>ndnsim</NameComponent>
    <NameComponent>LINK</NameComponent>
  </Name>
  <MetaInfo>
    <ContentType>1</ContentType>
  </MetaInfo>
  <Content>
    <ContenttypeLink>
      <LinkPair>
        <Pref>100</Pref>
        <Name>
          <NameComponent>att</NameComponent>
          <NameComponent>user</NameComponent>
          <NameComponent>alex</NameComponent>
          <NameComponent>net</NameComponent>
          <NameComponent>ndnsim</NameComponent>
        </Name>
      </LinkPair>
      <LinkPair>
        <Pref>10</Pref>
        <Name>
          <NameComponent>verizon</NameComponent>
          <NameComponent>user</NameComponent>
          <NameComponent>alex</NameComponent>
          <NameComponent>net</NameComponent>
          <NameComponent>ndnsim</NameComponent>
        </Name>
      </LinkPair>
    </ContenttypeLink>
  </Content>
  <SignatureInfo>...</SignatureInfo>
  <SignatureBits>...</SignatureBits>
</Data>

This <ContenttypeLink> element looks weird.


Section 3 mentions something about Interest modification. Does this affect wire format? If so, define the wire format.

Actions #13

Updated by Spyros Mastorakis about 9 years ago

  • File link.pdf added

The was a typo. Actually, it is the typical tlv::Content. Moreover, I updated the wire format for the Interest packet.

Actions #14

Updated by Spyros Mastorakis about 9 years ago

  • File deleted (link.pdf)
Actions #15

Updated by Junxiao Shi almost 9 years ago

As I see in note-13 link.pdf, a Link in section 1 is encoded as:

<Data>
  <Name>
    <NameComponent>net</NameComponent>
    <NameComponent>ndnsim</NameComponent>
    <NameComponent>LINK</NameComponent>
  </Name>
  <MetaInfo>
    <ContentType>1</ContentType>
  </MetaInfo>
  <Content>
    <Linkpair>
      <Pref>100</Pref>
      <Name>
        <NameComponent>att</NameComponent>
        <NameComponent>user</NameComponent>
        <NameComponent>alex</NameComponent>
        <NameComponent>net</NameComponent>
        <NameComponent>ndnsim</NameComponent>
      </Name>
    </Linkpair>
    <Linkpair>
      <Pref>10</Pref>
      <Name>
        <NameComponent>verizon</NameComponent>
        <NameComponent>user</NameComponent>
        <NameComponent>alex</NameComponent>
        <NameComponent>net</NameComponent>
        <NameComponent>ndnsim</NameComponent>
      </Name>
    </Linkpair>
  </Content>
  <SignatureInfo>...</SignatureInfo>
  <SignatureBits>...</SignatureBits>
</Data>

Please confirm this is precise.

TLV-TYPE codes for <Linkpair> and <Pref> elements are unassigned.

(yes I saw the assignments for <LinkPreference> <LinkDelegation> <SelectedDelegation> but the element names need to match precisely)

What are CONTENT-TLV LINKPAIR-TLV PREF-TLV?

If you are referring to the type code, it shall be written as CONTENT-TYPE, etc.


The extension to Interest in section 5 is missing the declaration of <SelectedDelegation> element.

Also, explain why <Link> <SelectedDelegation> elements should appear after <InterestLifetime>, instead of in some other position inside the Interest.

Actions #16

Updated by Spyros Mastorakis almost 9 years ago

Yes, this is precise.
The type of LinkContent is the typical Content. The type of the Delegation is the LinkDelegation noted as number 31. The Type of Preference is the LinkPreference noted as the number 30. The SelectedDelegation is the forwarding hint and its type is the SelectedDelegated noted as the number 32. The SelectedDelegation field is a NonNegativeInteger. You are right that this part of the document is confusing, so I will update it to make these points clear enough.

Moreover, I followed the guidelines and the Interest format proposed by the related memo, which was submitted for publication lately. In this paper, the field was placed after the field and the field after the field.

Actions #17

Updated by Spyros Mastorakis almost 9 years ago

  • File deleted (link.pdf)
Actions #18

Updated by Spyros Mastorakis almost 9 years ago

  • File link.pdf added
Actions #19

Updated by Spyros Mastorakis almost 9 years ago

  • File deleted (link.pdf)
Actions #20

Updated by Spyros Mastorakis almost 9 years ago

  • File link.pdf added
Actions #21

Updated by Junxiao Shi almost 9 years ago

From note-20 link.pdf:

I can see an Interest is encoded as: (please confirm this is accurate)

<Interest>
  <Name>..</Name>
  <Nonce>..</Nonce>
  <Data>
    <Name>
      <NameComponent>net</NameComponent>
      <NameComponent>ndnsim</NameComponent>
      <NameComponent>LINK</NameComponent>
    </Name>
    <MetaInfo>
      <ContentType>1</ContentType>
    </MetaInfo>
    <Content>
      <LinkDelegation>
        <LinkPreference>100</LinkPreference>
        <Name>
          <NameComponent>att</NameComponent>
          <NameComponent>user</NameComponent>
          <NameComponent>alex</NameComponent>
          <NameComponent>net</NameComponent>
          <NameComponent>ndnsim</NameComponent>
        </Name>
      </LinkDelegation>
      <LinkDelegation>
        <LinkPreference>10</LinkPreference>
        <Name>
          <NameComponent>verizon</NameComponent>
          <NameComponent>user</NameComponent>
          <NameComponent>alex</NameComponent>
          <NameComponent>net</NameComponent>
          <NameComponent>ndnsim</NameComponent>
        </Name>
      </LinkDelegation>
    </Content>
    <SignatureInfo>...</SignatureInfo>
    <SignatureBits>...</SignatureBits>
  </Data>
  <SelectedDelegation>
    1
  </SelectedDelegation>
</Interest>

Define the semantics of SelectedDelegation.

I guess it must be less than COUNT(/Interest/Data[MetaInfo/ContentType==1]/Content/LinkDelegation)? This rule needs to be made explicit.

Typo: "LINKP-REFERENCE-TLV" should be "LINK-PREFERENCE-TYPE".

Actions #22

Updated by Spyros Mastorakis almost 9 years ago

  • File deleted (link.pdf)
Actions #23

Updated by Spyros Mastorakis almost 9 years ago

Yes, the Interest encoding looks correct. I attach the updated design document.

Actions #24

Updated by Alex Afanasyev almost 9 years ago

  • Project changed from ndnSIM to ndn-cxx
  • Category set to Base
  • Target version changed from 2.1 to v0.4
Actions #25

Updated by Junxiao Shi almost 9 years ago

  • Tracker changed from Task to Feature
  • Subject changed from Implementation of Link in ndnSIM to Link and forwarding hint
  • Description updated (diff)
  • Start date deleted (02/27/2015)
Actions #26

Updated by Junxiao Shi almost 9 years ago

Earlier I was annoyed by these static methods:

  /**
   * @brief Get the name of the selected delegation for the given block and index
   * @param block The block format of the Link
   * @param delegation The index of the selected delegation
   * @return The name of the selected delegation
   */
  static Name
  getDelegationName(const Block& block, size_t delegation);

  /**
   * @brief Get the selected delegation index for the given block and Name
   * @param block The block format of the Link
   * @param delegation The name of the selected Delegation
   * @return The index of the selected delegation
   */
  static size_t
  getDelegationIndex(const Block& block, const Name& delegation);

Alex explained in 20150410 conference call that these methods allow a router to peek into a Link object without decoding, but I'm not convinced.

However, I realize that these methods are required for correct operation, because:

  • At protocol level, delegations in Link object is unordered.
  • SelectedDelegation field refers to the index of delegation in wire format.
  • ndn::Link type does not preserve the order of delegations from wire.

Therefore, decoding Link element into ndn::Link may change the order of delegations, and therefore SelectedDelegation no longer indexes the correct delegation.

I suggest changing the code as follows:

/** \brief gets the delegation at \p index from \p block
 *  \param block wire format of a Link object
 *  \param index 0-based index of a delegation in the Link object
 *  \return delegation preference and name
 *  \throw std::out_of_range index is out of range
 */
static std::tuple<uint32_t, Name>
getDelegationFromWire(const Block& block, size_t index);

/** \brief finds index of a delegation with \p delegationName from \p block
 *  \param block wire format of a Link object
 *  \return 0-based index of the first delegation with \p delegationName ,
 *          or -1 if no such delegation exists
 */
static ssize_t
findDelegationFromWire(const Block& block, const Name& delegationName);

And also add a warning to Link::wireDecode:

\warning This method does not preserve the relative order between delegations.
         To get a delegation by index, use \p getDelegationFromWire method.
Actions #27

Updated by Alex Afanasyev almost 9 years ago

+1 for the updated interface.

Actions #28

Updated by Alex Afanasyev almost 9 years ago

  • Status changed from Code review to Closed
  • % Done changed from 90 to 100
Actions #29

Updated by Junxiao Shi over 8 years ago

  • Related to Feature #3000: Design mobility with forwarding hint added
Actions

Also available in: Atom PDF