4 - Protocol Design

7/30/2019 4 - Protocol Design

1/51

IHA prsentation 1

Protocol Design

Lesson 4


2/51

IHA prsentation 2

Outline for today

Guidelines for implementing protocols

Protocol Design Patterns


3/51

IHA prsentation 3



4/51


Where is the protocol entity positioned in the complete

protocol stack

Clear picture of the services our protocol provides Procedure/functionality descriptions

Clear picture of which other protocol entities our

protocol interfaces to

Service Access Points, service primitives or other

Definition of messages/PDUs

ASN.1, Augmented BNF or other

IHA prsentation 4


5/51


Consider Task and module decomposition

Shall our protocol run as separate task?

Interaction with the Operating System Memory management

Dynamic memory allocation needed?

Timer management

Are timers needed?

(Inter process communication)

Queues, etc.

(Security management)

Passwords, authentication where are they stored?

IHA prsentation 5


6/51


Protocol states

Finite State Machine (State-event machines)

Identify all states and all internal events

How do we do this?

Message sequence charts (sequence diagrams) for

normal scenarios

MSCs for timer expiry scenarios

MSC for abnormal scenarios

IHA prsentation 6


7/51

IHA prsentation 7

Guidelines

Task and module decomposition ?

Protocol functions that need to manage their own timers

may have their own task

Protocol functions that need to have their own

transmit/receive messages to/from peer protocol

entities may also have their own task

However, consider context switching overhead


8/51

Traditionally

Tasks


9/51

IHA prsentation 9

Guidelines

Designing for Reentrancy

TCPUDP

IP

ip_send() to send packets

Service

Service

Users


10/51


We have protocol related design patterns?

Are they useful?

Can they handle all kind of protocols?

IHA prsentation 10


11/51

IHA prsentation 11



12/51

IHA prsentation 12


Protocol Layer Design Pattern

Protocol Packet Design Pattern

Protocol Stack Design Pattern

Receive Protocol Handler

Transmit Protocol Handler

State Pattern


13/51

IHA prsentation 13


Motivation A typical protocol layer interfaces with an upper and a lower layer of

the protocol stack

In most designs there is a lot of dependency bewteen differentlayers of the protocol

=> inflexibility

The Protocol Layer Design Pattern addresses these limitations bydecopling the individual protocol layers


14/51

IHA prsentation 14


Layer N+1

Layer N

Layer N-1

HandleRecieve

Transmit

Handle

Recieve

Tran

smit

Structure Communication between layers takes place usingstandard interfaces defined by a Protocol Layer base

class

All implementations of the protocol layer inherit from

this class

The inheriting class should implement the standard

interfaces:

Transmit is invoked by the upper layer to transfer

a packet to the lower layer

Handle Receive is invoked by the lower layer totransfer a packet to the upper layer


15/51

IHA prsentation 15


Network Layer

DataLink Layer

Physical Layer

HandleRecieve

Transmit

Handle

Recieve

Tran

smit

Example Transmitting Direction:

1. The application invokes the Network layer's Transmit

method.

2. The Network layer performs its actions and invokes the

Transmit method for the lower layer.

3. This invokes the Datalink layers transmit method. The

Datalink layer performs the layer specific actions and

invokes the lower layer's Transmit method.

4.The Physical layer's Transmit method is invoked. This

layer programs the appropriate hardware device and

transmits the message.


16/51

IHA prsentation 16


Participants

Protocol Layer: This is the base class for all protocol layers. The individual

layers interface with each other via pointers to this class. The actual type of the

upper layer and lower layer classes is not known to the implementers of a

certain layer.

Protocol Packet: This class manages addition and removal of headers and

trailers for various protocol layers.


17/51

IHA prsentation 17


Layer N+1

Layer N

Layer N-1

HandleRecieve

Transmit

Handle

Recieve

Tran

smit

Consequences The implementation of one layer is completelydecoupled from the adjacent layers

Layers can be added and removed without needing

any changes to the code for individual layers

an IPsec layer can be added between IP and physicallayer without any changes to the IP or physical layer code

A single layer could interface with multiple upper and

lower layer protocols using the same interface

an IP layer could interface with an ATM or Ethernet

physical layer. No changes to the IP layer needed.


18/51

IHA prsentation 18


#ifndef PROTOCOL_LAYER_H

#define PROTOCOL_LAYER_H

#include

class Protocol_Packet;

class Protocol_Layer{

Protocol_Layer*m_p_Lower_Layer;

Protocol_Layer*m_p_Upper_Layer;

public:

Protocol_Layer()

{

m_p_Lower_Layer= NULL;m_p_Upper_Layer= NULL;

}

virtual void Transmit(Protocol_Packet *p_Packet) = 0;

virtual void Handle_Receive(Protocol_Packet *p_Packet) = 0;

void Set_Upper_Layer(Protocol_Layer*p_Layer)

{ m_p_Upper_Layer= p_Layer; }

void Set_Lower_Layer(Protocol_Layer*p_Layer)

{ m_p_Lower_Layer= p_Layer; }

Protocol_Layer*Get_Upper_Layer() const

{ return m_p_Upper_Layer; }

Protocol_Layer*Get_Lower_Layer() const

{ return m_p_Lower_Layer; }

};

#endif
http://www.eventhelix.com/source_code/classProtocol__Packet.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Packet.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Packet.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Packet.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Packet.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Layer.htmhttp://www.eventhelix.com/source_code/classProtocol__Packet.htm


19/51

IHA prsentation 19


Motivation

A protocol stack generally handles multiple layers of a protocol

Each layer adds its own headers and trailers

Size of the buffer containing the message keeps changing

In most implementations this results in each layers allocating a new buffer to

adjust the changed buffer size

The Protocol Packet Design Pattern addresses this issue with asimple and efficient buffering architecture


20/51

IHA prsentation 20


Structure

This pattern is implemented by just one class, the Protocol Packet. This class works on a

raw buffer that is capable of holding the entire packet with protocol headers added for all

the layers in the protocol stack. The raw buffer is dynamically partitioned into three

regions:

Header Body

Trailer

As the message moves from one layer the other the location of the different regions is

adjusted. Let see:


21/51

IHA prsentation 21


Transmitting a Packet

Application Body Region Layer 3 Body Region

Layer 3 Header Region

Layer 3 Trailer Region

Layer 2 Body Region



Layer 1 Body Region



Transmitted Body Region

1. The Protocol Packet object is constructed with just the application body. Notice that the body does not start from the

first byte of the buffer. The application body is placed at an offset, leaving enough space for the protocol headers. At

this point, the header and trailer regions are of zero size.

1. The packet is passed to Layer 3. This layer adds its own headers and trailers regions into the same buffer.

1. Layer 2 adds its own headers and trailers regions. The previous header and trailer regions get merged into the body

1. Layer 1 adds headers and trailers. Again, the body region grows to accommodate the headers and trailers for Layer 2

1. Finally, zero length header and trailers are added, resulting in the entire packet moving to the body region. At this point

the header and trailer regions are of 0 length.


22/51

IHA prsentation 22


1. The received packet is created with all the bytes in the body region of the message. At this point, the header andtrailer regions are of zero length.

1. Layer 1 extracts its headers and trailer regions. The two regions have been carved out of the received body

region. The size of the body region is reduced.

1. Layer 2 also extracts its own header and trailer regions. Again shrinking the body region.

1. Layer 3 similarly extracts its header and trailer regions. Shrinking the body to the original application body.

1. The application extracts a zero length header and trailer. This leaves only the packet with only the body region.

Receiving a Packet

Application Body RegionLayer 3 Body Region



Layer 2 Body Region



Layer 1 Body Region



Received Bytes

(Body Region)


23/51

IHA prsentation 23


Participants

This pattern is implemented by just one class, the Protocol Packet. The class

has three internal constituent regions. These regions are defined by the Region

private structure.

Collaboration

The Protocol Packet class contains the header, body and trailer regions. This

relationship is shown in the following collaboration graph:


24/51


class Protocol_Packet

{

enum { MAXIMUM_PACKET_LENGTH = 1500};

struct Region

{

int offset;

int length;

};

Region m_header;

Region m_body;

Region m_trailer;

char m_buffer[MAXIMUM_PACKET_LENGTH];

}


25/51

IHA prsentation 25


Consequences

Using this pattern provides allows efficient handling of packets as different

layers are added or extracted.

A single buffer is used across layers. This reduces the overhead in buffer

processing

In addition, this pattern brings uniformity to the design of the protocol stack.


26/51

IHA prsentation 26


Implementation

Add_Header: Add the header to the transmit packet.

Add_Trailer: Add the trailer to the transmit packet.

Extract_Header: Extract the header from the received packet.

Extract_Trailer: Extract the trailer from the received packet.

Get_Header: Get a pointer to the current packet header.

Get_Body: Get a pointer to the current packet body.

Get_Trailer: Get a pointer to the current packet trailer.

Get_Length: Get the total length. The length includes the header, body and trailer.

The Protocol Packet class consists of the following methods:


27/51

IHA prsentation 27


We have already seen that Protocol Layerand Protocol Packet

provide a standardized interface between different layers of a

protocol.

The Protocol Stack design pattern takes advantage of the layerdecoupling and provides a mechanism for dynamic insertion and

removal of protocol layers from a stack
http://www.eventhelix.com/RealtimeMantra/PatternCatalog/protocol_layer.htmhttp://www.eventhelix.com/RealtimeMantra/PatternCatalog/protocol_layer.htm


28/51

IHA prsentation 28


Motivation

Protocol stacks tend to be rigid in design and protocol layers cannot be dynamicallyadded or removed from a protocol stack

Limits the use of protocol stacks in the even changing world of protocol standards

Example:

The user has enabled encryption and this requires the sandwiching of the encryption

layer between the network layer and the data-link layer

The Protocol Stack Design Pattern addresses this issue andintroduces a flexible architecture for dynamic addition and removal

of protocol layers


29/51

IHA prsentation 29


Structure

The Protocol Stack Design Pattern is implemented by the Protocol Stack class.

This class maintains a doubly linked list of active layers.

Participants

The key actors of this design pattern:

Protocol Stack: This class maintains a doubly linked list of Protocol layers. It supports

dynamic addition and removal of protocol layers.

Protocol Layer: This is the base class for all protocol layers. The individual layers

interface with each other via pointers to this class. The actual type of the upper layer and

lower layer classes is not known to the implementers of a certain layer.


30/51

IHA prsentation 30


Consequences

The Protocol Stack design pattern breaks down the rigid protocol layer

structure and provides a very flexible solution where layers can be dynamically

added and removed from the stack.

Examples


31/51

IHA prsentation 31


A debug pass-through layer that displays the

messages being exchanged between the datalink

layer and the physical layer

Network Layer

Datalink Layer

Physical Layer

HandleRecieve

Transmit

HandleRecieve

Transmit

Debug Layer

HandleRecieve

Transmit


32/51

IHA prsentation 32


A loopback layer that facilitates the testing of the

datalink and network layers by just looping back

all transmitted messages back for receive

Network Layer

Datalink Layer

HandleRecieve

Transmit

Loopback Layer

HandleRecieve

Transmit


33/51

IHA prsentation 33


An echo-back layer allows the protocol stack to

emulate a node by just echoing back all higher

layer messages back for transmission.

Network Layer

Datalink Layer

HandleRecieve

Transmit

Physical Layer

HandleRecieve

Transmit

Echo-back Layer

HandleRecieve

Transmit


34/51

IHA prsentation 34


An encryption layer sandwiched between the

datalink and physical layers. This layers encrypts

and decrypts data that is passed between these

layers

Datalink Layer

Encryption Layer

HandleRecieve

Transmit

Physical Layer

HandleRecieve

Transmit

Network Layer

HandleRecieve

Transmit


35/51

IHA prsentation 35


Implementation

Handle_Transmit: This handler is invoked by the application to transmitmessages using the protocol stack.

Handle_Recieve: This handler is invoked by the device to pass received

messages to the protocol stack.

Add_Layer: Add a protocol layer at a specific position in the protocol stack.

Remove_Layer: Remove a layer from the protocol stack.

The Protocol Stack is implemented as a single class. The class maintains a

doubly linked list of Protocol Layers. Important methods of the class are:


36/51

IHA prsentation 36


Discussion:

Any issues in implementing these patterns?


37/51


PDCP

RLCRLC

RRC

PDCP

BMC

MAC

RLCRLC

RLC

RLCRLC

RLC

PHY

control

control

control

control

control

L2/RLC

L2/MAC

L1

L2/PDCP

L2/BMC

L3

Transport

Channels

Logical

Channels

UMTS:


38/51


DECT


39/51


ZigBee


40/51

IHA prsentation 40


PHY

MAC

Link

Network

010010100111000000

Timer running

Handle ReceiveTransmit

Timeout send NWK PDU

When is control released

so we can handle timeout?


41/51



42/51

IHA prsentation 42

Receive Protocol Handler Pattern

Motivation

Different sliding window protocols have a lot of

similarity. This similarity can be captured in a common

design pattern for their implementation. Here we will

focus on the receive side of the protocol.

Applicability

Receive Protocol Handler Pattern can be used to

implement protocols at any layer.


43/51

IHA prsentation 43


Structure

This pattern is implemented by just one class, Receive Protocol

Handler. This class receives the packets from the other end and

performs the following operations:

Check validity of the received packet

Ask Transmit Protocol Handler to acknowledge the received

packet

Check if the remote end has acknowledged that was sent by

Transmit Protocol Handler.

Inform Transmit Protocol Handler about acknowledged packet.


44/51


To achieve this functionality, the following sequence numbers are

maintained:

Next Expected Sequence Number: Transmit sequence number

expected in the next packet from the remote end.

Last Acknowledged Sequence Number: Last receive sequence

number received from the remote end. This sequence number is

used by the remote end to acknowledge packets.

Participants

The Transmit and Receive Protocol Handlers are the mainparticipants in this pattern. The received messages are added to

the Receive Queue. The received message will be picked by the

next higher layer.

IHA prsentation 44


45/51


Motivation

Different sliding window protocols have a lot of

similarity. This similarity can be captured in a common

design pattern for their implementation. Here we will

focus on the transmit side of the protocol.

Applicability

Transmit Protocol Handler Pattern can be used to

implement protocols at any layer.

IHA prsentation 45


46/51


Structure

This pattern provides a framework for implementing a

sliding window protocol.

The Transmit Protocol Handler receives a packet from

the higher layer and transmits it to the lower layer afterassigning a sequence number

The packet is also stored in an internal retransmission

buffer.

The packet is removed from the retransmission queue ifthe remote end acknowledges the packet.

The Transmit Protocol Handler retransmits the packet if

it times out for an acknowledgement.

IHA prsentation 46


47/51


Participants

The key actors of this design pattern:

Transmit_Protocol_Handler: Class that manages the

transmit end of the protocol. This class interfaces with

the receive end and the retransmission queue.

Transmit_Queue: Enqueues messages that wait for

transmission when the window is full.

Retransmission_Buffer: Manages buffers until an

acknowledgement is received from the other end. The

messages are retransmitted If no ack is received, .

IHA prsentation 47


48/51

Example Data Link Layer

+Protocol_Layer()

+Transmit()

+Handle_Receive()

+Set_Upper_Layer()

+Set_Lower_Layer()

+Get_Upper_Layer()

+Get_Lower_Layer()

-m_p_Lower_Layer-m_p_Upper_Layer

Protocol_Layer

+DataLink_Layer()

+Tranmit()

+Handle_Receive()

-m_transmit_Protocol_Handler

-m_receive_Protocol_Handler

DataLink_Layer

+Handle_Received_Packet()

+Receive_Protocol_Handler()

-m_next_Expected_Sequence_Number

-m_last_Acknowledged_Sequence_Number

-m_p_Transmit_Protocol_Handler

-m_p_Layer

Receive_Protocol_Handler

+Transmit_Protocol_Handler()

+Handle_Transmit_Request()

+Handle_Send_Ack_Request()

+Handle_Received_Ack_Notification()

+Transmit_Packet()

-m_next_Transmit_Sequence_Number

-m_next_Receive_Sequence_Number

-m_Retransmission_Buffer

-m_Transmit_Queue

-m_p_Layer

Transmit_Protocol_Handler

1

1

1

1

* *

1

1

1

1


49/51


A packet is received from the upper layer

1. The upper layer uses its "Lower Layer" pointer to invoke the

Transmit method for the lower layer. The "Protocol Packet" to be

transmitted is passed to the Transmit method.

2. This invokes the Datalink Layer's Transmit method.3. The Datalink Layer passes the "Protocol Packet" to the "Transmit

Protocol Handler" object.

4. The "Transmit Protocol Handler" processes the "Protocol Packet"

and adds the datalink layer header to the packet.

5. The "Transmit Protocol Handler" uses its parent layer to obtain apointer to the lower layer.

6. The "Protocol Packet" is passed to the lower layer by invoking

the Transmit method.

IHA prsentation 49


50/51


A packet is received from the lower layer

1. The lower layer uses its "Upper Layer" pointer to invoke the

"Handle Receive" method for the upper layer. The received

"Protocol Packet" is passed to the "Handle Receive" method.

2. This invokes the Datalink Layer's "Handle Receive" method.3. The Datalink Layer passes the "Protocol Packet" to the "Receive

Protocol Handler" object.

4. The "Receive Protocol Handler" object uses the parent layer to

obtain a pointer to the upper layer.

5. The "Protocol Packet" is passed to the higher layer by invokingthe "Handle Receive" method.

IHA prsentation 50


51/51

State Pattern

Documents

4 - Protocol Design