Return-Path: 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 ; 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 ; 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 ; 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)" To: "Hylton, Alan G (313B-NASA)" , "Ivancic, William D. (GRC-RHN0)" , "dtn-interest@irtf.org" Thread-Topic: BP-Tables Thread-Index: Ac0hYft/z/qt3pRgTjGxOQiWFjlm0AABTJfwAABwCKAAAHsTwA== Date: Mon, 23 Apr 2012 16:12:03 +0000 Message-ID: References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> <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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 16:12:08 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B041335apembxsp40RESADJP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alan, I certainly agree about the need for standardization of service ident= ifiers. FWIW, I believe CCSDS is already working on standardizing ipn-sche= me 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 s= upporting. What's the argument for performing this function in bptables ra= ther 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 lis= ten to 5.whatever. Say you want to assure 4 that 1GB is set aside and 5 get= s 2GB when receiving data. Part of the need for BP Tables is to have resour= ce management in a general network setting. This guarantees that several sc= ience 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] 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 Subject: Re: [dtn-interest] BP-Tables Will, is it really important to manage service/application separate from en= dpoint ID (which is what I think you are saying when you say URI)? I can s= ee why you need to be able to identify the service/application that charact= erizes a bundle, but I think you're okay so long as you can always triviall= y 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 o= f 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] On Behalf Of Ivancic, William D. (GRC-RHN0) Sent: Monday, April 23, 2012 8:02 AM To: dtn-interest@irtf.org Subject: [dtn-interest] BP-Tables A small team at NASA Glenn Research Center is looking at implementing the e= quivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) Networki= ng 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 (ge= ts 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 =3D=3D 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 --_000_A5BEAD028815CB40A32A5669CF737C3B041335apembxsp40RESADJP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alan, I certainly agree a= bout the need for standardization of service identifiers.  FWIW, I bel= ieve CCSDS is already working on standardizing ipn-scheme service numbers through IANA.

 <= /p>

I’m less clear on y= our illustration, though.  What you’re describing sounds to me m= ore like QoS than the sort of thing I usually think of a firewall supportin= g.  What’s the argument for performing this function in bptables rather = than in, say, routing?

 <= /p>

Scott

 <= /p>

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-in= terest@irtf.org
Subject: RE: BP-Tables

 

Howdy,<= /p>

 <= /p>

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

 <= /p>

Also, as an illustration,= 3.3 might listen to 4.whatever, and 3.4 might listen to 5.whatever. Say yo= u 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 ma= nagement in a general network setting. This guarantees that several science= missions attached to a non-earth hub (a future TDRSS might be an axle betw= een several hub-n-spokes) do not fight each other.

 <= /p>

Alan

 <= /p>

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

 

Will, is it really import= ant 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 triviall= y infer service/application from the EID.  Certainly that’s alre= ady 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 i= f necessary.

 <= /p>

Scott

 <= /p>

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

 

A small team at NASA Glenn Research Center is lookin= g at implementing the equivalent of IP-Tables for Store-Carry-and-Forward &= nbsp;(Disconnected) Networking

 

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

 

We plan to put together an internet draft document s= ome 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/applicati= ons separate from URI 

* A more consistant/uniform naming scheme would be v= ery useful

* It would be useful to be able to filer on somethin= g like organization (gets into a lot of mixing of Security/keys with identi= ty verification)

 

 

 

Filtering on:

Size

Source URI

Destination URI

Lifetime (TTL) (limit acceptance of bu= ndle based on time). 

Hop Count (???)

Service (application =3D=3D IP port) (= how to determine???)

 

Should service be separate from URI?&n= bsp; (not currently possible in RFC 5050)

Key to deployment is Identity-based, n= ot address-based - So do we need PIB to implement?

In RFC5050 - there is no addressing.&n= bsp; IP-tables are address-based.

Allocate resources (size, etc.) by URI= .

Bundling needs the equivalent of IP-IC= MP. (Bundle Control Message Protocol?)

IP-Tables can filter on all fields,&nb= sp;BP-Tables (should it also do equivalent?)

BP-Tables may help manage resource all= ocation for quality of service (50% "bulk" bundles, 50% "sch= eduled 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-Tabl= es

7.   Security Section

o  BAB, PIB, and PCB key distribu= tion

 

- Will

--_000_A5BEAD028815CB40A32A5669CF737C3B041335apembxsp40RESADJP_--