Re: [dtn] [EXTERNAL] Re: EID encoding (Was: Re: Convergence Layer Adapter - Endpoint IDs (CLA-EID))

["Burleigh, Scott C (US 312B)" <[e-mail]>]

Lucien, I agree with Gilbert on this (the “late binding” principle refers to the binding of BP EIDs to convergence-layer endpoints; the destination EID should always be intelligible to every BP node on the end-to-end path) and also on his earlier “feature, not a bug” post.  Experimental EID schemes are fine, but if they are experimental then the corresponding experimental BP implementations can be designed to handle them.

We already have a pretty general mechanism for EIDs that are represented as strings: the “dtn” scheme.  I don’t think there’s a document anywhere that mandates any particular syntactic structure for the scheme-specific part of a dtn-scheme EID.  In BPv7 we simply encode such an EID as a 2-tuple comprising CBOR integer 1 followed by a CBOR text string, exactly as you propose for unknown/experimental.

Actually I think the CLA EID concept constitutes a more profound challenge to the DTN late binding principle: a bundle whose destination EID is coded in the CLA scheme would be bound to a particular convergence-layer endpoint at the moment of creation, and it would therefore become undeliverable if the destination node got bound to a different CL endpoint while the bundle was in transit.  This is exactly the problem that late binding was intended to address.

Put another way, doesn’t the CLA EID scheme make the user application responsible for knowing about, and selecting, convergence-layer protocol endpoints at the destination node?  I don’t know of any operational use cases where this would be helpful; can you describe some?

Scott

From: dtn <[e-mail]> On Behalf Of Clark, Gilbert J. (GRC-LCN0)
Sent: Tuesday, December 10, 2019 8:00 AM
To: Loiseau lucien <[e-mail]>
Cc: Brian Sipos <[e-mail]>; [e-mail]
Subject: Re: [dtn] [EXTERNAL] Re: EID encoding (Was: Re: Convergence Layer Adapter - Endpoint IDs (CLA-EID))

I don’t have a strong opinion for or against an IANA reservation described below.  If it would be useful, that seems fine.

However, in response to “RFC doesn’t say how to deal with a scheme that has no encoding definition”, my reading of the draft in this instance would go as follows:

Per 5.4, “Step 2: The bundle protocol agent MUST determine whether or not forwarding is contraindicated for any of the reasons listed in Figure 4.”

In Figure 4, listed under 6.1.1, reason code 5 is listed as “Destination endpoint ID unintelligible.“

As such, in the event that a destination EID is unintelligible (e.g. unknown scheme), my expectation would be that forwarding would be contraindicated and section 5.4.1 would apply.  In the event the scheme for a different EID isn’t understood, then I think it becomes an implementation question … but given that CBOR specifies the length of the field, I do not think it would have a negative impact on bundle decoding in the abstract.  As such, I think the behavior in such a case could be safely addressed as an implementation detail.

I expect someone will correct the above if / as needed, but … this is my interpretation of the current version of the draft.

-Gilbert

The views expressed in this mail reflect the opinions of the author.  They are, therefore, not intended to reflect official positions of NASA or the U.S. Government.


From: Loiseau lucien <[e-mail]<mailto:[e-mail]>>
Date: Monday, December 9, 2019 at 9:47 PM
To: "Clark, Gilbert J. (GRC-LCN0)" <[e-mail]<mailto:[e-mail]>>
Cc: Brian Sipos <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: EID encoding (Was: Re: [dtn] Convergence Layer Adapter - Endpoint IDs (CLA-EID))

Hi,

I agree that this may be beneficial for device with strong computing limitation. Still the RFC doesn't say how to deal with a scheme that has no encoding definition. Assuming that because this node doesn't know such definition it should drop this bundle would go against the late binding principle (maybe this scheme is only relevant once it has reached a certain region).

If we don't want to have string representation for EID, maybe we could reserve an IANA number for unknown or experimental EID scheme (say 254). In that case, encoding of an unknown EID would be the 2-tuples consisting of cbor integer 254 followed by a cbor text string representation of the entire EID (scheme included otherwise this information is lost). Node unwilling to perform string processing would simply drop or forward blindly this bundle to a more capable node.

What do you think?

On Mon, Dec 9, 2019 at 4:51 PM Clark, Gilbert J. (GRC-LCN0) <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

Extracting a very small piece of this text for additional conversation and transplanting into a new thread here…

So we would have to wait for IANA to approve the scheme and then update the code in all of bundle node, seems like a lot of unnecessary bureaucracy, why not just a string for encoding EIDs?

The benefit of encoding this way is that it avoids string processing in the general case.  I personally see this as a feature, not a bug.

Cheers,
Gilbert

The views expressed in this mail reflect the opinions of the author.  They are, therefore, not intended to reflect official positions of NASA or the U.S. Government.



--
Lucien Loiseau