Re: [dtn-interest] [dtn] History Correction: (was DTN static routing)

[Eric Travis <[e-mail]>]

Lloyd,

If this we coming from anyone else, I'd consider such participation to be
attention
seeking behavior. However, I know that you are sincere in your dislike of
CCSDS,
JPL, NASA, whatever this flavor of DTN might turn out to be *and* the
indifference
of the United States' to measuring our fuel consumption in
millimeters-per-deciliter.

Regardless, outside the Lloydiverse, none of this has *anything* to do with
the official
purpose of this mailing list or the associated working group.  Please,
(constructively)
comment on one or more drafts and divert your interesting philosophy to
Facebook
and Twitter which happen to be the perfect outlets for conspiracy theorists
and
performance art  (respectively) - your content there would be a refreshing
alternative.
>From your signature block ,  I infer that you have a web site dedicated to
disseminating
insightful content. Fantastic!

If you want to influence or shutdown CCSDS (who's power and influence you
comically
overestimate),  please lobby your national space agency.   If you want to
refight the
'IP-in-Space' wars and possibly mitigate your misinformed view of history,
build yourself
a time-machine.  Happily, that same time-machine could be used for you to
try (again) to
kill this Working Group before it was born.

At the very least (most?), write another peer-reviewed paper - perhaps the
sequel to
'A Bundle of Problems'  which you self suggested here 3 weeks ago?  I would
certainly
read it.

But, for concerns not directly related to DTN - *this* is not the outlet
you are looking for...

It is clear from your continued 'presence' and engagement that you care
deeply about
the idea of DTN, perhaps just not whatever flavor of DTN is being created
here.
Everything passes in time, and that's OK.

Considering there is an IETF meeting in about 2 weeks, there should be a
pile of drafts
worthy of commenting on - your insight would be valuable.

[On a even further side-note, *you* of all people can understand why CCSDS
mailing lists
are closed to posting by non-members, right?  If it bothers you, as above,
lobby your national
space agency.]

Eric

-- Secretly believes that you were hired to do guerrilla public awareness
on behalf of CCSDS

-- Openly bemused by your intense interest in activities which I enjoyed
being part of 20 years
    ago, but haven't considered relevant for almost as long...  The
misinformed swipes are
    (surprisingly) on the verge of becoming personally annoying


On Tue, Jun 30, 2015 at 2:05 AM, <[e-mail]> wrote:

>  Leigh,
>
>
>
> yes, JPL is very much the tail that wags the dog that is CCSDS as far as
> trying to get CCSDS to do networking or move the installed legacy base
> slowly forwards is concerned, providing necessary technical energy and
> leadership to CCSDS in those areas. Interaction with CCSDS re networking is
> interaction with JPL, not with the "CCSDS community" or their country ISO
> rapporteurs.
>
>
>
> Pointing out that JPL people were not actually (yet
> metaphorically) wearing their CCSDS hats while in a particular meeting is,
> frankly, a distinction without a difference.
>
>
>
> As the responsible DARPA manager, are you able to say why DARPA no longer
> appears to be actively participating in DTN work?
>
> (I see that the OMNI UoSAT-12 and the CLEO UK-DMC internet-in-space work
> have made SSTL's current list of firsts:
>
> http://www.sstl.co.uk/30-Firsts
>
>
> http://www.sstl.co.uk/News-and-Events/2015-News-Archive/SSTL-celebrates-30-years-of-Space-Innovation
> )
>
>
>
>  Lloyd Wood
> http://sat-net.com/L.Wood/dtn
>
> counting ground-based testbeds, it's at least two each. Hmmph.
>
>   ------------------------------
> *From:* Torgerson, Jordan L (332M) <[e-mail]>
> *Sent:* Tuesday, 30 June 2015 10:44 AM
> *To:* Scott, Keith L (9730-Affiliate)
> *Cc:* [e-mail]; [e-mail]; [e-mail];
> Wood L Dr (Electronic Eng)
> *Subject:* History Correction: (was DTN static routing)
>
>   "Cancel all my meetings. Someone on the internet is wrong.."
>
>  OK. I just have to comment on awkward and misleading statements about
> the role of CCSDS in development of SCPS and DTN.
>
>  "CCSDS" had nothing to do with the development of SCPS. I was the NASA
> Rapporteur for getting SCPS Blue Books accepted by CCSDS, and there was
> zero input from the "CCSDS community" that resulted in any changes to the
> technical specifications.
>
>   We did SCPS under a US government contract (SCPS was developed by
> people from JPL, MITRE, SPARTA and SAIC), and we successfully provided what
> the US government agency asked for. Since, at the time, the US government
> was trying to reduce reliance on MIL-SPECS, SCPS was given to CCSDS and
> they took the work we did for BMDO pretty much as-is and created CCSDS Blue
> Books which BMDO could refer to without creating new MIL-SPECs. As Keith
> said, all but SCPS-TP were deprecated in favor of more current techniques,
> but SCPS–TP as a performance enhancing proxy for internet over satellite
> hops has been quite successful, with about a dozen commercial products
> available, as well as being a standard for MILSATCOM.
>
>   What about DTN? Mr. Wood's assertions are likewise misleading. After
> SCPS we started speculating about what it would take to extend internet
> technologies to deep space missions, and there was a desire to layer CFDP
> to improve its utility vis-a-vis networking (i.e. morphing a CCSDS protocol
> to fit better with the internet model, not vice versa). That led to some
> conversations with Vint when Adrian, Scott and I were in Reston one day,
> but CCSDS didn't figure in to it.  The initial impetus for DTN was driven
> only by the networking challenges presented by deep space exploration, not
> by some sort of CCSDS influence. We didn't want to network spacecraft
> because of CCSDS, we wanted to network spacecraft and future colonies on
> Mars with the Earth because the value of networking and the utility of
> automation afforded by the terrestrial internet was obvious. The IPN study
> effort was funded by DARPA, not NASA or any other space agency associated
> with CCSDS.
>
>  Vint Cerf wrote in the forward to Stephen Farrell & Vinny Cahill's book
> "Delay- and Disruption-Tolerant Networking" (©2006, ARTECH HOUSE), " … a
> project was started in 1998 to develop a set of protocols suitable for
> supporting a store-and-forward Interplanetary Internet called "InterPlaNet"
> or "IPN" for short. During the course of the exploratory development of
> this new set of protocols it became clear that the IPN was a special case
> of a more general networking problem we called delay and disruption
> tolerant networking or DTN."
>
>  As the first task manager for the DARPA-funded Interplanetary Internet
> study and then later task manager for the JPL core engineering support for
> the DARPA DTN project, I can tell you that we very deliberately set up the
> DTNRG in the IRTF (as opposed to CCSDS or NASA or ESA) and funded the
> academic community to insure that DTN had as broad an applicability and
> research gene pool as possible. I have pictures of meetings in 1999 with
> not only Vint, but a number of internet pioneers from UCLA and USC as we
> held meetings to discuss how to do networking in environments that are
> characterized by disruption and delay. It took years before there was
> enough consensus in the CCSDS community to even *consider* getting CCSDS
> to look at DTN for space missions. Most of the researchers in the program
> had little experience (or interest) in international space missions or
> space communications.
>
>  Both SCPS and DTN are examples of protocols that were designed,
> developed and prototyped outside of the CCSDS environment and then offered
> to CCSDS as a potential solution to their needs.
>
>  Finally, Mr. Wood's "thanks, Adrian" comment is unfair and unkind.
> Sometime around 2004, Hugh Arif, then a Cisco Space Initiatives manager,
> arranged for several executives from CISCO to come to JPL to learn about
> CISCO's potential business opportunities with NASA and other worldwide
> space missions.  The Cisco VP for marketing (if I remember his position
> correctly)  wasn't particularly interested in developing "space routers"
> and he stated that even if the market for space routers was in the
> hundreds, CISCO's business model was to sell *millions* of units. No
> sale. No blame, no fault, just simple economics.
>
>  Attempts by others to convince CISCO to mass-produce IP routers for
> space have not fared any better.. in the last 15 years we've seen CLEO (one
> each) and IRIS (one each) and according to a 2011 evaluation report in
> Johns Hopkins University APL tech digest 3002, IRIS network unreliability
> and equipment configuration problems highlighted "the need for robust,
> real-time network management capabilities." Sounds like a great use case
> for Disruption-Tolerant Networking… If LEO folks want to run IP networks
> everywhere, that's OK – we run DTN over IP networks all the time, and DTN
> can lessen the need for the costly "robust, real-time network management"
> the APL report says you need for IP networks in space. If missions with
> legacy telemetry and CCSDS systems want to use DTN to automate mission ops,
> it runs over legacy telemetry just fine, as we demonstrated on EPOXI, and
> as we are currently demonstrating on ISS.
>
>  Leigh
>
>   From: "[e-mail]" <[e-mail]>
> Date: Sunday, June 28, 2015 at 2:10 AM
> To: "Scott, Keith L." <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> Subject: Re: [dtn-interest] [dtn] DTN static routing
>
>    Keith,
>
>
>  saying that the DTNWG exists solely because of the DTNRG is an
> oversimplification; the DTNRG exists because of the interplanetary internet
> RG, which existed because of the ISOC IPNSIG group, which existed because
> of the well-publicised 1998 push by CCSDS (well, Adrian and Vint) to adopt
> networking... it's a CCSDS effort all the way. (since CCSDS mailing lists
> are now closed, and since this group exists as a result of CCSDS efforts,
> discussing CCSDS influence on  DTNWG work here is entirely appropriate.)
>
>
>  CCSDS would like nothing better than to buy commercial routers? The
> chance to do that has been and gone; conversations with Adrian were never
> fruitful.
>
>
>  Some compatibility with terrestrial standards would have been achieved
> if CCSDS, an ISO subgroup, worked to carry HDLC (ISO 13239). That an ISO
> subgroup ignores ISO standards is pretty odd and hard to justify, but then
> NASA still works in imperial measures...
>
>
>  But supporting ISO 13239 and high-speed serial links would have gone a
> long way to do that, bringing in framing and layering from serrial links
> and encouraging those, against the prevailing commercial Ethernet
> assumptions; amazing how L2 Eth frames are now being sent through GEO
> satellites.... and now SpaceWire is reinventing high-speed serial LVDS.
> Specially, for space. CCSDS is good at physical and propagation; not so
> much framing and logical, and farming that work out while trying to control
> the results and ensure legacy support doesn't seem to work that well.
>
>
>  Doing work to support CCSDS protocols  has not previously had a good
> business case. ("If we implemented this in a router for you, how many would
> you buy?" "Well, one gateway, obviously" - thanks, Adrian.)
>
>
>  It's entirely possible that a DTN solution that satisfies CCSDS could
> also see widespread terrestrial adoption. It's also entirely unlikely.
>
>
>   Lloyd Wood
> http://sat-net.com/L.Wood/dtn
>
>  "NPI"? this will bounce from sis-dtn, I expect.
>
>  ------------------------------
> *From:* Scott, Keith L. <[e-mail]>
> *Sent:* Thursday, 11 June 2015 11:06 PM
> *To:* Wood L Dr (Electronic Eng); [e-mail]
> *Cc:* [e-mail]; [e-mail]; '[e-mail]'
> *Subject:* RE: [dtn-interest] [dtn] DTN static routing
>
>
> Lloyd,
>
>
>
>
>
> You’re right, the non-utility of the SCPS Network Protocol (and the
> security protocol) were in a sense wasted effort because they weren’t
> picked up by the space community.  The SCPS File Protocol was essentially a
> rubber-stamp of FTP, which the space community didn’t pick up either.  The
> CCSDS File Delivery Protocol (CFDP) has had more success and is being
> baselined into missions now.  That the space community wouldn’t take up
> what was essentially a copy of the Internet Protocol Suite, as well as the
> realization of the performance benefits of relaying from the Mars rovers,
> is what drove the development of an internetworking mechanism that could
> serve the space community.  That effort is DTN.
>
>
>
> CCSDS is not getting the IETF to do anything; IETF is picking up and
> advancing work done by the IRTF.  We (CCSDS) certainly HOPE to be able to
> adopt / adapt the result for use by CCSDS agencies, with a strong desire to
> do so in an on-the-wire-compatible way.  This is bad how?  If your argument
> is that CCSDS should simply cease to exist and agencies should use
> standards from other bodies (like the IETF) for missions, fine.  I’ve tried
> making that argument to the people designing missions and have not
> succeeded (see the early draft of the CCSDS BP and LTP profiles), but maybe
> you’d do better.  In that case, however, be sure that the specifications
> from other organizations meet all of the space community’s requirements,
> even where they conflict with those of the much larger terrestrial
> community.  I don’t think that’ll fly (NPI).
>
>
>
> I’m not sure what to make of your parenthetical statement.  CCSDS’ mission
> is to define recommended standards for space communication.  The agencies
> that make up CCSDS (and the technical people within those agencies) think
> there’s a win to the work that CCSDS is doing, otherwise the agencies
> wouldn’t support it.  If you as a private citizen take issue with how the
> space agency of your government spends its money, work for them and change
> the situation from the inside or lobby them from the outside.  With respect
> to ‘rubber stamping’ existing specifications, for the internetworking /
> DTN-related standards, I have argued strongly for on-the-wire compatibility
> with corresponding terrestrial standards with additions / modifications
> that are beneficial to space missions because I think it provides the best
> capabilities for the least effort.  To give an example, we found when
> running RFC5050 BP to (from) the international space station that custody
> acknowledgements were congesting the uplink (which was on the order of 100
> bits per second).  The people at the University of Colorado who were
> running the ground side developed a mechanism to aggregate / compress
> multiple custody signals together in order to reduce the uplink bandwidth.
> It helped them a lot.  Also, when JAXA first reviewed the proposed CCSDS
> spec (essentially a rubber stamp of RFC5050) they had concerns about the
> number of priority levels provided.  We included an Extended Class of
> Service block type in the CCSDS specification.  So, the non-inclusion of
> space-specific requirements in RFC5050 drove some domain-specific
> augmentations to the specification.  If the work coming out of the IETF
> includes everything the space agencies could possibly want then sure, CCSDS
> can simply adopt the IETF specification (which will take some time but very
> little money) and be done.  I’d LOVE that.  Please (and there’s no sarcasm
> here) lobby the IETF WG to include all the capabilities in the current
> CCSDS BP spec and I’ll argue that CCSDS should simply adopt it unchanged.
> If the IETF specification(s) do not include all that CCSDS thinks they
> need, but those capabilities can be added in a reasonable way, we’ll do it.
>
>
>
> I don’t get the rest of your argument.  CCSDS has moved out adopting the
> IRTF standard because of the timeline for getting new technologies adopted
> into space missions and because there are some missions now that can make
> use of it now.  Those missions want something that is stable (in the way
> that a particular RFC is stable), and they want assurances that the
> technology will work in space environments.  Also, when CCSDS began
> standardization of the CCSDS profile of RFC5050, there was not IETF working
> group.  Our (or at least MY) plan going forward is to try to convince
> missions to adopt internetworking technology (using IP and the current
> RFC5050-based CCSDS specification as the standards) and then to update the
> CCSDS BP spec to follow any RFC produced by the IETF.  My hope (I could be
> wrong) is that once missions have signed on to the benefits of an
> internetworked communication architecture, that slight modifications to the
> actual protocol(s) used to implement that architecture will be a
> non-issue.  I’ve been very open about this with CCSDS and NASA.
>
>
>
> Wait, what?!?!?   CCSDS dearly wants BP (DTN) to succeed terrestrially.
> CCSDS (and I argue, the space community as a whole) would like nothing
> better than to buy commercial routers (or appliances, something) with BP
> baked in that they can deploy to ground stations, mission control centers,
> scientists, and whatever spacecraft they might be able to use commercial
> hardware on (e.g. ISS, generally things with atmosphere and people).  This
> would be the biggest possible win for CCSDS – to cause something that CCSDS
> can use (DTN) to be adopted by a wider terrestrial community that actually
> has a large market that can cause products to be built, matured, and tested
> at a MUCH faster rate than the space agencies, and at an economy of scale
> that the space agencies could only dream of.
>
>
>
> The space community (wider than just CCSDS) has an interest in ensuring
> that the protocol developed by the IETF can in fact meet their requirements
> in addition to those of the other interested parties (see above, we want to
> buy the commercial equipment that we hope will result from the IETF
> effort).   Sure, with my CCSDS hat on I’ll argue that the IETF WG should
> include whatever ‘space-specific’ requirements we think we have in the
> RFC5050-bis spec.  The IETF working group will adjudicate those requests in
> concert with all the other requirements from other parties and do what they
> think is best.  Based on whatever comes out of that, CCSDS will have to
> decide if they should switch to the new protocol (or a profile of it) or if
> they should live with the old one.
>
>
>
>                         --keith
>
>
>
>
>
>
>
> *Dr. Keith Scott*
> Office: +1.703.983.6547
>
> Chief Engineer,
> J86A
> Fax:      [phone]
>
> Communications Network Engineering & Analysis                    Email:
> [e-mail]
>
> The MITRE Corporation <http://www.mitre.org/>
>                                                            M/S H300
>
> 7515 Colshire Drive
>
> McLean, VA 22102
>
>
>
> Area Director,CCSDS <http://www.ccsds.org/> Space Internetworking Services
> <http://cwe.ccsds.org/sis/default.aspx>
>
>
>
> MITRE self-signs its own certificates.  Information about the MITRE PKI
> Certificate Chain is available from http://www.mitre.org/tech/mii/pki/
>
>
>
>
>
>
>
> *From:* [e-mail] [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Thursday, June 11, 2015 3:47 AM
> *To:* Scott, Keith L.; [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [dtn-interest] [dtn] DTN static routing
>
>
>
> The SCPS lesson is interesting.
>
> CCSDS took IETF standards for TCP and IP, and modified them with
> optimisations, before publishing them as CCSDS standards, expecting their
> use as CCSDS blue books to take off.
>
> Those CCSDS standards didn't take off (SCPS-TP has some use as a
> lowest-common denominator PEP for govt use, that's about it, -NP, security
> etc. are dead) so e.g. Constellation baselines actual
> took-over-planet-Earth-meanwhile-that's-an-entire-planet-how-many-planets-does-CCSDS-have
> IP, reversing the CCSDS customisations. And Constellation got CCSDS to
> support actual IP better in the process.
>
> Fast forward a quarter of a century, and CCSDS is getting the IETF to
> standardise the DTN bundle protocol in this workgroup, with the usual
> intent of modifying it for adoption in CCSDS as slightly different CCSDS
> book standards. Just like SCPS - and CCSDS customisations to the RFC5050
> bundle protocol are already happening.
>
> (Because the IETF stuff is Not Invented Here for CCSDS, space is too
> special, and if CCSDS doesn't write its own standards documents and do
> modifications as part of rubber stamping others' designs, what is it for as
> a standards body?)
>
> So, to do this and diverge from what the IETF will produce, CCSDS has to
> be betting that what the IETF produces for the bundle protocol in this
> workgroup will not be at all popular as a standard.
>
> Because, if the IETF bundle protocol is popular and widely adopted, an
> embarrassing reversal to adopt the real thing, the actual IETF standard,
> will result in a few years' time. Just like the reversal that replaced SCPS
> with the more popular IP, resulting in much wasted effort and economic cost.
>
> So, this simple analysis suggests that it is not in CCSDS interests to see
> the bundle protocol succeed terrestrially. Quite the opposite, in fact.
>
> So perhaps CCSDS can ensure that the IETF work is not successful
> terrestrially by ensuring its design as suitable for space as possible, and
> not for ground use? Looks like a good bet to me.
>
> Lloyd Wood
> http://sat-net.com/L.Wood/dtn
>
> a sequel to 'A Bundle of Problems' has been suggested.
>  ------------------------------
>
> *From:* Scott, Keith L. <[e-mail]>
> *Sent:* Thursday, 11 June 2015 12:14:12 AM
> *To:* Wood L Dr (Electronic Eng); [e-mail];
> [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Subject:* RE: [dtn-interest] [dtn] DTN static routing
>
>
>
> [My apologies, none of this has anything to do with static routing.  I
> address Lloyd’s point about CCSDS and IP, then comment on Greg’s original
> post on interoperability.]
>
>
>
>
>
> Lloyd,
>
>
>
> There is no obstacle to including IP in the space domain as far as CCSDS
> is concerned.
>
>
>
> The IOAG-sponsored Space Internetworking Strategy Group (SISG) phase-1
> report
> <https://www.ioag.org/Public%20Documents/SISG%20Phase%20I%20report%20%E2%80%93%20final.pdf>
> concluded that both IP and BP were valid approaches to internetworking in
> space.  BP is the preferred mechanism since it should work over a larger
> domain of network conditions than IP, but IP is explicitly mentioned as an
> option for space (and ground) links.  The whole Solar System Internetwork
> Concept of Operations
> <https://www.ioag.org/Public%20Documents/SISG%20Operations%20Concept%20for%20SSI%20-%20final%20version.pdf>
> reflects this.
>
>
>
> CCSDS has in fact embraced the Internet Protocol Suite since the 1990s,
> and had a set of adaptations for space (including an ‘IP-like’ variant,
> SCPS-NP, that was deprecated in favor of simply using IP).
>
>
>
> The NASA Constellation program, while embracing CCSDS data links,
> baselined IP as their initial internetworking protocol, and argued strongly
> for greater support for IP over those links, resulting in modifications to
> the CCSDS link layer services to better support IP and IP header
> compression in particular.
>
>
>
>
>
> The Bundle Protocol is not just for CCSDS
>
>
>
> Since at least 2001 when people doing sensor networks became interested in
> BP there has been interest in other applications of BP for environments
> other than space.  A number of organizations (with only NASA having an
> explicit space application) collaborated in the creation of the Bundle
> Protocol.  That BP was specified as an IRTF RFC and is now being considered
> in the IETF (I think) demonstrates the broad (including external-to-CCSDS)
> support.  The CCSDS Bundle Protocol is in fact an adaptation/profile of the
> IRTF RFC – we (in CCSDS) followed the IRTF – and we’re going to do it again
> when the IETF specifies their version of bundle protocol and security.
>
>
>
>
>
> To Greg’s point on Naming and Interoperability
>
>
>
> I concur that a proliferation of naming schemes may (OK, almost surely
> will) lead to a lack of truly global interoperability, and that it is
> exactly that global interconnectivity that was the big win for IP (and
> internetworking in general).  However, given that there are different camps
> interested in using BP with different requirements that seem to argue for
> different naming schemes but who can all make use of the ‘base’ bundle
> protocol, allowing a multitude of schemes seems like the best solution for
> now.
>
>
>
> I hope that the DTN community figures out how they want to deal with
> that.  For example, gateways between naming regions can be constructed to
> connect those regions that want to / need to communicate, or one naming
> scheme could come to dominate (I know which one Scott would pick, and that
> that’s not the one everyone would pick), or different communities with
> different needs / applications (and naming schemes) could decide that
> interoperability isn’t worth the effort and live with it (their choice).  I
> DO think this discussion should inform the IETF WG, and that they (and the
> DTN community) should make a deliberate decision about how to proceed –
> i.e. whether to enforce a single naming/addressing scheme, or not.
>
>
>
> I view BP as a tool to effect end-to-end communication in the environments
> where BP can function and IP cannot (or where IP doesn’t perform well)
> rather than as a forklift replacement for IP, and so in my mind BP doesn’t
> HAVE to enforce immediate universal interconnectivity.  People can use BP
> where and how it works for them; they’ve seen the benefits of
> interconnectivity, and where it makes sense to do so, they’ll put in the
> effort to achieve it.  BP could one day replace IP I suppose, but I suspect
> it’s like the quote which is not mine but for which I have not been able to
> find a good citation: “You’re an excellent writer and your works will be
> remembered long after Shakespeare has been forgotten.  But not until then.”
>
>
>
>
>
>                         --keith
>
>
>
>
>
>
>
> *Dr. Keith Scott*
> Office: +1.703.983.6547
>
> Chief Engineer,
> J86A
> Fax:      [phone]
>
> Communications Network Engineering & Analysis                     Email:
> [e-mail]
>
> The MITRE Corporation <http://www.mitre.org/>
>                                                            M/S H300
>
> 7515 Colshire Drive
>
> McLean, VA 22102
>
>
>
> Area Director,CCSDS <http://www.ccsds.org/>Space Internetworking Services
> <http://cwe.ccsds.org/sis/default.aspx>
>
>
>
> MITRE self-signs its own certificates.  Information about the MITRE PKI
> Certificate Chain is available from http://www.mitre.org/tech/mii/pki/
>
>
>
>
>
>
>
> -----Original Message-----
> From: dtn-interest [mailto:[e-mail]
> <[e-mail]>] On Behalf Of [e-mail]
> Sent: Tuesday, June 09, 2015 10:14 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [dtn-interest] [dtn] DTN static routing
>
>
>
> Greg says:
>
> > Implicit in different groups using different schemes is a lack of global
>
> > interoperability.  Most if not almost all of the usefulness of IP is due
>
> > to the existence of a single interconnected global network.  But perhaps
>
> > that is explicitly not part of the DTN vision.
>
>
>
> Scott says:
>
> > I'm pretty sure there is no globally embraced DTN vision
>
>
>
> We addressed this in
>
> Lloyd Wood, Peter Holliday, et al. "Sharing the dream: The consensual
> networking hallucination offered by the Bundle Protocol"
>
> Peer-reviewed conference paper, Proceedings of the Workshop on the
> Emergence of Delay-/Disruption-Tolerant Networks (E-DTN), one of a number
> of workshops of the International Conference on Ultra Modern
> Telecommunication (ICUMT), St. Petersburg, Russia, 14 October 2009.
>
> http://dx.doi.org/10.1109/ICUMT.2009.5345655
>
>
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#e-dtn-position
>
>
>
> Really, the bundle protocol exists as an overlay working across both CCSDS
> and IP, as a bulwark to prevent incursion of IP into the space domain by
> claiming interoperability as an overlay of both. CCSDS is the prime
> proponent of the bundle protocol, and any other use or adoption of DTN and
> the bundle protocol is entirely secondary to and providing added support
> for that.
>
>
>
> There's a global vision for the bundle protocol, inasmuch as it meets
> CCSDS needs.
>
>
>
> Lloyd Wood
>
> http://sat-net.com/L.Wood/dtn
>
> ________________________________________
>
> From: dtn-interest <[e-mail]> on behalf of Greg
> Troxel <[e-mail]>
>
> Sent: Wednesday, 10 June 2015 3:55 AM
>
> To: Burleigh, Scott C (312B)
>
> Cc: [e-mail]; Rick Taylor; [e-mail]
>
> Subject: Re: [dtn-interest] [dtn]    DTN static routing
>
>
>
> "Burleigh, Scott C (312B)" <[e-mail]> writes:
>
>
>
> > Greg, strictly speaking, I don't think we're adding a new addressing
>
> > design, because there is no addressing in BP; there is only naming.
>
> > There is no presumption of topological significance in endpoint IDs.
>
> > Likewise, DTN isn't going to use a flat n-bit address space because it
>
> > doesn't use any address space at all.
>
>
>
> I was blurring naming/addressing, which is perhaps my error, but DTN
>
> seems to have only one thing that is some mix of both concepts.
>
>
>
> > More specifically, I don't find the same disconnect that you do.
>
> > We've got self-delimiting numeric values, so why should we have to
>
> > choose between solving the low-bandwidth problem and solving the
>
> > large-network problem?  A numeric node ID can be 3 bytes (or even
>
> > less) for users who need to work over constrained links, and it can be
>
> > 10 bytes for users who have bandwidth to burn.  Let's not "burden"
>
> > either community.
>
>
>
> Implicit in different groups using different schemes is a lack of global
>
> interoperability.  Most if not almost all of the usefulness of IP is due
>
> to the existence of a single interconnected global network.  But perhaps
>
> that is explicitly not part of the DTN vision.
>
> _______________________________________________
>
> dtn-interest mailing list
>
> [e-mail]
>
> https://www.irtf.org/mailman/listinfo/dtn-interest
>
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
>
>