Essay: Networking: Wired/wireless, Cobra, Petrinets, TCP, Sliding Window Protocol

TUTORIAL -1

1. Differences between wired and wireless hierarchy

Wired Network

1) Wired networking requires cables connected to each and every computer in the network.

2) Cost of a wired network is less as compared to wireless network as Ethernet, cables, switches are not expensive[1].

3) Wired LAN can show better performance as compared to wireless networks. Wired network can offer 100Mpbs bandwidth using Fast Ethernet technology.

4) Ethernet cables, Switches are used in wired network are reliable.

5) Firewalls are security considerations for a wired network connected to the internet. Firewall software is installed on each computer.

Wireless Network

1) Wireless network can be configured in two ways. i.e. Adhoc or infrastructure mode. Wireless devices require WLAN cards and access points for communication.

2) Wireless networks require equipments like Wireless Adapters and access points which are quite expensive. Cost of wireless networks is high as compared to wired networks.

3) Maximum bandwidth provided by wireless network is about 11Mpbs.

4) The reliability of wireless network is less as compared to wired network.

5) WLANS use wired equivalent privacy (WEP) encryption to protect the data. This makes wireless networks as secure as wired networks.

6) Laptops and other computing devices can be moved around freely within the wireless network because mobility of wireless network is better as compared to wired networks.

2. QOS  – Quality of services (Metrics used to evaluate the performance of the protocols)

Packet delivery: The ratio of the data packets successfully delivered to the destination (sink) to those generated by the CBR (constant bit rate) sources.

Packet dropped: The ratio of the data packets lost at destinations to those, generated by the CBR sources. It occurs due to the route failure or the overloading of the buffers.

Throughput: This is the measure of how soon an end user is able to receive data. It is determined as the ratio of the total data received to required propagation time. A higher throughput will directly impact the user’s perception of the quality of service (QoS).

Packet Delivery Ratio (PDR): The ratio of the data packets delivered to the destination to those generated by CBR sources. This metric illustrates the effectiveness of best effort routing protocols.

Average End-to-End delay: Average end-to-end delay is the delay experienced by the successfully delivered packets in reaching their destinations. This is a good metric for comparing protocols.

Energy Efficiency: We believe that delay should be given the highest priority when dealing with data packets over the wireless network.

3. Protocols of different layers and their functions

• Link Layer

SLIP – Serial Line Internet Protocol. This protocol places data packets into data frames in preparation for transport across network hardware media. This protocol is used for sending data across serial lines. There is no error correction, addressing or packet identification. There is no authentication or negotiation capabilities with SLIP. SLIP will only support transport of IP packets.

CSLIP – Compressed SLIP is essentially data compression of the SLIP protocol. It uses Van Jacobson compression to drastically reduce the overhead of packet overhead. This may also be used with PPP and called CPPP.

PPP – Point to Point Protocol is a form of serial line data encapsulation that is an improvement over SLIP which provides serial bi-directional communication. It is much like SLIP but can support AppleTalk, IPX, TCP/IP, and NetBEUI along with TCP/IP which is supported by SLIP. It can negociate connection parameters such as speed along with the ability to support PAP and CHAP user authentication.

Ethernet – Ethernet is not really called a protocol. There are also many types of ethernet. The most common ethernet which is used to control the handling of data at the lowest layer of the network model is 802.3 ethernet. 802.3 ethernet privides a means of encapsulating data frames to be sent between computers. It specifies how network data collisions are handled along with hardware addressing of network cards.

• Network Layer

ARP – Address Resolution Protocol enables the packaging of IP data into ethernet packages. It is the system and messaging protocol that is used to find the ethernet (hardware) address from a specific IP number. Without this protocol, the ethernet package could not be generated from the IP package, because the ethernet address could not be determined.

IP – Internet Protocol. Except for ARP and RARP all protocols’ data packets will be packaged into an IP data packet. IP provides the mechanism to use software to address and manage data packets being sent to computers.

RARP – Reverse address resolution protocol is used to allow a computer without a local permanent data storage media to determine its IP address from its ethernet address.

• Transport Layer

TCP – A reliable connection oriented protocol used to control the management of application level services between computers. It is used for transport by some applications.

UDP – An unreliable connection less protocol used to control the management of application level services between computers. It is used for transport by some applications which must provide their own reliability.

ICMP – Internet control message protocol (ICMP) provides management and error reporting to help manage the process of sending data between computers. (Management). This protocol is used to report connection status back to computers that are trying to connect other computers. For example, it may report that a destination host is not reachable.

IGMP – Internet Group Management Protocol used to support multicasting. IGMP messages are used by multicast routers to track group memberships on each of its networks.

• Application Layer

FTP – File Transfer Protocol allows file transfer between two computers with login required.

TFTP – Trivial File Transfer Protocol allows file transfer between two computers with no login required. It is limited, and is intended for diskless stations.

NFS – Network File System is a protocol that allows UNIX and Linux systems remotely mount each other’s file systems.

SNMP – Simple Network Management Protocol is used to manage all types of network elements based on various data sent and received.

SMTP – Simple Mail Transfer Protocol is used to transport mail. Simple Mail Transport Protocol is used on the internet, it is not a transport layer protocol but is an application layer protocol.

HTTP – Hypertext Transfer Protocol is used to transport HTML pages from web servers to web browsers. The protocol used to communicate between web servers and web browser software clients.

BOOTP – Bootstrap protocol is used to assign an IP address to diskless computers and tell it what server and file to load which will provide it with an operating system.

DHCP – Dynamic host configuration protocol is a method of assigning and controlling the IP addresses of computers on a given network. It is a server based service that automatically assigns IP numbers when a computer boots. This way the IP address of a computer does not need to be assigned manually. This makes changing networks easier to manage. DHCP can perform all the functions of BOOTP.

BGP – Border Gateway Protocol. When two systems are using BGP, they establish a TCP connection, then send each other their BGP routing tables. BGP uses distance vectoring. It detects failures by sending periodic keep alive messages to its neighbors every 30 seconds. It exchanges information about reachable networks with other BGP systems including the full path of systems that are between them. Described by RFC 1267, 1268, and 1497.

EGP – Exterior Gateway Protocol is used between routers of different systems.

IGP – Interior Gateway Protocol. The name used to describe the fact that each system on the internet can choose its own routing protocol. RIP and OSPF are interior gateway protocols.

RIP – Routing Information Protocol is used to dynamically update router tables on WANs or the internet. A distance-vector algorithm is used to calculate the best route for a packet. RFC 1058, 1388 (RIP2).

OSPF – Open Shortest Path First dynamic routing protocol. A link state protocol rather than a distance vector protocol. It tests the status of its link to each of its neighbors and sends the acquired information to them.

POP3 – Post Office Protocol version 3 is used by clients to access an internet mail server to get mail. It is not a transport layer protocol.

IMAP4 – Internet Mail Access Protocol version 4 is the replacement for POP3.

Telnet is used to remotely open a session on another computer. It relies on TCP for transport and is defined by RFC854.

TUTORIAL 2

1. CORBA MIDDLEWARE

The CORBA standard specifies interfaces that allow seamless interoperability among clients and servers under the object-oriented paradigm[2]. It is produced by the Object Management Group, which has been meeting approximately every six to eight weeks since 1989. The CORBA specification process is evolutionary. Features of the standard are proposed, bid upon, debated, and adopted piecemeal according to a roadmap established by the Object Management Group (OMG). CORBA version 1.1 was released in 1992, version 1.2 in 1993, and version 2.0 in 1996. The V1.2 standard deals primarily with the basic framework for applications to access objects in a distributed environment. This framework includes an object interface specification and the enabling of remote method calls from a client to a server object. Object services for naming, events, relationships, transactions, and concurrency control are addressed in Version 2.0]. Also addressed in CORBA 2.0 is interoperability of CORBA middleware implementations from different vendors through its Internet Inter-ORB Protocol (IIOP).

CORBA is designed to allow a programmer to construct object-oriented programs without regard to traditional object boundaries such as address spaces or location of the object in a distributed system. That is, a client program should be able to invoke a method on a server object whether the object is in the client’s address space or located on a remote node in a distributed system. The CORBA specification includes: an Interface Definition Language (IDL), that defines the object interfaces within the CORBA environment; an Object Request Broker (ORB), which is the middleware that enables the seamless interaction between distributed client objects and server objects; and Object Services, which facilitate standard client/server interaction with capabilities such as naming, event-based synchronization, and concurrency control.

An object model is a set of definitions about the properties of computational entities, such as the available types and their semantics, rules for type compatibility, behavior in case of errors, and so on.

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

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.

Resource Reservation Protocol (RSVP)

Introduction

The goal of the Resource Reservation Protocol (RSVP) is to establish Quality of Service information within routers and host computers of the Internet. Here a model of RSVP  presents the analysis approach and results. A large part of RSVP is modelled using Coloured Petri Nets. The model provides a clear, unambiguous and precise definition of the considered features of RSVP, which is missing in the current protocol specification. The model is analysed for a set of general properties, such as correct termination, and a set of RSVP specific properties defined in this paper. The properties are checked by querying the state graph and its associated strongly connected component graph. As a first step, we analyse RSVP under the assumption of a perfect medium to ensure that protocol errors are not hidden by rare events of the medium. The results show that the RSVP model satisfies the defined properties.

RSVP Properties

Termination Property

There are some standard ways in which protocols can fail. One of them is improper. Termination, so it is important to check that RSVP satisfies the desired termination conditions

(i.e. no deadlocks).

Livelock Property

Another standard way a protocol can fail is livelock. Livelock occurs when protocol sequences are executed indefinitely without the possibility of making effective progress. Thus it is important to check that the RSVP model doesn’t contain livelocks.

Path Setup Property

RSVP can fail in other ways, which are particular to the protocol. One of the main functions of RSVP is to be able to establish path state information along the route of the data flow, which will be used for resource reservations. Thus, it is important to check that RSVP can establish such information.

Path Maintenance Property

RSVP should be able to re-establish any path state information that  has been  removed due to the expiration of the path cleanup timer. The protocol provides a mechanism for recovery from Path message losses. Thus, it is important to check that RSVP can re-establish such information.

Path Release Property

The sender user can leave the session by sending a release request (i.e. a PathTear message). It is beneficial to check that all state information is removed after the sender leaves the session.

Resv Setup Property

RSVP should be able to establish a reservation along the path of the data flow. Therefore, it is

necessary to check that reservation state information is installed at each node after the receiver requests some resources. Also, it is important to check that a reservation is setup at a node only if the corresponding path state information exists at the node.

Resv Maintenance Property

RSVP should re-establish a reservation that has been removed as a result of the expiration of a

path or reservation cleanup timer.

Resv Release Property

RSVP should release the session after the receiver user sends a release request (i.e. a ResvTear message). It is important to check that all reservation state information is removed after the receiver leaves the session.

RSVP Service Provider

RSVP Internet Protocol Stack

RSVP in Internet Protocol Stack

RSVP does not carry data information. It only transports control information (i.e. RSVP signalling messages) intended to create, manage, and remove reservations associated with a user’s data flow. In this thesis, the applications, which can generate QoS requests to RSVP, are called QoS-aware applications. They use RSVP reservation-related services to request the desired QoS guarantees for the data flows and use conventional Internet transport protocol services for data transfer.

Protocol Specification

The specification describes the service or protocol by using, SDL diagrams or state transition tables. Examples of documents that include such specifications are ITU standards documents7 and Internet RFCs.

Colored Petri Nets (CPN)

As systems become more complex, Petri Net models can become very large, complex, and probably unreadable. This problem has been overcome by introducing new kinds of Petri Nets, called High-Level Petri Nets. Coloured Petri Nets (CPNs) are high-level nets. They incorporate some definitions, such as data types and data values processing found in programming languages. In this section, CPNs are introduced through a small example of the service specification for a communication protocol. Some modifications have been introduced to the original model to incorporate all the concepts of the CPN language, which are used in this thesis. In addition, the example is used to introduce the analysis techniques such as the state space method and language generation.

Sender SDL

SDL for sender

Receiver SDL

SDL for Receiver

Service SDL

RSVP Service SDL

Verification using CPN

As Petri Net models, CPN models are created as graphical drawings. Below figure shows the CPN model of the RSVP. It is divided into three parts:  the sender application/RSVP interface, the RSVP service provider, the receiver application/RSVP interface.

Transitions

Transitions represent the actions of the system. They are drawn as rectangles in figure. There are six transitions in the example. The transition RSVPSenderReq models the action taken when the sender sends a request with the traffic characteristics of the data flow. The reception and processing of a sender request is modelled by the transition RSVPSenderInd. The transition RSVPReserveReq models the action taken when the receiver generates a reservation request. The

transition RSVPReserveInd is used to model the reception and processing of a reservation request. The transition RequestRejected models the action taken when the RSVP service provider fails in allocating the requested reservation. Finally, the transition RSVPResvErrorInd  models the reception and processing of a reservation error notification.

Arcs

Arcs connect transitions and places. A transition may have input places connected by incoming arcs and output places connected by outgoing arcs. Arcs have expressions associated with them. They are located next to arcs and determine which tokens are removed or added to the places as explained in the next section.

CPN Simulator

Design/CPN provides both interactive and automatic simulations. They are intended to analyse and to debug the CPN model. In the interactive mode, the user is able to choose among several binding elements, change markings, set breakpoints, and so on. Interactive simulation is used for investigating the behaviour of some parts of the model. Automatic simulation is intended to study the overall behaviour of the system. Automatic simulation is faster than interactive simulation since it does not involve human interaction and also does not provide graphical updates of markings. The user controls automatic simulation by using stop options, which provide a limit on the number of simulation steps. The results of the automatic simulation can be checked by generating a simulation report, which includes all the binding elements that have occurred. Design/CPN also has some visualisation libraries, which can be used to display the results of the simulation in the form of charts.

FSMs of Entities

RSVP Service FSM

Sender FSM

Receiver FSM

RSVP Sender

The RSVP-Sender page is located at the second level of abstraction and includes the major functions that are performed by the RSVP sender entity. All the transitions are hierarchy transitions (as denoted by the HS-tags) and their names are closely related to the RSVP functions. A brief description of the substitution transitions are given as follows:

1. PathManagement: models the establishment, refreshment, error control and release of the

path state information.

2. ResvManagement: models the establishment, refreshment and release of the reservation state

information.

RSVP Receiver

The Receiver page includes the major functions performed by the RSVP entity at the receiver node. The substitution transitions are:

1. PathManagement: models the establishment, refreshment and release of the path state

information.

2. ResvManagement: models the establishment, refreshment, error control and release of the

reservation state information.

States of RSVP Entities

This section defines the states of the three RSVP entities considered in the model (i.e. the sender, receiver and router) and is shown in Figure. The colour set ParameterValues is an enumeration type, which represents abstract values for both the traffic specification (tspec) and flow specification (fspec) parameters. The possible values are Ta, Tb, Fa, Fb and E (empty). The colour set STSpec is a subset of ParameterValues and represents the traffic specification stored as part of the path state information. The colour set SFSpec is a subset of ParameterValues and represents the flow specification stored as part of the reservation state information. The colour set Status is an enumeration type, which defines the states of the RSVP entities. The values of this colour set have the following meanings:

1. SESSION: the sender or receiver has opened a session, but any data flow information or

reservation has not been established yet.

2. IDLE: there exist neither data flow information nor reservation installed in the router.

3. WAITINGRESV: a request with the sender’s data flow information has been accepted by the

entity and sent (if the entity is not the receiver) but no reservation request has been

received yet.

4. RESVREADY: a reservation request has been accepted and sent (if the entity is not the

sender).

5. RESVCONFIRMED: a reservation has been established and a confirmation has been

received.

6. CLOSED: the sender or the receiver has left the session.

Conclusion

Coloured Petri Nets have been used to model the main features of RSVP based on a number of assumptions. We use a simple representative network topology and a limited and reliable communication medium to verify that RSVP will operate correctly under ideal conditions. RSVP uses soft-state refresh and clean-up mechanisms, which are modelled in a non-deterministic way. Similar mechanisms are used in other Internet protocols. Therefore, the RSVP model can be used as a reference for modelling other protocols that use similar procedures.