Method for transferring information

ES 2 293 680 T3

DESCRIPTION

Procedure for transmitting information.

The present invention refers to a procedure for the transmission of information, the configuration of which is defined by the formal language for defining data structures designated by as syntax notation one (ASN.1).

Reference is made to the following bibliography:

<td>[NMFTR107]</td><td>Network Management Forum Forum TR107: ISO / CCITT and Internet Management: Coexistence and Interworking Strategy Issue 1.0 September 1992</td>

<td>[M.3010]</td><td>ITU-T Recommendation M.3010 Maintenance: Telecommunications Management Network Principles for a Telecommunications Management Network 10/92</td>

<td>[X.160]</td><td>ITU-T Recommendation X.160 Data Networks and Open System Communications Public Data Networks Maintenance Architecture for Customer Network Management Service for Public Data Networks 7/94</td>

<td>[X.200]</td><td>Data Networks and open system communications Open System Interconnection - Model and Notation Information Technology - Open System Interconnection Basic Reference Model Geneva, 1994</td>

<td>[X.208]</td><td>ITU-T Recommendation X.208 Specification of abstract syntax notation one (ASN.1) Information technology Open System Interconnection 1988</td>

ES 2 293 680 T3

<td>[X.209]</td><td>ITU-T Recommendation X.209 Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)</td>

<td>[X.710]</td><td>ITU-T Recommendation X.710 Data Communication Networks Open Systems Interconnection Common Management Information Service Definition for CCITT Applications Geneva, 1991</td>

<td>[X.711]</td><td>ITU-T Recommendation X.711 Data Communication Networks Open Systems Interconnection Common Management Information Protocol Specification for CCITT Applications Geneva, 1991</td>

<td>[X.722]</td><td>ITU-T Recommendation X.722 Data Communication Networks Open Systems Interconnection Structure of Management Information Guidelines for the Definition of Managed Objects Geneva, 1992</td>

<td>[RFC1157]</td><td>Network Working Group RFC 1157 Simple Network Management Protocol (SNMP)</td>

<td>[RFC1085]</td><td>Network Working Group RFC 1085 ISO Presentation Services on top of TCP / IPbased internets M. Rose, Performance Systems International K. McCloghrie, Hughes LAN Systems December 1988</td>

ES 2 293 680 T3

<td>[RFC1189]</td><td>Network Working Group RFC 1189 Common Management Information Services and Protocols for the Internet (CMOT and CMIP). US Warrier, L. Besaw, L. LaBarre, BD Handspicker. historic protocol, not recommended status Oct-01-1990.</td>

<td>[RFC1214]</td><td>Network Working Group RFC 1214 OSI Internet Management: Management Information Base L. Labarre historic protocol, not recommended status April 1991</td>

<td>[RFC0793]</td><td>Network Working Group RFC 0793 Transmission Control Protocol J. Postel. September 1981 OSI Abstract-Data Manipulation API (XOM) CAE Specification Issue 3 X / Open Company Ltd</td>

<td>ISBN</td><td> 1 85912 175 6</td>

On the other hand, the following abbreviations are used:

<td>ASN.1</td><td>Abstract Syntax Notation One [X.208]</td>

<td>BER</td><td>Basic Encoding Rules [X.209]</td>

<td>CMIP</td><td>Common Management Information Protocol [X.711]</td>

<td>CMIPDU</td><td>Common Management Information Protocol Data Unit [X.711]</td>

<td>CMIS</td><td>Common Management Information Service [X.710]</td>

<td>CNM</td><td>Customer Management Network [X.160]</td>

<td>DCF</td><td>Data Communication Function</td>

<td>DCN</td><td>Data Communication Network</td>

<td>GDMO</td><td>Guidelines for the Definition of Managed Objects [X.722]</td>

<td>OR IF</td><td>Open System Interconnection [X.200]</td>

<td>SNMP</td><td>Simple Network Management Protocol [RFC1157]</td>

ES 2 293 680 T3

TCP / IP

TMN

XOM

Transmission Control Protocol / Internet Protocol [RFC0793]

Telecommunication Management Network [M.3010]

X-OPEN, Interface for handling ASN.1

The “Abstract Syntax Notation 1 (ASN.1) [X.208] is used for the formal specification of data types. It is used, among other things, to define, independently of platforms, the various services and OSI-7 layer model protocols (“Open System Interconnection” [X.200]). In order to transmit the stored information, whose structure is prefixed by ASN.1, there are a series of procedures such as, for example, the (BER) [X.209] (“Basic Encoding Rules” (“ Basic encoding rules ”)), for encoding ASN.1 values. The information encoded with the BER rules can subsequently be transmitted in binary form by any procedure. For this, protocols of the OSI or TCP / IP family (“Transmission Control Protocol / Internet Protocol”) are generally used.

Nowadays it is considered that the transmission of the different PDUs (“Protocol Data Units”) defined in ASN.1 of layer 7 of the OSI-7 layer model by means of a protocol stack purely based on the OSI model is too expensive. As a result, the use of such protocols is often abandoned, or the lower layers of the OSI protocol stack are replaced by an existing TCP / IP protocol. The protocol (CMOT) [RFC1189] (“CMIP over TCP / IP”) is mentioned as an example of a group of these procedures.

The object of the present invention is to avoid these drawbacks of the binary transmission of information whose structure is prefixed by the ASN.1 notation.

This object is achieved, according to the invention, by encoded transmission in the form of text. Preferably, provision is made for this to carry out a plaintext encoding whose encoded content is readable without auxiliary means.

The advantages of the method according to the invention lie in that, basically, text-oriented transmission protocols are generally very widespread and are therefore cheaper than binary transmission methods. In addition, finding errors is much easier with clear text encoding, so the running costs of a given application are significantly lower. Specifically, it has the following advantages:

- Thanks to the wide diffusion of text-oriented transmission protocols such as, for example, e-mail, the number of computers that can be reached with this protocol is considerably higher than in the case of transmission procedures binaries.

- Often, the so-called firewalls (Firewalls) that delimit an internal network of a company are only open to text-oriented transmission protocols.

- No additional tools are necessary to search for errors in the encoded ASN.1 information, since the encoding has a form that a person can read.

- Thanks to the use of very simple protocols, it is not necessary to have a high computing power, so that simple personal computers are also suitable for this purpose.

- The transmitting and receiving equipment does not need to contain complex protocol stacks. Many operating systems already contain the necessary software for text-oriented transmission procedures.

Contrary to encoding with BER rules, with the method according to the invention, it is possible to decode the received data without having to resort to an internal reference of the ASN.1 definition.

A particularly advantageous refinement of the method according to the invention is to transmit for each information sent the corresponding type of data defined according to ASN.1, so that, preferably, the designation is provided before the information and separated from it by means of a separator character, especially an equal sign.

This improvement makes it possible to use the method according to the invention in a particularly advantageous way for the user, since the information encoded as text can be represented by means of commonly available output equipment. It is also easy for the user to enter data and permanently store the encoded information as text.

In the future, the CMIP protocol [X.711] will be used mainly for the management of public telecommunications networks, hereinafter also called networks. In this context, telecommunications networks can be networks for the transmission of voice, data and images. The configuration of the CMIPDU units (“Common Management Infor

ES 2 293 680 T3 mation Protocol Data Unit ") has been formally defined by ASN.1. The management information transmitted via the CMIPDUs is encoded according to the basic encoding rules. In particular, for long distances or in case of high quality requirements, the advantages of an OSI protocol stack for the transmission of management information based on the CMIP protocol cannot be dispensed with. On the other hand, there are application purposes in which, for the transmission of management information, a simpler and cheaper solution is sufficient. In addition to the use of CMIP over SNMP (“Simple Network Management Protocol”) widely used in local networks, another possibility currently used is the transmission of CMIP through TCP / IP, which is simpler than the OSI protocols of the lower protocol layers.

In another refinement of the method, according to the invention, it is therefore provided that the information to be transmitted via the CMIP relates to the management of public telecommunications networks. In this refinement, it is ultimately irrelevant that the plaintext encoding employed is based on the CMIP being defined in ASN.1 or that the text-oriented encoding rules have been developed independently.

In addition to the above-listed advantages of the method according to the invention, this improvement, that is to say, the text-oriented transmission of the CMIP, makes it possible to use the CMIP also in cases where, for reasons of economy, it would not be logical to use an expensive transmission using an OSI protocol stack.

In the future, public network operators will make a management interface available to their customers, through which customers will be able to carry out management operations related to the part of the public network leased by them. Through this interface, all the data that clients wish to exchange with the network operator can be transmitted.

An example of this is the request for a fixed line between sites A and B of a customer's own network. The two sites have to be connected to each other via the public network. To this end, in another refinement of the method, according to the invention, the transmission of information between a subscriber and a public network or its management systems has been provided, and that said information refers to a network management to be carried out by the subscriber.

In particular, the invention can be configured such that an e-mail interface is established for the information encoded as text. Through this refinement, customers are offered an inexpensive but secure interface to the network operator. In this case, it is not necessary to give up the advantages of CMIP as a management protocol.

Through this interface between the customer's own management system and the network operator's management system, the customer can perform management operations not only limited to its own local network, but also for the part of the public network that it uses. . This is designated as CNM (“Customer Network Management”). A typical application of this is, for example, custom network settings for the customer. Among the elements of the network management by the customer are also the immediate notification of detected errors and the making available of certain statistical data.

Another configuration of the invention provides for the use of character tables for the encoding and decoding of the information, whereby the method can be adapted in a simple and flexible way to the limited number of characters of the transmission system. For example, when a transmission protocol cannot transmit the characters "{" and "}", they can be replaced by another specific character, without having to make a fundamental modification of the encoding rules. In this way and without additional technical cost, by using different character tables in parallel, it is possible to support, within the same application, several transmission media having different character sets.

Another improvement of the method, according to the invention, lies in the fact that the coding and sending of management information, as well as the reception and decoding thereof, are carried out automatically.

In the area of ​​the network provider, automatic conversion from text-oriented transmission to an OSI protocol stack is possible at any time. The advantage of this architecture is that it does not require each client to manage their own OSI stack, but the network provider offers this service centrally to all clients.

Exemplary embodiments of the invention are represented in the drawings by various figures, and are explained in more detail in the following description:

- Figure 1 shows a first example of an installation to carry out the procedure, according to the invention,

- Figure 2 shows a second embodiment, also in the form of a block diagram,

- Figure 3 schematically shows the management of a part of a public telecommunications network used by a subscriber, and

ES 2 293 680 T3

Figure 4 schematically shows a text-oriented transmission of management information, based on the CMIP protocol, between a CNM client and a network operator.

In the exemplary embodiment according to FIG. 1, two management systems (1) and (2) have been connected to each other to exchange information by means of a text-oriented transmission system (3). The user information to be transmitted can be present within the sending and receiving application (4), (5) of the management systems (1), (2) in different formats of their own. The configuration of these data formats is determined by the tools that are used during the creation of the applications. This user information is encoded and decoded according to ASN.1 and, additionally, according to the method, according to the invention, at points (6), (7).

Figure 2 shows a possible embodiment of the architecture represented in figure 1. From the data structures "C" present at point (13) of a first management system (11), information is transmitted to the management system (12 ), where it is saved in point (18) as a “C / C ++” data class.

The information present in (13) is first led to an XOM interface (14) (“X-OPEN, Interface for handling ASN.1”) where it is encoded as a XOM object to be able to be handled in accordance with ASN.1. These objects are then converted by the method according to the invention into text-oriented transmission protocols, which are transmitted as electronic mail (19) and received by the management system (12). Here, at point (16) they are decoded and converted to "C ++" objects, and later, at point (18) they are saved as "C / C ++" data classes.

Figure 3 shows a case of a request from a customer to the operator of a public network to connect two sites "A" and "B" with a fixed line. For this, the client sends the corresponding request (24) to the management system (22) of the network operator through its management system (21) at location "A". The latter checks if the request can be carried out in the home network and relays (25) the request to the management system (23) of the customer's site "B". As soon as the message (26) arrives that the corresponding part of the fixed line has been established successfully, the connection is made in the public network and the result "Line established" is communicated (27) to location "A".

Figure 4 explains the text-oriented transmission of CMIP-based management information between a CNM client and the network operator. Both the management system (21) of site "A" and the management system (23) of site "B" of the client are connected to the management system (22) of the network operator "N" through the corresponding interfaces CNM (36), (37) through which information encoded as clear text is transmitted according to the procedure, according to the invention.

The client's management systems (21), (23) have access, respectively, to the client's network elements (34), (35). This is done, for example, at site "A" via CMIP over TCP / IP, while at site "B" the SNMP protocol is used. The management system (22) of the network operator "N", whose domain is bounded in Figure 4 by dashed lines, has access to the elements (31) to (33) of the public network. This is done using CMIP with a 7-layer OSI protocol stack.

The network operator "N" offers the client a CNM service, with which the client can use its own management application, or made available by the network operator, to relay its management requests to the management system ( 22) from the public network. The management information to be transmitted is automatically encoded by the client as clear text within its management application, and transmitted to the network operator's management system (22) by means of a text-oriented protocol. This message is received directly by the network operator's management system (22), or by the provider's CNM services, and is directly reprocessed or converted into (36) and (37) in an OSI protocol stack and in an OSI base transmission to the network operator's management system.

With the method according to the invention, the transmission of management information to the management systems (21), (23) of the client can also be advantageously carried out. For this, the network operator "N" automatically relays an encoded message in text form to the client. The CNM customer management application automatically receives and decodes this text message to retransmit the transmitted management information.

The ASN.1 encoding, according to the invention, is carried out following a fixed procedure. Basically, for each type of ASN.1 the tag is first encoded in the form of a name properly aligned to the ASN.1 standard (for example, "INTEGER" encoded for "Universal Tag 2"), then inserting an "=" sign as a separator element. The default mode value for that type is then encoded. In case an ASN.1 data type is itself composed of other data types, when the values ​​are encoded the labels and values ​​of the data types present are also encoded.

Two variants are defined for the encoding rules, both being the object of the present invention. The standard variant is entirely sufficient for the encoding of the ASN.1 version and is correspondingly easy to implement. In the second variant, additional information taken from the ASN.1 notation type definition is added to the code text. In this way, the search for errors is much easier than in the standard variant of encoding as clear text and also when compared to the binary form of encoding. However, the use of the extended variant increases the cost of performing the application development. Therefore, it is also permissible

ES 2 293 680 T3 use only some elements of the extended coding, as long as this is done consistently at the sender and at the receiver. In the following, in cases where the extended variant is envisaged for encoding a special data type, this is explained for the data types in question.

The following sections indicate the ASN.1 definition corresponding to the description of the encoding rules for each data type, and present one or more encoding examples.

BOOLEAN

The encoding of a "BOOLEAN" data type (Boolean) is done by encoding the text "BOOLEAN" for the type and, optionally, the texts "TRUE #" or "FALSE #":

Definition ASN.1 Encoding (various examples)

Bowl :: = BOOLEAN BOOLEAN = TRUE #

BOOLEAN = FALSE #

INTEGER

An integer value is designated by the text "INTEGER", and the corresponding value is encoded in the format of a decimal number. It is only necessary to prepend a sign for negative numbers. The value encoding ends with a "#" sign.

Definition ASN.1 Encoding (various examples)

Int :: = INTEGER INTEGER = 123 #

INTEGER = -123 #

BIT STRING

A “Bit String” is encoded with the text “BIT STRING”. The encoding of the value is carried out with a binary sequence framed with the signs "{}" and marked by preceding a "B" as a binary signal and the number of elements encoded. Correspondingly, a hexadecimal rather than binary encoding is marked with an "H". In case the number of bits is not an integer multiple of four, the undefined low value bits (they are on the right) are encoded with the binary value "0". According to the ASN.1 definition, both in binary and hexadecimal encoding it is possible to dispense with the elements that are at the end of the encoding, if they are encoded with the value "0".

In extended coding, a list is made of the designators of the elements whose binary value corresponds to a "1". The beginning of the list is marked with the sign "{" and the end with the sign "}". Within this list, a “/” sign is used as a separator element.

Definition ASN.1 Encoding (various variants)

<td>BitStr :: = BIT STRINGf</td><td>BIT</td><td>STRING = B5 {01100</td>

<td>ele (0),</td><td>BIT</td><td>STRING = B3 {011}</td>

<td>ele (l),</td><td>BIT</td><td>STRING = H2 {70}</td>

<td>ele (2),</td><td>BIT</td><td>STRING = H1 {7}</td>

<td>ele (3),</td><td></td><td></td>

ele (4)} Extended coding:

BIT STRING = {ele (1) / ele (2)}

BIT STRING = B5 {00000}

BIT STRING = Bl {0}

BIT STRING = Hl {0}

Extended coding:

BIT STRING = {}

ES 2 293 680 T3

OCTET STRING

An "Octet String" is encoded with the text "OCTET STRING". The encoding of the value is carried out by means of a binary list framed by the signs "{}" and marked by preceding a "B" as a binary signal and the number of elements encoded. Optionally, a correspondingly marked hexadecimal encoding with an "H" can also be used. A "/" sign is used as a separator between the individual values ​​of the octet.

Definition ASN.l Coding

OctStr :: = OCTET STRING OCTET STRING =

B2 {11100001/11111111}

OCTET STRING = H2 {El / FF}

Null

The encoding of the ASN.1 data type “NULL” (“Zero”) is done using the text “NULL = NULL #”.

Definition ASN.l Coding

Null = NULL NULL = NULL #

OBJECT IDENTIFIER

The ASN.1 “Object Identifier” data type is encoded with the text “OBJECT IDENTIFIER”. The value is encoded by prepending the text "NUMERIC", making a list of the order numbers of the nodes in the registry tree, starting with the root element, until reaching the registered element. All numeric values ​​in this list are separated by periods. The value encoding ends with a "#" sign.

In the extended encoding characterized with the text “Symbolic” a unique mnemonic descriptor is used instead of the uninformative digit sequence. To do this, a unique correlation table must logically be established between the designator and the "Object Identifier". The use of a combination of mnemonic designators and digit sequences is not permitted. Encoding is terminated with a "#" sign.

Definition ASN.l Coding

Obj :: = OBJECT IDENTIFIER OBJECT IDENTIFIER = Numeric, 1.2.2.1.4 #

Extended coding

OBJECT IDENTIFIER = Symbolic, systemld #

EXTERNAL

The label of the “External” data type is encoded with the text “EXTERNAL”. The encoding of the value of this data type comes from the encoding rules of the following “SEQUENCE”:

{

Direct-reference OBJECT IDENTIFIER OPTIONAL, indirect-reference INTEGER OPTIONAL, data-value-descriptor ObjectDescriptor OPTIONAL, encoding CHOICE

<td> {</td><td>single-ASNl-type</td><td> [0]</td><td>IMPLICIT</td><td>ANY,</td>

<td></td><td>octet-aligned</td><td>[OR</td><td>| IMPLICIT</td><td>OCTET STRING,</td>

<td> }</td><td>arbitrary</td><td> [2(</td><td>| IMPLICIT</td><td>BIT STRING</td>

ES 2 293 680 T3

REAL

Numbers in “Real” format are encoded with scientific notation. The value encoding ends with a "#" sign.

Definition ASN.l Coding

Real :: = REAL REAL = 1.23E45 #

ENUMERATED

The label of an “Enumerated” type is encoded with the text “ENUMERATED”. The encoding of the value is done by indicating the integer linked to the element. The value encoding ends with a "#" sign. In extended encoding, the element is encoded identically to its definition text.

Definition ASN.l

Enum :: = ENUMERATED {a (0), b (1), c (2)}

Coding

ENUMERATED = 1 #

Extended coding:

ENUMERATED = b (1) #

SEQUENCE

The tag of a "SEQUENCE" is encoded by the text "SEQUENCE". The encoding of the value of a sequence begins with the number of elements followed by a sign "{" and ends with a sign "}". In the subsequent specification of the value encoding, a differentiation must be made between two types of sequence:

In the single sequence, the ASN.1 types present in the sequence are encoded in their order of appearance in the definition. To do this, each position number is separated from the rest by a leading comma. As a separating element between these types, a “/” sign is inserted in each case. Unused optional elements of the sequence are simply omitted from the encoding, so that in such cases the “/” sign is not encoded either.

Definition ASN.l

Seq :: = SEQUENCE {a INTEGER, b BOOLEAN OPTIONAL, c INTEGER}

Coding (various examples)

SEQUENCE = # / 2 {1, INTEGER = 123

3, INTEGER = 456 #}

SEQUENCE = 3 {1, INTEGER = l # / 2,

BOOLEAN = FALSE # / 3,

INTEGER = 3 #}

The value of a sequence is defined by coding with the corresponding frequency the type of data with prepended position numbers and separated from each other by a "/" sign.

Definition ASN.l Encoding (various examples)

Seq :: = SEQUENCE OF INTEGER SEQUENCE F = 3 {1, INTEGER = 1 # /

2, INTEGER = 2 # / 3, INTEGER = 3 #} SEQUENCE = O {}

ES 2 293 680 T3

SET

The label of the “Set” type is encoded by the text “SET”. The encoding of the value begins with the number of elements encoded followed by a “{” sign and ends with a “}” sign. In the subsequent specification of the value encoding, a differentiation must be made between two types of "Set" data:

In the simple "Set" type, the ASN.1 types present in the definition are encoded in their order of appearance in the definition. To do this, each position number is separated by a comma. As a separating element between these types, a “/” sign is inserted in each case. Unused optional elements of the sequence are simply omitted from the encoding, so that in such cases the “/” sign is not encoded either.

Definition ASN.l Encoding (various examples)

Set :: = SET {SET = 2_ {1, INTEGER = 123 # /

2, BOOLEAN = TRUE #} a INTEGER, b BOOLEAN, c OBJECT IDENTIFIER optional}

The value of a "SET OF INTEGER" sequence is defined by encoding with the corresponding frequency the data type with prepended position numbers separated from each other by a "/" sign.

Definition ASN.l Encoding (various examples)

Set :: = SET OF INTEGER SET = 3 {1, INTEGER = 1 # /

2, INTEGER = 2 # / 3, INTEGER = 3 #}

SET = {}

Character Strings

The encoding of the various types of "Strings" and the subtypes derived from them is always the same. The type is encoded, as desired, according to the data type by the text "NumericString", "PrintableString", "TeletexString", "VideotexString", "VisibleString", "IA5String", "GraphicString", "GeneralString", "ObjectDescriptor "," UTCTime "or" GeneralizedTime ".

As long as there are no special characters or non-encodable signs, simple value encoding can be used. This encoding begins with the text "simple" and, separated by a sign "," is the number of characters present. Then follows the unencoded text itself, framed in round brackets. When it is no longer possible to encode with a simple value encoding, extended encoding preceded by "complex" is performed. Then, separated with a “,” sign, the encoding of the characters present follows followed by a “{” sign. The codes for each character are then hexadecimal encoded, separated from each other by a “/” sign. Encoding ends with a "}" sign.

Definition ASN.l Encoding (various examples)

Set :: = SET OF INTEGER SET = 3 {1, INTEGER = 1 # /

2, INTEGER = 2 # / 3, INTEGER = 3 #}

SET = {}

Str :: = GeneralString GraphicString = simple,

3 {xyz}

GeneralString = complex,

3 {78/79 / 7A}

ES 2 293 680 T3 “CHOICE”

The type “Choice” is encoded with the text “CHOICE”. The encoding of the value of a "CHOICE" is similar to that of a "Sequence" and begins with the figure "1" for the number of items encoded in this "Choice". The encoding of the present elements begins with a sign "{" and ends with a sign "}". Before encoding the type, its position is encoded by separating it with a comma.

<td>ASN.1 definition</td><td>Coding (various examples</td>

<td>Bsp :: = CHOICE {</td><td>CHOICE = 1 {2, GraphicString =</td>

simple.3 {A}

<td>typl INTEGER,</td><td>CHOICE = 1 {1, INTEGER = 123 #}</td>

typ2 GraphicString} "ANY DEFINED BY"

The type "ANY DEFINED BY" is defined with the String "ANY". The value of an “ANY” type, unlike BER encoding, is encoded as its own type. Since the type “ANY DEFINED BY” is only allowed within “SEQUENCE” or “SET”, the example presents the corresponding definition within a definition of “Sequence”. For the encoding, the text "1 {" is encoded first, and then the type expected for the types "aNy" is encoded. The definition ends with the sign "}".

Seq :: = SEQUENCE (SEQUENCE = 2 {1, INTEGER = l # / 2,

ANY = {INTEGER = 5 #}} i INTEGER;

a ANY DEFINED BY i}

In contrast to coding information models such as plaintext that can be decoded even if the information model is not known, for a BER coding it is necessary to have a reference of the information model, stored in metadata format. In order to encode the information about the metadata to be used, also in a clear text encoding, any type encoding can optionally be prepended to the metadata to be used. In this way, the metadata is only valid for that type and for the contents in it.

Definition ASN.1 Encoding (various examples)

Bsp :: = INTEGER SetMetaData = Dateiname,

INTEGER = 123 #