[computational.science] IQ2S'09: Call for papers

Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9VKlvJG022396 for ; Fri, 31 Oct 2008 13:47:57 -0700 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9VKaRsF022115 for ; Fri, 31 Oct 2008 16:36:27 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9VKaRYo022110; Fri, 31 Oct 2008 16:36:27 -0400 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 16:36:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93B98.5885265E" Date: Fri, 31 Oct 2008 16:36:25 -0400 Message-ID: <8E507634779E22488719233DB3DF9FF002FE5634@IMCSRV4.MITRE.ORG> In-Reply-To: <6.2.1.2.2.20081031162349.026ff530@po2.bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-interest] Bundle-in-Bundle Encapsulation Issue Thread-Index: Ack7l/1wr0rFQrXETgy+9aEKoZAhJwAADlng References: <6.2.1.2.2.20081031162349.026ff530@po2.bbn.com> From: "Symington, Susan F." To: "Jon Shapiro" , X-OriginalArrivalTime: 31 Oct 2008 20:36:27.0488 (UTC) FILETIME=[593B0E00:01C93B98] Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 20:47:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C93B98.5885265E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am available until 4PM EST on both days (11/12 and 11/13). =20 -susan =20 ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** From: dtn-interest-bounces@maillists.intel-research.net [mailto:dtn-interest-bounces@maillists.intel-research.net] On Behalf Of Jon Shapiro Sent: Friday, October 31, 2008 4:31 PM To: dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue =20 It seems like 11/12 or 11/13 are good dates for people. So lets try those as targets.=20 I am available until 4p EST on 11/12, and all day on 11/13. Does anybody have restriction(s) on either days? Thanks! - Jon Shapiro ________________________________ Jon Shapiro - Lead Software Engineer, Mobile Networking Systems, 6/249 BBN Technologies=20 10 Moulton St. Cambridge MA, 02138 (617) 873-4383 "The early bird gets the worm, but the second mouse gets the cheese." ------_=_NextPart_001_01C93B98.5885265E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am available until 4PM EST on both days (11/12 and = 11/13).

-susan

**********************************************************= *******

Susan Symington

The MITRE Corporation

susan@mitre.org

703-983-7209 (voice)

703-983-7142 (fax)

**********************************************************= ********

From:= dtn-interest-bounces@maillists.intel-research.net [mailto:dtn-interest-bounces@maillists.intel-research.net] On Behalf = Of Jon Shapiro
Sent: Friday, October 31, 2008 4:31 PM
To: dtn-interest@mailman.dtnrg.org
Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation = Issue

It seems like 11/12 or 11/13 are good dates for people. So lets try those as targets.

I am available until 4p EST on 11/12, and all day on 11/13. Does = anybody have restriction(s) on either days?

Thanks!
- Jon Shapiro

------_=_NextPart_001_01C93B98.5885265E-- Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9VKk9wR022282 for ; Fri, 31 Oct 2008 13:46:09 -0700 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9VKYdP6017536 for ; Fri, 31 Oct 2008 16:34:39 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9VKYcGL017522; Fri, 31 Oct 2008 16:34:38 -0400 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 16:34:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93B98.17FFB8DE" Date: Fri, 31 Oct 2008 16:34:35 -0400 Message-ID: <8E507634779E22488719233DB3DF9FF002FE5633@IMCSRV4.MITRE.ORG> In-Reply-To: <6.2.1.2.2.20081031125028.023e95f8@po2.bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-interest] Bundle-in-Bundle Encapsulation Issue Thread-Index: Ack7eqY/bLunyKcrQ2ODY62P+SBL/AAF0eag References: <6.2.1.2.2.20081031125028.023e95f8@po2.bbn.com> From: "Symington, Susan F." To: "Jon Shapiro" , X-OriginalArrivalTime: 31 Oct 2008 20:34:39.0097 (UTC) FILETIME=[189FE690:01C93B98] Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 20:46:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C93B98.17FFB8DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jon, =20 Hopefully some of your answers can be found in the I-D that I uploaded to the IETF website this morning (http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-encapsulat ion-04.txt ) . Based on this I-D, I have provided responses to your questions interspersed below: =20 ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** From: dtn-interest-bounces@maillists.intel-research.net [mailto:dtn-interest-bounces@maillists.intel-research.net] On Behalf Of Jon Shapiro Sent: Friday, October 31, 2008 1:00 PM To: dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue =20 Hi All, The recent discussion concerning the Bundle-In-Bundle feature has raised a number of questions for me as I strive to understand its use while familiarizing myself with the current reference implementation. As BBN is working on a DTN implementation that should include this feature, I propose that we have a teleconference, hosted by BBN, where all of the interested parties could participate and hopefully come to a resolution. =20 I propose that we hold this teleconference on 5-Nov-08, 1-2pm EST, if this works for the interested parties. If not, please propose an alternate date and time. If this topic and teleconference does not interest you please skip the remainder and thank you for your time. If this topic does interest you please let me know and I will send the teleconference connection information to you. A summary of my understanding of the feature and concerns follows. The previous scheme for encapsulating a Bundle-in-a-Bundle, henceforth BIB, was to place the entire bundle B1 inside another bundle wB1, essentially by putting another primary block in front of B1's primary block, and placing (wrapping) the original primary block and payload of B1 in the wB1 payload block. This scheme allowed the application agent to send bundle B1 to nodes without triggering (the original set of) BPA actions for B1. The wrapper bundle wB1 was an administrative record type bundle. Note that the scheme to wrap B1 inside bundle wB1, may be generalized to allow multiple bundles B1, B2, B3 etc. to be wrapped inside wB1, and may also allow wB1 to be extended (or wrapped inside wB2) so as to include additional bundles B4, B5. The lack of specificity in this matter is a weakness and needs to be addressed, especially given the objections stemming from the limitation on custody transfer below, as the handling of each inner bundle is presumed to be identical when wrapped inside wBN. =20 The previously proposed BIB scheme using administrative records as the wrapper had a problem (as noted by Peter Lovell) in that RFC 5050 sec. 4.2, states: "If the bundles processing control flags indicate that the bundle's application data unit is an administrative record, then the custody transfer requested flag must be zero and all status report request flags must be zero." This requirement basically limits the use of administrative records to their intended "signal" or "report" uses (see RFC 5050 sec. 5.1), and prevents their use for BIB use since it was considered important to allow custody transfer to be used for the wrapped bundle(s). =20 Susan Symington has proposed that one of three alternate proposals therefore be followed:=20 1. Accept this limitation. 2. Change the RFC 5050 section 4.2 rule to remove this limitation. 3. Use a different mechanism instead of the administrative record. One proposal is to use an extension block to hold both the original version of the modified primary block fields and information such as count and offset values that can be used to reconstitute the wrapped bundle(s) from the payload block. =20 These are all excellent points, but I am not sure how to understand them without context. I believe that a number of basic questions need to be addressed as we move forward with any BIB scheme. These questions are: 1. What are the uses for Bundle-In-Bundle? [Susan] A. The use you mention (delivering a cached bundle to a different EID than is listed as the destination in the bundle).=20 B. Sending a multicast bundle across a network to a specific destination D1 node (so that it is not disseminated as a multicast bundle between the source and destination D1, but it is disseminated as a multicast bundle once it is forwarded onward from D1).=20 1a. Why can't it be done currently? [Susan] A. Use case A because we don't have an integrity ciphersuite defined that permits it. And B. Use case B because you simply can't do this now in the BP. 1b. Who needs the BIB feature? [Susan] A. Folks wanting to perform content-centric distribution of cached data to new nodes that join a network, using the current integrity ciphersuite. B. Folks wanting to implement custodial multicast and send custodial retransmissions efficiently. 2. How are BIBs created? (by the app, or by the BPA?) [Susan] The application agent of the bundle node creates the BIB. It creates an encapsulating bundle, and, in the simplest case (1 bundle is encapsulated) it puts the bundle to be encapsulated into this encapsulating bundle's payload field, and adds a BiB Encapsulation block to the encapsulating bundle. The destination EID of the encapsulating bundle must be an EID of which the node that will be de-encapsulating the bundle is a member.=20 3. How are BIBs treated in transit? (hopefully as just another bundle) [Susan] Yes, they are just bundles and are just forwarded from hop to hop until they reach their destination. It is at the destination that they get treated differently, based only on the fact that they contain a BIB encapsulation block. 4. How are BIBs treated at the endpoints? (handled by app or BPA?) [Susan] They are delivered at their destination endpoint node (just like any other bundles). What is different is how the application agent of the node treats them once they are delivered. The application agent extracts the encapsulated bundles and passes each of the extracted bundles to the BPA for processing as if they had just been received from another node. This means they may then be delivered and /or forwarded by the BPA, as appropriate. =20 I hope these answers help. =20 -susan First: What are the uses, why isn't it already covered, why is it needed. The most concrete example (use case) so far is that a new node (N-new) appears in the network and requests information which exists as a previously delivered multicast bundle on an existing node (N-old). N-old wants to send the multicast data to N-new without flooding the network. Therefore N-old wants to substitute a unicast address in place of the multicast address, at least during intermediate hops, so that the bundle transport only consumes a minimal set of resources. N-old may require custody transfer and other services for this bundle that differ from the original set of services used to transport the bundle. Finally, the bundle may be protected by a checksum that is calculated across both its payload and primary block, such that the original multicast destination address has been included in the checksum. Therefore the original primary block can only be modified in transit, but not once it arrives (if the checksum needs to be calculated at each step the original block could be resurrected en-route for this purpose, and then re-wrapped). =20 Other considerations:=20 A) Flexibility is specifying different handling from original bundle handling such as custody transfer: It seems a bit odd that a multicast bundle would require custody transfer, since the node holding it (N-old) is presumably part of the same multicast group that N-new is a member of. However on the working assumption that N-new could be a better custodian than a resource bound N-old, and for maximum flexibility, it seems valid to keep this as part of the BIB requirements. =20 B) Multiple bundles within a single wrapped bundle: It also seems fair to allow multiple bundles to be wrapped inside a single bundle, so long as all of the bundles being wrapped together all share the same endpoint(s) and in transit handling requirements (custody transfer, etc.). The use case above could be reformulated such that N-old is holding multiple multicast bundles to send to N-new, and thus wishes to form a wrapped bundle wB1 consisting of B1, B2 and B3. The resulting bundle aggregate would then be handled as a single bundle, although it might get fragmented en-route. =20 C) Allowing other bundles to be added to an existing (wrapped or unwrapped) bundle: The utility of further wrapping additional bundles along with previously wrapped bundles seems reasonable (perhaps some node along the way determines to add bundles in response to the same request). However it appears to force several decisions. First, it appears to require that the BPA, as the entity that handles wrapped bundles 'in the tunnel', know how to peek inside them (i.e., the payload of a wrapped bundle can not be opaque). This in turn seems to require that the BPA be the entity that decides to wrap bundles in the first place, as an in-transit bundle has not reached the endpoint so the application would not be part of the processing, while the BPA would. =20 Including this feature raises a number of questions. Is it needed? Would it prevent the application from generating wrapped bundles as well? Would it impose a more complicated control interface between the application(s) and the BPA to support application wrapping? Why limit the BPA to extending pre-existing wrapped bundles - i.e., why not allow bundle aggregation (via wrapped bundles) whenever the BPA detects multiple bundles traveling to the same endpoint(s) with the same handling? Is this desired? =20 D) Layering of interfaces, features: My main concern about any BIB implementation is that it should follow the layering philosophy, where the entity that wraps the bundle is the entity that un-wraps it, to avoid complicated control flows between separate layers. As the discussion concerning extending an existing (wrapped or unwrapped) bundle by the BPA to include other bundles indicates, there appear to be several choices: 1) If the application agent is wrapping and handing a wrapped bundle down to the BPA, it should expect to be delivered the wrapped bundle at the tunnel endpoint(s), and it should be the entity that unwraps the bundle upon delivery. This would seem to prevent the BPA from further wrapping additional bundles en-route as the wrapped bundle would then be an opaque payload. 2) If the application-to-BPA interface is defined such that it allows a set of bundles to be sent to a unicast endpoint then it would be the BPA that does the wrapping, and it should be the BPA that does the unwrapping, so that the BPA would then present each un-wrapped bundle to the endpoint application as if it had arrived separately. If the BPA was doing the wrapping, it could add other bundles en-route. This approach would allow the BPA to further wrap bundles en-route, and would allow the BPA to initiate bundle wrapping if so desired.=20 3) These two approaches could be combined using different mechanisms for the application vs. the BPA to wrap bundles. In this approach, any bundles wrapped by the application would be handled as a single bundle back to the application by the BPA, and this bundle would have to be un-wrapped by the application. The BPA, however, could add bundles to any existing bundle it handled so long as the bundle handling and endpoint were the same. This scheme would create two parallel mechanisms, one for the application and one for the BPA, for managing Bundle-In-Bundle. =20 To some degree these are low level details. However they are broadly determined by the entity that is given the role of wrapping (and un-wrapping) bundles, and this brings me back to my original questions 1 and 2 - what are the uses for this service and how is it invoked. Once we have consensus on answers to those, I believe the other answers will be more forthcoming. =20 Thank you for reading so far. I look forward to hearing your thoughts on these matters. - Jon Shapiro ________________________________ Jon Shapiro - Lead Software Engineer, Mobile Networking Systems, 6/249 BBN Technologies=20 10 Moulton St. Cambridge MA, 02138 (617) 873-4383 "The early bird gets the worm, but the second mouse gets the cheese." ------_=_NextPart_001_01C93B98.17FFB8DE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jon,

Hopefully some of your answers can be found in the I-D = that I uploaded to the IETF website this morning (http://www.ietf.org/internet-drafts/draft-irtf-dt= nrg-bundle-encapsulation-04.txt) . Based on this I-D, I have provided responses to your questions interspersed = below:

**********************************************************= *******

Susan Symington

The MITRE Corporation

susan@mitre.org

703-983-7209 (voice)

703-983-7142 (fax)

**********************************************************= ********

From:= dtn-interest-bounces@maillists.intel-research.net = [mailto:dtn-interest-bounces@maillists.intel-research.net] On Behalf Of Jon Shapiro
Sent: Friday, October 31, 2008 1:00 PM
To: dtn-interest@mailman.dtnrg.org
Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation = Issue

Hi All,

The recent discussion concerning the Bundle-In-Bundle feature has raised = a number of questions for me as I strive to understand its use while familiarizing myself with the current reference implementation. As = BBN is working on a DTN implementation that should include this feature, I = propose that we have a teleconference, hosted by BBN, where all of the = interested parties could participate and hopefully come to a resolution.

I propose that we hold this teleconference on 5-Nov-08, 1-2pm EST, if = this works for the interested parties. If not, please propose an = alternate date and time. If this topic and teleconference does not interest = you please skip the remainder and thank you for your time. If this = topic does interest you please let me know and I will send the teleconference = connection information to you.

A summary of my understanding of the feature and concerns follows.

The previous scheme for encapsulating a Bundle-in-a-Bundle, henceforth = BIB, was to place the entire bundle B1 inside another bundle wB1, essentially by = putting another primary block in front of B1's primary block, and placing = (wrapping) the original primary block and payload of B1 in the wB1 payload = block. This scheme allowed the application agent to send bundle B1 to nodes = without triggering (the original set of) BPA actions for B1. The wrapper = bundle wB1 was an administrative record type bundle.

Note that the scheme to wrap B1 inside bundle wB1, may be generalized to = allow multiple bundles B1, B2, B3 etc. to be wrapped inside wB1, and may also = allow wB1 to be extended (or wrapped inside wB2) so as to include additional = bundles B4, B5. The lack of specificity in this matter is a weakness and = needs to be addressed, especially given the objections stemming from the = limitation on custody transfer below, as the handling of each inner bundle is presumed = to be identical when wrapped inside wBN.

The previously proposed BIB scheme using administrative records as the = wrapper had a problem (as noted by Peter Lovell) in that RFC 5050 sec. 4.2, = states: "If the bundles processing control flags indicate that the bundle's application data unit is an administrative record, then the custody = transfer requested flag must be zero and all status report request flags must be zero." This requirement basically limits the use of = administrative records to their intended "signal" or "report" uses = (see RFC 5050 sec. 5.1), and prevents their use for BIB use since it was = considered important to allow custody transfer to be used for the wrapped = bundle(s).

Susan Symington has proposed that one of three alternate proposals = therefore be followed:

1. Accept this limitation.
2. Change the RFC 5050 section 4.2 rule to remove this limitation.
3. Use a different mechanism instead of the administrative record. = One proposal is to use an extension block to hold both the original version = of the modified primary block fields and information such as count and offset = values that can be used to reconstitute the wrapped bundle(s) from the payload block.

These are all excellent points, but I am not sure how to understand them without context. I believe that a number of basic questions need = to be addressed as we move forward with any BIB scheme. These questions = are:

        1. What are the uses for Bundle-In-Bundle?

[Susan] A. The use you mention (delivering a cached = bundle to a different EID than is listed as the destination in the bundle). =

&nbs= p; B. Sending a multicast bundle across a network to a specific destination = D1 node (so that it is not disseminated as a multicast bundle between the source = and destination D1, but it is disseminated as a multicast bundle once it is forwarded = onward from D1).

&= nbsp; 1a. Why can't it be done currently?

[Susan] A. Use case A because we don’t have an = integrity ciphersuite defined that permits it.

And B. Use case = B because you simply can’t do this now in the = BP.

&= nbsp; 1b. Who needs the BIB feature?

[Susan] A. Folks wanting to perform content-centric = distribution of cached data to new nodes that join a network, using the current = integrity ciphersuite.

&nbs= p; B. Folks wanting to implement custodial multicast and send custodial retransmissions efficiently.

2. How are BIBs = created? (by the app, or by the BPA?)

[Susan] The application agent of the bundle node creates = the BIB. It creates an encapsulating bundle, and, in the simplest case = (1 bundle is encapsulated) it puts the bundle to be encapsulated into this encapsulating bundle’s payload field, and adds a BiB Encapsulation = block to the encapsulating bundle. The destination EID of the encapsulating = bundle must be an EID of which the node that will be de-encapsulating the bundle is = a member.

3. How are BIBs treated = in transit? (hopefully as just another bundle)

[Susan] Yes, they are just bundles and are just forwarded = from hop to hop until they reach their destination. It is at the destination = that they get treated differently, based only on the fact that they contain a = BIB encapsulation block.
4. How are BIBs treated = at the endpoints? (handled by app or BPA?)
[Susan] They are delivered at their destination endpoint = node (just like any other bundles). What is different is how the application agent = of the node treats them once they are delivered. The application agent extracts the encapsulated bundles and passes each of the extracted bundles to the BPA = for processing as if they had just been received from another node. This = means they may then be delivered and /or forwarded by the BPA, as = appropriate.

I hope these answers = help.

-susan
First: What are the uses, why isn't it already covered, why is it = needed.

The most concrete example (use case) so far is that a new node (N-new) = appears in the network and requests information which exists as a previously = delivered multicast bundle on an existing node (N-old). N-old wants to send = the multicast data to N-new without flooding the network. Therefore = N-old wants to substitute a unicast address in place of the multicast address, = at least during intermediate hops, so that the bundle transport only = consumes a minimal set of resources. N-old may require custody transfer and = other services for this bundle that differ from the original set of services = used to transport the bundle. Finally, the bundle may be protected by a = checksum that is calculated across both its payload and primary block, such that = the original multicast destination address has been included in the = checksum. Therefore the original primary block can only be modified in transit, = but not once it arrives (if the checksum needs to be calculated at each step the original block could be resurrected en-route for this purpose, and then re-wrapped).

Other considerations:

A) Flexibility is specifying different handling from original bundle = handling such as custody transfer:

It seems a bit odd that a multicast bundle would require custody = transfer, since the node holding it (N-old) is presumably part of the same = multicast group that N-new is a member of. However on the working assumption = that N-new could be a better custodian than a resource bound N-old, and for = maximum flexibility, it seems valid to keep this as part of the BIB = requirements.

B) Multiple bundles within a single wrapped bundle:

It also seems fair to allow multiple bundles to be wrapped inside a = single bundle, so long as all of the bundles being wrapped together all share = the same endpoint(s) and in transit handling requirements (custody transfer, etc.). The use case above could be reformulated such that N-old is holding multiple multicast bundles to send to N-new, and thus wishes to = form a wrapped bundle wB1 consisting of B1, B2 and B3. The resulting bundle = aggregate would then be handled as a single bundle, although it might get = fragmented en-route.

C) Allowing other bundles to be added to an existing (wrapped or = unwrapped) bundle:

The utility of further wrapping additional bundles along with previously wrapped bundles seems reasonable (perhaps some node along the way = determines to add bundles in response to the same request). However it appears = to force several decisions. First, it appears to require that the BPA, as = the entity that handles wrapped bundles 'in the tunnel', know how to peek = inside them (i.e., the payload of a wrapped bundle can not be opaque). = This in turn seems to require that the BPA be the entity that decides to wrap = bundles in the first place, as an in-transit bundle has not reached the endpoint = so the application would not be part of the processing, while the BPA = would.

Including this feature raises a number of questions. Is it = needed? Would it prevent the application from generating wrapped bundles as = well? Would it impose a more complicated control interface between the = application(s) and the BPA to support application wrapping? Why limit the BPA to extending pre-existing wrapped bundles - i.e., why not allow bundle = aggregation (via wrapped bundles) whenever the BPA detects multiple bundles = traveling to the same endpoint(s) with the same handling? Is this = desired?

D) Layering of interfaces, features:

My main concern about any BIB implementation is that it should follow = the layering philosophy, where the entity that wraps the bundle is the = entity that un-wraps it, to avoid complicated control flows between separate = layers. As the discussion concerning extending an existing (wrapped or = unwrapped) bundle by the BPA to include other bundles indicates, there appear to be several choices:

1) If the application agent is wrapping and handing a wrapped bundle = down to the BPA, it should expect to be delivered the wrapped bundle at the = tunnel endpoint(s), and it should be the entity that unwraps the bundle upon delivery. This would seem to prevent the BPA from further wrapping additional bundles en-route as the wrapped bundle would then be an = opaque payload.

2) If the application-to-BPA interface is defined such that it allows a = set of bundles to be sent to a unicast endpoint then it would be the BPA that = does the wrapping, and it should be the BPA that does the unwrapping, so that the = BPA would then present each un-wrapped bundle to the endpoint application as = if it had arrived separately. If the BPA was doing the wrapping, it = could add other bundles en-route. This approach would allow the BPA to further = wrap bundles en-route, and would allow the BPA to initiate bundle wrapping if = so desired.

3) These two approaches could be combined using different mechanisms for = the application vs. the BPA to wrap bundles. In this approach, any = bundles wrapped by the application would be handled as a single bundle back to = the application by the BPA, and this bundle would have to be un-wrapped by = the application. The BPA, however, could add bundles to any existing = bundle it handled so long as the bundle handling and endpoint were the = same. This scheme would create two parallel mechanisms, one for the = application and one for the BPA, for managing Bundle-In-Bundle.

To some degree these are low level details. However they are = broadly determined by the entity that is given the role of wrapping (and = un-wrapping) bundles, and this brings me back to my original questions 1 and 2 - what = are the uses for this service and how is it invoked. Once we have = consensus on answers to those, I believe the other answers will be more forthcoming.

Thank you for reading so far. I look forward to hearing your = thoughts on these matters.

- Jon Shapiro

------_=_NextPart_001_01C93B98.17FFB8DE-- Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9VKg7RQ022062 for ; Fri, 31 Oct 2008 13:42:08 -0700 Received: from dhcp89-069-173.bbn.com ([128.89.69.173] helo=7C-541.bbn.com) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Kw0dh-0001QX-FM for dtn-interest@mailman.dtnrg.org; Fri, 31 Oct 2008 16:30:37 -0400 Message-Id: <6.2.1.2.2.20081031162349.026ff530@po2.bbn.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 31 Oct 2008 16:30:37 -0400 To: dtn-interest@mailman.dtnrg.org From: Jon Shapiro Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_22389343==.ALT" Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 20:42:08 -0000 --=====================_22389343==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed It seems like 11/12 or 11/13 are good dates for people. So lets try those as targets. I am available until 4p EST on 11/12, and all day on 11/13. Does anybody have restriction(s) on either days? Thanks! - Jon Shapiro ---------- Jon Shapiro - Lead Software Engineer, Mobile Networking Systems, 6/249 BBN Technologies 10 Moulton St. Cambridge MA, 02138 (617) 873-4383 "The early bird gets the worm, but the second mouse gets the cheese." --=====================_22389343==.ALT Content-Type: text/html; charset="us-ascii" It seems like 11/12 or 11/13 are good dates for people. So lets try those as targets.

I am available until 4p EST on 11/12, and all day on 11/13. Does anybody have restriction(s) on either days?

Thanks!
- Jon Shapiro

Jon Shapiro - Lead Software Engineer, Mobile Networking Systems, 6/249

BBN Technologies
10 Moulton St.
Cambridge MA, 02138

(617) 873-4383

"The early bird gets the worm, but the second mouse gets the cheese."

--=====================_22389343==.ALT-- Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9VKFqj9020803 for ; Fri, 31 Oct 2008 13:15:53 -0700 Received: from [10.224.14.254] ([13.0.211.9]) by alpha.xerox.com with SMTP id <321916(2)>; Fri, 31 Oct 2008 13:04:12 PDT Message-Id: From: Ignacio Solis To: DTN Interest List In-Reply-To: <8E507634779E22488719233DB3DF9FF002FE5615@IMCSRV4.MITRE.ORG> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 31 Oct 2008 13:04:11 PDT References: <6.2.1.2.2.20081031125028.023e95f8@po2.bbn.com><4F6A2EF2-9B7C-4391-BC70-9B315F077437@cs.berkeley.edu><490B44A5.5000807@bbn.com> <8E507634779E22488719233DB3DF9FF002FE5615@IMCSRV4.MITRE.ORG> X-Mailer: Apple Mail (2.929.2) Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 20:15:53 -0000 On Oct 31, 2008, at 12:49 PM, Symington, Susan F. wrote: > 11/11 is Veteran's Day (a federal holiday). How about 11/12 or 11/13? I'm out next week on vacation (in case that is still under consideration), so I would prefer the following one. Any day/time works, but being west coast the later the better for me. Nacho > I would also like to note that earlier this morning I uploaded a > revised draft of the Bundle-in-Bundle Encapsulation I-D to the IETF > website. This version uses the mechanism of an extension block rather > than an administrative record to implement encapsulation. You can > find > this new ID at: > > http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle- > encapsulati > on-04.txt > > I haven't had a chance to read through Jon's email yet. > > -susan > ***************************************************************** > Susan Symington > The MITRE Corporation > susan@mitre.org > 703-983-7209 (voice) > 703-983-7142 (fax) > ****************************************************************** > >> -----Original Message----- >> From: dtn-interest-bounces@maillists.intel-research.net [mailto:dtn- >> interest-bounces@maillists.intel-research.net] On Behalf Of Kevin >> Fall >> Sent: Friday, October 31, 2008 3:04 PM >> To: Daniel Ellard >> Cc: DTN Interest List >> Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue >> >> that works for me. thx -K >> >> On Oct 31, 2008, at Oct 3110:47 AMPDT, Daniel Ellard wrote: >> >>> Kevin Fall wrote: >>>> Hi. That particular date/time is not possible for me. The >>>> following week is much easier, generally. How about Nov 10, at 1pm >>>> eastern? I am free nearly the whole day, except for 2-3pm Pacific. >>> >>> 11/10 some of the BBN folk are out all day. 11/11? >>> >>> -Dan >>> >> >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@maillists.intel-research.net >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest > > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9VK1A7h020155 for ; Fri, 31 Oct 2008 13:01:11 -0700 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9VJneY9025855 for ; Fri, 31 Oct 2008 15:49:41 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9VJneF7025847; Fri, 31 Oct 2008 15:49:40 -0400 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 15:49:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 31 Oct 2008 15:49:38 -0400 Message-ID: <8E507634779E22488719233DB3DF9FF002FE5615@IMCSRV4.MITRE.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-interest] Bundle-in-Bundle Encapsulation Issue Thread-Index: Ack7jBWhmwrgCb0NT6a69q86z3vTigABI6OA References: <6.2.1.2.2.20081031125028.023e95f8@po2.bbn.com><4F6A2EF2-9B7C-4391-BC70-9B315F077437@cs.berkeley.edu><490B44A5.5000807@bbn.com> From: "Symington, Susan F." To: "Kevin Fall" , "Daniel Ellard" X-OriginalArrivalTime: 31 Oct 2008 19:49:41.0001 (UTC) FILETIME=[D06F1F90:01C93B91] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id m9VK1A7h020155 Cc: DTN Interest List Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 20:01:11 -0000 11/11 is Veteran's Day (a federal holiday). How about 11/12 or 11/13? I would also like to note that earlier this morning I uploaded a revised draft of the Bundle-in-Bundle Encapsulation I-D to the IETF website. This version uses the mechanism of an extension block rather than an administrative record to implement encapsulation. You can find this new ID at: http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-encapsulati on-04.txt I haven't had a chance to read through Jon's email yet. -susan ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** >-----Original Message----- >From: dtn-interest-bounces@maillists.intel-research.net [mailto:dtn- >interest-bounces@maillists.intel-research.net] On Behalf Of Kevin Fall >Sent: Friday, October 31, 2008 3:04 PM >To: Daniel Ellard >Cc: DTN Interest List >Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue > >that works for me. thx -K > >On Oct 31, 2008, at Oct 3110:47 AMPDT, Daniel Ellard wrote: > >> Kevin Fall wrote: >>> Hi. That particular date/time is not possible for me. The >>> following week is much easier, generally. How about Nov 10, at 1pm >>> eastern? I am free nearly the whole day, except for 2-3pm Pacific. >> >> 11/10 some of the BBN folk are out all day. 11/11? >> >> -Dan >> > >_______________________________________________ >dtn-interest mailing list >dtn-interest@maillists.intel-research.net >http://maillists.intel-research.net/mailman/listinfo/dtn-interest Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9VJFogG018012 for ; Fri, 31 Oct 2008 12:15:50 -0700 Received: from kfalls-computer.research.intel-research.net (bldmz-nat-161-164.berkeley.intel-research.net [12.155.161.164]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m9VJ4IA9006898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 Oct 2008 12:04:20 -0700 (PDT) Message-Id: From: Kevin Fall To: Daniel Ellard In-Reply-To: <490B44A5.5000807@bbn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 31 Oct 2008 12:04:12 -0700 References: <6.2.1.2.2.20081031125028.023e95f8@po2.bbn.com> <4F6A2EF2-9B7C-4391-BC70-9B315F077437@cs.berkeley.edu> <490B44A5.5000807@bbn.com> X-Mailer: Apple Mail (2.929.2) Cc: DTN Interest List Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 19:15:50 -0000 that works for me. thx -K On Oct 31, 2008, at Oct 3110:47 AMPDT, Daniel Ellard wrote: > Kevin Fall wrote: >> Hi. That particular date/time is not possible for me. The >> following week is much easier, generally. How about Nov 10, at 1pm >> eastern? I am free nearly the whole day, except for 2-3pm Pacific. > > 11/10 some of the BBN folk are out all day. 11/11? > > -Dan > Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9VHwkwK014321 for ; Fri, 31 Oct 2008 10:58:46 -0700 Received: from senshu.bbn.com ([128.89.80.164]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Kvy5d-0007nC-Cn; Fri, 31 Oct 2008 13:47:18 -0400 Message-ID: <490B44A5.5000807@bbn.com> Date: Fri, 31 Oct 2008 13:47:17 -0400 From: Daniel Ellard Organization: BBN Technologies User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Kevin Fall References: <6.2.1.2.2.20081031125028.023e95f8@po2.bbn.com> <4F6A2EF2-9B7C-4391-BC70-9B315F077437@cs.berkeley.edu> In-Reply-To: <4F6A2EF2-9B7C-4391-BC70-9B315F077437@cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 17:58:46 -0000 Kevin Fall wrote: > Hi. That particular date/time is not possible for me. The following > week is much easier, generally. How about Nov 10, at 1pm eastern? I am > free nearly the whole day, except for 2-3pm Pacific. 11/10 some of the BBN folk are out all day. 11/11? -Dan Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9VHT9na012906 for ; Fri, 31 Oct 2008 10:29:09 -0700 Received: from kfalls-computer.research.intel-research.net (bldmz-nat-161-164.berkeley.intel-research.net [12.155.161.164]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m9VHHdTb005223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 Oct 2008 10:17:40 -0700 (PDT) Message-Id: <4F6A2EF2-9B7C-4391-BC70-9B315F077437@cs.berkeley.edu> From: Kevin Fall To: Jon Shapiro In-Reply-To: <6.2.1.2.2.20081031125028.023e95f8@po2.bbn.com> Content-Type: multipart/alternative; boundary=Apple-Mail-7-205634092 Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 31 Oct 2008 10:17:33 -0700 References: <6.2.1.2.2.20081031125028.023e95f8@po2.bbn.com> X-Mailer: Apple Mail (2.929.2) Cc: dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 17:29:09 -0000 --Apple-Mail-7-205634092 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi. That particular date/time is not possible for me. The following week is much easier, generally. How about Nov 10, at 1pm eastern? I am free nearly the whole day, except for 2-3pm Pacific. thx - K On Oct 31, 2008, at Oct 3110:00 AMPDT, Jon Shapiro wrote: > Hi All, > > The recent discussion concerning the Bundle-In-Bundle feature has > raised a number of questions for me as I strive to understand its > use while familiarizing myself with the current reference > implementation. As BBN is working on a DTN implementation that > should include this feature, I propose that we have a > teleconference, hosted by BBN, where all of the interested parties > could participate and hopefully come to a resolution. > > I propose that we hold this teleconference on 5-Nov-08, 1-2pm EST, > if this works for the interested parties. If not, please propose an > alternate date and time. If this topic and teleconference does not > interest you please skip the remainder and thank you for your time. > If this topic does interest you please let me know and I will send > the teleconference connection information to you. > > > A summary of my understanding of the feature and concerns follows. > > The previous scheme for encapsulating a Bundle-in-a-Bundle, > henceforth BIB, was to place the entire bundle B1 inside another > bundle wB1, essentially by putting another primary block in front of > B1's primary block, and placing (wrapping) the original primary > block and payload of B1 in the wB1 payload block. This scheme > allowed the application agent to send bundle B1 to nodes without > triggering (the original set of) BPA actions for B1. The wrapper > bundle wB1 was an administrative record type bundle. > > Note that the scheme to wrap B1 inside bundle wB1, may be > generalized to allow multiple bundles B1, B2, B3 etc. to be wrapped > inside wB1, and may also allow wB1 to be extended (or wrapped inside > wB2) so as to include additional bundles B4, B5. The lack of > specificity in this matter is a weakness and needs to be addressed, > especially given the objections stemming from the limitation on > custody transfer below, as the handling of each inner bundle is > presumed to be identical when wrapped inside wBN. > > The previously proposed BIB scheme using administrative records as > the wrapper had a problem (as noted by Peter Lovell) in that RFC > 5050 sec. 4.2, states: "If the bundles processing control flags > indicate that the bundle's application data unit is an > administrative record, then the custody transfer requested flag must > be zero and all status report request flags must be zero." This > requirement basically limits the use of administrative records to > their intended "signal" or "report" uses (see RFC 5050 sec. 5.1), > and prevents their use for BIB use since it was considered important > to allow custody transfer to be used for the wrapped bundle(s). > > Susan Symington has proposed that one of three alternate proposals > therefore be followed: > > 1. Accept this limitation. > 2. Change the RFC 5050 section 4.2 rule to remove this limitation. > 3. Use a different mechanism instead of the administrative record. > One proposal is to use an extension block to hold both the original > version of the modified primary block fields and information such as > count and offset values that can be used to reconstitute the wrapped > bundle(s) from the payload block. > > These are all excellent points, but I am not sure how to understand > them without context. I believe that a number of basic questions > need to be addressed as we move forward with any BIB scheme. These > questions are: > > 1. What are the uses for Bundle-In-Bundle? > 1a. Why can't it be done currently? > 1b. Who needs the BIB feature? > 2. How are BIBs created? (by the app, or by the BPA?) > 3. How are BIBs treated in transit? (hopefully as just > another bundle) > 4. How are BIBs treated at the endpoints? (handled by app > or BPA?) > > First: What are the uses, why isn't it already covered, why is it > needed. > > The most concrete example (use case) so far is that a new node (N- > new) appears in the network and requests information which exists as > a previously delivered multicast bundle on an existing node (N- > old). N-old wants to send the multicast data to N-new without > flooding the network. Therefore N-old wants to substitute a unicast > address in place of the multicast address, at least during > intermediate hops, so that the bundle transport only consumes a > minimal set of resources. N-old may require custody transfer and > other services for this bundle that differ from the original set of > services used to transport the bundle. Finally, the bundle may be > protected by a checksum that is calculated across both its payload > and primary block, such that the original multicast destination > address has been included in the checksum. Therefore the original > primary block can only be modified in transit, but not once it > arrives (if the checksum needs to be calculated at each step the > original block could be resurrected en-route for this purpose, and > then re-wrapped). > > Other considerations: > > A) Flexibility is specifying different handling from original bundle > handling such as custody transfer: > > It seems a bit odd that a multicast bundle would require custody > transfer, since the node holding it (N-old) is presumably part of > the same multicast group that N-new is a member of. However on the > working assumption that N-new could be a better custodian than a > resource bound N-old, and for maximum flexibility, it seems valid to > keep this as part of the BIB requirements. > > B) Multiple bundles within a single wrapped bundle: > > It also seems fair to allow multiple bundles to be wrapped inside a > single bundle, so long as all of the bundles being wrapped together > all share the same endpoint(s) and in transit handling requirements > (custody transfer, etc.). The use case above could be reformulated > such that N-old is holding multiple multicast bundles to send to N- > new, and thus wishes to form a wrapped bundle wB1 consisting of B1, > B2 and B3. The resulting bundle aggregate would then be handled as a > single bundle, although it might get fragmented en-route. > > C) Allowing other bundles to be added to an existing (wrapped or > unwrapped) bundle: > > The utility of further wrapping additional bundles along with > previously wrapped bundles seems reasonable (perhaps some node along > the way determines to add bundles in response to the same request). > However it appears to force several decisions. First, it appears to > require that the BPA, as the entity that handles wrapped bundles 'in > the tunnel', know how to peek inside them (i.e., the payload of a > wrapped bundle can not be opaque). This in turn seems to require > that the BPA be the entity that decides to wrap bundles in the first > place, as an in-transit bundle has not reached the endpoint so the > application would not be part of the processing, while the BPA would. > > Including this feature raises a number of questions. Is it needed? > Would it prevent the application from generating wrapped bundles as > well? Would it impose a more complicated control interface between > the application(s) and the BPA to support application wrapping? Why > limit the BPA to extending pre-existing wrapped bundles - i.e., why > not allow bundle aggregation (via wrapped bundles) whenever the BPA > detects multiple bundles traveling to the same endpoint(s) with the > same handling? Is this desired? > > D) Layering of interfaces, features: > > My main concern about any BIB implementation is that it should > follow the layering philosophy, where the entity that wraps the > bundle is the entity that un-wraps it, to avoid complicated control > flows between separate layers. As the discussion concerning > extending an existing (wrapped or unwrapped) bundle by the BPA to > include other bundles indicates, there appear to be several choices: > > 1) If the application agent is wrapping and handing a wrapped bundle > down to the BPA, it should expect to be delivered the wrapped bundle > at the tunnel endpoint(s), and it should be the entity that unwraps > the bundle upon delivery. This would seem to prevent the BPA from > further wrapping additional bundles en-route as the wrapped bundle > would then be an opaque payload. > > 2) If the application-to-BPA interface is defined such that it > allows a set of bundles to be sent to a unicast endpoint then it > would be the BPA that does the wrapping, and it should be the BPA > that does the unwrapping, so that the BPA would then present each un- > wrapped bundle to the endpoint application as if it had arrived > separately. If the BPA was doing the wrapping, it could add other > bundles en-route. This approach would allow the BPA to further wrap > bundles en-route, and would allow the BPA to initiate bundle > wrapping if so desired. > > 3) These two approaches could be combined using different mechanisms > for the application vs. the BPA to wrap bundles. In this approach, > any bundles wrapped by the application would be handled as a single > bundle back to the application by the BPA, and this bundle would > have to be un-wrapped by the application. The BPA, however, could > add bundles to any existing bundle it handled so long as the bundle > handling and endpoint were the same. This scheme would create two > parallel mechanisms, one for the application and one for the BPA, > for managing Bundle-In-Bundle. > > > To some degree these are low level details. However they are > broadly determined by the entity that is given the role of wrapping > (and un-wrapping) bundles, and this brings me back to my original > questions 1 and 2 - what are the uses for this service and how is it > invoked. Once we have consensus on answers to those, I believe the > other answers will be more forthcoming. > > Thank you for reading so far. I look forward to hearing your > thoughts on these matters. > > - Jon Shapiro > > > Jon Shapiro - Lead Software Engineer, Mobile Networking Systems, 6/249 > > BBN Technologies > 10 Moulton St. > Cambridge MA, 02138 > > (617) 873-4383 > > "The early bird gets the worm, but the second mouse gets the cheese." > > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest --Apple-Mail-7-205634092 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi. That particular = date/time is not possible for me. The following week is much easier, = generally. How about Nov 10, at 1pm eastern? I am free = nearly the whole day, except for 2-3pm = Pacific.

thx

- = K

On Oct 31, 2008, at Oct 3110:00 = AMPDT, Jon Shapiro wrote:

Hi = All,

The recent discussion concerning the Bundle-In-Bundle = feature has raised a number of questions for me as I strive to = understand its use while familiarizing myself with the current reference = implementation. As BBN is working on a DTN implementation that = should include this feature, I propose that we have a teleconference, = hosted by BBN, where all of the interested parties could participate and = hopefully come to a resolution.

I propose that we hold = this teleconference on 5-Nov-08, 1-2pm EST, if this works for the = interested parties. If not, please propose an alternate date and = time. If this topic and teleconference does not interest you = please skip the remainder and thank you for your time. If this = topic does interest you please let me know and I will send the = teleconference connection information to you.

A summary of = my understanding of the feature and concerns follows.

The = previous scheme for encapsulating a Bundle-in-a-Bundle, henceforth BIB, = was to place the entire bundle B1 inside another bundle wB1, essentially = by putting another primary block in front of B1's primary block, and = placing (wrapping) the original primary block and payload of B1 in the = wB1 payload block. This scheme allowed the application agent to = send bundle B1 to nodes without triggering (the original set of) BPA = actions for B1. The wrapper bundle wB1 was an administrative = record type bundle.

Note that the scheme to wrap B1 inside = bundle wB1, may be generalized to allow multiple bundles B1, B2, B3 etc. = to be wrapped inside wB1, and may also allow wB1 to be extended (or = wrapped inside wB2) so as to include additional bundles B4, B5. = The lack of specificity in this matter is a weakness and needs to be = addressed, especially given the objections stemming from the limitation = on custody transfer below, as the handling of each inner bundle is = presumed to be identical when wrapped inside wBN.

= The previously proposed BIB scheme using administrative records as the = wrapper had a problem (as noted by Peter Lovell) in that RFC 5050 sec. = 4.2, states: "If the bundles processing control flags indicate that the = bundle's application data unit is an administrative record, then the = custody transfer requested flag must be zero and all status report = request flags must be zero." This requirement basically limits the = use of administrative records to their intended "signal" or "report" = uses (see RFC 5050 sec. 5.1), and prevents their use for BIB use since = it was considered important to allow custody transfer to be used for the = wrapped bundle(s).

Susan Symington has proposed that one = of three alternate proposals therefore be followed:

1. Accept = this limitation.
2. Change the RFC 5050 section 4.2 rule to remove = this limitation.
3. Use a different mechanism instead of the = administrative record. One proposal is to use an extension block = to hold both the original version of the modified primary block fields = and information such as count and offset values that can be used to = reconstitute the wrapped bundle(s) from the payload block.   =

These are all excellent points, but I am not sure how to = understand them without context. I believe that a number of basic = questions need to be addressed as we move forward with any BIB = scheme. These questions are:

=         1. What are the uses for = Bundle-In-Bundle?
=             &n= bsp;   1a. Why can't it be done currently?
=             &n= bsp;   1b. Who needs the BIB feature?
=         2. How are BIBs = created? (by the app, or by the BPA?)
=         3. How are BIBs treated = in transit? (hopefully as just another bundle)
=         4. How are BIBs treated = at the endpoints? (handled by app or BPA?)

First: What are = the uses, why isn't it already covered, why is it needed.

The = most concrete example (use case) so far is that a new node (N-new) = appears in the network and requests information which exists as a = previously delivered multicast bundle on an existing node (N-old). = N-old wants to send the multicast data to N-new without flooding the = network. Therefore N-old wants to substitute a unicast address in = place of the multicast address, at least during intermediate hops, so = that the bundle transport only consumes a minimal set of = resources. N-old may require custody transfer and other services = for this bundle that differ from the original set of services used to = transport the bundle. Finally, the bundle may be protected by a = checksum that is calculated across both its payload and primary block, = such that the original multicast destination address has been included = in the checksum. Therefore the original primary block can only be = modified in transit, but not once it arrives (if the checksum needs to = be calculated at each step the original block could be resurrected = en-route for this purpose, and then re-wrapped).

Other = considerations:

A) Flexibility is specifying different handling = from original bundle handling such as custody transfer:

It seems = a bit odd that a multicast bundle would require custody transfer, since = the node holding it (N-old) is presumably part of the same multicast = group that N-new is a member of. However on the working assumption = that N-new could be a better custodian than a resource bound N-old, and = for maximum flexibility, it seems valid to keep this as part of the BIB = requirements.

B) Multiple bundles within a single wrapped = bundle:

It also seems fair to allow multiple bundles to be = wrapped inside a single bundle, so long as all of the bundles being = wrapped together all share the same endpoint(s) and in transit handling = requirements (custody transfer, etc.). The use case above could be = reformulated such that N-old is holding multiple multicast bundles to = send to N-new, and thus wishes to form a wrapped bundle wB1 consisting = of B1, B2 and B3. The resulting bundle aggregate would then be handled = as a single bundle, although it might get fragmented en-route. =

C) Allowing other bundles to be added to an existing (wrapped = or unwrapped) bundle:

The utility of further wrapping additional = bundles along with previously wrapped bundles seems reasonable (perhaps = some node along the way determines to add bundles in response to the = same request). However it appears to force several = decisions. First, it appears to require that the BPA, as the = entity that handles wrapped bundles 'in the tunnel', know how to peek = inside them (i.e., the payload of a wrapped bundle can not be = opaque). This in turn seems to require that the BPA be the entity = that decides to wrap bundles in the first place, as an in-transit bundle = has not reached the endpoint so the application would not be part of the = processing, while the BPA would.

Including this feature = raises a number of questions. Is it needed? Would it prevent = the application from generating wrapped bundles as well? Would it = impose a more complicated control interface between the application(s) = and the BPA to support application wrapping? Why limit the BPA to = extending pre-existing wrapped bundles - i.e., why not allow bundle = aggregation (via wrapped bundles) whenever the BPA detects multiple = bundles traveling to the same endpoint(s) with the same handling? = Is this desired?

D) Layering of interfaces, = features:

My main concern about any BIB implementation is that = it should follow the layering philosophy, where the entity that wraps = the bundle is the entity that un-wraps it, to avoid complicated control = flows between separate layers. As the discussion concerning = extending an existing (wrapped or unwrapped) bundle by the BPA to = include other bundles indicates, there appear to be several = choices:

1) If the application agent is wrapping and handing a = wrapped bundle down to the BPA, it should expect to be delivered the = wrapped bundle at the tunnel endpoint(s), and it should be the entity = that unwraps the bundle upon delivery. This would seem to prevent = the BPA from further wrapping additional bundles en-route as the wrapped = bundle would then be an opaque payload.

2) If the = application-to-BPA interface is defined such that it allows a set of = bundles to be sent to a unicast endpoint then it would be the BPA that = does the wrapping, and it should be the BPA that does the unwrapping, so = that the BPA would then present each un-wrapped bundle to the endpoint = application as if it had arrived separately. If the BPA was doing = the wrapping, it could add other bundles en-route. This approach would = allow the BPA to further wrap bundles en-route, and would allow the BPA = to initiate bundle wrapping if so desired.

3) These two = approaches could be combined using different mechanisms for the = application vs. the BPA to wrap bundles. In this approach, any = bundles wrapped by the application would be handled as a single bundle = back to the application by the BPA, and this bundle would have to be = un-wrapped by the application. The BPA, however, could add bundles = to any existing bundle it handled so long as the bundle handling and = endpoint were the same. This scheme would create two parallel = mechanisms, one for the application and one for the BPA, for managing = Bundle-In-Bundle.

To some degree these are low = level details. However they are broadly determined by the entity = that is given the role of wrapping (and un-wrapping) bundles, and this = brings me back to my original questions 1 and 2 - what are the uses for = this service and how is it invoked. Once we have consensus on = answers to those, I believe the other answers will be more = forthcoming.

Thank you for reading so far. I = look forward to hearing your thoughts on these matters.

- Jon = Shapiro

Jon Shapiro - Lead Software Engineer, Mobile = Networking Systems, 6/249

BBN Technologies
10 Moulton = St.
Cambridge MA, 02138

(617) 873-4383

"The early = bird gets the worm, but the second mouse gets the cheese."

=
= _______________________________________________
dtn-interest mailing = list
dtn-interest@mai= llists.intel-research.net
http://maillists.intel-research.net/mailm= an/listinfo/dtn-interest

= --Apple-Mail-7-205634092-- Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9VHBjmx012085 for ; Fri, 31 Oct 2008 10:11:45 -0700 Received: from dhcp89-069-173.bbn.com ([128.89.69.173] helo=7C-541.bbn.com) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1KvxMA-00078X-A5; Fri, 31 Oct 2008 13:00:18 -0400 Message-Id: <6.2.1.2.2.20081031125028.023e95f8@po2.bbn.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 31 Oct 2008 13:00:18 -0400 To: dtn-interest@mailman.dtnrg.org From: Jon Shapiro Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_9770187==.ALT" Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2008 17:11:45 -0000 --=====================_9770187==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi All, The recent discussion concerning the Bundle-In-Bundle feature has raised a number of questions for me as I strive to understand its use while familiarizing myself with the current reference implementation. As BBN is working on a DTN implementation that should include this feature, I propose that we have a teleconference, hosted by BBN, where all of the interested parties could participate and hopefully come to a resolution. I propose that we hold this teleconference on 5-Nov-08, 1-2pm EST, if this works for the interested parties. If not, please propose an alternate date and time. If this topic and teleconference does not interest you please skip the remainder and thank you for your time. If this topic does interest you please let me know and I will send the teleconference connection information to you. A summary of my understanding of the feature and concerns follows. The previous scheme for encapsulating a Bundle-in-a-Bundle, henceforth BIB, was to place the entire bundle B1 inside another bundle wB1, essentially by putting another primary block in front of B1's primary block, and placing (wrapping) the original primary block and payload of B1 in the wB1 payload block. This scheme allowed the application agent to send bundle B1 to nodes without triggering (the original set of) BPA actions for B1. The wrapper bundle wB1 was an administrative record type bundle. Note that the scheme to wrap B1 inside bundle wB1, may be generalized to allow multiple bundles B1, B2, B3 etc. to be wrapped inside wB1, and may also allow wB1 to be extended (or wrapped inside wB2) so as to include additional bundles B4, B5. The lack of specificity in this matter is a weakness and needs to be addressed, especially given the objections stemming from the limitation on custody transfer below, as the handling of each inner bundle is presumed to be identical when wrapped inside wBN. The previously proposed BIB scheme using administrative records as the wrapper had a problem (as noted by Peter Lovell) in that RFC 5050 sec. 4.2, states: "If the bundles processing control flags indicate that the bundle's application data unit is an administrative record, then the custody transfer requested flag must be zero and all status report request flags must be zero." This requirement basically limits the use of administrative records to their intended "signal" or "report" uses (see RFC 5050 sec. 5.1), and prevents their use for BIB use since it was considered important to allow custody transfer to be used for the wrapped bundle(s). Susan Symington has proposed that one of three alternate proposals therefore be followed: 1. Accept this limitation. 2. Change the RFC 5050 section 4.2 rule to remove this limitation. 3. Use a different mechanism instead of the administrative record. One proposal is to use an extension block to hold both the original version of the modified primary block fields and information such as count and offset values that can be used to reconstitute the wrapped bundle(s) from the payload block. These are all excellent points, but I am not sure how to understand them without context. I believe that a number of basic questions need to be addressed as we move forward with any BIB scheme. These questions are: 1. What are the uses for Bundle-In-Bundle? 1a. Why can't it be done currently? 1b. Who needs the BIB feature? 2. How are BIBs created? (by the app, or by the BPA?) 3. How are BIBs treated in transit? (hopefully as just another bundle) 4. How are BIBs treated at the endpoints? (handled by app or BPA?) First: What are the uses, why isn't it already covered, why is it needed. The most concrete example (use case) so far is that a new node (N-new) appears in the network and requests information which exists as a previously delivered multicast bundle on an existing node (N-old). N-old wants to send the multicast data to N-new without flooding the network. Therefore N-old wants to substitute a unicast address in place of the multicast address, at least during intermediate hops, so that the bundle transport only consumes a minimal set of resources. N-old may require custody transfer and other services for this bundle that differ from the original set of services used to transport the bundle. Finally, the bundle may be protected by a checksum that is calculated across both its payload and primary block, such that the original multicast destination address has been included in the checksum. Therefore the original primary block can only be modified in transit, but not once it arrives (if the checksum needs to be calculated at each step the original block could be resurrected en-route for this purpose, and then re-wrapped). Other considerations: A) Flexibility is specifying different handling from original bundle handling such as custody transfer: It seems a bit odd that a multicast bundle would require custody transfer, since the node holding it (N-old) is presumably part of the same multicast group that N-new is a member of. However on the working assumption that N-new could be a better custodian than a resource bound N-old, and for maximum flexibility, it seems valid to keep this as part of the BIB requirements. B) Multiple bundles within a single wrapped bundle: It also seems fair to allow multiple bundles to be wrapped inside a single bundle, so long as all of the bundles being wrapped together all share the same endpoint(s) and in transit handling requirements (custody transfer, etc.). The use case above could be reformulated such that N-old is holding multiple multicast bundles to send to N-new, and thus wishes to form a wrapped bundle wB1 consisting of B1, B2 and B3. The resulting bundle aggregate would then be handled as a single bundle, although it might get fragmented en-route. C) Allowing other bundles to be added to an existing (wrapped or unwrapped) bundle: The utility of further wrapping additional bundles along with previously wrapped bundles seems reasonable (perhaps some node along the way determines to add bundles in response to the same request). However it appears to force several decisions. First, it appears to require that the BPA, as the entity that handles wrapped bundles 'in the tunnel', know how to peek inside them (i.e., the payload of a wrapped bundle can not be opaque). This in turn seems to require that the BPA be the entity that decides to wrap bundles in the first place, as an in-transit bundle has not reached the endpoint so the application would not be part of the processing, while the BPA would. Including this feature raises a number of questions. Is it needed? Would it prevent the application from generating wrapped bundles as well? Would it impose a more complicated control interface between the application(s) and the BPA to support application wrapping? Why limit the BPA to extending pre-existing wrapped bundles - i.e., why not allow bundle aggregation (via wrapped bundles) whenever the BPA detects multiple bundles traveling to the same endpoint(s) with the same handling? Is this desired? D) Layering of interfaces, features: My main concern about any BIB implementation is that it should follow the layering philosophy, where the entity that wraps the bundle is the entity that un-wraps it, to avoid complicated control flows between separate layers. As the discussion concerning extending an existing (wrapped or unwrapped) bundle by the BPA to include other bundles indicates, there appear to be several choices: 1) If the application agent is wrapping and handing a wrapped bundle down to the BPA, it should expect to be delivered the wrapped bundle at the tunnel endpoint(s), and it should be the entity that unwraps the bundle upon delivery. This would seem to prevent the BPA from further wrapping additional bundles en-route as the wrapped bundle would then be an opaque payload. 2) If the application-to-BPA interface is defined such that it allows a set of bundles to be sent to a unicast endpoint then it would be the BPA that does the wrapping, and it should be the BPA that does the unwrapping, so that the BPA would then present each un-wrapped bundle to the endpoint application as if it had arrived separately. If the BPA was doing the wrapping, it could add other bundles en-route. This approach would allow the BPA to further wrap bundles en-route, and would allow the BPA to initiate bundle wrapping if so desired. 3) These two approaches could be combined using different mechanisms for the application vs. the BPA to wrap bundles. In this approach, any bundles wrapped by the application would be handled as a single bundle back to the application by the BPA, and this bundle would have to be un-wrapped by the application. The BPA, however, could add bundles to any existing bundle it handled so long as the bundle handling and endpoint were the same. This scheme would create two parallel mechanisms, one for the application and one for the BPA, for managing Bundle-In-Bundle. To some degree these are low level details. However they are broadly determined by the entity that is given the role of wrapping (and un-wrapping) bundles, and this brings me back to my original questions 1 and 2 - what are the uses for this service and how is it invoked. Once we have consensus on answers to those, I believe the other answers will be more forthcoming. Thank you for reading so far. I look forward to hearing your thoughts on these matters. - Jon Shapiro ---------- Jon Shapiro - Lead Software Engineer, Mobile Networking Systems, 6/249 BBN Technologies 10 Moulton St. Cambridge MA, 02138 (617) 873-4383 "The early bird gets the worm, but the second mouse gets the cheese." --=====================_9770187==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All,

The recent discussion concerning the Bundle-In-Bundle feature has raised a number of questions for me as I strive to understand its use while familiarizing myself with the current reference implementation. As BBN is working on a DTN implementation that should include this feature, I propose that we have a teleconference, hosted by BBN, where all of the interested parties could participate and hopefully come to a resolution.

I propose that we hold this teleconference on 5-Nov-08, 1-2pm EST, if this works for the interested parties. If not, please propose an alternate date and time. If this topic and teleconference does not interest you please skip the remainder and thank you for your time. If this topic does interest you please let me know and I will send the teleconference connection information to you.

A summary of my understanding of the feature and concerns follows.

The previous scheme for encapsulating a Bundle-in-a-Bundle, henceforth BIB, was to place the entire bundle B1 inside another bundle wB1, essentially by putting another primary block in front of B1's primary block, and placing (wrapping) the original primary block and payload of B1 in the wB1 payload block. This scheme allowed the application agent to send bundle B1 to nodes without triggering (the original set of) BPA actions for B1. The wrapper bundle wB1 was an administrative record type bundle.

Note that the scheme to wrap B1 inside bundle wB1, may be generalized to allow multiple bundles B1, B2, B3 etc. to be wrapped inside wB1, and may also allow wB1 to be extended (or wrapped inside wB2) so as to include additional bundles B4, B5. The lack of specificity in this matter is a weakness and needs to be addressed, especially given the objections stemming from the limitation on custody transfer below, as the handling of each inner bundle is presumed to be identical when wrapped inside wBN.

The previously proposed BIB scheme using administrative records as the wrapper had a problem (as noted by Peter Lovell) in that RFC 5050 sec. 4.2, states: "If the bundles processing control flags indicate that the bundle's application data unit is an administrative record, then the custody transfer requested flag must be zero and all status report request flags must be zero." This requirement basically limits the use of administrative records to their intended "signal" or "report" uses (see RFC 5050 sec. 5.1), and prevents their use for BIB use since it was considered important to allow custody transfer to be used for the wrapped bundle(s).

Susan Symington has proposed that one of three alternate proposals therefore be followed:

1. Accept this limitation.
2. Change the RFC 5050 section 4.2 rule to remove this limitation.
3. Use a different mechanism instead of the administrative record. One proposal is to use an extension block to hold both the original version of the modified primary block fields and information such as count and offset values that can be used to reconstitute the wrapped bundle(s) from the payload block.

These are all excellent points, but I am not sure how to understand them without context. I believe that a number of basic questions need to be addressed as we move forward with any BIB scheme. These questions are:

        1. What are the uses for Bundle-In-Bundle?
            &nbs= p;   1a. Why can't it be done currently?
            &nbs= p;   1b. Who needs the BIB feature?
        2. How are BIBs created? (by the app, or by the BPA?)
        3. How are BIBs treated in transit? (hopefully as just another bundle)
        4. How are BIBs treated at the endpoints? (handled by app or BPA?)

First: What are the uses, why isn't it already covered, why is it needed.

The most concrete example (use case) so far is that a new node (N-new) appears in the network and requests information which exists as a previously delivered multicast bundle on an existing node (N-old). N-old wants to send the multicast data to N-new without flooding the network. Therefore N-old wants to substitute a unicast address in place of the multicast address, at least during intermediate hops, so that the bundle transport only consumes a minimal set of resources. N-old may require custody transfer and other services for this bundle that differ from the original set of services used to transport the bundle. Finally, the bundle may be protected by a checksum that is calculated across both its payload and primary block, such that the original multicast destination address has been included in the checksum. Therefore the original primary block can only be modified in transit, but not once it arrives (if the checksum needs to be calculated at each step the original block could be resurrected en-route for this purpose, and then re-wrapped).

Other considerations:

A) Flexibility is specifying different handling from original bundle handling such as custody transfer:

It seems a bit odd that a multicast bundle would require custody transfer, since the node holding it (N-old) is presumably part of the same multicast group that N-new is a member of. However on the working assumption that N-new could be a better custodian than a resource bound N-old, and for maximum flexibility, it seems valid to keep this as part of the BIB requirements.

B) Multiple bundles within a single wrapped bundle:

It also seems fair to allow multiple bundles to be wrapped inside a single bundle, so long as all of the bundles being wrapped together all share the same endpoint(s) and in transit handling requirements (custody transfer, etc.). The use case above could be reformulated such that N-old is holding multiple multicast bundles to send to N-new, and thus wishes to form a wrapped bundle wB1 consisting of B1, B2 and B3. The resulting bundle aggregate would then be handled as a single bundle, although it might get fragmented en-route.

C) Allowing other bundles to be added to an existing (wrapped or unwrapped) bundle:

The utility of further wrapping additional bundles along with previously wrapped bundles seems reasonable (perhaps some node along the way determines to add bundles in response to the same request). However it appears to force several decisions. First, it appears to require that the BPA, as the entity that handles wrapped bundles 'in the tunnel', know how to peek inside them (i.e., the payload of a wrapped bundle can not be opaque). This in turn seems to require that the BPA be the entity that decides to wrap bundles in the first place, as an in-transit bundle has not reached the endpoint so the application would not be part of the processing, while the BPA would.

Including this feature raises a number of questions. Is it needed? Would it prevent the application from generating wrapped bundles as well? Would it impose a more complicated control interface between the application(s) and the BPA to support application wrapping? Why limit the BPA to extending pre-existing wrapped bundles - i.e., why not allow bundle aggregation (via wrapped bundles) whenever the BPA detects multiple bundles traveling to the same endpoint(s) with the same handling? Is this desired?

D) Layering of interfaces, features:

My main concern about any BIB implementation is that it should follow the layering philosophy, where the entity that wraps the bundle is the entity that un-wraps it, to avoid complicated control flows between separate layers. As the discussion concerning extending an existing (wrapped or unwrapped) bundle by the BPA to include other bundles indicates, there appear to be several choices:

1) If the application agent is wrapping and handing a wrapped bundle down to the BPA, it should expect to be delivered the wrapped bundle at the tunnel endpoint(s), and it should be the entity that unwraps the bundle upon delivery. This would seem to prevent the BPA from further wrapping additional bundles en-route as the wrapped bundle would then be an opaque payload.

2) If the application-to-BPA interface is defined such that it allows a set of bundles to be sent to a unicast endpoint then it would be the BPA that does the wrapping, and it should be the BPA that does the unwrapping, so that the BPA would then present each un-wrapped bundle to the endpoint application as if it had arrived separately. If the BPA was doing the wrapping, it could add other bundles en-route. This approach would allow the BPA to further wrap bundles en-route, and would allow the BPA to initiate bundle wrapping if so desired.

3) These two approaches could be combined using different mechanisms for the application vs. the BPA to wrap bundles. In this approach, any bundles wrapped by the application would be handled as a single bundle back to the application by the BPA, and this bundle would have to be un-wrapped by the application. The BPA, however, could add bundles to any existing bundle it handled so long as the bundle handling and endpoint were the same. This scheme would create two parallel mechanisms, one for the application and one for the BPA, for managing Bundle-In-Bundle.

To some degree these are low level details. However they are broadly determined by the entity that is given the role of wrapping (and un-wrapping) bundles, and this brings me back to my original questions 1 and 2 - what are the uses for this service and how is it invoked. Once we have consensus on answers to those, I believe the other answers will be more forthcoming.

Thank you for reading so far. I look forward to hearing your thoughts on these matters.

- Jon Shapiro

Dear = Colleagues,

We =0A= apologize if you receive multiple copies.

=0A=

Please find below the Call for papers for IQ2S 2009, = The First =0A= International Workshop
on Information Quality and Quality of Service = for =0A= Pervasive Computing, which will be held
in conjunction with IEEE = PerCom 2009, =0A= Galveston, Texas, March 9-13, 2009.

=0A=

[+++++++ DEADLINE HAS BEEN EXTENDED TO OCTOBER 31! =0A= +++++++]

=0A=

We would appreciate it very much if you could = disseminate =0A= this CFP to your colleagues and students!

Best = Regards,

Wendong =0A= Xiao, Institute for Infocomm Research, Singapore
Habib M. Ammari, the =0A= University of Texas at Arlington, USA

Program =0A= Co-Chairs

--------------------------------------------------------= -------------------------------------------------------------------------= ---
CALL =0A= FOR PAPERS

The First = International =0A= Workshop on Information Quality and Quality of Service for Pervasive = Computing =0A= (IQ2S 2009)
Website: http://iq2s2009.i2r.a-star.edu= .sg =0A= <http://iq2s2009.i2r.a-star.ed= u.sg/> =0A= <http://iq2s2009.i2r.a-star.edu.sg/ =0A= > >
In Conjunction with IEEE PerCom 2009 (http://www.percom.org <http://www.percom.org/> = <http://www.percom.org/ =0A= > > )
Galveston, Texas, March 9-13, =0A= 2009


   &nb= sp;    =0A= Quality of service (QoS) has been studied in various building blocks in =0A= pervasive computing, e.g., different QoS mechanisms are presented for = wireless =0A= or wired networks, with QoS metrics being described in terms of delay, =0A= bandwidth, and/or data loss etc. The emerging pervasive computing is =0A= application-driven and mission-critical, therefore the information = quality (IQ), =0A= such as the accuracy of target tracking or event detection, is also = critical for =0A= the end users, service providers and the system designers. IQ and QoS =0A= provisioning for pervasive computing is challenging and difficult due to = the =0A= resource-constrained, dynamic and distributed nature of the system, the = weakness =0A= under security attacking, and the lack of a holistic design approach = which takes =0A= into account the different types of resources and their =0A= inter-dependencies.

&nbs= p;      =0A= The objective of this workshop is to provide a forum to exchange ideas, = present =0A= results, share experience, and enhance collaborations among researchers, =0A= professionals, and application developers in various aspects of IQ and = QoS for =0A= pervasive computing. Topics of interest include but are not limited =0A= to:

        =0A= *            = System =0A= architecture for IQ and QoS =0A= provisioning

        =0A= *            = IQ-oriented =0A= signal & information processing (e.g., source coding and data =0A= compression)

        =0A= *            QoS = for =0A= target/event detection, localization, tracking and =0A= classification

        =0A= *            QoS = for =0A= wireless ad hoc and sensor networks (including coverage and =0A= connectivity)

        =0A= *            QoS = for task =0A= mapping and scheduling

        =0A= *            = Cross-layer =0A= design for coordinated QoS (including IQ-QoS =0A= integration)

        =0A= *            = Adaptative =0A= IQ and QoS under dynamic =0A= environments

        =0A= *            = Trust, =0A= security and privacy issues in IQ and =0A= QoS

        =0A= *            = Development =0A= environments and programming languages for IQ and =0A= QoS

        =0A= *            IQ = and QoS =0A= for emerging pervasive computing applications, such as three-dimensional =0A= wireless sensor networks (like underwater sensor network), healthcare, = and =0A= structural health = monitoring

        =0A= *            = Prototype =0A= test-bed design, implementation, and field =0A= trials

        Submission =0A= Instructions

        The = submitted =0A= paper should be in the IEEE conference format (author guidelines can be = found at =0A= ftp://pubftp.computer.org/Press/Outgoing/proceedings/INSTRUCT.HTM =0A= <ftp://pubftp.computer.org/Press/Outgoing/proceedings/INSTRUCT.HTM&g= t; =0A= ) and should be no more than 6 pages in length. The paper should not be =0A= previously published or currently under review elsewhere. Only = electronic =0A= submissions in PDF format will be considered. Detailed electronic = submission =0A= procedures will be announced later. All submissions will be = peer-reviewed and =0A= selected based on their originality, merit, and relevance to the = workshop. =0A= Accepted papers will be published by the IEEE Computer Society Press in = the =0A= combined PerCom 2009 workshops proceedings. At least one author of each = accepted =0A= paper must register and attend the workshop to present the =0A= paper.

        General =0A= Co-Chairs

        Sajal K. = Das, the =0A= University of Texas at Arlington, =0A= USA
        Chen Khong Tham, = Institute for =0A= Infocomm Research, =0A= Singapore

   &n= bsp;    =0A= Program Co-Chairs
        Wendong = Xiao, =0A= Institute for Infocomm Research, =0A= Singapore
        Habib M. Ammari, = the =0A= University of Texas at Arlington, =0A= USA

    &n= bsp;   =0A= Important Dates
        Paper =0A= submission:     October 31, =0A= 2008
        Author = notification: =0A= December 19, 2008
        = Camera-ready =0A= due:     January 7, =0A= 2009
-----------------------------------------------------------------= -------------------------------------------------------------------

=0A= =0A= =0A= ------_=_NextPart_001_01C935F9.4D7001C7-- Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9NIYEV9014402 for ; Thu, 23 Oct 2008 11:34:15 -0700 Received: from [13.2.117.234] ([13.2.117.234]) by alpha.xerox.com with SMTP id <321228(1)>; Thu, 23 Oct 2008 11:25:44 PDT Message-ID: <4900C1A8.60403@parc.com> Date: Thu, 23 Oct 2008 11:25:44 PDT From: Ignacio Solis User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: "Symington, Susan F." References: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> <711FB52C-F272-4A12-B041-51A2E5920283@parc.com> <8E507634779E22488719233DB3DF9FF002F86302@IMCSRV4.MITRE.ORG> In-Reply-To: <8E507634779E22488719233DB3DF9FF002F86302@IMCSRV4.MITRE.ORG> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dtn-interest@mailman.dtnrg.org" Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 18:34:15 -0000 Symington, Susan F. wrote > The situation (of sending an integrity-protected > multicast bundle to a singleton address) that we are trying to solve > arises because the integrity checksum is calculated over the > destination EID. If the integrity checksum were not calculated over the > destination EID, then the multicast destination EID in the cached > bundle could simply be replaced by the singleton destination to which > we want to send the bundle, and the bundle could be sent to the > singleton destination from the cache. Perhaps defining such a bundle > integrity ciphersuite should be the solution that we focus on for that > situation. This is actually my point. I _like_ the fact that the EID is part of the integrity checksum. This means that an application can rely on it. What I don't like is us (the "bottom layers") having to modify it. > Maybe bundles sent to multicast addresses should always use a (to be > defined) integrity checksum that is not calculated over the destination > EID whereas bundles sent to singleton EIDs may use either type of > checksum. From a content-centric viewpoint, the destination to which > the bundle is sent really is irrelevant, so why protect its integrity, > especially when protecting its integrity restricts what you can > usefully do with that bundle? What we need to protect is the content > and whatever metadata is used to make the decision regarding the > bundle's relevance. Perhaps we need an alternative integrity checksum > that is defined for the content-centric data dissemination approach > rather biased toward the source-to-destination "call" paradigm of > transmission as the current one is. However, even if we define a new > integrity checksum to deal with this situation, it still seems like > encapsulation would be useful for the situation I identified in the > custodial multicast draft. Will we really never want tunnels? My argument is that we always want "tunnels". To me, the "tunnel" mode seems like the real mode, and the non-tunnel mode seems like sending a naked Application Data Unit. > I guess my response to you amounts to this: I'm open to your objections > and I'd like to understand your ideas better. I am not a strong > advocate of encapsulation per se; I just want a way to do the two > things that I know encapsulation can enable me to do. I can see and > have said how we might solve the first situation with a new integrity > ciphersuite instead of encapsulation (though I don't know what > objections others might raise to that), but I can't see how we'd solve > the second situation (the situation from the custodial multicast > extensions document). I wonder if others see additional situations in > which they would like to use encapsulation. Once again, I like encapsulation. What I don't like is that we're having to encapsulate ourselves because the original bundles couldn't handle the problem. Also, I'm fine completely postponing this discussion until one day when we all have free time to brainstorm. My "perfect solution", which is not a solution, more like a problem statement, is probably impractical. So let me say something more along the lines of the problem we have. Let me restate the basic problem you describe in this email: - We use destination EIDs to forward and route bundles - Destination EIDs are protected by the integrity checksum Problem: We want to (re)deliver a bundle (B1) and using the current destination EID would prove problematic Solution 1 - encapsulate the bundle (B1) into another bundle (B2). Send bundle B2 to the destination we want to reach. Decapsulate, deliver to original EID. Solution 2 - don't include destination EIDs as part of the integrity check. Modify bundle B1 to reach the destination we want. Crazy Solution 3 - have 2 destination EIDs fields, one protected by the integrity check, the other just used for forwarding and routing For now, due to Real World (TM) constraints, I think solution 1, the one you are pursuing, is the right one. I don't like Solution 2 because I would like to keep the destination EID intact. I'm not advocating Solution 3, it's just to illustrate there are always alternatives. Later I will send an email with some of the concerns more clearly stated from the Content-Based side. They will probably support the need for tunneling under the current system. Nacho >> -----Original Message----- >> From: dtn-interest-bounces@maillists.intel-research.net [mailto:dtn- >> interest-bounces@maillists.intel-research.net] On Behalf Of Ignacio >> Solis >> Sent: Wednesday, October 22, 2008 6:18 PM >> To: dtn-interest@mailman.dtnrg.org >> Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue >> >> Hi all. >> >> I just want to make a meta comment. As a disclaimer, I feel biased >> towards content-centricity. >> >> It seems to me that what we're trying to solve with the BiB is an >> inherent flaw in the design of DTN. Basically, DTN ties down the way >> we transport the data with the data/meta information. >> Now we're having problems because due to "integrity-protection" we >> can't transfer the bundle the way we need to. To solve this problem, >> we are designing a bundle protocol to move bundles. >> >> This might be why I'm trying to design our DTN content approach as, >> basically, an overlay over DTN. DTN is used as a way to move the >> content around, but the content is by nature, self-contained. >> >> In this instance, we're trying to treat the bundle as self-contained, >> but still want it to be flexible enough to be moved around, and for >> this we're designing a new protocol. >> >> If this discussion (I don't mean my ideas, I mean the main thread) >> leads to a good BiB protocol, wouldn't we gravitate towards using the >> BiB protocol more than the normal Bundle protocol? After all, it will >> be more "flexible". >> >> I understand that a lot of work has been done on DTN, and I do realize >> I might be speaking about impractical things, I just wanted to voice >> my ideas publicly. >> >> Don't take me too seriously, >> >> Nacho >> >> >> >> >> On Oct 21, 2008, at 12:37 PM, Symington, Susan F. wrote: >>> Peter Lovell has pointed out an issue with DTN Bundle-in-Bundle >>> (BiB) Encapsulation. There are several options for how to address >>> this issue, and I would like to get a feel for the DTN community's >>> preferences. >>> >>> First of all, why do we want an encapsulation capability? Here is an >>> example of when BiB Encapsulation is handy: suppose a DTN cache has >>> some bundles stored on it. One of the bundles has a multicast >>> address as its destination EID and this bundle is integrity- >>> protected using a PIB. A new member joins the multicast group. We >>> would like to be able to send this new member the bundle. If we >>> simple send out the bundle as it is found in the cache, it is going >>> to go to all group members. If we change the destination EID of this >>> bundle, it can be sent to only the new member (as desired), but the >>> bundles integrity check will fail. Instead, we'd like to be able to >>> encapsulate this bundle so the encapsulating bundle can be addressed >>> directly to the new member only. >>> >>> Secondly, what is the problem that Peter has pointed out with the >>> way BiB encapsulation is now defined in draft-irtf-dtnrg-bundle- >>> encapsulation-03? The problem has to do with using an >>> administrative record as the mechanism to encapsulate bundles. >>> According to the Bundle Protocol, if a bundle is carrying an >>> administrative record, the bundle cannot have its custody transfer >>> requested bit set. This means that if the original bundle that is >>> sent has its custody transfer bit set and then this bundle is >>> encapsulated (by being placed in an administrative record that is >>> carried by an encapsulating bundle), no node can take custody of the >>> encapsulating bundle as it travels through the network. Only after >>> the original bundle is de-encapsulated can a node take custody of >>> the original de-encapsulated bundle. The whole time the bundle is >>> in the encapsulation "tunnel", the encapsulating bundle cannot be >>> taken custody of. In terms of the example use of BiB encapsulation >>> given above, there would be no way to take a bundle from a DTN >>> cache, encapsulate it in another bundle, and send this new bundle to >>> a newly joining group member custodially. >>> >>> There seem to be three options for addressing this: >>> 1. Do nothing. Leave the BiB Encapsulation I-D as written and >>> live with the fact that encapsulating bundles cannot be sent >>> custodially. >>> 2. Change the rule in section 4.2 (page 15) of the Bundle >>> Protocol Specification (RFC 5050) to enable bundles whose >>> application data unit is an administrative record of type BiB >>> Encapsulation to have a custody transfer requested flag of 1. >>> 3. Rewrite the BiB Encapsulation I-D to perform encapsulation >>> using an extension block instead of an administrative record. The >>> extension block would indicate that the payload of the bundle >>> contains one or more encapsulated bundles (and it could also provide >>> their offsets). The payload of the bundle would contain the actual >>> encapsulated bundles. (We want the encapsulated bundle(s) to be in >>> the payload and not in an extension block to allow for >>> fragmentation.) Some changes to the conceptual model and terminology >>> now used in the Bundle Protocol (BP) would be required in order to >>> be able to define encapsulation in this manner. As defined now, the >>> BP requires that when a bundle reaches a bundle node that is a >>> member of the bundle's destination endpoint, the bundle must be >>> delivered (section 5.7 of the BP, step2). Delivery means that the >>> bundles' application data unit (apdu), which consists of one or more >>> encapsulated bundles (along with any offset information if more than >>> one bundle has been encapsulated), would have to be presented to the >>> node's application agent (section 3.1 of the BP, page 6). In the >>> case of encapsulation, this application agent would in turn have to >>> take each of these bundles and hand them back to the bundle protocol >>> agent, in order, to each be processed as if they had just been >>> received from another node (as described in section 5.6 of the BP). >>> Where this doesn't exactly fit in now with the terminology and >>> conceptual model used in the BP is that the application agent, to >>> which the apdu is presented as part of the delivery process, >>> consists of two elements: an administrative element, and an >>> application-specific element. Neither of these two elements, as >>> currently defined in the BP, seems capable of handling the apdu of >>> encapsulated bundles as desired. >>> a. The application-specific element is unsuitable because the >>> only interface between the BPA and the application-specific element >>> of the application agent is the BP service interface (BP, page 6); >>> however, submitting a bundle to the BPA to be processed as if it has >>> just be received from another node is not one of the services listed >>> as being offered as part of this interface (see section 3.3 of the >>> BP). >>> b. The administrative element is unsuitable because according >>> to the BP, the administrative element of an application agent >>> constructs and requests transmission of administrative records and >>> accepts delivery of and processes custody signals; it doesn't accept >>> delivery of arbitrary apdus. (This is why we originally defined >>> administrative records to be the mechanism for encapsulating > bundles- >>> so the administrative records could be delivered to the >>> administrative element of the application agent and dealt with by >>> them.) Something would have to be changed in the terminology and >>> conceptual model of the BP as currently written to enable the >>> encapsulating bundle to be delivered to an entity that can then >>> extract the one or more encapsulated bundles and provide these back >>> to the BPA to be processed as if they had just been received from >>> another node. >>> >>> Right now I think I prefer option 2. I would like to understand how >>> much opposition there is to this option (if any) and I welcome any >>> other comments/ideas folks might have. >>> >>> If you've read this far, thanks. If you respond, even more thanks. >>> >>> -susan >>> ***************************************************************** >>> Susan Symington >>> The MITRE Corporation >>> susan@mitre.org >>> 703-983-7209 (voice) >>> 703-983-7142 (fax) >>> ****************************************************************** >>> >> >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@maillists.intel-research.net >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest -- Ignacio Solis - Member of Research Staff - PARC - isolis@parc.com GPG KEY: 523B5BCA | 1940 66A8 45B2 5504 8109 85A1 8976 554A 523B 5BCA Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9NFZxUF006325 for ; Thu, 23 Oct 2008 08:35:59 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m9NFRqOu022167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 10:28:02 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m9NFRprD016850; Thu, 23 Oct 2008 08:27:51 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m9NFRldw016692; Thu, 23 Oct 2008 08:27:51 -0700 (PDT) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Oct 2008 08:27:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Oct 2008 08:27:50 -0700 Message-ID: <8C7C41A176AC0B468BEFB2EFD9BDAB99062F098B@XCH-NW-5V2.nw.nos.boeing.com> In-Reply-To: <53B52415C756A84E8A169F0E3673A329018C083B@IMCSRV6.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-interest] Oasys won't configure Thread-Index: AckqQqvrV0DPYgAIR32VrmNk0xGRjQGNuIowASqISyA= References: <8C7C41A176AC0B468BEFB2EFD9BDAB990620D876@XCH-NW-5V2.nw.nos.boeing.com> <53B52415C756A84E8A169F0E3673A329018C083B@IMCSRV6.MITRE.ORG> From: "Duke, Martin" To: "Andresen, Jason R." , X-OriginalArrivalTime: 23 Oct 2008 15:27:51.0854 (UTC) FILETIME=[E9BF84E0:01C93523] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16234.003 X-TM-AS-Result: No--45.029900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id m9NFZxUF006325 Subject: Re: [dtn-interest] Oasys won't configure X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 15:36:00 -0000 For the record, I was able to get it to work on FreeBSD with the following steps: 1) Typing "aclocal" and "autoconf". 2) Changing the last line in the oasys configure file from 'make' to 'gmake'. 3) Applying the 4 patches to oasys and dtn from the sourceforge site. 4) Using 'gmake' instead of 'make' after the configure ran. Martin > -----Original Message----- > From: Andresen, Jason R. [mailto:jandrese@mitre.org] > Sent: Friday, October 17, 2008 10:02 AM > To: Duke, Martin; dtn-interest@mailman.dtnrg.org > Subject: RE: [dtn-interest] Oasys won't configure > > I had the same problem on FreeBSD. The problem is that > configure is calling make instead of gmake, but it's assuming > that it has GNU make as "make", not BSD Make. > > The good news is that those errors are harmless. If you run > "gmake", you should be able to build both DTN and oasys. > However, you will run into one other compile error later on. > In one of the files (I forget which), there is a reference to > a size_t (or something similar) without the corresponding > header included. If you just try to include the header by > hand, the build will blow up, but if you search and replace > all of those "size_t" instances in the one file with "int", > the build goes through and the bundle daemon seems to work > normally. I have not been able to track down the proper fix > for that yet, so there is no patch. Sorry. > > >-----Original Message----- > >From: dtn-interest-bounces@maillists.intel-research.net [mailto:dtn- > >interest-bounces@maillists.intel-research.net] On Behalf Of Duke, > Martin > >Sent: Thursday, October 09, 2008 3:10 PM > >To: dtn-interest@mailman.dtnrg.org > >Subject: [dtn-interest] Oasys won't configure > > > >I've downloaded dtn-2.6.0 and oasys-1.3.0 from the DTN sourceforge > site. > > > >I unzipped them into parallel directories, with BerkeleyDB 4.7.25 > >installed on my FreeBSD 7.0 system. > > > >I then typed > >cd oasys-1.3.0 > >./configure --with-dbver=4.7 > > > >And after a while I get this: > > > >"Makefile", line 209: Missing dependency operator > "Makefile", line 212: > >Need an operator "Rules.make", line 124: warning: duplicate > script for > >target "%.o" > >ignored > >"Rules.make", line 125: warning: duplicate script for target "%.o" > >ignored > >"Rules.make", line 135: warning: duplicate script for target "%.E" > >ignored > >"Rules.make", line 136: warning: duplicate script for target "%.E" > >ignored > >"Rules.make", line 148: Missing dependency operator > "Rules.make", line > >150: Need an operator "Rules.make", line 153: Missing dependency > >operator "Rules.make", line 154: Missing dependency operator > >"Rules.make", line 155: Need an operator "Makefile", line > 243: Missing > >dependency operator "Makefile", line 247: Need an operator > "Makefile", > >line 274: Need an operator "Makefile", line 275: Need an operator > >"Makefile", line 276: Need an operator "Makefile", line 277: Need an > >operator "Makefile", line 472: Need an operator "Makefile", > line 474: > >Need an operator "Makefile", line 479: Need an operator > >make: fatal errors encountered -- cannot continue > > > >Am I using the wrong distribution? Is there a configuration flag I > >should be using? > > > >Thanks! > >Martin > > > >All the other output listed below (preceeding the above): > > > >[root@freebsd7 /home/core/dtn/oasys-1.3.0]# ./configure > --with-dbver=4.7 > >checking location of source directory... > >"/usr/home/core/dtn/oasys-1.3.0" > >checking location of build directory... > "/usr/home/core/dtn/oasys-1.3.0" > >checking for a C compiler (trying gcc gcc-4.1 gcc-4.0 gcc-3.4 > >gcc-3.3)... > >checking for gcc... gcc > >checking for C compiler default output file name... a.out checking > >whether the C compiler works... yes checking whether we are cross > >compiling... no checking for suffix of executables... > >checking for suffix of object files... o checking whether we > are using > >the GNU C compiler... yes checking whether gcc accepts -g... yes > >checking for gcc option to accept ISO C89... none needed > checking for a > >C++ compiler (trying g++ g++-4.0 g++-4.0 g++-3.4 > >g++-3.3)... > >checking for g++... g++ > >checking whether we are using the GNU C++ compiler... yes checking > >whether g++ accepts -g... yes checking whether the C++ compiler > >works... yes checking how to run the C preprocessor... gcc > -E checking > >for the version of the GNU C compiler... 4.2.1 checking for > the version > >of the GNU C++ compiler... 4.2.1 checking for ar... ar checking for > >ranlib... ranlib checking whether to compile with debugging... yes > >checking whether to compile with memory debugging... no checking > >whether to compile with lock debugging (default yes)... yes checking > >whether to compile with optimization... no checking whether > to compile > >with profiling... no checking whether to link statically... > no checking > >whether to link using static external libraries... no > checking whether > >to try to build shared libraries... yes checking whether the > compiler > >supports -fPIC... yes checking whether the compiler can link > a dynamic > >library with > -shared... > >yes > >checking extension for dynamic libraries... so checking if > the compiler > >supports -Wl,--rpath=.... yes checking for grep that handles > long lines > >and -e... /usr/bin/grep checking for egrep... /usr/bin/grep > -E checking > >for sys/types.h... yes checking for sys/stat.h... yes checking for > >stdlib.h... yes checking for string.h... yes checking for > memory.h... > >yes checking for strings.h... yes checking for inttypes.h... yes > >checking for stdint.h... yes checking for unistd.h... yes > checking for > >gawk... no checking for mawk... no checking for nawk... nawk > checking > >for a BSD-compatible install... /usr/bin/install -c checking whether > >make sets $(MAKE)... yes checking for ranlib... (cached) ranlib > >checking for library containing pthread_create... -lpthread checking > >for pthread_yield... yes checking for library containing > >pthread_setspecific... none required checking for library containing > >socket... none required checking for library containing > >gethostbyname... none required checking for library containing > >xdr_int... none required checking for ANSI C header files... yes > >checking err.h usability... yes checking err.h presence... > yes checking > >for err.h... yes checking execinfo.h usability... no checking > >execinfo.h presence... no checking for execinfo.h... no checking for > >stdint.h... (cached) yes checking for string.h... (cached) > yes checking > >synch.h usability... no checking synch.h presence... no checking for > >synch.h... no checking sys/cdefs.h usability... yes checking > >sys/cdefs.h presence... yes checking for sys/cdefs.h... yes checking > >for sys/types.h... (cached) yes checking for an ANSI C-conforming > >const... yes checking for inline... inline checking for working > >volatile... yes checking for mode_t... yes checking value for > >_FILE_OFFSET_BITS preprocessor symbol... 64 checking for > off_t... yes > >checking size of off_t... 8 checking return type of signal > handlers... > >void checking for size_t... yes checking for ptrdiff_t... > yes checking > >for uint32_t... yes checking for u_int32_t... yes checking for > >fdatasync... no checking for getaddrinfo... yes checking for > >gethostbyname... yes checking for gethostbyname_r... yes > checking for > >getopt_long... yes checking for inet_aton... yes checking for > >inet_pton... yes checking for pthread_yield... (cached) yes checking > >for sched_yield... yes checking whether to compile with non-atomic > >"atomic" routines... no checking whether to compile with > assembly-based > >atomic functions... > yes > >checking for --with-python... no > >checking for python... /usr/local/bin/python checking whether python > >distutils can build an extension module... yes checking for library > >containing pow... -lm checking for library containing dlopen... none > >required > > > >configure: checking for tcl installation (version 8.4) checking for > >tcl.h (version 8.4) in /usr/include... no checking for tcl.h > (version > >8.4) in /usr/local/include... no checking for tcl.h (version 8.4) in > >/usr/include/tcl8.4... no checking for tcl.h (version 8.4) in > >/usr/local/include/tcl8.4... yes checking for tcl library in > /usr/lib: > >-ltcl8.4 ... no checking for tcl library in /usr/lib: -ltcl84 ... no > >checking for tcl library in /usr/lib: -ltcl ... no checking for tcl > >library in /usr/local/lib: -ltcl8.4 ... no checking for tcl > library in > >/usr/local/lib: -ltcl84 ... yes checking whether to compile > with google > >profiling... no checking whether bluetooth support should be > enabled... > >try checking for library containing baswap... no checking > >bluetooth/bluetooth.h usability... no checking bluetooth/bluetooth.h > >presence... no checking for bluetooth/bluetooth.h... no checking > >whether bluetooth support was found... no checking whether expat > >support should be enabled... try checking for expat in /usr/include, > >/usr/lib, -lexpat... no checking for expat in /usr/include, > >/usr/local/lib, -lexpat... no checking for expat in > /usr/local/include, > >/usr/lib, -lexpat... yes checking whether libexpat was found... yes > >checking whether xerces-c support should be enabled... try checking > >whether xerces-c (>= v2.6.0) was found... no checking whether > >tclreadline support should be enabled... try checking for library > >containing readline... -lreadline checking whether readline is GNU > >readline or BSD editline... editline checking whether tclreadline > >support was found... yes checking whether zlib support should be > >enabled... try checking for library containing compress... > -lz checking > >for library containing compressBound... none required > checking whether > >zlib support was found... yes checking for xsd... xsd checking for > >Berkeley DB header (version 4.7) in /usr/include... no checking for > >Berkeley DB header (version 4.7) in /usr/local/include... > >no > >checking for Berkeley DB header (version 4.7) in > >/usr/local/include/db4.7... no checking for Berkeley DB > header (version > >4.7) in /usr/local/include/db4... no checking for Berkeley DB header > >(version 4.7) in /usr/local/include/db47... no checking for > Berkeley DB > >header (version 4.7) in /usr/local/BerkeleyDB.4.7/include... yes > >checking for Berkeley DB library in /usr/local/BerkeleyDB.4.7/lib, > >-ldb-4.7... yes > >configure: creating ./config.status > >config.status: creating Rules.make > >config.status: creating System.make > >config.status: creating oasys-config.h > >config.status: oasys-config.h is unchanged > > > >_______________________________________________ > >dtn-interest mailing list > >dtn-interest@maillists.intel-research.net > >http://maillists.intel-research.net/mailman/listinfo/dtn-interest > Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9N2csvc002975 for ; Wed, 22 Oct 2008 19:38:55 -0700 Received: from [13.2.117.234] ([13.2.117.234]) by alpha.xerox.com with SMTP id <387650(2)>; Wed, 22 Oct 2008 19:31:04 PDT Message-ID: <48FFE1E8.5000201@parc.com> Date: Wed, 22 Oct 2008 19:31:04 PDT From: Ignacio Solis User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: "dtn-interest@mailman.dtnrg.org" References: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> <711FB52C-F272-4A12-B041-51A2E5920283@parc.com> <48FFCA82.90500@jpl.nasa.gov> In-Reply-To: <48FFCA82.90500@jpl.nasa.gov> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 02:38:55 -0000 Scott Burleigh wrote: > Ignacio Solis wrote: >> Hi all. >> >> I just want to make a meta comment. As a disclaimer, I feel biased >> towards content-centricity. >> >> It seems to me that what we're trying to solve with the BiB is an >> inherent flaw in the design of DTN. Basically, DTN ties down the way >> we transport the data with the data/meta information. >> Now we're having problems because due to "integrity-protection" we >> can't transfer the bundle the way we need to. To solve this problem, >> we are designing a bundle protocol to move bundles. >> >> This might be why I'm trying to design our DTN content approach as, >> basically, an overlay over DTN. DTN is used as a way to move the >> content around, but the content is by nature, self-contained. >> >> In this instance, we're trying to treat the bundle as self-contained, >> but still want it to be flexible enough to be moved around, and for >> this we're designing a new protocol. >> >> If this discussion (I don't mean my ideas, I mean the main thread) >> leads to a good BiB protocol, wouldn't we gravitate towards using the >> BiB protocol more than the normal Bundle protocol? After all, it will >> be more "flexible". >> > I doubt it, Nacho. I can't think of any operational scenario in the > work I'm doing where that flexibility would be useful. It seems to me > that there are better ways of achieving all the same objectives without it. > > Can you say some more about what you mean when you say "DTN ties down > the way we transport the data with the data/meta information"? Is what > Susan is proposing really that different from any other sort of > tunneling? Why isn't the content of a bundle already "self-contained"? > What's an example of a case where the design of DTN makes it impossible > to transfer the bundle the way we need to? Maybe I read things wrong. It's what I got from the description in Susan's email: "If we change the destination EID of this bundle, it can be sent to only the new member (as desired), but the bundles integrity check will fail." This seems to imply to me that the way we check for integrity includes checking the destination EID. And, because this is the destination we use for forwarding/actual delivery, we can't change it without affecting the integrity check. So (please correct me if I'm wrong): An application wants to send a bundle. It gives this bundle some EIDs (source, dest, etc) and payload. And it expects these to be delivered to the destination application. The destination can then check who it is from, who it was for, etc. This is, in a sense, meta-information about the payload. There is an association that exists between the payload and those EIDs. My comment was that the forwarding/routing/storing/caching/delivery engine, relies on those fields. So if the forwarding, or routing, or caching needs to change those fields, it can't. I'm not proposing to break the association the application has made. What I wish we had is a way to use our own "internal" fields (which could be potentially initialized to the same value), so that we are free to change them. This kind of sounds ridiculous. And partially I'm glancing over things, like "why would we limit the association the application is making to the EID format?", "why are we duplicating EIDs?" "are you talking about EIDs or tags/meta data"? Maybe I see every problem as a nail since I want to sell my hammer. Having said that, I think Bundle-in-Bundle is a really good thing given the system we're working in. It gives the BPA the freedom to move bundles around without affecting what the application thought was static. Maybe I'm just projecting what I wish was more like "Content-in-Bundle". Where I (as the content-routing/storing/forwarding engine) could move things around freely (bundles), while treating the Content as a read-only chunk that doesn't dictate my operation. Nacho PS. I have read the RFC and drafts, but I don't remember every detail, so maybe I'm generalizing a problem that doesn't actually exist (or is very specific to me). -- Ignacio Solis - Member of Research Staff - PARC - isolis@parc.com GPG KEY: 523B5BCA | 1940 66A8 45B2 5504 8109 85A1 8976 554A 523B 5BCA Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9N0wsDZ030811 for ; Wed, 22 Oct 2008 17:58:54 -0700 Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id m9N0pHaj024952 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Thu, 23 Oct 2008 00:51:17 GMT Received: from [127.0.0.1] (dhcp-79-22-229.jpl.nasa.gov [137.79.22.229]) by xmta3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9N0pEFc011787 for ; Wed, 22 Oct 2008 17:51:15 -0700 Message-ID: <48FFCA82.90500@jpl.nasa.gov> Date: Wed, 22 Oct 2008 17:51:14 -0700 From: Scott Burleigh User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org References: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> <711FB52C-F272-4A12-B041-51A2E5920283@parc.com> In-Reply-To: <711FB52C-F272-4A12-B041-51A2E5920283@parc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: dhcp-79-22-229.jpl.nasa.gov [137.79.22.229] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Authorized X-AUTH: Authorized Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 00:58:54 -0000 Ignacio Solis wrote: > Hi all. > > I just want to make a meta comment. As a disclaimer, I feel biased > towards content-centricity. > > It seems to me that what we're trying to solve with the BiB is an > inherent flaw in the design of DTN. Basically, DTN ties down the way > we transport the data with the data/meta information. > Now we're having problems because due to "integrity-protection" we > can't transfer the bundle the way we need to. To solve this problem, > we are designing a bundle protocol to move bundles. > > This might be why I'm trying to design our DTN content approach as, > basically, an overlay over DTN. DTN is used as a way to move the > content around, but the content is by nature, self-contained. > > In this instance, we're trying to treat the bundle as self-contained, > but still want it to be flexible enough to be moved around, and for > this we're designing a new protocol. > > If this discussion (I don't mean my ideas, I mean the main thread) > leads to a good BiB protocol, wouldn't we gravitate towards using the > BiB protocol more than the normal Bundle protocol? After all, it will > be more "flexible". > I doubt it, Nacho. I can't think of any operational scenario in the work I'm doing where that flexibility would be useful. It seems to me that there are better ways of achieving all the same objectives without it. Can you say some more about what you mean when you say "DTN ties down the way we transport the data with the data/meta information"? Is what Susan is proposing really that different from any other sort of tunneling? Why isn't the content of a bundle already "self-contained"? What's an example of a case where the design of DTN makes it impossible to transfer the bundle the way we need to? Scott Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9N0vhI4030733 for ; Wed, 22 Oct 2008 17:57:44 -0700 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9N0o8bk032299 for ; Wed, 22 Oct 2008 20:50:08 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9N0o7Dt032288; Wed, 22 Oct 2008 20:50:07 -0400 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 20:50:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C934A9.4B235E6C" Date: Wed, 22 Oct 2008 20:50:06 -0400 Message-ID: <8E507634779E22488719233DB3DF9FF002F86303@IMCSRV4.MITRE.ORG> In-Reply-To: <48FFC6E9.3070507@jpl.nasa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-interest] Bundle-in-Bundle Encapsulation Issue Thread-Index: Ack0p8EvPKkwuSZrQt67H1vgD7Z/RwAAQ50w References: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> <48FFC6E9.3070507@jpl.nasa.gov> From: "Symington, Susan F." To: "Scott Burleigh" , X-OriginalArrivalTime: 23 Oct 2008 00:50:07.0622 (UTC) FILETIME=[4B6B7260:01C934A9] Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 00:57:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C934A9.4B235E6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Scott. It's good news to learn that you don't see a problem reconciling option 3 with the current conceptual model and terminology in the BP. =20 -susan ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** From: dtn-interest-bounces@maillists.intel-research.net [mailto:dtn-interest-bounces@maillists.intel-research.net] On Behalf Of Scott Burleigh Sent: Wednesday, October 22, 2008 8:36 PM To: dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue =20 Symington, Susan F. wrote:=20 All, =20 Peter Lovell has pointed out an issue with DTN Bundle-in-Bundle (BiB) Encapsulation. There are several options for how to address this issue, and I would like to get a feel for the DTN community's preferences. =20 First of all, why do we want an encapsulation capability? Here is an example of when BiB Encapsulation is handy: suppose a DTN cache has some bundles stored on it. One of the bundles has a multicast address as its destination EID and this bundle is integrity-protected using a PIB. A new member joins the multicast group. We would like to be able to send this new member the bundle. If we simple send out the bundle as it is found in the cache, it is going to go to all group members. If we change the destination EID of this bundle, it can be sent to only the new member (as desired), but the bundles integrity check will fail. Instead, we'd like to be able to encapsulate this bundle so the encapsulating bundle can be addressed directly to the new member only.=20 =20 Secondly, what is the problem that Peter has pointed out with the way BiB encapsulation is now defined in draft-irtf-dtnrg-bundle-encapsulation-03? The problem has to do with using an administrative record as the mechanism to encapsulate bundles. According to the Bundle Protocol, if a bundle is carrying an administrative record, the bundle cannot have its custody transfer requested bit set. This means that if the original bundle that is sent has its custody transfer bit set and then this bundle is encapsulated (by being placed in an administrative record that is carried by an encapsulating bundle), no node can take custody of the encapsulating bundle as it travels through the network. Only after the original bundle is de-encapsulated can a node take custody of the original de-encapsulated bundle. The whole time the bundle is in the encapsulation "tunnel", the encapsulating bundle cannot be taken custody of. In terms of the example use of BiB encapsulation given above, there would be no way to take a bundle from a DTN cache, encapsulate it in another bundle, and send this new bundle to a newly joining group member custodially.=20 =20 There seem to be three options for addressing this: Do nothing. Leave the BiB Encapsulation I-D as written and live with the fact that encapsulating bundles cannot be sent custodially. Change the rule in section 4.2 (page 15) of the Bundle Protocol Specification (RFC 5050) to enable bundles whose application data unit is an administrative record of type BiB Encapsulation to have a custody transfer requested flag of 1. Rewrite the BiB Encapsulation I-D to perform encapsulation using an extension block instead of an administrative record. The extension block would indicate that the payload of the bundle contains one or more encapsulated bundles (and it could also provide their offsets). The payload of the bundle would contain the actual encapsulated bundles. (We want the encapsulated bundle(s) to be in the payload and not in an extension block to allow for fragmentation.) Some changes to the conceptual model and terminology now used in the Bundle Protocol (BP) would be required in order to be able to define encapsulation in this manner. As defined now, the BP requires that when a bundle reaches a bundle node that is a member of the bundle's destination endpoint, the bundle must be delivered (section 5.7 of the BP, step2). Delivery means that the bundles' application data unit (apdu), which consists of one or more encapsulated bundles (along with any offset information if more than one bundle has been encapsulated), would have to be presented to the node's application agent (section 3.1 of the BP, page 6). In the case of encapsulation, this application agent would in turn have to take each of these bundles and hand them back to the bundle protocol agent, in order, to each be processed as if they had just been received from another node (as described in section 5.6 of the BP). Where this doesn't exactly fit in now with the terminology and conceptual model used in the BP is that the application agent, to which the apdu is presented as part of the delivery process, consists of two elements: an administrative element, and an application-specific element. Neither of these two elements, as currently defined in the BP, seems capable of handling the apdu of encapsulated bundles as desired.=20 The application-specific element is unsuitable because the only interface between the BPA and the application-specific element of the application agent is the BP service interface (BP, page 6); however, submitting a bundle to the BPA to be processed as if it has just be received from another node is not one of the services listed as being offered as part of this interface (see section 3.3 of the BP). I don't see any obstacle here, Susan. "Delivering a received bundle" is one of the expected services. What the application-specific element of the application agent does with a delivered bundle is wholly an implementation matter. I can easily imagine, for instance, an endpoint ID convention that enables the destination endpoint to be specified somehow as "BiB handler". When the bundle is delivered to that endpoint, the application-specific element of the application agent deals with it by processing it as if it had been delivered by another node. Speaking just for myself, I also don't yet see this capability as being especially useful. I think we tend to do too much within "bundling" already and would be better served by leaving some capabilities to other, well, layers. But if we really want to do this, I think some sort of extension block scheme would be the cleaner approach. Scott The administrative element is unsuitable because according to the BP, the administrative element of an application agent constructs and requests transmission of administrative records and accepts delivery of and processes custody signals; it doesn't accept delivery of arbitrary apdus. (This is why we originally defined administrative records to be the mechanism for encapsulating bundles-so the administrative records could be delivered to the administrative element of the application agent and dealt with by them.) Something would have to be changed in the terminology and conceptual model of the BP as currently written to enable the encapsulating bundle to be delivered to an entity that can then extract the one or more encapsulated bundles and provide these back to the BPA to be processed as if they had just been received from another node.=20 ------_=_NextPart_001_01C934A9.4B235E6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Scott. = It’s good news to learn that you don’t see a problem reconciling option 3 with the = current conceptual model and terminology in the BP.

-susan

**********************************************************= *******

Susan Symington

The MITRE Corporation

susan@mitre.org

703-983-7209 (voice)

703-983-7142 (fax)

**********************************************************= ********

From: = dtn-interest-bounces@maillists.intel-research.net [mailto:dtn-interest-bounces@maillists.intel-research.net] On Behalf = Of Scott Burleigh
Sent: Wednesday, October 22, 2008 8:36 PM
To: dtn-interest@mailman.dtnrg.org
Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation = Issue

Symington, Susan F. wrote:

All,

Peter Lovell has pointed out an issue with DTN Bundle-in-Bundle (BiB) Encapsulation. There are several options for how = to address this issue, and I would like to get a feel for the DTN = community’s preferences.

First of all, why do we want an encapsulation = capability? Here is an example of when BiB Encapsulation is handy: suppose a DTN = cache has some bundles stored on it. One of the bundles has a multicast address as = its destination EID and this bundle is integrity-protected using a PIB. A = new member joins the multicast group. We would like to be able to send this = new member the bundle. If we simple send out the bundle as it is found in = the cache, it is going to go to all group members. If we change the = destination EID of this bundle, it can be sent to only the new member (as desired), but = the bundles integrity check will fail. Instead, we’d like to be able = to encapsulate this bundle so the encapsulating bundle can be addressed directly to the = new member only.

Secondly, what is the problem that Peter has = pointed out with the way BiB encapsulation is now defined in draft-irtf-dtnrg-bundle-encapsulation-03? The problem has to do with = using an administrative record as the mechanism to encapsulate bundles. According to the Bundle Protocol, if a bundle is carrying an administrative record, the bundle cannot have its custody transfer = requested bit set. This means that if the original bundle that is sent has its = custody transfer bit set and then this bundle is encapsulated (by being placed = in an administrative record that is carried by an encapsulating bundle), no = node can take custody of the encapsulating bundle as it travels through the = network. Only after the original bundle is de-encapsulated can a node take = custody of the original de-encapsulated bundle. The whole time the bundle is = in the encapsulation “tunnel”, the encapsulating bundle cannot be = taken custody of. In terms of the example use of BiB encapsulation given above, = there would be no way to take a bundle from a DTN cache, encapsulate it in another = bundle, and send this new bundle to a newly joining group member custodially. =

There seem to be three options for addressing = this:

Do nothing. = Leave the BiB Encapsulation I-D as written and live with the fact that encapsulating = bundles cannot be sent custodially.

Change the rule = in section 4.2 (page 15) of the Bundle Protocol Specification (RFC 5050) to enable = bundles whose application data unit is an administrative record of type BiB = Encapsulation to have a custody transfer requested flag of 1.

Rewrite the BiB Encapsulation I-D to perform encapsulation using an extension block = instead of an administrative record. The extension block would indicate that the = payload of the bundle contains one or more encapsulated bundles (and it could = also provide their offsets). The payload of the bundle would contain the = actual encapsulated bundles. (We want the encapsulated bundle(s) to be in the = payload and not in an extension block to allow for fragmentation.) Some changes = to the conceptual model and terminology now used in the Bundle Protocol (BP) = would be required in order to be able to define encapsulation in this manner. As = defined now, the BP requires that when a bundle reaches a bundle node that is a = member of the bundle’s destination endpoint, the bundle must be delivered = (section 5.7 of the BP, step2). Delivery means that the bundles’ application = data unit (apdu), which consists of one or more encapsulated bundles (along with = any offset information if more than one bundle has been encapsulated), would = have to be presented to the node’s application agent (section 3.1 of = the BP, page 6). In the case of encapsulation, this application agent would in turn = have to take each of these bundles and hand them back to the bundle protocol = agent, in order, to each be processed as if they had just been received from = another node (as described in section 5.6 of the BP). Where this doesn’t = exactly fit in now with the terminology and conceptual model used in the BP is that the application agent, to which the apdu is presented as part of the = delivery process, consists of two elements: an administrative element, and = an application-specific element. Neither of these two elements, as = currently defined in the BP, seems capable of handling the apdu of encapsulated = bundles as desired.

The application-specific element is unsuitable because the only interface = between the BPA and the application-specific element of the application agent is = the BP service interface (BP, page 6); however, submitting a bundle to the BPA = to be processed as if it has just be received from another node is not one of = the services listed as being offered as part of this interface (see section = 3.3 of the BP).

I don't see any obstacle here, Susan. "Delivering a received bundle" is one of the expected services. What the application-specific element of the application agent does with a = delivered bundle is wholly an implementation matter. I can easily imagine, = for instance, an endpoint ID convention that enables the destination = endpoint to be specified somehow as "BiB handler". When the bundle is delivered to that endpoint, the application-specific element of the = application agent deals with it by processing it as if it had been delivered by = another node.

Speaking just for myself, I also don't yet see this capability as being especially useful. I think we tend to do too much within "bundling" already and would be better served by leaving some capabilities to other, well, layers. But if we really want to do = this, I think some sort of extension block scheme would be the cleaner = approach.

Scott

The administrative element is unsuitable because according to the BP, the administrative element of an application agent constructs and = requests transmission of administrative records and accepts delivery of and = processes custody signals; it doesn’t accept delivery of arbitrary apdus. = (This is why we originally defined administrative records to be the mechanism for = encapsulating bundles—so the administrative records could be delivered to the = administrative element of the application agent and dealt with by them.) Something = would have to be changed in the terminology and conceptual model of the BP as = currently written to enable the encapsulating bundle to be delivered to an entity = that can then extract the one or more encapsulated bundles and provide these = back to the BPA to be processed as if they had just been received from another = node.

------_=_NextPart_001_01C934A9.4B235E6C-- Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9N0quKK030493 for ; Wed, 22 Oct 2008 17:52:56 -0700 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9N0jKGB020541 for ; Wed, 22 Oct 2008 20:45:20 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9N0jKEg020527; Wed, 22 Oct 2008 20:45:20 -0400 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 20:45:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Oct 2008 20:45:18 -0400 Message-ID: <8E507634779E22488719233DB3DF9FF002F86302@IMCSRV4.MITRE.ORG> In-Reply-To: <711FB52C-F272-4A12-B041-51A2E5920283@parc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-interest] Bundle-in-Bundle Encapsulation Issue Thread-Index: Ack0lHRKA/+KF6DBT6iXpYHksM7E6AAB1a0g References: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> <711FB52C-F272-4A12-B041-51A2E5920283@parc.com> From: "Symington, Susan F." To: "Ignacio Solis" , X-OriginalArrivalTime: 23 Oct 2008 00:45:20.0417 (UTC) FILETIME=[A03B7110:01C934A8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id m9N0quKK030493 Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 00:52:57 -0000 Nacho, It may be that we really don't need encapsulation or that encapsulation is a bad idea; I don't know. The situation that I identified (sending an integrity-protected bundle with a multicast EID from a DTN cache to a singleton endpoint) is one example of how encapsulation can be useful. A second situation that I have identified is in the DTN Custodial Multicast Extension draft (http://www.ietf.org/internet-drafts/draft-symington-dtnrg-bundle-multi cast-custodial-04.txt). In that example, a custodian receives a "Failed" custody signal for a multicast bundle from a specific downstream node, in which case the custodian wants to retransmit the multicast bundle to that downstream node. It may want to conserve bandwidth by encapsulating the multicast bundle in a singleton bundle for bandwidth-efficient transmission to the downstream node; this node can then de-encapsulate the multicast bundle and forward the multicast bundle further. There may be other uses of encapsulation as well--examples that are analogous to the ways that tunnels are used today in networks, but that remains to be seen. Maybe we want to avoid tunnels. If defining encapsulation really does just amount to defining another bundle protocol to move bundles, then it doesn't seem very appealing. I'm not sure I agree with you when you say that "what we're trying to solve with the BiB is an inherent flaw in the design of DTN". It may, however, be an inherent flaw in the integrity checksum ciphersuite as currently defined. The situation (of sending an integrity-protected multicast bundle to a singleton address) that we are trying to solve arises because the integrity checksum is calculated over the destination EID. If the integrity checksum were not calculated over the destination EID, then the multicast destination EID in the cached bundle could simply be replaced by the singleton destination to which we want to send the bundle, and the bundle could be sent to the singleton destination from the cache. Perhaps defining such a bundle integrity ciphersuite should be the solution that we focus on for that situation. Maybe bundles sent to multicast addresses should always use a (to be defined) integrity checksum that is not calculated over the destination EID whereas bundles sent to singleton EIDs may use either type of checksum. From a content-centric viewpoint, the destination to which the bundle is sent really is irrelevant, so why protect its integrity, especially when protecting its integrity restricts what you can usefully do with that bundle? What we need to protect is the content and whatever metadata is used to make the decision regarding the bundle's relevance. Perhaps we need an alternative integrity checksum that is defined for the content-centric data dissemination approach rather biased toward the source-to-destination "call" paradigm of transmission as the current one is. However, even if we define a new integrity checksum to deal with this situation, it still seems like encapsulation would be useful for the situation I identified in the custodial multicast draft. Will we really never want tunnels? I guess my response to you amounts to this: I'm open to your objections and I'd like to understand your ideas better. I am not a strong advocate of encapsulation per se; I just want a way to do the two things that I know encapsulation can enable me to do. I can see and have said how we might solve the first situation with a new integrity ciphersuite instead of encapsulation (though I don't know what objections others might raise to that), but I can't see how we'd solve the second situation (the situation from the custodial multicast extensions document). I wonder if others see additional situations in which they would like to use encapsulation. -susan ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** >-----Original Message----- >From: dtn-interest-bounces@maillists.intel-research.net [mailto:dtn- >interest-bounces@maillists.intel-research.net] On Behalf Of Ignacio >Solis >Sent: Wednesday, October 22, 2008 6:18 PM >To: dtn-interest@mailman.dtnrg.org >Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue > >Hi all. > >I just want to make a meta comment. As a disclaimer, I feel biased >towards content-centricity. > >It seems to me that what we're trying to solve with the BiB is an >inherent flaw in the design of DTN. Basically, DTN ties down the way >we transport the data with the data/meta information. >Now we're having problems because due to "integrity-protection" we >can't transfer the bundle the way we need to. To solve this problem, >we are designing a bundle protocol to move bundles. > >This might be why I'm trying to design our DTN content approach as, >basically, an overlay over DTN. DTN is used as a way to move the >content around, but the content is by nature, self-contained. > >In this instance, we're trying to treat the bundle as self-contained, >but still want it to be flexible enough to be moved around, and for >this we're designing a new protocol. > >If this discussion (I don't mean my ideas, I mean the main thread) >leads to a good BiB protocol, wouldn't we gravitate towards using the >BiB protocol more than the normal Bundle protocol? After all, it will >be more "flexible". > >I understand that a lot of work has been done on DTN, and I do realize >I might be speaking about impractical things, I just wanted to voice >my ideas publicly. > >Don't take me too seriously, > >Nacho > > > > >On Oct 21, 2008, at 12:37 PM, Symington, Susan F. wrote: >> Peter Lovell has pointed out an issue with DTN Bundle-in-Bundle >> (BiB) Encapsulation. There are several options for how to address >> this issue, and I would like to get a feel for the DTN community's >> preferences. >> >> First of all, why do we want an encapsulation capability? Here is an >> example of when BiB Encapsulation is handy: suppose a DTN cache has >> some bundles stored on it. One of the bundles has a multicast >> address as its destination EID and this bundle is integrity- >> protected using a PIB. A new member joins the multicast group. We >> would like to be able to send this new member the bundle. If we >> simple send out the bundle as it is found in the cache, it is going >> to go to all group members. If we change the destination EID of this >> bundle, it can be sent to only the new member (as desired), but the >> bundles integrity check will fail. Instead, we'd like to be able to >> encapsulate this bundle so the encapsulating bundle can be addressed >> directly to the new member only. >> >> Secondly, what is the problem that Peter has pointed out with the >> way BiB encapsulation is now defined in draft-irtf-dtnrg-bundle- >> encapsulation-03? The problem has to do with using an >> administrative record as the mechanism to encapsulate bundles. >> According to the Bundle Protocol, if a bundle is carrying an >> administrative record, the bundle cannot have its custody transfer >> requested bit set. This means that if the original bundle that is >> sent has its custody transfer bit set and then this bundle is >> encapsulated (by being placed in an administrative record that is >> carried by an encapsulating bundle), no node can take custody of the >> encapsulating bundle as it travels through the network. Only after >> the original bundle is de-encapsulated can a node take custody of >> the original de-encapsulated bundle. The whole time the bundle is >> in the encapsulation "tunnel", the encapsulating bundle cannot be >> taken custody of. In terms of the example use of BiB encapsulation >> given above, there would be no way to take a bundle from a DTN >> cache, encapsulate it in another bundle, and send this new bundle to >> a newly joining group member custodially. >> >> There seem to be three options for addressing this: >> 1. Do nothing. Leave the BiB Encapsulation I-D as written and >> live with the fact that encapsulating bundles cannot be sent >> custodially. >> 2. Change the rule in section 4.2 (page 15) of the Bundle >> Protocol Specification (RFC 5050) to enable bundles whose >> application data unit is an administrative record of type BiB >> Encapsulation to have a custody transfer requested flag of 1. >> 3. Rewrite the BiB Encapsulation I-D to perform encapsulation >> using an extension block instead of an administrative record. The >> extension block would indicate that the payload of the bundle >> contains one or more encapsulated bundles (and it could also provide >> their offsets). The payload of the bundle would contain the actual >> encapsulated bundles. (We want the encapsulated bundle(s) to be in >> the payload and not in an extension block to allow for >> fragmentation.) Some changes to the conceptual model and terminology >> now used in the Bundle Protocol (BP) would be required in order to >> be able to define encapsulation in this manner. As defined now, the >> BP requires that when a bundle reaches a bundle node that is a >> member of the bundle's destination endpoint, the bundle must be >> delivered (section 5.7 of the BP, step2). Delivery means that the >> bundles' application data unit (apdu), which consists of one or more >> encapsulated bundles (along with any offset information if more than >> one bundle has been encapsulated), would have to be presented to the >> node's application agent (section 3.1 of the BP, page 6). In the >> case of encapsulation, this application agent would in turn have to >> take each of these bundles and hand them back to the bundle protocol >> agent, in order, to each be processed as if they had just been >> received from another node (as described in section 5.6 of the BP). >> Where this doesn't exactly fit in now with the terminology and >> conceptual model used in the BP is that the application agent, to >> which the apdu is presented as part of the delivery process, >> consists of two elements: an administrative element, and an >> application-specific element. Neither of these two elements, as >> currently defined in the BP, seems capable of handling the apdu of >> encapsulated bundles as desired. >> a. The application-specific element is unsuitable because the >> only interface between the BPA and the application-specific element >> of the application agent is the BP service interface (BP, page 6); >> however, submitting a bundle to the BPA to be processed as if it has >> just be received from another node is not one of the services listed >> as being offered as part of this interface (see section 3.3 of the >> BP). >> b. The administrative element is unsuitable because according >> to the BP, the administrative element of an application agent >> constructs and requests transmission of administrative records and >> accepts delivery of and processes custody signals; it doesn't accept >> delivery of arbitrary apdus. (This is why we originally defined >> administrative records to be the mechanism for encapsulating bundles- >> so the administrative records could be delivered to the >> administrative element of the application agent and dealt with by >> them.) Something would have to be changed in the terminology and >> conceptual model of the BP as currently written to enable the >> encapsulating bundle to be delivered to an entity that can then >> extract the one or more encapsulated bundles and provide these back >> to the BPA to be processed as if they had just been received from >> another node. >> >> Right now I think I prefer option 2. I would like to understand how >> much opposition there is to this option (if any) and I welcome any >> other comments/ideas folks might have. >> >> If you've read this far, thanks. If you respond, even more thanks. >> >> -susan >> ***************************************************************** >> Susan Symington >> The MITRE Corporation >> susan@mitre.org >> 703-983-7209 (voice) >> 703-983-7142 (fax) >> ****************************************************************** >> > > >_______________________________________________ >dtn-interest mailing list >dtn-interest@maillists.intel-research.net >http://maillists.intel-research.net/mailman/listinfo/dtn-interest Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9N0m9rh030281 for ; Wed, 22 Oct 2008 17:48:09 -0700 Received: from xmta2.jpl.nasa.gov (xmta2.jpl.nasa.gov [137.78.160.56]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id m9N0eWI3032049 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Thu, 23 Oct 2008 00:40:32 GMT Received: from [127.0.0.1] (dhcp-79-22-229.jpl.nasa.gov [137.79.22.229]) by xmta2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9N0eUM9003296 for ; Wed, 22 Oct 2008 17:40:30 -0700 Message-ID: <48FFC7FE.6090409@jpl.nasa.gov> Date: Wed, 22 Oct 2008 17:40:30 -0700 From: Scott Burleigh User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org References: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> <48FE3928.1040509@cs.tcd.ie> In-Reply-To: <48FE3928.1040509@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: dhcp-79-22-229.jpl.nasa.gov [137.79.22.229] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Authorized X-AUTH: Authorized Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 00:48:09 -0000 Stephen Farrell wrote: > Hi Susan, > > (How come you get to explain all the hard-to-explain things? ;-) > > I think I'd rather explore option 3. And isn't the interface > spec part of rfc 5050 optional or am I mis-remembering? If > its optional, then non-conformance with an optional API > doesn't seem to be a big deal - a different API for tunnel > endpoints would seem reasonable anyway. (Though I don't > care very much if we define one or not.) > Stephen, no worries: section 3.3 isn't an interface spec, it isn't an API, and it's not normative. It's just a list of "expected" services -- no MUSTs, no SHALLs. > I can imagine a bunch of wrinkles if custody can be turned > on for things like custody acks, so I'd rather not go down > the road of your option 2. > > I guess I'd agree that the current situation isn't very good > if bundles can't be taken into custody whilst inside tunnels. > So I suppose that means I don't like option 1 either. > I agree on both counts. Scott Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9N0hYX0030004 for ; Wed, 22 Oct 2008 17:43:34 -0700 Received: from xmta2.jpl.nasa.gov (xmta2.jpl.nasa.gov [137.78.160.56]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id m9N0Zuxl029214 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Thu, 23 Oct 2008 00:35:57 GMT Received: from [127.0.0.1] (dhcp-79-22-229.jpl.nasa.gov [137.79.22.229]) by xmta2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9N0ZsRR002018 for ; Wed, 22 Oct 2008 17:35:55 -0700 Message-ID: <48FFC6E9.3070507@jpl.nasa.gov> Date: Wed, 22 Oct 2008 17:35:53 -0700 From: Scott Burleigh User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org References: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> In-Reply-To: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> Content-Type: multipart/alternative; boundary="------------050009020905040202090806" X-Source-IP: dhcp-79-22-229.jpl.nasa.gov [137.79.22.229] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Authorized X-AUTH: Authorized Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2008 00:43:35 -0000 This is a multi-part message in MIME format. --------------050009020905040202090806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Symington, Susan F. wrote: > > All, > > > > Peter Lovell has pointed out an issue with DTN Bundle-in-Bundle (BiB) > Encapsulation. There are several options for how to address this > issue, and I would like to get a feel for the DTN community's preferences. > > > > First of all, why do we want an encapsulation capability? Here is an > example of when BiB Encapsulation is handy: suppose a DTN cache has > some bundles stored on it. One of the bundles has a multicast address > as its destination EID and this bundle is integrity-protected using a > PIB. A new member joins the multicast group. We would like to be able > to send this new member the bundle. If we simple send out the bundle > as it is found in the cache, it is going to go to all group members. > If we change the destination EID of this bundle, it can be sent to > only the new member (as desired), but the bundles integrity check will > fail. Instead, we'd like to be able to encapsulate this bundle so the > encapsulating bundle can be addressed directly to the new member only. > > > > Secondly, what is the problem that Peter has pointed out with the way > BiB encapsulation is now defined in > draft-irtf-dtnrg-bundle-encapsulation-03? The problem has to do with > using an administrative record as the mechanism to encapsulate > bundles. According to the Bundle Protocol, if a bundle is carrying an > administrative record, the bundle cannot have its custody transfer > requested bit set. This means that if the original bundle that is sent > has its custody transfer bit set and then this bundle is encapsulated > (by being placed in an administrative record that is carried by an > encapsulating bundle), no node can take custody of the encapsulating > bundle as it travels through the network. Only after the original > bundle is de-encapsulated can a node take custody of the original > de-encapsulated bundle. The whole time the bundle is in the > encapsulation "tunnel", the encapsulating bundle cannot be taken > custody of. In terms of the example use of BiB encapsulation given > above, there would be no way to take a bundle from a DTN cache, > encapsulate it in another bundle, and send this new bundle to a newly > joining group member custodially. > > > > There seem to be three options for addressing this: > > 1. Do nothing. Leave the BiB Encapsulation I-D as written and > live with the fact that encapsulating bundles cannot be sent custodially. > > 2. Change the rule in section 4.2 (page 15) of the Bundle > Protocol Specification (RFC 5050) to enable bundles whose application > data unit is an administrative record of type BiB Encapsulation to > have a custody transfer requested flag of 1. > > 3. Rewrite the BiB Encapsulation I-D to perform encapsulation > using an extension block instead of an administrative record. The > extension block would indicate that the payload of the bundle contains > one or more encapsulated bundles (and it could also provide their > offsets). The payload of the bundle would contain the actual > encapsulated bundles. (We want the encapsulated bundle(s) to be in the > payload and not in an extension block to allow for fragmentation.) > Some changes to the conceptual model and terminology now used in the > Bundle Protocol (BP) would be required in order to be able to define > encapsulation in this manner. As defined now, the BP requires that > when a bundle reaches a bundle node that is a member of the bundle's > destination endpoint, the bundle must be delivered (section 5.7 of the > BP, step2). Delivery means that the bundles' application data unit > (apdu), which consists of one or more encapsulated bundles (along with > any offset information if more than one bundle has been encapsulated), > would have to be presented to the node's application agent (section > 3.1 of the BP, page 6). In the case of encapsulation, this application > agent would in turn have to take each of these bundles and hand them > back to the bundle protocol agent, in order, to each be processed as > if they had just been received from another node (as described in > section 5.6 of the BP). Where this doesn't exactly fit in now with the > terminology and conceptual model used in the BP is that the > application agent, to which the apdu is presented as part of the > delivery process, consists of two elements: an administrative > element, and an application-specific element. Neither of these two > elements, as currently defined in the BP, seems capable of handling > the apdu of encapsulated bundles as desired. > > a. The application-specific element is unsuitable because the > only interface between the BPA and the application-specific element of > the application agent is the BP service interface (BP, page 6); > however, submitting a bundle to the BPA to be processed as if it has > just be received from another node is not one of the services listed > as being offered as part of this interface (see section 3.3 of the BP). > I don't see any obstacle here, Susan. "Delivering a received bundle" is one of the expected services. What the application-specific element of the application agent does with a delivered bundle is wholly an implementation matter. I can easily imagine, for instance, an endpoint ID convention that enables the destination endpoint to be specified somehow as "BiB handler". When the bundle is delivered to that endpoint, the application-specific element of the application agent deals with it by processing it as if it had been delivered by another node. Speaking just for myself, I also don't yet see this capability as being especially useful. I think we tend to do too much within "bundling" already and would be better served by leaving some capabilities to other, well, layers. But if we really want to do this, I think some sort of extension block scheme would be the cleaner approach. Scott > > b. The administrative element is unsuitable because according to > the BP, the administrative element of an application agent constructs > and requests transmission of administrative records and accepts > delivery of and processes custody signals; it doesn't accept delivery > of arbitrary apdus. (This is why we originally defined administrative > records to be the mechanism for encapsulating bundles---so the > administrative records could be delivered to the administrative > element of the application agent and dealt with by them.) Something > would have to be changed in the terminology and conceptual model of > the BP as currently written to enable the encapsulating bundle to be > delivered to an entity that can then extract the one or more > encapsulated bundles and provide these back to the BPA to be processed > as if they had just been received from another node. > --------------050009020905040202090806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Symington, Susan F. wrote:

All,

Peter Lovell has pointed out an issue with DTN Bundle-in-Bundle (BiB) Encapsulation. There are several options for how to address this issue, and I would like to get a feel for the DTN community’s preferences.

First of all, why do we want an encapsulation capability? Here is an example of when BiB Encapsulation is handy: suppose a DTN cache has some bundles stored on it. One of the bundles has a multicast address as its destination EID and this bundle is integrity-protected using a PIB. A new member joins the multicast group. We would like to be able to send this new member the bundle. If we simple send out the bundle as it is found in the cache, it is going to go to all group members. If we change the destination EID of this bundle, it can be sent to only the new member (as desired), but the bundles integrity check will fail. Instead, we’d like to be able to encapsulate this bundle so the encapsulating bundle can be addressed directly to the new member only.

Secondly, what is the problem that Peter has pointed out with the way BiB encapsulation is now defined in draft-irtf-dtnrg-bundle-encapsulation-03? The problem has to do with using an administrative record as the mechanism to encapsulate bundles. According to the Bundle Protocol, if a bundle is carrying an administrative record, the bundle cannot have its custody transfer requested bit set. This means that if the original bundle that is sent has its custody transfer bit set and then this bundle is encapsulated (by being placed in an administrative record that is carried by an encapsulating bundle), no node can take custody of the encapsulating bundle as it travels through the network. Only after the original bundle is de-encapsulated can a node take custody of the original de-encapsulated bundle. The whole time the bundle is in the encapsulation “tunnel”, the encapsulating bundle cannot be taken custody of. In terms of the example use of BiB encapsulation given above, there would be no way to take a bundle from a DTN cache, encapsulate it in another bundle, and send this new bundle to a newly joining group member custodially.

There seem to be three options for addressing this:

1.       Do nothing. Leave the BiB Encapsulation I-D as written and live with the fact that encapsulating bundles cannot be sent custodially.

2.       Change the rule in section 4.2 (page 15) of the Bundle Protocol Specification (RFC 5050) to enable bundles whose application data unit is an administrative record of type BiB Encapsulation to have a custody transfer requested flag of 1.

3.      Rewrite the BiB Encapsulation I-D to perform encapsulation using an extension block instead of an administrative record. The extension block would indicate that the payload of the bundle contains one or more encapsulated bundles (and it could also provide their offsets). The payload of the bundle would contain the actual encapsulated bundles. (We want the encapsulated bundle(s) to be in the payload and not in an extension block to allow for fragmentation.) Some changes to the conceptual model and terminology now used in the Bundle Protocol (BP) would be required in order to be able to define encapsulation in this manner. As defined now, the BP requires that when a bundle reaches a bundle node that is a member of the bundle’s destination endpoint, the bundle must be delivered (section 5.7 of the BP, step2). Delivery means that the bundles’ application data unit (apdu), which consists of one or more encapsulated bundles (along with any offset information if more than one bundle has been encapsulated), would have to be presented to the node’s application agent (section 3.1 of the BP, page 6). In the case of encapsulation, this application agent would in turn have to take each of these bundles and hand them back to the bundle protocol agent, in order, to each be processed as if they had just been received from another node (as described in section 5.6 of the BP). Where this doesn’t exactly fit in now with the terminology and conceptual model used in the BP is that the application agent, to which the apdu is presented as part of the delivery process, consists of two elements: an administrative element, and an application-specific element. Neither of these two elements, as currently defined in the BP, seems capable of handling the apdu of encapsulated bundles as desired.

a.       The application-specific element is unsuitable because the only interface between the BPA and the application-specific element of the application agent is the BP service interface (BP, page 6); however, submitting a bundle to the BPA to be processed as if it has just be received from another node is not one of the services listed as being offered as part of this interface (see section 3.3 of the BP).

I don't see any obstacle here, Susan. "Delivering a received bundle" is one of the expected services. What the application-specific element of the application agent does with a delivered bundle is wholly an implementation matter. I can easily imagine, for instance, an endpoint ID convention that enables the destination endpoint to be specified somehow as "BiB handler". When the bundle is delivered to that endpoint, the application-specific element of the application agent deals with it by processing it as if it had been delivered by another node.

Speaking just for myself, I also don't yet see this capability as being especially useful. I think we tend to do too much within "bundling" already and would be better served by leaving some capabilities to other, well, layers. But if we really want to do this, I think some sort of extension block scheme would be the cleaner approach.

Scott

b. The administrative element is unsuitable because according to the BP, the administrative element of an application agent constructs and requests transmission of administrative records and accepts delivery of and processes custody signals; it doesn’t accept delivery of arbitrary apdus. (This is why we originally defined administrative records to be the mechanism for encapsulating bundles—so the administrative records could be delivered to the administrative element of the application agent and dealt with by them.) Something would have to be changed in the terminology and conceptual model of the BP as currently written to enable the encapsulating bundle to be delivered to an entity that can then extract the one or more encapsulated bundles and provide these back to the BPA to be processed as if they had just been received from another node.

--------------050009020905040202090806-- Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9MMPeYa023738 for ; Wed, 22 Oct 2008 15:25:40 -0700 Received: from manza-wlan.parc.xerox.com ([13.1.110.79]) by alpha.xerox.com with SMTP id <387499(1)>; Wed, 22 Oct 2008 15:17:43 PDT Message-Id: <711FB52C-F272-4A12-B041-51A2E5920283@parc.com> From: Ignacio Solis To: dtn-interest@mailman.dtnrg.org In-Reply-To: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 15:17:43 PDT References: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> X-Mailer: Apple Mail (2.929.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id m9MMPeYa023738 Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2008 22:25:40 -0000 Hi all. I just want to make a meta comment. As a disclaimer, I feel biased towards content-centricity. It seems to me that what we're trying to solve with the BiB is an inherent flaw in the design of DTN. Basically, DTN ties down the way we transport the data with the data/meta information. Now we're having problems because due to "integrity-protection" we can't transfer the bundle the way we need to. To solve this problem, we are designing a bundle protocol to move bundles. This might be why I'm trying to design our DTN content approach as, basically, an overlay over DTN. DTN is used as a way to move the content around, but the content is by nature, self-contained. In this instance, we're trying to treat the bundle as self-contained, but still want it to be flexible enough to be moved around, and for this we're designing a new protocol. If this discussion (I don't mean my ideas, I mean the main thread) leads to a good BiB protocol, wouldn't we gravitate towards using the BiB protocol more than the normal Bundle protocol? After all, it will be more "flexible". I understand that a lot of work has been done on DTN, and I do realize I might be speaking about impractical things, I just wanted to voice my ideas publicly. Don't take me too seriously, Nacho On Oct 21, 2008, at 12:37 PM, Symington, Susan F. wrote: > Peter Lovell has pointed out an issue with DTN Bundle-in-Bundle > (BiB) Encapsulation. There are several options for how to address > this issue, and I would like to get a feel for the DTN community�s > preferences. > > First of all, why do we want an encapsulation capability? Here is an > example of when BiB Encapsulation is handy: suppose a DTN cache has > some bundles stored on it. One of the bundles has a multicast > address as its destination EID and this bundle is integrity- > protected using a PIB. A new member joins the multicast group. We > would like to be able to send this new member the bundle. If we > simple send out the bundle as it is found in the cache, it is going > to go to all group members. If we change the destination EID of this > bundle, it can be sent to only the new member (as desired), but the > bundles integrity check will fail. Instead, we�d like to be able to > encapsulate this bundle so the encapsulating bundle can be addressed > directly to the new member only. > > Secondly, what is the problem that Peter has pointed out with the > way BiB encapsulation is now defined in draft-irtf-dtnrg-bundle- > encapsulation-03? The problem has to do with using an > administrative record as the mechanism to encapsulate bundles. > According to the Bundle Protocol, if a bundle is carrying an > administrative record, the bundle cannot have its custody transfer > requested bit set. This means that if the original bundle that is > sent has its custody transfer bit set and then this bundle is > encapsulated (by being placed in an administrative record that is > carried by an encapsulating bundle), no node can take custody of the > encapsulating bundle as it travels through the network. Only after > the original bundle is de-encapsulated can a node take custody of > the original de-encapsulated bundle. The whole time the bundle is > in the encapsulation �tunnel�, the encapsulating bundle cannot be > taken custody of. In terms of the example use of BiB encapsulation > given above, there would be no way to take a bundle from a DTN > cache, encapsulate it in another bundle, and send this new bundle to > a newly joining group member custodially. > > There seem to be three options for addressing this: > 1. Do nothing. Leave the BiB Encapsulation I-D as written and > live with the fact that encapsulating bundles cannot be sent > custodially. > 2. Change the rule in section 4.2 (page 15) of the Bundle > Protocol Specification (RFC 5050) to enable bundles whose > application data unit is an administrative record of type BiB > Encapsulation to have a custody transfer requested flag of 1. > 3. Rewrite the BiB Encapsulation I-D to perform encapsulation > using an extension block instead of an administrative record. The > extension block would indicate that the payload of the bundle > contains one or more encapsulated bundles (and it could also provide > their offsets). The payload of the bundle would contain the actual > encapsulated bundles. (We want the encapsulated bundle(s) to be in > the payload and not in an extension block to allow for > fragmentation.) Some changes to the conceptual model and terminology > now used in the Bundle Protocol (BP) would be required in order to > be able to define encapsulation in this manner. As defined now, the > BP requires that when a bundle reaches a bundle node that is a > member of the bundle�s destination endpoint, the bundle must be > delivered (section 5.7 of the BP, step2). Delivery means that the > bundles� application data unit (apdu), which consists of one or more > encapsulated bundles (along with any offset information if more than > one bundle has been encapsulated), would have to be presented to the > node�s application agent (section 3.1 of the BP, page 6). In the > case of encapsulation, this application agent would in turn have to > take each of these bundles and hand them back to the bundle protocol > agent, in order, to each be processed as if they had just been > received from another node (as described in section 5.6 of the BP). > Where this doesn�t exactly fit in now with the terminology and > conceptual model used in the BP is that the application agent, to > which the apdu is presented as part of the delivery process, > consists of two elements: an administrative element, and an > application-specific element. Neither of these two elements, as > currently defined in the BP, seems capable of handling the apdu of > encapsulated bundles as desired. > a. The application-specific element is unsuitable because the > only interface between the BPA and the application-specific element > of the application agent is the BP service interface (BP, page 6); > however, submitting a bundle to the BPA to be processed as if it has > just be received from another node is not one of the services listed > as being offered as part of this interface (see section 3.3 of the > BP). > b. The administrative element is unsuitable because according > to the BP, the administrative element of an application agent > constructs and requests transmission of administrative records and > accepts delivery of and processes custody signals; it doesn�t accept > delivery of arbitrary apdus. (This is why we originally defined > administrative records to be the mechanism for encapsulating bundles� > so the administrative records could be delivered to the > administrative element of the application agent and dealt with by > them.) Something would have to be changed in the terminology and > conceptual model of the BP as currently written to enable the > encapsulating bundle to be delivered to an entity that can then > extract the one or more encapsulated bundles and provide these back > to the BPA to be processed as if they had just been received from > another node. > > Right now I think I prefer option 2. I would like to understand how > much opposition there is to this option (if any) and I welcome any > other comments/ideas folks might have. > > If you�ve read this far, thanks. If you respond, even more thanks. > > -susan > ***************************************************************** > Susan Symington > The MITRE Corporation > susan@mitre.org > 703-983-7209 (voice) > 703-983-7142 (fax) > ****************************************************************** > Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9MIGRgV012447 for ; Wed, 22 Oct 2008 11:16:27 -0700 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9MI8wlf004433 for ; Wed, 22 Oct 2008 14:08:58 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9MI8wFv004410; Wed, 22 Oct 2008 14:08:58 -0400 Received: from IMCSRV1.MITRE.ORG ([129.83.20.158]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 14:08:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Wed, 22 Oct 2008 14:08:55 -0400 Message-ID: In-Reply-To: <48FE3928.1040509@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-interest] Bundle-in-Bundle Encapsulation Issue Thread-Index: AckzzndNGMN04b8sRGCbISML4+WhEQAiErIg References: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> <48FE3928.1040509@cs.tcd.ie> From: "Scott, Keith L." To: "Stephen Farrell" , "Symington, Susan F." X-OriginalArrivalTime: 22 Oct 2008 18:08:57.0850 (UTC) FILETIME=[40B7B5A0:01C93471] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by maillists.intel-research.net id m9MIGRgV012447 Cc: dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2008 18:16:28 -0000 Stephen, I don't think option 2 is as bad as you fear. Allowing custody to be set ONLY on admin records that contain encapsulated bundles would NOT (I think, and if I'm wrong then this whole line of argument goes away) allow the custody bit to be set on other admin records such as custody ACKs. There would be a weirdness if you encapsulated multiple bundles into one encapsulating bundle and the inner bundles were a mix of custodially-marked and non-custodially-marked bundles, but policy about what types of bundles can be mixed in an encapsulation bundle could address this. This approach would mean that bundle routers could not reject bundles solely on the combination of (Custody, Administrative) without also consulting the administrative record type. In any case, I also think there are cases where not allowing custody of encapsulated bundles (option 1) would result in poor performance. Just because the 'raw bundle interface' (that would be used by an application agent to 're-inject' bundles for forwarding) isn't part of section 3.3 of RFC5050 doesn't mean that it's not something that could be implemented. --keith -----Original Message----- From: dtn-interest-bounces@maillists.intel-research.net [mailto:dtn-interest-bounces@maillists.intel-research.net] On Behalf Of Stephen Farrell Sent: Tuesday, October 21, 2008 4:19 PM To: Symington, Susan F. Cc: dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue Hi Susan, (How come you get to explain all the hard-to-explain things? ;-) I think I'd rather explore option 3. And isn't the interface spec part of rfc 5050 optional or am I mis-remembering? If its optional, then non-conformance with an optional API doesn't seem to be a big deal - a different API for tunnel endpoints would seem reasonable anyway. (Though I don't care very much if we define one or not.) I can imagine a bunch of wrinkles if custody can be turned on for things like custody acks, so I'd rather not go down the road of your option 2. I guess I'd agree that the current situation isn't very good if bundles can't be taken into custody whilst inside tunnels. So I suppose that means I don't like option 1 either. S. Symington, Susan F. wrote: > All, > > > > Peter Lovell has pointed out an issue with DTN Bundle-in-Bundle (BiB) > Encapsulation. There are several options for how to address this issue, > and I would like to get a feel for the DTN community’s preferences. > > > > First of all, why do we want an encapsulation capability? Here is an > example of when BiB Encapsulation is handy: suppose a DTN cache has some > bundles stored on it. One of the bundles has a multicast address as its > destination EID and this bundle is integrity-protected using a PIB. A > new member joins the multicast group. We would like to be able to send > this new member the bundle. If we simple send out the bundle as it is > found in the cache, it is going to go to all group members. If we change > the destination EID of this bundle, it can be sent to only the new > member (as desired), but the bundles integrity check will fail. Instead, > we’d like to be able to encapsulate this bundle so the encapsulating > bundle can be addressed directly to the new member only. > > > > Secondly, what is the problem that Peter has pointed out with the way > BiB encapsulation is now defined in > draft-irtf-dtnrg-bundle-encapsulation-03? The problem has to do with > using an administrative record as the mechanism to encapsulate bundles. > According to the Bundle Protocol, if a bundle is carrying an > administrative record, the bundle cannot have its custody transfer > requested bit set. This means that if the original bundle that is sent > has its custody transfer bit set and then this bundle is encapsulated > (by being placed in an administrative record that is carried by an > encapsulating bundle), no node can take custody of the encapsulating > bundle as it travels through the network. Only after the original bundle > is de-encapsulated can a node take custody of the original > de-encapsulated bundle. The whole time the bundle is in the > encapsulation “tunnel”, the encapsulating bundle cannot be taken custody > of. In terms of the example use of BiB encapsulation given above, there > would be no way to take a bundle from a DTN cache, encapsulate it in > another bundle, and send this new bundle to a newly joining group member > custodially. > > > > There seem to be three options for addressing this: > > 1. Do nothing. Leave the BiB Encapsulation I-D as written and live > with the fact that encapsulating bundles cannot be sent custodially. > > 2. Change the rule in section 4.2 (page 15) of the Bundle Protocol > Specification (RFC 5050) to enable bundles whose application data unit > is an administrative record of type BiB Encapsulation to have a custody > transfer requested flag of 1. > > 3. Rewrite the BiB Encapsulation I-D to perform encapsulation using > an extension block instead of an administrative record. The extension > block would indicate that the payload of the bundle contains one or more > encapsulated bundles (and it could also provide their offsets). The > payload of the bundle would contain the actual encapsulated bundles. (We > want the encapsulated bundle(s) to be in the payload and not in an > extension block to allow for fragmentation.) Some changes to the > conceptual model and terminology now used in the Bundle Protocol (BP) > would be required in order to be able to define encapsulation in this > manner. As defined now, the BP requires that when a bundle reaches a > bundle node that is a member of the bundle’s destination endpoint, the > bundle must be delivered (section 5.7 of the BP, step2). Delivery means > that the bundles’ application data unit (apdu), which consists of one or > more encapsulated bundles (along with any offset information if more > than one bundle has been encapsulated), would have to be presented to > the node’s application agent (section 3.1 of the BP, page 6). In the > case of encapsulation, this application agent would in turn have to take > each of these bundles and hand them back to the bundle protocol agent, > in order, to each be processed as if they had just been received from > another node (as described in section 5.6 of the BP). Where this doesn’t > exactly fit in now with the terminology and conceptual model used in the > BP is that the application agent, to which the apdu is presented as part > of the delivery process, consists of two elements: an administrative > element, and an application-specific element. Neither of these two > elements, as currently defined in the BP, seems capable of handling the > apdu of encapsulated bundles as desired. > > a. The application-specific element is unsuitable because the only > interface between the BPA and the application-specific element of the > application agent is the BP service interface (BP, page 6); however, > submitting a bundle to the BPA to be processed as if it has just be > received from another node is not one of the services listed as being > offered as part of this interface (see section 3.3 of the BP). > > b. The administrative element is unsuitable because according to > the BP, the administrative element of an application agent constructs > and requests transmission of administrative records and accepts delivery > of and processes custody signals; it doesn’t accept delivery of > arbitrary apdus. (This is why we originally defined administrative > records to be the mechanism for encapsulating bundles—so the > administrative records could be delivered to the administrative element > of the application agent and dealt with by them.) Something would have > to be changed in the terminology and conceptual model of the BP as > currently written to enable the encapsulating bundle to be delivered to > an entity that can then extract the one or more encapsulated bundles and > provide these back to the BPA to be processed as if they had just been > received from another node. > > > > Right now I think I prefer option 2. I would like to understand how much > opposition there is to this option (if any) and I welcome any other > comments/ideas folks might have. > > > > If you’ve read this far, thanks. If you respond, even more thanks. > > > > -susan > > ***************************************************************** > > Susan Symington > > The MITRE Corporation > > susan@mitre.org > > 703-983-7209 (voice) > > 703-983-7142 (fax) > > ****************************************************************** > > > ----------------------------------------------------------------------- - > > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest _______________________________________________ dtn-interest mailing list dtn-interest@maillists.intel-research.net http://maillists.intel-research.net/mailman/listinfo/dtn-interest Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9LMlpAE023864 for ; Tue, 21 Oct 2008 15:47:51 -0700 Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id 1C5762E4D96; Tue, 21 Oct 2008 21:17:39 +0100 (IST) Received: from [10.87.48.5] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id m9LKHZpj005768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Oct 2008 21:17:36 +0100 Message-ID: <48FE3928.1040509@cs.tcd.ie> Date: Tue, 21 Oct 2008 21:18:48 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: "Symington, Susan F." References: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> In-Reply-To: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 33431982 - 0dccfca3fe31 (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52 Cc: dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 22:47:52 -0000 Hi Susan, (How come you get to explain all the hard-to-explain things? ;-) I think I'd rather explore option 3. And isn't the interface spec part of rfc 5050 optional or am I mis-remembering? If its optional, then non-conformance with an optional API doesn't seem to be a big deal - a different API for tunnel endpoints would seem reasonable anyway. (Though I don't care very much if we define one or not.) I can imagine a bunch of wrinkles if custody can be turned on for things like custody acks, so I'd rather not go down the road of your option 2. I guess I'd agree that the current situation isn't very good if bundles can't be taken into custody whilst inside tunnels. So I suppose that means I don't like option 1 either. S. Symington, Susan F. wrote: > All, > > > > Peter Lovell has pointed out an issue with DTN Bundle-in-Bundle (BiB) > Encapsulation. There are several options for how to address this issue, > and I would like to get a feel for the DTN community’s preferences. > > > > First of all, why do we want an encapsulation capability? Here is an > example of when BiB Encapsulation is handy: suppose a DTN cache has some > bundles stored on it. One of the bundles has a multicast address as its > destination EID and this bundle is integrity-protected using a PIB. A > new member joins the multicast group. We would like to be able to send > this new member the bundle. If we simple send out the bundle as it is > found in the cache, it is going to go to all group members. If we change > the destination EID of this bundle, it can be sent to only the new > member (as desired), but the bundles integrity check will fail. Instead, > we’d like to be able to encapsulate this bundle so the encapsulating > bundle can be addressed directly to the new member only. > > > > Secondly, what is the problem that Peter has pointed out with the way > BiB encapsulation is now defined in > draft-irtf-dtnrg-bundle-encapsulation-03? The problem has to do with > using an administrative record as the mechanism to encapsulate bundles. > According to the Bundle Protocol, if a bundle is carrying an > administrative record, the bundle cannot have its custody transfer > requested bit set. This means that if the original bundle that is sent > has its custody transfer bit set and then this bundle is encapsulated > (by being placed in an administrative record that is carried by an > encapsulating bundle), no node can take custody of the encapsulating > bundle as it travels through the network. Only after the original bundle > is de-encapsulated can a node take custody of the original > de-encapsulated bundle. The whole time the bundle is in the > encapsulation “tunnel”, the encapsulating bundle cannot be taken custody > of. In terms of the example use of BiB encapsulation given above, there > would be no way to take a bundle from a DTN cache, encapsulate it in > another bundle, and send this new bundle to a newly joining group member > custodially. > > > > There seem to be three options for addressing this: > > 1. Do nothing. Leave the BiB Encapsulation I-D as written and live > with the fact that encapsulating bundles cannot be sent custodially. > > 2. Change the rule in section 4.2 (page 15) of the Bundle Protocol > Specification (RFC 5050) to enable bundles whose application data unit > is an administrative record of type BiB Encapsulation to have a custody > transfer requested flag of 1. > > 3. Rewrite the BiB Encapsulation I-D to perform encapsulation using > an extension block instead of an administrative record. The extension > block would indicate that the payload of the bundle contains one or more > encapsulated bundles (and it could also provide their offsets). The > payload of the bundle would contain the actual encapsulated bundles. (We > want the encapsulated bundle(s) to be in the payload and not in an > extension block to allow for fragmentation.) Some changes to the > conceptual model and terminology now used in the Bundle Protocol (BP) > would be required in order to be able to define encapsulation in this > manner. As defined now, the BP requires that when a bundle reaches a > bundle node that is a member of the bundle’s destination endpoint, the > bundle must be delivered (section 5.7 of the BP, step2). Delivery means > that the bundles’ application data unit (apdu), which consists of one or > more encapsulated bundles (along with any offset information if more > than one bundle has been encapsulated), would have to be presented to > the node’s application agent (section 3.1 of the BP, page 6). In the > case of encapsulation, this application agent would in turn have to take > each of these bundles and hand them back to the bundle protocol agent, > in order, to each be processed as if they had just been received from > another node (as described in section 5.6 of the BP). Where this doesn’t > exactly fit in now with the terminology and conceptual model used in the > BP is that the application agent, to which the apdu is presented as part > of the delivery process, consists of two elements: an administrative > element, and an application-specific element. Neither of these two > elements, as currently defined in the BP, seems capable of handling the > apdu of encapsulated bundles as desired. > > a. The application-specific element is unsuitable because the only > interface between the BPA and the application-specific element of the > application agent is the BP service interface (BP, page 6); however, > submitting a bundle to the BPA to be processed as if it has just be > received from another node is not one of the services listed as being > offered as part of this interface (see section 3.3 of the BP). > > b. The administrative element is unsuitable because according to > the BP, the administrative element of an application agent constructs > and requests transmission of administrative records and accepts delivery > of and processes custody signals; it doesn’t accept delivery of > arbitrary apdus. (This is why we originally defined administrative > records to be the mechanism for encapsulating bundles—so the > administrative records could be delivered to the administrative element > of the application agent and dealt with by them.) Something would have > to be changed in the terminology and conceptual model of the BP as > currently written to enable the encapsulating bundle to be delivered to > an entity that can then extract the one or more encapsulated bundles and > provide these back to the BPA to be processed as if they had just been > received from another node. > > > > Right now I think I prefer option 2. I would like to understand how much > opposition there is to this option (if any) and I welcome any other > comments/ideas folks might have. > > > > If you’ve read this far, thanks. If you respond, even more thanks. > > > > -susan > > ***************************************************************** > > Susan Symington > > The MITRE Corporation > > susan@mitre.org > > 703-983-7209 (voice) > > 703-983-7142 (fax) > > ****************************************************************** > > > ------------------------------------------------------------------------ > > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9LKKu6E017229 for ; Tue, 21 Oct 2008 13:20:56 -0700 Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 3CDCD2D8018; Tue, 21 Oct 2008 15:13:51 -0500 (CDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m9LKDrjb017518; Tue, 21 Oct 2008 15:13:53 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 15:13:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Oct 2008 15:13:49 -0500 Message-ID: In-Reply-To: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-interest] Bundle-in-Bundle Encapsulation Issue Thread-Index: AckztHNapo3jwEXnTcmzQOpAwjQQrwAA8DQg References: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Symington, Susan F." , X-OriginalArrivalTime: 21 Oct 2008 20:13:50.0968 (UTC) FILETIME=[888D0780:01C933B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id m9LKKu6E017229 Subject: Re: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 20:20:57 -0000 >-----Original Message----- >From: dtn-interest-bounces@maillists.intel-research.net >[mailto:dtn-interest-bounces@maillists.intel-research.net] On >Behalf Of Symington, Susan F. >Sent: Tuesday, October 21, 2008 3:37 PM > > ... > >There seem to be three options for addressing this: > >1. Do nothing. Leave the BiB Encapsulation I-D as >written and live with the fact that encapsulating bundles >cannot be sent custodially. > >2. Change the rule in section 4.2 (page 15) of the >Bundle Protocol Specification (RFC 5050) to enable bundles >whose application data unit is an administrative record of >type BiB Encapsulation to have a custody transfer requested flag of 1. > >3. Rewrite the BiB Encapsulation I-D to perform >encapsulation using an extension block instead of an >administrative record. ... Some >changes to the conceptual model and terminology now used in >the Bundle Protocol (BP) would be required in order to be able >to define encapsulation in this manner. Option 1 is easiest in the short-term, but does it limit performance in any scenarios that have been proposed for operational concepts? If so, then we shouldn't pick option 1, but if not, then option 1 seems fine to me. Option 2 seems like a loophole that leads to bizarre little pieces of logic in the implementation and is difficult for people to keep in their heads when analyzing a problem or maintaining and enhancing code. Option 3 might be the most correct thing to do, though it involves reworking a small amount of the RFC 5050 text. I think this is perfectly fine and the right thing to do, if it's determined that option 1 is going to limit deployment or performance in some realistic case. Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9LJiac2015578 for ; Tue, 21 Oct 2008 12:44:36 -0700 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9LJbWYO004467 for ; Tue, 21 Oct 2008 15:37:32 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9LJbWL7004453 for ; Tue, 21 Oct 2008 15:37:32 -0400 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 15:37:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C933B4.73F1EB52" Date: Tue, 21 Oct 2008 15:37:27 -0400 Message-ID: <8E507634779E22488719233DB3DF9FF002F85FB3@IMCSRV4.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bundle-in-Bundle Encapsulation Issue Thread-Index: AckztHNapo3jwEXnTcmzQOpAwjQQrw== From: "Symington, Susan F." To: X-OriginalArrivalTime: 21 Oct 2008 19:37:29.0907 (UTC) FILETIME=[74898830:01C933B4] Subject: [dtn-interest] Bundle-in-Bundle Encapsulation Issue X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 19:44:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C933B4.73F1EB52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Peter Lovell has pointed out an issue with DTN Bundle-in-Bundle (BiB) Encapsulation. There are several options for how to address this issue, and I would like to get a feel for the DTN community's preferences. =20 First of all, why do we want an encapsulation capability? Here is an example of when BiB Encapsulation is handy: suppose a DTN cache has some bundles stored on it. One of the bundles has a multicast address as its destination EID and this bundle is integrity-protected using a PIB. A new member joins the multicast group. We would like to be able to send this new member the bundle. If we simple send out the bundle as it is found in the cache, it is going to go to all group members. If we change the destination EID of this bundle, it can be sent to only the new member (as desired), but the bundles integrity check will fail. Instead, we'd like to be able to encapsulate this bundle so the encapsulating bundle can be addressed directly to the new member only.=20 =20 Secondly, what is the problem that Peter has pointed out with the way BiB encapsulation is now defined in draft-irtf-dtnrg-bundle-encapsulation-03? The problem has to do with using an administrative record as the mechanism to encapsulate bundles. According to the Bundle Protocol, if a bundle is carrying an administrative record, the bundle cannot have its custody transfer requested bit set. This means that if the original bundle that is sent has its custody transfer bit set and then this bundle is encapsulated (by being placed in an administrative record that is carried by an encapsulating bundle), no node can take custody of the encapsulating bundle as it travels through the network. Only after the original bundle is de-encapsulated can a node take custody of the original de-encapsulated bundle. The whole time the bundle is in the encapsulation "tunnel", the encapsulating bundle cannot be taken custody of. In terms of the example use of BiB encapsulation given above, there would be no way to take a bundle from a DTN cache, encapsulate it in another bundle, and send this new bundle to a newly joining group member custodially.=20 =20 There seem to be three options for addressing this: 1. Do nothing. Leave the BiB Encapsulation I-D as written and live with the fact that encapsulating bundles cannot be sent custodially. 2. Change the rule in section 4.2 (page 15) of the Bundle Protocol Specification (RFC 5050) to enable bundles whose application data unit is an administrative record of type BiB Encapsulation to have a custody transfer requested flag of 1. 3. Rewrite the BiB Encapsulation I-D to perform encapsulation using an extension block instead of an administrative record. The extension block would indicate that the payload of the bundle contains one or more encapsulated bundles (and it could also provide their offsets). The payload of the bundle would contain the actual encapsulated bundles. (We want the encapsulated bundle(s) to be in the payload and not in an extension block to allow for fragmentation.) Some changes to the conceptual model and terminology now used in the Bundle Protocol (BP) would be required in order to be able to define encapsulation in this manner. As defined now, the BP requires that when a bundle reaches a bundle node that is a member of the bundle's destination endpoint, the bundle must be delivered (section 5.7 of the BP, step2). Delivery means that the bundles' application data unit (apdu), which consists of one or more encapsulated bundles (along with any offset information if more than one bundle has been encapsulated), would have to be presented to the node's application agent (section 3.1 of the BP, page 6). In the case of encapsulation, this application agent would in turn have to take each of these bundles and hand them back to the bundle protocol agent, in order, to each be processed as if they had just been received from another node (as described in section 5.6 of the BP). Where this doesn't exactly fit in now with the terminology and conceptual model used in the BP is that the application agent, to which the apdu is presented as part of the delivery process, consists of two elements: an administrative element, and an application-specific element. Neither of these two elements, as currently defined in the BP, seems capable of handling the apdu of encapsulated bundles as desired.=20 a. The application-specific element is unsuitable because the only interface between the BPA and the application-specific element of the application agent is the BP service interface (BP, page 6); however, submitting a bundle to the BPA to be processed as if it has just be received from another node is not one of the services listed as being offered as part of this interface (see section 3.3 of the BP).=20 b. The administrative element is unsuitable because according to the BP, the administrative element of an application agent constructs and requests transmission of administrative records and accepts delivery of and processes custody signals; it doesn't accept delivery of arbitrary apdus. (This is why we originally defined administrative records to be the mechanism for encapsulating bundles-so the administrative records could be delivered to the administrative element of the application agent and dealt with by them.) Something would have to be changed in the terminology and conceptual model of the BP as currently written to enable the encapsulating bundle to be delivered to an entity that can then extract the one or more encapsulated bundles and provide these back to the BPA to be processed as if they had just been received from another node.=20 =20 Right now I think I prefer option 2. I would like to understand how much opposition there is to this option (if any) and I welcome any other comments/ideas folks might have. =20 If you've read this far, thanks. If you respond, even more thanks. =20 -susan ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** ------_=_NextPart_001_01C933B4.73F1EB52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

First of all, why do we want an encapsulation = capability? Here is an example of when BiB Encapsulation is handy: suppose a DTN cache = has some bundles stored on it. One of the bundles has a multicast address as its destination EID and this bundle is integrity-protected using a PIB. A = new member joins the multicast group. We would like to be able to send this = new member the bundle. If we simple send out the bundle as it is found in = the cache, it is going to go to all group members. If we change the = destination EID of this bundle, it can be sent to only the new member (as desired), but = the bundles integrity check will fail. Instead, we’d like to be able = to encapsulate this bundle so the encapsulating bundle can be addressed = directly to the new member only.

Secondly, what is the problem that Peter has = pointed out with the way BiB encapsulation is now defined in = draft-irtf-dtnrg-bundle-encapsulation-03? The problem has to do with using an administrative record as the mechanism to encapsulate bundles. According to the Bundle = Protocol, if a bundle is carrying an administrative record, the bundle cannot have its = custody transfer requested bit set. This means that if the original bundle that = is sent has its custody transfer bit set and then this bundle is encapsulated = (by being placed in an administrative record that is carried by an encapsulating = bundle), no node can take custody of the encapsulating bundle as it travels = through the network. Only after the original bundle is de-encapsulated can a node = take custody of the original de-encapsulated bundle. The whole time the = bundle is in the encapsulation “tunnel”, the encapsulating bundle = cannot be taken custody of. In terms of the example use of BiB = encapsulation given above, there would be no way to take a bundle from a DTN cache, encapsulate it in another bundle, and send this new bundle to a newly = joining group member custodially.

There seem to be three options for addressing = this:

1. Do nothing. Leave the BiB Encapsulation I-D as = written and live with the fact that encapsulating bundles cannot be sent = custodially.

2. Change the rule in section 4.2 (page 15) of the = Bundle Protocol Specification (RFC 5050) to enable bundles whose application = data unit is an administrative record of type BiB Encapsulation to have a custody transfer requested flag of 1.

3. Rewrite the BiB Encapsulation I-D to = perform encapsulation using an extension block instead of an administrative = record. The extension block would indicate that the payload of the bundle contains = one or more encapsulated bundles (and it could also provide their offsets). The payload of the bundle would contain the actual encapsulated bundles. (We = want the encapsulated bundle(s) to be in the payload and not in an extension = block to allow for fragmentation.) Some changes to the conceptual model and terminology now used in the Bundle Protocol (BP) would be required in = order to be able to define encapsulation in this manner. As defined now, the BP = requires that when a bundle reaches a bundle node that is a member of the = bundle’s destination endpoint, the bundle must be delivered (section 5.7 of the = BP, step2). Delivery means that the bundles’ application data unit = (apdu), which consists of one or more encapsulated bundles (along with any = offset information if more than one bundle has been encapsulated), would have to be = presented to the node’s application agent (section 3.1 of the BP, page 6). In the = case of encapsulation, this application agent would in turn have to take each of = these bundles and hand them back to the bundle protocol agent, in order, to = each be processed as if they had just been received from another node (as = described in section 5.6 of the BP). Where this doesn’t exactly fit in now with the terminology and conceptual model used in the BP is that the application = agent, to which the apdu is presented as part of the delivery process, = consists of two elements: an administrative element, and an application-specific element. Neither of these two elements, as currently defined in the BP, = seems capable of handling the apdu of encapsulated bundles as desired.

a. = The application-specific element is unsuitable because the only interface = between the BPA and the application-specific element of the application agent is the = BP service interface (BP, page 6); however, submitting a bundle to the BPA = to be processed as if it has just be received from another node is not one of = the services listed as being offered as part of this interface (see section = 3.3 of the BP).

b. = The administrative element is unsuitable because according to the BP, the administrative element of an application agent constructs and = requests transmission of administrative records and accepts delivery of and = processes custody signals; it doesn’t accept delivery of arbitrary apdus. = (This is why we originally defined administrative records to be the mechanism for encapsulating bundles—so the administrative records could be = delivered to the administrative element of the application agent and dealt with by = them.) Something would have to be changed in the terminology and conceptual model of the = BP as currently written to enable the encapsulating bundle to be delivered to = an entity that can then extract the one or more encapsulated bundles and = provide these back to the BPA to be processed as if they had just been received = from another node.

Right now I think I prefer option = 2. I would like to understand how much opposition there is to this option (if = any) and I welcome any other comments/ideas folks might = have.

If you’ve read this far, = thanks. If you respond, even more thanks.

-susan

***************************************= **************************

Susan Symington

The MITRE Corporation

susan@mitre.org

703-983-7209 (voice)

703-983-7142 (fax)

*************= *****************************************************

------_=_NextPart_001_01C933B4.73F1EB52-- Received: from cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9LFQH5m003852 for ; Tue, 21 Oct 2008 08:26:17 -0700 Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id EEB993FBC1 for ; Tue, 21 Oct 2008 16:19:17 +0100 (IST) X-Virus-Scanned: amavisd-new at cs.tcd.ie Received: from cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uFy9l6zhGWT for ; Tue, 21 Oct 2008 16:19:17 +0100 (IST) Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18]) by smtp.cs.tcd.ie (Postfix) with ESMTP id 346753FBC3 for ; Tue, 21 Oct 2008 16:19:16 +0100 (IST) Message-ID: <48FDF340.10904@cs.tcd.ie> Date: Tue, 21 Oct 2008 16:20:32 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: DTN References: <48E5ECD9.1020807@cs.tcd.ie> In-Reply-To: <48E5ECD9.1020807@cs.tcd.ie> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dtn-interest] Possible DTNRG standalone meeting - San Francisco March 19-20 2009 X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 15:26:17 -0000 Hi, Based on responses received so far, it looks like we should take this opportunity to meet, so please add March 19-20 2009 to your diaries. Thanks to Google for hosting and to Adrian Hooke for organising, Regards, Stephen. PS: Current IETF schedule [1] has us meeting in MSP on Thursday Nov 20 0900-1130, but of course that can still change. [1] https://datatracker.ietf.org/meeting/73/agenda.html Stephen Farrell wrote: > Hi, > > Earlier we had some discussion about meeting frequency and > whether to have a standalone DTNRG meeting early next year. > > Thanks to Google (as prompted by Adrian Hooke from NASA) we > have an offer to host us for a 2 day slot just before the San > Francisco IETF, in Mountain View on 19-20 March. > > I realise that this'd make for a looooong trip for regular > IETFers, but OTOH, that's probably cheaper and not all of > us go to every IETF so maybe its ok. But since I'm not sure > I'd like to check. > > So, can you let Kevin and I know (offlist, any time in the > next week) if you'd plan to attend as above, or if you think > its such a terrible idea to have a meeting right before an > IETF that you're not coming but you otherwise would have come > to a standalone meeting. > > In other words just send one of the following to Kevin and I, > before the end of Oct 10: > > a) I plan to attend, or, > b) I would plan to go to a DTNRG standalone, but won't attend this > because its adjacent to the IETF meeting, or, > c) I can't make that date/location, but don't care about IETF > adjacency, or, > d) why are you bothering me with this nonsense? :-) > > I'll get back to the list then... (If there are split opinions > or something then let's discuss that then, rather than have an > abstract discussion now about whether its good, bad or indifferent > to have IRTF RGs meet just before the IETF.) > > Thanks, > Stephen. > > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest > Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9L8u8Ca018041 for ; Tue, 21 Oct 2008 01:56:08 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 1A256100406B3; Tue, 21 Oct 2008 09:49:16 +0100 (IST) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lchHsUVq8Bgj; Tue, 21 Oct 2008 09:49:15 +0100 (IST) Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id A5F7D1003F4DF; Tue, 21 Oct 2008 09:49:04 +0100 (IST) Message-ID: <48FD97CC.6080701@cs.tcd.ie> Date: Tue, 21 Oct 2008 09:50:20 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Paul Edelman References: <6c3baadf0810201928ia48ad1cx9c20d7d98aa3d303@mail.gmail.com> In-Reply-To: <6c3baadf0810201928ia48ad1cx9c20d7d98aa3d303@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-interest@mailman.dtnrg.org Subject: Re: [dtn-interest] Looking to build on top of DTN X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 08:56:09 -0000 Hi Paul, Most of that is more suited for the dtn-users list, the archive of which also probably contains some useful answers. I suggest moving the discussion there. Stephen. Paul Edelman wrote: > Hello all, > > My name is Paul Edelman. I am a masters candidate with the department > of computer science at Baylor University. We are looking at doing some > research / project work using the DTN reference implementation, > specifically building on top of DTN or even modifying DTN for the > purposes of experimentation. For some time now I have been going > through the available publications including the latest architectural > retrospective, available release documents, the DTN manual, as well as > the wiki. Despite all of that I still have a few questions. > > 1. The DTN daemon configuration file (dtnd.conf) lists support for > the following routing algorithms: static, flood, neighborhood, > linkstate, and external. What routing protocols are currently > mature in the implementation? For these protocols where might I > find specific documentation? > > 2. Does support for Prophet routing still exist? > > 3. What is the best source of information for a developer new to the > reference implementation? > > 4. In practice what is the state of the reference implementation, and > how is it currently being used? > > Really what I am looking for is how we can practically use the DTN > reference implementation, where the items listed above are our core > questions. Thank you very much for your time. > > Sincerely, > > *Paul Edelman* > Department of Computer Science > Baylor University > paul_edelman@baylor.edu > paul.edelman@gmail.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9L2ZGLP000545 for ; Mon, 20 Oct 2008 19:35:17 -0700 Received: by rv-out-0506.google.com with SMTP id b25so1896404rvf.49 for ; Mon, 20 Oct 2008 19:28:32 -0700 (PDT) Received: by 10.141.83.15 with SMTP id k15mr5331498rvl.74.1224556112553; Mon, 20 Oct 2008 19:28:32 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Mon, 20 Oct 2008 19:28:32 -0700 (PDT) Message-ID: <6c3baadf0810201928ia48ad1cx9c20d7d98aa3d303@mail.gmail.com> Date: Mon, 20 Oct 2008 21:28:32 -0500 From: "Paul Edelman" To: dtn-interest@mailman.dtnrg.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_54520_10622239.1224556112528" Subject: [dtn-interest] Looking to build on top of DTN X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 02:35:17 -0000 ------=_Part_54520_10622239.1224556112528 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello all, My name is Paul Edelman. I am a masters candidate with the department of computer science at Baylor University. We are looking at doing some research / project work using the DTN reference implementation, specifically building on top of DTN or even modifying DTN for the purposes of experimentation. For some time now I have been going through the available publications including the latest architectural retrospective, available release documents, the DTN manual, as well as the wiki. Despite all of that I still have a few questions. 1. The DTN daemon configuration file (dtnd.conf) lists support for the following routing algorithms: static, flood, neighborhood, linkstate, and external. What routing protocols are currently mature in the implementation? For these protocols where might I find specific documentation? 2. Does support for Prophet routing still exist? 3. What is the best source of information for a developer new to the reference implementation? 4. In practice what is the state of the reference implementation, and how is it currently being used? Really what I am looking for is how we can practically use the DTN reference implementation, where the items listed above are our core questions. Thank you very much for your time. Sincerely, *Paul Edelman* Department of Computer Science Baylor University paul_edelman@baylor.edu paul.edelman@gmail.com ------=_Part_54520_10622239.1224556112528 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hello all,

My name is Paul Edelman. I am a masters candidate with the department of computer science at Baylor University. We are looking at doing some research / project work using the DTN reference implementation, specifically building on top of DTN or even modifying DTN for the purposes of experimentation. For some time now I have been going through the available publications including the latest architectural retrospective, available release documents, the DTN manual, as well as the wiki. Despite all of that I still have a few questions.

The DTN daemon configuration file (dtnd.conf) lists support for the following routing algorithms: static, flood, neighborhood, linkstate, and external. What routing protocols are currently mature in the implementation? For these protocols where might I find specific documentation?
Does support for Prophet routing still exist?
What is the best source of information for a developer new to the reference implementation?
In practice what is the state of the reference implementation, and how is it currently being used?

Really what I am looking for is how we can practically use the DTN reference implementation, where the items listed above are our core questions. Thank you very much for your time.

Sincerely,

Paul Edelman
Department of Computer Science
Baylor University
paul_edelman@baylor.edu
paul.edelman@gmail.com

------=_Part_54520_10622239.1224556112528-- Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9HH78kv009743 for ; Fri, 17 Oct 2008 10:07:09 -0700 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9HH1rVZ008980 for ; Fri, 17 Oct 2008 13:01:54 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9HH1rxK008959; Fri, 17 Oct 2008 13:01:53 -0400 Received: from IMCSRV6.MITRE.ORG ([129.83.20.237]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 13:01:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Oct 2008 13:01:51 -0400 Message-ID: <53B52415C756A84E8A169F0E3673A329018C083B@IMCSRV6.MITRE.ORG> In-Reply-To: <8C7C41A176AC0B468BEFB2EFD9BDAB990620D876@XCH-NW-5V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-interest] Oasys won't configure Thread-Index: AckqQqvrV0DPYgAIR32VrmNk0xGRjQGNuIow References: <8C7C41A176AC0B468BEFB2EFD9BDAB990620D876@XCH-NW-5V2.nw.nos.boeing.com> From: "Andresen, Jason R." To: "Duke, Martin" , X-OriginalArrivalTime: 17 Oct 2008 17:01:53.0443 (UTC) FILETIME=[0DEB2F30:01C9307A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id m9HH78kv009743 Subject: Re: [dtn-interest] Oasys won't configure X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2008 17:07:09 -0000 I had the same problem on FreeBSD. The problem is that configure is calling make instead of gmake, but it's assuming that it has GNU make as "make", not BSD Make. The good news is that those errors are harmless. If you run "gmake", you should be able to build both DTN and oasys. However, you will run into one other compile error later on. In one of the files (I forget which), there is a reference to a size_t (or something similar) without the corresponding header included. If you just try to include the header by hand, the build will blow up, but if you search and replace all of those "size_t" instances in the one file with "int", the build goes through and the bundle daemon seems to work normally. I have not been able to track down the proper fix for that yet, so there is no patch. Sorry. >-----Original Message----- >From: dtn-interest-bounces@maillists.intel-research.net [mailto:dtn- >interest-bounces@maillists.intel-research.net] On Behalf Of Duke, Martin >Sent: Thursday, October 09, 2008 3:10 PM >To: dtn-interest@mailman.dtnrg.org >Subject: [dtn-interest] Oasys won't configure > >I've downloaded dtn-2.6.0 and oasys-1.3.0 from the DTN sourceforge site. > >I unzipped them into parallel directories, with BerkeleyDB 4.7.25 >installed on my FreeBSD 7.0 system. > >I then typed >cd oasys-1.3.0 >./configure --with-dbver=4.7 > >And after a while I get this: > >"Makefile", line 209: Missing dependency operator >"Makefile", line 212: Need an operator >"Rules.make", line 124: warning: duplicate script for target "%.o" >ignored >"Rules.make", line 125: warning: duplicate script for target "%.o" >ignored >"Rules.make", line 135: warning: duplicate script for target "%.E" >ignored >"Rules.make", line 136: warning: duplicate script for target "%.E" >ignored >"Rules.make", line 148: Missing dependency operator >"Rules.make", line 150: Need an operator >"Rules.make", line 153: Missing dependency operator >"Rules.make", line 154: Missing dependency operator >"Rules.make", line 155: Need an operator >"Makefile", line 243: Missing dependency operator >"Makefile", line 247: Need an operator >"Makefile", line 274: Need an operator >"Makefile", line 275: Need an operator >"Makefile", line 276: Need an operator >"Makefile", line 277: Need an operator >"Makefile", line 472: Need an operator >"Makefile", line 474: Need an operator >"Makefile", line 479: Need an operator >make: fatal errors encountered -- cannot continue > >Am I using the wrong distribution? Is there a configuration flag I >should be using? > >Thanks! >Martin > >All the other output listed below (preceeding the above): > >[root@freebsd7 /home/core/dtn/oasys-1.3.0]# ./configure --with-dbver=4.7 >checking location of source directory... >"/usr/home/core/dtn/oasys-1.3.0" >checking location of build directory... "/usr/home/core/dtn/oasys-1.3.0" >checking for a C compiler (trying gcc gcc-4.1 gcc-4.0 gcc-3.4 >gcc-3.3)... >checking for gcc... gcc >checking for C compiler default output file name... a.out >checking whether the C compiler works... yes >checking whether we are cross compiling... no >checking for suffix of executables... >checking for suffix of object files... o >checking whether we are using the GNU C compiler... yes >checking whether gcc accepts -g... yes >checking for gcc option to accept ISO C89... none needed >checking for a C++ compiler (trying g++ g++-4.0 g++-4.0 g++-3.4 >g++-3.3)... >checking for g++... g++ >checking whether we are using the GNU C++ compiler... yes >checking whether g++ accepts -g... yes >checking whether the C++ compiler works... yes >checking how to run the C preprocessor... gcc -E >checking for the version of the GNU C compiler... 4.2.1 >checking for the version of the GNU C++ compiler... 4.2.1 >checking for ar... ar >checking for ranlib... ranlib >checking whether to compile with debugging... yes >checking whether to compile with memory debugging... no >checking whether to compile with lock debugging (default yes)... yes >checking whether to compile with optimization... no >checking whether to compile with profiling... no >checking whether to link statically... no >checking whether to link using static external libraries... no >checking whether to try to build shared libraries... yes >checking whether the compiler supports -fPIC... yes >checking whether the compiler can link a dynamic library with -shared... >yes >checking extension for dynamic libraries... so >checking if the compiler supports -Wl,--rpath=.... yes >checking for grep that handles long lines and -e... /usr/bin/grep >checking for egrep... /usr/bin/grep -E >checking for sys/types.h... yes >checking for sys/stat.h... yes >checking for stdlib.h... yes >checking for string.h... yes >checking for memory.h... yes >checking for strings.h... yes >checking for inttypes.h... yes >checking for stdint.h... yes >checking for unistd.h... yes >checking for gawk... no >checking for mawk... no >checking for nawk... nawk >checking for a BSD-compatible install... /usr/bin/install -c >checking whether make sets $(MAKE)... yes >checking for ranlib... (cached) ranlib >checking for library containing pthread_create... -lpthread >checking for pthread_yield... yes >checking for library containing pthread_setspecific... none required >checking for library containing socket... none required >checking for library containing gethostbyname... none required >checking for library containing xdr_int... none required >checking for ANSI C header files... yes >checking err.h usability... yes >checking err.h presence... yes >checking for err.h... yes >checking execinfo.h usability... no >checking execinfo.h presence... no >checking for execinfo.h... no >checking for stdint.h... (cached) yes >checking for string.h... (cached) yes >checking synch.h usability... no >checking synch.h presence... no >checking for synch.h... no >checking sys/cdefs.h usability... yes >checking sys/cdefs.h presence... yes >checking for sys/cdefs.h... yes >checking for sys/types.h... (cached) yes >checking for an ANSI C-conforming const... yes >checking for inline... inline >checking for working volatile... yes >checking for mode_t... yes >checking value for _FILE_OFFSET_BITS preprocessor symbol... 64 >checking for off_t... yes >checking size of off_t... 8 >checking return type of signal handlers... void >checking for size_t... yes >checking for ptrdiff_t... yes >checking for uint32_t... yes >checking for u_int32_t... yes >checking for fdatasync... no >checking for getaddrinfo... yes >checking for gethostbyname... yes >checking for gethostbyname_r... yes >checking for getopt_long... yes >checking for inet_aton... yes >checking for inet_pton... yes >checking for pthread_yield... (cached) yes >checking for sched_yield... yes >checking whether to compile with non-atomic "atomic" routines... no >checking whether to compile with assembly-based atomic functions... yes >checking for --with-python... no >checking for python... /usr/local/bin/python >checking whether python distutils can build an extension module... yes >checking for library containing pow... -lm >checking for library containing dlopen... none required > >configure: checking for tcl installation (version 8.4) >checking for tcl.h (version 8.4) in /usr/include... no >checking for tcl.h (version 8.4) in /usr/local/include... no >checking for tcl.h (version 8.4) in /usr/include/tcl8.4... no >checking for tcl.h (version 8.4) in /usr/local/include/tcl8.4... yes >checking for tcl library in /usr/lib: -ltcl8.4 ... no >checking for tcl library in /usr/lib: -ltcl84 ... no >checking for tcl library in /usr/lib: -ltcl ... no >checking for tcl library in /usr/local/lib: -ltcl8.4 ... no >checking for tcl library in /usr/local/lib: -ltcl84 ... yes >checking whether to compile with google profiling... no >checking whether bluetooth support should be enabled... try >checking for library containing baswap... no >checking bluetooth/bluetooth.h usability... no >checking bluetooth/bluetooth.h presence... no >checking for bluetooth/bluetooth.h... no >checking whether bluetooth support was found... no >checking whether expat support should be enabled... try >checking for expat in /usr/include, /usr/lib, -lexpat... no >checking for expat in /usr/include, /usr/local/lib, -lexpat... no >checking for expat in /usr/local/include, /usr/lib, -lexpat... yes >checking whether libexpat was found... yes >checking whether xerces-c support should be enabled... try >checking whether xerces-c (>= v2.6.0) was found... no >checking whether tclreadline support should be enabled... try >checking for library containing readline... -lreadline >checking whether readline is GNU readline or BSD editline... editline >checking whether tclreadline support was found... yes >checking whether zlib support should be enabled... try >checking for library containing compress... -lz >checking for library containing compressBound... none required >checking whether zlib support was found... yes >checking for xsd... xsd >checking for Berkeley DB header (version 4.7) in /usr/include... no >checking for Berkeley DB header (version 4.7) in /usr/local/include... >no >checking for Berkeley DB header (version 4.7) in >/usr/local/include/db4.7... no >checking for Berkeley DB header (version 4.7) in >/usr/local/include/db4... no >checking for Berkeley DB header (version 4.7) in >/usr/local/include/db47... no >checking for Berkeley DB header (version 4.7) in >/usr/local/BerkeleyDB.4.7/include... yes >checking for Berkeley DB library in /usr/local/BerkeleyDB.4.7/lib, >-ldb-4.7... yes >configure: creating ./config.status >config.status: creating Rules.make >config.status: creating System.make >config.status: creating oasys-config.h >config.status: oasys-config.h is unchanged > >_______________________________________________ >dtn-interest mailing list >dtn-interest@maillists.intel-research.net >http://maillists.intel-research.net/mailman/listinfo/dtn-interest Received: from indomitable.uta.edu (indomitable.uta.edu [129.107.56.238]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9CNuNIh022698 for ; Sun, 12 Oct 2008 16:56:23 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYGAIIq8kiBazg8/2dsb2JhbACCRC+PQZ9ZBgKEfD1mAQh9 X-IronPort-AV: E=Sophos;i="4.33,398,1220227200"; d="scan'208,217";a="112756453" Received: from wolf3.uta.edu (HELO MAILST1.uta.edu) ([129.107.56.60]) by mail.uta.edu with ESMTP; 12 Oct 2008 23:53:14 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C92CC5.B039B5FA" Date: Sun, 12 Oct 2008 18:53:13 -0500 Message-ID: <5FC9D45135986C4398EFDB937D693394019A0163@MAILST1.uta.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IQ2S'09: Call for papers - DEADLINE HAS BEEN EXTENDED: October 31 Thread-Index: Acj1bf+J6Fn6NoDHQueuiSFQVV0eswAAlQS8AAvX59gADTSFugABI5sjAADNfikAAFgktQusOK3hAABoTPMAL2BjkAAAQYZWAADwNnAAAlIS/QAADE1vAABfE78AAJE1YwAARAEKAAAv+rsAAD9YUAAAB62MAdiTzbs= References: <162B8AFBFBBB2148A9A1B8F9C5753428FE5412@mailbe01.teak.local.net> <162B8AFBFBBB2148A9A1B8F9C575342803264283@mailbe01.teak.local.net> <358486CF38F8EA409E72DAB944FBC60602DEA60F@MAILFS2.uta.edu> <5FC9D45135986C4398EFDB937D6933940199FFC5@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D6933940199FFC6@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D6933940199FFC7@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D6933940199FFC8@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D693394019A00F0@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D693394019A00F2@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D693394019A0108@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D693394019A010A@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D693394019A0115@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D693394019A012E@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D693394019A012F@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D693394019A0131@MAILST1.uta.edu> <5FC9D45135986C4398EFDB93 7D693394019A0133@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D693394019A0134@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D693394019A0135@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D693394019A0136@MAILST1.uta.edu> <5FC9D45135986C4398EFDB937D693394019A0137@MAILST1.uta.edu> From: "Ammari, Habib M" To: Subject: [dtn-interest] IQ2S'09: Call for papers - DEADLINE HAS BEEN EXTENDED: October 31 X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2008 23:56:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C92CC5.B039B5FA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Colleagues, We apologize if you receive multiple copies. Please find below the Call for papers for IQ2S 2009, The First = International Workshop on Information Quality and Quality of Service for Pervasive Computing, = which will be held in conjunction with IEEE PerCom 2009, Galveston, Texas, March 9-13, = 2009. [+++++++ DEADLINE HAS BEEN EXTENDED TO OCTOBER 31! +++++++] We would appreciate it very much if you could disseminate this CFP to = your colleagues and students! Best Regards, Wendong Xiao, Institute for Infocomm Research, Singapore Habib M. Ammari, the University of Texas at Arlington, USA Program Co-Chairs -------------------------------------------------------------------------= ----------------------------------------------------------- CALL FOR PAPERS =20 The First International Workshop on Information Quality and Quality of = Service for Pervasive Computing (IQ2S 2009) Website: http://iq2s2009.i2r.a-star.edu.sg = = > > In Conjunction with IEEE PerCom 2009 (http://www.percom.org = > > ) Galveston, Texas, March 9-13, 2009 =20 Quality of service (QoS) has been studied in various building = blocks in pervasive computing, e.g., different QoS mechanisms are = presented for wireless or wired networks, with QoS metrics being = described in terms of delay, bandwidth, and/or data loss etc. The = emerging pervasive computing is application-driven and mission-critical, = therefore the information quality (IQ), such as the accuracy of target = tracking or event detection, is also critical for the end users, service = providers and the system designers. IQ and QoS provisioning for = pervasive computing is challenging and difficult due to the = resource-constrained, dynamic and distributed nature of the system, the = weakness under security attacking, and the lack of a holistic design = approach which takes into account the different types of resources and = their inter-dependencies. =20 The objective of this workshop is to provide a forum to exchange = ideas, present results, share experience, and enhance collaborations = among researchers, professionals, and application developers in various = aspects of IQ and QoS for pervasive computing. Topics of interest = include but are not limited to: * System architecture for IQ and QoS provisioning * IQ-oriented signal & information processing (e.g., = source coding and data compression) * QoS for target/event detection, localization, = tracking and classification * QoS for wireless ad hoc and sensor networks = (including coverage and connectivity) * QoS for task mapping and scheduling * Cross-layer design for coordinated QoS (including = IQ-QoS integration) * Adaptative IQ and QoS under dynamic environments * Trust, security and privacy issues in IQ and QoS * Development environments and programming languages = for IQ and QoS * IQ and QoS for emerging pervasive computing = applications, such as three-dimensional wireless sensor networks (like = underwater sensor network), healthcare, and structural health monitoring * Prototype test-bed design, implementation, and = field trials Submission Instructions The submitted paper should be in the IEEE conference format = (author guidelines can be found at = ftp://pubftp.computer.org/Press/Outgoing/proceedings/INSTRUCT.HTM = ) = and should be no more than 6 pages in length. The paper should not be = previously published or currently under review elsewhere. Only = electronic submissions in PDF format will be considered. Detailed = electronic submission procedures will be announced later. All = submissions will be peer-reviewed and selected based on their = originality, merit, and relevance to the workshop. Accepted papers will = be published by the IEEE Computer Society Press in the combined PerCom = 2009 workshops proceedings. At least one author of each accepted paper = must register and attend the workshop to present the paper. General Co-Chairs Sajal K. Das, the University of Texas at Arlington, USA Chen Khong Tham, Institute for Infocomm Research, Singapore =20 Program Co-Chairs Wendong Xiao, Institute for Infocomm Research, Singapore Habib M. Ammari, the University of Texas at Arlington, USA =20 Important Dates Paper submission: October 31, 2008 Author notification: December 19, 2008 Camera-ready due: January 7, 2009 -------------------------------------------------------------------------= ----------------------------------------------------------- ------_=_NextPart_001_01C92CC5.B039B5FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= [computational.science] IQ2S'09: Call for papers=0A= =0A= =0A=

Dear Colleagues,

We apologize if = you receive =0A= multiple copies.

=0A=

[+++++++ DEADLINE HAS BEEN EXTENDED TO OCTOBER 31! =0A= +++++++]

=0A=

=0A= =0A= =0A= ------_=_NextPart_001_01C92CC5.B039B5FA-- Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id m9C3MLwi004096 for ; Sat, 11 Oct 2008 20:22:22 -0700 Received: from xmta2.jpl.nasa.gov (xmta2.jpl.nasa.gov [137.78.160.56]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id m9C3JXOu012149 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Sun, 12 Oct 2008 03:19:34 GMT Received: from [127.0.0.1] (vpn-149-244-027.jpl.nasa.gov [128.149.244.27]) by xmta2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9C3JRoC009334 for ; Sat, 11 Oct 2008 20:19:31 -0700 Message-ID: <48F16CBE.5020608@jpl.nasa.gov> Date: Sat, 11 Oct 2008 20:19:26 -0700 From: Scott Burleigh User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: dtn-interest@mailman.dtnrg.org References: <20081009235750.AKO45377@metis.its.uow.edu.au><754BCCB1-0B2D-44A0-9592-9C88AA3BAB68@surrey.ac.uk> <48F012AE.70102@jpl.nasa.gov> <4835AFD53A246A40A3B8DA85D658C4BE7B0C7E@EVS-EC1-NODE4.surrey.ac.uk> In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE7B0C7E@EVS-EC1-NODE4.surrey.ac.uk> Content-Type: multipart/alternative; boundary="------------000507010502090800040509" X-Source-IP: vpn-149-244-027.jpl.nasa.gov [128.149.244.27] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Authorized X-AUTH: Authorized Subject: Re: [dtn-interest] Integrating IP with BP X-BeenThere: dtn-interest@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Delay Tolerant Networking Interest List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2008 03:22:22 -0000 This is a multi-part message in MIME format. --------------000507010502090800040509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit L.Wood@surrey.ac.uk wrote: > > I'd call that the 'Bundle architecture' for clarity, since it's > entirely built around bundles, and RFC4838 is clearly about bundles. > > Drawing a distinction between "Delay-Tolerant Networking" and > "delay-tolerant networking" really doesn't work in e.g. German, where > all nouns are capitalized - or in the New York Times heading style, > which does the same. I doubt that drawing a line similar to the > distinction between 'the Internet' and 'an internet' (or catenet) is > useful. > > If I say 'we run our DTNs over IP', what have I just said? Talking of > carrying bundles over IP is clearer as to how the Bundle architecture > and the Internet architecture are combined. > > I believe that as a research group, the DTNRG should look at and > consider all aspects of DTNs (or, if you like, dtns...), with a wider > view than just the focus on bundling. > An entirely valid point of view, Lloyd. Revisiting general topics in delay-tolerant networking can sometimes yield valuable new insights. What we want to be sure not to do is introduce confusion over what the terms "Delay-Tolerant Networking" and "DTN" denote. They have specific and well-understood meanings. There is no such thing as "Bundle architecture"; there is a Delay-Tolerant Networking architecture, and there is a Bundle Protocol that is one prominent feature of that architecture. There may well be other possible architectures for delay-tolerant networking (just as the Internet architecture is not the only possible architecture for internetworking); if so, they deserve their own names. English uses capitalization to distinguish between proper and common nouns that are spelled the same, and German and the New York Times manage to keep up one way or another: we all seem comfortable with distinguishing between "underground" and "Underground", "democrat" and "Democrat", "united nations" and "United Nations", "autonomous system" and "Autonomous System". I don't think there's a problem here. Scott > >