38.118 Protocol Design, overview of 38.157

1. 38.118 Protocol Design, overview of 38.157 • There is a special course for this 38.157. The lectures on Spring 20001 will be moved to Autumn 2001 in order to coordinate the course with the TIK course protocol production, which is rather similar in content. This lecture is an overview of the course. • 38.157 is at least 13 years old course and was previously called 72.157 Communication protocol design (Tiedonsiirron yhteyskäytäntöjen suunnittelu). Originally the content was protocol development tools from VTT (CVOPS), formal languages (SDL, Lotos) applied to OSI protocol development. • What is it now? There are three approaches to make protocols: ITU-T/ETSI-method, OOD/ODP-method and IETF-method. • In each method: general approach, design process, architectures, protocol mechanisms, tools, languages.

2. Protocol Design, overview • There is another course, 38.151 Service Creation and Development. It concentrates on service design. Java-based solutions are there, so are related IN-based approaches. • A service is more customized, fast created and deployed, more dynamic. • Protocol Design deals with protocol layers above the network layer, so it is upper layer and application software design and development. • Applications are often value added services, but the difference with service creation is that the services in protocol design course are more generic and more stable. • They are created in protocol design methods, while in service creation you want faster development process and more dynamics. Protocol design is more method oriented.

3. Protocol Design, overview • Whether to teach small amount of material deeply and well and have a difficult exam, or cover large amount of material less deeply and have a rather easy exam? • The first alternative is good for basic mathematics as it teaches logical thinking. It is also good if you need precisely some knowledge. • The second alternative is better if: there are many things which may be needed, you will anyway forget the details and have to refresh the knowledge if you need it, the purpose is to teach that there are always coming new things which must be learned very fast and applied immediately. It is also better for giving a whole picture of the field. The course is not a set of uncorrelated fragments where the topic changes for each lecture as it may appear at first, but it covers the essential aspects of what is protocol design.

4. Protocol Design, overview • Protocol design covers a rather wide area. It differs from TIK Protocol production in this respect. The idea is that while there is a need for deep courses on a specific topic, everybody should have some knowledge of all important areas in telecommunications. Many people will work on protocol development and the techniques in this course and on 38.151 are among the techniques, which people usually need in their work. • There is another goal: to try to understand what is protocol design. What are the questions upper layer protocols try to solve? What are the known solution methods? Where tools can be used? What are technologically superior design processes?

5. Protocol Design, overview • Goal: to be able oneself to estimate technological characteristics of different design processes rather than stating slogans. • ITU-T/ETSI-process: • slow, traditional, producing heavy ponderous solutions • or, a practical process producing working standards and tools • OOD/ODP-process: • TINA-like architectures, which never work, useless languages like Object Z, too heavy solutions, what for viewpoints? • or, modern software design methods, rather goods languages and tools • IETF-process: • ad hoc development methods, unsolved problems, no tools • or, simple solutions, working protocols, some useful concepts • Java-process: • write once, run everywhere • or, not a very suitable technology to problems on protocol design

6. Protocol Design, overview • ITU-T/ETSI-process • standards for interoperability, no reference implementations, fair to vendors • largely the view of users (operators) • top down design • influenced by the automatic code generation trend • precise specifications, time and work power used for specifications is not a major issue. It is possible to create a very precise well tested specification. • formal process, languages (SDL, MSC, ASN.1, GDMO, TTCN, Lotos,...) • tools for specification, verification, implementation, testing • architectures (SS7, IN, GSM, TMN, OSI) • useful components (ACSE, ROSE, CCR, TCAP,..)

7. Protocol Design, overview • Object oriented -process • Open Distributed processing (ODP) • Object Oriented Design (OOD) • Computer science originated approach • UML, OMT languages for specification • ODP viewpoints, transparences • IDL-interface definition language • implementation and testing not by formal methods • architectures (CORBA, DCOM, TINA) • components: CORBA-services, CORBA-facilities, trader • tools supported to some extent (UML editors, IDL compilers) • design patterns

8. Protocol Design, overview • That is, if majority has not passed object oriented design course, if they have, then they know UML, Design Patterns etc. but that is not a problem, then we continue further by looking at the applications in telecommunications. • UML (Unified Modeling Language) contains class diagrams, object diagrams, message charts, state automatons etc. which we go through. • Design Patterns are one way of structuring software. Conduits is one way of using design patterns in telecommunications software. This course does not explain conduits. There are other applications. • IDL (Interface Definition Language) is a simple interface language of CORBA with methods and attributes. It can be compared to ASN.1 with GDMO, but it is more simple. • Problems encountered with these methods.

9. Protocol Design, overview • IEFT-process • university, hobbyist (in a positive sense), only recently for commercial telecommunications, IEFT acceptance process should be investigated • end user view, operator’s role to be minimized • performance studies • reference implementations • standards not written in precise formal ways, so, this is not like ITU-T, precise implementation independent interface standards. • useful concepts: socket interface, RPC (example NFS) • architecture and how it developed • open questions changing, QoS, management, mobility, security,...proposed solutions for them.

10. Protocol Design, overview • As there are very few method in this approach, we look at what there is. • Distribution can be made on file level, like in NFS, on middle layers as in socket interface, or at user interface as in X11. What are the limitations? • Why CORBA adds a presentation layer on top of TCP socket interface? Presentation and session layers were supposed to be not needed. • How are made stream interfaces for real time traffic? • Simplification of ITU-T solutions, like SNMP, LDAP.

11. Protocol Design, overview • What are the central questions? • naming, locating, negotiation, transaction, interworking, agreed interfaces, specification methods/languages, components in architectures, distribution on what level, different communication types (remote procedure call, notification, streams, ..) etc. These upper layer questions are not yet even listed. • What are known common mechanisms? • how these questions are solved in different architectures and protocols? when the solutions are good when bad? These questions are not yet sufficiently understood. • For continued studies on protocol design one could select one question and study it deeply, survey the existing solutions and develop a new solution suitable for some circumstances. • It is not just picking up a standard/making design and coding.

12. Protocol Design, overview • Conclusions: why should anyone take this course? • General knowledge: These methods are basic methods used in communication software development and design. Every telecommunication engineer should have this knowledge. • Practical knowledge: The methods/languages are often needed in practice. This course gives a starting point. ASN.1, TTCN, SDL, UML are quite simple when learned. • Research: The course tries also to explain what are the questions studied and methods used in protocol design as a field of research. Usually people are completely lost when trying to do research in this field asking what is research here. If you intend to do continued studies on this field, the course may be helpful.

13. Protocol Design, overview • SDL (Specification and Description Language), v 92 • ITU-T standard notation for protocols, used heavily by ETSI. Most ETSI standards use this notation and the protocols are verified using the SDL descriptions. • Looks like flow charts and is basically easy to read, but it actually defines state machines, not flow charts, and there are a number of unfamiliar symbols if one has not learned it. System and process level descriptions. • SDL data types • Lotos • basic reading knowledge of Lotos specification language. Lotos is not much used, but it is of different type and it is useful to know in order not to reinvent it.

14. Protocol Design, overview • Tree and Tabular Combined Notation (TTCN) • ITU-T protocol conformance testing language. • Protocol testing methodology (black box, upper tester, lower tester, points of control and observation) • Conformance testing process. • Writing simple TTCN, reading TTCN definitions • Other testing methods used in industry will be added to this part, TTCN is only one alternative. • Experiences of typical problems in practical interworking tests, what caused them, how they could be solved.

15. Protocol Design, overview • Abstract Syntax Notation number 1 (ASN.1) • To start this, we must look at the problem of the presentation layer and explain the problems of the OSI presentation layer compared with e.g. CORBA ORB. • Language for defining Protocol Data Units (PDUs) and Abstract Service Primitives (ASPs) • For some reason this language is considered very difficult, which it is not - it is quite logical and easy to learn. • Writing basic ASN-1 definitions: Type definitions, value definitions, modules, macros. • Less importantly, understanding BER-encoding and decoding by hand BER-encoded PDUs, useful for debugging.

16. Protocol Design, overview • Message Sequence Charts (MSCs) • There are many formalisms form message charts and the ITU-T MSC is maybe the least obvious to understand. All message charts are simple to understand but there are notations for timers, alternative behaviors, loops etc. • We go through the MSC standard. • Some comments what else message charts could contain, like modeling of performance issues on message charts.

17. Protocol Design, overview • Additions, what ever is new at the time. • There are always some new approaches, they are explained to the extent the lecture understands it. • An example could be: As QoS issues are of particular interest now (since the Internet has problems with QoS), there could be explained for instance the hybrid approach which adds (quite simple) differential equations to state automaton descriptions in order to model QoS of protocols. Does this make any sense, it would be hard to write a compiler for such definitions at least.

18. Protocol Design, overview • Protocol production cycle contains basically the phases • specification • implementation • testing • maintenance • With the specification part there are phases • requirements • less precise specification (like MSCs) • more precise specification (like SDL diagrams) • behavior and interface specifications • In a certain meaning this is true, but there are variations in different approaches. We can start with a business model describing roles instead of requirements, we can divide the specification phase in many steps.

19. Protocol Design, overview • Such a division can be containing e.g. the information content, distribution to functional elements, technological design. • The goal of protocol is to make a good design. There is no such thing as correct/incorrect design, only good and bad. What is good depends on what you want to achieve. Contradictory goals: • simple system or system supporting many options • implementation independent interface specification or specification with a reference implementation • future proof design or design that can easily be realized with existing parts • precisely specified design or frame architecture • demonstrating new ideas or sound engineering solution. • comparing solutions one should remember what is good in each principle, like a design is not simple if it supports many options.

20. Protocol Design, overview • Implementing a specification leads to programming and to debugging problems. This is in a way interesting work. However, design problems I understand differently. Let us take some design problems, like negotiation • originator sends a list of options it supports • receiver drops out those it does not support • this is a basic negotiation solution in OSI • It is not the only solution to negotiation. • Consider cases when some option can be used if some other option is selected, else not. Then we get negotiation of sets of options. It seems to be harder to fix the sets, this kind of negotiation is realized in many OSI-protocols, a good example is Virtual Terminal which is mostly negotiation whole protocol.

21. Protocol Design, overview • We can continue with the negotiation problem: • What if for security reasons neither side wants to give any information of options before authentication, then the two massage negotiation is not necessarily the optimal solution • This negotiation works only with one connection for connection oriented protocols. Consider the case of Virtual Home Environment, there we want to negotiate options for communication with Service provider profile, User profile, Terminal profile and we transfer these profiles. This is harder, there are many protocols, how to negotiate their usage and even to name them. It should work for connectionless protocols also. • Trader is also negotiation, though from different point of view. The problem is what services are available.

22. Protocol Design, overview • We can continue with the negotiation problem: • Mobile agents are capable of discussing with agent languages. User’s agent negotiates with service provider’s agents. Both agents have a strategy and user’s agent tries to select good service offerings. • We can se, that negotiation is one design problem on upper levels. The simple OSI-negotiation is suitable for negotiating of transfer syntax and some other features, but the question is much deeper. One should know different solutions to negotiation type problems in order to invent a new solution. • Let us take another example of a design problem: • What components an architecture should contain?

23. Protocol Design, overview • What components an architecture should contain? • it is rather generally accepted, that component architectures are good • many architectures contain rather similar components: name server, locator, security component, database related components, components for transaction, remote procedure call, notification, stream interfaces, some management components etc. • There does not seem to be a general understanding what set of components are necessary but new architectures tend to include similar components as the older architectures, so there should be some set of necessary and useful components.

24. Protocol Design, overview • More design problems: • What is a good structure for a protocol development tool? This question has been studied in many tool implementation projects but it is not solved. • The tool could contain a scheduler, automaton, coding/decoding functions for PDUs/Primitives, tracing of behavior and useful routines for memory handling etc. • This kind of structure suits for state automaton based layered protocols. • The structure could also try to replace automatons with objects (what are the differences between an object and an automaton?, size?, inheritance?) and use current ideas from computer science. • There are contradictory views: stateless automaton (like a re-entry function) is good, object (having data and therefore a state) is also good. In general, this seems like an open question.

25. Protocol Design, overview • More design problems: • layered architecture or not? • OSI architecture is layered, but OSI application layer structure is not layered, it contains ASEs and SACF, MACF. • CORBA-architecture is not fully layered. • How to use the lower layers? • OSI-model has ROSE-macro: request, response, errors, and ROSE bind, unbind. This is a quite nice way to define mapping to lower layers. • CORBA has stubs linked to the program, another useful abstraction. • What interfaces lower layers should give is not quite solved: RPC, notification, streams, bulk data transfer, but missing usually are management/measurement interfaces.

26. Protocol Design, overview • Discussing these design problems is the most important part of the course. There is no literature on the subject, but design should be solving these kind of problems in a good way. • Often in a protocol course there is a time consuming practical assignment. Such teaches programming and can be useful in work later. In this course teaching programming is not the goal. That is learned by implementing large software systems. Neither is the purpose teaching use of particular development tools so that the students already know these tools if they need them later. These goals would be too practical - training for a certain work profile. • The practical assignment is intentionally easy in this course. • The goals here are to teach what are the design problems, what are the ways these problems are currently solved, what are the terms, languages and tools that can be used.

27. Protocol Design, overview • What do you need to know to take the course 38.157? • Nothing particular: what is taught in other courses will not be of much help. If you knew the things that are needed in the course you might not need the course at all. • Does this mean that the course is especially easy? No, there are many things, only they are not treated in other courses. It is possible to learn them in this course. • You should know what is an automaton, basic things about protocols, no harm if you have deep knowledge. • C/C++ language and some knowledge of Unix is helpful for the practical assignment if it is done with the OVOPS-tool, but maybe the assignment is with the SDT-tool next time. Exercises are kind of dull but hopefully useful. • Is the course especially difficult to pass? No, the exam is not too difficult. It is a 3 credits course.

28. Protocol Design, overview • What about the course material on 38.157? • There was a new text book in Finnish under preparation for several years, but it was insisted that the course be given in English, so there is no ready material and the lecture notes will be a collection of what is available in English. • The number of students on the course is too small (5 recently) to motivate spending again a major effort in preparing new material in English. • No material will be available through the WWW-pages. No exercises will have model solutions. No WWW-pages. • Therefore, if you intend to take the course, participate in lectures and in exercises. It will be much easier to learn the material. The material will not be exactly the same as what is said on the lectures as lectures are my view on the filed and material will be what can be found in English.

29. Protocol Design, overview • Exercises: • Learning to write and to read formal languages (MSC, SDL, Lotos, ASN.1, TTCN). Simple exercises which are solved on paper or with a tool. • Demonstrations of tools (there has been UML-editor, ASN.1-compiler, CVOPS-tool, SDT-tool for SDL, MSC, TTCN-demo). The demonstrations depend on what we can arrange. Hopefully SDT-tool. • Design exercises, given a problem design a system doing this, make the beginning of the design process in order to understand the whole picture. • Practical assignment: make a protocol or modify an existing protocol using CVOPS or OVOPS-tools. Purpose, to learn how such tools work.

30. Protocol Design, exercise • In the Internet searching information using search machines often does not find the information you need, you may get too many references and URLs are not existing. As an example, try to find ETSI Camel standard with Alta Vista, it will give all camel safaris etc. • Design a software system specification building a permanent information base when given some keywords, like telecommunication, Russian trade etc. • To the extent it is possible within the exercise time (2 hours) give business model, requirements, specification (MSC, SDL, etc.), components, architecture, interfaces. • Identify design problems and discuss alternative solutions, what you try to achieve (simple?, precise?...). • Outline a solution. The problem is thus: • How would you design the system without taking the course?