Task #1193
closedTask #1294: autoconfig: discover NDN router
HUB discovery procedure
Added by Alex Afanasyev almost 11 years ago. Updated over 10 years ago.
100%
Description
Define the protocol / procedure to discover and connect to NDN router.
Protocol: HubDiscovery
Files
CertificationArchitecture.pptx (2.18 MB) CertificationArchitecture.pptx | key management description (related to phase 3) | Alex Afanasyev, 03/05/2014 07:47 AM |
Updated by Junxiao Shi almost 11 years ago
- Category set to Tools
- Target version set to v0.1
Updated by Junxiao Shi almost 11 years ago
- Subject changed from Auto-config support in NFD to Auto-config: discover local HUB
Updated by Junxiao Shi over 10 years ago
20140223 conference call reviewed NDN hub discovery procedure revision 1.
- Three steps have different purposes:
- If there is a HUB in one-hop, use that HUB.
- If IP network announces a NDN hub using DNS search domain, use that HUB.
- If IP network does not announce a NDN hub using DNS search domain, connect to the home HUB.
- UDP multicast face is created when NFD starts, and can be used for communication. However, step 1 is still needed:
- You don't know whether you can reach broader NDN network by UDP multicast.
- Multicast has overhead.
- Data packet in reply to step 1 Interest should be signed by the site key, which in turn is signed by NDN testbed root key.
fake route to /autoconf is actually a tag that indicates a face is created by autoconf tool.
The alternates to using a fake route are:
- Store in a file.
- Store in a Data packet written to a repository.
- Set a string description on the Face in an argument to FaceMgmt create command.
- Store in a variable in NFD, and define a new command in FaceMgmt to access this variable.
The reason to have this tag is: the face to old HUB should be deleted when autoconf tool executes again and finds a different HUB, after network environment changes.
Deleting the face to old HUB is not always necessary, because:
- If the old HUB becomes inaccessible, the face would be created due to UDP send error.
- If the old HUB is reachable but slow, strategy should favor the new HUB.
The fundamental questions are:
- How many HUBs can a laptop simutaneously connect to?
- How long should a laptop keep faces to old HUBs?
- How many faces to old HUB should a laptop keep?
We decide not to have this tag in first release, because there aren't many HUBs at this time.
The questions should be revisited after first release.
Updated by Junxiao Shi over 10 years ago
- Subject changed from Auto-config: discover local HUB to HUB discovery procedure
- Description updated (diff)
- Category changed from Tools to Protocol
- Assignee set to Alex Afanasyev
- Parent task set to #1294
Updated by Junxiao Shi over 10 years ago
- Status changed from New to In Progress
- Assignee changed from Alex Afanasyev to Junxiao Shi
- Priority changed from Normal to High
- % Done changed from 0 to 40
- Estimated time set to 2.00 h
"40% Done" reflects what Alex did before. I will continue from this basis.
Updated by Junxiao Shi over 10 years ago
- Status changed from In Progress to Feedback
- % Done changed from 40 to 60
Procedure is refined and needs review.
Issues:
- Old procedure uses
/local/ndn/prefix
Interest in stage 1 to discover a routable prefix of the local HUB, but there's no equivalent feature in stage 2 and 3.
I didn't include this, because NRD does not support AUTOREG, and reverse prefix registration is not defined yet. - Stage 3 involves extracting site-specific part of a certificate. This process needs to be clearly defined.
Updated by Junxiao Shi over 10 years ago
- Status changed from Feedback to In Progress
- Assignee changed from Junxiao Shi to Alex Afanasyev
Updated by Alex Afanasyev over 10 years ago
Updated by Alex Afanasyev over 10 years ago
- Status changed from In Progress to Closed
- % Done changed from 60 to 100