Re: [dtn] [EXT] I-D Action: draft-ietf-dtn-ipn-update-00.txt

[[e-mail]]

Hi, Scott.  I can only speak to the way ION could handle this; other implementations would do it differently.

In ION, spacecraft A would be (let's say) a single node with one identified topological neighbor: another spacecraft B in the same "network" (administratively speaking).  In the configuration of node A there would be a single outduct, for transmission to B via long range radio. The contact plan at A would say that all the nodes it wants to talk to are reachable through relay B.  It would also say that all those nodes are additionally reachable through a third spacecraft that is in a foreign "network", C, but A has got no way of forwarding bundles to C (no outduct to it and no contact in the contact plan).

Now suppose A's long range radio fails; the data rate for transmission to B drops to zero, and suddenly contact graph routing determines that no data can be forwarded at all.  All bundles pending transmission are revectored into the "limbo" queue, where they sit waiting for something good to happen.

But now node C is detected by neighbor discovery.  In the course of neighbor discovery, A adds an outduct for transmission to C via its short-range radio and it also adds a contact with C to its contact plan.

Addition of the new contact causes reconsideration of all the nodes in the limbo queue, and happily it is determined that they can now all be forwarded through C to their destinations.  The bundles are enqueued to the C outduct and are thereupon transmitted over short-range radio to C for forwarding.

Scott  

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Thursday, November 10, 2022 2:28 PM
To: [e-mail]
Cc: 'Sipos, Brian J.' <[e-mail]>; 'Rick Taylor' <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: [dtn] [EXT] I-D Action: draft-ietf-dtn-ipn-update-00.txt

Hi Scott,

What happens when a long range radio on a spacecraft fails, but its short range radio can reach an alternate authority's network; perhaps of a commercial provider, perhaps a partner space agency.  Is there another reasonable way for the craft to reroute transmission, if, for example, neighbor discovery shows a viable contact in range for long enough to dump the data off into a network with a working long range link?

Thanks,
ScottJ

On Thu, 10 Nov 2022, [e-mail] wrote:

> Brian, this isn't exactly right.  Every BP node comprises a BP Agent, an Application Agent, and zero or more Convergence-Layer Adapters (see section 3.1 and Figure 2 of RFC 9171).  The node - not the BPA - is the thing that is assigned an IPN node number.
>
> But ION is indeed limited to assigning exactly one node number to a given node; stating that node number is one of the very first steps of deploying an ION BP node.
>
> You're also correct that an IPN node number is not a Node ID as defined in RFC 9171, much as I might wish it otherwise.  A Node ID is defined as the endpoint ID of any singleton endpoint of which the node is a member (RFC 9171 section 4.2.5.2).
>
> A BP endpoint is simply a set of nodes, nothing more.  There is nothing in RFC 9171 that prohibits a given node from registering in (becoming a member of) any endpoint it likes, so unfortunately it is conceptually possible for a given node to register (for example) in two different administrative endpoints whose EIDs are ipn-scheme URIs with (necessarily) different node numbers.
>
> In this event, the node would have two different node IDs and would be informally identified by two different node numbers.  I don't think this is ever necessary, and I don't think it's desirable.
>
> Scott
>
> -----Original Message-----
> From: Sipos, Brian J. <[e-mail]>
> Sent: Thursday, November 10, 2022 9:47 AM
> To: [e-mail]; [e-mail]
> Cc: 'Rick Taylor' <[e-mail]>; 
> [e-mail]; [e-mail]
> Subject: RE: [dtn] [EXT] I-D Action: draft-ietf-dtn-ipn-update-00.txt
>
> Scott,
> The BP Agent (BPA) is the thing which gets assigned an IPN Node Number and I believe that ION is limited to assigning exactly one node number to a BPA. It's important not to confuse the IPN node number, which is what we are talking about, with a Node ID. An ION BPA can currently be assigned a set of endpoint Node IDs but they must all have the same IPN node number (e.g. one BPA can have endpoints "ipn:3.1" and "ipn:3.8", but cannot have endpoint "ipn:5.1").
>
> CLAs are fully separate from Endpoint ID (and Node ID) and don't have their own on-the-wire identifiers; any CLA identifier or CLA parameters are an implementation detail and not currently standardized. So in your case you were working with 5 nodes.
>
> If Section 3.1 of RFC 9171 draws equivalency of a BP "node" to an IPv6 "interface", meaning it's the thing to which BP names / IP addresses are assigned, then the BP model is missing the concept of the IPv6 "node" which is the router which operates separately from address assignments. In the BP model the node is 1:1 with the BPA which is 1:1 with the administrative endpoint, and there is no specific example of how multiple node number assignments would interact with that structure.
>
> My naïve understanding is that a BPA is still 1:1 with an administrative endpoint and if there were multiple IPN node numbers assigned to that "node" the administrative endpoint (the entity doing the protocol work) would actually be registered as the "ipn:X.0" endpoint on all of the node numbers. In this case there is one BP "node" which is assigned multiple node numbers and it's the one BPA which is doing the routing and forwarding. This is more in-line with the IPv4 model where IP addresses are all assigned to the node, the same thing which is the router.
>
>> -----Original Message-----
>> From: [e-mail] <[e-mail]>
>> Sent: Thursday, November 10, 2022 11:58 AM
>> To: [e-mail]
>> Cc: 'Rick Taylor' <[e-mail]>; Sipos, Brian J.
>> <[e-mail]>; [e-mail]; [e-mail]
>> Subject: Re: [dtn] [EXT] I-D Action: draft-ietf-dtn-ipn-update-00.txt
>>
>> APL external email warning: Verify sender [e-mail] 
>> before clicking links or attachments
>>
>>
>> On Thu, 10 Nov 2022, [e-mail] wrote:
>>
>>> Hi, Rick.  The definitions of "node" and "BP agent" are in section 3.1.
>>> The observation that BP nodes are functionally analogous to network 
>>> interface cards is merely an observation, but I think it's 
>>> consistent with -- amplifying -- the third and fourth paragraphs of section 3.2.
>>
>> +1
>>
>> So under these definitions, my demonstrated implementation is 
>> conformant with the proposal, since I am not applying more than one 
>> Node ID to any single process, specifically CLA related daemons?  
>> This makes it also true that I demonstated 7 nodes, not 5. Each CLA 
>> is named with a different NodeID on the ION instance which implements 
>> UDP, LTP/UDP, and TCP simultaneously, making that 3 nodes instead of one.  Is that correct?
>>
>> ScottJ
>>
>>
>>
>>
>>>
>>> Scott
>>>
>>> -----Original Message-----
>>> From: Rick Taylor <[e-mail]>
>>> Sent: Thursday, November 10, 2022 7:56 AM
>>> To: [e-mail]; [e-mail]; 
>>> [e-mail]
>>> Cc: [e-mail]; [e-mail]
>>> Subject: Re: [dtn] [EXT] I-D Action: 
>>> draft-ietf-dtn-ipn-update-00.txt
>>>
>>> Hi Scott,
>>>
>>> That wasn't my reading, but I am often wrong.  Do you have a 
>>> reference to the
>> relevant section(s)?
>>>
>>> Cheers
>>>
>>> Rick
>>>
>>> On Thu, 2022-11-10 at 07:51 -0800, [e-mail] wrote:
>>>> I think RFC 9171 is fairly clear on the definitions of "node" and 
>>>> "BP agent".  BP nodes are functionally analogous to network 
>>>> interface cards; any number of BP nodes can be located on a single 
>>>> computing device (whether physical or virtual).
>>>>
>>>> Scott
>>>>
>>>> -----Original Message-----
>>>> From: dtn <[e-mail]> On Behalf Of Sipos, Brian J.
>>>> Sent: Thursday, November 10, 2022 4:30 AM
>>>> To: [e-mail]
>>>> Cc: [e-mail]; [e-mail]
>>>> Subject: Re: [dtn] [EXT] I-D Action: 
>>>> draft-ietf-dtn-ipn-update-00.txt
>>>>
>>>> Scott,
>>>> I do look forward to seeing more detail about use cases involving a 
>>>> node with multiple IPN node numbers.
>>>>
>>>> I wonder though if this is a terminology difference/confusion 
>>>> similar to how
>>>> IPv4 assigned addresses to a "host" while IPv6 assigns addresses to 
>>>> an "interface" with a host being allowed to have any number of 
>>>> interfaces. >From my current reading along with this proposed 
>>>> additional constraint, each BP Agent (BPA) instance is a "node" 
>>>> with a single node number but there could be a larger entity where 
>>>> BPA instances can share storage and routing logic to provide 
>>>> bridges between those BPAs. Or maybe there needs to be 
>>>> clarification on the difference (if there is one) between a "BP 
>>>> Agent" (with a single allowed IPN node number and single 
>>>> administrative endpoint) and a "BP Node" as something else possibly larger in scope.
>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] <[e-mail]>
>>>>> Sent: Wednesday, November 9, 2022 6:32 PM
>>>>> To: Sipos, Brian J. <[e-mail]>
>>>>> Cc: [e-mail]; [e-mail]
>>>>> Subject: Re: [dtn] [EXT] I-D Action: draft-ietf-dtn-ipn-update- 
>>>>> 00.txt
>>>>>
>>>>> APL external email warning: Verify sender [e-mail] 
>>>>> before clicking links or attachments
>>>>>
>>>>> Hi Brian,
>>>>>
>>>>> On Wed, 9 Nov 2022, Sipos, Brian J. wrote:
>>>>>
>>>>>> Rick,
>>>>>> I think this kind of new constraint on EID locality is very
>>>>>> helpful:
>>>>>>> All 'ipn' scheme URIs for endpoints co-located on a single 
>>>>>>> bundle processing node MUST share the same value for the 
>>>>>>> node-nbr component.
>>>>>
>>>>> I have to disagree.  This severely limits useful, already deployed 
>>>>> functionality, as you will see in the wg meeting, and will limit 
>>>>> the ability to implement sensible routing practices.  The proposal 
>>>>> turns every node into an end-user host.
>>>>>
>>>>> Enjoy,
>>>>> Scott
>>>>>
>>>>>
>>>>>> There are many assumptions embedded in current BP implementations 
>>>>>> which are based on "what makes sense" rather than documented an 
>>>>>> interoperable requirements.
>>>>>>
>>>>>> While that statement constrains half of the problem (a single 
>>>>>> node cannot have extra node numbers allocated) there is still a 
>>>>>> potential situation where a single "logical node" collection of 
>>>>>> EIDs with the same node-nbr is distributed over multiple 
>>>>>> entities/agents. For example Entity A is a routing node with EIDs 
>>>>>> "ipn:5.0" "ipn:5.2"
>>>>>> allocated, and Entity B is a stub node with EID "ipn:5.1"
>>>>>> allocated
>>>>>> and a forwarding route configured from Entity A. Entity A would 
>>>>>> contain the administrative endpoint and route to the outside 
>>>>>> world, and Entity B could be a very lightweight implementation 
>>>>>> that doesn't need to
>>>>> do any routing (all bundles pass through Entity A).
>>>>>> Is this an allowed behavior? Should it be?
>>>>>> It could be useful in a situation of distributed subsystems 
>>>>>> (e.g., a collection of sensors) where the whole system has a Node 
>>>>>> number allocated and each subsystem has a single EID allocated. 
>>>>>> This allows using "normal" BPA and CLA tools/protocols between 
>>>>>> the subsystems, though I suspect that most current 
>>>>>> implementations would not allow this
>>>>>> off-
>>>>> the-shelf.
>>>>>>
>>>>>> Another way of putting this similar to a behavioral requirement
>>>>>> is:
>>>>>> after a node receives a bundle destination matching its own node 
>>>>>> number, are the only two options for that node to either deliver 
>>>>>> or delete the bundle? i.e. it's prohibited from forwarding the 
>>>>>> bundle
>>>>>>
>>>>>> Thanks for the explanations,
>>>>>> Brian S.
>>>>>>
>>>>
>>>> _______________________________________________
>>>> dtn mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dtn
>>>
>>>
>>> _______________________________________________
>>> dtn mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dtn
>>>
>
>