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

[Brian Sipos <[e-mail]>]

Lucien,
Agreed that CLA IDs are a more general topic than the IP-network-specific uses in IPND.

My reason for mentioning it was from the perspective of an IPND being able to have both: a size-optimized representation of common CLAs (for example UDP CL of RFC7122<https://www.iana.org/go/rfc7122> with IPv6 address) as well as a more generic "here is a CLA ID that this node is providing". However, I'm not sure if there is so much value in pushing up decoding/using the CLA ID to a higher layer than at the IPND layer. The CLA ID still at some point has to be decoded and used by an agent to transfer bundles.
________________________________
From: Loiseau lucien <[e-mail]>
Sent: Saturday, December 7, 2019 03:46
To: Brian Sipos <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [dtn] Convergence Layer Adapter - Endpoint IDs (CLA-EID)

Hi Brian,

thanks for pointing out the IPND draft. Though related, I believe that CLA-EID does address a slightly different issue than peer or service discovery. My proposition is a general formalization for CLA Identifiers, how it should be encoded (string, integer or both) within the context a peer discovery protocol is another issue. Also the IPND draft seems to be limited to IP discovery only where as a CLA-EID can be used to describe a Bluetooth or a USB stick interface (this is very relevant for the context of DTN use case I am working on). CLA-EID is not about how to exchange identifier information, this draft is to agree on:

  1.  how a CLA-EID should be constructed, the proposition is cla:<CLA-NAME>:<CLA-SPECIFIC-PART> and should be automatically derivable from the cla interface without any exchange of packet (because the same identifier could be used to trigger and open such interface).
  2.  what a CLA service MUST expose: an ingress and egress CLA-EID when relevant.

Only when this brick is layed can a peer discovery protocol be built upon to exchange CLA-EID identifiers like IPND, or a new draft for bluetooth peer discovery using BLE beaconing for example, or a new draft for usb stick discovery using a specific file (for example `.BPV7INFO`).

Also it may be the topic of a different thread but since you ask the question, when I developed a BPv7 implementation [1] I found the serialization of EID to be very convoluted because it makes it hard to be generic. Since the RFC states that an EID is just an URI and no other constraint are given to it, it should just be it and be serialized as a string. Right now, there is two issues with how EID are serialized:

  1.  The scheme is encoded as a number which MUST require to be registered on IANA.
  2.  The SSP is schema-specific, for instance it is a cbor string for `dtn:` and a cbor array of cbor integer for `ipn`.

The problem is that if someone come up with its own schema that isn't yet registered on IANA, those bundle would be impossible to route because impossible to serialize. In a situation where an AA receive from its API a query to send a bundle to an unknown URI scheme (so it is a string), a sane process would be to either delete it or just pass it to some other more knowledgeable node (sort of a default route) but in this case event it would be impossible to do so because it wouldn't even know how to serialize it. 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 above issue was also one of the purpose of formalizing CLA-EID, so that we can at least work generically with all CLA identifiers in a generic fashion.

[1] https://github.com/Marlinski/Terra


On Fri, Dec 6, 2019 at 9:42 PM Brian Sipos <[e-mail]<mailto:[e-mail]>> wrote:
Lucien,
I do see value in registration of CLA identifiers. One of the deficiencies I see with the IPND draft is that its notion of what is a CLA service [1] is quite ambiguous. It implies that "TCP" means "DTN TCPCL" and isn't exactly clear about what protocol version is used (all of the CLAs are cited from that draft as Informative References). It's a good notional start but I would love to take a crack at tightening up, modernizing, and security-enhancing the IPND protocol.

A question to the WG related to CLA identifiers is: do we want the CLA registry to be maintained as text (similar to the URN namespace registry) or using integer namespaces as IPND, BPv7, and BPv6/CBHE do, or as a combination of "text name" and "integer label" as COSE [2] does for its parameters.

[1] https://tools.ietf.org/html/draft-irtf-dtnrg-ipnd-03#section-2.6.3
[2] https://www.iana.org/assignments/cose/cose.xhtml#header-parameters
CBOR Object Signing and Encryption (COSE)<https://www.iana.org/assignments/cose/cose.xhtml#header-parameters>
CBOR Object Signing and Encryption (COSE) Created 2017-01-11 Last Updated 2019-08-20 Available Formats XML HTML Plain text. Registries included below. COSE Header Parameters
www.iana.org<http://www.iana.org>

CBOR Object Signing and Encryption (COSE)<https://www.iana.org/assignments/cose/>
CBOR Object Signing and Encryption (COSE) Created 2017-01-11 Last Updated 2019-08-20 Available Formats XML HTML Plain text. Registries included below. COSE Header Parameters
www.iana.org<http://www.iana.org>



________________________________
From: dtn <[e-mail]<mailto:[e-mail]>> on behalf of Loiseau lucien <[e-mail]<mailto:[e-mail]>>
Sent: Monday, December 2, 2019 03:59
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [dtn] Convergence Layer Adapter - Endpoint IDs (CLA-EID)

Hi all,

last year I wrote a draft regarding the introduction of an EID format that would be specific to convergence layer adapters that I called IID (Interface IDentier):

https://tools.ietf.org/html/draft-loiseau-dtn-cla-eid-00

The purpose was to have a generic EID format that would carry enough semantic so as to allow routing protocol and automatic connection scheduling to operate in a way that is not implementation specific. My use cases was the ability to maintain a link-local EID routing table as well as automatically initiating TCP connection for certain destination upon the reception of some bundles.

The draft expired in May but I would be happy to take your comments and submit a new one with a better wording, please have a look!

Best Regards,
Lucien Loiseau


--
--
Lucien Loiseau