Minutes for DTN at interim-2014-dtn-1
minutes-interim-2014-dtn-1-1

==============================
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?