Subject: Re: [dtn-interest] [dtn] DTN static routing

From: Greg Troxel <[email-masked]>
Date: Thu, 04 Jun 2015 09:36:33 -0400

Rick Taylor <[email-masked]> writes:

> For IPv4, I would have an entry like: 10.10.0.0/16 via 10.1.1.1. But in 
> a DTN network, endpoints have string EIDs, with no concept of 
> subnetting.  I know there has been some work on intermediate node ids, 
> but I am not sure if the concept of 'subnetting' or grouping has been 
> explored.
>
> So, yes, static routing seems like a simple topic, but unless every 
> implementation is happy to have a routing table containing a next hop 
> entry for every potentially routeable endpoint, and every dynamic 
> routing protocol is happy to exchange such potentially large sets of 
> routes, there has to be some work done in endpoint 
> aggregation/sub-netting, and this, I suggest, would be the most useful 
> output from any work on static routing in DTNs.

Routing tables and protocols dealing with un-aggregated addresses is a
real issue, but it's the nature of a system that doesn't have aggregated
addresses as a core architectural notion.  We know that IPv4 systems
handle 1E5 routes just fine (and some probably more), and I'm unaware of
anyone doing DTN with more than a tiny fraction of that.

> Hopefully this sounds like work that the IETF should tackle, rather than 
> the IRTF, it seeming more like an 'engineering' task to me.

I think it's firmly a research question.  Specifically, is it really
workable to have a network of world-wide scope without aggegrated
addresses, and if not, how do islands of DTN relate to a feasible
world-wide network?  So far, I haven't seen a DTN system that is more
than 1E3 nodes be feasible and in use for real data.

So perhaps a good question is: what do we have to do to make DTN scale
to larger than how ad hoc networks can scale?

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Jun 2015 14:40:32 +0000

Hi Greg,

> -----Original Message-----
> From: dtn-interest [mailto:[email-masked]] On Behalf Of Greg Troxel
> Sent: Thursday, June 04, 2015 6:37 AM
> To: Rick Taylor
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dtn-interest] [dtn] DTN static routing
> 
> 

The trouble with aggregated addresses and DTN is that aggregation
implies that nodes are either always at home, or that there is a home
network that knows where the nodes are currently located. In DTN,
I think we need to assume that every node is mobile at all times and
rarely at home. So, a completely de-aggregated addressing architecture
may be necessary. Or, at most the addressing architecture would
include an "origin" code that tells where the node originated from,
e.g., similar to the way the area codes of our cellphones tells the
origin even if we are rarely if ever "at home".

About scaling, I have heard that 1E6 routes were within practical operational
scaling limits of BGP routers, but I have no data to back that up.

> to larger than how ad hoc networks can scale?

It is a fair question, and maybe a point of comparison would be with
how modern cellular network systems scale. There are billions of
consumer handheld devices in operation deployments today, and
many/most of these are rarely at home. Instead, they have an N
digit "area code" that indicates the node's origin, and somehow
cellular system routing directs calls to the node's current location.
Can't it be the same (or similar) for DTNs?

Thanks - Fred
[email-masked]

---

From: Greg Troxel <[email-masked]>
Date: Thu, 04 Jun 2015 11:38:27 -0400

> origin even if we are rarely if ever "at home".

Sure, I realize that the "usually home" assumption is unreasonable.
Although "usually" gets more interesting, since it may be that a
human-carried node is often in particular places.  I was really just
trying to pointin out that non-aggregatable addresses are part of what
DTN is, rather than something we haven't written down yet.

A weakness (some see it as a strength) is that DTN so far does not
actually define an addressing architecture at all, but only a mechanism
for representing some addresssing scheme once it is defined.  So having
this discussion about "DTN" is unreasonable; it can only be had about a
particular instantiation of DTN with a concrete addressing plan.

> scaling limits of BGP routers, but I have no data to back that up.

I can believe that - 1E5 and 1E6 are close.  It's 1E10 that's far away
From those numbers (# of devices that speak IP today?).  And I think 1E5
is very far away from what anyone has done with DTN to date.  I'll posit
that 1E2 is the most that's ever happened.  Reference to something
bigger?

> Can't it be the same (or similar) for DTNs?

Cellular is basically like Mobile IP, with calls connected from asking
the home system where the mobile is.  That depends on having
connectivity among the fixed infrastructure, and scales linearly with
the product of #mobiles and network diameter (to report/fetch current
location).  What if all of California had no telephone links out of
state, and all in-state links are ok, and I (from Boston) show up in San
Francisco.  Would someone else from Atlanta who is in LA be able to call
me?  I expect that this would not work.  Even if it did, it would still
be relying on robust inter-site connectivity, much like last-hop wifi
with dynamic addresses.  Arguably (today) telephone numbers are names
and not addresses anyway, so this is not so far off from Dynamic DNS.

So the DTN scaling issue is really like ad hoc networks, where we have
to worry about consumption of link capacity from updates.  But it's more
complicated because we're trying to decide when to hand off bundles or
to duplicate bundles to optimize delivery, when we at best have only a
probabilitstic model of what will happen.  In ad hoc networks, 1000 is a
great victory.  So I am not seeing that this group is on track to define
something that works at Internet scale.

So I think the hard problems in DTN are about scaling and how to behave
when there are only probabalistic assumptions, and we also know that our
assumptions are probably wrong.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Jun 2015 16:14:35 +0000

Hi Greg,

Top posting not to disqualify the good stuff that you wrote, but just to mention
that I have the editor's ball for the address architecture document and have
started to formulate some ideas for that. We will presumably still have the dtn:
URI naming scheme carry forward from Section 4.4 of RFC5050, but then it
seems that we will also need a numeric scheme. 64 bits seems like a reasonable
length, since it provides scaling to large numbers of DTN nodes and fits within
a single SDNV.

What I would like to propose is a numeric addressing scheme where the most
significant 24 bits encode an "origin" code and the remaining 40 bits encode a
"node ID" (I won't draw an ASCII art representation here, because they rarely
come out looking right in email).

In this scheme, the origin code would be akin to a cellphone area code or
an IEEE802 OUI code. Each origin code would correspond to an addressing
authority that assigns node IDs to DTN nodes that "originate" from their
operational jurisdiction (whatever that means). Sort of like the way the
telephone company and network equipment vendors assign node IDs
to the devices they distribute to users.

How the origin code and node ID would interact with routing is an interesting
question, and you spelled out some of the concerns below. But, it seems
likely that routing and addressing will be interdependent at some level.

Thanks - Fred

> From: dtn [mailto:[email-masked]] On Behalf Of Greg Troxel
> Sent: Thursday, June 04, 2015 8:38 AM
> To: Templin, Fred L
> Cc: [email-masked]; Rick Taylor; [email-masked]
> Subject: Re: [dtn] [dtn-interest] DTN static routing
> 
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 4 Jun 2015 21:51:53 +0000

I'm glad to see this important conversation happening.  A couple of comments:

-	Scalability of DTNs is a challenge that I don't think anyone has seriously tackled yet.  A background note: because "late binding" is a central tenet of the Bundle Protocol routing concept, BP endpoint IDs -- much like cell phone numbers (as Greg points out) -- are really names rather than addresses.  We can't have aggregated addresses because we don't have addresses -- the names of destination endpoints cannot be expected to convey any topological information at all.

-	What I think might work is a notion of topological "regions", somewhat analogous to autonomous regions.  A given node might be highly mobile, in terms of its current topological adjacency to other nodes, but its mobility might only rarely take it out of some "region" comprising N nodes that, while mobile, are frequently, briefly in contact with one another and are only infrequently in contact with other nodes (which notionally reside in other "regions").  Building current region ID into the endpoint ID itself seems wrong (you don't change your surname just because you move to Boston), but an infrastructure that tells nodes which regions other nodes reside in might be sufficiently delay-tolerant to work, provided region boundaries are managed in such a way that most nodes rarely change regions.  We'll be prototyping this idea at JPL over the next nine months, but I've got no idea yet how well it can perform.

-	I can see how building a node's initial region of residence (its origin) into its name could somewhat reduce the load on the region information infrastructure; Social Security numbers sort of do that.  (I.e., there's a fair chance that a person with a social security number starting with 218 still lives somewhere in Maryland.  Not everybody moves.)   But requiring that every numeric node ID be 10 bytes long (a 63-bit number fits in a 9-byte SDNV, but you need another byte to pick up that 64th bit) seems harsh; that's a lot of overhead when you're in an environment that offers very limited bandwidth, as is true for a lot of our use cases.  I'm skeptical that the cost is justified.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Thursday, June 4, 2015 9:15 AM
To: Greg Troxel
Cc: [email-masked]; Rick Taylor; [email-masked]
Subject: Re: [dtn] [dtn-interest] DTN static routing

Hi Greg,

Top posting not to disqualify the good stuff that you wrote, but just to mention that I have the editor's ball for the address architecture document and have started to formulate some ideas for that. We will presumably still have the dtn:
URI naming scheme carry forward from Section 4.4 of RFC5050, but then it seems that we will also need a numeric scheme. 64 bits seems like a reasonable length, since it provides scaling to large numbers of DTN nodes and fits within a single SDNV.

What I would like to propose is a numeric addressing scheme where the most significant 24 bits encode an "origin" code and the remaining 40 bits encode a "node ID" (I won't draw an ASCII art representation here, because they rarely come out looking right in email).

In this scheme, the origin code would be akin to a cellphone area code or an IEEE802 OUI code. Each origin code would correspond to an addressing authority that assigns node IDs to DTN nodes that "originate" from their operational jurisdiction (whatever that means). Sort of like the way the telephone company and network equipment vendors assign node IDs to the devices they distribute to users.

How the origin code and node ID would interact with routing is an interesting question, and you spelled out some of the concerns below. But, it seems likely that routing and addressing will be interdependent at some level.

Thanks - Fred

> >> Routing tables and protocols dealing with un-aggregated addresses 
> >> is a real issue, but it's the nature of a system that doesn't have 
> >> aggregated addresses as a core architectural notion.  We know that 
> >> IPv4 systems handle 1E5 routes just fine (and some probably more), 
> >> and I'm unaware of anyone doing DTN with more than a tiny fraction of that.
> >
> > implies that nodes are either always at home, or that there is a 
> > home network that knows where the nodes are currently located. In 
> > DTN, I think we need to assume that every node is mobile at all 
> > times and rarely at home. So, a completely de-aggregated addressing 
> > architecture may be necessary. Or, at most the addressing 
> > architecture would include an "origin" code that tells where the 
> > node originated from, e.g., similar to the way the area codes of our 
> > cellphones tells the origin even if we are rarely if ever "at home".
> 
> actually define an addressing architecture at all, but only a 
> mechanism for representing some addresssing scheme once it is defined.  
> So having this discussion about "DTN" is unreasonable; it can only be 
> had about a particular instantiation of DTN with a concrete addressing plan.
> 
> > About scaling, I have heard that 1E6 routes were within practical 
> > operational scaling limits of BGP routers, but I have no data to back that up.
> 
> From those numbers (# of devices that speak IP today?).  And I think 
> 1E5 is very far away from what anyone has done with DTN to date.  I'll 
> posit that 1E2 is the most that's ever happened.  Reference to 
> something bigger?
> 
> >> I think it's firmly a research question.  Specifically, is it 
> >> really workable to have a network of world-wide scope without 
> >> aggegrated addresses, and if not, how do islands of DTN relate to a 
> >> feasible world-wide network?  So far, I haven't seen a DTN system 
> >> that is more than 1E3 nodes be feasible and in use for real data.
> >>
> >> So perhaps a good question is: what do we have to do to make DTN 
> >> scale to larger than how ad hoc networks can scale?
> >
> > many/most of these are rarely at home. Instead, they have an N digit 
> > "area code" that indicates the node's origin, and somehow cellular 
> > system routing directs calls to the node's current location.
> state, and all in-state links are ok, and I (from Boston) show up in 
> San Francisco.  Would someone else from Atlanta who is in LA be able 
> to call me?  I expect that this would not work.  Even if it did, it 
> would still be relying on robust inter-site connectivity, much like 
> last-hop wifi with dynamic addresses.  Arguably (today) telephone 
> numbers are names and not addresses anyway, so this is not so far off from Dynamic DNS.
> 
> to worry about consumption of link capacity from updates.  But it's 
> more complicated because we're trying to decide when to hand off 
> bundles or to duplicate bundles to optimize delivery, when we at best 
> have only a probabilitstic model of what will happen.  In ad hoc 
> networks, 1000 is a great victory.  So I am not seeing that this group 
> is on track to define something that works at Internet scale.
> 
> So I think the hard problems in DTN are about scaling and how to 
> behave when there are only probabalistic assumptions, and we also know 
> that our assumptions are probably wrong.

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Jun 2015 22:01:38 +0000

Hi Scott,

> From: Burleigh, Scott C (312B) [mailto:[email-masked]]
> Sent: Thursday, June 04, 2015 2:52 PM
> To: Templin, Fred L; Greg Troxel
> Subject: RE: [dtn] [dtn-interest] DTN static routing
> 
> -	Scalability of DTNs is a challenge that I don't think anyone has seriously tackled yet.  A background note: because "late binding"
> is a central tenet of the Bundle Protocol routing concept, BP endpoint IDs -- much like cell phone numbers (as Greg points out) -- are
> really names rather than addresses.  We can't have aggregated addresses because we don't have addresses -- the names of
> destination endpoints cannot be expected to convey any topological information at all.
> 
> -	What I think might work is a notion of topological "regions", somewhat analogous to autonomous regions.  A given node might
> be highly mobile, in terms of its current topological adjacency to other nodes, but its mobility might only rarely take it out of some
> "region" comprising N nodes that, while mobile, are frequently, briefly in contact with one another and are only infrequently in
> contact with other nodes (which notionally reside in other "regions").  Building current region ID into the endpoint ID itself seems
> wrong (you don't change your surname just because you move to Boston), but an infrastructure that tells nodes which regions other
> nodes reside in might be sufficiently delay-tolerant to work, provided region boundaries are managed in such a way that most nodes
> rarely change regions.  We'll be prototyping this idea at JPL over the next nine months, but I've got no idea yet how well it can
> perform.
> 
> -	I can see how building a node's initial region of residence (its origin) into its name could somewhat reduce the load on the
> region information infrastructure; Social Security numbers sort of do that.  (I.e., there's a fair chance that a person with a social
> security number starting with 218 still lives somewhere in Maryland.  Not everybody moves.)   But requiring that every numeric node
> ID be 10 bytes long (a 63-bit number fits in a 9-byte SDNV, but you need another byte to pick up that 64th bit) seems harsh; that's a lot
> of overhead when you're in an environment that offers very limited bandwidth, as is true for a lot of our use cases.  I'm skeptical that
> the cost is justified.

Does the node ID have to appear as an SDNV, or can it be a simple fixed-length
8-byte field much in the same way that IP addresses are fixed-length N-byte fields?
Or, maybe you are saying that even 8bytes is too much?

Thanks - Fred

> Top posting not to disqualify the good stuff that you wrote, but just to mention that I have the editor's ball for the address
> architecture document and have started to formulate some ideas for that. We will presumably still have the dtn:
> URI naming scheme carry forward from Section 4.4 of RFC5050, but then it seems that we will also need a numeric scheme. 64 bits
> seems like a reasonable length, since it provides scaling to large numbers of DTN nodes and fits within a single SDNV.
> 
> What I would like to propose is a numeric addressing scheme where the most significant 24 bits encode an "origin" code and the
> remaining 40 bits encode a "node ID" (I won't draw an ASCII art representation here, because they rarely come out looking right in
> email).
> 
> In this scheme, the origin code would be akin to a cellphone area code or an IEEE802 OUI code. Each origin code would correspond to
> an addressing authority that assigns node IDs to DTN nodes that "originate" from their operational jurisdiction (whatever that means).
> Sort of like the way the telephone company and network equipment vendors assign node IDs to the devices they distribute to users.
> 
> How the origin code and node ID would interact with routing is an interesting question, and you spelled out some of the concerns
> below. But, it seems likely that routing and addressing will be interdependent at some level.
> 
> Thanks - Fred

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 4 Jun 2015 22:39:39 +0000

Hi, Fred.  Yes, I think even 8 bytes is too much.  For space flight operations we've standardized on node numbers in the range 16384-2097151, which all fit into 3-byte SDNVs.  This means that the size of a BP primary block in CBHE form, including current custodian ID, is typically 29 bytes.  Adding 20 bytes to that size (5 extra bytes for each of the 4 node IDs) is a 70% increase.  That's not a big deal when your bundles are megabytes, but custody signals and status reports are virtually always less than 100 bytes; for spacecraft telemetry the bundle payload size will typically be in the range 100-64000 bytes.  Increasing the transmission overhead on a 1000-byte application data unit from 2.9% to 4.9% would matter to many missions.

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, June 4, 2015 3:02 PM
To: Burleigh, Scott C (312B); Greg Troxel
Cc: [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn] [dtn-interest] DTN static routing

Hi Scott,

> is a central tenet of the Bundle Protocol routing concept, BP endpoint 
> IDs -- much like cell phone numbers (as Greg points out) -- are really 
> names rather than addresses.  We can't have aggregated addresses because we don't have addresses -- the names of destination endpoints cannot be expected to convey any topological information at all.
> 
> be highly mobile, in terms of its current topological adjacency to 
> other nodes, but its mobility might only rarely take it out of some 
> "region" comprising N nodes that, while mobile, are frequently, 
> briefly in contact with one another and are only infrequently in 
> contact with other nodes (which notionally reside in other "regions").  
> Building current region ID into the endpoint ID itself seems wrong 
> (you don't change your surname just because you move to Boston), but an infrastructure that tells nodes which regions other nodes reside in might be sufficiently delay-tolerant to work, provided region boundaries are managed in such a way that most nodes rarely change regions.  We'll be prototyping this idea at JPL over the next nine months, but I've got no idea yet how well it can perform.
> 
> ID be 10 bytes long (a 63-bit number fits in a 9-byte SDNV, but you 
> need another byte to pick up that 64th bit) seems harsh; that's a lot 
> of overhead when you're in an environment that offers very limited bandwidth, as is true for a lot of our use cases.  I'm skeptical that the cost is justified.

Does the node ID have to appear as an SDNV, or can it be a simple fixed-length 8-byte field much in the same way that IP addresses are fixed-length N-byte fields?
Or, maybe you are saying that even 8bytes is too much?

Thanks - Fred

> Top posting not to disqualify the good stuff that you wrote, but just 
> to mention that I have the editor's ball for the address architecture document and have started to formulate some ideas for that. We will presumably still have the dtn:
> URI naming scheme carry forward from Section 4.4 of RFC5050, but then 
> it seems that we will also need a numeric scheme. 64 bits seems like a reasonable length, since it provides scaling to large numbers of DTN nodes and fits within a single SDNV.
> 
> What I would like to propose is a numeric addressing scheme where the 
> most significant 24 bits encode an "origin" code and the remaining 40 
> bits encode a "node ID" (I won't draw an ASCII art representation here, because they rarely come out looking right in email).
> 
> In this scheme, the origin code would be akin to a cellphone area code 
> or an IEEE802 OUI code. Each origin code would correspond to an addressing authority that assigns node IDs to DTN nodes that "originate" from their operational jurisdiction (whatever that means).
> How the origin code and node ID would interact with routing is an 
> interesting question, and you spelled out some of the concerns below. But, it seems likely that routing and addressing will be interdependent at some level.
> 
> Thanks - Fred
> > >> is a real issue, but it's the nature of a system that doesn't 
> > >> have aggregated addresses as a core architectural notion.  We 
> > >> know that
> > >> IPv4 systems handle 1E5 routes just fine (and some probably 
> > >> more), and I'm unaware of anyone doing DTN with more than a tiny fraction of that.
> > >
> > > times and rarely at home. So, a completely de-aggregated 
> > > addressing architecture may be necessary. Or, at most the 
> > > addressing architecture would include an "origin" code that tells 
> > > where the node originated from, e.g., similar to the way the area 
> > > codes of our cellphones tells the origin even if we are rarely if ever "at home".
> >
> > trying to pointin out that non-aggregatable addresses are part of 
> > what DTN is, rather than something we haven't written down yet.
> >
> > So having this discussion about "DTN" is unreasonable; it can only 
> > be had about a particular instantiation of DTN with a concrete addressing plan.
> >
> > I can believe that - 1E5 and 1E6 are close.  It's 1E10 that's far 
> > away From those numbers (# of devices that speak IP today?).  And I 
> > think
> > 1E5 is very far away from what anyone has done with DTN to date.  
> > I'll posit that 1E2 is the most that's ever happened.  Reference to 
> > something bigger?
> >
> > >> aggegrated addresses, and if not, how do islands of DTN relate to 
> > >> a feasible world-wide network?  So far, I haven't seen a DTN 
> > >> system that is more than 1E3 nodes be feasible and in use for real data.
> > >>
> > > It is a fair question, and maybe a point of comparison would be 
> > > with how modern cellular network systems scale. There are billions 
> > > of consumer handheld devices in operation deployments today, and 
> > Cellular is basically like Mobile IP, with calls connected from 
> > asking the home system where the mobile is.  That depends on having 
> > connectivity among the fixed infrastructure, and scales linearly 
> > with the product of #mobiles and network diameter (to report/fetch 
> > current location).  What if all of California had no telephone links 
> > out of state, and all in-state links are ok, and I (from Boston) 
> > show up in San Francisco.  Would someone else from Atlanta who is in 
> > LA be able to call me?  I expect that this would not work.  Even if 
> > it did, it would still be relying on robust inter-site connectivity, 
> > much like last-hop wifi with dynamic addresses.  Arguably (today) 
> > telephone numbers are names and not addresses anyway, so this is not so far off from Dynamic DNS.
> >
> > So the DTN scaling issue is really like ad hoc networks, where we 
> > have to worry about consumption of link capacity from updates.  But 
> > it's more complicated because we're trying to decide when to hand 
> > off bundles or to duplicate bundles to optimize delivery, when we at 
> > best have only a probabilitstic model of what will happen.  In ad 
> > hoc networks, 1000 is a great victory.  So I am not seeing that this 
> > group is on track to define something that works at Internet scale.
> >
> > behave when there are only probabalistic assumptions, and we also 
> > know that our assumptions are probably wrong.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Jun 2015 22:52:55 +0000

Hi Scott,

> Sent: Thursday, June 04, 2015 3:40 PM
> Hi, Fred.  Yes, I think even 8 bytes is too much.  For space flight operations we've standardized on node numbers in the range 16384-
> 2097151, which all fit into 3-byte SDNVs.  This means that the size of a BP primary block in CBHE form, including current custodian ID, is
> typically 29 bytes.  Adding 20 bytes to that size (5 extra bytes for each of the 4 node IDs) is a 70% increase.  That's not a big deal when
> your bundles are megabytes, but custody signals and status reports are virtually always less than 100 bytes; for spacecraft telemetry
> the bundle payload size will typically be in the range 100-64000 bytes.  Increasing the transmission overhead on a 1000-byte application
> data unit from 2.9% to 4.9% would matter to many missions.

OK, then for this reason can I assume that you think we need a numeric scheme
in addition to (or instead of) a dtn: URI scheme? If both, then do we need some
sort of URI-to-numeric name resolution system - a DNS for DTN?

Thanks - Fred

> > names rather than addresses.  We can't have aggregated addresses because we don't have addresses -- the names of destination
> endpoints cannot be expected to convey any topological information at all.
> >
> > (you don't change your surname just because you move to Boston), but an infrastructure that tells nodes which regions other nodes
> reside in might be sufficiently delay-tolerant to work, provided region boundaries are managed in such a way that most nodes rarely
> change regions.  We'll be prototyping this idea at JPL over the next nine months, but I've got no idea yet how well it can perform.
> >
> > it seems that we will also need a numeric scheme. 64 bits seems like a reasonable length, since it provides scaling to large numbers
> of DTN nodes and fits within a single SDNV.
> >
> > or an IEEE802 OUI code. Each origin code would correspond to an addressing authority that assigns node IDs to DTN nodes that
> "originate" from their operational jurisdiction (whatever that means).

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 4 Jun 2015 23:13:12 +0000

Right, I do absolutely favor a numeric node ID scheme, i.e., CBHE (RFC 6260) relies on the "ipn" scheme.  At the same time, I recognize that a lot of people see a lot of value in the dtn-scheme string IDs for other kinds of use cases, so I'm not arguing to replace that scheme; I think we can engineer things so that numeric and string endpoint IDs can productively coexist.

And I can imagine that for many purposes it might be helpful for a given node to be identified both by a numeric-scheme URI and a string-scheme URI.  I have an partially-baked notion that the region information infrastructure I proposed earlier could be extended to include this sort of non-volatile ID association as well, maybe eventually morphing into something like DNS but much less dynamic.

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, June 4, 2015 3:53 PM
To: Burleigh, Scott C (312B); Greg Troxel
Cc: [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn] [dtn-interest] DTN static routing

Hi Scott,

> Hi, Fred.  Yes, I think even 8 bytes is too much.  For space flight 
> operations we've standardized on node numbers in the range 16384- 
> 2097151, which all fit into 3-byte SDNVs.  This means that the size of 
> a BP primary block in CBHE form, including current custodian ID, is 
> typically 29 bytes.  Adding 20 bytes to that size (5 extra bytes for 
> each of the 4 node IDs) is a 70% increase.  That's not a big deal when your bundles are megabytes, but custody signals and status reports are virtually always less than 100 bytes; for spacecraft telemetry the bundle payload size will typically be in the range 100-64000 bytes.  Increasing the transmission overhead on a 1000-byte application data unit from 2.9% to 4.9% would matter to many missions.

OK, then for this reason can I assume that you think we need a numeric scheme in addition to (or instead of) a dtn: URI scheme? If both, then do we need some sort of URI-to-numeric name resolution system - a DNS for DTN?

Thanks - Fred

> > is a central tenet of the Bundle Protocol routing concept, BP 
> > endpoint IDs -- much like cell phone numbers (as Greg points out) -- 
> > are really names rather than addresses.  We can't have aggregated 
> > addresses because we don't have addresses -- the names of 
> > destination
> > (you don't change your surname just because you move to Boston), but 
> > an infrastructure that tells nodes which regions other nodes
> reside in might be sufficiently delay-tolerant to work, provided 
> region boundaries are managed in such a way that most nodes rarely change regions.  We'll be prototyping this idea at JPL over the next nine months, but I've got no idea yet how well it can perform.
> >
> > need another byte to pick up that 64th bit) seems harsh; that's a 
> > lot of overhead when you're in an environment that offers very 
> > limited bandwidth, as is true for a lot of our use cases.  I'm 
> > skeptical
> that the cost is justified.
> 
> Does the node ID have to appear as an SDNV, or can it be a simple 
> fixed-length 8-byte field much in the same way that IP addresses are fixed-length N-byte fields?
> > Top posting not to disqualify the good stuff that you wrote, but 
> > just to mention that I have the editor's ball for the address architecture document and have started to formulate some ideas for that.
> We will presumably still have the dtn:
> > URI naming scheme carry forward from Section 4.4 of RFC5050, but 
> > then it seems that we will also need a numeric scheme. 64 bits seems 
> > like a reasonable length, since it provides scaling to large numbers
> > What I would like to propose is a numeric addressing scheme where 
> > the most significant 24 bits encode an "origin" code and the 
> > remaining 40 bits encode a "node ID" (I won't draw an ASCII art representation here, because they rarely come out looking right in email).
> >
> > In this scheme, the origin code would be akin to a cellphone area 
> > code or an IEEE802 OUI code. Each origin code would correspond to an 
> > addressing authority that assigns node IDs to DTN nodes that
> > Sort of like the way the telephone company and network equipment 
> > vendors assign node IDs to the devices they distribute to
> users.
> >
> > interesting question, and you spelled out some of the concerns 
> > > >> Routing tables and protocols dealing with un-aggregated 
> > > >> addresses is a real issue, but it's the nature of a system that 
> > > >> doesn't have aggregated addresses as a core architectural 
> > > >> notion.  We know that
> > > > The trouble with aggregated addresses and DTN is that 
> > > > aggregation implies that nodes are either always at home, or 
> > > > that there is a home network that knows where the nodes are 
> > > > currently located. In DTN, I think we need to assume that every 
> > > > node is mobile at all times and rarely at home. So, a completely 
> > > > de-aggregated addressing architecture may be necessary. Or, at 
> > > > most the addressing architecture would include an "origin" code 
> > > > that tells where the node originated from, e.g., similar to the 
> > > > way the area codes of our cellphones tells the origin even if we are rarely if ever "at home".
> > >
> > > human-carried node is often in particular places.  I was really 
> > > just trying to pointin out that non-aggregatable addresses are 
> > > part of what DTN is, rather than something we haven't written down yet.
> > >
> > > > About scaling, I have heard that 1E6 routes were within 
> > > > practical operational scaling limits of BGP routers, but I have no data to back that up.
> > >
> > > away From those numbers (# of devices that speak IP today?).  And 
> > > I think
> > > I'll posit that 1E2 is the most that's ever happened.  Reference 
> > > to something bigger?
> > >
> > > >> aggegrated addresses, and if not, how do islands of DTN relate 
> > > >> to a feasible world-wide network?  So far, I haven't seen a DTN 
> > > >> So perhaps a good question is: what do we have to do to make 
> > > >> DTN scale to larger than how ad hoc networks can scale?
> > > >
> > > > with how modern cellular network systems scale. There are 
> > > > billions of consumer handheld devices in operation deployments 
> > > > today, and many/most of these are rarely at home. Instead, they 
> > > > have an N digit "area code" that indicates the node's origin, 
> > > > and somehow cellular system routing directs calls to the node's current location.
> > > asking the home system where the mobile is.  That depends on 
> > > having connectivity among the fixed infrastructure, and scales 
> > > linearly with the product of #mobiles and network diameter (to 
> > > report/fetch current location).  What if all of California had no 
> > > telephone links out of state, and all in-state links are ok, and I 
> > > (from Boston) show up in San Francisco.  Would someone else from 
> > > Atlanta who is in LA be able to call me?  I expect that this would 
> > > not work.  Even if it did, it would still be relying on robust 
> > > inter-site connectivity, much like last-hop wifi with dynamic 
> > > addresses.  Arguably (today) telephone numbers are names and not addresses anyway, so this is not so far off from Dynamic DNS.
> > >
> > > have to worry about consumption of link capacity from updates.  
> > > But it's more complicated because we're trying to decide when to 
> > > hand off bundles or to duplicate bundles to optimize delivery, 
> > > when we at best have only a probabilitstic model of what will 
> > > happen.  In ad hoc networks, 1000 is a great victory.  So I am not 
> > > seeing that this group is on track to define something that works at Internet scale.
> > >

---

From: Greg Troxel <[email-masked]>
Date: Tue, 09 Jun 2015 11:05:23 -0400

Adding a new addressing design at the document revision stage seems like
it's a much bigger change than most people are contemplating.

The notion of a split between adresss assignment authority and node
address does not sound unreasonable, but it feels like taking only a few
steps down the path to later reinventing CIDR.  That makes me wonder
why, if DTN is going to use a flat n-bit address space, it shouldn't
just use IPv6 addresses, with the notion being that people should get a
v6 address and then just use it, rather than requiring an entirely new
allocation mechanism.

I am finding a disconnect between the notion that 64 bits is too big for
space on one hand and planning for global scale on the other.  Which
problem is this group solving?  Should the bit-contrained users be using
some address compression scheme on the links, to avoid burdening the
global scale users with too small an address space?

Of course, the big problem is how to achieve global scale at all, not
exactly how many bits will be needed.   The needed size will likely
depend on the scaling scheme anyway.  But it feels like choosing 64 bits
has a decent chance of being limiting.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 9 Jun 2015 17:49:57 +0000

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.

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.

Scott

-----Original Message-----
From: dtn-interest [mailto:[email-masked]] On Behalf Of Greg Troxel
Sent: Tuesday, June 9, 2015 8:05 AM
To: Templin, Fred L
Cc: [email-masked]; Rick Taylor; [email-masked]
Subject: Re: [dtn-interest] [dtn] DTN static routing

Adding a new addressing design at the document revision stage seems like it's a much bigger change than most people are contemplating.

The notion of a split between adresss assignment authority and node address does not sound unreasonable, but it feels like taking only a few steps down the path to later reinventing CIDR.  That makes me wonder why, if DTN is going to use a flat n-bit address space, it shouldn't just use IPv6 addresses, with the notion being that people should get a
v6 address and then just use it, rather than requiring an entirely new allocation mechanism.

I am finding a disconnect between the notion that 64 bits is too big for space on one hand and planning for global scale on the other.  Which problem is this group solving?  Should the bit-contrained users be using some address compression scheme on the links, to avoid burdening the global scale users with too small an address space?

Of course, the big problem is how to achieve global scale at all, not
exactly how many bits will be needed.   The needed size will likely
depend on the scaling scheme anyway.  But it feels like choosing 64 bits has a decent chance of being limiting.

---

From: Greg Troxel <[email-masked]>
Date: Tue, 09 Jun 2015 13:55:34 -0400

"Burleigh, Scott C (312B)" <[email-masked]> 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.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 9 Jun 2015 18:21:31 +0000

I'm pretty sure there is no globally embraced DTN vision, but my own vision for DTN definitely extends (eventually) to a single interconnected global network of interoperating entities.  I don't think the mechanism I've been talking about is incompatible with that, though.

I am abundantly aware that there are plenty of people in the DTN community who see lots of value in using what I would consider lengthy character strings to identify nodes and endpoints.  I myself am not a fan, but that doesn't mean that everybody else is wrong, nor that I'm wrong.  The ION and DTN2 and (I think) IBR-DTN implementations of BP can forward and acquire bundles tagged with both types of IDs.  I think global interoperability isn't necessarily threatened by BP's tolerance of different naming schemes.

Coming back to numeric ID sizes in particular: I can imagine a spacecraft orbiting Phobos that is identified by a 3-byte SDNV numeric node ID, communicating with other orbiters and landers in the Mars-Phobos system that are likewise identified by 3-byte node IDs, and sending images to an imaging spectrometer's Principal Investigator in Chicago who receives science data at an iPad-based BP node identified by a 10-digit node ID.  The brief data exchanges among the space assets impose minimal overhead on their communication channels, while the larger overhead on the science data return bundles is amortized over the larger size of the images.  I don't think this is difficult.

Scott

-----Original Message-----
From: Greg Troxel [mailto:[email-masked]] 
Sent: Tuesday, June 9, 2015 10:56 AM
To: Burleigh, Scott C (312B)
Cc: Templin, Fred L; [email-masked]; Rick Taylor; [email-masked]
Subject: Re: [dtn-interest] [dtn] DTN static routing

...

> 10 bytes for users who have bandwidth to burn.  Let's not "burden"

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.

---

From: <[email-masked]>
Date: Wed, 10 Jun 2015 02:13:56 +0000

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 <[email-masked]> on behalf of Greg Troxel <[email-masked]>
Sent: Wednesday, 10 June 2015 3:55 AM
To: Burleigh, Scott C (312B)
Cc: [email-masked]; Rick Taylor; [email-masked]
Subject: Re: [dtn-interest] [dtn]    DTN static routing

---

From: "Scott, Keith L." <[email-masked]>
Date: Wed, 10 Jun 2015 14:14:12 +0000

[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:      +1.703.983.7142
Communications Network Engineering & Analysis                     Email: [email-masked]
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:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 09, 2015 10:14 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] [dtn] DTN static routing

We addressed this in

Lloyd Wood

From: dtn-interest <[email-masked]<mailto:[email-masked]>> on behalf of Greg Troxel <[email-masked]<mailto:[email-masked]>>

Cc: [email-masked]<mailto:[email-masked]>; Rick Taylor; [email-masked]<mailto:[email-masked]>

dtn-interest mailing list

[email-masked]<mailto:[email-masked]>

https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Jun 2015 15:56:06 +0000

Hi Scott,

> Sent: Tuesday, June 09, 2015 11:22 AM
> To: Greg Troxel
> Subject: RE: [dtn-interest] [dtn] DTN static routing
> 
> I'm pretty sure there is no globally embraced DTN vision, but my own vision for DTN definitely extends (eventually) to a single
> interconnected global network of interoperating entities.  I don't think the mechanism I've been talking about is incompatible with
> that, though.
> 
> I am abundantly aware that there are plenty of people in the DTN community who see lots of value in using what I would consider
> lengthy character strings to identify nodes and endpoints.  I myself am not a fan, but that doesn't mean that everybody else is wrong,
> nor that I'm wrong.  The ION and DTN2 and (I think) IBR-DTN implementations of BP can forward and acquire bundles tagged with
> both types of IDs.  I think global interoperability isn't necessarily threatened by BP's tolerance of different naming schemes.
> 
> Coming back to numeric ID sizes in particular: I can imagine a spacecraft orbiting Phobos that is identified by a 3-byte SDNV numeric
> node ID, communicating with other orbiters and landers in the Mars-Phobos system that are likewise identified by 3-byte node IDs,
> and sending images to an imaging spectrometer's Principal Investigator in Chicago who receives science data at an iPad-based BP node
> identified by a 10-digit node ID.  The brief data exchanges among the space assets impose minimal overhead on their communication
> channels, while the larger overhead on the science data return bundles is amortized over the larger size of the images.  I don't think
> this is difficult.

So, how would it be if there were a 64-bit universal addressing/naming scheme and
a 16-bit local-use addressing/naming scheme? All nodes would get a 64-bit universal
address/name assignment, but would use an administratively assigned 16-bit local
address/name within a limited-scope DTN. It wouldn't be too far different from the
way IPv4 has both global scope and RFC1918 privacy addresses. The privacy addresses
need only be unique within the local network, and may be reused in countless other
standalone local networks. Later, when multiple local networks are bridged together
to form a larger DTN, they would have to deprecate their local addresses/names and
begin using their universal addresses/names. What do you think?

Thanks - Fred

> 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.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 10 Jun 2015 16:06:22 +0000

Hi, Fred.  I don't think the additional complexity is necessary.  What's wrong with using variable-length numbers and strings as permanent node identifiers, without declaring any topological information at all, and relying on late binding for "addressing"?

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2015 8:56 AM
To: Burleigh, Scott C (312B); Greg Troxel
Cc: [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Hi Scott,

> I'm pretty sure there is no globally embraced DTN vision, but my own 
> vision for DTN definitely extends (eventually) to a single 
> interconnected global network of interoperating entities.  I don't think the mechanism I've been talking about is incompatible with that, though.
> 
> I am abundantly aware that there are plenty of people in the DTN 
> community who see lots of value in using what I would consider lengthy 
> character strings to identify nodes and endpoints.  I myself am not a 
> fan, but that doesn't mean that everybody else is wrong, nor that I'm wrong.  The ION and DTN2 and (I think) IBR-DTN implementations of BP can forward and acquire bundles tagged with both types of IDs.  I think global interoperability isn't necessarily threatened by BP's tolerance of different naming schemes.
> 
> Coming back to numeric ID sizes in particular: I can imagine a 
> spacecraft orbiting Phobos that is identified by a 3-byte SDNV numeric 
> node ID, communicating with other orbiters and landers in the 
> Mars-Phobos system that are likewise identified by 3-byte node IDs, 
> and sending images to an imaging spectrometer's Principal Investigator 
> in Chicago who receives science data at an iPad-based BP node identified by a 10-digit node ID.  The brief data exchanges among the space assets impose minimal overhead on their communication channels, while the larger overhead on the science data return bundles is amortized over the larger size of the images.  I don't think this is difficult.

So, how would it be if there were a 64-bit universal addressing/naming scheme and a 16-bit local-use addressing/naming scheme? All nodes would get a 64-bit universal address/name assignment, but would use an administratively assigned 16-bit local address/name within a limited-scope DTN. It wouldn't be too far different from the way IPv4 has both global scope and RFC1918 privacy addresses. The privacy addresses need only be unique within the local network, and may be reused in countless other standalone local networks. Later, when multiple local networks are bridged together to form a larger DTN, they would have to deprecate their local addresses/names and begin using their universal addresses/names. What do you think?

Thanks - Fred

> 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.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Jun 2015 16:25:24 +0000

Hi Scott,

> Sent: Wednesday, June 10, 2015 9:06 AM
> Hi, Fred.  I don't think the additional complexity is necessary.

IMHO, what I proposed is simple and natural. We have an existence
proof in IPv4 privacy addressing and to a certain extent also IPv6
unique local addressing.

> What's wrong with using variable-length numbers and strings as
> permanent node identifiers,

The problem is that the node IDs need to be managed for uniqueness within
the DTN domain they will be operating in. When the domain of operation is
universal-scope, who is to say that we should give a 16-bit universally unique
node ID to a sensor node mote but then only give a 64-bit ID to an aircraft
carrier? Seems backwards.

> without declaring any topological information at all, and relying on late binding for "addressing"?

I am fine with no topological information - I never suggested it. Still having
the late binding for addressing is also fine. But, it would be much simpler to
assign universally unique numeric names if they came from the same 64-bit
naming space (and then use a 16-bit locally assigned numeric name for
limited-scope operation.

Thanks - Fred

> > fan, but that doesn't mean that everybody else is wrong, nor that I'm wrong.  The ION and DTN2 and (I think) IBR-DTN
> implementations of BP can forward and acquire bundles tagged with both types of IDs.  I think global interoperability isn't necessarily
> threatened by BP's tolerance of different naming schemes.
> >
> > in Chicago who receives science data at an iPad-based BP node identified by a 10-digit node ID.  The brief data exchanges among the
> space assets impose minimal overhead on their communication channels, while the larger overhead on the science data return
> bundles is amortized over the larger size of the images.  I don't think this is difficult.
> 
> So, how would it be if there were a 64-bit universal addressing/naming scheme and a 16-bit local-use addressing/naming scheme? All
> nodes would get a 64-bit universal address/name assignment, but would use an administratively assigned 16-bit local address/name
> within a limited-scope DTN. It wouldn't be too far different from the way IPv4 has both global scope and RFC1918 privacy addresses.
> The privacy addresses need only be unique within the local network, and may be reused in countless other standalone local networks.
> Later, when multiple local networks are bridged together to form a larger DTN, they would have to deprecate their local
> addresses/names and begin using their universal addresses/names. What do you think?
> 
> Thanks - Fred
> > 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.

---

From: "Torgerson, Jordan L (332M)" <[email-masked]>
Date: Wed, 10 Jun 2015 16:41:52 +0000

Just an historical note for consideration: In 1999 or 2000, at one of the
first IPN study meetings which was attended by Vint, as well as folks from
USC and UCLA, we talked about addressing in the context of coupling a
network at Mars with the Earth's network, and quickly realized that if
Mars had the same address space as Earth, the entire communications trunk
between Mars and Earth would be taken up by DNS update traffic.

So that was one of the reasons that DTN was conceived as an overlay
network with gateways in to local address spaces.

This whole thread talking about some universal DTN naming scheme kinda
sounds like people are going down that path again...I guess we COULD do
some globally-scalable addressing system, and then reinvent yet another
overlay network on top of DTN to take care of naming scheme updates and
routing scheme complexities..

It's turtles all the way down.

Leigh

On 6/10/15, 9:25 AM, "Templin, Fred L" <[email-masked]> wrote:

>> > interconnected global network of interoperating entities.  I don't
>>think the mechanism I've been talking about is incompatible with
>> that, though.
>> >
>> > fan, but that doesn't mean that everybody else is wrong, nor that I'm
>>wrong.  The ION and DTN2 and (I think) IBR-DTN
>> implementations of BP can forward and acquire bundles tagged with both
>>types of IDs.  I think global interoperability isn't necessarily
>> > in Chicago who receives science data at an iPad-based BP node
>>identified by a 10-digit node ID.  The brief data exchanges among the
>> space assets impose minimal overhead on their communication channels,
>>while the larger overhead on the science data return
>> So, how would it be if there were a 64-bit universal addressing/naming
>>scheme and a 16-bit local-use addressing/naming scheme? All
>> nodes would get a 64-bit universal address/name assignment, but would
>>use an administratively assigned 16-bit local address/name
>> within a limited-scope DTN. It wouldn't be too far different from the
>>way IPv4 has both global scope and RFC1918 privacy addresses.
>> The privacy addresses need only be unique within the local network, and
>>may be reused in countless other standalone local networks.
>> Later, when multiple local networks are bridged together to form a
>>larger DTN, they would have to deprecate their local
>> > global interoperability.  Most if not almost all of the usefulness of
>>IP is due to the existence of a single interconnected global
>[email-masked]

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 10 Jun 2015 16:49:56 +0000

Fred, I still don't understand the problem. What we've already got defined for the "ipn" scheme (for example) is a 64-bit numeric node name space, of which subsets are allocated to various administrative entities for assignment to the nodes they instantiate; the CCSDS Space Assigned Numbers Authority has been allocated the range 2^14 through (2^21)-1, and there's a procedure for allocating other ranges to whoever needs them.  But in over-the-wire representation we are able to economize on transmission by omitting a lot of leading zeroes, because we represent them as SDNVs.  How does this not achieve the objectives you're aiming for?

Scott 

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2015 9:25 AM
To: Burleigh, Scott C (312B); Greg Troxel
Cc: [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Hi Scott,

> Hi, Fred.  I don't think the additional complexity is necessary.

IMHO, what I proposed is simple and natural. We have an existence proof in IPv4 privacy addressing and to a certain extent also IPv6 unique local addressing.

> permanent node identifiers,

The problem is that the node IDs need to be managed for uniqueness within the DTN domain they will be operating in. When the domain of operation is universal-scope, who is to say that we should give a 16-bit universally unique node ID to a sensor node mote but then only give a 64-bit ID to an aircraft carrier? Seems backwards.

> without declaring any topological information at all, and relying on late binding for "addressing"?

I am fine with no topological information - I never suggested it. Still having the late binding for addressing is also fine. But, it would be much simpler to assign universally unique numeric names if they came from the same 64-bit naming space (and then use a 16-bit locally assigned numeric name for limited-scope operation.

Thanks - Fred

> > community who see lots of value in using what I would consider 
> > lengthy character strings to identify nodes and endpoints.  I myself 
> > am not a fan, but that doesn't mean that everybody else is wrong, 
> > nor that I'm wrong.  The ION and DTN2 and (I think) IBR-DTN
> types of IDs.  I think global interoperability isn't necessarily threatened by BP's tolerance of different naming schemes.
> >
> > spacecraft orbiting Phobos that is identified by a 3-byte SDNV 
> > numeric node ID, communicating with other orbiters and landers in 
> > the Mars-Phobos system that are likewise identified by 3-byte node 
> > IDs, and sending images to an imaging spectrometer's Principal 
> > Investigator in Chicago who receives science data at an iPad-based 
> > BP node identified by a 10-digit node ID.  The brief data exchanges 
> > among the
> while the larger overhead on the science data return bundles is amortized over the larger size of the images.  I don't think this is difficult.
> 
> scheme and a 16-bit local-use addressing/naming scheme? All nodes 
> would get a 64-bit universal address/name assignment, but would use an administratively assigned 16-bit local address/name within a limited-scope DTN. It wouldn't be too far different from the way IPv4 has both global scope and RFC1918 privacy addresses.
> larger DTN, they would have to deprecate their local addresses/names and begin using their universal addresses/names. What do you think?
> 
> Thanks - Fred
> > global interoperability.  Most if not almost all of the usefulness 
> > of IP is due to the existence of a single interconnected global

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Jun 2015 16:55:56 +0000

Hi Leigh,

> From: Torgerson, Jordan L (332M) [mailto:[email-masked]]
> Sent: Wednesday, June 10, 2015 9:42 AM
> To: Templin, Fred L; Burleigh, Scott C (312B); Greg Troxel

15 years is a long time between formulation of the problem space and
finally coming around to working on a solution! :^}

Joining multiple DTNs together to form one larger DTN is exactly why
we ned a universal numeric naming scheme because it avoids network
renumbering and avoids dynamic updates to the name resolution
system (be it DNS or some DTN equivalent of DNS).

> sounds like people are going down that path again...I guess we COULD do

I don't know how to do large DTNs (say, on the same scale as the terrestrial
Internet) without having some kind of universal DTN naming scheme.

> routing scheme complexities..

No, not at all. One DTN overlay and no standing on the backs of turtles.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Jun 2015 17:03:34 +0000

Hi Scott,

> Sent: Wednesday, June 10, 2015 9:50 AM
> Fred, I still don't understand the problem. What we've already got defined for the "ipn" scheme (for example) is a 64-bit numeric
> node name space, of which subsets are allocated to various administrative entities for assignment to the nodes they instantiate;

That is the same as I suggested by having a 24-bit "origin" code as the leading 24bits of
the numeric node ID. CCSDS would have one such origin code.

> CCSDS Space Assigned Numbers Authority has been allocated the range 2^14 through (2^21)-1, and there's a procedure for allocating
> other ranges to whoever needs them.  But in over-the-wire representation we are able to economize on transmission by omitting a
> lot of leading zeroes, because we represent them as SDNVs.  How does this not achieve the objectives you're aiming for?

It means that only early adopters would have compressible strings of 0's in the leading
bits of the 64-bit field. Latecomers will not be able to take advantage of the optimization.
Latecomers with low-end devices that operate over underprivileged links will suffer
most of all. I guess I am also of the opinion that this system should not be optimized
to suit the specific needs of just one or a few privileged entities like CCSDS.

Thanks - Fred

> The problem is that the node IDs need to be managed for uniqueness within the DTN domain they will be operating in. When the
> domain of operation is universal-scope, who is to say that we should give a 16-bit universally unique node ID to a sensor node mote
> but then only give a 64-bit ID to an aircraft carrier? Seems backwards.
> 
> I am fine with no topological information - I never suggested it. Still having the late binding for addressing is also fine. But, it would be
> much simpler to assign universally unique numeric names if they came from the same 64-bit naming space (and then use a 16-bit
> locally assigned numeric name for limited-scope operation.
> 
> Thanks - Fred
> > would get a 64-bit universal address/name assignment, but would use an administratively assigned 16-bit local address/name within
> a limited-scope DTN. It wouldn't be too far different from the way IPv4 has both global scope and RFC1918 privacy addresses.

---

From: "Torgerson, Jordan L (332M)" <[email-masked]>
Date: Wed, 10 Jun 2015 17:03:22 +0000

thanks - good points Fred.

On 6/10/15, 9:55 AM, "Templin, Fred L" <[email-masked]> wrote:

>>lengthy
>>numeric
>> >> bundles is amortized over the larger size of the images.  I don't
>>think
>> >>this is difficult.
>> >>
>> >> > > less) for users who need to work over constrained links, and it
>>can
>> >> > > be
>>of

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 10 Jun 2015 17:23:16 +0000

Okay, I think I'm getting a better understanding.  Your objection isn't that the current "ipn" node numbering scheme (for example) isn't global or that it isn't interoperable - it's that it isn't fair, correct?  Some user communities get to use brief node IDs because they grabbed all the ranges of short numbers, and everybody else has to get by with long numbers.  So the fair thing is to require that everybody use long numbers, yes?

This is a reasonable perspective, but I disagree.

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2015 10:04 AM
To: Burleigh, Scott C (312B); Greg Troxel
Cc: [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Hi Scott,

> Fred, I still don't understand the problem. What we've already got 
> defined for the "ipn" scheme (for example) is a 64-bit numeric node 
> name space, of which subsets are allocated to various administrative 
> entities for assignment to the nodes they instantiate;

That is the same as I suggested by having a 24-bit "origin" code as the leading 24bits of the numeric node ID. CCSDS would have one such origin code.

> CCSDS Space Assigned Numbers Authority has been allocated the range 
> 2^14 through (2^21)-1, and there's a procedure for allocating other 
> ranges to whoever needs them.  But in over-the-wire representation we are able to economize on transmission by omitting a lot of leading zeroes, because we represent them as SDNVs.  How does this not achieve the objectives you're aiming for?

It means that only early adopters would have compressible strings of 0's in the leading bits of the 64-bit field. Latecomers will not be able to take advantage of the optimization.
Latecomers with low-end devices that operate over underprivileged links will suffer most of all. I guess I am also of the opinion that this system should not be optimized to suit the specific needs of just one or a few privileged entities like CCSDS.

Thanks - Fred

> proof in IPv4 privacy addressing and to a certain extent also IPv6 unique local addressing.
> 
> The problem is that the node IDs need to be managed for uniqueness 
> within the DTN domain they will be operating in. When the domain of 
> operation is universal-scope, who is to say that we should give a 16-bit universally unique node ID to a sensor node mote but then only give a 64-bit ID to an aircraft carrier? Seems backwards.
> 
> I am fine with no topological information - I never suggested it. 
> Still having the late binding for addressing is also fine. But, it 
> would be much simpler to assign universally unique numeric names if they came from the same 64-bit naming space (and then use a 16-bit locally assigned numeric name for limited-scope operation.
> 
> Thanks - Fred
> > > I'm pretty sure there is no globally embraced DTN vision, but my 
> > > own vision for DTN definitely extends (eventually) to a single 
> > > lengthy character strings to identify nodes and endpoints.  I 
> > > myself am not a fan, but that doesn't mean that everybody else is 
> > > wrong, nor that I'm wrong.  The ION and DTN2 and (I think) IBR-DTN
> > implementations of BP can forward and acquire bundles tagged with 
> > > BP node identified by a 10-digit node ID.  The brief data 
> > > exchanges among the
> > space assets impose minimal overhead on their communication 
> > channels, while the larger overhead on the science data return 
> > think this is
> difficult.
> > So, how would it be if there were a 64-bit universal 
> > addressing/naming scheme and a 16-bit local-use addressing/naming 
> > scheme? All nodes would get a 64-bit universal address/name 
> > assignment, but would use an administratively assigned 16-bit local 
> > address/name within
> > The privacy addresses need only be unique within the local network, 
> > and may be reused in countless other standalone local
> networks.
> > larger DTN, they would have to deprecate their local addresses/names 
> > and begin using their universal addresses/names. What do
> you think?
> >
> > Thanks - Fred
> > > > 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
> > > > can be

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Jun 2015 17:33:16 +0000

Hi Scott,

> Sent: Wednesday, June 10, 2015 10:23 AM
> Okay, I think I'm getting a better understanding.  Your objection isn't that the current "ipn" node numbering scheme (for example)
> isn't global or that it isn't interoperable - it's that it isn't fair, correct?

I think that is one way to look at it, yes. Much in the same way that early IP
adopters snapped up Class A networks, while others who were less lucky
got only Class B and Class C. CIDR finally came through and broke that logjam,
but by then it was too late and a privileged few land grabbers ended up with
the choice cuts of the address space. We have an opportunity to avoid a
repeat of history now. 

> Some user communities get to use brief node IDs because they
> grabbed all the ranges of short numbers, and everybody else has to get by with long numbers.  So the fair thing is to require that
> everybody use long numbers, yes?

Long numbers only for universal-scope communications. For local-scope
communications, use 16-bit local-scope numbers.

Thanks - Fred

> > ranges to whoever needs them.  But in over-the-wire representation we are able to economize on transmission by omitting a lot of
> leading zeroes, because we represent them as SDNVs.  How does this not achieve the objectives you're aiming for?
> 
> It means that only early adopters would have compressible strings of 0's in the leading bits of the 64-bit field. Latecomers will not be
> able to take advantage of the optimization.
> Latecomers with low-end devices that operate over underprivileged links will suffer most of all. I guess I am also of the opinion that
> this system should not be optimized to suit the specific needs of just one or a few privileged entities like CCSDS.
> 
> Thanks - Fred
> > operation is universal-scope, who is to say that we should give a 16-bit universally unique node ID to a sensor node mote but then
> only give a 64-bit ID to an aircraft carrier? Seems backwards.
> >
> > would be much simpler to assign universally unique numeric names if they came from the same 64-bit naming space (and then use a
> 16-bit locally assigned numeric name for limited-scope operation.
> >
> > Thanks - Fred

---

From: Sebastian Schildt <[email-masked]>
Date: Wed, 10 Jun 2015 20:04:20 +0200

Hi *,

I read this discussion, but I am not quite sure, where Fred and Scott disagree. So, if I understand it correctly, basically both of you wish/are ok with a numeric namespace. Is anyone here familiar with IEEE 802.15.4 („ZigBee“)? Yes, it is a lower layer, but basically it tackles the same problem: First, addresses are 64 bit (long addresses). This should be enough for a while. Because IEEE 8021.5.4 is used on low datarate links and tiny microcontrollers, you do not always want to throw around 64 bit addresses when sending a 16 bit temperature sample. Therefore there is a short addressing mode which uses 16bit identifiers. On top of that there is optionally a 2 byte network ID (the PAN ID, conceptually this sounds similar to Fred’s „network of origin“). There are some flags managing addressing in the header so that you can go from src&dst PAN Identifier and long addresses (2*(2+8) bytes) down to no PAN ID and destination short address, no src address  (2 byte). 

In such a system, whether you are able to reserve chunks form the 64 bit address space or a 16 bit PAN ID (in IEEE 802.15.4 there is no such thing, but lets just assume they would do it to get globally valid addresses for a super-WSN), is not a problem: Even if you are late/unlucky  full addresses „suck“, in your application you can always work with arbitrary 16 bit short addresses. Gateways mapping this to globally valid addresses are very easy.

Wouldn’t this make you both happy, @Fred/Scott? I guess some of the things discussed in this thread are already quite similar, but maybe it can serve as an inspiration looking at a spec, where such an approach is actually written down (and deployed).

Cheers

Sebastian

> On 10 Jun 2015, at 19:33, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Scott,
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 10 Jun 2015 18:49:09 +0000

Thanks, Sebastian, this is a good contribution to this discussion.  I personally prefer the greater flexibility and transmission efficiency that we can get with SDNVs, and I'd prefer not to have to deploy gateways to enable global interoperability.

Scott

-----Original Message-----
From: Sebastian Schildt [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2015 11:04 AM
To: Templin, Fred L
Cc: Burleigh, Scott C (312B); Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
Subject: Re: [dtn-interest] [dtn] DTN static routing

Hi *,

Cheers

Sebastian

>> Okay, I think I'm getting a better understanding.  Your objection 
>> isn't that the current "ipn" node numbering scheme (for example) isn't global or that it isn't interoperable - it's that it isn't fair, correct?
> 
> I think that is one way to look at it, yes. Much in the same way that 
> early IP adopters snapped up Class A networks, while others who were 
> less lucky got only Class B and Class C. CIDR finally came through and 
> broke that logjam, but by then it was too late and a privileged few 
> land grabbers ended up with the choice cuts of the address space. We 
> have an opportunity to avoid a repeat of history now.
> 
>> Some user communities get to use brief node IDs because they grabbed 
>> all the ranges of short numbers, and everybody else has to get by 
>> with long numbers.  So the fair thing is to require that everybody use long numbers, yes?
> 
>> That is the same as I suggested by having a 24-bit "origin" code as 
>> the leading 24bits of the numeric node ID. CCSDS would have one such origin code.
>> 
>>> ranges to whoever needs them.  But in over-the-wire representation 
>>> we are able to economize on transmission by omitting a lot of
>> It means that only early adopters would have compressible strings of 
>> 0's in the leading bits of the 64-bit field. Latecomers will not be able to take advantage of the optimization.
>> Latecomers with low-end devices that operate over underprivileged 
>> links will suffer most of all. I guess I am also of the opinion that this system should not be optimized to suit the specific needs of just one or a few privileged entities like CCSDS.
>> 
>> Thanks - Fred
>>> operation is universal-scope, who is to say that we should give a 
>>> 16-bit universally unique node ID to a sensor node mote but then
>>> would be much simpler to assign universally unique numeric names if 
>>> they came from the same 64-bit naming space (and then use a
>>>> addresses/names and begin using their universal addresses/names. 
>>>> What do
>>> you think?
>>>> 
>>>> Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Jun 2015 19:37:38 +0000

Hi Sebastian,

> From: dtn [mailto:[email-masked]] On Behalf Of Sebastian Schildt
> Cc: [email-masked]; Burleigh, Scott C (312B); [email-masked]; Rick Taylor; Greg Troxel
> I read this discussion, but I am not quite sure, where Fred and Scott disagree. So, if I understand it correctly, basically both of you
> wish/are ok with a numeric namespace. Is anyone here familiar with IEEE 802.15.4 („ZigBee“)? Yes, it is a lower layer, but basically it
> tackles the same problem: First, addresses are 64 bit (long addresses). This should be enough for a while. Because IEEE 8021.5.4 is
> used on low datarate links and tiny microcontrollers, you do not always want to throw around 64 bit addresses when sending a 16 bit
> temperature sample. Therefore there is a short addressing mode which uses 16bit identifiers. On top of that there is optionally a 2
> byte network ID (the PAN ID, conceptually this sounds similar to Fred’s „network of origin“). There are some flags managing
> addressing in the header so that you can go from src&dst PAN Identifier and long addresses (2*(2+8) bytes) down to no PAN ID and
> destination short address, no src address  (2 byte).

As I wrote what I did, I had  a nagging suspicion that this has been done
before; I was thinking about OSI, but I think your zigbee is a great example.
I have also likened my vision to 802 MAC addresses where the upper 24bits
identifies an organization, which I suspect is also very much like zigbee.

> In such a system, whether you are able to reserve chunks form the 64 bit address space or a 16 bit PAN ID (in IEEE 802.15.4 there is no
> such thing, but lets just assume they would do it to get globally valid addresses for a super-WSN), is not a problem: Even if you are
> late/unlucky  full addresses „suck“, in your application you can always work with arbitrary 16 bit short addresses. Gateways mapping
> this to globally valid addresses are very easy.

Full 64bit node identifiers for universal communications and 16bit PAN IDs
for local-scope communications is pretty much what I was suggesting.
> 
> Wouldn’t this make you both happy, @Fred/Scott? I guess some of the things discussed in this thread are already quite similar, but
> maybe it can serve as an inspiration looking at a spec, where such an approach is actually written down (and deployed).

Very good point; thanks for this contribution.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Jun 2015 19:43:44 +0000

Hi Scott,

> Sent: Wednesday, June 10, 2015 11:49 AM
> To: Sebastian Schildt; Templin, Fred L
> Cc: Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
> Thanks, Sebastian, this is a good contribution to this discussion.  I personally prefer the greater flexibility and transmission efficiency
> that we can get with SDNVs, and I'd prefer not to have to deploy gateways to enable global interoperability.

Now that I (think) I fully understand the IPN naming scheme, I guess I still
see it that the transmission efficiency is only there for early adopters and
the advantage shrinks as more and more chunks of ID space are allocated.
I think it is clever to use SDNVs to compress the node ID, but again the
advantage diminishes as countless billions of users claim ID space. I still
like Sebastian's zigbee analogy.

Thanks - Fred
[email-masked]

> >> links will suffer most of all. I guess I am also of the opinion that this system should not be optimized to suit the specific needs of just
> one or a few privileged entities like CCSDS.
> >>
> >> Thanks - Fred

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 10 Jun 2015 20:45:18 +0000

Fred, you're certainly right: if everybody pays full freight, nobody ever obtains any advantage.  Banks running on gigabit Ethernet connected to fiber backbone incur exactly the same transmission overhead as research submersibles on acoustic modems, even if they acquired their namespace much later.  It's absolutely fair.

What I would say, though, is that namespace allocation is a matter of policy rather than a matter of technology.  We can engineer the protocols to obviate the potential policy failures, or we can engineer the protocols to confer as much technology advantage as possible and address the potential policy failures in a policy planning discussion.  I think the latter is a stronger strategy.

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2015 12:44 PM
To: Burleigh, Scott C (312B); Sebastian Schildt
Cc: Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Hi Scott,

> Thanks, Sebastian, this is a good contribution to this discussion.  I 
> personally prefer the greater flexibility and transmission efficiency that we can get with SDNVs, and I'd prefer not to have to deploy gateways to enable global interoperability.

Now that I (think) I fully understand the IPN naming scheme, I guess I still see it that the transmission efficiency is only there for early adopters and the advantage shrinks as more and more chunks of ID space are allocated.
I think it is clever to use SDNVs to compress the node ID, but again the advantage diminishes as countless billions of users claim ID space. I still like Sebastian's zigbee analogy.

Thanks - Fred

> I read this discussion, but I am not quite sure, where Fred and Scott 
> disagree. So, if I understand it correctly, basically both of you 
> wish/are ok with a numeric namespace. Is anyone here familiar with 
> IEEE 802.15.4 („ZigBee“)? Yes, it is a lower layer, but basically it 
> tackles the same problem: First, addresses are 64 bit (long 
> addresses). This should be enough for a while. Because IEEE 8021.5.4 
> is used on low datarate links and tiny microcontrollers, you do not 
> always want to throw around 64 bit addresses when sending a 16 bit temperature sample. Therefore there is a short addressing mode which uses 16bit identifiers. On top of that there is optionally a 2 byte network ID (the PAN ID, conceptually this sounds similar to Fred’s „network of origin“). There are some flags managing addressing in the header so that you can go from src&dst PAN Identifier and long addresses (2*(2+8) bytes) down to no PAN ID and destination short address, no src address  (2 byte).
> 
> In such a system, whether you are able to reserve chunks form the 64 
> bit address space or a 16 bit PAN ID (in IEEE 802.15.4 there is no 
> such thing, but lets just assume they would do it to get globally 
> valid addresses for a super-WSN), is not a problem: Even if you are late/unlucky  full addresses „suck“, in your application you can always work with arbitrary 16 bit short addresses. Gateways mapping this to globally valid addresses are very easy.
> 
> Wouldn’t this make you both happy, @Fred/Scott? I guess some of the 
> things discussed in this thread are already quite similar, but maybe it can serve as an inspiration looking at a spec, where such an approach is actually written down (and deployed).
> 
> 
> Cheers
> 
> Sebastian
> 
> >> isn't that the current "ipn" node numbering scheme (for example) 
> >> isn't global or that it isn't interoperable - it's that it isn't 
> >> fair,
> correct?
> >
> > I think that is one way to look at it, yes. Much in the same way 
> > that early IP adopters snapped up Class A networks, while others who 
> > were less lucky got only Class B and Class C. CIDR finally came 
> > through and broke that logjam, but by then it was too late and a 
> > privileged few land grabbers ended up with the choice cuts of the 
> > address space. We have an opportunity to avoid a repeat of history now.
> >
> >> grabbed all the ranges of short numbers, and everybody else has to 
> >> get by with long numbers.  So the fair thing is to require that everybody use long numbers, yes?
> >
> > Long numbers only for universal-scope communications. For 
> > local-scope communications, use 16-bit local-scope numbers.
> >
> > Thanks - Fred
> >>> defined for the "ipn" scheme (for example) is a 64-bit numeric 
> >>> node name space, of which subsets are allocated to various 
> >>> administrative entities for assignment to the nodes they 
> >>> instantiate;
> >>
> >>> 2^14 through (2^21)-1, and there's a procedure for allocating 
> >>> other ranges to whoever needs them.  But in over-the-wire 
> >>> representation we are able to economize on transmission by 
> >>> omitting a lot of
> >> It means that only early adopters would have compressible strings 
> >> of 0's in the leading bits of the 64-bit field. Latecomers will not be able to take advantage of the optimization.
> >> links will suffer most of all. I guess I am also of the opinion 
> >> that this system should not be optimized to suit the specific needs 
> >> of just
> >>> within the DTN domain they will be operating in. When the domain 
> >>> of operation is universal-scope, who is to say that we should give 
> >>> a 16-bit universally unique node ID to a sensor node mote but then
> >>> would be much simpler to assign universally unique numeric names 
> >>> if they came from the same 64-bit naming space (and then use a
> >>>>> interconnected global network of interoperating entities.  I 
> >>>>> don't think the mechanism I've been talking about is 
> >>>>> incompatible with
> >>>> that, though.
> >>>>>
> >>>>> myself am not a fan, but that doesn't mean that everybody else 
> >>>>> is wrong, nor that I'm wrong.  The ION and DTN2 and (I think) 
> >>>>> IBR-DTN
> >>>>> numeric node ID, communicating with other orbiters and landers 
> >>>>> in the Mars-Phobos system that are likewise identified by 3-byte 
> >>>>> node IDs, and sending images to an imaging spectrometer's 
> >>>>> Principal Investigator in Chicago who receives science data at 
> >>>>> an iPad-based BP node identified by a 10-digit node ID.  The 
> >>>>> brief data exchanges among the
> >>>> assignment, but would use an administratively assigned 16-bit 
> >>>> local address/name within
> >>>> The privacy addresses need only be unique within the local 
> >>>> network, and may be reused in countless other standalone local
> >>> networks.
> >>>> Later, when multiple local networks are bridged together to form 
> >>>> a larger DTN, they would have to deprecate their local 
> >>>>>> the large-network problem?  A numeric node ID can be 3 bytes 
> >>>>>> (or even
> >>>>> 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Jun 2015 21:14:01 +0000

Hi Scott,

> Sent: Wednesday, June 10, 2015 1:45 PM
> To: Templin, Fred L; Sebastian Schildt
> Fred, you're certainly right: if everybody pays full freight, nobody ever obtains any advantage.  Banks running on gigabit Ethernet
> connected to fiber backbone incur exactly the same transmission overhead as research submersibles on acoustic modems, even if
> they acquired their namespace much later.  It's absolutely fair.

Right, but we would not expect to see the research submersible talking
directly to the bank - at least not w/o going through some translating
gateway that joins the underwater network domain to the terrestrial
world. That means that, while the submersible certainly has a long
universal ID it does not use it in its underwater acoustic transmissions;
instead, it uses a little 16bit local area ID, and relies on a translating
gateway to translate the local ID to the universal. I think the other
viewpoint (only use universal IDs, and take maximum advantage of
SDNV compression) is perhaps more of a strict end-to-end viewpoint
whereas the IETF has moved on to consider the "Rise of the Middle
and the Future of End-to-End" (e.g., RFC3724).

> What I would say, though, is that namespace allocation is a matter of policy rather than a matter of technology.  We can engineer the
> protocols to obviate the potential policy failures, or we can engineer the protocols to confer as much technology advantage as
> possible and address the potential policy failures in a policy planning discussion.  I think the latter is a stronger strategy.

There is certain to be policy in the allocation of DTN node ID ranges to
organizations that want to deploy DTN nodes, yes.

Thanks - Fred

> > personally prefer the greater flexibility and transmission efficiency that we can get with SDNVs, and I'd prefer not to have to deploy
> gateways to enable global interoperability.
> 
> Now that I (think) I fully understand the IPN naming scheme, I guess I still see it that the transmission efficiency is only there for early
> adopters and the advantage shrinks as more and more chunks of ID space are allocated.
> I think it is clever to use SDNVs to compress the node ID, but again the advantage diminishes as countless billions of users claim ID
> space. I still like Sebastian's zigbee analogy.
> 
> Thanks - Fred
> > always want to throw around 64 bit addresses when sending a 16 bit temperature sample. Therefore there is a short addressing
> mode which uses 16bit identifiers. On top of that there is optionally a 2 byte network ID (the PAN ID, conceptually this sounds similar
> to Fred’s „network of origin“). There are some flags managing addressing in the header so that you can go from src&dst PAN Identifier
> and long addresses (2*(2+8) bytes) down to no PAN ID and destination short address, no src address  (2 byte).
> >
> > valid addresses for a super-WSN), is not a problem: Even if you are late/unlucky  full addresses „suck“, in your application you can
> always work with arbitrary 16 bit short addresses. Gateways mapping this to globally valid addresses are very easy.
> >
> > things discussed in this thread are already quite similar, but maybe it can serve as an inspiration looking at a spec, where such an
> approach is actually written down (and deployed).
> >
> >
> > Cheers
> >
> > Sebastian
> >

---

From: William Immerman <[email-masked]>
Date: Wed, 10 Jun 2015 17:24:41 -0400

Fred & Scott--

If I'm understanding Fred's point and Scott's reduction to an issue of fairness of access to short addresses, would it be valuable for some non-biased entity (like ietf) to reserve a block of (short) ids for use in whatever form of autonomous DT-sub-nets are needed for re-usable address space under control of various authorities (a la RFC 1918?). I think this may be what Fred was intending to achieve by separating "local" from "global" addresses. Since DTN names are not supposed to constrain topology, "local" might be misleading, but it would seem to be important that engineers constructing a DT-sub-net who do know what the topology and traffic patterns within it will be, to achieve bundle forwarding within that net efficiently. That net might be geographically local, topologically local, or just belong to a homogeneous organization, but it should allow entities large and small, early or late to adopt, to design their own portion of a larger net somewhat independently of others and without permission from a central authority. (Also consider that there might be more than one "true global" network using the same protocols and names. For instance, in addition to the Internet, there are multiple independent IP nets that are unable to communicate with each other or the Internet such as classified and other private networks).

Even in IP routing it appears that this kind of separation into autonomous regions with different protocols for sharing info at the boundaries has been valuable, so it wouldn't seem reasonable to come up with a truly global DTN address space/routing protocol suitable for connecting individual devices on an IPv6 scale, statically, that would scale appropriately.

Bill Immerman

---

From: Vint Cerf <[email-masked]>
Date: Wed, 10 Jun 2015 17:26:44 -0400

> like Sebastian's zigbee analogy.

sounds like domain names.....

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Jun 2015 21:37:34 +0000

Hi Vint,

From: Vint Cerf [mailto:[email-masked]]
Sent: Wednesday, June 10, 2015 2:27 PM
To: Templin, Fred L
Cc: Burleigh, Scott C (312B); Sebastian Schildt; [email-masked]; [email-masked]; Rick Taylor
Subject: Re: [dtn-interest] [dtn] DTN static routing

On Wed, Jun 10, 2015 at 3:43 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Ø    Right, we already have the dtn: (URI-based) scheme in our back pocket. Now,

Ø    we are trying to design a numeric scheme to go along with it.

Thanks - Fred

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 10 Jun 2015 22:11:36 +0000

Fred, I certainly expect that the submersible would be talking to the bank through a router, but there's no need for a gateway unless we adopt the node ID translation you're proposing.

I think what this comes down to is whether or not the cost of developing and deploying the node ID translation infrastructure is justified by the ID allocation fairness that is structurally imposed by a fixed-length node ID standard.  I don't think it is.

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2015 2:14 PM
To: Burleigh, Scott C (312B); Sebastian Schildt
Cc: Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Hi Scott,

> Fred, you're certainly right: if everybody pays full freight, nobody 
> ever obtains any advantage.  Banks running on gigabit Ethernet 
> connected to fiber backbone incur exactly the same transmission overhead as research submersibles on acoustic modems, even if they acquired their namespace much later.  It's absolutely fair.

Right, but we would not expect to see the research submersible talking directly to the bank - at least not w/o going through some translating gateway that joins the underwater network domain to the terrestrial world. That means that, while the submersible certainly has a long universal ID it does not use it in its underwater acoustic transmissions; instead, it uses a little 16bit local area ID, and relies on a translating gateway to translate the local ID to the universal. I think the other viewpoint (only use universal IDs, and take maximum advantage of SDNV compression) is perhaps more of a strict end-to-end viewpoint whereas the IETF has moved on to consider the "Rise of the Middle and the Future of End-to-End" (e.g., RFC3724).

> What I would say, though, is that namespace allocation is a matter of 
> policy rather than a matter of technology.  We can engineer the 
> protocols to obviate the potential policy failures, or we can engineer the protocols to confer as much technology advantage as possible and address the potential policy failures in a policy planning discussion.  I think the latter is a stronger strategy.

There is certain to be policy in the allocation of DTN node ID ranges to organizations that want to deploy DTN nodes, yes.

Thanks - Fred

> > Thanks, Sebastian, this is a good contribution to this discussion.  
> > I personally prefer the greater flexibility and transmission 
> > efficiency that we can get with SDNVs, and I'd prefer not to have to 
> > deploy
> Now that I (think) I fully understand the IPN naming scheme, I guess I 
> still see it that the transmission efficiency is only there for early adopters and the advantage shrinks as more and more chunks of ID space are allocated.
> I think it is clever to use SDNVs to compress the node ID, but again 
> the advantage diminishes as countless billions of users claim ID space. I still like Sebastian's zigbee analogy.
> 
> Thanks - Fred
> > I read this discussion, but I am not quite sure, where Fred and 
> > Scott disagree. So, if I understand it correctly, basically both of 
> > you wish/are ok with a numeric namespace. Is anyone here familiar 
> > with IEEE 802.15.4 („ZigBee“)? Yes, it is a lower layer, but 
> > basically it tackles the same problem: First, addresses are 64 bit 
> > (long addresses). This should be enough for a while. Because IEEE 
> > 8021.5.4 is used on low datarate links and tiny microcontrollers, 
> > you do not always want to throw around 64 bit addresses when sending 
> > a 16 bit temperature sample. Therefore there is a short addressing
> mode which uses 16bit identifiers. On top of that there is optionally 
> a 2 byte network ID (the PAN ID, conceptually this sounds similar to 
> Fred’s „network of origin“). There are some flags managing addressing in the header so that you can go from src&dst PAN Identifier and long addresses (2*(2+8) bytes) down to no PAN ID and destination short address, no src address  (2 byte).
> >
> > valid addresses for a super-WSN), is not a problem: Even if you are 
> > late/unlucky  full addresses „suck“, in your application you can
> > things discussed in this thread are already quite similar, but maybe 
> > it can serve as an inspiration looking at a spec, where such an
> > > that early IP adopters snapped up Class A networks, while others 
> > > who were less lucky got only Class B and Class C. CIDR finally 
> > > came through and broke that logjam, but by then it was too late 
> > > and a privileged few land grabbers ended up with the choice cuts 
> > > of the address space. We have an opportunity to avoid a repeat of history now.
> > >
> > >> grabbed all the ranges of short numbers, and everybody else has 
> > >> to get by with long numbers.  So the fair thing is to require that everybody use long numbers, yes?
> > >
> > >>> Fred, I still don't understand the problem. What we've already 
> > >>> got defined for the "ipn" scheme (for example) is a 64-bit 
> > >>> numeric node name space, of which subsets are allocated to 
> > >>> various administrative entities for assignment to the nodes they 
> > >>> instantiate;
> > >>
> > >> That is the same as I suggested by having a 24-bit "origin" code 
> > >> as the leading 24bits of the numeric node ID. CCSDS would have one such origin code.
> > >>
> > >> that this system should not be optimized to suit the specific 
> > >> needs of just
> > >>> IMHO, what I proposed is simple and natural. We have an 
> > >>> existence proof in IPv4 privacy addressing and to a certain extent also IPv6 unique local addressing.
> > >>>
> > >>> The problem is that the node IDs need to be managed for 
> > >>> uniqueness within the DTN domain they will be operating in. When 
> > >>> the domain of operation is universal-scope, who is to say that 
> > >>> we should give a 16-bit universally unique node ID to a sensor 
> > >>> node mote but then
> > >>> Still having the late binding for addressing is also fine. But, 
> > >>> it would be much simpler to assign universally unique numeric 
> > >>> names if they came from the same 64-bit naming space (and then 
> > >>> use a
> > >>>>> I'm pretty sure there is no globally embraced DTN vision, but 
> > >>>>> my own vision for DTN definitely extends (eventually) to a 
> > >>>>> single interconnected global network of interoperating 
> > >>>>> entities.  I don't think the mechanism I've been talking about 
> > >>>>> is incompatible with
> > >>>> that, though.
> > >>>>>
> > >>>>> I am abundantly aware that there are plenty of people in the 
> > >>>>> DTN community who see lots of value in using what I would 
> > >>>>> consider lengthy character strings to identify nodes and 
> > >>>>> endpoints.  I myself am not a fan, but that doesn't mean that 
> > >>>>> everybody else is wrong, nor that I'm wrong.  The ION and DTN2 
> > >>>>> and (I think) IBR-DTN
> > >>>> implementations of BP can forward and acquire bundles tagged 
> > >>>> with both types of IDs.  I think global interoperability isn't necessarily threatened by BP's tolerance of different naming schemes.
> > >>>>>
> > >>>>> in the Mars-Phobos system that are likewise identified by 
> > >>>>> 3-byte node IDs, and sending images to an imaging 
> > >>>>> spectrometer's Principal Investigator in Chicago who receives 
> > >>>>> science data at an iPad-based BP node identified by a 10-digit 
> > >>>>> node ID.  The brief data exchanges among the
> > >>>> bundles is amortized over the larger size of the images.  I 
> > >>>> don't think this is
> > >>> difficult.
> > >>>>
> > >>>> addressing/naming scheme and a 16-bit local-use 
> > >>>> addressing/naming scheme? All nodes would get a 64-bit 
> > >>>> universal address/name assignment, but would use an 
> > >>>> administratively assigned 16-bit local address/name within
> > >>>> Later, when multiple local networks are bridged together to 
> > >>>> form a larger DTN, they would have to deprecate their local 
> > >>>>>> 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Jun 2015 22:34:38 +0000

Hi Scott,

> Sent: Wednesday, June 10, 2015 3:12 PM
> Fred, I certainly expect that the submersible would be talking to the bank through a router, but there's no need for a gateway unless
> we adopt the node ID translation you're proposing.
> 
> I think what this comes down to is whether or not the cost of developing and deploying the node ID translation infrastructure is
> justified by the ID allocation fairness that is structurally imposed by a fixed-length node ID standard.  I don't think it is.

Maybe we aren't quite looking at this the same way. We are now at the
ground floor of universal DTN deployment (or, maybe we're still in the
basement). But, we should allow for the possibility that there will be
countless billions of DTN nodes in the future much in the same way that
the public Internet rose to its current scale from humble beginnings.
To accommodate that kind of scaling, the node ID allocation service
has to be fair to all comers whether they are early adopters or late
arrivals. We learned that lesson when we went from classful to
classless addressing in IPv4.

Thanks - Fred

> Right, but we would not expect to see the research submersible talking directly to the bank - at least not w/o going through some
> translating gateway that joins the underwater network domain to the terrestrial world. That means that, while the submersible
> certainly has a long universal ID it does not use it in its underwater acoustic transmissions; instead, it uses a little 16bit local area ID, and
> relies on a translating gateway to translate the local ID to the universal. I think the other viewpoint (only use universal IDs, and take
> maximum advantage of SDNV compression) is perhaps more of a strict end-to-end viewpoint whereas the IETF has moved on to
> consider the "Rise of the Middle and the Future of End-to-End" (e.g., RFC3724).
> 
> > Fred’s „network of origin“). There are some flags managing addressing in the header so that you can go from src&dst PAN Identifier

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 10 Jun 2015 22:38:11 +0000

So I think we agree on what the question is, we just disagree on the answer.  Progress!

Scott

-----Original Message-----
From: dtn-interest [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Wednesday, June 10, 2015 3:35 PM
To: Burleigh, Scott C (312B); Sebastian Schildt
Cc: [email-masked]; [email-masked]; Rick Taylor
Subject: Re: [dtn-interest] [dtn] DTN static routing

Hi Scott,

> Fred, I certainly expect that the submersible would be talking to the 
> bank through a router, but there's no need for a gateway unless we adopt the node ID translation you're proposing.
> 
> I think what this comes down to is whether or not the cost of 
> developing and deploying the node ID translation infrastructure is justified by the ID allocation fairness that is structurally imposed by a fixed-length node ID standard.  I don't think it is.

Maybe we aren't quite looking at this the same way. We are now at the ground floor of universal DTN deployment (or, maybe we're still in the basement). But, we should allow for the possibility that there will be countless billions of DTN nodes in the future much in the same way that the public Internet rose to its current scale from humble beginnings.
To accommodate that kind of scaling, the node ID allocation service has to be fair to all comers whether they are early adopters or late arrivals. We learned that lesson when we went from classful to classless addressing in IPv4.

Thanks - Fred

> > connected to fiber backbone incur exactly the same transmission 
> > overhead as research submersibles on acoustic modems, even if
> universal ID it does not use it in its underwater acoustic 
> transmissions; instead, it uses a little 16bit local area ID, and relies on a translating gateway to translate the local ID to the universal. I think the other viewpoint (only use universal IDs, and take maximum advantage of SDNV compression) is perhaps more of a strict end-to-end viewpoint whereas the IETF has moved on to consider the "Rise of the Middle and the Future of End-to-End" (e.g., RFC3724).
> 
> > What I would say, though, is that namespace allocation is a matter 
> > of policy rather than a matter of technology.  We can engineer the 
> > protocols to obviate the potential policy failures, or we can 
> > engineer the protocols to confer as much technology advantage as
> > > efficiency that we can get with SDNVs, and I'd prefer not to have 
> > > to deploy
> > Now that I (think) I fully understand the IPN naming scheme, I guess 
> > I still see it that the transmission efficiency is only there for 
> > early adopters and the advantage shrinks as more and more chunks of 
> > ID
> space are allocated.
> > > Scott disagree. So, if I understand it correctly, basically both 
> > > of you wish/are ok with a numeric namespace. Is anyone here 
> > > familiar with IEEE 802.15.4 („ZigBee“)? Yes, it is a lower layer, 
> > > but basically it tackles the same problem: First, addresses are 64 
> > > bit (long addresses). This should be enough for a while. Because 
> > > IEEE
> > > you do not always want to throw around 64 bit addresses when 
> > > sending a 16 bit temperature sample. Therefore there is a short 
> > > addressing
> > mode which uses 16bit identifiers. On top of that there is 
> > optionally a 2 byte network ID (the PAN ID, conceptually this sounds 
> > similar to Fred’s „network of origin“). There are some flags 
> > managing addressing in the header so that you can go from src&dst 
> > PAN Identifier
> > > In such a system, whether you are able to reserve chunks form the 
> > > 64 bit address space or a 16 bit PAN ID (in IEEE 802.15.4 there is 
> > > no such thing, but lets just assume they would do it to get 
> > > globally valid addresses for a super-WSN), is not a problem: Even 
> > > if you are late/unlucky  full addresses „suck“, in your 
> > > application you can
> > > Wouldn’t this make you both happy, @Fred/Scott? I guess some of 
> > > the things discussed in this thread are already quite similar, but 
> > > maybe it can serve as an inspiration looking at a spec, where such 
> > > an
> > > >> Okay, I think I'm getting a better understanding.  Your 
> > > >> objection isn't that the current "ipn" node numbering scheme 
> > > >> (for example) isn't global or that it isn't interoperable - 
> > > >> it's that it isn't fair,
> > > correct?
> > > >
> > > >>> various administrative entities for assignment to the nodes 
> > > >>> they instantiate;
> > > >>
> > > >> That is the same as I suggested by having a 24-bit "origin" 
> > > >> code as the leading 24bits of the numeric node ID. CCSDS would have one such origin code.
> > > >>
> > > >> It means that only early adopters would have compressible 
> > > >> strings of 0's in the leading bits of the 64-bit field. Latecomers will not be able to take advantage of the optimization.
> > > >> Latecomers with low-end devices that operate over 
> > > >> underprivileged links will suffer most of all. I guess I am 
> > > >> also of the opinion that this system should not be optimized to 
> > > >> suit the specific needs of just
> > > >>>> What's wrong with using variable-length numbers and strings 
> > > >>>> as permanent node identifiers,
> > > >>>
> > > >>> uniqueness within the DTN domain they will be operating in. 
> > > >>> When the domain of operation is universal-scope, who is to say 
> > > >>> that we should give a 16-bit universally unique node ID to a 
> > > >>> sensor node mote but then
> > > >>> Still having the late binding for addressing is also fine. 
> > > >>> But, it would be much simpler to assign universally unique 
> > > >>> numeric names if they came from the same 64-bit naming space 
> > > >>> (and then use a
> > > >>>>> I'm pretty sure there is no globally embraced DTN vision, 
> > > >>>>> but my own vision for DTN definitely extends (eventually) to 
> > > >>>>> a single interconnected global network of interoperating 
> > > >>>>> entities.  I don't think the mechanism I've been talking 
> > > >>>>> about is incompatible with
> > > >>>> that, though.
> > > >>>>>
> > > >>>>> endpoints.  I myself am not a fan, but that doesn't mean 
> > > >>>>> that everybody else is wrong, nor that I'm wrong.  The ION 
> > > >>>>> and DTN2 and (I think) IBR-DTN
> > > >>>> with both types of IDs.  I think global interoperability 
> > > >>>> isn't necessarily threatened by BP's tolerance of different 
> > > >>>> naming
> schemes.
> > > >>>>>
> > > >>>>> Coming back to numeric ID sizes in particular: I can imagine 
> > > >>>>> a spacecraft orbiting Phobos that is identified by a 3-byte 
> > > >>>>> SDNV numeric node ID, communicating with other orbiters and 
> > > >>>>> landers in the Mars-Phobos system that are likewise 
> > > >>>>> identified by 3-byte node IDs, and sending images to an 
> > > >>>>> imaging spectrometer's Principal Investigator in Chicago who 
> > > >>>>> receives science data at an iPad-based BP node identified by 
> > > >>>>> a 10-digit node ID.  The brief data exchanges among the
> > > >>>> channels, while the larger overhead on the science data 
> > > >>>> return bundles is amortized over the larger size of the 
> > > >>>> images.  I don't think this is
> > > >>> difficult.
> > > >>>>
> > > >>>>>> 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
> > > >>>>> 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

---

From: Sebastian Schildt <[email-masked]>
Date: Thu, 11 Jun 2015 01:00:13 +0200

Scott, 

I am not sure I follow your argument completely. Practically speaking you want short IDs (overhead) in your application. And using SDNVs can of course help, if you are able to use ID 1 to 127. You do not want to be forced to use a looong (the longest possible) identifier, just because then "it is fair for everyone". Understandable.

However, I agree it with Fred, that it is not a good idea, if your only chance to be efficient, is being a first mover.

It is clear, that IF we want numeric identifiers and IF we want to make them usable globally (inter-planetary) on Internet-scale networks (and I think we should), we need them to be "long enough" (think IPv4/v6). 

I really think private/local address spaces are the solution: If we have a flat numeric address scheme, you could say  define 0x0-0xFFFFFFFFFF are not globally routable, or alternatively, if opting for some prefix/network scheme something like network „0“ could be defined as local (and be omitted in packets). 

Your argument for keeping all addresses global is
"there's no need for a gateway"  
however, I think those gateways would be really, really simple. If building NASA's whole network with "private" IDs, all that is needed for being able to connect a rover to its own facebook page is assigning it a public (long) ID with a simple 1-to-1 mapping on some simple gateway router. I think this can be done in a simple and clean way. 

And if you still do not like the translation for your setup, you would still be able to grab those precious first blocks of the global address space and just use those :)  I agree however, that policy questions, albeit important,  about how to distribute the address space should be part of a separate discussion.

Sebastian

> On 11 Jun 2015, at 00:11, Burleigh, Scott C (312B) <[email-masked]> wrote:
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 10 Jun 2015 23:54:47 +0000

Hi, Sebastian.  I definitely agree that a 64-bit global node ID space is needed for an Internet-scale network.  All we're talking about here is whether those global IDs are always 64 bits long when transmitted or, alternatively, they can have leading zeros that can be truncated in SDNV representation.

I also recognize that creating a "land rush" for short ID number ranges is undesirable.  I just think that the solution is careful development of range allocation policy rather than requiring useless leading bits in the standard.

We clearly wouldn't be able to accomplish that careful development of range allocation policy in this email thread, but I don't think that means it's impossible.

For example: the kinds of networks where I think short node numbers are likely to be important are going to be the small "local" research and experimental networks we've been talking about, right?  Suppose -- strictly as a strawman, proof-of-concept sort of thing -- we say the maximum number of nodes in any such network will be (2^10)-1, i.e., 1023.  We could allocate 2^18 = 262,144 such research network ranges, every node of which would have a 28-bit ID that would fit into a 4-byte SDNV.  We could allocate 33.5 million of them and still have every node's ID fit into a 5-byte SDNV, still a savings of at least 12 bytes in every bundle header -- without any need for any gateways anywhere, ever.

I don't doubt that the gateways would be really, really simple.  I just think that every one of them would need to be deployed, configured, managed, updated, troubleshot, defended against cyber-attack, etc.  That sounds to me like millions of hours of tedious yet critical work.

Scott

-----Original Message-----
From: Sebastian Schildt [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2015 4:00 PM
To: Burleigh, Scott C (312B)
Cc: Templin, Fred L; Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
Subject: Re: [dtn-interest] [dtn] DTN static routing

Scott, 

Your argument for keeping all addresses global is "there's no need for a gateway"  
however, I think those gateways would be really, really simple. If building NASA's whole network with "private" IDs, all that is needed for being able to connect a rover to its own facebook page is assigning it a public (long) ID with a simple 1-to-1 mapping on some simple gateway router. I think this can be done in a simple and clean way. 

Sebastian

>> I still see it that the transmission efficiency is only there for early adopters and the advantage shrinks as more and more chunks of ID space are allocated.
>>>> who were less lucky got only Class B and Class C. CIDR finally came 
>>>>>> the domain of operation is universal-scope, who is to say that we 
>>>>>> should give a 16-bit universally unique node ID to a sensor node 
>>>>>> mote but then
>>>>>>> addressing/naming scheme? All nodes would get a 64-bit universal 
>>>>>>> address/name assignment, but would use an administratively 
>>>>>>> assigned 16-bit local address/name within

---

From: <[email-masked]>
Date: Thu, 11 Jun 2015 07:47:17 +0000

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

a sequel to 'A Bundle of Problems' has been suggested.
________________________________
From: Scott, Keith L. <[email-masked]>
Sent: Thursday, 11 June 2015 12:14:12 AM
To: Wood L Dr (Electronic Eng); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
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,

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).

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

-----Original Message-----
From: dtn-interest [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 09, 2015 10:14 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] [dtn] DTN static routing

We addressed this in

Lloyd Wood

---

From: "Scott, Keith L." <[email-masked]>
Date: Thu, 11 Jun 2015 13:06:37 +0000

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

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 11, 2015 3:47 AM
To: Scott, Keith L.; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] [dtn] DTN static routing

Lloyd Wood

a sequel to 'A Bundle of Problems' has been suggested.
________________________________
From: Scott, Keith L. <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, 11 June 2015 12:14:12 AM
To: Wood L Dr (Electronic Eng); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn-interest] [dtn] DTN static routing

Lloyd,

                        --keith

Dr. Keith Scott                                                                                           Office: +1.703.983.6547
Chief Engineer, J86A                                                                               Fax:      +1.703.983.7142
Communications Network Engineering & Analysis                     Email: [email-masked]<mailto:[email-masked]>
The MITRE Corporation<http://www.mitre.org/>                                                                        M/S H300
7515 Colshire Drive
McLean, VA 22102

-----Original Message-----
From: dtn-interest [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, June 09, 2015 10:14 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] [dtn] DTN static routing

We addressed this in

Lloyd Wood

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jun 2015 14:59:26 +0000

Hi Scott,

> Sent: Wednesday, June 10, 2015 4:55 PM
> To: Sebastian Schildt
> Hi, Sebastian.  I definitely agree that a 64-bit global node ID space is needed for an Internet-scale network.  All we're talking about
> here is whether those global IDs are always 64 bits long when transmitted or, alternatively, they can have leading zeros that can be
> truncated in SDNV representation.
> 
> I also recognize that creating a "land rush" for short ID number ranges is undesirable.  I just think that the solution is careful
> development of range allocation policy rather than requiring useless leading bits in the standard.
> 
> For example: the kinds of networks where I think short node numbers are likely to be important are going to be the small "local"
> research and experimental networks we've been talking about, right?  Suppose -- strictly as a strawman, proof-of-concept sort of
> thing -- we say the maximum number of nodes in any such network will be (2^10)-1, i.e., 1023.  We could allocate 2^18 = 262,144 such
> research network ranges, every node of which would have a 28-bit ID that would fit into a 4-byte SDNV.  We could allocate 33.5 million
> of them and still have every node's ID fit into a 5-byte SDNV, still a savings of at least 12 bytes in every bundle header -- without any
> need for any gateways anywhere, ever.
> 
> I don't doubt that the gateways would be really, really simple.  I just think that every one of them would need to be deployed,
> configured, managed, updated, troubleshot, defended against cyber-attack, etc.  That sounds to me like millions of hours of tedious
> yet critical work.

Networks that care so much about reducing the node ID length likely comprise
low-end links and/or systems and would use a gateway to connect to the rest
of the universe anyway. Surely, we do not want dynamic routing updates and
other high-bandwidth control messaging to flow over those links - the control
messages would instead be terminated by the gateway. So, why wouldn't
the gateway also provide node ID translation services?

Thanks - Fred

> I am not sure I follow your argument completely. Practically speaking you want short IDs (overhead) in your application. And using
> SDNVs can of course help, if you are able to use ID 1 to 127. You do not want to be forced to use a looong (the longest possible)
> identifier, just because then "it is fair for everyone". Understandable.
> 
> It is clear, that IF we want numeric identifiers and IF we want to make them usable globally (inter-planetary) on Internet-scale
> networks (and I think we should), we need them to be "long enough" (think IPv4/v6).
> 
> I really think private/local address spaces are the solution: If we have a flat numeric address scheme, you could say  define 0x0-
> 0xFFFFFFFFFF are not globally routable, or alternatively, if opting for some prefix/network scheme something like network „0“ could
> be defined as local (and be omitted in packets).
> 
> however, I think those gateways would be really, really simple. If building NASA's whole network with "private" IDs, all that is needed
> for being able to connect a rover to its own facebook page is assigning it a public (long) ID with a simple 1-to-1 mapping on some
> simple gateway router. I think this can be done in a simple and clean way.
> 
> And if you still do not like the translation for your setup, you would still be able to grab those precious first blocks of the global address
> space and just use those :)  I agree however, that policy questions, albeit important,  about how to distribute the address space
> should be part of a separate discussion.
> 
> Sebastian
> 
> 
> 
> >> Fred’s „network of origin“). There are some flags managing addressing in the header so that you can go from src&dst PAN
> Identifier and long addresses (2*(2+8) bytes) down to no PAN ID and destination short address, no src address  (2 byte).
> >>>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 11 Jun 2015 15:57:36 +0000

Fred, I don't understand why you think a small research network would want or need to be separated from the rest of the network by a gateway.  There aren't currently any gateway functions defined in DTN architecture at all, nor are there any high-bandwidth control messages that research network nodes need to be shielded from.  Certainly there might be in the future, and nothing in the DTN architecture precludes these developments, but currently nothing requires them - except the node ID translation function you're proposing.

Node ID translation presents at least one other problem as well: we lose the possibility of end-to-end integrity protection of the primary block, because the primary block is no longer immutable.

Okay, how about this as an alternative?  Let's define an "office ID" extension block that identifies a numeric "office ID", to disambiguate a numeric source or destination or report-to (or whatever) node ID.

When node A sends a bundle to node B that is in the same "office" (e.g., small research network; this is an administrative mechanism) and is reachable without forwarding through any node in any other office, no office ID extension blocks are attached.  The source, destination, etc. node ID numbers are all of whatever length has been determined to be most efficient for that office: 7 bits, 14 bits, 21 bits, whatever.

Whenever it is recognized that a bundle's destination requires the bundle to cross an office boundary, office ID extension blocks are added to disambiguate the brief node ID numbers.  The length of an office ID is always 64 bits (or, my preference, 63 bits; this avoids writing another whole SDNV byte just to double the size of the namespace) less the number of bits in the office's node ID number length.

So traffic that is wholly internal to an office is as bit-efficient as possible, but traffic on the global network is always routable by the lengthy global IDs.  Global IDs are allocated on whatever basis you like; the partitioning of the global ID into office ID and office-specific node ID is entirely a private office administration matter that nobody else in the network needs to know or care about.  The insertion and (potentially) removal of office ID extension blocks is the same straightforward extension block management mechanism we've already got in the architecture; it happens at the routers and it is very straightforward, with no need for any mapping between long and short node IDs, so the gateway management problem goes away.

What do you think?

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, June 11, 2015 7:59 AM
To: Burleigh, Scott C (312B); Sebastian Schildt
Cc: Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Hi Scott,

> Hi, Sebastian.  I definitely agree that a 64-bit global node ID space 
> is needed for an Internet-scale network.  All we're talking about here 
> is whether those global IDs are always 64 bits long when transmitted or, alternatively, they can have leading zeros that can be truncated in SDNV representation.
> 
> I also recognize that creating a "land rush" for short ID number 
> ranges is undesirable.  I just think that the solution is careful development of range allocation policy rather than requiring useless leading bits in the standard.
> 
> We clearly wouldn't be able to accomplish that careful development of 
> range allocation policy in this email thread, but I don't think that means it's impossible.
> 
> research and experimental networks we've been talking about, right?  
> Suppose -- strictly as a strawman, proof-of-concept sort of thing -- 
> we say the maximum number of nodes in any such network will be 
> (2^10)-1, i.e., 1023.  We could allocate 2^18 = 262,144 such research 
> network ranges, every node of which would have a 28-bit ID that would fit into a 4-byte SDNV.  We could allocate 33.5 million of them and still have every node's ID fit into a 5-byte SDNV, still a savings of at least 12 bytes in every bundle header -- without any need for any gateways anywhere, ever.
> 
> I don't doubt that the gateways would be really, really simple.  I 
> just think that every one of them would need to be deployed, 
> configured, managed, updated, troubleshot, defended against cyber-attack, etc.  That sounds to me like millions of hours of tedious yet critical work.

Networks that care so much about reducing the node ID length likely comprise low-end links and/or systems and would use a gateway to connect to the rest of the universe anyway. Surely, we do not want dynamic routing updates and other high-bandwidth control messaging to flow over those links - the control messages would instead be terminated by the gateway. So, why wouldn't the gateway also provide node ID translation services?

Thanks - Fred

> I am not sure I follow your argument completely. Practically speaking 
> you want short IDs (overhead) in your application. And using SDNVs can 
> of course help, if you are able to use ID 1 to 127. You do not want to be forced to use a looong (the longest possible) identifier, just because then "it is fair for everyone". Understandable.
> 
> It is clear, that IF we want numeric identifiers and IF we want to 
> make them usable globally (inter-planetary) on Internet-scale networks (and I think we should), we need them to be "long enough" (think IPv4/v6).
> 
> I really think private/local address spaces are the solution: If we 
> have a flat numeric address scheme, you could say  define 0x0- 
> 0xFFFFFFFFFF are not globally routable, or alternatively, if opting for some prefix/network scheme something like network „0“ could be defined as local (and be omitted in packets).
> 
> however, I think those gateways would be really, really simple. If 
> building NASA's whole network with "private" IDs, all that is needed 
> for being able to connect a rover to its own facebook page is assigning it a public (long) ID with a simple 1-to-1 mapping on some simple gateway router. I think this can be done in a simple and clean way.
> 
> And if you still do not like the translation for your setup, you would 
> still be able to grab those precious first blocks of the global 
> address space and just use those :)  I agree however, that policy questions, albeit important,  about how to distribute the address space should be part of a separate discussion.
> 
> Sebastian
> 
> 
> 
> > Fred, I certainly expect that the submersible would be talking to 
> > the bank through a router, but there's no need for a gateway unless
> > developing and deploying the node ID translation infrastructure is
> >> Fred, you're certainly right: if everybody pays full freight, 
> >> nobody ever obtains any advantage.  Banks running on gigabit 
> >> Ethernet connected to fiber backbone incur exactly the same 
> >> transmission overhead as research submersibles on acoustic modems, 
> >> even if
> > Right, but we would not expect to see the research submersible 
> > talking directly to the bank - at least not w/o going through some
> translating gateway that joins the underwater network domain to the 
> terrestrial world. That means that, while the submersible certainly 
> has a long universal ID it does not use it in its underwater acoustic 
> transmissions; instead, it uses a little 16bit local area ID, and 
> relies on a translating gateway to translate the local ID to the universal. I think the other viewpoint (only use universal IDs, and take maximum advantage of SDNV compression) is perhaps more of a strict end-to-end viewpoint whereas the IETF has moved on to consider the "Rise of the Middle and the Future of End-to-End" (e.g., RFC3724).
> >
> >> Now that I (think) I fully understand the IPN naming scheme, I 
> >> guess I still see it that the transmission efficiency is only there 
> >> for early adopters and the advantage shrinks as more and more 
> >> chunks of
> ID space are allocated.
> >> I think it is clever to use SDNVs to compress the node ID, but 
> >> again the advantage diminishes as countless billions of users claim ID space. I still like Sebastian's zigbee analogy.
> >>
> >> Thanks - Fred
> >> optionally a 2 byte network ID (the PAN ID, conceptually this 
> >> sounds similar to Fred’s „network of origin“). There are some flags 
> >> PAN
> >>>>> (for example) isn't global or that it isn't interoperable - it's 
> >>>>> that it isn't fair,
> >>> correct?
> >>>>
> >>>>> underprivileged links will suffer most of all. I guess I am also 
> >>>>> of the opinion that this system should not be optimized to suit 
> >>>>> the specific needs of just
> >>>>>>>> everybody else is wrong, nor that I'm wrong.  The ION and 
> >>>>>>>> DTN2 and (I think) IBR-DTN
> >>>>>>> with both types of IDs.  I think global interoperability isn't 
> >>>>>>> necessarily threatened by BP's tolerance of different naming
> schemes.
> >>>>>>>>

---

From: Sebastian Schildt <[email-masked]>
Date: Thu, 11 Jun 2015 18:11:51 +0200

I am not Fred, but my answer would be „yes, definitely I want a small research network to be separated from the rest of the global network“. Maybe we do have different ideas about what „gateway“ means? For example, I am working at university, so the IP address shortage is not as bad yet. Therefore, we have some printers which have public, globally-routable  addresses. Of course, you can not just print on them (I hope…) because there are at least two routing/firewalling installations between them and the world. 

No matter whether you use local or global addresses, even with a DTN, you will have some boxes at the border of your network. I mean, you do not want to 200 million internet users trying to dtnping a space probe, just because somebody at NASA twittered „We seem to have lost contact with …“.  So once you do have these boxes, having them manage public addresses for a few select endpoints will be trivial. 

This is similar to what Amazon is doing in their AWS cloud computing service (and i think maybe Openstack does the same with their floating IPs): Your VM will start with a private IP. If you assign/buy a global IP address, the network interface (e.g. eth0)  INSIDE the virtual machine does not know about it Is still sees the private IP, but is fully reachable by the assigned global one.

Sebastian

> On 11 Jun 2015, at 17:57, Burleigh, Scott C (312B) <[email-masked]> wrote:
>

---

From: Sebastian Schildt <[email-masked]>
Date: Thu, 11 Jun 2015 18:16:50 +0200

Yes, I think this is basically an example of a feasible address mapping approach. You make a difference between „network“ and „node“, and thus for intra-network traffic you can be efficient by omitting the network IDs. What you call „routers“ some might call gateway devices. So maybe this whole discussion is just about terminology :)

Sebastian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jun 2015 16:29:50 +0000

Hi Scott,

> Sent: Thursday, June 11, 2015 8:58 AM
> Fred, I don't understand why you think a small research network would want or need to be separated from the rest of the network by
> a gateway.  There aren't currently any gateway functions defined in DTN architecture at all, nor are there any high-bandwidth control
> messages that research network nodes need to be shielded from.  Certainly there might be in the future, and nothing in the DTN
> architecture precludes these developments, but currently nothing requires them - except the node ID translation function you're
> proposing.
> 
> Node ID translation presents at least one other problem as well: we lose the possibility of end-to-end integrity protection of the
> primary block, because the primary block is no longer immutable.

That's OK; the integrity protection extends from the source to the gateway, and
then a second integrity protection extends from the gateway to the destination.

> Okay, how about this as an alternative?  Let's define an "office ID" extension block that identifies a numeric "office ID", to
> disambiguate a numeric source or destination or report-to (or whatever) node ID.
> 
> When node A sends a bundle to node B that is in the same "office" (e.g., small research network; this is an administrative mechanism)
> and is reachable without forwarding through any node in any other office, no office ID extension blocks are attached.  The source,
> destination, etc. node ID numbers are all of whatever length has been determined to be most efficient for that office: 7 bits, 14 bits,
> 21 bits, whatever.

You are assuming that all of the nodes in your small research network have a common
office ID. That may only very rarely be the case when thinking about applications such
as MANETs, etc. That is why I have been saying that, while DTN nodes certainly have
an origin (i.e., a "home office") we must assume that they are always away from home
and potentially commingling with nodes from other offices.

> Whenever it is recognized that a bundle's destination requires the bundle to cross an office boundary, office ID extension blocks are
> added to disambiguate the brief node ID numbers.  The length of an office ID is always 64 bits (or, my preference, 63 bits; this avoids
> writing another whole SDNV byte just to double the size of the namespace) less the number of bits in the office's node ID number
> length.
> 
> So traffic that is wholly internal to an office is as bit-efficient as possible, but traffic on the global network is always routable by the
> lengthy global IDs.  Global IDs are allocated on whatever basis you like; the partitioning of the global ID into office ID and office-specific
> node ID is entirely a private office administration matter that nobody else in the network needs to know or care about.  The insertion
> and (potentially) removal of office ID extension blocks is the same straightforward extension block management mechanism we've
> already got in the architecture; it happens at the routers and it is very straightforward, with no need for any mapping between long
> and short node IDs, so the gateway management problem goes away.
> 
> What do you think?

I think  this is basically the same as encoding a network part and a host part
in the DTN node ID much in the same way as for IPv4 and IPv6. I thought we
were trying to avoid encoding topology information in DTN node IDs.

Thanks - Fred

> > network ranges, every node of which would have a 28-bit ID that would fit into a 4-byte SDNV.  We could allocate 33.5 million of
> them and still have every node's ID fit into a 5-byte SDNV, still a savings of at least 12 bytes in every bundle header -- without any
> Networks that care so much about reducing the node ID length likely comprise low-end links and/or systems and would use a gateway
> to connect to the rest of the universe anyway. Surely, we do not want dynamic routing updates and other high-bandwidth control
> messaging to flow over those links - the control messages would instead be terminated by the gateway. So, why wouldn't the
> gateway also provide node ID translation services?
> 
> Thanks - Fred
> > of course help, if you are able to use ID 1 to 127. You do not want to be forced to use a looong (the longest possible) identifier, just
> because then "it is fair for everyone". Understandable.
> >
> > address space and just use those :)  I agree however, that policy questions, albeit important,  about how to distribute the address
> space should be part of a separate discussion.
> >
> > Sebastian
> >
> >
> >

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jun 2015 16:39:08 +0000

Scott,

> primary block, because the primary block is no longer immutable.

You really want bundles that would fail an integrity check to be dropped at the
gateway anyway instead of conveying them across the low-end link and wasting
precious bandwidth.

Thanks - Fred

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 11 Jun 2015 17:00:02 +0000

Fred, some remarks in-line below.

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, June 11, 2015 9:30 AM
To: Burleigh, Scott C (312B); Sebastian Schildt
Cc: Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Hi Scott,

> Fred, I don't understand why you think a small research network would 
> want or need to be separated from the rest of the network by a 
> gateway.  There aren't currently any gateway functions defined in DTN 
> architecture at all, nor are there any high-bandwidth control messages 
> that research network nodes need to be shielded from.  Certainly there might be in the future, and nothing in the DTN architecture precludes these developments, but currently nothing requires them - except the node ID translation function you're proposing.
> 
> Node ID translation presents at least one other problem as well: we 
> lose the possibility of end-to-end integrity protection of the primary block, because the primary block is no longer immutable.

That's OK; the integrity protection extends from the source to the gateway, and then a second integrity protection extends from the gateway to the destination.

>>	No, I think it's not OK.  If I am an application sending data in bundles over the network, I think I want assurance that the primary block of the bundle as received is bit-for-bit identical to what was sent.  End-to-end integrity protection means end-to-end integrity protection.  However, this question is moot if we adopt a mechanism along the lines I proposed below rather than translating node IDs.

> Okay, how about this as an alternative?  Let's define an "office ID" 
> extension block that identifies a numeric "office ID", to disambiguate a numeric source or destination or report-to (or whatever) node ID.
> 
> When node A sends a bundle to node B that is in the same "office" 
> (e.g., small research network; this is an administrative mechanism) 
> and is reachable without forwarding through any node in any other 
> office, no office ID extension blocks are attached.  The source, 
> destination, etc. node ID numbers are all of whatever length has been 
> determined to be most efficient for that office: 7 bits, 14 bits,
> 21 bits, whatever.

You are assuming that all of the nodes in your small research network have a common office ID. That may only very rarely be the case when thinking about applications such as MANETs, etc. That is why I have been saying that, while DTN nodes certainly have an origin (i.e., a "home office") we must assume that they are always away from home and potentially commingling with nodes from other offices.

>>	No, not at all.  All of the nodes in my small research network *by definition* have a common office ID, because that is how I am defining "office".  The "office" concept has no topological significance at all.  It is strictly administrative, as I stated.  There is no notion of "home" here, or "origin".  An "office" is simply a set of nodes whose assigned IDs all have some number of high-order bits in common.  This is just a mechanism for abbreviating node IDs.

> Whenever it is recognized that a bundle's destination requires the 
> bundle to cross an office boundary, office ID extension blocks are 
> added to disambiguate the brief node ID numbers.  The length of an 
> office ID is always 64 bits (or, my preference, 63 bits; this avoids writing another whole SDNV byte just to double the size of the namespace) less the number of bits in the office's node ID number length.
> 
> So traffic that is wholly internal to an office is as bit-efficient as 
> possible, but traffic on the global network is always routable by the 
> lengthy global IDs.  Global IDs are allocated on whatever basis you 
> like; the partitioning of the global ID into office ID and 
> office-specific node ID is entirely a private office administration 
> matter that nobody else in the network needs to know or care about.  The insertion and (potentially) removal of office ID extension blocks is the same straightforward extension block management mechanism we've already got in the architecture; it happens at the routers and it is very straightforward, with no need for any mapping between long and short node IDs, so the gateway management problem goes away.
> 
> What do you think?

I think  this is basically the same as encoding a network part and a host part in the DTN node ID much in the same way as for IPv4 and IPv6. I thought we were trying to avoid encoding topology information in DTN node IDs.

>>	Not at all, because office IDs have no topological significance.  If office IDs and node IDs were topologically significant then I would agree with you that this partitioning would be basically the same as encoding a network part and a host part in an IP address.  But they are not, so I don't.  Given which, what is your objection to this mechanism?

Thanks - Fred

> > Hi, Sebastian.  I definitely agree that a 64-bit global node ID 
> > space is needed for an Internet-scale network.  All we're talking 
> > about here is whether those global IDs are always 64 bits long when 
> > transmitted or, alternatively, they can have leading zeros that can 
> > be
> > ranges is undesirable.  I just think that the solution is careful 
> > We clearly wouldn't be able to accomplish that careful development 
> > of range allocation policy in this email thread, but I don't think that means it's impossible.
> >
> > (2^10)-1, i.e., 1023.  We could allocate 2^18 = 262,144 such 
> > research network ranges, every node of which would have a 28-bit ID 
> > that would fit into a 4-byte SDNV.  We could allocate 33.5 million 
> > of
> them and still have every node's ID fit into a 5-byte SDNV, still a 
> savings of at least 12 bytes in every bundle header -- without any need for any gateways anywhere, ever.
> >
> > configured, managed, updated, troubleshot, defended against 
> > cyber-attack, etc.  That sounds to me like millions of hours of 
> > tedious
> yet critical work.
> 
> Networks that care so much about reducing the node ID length likely 
> comprise low-end links and/or systems and would use a gateway to 
> connect to the rest of the universe anyway. Surely, we do not want 
> dynamic routing updates and other high-bandwidth control messaging to flow over those links - the control messages would instead be terminated by the gateway. So, why wouldn't the gateway also provide node ID translation services?
> 
> Thanks - Fred
> > I am not sure I follow your argument completely. Practically 
> > speaking you want short IDs (overhead) in your application. And 
> > using SDNVs can of course help, if you are able to use ID 1 to 127. 
> > You do not want to be forced to use a looong (the longest possible) 
> > identifier, just
> > 0xFFFFFFFFFF are not globally routable, or alternatively, if opting 
> > for some prefix/network scheme something like network „0“ could
> > for being able to connect a rover to its own facebook page is 
> > assigning it a public (long) ID with a simple 1-to-1 mapping on some
> > And if you still do not like the translation for your setup, you 
> > would still be able to grab those precious first blocks of the 
> > global address space and just use those :)  I agree however, that 
> > policy questions, albeit important,  about how to distribute the 
> > address
> > >> transmission overhead as research submersibles on acoustic 
> > >> modems, even if
> > has a long universal ID it does not use it in its underwater 
> > acoustic transmissions; instead, it uses a little 16bit local area 
> > ID, and relies on a translating gateway to translate the local ID to 
> > the universal. I think the other viewpoint (only use universal IDs, 
> > and take
> maximum advantage of SDNV compression) is perhaps more of a strict 
> end-to-end viewpoint whereas the IETF has moved on to consider the "Rise of the Middle and the Future of End-to-End" (e.g., RFC3724).
> > >
> > >> What I would say, though, is that namespace allocation is a 
> > >> matter of policy rather than a matter of technology.  We can 
> > >> engineer the protocols to obviate the potential policy failures, 
> > >> or we can engineer the protocols to confer as much technology 
> > >> advantage as
> > >>> efficiency that we can get with SDNVs, and I'd prefer not to 
> > >>> have to deploy
> > >> guess I still see it that the transmission efficiency is only 
> > >> there for early adopters and the advantage shrinks as more and 
> > >> more chunks of
> > ID space are allocated.
> > >>> Cc: Burleigh, Scott C (312B); Greg Troxel; 
> > >>> [email-masked]; Rick Taylor; [email-masked]
> > >>> familiar with IEEE 802.15.4 („ZigBee“)? Yes, it is a lower 
> > >>> layer, but basically it tackles the same problem: First, 
> > >>> addresses are 64 bit (long addresses). This should be enough for 
> > >>> a while. Because IEEE
> > >>> 8021.5.4 is used on low datarate links and tiny 
> > >>> microcontrollers, you do not always want to throw around 64 bit 
> > >>> addresses when sending a 16 bit temperature sample. Therefore 
> > >>> there is a short addressing
> > >> sounds similar to Fred’s „network of origin“). There are some 
> > >> flags managing addressing in the header so that you can go from 
> > >> src&dst PAN
> > >>> 64 bit address space or a 16 bit PAN ID (in IEEE 802.15.4 there 
> > >>> is no such thing, but lets just assume they would do it to get 
> > >>> globally valid addresses for a super-WSN), is not a problem: 
> > >>> Even if you are late/unlucky  full addresses „suck“, in your 
> > >>> application you can
> > >>> the things discussed in this thread are already quite similar, 
> > >>> but maybe it can serve as an inspiration looking at a spec, 
> > >>> where such an
> > >>>> I think that is one way to look at it, yes. Much in the same 
> > >>>> way that early IP adopters snapped up Class A networks, while 
> > >>>> others who were less lucky got only Class B and Class C. CIDR 
> > >>>> finally came through and broke that logjam, but by then it was 
> > >>>> too late and a privileged few land grabbers ended up with the 
> > >>>> choice cuts of the address space. We have an opportunity to avoid a repeat of history now.
> > >>>>
> > >>>>> grabbed all the ranges of short numbers, and everybody else 
> > >>>>> has to get by with long numbers.  So the fair thing is to require that everybody use long numbers, yes?
> > >>>>
> > >>>>>> Fred, I still don't understand the problem. What we've 
> > >>>>>> already got defined for the "ipn" scheme (for example) is a 
> > >>>>>> 64-bit numeric node name space, of which subsets are 
> > >>>>>> allocated to various administrative entities for assignment 
> > >>>>>> to the nodes they instantiate;
> > >>>>>
> > >>>>> also of the opinion that this system should not be optimized 
> > >>>>> to suit the specific needs of just
> > >>>>>> When the domain of operation is universal-scope, who is to 
> > >>>>>> say that we should give a 16-bit universally unique node ID 
> > >>>>>> to a sensor node mote but then
> > >>>>>>>> but my own vision for DTN definitely extends (eventually) 
> > >>>>>>>> to a single interconnected global network of interoperating 
> > >>>>>>>> I am abundantly aware that there are plenty of people in 
> > >>>>>>>> the DTN community who see lots of value in using what I 
> > >>>>>>>> would consider lengthy character strings to identify nodes 
> > >>>>>>>> and endpoints.  I myself am not a fan, but that doesn't 
> > >>>>>>>> mean that everybody else is wrong, nor that I'm wrong.  The 
> > >>>>>>>> ION and
> > >>>>>>>> Coming back to numeric ID sizes in particular: I can 
> > >>>>>>>> imagine a spacecraft orbiting Phobos that is identified by 
> > >>>>>>>> a 3-byte SDNV numeric node ID, communicating with other 
> > >>>>>>>> orbiters and landers in the Mars-Phobos system that are 
> > >>>>>>>> likewise identified by 3-byte node IDs, and sending images 
> > >>>>>>>> to an imaging spectrometer's Principal Investigator in 
> > >>>>>>>> Chicago who receives science data at an iPad-based BP node 
> > >>>>>> a limited-scope DTN. It wouldn't be too far different from 
> > >>>>>> the way IPv4 has both global scope and RFC1918 privacy
> addresses.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jun 2015 17:44:14 +0000

Hi Scott,

OK, let me try again:

> Sent: Thursday, June 11, 2015 10:00 AM
> > that research network nodes need to be shielded from.  Certainly there might be in the future, and nothing in the DTN architecture
> precludes these developments, but currently nothing requires them - except the node ID translation function you're proposing.
> >
> >>	No, I think it's not OK.  If I am an application sending data in bundles over the network, I think I want assurance that the
> primary block of the bundle as received is bit-for-bit identical to what was sent.  End-to-end integrity protection means end-to-end
> integrity protection.  However, this question is moot if we adopt a mechanism along the lines I proposed below rather than translating
> node IDs.

In IPv4, primary block integrity checking is hop-by-hop. It lets the network
discard packets that have corrupt headers early on so that they don't consume
link resources further down the line. While I recognize that the goal for DTN
is end-to-end, the gateway appears as an "proxy end" that is very near to the
actual end.

> You are assuming that all of the nodes in your small research network have a common office ID. That may only very rarely be the case
> when thinking about applications such as MANETs, etc. That is why I have been saying that, while DTN nodes certainly have an origin
> (i.e., a "home office") we must assume that they are always away from home and potentially commingling with nodes from other
> offices.
> 
> >>	No, not at all.  All of the nodes in my small research network *by definition* have a common office ID, because that is how I
> am defining "office".  The "office" concept has no topological significance at all.  It is strictly administrative, as I stated.  There is no
> notion of "home" here, or "origin".  An "office" is simply a set of nodes whose assigned IDs all have some number of high-order bits in
> common.  This is just a mechanism for abbreviating node IDs.

Help me out - when you say "whose assigned IDs all have some number
of high-order bits in common", do you mean all 64bits (or, 63 bits) in the
office ID extension block? Then, what if there is no well-defined office
structure and everything is ad-hoc - like in a MANET. Are you saying that
an office ID identifies a border router that connects the "office" to the
rest of the DTN?

> > office ID is always 64 bits (or, my preference, 63 bits; this avoids writing another whole SDNV byte just to double the size of the
> namespace) less the number of bits in the office's node ID number length.
> >
> > matter that nobody else in the network needs to know or care about.  The insertion and (potentially) removal of office ID extension
> blocks is the same straightforward extension block management mechanism we've already got in the architecture; it happens at the
> routers and it is very straightforward, with no need for any mapping between long and short node IDs, so the gateway management
> problem goes away.
> >
> > What do you think?

I am still trying to understand "office ID". Is it an N bit office ID number
concatenated with an M bit node ID number where N+M = 63/64? Or is
it a 63/64 bit number that identifies the office, and the M bit node ID is
a separate number?

How about this instead. Each DTN node gets a 63/64 bit global ID, and
DTN routing tracks the node wherever it goes. If the node enters an
office with low-end links, it will receive a short (maybe 16bit) local
scope ID that it can use as source/destination for intra-office
communications. If the node wishes to communicate with a
correspondent outside of the office, it appends its own 63/64 bit
global ID and not an office ID.

> I think  this is basically the same as encoding a network part and a host part in the DTN node ID much in the same way as for IPv4 and
> IPv6. I thought we were trying to avoid encoding topology information in DTN node IDs.
> 
> >>	Not at all, because office IDs have no topological significance.  If office IDs and node IDs were topologically significant then I
> would agree with you that this partitioning would be basically the same as encoding a network part and a host part in an IP address.
> But they are not, so I don't.  Given which, what is your objection to this mechanism?

I think the only objection would be that, if the node has to append a 64bit
office/node ID and that value needs to traverse low-end links before it
emerges from the office then you are still back to the original problem
of carrying too many bits on low-end links. Better to have the router
append the 64bit office/node ID, but then it begins to look like a
gateway.

Here's another question - how is the short local-scope ID assigned?
Manual configuration? DTN-DHCP?

Thanks - Fred

> > dynamic routing updates and other high-bandwidth control messaging to flow over those links - the control messages would instead
> be terminated by the gateway. So, why wouldn't the gateway also provide node ID translation services?
> >
> > Thanks - Fred
> > > make them usable globally (inter-planetary) on Internet-scale networks (and I think we should), we need them to be "long
> enough"
> > (think IPv4/v6).
> > >

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 11 Jun 2015 20:20:10 +0000

Hi, Fred.  Let me reorganize and amplify, to try to make this hang together a bit better.

1.  Just for background: we are talking here about the principles for operating an EID scheme that is based, at least in part, on numeric node IDs.  (Other EID schemes, whether numeric or string-based, are certainly worth discussing but are not part of this discussion.)

2.  Every node that must be identified in the operation of this scheme has got a 63-bit global node ID.  [Or 64-bit, if everybody thinks that's important.]  IANA (I guess) allocates ranges of node IDs to administrative entities such as companies, universities, space agencies, etc. who request them.  An administrative entity that has been allocated a given range of 63-bit node ID numbers has exclusive authority to assign the ID numbers in that range to BP nodes.  Since all of the node ID numbers are 63 bits long, no range has any particular operational advantage over any other.  If we want the leading 23 bits of each node ID number to identify the "origin" of the ID number, fine.

3.  The administrative entity that has exclusive authority to assign the ID numbers is in some range X1 through X2 may choose to subdivide that range into sub-ranges, termed "offices".  The nature of this subdivision is the administrative entity's own private affair; an "office" might be some set of nodes that frequently communicate among themselves over highly constrained links (e.g., a research project), but the motivation for forming a given office is none of our business.  Allocation of node IDs within an office is likewise the administrative entity's own private affair; the machinery for doing this may evolve over time, but for now we don't have to care. 

4.  Just as node IDs have no topological significance, offices have absolutely no topological significance.  They exist solely as a mechanism for abbreviating node IDs.

5.  Any single office comprises all nodes in the range Y1 through (Y2 - 1) where Y2 exceeds Y1 by exactly 2**(7*Q), where Q (let's call it the "order" of the office) is an integer in the range 1 to 8.  2**(7*Q) is the "size" of the office.  If Q is 1 then there are 2**7 = 128 node IDs available for allocation in this office; if Q is 2 then the size of the office is 2**14 = 16384 node IDs, and so on.  The high-order (63 - (7*Q)) bits of the IDs of all nodes in any office are identical; the numeric value of these high-order (63 - (7*Q)) bits uniquely identifies the office.

6.  So the 63-bit node ID of a node in an office of order Q may be thought of as having two parts: the high-order (63 - (7*Q)) bits that are the "office ID" followed by the (7*Q) bits that are the "private ID" of the node.

7.  When a node issues a bundle, the source and destination node IDs noted in the primary header may both be full 63-bit node IDs.  Alternatively, though, both of these IDs may be just the private ID portions of the node IDs, and the bundle may or may not contain "office ID" extension blocks that supply the office ID portions: if and only if the source and destination are both in the same office, the office ID extension blocks may be omitted.  (Of course, if the source node knows that the destination node is in another office then it would be more efficient simply to use the full 63-bit node IDs right from the beginning.)

8.  When forwarding a bundle whose primary header contains a full 63-bit destination node ID, the forwarding node routes the bundle in the normal way; likewise when forwarding a bundle whose destination is represented as a private ID but whose extension blocks include a destination office ID extension block.  (The extension block's office ID, concatenated with the destination private ID, constitutes the full 63-bit destination node ID.)

9.  But when forwarding a bundle *lacking* a destination office ID extension block, whose destination is a private ID, the forwarding node computes a route based on the concatenation of its own office ID (that is, the ID of the office that is common to all nodes that have handled this bundle so far) and the destination private ID.  If the first hop on that route is a node that is in a different office, then the forwarding node inserts source and destination office ID extension blocks before sending the bundle onward.

So:
-	Traffic that is wholly internal to an office is bit-efficient, because private IDs are used and office ID extension blocks are always omitted.
-	Traffic on the global network is always routable, because either full node IDs are used or else office ID extension blocks are included: full node IDs can always be used for route computation.
-	Global IDs are allocated on whatever basis seems fair.  No land rush.
-	All node IDs are permanent.  No need for any temporary allocation of anything.
-	There is no need to maintain any table that maps between global IDs and local IDs: global ID is always simply office ID followed by private ID.

If you want to call the conditional insertion of extension blocks by a router a "gateway function", fine, it's a gateway function.

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, June 11, 2015 10:44 AM
To: Burleigh, Scott C (312B); Sebastian Schildt
Cc: Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Hi Scott,

OK, let me try again:

> > Fred, I don't understand why you think a small research network 
> > would want or need to be separated from the rest of the network by a 
> > gateway.  There aren't currently any gateway functions defined in 
> > DTN architecture at all, nor are there any high-bandwidth control 
> > messages that research network nodes need to be shielded from.  
> > Certainly there might be in the future, and nothing in the DTN 
> > architecture
> That's OK; the integrity protection extends from the source to the 
> gateway, and then a second integrity protection extends from the gateway to the destination.
> 
> >>	No, I think it's not OK.  If I am an application sending data in 
> >>bundles over the network, I think I want assurance that the
> primary block of the bundle as received is bit-for-bit identical to 
> what was sent.  End-to-end integrity protection means end-to-end 
> integrity protection.  However, this question is moot if we adopt a mechanism along the lines I proposed below rather than translating node IDs.

In IPv4, primary block integrity checking is hop-by-hop. It lets the network discard packets that have corrupt headers early on so that they don't consume link resources further down the line. While I recognize that the goal for DTN is end-to-end, the gateway appears as an "proxy end" that is very near to the actual end.

> > extension block that identifies a numeric "office ID", to 
> > disambiguate a numeric source or destination or report-to (or 
> > whatever)
> node ID.
> >
> > destination, etc. node ID numbers are all of whatever length has 
> > been determined to be most efficient for that office: 7 bits, 14 
> > bits,
> > 21 bits, whatever.
> 
> You are assuming that all of the nodes in your small research network 
> have a common office ID. That may only very rarely be the case when 
> thinking about applications such as MANETs, etc. That is why I have 
> been saying that, while DTN nodes certainly have an origin (i.e., a "home office") we must assume that they are always away from home and potentially commingling with nodes from other offices.
> 
> >>	No, not at all.  All of the nodes in my small research network *by 
> >>definition* have a common office ID, because that is how I
> am defining "office".  The "office" concept has no topological 
> significance at all.  It is strictly administrative, as I stated.  
> There is no notion of "home" here, or "origin".  An "office" is simply a set of nodes whose assigned IDs all have some number of high-order bits in common.  This is just a mechanism for abbreviating node IDs.

Help me out - when you say "whose assigned IDs all have some number of high-order bits in common", do you mean all 64bits (or, 63 bits) in the office ID extension block? Then, what if there is no well-defined office structure and everything is ad-hoc - like in a MANET. Are you saying that an office ID identifies a border router that connects the "office" to the rest of the DTN?

> > office ID is always 64 bits (or, my preference, 63 bits; this avoids 
> > writing another whole SDNV byte just to double the size of the
> > So traffic that is wholly internal to an office is as bit-efficient 
> > as possible, but traffic on the global network is always routable by 
> > the lengthy global IDs.  Global IDs are allocated on whatever basis 
> > you like; the partitioning of the global ID into office ID and 
> > matter that nobody else in the network needs to know or care about.  
> > The insertion and (potentially) removal of office ID extension
> blocks is the same straightforward extension block management 
> mechanism we've already got in the architecture; it happens at the 
> routers and it is very straightforward, with no need for any mapping between long and short node IDs, so the gateway management problem goes away.
> >
> > What do you think?

I am still trying to understand "office ID". Is it an N bit office ID number concatenated with an M bit node ID number where N+M = 63/64? Or is it a 63/64 bit number that identifies the office, and the M bit node ID is a separate number?

How about this instead. Each DTN node gets a 63/64 bit global ID, and DTN routing tracks the node wherever it goes. If the node enters an office with low-end links, it will receive a short (maybe 16bit) local scope ID that it can use as source/destination for intra-office communications. If the node wishes to communicate with a correspondent outside of the office, it appends its own 63/64 bit global ID and not an office ID.

> I think  this is basically the same as encoding a network part and a 
> host part in the DTN node ID much in the same way as for IPv4 and IPv6. I thought we were trying to avoid encoding topology information in DTN node IDs.
> 
> >>	Not at all, because office IDs have no topological significance.  
> >>If office IDs and node IDs were topologically significant then I

I think the only objection would be that, if the node has to append a 64bit office/node ID and that value needs to traverse low-end links before it emerges from the office then you are still back to the original problem of carrying too many bits on low-end links. Better to have the router append the 64bit office/node ID, but then it begins to look like a gateway.

Thanks - Fred

> > > about here is whether those global IDs are always 64 bits long 
> > > when transmitted or, alternatively, they can have leading zeros 
> > > that can be
> > > development of range allocation policy rather than requiring 
> > > useless
> > leading bits in the standard.
> > >
> > > Suppose -- strictly as a strawman, proof-of-concept sort of thing 
> > > -- we say the maximum number of nodes in any such network will be 
> > > research network ranges, every node of which would have a 28-bit 
> > > ID that would fit into a 4-byte SDNV.  We could allocate 33.5 
> > > million of
> > dynamic routing updates and other high-bandwidth control messaging 
> > to flow over those links - the control messages would instead
> > > You do not want to be forced to use a looong (the longest 
> > > possible) identifier, just
> > > make them usable globally (inter-planetary) on Internet-scale 
> > > networks (and I think we should), we need them to be "long
> enough"
> > (think IPv4/v6).
> > >
> > > I really think private/local address spaces are the solution: If 
> > > we have a flat numeric address scheme, you could say  define 0x0- 
> > > 0xFFFFFFFFFF are not globally routable, or alternatively, if 
> > > opting for some prefix/network scheme something like network „0“ 
> > > could
> > > building NASA's whole network with "private" IDs, all that is 
> > > needed for being able to connect a rover to its own facebook page 
> > > is assigning it a public (long) ID with a simple 1-to-1 mapping on 
> > > some
> > > > Fred, I certainly expect that the submersible would be talking 
> > > > to the bank through a router, but there's no need for a gateway 
> > > > unless
> > > translating gateway that joins the underwater network domain to 
> > > the terrestrial world. That means that, while the submersible 
> > > certainly has a long universal ID it does not use it in its 
> > > underwater acoustic transmissions; instead, it uses a little 16bit 
> > > local area ID, and relies on a translating gateway to translate 
> > > the local ID to the universal. I think the other viewpoint (only 
> > > use universal IDs, and take
> > end-to-end viewpoint whereas the IETF has moved on to consider the 
> > "Rise of the Middle and the Future of End-to-End" (e.g.,
> RFC3724).
> > > >
> > > >> engineer the protocols to obviate the potential policy 
> > > >> failures, or we can engineer the protocols to confer as much 
> > > >> technology advantage as
> > > >>> I read this discussion, but I am not quite sure, where Fred 
> > > >>> and Scott disagree. So, if I understand it correctly, 
> > > >>> basically both of you wish/are ok with a numeric namespace. Is 
> > > >>> anyone here familiar with IEEE 802.15.4 („ZigBee“)? Yes, it is 
> > > >>> a lower layer, but basically it tackles the same problem: 
> > > >>> First, addresses are 64 bit (long addresses). This should be 
> > > >>> enough for a while. Because IEEE
> > > >>> microcontrollers, you do not always want to throw around 64 
> > > >>> bit addresses when sending a 16 bit temperature sample. 
> > > >>> Therefore there is a short addressing
> > > >>> 64 bit address space or a 16 bit PAN ID (in IEEE 802.15.4 
> > > >>> there is no such thing, but lets just assume they would do it 
> > > >>> to get globally valid addresses for a super-WSN), is not a problem:
> > > >>> Wouldn’t this make you both happy, @Fred/Scott? I guess some 
> > > >>> of the things discussed in this thread are already quite 
> > > >>> similar, but maybe it can serve as an inspiration looking at a 
> > > >>> spec, where such an
> > > >>>> finally came through and broke that logjam, but by then it 
> > > >>>> was too late and a privileged few land grabbers ended up with 
> > > >>>> the choice cuts of the address space. We have an opportunity to avoid a repeat of history now.
> > > >>>>
> > > >>>>>> 2^14 through (2^21)-1, and there's a procedure for 
> > > >>>>>> allocating other ranges to whoever needs them.  But in 
> > > >>>>>> over-the-wire representation we are able to economize on 
> > > >>>>>> transmission by omitting a lot of
> > > >>>>>>> What's wrong with using variable-length numbers and 
> > > >>>>>>> strings as permanent node identifiers,
> > > >>>>>>
> > > >>>>>> numeric names if they came from the same 64-bit naming 
> > > >>>>>> space (and then use a
> > > >>>>>>>> to a single interconnected global network of 
> > > >>>>>>>> interoperating entities.  I don't think the mechanism 
> > > >>>>>>>> I've been talking about is incompatible with
> > > >>>>>>> that, though.
> > > >>>>>>>>
> > > >>>>>>>> would consider lengthy character strings to identify 
> > > >>>>>>>> nodes and endpoints.  I myself am not a fan, but that 
> > > >>>>>>>> doesn't mean that everybody else is wrong, nor that I'm 
> > > >>>>>>>> wrong.  The ION and
> > > >>>>>>> implementations of BP can forward and acquire bundles 
> > > >>>>>>> tagged with both types of IDs.  I think global 
> > > >>>>>>> interoperability isn't necessarily threatened by BP's 
> > > >>>>>>> tolerance of different naming
> > > schemes.
> > > >>>>>>>>
> > > >>>>>>>> imagine a spacecraft orbiting Phobos that is identified 
> > > >>>>>>>> by a 3-byte SDNV numeric node ID, communicating with 
> > > >>>>>>>> other orbiters and landers in the Mars-Phobos system that 
> > > >>>>>>>> are likewise identified by 3-byte node IDs, and sending 
> > > >>>>>>>> images to an imaging spectrometer's Principal 
> > > >>>>>>>> Investigator in Chicago who receives science data at an 
> > > >>>>>>>> iPad-based BP node identified by a 10-digit node ID.  The 
> > > >>>>>>> space assets impose minimal overhead on their 
> > > >>>>>>> communication channels, while the larger overhead on the 
> > > >>>>>>> science data return bundles is amortized over the larger 
> > > >>>>>>> size of the images.  I don't think this is
> > > >>>>>> difficult.
> > > >>>>>>>
> > > >>>>>>> Later, when multiple local networks are bridged together 
> > > >>>>>>> to form a larger DTN, they would have to deprecate their 
> > > >>>>>>> local addresses/names and begin using their universal addresses/names.
> > > >>>>>>> What do
> > > >>>>>> you think?
> > > >>>>>>>
> > > >>>>>>> Thanks - Fred
> > > >>>>>>>>> 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
> > > >>>>>>>> lack of global interoperability.  Most if not almost all 
> > > >>>>>>>> of the usefulness of IP is due to the existence of a 
> > > >>>>>>>> single interconnected global

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jun 2015 21:59:30 +0000

Hi Scott,

> Sent: Thursday, June 11, 2015 1:20 PM
> 1.  Just for background: we are talking here about the principles for operating an EID scheme that is based, at least in part, on numeric
> node IDs.  (Other EID schemes, whether numeric or string-based, are certainly worth discussing but are not part of this discussion.)
> 
> 2.  Every node that must be identified in the operation of this scheme has got a 63-bit global node ID.  [Or 64-bit, if everybody thinks
> that's important.]  IANA (I guess) allocates ranges of node IDs to administrative entities such as companies, universities, space
> agencies, etc. who request them.  An administrative entity that has been allocated a given range of 63-bit node ID numbers has
> exclusive authority to assign the ID numbers in that range to BP nodes.  Since all of the node ID numbers are 63 bits long, no range has
> any particular operational advantage over any other.  If we want the leading 23 bits of each node ID number to identify the "origin" of
> the ID number, fine.

That is very much like IEEE 802 MAC address assignment, yes.

> 3.  The administrative entity that has exclusive authority to assign the ID numbers is in some range X1 through X2 may choose to
> subdivide that range into sub-ranges, termed "offices".  The nature of this subdivision is the administrative entity's own private affair;
> an "office" might be some set of nodes that frequently communicate among themselves over highly constrained links (e.g., a research
> project), but the motivation for forming a given office is none of our business.  Allocation of node IDs within an office is likewise the
> administrative entity's own private affair; the machinery for doing this may evolve over time, but for now we don't have to care.

That is very much unlike IEEE 802 MAC address assignment. Once an organization
burns IEEE 802 MAC addresses into products and releases them to the public, they
scatter to the four winds and may never even talk to one another throughout their
operational lifetimes. So, the concept of nodes being co-located in an "office"
seems like a rare exception to me and not the ordinary expectation of vendors
of DTN products.

> 5.  Any single office comprises all nodes in the range Y1 through (Y2 - 1) where Y2 exceeds Y1 by exactly 2**(7*Q), where Q (let's call it
> the "order" of the office) is an integer in the range 1 to 8.  2**(7*Q) is the "size" of the office.  If Q is 1 then there are 2**7 = 128 node
> IDs available for allocation in this office; if Q is 2 then the size of the office is 2**14 = 16384 node IDs, and so on.  The high-order (63 -
> (7*Q)) bits of the IDs of all nodes in any office are identical; the numeric value of these high-order (63 - (7*Q)) bits uniquely identifies
> the office.
> 
> 6.  So the 63-bit node ID of a node in an office of order Q may be thought of as having two parts: the high-order (63 - (7*Q)) bits that
> are the "office ID" followed by the (7*Q) bits that are the "private ID" of the node.

I am guessing that the reason for (7*Q) is to map better to SDNVs, right?

> 7.  When a node issues a bundle, the source and destination node IDs noted in the primary header may both be full 63-bit node IDs.
> Alternatively, though, both of these IDs may be just the private ID portions of the node IDs, and the bundle may or may not contain
> "office ID" extension blocks that supply the office ID portions: if and only if the source and destination are both in the same office, the
> office ID extension blocks may be omitted.

The model I have been envisioning is a MANET. The MANET can be standalone,
or it can connect to a more stable network like the Internet via one or more
MANET/Internet routers (aka "gateways"). Nodes within the MANET may have
no idea nor expectation that other nodes from their home office will show up
in the same MANET - a far more likely case is that the nodes would have a
scattering of node IDs issued by many different origins.

> (Of course, if the source node knows that the destination node is in another office then it
> would be more efficient simply to use the full 63-bit node IDs right from the beginning.)

What if the source and destination are in the same MANET? It would be nice
to be able to use a short little local ID for intra-MANET communications even
if the two nodes have universal IDs from different origins/offices. That
would require a global ID to local ID mapping system within the MANET;
most probably something orchestrated by a MANET gateway.

> 8.  When forwarding a bundle whose primary header contains a full 63-bit destination node ID, the forwarding node routes the bundle
> in the normal way; likewise when forwarding a bundle whose destination is represented as a private ID but whose extension blocks
> include a destination office ID extension block.  (The extension block's office ID, concatenated with the destination private ID,
> constitutes the full 63-bit destination node ID.)
> 
> 9.  But when forwarding a bundle *lacking* a destination office ID extension block, whose destination is a private ID, the forwarding
> node computes a route based on the concatenation of its own office ID (that is, the ID of the office that is common to all nodes that
> have handled this bundle so far) and the destination private ID.  If the first hop on that route is a node that is in a different office, then
> the forwarding node inserts source and destination office ID extension blocks before sending the bundle onward.

I'm afraid I may still be missing the point as to how this is supposed to work.
It all seems too complicated to me to the point that I don't understand it;
naming/addressing should be simple.

> -	Traffic on the global network is always routable, because either full node IDs are used or else office ID extension blocks are
> included: full node IDs can always be used for route computation.

I go back to the MANET example. There can be no expectation that nodes that
end up in the same randomly-formed MANET are from the same office.

Thanks - Fred

> In IPv4, primary block integrity checking is hop-by-hop. It lets the network discard packets that have corrupt headers early on so that
> they don't consume link resources further down the line. While I recognize that the goal for DTN is end-to-end, the gateway appears
> as an "proxy end" that is very near to the actual end.
> 
> > been saying that, while DTN nodes certainly have an origin (i.e., a "home office") we must assume that they are always away from
> home and potentially commingling with nodes from other offices.
> >
> > There is no notion of "home" here, or "origin".  An "office" is simply a set of nodes whose assigned IDs all have some number of
> high-order bits in common.  This is just a mechanism for abbreviating node IDs.
> 
> Help me out - when you say "whose assigned IDs all have some number of high-order bits in common", do you mean all 64bits (or, 63
> bits) in the office ID extension block? Then, what if there is no well-defined office structure and everything is ad-hoc - like in a MANET.
> Are you saying that an office ID identifies a border router that connects the "office" to the rest of the DTN?
> 
> I am still trying to understand "office ID". Is it an N bit office ID number concatenated with an M bit node ID number where N+M =
> 63/64? Or is it a 63/64 bit number that identifies the office, and the M bit node ID is a separate number?
> 
> How about this instead. Each DTN node gets a 63/64 bit global ID, and DTN routing tracks the node wherever it goes. If the node
> enters an office with low-end links, it will receive a short (maybe 16bit) local scope ID that it can use as source/destination for intra-
> office communications. If the node wishes to communicate with a correspondent outside of the office, it appends its own 63/64 bit
> I think the only objection would be that, if the node has to append a 64bit office/node ID and that value needs to traverse low-end
> links before it emerges from the office then you are still back to the original problem of carrying too many bits on low-end links. Better
> to have the router append the 64bit office/node ID, but then it begins to look like a gateway.
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 11 Jun 2015 22:31:59 +0000

Some more comments in-line below (>>>).

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, June 11, 2015 3:00 PM
To: Burleigh, Scott C (312B); Sebastian Schildt
Cc: Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Hi Scott,

> 1.  Just for background: we are talking here about the principles for 
> operating an EID scheme that is based, at least in part, on numeric 
> node IDs.  (Other EID schemes, whether numeric or string-based, are 
> certainly worth discussing but are not part of this discussion.)
> 
> 2.  Every node that must be identified in the operation of this scheme 
> has got a 63-bit global node ID.  [Or 64-bit, if everybody thinks 
> that's important.]  IANA (I guess) allocates ranges of node IDs to 
> administrative entities such as companies, universities, space 
> agencies, etc. who request them.  An administrative entity that has 
> been allocated a given range of 63-bit node ID numbers has exclusive authority to assign the ID numbers in that range to BP nodes.  Since all of the node ID numbers are 63 bits long, no range has any particular operational advantage over any other.  If we want the leading 23 bits of each node ID number to identify the "origin" of the ID number, fine.

> 3.  The administrative entity that has exclusive authority to assign 
> the ID numbers is in some range X1 through X2 may choose to subdivide 
> that range into sub-ranges, termed "offices".  The nature of this 
> subdivision is the administrative entity's own private affair; an 
> "office" might be some set of nodes that frequently communicate among themselves over highly constrained links (e.g., a research project), but the motivation for forming a given office is none of our business.  Allocation of node IDs within an office is likewise the administrative entity's own private affair; the machinery for doing this may evolve over time, but for now we don't have to care.

That is very much unlike IEEE 802 MAC address assignment. Once an organization burns IEEE 802 MAC addresses into products and releases them to the public, they scatter to the four winds and may never even talk to one another throughout their operational lifetimes. So, the concept of nodes being co-located in an "office"
seems like a rare exception to me and not the ordinary expectation of vendors of DTN products.

>>>	Sure, but I am in no way interested in trying to replicate IEEE 802 MAC address assignment.  BP nodes are logical constructs, not electronic products.  Node IDs are assigned by the administrative entities that use the nodes to support applications, not by vendors.
>>>	This "office" concept says absolutely nothing about the collocation of nodes.  What I suggest is that in some cases some closed set of nodes might be used in (for example) a deep space or undersea research network, in which they must frequently communicate among themselves over highly constrained links.  In such a case, the administrative entity that manages that research network might choose to carve out one "office" of node IDs (from its authorized node ID allocation range) for assignment to those nodes.

> 4.  Just as node IDs have no topological significance, offices have 
> absolutely no topological significance.  They exist solely as a mechanism for abbreviating node IDs.
> 
> 5.  Any single office comprises all nodes in the range Y1 through (Y2 
> - 1) where Y2 exceeds Y1 by exactly 2**(7*Q), where Q (let's call it 
> the "order" of the office) is an integer in the range 1 to 8.  
> 2**(7*Q) is the "size" of the office.  If Q is 1 then there are 2**7 = 
> 128 node IDs available for allocation in this office; if Q is 2 then 
> the size of the office is 2**14 = 16384 node IDs, and so on.  The 
> high-order (63 -
> (7*Q)) bits of the IDs of all nodes in any office are identical; the 
> numeric value of these high-order (63 - (7*Q)) bits uniquely identifies the office.
> 
> 6.  So the 63-bit node ID of a node in an office of order Q may be 
> thought of as having two parts: the high-order (63 - (7*Q)) bits that are the "office ID" followed by the (7*Q) bits that are the "private ID" of the node.

>>>	Exactly.

> Alternatively, though, both of these IDs may be just the private ID 
> portions of the node IDs, and the bundle may or may not contain 
> "office ID" extension blocks that supply the office ID portions: if and only if the source and destination are both in the same office, the office ID extension blocks may be omitted.

The model I have been envisioning is a MANET. The MANET can be standalone, or it can connect to a more stable network like the Internet via one or more MANET/Internet routers (aka "gateways"). Nodes within the MANET may have no idea nor expectation that other nodes from their home office will show up in the same MANET - a far more likely case is that the nodes would have a scattering of node IDs issued by many different origins.

>>>	This model is nothing like a MANET, as far as I can tell.  I don't know of any reason why it needs to be.

> (Of course, if the source node knows that the destination node is in 
> another office then it would be more efficient simply to use the full 
> 63-bit node IDs right from the beginning.)

What if the source and destination are in the same MANET? It would be nice to be able to use a short little local ID for intra-MANET communications even if the two nodes have universal IDs from different origins/offices. That would require a global ID to local ID mapping system within the MANET; most probably something orchestrated by a MANET gateway.

>>>	If the source and destination are actually in the same MANET - that is, real MANET, at the convergence layer under BP - then there very likely needs to be some sort of BP node ID to MANET IP address, just as in any convergence-layer adapter.  But that has nothing to do with BP node ID assignment, right?

> 8.  When forwarding a bundle whose primary header contains a full 
> 63-bit destination node ID, the forwarding node routes the bundle in 
> the normal way; likewise when forwarding a bundle whose destination is 
> represented as a private ID but whose extension blocks include a 
> destination office ID extension block.  (The extension block's office 
> ID, concatenated with the destination private ID, constitutes the full 
> 63-bit destination node ID.)
> 
> 9.  But when forwarding a bundle *lacking* a destination office ID 
> extension block, whose destination is a private ID, the forwarding 
> node computes a route based on the concatenation of its own office ID 
> (that is, the ID of the office that is common to all nodes that have handled this bundle so far) and the destination private ID.  If the first hop on that route is a node that is in a different office, then the forwarding node inserts source and destination office ID extension blocks before sending the bundle onward.

I'm afraid I may still be missing the point as to how this is supposed to work.
It all seems too complicated to me to the point that I don't understand it; naming/addressing should be simple.

>>>	It really is simple.  The explanation is lengthy because I wrote it all down, in detail, but it's very simple.

> -	There is no need to maintain any table that maps between global IDs and local IDs: global ID is always simply office ID followed

I go back to the MANET example. There can be no expectation that nodes that end up in the same randomly-formed MANET are from the same office.

>>>	I do not.  If DTNs were the same as MANETs we would simply use MANETs instead.  DTNs are different from MANETs.
>>>	In one specific case that this mechanism is intended to address, we can absolute expect that all of the nodes in a Mars network will remain in the same "office" forever.  Nothing is randomly formed.  There is no MANET.  There is nothing remotely resembling a MANET.
>>>	Sure, in a terrestrial DTN of opportunistic contacts the topological change may be completely random.  But in that environment we've got bandwidth to burn and there's no need for "office" concept at all; you just use full global node IDs all the time.
>>>	I am truly baffled here, Fred.  The mechanism I have proposed satisfies every single requirement you have stated, while also providing the efficiency that our limited-resource use cases require.  Why have we not converged?

Thanks - Fred

> > > would want or need to be separated from the rest of the network by 
> > > a gateway.  There aren't currently any gateway functions defined 
> > > in DTN architecture at all, nor are there any high-bandwidth 
> > > control messages that research network nodes need to be shielded from.
> > > Node ID translation presents at least one other problem as well: 
> > > we lose the possibility of end-to-end integrity protection of the primary block, because the primary block is no longer immutable.
> >
> > integrity protection.  However, this question is moot if we adopt a 
> > mechanism along the lines I proposed below rather than
> translating node IDs.
> 
> In IPv4, primary block integrity checking is hop-by-hop. It lets the 
> network discard packets that have corrupt headers early on so that 
> they don't consume link resources further down the line. While I recognize that the goal for DTN is end-to-end, the gateway appears as an "proxy end" that is very near to the actual end.
> 
> > > (e.g., small research network; this is an administrative 
> > > mechanism) and is reachable without forwarding through any node in 
> > > any other office, no office ID extension blocks are attached.  The 
> > > source, destination, etc. node ID numbers are all of whatever 
> > > length has been determined to be most efficient for that office: 7 
> > > bits, 14 bits,
> > > 21 bits, whatever.
> >
> > You are assuming that all of the nodes in your small research 
> > network have a common office ID. That may only very rarely be the 
> > case when thinking about applications such as MANETs, etc. That is 
> > why I have been saying that, while DTN nodes certainly have an 
> > origin (i.e., a "home office") we must assume that they are always 
> > away from
> > There is no notion of "home" here, or "origin".  An "office" is 
> > simply a set of nodes whose assigned IDs all have some number of
> Help me out - when you say "whose assigned IDs all have some number of 
> high-order bits in common", do you mean all 64bits (or, 63
> > > office ID is always 64 bits (or, my preference, 63 bits; this 
> > > avoids writing another whole SDNV byte just to double the size of 
> > > the
> > > So traffic that is wholly internal to an office is as 
> > > bit-efficient as possible, but traffic on the global network is 
> > > always routable by the lengthy global IDs.  Global IDs are 
> > > allocated on whatever basis you like; the partitioning of the 
> > > global ID into office ID and office-specific node ID is entirely a 
> > > private office administration matter that nobody else in the network needs to know or care about.
> > routers and it is very straightforward, with no need for any mapping 
> > between long and short node IDs, so the gateway management
> problem goes away.
> > >
> > > What do you think?
> 
> I am still trying to understand "office ID". Is it an N bit office ID 
> number concatenated with an M bit node ID number where N+M = 63/64? Or is it a 63/64 bit number that identifies the office, and the M bit node ID is a separate number?
> 
> scope ID that it can use as source/destination for intra- office communications. If the node wishes to communicate with a correspondent outside of the office, it appends its own 63/64 bit global ID and not an office ID.
> 
> > host part in the DTN node ID much in the same way as for IPv4 and 
> I think the only objection would be that, if the node has to append a 
> 64bit office/node ID and that value needs to traverse low-end links 
> before it emerges from the office then you are still back to the original problem of carrying too many bits on low-end links. Better to have the router append the 64bit office/node ID, but then it begins to look like a gateway.
> 
> > > > space is needed for an Internet-scale network.  All we're 
> > > > talking about here is whether those global IDs are always 64 
> > > > bits long when transmitted or, alternatively, they can have 
> > > > leading zeros that can be
> > > > ranges is undesirable.  I just think that the solution is 
> > > > careful development of range allocation policy rather than 
> > > > requiring useless
> > > > We clearly wouldn't be able to accomplish that careful 
> > > > development of range allocation policy in this email thread, but I don't think that means it's impossible.
> > > >
> > > > -- we say the maximum number of nodes in any such network will 
> > > > be (2^10)-1, i.e., 1023.  We could allocate 2^18 = 262,144 such 
> > > them and still have every node's ID fit into a 5-byte SDNV, still 
> > > a savings of at least 12 bytes in every bundle header -- without any need for any gateways anywhere, ever.
> > > >
> > > > I don't doubt that the gateways would be really, really simple.  
> > > > I just think that every one of them would need to be deployed, 
> > > Networks that care so much about reducing the node ID length 
> > > likely comprise low-end links and/or systems and would use a 
> > > gateway to connect to the rest of the universe anyway. Surely, we 
> > > do not want dynamic routing updates and other high-bandwidth 
> > > control messaging to flow over those links - the control messages 
> > > would instead
> > > > It is clear, that IF we want numeric identifiers and IF we want 
> > > > to make them usable globally (inter-planetary) on Internet-scale 
> > > > we have a flat numeric address scheme, you could say  define 
> > > > 0x0- 0xFFFFFFFFFF are not globally routable, or alternatively, 
> > > > if opting for some prefix/network scheme something like network 
> > > > „0“ could
> > > > however, I think those gateways would be really, really simple. 
> > > > If building NASA's whole network with "private" IDs, all that is 
> > > > needed for being able to connect a rover to its own facebook 
> > > > page is assigning it a public (long) ID with a simple 1-to-1 
> > > > mapping on some
> > > > global address space and just use those :)  I agree however, 
> > > > that policy questions, albeit important,  about how to 
> > > > distribute the address
> > > > > to the bank through a router, but there's no need for a 
> > > > > gateway unless
> > > > underwater acoustic transmissions; instead, it uses a little 
> > > > 16bit local area ID, and relies on a translating gateway to 
> > > > translate the local ID to the universal. I think the other 
> > > > viewpoint (only use universal IDs, and take
> > > > >> Now that I (think) I fully understand the IPN naming scheme, 
> > > > >> I guess I still see it that the transmission efficiency is 
> > > > >> only there for early adopters and the advantage shrinks as 
> > > > >> more and more chunks of
> > > > ID space are allocated.
> > > > >> I think it is clever to use SDNVs to compress the node ID, 
> > > > >> but again the advantage diminishes as countless billions of users claim ID space. I still like Sebastian's zigbee analogy.
> > > > >>
> > > > >> Thanks - Fred
> > > > >>> basically both of you wish/are ok with a numeric namespace. 
> > > > >>> Is anyone here familiar with IEEE 802.15.4 („ZigBee“)? Yes, 
> > > > >>> it is a lower layer, but basically it tackles the same problem:
> > > > >> flags managing addressing in the header so that you can go 
> > > > >> from src&dst PAN
> > > > >>> there is no such thing, but lets just assume they would do 
> > > > >>> it to get globally valid addresses for a super-WSN), is not a problem:
> > > > >>> similar, but maybe it can serve as an inspiration looking at 
> > > > >>> a spec, where such an
> > > > >>>>> objection isn't that the current "ipn" node numbering 
> > > > >>>>> scheme (for example) isn't global or that it isn't 
> > > > >>>>> interoperable - it's that it isn't fair,
> > > > >>> correct?
> > > > >>>>
> > > > >>>> I think that is one way to look at it, yes. Much in the 
> > > > >>>> same way that early IP adopters snapped up Class A 
> > > > >>>> networks, while others who were less lucky got only Class B 
> > > > >>>> and Class C. CIDR finally came through and broke that 
> > > > >>>> logjam, but by then it was too late and a privileged few 
> > > > >>>> land grabbers ended up with the choice cuts of the address space. We have an opportunity to avoid a repeat of history now.
> > > > >>>>
> > > > >>>>> Some user communities get to use brief node IDs because 
> > > > >>>>> they grabbed all the ranges of short numbers, and 
> > > > >>>>> everybody else has to get by with long numbers.  So the fair thing is to require that everybody use long numbers, yes?
> > > > >>>>
> > > > >>>>>> already got defined for the "ipn" scheme (for example) is 
> > > > >>>>>> a 64-bit numeric node name space, of which subsets are 
> > > > >>>>>> allocated to various administrative entities for 
> > > > >>>>>> assignment to the nodes they instantiate;
> > > > >>>>>
> > > > >>>>> underprivileged links will suffer most of all. I guess I 
> > > > >>>>> am also of the opinion that this system should not be 
> > > > >>>>> optimized to suit the specific needs of just
> > > > >>>>>> When the domain of operation is universal-scope, who is 
> > > > >>>>>> to say that we should give a 16-bit universally unique 
> > > > >>>>>> node ID to a sensor node mote but then
> > > > >>>>>> But, it would be much simpler to assign universally 
> > > > >>>>>> unique numeric names if they came from the same 64-bit 
> > > > >>>>>> naming space (and then use a
> > > > >>>>>>>> I'm pretty sure there is no globally embraced DTN 
> > > > >>>>>>>> vision, but my own vision for DTN definitely extends 
> > > > >>>>>>>> (eventually) to a single interconnected global network 
> > > > >>>>>>>> of interoperating entities.  I don't think the 
> > > > >>>>>>>> mechanism I've been talking about is incompatible with
> > > > >>>>>>> that, though.
> > > > >>>>>>>>
> > > > >>>>>>>> I am abundantly aware that there are plenty of people 
> > > > >>>>>>>> in the DTN community who see lots of value in using 
> > > > >>>>>>>> what I would consider lengthy character strings to 
> > > > >>>>>>>> identify nodes and endpoints.  I myself am not a fan, 
> > > > >>>>>>>> but that doesn't mean that everybody else is wrong, nor 
> > > > >>>>>>>> that I'm wrong.  The ION and
> > > > >>>>>>>> other orbiters and landers in the Mars-Phobos system 
> > > > >>>>>>>> that are likewise identified by 3-byte node IDs, and 
> > > > >>>>>>>> sending images to an imaging spectrometer's Principal 
> > > > >>>>>>>> iPad-based BP node identified by a 10-digit node ID.  
> > > > >>>>>>>> The brief data exchanges among the
> > > > >>>>>> a limited-scope DTN. It wouldn't be too far different 
> > > > >>>>>> from the way IPv4 has both global scope and RFC1918 
> > > > >>>>>> privacy
> > > addresses.
> > > > >>>>>>> The privacy addresses need only be unique within the 
> > > > >>>>>>> local network, and may be reused in countless other 
> > > > >>>>>>> standalone local
> > > > >>>>>> networks.
> > > > >>>>>>>>> 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
> > > > >>>>>>>> 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jun 2015 22:57:49 +0000

Hi Scott,

> >>>	This "office" concept says absolutely nothing about the collocation of nodes.  What I suggest is that in some cases some closed
> set of nodes might be used in (for example) a deep space or undersea research network, in which they must frequently communicate
> among themselves over highly constrained links.  In such a case, the administrative entity that manages that research network might
> choose to carve out one "office" of node IDs (from its authorized node ID allocation range) for assignment to those nodes.

IYou are talking about a closed set of nodes. I am thinking about open sets of nodes.
You are also talking about administrative entities that want to rig their node ID
allocations in some proprietary way. That is certainly their option, but not
something that applies universally and therefore not something the belongs
in a standard.

> I am guessing that the reason for (7*Q) is to map better to SDNVs, right?

I didn't necessarily intend that as a compliment. I don't think we should
necessarily be locked into SDNVs as the only way to represent node IDs.

> >>>	Sure, in a terrestrial DTN of opportunistic contacts the topological change may be completely random.  But in that environment
> we've got bandwidth to burn and there's no need for "office" concept at all; you just use full global node IDs all the time.

Bandwidth to burn is not always a reasonable assumption. Some aviation links
are as slow as 32kbps. Many MANETs such as occur in tactical environments
also do not have bandwidth to burn.

> >>>	I am truly baffled here, Fred.  The mechanism I have proposed satisfies every single requirement you have stated, while also
> providing the efficiency that our limited-resource use cases require.  Why have we not converged?

It doesn't ring true to me as something that can be offered as a universal
standard - at least not in the way that I perceive IETF standards. It seems
very organization and use case specific. Not all organizations  nor use cases
are going to want to manage their node ID allocations in the same way.

Thanks - Fred

> Sent: Thursday, June 11, 2015 3:32 PM
> > been allocated a given range of 63-bit node ID numbers has exclusive authority to assign the ID numbers in that range to BP nodes.
> Since all of the node ID numbers are 63 bits long, no range has any particular operational advantage over any other.  If we want the
> leading 23 bits of each node ID number to identify the "origin" of the ID number, fine.
> 
> > "office" might be some set of nodes that frequently communicate among themselves over highly constrained links (e.g., a research
> That is very much unlike IEEE 802 MAC address assignment. Once an organization burns IEEE 802 MAC addresses into products and
> releases them to the public, they scatter to the four winds and may never even talk to one another throughout their operational
> lifetimes. So, the concept of nodes being co-located in an "office"
> >>>	Sure, but I am in no way interested in trying to replicate IEEE 802 MAC address assignment.  BP nodes are logical constructs,
> not electronic products.  Node IDs are assigned by the administrative entities that use the nodes to support applications, not by
> vendors.
> >>>	This "office" concept says absolutely nothing about the collocation of nodes.  What I suggest is that in some cases some closed
> set of nodes might be used in (for example) a deep space or undersea research network, in which they must frequently communicate
> among themselves over highly constrained links.  In such a case, the administrative entity that manages that research network might
> choose to carve out one "office" of node IDs (from its authorized node ID allocation range) for assignment to those nodes.
> 
> > "office ID" extension blocks that supply the office ID portions: if and only if the source and destination are both in the same office,
> the office ID extension blocks may be omitted.
> 
> The model I have been envisioning is a MANET. The MANET can be standalone, or it can connect to a more stable network like the
> Internet via one or more MANET/Internet routers (aka "gateways"). Nodes within the MANET may have no idea nor expectation that
> other nodes from their home office will show up in the same MANET - a far more likely case is that the nodes would have a scattering
> of node IDs issued by many different origins.
> 
> What if the source and destination are in the same MANET? It would be nice to be able to use a short little local ID for intra-MANET
> communications even if the two nodes have universal IDs from different origins/offices. That would require a global ID to local ID
> mapping system within the MANET; most probably something orchestrated by a MANET gateway.
> 
> >>>	If the source and destination are actually in the same MANET - that is, real MANET, at the convergence layer under BP - then
> there very likely needs to be some sort of BP node ID to MANET IP address, just as in any convergence-layer adapter.  But that has
> nothing to do with BP node ID assignment, right?
> 
> > (that is, the ID of the office that is common to all nodes that have handled this bundle so far) and the destination private ID.  If the
> first hop on that route is a node that is in a different office, then the forwarding node inserts source and destination office ID
> extension blocks before sending the bundle onward.
> 
> >>>	In one specific case that this mechanism is intended to address, we can absolute expect that all of the nodes in a Mars
> network will remain in the same "office" forever.  Nothing is randomly formed.  There is no MANET.  There is nothing remotely
> resembling a MANET.
> >>>	Sure, in a terrestrial DTN of opportunistic contacts the topological change may be completely random.  But in that environment
> we've got bandwidth to burn and there's no need for "office" concept at all; you just use full global node IDs all the time.
> >>>	I am truly baffled here, Fred.  The mechanism I have proposed satisfies every single requirement you have stated, while also
> providing the efficiency that our limited-resource use cases require.  Why have we not converged?
> 
> Thanks - Fred
> > scope ID that it can use as source/destination for intra- office communications. If the node wishes to communicate with a
> correspondent outside of the office, it appends its own 63/64 bit global ID and not an office ID.
> >
> > before it emerges from the office then you are still back to the original problem of carrying too many bits on low-end links. Better to
> have the router append the 64bit office/node ID, but then it begins to look like a gateway.
> >

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 11 Jun 2015 23:46:53 +0000

Wait, Fred, didn't you start off arguing for 64-bit fixed length global identifiers?  That is, on June 4 you wrote:

"We will presumably still have the dtn: URI naming scheme carry forward from Section 4.4 of RFC5050, but then it seems that we will also need a numeric scheme. 64 bits seems like a reasonable length, since it provides scaling to large numbers of DTN nodes and fits within a single SDNV.  What I would like to propose is a numeric addressing scheme where the most significant 24 bits encode an 'origin' code and the remaining 40 bits encode a 'node ID'."

When did we pick up the requirement to support bit-efficient MANETs?  Can you tell me which of our accepted use cases state that MANET architectures must be supported?

My proposal traces directly back to the stated Needs for Space Systems Communications and Unmanned Underwater Vehicles, which are (relatively) closed sets of nodes for which administrative entities are definitely going to want to rig their node ID assignments in a way that meets their operational requirements.  Are you saying that a design that addresses the stated needs of these accepted use cases (without in any way compromising other use cases) is not universal and therefore doesn't belong in a standard?  I think we've gotten off-track here.

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, June 11, 2015 3:58 PM
To: Burleigh, Scott C (312B); Sebastian Schildt
Cc: Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Hi Scott,

> >>>	This "office" concept says absolutely nothing about the 
> >>>collocation of nodes.  What I suggest is that in some cases some 
> >>>closed
> set of nodes might be used in (for example) a deep space or undersea 
> research network, in which they must frequently communicate among 
> themselves over highly constrained links.  In such a case, the administrative entity that manages that research network might choose to carve out one "office" of node IDs (from its authorized node ID allocation range) for assignment to those nodes.

IYou are talking about a closed set of nodes. I am thinking about open sets of nodes.
You are also talking about administrative entities that want to rig their node ID allocations in some proprietary way. That is certainly their option, but not something that applies universally and therefore not something the belongs in a standard.

> I am guessing that the reason for (7*Q) is to map better to SDNVs, right?

I didn't necessarily intend that as a compliment. I don't think we should necessarily be locked into SDNVs as the only way to represent node IDs.

> >>>	Sure, in a terrestrial DTN of opportunistic contacts the 
> >>>topological change may be completely random.  But in that 
> >>>environment

Bandwidth to burn is not always a reasonable assumption. Some aviation links are as slow as 32kbps. Many MANETs such as occur in tactical environments also do not have bandwidth to burn.

> >>>	I am truly baffled here, Fred.  The mechanism I have proposed 
> >>>satisfies every single requirement you have stated, while also

It doesn't ring true to me as something that can be offered as a universal standard - at least not in the way that I perceive IETF standards. It seems very organization and use case specific. Not all organizations  nor use cases are going to want to manage their node ID allocations in the same way.

Thanks - Fred

> > 1.  Just for background: we are talking here about the principles 
> > for operating an EID scheme that is based, at least in part, on 
> > numeric node IDs.  (Other EID schemes, whether numeric or 
> > string-based, are certainly worth discussing but are not part of 
> > this discussion.)
> >
> > 2.  Every node that must be identified in the operation of this 
> > scheme has got a 63-bit global node ID.  [Or 64-bit, if everybody 
> > thinks that's important.]  IANA (I guess) allocates ranges of node 
> > IDs to administrative entities such as companies, universities, 
> > space agencies, etc. who request them.  An administrative entity 
> > that has been allocated a given range of 63-bit node ID numbers has exclusive authority to assign the ID numbers in that range to BP nodes.
> Since all of the node ID numbers are 63 bits long, no range has any 
> particular operational advantage over any other.  If we want the leading 23 bits of each node ID number to identify the "origin" of the ID number, fine.
> 
> > the ID numbers is in some range X1 through X2 may choose to 
> > subdivide that range into sub-ranges, termed "offices".  The nature 
> > of this subdivision is the administrative entity's own private 
> > affair; an "office" might be some set of nodes that frequently 
> > communicate among themselves over highly constrained links (e.g., a 
> > research
> project), but the motivation for forming a given office is none of our 
> business.  Allocation of node IDs within an office is likewise the administrative entity's own private affair; the machinery for doing this may evolve over time, but for now we don't have to care.
> 
> That is very much unlike IEEE 802 MAC address assignment. Once an 
> organization burns IEEE 802 MAC addresses into products and releases 
> them to the public, they scatter to the four winds and may never even talk to one another throughout their operational lifetimes. So, the concept of nodes being co-located in an "office"
> >>>	Sure, but I am in no way interested in trying to replicate IEEE 
> >>>802 MAC address assignment.  BP nodes are logical constructs,
> not electronic products.  Node IDs are assigned by the administrative 
> entities that use the nodes to support applications, not by vendors.
> >>>	This "office" concept says absolutely nothing about the 
> >>>collocation of nodes.  What I suggest is that in some cases some 
> >>>closed
> set of nodes might be used in (for example) a deep space or undersea 
> research network, in which they must frequently communicate among 
> themselves over highly constrained links.  In such a case, the administrative entity that manages that research network might choose to carve out one "office" of node IDs (from its authorized node ID allocation range) for assignment to those nodes.
> 
> > thought of as having two parts: the high-order (63 - (7*Q)) bits 
> > that are the "office ID" followed by the (7*Q) bits that are the
> "private ID" of the node.
> 
> > "office ID" extension blocks that supply the office ID portions: if 
> > and only if the source and destination are both in the same office,
> The model I have been envisioning is a MANET. The MANET can be 
> standalone, or it can connect to a more stable network like the 
> Internet via one or more MANET/Internet routers (aka "gateways"). 
> Nodes within the MANET may have no idea nor expectation that other nodes from their home office will show up in the same MANET - a far more likely case is that the nodes would have a scattering of node IDs issued by many different origins.
> 
> > another office then it would be more efficient simply to use the 
> > full 63-bit node IDs right from the beginning.)
> 
> What if the source and destination are in the same MANET? It would be 
> nice to be able to use a short little local ID for intra-MANET 
> communications even if the two nodes have universal IDs from different origins/offices. That would require a global ID to local ID mapping system within the MANET; most probably something orchestrated by a MANET gateway.
> 
> >>>	If the source and destination are actually in the same MANET - 
> >>>that is, real MANET, at the convergence layer under BP - then
> there very likely needs to be some sort of BP node ID to MANET IP 
> address, just as in any convergence-layer adapter.  But that has nothing to do with BP node ID assignment, right?
> 
> > the normal way; likewise when forwarding a bundle whose destination 
> > is represented as a private ID but whose extension blocks include a 
> > destination office ID extension block.  (The extension block's 
> > office ID, concatenated with the destination private ID, constitutes 
> > the full 63-bit destination node ID.)
> >
> > node computes a route based on the concatenation of its own office 
> > ID (that is, the ID of the office that is common to all nodes that 
> > have handled this bundle so far) and the destination private ID.  If 
> > the
> first hop on that route is a node that is in a different office, then 
> I go back to the MANET example. There can be no expectation that nodes 
> that end up in the same randomly-formed MANET are from the same office.
> 
> >>>	In one specific case that this mechanism is intended to address, 
> >>>we can absolute expect that all of the nodes in a Mars
> network will remain in the same "office" forever.  Nothing is randomly 
> formed.  There is no MANET.  There is nothing remotely resembling a MANET.
> >>>	Sure, in a terrestrial DTN of opportunistic contacts the 
> >>>topological change may be completely random.  But in that 
> >>>environment
> >>>	I am truly baffled here, Fred.  The mechanism I have proposed 
> >>>satisfies every single requirement you have stated, while also
> > > > would want or need to be separated from the rest of the network 
> > > > by a gateway.  There aren't currently any gateway functions 
> > > > defined in DTN architecture at all, nor are there any 
> > > > high-bandwidth control messages that research network nodes need to be shielded from.
> > > >>	No, I think it's not OK.  If I am an application sending data 
> > > >>in bundles over the network, I think I want assurance that the
> > > primary block of the bundle as received is bit-for-bit identical 
> > > to what was sent.  End-to-end integrity protection means 
> > > end-to-end integrity protection.  However, this question is moot 
> > > if we adopt a mechanism along the lines I proposed below rather 
> > > than
> > translating node IDs.
> >
> > they don't consume link resources further down the line. While I 
> > recognize that the goal for DTN is end-to-end, the gateway appears
> > > > mechanism) and is reachable without forwarding through any node 
> > > > in any other office, no office ID extension blocks are attached.  
> > > > The source, destination, etc. node ID numbers are all of 
> > > > whatever length has been determined to be most efficient for 
> > > > that office: 7 bits, 14 bits,
> > > > 21 bits, whatever.
> > >
> > of high-order bits in common", do you mean all 64bits (or, 63
> > bits) in the office ID extension block? Then, what if there is no 
> > well-defined office structure and everything is ad-hoc - like in a
> MANET.
> > > > Whenever it is recognized that a bundle's destination requires 
> > > > the bundle to cross an office boundary, office ID extension 
> > > > blocks are added to disambiguate the brief node ID numbers.  The 
> > > > length of an office ID is always 64 bits (or, my preference, 63 
> > > > bits; this avoids writing another whole SDNV byte just to double 
> > > > the size of the
> > > > global ID into office ID and office-specific node ID is entirely 
> > > > a private office administration matter that nobody else in the network needs to know or care about.
> > > routers and it is very straightforward, with no need for any 
> > > mapping between long and short node IDs, so the gateway management
> > problem goes away.
> > > >
> > > > What do you think?
> >
> > I am still trying to understand "office ID". Is it an N bit office 
> > ID number concatenated with an M bit node ID number where N+M = 
> > How about this instead. Each DTN node gets a 63/64 bit global ID, 
> > and DTN routing tracks the node wherever it goes. If the node enters 
> > an office with low-end links, it will receive a short (maybe 16bit) 
> > local scope ID that it can use as source/destination for intra- 
> > office communications. If the node wishes to communicate with a
> > > I think  this is basically the same as encoding a network part and 
> > > a host part in the DTN node ID much in the same way as for IPv4 
> > > and IPv6. I thought we were trying to avoid encoding topology
> > information in DTN node IDs.
> > >
> > > would agree with you that this partitioning would be basically the 
> > > same as encoding a network part and a host part in an IP
> address.
> > I think the only objection would be that, if the node has to append 
> > a 64bit office/node ID and that value needs to traverse low-end 
> > links before it emerges from the office then you are still back to 
> > the original problem of carrying too many bits on low-end links. 
> > Better to
> > > > > Hi, Sebastian.  I definitely agree that a 64-bit global node 
> > > > > ID space is needed for an Internet-scale network.  All we're 
> > > > > I also recognize that creating a "land rush" for short ID 
> > > > > number ranges is undesirable.  I just think that the solution 
> > > > > is careful development of range allocation policy rather than 
> > > > > requiring useless
> > > > > For example: the kinds of networks where I think short node 
> > > > > numbers are likely to be important are going to be the small
> "local"
> > > > > be (2^10)-1, i.e., 1023.  We could allocate 2^18 = 262,144 
> > > > > such research network ranges, every node of which would have a 
> > > > > 28-bit ID that would fit into a 4-byte SDNV.  We could 
> > > > > allocate 33.5 million of
> > > > them and still have every node's ID fit into a 5-byte SDNV, 
> > > > still a savings of at least 12 bytes in every bundle header -- without any need for any gateways anywhere, ever.
> > > > >
> > > > > cyber-attack, etc.  That sounds to me like millions of hours 
> > > > > of tedious
> > > > yet critical work.
> > > >
> > > > gateway to connect to the rest of the universe anyway. Surely, 
> > > > we do not want dynamic routing updates and other high-bandwidth 
> > > > control messaging to flow over those links - the control 
> > > > messages would instead
> > > > > speaking you want short IDs (overhead) in your application. 
> > > > > And using SDNVs can of course help, if you are able to use ID 1 to 127.
> > > > > It is clear, that IF we want numeric identifiers and IF we 
> > > > > want to make them usable globally (inter-planetary) on 
> > > > > Internet-scale networks (and I think we should), we need them 
> > > > > to be "long
> > > enough"
> > > > (think IPv4/v6).
> > > > >
> > > > > I really think private/local address spaces are the solution: 
> > > > > If we have a flat numeric address scheme, you could say  
> > > > > define
> > > > > if opting for some prefix/network scheme something like 
> > > > > network „0“ could
> > > > > If building NASA's whole network with "private" IDs, all that 
> > > > > is needed for being able to connect a rover to its own 
> > > > > facebook page is assigning it a public (long) ID with a simple 
> > > > > 1-to-1 mapping on some
> > > > > And if you still do not like the translation for your setup, 
> > > > > you would still be able to grab those precious first blocks of 
> > > > > the global address space and just use those :)  I agree 
> > > > > however, that policy questions, albeit important,  about how 
> > > > > to distribute the address
> > > > > > Fred, I certainly expect that the submersible would be 
> > > > > > talking to the bank through a router, but there's no need 
> > > > > > for a gateway unless
> > > > > > I think what this comes down to is whether or not the cost 
> > > > > > of developing and deploying the node ID translation 
> > > > > > infrastructure is
> > > > > >> Fred, you're certainly right: if everybody pays full 
> > > > > >> freight, nobody ever obtains any advantage.  Banks running 
> > > > > >> on gigabit Ethernet connected to fiber backbone incur 
> > > > > >> exactly the same transmission overhead as research 
> > > > > >> submersibles on acoustic modems, even if
> > > > > > Right, but we would not expect to see the research 
> > > > > > submersible talking directly to the bank - at least not w/o 
> > > > > > going through some
> > > > > translating gateway that joins the underwater network domain 
> > > > > to the terrestrial world. That means that, while the 
> > > > > submersible certainly has a long universal ID it does not use 
> > > > > it in its underwater acoustic transmissions; instead, it uses 
> > > > > a little 16bit local area ID, and relies on a translating 
> > > > > gateway to translate the local ID to the universal. I think 
> > > > > the other viewpoint (only use universal IDs, and take
> > > > maximum advantage of SDNV compression) is perhaps more of a 
> > > > strict end-to-end viewpoint whereas the IETF has moved on to 
> > > > consider the "Rise of the Middle and the Future of End-to-End" 
> > > > (e.g.,
> > > RFC3724).
> > > > > >
> > > > > >> matter of policy rather than a matter of technology.  We 
> > > > > >> can engineer the protocols to obviate the potential policy 
> > > > > >> failures, or we can engineer the protocols to confer as 
> > > > > >> much technology advantage as
> > > > > >>> I personally prefer the greater flexibility and 
> > > > > >>> transmission efficiency that we can get with SDNVs, and 
> > > > > >>> I'd prefer not to have to deploy
> > > > > >> Now that I (think) I fully understand the IPN naming 
> > > > > >> scheme, I guess I still see it that the transmission 
> > > > > >> efficiency is only there for early adopters and the 
> > > > > >> advantage shrinks as more and more chunks of
> > > > > ID space are allocated.
> > > > > >>> I read this discussion, but I am not quite sure, where 
> > > > > >>> Fred and Scott disagree. So, if I understand it correctly, 
> > > > > >>> Is anyone here familiar with IEEE 802.15.4 („ZigBee“)? 
> > > > > >>> Yes, it is a lower layer, but basically it tackles the same problem:
> > > > > >>> First, addresses are 64 bit (long addresses). This should 
> > > > > >>> be enough for a while. Because IEEE
> > > > > >>> microcontrollers, you do not always want to throw around 
> > > > > >>> 64 bit addresses when sending a 16 bit temperature sample.
> > > > > >> optionally a 2 byte network ID (the PAN ID, conceptually 
> > > > > >> this sounds similar to Fred’s „network of origin“). There 
> > > > > >> are some flags managing addressing in the header so that 
> > > > > >> you can go from src&dst PAN
> > > > > >>> Even if you are late/unlucky  full addresses „suck“, in 
> > > > > >>> your application you can
> > > > > >>> Wouldn’t this make you both happy, @Fred/Scott? I guess 
> > > > > >>> some of the things discussed in this thread are already 
> > > > > >>> quite similar, but maybe it can serve as an inspiration 
> > > > > >>> looking at a spec, where such an
> > > > > >>>> networks, while others who were less lucky got only Class 
> > > > > >>>> B and Class C. CIDR finally came through and broke that 
> > > > > >>>> land grabbers ended up with the choice cuts of the 
> > > > > >>>> address space. We have an opportunity to avoid a repeat 
> > > > > >>>> of history
> now.
> > > > > >>>>
> > > > > >>>>>> already got defined for the "ipn" scheme (for example) 
> > > > > >>>>>> is a 64-bit numeric node name space, of which subsets 
> > > > > >>>>>> are allocated to various administrative entities for 
> > > > > >>>>>> over-the-wire representation we are able to economize 
> > > > > >>>>>> on transmission by omitting a lot of
> > > > > >>>>> It means that only early adopters would have 
> > > > > >>>>> compressible strings of 0's in the leading bits of the 64-bit field. Latecomers will not be able to take advantage of the optimization.
> > > > > >>>>>>>> (eventually) to a single interconnected global 
> > > > > >>>>>>>> network of interoperating entities.  I don't think 
> > > > > >>>>>>>> the mechanism I've been talking about is incompatible 
> > > > > >>>>>>>> with
> > > > > >>>>>>> that, though.
> > > > > >>>>>>>>
> > > > > >>>>>>>> but that doesn't mean that everybody else is wrong, 
> > > > > >>>>>>>> imagine a spacecraft orbiting Phobos that is 
> > > > > >>>>>>>> identified by a 3-byte SDNV numeric node ID, 
> > > > > >>>>>>>> communicating with other orbiters and landers in the 
> > > > > >>>>>>>> Mars-Phobos system that are likewise identified by 
> > > > > >>>>>>>> spectrometer's Principal Investigator in Chicago who 
> > > > > >>>>>>>> receives science data at an iPad-based BP node identified by a 10-digit node ID.
> > > > > >>>>>>> communication channels, while the larger overhead on 
> > > > > >>>>>>> the science data return bundles is amortized over the 
> > > > > >>>>>>> larger size of the images.  I don't think this is
> > > > > >>>>>> difficult.
> > > > > >>>>>>>
> > > > > >>>>>>> Later, when multiple local networks are bridged 
> > > > > >>>>>>> together to form a larger DTN, they would have to 
> > > > > >>>>>>> deprecate their local addresses/names and begin using their universal addresses/names.
> > > > > >>>>>>> What do
> > > > > >>>>>> you think?
> > > > > >>>>>>>
> > > > > >>>>>>> Thanks - Fred
> > > > > >>>>>>>> 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
> > > > > >>>> dtn-interest mailing list [email-masked]

---

From: Carlo Caini <[email-masked]>
Date: Fri, 12 Jun 2015 12:06:15 +0200

Dear Scott,
        Just a small comment. Your scheme looks 
like the "classfull" IP adressing, although I 
have perfectly understood that EID are not 
addresses (your point 4). The analogy is related 
to the fact that your EIDs consists of two parts 
(Office ID, Private ID),  as IPs do (prefix and 
suffix). The question is why we need to pose a 
constraint on the Office ID lenght, as in 
classfull IP adressing? Why not to follow instead 
a sort of "classless" IP addressing scheme, by 
letting the Office ID lenght be free (i.e. any 
number of bits is OK). This would avoid the 
problem of Nbit-exponential ranges, which led to 
a very poor distribution of IP addresses and 
eventually to the adoption of the classless 
system fo IPs, as you certainly know. Here, as we 
have 7-ples instead of bytes, we have the 
smallest office range of 128, followed by 16384, 
and then by an enormous 2 097 152. These sizes 
are too different to be convenient. Letting the 
lenght of the office free, ranges will just 
double for each additional bit in the Office ID.
Of course you need to know the lenght of the 
office ID (the equivalent of /bitsofprefix or of 
the mask in IP), but I suppose it is worth the effort.
Yours,
    Carlo

At 22:20 11/06/2015, Burleigh, Scott C (312B) wrote:
>1.  Just for background: we are talking here 
>about the principles for operating an EID scheme 
>that is based, at least in part, on numeric node 
>IDs.  (Other EID schemes, whether numeric or 
>string-based, are certainly worth discussing but 
>are not part of this discussion.)
>
>2.  Every node that must be identified in the 
>operation of this scheme has got a 63-bit global 
>node ID.  [Or 64-bit, if everybody thinks that's 
>important.]  IANA (I guess) allocates ranges of 
>node IDs to administrative entities such as 
>companies, universities, space agencies, etc. 
>who request them.  An administrative entity that 
>has been allocated a given range of 63-bit node 
>ID numbers has exclusive authority to assign the 
>ID numbers in that range to BP nodes.  Since all 
>of the node ID numbers are 63 bits long, no 
>range has any particular operational advantage 
>over any other.  If we want the leading 23 bits 
>of each node ID number to identify the "origin" of the ID number, fine.
>
>3.  The administrative entity that has exclusive 
>authority to assign the ID numbers is in some 
>range X1 through X2 may choose to subdivide that 
>range into sub-ranges, termed "offices".  The 
>nature of this subdivision is the administrative 
>entity's own private affair; an "office" might 
>be some set of nodes that frequently communicate 
>among themselves over highly constrained links 
>(e.g., a research project), but the motivation 
>for forming a given office is none of our 
>business.  Allocation of node IDs within an 
>office is likewise the administrative entity's 
>own private affair; the machinery for doing this 
>may evolve over time, but for now we don't have to care.
>
>4.  Just as node IDs have no topological 
>significance, offices have absolutely no 
>topological significance.  They exist solely as 
>a mechanism for abbreviating node IDs.
>
>5.  Any single office comprises all nodes in the 
>range Y1 through (Y2 - 1) where Y2 exceeds Y1 by 
>exactly 2**(7*Q), where Q (let's call it the 
>"order" of the office) is an integer in the 
>range 1 to 8.  2**(7*Q) is the "size" of the 
>office.  If Q is 1 then there are 2**7 = 128 
>node IDs available for allocation in this 
>office; if Q is 2 then the size of the office is 
>2**14 = 16384 node IDs, and so on.  The 
>high-order (63 - (7*Q)) bits of the IDs of all 
>nodes in any office are identical; the numeric 
>value of these high-order (63 - (7*Q)) bits uniquely identifies the office.
>
>6.  So the 63-bit node ID of a node in an office 
>of order Q may be thought of as having two 
>parts: the high-order (63 - (7*Q)) bits that are 
>the "office ID" followed by the (7*Q) bits that 
>are the "private ID" of the node.
>
>7.  When a node issues a bundle, the source and 
>destination node IDs noted in the primary header 
>may both be full 63-bit node 
>IDs.  Alternatively, though, both of these IDs 
>may be just the private ID portions of the node 
>IDs, and the bundle may or may not contain 
>"office ID" extension blocks that supply the 
>office ID portions: if and only if the source 
>and destination are both in the same office, the 
>office ID extension blocks may be omitted.  (Of 
>course, if the source node knows that the 
>destination node is in another office then it 
>would be more efficient simply to use the full 
>8.  When forwarding a bundle whose primary 
>header contains a full 63-bit destination node 
>ID, the forwarding node routes the bundle in the 
>normal way; likewise when forwarding a bundle 
>whose destination is represented as a private ID 
>but whose extension blocks include a destination 
>office ID extension block.  (The extension 
>block's office ID, concatenated with the 
>destination private ID, constitutes the full 63-bit destination node ID.)
>
>9.  But when forwarding a bundle *lacking* a 
>destination office ID extension block, whose 
>destination is a private ID, the forwarding node 
>computes a route based on the concatenation of 
>its own office ID (that is, the ID of the office 
>that is common to all nodes that have handled 
>this bundle so far) and the destination private 
>ID.  If the first hop on that route is a node 
>that is in a different office, then the 
>forwarding node inserts source and destination 
>office ID extension blocks before sending the bundle onward.
>
>So:
>-       Traffic that is wholly internal to an 
>office is bit-efficient, because private IDs are 
>used and office ID extension blocks are always omitted.
>-       Traffic on the global network is always 
>routable, because either full node IDs are used 
>or else office ID extension blocks are included: 
>full node IDs can always be used for route computation.
>-       There is no need to maintain any table 
>that maps between global IDs and local IDs: 
>global ID is always simply office ID followed by private ID.
>
>If you want to call the conditional insertion of 
>extension blocks by a router a "gateway 
>function", fine, it's a gateway function.
>
>Scott
>
> > precludes these developments, but currently 
> nothing requires them - except the node ID 
> translation function you're proposing.
> > >
> > > lose the possibility of end-to-end 
> integrity protection of the primary block, 
> because the primary block is no longer immutable.
> >
> > gateway, and then a second integrity 
> protection extends from the gateway to the destination.
> >
> > integrity protection.  However, this question 
> is moot if we adopt a mechanism along the lines 
> I proposed below rather than translating node IDs.
>
>In IPv4, primary block integrity checking is 
>hop-by-hop. It lets the network discard packets 
>that have corrupt headers early on so that they 
>don't consume link resources further down the 
>line. While I recognize that the goal for DTN is 
>end-to-end, the gateway appears as an "proxy 
>end" that is very near to the actual end.
>
> > been saying that, while DTN nodes certainly 
> have an origin (i.e., a "home office") we must 
> assume that they are always away from home and 
> potentially commingling with nodes from other offices.
> >
> > There is no notion of "home" here, or 
> "origin".  An "office" is simply a set of nodes 
> whose assigned IDs all have some number of 
>Help me out - when you say "whose assigned IDs 
>all have some number of high-order bits in 
>common", do you mean all 64bits (or, 63 bits) in 
>the office ID extension block? Then, what if 
>there is no well-defined office structure and 
>everything is ad-hoc - like in a MANET. Are you 
>saying that an office ID identifies a border 
>router that connects the "office" to the rest of the DTN?
>
> > routers and it is very straightforward, with 
> no need for any mapping between long and short 
> node IDs, so the gateway management problem goes away.
> > >
> > > What do you think?
>
>I am still trying to understand "office ID". Is 
>it an N bit office ID number concatenated with 
>an M bit node ID number where N+M = 63/64? Or is 
>it a 63/64 bit number that identifies the 
>office, and the M bit node ID is a separate number?
>
>How about this instead. Each DTN node gets a 
>63/64 bit global ID, and DTN routing tracks the 
>node wherever it goes. If the node enters an 
>office with low-end links, it will receive a 
>short (maybe 16bit) local scope ID that it can 
>use as source/destination for intra-office 
>communications. If the node wishes to 
>communicate with a correspondent outside of the 
>office, it appends its own 63/64 bit global ID and not an office ID.
>
> > host part in the DTN node ID much in the same 
> way as for IPv4 and IPv6. I thought we were 
> trying to avoid encoding topology information in DTN node IDs.
> >
> > would agree with you that this partitioning 
> would be basically the same as encoding a 
> network part and a host part in an IP address.
> > But they are not, so I don't.  Given which, 
> what is your objection to this mechanism?
>
>I think the only objection would be that, if the 
>node has to append a 64bit office/node ID and 
>that value needs to traverse low-end links 
>before it emerges from the office then you are 
>still back to the original problem of carrying 
>too many bits on low-end links. Better to have 
>the router append the 64bit office/node ID, but 
>then it begins to look like a gateway.
>
> > > > of range allocation policy in this email 
> thread, but I don't think that means it's impossible.
> > > >
> > > > For example: the kinds of networks where 
> I think short node numbers are likely to be 
> important are going to be the small "local"
> > > savings of at least 12 bytes in every 
> bundle header -- without any need for any gateways anywhere, ever.
> > > >
> > be terminated by the gateway. So, why 
> wouldn't the gateway also provide node ID translation services?
> > >
> > > Thanks - Fred
> > > > However, I agree it with Fred, that it is 
> not a good idea, if your only chance to be efficient, is being a first mover.
> > > >
> > > > opting for some prefix/network scheme something like network „0â€œ
> > > > could
> > > > Your argument for keeping all addresses 
> global is "there's no need for a gateway"
> > > > > On 11 Jun 2015, at 00:11, Burleigh, 
> Scott C (312B) <[email-masked]> wrote:
> > > > >
> > > > justified by the ID allocation fairness 
> that is structurally imposed by a fixed-length 
> node ID standard.  I don't think it is.
> > > > >
> > > > > Scott
> > > > >
> > > > possible and address the potential policy 
> failures in a policy planning discussion.  I 
> think the latter is a stronger strategy.
> > > > >
> > > > >> again the advantage diminishes as 
> countless billions of users claim ID space. I 
> still like Sebastian's zigbee analogy.
> > > > >>
> > > > >> Thanks - Fred
> > > > >>> anyone here familiar with IEEE 802.15.4 („ZigBeeâ€œ)? Yes, it is
> > > > >>> a lower layer, buut basically it tackles the same problem:
> > > > >> sounds similar to Fredâ€™s „network of originâ€œ). There are somme
> > > > Identifier and long addresses (2*(2+8) 
> bytes) down to no PAN ID and destination short 
> address, no src address  (2 byte).
> > > > >>>
> > > > >>> Even if you are late/unlucky  full addresses „suckâ€œ, in your
> > > > >>> application you can
> > > > >> always work with arbitrary 16 bit 
> short addresses. Gateways mapping this to 
> globally valid addresses are very easy.
> > > > >>>
> > > > >>> Wouldnâ€™t this make you both happy, @Fred/Scott? I guess some
> > > > >>>> On 10 Jun 2015, at 19:33, Templin, 
> Fred L <[email-masked]> wrote:
> > > > >>>>
> > > > >>>> Hi Scott,
> > > > >>>>
> > > > >>>> the choice cuts of the address 
> space. We have an opportunity to avoid a repeat of history now.
> > > > >>>>
> > > > >>>>> has to get by with long 
> numbers.  So the fair thing is to require that everybody use long numbers, yes?
> > > > >>>>
> > > > >>>>> code as the leading 24bits of the 
> numeric node ID. CCSDS would have one such origin code.
> > > > >>>>>
> > > > >>>>> leading zeroes, because we 
> represent them as SDNVs.  How does this not 
> achieve the objectives you're aiming for?
> > > > >>>>>
> > > > >>>>> strings of 0's in the leading bits 
> of the 64-bit field. Latecomers will not be 
> > > > >>>>>> existence proof in IPv4 privacy 
> addressing and to a certain extent also IPv6 unique local addressing.
> > > > >>>>>>
> > > > >>>>>>> without declaring any topological 
> information at all, and relying on late binding for "addressing"?
> > > > >>>>>>
>dtn mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dtn

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Jun 2015 15:42:47 +0000

Hi Scott,

> Sent: Thursday, June 11, 2015 4:47 PM
> "We will presumably still have the dtn: URI naming scheme carry forward from Section 4.4 of RFC5050, but then it seems that we will
> also need a numeric scheme. 64 bits seems like a reasonable length, since it provides scaling to large numbers of DTN nodes and fits
> within a single SDNV.  What I would like to propose is a numeric addressing scheme where the most significant 24 bits encode an
> 'origin' code and the remaining 40 bits encode a 'node ID'."
> 

Teams of autonomous UAVs is one example where MANET is applicable.
Disaster relief networks is another.

> My proposal traces directly back to the stated Needs for Space Systems Communications and Unmanned Underwater Vehicles, which
> are (relatively) closed sets of nodes for which administrative entities are definitely going to want to rig their node ID assignments in a
> way that meets their operational requirements.  Are you saying that a design that addresses the stated needs of these accepted use
> cases (without in any way compromising other use cases) is not universal and therefore doesn't belong in a standard?  I think we've
> gotten off-track here.

I think "office" is a term that has been throwing me off in these discussions.
A more IETF-ish word is "site". I think what I hear you saying is that you have
use cases where all DTN nodes within a site have a common leading N bits in
their universal endpoint ID, therefore the leading N bits can be omitted for
intra-site communications. For off-site communications, then, the router that
connects the site to the rest of the DTN can prepend the leading N bits to any
bundles that originate from a node within the site and are destined to a node
outside the site. Since all nodes within the site share a common leading N bits,
the router can perhaps be thought of as a "stateless gateway".

In my understanding, however, there may be many sites that include DTN
nodes with diverse values in the leading N bits of their universal node IDs;
i.e., a heterogeneous rather than homogeneous collection of DTN nodes.
In that case, the router that connects the site to the rest of the universe
would need to maintain a mapping of universal node IDs to local node IDs
so that the address translation can satisfy off-site communication
requirements - a "stateful gateway".

So, maybe we are both half-right - maybe it doesn't need to be all one
way or the other. What do you think?

Fred

> > themselves over highly constrained links.  In such a case, the administrative entity that manages that research network might
> You are also talking about administrative entities that want to rig their node ID allocations in some proprietary way. That is certainly
> their option, but not something that applies universally and therefore not something the belongs in a standard.
> 
> Bandwidth to burn is not always a reasonable assumption. Some aviation links are as slow as 32kbps. Many MANETs such as occur in
> tactical environments also do not have bandwidth to burn.
> 
> It doesn't ring true to me as something that can be offered as a universal standard - at least not in the way that I perceive IETF
> standards. It seems very organization and use case specific. Not all organizations  nor use cases are going to want to manage their
> node ID allocations in the same way.
> 
> Thanks - Fred
> > business.  Allocation of node IDs within an office is likewise the administrative entity's own private affair; the machinery for doing
> this may evolve over time, but for now we don't have to care.
> >
> > them to the public, they scatter to the four winds and may never even talk to one another throughout their operational lifetimes.
> So, the concept of nodes being co-located in an "office"
> > themselves over highly constrained links.  In such a case, the administrative entity that manages that research network might
> > Nodes within the MANET may have no idea nor expectation that other nodes from their home office will show up in the same
> MANET - a far more likely case is that the nodes would have a scattering of node IDs issued by many different origins.
> >

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Jun 2015 15:51:22 +0000

HI Rick,

Your message does seem to bring the discussion back around again
to routing, which does make sense. Routing and naming/addressing
are inherently linked, so it is inevitable the two discussions would
be intertwined. I have just one small comment below:

> From: Rick Taylor [mailto:[email-masked]]
> Sent: Friday, June 12, 2015 3:42 AM
> To: Burleigh, Scott C (312B); Templin, Fred L; Sebastian Schildt
> Cc: Greg Troxel; [email-masked]; [email-masked]
> Hi All,
> I think we have got a bit lost in the weeds here.  If I understand this
> thread so far, there is general consensus that keeping unique Node Ids
> as short as possible is a good thing, and there is general consensus
> that inter-connecting DTN node groups in some way is also a good thing,
> but we have wandered into bit-lengths and concatenation rules and who
> hands out the high bits and how.
> 
> I must admit that when thinking about DTN's I usually start with a
> postal system analogy, it's not always a good fit, but it helps, and in
> this case I think the problem we are discussing has already been solved
> many years ago by postal services: Multi-part addresses.
> 
> An example might help; If I wished to send a postcard to Scott, and I
> don't actually know a convergence layer shortcut to him (e.g. his
> zipcode), I would address the postcard as such:
> 
> { Scott Burleigh, JPL, NASA, USA }
> 
> and I would add a sender address of:
> 
> { Rick Taylor, Airbus D&S, Newport, Wales, UK }.
> 
> Now the chances are that this information is probably enough for the
> postcard to get delivered, and for Scott to send me a reply. (Could be
> an interesting experiment)
> 
> Equally, if I wanted to send a postcard to my colleague John, I would
> address the postcard to: { John Dowdell } from { Rick Taylor }.
> 
> I would give both postcards to my local mailroom, and they would do a
> lookup for the receiver, and if it is not a local ID, they would pass it
> on via some routing rule to some mailroom elsewhere that can get it to
> the recipient, possibly via multiple repetitions of lookup.
> 
> Putting this in DTN terms: If a primary block contains an ordered list
> of EIDs (numeric or string), the list-head being the recipient, and the
> other entries being administrative zones, scoped within the next
> enclosing zone, then I think we might have solved both issues in the
> current discussion:
> 
> 1) Nodes can talk to local nodes using short, locally assigned EIDs.
> 
> 2) Nodes can talk globally using (longer) lists of EIDs (that's the
> price for talking globally, and there needs to be routers)

Isn't this a lot like IP source routing? Where the header can contain a
list of names/addresses that need to be visited (in order) on the path
from the original source to the final destination? Not saying it is not a
good idea, but is source routing where we want to go with DTN?

Thanks - Fred

> 3) Only top-level, dare I say, 'Domains' need assignment from IANA, or
> whoever is deemed appropriate.
> 
> 4) End-to-end bundle integrity is maintained as there is no need to
> rewrite addresses if bundles cross administrative zones (No NAT required).
> 
> Yes, this looks just like DNS, but more importantly, it looks like
> postal addresses, and that is a system that has provably worked at
> global scale, without top-down administration, across disconnected
> networks, since about 1650.
> 
> I'll attach a disclaimer that this might be a very naive suggestion, or
> might have been covered at length in the DTN-RG, but I am still getting
> up to speed with this topic.
> 
> Cheers,
> 
> Rick Taylor
> { Airbus D&S, Newport, Wales, UK } ;-)
> 
> 
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 12 Jun 2015 16:14:48 +0000

Hi, Carlo.  Sure, I would be fine with letting the office ID and private ID be any number of bits that the configuring administrative entity finds convenient.  The concept would still work the same way.

My preference is for the sizes to be in multiples of 7 bits for efficiency and convenience, so that (for example) the representation of office ID in an extension block never has any wasted high-order bits and the value itself indicates the number of bits that are significant (i.e., they all are; otherwise you have to carry office ID bit length somewhere else, an additional complication).  I suspect that "office" sizes 128 and 16284 would meet the needs of just about all users of this feature.  But maybe not.

Scott

-----Original Message-----
From: Carlo Caini [mailto:[email-masked]] 
Sent: Friday, June 12, 2015 3:06 AM
To: Burleigh, Scott C (312B); Templin, Fred L; Sebastian Schildt
Cc: [email-masked]; [email-masked]; Rick Taylor; Greg Troxel
Subject: Re: [dtn] [dtn-interest] DTN static routing

Dear Scott,
        Just a small comment. Your scheme looks like the "classfull" IP adressing, although I have perfectly understood that EID are not addresses (your point 4). The analogy is related to the fact that your EIDs consists of two parts (Office ID, Private ID),  as IPs do (prefix and suffix). The question is why we need to pose a constraint on the Office ID lenght, as in classfull IP adressing? Why not to follow instead a sort of "classless" IP addressing scheme, by letting the Office ID lenght be free (i.e. any number of bits is OK). This would avoid the problem of Nbit-exponential ranges, which led to a very poor distribution of IP addresses and eventually to the adoption of the classless system fo IPs, as you certainly know. Here, as we have 7-ples instead of bytes, we have the smallest office range of 128, followed by 16384, and then by an enormous 2 097 152. These sizes are too different to be convenient. Letting the lenght of the office free, ranges will just double for each additional bit in the Office ID.
Of course you need to know the lenght of the office ID (the equivalent of /bitsofprefix or of the mask in IP), but I suppose it is worth the effort.
Yours,
    Carlo

At 22:20 11/06/2015, Burleigh, Scott C (312B) wrote:
>agencies, etc.
>who request them.  An administrative entity that has been allocated a 
>given range of 63-bit node ID numbers has exclusive authority to assign 
>the ID numbers in that range to BP nodes.  Since all of the node ID 
>numbers are 63 bits long, no range has any particular operational 
>advantage over any other.  If we want the leading 23 bits of each node 
>ID number to identify the "origin" of the ID number, fine.
>
>"office" might be some set of nodes that frequently communicate among 
>themselves over highly constrained links (e.g., a research project), 
>but the motivation for forming a given office is none of our business.  
>Allocation of node IDs within an office is likewise the administrative 
>entity's own private affair; the machinery for doing this may evolve 
>over time, but for now we don't have to care.
>
>5.  Any single office comprises all nodes in the range Y1 through (Y2 - 
>1) where Y2 exceeds Y1 by exactly 2**(7*Q), where Q (let's call it the 
>"order" of the office) is an integer in the range 1 to 8.  2**(7*Q) is 
>the "size" of the office.  If Q is 1 then there are 2**7 = 128 node IDs 
>available for allocation in this office; if Q is 2 then the size of the 
>office is
>2**14 = 16384 node IDs, and so on.  The high-order (63 - (7*Q)) bits of 
>the IDs of all nodes in any office are identical; the numeric value of 
>these high-order (63 - (7*Q)) bits uniquely identifies the office.
>
>thought of as having two
>parts: the high-order (63 - (7*Q)) bits that are the "office ID" 
>followed by the (7*Q) bits that are the "private ID" of the node.
>
>7.  When a node issues a bundle, the source and destination node IDs 
>noted in the primary header may both be full 63-bit node IDs.  
>portions of the node IDs, and the bundle may or may not contain "office 
>ID" extension blocks that supply the office ID portions: if and only if 
>the source and destination are both in the same office, the office ID 
>extension blocks may be omitted.  (Of course, if the source node knows 
>that the destination node is in another office then it would be more 
>efficient simply to use the full 63-bit node IDs right from the 
>beginning.)
>
>extension block, whose destination is a private ID, the forwarding node 
>computes a route based on the concatenation of its own office ID (that 
>is, the ID of the office that is common to all nodes that have handled 
>this bundle so far) and the destination private ID.  If the first hop 
>on that route is a node that is in a different office, then the 
>forwarding node inserts source and destination office ID extension 
>blocks before sending the bundle onward.
>
>So:
>office is bit-efficient, because private IDs are used and office ID 
>extension blocks are always omitted.
>routable, because either full node IDs are used or else office ID 
>extension blocks are included:
>If you want to call the conditional insertion of extension blocks by a 
>router a "gateway function", fine, it's a gateway function.
>
>Scott
>
> nothing requires them - except the node ID translation function you're 
> proposing.
> > >
> > > we lose the possibility of end-to-end
> integrity protection of the primary block, because the primary block 
> is no longer immutable.
> >
> is moot if we adopt a mechanism along the lines I proposed below 
> rather than translating node IDs.
>
>network discard packets that have corrupt headers early on so that they 
>don't consume link resources further down the line. While I recognize 
>that the goal for DTN is end-to-end, the gateway appears as an "proxy 
> > why I have been saying that, while DTN nodes certainly
> have an origin (i.e., a "home office") we must assume that they are 
> always away from home and potentially commingling with nodes from 
> other offices.
> >
> "origin".  An "office" is simply a set of nodes whose assigned IDs all 
> have some number of high-order bits in common.  This is just a 
> mechanism for abbreviating node IDs.
>
>high-order bits in common", do you mean all 64bits (or, 63 bits) in the 
>office ID extension block? Then, what if there is no well-defined 
>office structure and everything is ad-hoc - like in a MANET. Are you 
>saying that an office ID identifies a border router that connects the 
>"office" to the rest of the DTN?
>
> no need for any mapping between long and short node IDs, so the 
> gateway management problem goes away.
> > >
> > > What do you think?
>
>number concatenated with an M bit node ID number where N+M = 63/64? Or 
>is it a 63/64 bit number that identifies the office, and the M bit node 
>ID is a separate number?
>
>63/64 bit global ID, and DTN routing tracks the node wherever it goes. 
>If the node enters an office with low-end links, it will receive a 
>short (maybe 16bit) local scope ID that it can use as 
>source/destination for intra-office communications. If the node wishes 
>to communicate with a correspondent outside of the office, it appends 
>its own 63/64 bit global ID and not an office ID.
>
> way as for IPv4 and IPv6. I thought we were trying to avoid encoding 
> topology information in DTN node IDs.
> >
> would be basically the same as encoding a network part and a host part 
> in an IP address.
>before it emerges from the office then you are still back to the 
>original problem of carrying too many bits on low-end links. Better to 
> > > > development of range allocation policy in this email
> I think short node numbers are likely to be important are going to be 
> the small "local"
> > > a savings of at least 12 bytes in every
> > > > „0â€œ could
> that is structurally imposed by a fixed-length node ID standard.  I 
> don't think it is.
> > > > >
> > > > > Scott
> > > > >
> failures in a policy planning discussion.  I think the latter is a 
> stronger strategy.
> > > > >
> > > > >> but again the advantage diminishes as
> countless billions of users claim ID space. I still like Sebastian's 
> zigbee analogy.
> > > > >>
> > > > >> Thanks - Fred
> > > > >>> Is anyone here familiar with IEEE 802.15.4 („ZigBeeâ€œ)? 
> > > > >>> Yes, it is a lower layer, buut basically it tackles the same problem:
> > > > >> sounds similar to Fredâ€™s „network of originâ€œ). There are 
> > > > >> somme flags managing addressing in the header so that you can 
> > > > >> go from src&dst PAN
> bytes) down to no PAN ID and destination short address, no src address  
> (2 byte).
> > > > >>>
> > > > >>> Even if you are late/unlucky  full addresses „suckâ€œ, in 
> > > > >>> your application you can
> short addresses. Gateways mapping this to globally valid addresses are 
> very easy.
> > > > >>>
> > > > >>> Wouldnâ€™t this make you both happy, @Fred/Scott? I guess 
> > > > >>>> land grabbers ended up with the choice cuts of the address
> > > > >>>>> everybody else has to get by with long
> represent them as SDNVs.  How does this not achieve the objectives 
> you're aiming for?
> > > > >>>>>
> of the 64-bit field. Latecomers will not be able to take advantage of 
> the optimization.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 12 Jun 2015 16:37:07 +0000

Hi, Rick.  I definitely agree that the postal model is almost always a good perspective for thinking about DTN issues.  In this case, though, I think the analogy is just slightly off the mark.

That's because we are not talking about addresses, here; we're talking about names.  Nested zones of routing and forwarding are very likely going to be important in DTN, but they don't address the naming problem we're dealing with.

I think a closer analogy would be internal memos in a corporation.  Suppose you and I work in the same department of Megamind, Ltd., and in Megamind we communicate using old-fashioned paper memos that are copied and delivered by hand, by underpaid administrative assistants.  If I write a policy memo that is only for circulation within our department, I can sign it "SB" and send it to DF, LG, and RT, and you will get a copy (assuming there's nobody else in the department with initials "RT").  But if I need to send a copy of that memo to the head of the corporate legal department, I can't do that: there are 16 people with initials SB in Megamind.  That copy has to be sent to "Donna Fargo" and signed "Scott Burleigh" so she'll know who it came from, and I probably need to spell out the names of everybody else in the CC list as well: Donald Faraday, Louise Gish, Rick Taylor.

Now, I agree, the next step is figuring out how to convey those copies of the memo to those individuals, and for that purpose an ordered list of nested mail distribution administrative zones might be very helpful.  But I don't think we're there yet.

Scott 

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: Friday, June 12, 2015 3:42 AM
To: Burleigh, Scott C (312B); Templin, Fred L; Sebastian Schildt
Cc: Greg Troxel; [email-masked]; [email-masked]
Subject: Re: [dtn-interest] [dtn] DTN static routing

Hi All,

I think we have got a bit lost in the weeds here.  If I understand this thread so far, there is general consensus that keeping unique Node Ids as short as possible is a good thing, and there is general consensus that inter-connecting DTN node groups in some way is also a good thing, but we have wandered into bit-lengths and concatenation rules and who hands out the high bits and how.

I must admit that when thinking about DTN's I usually start with a postal system analogy, it's not always a good fit, but it helps, and in this case I think the problem we are discussing has already been solved many years ago by postal services: Multi-part addresses.

An example might help; If I wished to send a postcard to Scott, and I don't actually know a convergence layer shortcut to him (e.g. his zipcode), I would address the postcard as such:

Now the chances are that this information is probably enough for the postcard to get delivered, and for Scott to send me a reply. (Could be an interesting experiment)

Equally, if I wanted to send a postcard to my colleague John, I would address the postcard to: { John Dowdell } from { Rick Taylor }.

I would give both postcards to my local mailroom, and they would do a lookup for the receiver, and if it is not a local ID, they would pass it on via some routing rule to some mailroom elsewhere that can get it to the recipient, possibly via multiple repetitions of lookup.

Putting this in DTN terms: If a primary block contains an ordered list of EIDs (numeric or string), the list-head being the recipient, and the other entries being administrative zones, scoped within the next enclosing zone, then I think we might have solved both issues in the current discussion:

2) Nodes can talk globally using (longer) lists of EIDs (that's the price for talking globally, and there needs to be routers)

3) Only top-level, dare I say, 'Domains' need assignment from IANA, or whoever is deemed appropriate.

4) End-to-end bundle integrity is maintained as there is no need to rewrite addresses if bundles cross administrative zones (No NAT required).

Yes, this looks just like DNS, but more importantly, it looks like postal addresses, and that is a system that has provably worked at global scale, without top-down administration, across disconnected networks, since about 1650.

I'll attach a disclaimer that this might be a very naive suggestion, or might have been covered at length in the DTN-RG, but I am still getting up to speed with this topic.

Cheers,

Rick Taylor

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 12 Jun 2015 17:03:28 +0000

Hi, Fred.  I picked the term "office" because I wanted to emphasize the fact that it was strictly administrative, with absolutely no topological significance, and that's what troubles me about using "site" instead.  "Site" certainly connotes location and topology, and I think a large part of our problem here is that topology and routing keep getting dragged into this conversation, in which they have no part.

Let me re-emphasize: in DTN, routing is based on late binding.  The mapping of a destination node identifier to some point in network topology is NOT reflected in the node identifier.  Not in any way.  Looking at the destination endpoint ID cannot ever be relied upon to tell you anything about the location of the destination in the network.  The word "routing" should never come up in a discussion of node naming.  There is no relationship between the two.

But sure, let's pick a better term than "office".  Maybe "unit"?  Or "corps", or "department"?  "Family?"  It doesn't need to be IETF-ish, it needs to be accurate, and in particular it needs to have absolutely no connotation of geography or topology or location.

"Family" is actually a fairly okay model.  Members of the same family can be scattered all across the world, but no matter where they are they can refer to one another by their first names when they write letters, so long as the letters are only exchanged among the family members.

Scott  

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Friday, June 12, 2015 8:43 AM
To: Burleigh, Scott C (312B); Sebastian Schildt
Cc: Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Hi Scott,

Fred

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 12 Jun 2015 19:39:10 +0000

Finally getting back to this, because on reflection I think it uncovers another potentially useful feature of the "office" concept I've been proposing.

Again, DTN names are not addresses and contain no routing information, so some elements of Bill's message don't really apply.  But as Bill says, there could be a lot of value in a RFC1918-ish capability to configure and manage a network independently, without obtaining authorization from a central authority, and then later integrate it into a more comprehensive (even global) network without too much hassle.  I think the "office" (or "unit" or whatever) concept facilitates this.

Suppose a research team wants to set up a network of 100 nodes that communicate among themselves over constrained links.  While the network is being initially configured and bench-tested in the laboratory, the nodes of the network are all assigned node numbers in the range 1-100, as if the research team had been allocated an "office" of 128 nodes with office ID zero.

When testing is complete and the network is functioning well in the lab, the research team asks its parent administrative entity (NSF, MIT, DOE, whoever) to allocate to this team a new "office" of  128 nodes for operations in the global network.  The administrative entity provides the new "office" ID, a 56-bit integer.

The research team simply shuts the research network down, replaces office ID zero with this new allocated office ID everywhere in the configuration parameters for the research network, and restarts the network; no renumbering or renaming.  The research network is functionally unchanged but is instantly ready for integration into the global DTN.

Scott

-----Original Message-----
From: William Immerman [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2015 2:25 PM
To: Templin, Fred L; Burleigh, Scott C (312B)
Cc: [email-masked]; [email-masked] interest
Subject: Re: [dtn-interest] [dtn] DTN static routing

Fred & Scott--

Bill Immerman

On Jun 10, 2015, at 3:43 PM, Templin, Fred L wrote:

> still see it that the transmission efficiency is only there for early 
> the advantage diminishes as countless billions of users claim ID 
>> IEEE 802.15.4 ("ZigBee")? Yes, it is a lower layer, but basically it 
>> always want to throw around 64 bit addresses when sending a 16 bit temperature sample. Therefore there is a short addressing mode which uses 16bit identifiers. On top of that there is optionally a 2 byte network ID (the PAN ID, conceptually this sounds similar to Fred's "network of origin"). There are some flags managing addressing in the header so that you can go from src&dst PAN Identifier and long addresses (2*(2+8) bytes) down to no PAN ID and destination short address, no src address  (2 byte).
>> 
>> valid addresses for a super-WSN), is not a problem: Even if you are late/unlucky  full addresses "suck", in your application you can always work with arbitrary 16 bit short addresses. Gateways mapping this to globally valid addresses are very easy.
>> 
>> Wouldn't this make you both happy, @Fred/Scott? I guess some of the

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Jun 2015 20:03:05 +0000

Scott,

OK, let me take a "walk-before-run" breakdown of what I think I know.
Let's say there were two families (a and b). Family members could be
scattered to the four winds, meaning they could be on opposite sides of
an arbitrarily complex Internetwork from one another. What matters is
whether the family members can contact one another directly without
having to go through a DTN router, right?

So, let's take a look at a couple of contact graphs. Let's say that in the
first contact graph family members can talk to one another directly and
need to go through a DTN router to talk to members of other families.
So, if we had the contact graph:

  a1<->a2
  a1<->R
  b1<->b2
  b1<->R

In this case, a1 can talk to a2 using a short ID and b1 can talk to b2
using a short ID. But if a1 wanted to talk to b1 it would need to go
through a router R. Router R must then supply a's family name
along with the short node ID, because family a's short node IDs
are meaningless to family b's and vice-versa.
  
Now, let's say that in a second contact graph family members are on
opposite sides of a DTN router from one another but have contacts
with members of other families. So, if we had the contact graph:

  a1<->b1
  a1<->R
  a2<->b2
  a2<->R

In this case, a1 can talk to b1 directly but can't use a short ID because
it might collide with someone in b's family. However, if there were
some long-to-short ID mapping system that both a1 and b1 subscribed
to they could still use a short ID. Then, if a1 wanted to talk to a2 it would
need to go through a router R. Router R must then translate a1's short
node ID into its full long ID because the (local-scope) short IDs have no
meaning outside of router R's "domain".

So, if I have this right, the difference comes down to intra-family
and inter-family contact graph plans. I get what you are saying
about intra-family node ID compression, but I have been assuming
cases with inter-family mixes in the contact graph.

I'd like to get the SNR of this discussion back to a reasonable level so
it would be a big help if you could correct anything I might still be
misunderstanding.

Thanks - Fred

> Sent: Friday, June 12, 2015 10:03 AM
> Hi, Fred.  I picked the term "office" because I wanted to emphasize the fact that it was strictly administrative, with absolutely no
> topological significance, and that's what troubles me about using "site" instead.  "Site" certainly connotes location and topology, and I
> think a large part of our problem here is that topology and routing keep getting dragged into this conversation, in which they have no
> part.
> 
> Let me re-emphasize: in DTN, routing is based on late binding.  The mapping of a destination node identifier to some point in network
> topology is NOT reflected in the node identifier.  Not in any way.  Looking at the destination endpoint ID cannot ever be relied upon to
> tell you anything about the location of the destination in the network.  The word "routing" should never come up in a discussion of
> node naming.  There is no relationship between the two.
> 
> But sure, let's pick a better term than "office".  Maybe "unit"?  Or "corps", or "department"?  "Family?"  It doesn't need to be IETF-ish,
> it needs to be accurate, and in particular it needs to have absolutely no connotation of geography or topology or location.
> 
> "Family" is actually a fairly okay model.  Members of the same family can be scattered all across the world, but no matter where they
> are they can refer to one another by their first names when they write letters, so long as the letters are only exchanged among the
> family members.
> 
> Scott
> 
> > I didn't necessarily intend that as a compliment. I don't think we should necessarily be locked into SDNVs as the only way to
> represent
> > node IDs.
> >

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 12 Jun 2015 21:11:36 +0000

Great example, Fred.  I'll try to offer a couple of comments in-line on what you've written.

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Friday, June 12, 2015 1:03 PM
To: Burleigh, Scott C (312B); Sebastian Schildt
Cc: Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Scott,

  a1<->a2
  a1<->R
  b1<->b2
  b1<->R

through a router R.

	>	Yes, that's the way this topology works.

Router R must then supply a's family name
along with the short node ID, because family a's short node IDs
are meaningless to family b's and vice-versa.

	>	Since the bundle from a1 to b1 has to pass through R, yes, that's what R has to do.  (Unless R itself is not in family "a", in which case node a1 had to do this right at the start -- and R couldn't.  Remember, there are actually no "routers" in DTN; there are just nodes that can source, forward, and receive bundles, so R is just a node like any other.  If R happened to be in family "a" then there would be no need for any family ID extension blocks to be attached to the bundle until the hop from R to b1: from a1 to R, the bundle is always in the same family.  If not, then a1 would have to attach a family ID extension block to the bundle when sending it to R; that's the only way R could make any sense of the abbreviated source node ID "1".)

  a1<->b1
  a1<->R
  a2<->b2
  a2<->R

In this case, a1 can talk to b1 directly but can't use a short ID because
it might collide with someone in b's family.

	>	Correct.  They'd have to use fully qualified IDs ("a1" and "b1" instead of "1" and "1") in order to communicate.

However, if there were
some long-to-short ID mapping system that both a1 and b1 subscribed
to they could still use a short ID.

	>	Sure.  For example, we could carve out some large chunk of our node ID namespace for temporary allocation of new ad hoc "families".  In that case, we could assign these nodes additional "alias" IDs in a newly allocated ad hoc family while they're temporarily collocated.  An ad hoc family named "g" could be temporarily created, for example, and node a1 could be temporarily assigned alias ID "g1", with node b1 temporarily assigned alias ID "g2".  I'm not necessarily convinced that this is a good idea, but it's certainly consistent with the concept.

Then, if a1 wanted to talk to a2 it would
need to go through a router R. Router R must then translate a1's short
node ID into its full long ID because the (local-scope) short IDs have no
meaning outside of router R's "domain".

	>	That depends on what family R is in.  If R is in family a (e.g.  its ID is "a5") then there's no need for family ID extension blocks at any time: as the bundle moves from a1 to R ("a5") to a2 it never passes through any node that's not in the family.  But if R is in a different family from a1 (let's say its ID is "c1"), then when a1 initially forwards the bundle to R it has to attach family ID extension blocks so that R can know who the bundle's source and destination are.  Those family ID extension blocks are still there when R receives the bundle and then forwards it to a2.
	>	But there's no translation of IDs, just attachment of extension blocks, and router R doesn't have a "domain", it just has a family like anybody else. 

	>	We seem to be still focusing on routing, which is orthogonal to naming, but all the same I think it has been worthwhile to work through this example.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Jun 2015 21:31:23 +0000

Thanks for the feedback, Scott. Acknowledged about the point on there
being no such thing as a "DTN router" construct - every DTN node needs
to be able to store, carry and forward, right?

Here's another question - can a DTN node have multiple IDs (possibly
from different families)?

Fred

> Sent: Friday, June 12, 2015 2:12 PM
> 	>	Since the bundle from a1 to b1 has to pass through R, yes, that's what R has to do.  (Unless R itself is not in family "a",
> in which case node a1 had to do this right at the start -- and R couldn't.  Remember, there are actually no "routers" in DTN; there are
> just nodes that can source, forward, and receive bundles, so R is just a node like any other.  If R happened to be in family "a" then
> there would be no need for any family ID extension blocks to be attached to the bundle until the hop from R to b1: from a1 to R, the
> bundle is always in the same family.  If not, then a1 would have to attach a family ID extension block to the bundle when sending it to
> R; that's the only way R could make any sense of the abbreviated source node ID "1".)
> 
> 	>	Sure.  For example, we could carve out some large chunk of our node ID namespace for temporary allocation of new
> ad hoc "families".  In that case, we could assign these nodes additional "alias" IDs in a newly allocated ad hoc family while they're
> temporarily collocated.  An ad hoc family named "g" could be temporarily created, for example, and node a1 could be temporarily
> assigned alias ID "g1", with node b1 temporarily assigned alias ID "g2".  I'm not necessarily convinced that this is a good idea, but it's
> certainly consistent with the concept.
> 
> 	>	That depends on what family R is in.  If R is in family a (e.g.  its ID is "a5") then there's no need for family ID extension
> blocks at any time: as the bundle moves from a1 to R ("a5") to a2 it never passes through any node that's not in the family.  But if R is in
> a different family from a1 (let's say its ID is "c1"), then when a1 initially forwards the bundle to R it has to attach family ID extension
> blocks so that R can know who the bundle's source and destination are.  Those family ID extension blocks are still there when R
> receives the bundle and then forwards it to a2.
> > > When did we pick up the requirement to support bit-efficient MANETs?  Can you tell me which of our accepted use cases state
> that
> > > MANET architectures must be supported?
> >
> > > > > that has been allocated a given range of 63-bit node ID numbers has exclusive authority to assign the ID numbers in that range
> to
> > > BP nodes.
> > > > particular operational advantage over any other.  If we want the leading 23 bits of each node ID number to identify the "origin"
> of
> > > the ID number, fine.
> > > >
> > > > > -	Traffic that is wholly internal to an office is bit-efficient, because private IDs are used and office ID extension blocks are
> always
> > > > > omitted.
> > > > >
> > > > > -	There is no need to maintain any table that maps between global IDs and local IDs: global ID is always simply office ID
> followed
> > > > > by private ID.
> > > >
> > > > > > > > >>>>> compressible strings of 0's in the leading bits of the 64-bit field. Latecomers will not be able to take advantage of
> the
> > > optimization.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 12 Jun 2015 21:48:01 +0000

Fred, I'd say nothing in RFC 5050 or in our current IETF BP specification draft precludes letting a DTN node have multiple IDs.  Every node is required to be a member of at least one singleton endpoint, whose EID can be used to identify the node (so membership in the endpoint has to persist long enough for completion of all activities for which the node is identified by that EID).  But nothing says a node can't be a member of two or more such endpoints.

In practice, I think letting a node take on multiple identities introduces complexity that costs more than it's worth, so I don't much like the idea.  But I'm pretty sure it's legal.

Scott

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Friday, June 12, 2015 2:31 PM
To: Burleigh, Scott C (312B); Sebastian Schildt
Cc: Greg Troxel; [email-masked]; Rick Taylor; [email-masked]
Subject: RE: [dtn-interest] [dtn] DTN static routing

Fred

---

From: Sebastian Schildt <[email-masked]>
Date: Mon, 15 Jun 2015 17:42:23 +0300

Yes, and it is already common practice (I think? At least we are doing it) assigning several group EIDs to a node besides its normal unicast EID. So having multiple EIDs should be easy (and fully optional, just as you can have as many IP interfaces as you like, with 1 being a common and sensible choice for very simple devices)

Sebastian

> Am 15.06.2015 um 16:44 schrieb Sheehe, Charles J. (GRC-LCA0) <[email-masked]>:
> 
> I do not agree. By allowing a node to have two ID's and sufficient onboard resources, it allows easy expansion of the network. 
> 
> 
> Thanks
> Chuck
> 
> Charles J. Sheehe III
> Electronics Engineer
> System Architectures and Networks Branch
> 21000 Brookpark Rd
> Cleveland, OH 44135
> [email-masked]
> Office: 216-433-5179
> 
> 
> From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312B)
> Sent: Friday, June 12, 2015 5:48 PM

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 15 Jun 2015 15:19:32 +0000

Absolutely, it's a fundamental architectural principle of DTN that a node can be a member of multiple endpoints (singleton or otherwise) concurrently.

I'd say that's a little different from attaching multiple identities to a node, though, because not every singleton endpoint of which a node is a member will necessarily be used as a node ID for such purposes as custody transfer and security policy.  I think doing so can make DTN network management - which is already complex - even more complicated.  But maybe I'm wrong.  Chuck, in what way do you see multiplicity of node identities making it easier to scale up the network?

Scott

-----Original Message-----
From: Sebastian Schildt [mailto:[email-masked]] 
Sent: Monday, June 15, 2015 7:42 AM
To: Sheehe, Charles J. (GRC-LCA0)
Cc: Burleigh, Scott C (312B); Templin, Fred L; [email-masked]; [email-masked]; Rick Taylor; Greg Troxel
Subject: Re: [dtn] [dtn-interest] DTN static routing

Sebastian

---

From: <[email-masked]>
Date: Sun, 28 Jun 2015 09:10:22 +0000

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

"NPI"? this will bounce from sis-dtn, I expect.

________________________________
From: Scott, Keith L. <[email-masked]>
Sent: Thursday, 11 June 2015 11:06 PM
To: Wood L Dr (Electronic Eng); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]'
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

7515 Colshire Drive

McLean, VA 22102

Lloyd Wood

Lloyd,

                        --keith

7515 Colshire Drive

McLean, VA 22102

-----Original Message-----
From: dtn-interest [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, June 09, 2015 10:14 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] [dtn] DTN static routing

We addressed this in

Lloyd Wood

---

From: "Scott, Keith L." <[email-masked]>
Date: Sun, 28 Jun 2015 11:58:49 +0000

Whatever its heritage, the IETF WG is an IETF entity; it is not an arm of CCSDS, and it provides the forum, following the IETF rules and procedures, for all DTN users (including space, sensor-network, other terrestrial, etc.) to express their requirements and influence whatever protocols the WG develops.

My hope (from a CCSDS perspective) and what I will argue for within the WG is that the protocols that come out of the IETF WG can meet CCSDS’ needs, and better if they can be easily-translatable into RFC5050-based networks to ease evolution of CCSDS deployments.  If the IETF protocols can also meet CCSDS’ needs, CCSDS will enjoy a wider degree of interoperability with other (including terrestrial) systems, which as you  pointed out earlier would be a great benefit.  If the protocols developed by the IETF are not appropriate for space environments, CCSDS and the rest of the space community will have to define their own, separate, presumably non-interoperable (with the IETF) protocols for space internetworking.

Link-layer in CCSDS is another area, and I’ll leave your arguments with link-layer protocols to them.

—keith

From: "[email-masked]<mailto:[email-masked]>"
Date: Sunday, June 28, 2015 at 5:10 AM
To: "Scott, Keith L."
Cc: dtn-interest, "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>"
Subject: Re: [dtn-interest] [dtn] DTN static routing

Keith,

Lloyd Wood

________________________________
From: Scott, Keith L. <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, 11 June 2015 11:06 PM
To: Wood L Dr (Electronic Eng); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>'
Subject: RE: [dtn-interest] [dtn] DTN static routing

Lloyd,

                        --keith

7515 Colshire Drive

McLean, VA 22102

Area Director,CCSDS<http://www.ccsds.org/> Space Internetworking Services<http://cwe.ccsds.org/sis/default.aspx>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, June 11, 2015 3:47 AM
To: Scott, Keith L.; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] [dtn] DTN static routing

Lloyd Wood

Lloyd,

                        --keith

7515 Colshire Drive

McLean, VA 22102

Area Director,CCSDS<http://www.ccsds.org/>Space Internetworking Services<http://cwe.ccsds.org/sis/default.aspx>

-----Original Message-----
From: dtn-interest [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, June 09, 2015 10:14 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] [dtn] DTN static routing

We addressed this in

Lloyd Wood