============================== DTN WG Interim Meeting December 5, 2014 Meeting Notes by Will Ivancic Marc - Agenda and Goals Get consensus on what to work on. Reviewing google document consisting of possible work items. https://docs.google.com/document/d/1RVwIUVIoJbZDCqIaZX5SICZN06kVjx42VzH82_r m3JI/edit Will - terminate bundles stuck in routing loops and hop-by-hop integrity for the header and end-to-end integrity for the bundle if the bundles are large. Conesus that these need to be worked. Marc, where should these topics reside? Discussion of header. Created INTEGRITY task for header integrity, header immutability. Discussion of primary block vs header blocks. Elwynd indicated that extension blocks get quite complicated particularly if you have meta-data blocks, order of blocks. ???Need something to indicate what headers are there??? Marc ­ we think we need to work some type of addressing, but scope may be to large. Need to determine the scope of the work. Fred ­ volunteered to work on use cases that correspond to Addressing Marc ­ what does the industry need with regard to addressing? Fred ­ what about zero/one indicating aggregated vs flat address space. Will ­ mult-homed, mobile systems are hard. Adding disconnection is harder. Adding propagation delay adds additional complication. Neighbor discovery: Elwynd ­ is discovery, discovering your neighbors or discovering what you neighbors are capable of? Marc ­ first just discovering you neighbors. Keith ­ should neighbor discovery be part of the core bundling protocol or an application that uses the neighbor discovery? Simple Routing: From Group ­ what does it mean? F red ­ manet has routing protocol separate from neighbor Discovery Elwynd ­ manet may not be a good example. One that uses 2 hop discovery is good work, but only by one (or a few) manet routing protocols. Elwynd ­ recommend that discovery is separate from routing. Scott Burleigh ­ agrees with Elwynd. Marc ­ summary and consensus is to work some type of neighbor discovery. Fred ­ a modular neighbor discovery will enable hooks with routing protocols. Dynamic routing: Consensus is to not include as work item at this time. Too big and one size does not fit all. Simple Routing: What is it? Consensus appears to be Static Routing. Keith Scott ­ simple forwarding table. No discussion about how to populate the Table. Network Management: Scott Burleigh ­ needed, but to big for current charter. Elwynd ­ is this just monitoring or monitoring and configuration. Brian ­ may be synergy with other working groups. Some groups are working layer independent management models. DTN may be able to make their needs known. Marc ­ would like to hear from industry as experience has shown that network management is usually needed. Jeremry Pierce Mayer ­ Network management is important even for small networks. Marc ­ is configuration or just monitoring. Jeremy ­ to many open items such as addressing that need to be discussed prior to configuration. Concentrate on monitoring. Scott Burleigh ­ really to large at this time. Fred ­ can work on items that are not in charter? Marc ­ individuals can submit individual submissions and then working group can consider the draft as moved to WG item. SECURITY: Marc ­ improved security. Scott Burleigh ­ needs to be done. Brian ­ what are you discussing: integrity, confidentiality, none repudiation? Chuck Sheehe ­ what about creation/expiration time, how is that treated? Ed Barrine ­ allows layering of security. Scott and Fred ­ strong support for simplified bundle security. Elwynd ­ what about key distribution. Fred and Scott ­ both Boeing and JPL working on implementations of key management. Brian ­ there appears to be interest in working on simplified security. Elwynd ­ need to ensure that BP structure does not make security break. Will ­ Does security have to operate with reactive Fragmentation? Scott B.­ If reactive fragmentation is part of core bundle protocol, then security my work with reactive fragmentation or whatever else. EXTENDED CLASS OF SERVICE: Scott B and Keith Scott ­ Extended Class of Service should be left for future work Elwynd ­ forget ECOS, it doesn¹t work except perhaps for close deployments. MULTICAST: Scott B ­ have some work, but propose until next iteration. Elwynd ­ existing protocol has multi-node endpoints. Will ­ ICN has multicast concepts that my be useful. Ronald Velt ­ interested and relevant, but push to later. STREAMING: Scott B. ­ JPL has working solution for NASA. DRL is working on this, but no need for standards track. Keith Scott ­ does base protocol need something for streaming? Answer, ECOS is mandatory for streaming to work, but nothing needed in base protocol. BUNDLE SIZE: Will ­ large, small or what? ­ large bundles requires reactive Fragmentation. Keith ­ perhaps no need for reactive fragmentation. Elwynd ­ restricting bundle size would be fundamental change to architecture/protocol. TIME: Will ­ explained position and referenced wiki: https://sites.google.com/site/dtnresgroup/home/dtn-bone Scott B. ­ Work item but disagrees with Will on time Elwynd ­ keep as work item. Item 18 ­ 22: Bugs, operation in constrained environments, default operations, gateway for 5050. Scott B. ­ all items should be considered. Elwynd ­ do we really need to be gateway consideration. REGISTRY OF SERVICE IDENTIFIER Marc ­ Already a work item. SUMMARY OF TOPICS TO WORK: ======= Phase 1 =================== integrity/header: #6, 7, 9 add?: extension blocks which one are there avoid routing loops: #11 addressing: determine restricted scope? (Fred volunteer working use cases aggregability? ... neighbor discovery draft-irtf-dtnrg-ipnd investigate MANET discovery protocol? (modular approach to hook with routing) static routing remove dictionary time/expiring bundles considerations: on constrained environments, “comptability” with 5050, simplify, default operation registry of service identifier security: sbsp dependency with header changes? interop with reactive fragmentation/other changes in header? tbd registry of service identifier (already a work item) ======= Phase 1.5 =================== network management: monitoring maybe, not configuration for now.. ======= Phase 2 =================== Key management? extended class of service: not for now. multicast: not for now? multipoint? streaming: not for now? ======= No plan =================== dynamic routing: NO. send to RG. ======= No clear consensus ======== bundle size?