Subject: Re: [dtn] for the virtual meeting

From: "Scott, Keith L." <[email-masked]>
Date: Fri, 5 Dec 2014 13:49:43 +0000

I think I concur with most of Scott's points below.  We definitely need something to identify nodes, and numbers should work fine - we can sort out some sort of DNS-like mechanism later *if* it seems important for people to be able to remember / refer to them.

I would argue that instead of limiting the range to 2^63-1 that the numbers be allowed to use [1, 2^128-1].  That gets us as many node identifiers as IPv6 has addresses, and there might be utility to being able to map between them in some situations.

And I'd like to discuss the relationship between endpoints and nodes (if any), and how (or if) anything ever needs to map one to the other.  If the node identifiers are truly persistent and unique, they sound like good things to route on, though to maintain the notion of late binding from RFC4838 I think the relationship between node IDs and endpoint identifiers would still need to be non-static (and preferably possibly fluid until near the time when a bundle needed to be delivered).

               --keith

====================

Hi.  If there's time during our virtual WG meeting tomorrow, I'd like to talk about the topic discussed in the attached file.

Scott

An argument for numeric node IDs in Bundle Protocol

Scott Burleigh

3 December 2014

        -       Why do we need node IDs?

We need node IDs in order to identify, in the fields of our protocol data units, the nodes that are designated to perform various protocol functions.

Currently we have no node IDs; all we have is endpoint IDs.  An endpoint ID identifies an endpoint, not a node.

An endpoint is a set of nodes.  RFC 5050 defines the manner in which an endpoint:

a.      Can be the destination of a bundle.  Bundle transmission is accomplished by sending a copy of the bundle to every node that is a member of the minimum reception group of the destination endpoint.

b.      Can constrain the delivery of a bundle; bundle delivery to the application agent of a node is subject to the node?s registration within the endpoint that is the destination of the bundle.

c.      Can constrain the forwarding of a bundle: the forwarding of a bundle to an endpoint is implemented by sending the bundle to every node that is a member of the minimum reception group of that endpoint.

That?s it.  An endpoint cannot initiate transmission of a bundle, it cannot send a bundle, it cannot receive a bundle, it cannot dispatch a bundle, it cannot forward a bundle, it cannot transmit a bundle, it cannot accept or refuse or release custody of a bundle, it cannot fragment or reassemble a bundle, and it cannot delete a bundle.  In BP, endpoints do almost nothing; nodes do almost everything.

In order for BP data unit fields to designate a node to send a bundle to, release custody of a bundle to, authenticate against, etc., they must be able to identify that node.  We manage to do this even though we don?t have node IDs.  We do it by asserting that every node must be a member of at least one singleton endpoint (an endpoint that can never have more than one member; see RFC 5050 section 3.1), and therefore the ID of that endpoint can be used as the ID for the node that is the sole member of that endpoint.

This works in practice because all implementations informally abide by the unstated assumption that a given node?s registration in its singleton endpoint(s) will persist long enough to enable that endpoint ID to serve as a node ID in continuous operation.  The BP spec in fact says no such thing.  It would be entirely compliant for a BP implementation to register a node in a new singleton endpoint once per second and also, once per second, unregister that node from all other singleton endpoints in which it is registered (see RFC 5050 section 3.3).

        -       Okay, so why not just fix that in the BP spec (state that "Every node shall be permanently registered in at least one endpoint, whose ID shall be termed the node?s ?node ID?") and continue using endpoint IDs - URIs - as node IDs wherever node IDs must be cited?

Because it?s not cost-effective to use URIs as node IDs in resource-constrained environments.  URIs are text strings of unlimited length.  In RFC 5050 we limit the length of any single endpoint ID to 2047 bytes, but that still means that the four endpoint IDs in the primary block of a bundle may occupy 8188 bytes - and we may need to cite additional endpoint IDs in security extension blocks, routing support extension blocks, administrative records, etc., etc.  In a bandwidth-rich academic Internet environment this may not seem like a big deal.  In live operations of sensor webs, spacecraft, underwater vehicles - or in bandwidth-constrained parts of the world - it?s high, possibly disabling, overhead, especially when bundles themselves must be small in order to be transmitted without fragmentation though low-bandwidth links.

And textual EIDs don?t only waste bandwidth and storage: they also waste processing cycles.  Reserving 2048 bytes for every node ID in the system may not be possible in resource-constrained environments.  But when implementations try to conserve the memory used for bundle retention by dynamically allocating only as much memory for an endpoint IDs as is needed, extra cycles have to be spent on allocating dynamic memory, testing for memory allocation failure, invoking error handling procedures when memory allocation failure occurs, and releasing allocated memory when it is no longer needed.  Time is wasted and code bloats.  Moreover, every dynamic memory allocation is an opportunity for corresponding memory release to be overlooked, introducing memory leakage that results in degraded performance and, in the extreme, software failure.

Numeric node IDs, limited to the range 1 to (2^63 - 1) and represented in SDNVs, would be vastly more efficient in consumption of bandwidth, memory, storage, and processing, without the possibility of memory leakage.

        -       Numeric IDs are space-centric.  We need a naming system that works for terrestrial DTN as well.

A numeric ID system has been developed for use in space flight operations, true, but that doesn?t mean that numeric IDs are space-centric.  Social security numbers are numeric IDs.  Phone numbers are numeric IDs.  Credit card numbers are numeric IDs.  They work fine for terrestrial networking.

        -       But numeric IDs are bad.  They are difficult to remember and easy to mistype.

Sure, but users of DTN will essentially never need to remember or type them.  IP is based on IP addresses, which we as users never see; we just click on free-form text links that are invisibly associated with domain names which are automatically resolved to IP addresses by the network itself.  Computer systems have no trouble remembering numbers.  The only humans who ever see IP addresses - or who would ever see numeric node IDs - are software developers and network managers.  Numeric node IDs would impose some burden on those users, but we don?t optimize protocol design for the convenience of developers and network managers; we optimize protocol design to deliver maximum value to users.

        -       But aren?t we specifically trying to get away from IP addressing in DTN, because it?s not delay-tolerant?

Sure, and numeric node IDs are an important part of that.  These are IDs, not addresses.  They have no topological significance; they contain no routing information.  Numeric node IDs would not be a flat address space.  They would be a flat name space, like social security numbers or MAC addresses, which DTN "late binding" would resolve to convergence-layer protocol addresses for forwarding and delivery.

        -       But such numbers would convey no information; they are too limiting.  Strings are much more expressive.

Strings are certainly more expressive and convey more information, but node IDs don?t need to convey information; they just need to be unique.  We can - and inevitably will - have registries that associate loads of information with node numbers: names, descriptions, inception dates, whatever - way more than could ever be reasonably encoded in any textual node name that anybody would ever type.  Numeric node IDs in the range 1 to (2^63 - 1) would not be limiting at all.  They would uniquely identify up to 8 quintillion BP nodes, occupying only 1 to 9 bytes of storage per ID.

        -       But how would the numbers be assigned?  If we use URIs based on DNS names then we don?t have to worry about two nodes ending up with the same ID.  The node IDs can be self-assigned.  If we use numbers, we?ve got no such assurance.

URIs based on DNS names can solve this problem only because the DNS system ensures the uniqueness of names; in general, most ID systems need some sort of registry somewhere to ensure the uniqueness of IDs.  Such a registry has already been established in IANA for numeric BP node IDs (RFC 7116, http://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-node-numbers).  Responsibility for node number assignment ranges can be delegated in the usual way.  And if we want them to be self-assigned, to first order we can just use MAC addresses.

---

From: "Sheehe, Charles J. (GRC-LCA0)" <[email-masked]>
Date: Fri, 5 Dec 2014 14:09:42 +0000

Hi

I understand that I am new to the group and do not understand a lot.

In order for the system to be scalable for space and terrestrial some kind of addressing structure with rules are needed.

If we split the solar system into 2 groups planetoids and non-planetoids  this covers Earth's and Mars section and the space in-between.

The planetoids address schemes are governed by a rapid changing address space and non-planetoids a much less evolving address space.

This allows for dual addressing and discovery of new nodes.

I understand the desire to dig in to the design, but is it possible to come up with a structure that will accommodate the fast paced dynamic planet based systems and allows addressing for non-planet based systems with one bit?

Thanks for listening
The file is a Visio breakdown of my thoughts.
I am planning to do more work in this area if it is needed.

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

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Scott, Keith L.
Sent: Friday, December 05, 2014 8:50 AM
To: [email-masked]
Subject: Re: [dtn] for the virtual meeting

 
 
               --keith

====================

Scott
An argument for numeric node IDs in Bundle Protocol Scott Burleigh
3 December 2014

---

From: "Sheehe, Charles J. (GRC-LCA0)" <[email-masked]>
Date: Fri, 5 Dec 2014 14:16:03 +0000

I was asked to resend as a PDF.

Thanks
Chuck

Charles J. Sheehe III
Electronics Engineer

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Sheehe, Charles J. (GRC-LCA0)
Sent: Friday, December 05, 2014 9:10 AM
To: Scott, Keith L.; [email-masked]
Subject: Re: [dtn] for the virtual meeting

Hi

Thanks for listening

Thanks
Chuck

Charles J. Sheehe III
Electronics Engineer

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Scott, Keith L.
Sent: Friday, December 05, 2014 8:50 AM
To: [email-masked]
Subject: Re: [dtn] for the virtual meeting

 
 
               --keith

====================

Scott

---

From: "Scott, Keith L." <[email-masked]>
Date: Fri, 5 Dec 2014 14:21:15 +0000

Charles,

We originally had a notion of a hierarchical (or at least, federated) address scheme similar to what you mention (the areas were called 'regions').  We could never fully sort out what to do with things that then moved from one region to another -- how they would acquire addresses in the new region and more importantly, how data to their 'old' address would be forwarded to their 'new' one.

The whole region-based addressing idea collapsed when we introduced the URI-based naming scheme and simply left it for later work.

I think this touches on the structure of any proposed node and/or EID naming schemes -- i.e. is the identifier space completely flat w.r.t. physical topology (which would make it harder to use as routing identifiers, if in fact we want to use them that way at all), or is it (nodes and/or eids) aggregable like IP addresses (which would make them easier to use for routing, but complicates mobility).

		--keith

-----Original Message-----
From: Sheehe, Charles J. (GRC-LCA0) [mailto:[email-masked]] 
Sent: Friday, December 05, 2014 9:10 AM
To: Scott, Keith L.; [email-masked]
Subject: RE: [dtn] for the virtual meeting

Hi

Thanks for listening

Thanks
Chuck

Charles J. Sheehe III
Electronics Engineer

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Scott, Keith L.
Sent: Friday, December 05, 2014 8:50 AM
To: [email-masked]
Subject: Re: [dtn] for the virtual meeting

 
 
               --keith

====================

Scott

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Fri, 5 Dec 2014 14:35:57 +0000

This is still valid and the crux of the matter:

http://www.ietf.org/rfc/rfc1498.txt

Recursively a name binds to an address.

IMHO, the URL naming was somewhat of a punt on addressing as well as an
attempt to mix content based networking with DTN.  Concepts of using the
URI as a query. Great for research, but not so great if one want wide
scale deployment - billions of nodes.

ICN is working naming schemes.  Naming and addressing are the key.  It is
a difficult concept and, IMHO,  not very well understood buy many.

Will

On 12/5/14 9:21 AM, "Scott, Keith L." <[email-masked]> wrote:

>Charles,
>
>We originally had a notion of a hierarchical (or at least, federated)
>address scheme similar to what you mention (the areas were called
>'regions').  We could never fully sort out what to do with things that
>then moved from one region to another -- how they would acquire addresses
>in the new region and more importantly, how data to their 'old' address
>would be forwarded to their 'new' one.
>
>The whole region-based addressing idea collapsed when we introduced the
>URI-based naming scheme and simply left it for later work.
>
>I think this touches on the structure of any proposed node and/or EID
>naming schemes -- i.e. is the identifier space completely flat w.r.t.
>physical topology (which would make it harder to use as routing
>identifiers, if in fact we want to use them that way at all), or is it
>(nodes and/or eids) aggregable like IP addresses (which would make them
>easier to use for routing, but complicates mobility).
>
>		--keith
>
>In order for the system to be scalable for space and terrestrial some
>kind of addressing structure with rules are needed.
>
>If we split the solar system into 2 groups planetoids and non-planetoids
>this covers Earth's and Mars section and the space in-between.
>
>The planetoids address schemes are governed by a rapid changing address
>space and non-planetoids a much less evolving address space.
>
>I understand the desire to dig in to the design, but is it possible to
>come up with a structure that will accommodate the fast paced dynamic
>planet based systems and allows addressing for non-planet based systems
>with one bit?
>
>Thanks for listening
>I think I concur with most of Scott's points below.  We definitely need
>something to identify nodes, and numbers should work fine - we can sort
>out some sort of DNS-like mechanism later *if* it seems important for
>people to be able to remember / refer to them.
> 
>I would argue that instead of limiting the range to 2^63-1 that the
>numbers be allowed to use [1, 2^128-1].  That gets us as many node
>identifiers as IPv6 has addresses, and there might be utility to being
>able to map between them in some situations.
> 
>And I'd like to discuss the relationship between endpoints and nodes (if
>any), and how (or if) anything ever needs to map one to the other.  If
>the node identifiers are truly persistent and unique, they sound like
>good things to route on, though to maintain the notion of late binding
>from RFC4838 I think the relationship between node IDs and endpoint
>identifiers would still need to be non-static (and preferably possibly
>fluid until near the time when a bundle needed to be delivered).
> 
>               --keith
> 
> 
>====================
> 
>Hi.  If there's time during our virtual WG meeting tomorrow, I'd like to
>talk about the topic discussed in the attached file.
> 
>Scott
>We need node IDs in order to identify, in the fields of our protocol data
>units, the nodes that are designated to perform various protocol
>functions.
> 
>a.      Can be the destination of a bundle.  Bundle transmission is
>accomplished by sending a copy of the bundle to every node that is a
>member of the minimum reception group of the destination endpoint.
>b.      Can constrain the delivery of a bundle; bundle delivery to the
>application agent of a node is subject to the node?s registration within
>the endpoint that is the destination of the bundle.
>c.      Can constrain the forwarding of a bundle: the forwarding of a
>bundle to an endpoint is implemented by sending the bundle to every node
>that is a member of the minimum reception group of that endpoint.
> 
>That?s it.  An endpoint cannot initiate transmission of a bundle, it
>cannot send a bundle, it cannot receive a bundle, it cannot dispatch a
>bundle, it cannot forward a bundle, it cannot transmit a bundle, it
>cannot accept or refuse or release custody of a bundle, it cannot
>fragment or reassemble a bundle, and it cannot delete a bundle.  In BP,
>endpoints do almost nothing; nodes do almost everything.
> 
>In order for BP data unit fields to designate a node to send a bundle to,
>release custody of a bundle to, authenticate against, etc., they must be
>able to identify that node.  We manage to do this even though we don?t
>have node IDs.  We do it by asserting that every node must be a member of
>at least one singleton endpoint (an endpoint that can never have more
>than one member; see RFC 5050 section 3.1), and therefore the ID of that
>endpoint can be used as the ID for the node that is the sole member of
>that endpoint.
> 
>This works in practice because all implementations informally abide by
>the unstated assumption that a given node?s registration in its singleton
>endpoint(s) will persist long enough to enable that endpoint ID to serve
>as a node ID in continuous operation.  The BP spec in fact says no such
>thing.  It would be entirely compliant for a BP implementation to
>register a node in a new singleton endpoint once per second and also,
>once per second, unregister that node from all other singleton endpoints
>in which it is registered (see RFC 5050 section 3.3).
> 
>        -       Okay, so why not just fix that in the BP spec (state that
>"Every node shall be permanently registered in at least one endpoint,
>whose ID shall be termed the node?s ?node ID?") and continue using
>endpoint IDs - URIs - as node IDs wherever node IDs must be cited?
> 
>Because it?s not cost-effective to use URIs as node IDs in
>resource-constrained environments.  URIs are text strings of unlimited
>length.  In RFC 5050 we limit the length of any single endpoint ID to
>2047 bytes, but that still means that the four endpoint IDs in the
>primary block of a bundle may occupy 8188 bytes - and we may need to cite
>additional endpoint IDs in security extension blocks, routing support
>extension blocks, administrative records, etc., etc.  In a bandwidth-rich
>academic Internet environment this may not seem like a big deal.  In live
>operations of sensor webs, spacecraft, underwater vehicles - or in
>bandwidth-constrained parts of the world - it?s high, possibly disabling,
>overhead, especially when bundles themselves must be small in order to be
>transmitted without fragmentation though low-bandwidth links.
> 
>And textual EIDs don?t only waste bandwidth and storage: they also waste
>processing cycles.  Reserving 2048 bytes for every node ID in the system
>may not be possible in resource-constrained environments.  But when
>implementations try to conserve the memory used for bundle retention by
>dynamically allocating only as much memory for an endpoint IDs as is
>needed, extra cycles have to be spent on allocating dynamic memory,
>testing for memory allocation failure, invoking error handling procedures
>when memory allocation failure occurs, and releasing allocated memory
>when it is no longer needed.  Time is wasted and code bloats.  Moreover,
>every dynamic memory allocation is an opportunity for corresponding
>memory release to be overlooked, introducing memory leakage that results
>in degraded performance and, in the extreme, software failure.
> 
>Numeric node IDs, limited to the range 1 to (2^63 - 1) and represented in
>SDNVs, would be vastly more efficient in consumption of bandwidth,
>memory, storage, and processing, without the possibility of memory
>leakage.
> 
>A numeric ID system has been developed for use in space flight
>operations, true, but that doesn?t mean that numeric IDs are
>space-centric.  Social security numbers are numeric IDs.  Phone numbers
>are numeric IDs.  Credit card numbers are numeric IDs.  They work fine
>for terrestrial networking.
> 
>Sure, but users of DTN will essentially never need to remember or type
>them.  IP is based on IP addresses, which we as users never see; we just
>click on free-form text links that are invisibly associated with domain
>names which are automatically resolved to IP addresses by the network
>itself.  Computer systems have no trouble remembering numbers.  The only
>humans who ever see IP addresses - or who would ever see numeric node IDs
>- are software developers and network managers.  Numeric node IDs would
>impose some burden on those users, but we don?t optimize protocol design
>for the convenience of developers and network managers; we optimize
>protocol design to deliver maximum value to users.
> 
>        -       But aren?t we specifically trying to get away from IP
>addressing in DTN, because it?s not delay-tolerant?
> 
>Sure, and numeric node IDs are an important part of that.  These are IDs,
>not addresses.  They have no topological significance; they contain no
>routing information.  Numeric node IDs would not be a flat address space.
> They would be a flat name space, like social security numbers or MAC
>addresses, which DTN "late binding" would resolve to convergence-layer
>protocol addresses for forwarding and delivery.
> 
>        -       But such numbers would convey no information; they are
>too limiting.  Strings are much more expressive.
> 
>Strings are certainly more expressive and convey more information, but
>node IDs don?t need to convey information; they just need to be unique.
>We can - and inevitably will - have registries that associate loads of
>information with node numbers: names, descriptions, inception dates,
>whatever - way more than could ever be reasonably encoded in any textual
>node name that anybody would ever type.  Numeric node IDs in the range 1
>to (2^63 - 1) would not be limiting at all.  They would uniquely identify
>up to 8 quintillion BP nodes, occupying only 1 to 9 bytes of storage per
>ID. 
> 
>        -       But how would the numbers be assigned?  If we use URIs
>based on DNS names then we don?t have to worry about two nodes ending up
>with the same ID.  The node IDs can be self-assigned.  If we use numbers,
>we?ve got no such assurance.
> 
>URIs based on DNS names can solve this problem only because the DNS
>system ensures the uniqueness of names; in general, most ID systems need
>some sort of registry somewhere to ensure the uniqueness of IDs.  Such a
>registry has already been established in IANA for numeric BP node IDs
>(RFC 7116, 
>http://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-node-numbers).
>Responsibility for node number assignment ranges can be delegated in the
>usual way.  And if we want them to be self-assigned, to first order we
>can just use MAC addresses.
>
> 
>
>_______________________________________________
>dtn mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dtn

---

From: Brian Haberman <[email-masked]>
Date: Fri, 05 Dec 2014 09:40:02 -0500

Hi Charles,

On 12/5/14 9:21 AM, Scott, Keith L. wrote:
> 'regions').  We could never fully sort out what to do with things
> that then moved from one region to another -- how they would acquire
> addresses in the new region and more importantly, how data to their
> 'old' address would be forwarded to their 'new' one.
> 
> The whole region-based addressing idea collapsed when we introduced
> the URI-based naming scheme and simply left it for later work.
> 
> identifiers, if in fact we want to use them that way at all), or is
> it (nodes and/or eids) aggregable like IP addresses (which would make
> them easier to use for routing, but complicates mobility).

I think we need to avoid overloading this identifier with location
semantics.  That is, we should keep the ID component distinctly separate
from the locator.  One way to think of this is MIP view of a Home
Address and a Care-of Address.

Has anyone considered a HIP-based approach to node identity in the DTN
realm?

Regards,
Brian

> 
> --keith
> 
> -----Original Message----- From: Sheehe, Charles J. (GRC-LCA0)
> [mailto:[email-masked]] Sent: Friday, December 05, 2014
> 9:10 AM To: Scott, Keith L.; [email-masked] Subject: RE: [dtn] for the
> virtual meeting
> 
> Hi
> 
> If we split the solar system into 2 groups planetoids and
> non-planetoids  this covers Earth's and Mars section and the space
> in-between.
> 
> The planetoids address schemes are governed by a rapid changing
> address space and non-planetoids a much less evolving address space.
> 
> I understand the desire to dig in to the design, but is it possible
> to come up with a structure that will accommodate the fast paced
> dynamic planet based systems and allows addressing for non-planet
> based systems with one bit?
> 
> Thanks for listening The file is a Visio breakdown of my thoughts. I
> am planning to do more work in this area if it is needed.
> 
> 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
> 
> -----Original Message----- From: dtn [mailto:[email-masked]] On
> Behalf Of Scott, Keith L. Sent: Friday, December 05, 2014 8:50 AM To:
> [email-masked] Subject: Re: [dtn] for the virtual meeting
> 
> I think I concur with most of Scott's points below.  We definitely
> need something to identify nodes, and numbers should work fine - we
> can sort out some sort of DNS-like mechanism later *if* it seems
> important for people to be able to remember / refer to them.
> 
> identifiers as IPv6 has addresses, and there might be utility to
> being able to map between them in some situations.
> 
> And I'd like to discuss the relationship between endpoints and nodes
> (if any), and how (or if) anything ever needs to map one to the
> other.  If the node identifiers are truly persistent and unique, they
> sound like good things to route on, though to maintain the notion of
> late binding from RFC4838 I think the relationship between node IDs
> and endpoint identifiers would still need to be non-static (and
> preferably possibly fluid until near the time when a bundle needed to
> be delivered).
> 
> --keith
> 
> 
> ====================
> 
> Hi.  If there's time during our virtual WG meeting tomorrow, I'd like
> to talk about the topic discussed in the attached file.
> 
> Scott An argument for numeric node IDs in Bundle Protocol Scott
> Burleigh 3 December 2014
> 
> We need node IDs in order to identify, in the fields of our protocol
> data units, the nodes that are designated to perform various protocol
> functions.
> 
> Currently we have no node IDs; all we have is endpoint IDs.  An
> endpoint ID identifies an endpoint, not a node.
> 
> An endpoint is a set of nodes.  RFC 5050 defines the manner in which
> an endpoint: a.      Can be the destination of a bundle.  Bundle
> transmission is accomplished by sending a copy of the bundle to every
> node that is a member of the minimum reception group of the
> destination endpoint. b.      Can constrain the delivery of a bundle;
> bundle delivery to the application agent of a node is subject to the
> node?s registration within the endpoint that is the destination of
> the bundle. c.      Can constrain the forwarding of a bundle: the
> forwarding of a bundle to an endpoint is implemented by sending the
> bundle to every node that is a member of the minimum reception group
> of that endpoint.
> 
> cannot send a bundle, it cannot receive a bundle, it cannot dispatch
> a bundle, it cannot forward a bundle, it cannot transmit a bundle, it
> fragment or reassemble a bundle, and it cannot delete a bundle.  In
> BP, endpoints do almost nothing; nodes do almost everything.
> 
> In order for BP data unit fields to designate a node to send a bundle
> to, release custody of a bundle to, authenticate against, etc., they
> must be able to identify that node.  We manage to do this even though
> we don?t have node IDs.  We do it by asserting that every node must
> be a member of at least one singleton endpoint (an endpoint that can
> never have more than one member; see RFC 5050 section 3.1), and
> therefore the ID of that endpoint can be used as the ID for the node
> that is the sole member of that endpoint.
> 
> This works in practice because all implementations informally abide
> by the unstated assumption that a given node?s registration in its
> singleton endpoint(s) will persist long enough to enable that
> endpoint ID to serve as a node ID in continuous operation.  The BP
> spec in fact says no such thing.  It would be entirely compliant for
> a BP implementation to register a node in a new singleton endpoint
> once per second and also, once per second, unregister that node from
> all other singleton endpoints in which it is registered (see RFC 5050
> section 3.3).
> 
> resource-constrained environments.  URIs are text strings of
> unlimited length.  In RFC 5050 we limit the length of any single
> endpoint ID to 2047 bytes, but that still means that the four
> endpoint IDs in the primary block of a bundle may occupy 8188 bytes -
> and we may need to cite additional endpoint IDs in security extension
> blocks, routing support extension blocks, administrative records,
> etc., etc.  In a bandwidth-rich academic Internet environment this
> may not seem like a big deal.  In live operations of sensor webs,
> spacecraft, underwater vehicles - or in bandwidth-constrained parts
> of the world - it?s high, possibly disabling, overhead, especially
> when bundles themselves must be small in order to be transmitted
> without fragmentation though low-bandwidth links.
> 
> And textual EIDs don?t only waste bandwidth and storage: they also
> waste processing cycles.  Reserving 2048 bytes for every node ID in
> the system may not be possible in resource-constrained environments.
> But when implementations try to conserve the memory used for bundle
> retention by dynamically allocating only as much memory for an
> endpoint IDs as is needed, extra cycles have to be spent on
> allocating dynamic memory, testing for memory allocation failure,
> invoking error handling procedures when memory allocation failure
> occurs, and releasing allocated memory when it is no longer needed.
> Time is wasted and code bloats.  Moreover, every dynamic memory
> allocation is an opportunity for corresponding memory release to be
> overlooked, introducing memory leakage that results in degraded
> performance and, in the extreme, software failure.
> 
> Numeric node IDs, limited to the range 1 to (2^63 - 1) and
> represented in SDNVs, would be vastly more efficient in consumption
> of bandwidth, memory, storage, and processing, without the
> possibility of memory leakage.
> 
> space-centric.  Social security numbers are numeric IDs.  Phone
> numbers are numeric IDs.  Credit card numbers are numeric IDs.  They
> work fine for terrestrial networking.
> 
> Sure, but users of DTN will essentially never need to remember or
> type them.  IP is based on IP addresses, which we as users never see;
> we just click on free-form text links that are invisibly associated
> with domain names which are automatically resolved to IP addresses by
> the network itself.  Computer systems have no trouble remembering
> numbers.  The only humans who ever see IP addresses - or who would
> ever see numeric node IDs - are software developers and network
> managers.  Numeric node IDs would impose some burden on those users,
> but we don?t optimize protocol design for the convenience of
> developers and network managers; we optimize protocol design to
> deliver maximum value to users.
> 
> Sure, and numeric node IDs are an important part of that.  These are
> IDs, not addresses.  They have no topological significance; they
> contain no routing information.  Numeric node IDs would not be a flat
> address space.  They would be a flat name space, like social security
> numbers or MAC addresses, which DTN "late binding" would resolve to
> convergence-layer protocol addresses for forwarding and delivery.
> 
> -       But such numbers would convey no information; they are too
> limiting.  Strings are much more expressive.
> 
> Strings are certainly more expressive and convey more information,
> but node IDs don?t need to convey information; they just need to be
> unique.  We can - and inevitably will - have registries that
> associate loads of information with node numbers: names,
> descriptions, inception dates, whatever - way more than could ever be
> reasonably encoded in any textual node name that anybody would ever
> type.  Numeric node IDs in the range 1 to (2^63 - 1) would not be
> limiting at all.  They would uniquely identify up to 8 quintillion BP
> nodes, occupying only 1 to 9 bytes of storage per ID.
> 
> -       But how would the numbers be assigned?  If we use URIs based
> on DNS names then we don?t have to worry about two nodes ending up
> with the same ID.  The node IDs can be self-assigned.  If we use
> numbers, we?ve got no such assurance.
> 
> system ensures the uniqueness of names; in general, most ID systems
> need some sort of registry somewhere to ensure the uniqueness of IDs.
> Such a registry has already been established in IANA for numeric BP
> node IDs (RFC 7116,
> Responsibility for node number assignment ranges can be delegated in
> the usual way.  And if we want them to be self-assigned, to first
> order we can just use MAC addresses.
> 
> 
> 
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Fri, 5 Dec 2014 15:00:15 +0000

>Address and a Care-of Address.

Agree 

>Has anyone considered a HIP-based approach to node identity in the DTN

HIP improves on mobile-ip so it has conceptually valid.

I think the problem is closely associated with the two vastly different
Disconnection deployment environments: opportunistic with low propagation
delays, and deep space with high propagation delays.  The former may have
billions of nodes, the later 10s or perhaps 100s.  (Note, I do not include
Low Earth Orbiting systems wit deep space as propagation delay is not an
issue nor is Geostationary.)

I'll leave this discussion for a later time as the meeting is nearly upon
us.  Such discussion may result in a re-architecture as well as
significant changes to the protocol.

I think the meeting is about what we do to fix the current protocol -
minimalistic approach or not.  Hop count, header / payload reliability,
simplify security.  These are doable, but I highly doubt will result in a
protocol that gets deployed much beyond Space and a few small special
terrestrial networks due to scalability, no routing, no discovery.  May be
deployable to 100s of nodes, but that might be the limit.

Will

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Dec 2014 17:38:58 +0000

Hi,

I am just now seeing this thread after the interim meeting. On addressing, many of the use
cases I am looking at involve mobile nodes and with mobility always comes de-aggregation.
See AERO for example for how it handles mobility-related de-aggregation:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

If the address has a network prefix part and a node ID part (e.g. as for IPv6 addresses)
then de-aggregation is accommodated by the routing system in the mobile node's home
network. If the address is just a flat node ID space, then de-aggregation must be handled
by some universal routing system. The trouble is, for many classes of DTN nodes there
may be no notion of a "home network". In that case, a completely flat node ID space
may be the only thing that makes sense.

So, one idea is to define the most significant bit of the address as the "hierarchical/flat"
bit. If the bit is 0, the rest of the address contains a flat node ID. If the bit is 1, however,
the address contains a network prefix part followed by a node ID for which the exact
format is TBD and beyond the scope of the current working group charter. (Don't
worry; we will figure out how to shoehorn in multicast addresses as well.)

Comments?

Thanks - Fred
[email-masked]

> From: dtn [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-LCA0)
> Sent: Friday, December 05, 2014 7:00 AM
> To: Brian Haberman; [email-masked]

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 5 Dec 2014 18:36:53 +0000

I have a slight preference for the smaller range, as I think it would end up generating more compact object code, but I wouldn't argue hard against an upper limit of 2^128-1.  This would always fit into an SDNV of at most 19 octets (leaving the 5 high-order bits undefined); the maximum size of a node ID on the wire would be 152 bits, and the maximum size of a node ID in memory would be 16 bytes.

I think the original RFC4838 concept of late binding is still fundamental to DTN, and in practice indispensable:

In a frequently-disconnected network, late binding may be  advantageous because the transit time of a message may exceed the  validity time of a binding, making binding at the source impossible  or invalid.  Furthermore, use of name-based routing with late binding  may reduce the amount of administrative (mapping) information that must propagate through the network, and may also limit the scope of  mapping synchronization requirements to a local topological neighborhood where changes are made.

That is why I keep harping on the notion that these node IDs need to be names (albeit names that are written in the restricted alphabet of the ten Hindu-Arabic numerals) rather than addresses.  They shouldn't indicate the topological location of the referenced node, because that location can be ephemeral; a node's identity is permanent, but its location is not.  For this reason, I think it would be a mistake to build any sort of routing hints into BP node IDs at all - they would always be susceptible to suddenly becoming falsehoods.

I recognize that this leaves us with the problem of efficiently storing and searching routing tables, which we solve in the Internet by address aggregation.  But address aggregation doesn't align well with node mobility, so let's resolve to find a different solution in DTN.  (I've got some ideas on what that different solution might look like, but I would propose that we take that up on a separate thread.)

Scott

From: dtn [mailto:[email-masked]] On Behalf Of Scott, Keith L.
Sent: Friday, December 5, 2014 5:50 AM
To: [email-masked]
Subject: Re: [dtn] for the virtual meeting

               --keith

====================

Scott

Scott Burleigh

3 December 2014

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 5 Dec 2014 21:15:05 +0000

Will, sure, Saltzer is certainly still valid.  Nothing in the "late binding" concept of DTN - nothing in the notion of issuing a bundle to a node directly by name rather than indirectly via the node's address - conflicts in any way with anything in RFC 1498.  As Salter observes, "A given node may be connected to one or more network attachment points, and may need to move from one attachment point to another without losing its identity as a node."  The novelty introduced by DTN is simply that this change in attachment point may routinely occur while data are in transit (that is, after a bundle has been issued but before it arrives), and the protocol design needs to accommodate this behavior without depending on rapid network-wide propagation of information regarding these changes in bindings.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-LCA0)
Sent: Friday, December 5, 2014 6:36 AM
To: Scott, Keith L.; Sheehe, Charles J. (GRC-LCA0); [email-masked]
Subject: Re: [dtn] for the virtual meeting

IMHO, the URL naming was somewhat of a punt on addressing as well as an attempt to mix content based networking with DTN.  Concepts of using the URI as a query. Great for research, but not so great if one want wide scale deployment - billions of nodes.

ICN is working naming schemes.  Naming and addressing are the key.  It is a difficult concept and, IMHO,  not very well understood buy many.

Will

On 12/5/14 9:21 AM, "Scott, Keith L." <[email-masked]> wrote:

>then moved from one region to another -- how they would acquire 
>non-planetoids this covers Earth's and Mars section and the space in-between.
>
>(if any), and how (or if) anything ever needs to map one to the other.  
>If the node identifiers are truly persistent and unique, they sound 
>like good things to route on, though to maintain the notion of late 
>binding from RFC4838 I think the relationship between node IDs and 
>endpoint identifiers would still need to be non-static (and preferably 
>possibly fluid until near the time when a bundle needed to be delivered).
> 
>               --keith
> 
> 
>====================
> 
>application agent of a node is subject to the node?s registration 
>within the endpoint that is the destination of the bundle.
>bundle to an endpoint is implemented by sending the bundle to every 
>node that is a member of the minimum reception group of that endpoint.
> 
>we don?t have node IDs.  We do it by asserting that every node must be 
>a member of at least one singleton endpoint (an endpoint that can never 
>have more than one member; see RFC 5050 section 3.1), and therefore the 
>ID of that endpoint can be used as the ID for the node that is the sole 
>member of that endpoint.
> 
>endpoint(s) will persist long enough to enable that endpoint ID to 
>serve as a node ID in continuous operation.  The BP spec in fact says 
>no such thing.  It would be entirely compliant for a BP implementation 
>to register a node in a new singleton endpoint once per second and 
>also, once per second, unregister that node from all other singleton 
>endpoints in which it is registered (see RFC 5050 section 3.3).
> 
>primary block of a bundle may occupy 8188 bytes - and we may need to 
>cite additional endpoint IDs in security extension blocks, routing 
>support extension blocks, administrative records, etc., etc.  In a 
>bandwidth-rich academic Internet environment this may not seem like a 
>big deal.  In live operations of sensor webs, spacecraft, underwater 
>vehicles - or in bandwidth-constrained parts of the world - it?s high, 
>possibly disabling, overhead, especially when bundles themselves must 
>be small in order to be transmitted without fragmentation though low-bandwidth links.
> 
>waste processing cycles.  Reserving 2048 bytes for every node ID in the 
>system may not be possible in resource-constrained environments.  But 
>when implementations try to conserve the memory used for bundle 
>retention by dynamically allocating only as much memory for an endpoint 
>IDs as is needed, extra cycles have to be spent on allocating dynamic 
>memory, testing for memory allocation failure, invoking error handling 
>procedures when memory allocation failure occurs, and releasing 
>allocated memory when it is no longer needed.  Time is wasted and code 
>bloats.  Moreover, every dynamic memory allocation is an opportunity 
>for corresponding memory release to be overlooked, introducing memory 
>leakage that results in degraded performance and, in the extreme, software failure.
> 
>Numeric node IDs, limited to the range 1 to (2^63 - 1) and represented 
>in SDNVs, would be vastly more efficient in consumption of bandwidth, 
>them.  IP is based on IP addresses, which we as users never see; we 
>just click on free-form text links that are invisibly associated with 
>domain names which are automatically resolved to IP addresses by the 
>network itself.  Computer systems have no trouble remembering numbers.  
>The only humans who ever see IP addresses - or who would ever see 
>numeric node IDs
>impose some burden on those users, but we don?t optimize protocol 
>design for the convenience of developers and network managers; we 
>optimize protocol design to deliver maximum value to users.
> 
>contain no routing information.  Numeric node IDs would not be a flat address space.
>whatever - way more than could ever be reasonably encoded in any 
>textual node name that anybody would ever type.  Numeric node IDs in 
>the range 1 to (2^63 - 1) would not be limiting at all.  They would 
>uniquely identify up to 8 quintillion BP nodes, occupying only 1 to 9 
>bytes of storage per ID.
> 
>based on DNS names then we don?t have to worry about two nodes ending 
>up with the same ID.  The node IDs can be self-assigned.  If we use 
>the usual way.  And if we want them to be self-assigned, to first order 
>we can just use MAC addresses.
>
> 
>