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, operators 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. Users agent negotiates with
  service providers agents. Both agents have a
  strategy and users 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?