T-110.300: Protocol Design - cse.tkk.fi€¦ · ©Tik-109.401 / Aanen, TKy, Mlu, MTu 1 (154)...

1 (154) © Tik-109.401 /Aanen, TKy, Mlu, MTu

T-110.300: Protocol Design

• Protocol Design Theory• Methods • Protocol Engineering Process (PEP)

[email protected]


Motivation• Telecom systems engineering is a huge industry

– networks, terminals, services

• Also datacom networks consist of protocols– IP technologies today and in future are based on protocols– protocols exist between services and applications– also security systems include protocols

• Basic ideas about protocol systems are portable to every systems that communicate– independent of methods and languages

• Research and industry have use for the know how– research centers, software and hardware manufacturers, telecom and

datacom operators, ISPs, content providers, ...


Objectives of the lecture• Protocol Engineering Theory

– layered protocol systems, communication, definition of behavior

– specification, design and implementation of protocols– methods used in protocol engineering

• MSC, UML, SDL, ASN.1, TTCN

• Protocol Engineering Processes (PEP)– Presentation of iterative and incremental way of

protocol software engineering


Protocol engineering

• Protocol engineering as a discipline of its own

Protocolengineering

Communicationsystems

Formallanguages

Softwareengineering


Protocol engineeringProtocol Engineering Process Overview

Protocol engineering covers the whole life-cycle of a protocol

l requirements are set during overall system design

l protocol design produces complete specification

l specification needs to be verified

l protocol implementation is derived from specification

l implementation must be tested thoroughly


History of protocol engineeringFirst communication protocols were designed in late 60s

(alternating bit protocol by Bartlett at al in 1969)l Theory of protocol verification dates back to late 70s (IBM

Zurich 1978)l Special-purpose protocol design languages were

developed during 80sl The increase of CPU power has made analysis of

moderate sized real life protocols feasible during last 5 years

l Protocol design and implementation tools and development environment products since early 90s

l Since the end of 90s the object oriented methods have been studied and developed


Protocol engineering today• Protocol standardisation quality is miscellaneous

– a lot of natural language documentation– state machines, signalling charts, tables– > a need to standardise standardisation => SDL and MSC => UML

• In design SA/SD methods have been replaced with OO methods– OMT, UML

• Implementation: – C => C++ and Java– CVOPS => OVOPS => SDL => UML– Frameworks and code generation are used

• Testing with TTCN


Protocol designProtocol architectures: designing layers

l allocate a well-defined function for each layer

l keep the number of layers to the minimum

l create a layer boundary at a point where the number of interactions is minimized

l design interlayer interactions as service primitives (confirmed and unconfirmed services)

l use layers to allow different levels of abstraction

l allow changes to layer functions or even change of a complete layer protocol without affecting other layers

=> set of functional protocol entities composing a stack


Protocol Engineering Process

- Requirements- Analysis- Design- Implementation- Testing- Maintenance

- Requirements- Analysis- Design- Specification- Verification

Protocol SpecificationProcess

Protocol ImplementationProcess

Specification

Implementation

• Iterative, parallel

• Two related processes


Protocol Engineering Process

Phases inside processes are also iterative

Requirements Analysis Design

Implementation

Testing

Maintenance


Protocol Engineering Process• Iterative

• refinement in cycles

• Incremental• knowledge and information is added during each round

• Output of each phase should be documented and easily managed

• textual descriptions• languages and methods• tool independent file formats• change management, e.g. versioning systems

• Defining the methodologies and patterns• rules• guidelines• practises


Protocol Engineering ProcessSummary of protocol engineering

Protocol life-cyclel problem - results into requirementsl analysis - results into tentative solutionl design - results into specificationl verification - results into proved specification----------l implementation - results into executable softwarel testing - results into final software

Methods and languages for each phasel UML for requirements capturing and analysisl MSC diagrams for signaling proceduresl SDL with ASN.1 for protocol entity designl Reachability analysis for verificationl C code generation for software implementationl TTCN with ASN.1 for software testing


Waterfall ModelRequirementsspecification

Specification

Design

Implementation

Testing

Process is iterative,but not incremental.


Analysis

Design

ImplementationIntegration

Requirementspecification

Prototyping/testing

version 1version 2version 3

Boehm’s Spiral Model


Spiral Model Properties• Is iterative and incremental• Is not attached to any specific application area• Does not provide means to fix time• Does not provide means to manage the process


Parallel Phase Process Model

Analyse

System Requirements

Design

Implementation

Testing

Time

Stage 1

Stage 1

Stage 2

Stage 1

Stage 1

Stage 2

Stage 2

Stage 3

Par

alle

l pha

ses

Stage 1 Stage 2 Stage 3


Literate Programming• Donald Knuth’s idea

– how programming code and documentation could be combined

– Literate Programming. Stanford, California: Center for the Study of Language and Information, 1992

• Each phase of the process produce documents that are combined to one structural process output documentation

• no tool dependent formats are allowed• structural document management using e.g. XML• every phase output is put to versioning system• project output is stored in one database that allows getting and

putting files through public networks– security issues are raised

• This is ideal situation - excessive tool support is needed


Process Documentation ExampleRequirements

Analyse

Design

Implementation

Process Output

HTML

UML

UML XMIASN.1, IDL

C, C++, Java

XML

XMI


Protocol Engineering Process • Requirements capturing (Why?)

– dictionary– descriptions of the system properties

• Analysis (What?)– system components and interaction

• e.g. conceptual class diagrams

– roles and behaviour • e.g. MSC scenarios, UML sequence charts and use cases


PEP cont.• Design (How?)

– System structures• subsystems and interfaces between them

– Protocol entity structure with interface descriptions• e.g. class diagrams using UML

– Functional model providing early simulation• e.g. behaviour and processes using SDL or UML

– Data definition• e.g. messages using ASN.1

• Validation– to prevent dead-locks, unreachable states, etc.– automatic or semi-automatic protocol validation with a

proper tool


PEP cont.• Implementation

– behaviour• state machines• data handling, error handling• time management

– internal messages– external messages

• encoding/decoding

– implementation for the target environment• frameworks, patterns• languages

– SDL, UML, ASN.1, C, C++, Java• code generation


PEP cont.• Testing

– module testing• autonomous functionality• during implementation phase

– integration testing• system internal interfaces

– conformance testing• ensuring that the system as whole works as specified• external interfaces• execution against reference implementations or testers (e.g.

using TTCN)


Protocol designSignaling procedures

Interactions between protocol entities can be described as signaling procedures.

Description method for signaling procedures is Message Sequence Chart (MSC) Notation, standardized by ITU-T inRec Z.120

Software tools for editing MSC diagrams, e.g. SDT MSC editor


Protocol designMessage Sequence Chart

Graphical MSC notation

l entities = vertical lines with names

l signaling messages = arrows

l messages have names

l order of messages MSC-diagram is not a complete description of the behavior of entities, typically only basic (successful) cases are described as MSCs


Protocol designMessage Sequence Chart - Example: GSM handover

MS BSCBTS-newBTS-old

Channel_activate

Channel_activate_ack

Handover_command

Handover_command

Handover_accessloop

Handover_detect

Physical_information

Move_to_new_channel

Handover_completeHandover_complete


Protocol designDesigning Protocol Data Units (PDUs)

The MSC diagrams from the previous step describe information as messages with names, but no detailed contents.

This representation is called the abstract syntax of PDUs

This encoded representation is called the transfer syntax of PDUs

PDUs are derived from MSC diagrams asl messages, which are composed ofl information elements, which are composed ofl parameters with specified data types

For transmission the PDU encoding is defined asl exact encoding of each parameter data type as bits and bytesl (optional) identifiers for information elements and PDUsl exact bit and byte order


Protocol designDesigning PDUs

Design methods:l the most common informal method is to use bit/byte maps, which

make no distinction between abstract and transfer syntaxesl abstract syntax definition languages: ASN.1, XDR, CORBA IDLl encoding rules are associated to abstract syntax definition languages:

Basic Encoding Rules (BER), Packed ERs (PER)

Design toolsl graphical message editorsl abstract syntax language tools, e.g. ASN.1-to-C translators like the

Nokia CASN Compiler for ASN.1l data definition within integrated design environments, e.g. SDT


Protocol designProtocol entity behavior

The MSCs resulting from the system design are used as starting point for this step

Not only the basic scenarios but also error situations must be taken into account

Protocol entities are usually modeled as state automata

Correctly behaving protocol entity mustl accept all correct sequences of input messagesl detect any incorrect sequence of messagesl recover from such protocol errors


Protocol designFinite State Automaton

FSA model of a protocol

(i) set of input elements I and set of output elements O, i.e.PDUs and Abstract Service Primitives (ASPs)

(ii) set of states S and state transition function succ:

S x I -> S (input transitions)succ

S x O -> S (output transitions)


Protocol designExtended Finite State Automaton (EFSA)

The resulting representation of protocol entity is extended finite state automaton (EFSA)

Example of a graphical EFSA notation is UML State Chart

Software tools for editing State Charts, e.g. SDT SC editor

Basic FSA notation is usually extended byl typed variables within state automaton (context variables)l typed parameters within input and output messagesl conditions (predicates) for state transitions may be given as Boolean

expressionsl transitions may include actions given as block statementsl hierarchical states


SDL

l Specification and Description Language

l Standardised by ITU-T (former CCITT)

l Recommendation Z.100, CCITT Blue Book

l Designed for systems engineering

l First version 1988, new version 1992 (object concepts)

l Formal language

l Can also be used for implementation


What to Describe with SDL• Reactive systems: input - output

– Telecommunication systems and protocols• Discrete systems

– Finite State Machines (FSM)• Not suitable for

– Continuous systems • steering a car

– Heavy calculation• weather models


SDL is a formal language• Unambiguous specification of systems• Can be applied in many phases

– specification– design– implementation– documentation

• Supports also informal specifications• Formality does not say how to specify an arbitrary system


Overview of SDL• SDL system is a model of a real world system

– definition of system components– hierarchical model– Does not restrict the model, no absolute patterns

• a System consists of– blocks, that are connected with channels

• a Block consists of– processes, that are connected with signal routes– sub-blocks, that contain sub-blocks or processes

• a Process has– attributes defined with variables and external procedures– behaviour defined with EFSM, with states and transitions


The Structure of the SDL system


SDL System Behavior• Behavior is defined for processes

– blocks cannot have any behavior, they are only hierarchical building blocks

• Behavior is defined by using Extended Finite State Machines– Extended = variables are used– SDL has its own graphical language for state machines

• Input-Action-Transition defines the behavior– a signal is received– some tasks are carried out, signal(s) sent out– transition to another state

• Conventional programming is possible– procedures– control structures– etc.


Process Diagram


SDL State Machine Diagramprocess type Tili

dcl Ti l iNro Numero;dcl Saldo SaldoTyyppi;dcl veloitus SaldoTyyppi;dcl summa SaldoTyyppi;

‘alustus’

odota_talletusta

Talletus(summa)

saldo:=saldo+summa

tili_ok

tili_ok

Talletus(summa)

saldo:=saldo+summa

tili_ok

Nosto(summa)

summa>saldo

Ylitysto sender

saldo:=saldo-summa

Ylitysto sender

Ylitysto sender

-

saldo:=saldo-summa-veloitus

tili_ylitetty

tili_ylitetty

Talletus(summa)

saldo:=saldo+summa

saldo>0

tili_ylitetty tili_ok

False

True

FalseTrue

*

Sulje


Intro to ASN.1• A message can be viewed from two abstraction levels

Message Message01101001 10110101

Concrete level

Abstract level

Encoding Decoding

Representation during transmission=

Transfer syntax

Representation inside systems=

Local syntax

Logical message information contents = Abstract syntax


Abstract syntaxes for PDUs• Abstract syntax of a PDU deals with

– composition of a PDU from information elements– data types of information elements

• No attention to bits or bytes of the PDU being constructed– Responsibility of abstract syntax: Contents of a

message– Responsibility of transfer syntax: Message

representation

• Message transfer syntax is derived from message abstract syntax


Abstract syntaxes for PDUs• Definition: in natural language or with a formal notation• Example: A semi-formal tabular notation

PDU name Informationelements

Notes

MovePDU Piece ...

from Square ...

to Square ...

InformationElement

Data value Notes

Piece king, queen, ... ,piece

...

Square vertical row Values: a..h

horizontal row Values: 1..8


ASN.1 Overview• ASN.1 is a language for definition of abstract syntaxes

• Associated with ASN.1 there are encoding rules, which determine transfer syntax for any ASN.1 value– Basic Encoding Rules (BER)– Canonical Encoding Rules (CER)– Distinguished Encoding Rules (DER)– Packed Encoding Rules (PER)

• More about encoding rules in a later lecture

• ASN.1 can be used together with other definition languages like SDL


ASN.1 overview• Message concepts and their relationships

Generic rules

ASN.1language

Encoding rulese.g. BER

Message specification

Abstract syntax(message structure)

Transfer syntax(message encoding)

Implementation

Local syntax(message structure)

Encoding routines


ASN.1 - Basic concepts• ASN.1 is a data type definition language

• Basic data concepts– Record => SEQUENCE type– List/array => SEQUENCE OF

type– Mutually exclusive alternatives => CHOICE type– Primitive data types => ASN.1 primitive types– Constants => values

• Structuring– Package/module => module


• Example:

MyModule MODULE DEFINITIONS ::=BEGIN

MyType ::= INTEGER

myValue INTEGER ::= 100

END• ASN.1 is similar to type specification parts of

programming languages

ASN.1 - Basic concepts, cntd.

A type definition.

A value definition

A module definition


Future work• SDL

– SDL 2000– combination of SDL and UML– UML Action Language

• Real-time UML– profile for building communications systems

• Using UML in standardisation– ETSI profile

• Java Protocol Framework (JPF)– implemented by VTT– patterns to use Conduits, UML and Java in protocol

engineering

T-110.300: Protocol Design - cse.tkk.fi€¦ · ©Tik-109.401 / Aanen, TKy, Mlu, MTu 1 (154)...

Documents

Transcript of T-110.300: Protocol Design - cse.tkk.fi€¦ · ©Tik-109.401 / Aanen, TKy, Mlu, MTu 1 (154)...