T : Protocol Design

Transcription

1 T : Protocol Design Protocol Design Theory Methods Protocol Engineering Process (PEP) 1 (154)

2 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,... 2 (154)

3 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 3 (154)

4 Protocol engineering Protocol engineering as a discipline of its own Communication systems Protocol engineering Formal languages Software engineering 4 (154)

5 Protocol engineering Protocol Engineering Process Overview Protocol engineering covers the whole life-cycle of a protocol requirements are set during overall system design protocol design produces complete specification specification needs to be verified protocol implementation is derived from specification implementation must be tested thoroughly 5 (154)

6 History of protocol engineering First communication protocols were designed in late 60s (alternating bit protocol by Bartlett at al in 1969) Theory of protocol verification dates back to late 70s (IBM Zurich 1978) Special-purpose protocol design languages were developed during 80s The increase of CPU power has made analysis of moderate sized real life protocols feasible during last 5 years Protocol design and implementation tools and development environment products since early 90s Since the end of 90s the object oriented methods have been studied and developed 6 (154)

7 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 7 (154)

8 Protocol design Protocol architectures: designing layers allocate a well-defined function for each layer keep the number of layers to the minimum create a layer boundary at a point where the number of interactions is minimized design interlayer interactions as service primitives (confirmed and unconfirmed services) use layers to allow different levels of abstraction 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 8 (154)

9 Protocol Engineering Process Two related processes Protocol Specification Process - Requirements - Analysis - Design - Specification - Verification Protocol Implementation Process - Requirements - Analysis - Design - Implementation - Testing - Maintenance Iterative, parallel Specification Implementation 9 (154)

10 Protocol Engineering Process Phases inside processes are also iterative Implementation Requirements Analysis Design Maintenance Testing 10 (154)

11 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 11 (154)

12 Protocol Engineering Process Summary of protocol engineering Protocol life-cycle problem - results into requirements analysis - results into tentative solution design - results into specification verification - results into proved specification implementation - results into executable software testing - results into final software Methods and languages for each phase UML for requirements capturing and analysis MSC diagrams for signaling procedures SDL with ASN.1 for protocol entity design Reachability analysis for verification C code generation for software implementation TTCN with ASN.1 for software testing 12 (154)

13 Waterfall Model Requirements specification Specification Design Process is iterative, but not incremental. Implementation Testing 13 (154)

14 Boehm s Spiral Model Requirement specification Analysis Design version 3 version 2 version 1 Prototyping/ testing Integration Implementation 14 (154)

15 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 15 (154)

16 Parallel Phase Process Model System Requirements Stage 1 Stage 2 Stage 3 Analyse Stage 1 Stage 2 Stage 3 Parallel phases Design Implementation Testing Time Stage 1 Stage 2 Stage 1 Stage 2 Stage 1 16 (154)

17 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 17 (154)

18 Process Documentation Example Requirements HTML Analyse UML XMI Design UML XMI ASN.1, IDL Implementation C, C++, Java Process Output XML 18 (154)

19 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 19 (154)

20 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 20 (154)

21 Implementation behaviour PEP cont. 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 21 (154)

22 Testing module testing PEP cont. 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) 22 (154)

23 Protocol design Signaling 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 in Rec Z.120 Software tools for editing MSC diagrams, e.g. SDT MSC editor 23 (154)

24 Graphical MSC notation Protocol design Message Sequence Chart entities = vertical lines with names signaling messages = arrows messages have names order of messages MSC-diagram is not a complete description of the behavior of entities, typically only basic (successful) cases are described as MSCs 24 (154)

25 Protocol design Message Sequence Chart - Example: GSM handover MS BTS-old BTS-new BSC Channel_activate Channel_activate_ack Handover_command Handover_command loop Handover_access Handover_detect Physical_information Move_to_new_channel Handover_complete Handover_complete 25 (154)

26 Protocol design Designing Protocol Data Units (PDUs) The MSC diagrams from the previous step describe information as messages with names, but no detailed contents. PDUs are derived from MSC diagrams as messages, which are composed of information elements, which are composed of parameters with specified data types This representation is called the abstract syntax of PDUs For transmission the PDU encoding is defined as exact encoding of each parameter data type as bits and bytes (optional) identifiers for information elements and PDUs exact bit and byte order This encoded representation is called the transfer syntax of PDUs 26 (154)

27 Protocol design Designing PDUs Design methods: the most common informal method is to use bit/byte maps, which make no distinction between abstract and transfer syntaxes abstract syntax definition languages: ASN.1, XDR, CORBA IDL encoding rules are associated to abstract syntax definition languages: Basic Encoding Rules (BER), Packed ERs (PER) Design tools graphical message editors abstract syntax language tools, e.g. ASN.1-to-C translators like the Nokia CASN Compiler for ASN.1 data definition within integrated design environments, e.g. SDT 27 (154)

28 Protocol design Protocol 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 Correctly behaving protocol entity must accept all correct sequences of input messages detect any incorrect sequence of messages recover from such protocol errors Protocol entities are usually modeled as state automata 28 (154)

29 FSA model of a protocol Protocol design Finite State Automaton (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: succ S x I -> S (input transitions) S x O -> S (output transitions) 29 (154)

30 Protocol design Extended Finite State Automaton (EFSA) Basic FSA notation is usually extended by typed variables within state automaton (context variables) typed parameters within input and output messages conditions (predicates) for state transitions may be given as Boolean expressions transitions may include actions given as block statements hierarchical states 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 30 (154)

31 SDL Specification and Description Language Standardised by ITU-T (former CCITT) Recommendation Z.100, CCITT Blue Book Designed for systems engineering First version 1988, new version 1992 (object concepts) Formal language Can also be used for implementation 31 (154)

32 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 32 (154)

33 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 33 (154)

34 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 34 (154)

35 The Structure of the SDL system 35 (154)

36 The Structure of the SDL system 36 (154)

37 The Structure of the SDL system 37 (154)

38 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. 38 (154)

39 Process Diagram 39 (154)

40 SDL State Machine Diagram process type Tili dcl TiliNro Numero; dcl Saldo SaldoTyyppi; dcl veloitus SaldoTyyppi; dcl summa SaldoTyyppi; Sulje * tili_ok tili_ylitetty alustus Talletus (summa) Nosto (summa) Talletus (summa) odota_talletusta saldo:=saldo+ summa True summa> saldo False saldo:=saldo+ summa Talletus (summa) saldo:=saldo+ summa tili_ok tili_ok Ylitys to sender saldo:=saldosumma saldo:=saldosumma-veloitus tili_ylitetty Ylitys to sender Ylitys to sender False saldo >0 tili_ylitetty True tili_ok - 40 (154)

41 Intro to ASN.1 A message can be viewed from two abstraction levels Abstract level Logical message information contents = Abstract syntax Concrete level Message Representation during transmission = Transfer syntax Encoding Decoding Message Representation inside systems = Local syntax 41 (154)

42 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 42 (154)

43 Abstract syntaxes for PDUs Definition: in natural language or with a formal notation Example: A semi-formal tabular notation PDU name Information Notes elements MovePDU Piece... from Square... to Square... Information Data value Notes Element Piece king, queen,...,... piece Square vertical row Values: a..h horizontal row Values: (154)

44 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 44 (154)

45 ASN.1 overview Message concepts and their relationships Generic rules ASN.1 language Message specification Abstract syntax (message structure) Implementation Local syntax (message structure) Encoding rules e.g. BER Transfer syntax (message encoding) Encoding routines 45 (154)

46 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 46 (154)

47 ASN.1 - Basic concepts, cntd. Example: A module definition MyModule MODULE DEFINITIONS ::= BEGIN MyType ::= INTEGER myvalue INTEGER ::= 100 A type definition. END ASN.1 is similar to type specification parts of programming languages A value definition 47 (154)

48 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 48 (154)