Real-Time Channels

What is a real-time channel?

A real-time channel is a simplex, ordered, unreliable virtual connection between two networked hosts that provides deterministic or statistical end-to-end delay guarantees between the hosts. Once established, a real-time channel is guaranteed to meet user-specified performance requirements deterministically or statistically as long as the user does not violate his pre-specified traffic-generation characteristics. These guarantees typically involve a bound on the end-to-end delay that is maintained by the network and in the communication subsystem at the source and destination hosts. In addition to delay guarantees, a real-time channel is also guaranteed to have a certain minimum message bandwidth and buffer space. The real-time channel model can also be extended to support performance guarantees for bidirectional and multicast communication.

For more information about real-time channels, the following papers are available:

o "Real-Time Communication in Multihop Networks" by Dilip D. Kandlur, Kang G. Shin, and Domenico Ferrari. (General introduction and overview)
o "Resource Management for Real-Time Communication: Making Theory Meet Practice" by Ashish Mehra, Atri Indiresan, and Kang Shin.
o "Structuring Communication Software for Quality-of-Service Guarantees" by Ashish Mehra, Atri Indiresan, and Kang Shin.

Software architecture




This figure depicts the key aspects of our proposed communication subsystem architecture at the source (transmitting) and destination (receiving) hosts. Only the components involved in run-time traffic management are illustrated. The key features of the proposed architecture include:
oa process-per-channel protocol processing model with per-channel handlers and message FIFOs
odeadline-based and priority-based CPU scheduling of channel handlers
odeadline-based link scheduling for network access
otraffic policing via interaction between CPU and link schedulers.
On the source host, invocation of message transmission transfers control to the API. After assignment of a deadline to the message, it is demultiplexed onto the corresponding channel's message FIFO for subsequent processing (including fragmentation) and transmission by the channel handler. With deadline-based CPU scheduling, channel handlers are assigned to one of three run queues based on their type (best-effort or real-time) and traffic generation/arrival (early or on-time) such that on-time real-time traffic gets the highest processing priority, followed by best-effort traffic and early real-time traffic in that order. Note that in this architecture all best-effort traffic is associated with a single (logical) channel. The packets generated by each handler are inserted in one of three packet queues, once again based on the channel's type and traffic generation/arrival; the relative priority assignment for the packet queues is similar to that for the handler run queues. While we allow CPU scheduling to be work-conserving, link scheduling is non-work-conserving to avoid stressing resources at downstream hosts.

At the destination host, the received packet is demultiplexed to the corresponding channel's packet FIFO for subsequent processing and reassembly. Channel handlers are assigned to CPU run queues, as in transmission processing. Once the last packet of a message arrives, the channel handler completes message reassembly and inserts the message into the corresponding message FIFO. The application retrieves the message from the message FIFO by invoking the API's receive routine.

In addition to policies for run-time traffic management of CPU and link resources, the proposed architecture provides policies for buffer management and protocols for channel establishment and teardown. For end-to-end guarantees, the policies for scheduling channel handlers (earliest-deadline-first and fixed-priority) must be integrated with those for application scheduling.

Real-Time Channel Application Programming Interface

Applications and middleware services use the interface below to create and communicate with real-time channels.

rtc_register: register intent to receive channel requests (by receiver)

rtc_open: open real-time channel to destination (by sender)

rtc_close: close existing real-time channel (by sender)

rtc_send: send message on existing real-time channel (by sender)

rtc_recv: receive message on existing real-time channel (by receiver)

Real-Time Channel Server Configuration



Our current implmentation realizes real-time channels as a user-level server in the OSF MK 7.2 operating system. The server is an x-Kernel process which implements all signalling and data transfer functions on behalf of applications wishing to use the service. Applications link with a new library, librtc, to access the real-time channel API.

The OSF version of x-Kernel introduces the notion of Paths which associate buffer and thread resources with specific connections. We take advantage of this facility to reserve resources for real-time channels and to multiplex UX server traffic with RTC server traffic.

x-Kernel RTC Server Configuration at Hosts



The real-time channel server is divided into two distinct but related portions:
RTC Signalling
o coordinated by new x-kernel protocol RTCOP (Real-Time Channel Ordination Protocol) running on each node
o reliable datagram semantics with consistent channel state management
o interface to RTROUTER (Real-Time Router) for routing policy
o RTROUTER interfaces to IP (unicast) routing
o interface to traffic control modules (admission control, traffic enforcement)
RTC Data Transfer
o push and pop on RTCOP by top-level anchor protocol
o management of CPU and link bandwidth to maintain QoS guarantees
o process-per-channel model for protocol processing at hosts
o early demultiplexing via efficient packet filter
Back to the project homepage.