1. A Basic Service Model

The basic Internet service model has schematically been shown in Fig. 15.

core router

Figure 15: A Simple Model of the Internet

The Ingress router is the router attached at the sender’s end. It is the first interface to the data sent by the sender host. The type of physical link used at a link may be a twisted pair cable, a fiber optic cable, and even wireless link. The Internet service is provided by an Internet Service Provider (ISP). Therefore, the data passes through the ISP’s routers. These are termed as core routers. The density of these routers is very high at the ISP end, since huge amount of data and links typically converge at the ISP. From the core routers, the data is forwarded through the egress routers (at the receiver end) to the corresponding receivers.

Real-Time communication can be supported on the Internet by providing preferential treatment to data of cer­tain senders that have entered into a contract with the ISP. But for that data packets should have been classified before transmission. At the connection set-up time, the sender provides the ISP with two parameters: the traffic specification and the service specification. The ISP uses this to determine whether it can accept or has to refuse the client request. It checks for the resources on the possible routes of that packet data. Alternatively, we can say it tries to find a path (unicast or multicast routing) that has the necessary resources to satisfy the required QoS for the specified traffic pattern to be generated by the source.

If the network accepts the connection request, then it promises that the data transmission service will meet (or exceed) the client-specified performance bounds. However, the given guarantee remains valid only if the client­generated traffic remains within the specified traffic bounds. If the client traffic violates the prespecified traffic bounds, then the network may drop packets, or reshape the traffic.

Another important component of this approach is the protection given to the real-time connections. Note that the network service will meet the given performance bounds as long as the client traffic remains within the traf­fic specification, irrespective of the behavior of other clients. Now, this performance cannot be guaranteed, if the connections are not protected from the misbehaving (or malicious) real-time and non real-time sources. To avoid violating the guarantees made to real-time connections, the network must either explicitly control the input rates on a por-connoction basis i.e. shaping and policing of the data, or adopt scheduling algorithms that will do so automatically in tho nodos (o.g., Fair Queuing, Weighted Fair Queuing, etc.).

Those techniques are a part of integrated software architectures like IntSorv, DiffSorv etc., which have boon de­signed keeping in mind various issues pertaining to roal-timo communication. Wo discuss those issues in tho following.