Bundle Protocol Specification Keith Scott 3-9-2005 Minneapolis, MN

This Presentation Current Bundle Protocol Spec Document Expires soon (now) What’s in it What we like, don’t like, and are unsure about Bundle header picture Ways forward

TOC Expires: March 2005 Jet Propulsion Laboratory Table of Contents 1. Introduction..........................................3 2. Service Description...................................4 2.1 Definitions...........................................4 2.2 Services at the User Interface........................5 2.3 Summary of Primitives.................................5 2.3.1 Requests..............................................5 2.3.2 Indications...........................................6 2.4 Summary of Parameters.................................6 2.4.1 Destination Communications endpoint ID................6 2.4.2 Source Communications endpoint ID.....................6 2.4.3 Report Communications endpoint ID.....................6 2.4.4 Class of Service......................................6 2.4.5 Delivery Options......................................7 2.4.6 Lifespan..............................................7 2.4.7 Application Data Unit.................................7 2.4.8 Delivery Failure Action...............................7 2.5 Bundling Service Primitives...........................8 2.5.1 SEND.REQUEST..........................................8 2.5.2 CANCELBUNDLE.REQUEST..................................8 2.5.3 REGISTER.REQUEST......................................9 2.5.4 START-DELIVERY.REQUEST................................9 2.5.5 STOP-DELIVERY.REQUEST................................10 2.5.6 CHANGE-REGISTRATION.REQUEST..........................10 2.5.7 DEREGISTER.REQUEST...................................10 2.5.8 POLL.REQUEST.........................................11 2.5.9 DATA.INDICATION......................................11 2.5.10 SENDERROR.INDICATION.................................12 2.5.11 SENDTOKEN.INDICATION.................................12 2.5.12 REGISTRATIONTOKEN.INDICATION.........................13 3. Bundle Message Format................................13 3.1 General Bundle Header Format.........................16 3.2 Tuples...............................................16 3.3 Primary Bundle Header................................17 3.4 Bundle Payload Header................................20 3.5 Bundle Authentication Header.........................20 3.6 Payload Security Header..............................20 3.7 Bundle Fragment Header...............................21 3.8 Dictionary Header....................................21 3.9 Rules Governing the Appearance and Order of Headers..22 4. Bundle Processing....................................22 4.1 Bundle transmission requests.........................22 4.2 Bundles received from other bundle agents............22 Internet Draft Bundle Protocol Specification September 2004 Delay Tolerant Networking Research Group K. Scott Internet Draft The MITRE Corporation <draft-irtf-dtnrg-bundle-spec-02.txt> September 2004 S. Burleigh Expires: March 2005 Jet Propulsion Laboratory

Things We’re Pretty Sure About Service Primitives (§2.5) What’s there is good, some missing (more later) General Header Chaining Structure (§3.1) Administrative Payloads (§5) Application data where the bundle node is the application, and the data units support the operation of the bundle protocol itself Bundle status payloads, Custody ACKs, etc. Split of responsibilities between bundle & convergence layers (§6) Need to support bundle fragmentation / reassembly

Things We Think Are Good Ideas Dictionary to improve header overhead (§3.8) Pointers in primary bundle header currently assume two-part naming Exchanging administrative (address) information at the beginning of a ‘contacts’ to enable ‘passive-mode’ transfers Need to formalize this as a particular type of administrative bundle

Things We Think Need Refinement API required to implement security architecture Using multipath routing / forwarding to improve reliability / decrease latency How to remove duplicates once we decide they’re no longer needed? Support for forward erasure coding in conjunction with multipath routing / forwarding Protocol support for multipoint delivery

Things We Think Are Totally Open Interaction between user desires and policy API for notification / negotiation Protocol support for streaming apps?

String Records (variable) String Count 32 bits Version Next Header CoS Flags Payl’d Security Primary Bundle Header Destination Source Report-to Custodian Creation Timestamp Dictionary Header Expiration Time Next Header String Records (variable) String Count Fragment Header Next Header Length of Original Bundle Payload Payload len (cont’d) Fragment Offset Frag. Offset (cont’d) Payload Class Length of bundle payload Payload Header Bundle Payload (variable) Length (cont’d)

Hash/MAC Length (2 bytes, SDNV?) Hash/MAC Length (2 bytes, SDNV?) String (Variable) Dictionary String Format Length (1B) Security Stuff Bundle Auth. Header Hash/MAC Alg. (opt) Hash of all bundle fields (Primary header through end of payload) Hash/MAC Key ID (opt) Hash/MAC Length (2 bytes, SDNV?) Payload Security Header Hash/MAC covering: Primary bundle header, dictionary header, override report-to header source routing header (if present), payload security header (this), bundle payload header. Hash/MAC Alg. (opt) Hash/MAC Key ID (opt) Hash/MAC Length (2 bytes, SDNV?) SDNV = Self-Delimiting Numerical Value

Ways Forward Move from ‘Next Header’ to ‘Current Header’ identifiers? Remove ‘Payload Class’ from payload header (holdover from before administrative bundles) Just a question: can we (do we want to) support ‘router-alert’ style administrative bundles? Include Length fields in headers (at least dictionary header?) Would allow padding of individual headers to XX-bit boundaries Security: Move all of security into separate headers? Payload security ‘above’ bundling Hop-by-hop security ‘below’ bundling Source Routing Header Next type, total length, # of entries, current entry index, list of tuples (and bits identifying loose/strict for each?)

Other Stuff To Add? DO specify how new header types can be defined in future documents Allow a new header type (TBD in separate document?) that a bundle router in the path can add to a bundle flowing through it NOT end-to-end significant (not covered by PSH, and ripped out at destination) Add ‘my id’ and ‘# of times I’ve seen it’ to detect/deal w/ replay Could implement as a general ‘added header type’ with above security example as one case Other (possibly non-security-related) applications