Upload
sony-neyyan-varghese
View
222
Download
0
Embed Size (px)
Citation preview
7/30/2019 4 - Protocol Design
1/51
IHA prsentation 1
Protocol Design
Lesson 4
7/30/2019 4 - Protocol Design
2/51
IHA prsentation 2
Outline for today
Guidelines for implementing protocols
Protocol Design Patterns
7/30/2019 4 - Protocol Design
3/51
IHA prsentation 3
Guidelines for implementing protocols
7/30/2019 4 - Protocol Design
4/51
Guidelines for implementing protocols
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
7/30/2019 4 - Protocol Design
5/51
Guidelines for implementing protocols
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
7/30/2019 4 - Protocol Design
6/51
Guidelines for implementing protocols
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/30/2019 4 - Protocol Design
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
7/30/2019 4 - Protocol Design
8/51
Traditionally
Tasks
7/30/2019 4 - Protocol Design
9/51
IHA prsentation 9
Guidelines
Designing for Reentrancy
TCPUDP
IP
ip_send() to send packets
Service
Service
Users
7/30/2019 4 - Protocol Design
10/51
Guidelines for implementing protocols
We have protocol related design patterns?
Are they useful?
Can they handle all kind of protocols?
IHA prsentation 10
7/30/2019 4 - Protocol Design
11/51
IHA prsentation 11
Protocol Design Patterns
7/30/2019 4 - Protocol Design
12/51
IHA prsentation 12
Protocol Design Patterns
Protocol Layer Design Pattern
Protocol Packet Design Pattern
Protocol Stack Design Pattern
Receive Protocol Handler
Transmit Protocol Handler
State Pattern
7/30/2019 4 - Protocol Design
13/51
IHA prsentation 13
Protocol Layer Design Pattern
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
7/30/2019 4 - Protocol Design
14/51
IHA prsentation 14
Protocol Layer Design Pattern
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
7/30/2019 4 - Protocol Design
15/51
IHA prsentation 15
Protocol Layer Design Pattern
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.
7/30/2019 4 - Protocol Design
16/51
IHA prsentation 16
Protocol Layer Design Pattern
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.
7/30/2019 4 - Protocol Design
17/51
IHA prsentation 17
Protocol Layer Design Pattern
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.
7/30/2019 4 - Protocol Design
18/51
IHA prsentation 18
Protocol Layer Design Pattern
#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.htm7/30/2019 4 - Protocol Design
19/51
IHA prsentation 19
Protocol Packet Design Pattern
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
7/30/2019 4 - Protocol Design
20/51
IHA prsentation 20
Protocol Packet Design Pattern
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:
7/30/2019 4 - Protocol Design
21/51
IHA prsentation 21
Protocol Packet Design Pattern
Transmitting a Packet
Application Body Region Layer 3 Body Region
Layer 3 Header Region
Layer 3 Trailer Region
Layer 2 Body Region
Layer 2 Header Region
Layer 2 Trailer Region
Layer 1 Body Region
Layer 1 Trailer Region
Layer 1 Header 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.
7/30/2019 4 - Protocol Design
22/51
IHA prsentation 22
Protocol Packet Design Pattern
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 3 Header Region
Layer 3 Trailer Region
Layer 2 Body Region
Layer 2 Header Region
Layer 2 Trailer Region
Layer 1 Body Region
Layer 1 Trailer Region
Layer 1 Header Region
Received Bytes
(Body Region)
7/30/2019 4 - Protocol Design
23/51
IHA prsentation 23
Protocol Packet Design Pattern
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:
7/30/2019 4 - Protocol Design
24/51
Protocol Packet Design Pattern
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];
}
7/30/2019 4 - Protocol Design
25/51
IHA prsentation 25
Protocol Packet Design Pattern
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.
7/30/2019 4 - Protocol Design
26/51
IHA prsentation 26
Protocol Packet Design Pattern
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:
7/30/2019 4 - Protocol Design
27/51
IHA prsentation 27
Protocol Stack Design Pattern
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.htm7/30/2019 4 - Protocol Design
28/51
IHA prsentation 28
Protocol Stack Design Pattern
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
7/30/2019 4 - Protocol Design
29/51
IHA prsentation 29
Protocol Stack Design Pattern
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.
7/30/2019 4 - Protocol Design
30/51
IHA prsentation 30
Protocol Stack Design Pattern
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
7/30/2019 4 - Protocol Design
31/51
IHA prsentation 31
Protocol Stack Design Pattern
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
7/30/2019 4 - Protocol Design
32/51
IHA prsentation 32
Protocol Stack Design Pattern
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
7/30/2019 4 - Protocol Design
33/51
IHA prsentation 33
Protocol Stack Design Pattern
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
7/30/2019 4 - Protocol Design
34/51
IHA prsentation 34
Protocol Stack Design Pattern
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
7/30/2019 4 - Protocol Design
35/51
IHA prsentation 35
Protocol Stack Design Pattern
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:
7/30/2019 4 - Protocol Design
36/51
IHA prsentation 36
Protocol Stack Design Pattern
Discussion:
Any issues in implementing these patterns?
7/30/2019 4 - Protocol Design
37/51
Protocol Stack Design Pattern
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:
7/30/2019 4 - Protocol Design
38/51
Protocol Stack Design Pattern
DECT
7/30/2019 4 - Protocol Design
39/51
Protocol Stack Design Pattern
ZigBee
7/30/2019 4 - Protocol Design
40/51
IHA prsentation 40
Protocol Stack Design Pattern
PHY
MAC
Link
Network
010010100111000000
Timer running
Handle ReceiveTransmit
Timeout send NWK PDU
When is control released
so we can handle timeout?
7/30/2019 4 - Protocol Design
41/51
Protocol Stack Design Pattern
7/30/2019 4 - Protocol Design
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.
7/30/2019 4 - Protocol Design
43/51
IHA prsentation 43
Receive Protocol Handler Pattern
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.
7/30/2019 4 - Protocol Design
44/51
Receive Protocol Handler Pattern
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
7/30/2019 4 - Protocol Design
45/51
Transmit Protocol Handler
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
7/30/2019 4 - Protocol Design
46/51
Transmit Protocol Handler
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
7/30/2019 4 - Protocol Design
47/51
Transmit Protocol Handler
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
7/30/2019 4 - Protocol Design
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
7/30/2019 4 - Protocol Design
49/51
Example Data Link Layer
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
7/30/2019 4 - Protocol Design
50/51
Example Data Link Layer
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
7/30/2019 4 - Protocol Design
51/51
State Pattern