ARMADA Middleware and Communication Services

1. 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

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

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

4. Key Challenges • Timely delivery of services with end-to-end real-time constraints • Dependabilityof 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

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

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

7. 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

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

9. Achieve reliability, atomicity, RT • Reliability: each 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

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

11. 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

12. 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

13. Steady-state operation

14. 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

15. Steady-state operation– contd.

16. Handle faults

17. 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

18. Token Rotation Period • Ptoken – Token rotation time • Ti – maximum token hold time at any processor • n – number of processes • dmax – comm. delay

19. 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 Δ

20. Admission Control – Contd. • Real-time message: Maximum transmission time Ci, period Pi, deadline di • Sufficient Schedulability Condition:

21. Implementation

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

23. RT Channel Architecture

24. 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:

25. RTC API

26. 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

27. RTCOP

28. Resource scheduling

29. 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

30. Resource Scheduling – contd.

31. Traffic isolation in RTC

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

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

34. 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

35. 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

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

37. Questions?