Subject: RE: [dtn-interest] Non-custodial multicasting in DTN draft
From: "Symington, Susan F." <[email-masked]>
To: "Fall, Kevin" <[email-masked]>, "Durst, Robert C." <[email-masked]>, "Michael Demmer" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 28 Feb 2006 17:20:56 -0500
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Kevin,

In looking over your comments it seems that a reasonable way of
accommodating most of them would be for us to make this document into
four separate documents:

1. Overview of Non-Custodial Multicast in DTN (informative)
2. Previous Hop Endpoint ID Extension Header Definition
3. Bundle-in-Bundle Encapsulation Administrative Record
4. Protocol Extensions to Support Non-Custodial Multicast (normative)

1. The Overview document would include the non-normative parts of the
current document that you wanted removed, such as:
 - the open issues section
 - discussion of use of flooding as a multicast distribution strategy
 - discussion of potential need to enhance the registration semantics
to support temporal semantics, to enforce which nodes are allowed to
join groups, etc.
 - discussion of support for multicast in a mixed-node network (we
realize that you would prefer to remove this discussion entirely and
simply require all nodes to be multicast-capable, but we will leave it
in for now until the wider group is able to discuss and come to some
consensus on the extent to which multicast should be required)
- and also the rationale explaining why each of the other documents is
needed and how they fit into the support of non-custodial multicast in
DTN. 

2. and 3. The Previous Hop Endpoint ID Extension Header Definition and
Bundle-in-Bundle Encapsulation Administrative Record documents would
define the named optional protocol extensions that are separated out
because they may have more general use than just their use with
multicast.

4. The Protocol Extensions to Support Non-Custodial Multicast document
would include:
 - a normative reference to the Previous-Hop Endpoint ID Extension
Header document (i.e., if the multicast routing protocol being used
requires it, the node must be capable of including a previous-hop
endpoint ID extension header so the receiving node knows the ID of the
sending node)
 - a requirement for unique identifiability of all multicast-capable
nodes (in conjunction with the use of the previous-hop endpoint ID
extension header)
 - a stipulation that generation of Bundle Status Reports for multicast
bundles may be overridden by local policy (to enable the avoidance of
implosion at the report-to endpoint, if needed)

So, the Protocol Extensions document would define the list of functions
that may be required, depending on the multicast routing protocol being
used, in order for a node to be non-custodial multicast-capable. 

This is our current thinking on how to best accommodate your comments.
Does it seem sensible to you?

-susan

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

>-----Original Message-----
>From: Fall, Kevin [mailto:[email-masked]] 
>Sent: Saturday, February 25, 2006 2:53 AM
>To: Durst, Robert C.; Michael Demmer; Stephen Farrell
>Cc: Symington, Susan F.; [email-masked]
>Subject: RE: [dtn-interest] Non-custodial multicasting in DTN draft
>
>Thanks for writing this up!
>
>My comments are in the enclosed document.  My recommendation is to
make
>this draft-symington for Monday's cutoff so we be sure it gets into
the
>process, and then go hack on it some more...
>
>Thanks,
>- K
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-interest-
>> [email-masked]] On Behalf Of Durst, Robert C.
>> Sent: Friday, February 24, 2006 3:38 PM
>> To: Michael Demmer; Stephen Farrell
>> Cc: Symington, Susan F.; [email-masked]
>> Subject: RE: [dtn-interest] Non-custodial multicasting in DTN draft
>> 
>> We thought this might have general utility, but wanted to publish it
>as
>> a -00 draft and then have that discussion.
>> 
>> >-----Original Message-----
>> >From: [email-masked]
>> >[mailto:[email-masked]] On Behalf Of
>> >Michael Demmer
>> >Sent: Friday, February 24, 2006 6:13 PM
>> >To: Stephen Farrell
>> >Cc: Symington, Susan F.; [email-masked]
>> >Subject: Re: [dtn-interest] Non-custodial multicasting in DTN draft
>> >
>> >
>> >> Had a quick read of this and I like the idea of the
encapsulation.
>> >> However, it occurs to me that that might be useful as a generic
>> >> mechanism for other, non-multicast reasons too. So I was
wondering
>> >> if it'd be better were that a separate document by itself that'd
>> >> be referenced from the multicast I-D. What do you think?
>> >> (No-one having the energy to do the added work is a fine reason
>> >> not to do this btw. And no, I'm not volunteering either:-)
>> >
>> >I agree with this. Though I'm not volunteering either :-)
>> >
>> >-m
>> >_______________________________________________
>> >dtn-interest mailing list
>> >[email-masked]
>> >http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>> >
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Content-class: urn:content-classes:message
Date: Mon, 27 Feb 2006 10:27:10 -0800
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] FW: [IRSG] please publish draft-irtf-rfcs-00.txt
Sender: [email-masked]

This is the new proposed RG RFC doc format.  It should be an ID this
week.

- K

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Aaron Falk
> Sent: Sunday, February 26, 2006 9:24 PM
> To: [email-masked]
> Subject: [IRSG] please publish draft-irtf-rfcs-00.txt
> 
> Dear ID editor-
> 
> Please publish the document at this URL, <http://www.isi.edu/~falk/
> papers/draft-irtf-rfcs-00.txt>, as an Internet Draft.
> 
> Regards,
> 
> --Aaron Falk, IRTF Chair
> _______________________________________________
> IRSG mailing list
> [email-masked]
> http://mailman.isi.edu/mailman/listinfo/irsg

Content-class: urn:content-classes:message
Date: Mon, 27 Feb 2006 13:23:58 -0500
From: "Scott, Keith L." <[email-masked]>
To: <[email-masked]>
Cc: "Fall, Kevin" <[email-masked]>, "Scott Burleigh" <[email-masked]>
Subject: [dtn-interest] IRTF RFC document process -- Bundle Protocol Specification
Sender: [email-masked]

All,

In support of the revised IRTF document process, I'd like to solicit
nods of approval from the working group on the current draft of the
Bundle Protocol Specification:

https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=10
154

Please respond with a short 'yes' or 'no' as to whether you agree with
the current specification or not.

		--keith

Date: Mon, 27 Feb 2006 08:55:05 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Motivation of DTN
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------040806050208040505000701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Rajesh Krishnan wrote:

>>Hi
>>
>>I am a newbie to DTN i have been reading few papers on it since last few
>>days. One question which is still unclear that what is the novelity in DTN
>>networking due to following reasons.
>>
>>As it is apparent e-mail like architecture and its just an application for
>>reliable delivery of messages. The only difference lies in  Network layer
>>more specifically in routing. But we have same chracterstic of intermittency
>>in mobile Ad Hoc Networks so why do we need specialize routing algorithm for
>>DTN?
>>
>>In other words; what aspects differentiate DTN from AD hoc networks?
>>
>>Regards
>>
>>Obaid
>>    
>>
>Obaid,
>
>Here is my personal view on this issue.  Others on the list may be 
>able to provide clearer insights into this issue.
>
>A key difference between traditional networks (including MANETs) and 
>DTN is the fact that in traditional networks, communications occur under
>the "eventual stability" model, that is, an end-to-end path must
>exist between the endpoints involved in the communication.  In DTNs, 
>the weaker "eventual connectivity" model is supported; communication 
>can take place as long as there is no permanent cut (necessary and 
>sufficient condition)  between the source and destination. There
>is a desire to support communications in DTNs even if the source 
>leaves the network after originating a message.  The need to support
>the eventual connectivty model, IMHO, is the fundamental distinction 
>between traditional networks (including MANETs) and DTNs.
>
>If an end-to-end path cannot be determined, data will typically be 
>discarded by intermediate nodes in traditional networks.  Clearly,
>storage and delegation of retransmission responsibility are corrollary 
>necessities for achieving communications under eventual connectivity.
>A number of interesting algorithmic and engineering challenges and
>new resource trade-offs arise when we add in-network storage and 
>retransmissions.  Highly interactive/chatty protocols will not work in
>DTNs due to extermely high path delays and asymmetry; this requires 
>a more radical rethinking of protocol and sometimes application 
>design assumptions.
>
>Beyond the basic distinctions, we ultimately want a solution that works
>in a wide range of scenarios (when the eventual stability assumption
>holds and when it doesn't, when adversaries are present, when node and
>link failures are common, when parts of the network are highly
>challenged).  We want a solution that takes into account many different
>types of connectivity: static adjacencies, discovered adjacencies
>(MANETs focus on this), scheduled adjacencies, on-demand adjacencies
>(effect/exploit not just expect mobility to achieve delivery), and
>predictive adjacencies.  In stable networks, algorithms that can work
>under eventual connectivity (consider pure flooding as a trivial
>example), tend to be less message-efficient than their eventual
>stability counterparts (say link-state routing).  DTN routing algorithms
>must be adaptive, and must deal with a much wider range of heterogeneity
>in network characteristics (capacity, delay, availability, error) than
>is typical for MANETs.  Ideally, a DTN solution must subsume existing
>solutions (adaptively choosing the best for each situation), and enable
>incorporation of new solutions within the same framework.
>
>Best Regards,
>Rajesh
>
>========================================================================
>Rajesh Krishnan, Ph.D.
>Senior Scientist                     Email: [email-masked]
>Internetwork Research Department     Phone: +1 617 873 4684
>BBN Technologies                     Fax:   +1 617 873 6091
>10 Moulton Street, Mailstop 6/5c     GPS:   N42°23.36' W71°08.86'
>Cambridge, MA 02138, USA             Web:   http://www.ir.bbn.com/~krash
>========================================================================
>  
>
This is very well put, Rajesh.  As an alternative, long-winded way of 
saying what I think amounts to the same thing, I would suggest that the 
central differentiating notion in DTN architecture is a re-application 
of the end-to-end principle to what we sometimes call "challenged" 
networks -- those where timely, continuous interchange between 
applications at the ends is frequently impossible

The end-to-end argument -- that is, the Salzer and Clark paper from 1984 
-- says in essence that many network functions 
(acknowledgement/retransmission, for example) should be performed only 
at the ends, where the applications reside, because performing those 
functions at those points is necessary and sufficient.  Performing such 
functions at intermediate points within the network is sometimes okay, 
but only where the increase in cost is justified by enhanced performance.

But when timely, continuous interchange between applications at the end 
is impossible -- because of lengthy signal propagation delays and/or 
link interruptions -- some of these functions can no longer be 
effectively performed at the ends.  Performing them at intermediate 
points within the network then becomes necessary rather than optional, 
because the resulting performance enhancements are the only way to 
assure any communication at all.

In my mind, this is what DTN is ultimately about: each point in the 
end-to-end path, acting autonomously on information that is available 
locally, has to take on additional responsibility for assuring 
end-to-end communication.

Scott

--------------040806050208040505000701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Rajesh Krishnan wrote:
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">Hi

I am a newbie to DTN i have been reading few papers on it since last few
days. One question which is still unclear that what is the novelity in DTN
networking due to following reasons.

As it is apparent e-mail like architecture and its just an application for
reliable delivery of messages. The only difference lies in  Network layer
more specifically in routing. But we have same chracterstic of intermittency
in mobile Ad Hoc Networks so why do we need specialize routing algorithm for
DTN?

In other words; what aspects differentiate DTN from AD hoc networks?

Regards

Obaid
    </pre>
  </blockquote>
  <pre wrap=""><!---->Obaid,

Here is my personal view on this issue.  Others on the list may be 
able to provide clearer insights into this issue.

A key difference between traditional networks (including MANETs) and 
DTN is the fact that in traditional networks, communications occur under
the "eventual stability" model, that is, an end-to-end path must
exist between the endpoints involved in the communication.  In DTNs, 
the weaker "eventual connectivity" model is supported; communication 
can take place as long as there is no permanent cut (necessary and 
sufficient condition)  between the source and destination. There
is a desire to support communications in DTNs even if the source 
leaves the network after originating a message.  The need to support
the eventual connectivty model, IMHO, is the fundamental distinction 
between traditional networks (including MANETs) and DTNs.

If an end-to-end path cannot be determined, data will typically be 
discarded by intermediate nodes in traditional networks.  Clearly,
storage and delegation of retransmission responsibility are corrollary 
necessities for achieving communications under eventual connectivity.
A number of interesting algorithmic and engineering challenges and
new resource trade-offs arise when we add in-network storage and 
retransmissions.  Highly interactive/chatty protocols will not work in
DTNs due to extermely high path delays and asymmetry; this requires 
a more radical rethinking of protocol and sometimes application 
design assumptions.

Beyond the basic distinctions, we ultimately want a solution that works
in a wide range of scenarios (when the eventual stability assumption
holds and when it doesn't, when adversaries are present, when node and
link failures are common, when parts of the network are highly
challenged).  We want a solution that takes into account many different
types of connectivity: static adjacencies, discovered adjacencies
(MANETs focus on this), scheduled adjacencies, on-demand adjacencies
(effect/exploit not just expect mobility to achieve delivery), and
predictive adjacencies.  In stable networks, algorithms that can work
under eventual connectivity (consider pure flooding as a trivial
example), tend to be less message-efficient than their eventual
stability counterparts (say link-state routing).  DTN routing algorithms
must be adaptive, and must deal with a much wider range of heterogeneity
in network characteristics (capacity, delay, availability, error) than
is typical for MANETs.  Ideally, a DTN solution must subsume existing
solutions (adaptively choosing the best for each situation), and enable
incorporation of new solutions within the same framework.

Best Regards,
Rajesh

========================================================================
Rajesh Krishnan, Ph.D.
Senior Scientist                     Email: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Internetwork Research Department     Phone: +1 617 873 4684
BBN Technologies                     Fax:   +1 617 873 6091
10 Moulton Street, Mailstop 6/5c     GPS:   N42&deg;23.36' W71&deg;08.86'
Cambridge, MA 02138, USA             Web:   <a class="moz-txt-link-freetext" href="http://www.ir.bbn.com/~krash">http://www.ir.bbn.com/~krash</a>
========================================================================
  </pre>
</blockquote>
This is very well put, Rajesh.&nbsp; As an alternative, long-winded way of
saying what I think amounts to the same thing, I would suggest that the
central differentiating notion in DTN architecture is a re-application
of the end-to-end principle to what we sometimes call "challenged"
networks -- those where timely, continuous interchange between
applications at the ends is frequently impossible<br>
<br>
The end-to-end argument -- that is, the Salzer and Clark paper from
1984 -- says in essence that many network functions
(acknowledgement/retransmission, for example) should be performed only
at the ends, where the applications reside, because performing those
functions at those points is necessary and sufficient.&nbsp; Performing such
functions at intermediate points within the network is sometimes okay,
but only where the increase in cost is justified by enhanced
performance.<br>
<br>
But when timely, continuous interchange between applications at the end
is impossible -- because of lengthy signal propagation delays and/or
link interruptions -- some of these functions can no longer be
effectively performed at the ends.&nbsp; Performing them at intermediate
points within the network then becomes necessary rather than optional,
because the resulting performance enhancements are the only way to
assure any communication at all.<br>
<br>
In my mind, this is what DTN is ultimately about: each point in the
end-to-end path, acting autonomously on information that is available
locally, has to take on additional responsibility for assuring
end-to-end communication.<br>
<br>
Scott<br>
<br>
</body>
</html>

--------------040806050208040505000701--

Content-class: urn:content-classes:message
Date: Mon, 27 Feb 2006 08:30:03 -0800
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] reminder: today's bridge number
Sender: [email-masked]

Monday, February 27, 2006 10:00 AM US Pacific Time  Where: 8-356-2663,
916-356-2663, Bridge: 1, Passcode: 8335461 

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Motivation of DTN
To: [email-masked] (Syed Obaid Amin)
Date: Sun, 26 Feb 2006 17:42:22 -0500 (EST)
Cc: [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

> Hi
> 
> I am a newbie to DTN i have been reading few papers on it since  last few
> days. One question which is still unclear that what is the novelity in DTN
> networking due to following reasons.
> 
>  As it is apparent e-mail like architecture and its just  an application fo=
> r
> reliable delivery of messages. The only difference lies in  Network layer
> more specifically in routing. But we have same chracterstic of intermittenc=
> y
> in mobile Ad Hoc Networks so why do we need specialize routing algorithm fo=
> r
> DTN?
> 
> In other words; what   aspects differentiate  DTN from AD hoc networks?
> 
> Regards
> 
> Obaid

Obaid,

Here is my personal view on this issue.  Others on the list may be 
able to provide clearer insights into this issue.

A key difference between traditional networks (including MANETs) and 
DTN is the fact that in traditional networks, communications occur under
the "eventual stability" model, that is, an end-to-end path must
exist between the endpoints involved in the communication.  In DTNs, 
the weaker "eventual connectivity" model is supported; communication 
can take place as long as there is no permanent cut (necessary and 
sufficient condition)  between the source and destination. There
is a desire to support communications in DTNs even if the source 
leaves the network after originating a message.  The need to support
the eventual connectivty model, IMHO, is the fundamental distinction 
between traditional networks (including MANETs) and DTNs.

If an end-to-end path cannot be determined, data will typically be 
discarded by intermediate nodes in traditional networks.  Clearly,
storage and delegation of retransmission responsibility are corrollary 
necessities for achieving communications under eventual connectivity.
A number of interesting algorithmic and engineering challenges and
new resource trade-offs arise when we add in-network storage and 
retransmissions.  Highly interactive/chatty protocols will not work in
DTNs due to extermely high path delays and asymmetry; this requires 
a more radical rethinking of protocol and sometimes application 
design assumptions.

Beyond the basic distinctions, we ultimately want a solution that works
in a wide range of scenarios (when the eventual stability assumption
holds and when it doesn't, when adversaries are present, when node and
link failures are common, when parts of the network are highly
challenged).  We want a solution that takes into account many different
types of connectivity: static adjacencies, discovered adjacencies
(MANETs focus on this), scheduled adjacencies, on-demand adjacencies
(effect/exploit not just expect mobility to achieve delivery), and
predictive adjacencies.  In stable networks, algorithms that can work
under eventual connectivity (consider pure flooding as a trivial
example), tend to be less message-efficient than their eventual
stability counterparts (say link-state routing).  DTN routing algorithms
must be adaptive, and must deal with a much wider range of heterogeneity
in network characteristics (capacity, delay, availability, error) than
is typical for MANETs.  Ideally, a DTN solution must subsume existing
solutions (adaptively choosing the best for each situation), and enable
incorporation of new solutions within the same framework.

Best Regards,
Rajesh

========================================================================
Rajesh Krishnan, Ph.D.
Senior Scientist                     Email: [email-masked]
Internetwork Research Department     Phone: +1 617 873 4684
BBN Technologies                     Fax:   +1 617 873 6091
10 Moulton Street, Mailstop 6/5c     GPS:   N42°23.36' W71°08.86'
Cambridge, MA 02138, USA             Web:   http://www.ir.bbn.com/~krash
========================================================================

Date: Mon, 27 Feb 2006 07:18:13 +0900
From: "Syed Obaid Amin" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Motivation of DTN
Sender: [email-masked]

------=_Part_809_18459172.1140992293911
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi

I am a newbie to DTN i have been reading few papers on it since  last few
days. One question which is still unclear that what is the novelity in DTN
networking due to following reasons.

 As it is apparent e-mail like architecture and its just  an application fo=
r
reliable delivery of messages. The only difference lies in  Network layer
more specifically in routing. But we have same chracterstic of intermittenc=
y
in mobile Ad Hoc Networks so why do we need specialize routing algorithm fo=
r
DTN?

In other words; what   aspects differentiate  DTN from AD hoc networks?

Regards

Obaid

------=_Part_809_18459172.1140992293911
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>Hi</div>
<div>&nbsp;</div>
<div>I am a newbie to DTN i have been reading few papers on it since &nbsp;=
last few days. One question which is still unclear that what is the novelit=
y in DTN networking due to following reasons.</div>
<div>&nbsp;</div>
<div>&nbsp;As it is apparent e-mail like architecture&nbsp;and&nbsp;its jus=
t&nbsp;&nbsp;an application for reliable delivery of messages. The only dif=
ference lies in&nbsp; Network layer more specifically in routing. But we ha=
ve same chracterstic of intermittency in mobile Ad Hoc Networks so why do w=
e need specialize routing algorithm for DTN?
</div>
<div>&nbsp;</div>
<div>In other words;&nbsp;what &nbsp;&nbsp;aspects differentiate &nbsp;DTN =
from AD hoc networks?</div>
<div>&nbsp;</div>
<div>Regards</div>
<div>&nbsp;</div>
<div>Obaid</div>
<div>&nbsp;</div>

------=_Part_809_18459172.1140992293911--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Non-custodial multicasting in DTN draft
Date: Fri, 24 Feb 2006 23:53:13 -0800
From: "Fall, Kevin" <[email-masked]>
To: "Durst, Robert C." <[email-masked]>, "Michael Demmer" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "Symington, Susan F." <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C639E0.88E91F1B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks for writing this up!

My comments are in the enclosed document.  My recommendation is to make
this draft-symington for Monday's cutoff so we be sure it gets into the
process, and then go hack on it some more...

Thanks,
- K

> -----Original Message-----
> From: [email-masked] [mailto:dtn-interest-
> [email-masked]] On Behalf Of Durst, Robert C.
> Sent: Friday, February 24, 2006 3:38 PM
> To: Michael Demmer; Stephen Farrell
> Cc: Symington, Susan F.; [email-masked]
> Subject: RE: [dtn-interest] Non-custodial multicasting in DTN draft
>=20
> We thought this might have general utility, but wanted to publish it
as
> a -00 draft and then have that discussion.
>=20
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]] On Behalf Of
> >Michael Demmer
> >Sent: Friday, February 24, 2006 6:13 PM
> >To: Stephen Farrell
> >Cc: Symington, Susan F.; [email-masked]
> >Subject: Re: [dtn-interest] Non-custodial multicasting in DTN draft
> >
> >
> >> Had a quick read of this and I like the idea of the encapsulation.
> >> However, it occurs to me that that might be useful as a generic
> >> mechanism for other, non-multicast reasons too. So I was wondering
> >> if it'd be better were that a separate document by itself that'd
> >> be referenced from the multicast I-D. What do you think?
> >> (No-one having the energy to do the added work is a fine reason
> >> not to do this btw. And no, I'm not volunteering either:-)
> >
> >I agree with this. Though I'm not volunteering either :-)
> >
> >-m
> >_______________________________________________
> >dtn-interest mailing list
> >[email-masked]
> >http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

------_=_NextPart_001_01C639E0.88E91F1B
Content-Type: text/plain;
	name="kfall-comments.txt"
Content-Transfer-Encoding: base64
Content-Description: kfall-comments.txt
Content-Disposition: attachment;
	filename="kfall-comments.txt"

------_=_NextPart_001_01C639E0.88E91F1B--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Non-custodial multicasting in DTN draft
Date: Fri, 24 Feb 2006 18:37:42 -0500
From: "Durst, Robert C." <[email-masked]>
To: "Michael Demmer" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "Symington, Susan F." <[email-masked]>, <[email-masked]>
Sender: [email-masked]

We thought this might have general utility, but wanted to publish it as
a -00 draft and then have that discussion. 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>Michael Demmer
>Sent: Friday, February 24, 2006 6:13 PM
>To: Stephen Farrell
>Cc: Symington, Susan F.; [email-masked]
>Subject: Re: [dtn-interest] Non-custodial multicasting in DTN draft
>
>
>> Had a quick read of this and I like the idea of the encapsulation.
>> However, it occurs to me that that might be useful as a generic
>> mechanism for other, non-multicast reasons too. So I was wondering
>> if it'd be better were that a separate document by itself that'd
>> be referenced from the multicast I-D. What do you think?
>> (No-one having the energy to do the added work is a fine reason
>> not to do this btw. And no, I'm not volunteering either:-)
>
>I agree with this. Though I'm not volunteering either :-)
>
>-m
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Fri, 24 Feb 2006 15:13:29 -0800
From: Michael Demmer <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: "Symington, Susan F." <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Non-custodial multicasting in DTN draft
Mail-Followup-To: Stephen Farrell <[email-masked]>, "Symington, Susan F." <[email-masked]>, [email-masked]
Sender: [email-masked]

> Had a quick read of this and I like the idea of the encapsulation.
> However, it occurs to me that that might be useful as a generic
> mechanism for other, non-multicast reasons too. So I was wondering
> if it'd be better were that a separate document by itself that'd
> be referenced from the multicast I-D. What do you think?
> (No-one having the energy to do the added work is a fine reason
> not to do this btw. And no, I'm not volunteering either:-)

I agree with this. Though I'm not volunteering either :-)

-m

Date: Fri, 24 Feb 2006 22:49:41 +0000
From: Stephen Farrell <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Non-custodial multicasting in DTN draft
Sender: [email-masked]

Hi Susan,

Had a quick read of this and I like the idea of the encapsulation.
However, it occurs to me that that might be useful as a generic
mechanism for other, non-multicast reasons too. So I was wondering
if it'd be better were that a separate document by itself that'd
be referenced from the multicast I-D. What do you think?
(No-one having the energy to do the added work is a fine reason
not to do this btw. And no, I'm not volunteering either:-)

I'm also a bit confused as to why the previous-hop extension is
the thing to do. (Maybe I need to read it more closely.) Did you
consider defining a "Via" extension that could be accumulated as
a bundle gets routed. I remember that that got mentioned at some
DTN meeting sometime, but I don't remember if there was a reason
to not do that.

Cheers,
Stephen.

PS: Is the draft published yet? I didn't see it and the cutoff
date for -00 drafts before Dallas is coming up soon.

Symington, Susan F. wrote:
> All,
>  
> We would like to submit the attached document as an internet draft. It 
> discusses non-custodial support for multicast in DTN, meaning it 
> discusses how to support multicast delivery of bundles, but it does not 
> provide support for custody transfer of multicast bundles.
>  
> We would appreciate your posting any comments you might have. Thanks.
>  
> -susan
>  
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************
>  

To: [email-masked]
From: Manikantan Ramadas <[email-masked]>
Date: Thu, 23 Feb 2006 08:02:14 -0500
Subject: [dtn-interest] Call For Papers : SMC-IT Miniworkshop
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-3--816222997
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed

Hi folks,

	We seek your participation in the workshop on "Next Generation =20=

Communication Infrastructure for Deep-Space Communications" we are =20
organizing at the Space Mission Challenges for IT conference. The =20
official CFP follows :

Call for Papers

Two day workshop on the Next Generation Communication Infrastructure =20
for Deep-Space Communications to be held in conjunction with the =20
Second International Conference on Space Mission Challenges for =20
Information Technology (SMC-IT), July 17-21, 2006, Pasadena, California.

Description

In the coming decades, NASA is targeting an extensive study of the =20
lunar environment along with continued robotic missions to Mars and =20
other corners of the solar system.  The European Space Agency is =20
developing plans for a similar venture with its Aurora project and =20
countries such as China and India are considering lunar missions on =20
their own. With the many fold increase in spacecraft beyond Earth =20
orbit, the standard method of preplanned communication links for deep =20=

space elements has the potential to become complex and unmanageable.  =20=

The goal of this workshop is to bring together mission operators, and =20=

managers, and researchers from the network and information technology =20=

community to discuss both near-term and long-term communication =20
challenges.  By doing so, those on the front lines of the solar =20
system exploration effort can provide first hand accounts of how =20
missions currently operate while at the same time providing a =20
=93reality check=94 on future research directions.  At the same time, =20=

researchers from academia can provide insight into the substantial =20
body of knowledge into the design of communication protocols, =20
architecture, network-modeling and other areas that may have direct =20
relevance to the deep space communication environment or have =20
interesting applied value in unique ways.

For this workshop we seek short abstracts of  novel ideas including =20
those at their nascent stages of study from the following areas (not =20
exclusively):

Current relay communication architectures
Deep space mission scenarios
Delay and Disruption Tolerant Networking
Novel network architecture, protocols, and paradigms
Security infrastructure, models
Scheduling, optimization, and management of communication infrastructure

Abstracts need to be submitted by email to the Program Co-Chairs. =20
Selected abstracts will be made available to all conference attendees.

Important Dates :

Abstracts (1-2 pages in size) due by April 3, 2006.
Notification of Acceptance June 5th 2006
Final Presentations due by July 3rd 2006.

Program Co-Chairs
	Leigh Torgerson, NASA/JPL, [email-masked]
	Manikantan Ramadas, Ohio University, [email-masked]

Program Committee
	Christopher Krupiarz, JHU/APL, [email-masked]
	Shawn Ostermann, Ohio University, [email-masked]
	Hans Kruse, Ohio University, [email-masked]
	Stephen Farrell, Trinity College Dublin, =
[email-masked]

--------

Please feel to mail us if you have any questions.

Thank you,
Mani.

--
"Always being cheerful and being happy takes you get closer to God than
any prayer"    - Anonymous

____________________________________________________________________

* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--Apple-Mail-3--816222997
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-3--816222997--

Content-class: urn:content-classes:message
Date: Wed, 22 Feb 2006 11:38:49 -0800
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] IRTF RFC document process
Sender: [email-masked]

Hello folks.

So, the IETF is re-examining the way in which IRTF documents are handled
in the IETF.  Up until now they have always been handled as 'individual
contributions' meaning they were basically handled as though written by
one particular individual.  This is evolving to have a mechanism whereby
an entire research group can say "I agree with this" and the document
will carry a bit more formality than an individual submit.  It will
still not represent an official Internet standard, as such, but the
current proposed process will include a comment in the text as to the
fact that the document represents concensus among the RG members.  In
addition, there is some provision for external review.

I believe the two following documents are our most mature at the moment
(please let me know if you feel differently).  So, I would like to
solicit any final remaining comments before I push these into the RFC
process.  They are as follows:

https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=101
57

https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=101
54

Please just drop me a short "yep" email if you feel fine with these.
Also, if you have any serious concerns, NOW IS THE TIME, as I am
soliciting external review for them presently which will get them into
the pipeline.
 
Thanks,
- Kevin

Date: Mon, 20 Feb 2006 14:36:17 -0800 (PST)
From: "Kevin C. Almeroth" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP:  Sigcomm Workshop on Challenged Networks (CHANTS)
Sender: [email-masked]

(See below:  papers are due April 21st)

=====================================================================
		  	  CALL FOR PAPERS
     Sigcomm 2006 - Workshop on Challenged Networks (CHANTS-06)
   	      Pisa, Italy - September 11-15, 2006
=====================================================================

Technical Area:

   Challenged networks include those found in mobile and in-motion 
networking, dynamic wireless networks, heterogeneous and mobile 
sensor networks, interplanetary networking, and networks providing 
rural connectivity. Such networks are not well served by standard 
TCP/IP solutions, due to the prevalence of disconnection, disruption, 
intermittency, large delays, or other factors. 

   Today, the most successful network architecture is that of the 
Internet. It has scaled well beyond the original plan of its 
designers, and the Internet Protocol has been carried on a great 
number of underlying protocols, including itself. However, the 
Internet's protocol architecture suffers some problems when 
implemented on classes of networks for which it was not originally 
designed. For example, when disconnection and reconnection is common, 
or link performance is highly variable or extreme, one or more of the 
traditional Internet protocols do not work well. In this workshop, we 
wish to explore physical networks that operate significantly 
differently from wired, connected networks and the protocol 
architectures and algorithms used to deal with such situations. 
Techniques for making applications tolerant to disruptions and/or 
high delays are also in scope. More specifically, we solicit papers 
in the following areas:

- Characterization of performance-challenged networks, 
e.g. network measurements.
- Networking systems operating over unusual/challenged networks.
- Protocol design and evaluation of operations over challenged 
networks.
- Robust network application design and implementation techniques. 
- Delay tolerant and disruption tolerant networks (DTN).
- Situated and autonomic communications for challenged networks.
- Handling user concerns in challenged networks such as usability, 
privacy, security and incentives to cooperate.

   Submissions may include presentations of specific systems or 
performance measurements, as well as more general, philosophical 
position papers. Papers that bring out interesting and novel ideas at 
an early stage in their development are favored over highly polished, 
journal-style results. Selected papers will be forward-looking, with 
impact and implications for ongoing or future research. We aim to 
accept around 15 papers, and to have a highly interactive workshop 
focusing on broader issues and community development.

Paper Format and Submission:

   Submitted papers must be no more than 8 pages long, double 
column, with no characters smaller than 10 point fonts.  Papers will 
be reviewed single blind, which means be sure to include author 
information on the first page after the title and before the 
abstract. Papers that do not adhere to these requirements exactly (or 
attempt to cheat on spacing or fonts) will not be accepted for 
submission.

   Paper submission will be via EDAS.  The exact URL will be posted 
by April 1, 2006.

Important Dates:

	Submission Deadline: 21 April 2006
	Notification of Acceptance: 2 June 2006
	Camera Ready Deadline: 16 June 2006
	Workshop Date: 11-15 Sept 2006

Organizing Committee:

	Technical Program Co-chairs:

		Kevin Almeroth, UC-Santa Barbara
		Email: [email-masked]

		James Scott, Intel Research Cambridge
		Email: [email-masked]

	Program Committee Members: (Under Construction)

	Webmaster:  Khaled Harras, UC-Santa Barbara

=====================================================================

Date: Thu, 16 Feb 2006 14:40:37 -0600
From: Georgios Lazarou <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CAMAD'06 Deadline extension to Feb.22nd, 2006
Sender: [email-masked]

========================================================================
             CALL FOR PAPERS

11th International Workshop on Computer Aided Modeling and Design
     of Communication Links and Networks (CAMAD'06)
         Trento, Italy, June 8-9, 2006
         http://dit.unitn.it/~camad06

       Technically Co-Sponsored by IEEE Communication Society

The 11th International Workshop on Computer-Aided Modeling and Design of
Communication Links and Networks (CAMAD) is a unique forum that brings
together major experts around the globe on modeling and simulation of
communications systems.

The workshop is a bi-annual event, often held  in cooperation with
flagship IEEE Communication Society conferences (Int.l Conference on
Communications - ICC, Global Telecommunication Conference - GLOBECOM).
Last CAMAD'04 was held in conjunction with Globecom2004 in Dallas, TX,
on Nov.29th, 2004.

CAMAD'06 will be a two days stand-alone event, held in the beautiful
city of Trento, just before ICC 2006 (Instanbul, Turkey). Specific
information about the connection between Italy and Turkey will be
provided on the workshop website.

CAMAD'06 is soliciting papers describing original, unpublished and not
currently submitted for publication elsewhere, on topics, including but
not limited to, the following:

o Modeling and Simulation techniques for Integrated Communication Systems
o Traffic Engineering and Analysis
o Network Measurements
o Simulation techniques for large-scale Networks
o Simulation and Fast Simulation Techniques for Communication Networks
o Validation of Simulation Models with Measurements
o Network Optimization and Resource Provisioning
o Next Generation Internet
o Overlay and Virtual Networks
o Autonomic Communication Systems
o Cross-Layer Protocol Design
o Network Monitoring
o Internet Traffic Modeling
o Wireless, Mobile, Ad hoc and Sensor Networks
o Modeling and Design of Wireless Ad Hoc Networks
o Seamless Integration of Wireless (Cellular) Networks with Internet
o Design of Satellite Networks
o Integration of Terrestrial and Satellite Networks

The event is sponsored by the University of Trento, and endorsed by the
IEEE Technical Committees on Communications Systems Integration and
Modeling (CSIM) and Satellite and Space Communications (SSC).

========================================================================
             PAPER SUBMISSION

Prospective authors are invited to submit full paper of not more than
eight (8) IEEE style pages including results, figures and references.
Papers will be reviewed with the standard reviewing procedure (each
paper being sent to at least 3 independent anonymous reviewers).

Accepted papers will be published on IEEExplore
(http://ieeexplore.ieee.org/).

The best accepted paper will receive the Best Paper Award, sponsored by
IEEE ComSocCSIM Technical Committee.

- Paper Submission:        February 22, 2006  *NEW*
- Notification of acceptance:    April 15, 2006
- Submission of camera-ready papers: May 7, 2006

========================================================================
             COMMITTEES

General Chair:
Fabrizio Granelli (Univ. of Trento, Italy)

Technical Program Co-Chairs:
Georgios Lazarou (Mississippi State Univ., U.S.)
Changcheng Huang (Carleton Univ., CA, U.S.)

Publication Chair:
Dzmitry Kliazovich (Univ. of Trento, ITALY)

Local Arrangements:
Ufficio Manifestazioni e Convegni (U. Trento, ITALY)

Steering Committee Chair:
Michael Devetsikiotis (North Carolina State Univ., U.S.)

Steering Committee:
Nelson L.S. da Fonseca (UNICAMP, Brazil)
Pascal Lorenz (Univ. of Haute Alsace, France)
Hussein Mouftah (Univ. of Ottawa, CA, U.S.)

Technical Program Committee:
Fatih Alagoz (Bogazici University, Turkey)
Giulia Boato (Univ. Trento, IT)
Stephen Bush (GE, USA)
Luiz DaSilva (VirginiaTech, USA)
Periklis Chatzimisios (TEI of Thessaloniki, Greece)
Mike Devetsikiotis (NCSU, USA)
Christos Douligeris (Univ. of Piraeus, Greece)
Rachid Elazouzi (Univ. of Avignon, France)
Lars Erup (EMS Satellite Networks, CA)
Sally Floyd (ICIR, USA)
Nelson L.S. da Fonseca (Unicamp, Brasil)
Victor Frost (Univ. of Kansas, USA)
Stefano Giordano (Univ. Pisa, IT)
Pin-Han Ho (Univ. of Waterloo, Canada)
Rose Q. Hu (Nortel, USA)
Abbas Jamalipour (Univ. of Sydney, Australia)
Gabriel Junyent (UPC/CTTC, Spain)
Dzmitry Kliazovich (U. Trento, Italy)
Jie Li (Univ. of Tsukuba, Japan)
Xian Liu (Univ. of Arkansas at Little Rock, USA)
Renato Lo Cigno (U. Trento, Italy)
Pascal Lorenz (Univ. of Haute-Alsace, France)
Zhisheng Niu (Tsinghua Univ., China)
Otilia Popescu  (UTSA, USA)
Petia Todorova (Fraunhofer Institut FOKUS, Germany)
Steven Wright (BellSouth, USA)

========================================================================

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Non-custodial multicasting in DTN draft
Date: Wed, 15 Feb 2006 15:29:08 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6326E.79753B92
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C6326E.79753B92"

------_=_NextPart_002_01C6326E.79753B92
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Scott,
=20
Great!  I addressed both of your remaining two concerns in the attached
new version.
=20
- I removed the ambiguous "go to may" wording mentioned in item 4. For
your information, non-multicast-capable nodes may participate in a
general flooding protocol.
=20
- I inserted the suggested brief rationale in item 5.
=20
Thanks again for reading this and for providing helpful comments.=20
=20
-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
=20

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott
Burleigh
	Sent: Wednesday, February 15, 2006 2:05 PM
	To: [email-masked]
	Subject: Re: [dtn-interest] Non-custodial multicasting in DTN
draft
=09
=09
	Symington, Susan F. wrote:=20

		Scott,
		=20
		Thanks very much for reading this through.  I agree
with your comments in items 1, 2, and 3 and revised the document
accordingly.
		=20
		With regard to item 4, I did not remove the word "may"
because this would imply that all multicast-capable nodes participate
in multicast routing protocols, but we can have multicast-capable nodes
and just use either static, predefined routing (like we do now with
"unicast-capable" nodes) or flooding as our bundle dissemination
mechanisms.

	Sorry, I should have provided a better pointer to the text I
was talking about: the "may" I meant was the one at the start of the
second bullet under the "- Do not" bullet under "-
Non-multicast-capable nodes, which we define as nodes that".  As it is
now, the text signifies that part of the definition of
non-multicast-capable nodes is that they "Do not may participate in a
general flooding protocol" when I think you mean to say that they "Do
not participate in a general flooding protocol".
=09

		To answer your question with regard to item 5, we chose
to use an administrative record rather than an extension header because
it seemed the easiest way for us to fit the encapsulation capability
into the model of what a bundle node is. When the encapsulated bundle
is delivered at a node, we want it to be delivered to the node's
application agent's (AA's) administrative element, not to the node's
AA's application-specific element. This is because the administrative
element will process the encapsulated bundle by extracting the "inner"
bundle from the payload field of the encapsulated bundle and then
sending this inner bundle down to its bundle protocol agent (BPA) to be
delivered and/or forwarded.

	Right, that's exactly the rationale I finally figured out.
=09

		Furthermore, along with this inner bundle, the
administrative element may also need to send to its BPA a list of one
or more next-hop node IDs (such as the previous-hop EID) to which the
bundle should not be forwarded. If the encapsulated bundle were instead
delivered to the application specific element of the AA, then it isn't
clear how the application-specific element could pass the
"don't-send-to EIDs" down to its BPA along with the "inner" bundle,
given that the only interface between the application specific element
of the AA and the BPA is the BP service interface, and specifying a
list of "don't-send-to EIDs is not included among the services on this
interface. Also, tunneling is a service that one can envision wanting
to be in a node that serves simply as a router and may not have any
application-specific element in its AA, so we wanted the administrative
element of the AA to be capable of handling it.=20
		=20
		This is the rationale.  I don't think that putting this
in the multicast spec itself is the right thing to do. Where do you
suggest it be documented?  Where is such rationale documented for the
Bundle Protocol Spec.?

	I don't think an exhaustively detailed rationale is important,
but a brief hint to the interested reader might not be amiss.
Something like "(Note: administrative records are used for
Bundle-in-Bundle encapsulation so as to cause the encapsulated bundles
to be presented to the administrative element of the receiving node's
application agent, which implements the relevant procedures defined in
this document, rather than to the application-specific element.)"  It
could go immediately after the forward reference to section 10 in the
"Tunneling" discussion on page 20.  And in fact you might want to amend
slightly the sentence that contains that forward reference: the
encapsulated bundle doesn't actually become the payload of the
encapsulating bundle -- the encapsulation administrative record that
*contains* the encapsulated bundle becomes the payload of the
encapsulating bundle.
=09
	Scott
=09

------_=_NextPart_002_01C6326E.79753B92
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D430542319-15022006>Scott,</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D430542319-15022006></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D430542319-15022006>Great!&nbsp; I addressed both of your =
remaining two=20
concerns in the attached new version.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D430542319-15022006></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D430542319-15022006>- I removed the ambiguous "go to may" wording =
mentioned=20
in item 4. For your information, non-multicast-capable nodes=20
</SPAN></FONT></FONT></FONT><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2>may participate in a general flooding=20
protocol.</FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D430542319-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- I inserted the suggested brief rationale in =
item=20
5.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D430542319-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D430542319-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks again for reading this and for providing =
helpful=20
comments. </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D430542319-15022006></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D430542319-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>-susan</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D430542319-15022006></SPAN><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of =
</B>Scott=20
  Burleigh<BR><B>Sent:</B> Wednesday, February 15, 2006 2:05 =
PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Re: [dtn-interest]=20
  Non-custodial multicasting in DTN draft<BR></FONT><BR></DIV>
  <DIV></DIV>Symington, Susan F. wrote:=20
  <BLOCKQUOTE =
cite=[email-masked]=20
  type=3D"cite">
    <META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>Scott,</FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN =
class=3D434150417-15022006></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>Thanks very much for reading this =
through.&nbsp; I=20
    agree with your comments in items 1, 2, and 3 and revised the =
document=20
    accordingly.</FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN =
class=3D434150417-15022006></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>With regard to item 4, I did not remove the =
word "may"=20
    because this would imply that all multicast-capable nodes =
participate in=20
    multicast routing protocols, but we can have multicast-capable nodes =
and=20
    just use either static, predefined routing (like we do now with=20
    "unicast-capable" nodes) or flooding as our bundle dissemination=20
    mechanisms.</FONT></SPAN></DIV></BLOCKQUOTE>Sorry, I should have =
provided a=20
  better pointer to the text I was talking about: the "may" I meant was =
the one=20
  at the start of the second bullet under the "- Do not" bullet under "- =

  Non-multicast-capable nodes, which we define as nodes that".&nbsp; As =
it is=20
  now, the text signifies that part of the definition of =
non-multicast-capable=20
  nodes is that they "Do not may participate in a general flooding =
protocol"=20
  when I think you mean to say that they "Do not participate in a =
general=20
  flooding protocol".<BR>
  <BLOCKQUOTE =
cite=[email-masked]=20
  type=3D"cite"><SPAN class=3D434150417-15022006><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>To answer your question with regard to item 5, we chose to =
use an=20
    administrative record rather than an extension header because it =
seemed the=20
    easiest way for us to fit&nbsp;the encapsulation =
capability&nbsp;into the=20
    model of what a bundle node is. When the encapsulated bundle is =
delivered at=20
    a node, we want it to be delivered to the node's application agent's =
(AA's)=20
    administrative element, not to the node's AA's application-specific =
element.=20
    This is because the administrative element will process the =
encapsulated=20
    bundle by extracting the "inner" bundle from the payload field of =
the=20
    encapsulated bundle and then sending this inner bundle down to its =
bundle=20
    protocol agent (BPA) to be delivered and/or=20
  forwarded.</FONT></SPAN></BLOCKQUOTE>Right, that's exactly the =
rationale I=20
  finally figured out.<BR>
  <BLOCKQUOTE =
cite=[email-masked]=20
  type=3D"cite"><SPAN class=3D434150417-15022006><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Furthermore, along with this inner bundle, the =
administrative element=20
    may also need to send to its BPA a list of one or more next-hop node =
IDs=20
    (such as the previous-hop EID) to which the bundle should not be =
forwarded.=20
    If the encapsulated bundle were instead delivered to the application =

    specific element of the AA, then it isn't clear how=20
    the&nbsp;application-specific element&nbsp;could pass the =
"don't-send-to=20
    EIDs" down to its BPA along with the "inner" bundle, given that the =
only=20
    interface between the application specific element of the AA and the =
BPA is=20
    the BP service interface, and specifying a list of "don't-send-to =
EIDs is=20
    not included among the services on this interface. Also, tunneling =
is a=20
    service that one can envision wanting to be in a node that serves =
simply as=20
    a router and may not have any application-specific element in its =
AA, so we=20
    wanted the administrative element of the AA to be capable of =
handling it.=20
    </FONT></SPAN>
    <DIV dir=3Dltr align=3Dleft><SPAN =
class=3D434150417-15022006></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>This is the rationale.&nbsp; I don't think =
that putting=20
    this in the multicast spec itself is the right thing to do. Where do =
you=20
    suggest it be documented?&nbsp; Where is such rationale documented =
for the=20
    Bundle Protocol Spec.?</FONT></SPAN></DIV></BLOCKQUOTE>I don't think =
an=20
  exhaustively detailed rationale is important, but a brief hint to the=20
  interested reader might not be amiss.&nbsp; Something like "(Note:=20
  administrative records are used for Bundle-in-Bundle encapsulation so =
as to=20
  cause the encapsulated bundles to be presented to the administrative =
element=20
  of the receiving node's application agent, which implements the =
relevant=20
  procedures defined in this document, rather than to the =
application-specific=20
  element.)"&nbsp; It could go immediately after the forward reference =
to=20
  section 10 in the "Tunneling" discussion on page 20.&nbsp; And in fact =
you=20
  might want to amend slightly the sentence that contains that forward=20
  reference: the encapsulated bundle doesn't actually become the payload =
of the=20
  encapsulating bundle -- the encapsulation administrative record that=20
  *contains* the encapsulated bundle becomes the payload of the =
encapsulating=20
  bundle.<BR><BR>Scott<BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_002_01C6326E.79753B92--

------_=_NextPart_001_01C6326E.79753B92
Content-Type: text/plain;
	name="draft-irtf-dtnrg-bundle-multicast-noncustodial-draft3.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-irtf-dtnrg-bundle-multicast-noncustodial-draft3.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-multicast-noncustodial-draft3.txt"

------_=_NextPart_001_01C6326E.79753B92--

Date: Wed, 15 Feb 2006 11:05:23 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Non-custodial multicasting in DTN draft
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------070601050105040806040809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Symington, Susan F. wrote:

> Scott,
>  
> Thanks very much for reading this through.  I agree with your comments 
> in items 1, 2, and 3 and revised the document accordingly.
>  
> With regard to item 4, I did not remove the word "may" because this 
> would imply that all multicast-capable nodes participate in multicast 
> routing protocols, but we can have multicast-capable nodes and just 
> use either static, predefined routing (like we do now with 
> "unicast-capable" nodes) or flooding as our bundle dissemination 
> mechanisms.

Sorry, I should have provided a better pointer to the text I was talking 
about: the "may" I meant was the one at the start of the second bullet 
under the "- Do not" bullet under "- Non-multicast-capable nodes, which 
we define as nodes that".  As it is now, the text signifies that part of 
the definition of non-multicast-capable nodes is that they "Do not may 
participate in a general flooding protocol" when I think you mean to say 
that they "Do not participate in a general flooding protocol".

> To answer your question with regard to item 5, we chose to use an 
> administrative record rather than an extension header because it 
> seemed the easiest way for us to fit the encapsulation capability into 
> the model of what a bundle node is. When the encapsulated bundle is 
> delivered at a node, we want it to be delivered to the node's 
> application agent's (AA's) administrative element, not to the node's 
> AA's application-specific element. This is because the administrative 
> element will process the encapsulated bundle by extracting the "inner" 
> bundle from the payload field of the encapsulated bundle and then 
> sending this inner bundle down to its bundle protocol agent (BPA) to 
> be delivered and/or forwarded.

Right, that's exactly the rationale I finally figured out.

> Furthermore, along with this inner bundle, the administrative element 
> may also need to send to its BPA a list of one or more next-hop node 
> IDs (such as the previous-hop EID) to which the bundle should not be 
> forwarded. If the encapsulated bundle were instead delivered to the 
> application specific element of the AA, then it isn't clear how 
> the application-specific element could pass the "don't-send-to EIDs" 
> down to its BPA along with the "inner" bundle, given that the only 
> interface between the application specific element of the AA and the 
> BPA is the BP service interface, and specifying a list of 
> "don't-send-to EIDs is not included among the services on this 
> interface. Also, tunneling is a service that one can envision wanting 
> to be in a node that serves simply as a router and may not have any 
> application-specific element in its AA, so we wanted the 
> administrative element of the AA to be capable of handling it.
>  
> This is the rationale.  I don't think that putting this in the 
> multicast spec itself is the right thing to do. Where do you suggest 
> it be documented?  Where is such rationale documented for the Bundle 
> Protocol Spec.?

I don't think an exhaustively detailed rationale is important, but a 
brief hint to the interested reader might not be amiss.  Something like 
"(Note: administrative records are used for Bundle-in-Bundle 
encapsulation so as to cause the encapsulated bundles to be presented to 
the administrative element of the receiving node's application agent, 
which implements the relevant procedures defined in this document, 
rather than to the application-specific element.)"  It could go 
immediately after the forward reference to section 10 in the "Tunneling" 
discussion on page 20.  And in fact you might want to amend slightly the 
sentence that contains that forward reference: the encapsulated bundle 
doesn't actually become the payload of the encapsulating bundle -- the 
encapsulation administrative record that *contains* the encapsulated 
bundle becomes the payload of the encapsulating bundle.

Scott

--------------070601050105040806040809
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Symington, Susan F. wrote:
<blockquote
 cite="[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.2802" name="GENERATOR">
  <div align="left" dir="ltr"><span class="434150417-15022006"><font
 color="#0000ff" face="Arial" size="2">Scott,</font></span></div>
  <div align="left" dir="ltr"><span class="434150417-15022006"></span>&nbsp;</div>
  <div align="left" dir="ltr"><span class="434150417-15022006"><font
 color="#0000ff" face="Arial" size="2">Thanks very much for reading
this through.&nbsp; I agree with your comments in items 1, 2, and 3 and
revised the document accordingly.</font></span></div>
  <div align="left" dir="ltr"><span class="434150417-15022006"></span>&nbsp;</div>
  <div align="left" dir="ltr"><span class="434150417-15022006"><font
 color="#0000ff" face="Arial" size="2">With regard to item 4, I did not
remove the word "may" because this would imply that all
multicast-capable nodes participate in multicast routing protocols, but
we can have multicast-capable nodes and just use either static,
predefined routing (like we do now with "unicast-capable" nodes) or
flooding as our bundle dissemination mechanisms.</font></span></div>
</blockquote>
Sorry, I should have provided a better pointer to the text I was
talking about: the "may" I meant was the one at the start of the second
bullet under the "- Do not" bullet under "- Non-multicast-capable
nodes, which we define as nodes that".&nbsp; As it is now, the text
signifies that part of the definition of non-multicast-capable nodes is
that they "Do not may participate in a general flooding protocol" when
I think you mean to say that they "Do not participate in a general
flooding protocol".<br>
<blockquote
 cite="[email-masked]"
 type="cite"> <span class="434150417-15022006"><font color="#0000ff"
 face="Arial" size="2">To answer your question with regard to item 5,
we chose to use an administrative record rather than an extension
header because it seemed the easiest way for us to fit&nbsp;the
encapsulation capability&nbsp;into the model of what a bundle node is. When
the encapsulated bundle is delivered at a node, we want it to be
delivered to the node's application agent's (AA's) administrative
element, not to the node's AA's application-specific element. This is
because the administrative element will process the encapsulated bundle
by extracting the "inner" bundle from the payload field of the
encapsulated bundle and then sending this inner bundle down to its
bundle protocol agent (BPA) to be delivered and/or forwarded.</font></span></blockquote>
Right, that's exactly the rationale I finally figured out.<br>
<blockquote
 cite="[email-masked]"
 type="cite"><span class="434150417-15022006"><font color="#0000ff"
 face="Arial" size="2">Furthermore, along with this inner bundle, the
administrative element may also need to send to its BPA a list of one
or more next-hop node IDs (such as the previous-hop EID) to which the
bundle should not be forwarded. If the encapsulated bundle were instead
delivered to the application specific element of the AA, then it isn't
clear how the&nbsp;application-specific element&nbsp;could pass the
"don't-send-to EIDs" down to its BPA along with the "inner" bundle,
given that the only interface between the application specific element
of the AA and the BPA is the BP service interface, and specifying a
list of "don't-send-to EIDs is not included among the services on this
interface. Also, tunneling is a service that one can envision wanting
to be in a node that serves simply as a router and may not have any
application-specific element in its AA, so we wanted the administrative
element of the AA to be capable of handling it. </font></span>
  <div align="left" dir="ltr"><span class="434150417-15022006"></span>&nbsp;</div>
  <div align="left" dir="ltr"><span class="434150417-15022006"><font
 color="#0000ff" face="Arial" size="2">This is the rationale.&nbsp; I don't
think that putting this in the multicast spec itself is the right thing
to do. Where do you suggest it be documented?&nbsp; Where is such rationale
documented for the Bundle Protocol Spec.?</font></span></div>
</blockquote>
I don't think an exhaustively detailed rationale is important, but a
brief hint to the interested reader might not be amiss.&nbsp; Something like
"(Note: administrative records are used for Bundle-in-Bundle
encapsulation so as to cause the encapsulated bundles to be presented
to the administrative element of the receiving node's application
agent, which implements the relevant procedures defined in this
document, rather than to the application-specific element.)"&nbsp; It could
go immediately after the forward reference to section 10 in the
"Tunneling" discussion on page 20.&nbsp; And in fact you might want to amend
slightly the sentence that contains that forward reference: the
encapsulated bundle doesn't actually become the payload of the
encapsulating bundle -- the encapsulation administrative record that
*contains* the encapsulated bundle becomes the payload of the
encapsulating bundle.<br>
<br>
Scott<br>
</body>
</html>

--------------070601050105040806040809--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Non-custodial multicasting in DTN draft
Date: Wed, 15 Feb 2006 12:55:45 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C63259.0BD13790
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C63259.0BD13790"

------_=_NextPart_002_01C63259.0BD13790
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Scott,
=20
Thanks very much for reading this through.  I agree with your comments
in items 1, 2, and 3 and revised the document accordingly.
=20
With regard to item 4, I did not remove the word "may" because this
would imply that all multicast-capable nodes participate in multicast
routing protocols, but we can have multicast-capable nodes and just use
either static, predefined routing (like we do now with
"unicast-capable" nodes) or flooding as our bundle dissemination
mechanisms.=20
=20
To answer your question with regard to item 5, we chose to use an
administrative record rather than an extension header because it seemed
the easiest way for us to fit the encapsulation capability into the
model of what a bundle node is. When the encapsulated bundle is
delivered at a node, we want it to be delivered to the node's
application agent's (AA's) administrative element, not to the node's
AA's application-specific element. This is because the administrative
element will process the encapsulated bundle by extracting the "inner"
bundle from the payload field of the encapsulated bundle and then
sending this inner bundle down to its bundle protocol agent (BPA) to be
delivered and/or forwarded. Furthermore, along with this inner bundle,
the administrative element may also need to send to its BPA a list of
one or more next-hop node IDs (such as the previous-hop EID) to which
the bundle should not be forwarded. If the encapsulated bundle were
instead delivered to the application specific element of the AA, then
it isn't clear how the application-specific element could pass the
"don't-send-to EIDs" down to its BPA along with the "inner" bundle,
given that the only interface between the application specific element
of the AA and the BPA is the BP service interface, and specifying a
list of "don't-send-to EIDs is not included among the services on this
interface. Also, tunneling is a service that one can envision wanting
to be in a node that serves simply as a router and may not have any
application-specific element in its AA, so we wanted the administrative
element of the AA to be capable of handling it.=20
=20
This is the rationale.  I don't think that putting this in the
multicast spec itself is the right thing to do. Where do you suggest it
be documented?  Where is such rationale documented for the Bundle
Protocol Spec.?
=20
Attached is the revised draft, which we hope to submit as an internet
draft shortly.
=20
-susan
=20
=20
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
=20

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott
Burleigh
	Sent: Tuesday, February 14, 2006 7:26 PM
	To: [email-masked]
	Subject: Re: [dtn-interest] Non-custodial multicasting in DTN
draft
=09
=09
	Symington, Susan F. wrote:=20

		All,
		=20
		We would like to submit the attached document as an
internet draft. It discusses non-custodial support for multicast in
DTN, meaning it discusses how to support multicast delivery of bundles,
but it does not provide support for custody transfer of multicast
bundles.
		=20
		We would appreciate your posting any comments you might
have. Thanks.

	I think this is good, Susan, especially the use of tunneling to
deal with heterogeneous DTNs; very clean.  A few comments:
=09
	1.   A tiny thing, but in the definition of multicast bundle in
1.2 I would say that the destination of the bundle is a multicast
endpoint, not a multicast endpoint ID.  A multicast endpoint ID is the
string by which we refer to a multicast endpoint; it's not a
destination.
=09
	2.   Looking at section 3: in order to disseminate,
meaningfully, the fact that some node has registered within a multicast
endpoint identified by <schemename1>:<ssp1>, you have to send some sort
of message that associates <schemename1>:<ssp1> with a token indicating
the means by which multicast bundles can be sent to that node.  One
such token might be the ID of a convergence-layer protocol service
access point at which that node declares it will be listening for
messages.  Alternatively, the node-identifying token might be the
multicast node ID of that node, a different DTN endpoint ID
<schemename2>:<ssp2>.  In the latter case you'd send multicast messages
destined for this particular member of <schemename1>:<ssp1> to
<schemename2>:<ssp2> -- in effect you'd be routing those messages
through <schemename2>:<ssp2>, which would "forward" them to itself.
But you can only do that if you've already gotten registration
information that associates <schemename2>:<ssp2> with the ID of a
convergence-layer protocol service access point at which that node
declares it will be listening for messages.  It seems to me that the
latter is at the root of things in either case, and it seems to me that
propagation of this sort of information is something that I'd expect a
routing protocol to do.  So I'm questioning the correctness of
distinguishing in this section between these kinds of registration
information propagation protocols and routing protocols.  Maybe I've
just got the wrong idea of what to expect from a DTN routing protocol;
in that case it might be worthwhile to define the difference explicitly
somewhere, either here or in some other document.
=09
	3.   I think there's some unhelpful imprecision in language in
section 7.  A "layer" is a locus within a protocol stack at which one
or more protocols (designed to perform the functions nominally
allocated to that layer) operate.  There is exactly one DTN convergence
layer; it is located directly beneath the Bundle Protocol in the stack.
There may be operational instances of any number of protocols at that
layer for any single DTN node, each of which receives bundles that are
somehow directed to it, often by means of some sort of service access
point ID such as IP-address/port-number.  It's not useful to say "There
may be more than one convergence layer shared between a sending node
and a receiving node."  I think what you mean is something like "There
may be more than one convergence-layer protocol by which a sending node
and receiving node can communicate" or, better, "There may be more than
one convergence-layer protocol service access point pair over which the
sending node and receiving node can exchange messages."  When you say
it this way, the assertion that "receipt of a bundle on one of these
convergence layers does not necessarily mean that the node that sent
that bundle is distinct from the node that sends a bundle on another
convergence layer" comes out more clearly (I think) as "receipt of a
bundle at one convergence-layer protocol service access point doesn't
necessarily enable identification of the node that sent the bundle" --
which I would say is not the case when TCP or UDP is the
convergence-layer protocol that is being used, but is probably true for
some other potential convergence-layer protocols.
=09
	4.   On page 18, section 9.0, I think you want to remove the
word "may" at the start of the second bullet.
=09
	5.   Why define a bundle-in-bundle Encapsulation admin record?
Why not just define another extension header that indicates
encapsulation?  Having asked this question, I think I can imagine a
good answer, but I think the rationale needs to be documented
somewhere.
=09
	Scott
=09

------_=_NextPart_002_01C63259.0BD13790
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Scott,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks very much for reading this =
through.&nbsp; I agree=20
with your comments in items 1, 2, and 3 and revised the document=20
accordingly.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>With regard to item 4, I did not remove the =
word "may"=20
because this would imply that all multicast-capable nodes participate in =

multicast routing protocols, but we can have multicast-capable nodes and =
just=20
use either static, predefined routing (like we do now with =
"unicast-capable"=20
nodes) or flooding as our bundle dissemination=20
mechanisms.&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>To answer your question with regard to item 5, =
we chose to=20
use an administrative record rather than an extension header because it =
seemed=20
the easiest way for us to fit&nbsp;the encapsulation =
capability&nbsp;into the=20
model of what a bundle node is. When the encapsulated bundle is =
delivered at a=20
node, we want it to be delivered to the node's application agent's =
(AA's)=20
administrative element, not to the node's AA's application-specific =
element.=20
This is because the administrative element will process the encapsulated =
bundle=20
by extracting the "inner" bundle from the payload field of the =
encapsulated=20
bundle and then sending this inner bundle down to its bundle protocol =
agent=20
(BPA) to be delivered and/or forwarded. Furthermore, along with this =
inner=20
bundle, the administrative element may also need to send to its BPA a =
list of=20
one or more next-hop node IDs (such as the previous-hop EID) to which =
the bundle=20
should not be forwarded. If the encapsulated bundle were instead =
delivered to=20
the application specific element of the AA, then it isn't clear how=20
the&nbsp;application-specific element&nbsp;could pass the "don't-send-to =
EIDs"=20
down to its BPA along with the "inner" bundle, given that the only =
interface=20
between the application specific element of the AA and the BPA is the BP =
service=20
interface, and specifying a list of "don't-send-to EIDs is not included =
among=20
the services on this interface. Also, tunneling is a service that one =
can=20
envision wanting to be in a node that serves simply as a router and may =
not have=20
any application-specific element in its AA, so we wanted the =
administrative=20
element of the AA to be capable of handling it. </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>This is the rationale.&nbsp; I don't think that =
putting=20
this in the multicast spec itself is the right thing to do. Where do you =
suggest=20
it be documented?&nbsp; Where is such rationale documented for the =
Bundle=20
Protocol Spec.?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Attached is the revised draft, which we hope to =
submit as=20
an internet draft shortly.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN><SPAN =
class=3D434150417-15022006><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D434150417-15022006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>-susan</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D434150417-15022006></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D434150417-15022006></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D434150417-15022006></SPAN><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of =
</B>Scott=20
  Burleigh<BR><B>Sent:</B> Tuesday, February 14, 2006 7:26 =
PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Re: [dtn-interest]=20
  Non-custodial multicasting in DTN draft<BR></FONT><BR></DIV>
  <DIV></DIV>Symington, Susan F. wrote:=20
  <BLOCKQUOTE =
cite=[email-masked]=20
  type=3D"cite">
    <META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    class=3D973101819-13022006>All,</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    class=3D973101819-13022006></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN class=3D973101819-13022006>We =
would like to=20
    submit the attached document as an internet draft. It discusses=20
    non-custodial support for multicast in DTN, meaning it discusses how =
to=20
    support multicast delivery of bundles, but it does not provide =
support for=20
    custody transfer of multicast bundles.</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    class=3D973101819-13022006></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN class=3D973101819-13022006>We =
would=20
    appreciate your posting any comments you might have.=20
    Thanks.</SPAN></FONT></DIV></BLOCKQUOTE>I think this is good, Susan, =

  especially the use of tunneling to deal with heterogeneous DTNs; very=20
  clean.&nbsp; A few comments:<BR><BR>1.&nbsp;&nbsp; A tiny thing, but =
in the=20
  definition of multicast bundle in 1.2 I would say that the destination =
of the=20
  bundle is a multicast endpoint, not a multicast endpoint ID.&nbsp; A =
multicast=20
  endpoint ID is the string by which we refer to a multicast endpoint; =
it's not=20
  a destination.<BR><BR>2.&nbsp;&nbsp; Looking at section 3: in order to =

  disseminate, meaningfully, the fact that some node has registered =
within a=20
  multicast endpoint identified by &lt;schemename1&gt;:&lt;ssp1&gt;, you =
have to=20
  send some sort of message that associates =
&lt;schemename1&gt;:&lt;ssp1&gt;=20
  with a token indicating the means by which multicast bundles can be =
sent to=20
  that node.&nbsp; One such token might be the ID of a convergence-layer =

  protocol service access point at which that node declares it will be =
listening=20
  for messages.&nbsp; Alternatively, the node-identifying token might be =
the=20
  multicast node ID of that node, a different DTN endpoint ID=20
  &lt;schemename2&gt;:&lt;ssp2&gt;.&nbsp; In the latter case you'd send=20
  multicast messages destined for this particular member of=20
  &lt;schemename1&gt;:&lt;ssp1&gt; to &lt;schemename2&gt;:&lt;ssp2&gt; =
-- in=20
  effect you'd be routing those messages through=20
  &lt;schemename2&gt;:&lt;ssp2&gt;, which would "forward" them to =
itself.&nbsp;=20
  But you can only do that if you've already gotten registration =
information=20
  that associates &lt;schemename2&gt;:&lt;ssp2&gt; with the ID of a=20
  convergence-layer protocol service access point at which that node =
declares it=20
  will be listening for messages.&nbsp; It seems to me that the latter =
is at the=20
  root of things in either case, and it seems to me that propagation of =
this=20
  sort of information is something that I'd expect a routing protocol to =

  do.&nbsp; So I'm questioning the correctness of distinguishing in this =
section=20
  between these kinds of registration information propagation protocols =
and=20
  routing protocols.&nbsp; Maybe I've just got the wrong idea of what to =
expect=20
  from a DTN routing protocol; in that case it might be worthwhile to =
define the=20
  difference explicitly somewhere, either here or in some other=20
  document.<BR><BR>3.&nbsp;&nbsp; I think there's some unhelpful =
imprecision in=20
  language in section 7.&nbsp; A "layer" is a locus within a protocol =
stack at=20
  which one or more protocols (designed to perform the functions =
nominally=20
  allocated to that layer) operate.&nbsp; There is exactly one DTN =
convergence=20
  layer; it is located directly beneath the Bundle Protocol in the =
stack.&nbsp;=20
  There may be operational instances of any number of protocols at that =
layer=20
  for any single DTN node, each of which receives bundles that are =
somehow=20
  directed to it, often by means of some sort of service access point ID =
such as=20
  IP-address/port-number.&nbsp; It's not useful to say "There may be =
more than=20
  one convergence layer shared between a sending node and a receiving=20
  node."&nbsp; I think what you mean is something like "There may be =
more than=20
  one convergence-layer protocol by which a sending node and receiving =
node can=20
  communicate" or, better, "There may be more than one convergence-layer =

  protocol service access point pair over which the sending node and =
receiving=20
  node can exchange messages."&nbsp; When you say it this way, the =
assertion=20
  that "receipt of a bundle on one of these convergence layers does not=20
  necessarily mean that the node that sent that bundle is distinct from =
the node=20
  that sends a bundle on another convergence layer" comes out more =
clearly (I=20
  think) as "receipt of a bundle at one convergence-layer protocol =
service=20
  access point doesn't necessarily enable identification of the node =
that sent=20
  the bundle" -- which I would say is not the case when TCP or UDP is =
the=20
  convergence-layer protocol that is being used, but is probably true =
for some=20
  other potential convergence-layer protocols.<BR><BR>4.&nbsp;&nbsp; On =
page 18,=20
  section 9.0, I think you want to remove the word "may" at the start of =
the=20
  second bullet.<BR><BR>5.&nbsp;&nbsp; Why define a bundle-in-bundle=20
  Encapsulation admin record?&nbsp; Why not just define another =
extension header=20
  that indicates encapsulation?&nbsp; Having asked this question, I =
think I can=20
  imagine a good answer, but I think the rationale needs to be =
documented=20
  somewhere.<BR><BR>Scott<BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_002_01C63259.0BD13790--

------_=_NextPart_001_01C63259.0BD13790
Content-Type: text/plain;
	name="draft-irtf-dtnrg-bundle-multicast-noncustodial-draft2.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-irtf-dtnrg-bundle-multicast-noncustodial-draft2.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-multicast-noncustodial-draft2.txt"

------_=_NextPart_001_01C63259.0BD13790--

Date: Tue, 14 Feb 2006 16:25:41 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Non-custodial multicasting in DTN draft
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------080009010109050403050407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Symington, Susan F. wrote:

> All,
>  
> We would like to submit the attached document as an internet draft. It 
> discusses non-custodial support for multicast in DTN, meaning it 
> discusses how to support multicast delivery of bundles, but it does 
> not provide support for custody transfer of multicast bundles.
>  
> We would appreciate your posting any comments you might have. Thanks.

I think this is good, Susan, especially the use of tunneling to deal 
with heterogeneous DTNs; very clean.  A few comments:

1.   A tiny thing, but in the definition of multicast bundle in 1.2 I 
would say that the destination of the bundle is a multicast endpoint, 
not a multicast endpoint ID.  A multicast endpoint ID is the string by 
which we refer to a multicast endpoint; it's not a destination.

2.   Looking at section 3: in order to disseminate, meaningfully, the 
fact that some node has registered within a multicast endpoint 
identified by <schemename1>:<ssp1>, you have to send some sort of 
message that associates <schemename1>:<ssp1> with a token indicating the 
means by which multicast bundles can be sent to that node.  One such 
token might be the ID of a convergence-layer protocol service access 
point at which that node declares it will be listening for messages.  
Alternatively, the node-identifying token might be the multicast node ID 
of that node, a different DTN endpoint ID <schemename2>:<ssp2>.  In the 
latter case you'd send multicast messages destined for this particular 
member of <schemename1>:<ssp1> to <schemename2>:<ssp2> -- in effect 
you'd be routing those messages through <schemename2>:<ssp2>, which 
would "forward" them to itself.  But you can only do that if you've 
already gotten registration information that associates 
<schemename2>:<ssp2> with the ID of a convergence-layer protocol service 
access point at which that node declares it will be listening for 
messages.  It seems to me that the latter is at the root of things in 
either case, and it seems to me that propagation of this sort of 
information is something that I'd expect a routing protocol to do.  So 
I'm questioning the correctness of distinguishing in this section 
between these kinds of registration information propagation protocols 
and routing protocols.  Maybe I've just got the wrong idea of what to 
expect from a DTN routing protocol; in that case it might be worthwhile 
to define the difference explicitly somewhere, either here or in some 
other document.

3.   I think there's some unhelpful imprecision in language in section 
7.  A "layer" is a locus within a protocol stack at which one or more 
protocols (designed to perform the functions nominally allocated to that 
layer) operate.  There is exactly one DTN convergence layer; it is 
located directly beneath the Bundle Protocol in the stack.  There may be 
operational instances of any number of protocols at that layer for any 
single DTN node, each of which receives bundles that are somehow 
directed to it, often by means of some sort of service access point ID 
such as IP-address/port-number.  It's not useful to say "There may be 
more than one convergence layer shared between a sending node and a 
receiving node."  I think what you mean is something like "There may be 
more than one convergence-layer protocol by which a sending node and 
receiving node can communicate" or, better, "There may be more than one 
convergence-layer protocol service access point pair over which the 
sending node and receiving node can exchange messages."  When you say it 
this way, the assertion that "receipt of a bundle on one of these 
convergence layers does not necessarily mean that the node that sent 
that bundle is distinct from the node that sends a bundle on another 
convergence layer" comes out more clearly (I think) as "receipt of a 
bundle at one convergence-layer protocol service access point doesn't 
necessarily enable identification of the node that sent the bundle" -- 
which I would say is not the case when TCP or UDP is the 
convergence-layer protocol that is being used, but is probably true for 
some other potential convergence-layer protocols.

4.   On page 18, section 9.0, I think you want to remove the word "may" 
at the start of the second bullet.

5.   Why define a bundle-in-bundle Encapsulation admin record?  Why not 
just define another extension header that indicates encapsulation?  
Having asked this question, I think I can imagine a good answer, but I 
think the rationale needs to be documented somewhere.

Scott

--------------080009010109050403050407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Symington, Susan F. wrote:
<blockquote
 cite="[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.2802" name="GENERATOR">
  <div><font face="Arial" size="2"><span class="973101819-13022006">All,</span></font></div>
  <div><font face="Arial" size="2"><span class="973101819-13022006"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="973101819-13022006">We
would like to submit the attached document as an internet draft. It
discusses non-custodial support for multicast in DTN, meaning it
discusses how to support multicast delivery of bundles, but it does not
provide support for custody transfer of multicast bundles.</span></font></div>
  <div><font face="Arial" size="2"><span class="973101819-13022006"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="973101819-13022006">We
would appreciate your posting any comments you might have. Thanks.</span></font></div>
</blockquote>
I think this is good, Susan, especially the use of tunneling to deal
with heterogeneous DTNs; very clean.&nbsp; A few comments:<br>
<br>
1.&nbsp;&nbsp; A tiny thing, but in the definition of multicast bundle in 1.2 I
would say that the destination of the bundle is a multicast endpoint,
not a multicast endpoint ID.&nbsp; A multicast endpoint ID is the string by
which we refer to a multicast endpoint; it's not a destination.<br>
<br>
2.&nbsp;&nbsp; Looking at section 3: in order to disseminate, meaningfully, the
fact that some node has registered within a multicast endpoint
identified by &lt;schemename1&gt;:&lt;ssp1&gt;, you have to send some
sort of message that associates &lt;schemename1&gt;:&lt;ssp1&gt; with a
token indicating the means by which multicast bundles can be sent to
that node.&nbsp; One such token might be the ID of a convergence-layer
protocol service access point at which that node declares it will be
listening for messages.&nbsp; Alternatively, the node-identifying token
might be the multicast node ID of that node, a different DTN endpoint
ID &lt;schemename2&gt;:&lt;ssp2&gt;.&nbsp; In the latter case you'd send
multicast messages destined for this particular member of
&lt;schemename1&gt;:&lt;ssp1&gt; to &lt;schemename2&gt;:&lt;ssp2&gt; --
in effect you'd be routing those messages through
&lt;schemename2&gt;:&lt;ssp2&gt;, which would "forward" them to
itself.&nbsp; But you can only do that if you've already gotten registration
information that associates &lt;schemename2&gt;:&lt;ssp2&gt; with the
ID of a convergence-layer protocol service access point at which that
node declares it will be listening for messages.&nbsp; It seems to me that
the latter is at the root of things in either case, and it seems to me
that propagation of this sort of information is something that I'd
expect a routing protocol to do.&nbsp; So I'm questioning the correctness of
distinguishing in this section between these kinds of registration
information propagation protocols and routing protocols.&nbsp; Maybe I've
just got the wrong idea of what to expect from a DTN routing protocol;
in that case it might be worthwhile to define the difference explicitly
somewhere, either here or in some other document.<br>
<br>
3.&nbsp;&nbsp; I think there's some unhelpful imprecision in language in section
7.&nbsp; A "layer" is a locus within a protocol stack at which one or more
protocols (designed to perform the functions nominally allocated to
that layer) operate.&nbsp; There is exactly one DTN convergence layer; it is
located directly beneath the Bundle Protocol in the stack.&nbsp; There may
be operational instances of any number of protocols at that layer for
any single DTN node, each of which receives bundles that are somehow
directed to it, often by means of some sort of service access point ID
such as IP-address/port-number.&nbsp; It's not useful to say "There may be
more than one convergence layer shared between a sending node and a
receiving node."&nbsp; I think what you mean is something like "There may be
more than one convergence-layer protocol by which a sending node and
receiving node can communicate" or, better, "There may be more than one
convergence-layer protocol service access point pair over which the
sending node and receiving node can exchange messages."&nbsp; When you say
it this way, the assertion that "receipt of a bundle on one of these
convergence layers does not necessarily mean that the node that sent
that bundle is distinct from the node that sends a bundle on another
convergence layer" comes out more clearly (I think) as "receipt of a
bundle at one convergence-layer protocol service access point doesn't
necessarily enable identification of the node that sent the bundle" --
which I would say is not the case when TCP or UDP is the
convergence-layer protocol that is being used, but is probably true for
some other potential convergence-layer protocols.<br>
<br>
4.&nbsp;&nbsp; On page 18, section 9.0, I think you want to remove the word "may"
at the start of the second bullet.<br>
<br>
5.&nbsp;&nbsp; Why define a bundle-in-bundle Encapsulation admin record?&nbsp; Why not
just define another extension header that indicates encapsulation?&nbsp;
Having asked this question, I think I can imagine a good answer, but I
think the rationale needs to be documented somewhere.<br>
<br>
Scott<br>
</body>
</html>

--------------080009010109050403050407--

Content-class: urn:content-classes:message
Date: Mon, 13 Feb 2006 14:22:23 -0500
From: "Symington, Susan F." <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] Non-custodial multicasting in DTN draft
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C630D2.D195A623
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C630D2.D195A623"

------_=_NextPart_002_01C630D2.D195A623
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,
=20
We would like to submit the attached document as an internet draft. It
discusses non-custodial support for multicast in DTN, meaning it
discusses how to support multicast delivery of bundles, but it does not
provide support for custody transfer of multicast bundles.
=20
We would appreciate your posting any comments you might have. Thanks.
=20
-susan
=20
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
=20

------_=_NextPart_002_01C630D2.D195A623
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D973101819-13022006>All,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D973101819-13022006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D973101819-13022006>We =
would like to=20
submit the attached document as an internet draft. It discusses =
non-custodial=20
support for multicast in DTN, meaning it discusses how to support =
multicast=20
delivery of bundles, but it does not provide support for custody =
transfer of=20
multicast bundles.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D973101819-13022006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D973101819-13022006>We =
would appreciate=20
your posting any comments you might have. Thanks.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D973101819-13022006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D973101819-13022006>-susan</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_002_01C630D2.D195A623--

------_=_NextPart_001_01C630D2.D195A623
Content-Type: text/plain;
	name="draft-irtf-dtnrg-bundle-multicast-noncustodial-draft.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-irtf-dtnrg-bundle-multicast-noncustodial-draft.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-multicast-noncustodial-draft.txt"

------_=_NextPart_001_01C630D2.D195A623--