1 / 7

Delay Tolerant Network Endpoint ID Discussion

Delay Tolerant Network Endpoint ID Discussion. David Young - Ohio University IRG david.a.young@gmail.com Joerg Ott - TKK Netlab jo@netlab.tkk.fi. Current EID Conventions. Bundle Protocol Specification <scheme> : <scheme-specific part> both fields limited to 1023 bytes

felice
Télécharger la présentation

Delay Tolerant Network Endpoint ID Discussion

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. Delay Tolerant NetworkEndpoint ID Discussion David Young - Ohio University IRG david.a.young@gmail.com JoergOtt - TKK Netlab jo@netlab.tkk.fi Ohio University IRG ~~~ TKK Netlab

  2. Current EID Conventions • Bundle Protocol Specification • <scheme> : <scheme-specific part> • both fields limited to 1023 bytes • dtn:none  -- null endpoint • DTN2 • dtn: <hostname>.dtn [/ <appname> ] [.<id>] • <id> used is the OS PID (see dtnping) • multihoming unsupported • ION • ipn: <element_number> : <service_number> • <service_number> 0 reserved for admin bundles • multihoming unsupported Ohio University IRG ~~~ TKK Netlab

  3. Current Routing Conventions • DTN2 • Route aggregation via wildcard * • <prefix>* • route add dtn://mybox.dtn/* link_tcp • dtn://mybox.dtn/dtnping  match • dtn://mybox.dtn/dtnsend.43233 match • ION • Implicit aggregation of service_number • Only element_number considered. • a plan 2 router x tcp/amroc.jpl.nasa.gov:5001 • ipn:2.0 match • ipn:2.10 match Ohio University IRG ~~~ TKK Netlab

  4. EID issues • Multiple Implementations • ion, dtn2 ... • Different schemes • Naming Collisions • dtn://linksys.dtn • Crossing Dumb(er) Nodes • Intermediate nodes don't understand your scheme • Application Context • How much application context goes in the EID? • Where else could it go? Ohio University IRG ~~~ TKK Netlab

  5. Some Solutions • New schemes for every application • mailto: ftp: ... • Allows routing/load balancing by application • Demux at bundle layer, not application • Explicit nature avoids indirection/lookups • Application-hints extension block Ohio University IRG ~~~ TKK Netlab

  6. Some (more) Suggestions • Disclaimer • Modify dtn:// for more general use • Use FQDNs if dns is possible • Reduces likelihood of collision • Makes routing easier on terrestrial internet • Continue * notation, but reverse order of FQDN • dtn://edu.ohiou.cs.myhost • allows more aggregation, especially at gateway • New scheme for general use. • Lowest common denominator of EID on all platforms • No application data/optional application data • Multiple schemes in same EID for interoperability • dtn://dtnnetwork.ohiou.edu.dtn/:ipn:1.0 • Networks that do not understand each other's schemes Ohio University IRG ~~~ TKK Netlab

  7. References • Application Conventions for Bundle-based Communications • draft-ott-dtnrg-appl-00 • Architectural Considerations for the use of Endpoint Identifiers in Delay Tolerant Networking • draft-eddy-dtnrg-eid-00 • Bundle Protocol Specification • rfc5050 Ohio University IRG ~~~ TKK Netlab

More Related