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

5
ARMADA Architecture
Applications
Middleware Services
Evaluation Tools
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?