You are on page 1of 42

The System Description Language (SDL) - user’s manual

version 1.30.01 - January 31, 2007

http://www.positif.org http://www.deserec.eu
The System Description Language (SDL) - user’s manual

Contents
1 Introduction 4

2 Common definitions and syntax rules 4


2.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Ethernet addr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6 IPv4 addr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.7 IPv6 addr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.8 IPv4 netmask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.9 uint8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.10 pint16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.11 pint32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.12 DateType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.13 CapabilityType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.14 AccessType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.15 DNSNameType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.16 portPosition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.17 connectorType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.18 technologyType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.19 L1type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.20 L2protoType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.21 L4proto type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.22 L7proto type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.23 OSproduct type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.24 cpuType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.25 SensitivityType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.26 ConnectionTechnologyType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.27 ByteSizeType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.28 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 The SDL Core 9


3.1 Definition of network nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 The sdl element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 The network element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3 The unknown element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.4 The other element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.5 The router element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.6 The switch3 element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.7 The switch element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.8 The hub element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.9 The bridge element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1 / 41
The System Description Language (SDL) - user’s manual

3.1.10 The repeater element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14


3.1.11 The computer element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.12 The nas element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.13 The firewall element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.14 The printer element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.15 The mobiledevice element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.16 The gateway element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.17 The networkAccessPoint element . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.18 The wirelessAccessPoint element . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Definition of other elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1 The interface element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 The address element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.3 The addr element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.4 The dnsname element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.5 The access element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.6 The os element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.7 The operatingSystem element . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.8 The connection element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.9 The localStorage element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.10 The service element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.11 The protocol element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.12 The software element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.13 The distribution element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.14 The kernel element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.15 The module element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.16 The patch element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.17 The failover element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.18 The vlan element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.19 The capability element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 The SDL Extensions 28


4.1 The sensitivities extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1 The sensitivity element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.2 A sensitivities example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 The environment extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 The power line element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.2 The contained element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.3 The area element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.4 The building element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.5 The floor element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.6 The room element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.7 The locker element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.8 An environment example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Example of a network expressed in SDL 33

2 / 41
The System Description Language (SDL) - user’s manual

6 Support tools for SDL checking and translation 35


6.1 General software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.2 Xerces2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.3 Saxon8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2 SDL checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.1 Using the checker on Windows systems . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.2 Using the checker on Unix systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3 SDL translation to SDL/CIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3.1 Using the translator on Windows systems . . . . . . . . . . . . . . . . . . . . . . . . 40
6.3.2 Using the translator on Unix systems . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 / 41
The System Description Language (SDL) - user’s manual

1 Introduction
SDL is a language defined to provide a format for description of networked ICT systems. Although SDL
attempts to be general and complete, its main purpose is to provide the data needed to perform various kind of
security analysis. For this reason some details (e.g. the MAC addresses) are optional and can be omitted if the
user creating the description thinks that they are irrelevant to the kind of analysis he wants to perform.
SDL is a user-friendly (although verbose) language, based on XML. This document provides the definition of
the language itself and gives instructions on how to use the schema checker (to verify the description correct-
ness) and the translator towards the internal format, which is based on CIM. The choice of a translation of the
SDL into CIM language was in fact made in order to adhere, at least at low level, to a well-known, standard
language. Programmer-level details about the checker, the translator and the internal format are given in a
separate document.
SDL is used to formally describe an ICT system. It can convey:

• the topology of the system, both physical (nodes and cables) and logical (such as that created by a VLAN);

• the network configuration and black-box functionality of each node (that is, the network services offered
and the applications supported);

• the security functionality of each node (that is, its capabilities, such as packet filtering, OS controls, or
application-level access controls).

2 Common definitions and syntax rules


This section explains the notation and the datatypes used in describing the SDL syntax.

2.1 Notation
The notation used in this manual to describe the SDL syntax is mostly taken from the ABNF.
The names in italic – such as Identifier or L3 interface – are either a datatype (defined in section 2) or a
generalized SDL element.
The cardinality of a syntax element is defined by the following notation:

minOcc * maxOcc

where minOcc and maxOcc are optional decimal values, used to require at least minOcc and at most maxOcc
occurrences of element. Default values are 0 and infinity so that *element allows any number, including zero,
1*element requires at least one, 3*3element allows exactly three and 1*2element allows one or two.
Optional parts are enclosed within square brackets:

[ element ]

By the way, this is equivalent to *1element.


A vertical bar sign | indicates a logical OR, that is a choice between two elements.

2.2 Comments
Comments can be inserted in any place, can span multiple rows and follow the usual XML syntax, that is a
comment is any text inserted between the <!-- and --> tags, as in the following example:

<!-- this is a comment in SDL -->

4 / 41
The System Description Language (SDL) - user’s manual

2.3 Identifier
This is a case-sensitive string of characters, to create user-defined names that identify SDL elements. Any legal
Unicode character can be used1 , with the following exceptions:

• the single-quote (’) and double-quote (”) characters cannot be used because they are XML separators for
the attribute values.

It is also forbidden to use characters like tab, carriage return, and line feed, but the space character can be used.

2.4 String
This is a string of printable Unicode characters.

2.5 Ethernet addr


This datatype represents an Ethernet media access control address (MAC address). These addresses must be
expressed in the format composed of six groups of two hexadecimal digits, separated by colons (:) or hyphens
(-), as in the following examples:

01:23:45:67:89:ab 01-23-45-67-89-ab

2.6 IPv4 addr


This is a network-layer address in version 4 of the Internet Protocol (IPv4). These addresses must be expressed
as a dotted quad of decimal numbers in the range 0. . . 255, as in 207.142.131.236.

2.7 IPv6 addr


This is a network-layer address in version 6 of the Internet Protocol (IPv6). These addresses must be expressed
as eight 4-digit (16-bit) hexadecimal numbers separated by colons, followed by a slash (/) character and a
decimal prefix length (i.e. the bit length of the subnet mask), which is a decimal integer in the range 1. . . 127
and determines the size of the network. The following is a valid IPv6 addr datum:

1080:0:0:0:0:800:0:417A/48

2.8 IPv4 netmask


This datatype represents an IPv4 netmask, also known as subnet mask or address mask. The netmask must be
expressed as a dotted quad of decimal numbers in the range 0. . . 255, as in 255.128.0.0.

2.9 uint8
This datatype represents an unsigned 8-bit integer which can take only decimal values in the range 0. . . 255.

2.10 pint16
This datatype represents a positive 16-bit integer which can take only decimal values in the range 1. . . 65535.

2.11 pint32
This datatype represents a positive 32-bit integer which can take only decimal values in the range 1. . . 4294967295.
1
However, it is suggested to use only printable characters, to avoid problems with applications that display identifiers or request
user input to identify an element.

5 / 41
The System Description Language (SDL) - user’s manual

2.12 DateType
This datatype represents a calendar date according to the ISO 8601 standard, that is in the form YYYY-MM-DD
(e.g. 2005-12-15).

2.13 CapabilityType
This datatype represents the different security capabilities available for softwares. The allowed values are:

channel protection authorization authentication


filtering operational

2.14 AccessType
This datatype enumerates the different ways available to the user to access a machine. The allowed values are:

ssh telnet http snmp human

2.15 DNSNameType
This datatype represent the human-readable address of a machine on a network, as requested to a DNS name-
server. It is expressed in the well-known hierarchical dotted notation for URL, like www.foobar.org.

2.16 portPosition
This datatype represents the position of a physical port on a network device. It is expressed in the form:

[N /M /]P

where N stands for linecard number, M stands for the slot number and P is the port number.

2.17 connectorType
This type represents the physical connector and can take only the following predefined values:

BNC DB9 RJ11 RJ45 RS232 Other Unknown

2.18 technologyType
This datatype represents the data link technology and can take only the following predefined values:

ATM BlueTooth Ethernet FC


FDDI Frame Relay IB Infrared
Other Token Ring Unknown Wireless LAN

2.19 L1type
This datatype represents physical layer details for the technology used and can take only the following prede-
fined values:

10BaseT 100BaseT 1000BaseT 10-100BaseT


802.11 802.11a 802.11b 802.11g
802.11h 802.11ab 802.11ag Other
Unknown

6 / 41
The System Description Language (SDL) - user’s manual

2.20 L2protoType
This type represents a data link protocol and it can take only the following predefined values:

Ethernet CSMA/CD HDLC Other PPP


SLIP Unknown

2.21 L4proto type


This type represents the transport protocol and can take only the following predefined values:

other tcp tcp/udp udp unknown

2.22 L7proto type


This type represents an application protocol and can take only the following IANA-assigned predefined values:

domain ftp ftps http


https kerberos imap imaps
ldap ldaps ntp pop3
pop3s printer radius radacct
rdist rsync smtp smtps
snmp socks ssh syslog
telnet telnets ftfp

2.23 OSproduct type


It represents an operating system and it takes the following predefined values:

AIX ASERIES ATTUNIX BeOS


BS2000 BSDUNIX Caldera Open UNIX DC/OS
DECNT Dedicated DGUX EPOC
FreeBSD GNU Hurd HP MPE HPUX
Inferno Interactive UNIX IRIX IxWorks
JavaVM LINUX Lynx MACH Kernel
MACOS MiNT MSDOS MVS
NCR3000 NetBSD NetWare NextStep
Not Applicable OpenBSD OpenVMS OS/2
OS/390 OS400 OS9 OSF
Other PalmPilot QNX Reliant UNIX
Rhapsody SCO OpenServer SCO UnixWare Sequent
Solaris SunOS TandemNSK TandemNT
TPF Tru64 UNIX U6000 Unknown
VM VSE VxWorks WIN3x
WIN95 WIN98 WINCE Windows Me
Windows 2000 Windows XP WINNT XENIX
z/OS

2.24 cpuType
This type represents the processor and can take only the following predefined values:

7 / 41
The System Description Language (SDL) - user’s manual

Other Unknown 8086


80286 80386 80486
8087 80287 80387
80487 Pentium brand Pentium Pro
Pentium II Pentium MMX Celeron
Pentium II Xeon Pentium III M1 Family
M2 Family K5 Family K6 Family
K6-2 K6-3 AMD Athlon Family
AMD Duron AMD29000 Family K6-2+
Power PC Family Power PC 601 Power PC 603
Power PC 603+ Power PC 604 Power PC 620
Power PC X704 Power PC 750 Alpha Family
Alpha 21064 Alpha 21066 Alpha 21164
Alpha 21164PC Alpha 21164a Alpha 21264
Alpha 21364 MIPS Family MIPS R4000
MIPS R4200 MIPS R4400 MIPS R4600
MIPS R10000 SPARC Family SuperSPARC
microSPARC II microSPARC IIep UltraSPARC
UltraSPARC II UltraSPARC IIi UltraSPARC III
UltraSPARC IIIi 68040 68xxx Family
68000 68010 68020
68030 Hobbit Family Crusoe TM5000 Family
Crusoe TM3000 Family Efficeon TM8000 Family Weitek
Itanium AMD Athlon 64 Family AMD Opteron Family
AMD Sempron Family AMD Turion 64 Mobile PA-RISC Family
PA-RISC 8500 PA-RISC 8000 PA-RISC 7300LC
PA-RISC 7200 PA-RISC 7100LC PA-RISC 7100
V30 Family Pentium III Xeon Pentium III with SpeedStep
Pentium 4 Intel Xeon AS400 Family
Intel Xeon MP AMD Athlon XP Family AMD Athlon MP Family
Intel Itanium 2 Intel Pentium M K7
S/390 and zSeries Family ESA/390 G4 ESA/390 G5
ESA/390 G6 z/Architecture base i860
i960 SH-3 SH-4
ARM StrongARM 6x86
MediaGX MII WinChip

2.25 SensitivityType
This type represents the security sensitivity characteristics of an element, and can take only the predefined
values:
confidentiality integrity availability

2.26 ConnectionTechnologyType
The ConnectionTechnologyType type defines the particular kind of technology through which transmission
signals pass. The available values are:
Unknown Other Cat1 Cat2
Cat3 Cat4 Cat5 50-ohm Coaxial
75-ohm Coaxial 100-ohm Coaxial Fiber-optic UTP
STP Ribbon Cable Twinaxial Optical 9um
Optical 50um Optical 62.5um

8 / 41
The System Description Language (SDL) - user’s manual

2.27 ByteSizeType
This type defines the size (expressed in bytes) of a physical storage. It is expressed in the form:

N [B | KB | MB | GB | TB ]

where N stands for an integer number and B, KB, MB, GB or TB is the order of magnitude (bytes, kilobytes,
megabytes, gigabytes or terabytes).

2.28 Reference
This type is used to define a reference from an element to another element. The Reference data type is used as
the argument of the IdRef attributes found inside many SDL elements. It is a string, expressed in the form:

ID[.ID]*

where IDs are strings of the Identifier type. This is equivalent to the XPath query

*[..]/*[id="Identifier"]/*[id="Identifier"]/...

In this way it’s possible to have hierarchical references, using the “path” of the IdRef attributes of an element.
For example:

<network id="emptyNetwork">
<computer id="pc1">
<interface id="eth0" />
</computer>
<switch id="switch1">
<interface id="eth0" />
</switch>
<connection id="connection1">
<endpoint idRef="pc1.eth0"/>
<endpoint idRef="switch1.eth0"/>
</connection>
</network>

In this way the connection endpoints are indicated with a single, hierarchical idRef, and not with the old-style

<connection>
<endpoint elementId="pc1" interfaceId="eth0" />
<endpoint elementId="switch1" interfaceId="eth0" />
</connection>

It’s worth noting that the use of hierarchical references is only needed when referencing a sub-element contained
in another element (like an interface or a service). References to top-level elements (computer,
switch and so on) are unchanged.
In other words: the elements in the path are searched in the XML document, and are expressed as the minimum
subtree where the target can be found. This subtree is first searched in the element containing the reference. If
it can’t be found there, the same search is done in the upper-level element (the container), and so on, until the
desired element is found or no element can be found. In the latter case, the reference is a so-called “broken
reference”, not pointing to anything. This situation must be avoided.

3 The SDL Core


SDL consists in the definition of a grammar and a vocabulary for the networks domain. SDL aims to define
the elements and the attributes necessary to describe the data related to network systems, from the interface

9 / 41
The System Description Language (SDL) - user’s manual

parameters of a component to the complex components and the connections among them. These elements and
the attributes are used to define logical models for actual network systems. They represent the vocabulary of
the language. The grammar of SDL is established through the relations specified among the elements and the
attributes of the language.
In SDL there are network topology elements and elements that are part of the network topology elements
themselves or are used to express associations between the network elements or networks.
The network topology nodes have the following predefined names:

network bridge computer firewall


gateway hub mobiledevice networkAccessPoint
other printer repeater router
switch switch3 unknown wirelessAccessPoint
nas

Most of the names are self-explanatory. In addition, unknown is an element not known to the user, while
other is an element known to the user but not supported by SDL.
The following predefined names are used to describe sub-element of the nodes (for example, a physical inter-
face) or to express associations between the nodes:

addr connection interface operatingSystem


os protocol localStorage service
software distribution kernel module
patch address dnsname access

3.1 Definition of network nodes


The SDL syntax to describe network nodes is detailed in this section.
All the nodes have a mandatory id attribute (of type Identifier), which must be unique within the parent sdl
element.

3.1.1 The sdl element


<sdl
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../../schema/sdl.xsd">
...
</sdl>

This is the root element of any description. Each description is composed by a main mandatory part, that has,
as root node, the network element, and some other optional parts (extensions); these optional parts are used
to explicitly describe details about the network physical environment or the security level associated to each
element in the description.

3.1.2 The network element


<network id="Identifier">
*L3 logicalinterface
...
</network>

This is the root element of the core description: the network nodes and the links between them are children of the
network element. The id attribute uniquely identifies the network being described. The network element
is a node too: that means that a network may contain one or more other networks. A network (or subnetwork)
may have network interfaces (logical interfaces) representing the endpoints connecting the network with other

10 / 41
The System Description Language (SDL) - user’s manual

external networks or elements. A network can be empty, with no elements explicitly expressed other than the
virtual interfaces. Otherwise, the nodes inside a network can be expressed: in this case, the logical interfaces of
the network refer to real interfaces belonging to the border elements of the network, like a firewall or a router.
An example of a network named voidNetwork is given below:

<network id="emptyNetwork">
<interface id="virtualIF1" />
<interface id="virtualIF2" />
</network>

This is an empty network: only its logical interfaces, which connect the network with the rest of the world, are
expressed.
An example of explicitly expressed virtual interfaces:

<network id="realNetwork">
<interface id="virtualIF1">
<actual_interface IdRef="firewall.eth1" />
</interface>
...
<firewall id="firewall">
<interface id="eth0" />
<interface id="eth1" />
</firewall>
...
</network>

This example shows a firewall, having its interface eth1 as border element of the inner network.

3.1.3 The unknown element


<unknown id="Identifier">
1*L3 interface
*service
</unknown>

This element represents a black box to be used when the device type is unknown. This element is provided
as a catch-all solution to permit at least insertion of the device at the topological level, with a base network
configuration up to level 3.

3.1.4 The other element


<other id="Identifier">
1*L3 interface
*service
</other>

This element represents a network device whose type is known to the user but it is not (currently) explicitly
supported by SDL. This element is provided as a catch-all solution to permit at least insertion of the device at
the topological level, with a base network configuration up to level 3.

11 / 41
The System Description Language (SDL) - user’s manual

3.1.5 The router element


<router id="Identifier" [ ifaces="uint8" ]>
*access
[ <management id="Identifier">
*<address type="ipv4" netmask="IPv4 netmask" value="IPv4 addr">
*dnsname
</address>
*<address type="ipv6" value="IPv6 addr">
*dnsname
</address>
</management> ]
1*L3 interface
*service
*os
</router>

This element represents a router, that is a network device that works at layer 3 (network layer) of the OSI model
and forwards data packets towards their destination, through the process known as routing.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
This device has the optional management child element, representing the IP address used for network man-
agement purposes. Since this IP address is a characteristic of the device, and is not assigned to any interface, it
is a sub-element of the router itself.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.
An example of a router named R1 is given below:

<router id="R1">
<management id="mng1">
<address type="ipv4" netmask="255.255.255.0" value="192.168.1.1"/>
</management>
<interface id="eth0">
<address type="ipv4" netmask="255.255.0.0" value="10.1.0.1"/>
</interface>
<interface id="eth1">
<address type="ipv4" netmask="255.255.0.0" value="10.2.0.1"/>
</interface>
</router>

3.1.6 The switch3 element

This element represents a network device that operates at layer 3 (the network layer) of the OSI model and
performs operations similar to routers. It is also referred to as a “layer 3 switch” to emphasize its speed, closer
to that of a layer-2 switch than that of a router. In other words, it is a sort of high-performance router optimized
for LAN or intranet use.
This element has the same syntax as the router element (see section 3.1.5), but for the tag name (switch3
instead of router).

12 / 41
The System Description Language (SDL) - user’s manual

3.1.7 The switch element


<switch id="Identifier" [ ifaces="uint8" ]>
*access
[ <management id="Identifier">
*<address type="ipv4" netmask="IPv4 netmask" value="IPv4 addr">
*dnsname
</address>
*<address type="ipv6" value="IPv6 addr">
*dnsname
</address>
</management> ]
2*L1V interface
*os
*service
</switch>

This element is used to represent a link-layer switch, that is a network device providing dedicated connections
for network nodes. Unlike hubs that broadcast packets to all ports, a switch provides dedicated bandwidth
between source and destination ports. So unlike a hub, a switch splits the network traffic and sends it to
different destinations rather than to all systems on the network. It operates at layer 2 (the data link layer) of the
OSI seven-level layer model.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
This device has the optional management child element, representing the IP address used for network man-
agement purposes. Since this IP address is a characteristic of the device, and is not assigned to any interface, it
is a sub-element of the switch itself.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.

3.1.8 The hub element


<hub id="Identifier" [ ifaces="uint8" ]>
*access
[ <management id="Identifier">
*<address type="ipv4" netmask="IPv4 netmask" value="IPv4 addr">
*dnsname
</address>
*<address type="ipv6" value="IPv6 addr">
*dnsname
</address>
</management> ]
2*L1 interface
</hub>

This element represents a device that allows network nodes to communicate with each other, making them act
as a single segment. It works at layer 1 (physical layer) of the OSI network model, repeating the signal that
comes into one port out each of the other ports. It has two or more interfaces. In hubs, when a bit arrives from
one interface, the hub simply re-creates the bit, boosts its energy strength and transmits the bit onto all the other
interfaces. Thus, in hubs the bandwidth is shared between all the connected devices.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.

13 / 41
The System Description Language (SDL) - user’s manual

This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.

3.1.9 The bridge element

<bridge id="Identifier" [ ifaces="uint8" ]>


2*L1 interface
</bridge>

This element represents a device that connects multiple network segments at the data link layer.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
Besides its unique identifier, a bridge must have at least two network interfaces, configured at most at the
data level.

3.1.10 The repeater element

<repeater id="Identifier">
2*L1 interface
</repeater>

This element represents a network device that works at OSI layer 1 (the physical layer) and amplifies or regen-
erates the digital signals while transporting them between its interfaces.
Besides its unique identifier, a repeater must have exactly two network interfaces, configured only at the
physical level.

3.1.11 The computer element

<computer id="Identifier" [ ifaces="uint8" ]>


*access
1*L3 interface
*os
*service
*localStorage
*<cpu id="Identifier" [ frequency="pint32" ]> cpuType </cpu>
</computer>

This element represents an autonomous computing device capable to communicate with other network devices.
It is used to represent both workstations and servers.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.
This element contains the sub-elements os, to indicate the operating system (more information on this topic in
section 3.2.6), and service, to list the network application services provided by this device (more information
on this topic in section 3.2.10).
The sub-element localStorage specifies physical storages, like hard disks, installed on the system. More
information about the localStorage element can be found in section 3.2.9.

14 / 41
The System Description Language (SDL) - user’s manual

The sub-element cpu specifies the hardware platform and it takes one of the predefined values specified in
section 2.24. This element has the frequency attribute, whose value is an integer specifying the processor’s
clock speed in MHz.
An example of a wireless node named station1 is given below:

<computer id="station1">
<interface id="ath0" technology="Wireless LAN" protocol="802.11g">
<address type="ipv4" value="10.0.0.2"/>
<address type="hw" value="00:11:11:11:11:22"/>
</interface>
</computer>

3.1.12 The nas element


<nas id="Identifier" [ ifaces="uint8" ]>
*access
1*L3 interface
*os
*service
*localStorage
*<cpu id="Identifier" [ frequency="pint32" ]> cpuType </cpu>
</nas>

This element represents a Network Attached Storage (NAS), a system used to store and share data over the
network.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.
This element contains the sub-elements os, to indicate the operating system (more information on this topic in
section 3.2.6), and service, to list the network application services provided by this device (more information
on this topic in section 3.2.10).
The sub-element localStorage specifies physical storages, like hard disks, installed on the system. More
information about the localStorage element can be found in section 3.2.9.
The sub-element cpu specifies the hardware platform and it takes one of the predefined values specified in
section 2.24. This element has the frequency attribute, whose value is an integer specifying the processor’s
clock speed in MHz.

3.1.13 The firewall element


<firewall id="Identifier">
*access
1*L3 interface
*os
*service
</firewall>

This element represents a dedicated network device whose main purpose is to filter the traffic between different
trust domains.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.

15 / 41
The System Description Language (SDL) - user’s manual

3.1.14 The printer element

<printer id="Identifier">
*access
L3 interface
*os
*service
</printer>

This element represents a network printer.


This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.

3.1.15 The mobiledevice element


<mobiledevice id="Identifier">
1*L1 interface
*os
</mobiledevice>

This element represents a mobile device.

3.1.16 The gateway element

<gateway id="Identifier">
*access
1*L3 interface
*os
*service
</gateway>

This element represents a network device performing some sort of protocol transformation to/from another
network that uses different protocols. It works at OSI layers 4 to 7.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.

3.1.17 The networkAccessPoint element


<networkAccessPoint id="Identifier">
L3 interface
</networkAccessPoint>

This is a dummy element used to model the access points to other (external) networks. Besides its unique iden-
tifier, a networkAccessPoint must contain exactly one interface, configured at most at the network
level; this is used to model the entry point to the linked network.
Here is an example of an access point (of the network being currently described) towards an external network
named Internet, which provides an interface (named rl0) with the IP address 192.168.1.24:

<networkAccessPoint id="Internet">
<interface id="rl0">
<address type="ipv4" netmask="255.255.255.255" value="192.168.1.24"/>
</interface>
</networkAccessPoint>

Note that the link between the router of the network being described and the access point of the linked network
is given by a connection SDL element (not present in the example).

16 / 41
The System Description Language (SDL) - user’s manual

3.1.18 The wirelessAccessPoint element


<wirelessAccessPoint id="Identifier" [ ifaces="uint8" ]>
*access
[ <management id="Identifier">
*<address type="ipv4" netmask="IPv4 netmask" value="IPv4 addr">
*dnsname
</address>
*<address type="ipv6" value="IPv6 addr">
*dnsname
</address>
</management> ]
1*L2 interface
*os
*service
</wirelessAccessPoint>

This element represents a wireless LAN Access Point (AP) which is compliant with the 802.11 specifications.
An AP manages a cell of 802.11 stations, forwarding traffic between them and to/from the rest of the LAN. It
has at least one wireless interface. Typically, it has one Ethernet interface to connect to the wired network.
This element has the optional attribute ifaces, representing the number of physical network interfaces avail-
able on this device. If this attribute is not specified, then its value will be automatically computed as the number
of interfaces actually listed within the element. Note that the number of interfaces declared can be higher than
those actually listed, because they describe respectively the available interfaces and the actually connected ones.
This element may contain the optional sub-element access, representing how a configuration can be deployed
on this particular SDL element.
The wirelessAccessPoint element has also an optional child element named management, represent-
ing the IP address used for network management purposes. Since this IP address is a characteristic of the
device, and is not assigned to any interface it is an element of the wirelessAccessPoint element itself.
An example of an AP named AP1 and having two interfaces is given below. The interface wlan0 is the wireless
interface compliant with the 802.11g specification while the interface eth0 is an Ethernet one.

<wirelessAccessPoint id="AP1">
<interface id="wlan0" technology="Wireless LAN" protocol="802.11g">
<address type="hw" value="00:11:11:11:11:11"/>
</interface>
<interface id="eth0" technology="Ethernet">
<address type="hw" value="00:22:22:58:28:EA"/>
</interface>
</wirelessAccessPoint>

3.2 Definition of other elements


This section describes the syntax of those elements that are common sub-elements of several types of network
nodes or are used to express associations between them. These elements have the following predefined names:

• interface

• addr

• address

• dnsname

• os

• operatingSystem

• connection

17 / 41
The System Description Language (SDL) - user’s manual

• localStorage
• service
• protocol
• software
• distribution
• kernel
• module
• patch

3.2.1 The interface element


<interface id="Identifier" [ technology="technologyType" ]
[ number="portPosition" ] [ connector="connectorType" ]
[ protocol="L1type" ] [ datalinkprotocol="L2protoType" ]>
*<address type="hw" value="Ethernet addr"/>
*<address type="ipv4" netmask="IPv4 netmask" value="IPv4 addr">
*dnsname
</address>
*<address type="ipv6" value="IPv6 addr">
*dnsname
</address>
*<vlan interface idRef="Reference" [trunking = "yes" | "no"]>
[ IPv4 addr | IPv6 addr ]
</vlan interface>
[ <actual interface idRef="Reference" /> ]
</interface>

Interfaces are physically distinguishable network adapters. For example normally a PC has just one interface,
while a router has multiple interfaces and so on. The interface element describes one physical network
interface of a node.
The optional attributes are:
• technology represents the data link (layer 2) technology and can only take the values in section 2.18;
• number represents the number of the physical port and follows the syntax in section 2.16;
• connector represents the physical connector and can only take the values in section 2.17;
• protocol represents the physical layer details and can take only the values in section 2.19.
• datalinkprotocol represents the data link protocol and can take only the values in section 2.20.
The interface element has three types of sub-elements: address, vlan interface and actual interface.
address is used to describe the layer 2 and 3 addresses (details in section 3.2.2).
vlan interface is used to specify the membership in a VLAN by pointing – through the idRef attribute
– to an external vlan element. The trunking attribute specifies whether the interface operates in trunking
mode: its default value is no.
actual interface is used, in virtual (logical) interfaces inside a network element, as a reference to a
real network interface on a device.
An example of an interface named eth0, assigned to the physical port number 1 and that supports the
Ethernet 10-100 BaseT technology is given below:
<interface id ="eth0" number="1" technology="Ethernet" protocol="10-100BaseT"
datalinkprotocol="Ethernet CSMA/CD">
. . .
</interface>

18 / 41
The System Description Language (SDL) - user’s manual

L1 interface type It is used to represent interfaces of physical-layer network devices (e.g. a hub or a repeater).
Thus, an interface of type L1 type does not contain any address element.
An interface of type L1 interface has the following syntax:

<interface id="Identifier" [ technology="technologyType" ] [


number="portPosition"] [ connector="connectorType" ] [ protocol="L1type" ]>
</interface>

Note that the attribute datalinkprotocol is not present, unlike in interface elements of type L2 interface
and L3 interface.

L1V interface type It is the same as a L1 interface, but is used to represent the network interfaces of switches,
which can have a VLAN tag.
An interface of type L1 interface has the following syntax:

<interface id="Identifier" [ technology="technologyType" ] [


number="portPosition"] [ connector="connectorType" ] [ protocol="L1type" ]>
*<vlan interface idRef="Reference" [trunking = "yes" | "no"]/>
</interface>

L2 interface type It is used to represent interfaces of data link-layer network devices (e.g. a switch or a
bridge).
This type of device has a MAC address but it does not have an IP address and consequently only the address
element of type hw can be specified.
An interface of type L2 interface has the following syntax:

<interface id="Identifier" [ technology="technologyType" ] [


number="portPosition"] [ connector="connectorType" ] [ protocol="L1type" ]
[ datalinkprotocol="L2protoType" ] >
[ <address type="hw" value="Ethernet addr"/>]
</interface>

L3 interface type It is used to represent interfaces of network-layer devices (e.g. a router or a computer).
This type of device has a MAC address and an IP address and consequently the address elements of type hw
and ipv4 are compulsory. The address element of type ipv6 is optional. The syntax of an interface of
type L3 interface is given below:

<interface id="Identifier" [ technology="technologyType" ] [


number="portPosition" ] [ connector="connectorType" ] [ protocol="L1type"
] [ datalinkprotocol="L2protoType" ]>
[ <address type="hw" value="Ethernet addr"/>]
*<address type="ipv4" netmask="IPv4 netmask" value="IPv4 addr">
*dnsname
</address>
*<address type="ipv6" value="IPv6 addr">
*dnsname
</address>
*<vlan interface idRef="Reference" [trunking = "yes" | "no"]>
[ IPv4 addr | IPv6 addr ]
</vlan interface>
</interface>

19 / 41
The System Description Language (SDL) - user’s manual

L3 logicalinterface type A virtual (logical) interface is like a L3 interface type, but is used only inside a
network element, simulating an endpoint of the generic network. The actual interface sub-element is
a reference to a real interface inside the network, and specifies that this given interface is on the border of the
network. The syntax of an interface of type L3 logicalinterface is given below:

<interface id="Identifier" [ technology="technologyType" ] [


number="portPosition" ] [ connector="connectorType" ] [ protocol="L1type"
] [ datalinkprotocol="L2protoType" ]>
[ <address type="hw" value="Ethernet addr"/>]
*<address type="ipv4" netmask="IPv4 netmask" value="IPv4 addr">
*dnsname
</address>
*<address type="ipv6" value="IPv6 addr">
*dnsname
</address>
*<vlan interface idRef="Reference" [trunking = "yes" | "no"]>
[ IPv4 addr | IPv6 addr ]
</vlan interface>
[ <actual interface idRef="Reference" /> ]
</interface>

Examples about the usage of virtual interfaces in a network element can be found in section 3.1.2.

3.2.2 The address element


<address type="hw" value="Ethernet addr t" />

<address type="ipv4" netmask="IPv4 netmask t" value="IPv4 addr t">


*dnsname
</address>

<address type="ipv6" value="IPv6 addr t">


*dnsname
</address>

Each network device connects to the network through a network interface card (NIC) that has a unique hardware
address. At the physical layer, these network devices communicate with each other through the hardware
addresses. IP, being a higher level protocol in the OSI model, communicates through a logical address, which
in this case, is the IP address.
The address SDL element represents a network address (e.g. MAC, IPv4 or IPv6). The element has a
mandatory attribute named type, which can take one of the following values:

• hw represents a hardware address (e.g. MAC address) and in this case the attribute value of the
address element must be of Ethernet address t datatype (defined in Section 2).

• ipv4 represents an IPv4 address and in this case the attribute value of the address element must
be of IPv4 addr t datatype (defined in 2) and it is mandatory to define also the netmask attribute of
IPv4 mask t datatype (defined in Section 2).

• ipv6 represents an IPv6 address and in this case the attribute value of the address element must be
of type IPv6 addr t.

If the type attribute is ipv4 or ipv6, the address element may include additional sub-elements of dnsname
type. Please refer to section 3.2.4 for the details about the dnsname element.
The example below illustrates the case of a computer with one Ethernet interface named eth0, with known
MAC, IPv4 address and DNS names:

20 / 41
The System Description Language (SDL) - user’s manual

<computer id="client2">
<interface id="eth0" technology="Ethernet">
<address type="hw" value="00:08:02:57:28:EA" />
<address type="ipv4" netmask="255.255.255.0" value="192.168.1.254">
<dnsname>alpha.foobar.eu</dnsname>
<dnsname>omega.foobar.eu</dnsname>
</address>
</interface>
</computer>

The dnsname element represents one of the DNS names associated with a given IP address.

3.2.3 The addr element


<addr type="hw"> Ethernet addr t </addr>
<addr type="ipv4" netmask="IPv4 netmask t"> IPv4 addr t </addr>
<addr type="ipv6"> IPv6 addr t </addr>

Important note: the addr element is deprecated. It is still present only for backward compatibility with
already existing SDL descriptions. Please use the address element (section 3.2.2) for any new SDL descrip-
tion.

The addr SDL element represents a network address (e.g. MAC, IPv4 or IPv6). The element has a mandatory
attribute named type, which can take one of the following values:

• hw represents a hardware address (e.g. MAC address) and in this case the content of the addr element
must be of Ethernet address t datatype (defined in Section 2).

• ipv4 represents an IPv4 address and in this case the content of the addr element must be of IPv4 addr t
datatype (defined in 2) and it is mandatory to define also the netmask attribute of IPv4 mask t datatype
(defined in Section 2).

• ipv6 represents an IPv6 address and in this case the content of the addr element must be of type
IPv6 addr t.

The example below illustrates the case of a computer with one Ethernet interface named eth0, with known
MAC and IPv4 addresses:

<computer id="client2">
<interface id="eth0" technology="Ethernet">
<addr type="hw">00:08:02:57:28:EA</addr>
<addr type="ipv4" netmask="255.255.255.0">192.168.1.254</addr>
</interface>
</computer>

3.2.4 The dnsname element

<dnsname> DNSNameType </dnsname>

The dnsname elements represent the different names, expressed as strings, assigned to a single machine on
the net. From the DNS name the IP address of a machine can be obtained through a query to a DNS server:
the DNS name unambiguously links a human-readable string to a specific IP address. Several different DNS
names can point to a single IP address: for example, a web server may have different virtual hosts bounded on
the same IP address and port.

21 / 41
The System Description Language (SDL) - user’s manual

3.2.5 The access element

<access id="Reference" type="AccessType" value="String"/>

The access element is used to specify which service must be used to manage the machine or deploy a
configuration file. Besides its unique identifier, this element has two other mandatory attributes:

• type, stating which protocol must be used to access the machine. For example, ssh for an access
through a secure shell, or human, for a machine which cannot be used remotely and requires the presence
of a human operator. A complete list of the protocols currently supported can be found in section 2.14;

• value, a free-form string indicating the URL, the generic address or the commands needed to access to
the machine.

3.2.6 The os element

<os idRef="Reference" [ running="yes" | "no" ] />

This element is used to specify the operating systems that are running and/or installed on a network compo-
nent. It can be used also to specify a firmware for a special purpose device (e.g. a router). Thus, this
element is a child element of an active SDL element (e.g. computer, router a.s.o.). The SDL element
os references the installed/running operating system described by another SDL element, namely the element
operatingSystem. It has a mandatory attribute named idRef of type Reference, which is a reference to
an identifier (id) of an SDL element named operatingSystem. This means that the value of the idRef at-
tribute must match the value of the id attribute of an operatingSystem element that was already specified
(or is to be specified) in the network to be described. It has an optional attribute running, which can take the
values: yes, no. If no running attribute is specified, then the first encountered os is the running one. The
following is an example of a server with two installed operating systems named by MyOS1 and MyOS2:

<computer id="server1">
. . .
<os idRef="MyOS1"/> <!-- this is the running OS -->
<os idRef="MyOS2"/>
. . .
</computer>

3.2.7 The operatingSystem element

<operatingSystem id="Identifier">
[ <product> OSproduct type | String </product> ]
[ <version> String </version> ]
*<kernel idRef="Reference">
*<distribution idRef="Reference">
*<patch idRef="Reference">
*<module idRef="Reference">
* [capability]
</operatingSystem>

This element describes an operating system (that can be referred to by the os sub-element in a network node).
Its sub-elements are:

• product represents the product name and usually takes one of the values in section 2.23 for the most
widely used operating system; additionally, a generic string can be used to describe the OS or firmware
of a special-purpose device (e.g. a router)

• version represents the product version

• kernel references an external kernel element (see section 3.2.14) that describes the kernel of this
operating system

22 / 41
The System Description Language (SDL) - user’s manual

• distribution references an external distribution element (see section 3.2.13) that describes a
specific operating system distribution
• patch references an external patch element (see section 3.2.16) that describes a patch applied to this
operating system
• module describes a functional enhancement module applied to the operating system, by referencing the
id of a global module element (see section 3.2.15)
• capability describes the security capabilities of the operating system, with the format specified in
section 3.2.19
Note that the version sub-element can be used not only to express the version number (e.g. 4.9) but also
to further refine the product type. For example, for WINNT we could use this field to specify whether it is
the workstation (expressed by the string WK) or server (expressed by the string SRV). Similarly, for Windows
2000, the version element could express the specific variant:
Professional Server AdvancedServer DatacenterServer
An example of an operating system Solaris 4.9, identified by the name mySolaris is given below:
<operatingSystem id="mySolaris">
<product>Solaris</product>
<version>4.9</version>
</operatingSystem>

3.2.8 The connection element


<connection id="Identifier [ type="ConnectionTechnologyType" ]>
<endpoint idRef="Reference"/>
<endpoint idRef="Reference"/>
</connection>

This element describes a physical connection between two network elements. A connection is used to link two
interfaces. Thus, this element is used when two network elements must be connected, e.g. a switch and a
router as well as when it is necessary to link two networks, i.e. a network element (e.g. a router) and a
networkAccessPoint.
The endpoints of the connection are specified with the endpoint SDL element, which is a child element of the
connection SDL element. The endpoint sub-element has the mandatory attribute idRef, a (hierarchical)
reference to an interface contained in a network node.
The optional attribute type express, in the case of a wired connection, the link technology type, like Cat5,
100-ohm Coaxial or Fiber-optic. This attribute can’t apply to wireless connections, since they don’t
establish a physical link between two network interfaces.
The following example describes a connection between between the interface port01 of the switch S1 and
the interface eth0 of the server server1:
<switch id="switch1">
<interface id="port01">
...
</interface>
</switch>
<computer id="server1">
<interface id="eth0">
...
</interface>
</computer>
<connection id="connection1">
<endpoint idRef="switch1.port01" />
<endpoint idRef="server1.eth0" />
</connection>

23 / 41
The System Description Language (SDL) - user’s manual

The following is an example of a connection with an external network, i.e. between the interface eth1 of the
router R1 and the interface rl0 of an access point to the external network named Internet:

<router id="R1">
<interface id="eth1">
...
</interface>
</router>
<networkAccessPoint id="Internet">
<interface id="rl0">
...
</interface>
</networkAccessPoint>
<connection id="connection1">
<endpoint idRef="Internet.rl0" />
<endpoint idRef="R1.eth1" />
</connection>

3.2.9 The localStorage element

<localStorage id="Identifier" [ size="ByteSizeType" ]


[ technology="String" ] [ removable="yes"|"no" ]/>

This element represents a physical storage installed on a node, like an hard disk or a USB memory stick, and
therefore it is available only inside an active SDL element with storage (e.g. a computer or a NAS). The
localStorage element is an empty element, with the standard id attribute, plus three optional attributes:

• size, indicating the storage size.

• technology, which indicates the bus type for the storage, like IDE, SATA, USB, . . .

• removable, a flag indicating if the storage is meant to be a removable storage, like a memory stick.

The following example shows a computer with multiple storages:

<computer id="c1">
<interface id="eth1"/>

<localStorage id="hda" size="200GB" technology="SATA"/>


<localStorage id="hda" size="128MB" technology="USB" removable="yes"/>
...
</computer>

3.2.10 The service element


<service id="Identifier">
<protocol idRef="L7proto type"/>
1*<sap addr="IPv4 addr||IPv6 addr||dnsname" transport="L4proto type"
port="pint16" [session="SSL"]/>
*<software idRef="Reference"/>
</service>

This element represents a network service provided by a node therefore it is available only inside an active SDL
element (e.g. a computer or a router).
The sub-elements of a service are:

• protocol represents the application protocol (e.g. HTTP). This is an empty element with only the
mandatory attribute idRef, which is a reference to the id of an external protocol element providing
unique and detailed protocol description.

24 / 41
The System Description Language (SDL) - user’s manual

• software represents the software element providing the service. This element has the mandatory
attribute idRef, which is a reference to the id of an external software element providing unique and
detailed software description.

• sap represents the service access point and has four attributes:

– addr is a mandatory attribute which specifies the addresses where the service is provided. The
value of this attribute is of type IPv4 addr or IPv6 addr, or a dnsname. The wildcard character
“* ” can be used to bind the service to all addresses of the device, both IPv4 and IPv6 types. The
notations “*IPv4” or “*IPv6” can be used to bind the service respectively to all IPv4 or IPv6
addresses of the device.
– transport is an optional attribute that represents the underlying transport protocol and it can
take only the values in section 2.21.
– port is an optional attribute (of type pint16) that represents the transport protocol port.
– session is an optional attribute, taking the value “SSL”. It is used to express that a certain service
is secured by means of SSL.

Note that when port and/or transport are unspecified they default to the standard values for the
application protocol (e.g. 80/tcp for HTTP).

The example below illustrates the case of a server providing the HTTP and FTP services.

<computer id="server1">
...
<service id="web server">
<protocol idRef="http"/>
<sap addr="192.168.1.17" transport="tcp" port="80"/>
<sap addr="192.168.1.17" transport="tcp" port="4444"/>
<software idRef="MyApache"/>
</service>
<service id="ftp server">
<protocol idRef="ftp"/>
<sap addr="*" transport="tcp" port="21"/>
<software idRef="Myftpd"/>
</service>
...
</computer>

It is worth mentioning that multiple instances of the protocol and sap elements are allowed.

3.2.11 The protocol element

<protocol id="Identifier">
<name> L7proto type </name>
[ <version> String </version> ]
</protocol>

This element defines an application protocol and, besides its id attribute, it has two sub-elements:

• name specifies the application protocol name and it can take only one of the values listed in section 2.22.

• version may be used to specify the application protocol version

The following example describes the HTTP version 1.1 protocol:

<protocol id="myhttp">
<name>http</name>
<version>1.1</version>
</protocol>

25 / 41
The System Description Language (SDL) - user’s manual

3.2.12 The software element


<software id="Identifier">
<name>String</name>
*<module idRef="Reference" />
*<patch idRef="Reference" />
*<version> String </version>
*<maintainer> String </maintainer>
*<description> String </description>
*<date> DateType </date>
*capability
</software>

This element represents the software implementing a service. Its sub-elements are:

• name is the product name and it is a String (e.g. Apache)

• version is the product version and it is a String (e.g. 1.3.34)

• patch describes a security patch applied to the software, by referencing the id of a global patch
element (see section 3.2.16)

• module describes a functional enhancement module applied to the software, by referencing the id of a
global module element (see section 3.2.15)

• maintainer gives the maintainer of the software (e.g. apache.org)

• description contains additional information associated with the software

• date gives the release date of the software, with the format specified in section 2.12.

• capability gives the security capabilities of the software, with the format specified in section 3.2.19

The example below describes the standard version of the Apache software, compiled without any additional
security patch or functional module:

<software id="MyApache">
<name>Apache</name>
<version>1.3.34</version>
<maintainer>apache.org</maintainer>
</software>

3.2.13 The distribution element


<distribution id="Identifier">
<name>String</name>
*<patch idRef="Reference" />
*<module idRef="Reference" />
*<version> String </version>
*<maintainer> String </maintainer>
*<description> String </description>
*<date> DateType </date>
*capability
</distribution>

This element is used to specify an operating system distribution (e.g. RedHat Enterprise Server 2.1). Apart
from the tag (distribution rather than software), it follows the syntax of the software element.

26 / 41
The System Description Language (SDL) - user’s manual

3.2.14 The kernel element


<kernel id="Identifier">
<name>String</name>
*<module idRef="Reference" />
*<patch idRef="Reference" />
*<version> String </version>
*<maintainer> String </maintainer>
*<description> String </description>
*<date> DateType </date>
*capability
</kernel>

This element is used mainly to describe Linux kernels. Apart from the tag (kernel rather than software),
it follows the syntax of the software element.

3.2.15 The module element


<module id="Identifier">
<name>String</name>
*<patch idRef="Reference" />
*<version> String </version>
*<maintainer> String </maintainer>
*<description> String </description>
*<date> DateType </date>
*capability
</module>

This element is used mainly to describe modules that add some functionality to a software element, be that an
operating system or an application software. Apart from the tag (module rather than software), it follows
the syntax of the software element.

3.2.16 The patch element

<patch id="Identifier">
<name>String</name>
*<version> String </version>
*<maintainer> String </maintainer>
*<description> String </description>
*<date> DateType </date>
*capability
</patch>

This element describes a patch that corrects an error or fixes a security vulnerability but don’t add a new
functionality. Apart from the tag (patch rather than software), it follows the syntax of the software
element.

3.2.17 The failover element


<failover id="Identifier">
<activeSystem idRef="Reference" />
1*<spareSystem idRef="Reference" />
</failover>

This element specifies a group of active network nodes – such as a computers – that can act as replacement for
each other. The node acting as main system is identified by referencing its id in the activeSystem sub-
element. The replacement stand-by nodes are identified by referencing their id in one or more spareSystem
sub-elements.

27 / 41
The System Description Language (SDL) - user’s manual

3.2.18 The vlan element

<vlan id="Identifier" vlan id="pint16" />

This element contains all general information specific for a VLAN. Its id attribute is the unique user-assigned
VLAN identifier while the vlan id attribute represents the 802.1q VLAN id of the VLAN.

3.2.19 The capability element

<capability type="CapabilityType"/>

This element contains the security-relevant capabilities supported by a given SDL element, e.g. by a software,
an operating system, a distribution, patch or a module. In particular, the capability element highlights
that a given software element has the potential to enforce a security policy of the same type. Note that in this
conceptual model, the configuration of security properties (e.g. the parameters of the SSL protocol) in the
system is not interpreted as system description, and thus it is not described by an SDL element.
The attribute type can take the values expressed in section 2.13. Their meanings are:

• channel protection: this tag is used to express that an SDL element (e.g. software) supports a
security protocol, such as SSL or IPsec, and thus can enforce a channel protection policy;

• authorization: this tag is used to express the ability of a software to grant authorization criteria,
based on privileges;

• authentication: this tag is used to state that a software can enforce policies regarding the authenti-
cation of a user on a given network system;

• filtering: this tag is used to express the packet filtering capability of an SDL element, such as
iptables;

• operational: this tag is used to express that a software can enforce operational policies, changing
the behavior of a network element when an event occurs.

4 The SDL Extensions


The main focus of the SDL language is to describe the nodes and the software in a generic network. The
main part of the language is aimed to express detailed information about informatic systems. But, sometimes,
this is not enough: in order to perform an in-dept analysis, an administrator could want to formally describe
not only the network, but also, for example, information about the physical environment or the sensitivity
of various elements in the network. So, aside from the “core” part of the SDL language, the need to define
some “extensions” arose. These extensions are optional parts in an SDL description, providing information not
strictly related to the network.
The extensions currently defined use the following predefined names:

sensitivities environment

The sub-elements inside extensions can have the following predefined values:

sensitivity feature target power line


source contained area building
floor room locker

The following example shows the basic use of extensions in an SDL description:

28 / 41
The System Description Language (SDL) - user’s manual

<?xml version="1.0" encoding="UTF-8"?>


<sdl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../../schema/sdl.xsd">
<network id="network1">
...
</network>
<sensitivities>
...
</sensitivities>
<environment>
...
</environment>
...
</sdl>

4.1 The sensitivities extension


<sensitivities>
1*sensitivity
</sensitivities>

The sensitivities extension has been added to permit an explicit definition of the security sensitivity
level of the elements expressed in an SDL network description.
The sensitivities element must contain at least one sensitivity element.

4.1.1 The sensitivity element

<sensitivity>
1*<feature type="SensitivityType" level="low"|"medium"|"high"/>
1*<target idRef="Reference/>
</sensitivity>

A sensitivity element is a collection of elements sharing the same security features and levels. Each
sensitivity element contains one or more feature sub-elements. The feature element is an empty
node, with two mandatory attributes:

• type, indicating which security attribute is specified. The type attribute can take the values specified
by the SensitivityType(2.25).

• level, defining the security level on a three-values scale: low, medium and high.

Each sensitivity element also contains a list of target elements. The target element is an empty
element indicating an element with the given security property. The element contains a reference to the id
attribute of another element

4.1.2 A sensitivities example

The following example shows the usage of the sensitivities extensions:

<sensitivities>

<sensitivity>
<feature type="availability" level="high"/>
<feature type="integrity" level="high"/>
<target idRef="SVNServer"/>
</sensitivity>

29 / 41
The System Description Language (SDL) - user’s manual

<sensitivity>
<feature type="confidentiality" level="low"/>
<target idRef="PC1"/>
<target idRef="PC2"/>
<target idRef="PC3"/>
</sensitivity>

</sensitivities>

In this example, two sensitivity groups are defined, each with its own security features and levels. Elements
with the same security sensitivity are referenced by the target elements.

4.2 The environment extension


<environment id="Identifier">
*power line
*contained
*area
*building
*floor
*room
*locker
</environment>

The environment element is the main SDL extension concerning the physical environment containing a
network. This element has many sub-elements, each describing a specific feature.

4.2.1 The power line element

<power line id="Identifier" [ ups="yes"|"no" ] [ default="yes" | "no" ]>


*<source idRef="Reference"/>
</power line>

power line is an element indicating that, in this particular environment, a power supplier is present. It has
the attribute id, which specifies a name for the power source, and two optional attributes:

• ups : this attributes, set to yes, indicates that this power supplier acts as an UPS (Uninterruptible Power
Source). That means that if its power sources die, this power line will keep on working. Default for this
attribute is no.

• default : if a power line is marked as “default”, it’s considered the power supplier for each contained
element (unless otherwise specified). If at least a power line is present in the main environment
element, one of these powerlines must be marked as default. In case of more power supplier, only one
default can be present.

A power line element can have sub-elements of source type. These empty elements have an attribute
idRef, referenced to another power supplier. The source element is used to simulate the connection to
another power supplier, acting as a source of power. If all the sources stop working, the power line dies, unless
the attribute ups is set to yes.

4.2.2 The contained element


<contained idRef="Reference">
*<ps idRef="Reference"/>
</contained>

30 / 41
The System Description Language (SDL) - user’s manual

contained is an element used to specify which network elements are contained in a location. This element
has an attribute idRef, referencing a node in the main SDL description contained in this container. The
contained element may contain many optional ps elements(meaning “power source”): these sub-elements
indicate which power line the physical element is connected to. If ps is not specified, the power supplier for
this element is considered to be the default one. Instead, if a power supplier is indicated, it overrides the default
one. This means that, if an element is connected to the default power supplier and to an additional, redundant
one, both must be explicitly indicated.

4.2.3 The area element


<area id="Identifier">
*power line
*contained
*building
*floor
*room
*locker
</area>

area is an upper-level element, representing a block or a group of buildings, for example. It can only be
contained inside an environment element.
This element contains many sub-elements, like power line and contained. Their meaning is the same as
in the main environment element(see section 4.2). An area can also contain buildings. If it’s not required to
describe the whole environment, only floor, room or locker can be expressed inside the area element.

4.2.4 The building element

<building id="Identifier">
*power line
*contained
*floor
*room
*locker
</building>

building is an element representing a single building. This element contains many sub-elements, like
power line and contained. Their meaning is the same as in the main environment element(see
section 4.2). A building can also contain floor, room or locker elements.

4.2.5 The floor element

floor is an element representing a single floor inside a building.

<floor id="Identifier">
*power line
*contained
*room
*locker
</floor>

This element contains many sub-elements, like power line and contained. Their meaning is the same as
in the main environment element(see section 4.2). A floor can also contain room or locker elements.

31 / 41
The System Description Language (SDL) - user’s manual

4.2.6 The room element


<room id="Identifier">
*power line
*contained
*locker
</room>

room is an element representing a single room.


This element contains many sub-elements, like power line and contained. Their meaning is the same as
in the main environment element(see section 4.2). A room can also contain locker elements.

4.2.7 The locker element


<locker id="Identifier">
*power line
*contained
</locker>

locker is an element representing a single locker, rack or closet.


This element contains many sub-elements, like power line and contained. Their meaning is the same as
in the main environment element(see section 4.2).

4.2.8 An environment example

In the following example, the usage of the environment extension is shown.

<environment id="world">
<power_line id="ENEL" default="yes"/>
<power_line id="generator"/>

<building id="boella">

<room id="e-security">
<contained idRef="pc1"/>
<contained idRef="pc2"/>
<contained idRef="server1">
<ps idRef="generator"/>
</contained>

<locker id="rack1">
<power_line id="UPS" ups="yes">
<source idRef="generator"/>
</power_line>
<contained idRef="switch1">
<ps idRef="UPS"/>
</contained>
<contained idRef="switch2">
<ps idRef="UPS"/>
</contained>
</locker>

</room>

</building>

</environment>

32 / 41
The System Description Language (SDL) - user’s manual

Figure 1: Sample network

5 Example of a network expressed in SDL


The sample network Figure 1 is described in SDL with the following document:
<?xml version="1.0" encoding="UTF-8"?>
<sdl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../../schema/sdl.xsd">
<network id="example_1">
<router id="R1" ifaces="24">
<interface id="eth0" number="1" technology="Ethernet" protocol="10-100BaseT">
<address type="hw" value="00:08:02:57:28:EA"/>
<address type="ipv4" netmask="255.255.255.0" value="192.168.1.254"/>
</interface>
<interface id="eth1" number="2" technology="Ethernet" protocol="10-100BaseT">
<address type="hw" value="00:08:02:E1:A3:42"/>
<address type="ipv4" netmask="255.255.255.0" value="192.168.4.254"/>
</interface>
<interface id="eth2" technology="Frame Relay" connector="RS232">
<address type="ipv4" netmask="255.255.255.0" value="192.168.2.254"/>
</interface>
</router>
<switch id="S1" ifaces="16">
<interface id="port01" number="1" technology="Ethernet" protocol="10-100BaseT">
<address type="hw" value="00:08:02:E2:5A:EB"/>
</interface>
<interface id="port02" number="2" technology="Ethernet" protocol="10-100BaseT">
<address type="hw" value="00:08:02:E1:2A:EA"/>
</interface>
</switch>
<connection id="conn1">
<endpoint idRef="S1.port01"/>
<endpoint idRef="R1.eth0"/>
</connection>
<computer id="server1">
<interface id="eth0" technology="Ethernet" connector="RJ45" protocol="10-100BaseT">
<address type="hw" value="00:08:02:E7:FF:EA"/>
<address type="ipv4" netmask="255.255.255.0" value="192.168.1.17"/>
</interface>
<os idRef="MyOS"/>
<service id="web server">
<protocol idRef="myhttp"/>
<sap addr="192.168.1.17" transport="tcp" port="80"/>
<software idRef="MyApache"/>
</service>
<service id="ftp server">
<protocol idRef="myftp"/>

33 / 41
The System Description Language (SDL) - user’s manual

<sap addr="*" transport="tcp" port="21"/>


<software idRef="Myftpd"/>
</service>
</computer>
<connection id="conn2">
<endpoint idRef"R1.eth1"/>
<endpoint idRef="server1.eth0"/>
</connection>
<software id="MyApache">
<name>Apache </name>
<version>2.0.1</version>
</software>
<software id="Myftpd">
<name>Vsftpd </name>
<version>1.3</version>
</software>
<protocol id="myhttp">
<name>http</name>
<version>1.0</version>
</protocol>
<protocol id="myftp">
<name>ftp</name>
<version />
</protocol>
<operatingSystem id="MyOS">
<product>Solaris</product>
<version>2.9</version>
</operatingSystem>
<computer id="client1">
<interface id="eth0" technology="Ethernet" connector="RJ45" protocol="10-100BaseT">
<address type="hw" value="00:07:02:F5:FF:BA"/>
<address type="ipv4" netmask="255.255.255.0" value="192.168.1.33">
<dnsname>alpha.foobar.eu</dnsname>
<dnsname>omega.foobar.eu</dnsname>
</address>
</interface>
<os idRef="MyOS"/>
</computer>
<connection id="conn3">
<endpoint idRef="S1.port2"/>
<endpoint idRef="client1.eth0"/>
</connection>
<network id="Internet">
<interface id="rl0">
<address type="ipv4" netmask="255.255.255.128" value="192.168.2.253"/>
</interface>
</network>
<connection id="conn4">
<endpoint idRef="Internet.rl0"/>
<endpoint idRef="R1.eth2"/>
</connection>
</network>
<environment id="world">
<power_line id="ENEL" default="yes"/>
<room id="SecureRoom">
<power_line id="UPS" ups="yes">
<source idRef="ENEL"/>
</power_line>
<contained idRef="server1">
<ps idRef="UPS"/>
</contained>
<locker id="LockedRack">
<contained idRef="S1">
<ps idRef="UPS"/>
</contained>
<contained idRef="R1">

34 / 41
The System Description Language (SDL) - user’s manual

<ps idRef="UPS"/>
</contained>
</locker>
</room>
</environment>
<sensitivities>
<sensitivity>
<feature type="integrity" level="low"/>
<target idRef="client1"/>
</sensitivity>
</sensitivities>
</sdl>

This network is located in a room with alarm and access control. The switch and router are contained inside
a locked rack. Server, switch and router are connected to an UPS. A low level of integrity is specified for the
client.

6 Support tools for SDL checking and translation


6.1 General software requirements
To validate and transform an SDL description, the following software must be installed in your system:

• an operating system supporting Java (e.g. Linux, BSD, Solaris, Windows).

• the Java JDK (1.5+) or Java Runtime Environment (1.5+)2 . If no Java environment is installed, please
download the right version for your system and install it.

• the Xerces2 Java Parser (2.7.1+)3 , which is a fully compliant XML parser (Apache Xerces family) and
XML schema processor

• the Saxon84 XSLT and XQuery processor, that provides the libraries needed for SDL transformation.

6.1.1 Java

To check the installed version of Java use the following command:

java -version

You can then read the running version from the output; for example:

java version "1.5.0_03"


Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing)

6.1.2 Xerces2

Xerces2 is a fully compliant XML parser (Apache Xerces family) and a fully conforming XML Schema pro-
cessor needed to perform validation of SDL documents against the SDL schema.
If you don’t already have it, download the appropriate package for your system from the http://www.
apache.org/dist/xml/xerces-j/binaries/ page:
2
http://www.java.com
3
http://xml.apache.org/xerces2-j/index.html
4
http://saxon.sourceforge.net/

35 / 41
The System Description Language (SDL) - user’s manual

• Xerces-J-bin.2.9.0.zip for Windows

• Xerces-J-bin.2.9.0.tar.gz for Unix

Then follow the installation instructions in the appropriate next section.

Windows installation Unzip the distribution package; a folder named xerces-2 9 0 is created (by default)
and we assume that the complete installation path be named:

C:\xml\xerces-2_9_0

This folder should contain the following files:

• xercesSamples.jar

• xercesImpl.jar

• xml-apis.jar

Finally to complete the installation, set the XERCES environment variable to:

C:\xml\xerces-2_9_0\xercesSamples.jar;C:\xml\xerces-2_9_0\xercesImpl.jar

Unix installation Unpack the distribution package by using the following command:

tar xfpz Xerces-J-bin.2.7.1.tar.gz -C /usr/java/

A directory named xerces-2 9 0 is created (by default) under the installation directory and therefore we
assume that the complete installation path be named:

/usr/java/xerces-2_9_0

This directory should contain the following files:

• xercesSamples.jar

• xercesImpl.jar

• xml-apis.jar

Finally to complete the installation, set the XERCES environment variable to:

"/usr/java/xerces-2_9_0/xercesSamples.jar":"/usr/java/xerces-2_9_0/xercesImpl.jar"

6.1.3 Saxon8

Saxon is an open-source XSLT and XQuery processor. This software provides the libraries needed to transform
SDL into the SDL/CIM format.
If you don’t already have it, download the package saxonb8-8j.zip from the http://prdownloads.
sourceforge.net/saxon/saxonb8-8j.zip page and then follow the installation instructions in the
next sections.

36 / 41
The System Description Language (SDL) - user’s manual

Windows installation To install saxon8 on Windows systems, just unzip the downloaded archive in the folder
where you want to install the package. Let us assume the folder be:

C:\xml\saxonb8-8j

Then, to complete the installation, set the SAXON environment variable to:

C:\xml\saxonb8-8j\saxon8.jar

Unix installation To install saxon8 on Unix systems, just unzip the downloaded archive in the directory
where you want to install the package. Let us assume the directory be:

/usr/java/saxonb8-8j

Then the command to extract the package is:

unzip saxonb8-8j.zip -d /usr/java/saxonb8-8j

Finally to complete the installation, set the SAXON environment variable to:

/usr/java/saxonb8-8j/saxon8.jar

6.2 SDL checker


The vocabulary and the syntax of SDL are specified by means of an XML Schema since SDL is an XML
application. The XML Schema provides the structure of the data separately from the actual data. It is located
in schema folder of the package
This section describes the software requirements and the procedures to follow for validating SDL descriptions
against the SDL XML Schema. Beware that in this way only the general structure of the description is checked
but there could still be lexical or structural errors, such as specifying illegal IP addresses for an interface (e.g
using a multicast address for a unicast interface) or lack of a connection between two network nodes.
Note that XERCES will look for the XML Schema by reading the URI in the network element in the SDL file.
Therefore this element should have the xsi:noNamespaceSchemaLocation attribute value correctly set
to the schema location URI. For example, if the schema file is named SDL.xsd and it is located in the same
directory of the SDL file, the network element should be:

<network id="local_example"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="sdl.xsd">

For sake of simplicity, we suggest to create a dedicated directory that will be used to store both the SDL
description and the SDL XML Schema. Let us assume that the SDL description is named mynet.sdl, the
schema is named sdl.xsd and these two files are stored in the folder:

C:\SDL (in Windows) /home/sdl (in Unix)

37 / 41
The System Description Language (SDL) - user’s manual

6.2.1 Using the checker on Windows systems

Open a text command window, change to the SDL folder and then use the following command to validate an
SDL description against the SDL schema:

java -classpath %XERCES% sax.Counter -v -s <sdl_file>

where <sdl_file> is the name of the SDL file to be validated.


Keeping with our example, to validate the file mynet.sdl run the following command from the C:\SDL
folder:

C:\SDL> java -classpath %XERCES% sax.Counter -v -s mynet.sdl

If the SDL document is valid then no error will be produced and the checker will only show the time taken and
some statistics about the complexity of the description, as in the following output :

mynet.sdl: 310 ms (55 elems, 85 attrs, 0 spaces, 434 chars)

In case of errors, they will be listed each on separate a line prefixed with [Error], like in the following
example produced by a SDL document containing an invalid element (i.e. an hyperswitch):

[Error] mynet.sdl:84:11: cvc-complex-type.2.4.a:


Invalid content was found starting with element ’hyperswitch’. One of
’{"":router, "":connection, "":switch, "":computer, "":software,
"":operatingSystem,"":networkAccessPoint, "":hub}’ is expected.
mynet.sdl: 330 ms (56 elems, 85 attrs, 0 spaces, 438 chars)

A batch file sdl check.bat is also provided to avoid tedious command typing; it takes as parameter the
basename of the SDL file (that is, without the .sdl extension) and works as in the following example:

C:\SDL> sdl_check mynet


-- sdl_check.bat (1.0 - 20051215)
mynet.sdl: 310 ms (55 elems, 85 attrs, 0 spaces, 434 chars)
-- done!

6.2.2 Using the checker on Unix systems

From the command line, change to the SDL directory and then use the following command to validate an SDL
description against the SDL schema:

java -classpath $XERCES sax.Counter -v -s <sdl_file>

where <sdl_file> is the name of the SDL file to be validated.


Keeping with our example, to validate the file mynet.sdl run the following command from the /home/sdl
directory:

/home/sdl$ java -classpath $XERCES sax.Counter -v -s mynet.sdl

38 / 41
The System Description Language (SDL) - user’s manual

If the SDL document is valid then no error will be produced and the checker will only show the time taken and
some statistics about the complexity of the description, as in the following output :

mynet.sdl: 896 ms (55 elems, 85 attrs, 0 spaces, 434 chars)

In case of errors, they will be listed each on separate a line prefixed with [Error], like in the following
example produced by a SDL document containing a wrong attribute (i.e. ifaceos):

[Error] mynet.sdl:3:31: cvc-complex-type.3.2.2:


Attribute ’ifaceos’ is not allowed to appear in element ’router’.
mynet.sdl: 1009 ms (55 elems, 85 attrs, 0 spaces, 434 chars)

A script sdl check is also provided to avoid tedious command typing; it takes as parameter the basename of
the SDL file (that is, without the .sdl extension) and works as in the following example:

/home/sdl$ ./sdl_check mynet


-- sdl_check (1.0 - 20051215)
mynet.sdl: 310 ms (55 elems, 85 attrs, 0 spaces, 434 chars)
-- done!

6.3 SDL translation to SDL/CIM


While SDL is a language that - although verbose - is understandable by human operators, other formats are
more standard and efficient for automatic analysis by computer systems.
Therefore a network described in SDL must be translated to the xCIM format before being analyzed and ma-
nipulated by specific tools (Figure 2).
This section contains the instructions to transform an SDL document into a SDL/CIM one. The stylesheet is
locate in the folder sdl2cim in this package.
We assume that the stylesheet is located in

C:\SDL (in Windows) /home/sdl (in Unix)

basides the file to be transformed is named mynet.sdl and is stored in the same folder.

Figure 2: Transformation of network description from SDL to the internal format based on CIM (SDL/CIM)

39 / 41
The System Description Language (SDL) - user’s manual

6.3.1 Using the translator on Windows systems

Open a text command window, change to the SDL folder and then use the following command to translate an
SDL description to SDL/CIM:

java -jar %SAXON% -o <cim_file> <sdl_file> sdl2cim.xsl

where <sdl_file> is the name of the SDL file to be validated and <cim_file> is the name of the
SDL/CIM that will be created.
Back to our example, use the following command to transform a document file named mynet.sdl from SDL to
SDL/CIM:

C:\SDL> java -jar %SAXON% -o mynet.cim mynet.sdl sdl2sdlcim.xsl

If no errors are encountered during the transformation, then the output file mynet.cim is generated.
A batch file sdl2cim.bat is also provided to avoid tedious command typing; it takes as parameter the
basename of the SDL file (that is, without the .sdl extension) and works as in the following example:

C:\SDL> sdl2cim mynet


-- sdl2cim.bat (1.0 - 20051215)
-- done!

6.3.2 Using the translator on Unix systems

From the command line, change to the SDL directory and then use the following command to translate an SDL
description to SDL/CIM:

java -jar $SAXON -o <cim_file> <sdl_file> sdl2cim.xsl

where <sdl_file> is the name of the SDL file to be validated and <cim_file> is the name of the
SDL/CIM that will be created.
Back to our example, use the following command to transform a document file named mynet.sdl from SDL to
SDL/CIM:

/home/sdl$ java -jar $SAXON -o mynet.cim mynet.sdl sdl2sdlcim.xsl

If no errors are encountered during the transformation, then the output file mynet.cim is generated.

40 / 41
The System Description Language (SDL) - user’s manual

AUTHORS AND ACKNOWLEDGMENTS

This manual has been written by Diana Berbecaru, Luca Dutto, Antonio Lioy, Massimiliano Pala and Paolo
Carlo Pomi of the Politecnico di Torino, Dip. di Automatica e Informatica.
However the SDL language is the joint effort of all the partners of the POSITIF project, that have contributed
to its birth and development.
The language has been further augmented and developed in the DESEREC project.

41 / 41

You might also like