38.157 Protocol Design-course, overview
• Lecturer: Prof. Jorma Jormakka
• Exercises: Prof. Jorma Jormakka
• Lecures Spring 20001 will probably be moved to Autumn 2001
in order to coordinate the course with the TIK course protocol
production, which is rather similar in content. We will see.
• 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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?
38.157 Protocol Design-course, 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
38.157 Protocol Design-course, 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,..)
38.157 Protocol Design-course, 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
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, overview
• Abstract Syntac 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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?
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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 reentry function) is good, object (having data and therefore a state)
is also good. In general, this seems like an open question.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, overview
• What do you need to know to take this course?
• 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 OVOPStool, 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.
38.157 Protocol Design-course, overview
• What about the course material?
• 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.
38.157 Protocol Design-course, 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.
38.157 Protocol Design-course, 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?