SIS-DTNFriday 20141114

FRIDAY SCHEDULE

SIS-DTN WORK ITEMS(FROM FRAMEWORK)

(EDITED) NOTES FROMSPRING 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 2nd 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)