Essay: RSVP Protocol: Learn About Resource Reservation Protocol & its Use in MANETs Unavailable



TUTORIAL 4

1.  RSVP Protocol

The Resource Reservation Protocol (RSVP) is a Transport Layer protocol designed to reserve resources across a network for an integrated services Internet. RSVP operates over an IPv4 or IPv6 Internet Layer and provides receiver-initiated setup of resource reservations for multicast or unicast data flows with scaling and robustness. RSVP can be used by either hosts or routers to request or deliver specific levels of quality of service (QoS) for application data streams or flows. RSVP defines how applications place reservations and how they can relinquish the reserved resources once the need for them has ended. RSVP operation will generally result in resources being reserved in each node along a path. RSVP is not a routing protocol and was designed to interoperate with current and future routing protocols.

2. Setting up an MANET

 Abstract – Mobile ad hoc networks (MANETs) is an infrastructure-less , dynamic network consisting of a collection of wireless mobile nodes that communicate with each other without the use of any centralized authority. Due to its fundamental characteristics, such as wireless medium, dynamic topology, distributed cooperation, MANETs is vulnerable to various kinds of security attacks like worm hole, black hole, rushing attack etc.

A. MANETs characteristics

1) Distributed operation: There is no background network for the central control of the network operations, the control of the network is distributed among the nodes. The nodes involved in a MANET should cooperate with each other and communicate among themselves and each node acts as a relay as needed, to implement specific functions such as routing and security.

2) Multi hop routing: When a node tries to send information to other nodes which is out of its communication range, the packet should be forwarded via one or more intermediate nodes.

3) Autonomous terminal: In MANET, each mobile node is an independent node, which could function as both a host and a router.

4) Dynamic topology: Nodes are free to move arbitrarily with different speeds; thus, the network topology may change randomly and at unpredictable time. The nodes in the MANET dynamically establish routing among themselves as they travel around, establishing their own network.

5) Light-weight terminals: In maximum cases, the nodes at MANET are mobile with less CPU capability, low power storage and small memory size.

6) Shared Physical Medium: The wireless communication medium is accessible to any entity with the appropriate equipment and adequate resources. Accordingly, access to the channel cannot be restricted.

B. Advantages of MANET

The advantages of an Ad-Hoc network include the following:

 They provide access to information and services regardless of geographic position.

 Independence from central network administration. Self-configuring network, nodes are also act as routers. Less expensive as compared to wired network.

 Scalable—accommodates the addition of more nodes.

 Improved Flexiblibility.

 Robust due to decentralize administration.

 The network can be set up at any place and time.

C. MANETs Challenges

1) Limited bandwidth: Wireless link continue to have significantly lower capacity than infrastructure networks. In addition, the realized throughput of wireless communication after accounting for the effect of multiple access, fading, noise, and interference conditions, etc., is often much less than a radio’s maximum transmission rate.

2) Dynamic topology: Dynamic topology membership may disturb the trust relationship among nodes. The trust may also be disturbed if some nodes are detected as compromised.

3) Routing Overhead: In wireless adhoc networks, nodes often change their location within network. So, some stale routes are generated in the routing table which leads to unnecessary routing overhead.

4) Hidden terminal problem: The hidden terminal problem refers to the collision of packets at a receiving node due to the simultaneous transmission of those nodes that are not within the direct transmission range of the sender, but are within the transmission range of the receiver.

5) Packet losses due to transmission errors: Ad hoc wireless networks experiences a much higher packet loss due to factors such as increased collisions due to the presence of hidden terminals, presence of interference, uni-directional links, frequent path breaks due to mobility of nodes.

6) Mobility-induced route changes: The network topology in an ad hoc wireless network is highly dynamic due to the movement of nodes; hence an on-going session suffers frequent path breaks. This situation often leads to frequent route changes.

7) Battery constraints: Devices used in these networks have restrictions on the power source in order to maintain portability, size and weight of the device.

8) Security threats: The wireless mobile ad hoc nature of MANETs brings new security challenges to the network design. As the wireless medium is vulnerable to eavesdropping and ad hoc network functionality is established through node cooperation, mobile ad hoc networks are intrinsically exposed to numerous security attacks.

D. MANETs Applications

Some of the typical applications include:

1)Military battlefield: Ad-Hoc networking would allow the military to take advantage of commonplace network technology to maintain an information network between the soldiers, vehicles, and military information head quarter.

2) Collaborative work: For some business environments, the need for collaborative computing might be more important outside office environments than inside and where people do need to have outside meetings to cooperate and exchange information on a given project.

3) Local level: Ad-Hoc networks can autonomously link an instant and temporary multimedia network using notebook computers to spread and share information among participants at a e.g. conference or classroom. Another appropriate local level application might be in home networks where devices can communicate directly to exchange information.

4) Personal area network and Bluetooth: A personal area network is a short range, localized network where nodes are usually associated with a given person. Short-range MANET such as Bluetooth can simplify the inter communication between various mobile devices such as a laptop, and a mobile phone.

5) Commercial Sector: Ad hoc can be used in emergency/rescue operations for disaster relief efforts, e.g. in fire, flood, or earthquake. Emergency rescue operations must take place where non-existing or damaged communications infrastructure and rapid deployment of a communication network is needed.

TUTORIAL 5

PETRINETS

Definition

Examples

1. TCP Protocol

Petri net model of protocol TCP is represented in Fig. 1. Notations of right system contain prefix “x”. States of diagram are represented by places of the same name. At that the additional places corresponding to flags SYN, FIN, ACK of packets’ headers are used. These places constitute the communication subsystem. Flags of packets transmitting by right interacting system have prefix “x”. Notice that, for clearness of model the flag of acknowledgement ACK is represented by separate places corresponding to its receiving either as answer on flag SYN (SYNACK), or as answer on flag FIN (FINACK). Moreover, since model does not contain the descriptions of application level protocols, commands OPEN, CLOSE, SEND are represented merely in notations of corresponding transitions. The names of residuary transitions are chosen as first letters of flags waiting for which are represented in standard state diagram of protocol.

Fig. Petri net model of protocol TCP

2. Stop and wait protocol

TUTORIAL 6

SPIN

SPIN is a general tool for verifying the correctness of distributed software models in a rigorous and mostly automated fashion. It was written by Gerard J. Holzmann and others in the original Unix group of the Computing Sciences Research Center at Bell Labs, beginning in 1980. The software has been available freely since 1991, and continues to evolve to keep pace with new developments in the field. Unlike many model-checkers, SPIN does not actually perform model-checking itself, but instead generates C sources for a problem-specific model checker. This technique saves memory and improves performance, while also allowing the direct insertion of chunks of C code into the model.

PROMELA

PROMELA (Process or Protocol Meta Language) is a verification modeling language introduced by Gerard J. Holzmann. The language allows for the dynamic creation of concurrent processes to model, for example, distributed systems. In PROMELA models, communication via message channels can be defined to be synchronous (i.e., rendezvous), or asynchronous (i.e., buffered). PROMELA models can be analyzed with the SPIN model checker, to verify that the modeled system produces the desired behavior. An implementation verified with Isabelle/HOL is also available, as part of the Computer Aided Verification of Automata project.

ESTELLE

In the mid 1980's, Estelle was proposed as a formal description technique for the specification of communication protocols. Dr. Paul Amer has been actively involved in Estelle's development since 1985 when he spent a sabbatical year in Paris, France helping define Estelle's formal semantics and syntax with Piotr Dembinski and Stanislav Budkowski. In 1989 with Professor Richard Tenney (Univ. of Mass, Boston) as Editor, Estelle was approved as an ISO International Standard. Based on communicating extended finite state machines, Estelle has a formal, mathematical, implementation-independent semantics. It is an expressive, well-defined, well-structured language that is capable of specifying distributed, concurrent information processing systems in a complete, consistent, concise and unambiguous manner.

There is little need to explore yet additional languages for formal specification; an international ISO standard based on ten years of study exists. The real challenge is to fully exploit the benefits of Estelle thereby making it as appealing and user friendly as possible to protocol specifiers. We need high quality software design tools based on Estelle: language-based graphical editors that facilitate the writing and modification of Estelle specifications, compilers that convert any Estelle specification to implementation code, simulators that emulate the message passing and extended finite state machine transition firing of any Estelle specification, etc.

LOTOS

The description in full LOTOS consists of two parts:

• XDT service specification

• XDT protocol specification

The protocol description is limited as with the other descriptions on the virtual communication between the protocol entities. The description of the data formats is integrated into the service and the protocol specification.

XDT service specification

The XDT service specification describes the behavior of the service interface with the service access points Sender_SAP and Receiver_SAP, referred to as S and R. The specification uses the resource-oriented style, because thereby the dependencies between the processes at the service access points can be illustrated in more detail. The specification consists of the three main processes sender, association and receiver.

Example: sender[S] |[SA]| association[SA,RA] |[R]| receiver[R]

XDT protocol specification

The protocol specification introduces three new data type definitions: XdtPduType, XdtBufferType and TimerMsgType. The other data types are taken from the service specification. The XDT PDUs are specified in the data type XdtPduType while the data type XdtBufferType describes the buffer for the DT-copies and the associated operations. The last data type TimerMsgType describes timer events. Furthermore, the signals ack_N, go_back_N, abort and end for internal communication between the processes transfer_s and ack_handler are introduced on the transmitter side.

TUTORIAL 8

Sliding Window Protocol

In the SWP, n sequence numbers are used ranging from 0 to n−1. Both the sender and receiver maintain a window, representing a set of sequence numbers they are allowed to send or receive respectively. The sender may send as many octets as the size of its window before it has to wait for an acknowledgement from the receiver. Once the receiver sends an acknowledgement for m octets, its window ‘slides’ forward by m sequence numbers. Likewise, the sender’s window ‘slides’ forward by m sequence numbers if this acknowledgement arrives. For the SWP to function correctly over mediums that may lose data, the maximum size of the window is n 2. If window sizes are larger, a retransmission of a segment with sequence number i may be mistaken for a fresh segment with the same sequence number, resulting in a corrupted byte stream. As a consequence, only n 2 octet buffers are required at the receiving side. Intuitively, the SWP is a generalisaton of the ABP in which the sequence number space is split into two parts, the first part representing the 0-bit that was used in the ABP and the second part representing the 1-bit. As an example, consider a sequence number space of size 8 and a window of size 4. Initially, both the sender and receiver have available windows of size 4. Now, the sender buffers octets 0…3 and sends two segments, one containing octets 0 and 1 and the other containing octets 2 and 3. The sender will have to wait for an acknowledgement before it can send additional data, as it has used up its entire window space. Once the first segment arrives at the receiver, it forwards the octets in the segment to the application layer and sends an acknowledgement. Subsequently, it ‘slides’ its window by 2. The sender also updates its window as it receives this acknowledgement. It may now send octets 4 and 5.

The implementation of the SWP that is used in TCP is different from our example, since octets may be acknowledged before they are forwarded to the application layer and therefore still occupy a position in the receive buffer. In this case, the receiving entity reduces the size of the window through the acknowledgement segment that it sends to the sending entity, resulting in a situation. By doing this, it ensures that the sending entity does not send new data that will overflow its buffer. Once the octets are forwarded to the application layer, it may reopen the window.

TUTORIAL 9

TCP

Connection establishment

During its lifetime, a connection progresses through several states. Of course, both initially and after finishing the communication the connection does not exist. In this case, the connection’s state is described as CLOSED. To initiate communications, a connection must be established. Connection establishment is initiated by issuing the OPEN call from the application layer to TCP. Opening a connection can be done either actively, meaning that the initiating side has the intention to send data, or passively, indicating that the initiating side is willing to accept incoming connection requests. Due to this asymmetry, we identify the following two scenarios:

1. The local TCP entity actively opens a connection In this case, the TCP entity instantiates the TCB in which all state information relevant for the connection will be stored. It then sends a segment with the SYN flag set and progresses the connection’s state from CLOSED to SYN SENT. While in this state, the TCP entity waits for an acknowledgement of the segment that has the SYN flag set. Upon receiving this acknowledgement, it will send back an acknowledgement and progress to the ESTABLISHED state.

A variation to this scenario is possible where the local TCP entity receives a segment with only the SYN flag set while in the SYN SENT state, as a result of the remote entity also actively opening the connection. In this case, the local TCP entity will send a segment with both the SYN and ACK flags set and progress to the SYN RCVD state.

2. The local TCP entity passively opens a connection In the second case, the TCP entity again instantiates the TCB after which the connection’s state will progress to LISTEN. While in this state, the TCP entity waits until it receives a segment with the SYN flag set.1 Upon receiving such a segment, it responds by sending a segment with the SYN and ACK flag set and progresses to the state SYN RCVD. It will then wait for an acknowledgement of this segment and progress to the ESTABLISHED state.

Again, there is a variation to this scenario where a passively opened connection may be transformed into an actively opened connection as the result of a SEND call issued from the application layer of the local TCP entity while this entity is in the LISTEN state. In this case, the local TCP entity will send a segment with the SYN flag set and progress to the SYN SENT state, after which the procedure will be as described before.

We see that in both scenarios, first the initiating side sends a SYN segment. As a response to this segment, a SYN, ACK segment is sent. As this segment is acknowledged, the connection’s state at either end progresses to ESTABLISHED. This procedure is called the three-way handshake, after the three segments that are exchanged during its course.

Once the connection has reached the ESTABLISHED state, both entities have reached an agreement on the configuration to use for the connection and either end will have stored the relevant data in their TCB. For both entities, among other things, this data involves the initial sequence number that the entity will use for outgoing data (ISS), the size of the send window for the entity (SND.WND), indicating the maximum number of octets that it may send at once, and the size of the receive window for the entity (RCV.WND), indicating the maximum number of octets that it is prepared to accept at once[7]. From this point on, data transfer between the entities may take place through consecutive calls of the SEND and/or RECEIVE function from the application layer.

Verification

After having obtained a model from our System Specification, we could verify the correctness of TCP→. First, we will define what correctness entails. In our research question, we formulated the following hypothesis for incorrect behaviour of the protocol:

1. There is a byte that is delivered to the receiver’s transport layer corrupted, or

2. There are bytes that are delivered to the application layer of the receiver in a different order as the order in which they were delivered to the transport layer of the sender, or

3. There are bytes that are delivered to the application layer of the sender, but never delivered to the application layer of the receiver, or

4. There are scenarios in which the execution of the protocol gets stuck

For reasons discussed in chapter 4, our specification abstracts from corrupted segments. Furthermore, we have seen that TCP performs a check on each incoming segment to see whether it starts with the octet that it expects to receive next. If this is not the case, the segment is dropped. If this check is implemented correctly, it is not possible that bytes are delivered to the application layer of the receiver in a different order as the order in which they were delivered to the transport layer of the sender. The third and fourth case, however, are more likely to occur in the event of an error.

Therefore, our verification efforts focused on two aspects of our model. First of all, we verified that its state space does not contain any deadlocks, since they are a sign of an error as a result of how we approached the specification. If m octets must be sent and everything works correctly, the application layer at the sending end issues the SEND call m times and the receiving TCP instance issues the RECEIVE call m times, after which the protocol will indefinitely perform the CONNECTION_CLOSED action. It should be clear that a deadlock does not fit into this expected behaviour, and that therefore deadlocks may not occur in our model.

Second, we compared the external behaviour of our model, defined in terms of the SEND and RECEIVE calls as issued by the application layers at either end, to the external behaviour of a FIFO queue. We chose this approach over model checking since we expected the latter technique to be infeasible on a state space as large as that of TCP→. The reason to model the external behaviour as a FIFO queue is that from a such a queue, elements are taken in the same order as that they were put into the queue. If the SEND call of TCP is seen as putting something into a queue and the RECEIVE call as taking something from it, it becomes immediately clear that the external behaviour of the FIFO queue is the desired behaviour for TCP: the sending entity puts some data elements into the transport medium and the receiving entity takes them all out of this medium in exactly the same order.

TUTORIAL 10

SIP – Session Initiation Protocol

The Session Initiation Protocol (SIP) is a communications protocol for signaling and controlling multimedia communication sessions. The most common applications of SIP are in Internet telephony for voice and video calls, as well as instant messaging, over Internet Protocol (IP) networks. The protocol defines the messages that are sent between endpoints, which govern establishment, termination and other essential elements of a call. SIP can be used for creating, modifying and terminating sessions consisting of one or several media streams. SIP is an application layer protocol designed to be independent of the underlying transport layer. It is a text-based protocol, incorporating many elements of the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP) [9]. SIP works in conjunction with several other application layer protocols that identify and carry the session media. Media identification and negotiation is achieved with the Session Description Protocol (SDP). For the transmission of media streams (voice, video) SIP typically employs the Real-time Transport Protocol (RTP) or Secure Real-time Transport Protocol (SRTP). For secure transmissions of SIP messages, the protocol may be encrypted with Transport Layer Security (TLS).

Conformance Testing

SIP Conformance Analyzer is an advanced testing solution for SIP enabled products widely used in today's VoIP and 3G networks. Comprehensive tests, protocol simulation and analysis tools verify SIP compliance according to ETSI TS 102 027 / RFC 3261 ensuring high probability of interoperability. Offering a full suite of over 600 test cases, the SIP Conformance Analyzer is an automatic conformance testing solution that significantly reduces testing time and facilitates problem identification & solution, improving time-to-market. This solution is available as a SIP conformance analyzer stand-alone software product or as an option provided in the TCA8200 Conformance Analyzer or TCA 4100 Telephony Conformance Analyzer.

FEATURES

• Fully automatic testing of SIP protocol (RFC 3261) according to ETSI TS 102-027

• TTCN-3 suites for User Agent, Proxy, Redirect server, Registrar

• Tests for valid, invalid and inopportune SIP protocol behavior and syntax variations

• User-friendly test parameter (PICS/PIXIT values) setting

• User-configurable tests suites

• On-line and off-line analysis

• Real time display of protocol traces and test results

• Logging of trace and results to file

• Automatic test reports in text and MS Word format

• Powerful management features