SIS-DTN Friday

FRIDAY SCHEDULE

SIS-DTN WORK ITEMS (FROM FRAMEWORK)

(EDITED) NOTES FROM SPRING 2014 MEETING Network Management Leigh Torgerson (?) is interested in NM (Green Book editor?) Lee Pitts volunteers to be book editor for something related to NM (DTNMP?) Contact Graph Routing Scott Burleigh to collect and coordinate work in CGR Security Dennis Iannicca [need to revisit this? Confirm with Karen Tuttle]

SCHEDULE BUILDING “Single-Agency” Network Management Requirements Green Book (Target: End of CY15) Axiom: these are the requirements on ‘doing NM’ not ‘cross-supporting NM’ Collect NM requirements from agencies Describe required capabilities pertinent to interoperability (feeds into NM service specification) Ancillary material on NM systems as appropriate (other considerations such as storage, replay, …) with analysis of impacts on interoperability SMTP interoperability Network Management Protocol (Target: End of CY2016) Analysis of implications of using MO Services Understand MO Services Understand how to define new (DTN NM) service in terms of MO services Implications w.r.t. future interaction with IETF ADM Definitions (annexes) BP Core ADM definition LTP ADM Anything else we can fit into the resource envelope (e.g. CGR,…) Could develop CGR ADM in the context of ION ADM initially, then break it out later; Could abstract it out to begin with ION ADM is probably out of scope (implementation-specific) Other APPLICATION management, … really should be application-area-done blah blah blah (CFDP, AMS, …) [??? In-scope? These are application-layer things DTNMP specification (work here depends on results from above) Interoperability Test (DTNMP Agent / DTNMP Controller) Book Editor: NASA Impl1: NASA (Agent) Impl2: ??????? Thing1: Controller –or- Agent Thing2: Another controller –or- Agent Keith to sort this out with CESG / CMC – not in current framework / charter. Figure out if Leigh Torgerson is still available; if not we need a backup.

NETWORK MANAGEMENT PROTOCOL RESOURCES Book Editor: NASA Prototype 1: NASA Prototype 2: ??????

SCHEDULE BUILDING Contact Graph Routing (Target: End of CY2016) Must provide prescribed forwarding behavior based on contact inputs Could try to define a protocol for exchanging / updating contacts (but might simply rely on NM to do this) Define what’s in and what’s out (for now) (e.g. CGR extension work by Ed, etc.) What amount of ‘inferred information’ (e.g. inferred knowledge of other nodes’ queues) should be employed in CGR decisions (and how does that affect testability / stability / interoperability, etc.) Formal (CCSDS) CGR definition (that can be employed/adopted by IETF) (Possibly abstract) input (schedule) format CGR experience: NASA, CNES, JAXA, Argentina, ASI, BITTT, DUTH Interoperability testing Commitment to do 2 nd implementation needed by Spring 2015 Need implementation by ~ Spring 2016 (?) Given two CGR instances, a bucket of different schedules (that imply a topology), and for each schedule, a slew of bundles, does each produce [the same, ‘reasonable’] routing decision output; Note that routing decisions may depend on known / inferred status of other nodes’ queue lengths (congestion) Mixed implementations in a ‘test’? JAXA: ‘simple case is easy – be sure to include tests that include disruption / disconnection’ and complex topologies

CONTACT GRAPH ROUTING RESOURCES Book Editor: NASA Contributions from: Prototype 1: NASA (Use ION CGR) Prototype 2: ????? [need (commitment to implement) by Spring 2015 – implementation work might start then or later] Second implementation could be in the context of ION, DTN2 (maybe more useful), IBR, JDTN, or ‘stand-alone’

BUNDLE PROTOCOL SECURITY Starting point: Streamlined Bundle Security Protocol Draft Deal with Bundle-in-Bundle Encapsulation later (not this book) Deal with Key Administration later (not this book) Resources: Book Editor: NASA Implementation 1: NASA (ION 3.3.0) Implementation 2: NASA (MSFC DTN2)