1 / 10

Pragmatists

Naming and Addressing Network Management Benchmarking. Pragmatists. A General Principle. Bundle agents should be able to make routing (etc.) decisions on bundles from information already at hand, without consulting a remote service. Two options for this:

edward
Download Presentation

Pragmatists

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Naming and Addressing Network Management Benchmarking Pragmatists

  2. A General Principle • Bundle agents should be able to make routing (etc.) decisions on bundles from information already at hand, without consulting a remote service. • Two options for this: • Provide necessary info in the bundle itself • Pre-pace the necessary information and use information in the bundle to look it up

  3. Naming • Information-rich names such as: • dtn:regionid.nodeid (contains routing cue) • Information-limitef names such as: • ipn:nodeNbr.serviceNbr • Syntax of DTN endpoint Ids names) should accommodate both. Proposed (Stephen Farrell): • dtn:authorityName/authority-specific-stuff • E.g.: dtn://dtn2.dtnrg.org/ptlsun.jpl.nasa.gov

  4. Naming and Addressing • Need multiple DTN regions • Scaling • Limiting amount of information to be carried by routing protocols • Membership is key attribute for nodes • Node may be member of multiple DTNs • Proposal: very mobile node should be a member of its very own one node/one EID region • Membership in other DTNs =>'Alias' EIDs

  5. Routing Principles • Need to be able to accommodate multiple routing systems • Proposed to use authority name in endpoint ID to select routing system as well as to parse authority-specific stuff in the endpoint ID – but separately. Decouple routing system from name syntax.

  6. Routing • Possible ways to provide routing information • Distributed database (see network mgt!) • Info added to bundles • Source node adds extra (new type of) bundle block containing all its aliases • Nodes that the bundle passes can learn aliases • If the destination is not in any of the DTNs of which the source is a member send to a gateway

  7. Gateways • Link between DTN region and LI • Redundancy => multiple gateway nodes • Multi-node EID! • LI Gateway is a 'well-known' EID within the DTN? • Thought: Use bundle-in-bundle to wrap bundle going 'outside current DTN' • 'Current DTN' determined by first encounter or administrative knowledge • Outer bundle addressed to gateway • Gateway unwraps bundle and sends to right gateway for destination DTN

  8. Routing 2 • On passing through a node • Node can extract aliases of source and cache • With a wrapped bundle, the node may know a better place way to deliver the bundle due to cached aliases (like in this DTN) • Security issue! Should the extracting node trust the aliases? • Can rewrap bundle with new destination • If it 'knows' the node can be reached at an EID in the 'current' DTN

  9. Network Management • No deep insights • Logging • Discusssed need for cross referencable timestamps • Importance of relative timing of events when something has gone wrong! • But really only relevant during encounters when relationship of node clocks can be known • Tecnnique? Bundles to remote logging daemon • Configuration: Security, Security, Security! • Remote software updates!

  10. Benchmarking • Unlikely to be a one size fits all solution • Different types of DTN, e.g. • Space with scheduled/contact graph opportunities • Communication challenged areas with probabilistic techniques • Related to the resource allocation utility function used to do routing • Benchmarking = Measure of success against resource allocation utility function • Need to develop reference scenarios

More Related