Re: [dtn-interest] RFC 5050 revision?

["Burleigh, Scott C (313B)" <[e-mail]>]

I think we got a lot of things right in RFC 5050: I think it's just about open-ended enough -- I'm a big fan of the extension block mechanism -- and I think the notions of node, endpoint, forwarding, delivery, custody, etc. are generally pretty solid.

But I do think we got one major thing wrong: although we recognize the significance of nodes, we nowhere establish any concept of node ID.  All we've got are endpoint IDs.

And we need that concept.  As important as endpoints are, we define a large (and growing) number of critical DTN functions in terms of nodes, not endpoints:
	-  Custody transfer is accomplished between nodes, not endpoints.
	-  In practice, we route on the basis of nodes, not endpoints.  (Delivery predictability in PROPHET, for example, is associated with nodes.  Everything in Contact Graph Routing is implemented in terms of nodes.)
	-  All of the Bundle Security Protocol mechanisms actually operate on the basis of nodes, not endpoints.  (For example, section 1.2 of RFC 6257 defines "security source" and "security destination" as nodes.)

Since nodes have got to be identified in order to accomplish these functions, and we can't live without these functions, we identify nodes now.  We use endpoint identifiers to identify them.

But endpoint identifiers don't identify nodes.  They identify endpoints.

By convention we mutually agree that a node can always be identified by the ID of one of the singleton endpoints in which it is registered (and there always has to be at least one, per section 3.1 of RFC 5050).  This works, so long as our nodes all know which singleton endpoints other nodes are registered in, and those registrations never change without notification to all other nodes who care about them.

But there's nothing in any specification anywhere that requires this persistent registration.  A node could register in a new singleton endpoint (and unregister in all old ones) once every second, making its use as a "router" node impossible, and yet remain fully conformant with RFC 5050.  Since there is no requirement for persistent endpoint registration in any DTN specification, and therefore no assurance of persistent node identity, the foundation on which many critical DTN functions rests is really just good will and out-of-band consensus on the part of node administrators.

I will freely admit to a bias on this topic: I think the CBHE (and "ipn" scheme) notion of explicitly identifying nodes and services (i.e., demuxes) by numbers, expressing most endpoint IDs in terms of node and service numbers, and directly encoding those numeric EIDs as SDNVs in the primary block -- rather than carrying arbitrarily long ASCII strings in a dictionary array -- has been shown to work well, and I'd like to see that representation made standard in the Bundle Protocol rather than supported only as a convergence-layer adaptation.  I'm fully on board with retaining the expressive power of URIs for complex and interesting new destination EIDs (intentional naming, etc.), but the vast bulk of BP traffic now and in the foreseeable future doesn't need any of that power.  I believe we can, and should, optimize for the uninteresting, prevailing case of sending bundles directly to explicitly identified service points at explicitly identified nodes, and define one or more destination EID override extension blocks for the scenarios that need more complex endpoint IDs.

But whether or not we make that adjustment, at the very least I believe we have got to acknowledge nodes as first-class entities in the DTN architecture and decide how we're going to reference them in our protocols.

Scott

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Stephen Farrell
Sent: Tuesday, May 15, 2012 1:01 PM
To: DTN interest
Subject: [dtn-interest] RFC 5050 revision?


Hi all,

As Joerg noted we're interested in whether or not, and if so how, folks would like to do some work on an update or revision for RFC 5050, or ideas for alternatives to the BP or additional DTN protocols.

Things we're interested in hearing about, are:

- Should we rev 5050? why? why not?
- What do you not like about 5050? how'd you fix that?
- What is missing from 5050? how'd you add that?
- What's great about 5050? why'd you keep that?
- What 2119 MUST/SHOULD/MAY would you change and why?
- What DTN research questions would you like to tackle
  where RFC 5050 (or implementations thereof) are
  a barrier?

In addition, we'd be interested in hearing whether folks would like to explore doing DTN based not on a straight revision of the BP, but maybe e.g. based on CoAP, SPDY, websockets, or other protocols.

Or, if you've something else to say/suggest, fo ahead and do that too.

At this point the goal is to gather and discuss ideas on the list, with a view to seeing what's of interest to RG participants.

If we get a bunch of ideas, then we'll try to organise those a bit and start separate threads.
For now, if you can respond to this mail, that'll help us track the discussion later.

Later on, the question of who's actually willing to do stuff will get more interesting, since that's how things get done - just saying that it "must be so"
is frequently trumped by the fact that someone else has the energy to actually do something.

Lastly, none of this means that there's anything wrong with RFC 5050 which has been great for both doing DTN experiments and for the CCSDS folks who're building on it for their work. (And in case CCSDS people get process-scared, no, nothing will ever change the existing RFCs, so documents referring to them are unaffected.)

Cheers,
Stephen, Kevin, Joerg.

_______________________________________________
dtn-interest mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-interest