Notes on DTNRG meeting 2-Aug-2005 at IETF 63
Chair: Kevin Fall / Intel (Berkeley)
Co-Presenter: Stephen Farrell / Trinity College (Ireland)
Thanks to note-takers:
Daniel Lee
James Scott
(some editing by K. Fall)
Intro (Kevin)
- Many IRTF draft documents updated on http://www.dtnrg.org or through IETF I-D directory
- Mike Demmer (Kevin's student) has version 2 of C++ implementation up at dtnrg.org (cvs and snapshots)
- Mailing lists on www.dtnrg.org too.: dtn-users, dtn-interest, dtn-security
Architecture update (Kevin Fall presenting)
- security issues moved almost entirely to new security document
- "Regions" are actually namespaces
- Endpoint IDs (which may be one or more nodes for uni/multicast) have URIs
- still need to see if wish to use the 'official' URI scheme names
- issues about joining or leaving endpoint IDs in timely fashion (later)
- custody transfer - more issues
- idea that there may be "no" custody if source node cannot provide it
- idea that a node may take custody if unrequested, just because it feels
- what does "reliable" mean -- e.g. custody transfer through "diodes" (IDEA: percentage success report?)
the problem is that across a diode no form of ACK may be possible, causing custody transfers to fail. That can result in the source being told 'your bundle expired' at the last custodian before the diode. Idea is to have another form of message indicating to source that it may have hit a diode. Still needs work.
- priority indicators relative to source, and does not proscribe scheduling (left to implementation)
- API: change wording away from "atomic" since that implies potentially huge transfer across one procedure call, and change wording from "binding" to "registration" for applications registering interest
- "reports" are sent to "report-to" EID, "signals" are signals to prev. custodian e.g. about custody transfer
- arch document is heading towards info-RFC - want suggestions to dtn-interest@mailman.dtnrg.org questions:
- Kevin said he'd put the slides online
- there was some discussion of whether the API is necessary in the doc, the answer was that the API is not mandatory and is there as a reference only, but that it has generally been useful.
Bundle spec update (Kevin Fall presenting)
- Now on draft-irtf-dtnrg-bundle-spec-03
- naming format: <scheme>:<scheme-specific-part>, both kept (separately) in "dictionary".
- strings kept in a dictionary, numbers encoded with flexible length encoding. (SDNV)
- two mandatory headers: primary (at beginning) and payload (at end)
question from Pekka: could payload just be a "header" too?
- multiple nodes with custody (e.g. because of multicast or multiple network paths) is under consideration
- question of whether to have status reports include a copy (or digest) of the message - answer is that maybe
"you can specify"
'is this like ICMP'?
- custody transfer goes from 'custody transfer required' to only 'requested'
Bundle security (Stephen Farrell presenting)
- "motivation draft" is not yet an i-d but en route
- "bundle security spec" is a 00-draft - crypto is "should" implement, but "may" use
- got (bundle security) hop-by-hop authentication
- got "security" end-to-end security header and condfidentiality header
- notion of "security source" and "security dest" which may not be actual source and dest
- based on TLS "ciphersuite" idea where input bits, processing and output bits are all identified (so you can cover payload and parts/all of the header)
q from pekka nikander: why might you want to encode the payload separately from the header (aka why mandate the signature as a trailer)?
a from kevin/stephen: that's probably okay... might be issues with fragmentation...lets discuss on mailing list
a from joerg ott: there is the idea of toilet paper encoding which aids fragmentation which would essentially mean multiple payloads.
q: what about future-defined headers -- how do ciphersuites reference a variety of bits if the headers havent been defined yet?
a: we need to be careful and have canonicalisation, not reorder headers, etc
- nodes need to exchange policy settings in some sensible way so that they can agree on a ciphersuite to use. This is under development.
[discussion on how do we provide confidentiality of the source id - why do we even have the source ID in the header?]
- no real story on key distribution at this time
- CH (confidentiality header), new in this draft, "e2e" privacy
- BAH (bundle auth header) -> hop-by-hop authentication
- PSH (payload security header -- name should be changed?) - e2e auth
LTP (Stephen Farrell presenting)
- a point-to-point protocol for DTNs aimed at deep space (and other long delay things), so avoiding round trips.
- red/green segments for reliable/unreliable
- during transmission, red parts are sent -reliably- first
- "punctuated timers" only decremented during periods when data could actually be arriving
- some security extensions
- 3 irtf drafts (main, motivation, and extensions)
- RFCs soon
PROPHET (Anders Lindgren presenting)
- routing protocol for DTNs relying on mobility of nodes for delivery
- record encounter history and use it as predictor of future meetings
- keep delivery probability vector and use when deciding who to forward bundles to, and also which bundles to drop when queues are full
- apply transitivity and aging to this vector
- exploring various forwarding and queueing strategies
- protocol has neighbour awareness messages, delivery probability information exchanges, bundle exchanges and acks.
- irtf draft is on -01; moving drafts to dtnrg working group in future
- simulated based testing being done
- prototype implementation in java
- demo using lego mindstorms at MobiCom 2005
- future work: create a reference implementation in python
q from kevin: this seems like distance-vector in some regard... do you get problems if things behave unfavourably, e.g. go away for a long long time?
a: rely on aging
q from kevin: do acks follow the send path?
a: acks are epidemically spread
q: is the mindstorms code available?
a: not right now, but it can be made so
- Open issues
Tuning protocol parameters
Custody transfer
Security
Multicast/Anycast (Kevin Fall presenting)
- Paper on this with student Wenrui Zhao at WDTN workshop
- explicit addressing multicast - send it to multiple EIDs (each of which may be one or itself a group)
- group addressing multicast - send to an EID that refers to a group of nodes
- cannot use IP multicast model since delays might be high
- "join" request might have delay parameter. retroactive joins...
- issues with custody transfer - need to retain custody even after delivery to all bound endpoints, just in
case a late binding -- in case someone else turns up-
- anycast - deliver to at least one node which is the current member of a group
…
Q: Why should we have source address in the header?
Closing (Fall)
likely to be another session/update at Vancouver
|
