ARMADA Middleware and Communication Services T. ABDELZAHER, M. BJORKLUND, S. DAWSON, W.-C. FENG, F. JAHANIAN, S. JOHNSON, P. MARRON, A. MEHRA, T. MITTON, A. SHAIKH, K. SHIN, Z. WANG, H. ZOU Real-Time Computing Laboratory University of Michigan Presented by Guoliang Xing

Agenda Introduction RTCAST Group Comm. Service Real-Time Channel Architecture Platforms RTPB Replication Service Evaluation Tools

Target Applications Embedded fault-tolerant applications Industrial and manufacturing systems Distributed multimedia Air traffic control

Key Challenges Timely delivery of services with end-to-end real-time constraints Dependability of services in the presence of h/s failures Scalability of computation and communication resources Exploitation of open systems and emerging standards in operating systems and communication services

ARMADA Architecture Applications Middleware Services Evaluation Tools API Real-Time Channels Microkernel

RTCAST Multicast comm. and group management in timely fashion, with faults

Group Communication Reliable message delivery Agreement on group membership Failure detection and handling Consistency Atomicity: either everybody gets the message or nobody gets it Global order

Real-time Group Comm. Late message means failure Atomic, ordered message delivery in timely fashion Immediate message delivery without compromising the above

Achieve reliability, atomicity, RT Reliability: e ach member either receives a multicast message m or crashes before receiving m Atomicity: correct members receive all message and in the same order Time-bounded multicast: each member either receives each multicast m in total order within T time units or crashes during T before receiving m

RTCAST - Architecture Real-time Process Groups API Clock SynchronizationVirtual Network Interface Unicast Datagram Communication Admission Control and Schedulability Analysis Group Membership Service Timed Atomic Multicast

System Model Assumptions: each processor has its own unique identifier a path exists between any two processors communication delay is bounded (in the absence of failures) synchronized clocks Failures processors may suffer performance or crash failures messages may suffer performance or omission failures

Agreement on membership All members have the same membership view at group initialization time For each membership update U which changes membership view from V to V’, U is delivered atomically (in order) to all members in V U V’ within T time units

Steady-state operation

Token Ring: ensure order A processor sends messages only after holds token Upon receiving the token sends multicast messages within maximum token hold time sends a heartbeat which is a token to successor Upon receiving a multicast message deliver to application in sequence if message omission detected, crash

Steady-state operation– contd.

Handle faults

Membership Changes Processor crashes Each processor checks the heartbeats from members when its turn comes Send membership update multicast Joins Sends a join request to some processor which multicasts membership change message Joining processor checks the consistence of membership views sent in ACKs

Token Rotation Period P token – Token rotation time T i – maximum token hold time at any processor n – number of processes d max – comm. delay

Admission Control Goal: Only admit affordable messages Assumptions: Each sender can transmit messages for up to Tj units of time within P Time elapsed between the send and delivery is bounded by Δ

Admission Control – Contd. Real-time message: Maximum transmission time C i, period P i, deadline d i Sufficient Schedulability Condition:

Implementation

Agenda Introduction RTCAST Group Comm. Service Real-Time Comm. Architecture Platforms RTPB Replication Service Evaluation Tools Conclusion

RT Channel Architecture

RT Comm. Architecture – Contd. Real-time channel: unicast virtual connection between two hosts with bounded end-to-end delay guarantee RTC API: Clip: endpoint with QoS parameters RTCOP: Signaling and resource reservation QoS model & Admission control:

RTC API

RTCOP-Contd. Real-Time Connection Ordination Protocol: Distributed end-to-end signaling Request and reply handler: manage signaling state and interface to admission control Comm. module: reliably forward signaling message Signaling connection is non-real-time but reliable

RTCOP

Resource scheduling

Resource scheduling- Contd. QoS-sensitive CPU scheduling: Each message must be sent within deadline Comm. Handler scheduled with EDF policy Resource reservation: Associate each Comm. Handler with budget Policing: Link bandwidth allocation: Dynamic priority based link scheduler

Resource Scheduling – contd.

Traffic isolation in RTC

Agenda Introduction RTCAST Group Comm. Service Real-Time Comm. Architecture Platforms RTPB Replication Service Evaluation Tools Conclusion

Platforms Microkernel x-kernel: Co- located server UDP/IP

RTPB Architecture Many RT applications can tolerate minor inconsistencies in replicated state Backup maintains a less current copy of primary Distance between the primary and backup data is bounded within a time window

Evaluation Tools - ORCHESTRA A distributed protocol is viewed as an abstraction layer through which participants communicate by exchanging messages A probe/fault injection (PFI) layer is inserted between any two consecutive layers in a protocol stack. PFI layer can delay, drop, reorder, duplicate, modify, introducing spontaneous messages

Conclusions Middleware Services for fault-tolerant group communication Real-time communication services validation tools

Questions?