nlsr named data link state routing protocol
play

NLSR: Named-data Link State Routing Protocol A K M Mahmudul Hoque, - PowerPoint PPT Presentation

NLSR: Named-data Link State Routing Protocol A K M Mahmudul Hoque, Syed Obaid Amin, Adam Alyyan, Lan Wnag ( University of Memphis ) Beichuan Zhang ( University of Arizona ) Lixia Zhang ( UCLA ) 1 Motivation n Need a routing


  1. NLSR: Named-data Link State Routing Protocol A K M Mahmudul Hoque, Syed Obaid Amin, Adam Alyyan, Lan Wnag ( University of Memphis ) � Beichuan Zhang ( University of Arizona )� Lixia Zhang ( UCLA )� 1

  2. Motivation n Need a routing protocol for NDN � q Populate FIB so routers can forward interests. � q Compute next - hops for name prefixes � q Not necessarily point to the nearest cache. � n Be NDN “native” � q Carry routing information in Interest/Data. � q Provide better support for NDN’s adaptive forwarding � q Current OSPFN is a hack of IP - based OSPF implementation. � 2

  3. Approach n Reuse a mature routing algorithm: link state � q Each router advertises local links and prefixes � q Compute best paths based on entire topology. � n Design a native NDN protocol to realize it. � q Naming � q Trust � q Syncing � q Multipath � 3

  4. Naming n Follow the hierarchy within a network � q Easy to identify the relationship among entities � q Easy to associate keys with key owners � n Topology � q /<network/<site>/<router> � n E.g., /ndn/memphis.edu/rtr1 n Updates � q /<network>/NLSR/LSA/<site>/<router>/<type>/<version> � n Keys � q /<network>/keys/<site>/….. � 4

  5. LSA messages n Generated and signed by the NLSR process at a particular router � n Adjacency LSA � q The content contains all links of a router. � n Prefix LSA � q The content contains a name prefix registered at the router. � 5

  6. Link State Database (LSDB) n Traditional OSPF operations � q LSDB synchronization at the start of a session � q Reliable flooding of new LSAs with per - hop ack � q Periodic flooding of current LSAs, i.e., refresh � n How to “flood” updates in an NDN network? � 6

  7. From flooding to synchronization n NLSR � q Keep synchronizing LSDB with neighbors � n Sync � q Two neighbors periodically send summary digest of LSDB to each other in Interest packets. � q If the digests are di ff erent, figure out the di ff erence and fetch new LSAs. � q More resilient/scalable, fits NDN model. � 7

  8. Example of Sync NLSR REPO/SYNC REPO/SYNC NLSR 1. Root Advise interest no reply 2. Store LSA 3. Root Advise reply 4. Content Interest 5. Content Reply 6. Sync Notification 7. Request for LSA 8. LSA Reply 9. Install LSA to LSDB 8

  9. Multipath n Traditional OSPF � q Single best next - hop or ECMP. � n NDN makes multipath easy and natural. � q Built - in loop detection � q Returning Data indicates it worked. � q Interest NACK or PIT timeout indicates it didn’t work. � n NLSR provides an ordered list of interfaces for each prefix, so that NDN’s forwarding strategy can explore them e ffi ciently. � 9

  10. Route computation n Currently multiple runs of Dijkstra’s algorithm over LSDB � q Investigating more e ffi cient algorithms. � n Compute the path cost of using each neighbor � q Keep the link to the neighbor, disable all other neighbor links. � q Compute shortest path to the name prefix and record the cost. � n Rank all next - hops by their path costs. Install in FIB. � 10

  11. Message authenticity and integrity Signature n Every NDN Data packet is signed. � n “key locator” includes information about the key. � n Receiver retrieves the key and verifies the signature. � Key Locator 11

  12. Signing and Verification in NLSR Keys are distributed via Sync, available in Repo, and identified by names carried in the “Key Locator” field. 12

  13. OSPF vs. NLSR n Both are link - state intra - domain routing protocols. � OSPF � NLSR � Naming � addresses � hierarchical names � Updates � network flooding � neighbor syncing � Next - hop � single � multiple � Security � Passwords � Public keys � 13

  14. Lab Experiment 14

  15. Development Status n Implemented in CCNx with Sync/Repo � q Lab experiments revealed several bugs and limitations � q Plan to try ChronoSync � n Ongoing improvement of the design � q Adjacency discovery and maintenance � q Faster multipath computation � n Plan to deploy on NDN testbed and make code available on github. � http://www.github.com/named - data � � 15

  16. Questions? 16

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend