[dtn-interest] (no subject)

["Symington, Susan F." <[e-mail]>]

All,

 

Here is my proposed agenda for the non-custodial multicast discussion
we need to have.

 

Objective: Conclude our discussion with an agreement on how
non-custodial multicast should be specified in DTN.

 

Summary of the four identified additional mechanisms that are needed to
support non-custodial DTN multicast:

1.	A way to identify the EID of the node that forwarded a received
bundle. 
2.	An assurance that the EID used to identify this previous hop is
the same EID that the receiving node uses to identify the forwarding
node (and not some other alias EID of the forwarding node)
3.	A way to eliminate or sufficiently mitigate potential implosion
at the report-to endpoint from a multicast bundle that requests status
report generation
4.	If support for multicast is optional rather than mandatory, a
way to encapsulate multicast bundles inside of unicast bundles.

Summary of the proposals made at the Dallas DTNRG meeting to address
the need for the above mechanisms:

1.	Define an optional Previous Hop EID extension header (in a
separate, stand-alone specification) that a forwarding node inserts
into a bundle to identify itself to the receiving node.
2.	Require that each node that is capable of supporting multicast
delivery must have a unique, designated singleton EID that is the only
EID for that node that:

	a.	Other nodes use to identify that node when making
forwarding decisions, and
	b.	That node will ever put in a Previous Hop EID header
that it creates.

3.	Require that local policy must be capable of overriding all
requests for status reporting so as to mitigate the risk of status
report implosion at report-to endpoints.
4.	Assuming that support for multicast is optional rather than
mandatory, require multicast-capable nodes to implement
bundle-in-bundle encapsulation (defined in a separate specification) 

Specifically we want to answer the following questions which have
arisen in previous discussion: 

1.      Should support for non-custodial multicast be mandatory (in the
base bundle protocol) or optional?  By making support mandatory, we
mean that every node would be required to be capable of generating and
processing previous-hop EID headers, though not required to actually
use these headers. (Implementation would be mandatory; use would remain
optional)

2.      How should the problem of potential implosion at the report-to
endpoint of a multicast bundle be mitigated? Some ideas that were
floated include:

a.       Turn off generation of all status reports if the destination
endpoint is not a singleton endpoint? 

b.      Turn off generation of only the "each-hop" status reports if
destination endpoint is not a singleton endpoint (turn off only Request
reporting of bundle reception and Request reporting of bundle
forwarding; leave on Request reporting of bundle delivery, Request
reporting of bundle deletion, and Request acknowledgement by
application ) (For large groups this could still be a problem.)

c.       Say that at any node implementing the Bundle Protocol, local
policy may override status report request flags and not send reports
for multicast bundles. (Question here is how any given node has
knowledge necessary to know whether to override or not.)

3.      What exactly should be the wording of the requirement that each
node have some sort of "designated" EID that denotes it and that it and
other nodes use in specific situations.  (A mechanism for identifying
the previous hop endpoint of a bundle seems to be required for
multicast support. Regardless of how it is implemented, for the
previous-hop EID to be meaningful, there must be a requirement that the
endpoint ID that a node uses to identify itself to others in the
previous hop EID header/field is the same endpoint ID that it's
neighbor nodes use to identify it for the purpose of making forwarding
decisions. Right now there is nothing in the specifications that ensure
that every node has or uses a "designated" EID. Is this a more general
requirement that will be needed to support DTN routing in general or is
it multicast-specific?)

 

Lastly, I am attaching three normative drafts that I put together based
on my presentation at the Dallas meeting. Please look them over and
provide me with comments. They are:

 

1.	Previous Hop Extension Header draft
2.	Bundle-in-Bundle Encapsulation draft
3.	Non-Custodial Multicast Extensions draft

 The multicast extensions draft assumes that multicast remains
optional, so it would have to be modified slightly if we end up
deciding that multicast is mandatory, but the basic ideas would remain
the same. 

 

Thanks.

 

-Susan

 
*****************************************************************
Susan Symington
The MITRE Corporation
[e-mail]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************