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

[Loiseau lucien <[e-mail]>]

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]> 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
>
> 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
>
>
>
> ------------------------------
> *From:* dtn <[e-mail]> on behalf of Loiseau lucien <
> [e-mail]>
> *Sent:* Monday, December 2, 2019 03:59
> *To:* [e-mail] <[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