Re: [dtn-interest] BP-Tables

"Burleigh, Scott C (313B)" <scott.c.burleigh@jpl.nasa.gov> Mon, 23 April 2012 16:12 UTC

Return-Path: <scott.c.burleigh@jpl.nasa.gov>
X-Original-To: dtn-interest@ietfa.amsl.com
Delivered-To: dtn-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC6621F8720 for <dtn-interest@ietfa.amsl.com>; Mon, 23 Apr 2012 09:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.244
X-Spam-Level:
X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itvMdn+vW8aX for <dtn-interest@ietfa.amsl.com>; Mon, 23 Apr 2012 09:12:05 -0700 (PDT)
Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6FE21F8582 for <dtn-interest@irtf.org>; Mon, 23 Apr 2012 09:12:05 -0700 (PDT)
Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3NGC3U2023310 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 23 Apr 2012 09:12:04 -0700
Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.170]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.238]) with mapi id 14.01.0355.002; Mon, 23 Apr 2012 09:12:03 -0700
From: "Burleigh, Scott C (313B)" <scott.c.burleigh@jpl.nasa.gov>
To: "Hylton, Alan G (313B-NASA)" <alan.g.hylton@nasa.gov>, "Ivancic, William D. (GRC-RHN0)" <william.d.ivancic@nasa.gov>, "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Thread-Topic: BP-Tables
Thread-Index: Ac0hYft/z/qt3pRgTjGxOQiWFjlm0AABTJfwAABwCKAAAHsTwA==
Date: Mon, 23 Apr 2012 16:12:03 +0000
Message-ID: <A5BEAD028815CB40A32A5669CF737C3B041335@ap-embx-sp40.RES.AD.JPL>
References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> <A5BEAD028815CB40A32A5669CF737C3B04123C@ap-embx-sp40.RES.AD.JPL> <7BBFF2424089F04FB7D62F800895E2B629F36161D4@NDJSSCC07.ndc.nasa.gov>
In-Reply-To: <7BBFF2424089F04FB7D62F800895E2B629F36161D4@NDJSSCC07.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.149.137.26]
Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B041335apembxsp40RESADJP_"
MIME-Version: 1.0
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
Subject: Re: [dtn-interest] BP-Tables
X-BeenThere: dtn-interest@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <dtn-interest.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-interest>
List-Post: <mailto:dtn-interest@irtf.org>
List-Help: <mailto:dtn-interest-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Apr 2012 16:12:08 -0000

Alan, I certainly agree about the need for standardization of service identifiers.  FWIW, I believe CCSDS is already working on standardizing ipn-scheme service numbers through IANA.

I'm less clear on your illustration, though.  What you're describing sounds to me more like QoS than the sort of thing I usually think of a firewall supporting.  What's the argument for performing this function in bptables rather than in, say, routing?

Scott

From: Hylton, Alan G. (GRC-RHN0) [mailto:alan.g.hylton@nasa.gov]
Sent: Monday, April 23, 2012 8:58 AM
To: Burleigh, Scott C (313B); Ivancic, William D. (GRC-RHN0); dtn-interest@irtf.org
Subject: RE: BP-Tables

Howdy,

I think that this gets at a need for standardization of services.

Also, as an illustration, 3.3 might listen to 4.whatever, and 3.4 might listen to 5.whatever. Say you want to assure 4 that 1GB is set aside and 5 gets 2GB when receiving data. Part of the need for BP Tables is to have resource management in a general network setting. This guarantees that several science missions attached to a non-earth hub (a future TDRSS might be an axle between several hub-n-spokes) do not fight each other.

Alan

From: dtn-interest-bounces@irtf.org<mailto:dtn-interest-bounces@irtf.org> [mailto:dtn-interest-bounces@irtf.org]<mailto:[mailto:dtn-interest-bounces@irtf.org]> On Behalf Of Burleigh, Scott C (313B)
Sent: Monday, April 23, 2012 11:47 AM
To: Ivancic, William D. (GRC-RHN0); dtn-interest@irtf.org<mailto:dtn-interest@irtf.org>
Subject: Re: [dtn-interest] BP-Tables

Will, is it really important to manage service/application separate from endpoint ID (which is what I think you are saying when you say URI)?  I can see why you need to be able to identify the service/application that characterizes a bundle, but I think you're okay so long as you can always trivially infer service/application from the EID.  Certainly that's already easy to do if you're using "ipn"-scheme EIDs, according to the formal definition of the scheme, but it ought to be easy to tweak the "dtn" scheme definition for this purpose as well if necessary.

Scott

From: dtn-interest-bounces@irtf.org<mailto:dtn-interest-bounces@irtf.org> [mailto:dtn-interest-bounces@irtf.org]<mailto:[mailto:dtn-interest-bounces@irtf.org]> On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Monday, April 23, 2012 8:02 AM
To: dtn-interest@irtf.org<mailto:dtn-interest@irtf.org>
Subject: [dtn-interest] BP-Tables

A small team at NASA Glenn Research Center is looking at implementing the equivalent of IP-Tables for Store-Carry-and-Forward  (Disconnected) Networking

The following are some rough notes from our kickoff brainstorming session.  Anyone who has some ideas on what they might like to see, we would love to hear from you.

We plan to put together an internet draft document some of our thoughts.

A couple of things that sort of stood out:

*  We probably need something like ICMP (BCMP) to return status (with every node listening for this service
* It really would be nice to have services/applications separate from URI
* A more consistant/uniform naming scheme would be very useful
* It would be useful to be able to filer on something like organization (gets into a lot of mixing of Security/keys with identity verification)



Filtering on:
Size
Source URI
Destination URI
Lifetime (TTL) (limit acceptance of bundle based on time).
Hop Count (???)
Service (application == IP port) (how to determine???)

Should service be separate from URI?  (not currently possible in RFC 5050)
Key to deployment is Identity-based, not address-based - So do we need PIB to implement?
In RFC5050 - there is no addressing.  IP-tables are address-based.
Allocate resources (size, etc.) by URI.
Bundling needs the equivalent of IP-ICMP. (Bundle Control Message Protocol?)
IP-Tables can filter on all fields, BP-Tables (should it also do equivalent?)
BP-Tables may help manage resource allocation for quality of service (50% "bulk" bundles, 50% "scheduled service" for example).


ID BP-Tables
1.   Intro
o  Why BP-Tables
2.   IP-Tables
o  What does IP-tables do
3.   BP-Tables
o  What is different
o  What is similar
o  What it should do
o  What it can do
4.   Items of interest
o  URI vs. identity
o  URI vs. application/service
o  How do we identify application/service
5.   ICMP -> BCMP
o  Status replies
6.   Network management and BP-Tables
7.   Security Section
o  BAB, PIB, and PCB key distribution

- Will