Difference between revisions of "Technical topic: Hints to model complex packet encodings with ASN.1 and ACN"

From TASTE
Jump to: navigation, search
(Created page with " == Context: The Packet Utilization Standard (aka PUS-C) == ASN.1 is providing simple contructs to define data types which are independent from implementation languages. ASN....")
 
(Context: The Packet Utilization Standard (aka PUS-C))
Line 1: Line 1:
  
== Context: The Packet Utilization Standard (aka PUS-C) ==
+
== Context: Legacy Binary Encodings ==
  
 
ASN.1 is providing simple contructs to define data types which are independent from implementation languages. ASN.1 helps focusing on your ''application semantics'' rather than on how data will eventually be physically represented in memory, for example for network transmission.
 
ASN.1 is providing simple contructs to define data types which are independent from implementation languages. ASN.1 helps focusing on your ''application semantics'' rather than on how data will eventually be physically represented in memory, for example for network transmission.

Revision as of 10:59, 8 June 2018

Context: Legacy Binary Encodings

ASN.1 is providing simple contructs to define data types which are independent from implementation languages. ASN.1 helps focusing on your application semantics rather than on how data will eventually be physically represented in memory, for example for network transmission.

This is essential in any kind of distributed systems and embedded systems in general. When you want to send a meaningful set of data over a physical link, you can never count on how your local machine will store it. For example, if you use a type named "t_int16" in your code, you can never be sure that is you memory-dump it and send it as-is to a remote node that it will be properly decoded. Why? Because some machine would store the first byte first followed by the other one, while other would do the opposite. This is one example (endianness), but there are many others.

In some situations (actually, most of the time), you need to comply to some pre-established encoding rules, that are explicitly telling you, for a given protocol, how each packet shall be encoded.

ASN.1 is widely used and is very popular also because it provided built-in standard encoding rules that range from compact binary encoding (uPER, standing for unaligned Packed Encoding Rules) to XML encodings. Many telecommunication protocols are using these encoding rules. They allow users to rely on existing tools - you provide your ASN.1 grammar, and the tools provide encoders and decoders following the standard, therefore ensuring inter-operability.

However sometimes this is not sufficient... Some communication protocols (too many...) come with custom, proprietary encoding rules that are incompatible with any existing standard. In those situations, the usual approach consists in hand-writing binary encoding/decoding functions. ASN.1 may look far less relevant in that case, as automation can hardly be achieved...

Well, this is not exactly true. ASN.1 has two options to deal with that family of problems (legacy encodings). The ECN language (for Encoding Control Notation is a full-blown ISO standard that allows to formally describe custom encoding rules. It is powerful, but also extremely complex. ACN, on the other hand, is a light, free and open-source language that was developed to cover the same need but in a usable way (simple syntax, very close to ASN.1).