Subject: [Anima] anima/signaling: FYI: CBOR as a generic TLV format

From: Toerless Eckert <[email-masked]>
Date: Sun, 19 Jul 2015 22:52:10 -0700

In the anima signaling team, we discussed whetherhow to use generic/extensible
encoding like JSOB/CBOR. I mentioned that this is also going to be proposed
by Joe Hildebrand in the "Routing Area Open Meeting" (rtgarea), Tue 15:20 - 17:20
slot, so if you're interested in this subjet, it might be useful to attend
that slot.

Brians current analysis seems to indicate a good set of open questions against
the approach:

  -> Schema definition & parsing, for ease of programming. Whats available, best practices
  -> Efficient encoding of important data types, eg: IPv6 addresses ( > 64 bit)

Cheers
    Toerless

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Jul 2015 08:48:33 +0200

Obviously, many people experienced with CBOR will be in the CoRE meeting
at the same time the RTGAREA meeting happens.

I'm not sure that we want to go into a "Schema language" rathole, but an
ABNF-like data definition language for CBOR is available in the CBOR
Data Definition Language (CDDL).
https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl

There are many ways to map information into the extended JSON data model
that CBOR uses.  In general, if there is no better way to keep
something, use byte strings.  This would apply to IPv4 or IPv6
addresses.  Prefixes would be a pair (two-element array) of a prefix
length and a byte array for the bits.

Certainly, the body of best practices in encoding protocol information
in the CBOR data model is still growing.  But apart from us people with
gray hair having to learn something new, there is no big obstacle in the
way.

Grüße, Carsten

Toerless Eckert wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Jul 2015 18:59:26 +1200

I spent a little time looking at the CDDL draft and it certainly has
potential (as well as one or two issues IMHO). But it isn't quite obvious
from the draft whether I can use CDDL to *specify* PDUs intended to be
transmitted in CBOR format, and to automate their mapping into an OO
language, or into JSON objects.

Regards
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 20 Jul 2015 00:23:52 -0700

Carsten/*:

  If we encode types as strings and IPv4/IPv6 addresses as strings as well,
  we do end up with this ~5 times as many bits as with a traditional binary
  TLV format. (Brian guesses 10 times ;-)

  In conclusion, i think we would also need to have a transport without
  packet size limits. So let's assume we require stream transport (TCP/SCP/...).

  I would love this. It ends up 5 times bitrate, X more CPU for encoding/decoding
  values (string <-> data object like addresses) and reliable transport proto
  work.

  Question: what is the scope of devices that we would exclude from being able
  to deal with these expectations ? Obviously we would exclude devices that
  MUST use CoAP because of resource constraints, right ?

  If we can conclude that the devices that would be excluded are anyhow not
  capable to support the other requirements as raised today against an autonomic
  node, then i think we are fine with a choice like this.

  Personally i think this design should fit. "Full" autonomic nodes shouldn't
  have a problem, i can see them being anything as small as gateways in an IoT
  scenario, while "constraiend AN nodes" would then be anything arbitrarily smaller,
  and we could try to design how to expand AN into them separately as a next step,
  eg: via subsets of what we'd do for full AN nodes and potentially with additional
  work such as the need to use more efficient encoding - eg: via ASA operating
  on the AN nodes that act as gateways.

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Jul 2015 09:41:31 +0200

>   If we encode types as strings and IPv4/IPv6 addresses as strings as well,

I'm sorry, I was talking about byte strings, not text strings.

I have two IP addresses right now.  One is:

2001:67c:370:152:fd2d:3b45:57e9:f827

Encoded in CBOR:

50                                  # bytes(16)
   2001067c03700152fd2d3b4557e9f827 # "
\x01\x06|\x03p\x01R\xFD-;EW\xE9\xF8'"

Represented in "diagnostic notation"
(https://tools.ietf.org/html/rfc7049#section-6)

h'2001067c03700152fd2d3b4557e9f827'

The other one is:

31.133.152.125

44          # bytes(4)
   1f85987d # "\x1F\x85\x98}"

h'1f85987d'

(I used http://cbor.me to translate between diagnostic and bytes.)

Similarly, map keys (see the discussion in
https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-06#section-2
for some of the relevant terms here) are best encoded as integers,
unless there is a need for a wide open process of assigning them (then
you'd use text strings, but could still mix in integers for the frequent
ones).

Using CBOR and then using text strings for everything wouldn't use its
full capabilities (you might as well use JSON).  CBOR was designed to
work on constrained nodes (class 1 as per RFC 7228), which typically
have even more stringent size restrictions than the nodes considered in
this WG.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Jul 2015 20:19:52 +1200

Yes, the CBOR disgnostic h format is economical; the problem is much worse
in JSON. Carsten, we would love to discuss this further; we actually need
a JSON/CBOR expert on our design team, since the WG just encouraged us to
fully investigate an OO re-design of our protocol.

Regards
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 20 Jul 2015 02:12:16 -0700

Thanks

So this also has me wondering more about the tool chain to write in source
code readable IP/IPv6 addresses and encode as you propose in CBOR.

But i would nevertheless claim that i don't like 1500 byte restricted
design spaces, so the discussion a about the size/performance of devices
we'd exclude by manadating/selectng that is important nevertheless.

Cheers
    Toerless

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Jul 2015 11:30:16 +0200

> code readable IP/IPv6 addresses and encode as you propose in CBOR.

Use getaddrinfo to translate the IPv6 address from string to the 16-byte
binary.
Use a CBOR library to encode the 16-byte string, or hand-code like

uint8_t cbor[17] = {0x50};
memcpy(cbor+1, ipv6, 16);

(General observation from the world of TLV coders:
Don't do the latter, unless you have a superb mastery of static analysis
tools.)

Grüße, Carsten