Remote Prefix Registration
Draft 1. October 17, 2014
Alex Afanasyev
Yanbiao Li
1
Objectives
• Register “back-route(s)” on remote hub
– apps own the registered prefix(es)
• NDN Testbed certificate delegates ownership for namespace
– register only when necessary
• at least one local app expects Interests
• there is a connectivity to access router/gateway
– re-register if failed
• re-register if do not receive the success notification from the remote hub.
• “Back-route(s)” should be maintained
– remote hubs keep only soft state for
• remote face
• remote registration (?)
• Process should be transparent for apps
– apps register only with local NRD
– when necessary, registrations further “propagate”
2
Overview diagram
/localhop/nfd/nrd/register/…
Remote NFD/NRD
register: /ndn/prefix
signed: /ndn/prefix/KEY/nrd/...
Local NFD/NRD
/localhost/nfd/rib/register/…
register: /ndn/prefix/app1
signed: /ndn/prefix/KEY/app1/...
App
register: /ndn/prefix/app2
signed: /ndn/prefix/KEY/...
App
register: /ndn/prefix/app3
signed: /ndn/prefix/app2/KEY/...
App
3
Requirements
• local NRD
– owns a set of keys/certificates, delegated from user namespace
• key can be restricted/scoped for NRD operations only
– /<...>/KEY/<...>/nrd/<dsk-id>/ID-CERT
• /ndn/edu/ucla/KEY/cs/afanasev/nrd/dsk-1/ID-CERT
• /ndn/edu/ucla/cs/afanasev/KEY/chronochat/nrd/dsk-1/ID-CERT
• /ndn/guest/KEY/cawka1@gmail.com/nrd/dsk-2/ID-CERT
• remote NRD
– allow /localhop registrations with proper trust model
– allow registrations for set of prefixes
• /ndn/edu/ucla
• /ndn/guest
Will be implemented in
phase 2.
In phase 1, remote NRDs
will process all
registrations
4
Remote registration processing on
local NRD
• after any prefix registration for prefix <P>
– if “/localhost”.isPrefixOf(<P>) or no connection to gateway hub
• stop
– (keys, namespaces) <- enumerate keys NRD owns
• each key defines “namespace” it uses
• we define the following convention:
– key: /<..1..>/KEY/<..2..>/nrd/<dsk-id>/ID-CERT
– namespace: /<..1..>/<..2..>
– (<KEY>, <PREFIX>) <- longest prefix match on key namespaces for <P>
• if nothing found, stop
– if <PREIFX> already registered
• stop
– send localhop registration for <PREFIX>
• sign with <KEY>
– schedule registration refresh for <PREFIX>
• add <PREFIX> to the registered prefix set
5
Checking whether connected to hub
• We will rely on naming convention
• /localhop/<site>/nfd
– /localhop/nfd
– /localhop/ndn/edu/ucla/nfd
– /localhop/org/caida/nfd
• If “/localhop/<site>/nfd” route exists in RIB, then we are connected
to one or more hubs
– phase 1: only /localhop/nfd
• only one hub or requires broadcast strategy
– phase 2: all variants
• explicit name of the hub in the name
• Entries registered
– automatically with ndn-autoconfig
– manually
Sending remote registration
• For each found /localhop/<site>/nfd entry
– if registration for prefix <P> is in progress for
localhop entry <E>
• stop
– send /localhop/<site>/nfd/rib/register/...
– if error or timeout (4s), retry
• max 5 retries (configurable parameter)
• Only /localhop/nfd in phase 1
How remote registered prefix should be
maintained?
• Soft state on remote hub needs to be refreshed
– short-term: re-register periodically (on-demand face timeout * 90%)
– long-term: keep-alive + periodic face/rib query
• When connectivity changes, remote registered prefix should be
refreshed
– USR1 signal will be sent by an external tool
– NRD should process USR1 signal and refresh all previously remotely
registered prefixes
• When all local apps stops, remotely registered prefix should be
unregistered
– unregister and face destroy should trigger clean up processing
8
Cleanup processing on local NRD
• after localhost unregister for prefix <P> or and face
destroy (local application stopped)
– if “/localhost”.isPrefixOf(<P>)
• stop
– for each registered prefix <PREFIX> in the registered
prefix list
• find RIB entry that has prefix <PREFIX>
• if entry not found
– unregister <PREFIX>
– cancel refresh events
– remove from the registered list
9