search

nasa-jpl / ION-DTN

NASA Open Source ION Software implementation of Delay Tolerant Networking. ION development is managed by the Jet Propulsion Lab; regression testing and code management are provided by Ohio University.
https://nasa-jpl.github.io/ION-DTN/
Other
22 stars 5 forks source link

SF: C: Creation of Previous Node ext. block in starting (source) node #29

Closed iondev33 closed 3 months ago

iondev33 commented 9 months ago

Hi, I am Cheol H. Koo from Korea Aerospace Research Institute. I found ION BPv7 engine in a IPN node creates a Previous Node when the node is the source node, i.e., the bundle starts from this node in first.

RFC-9171 says as "4.4.1. Previous Node The Previous Node Block, block type 6, identifies the node that forwarded this bundle to the local node (i.e., to the node at which the bundle currently resides); its block-type-specific data is the node ID of that forwarder node. That node ID SHALL conform to Section 4.2.5.2. If the local node is the source of the bundle, then the bundle MUST NOT contain any Previous Node Block. Otherwise, the bundle contain one (1) occurrence of this type of block and MUST NOT contain more than one."

So, I think when a IPN node is the source node, the IPN node is NOT supposed to create the Previous Node extension block. But, it seems ION BPv7 engine creates the Previous Node during creation of the starting bundle.

------ comment Jay When ION source a bundle in storage, it does not contain a previous node block when in storage.

If ION source a bundle and it is forwarded externally, it appends a previous node block by the convergence layer so the receiving node, the local node that stores the bundle, can identify the node that forwards the bundle to it.

------ comment Cheol Thanks for the explanation about how ION works with insertion of a previous node.

I issued this because insertion of a previous node at the starting node, i.e. the first node forwarding a bundle, is NOT expected as RFC-9171 describes at 4.4.1. Previous Node (see my initial comment above). Hope this helps if you want my clarification to my comment.

------ comment Jay Hi Cheol, this is Jay (not logged in right now). I think I understand your point. I think we have different interpretations of the same language.

Say node A created a bundle and send to node B. I believe the spec is saying that while the bundle is stored (resides) in node A, it should not have a previous node block because the bundle is residing in its source node. This is perfectly reasonable because the bundle is not being transmitted and if it is consumed locally, then there is no previous node anyways.

I don't see the spec saying we cannot add a previous node block while transmitting to external node B because the intent of the previous node block is to identify, once the bundle arrives at B, which node forwarded the bundle.

But I can also perfectly understand how you read the spec from the same language. Personally I don't have strong preference with either way.

So a more practical question is to identify a driving rationale that requires the first hop transmission NOT to include the previous node block. Is there a reason that the first hop neighbor should not have a previous node block that identifies the source that forward the bundle to it?

type6six commented 3 months ago

I am closing this ticket for now. Change can be made for 4.1.4 or later if necessary.