465:(UPC/NPC), which are implemented within the network, to limit the traffic on each VC separately. This allows the usage of the shared resources (switch buffers) in the network to be calculated from the parameters of the traffic to be carried in advance, i.e. at system design time. That they are implemented by the network means that these calculations remain valid even when other users of the network behave in unexpected ways, i.e. transmit more data than they are expected to. The calculated usages can then be compared with the capacities of these resources to show that, given the constraints on the routes and the bandwidths of these connections, the resource used for these transfers will never be over-subscribed. These transfers will therefore never be affected by congestion and there will be no losses due to this effect. Then, from the predicted maximum usages of the switch buffers, the maximum delay through the network can also be predicted. However, for the reliability and timeliness to be proved, and for the proofs to be tolerant of faults in and malicious actions by the equipment connected to the network, the calculations of these resource usages cannot be based on any parameters that are not actively enforced by the network, i.e. they cannot be based on what the sources of the traffic are expected to do or on statistical analyses of the traffic characteristics (see
484:
switches in the network enforce this timing to provide tolerance of faults in, and malicious actions on the part of, the other connected equipment. However, "synchronized local clocks are the fundamental prerequisite for time-triggered communication". This is because the sources of critical data will have to have the same view of time as the switch, in order that they can transmit at the correct time and the switch will see this as correct. This also requires that the sequence with which a critical transfer is scheduled has to be predictable to both source and switch. This, in turn, will limit the transmission schedule to a highly deterministic one, e.g. the
38:
267:, meaning that as long as at least a single copy of a message remains available at any of the recipients, every other recipient that does not fail eventually also receives a copy. Strong reliability properties such as this one typically require that messages are retransmitted or forwarded among the recipients.
491:
However, low latency in transferring data over the bus or network does not necessarily translate into low transport delays between the application processes that source and sink this data. This is especially true where the transfers over the bus or network are cyclically scheduled (as is commonly the
495:
With both AFDX and TTEthernet, there are additional functions required of the interfaces, e.g. AFDX's
Bandwidth Allocation Gap control, and TTEthernet's requirement for very close synchronization of the sources of time-triggered data, that make it difficult to use standard Ethernet interfaces. Other
483:
TTEthernet provides the lowest possible latency in transferring data across the network by using time-domain control methods – each time triggered transfer is scheduled at a specific time so that contention for shared resources is controlled and thus the possibility of congestion is eliminated. The
434:
systems. It uses a bus controller (BC) to command the connected remote terminals (RTs) to receive or transmit this data. The BC can, therefore, ensure that there will be no congestion, and transfers are always timely. The MIL-1553 protocol also allows for automatic retries that can still ensure
209:
If a network does not guarantee packet delivery, then it becomes the host's responsibility to provide reliability by detecting and retransmitting lost packets. Subsequent experience on the ARPANET indicated that the network itself could not reliably detect all packet delivery failures, and this
259:
protocols can be expressed on a per-recipient basis (simple reliability properties), or they may relate the fact of delivery or the order of delivery among the different recipients (strong reliability properties). In the context of multicast protocols, strong reliability properties express the
404:
to perform at some specified minimum level. This, in turn, requires that a specified minimum reliability for the delivery of the critical data be met. Therefore, in these cases, it is only the delivery that matters; notification of the failure to deliver does ameliorate the failure. In
292:
across an unreliable infrastructure whilst being able to make certain guarantees about the successful transmission of the messages. For example, that if the message is delivered, it is delivered at most once, or that all messages successfully delivered arrive in a particular order.
278:. The property states that if at least a single copy of a message has been delivered to a recipient, all other recipients will eventually receive a copy of the message. In other words, each message is always delivered to either all or none of the recipients.
454:(TTEthernet) are examples of packet-switched networks protocols where the timeliness and reliability of data transfers can be assured by the network. AFDX and TTEthernet are also based on IEEE 802.3 Ethernet, though not entirely compatible with it.
191:(IMP). Once the message was delivered to the destination host, an acknowledgment was delivered to the sending host. If the network could not deliver the message, the IMP would send an error message back to the sending host.
347:
is a flexible platform that allows strong reliability properties to be expressed in a purely declarative manner, using a simple rule-based language, and automatically translated into a hierarchical protocol.
480:
so it can be proved not to affect the critical data. However, the techniques for predicting the resource requirements and proving that congestion is prevented are not part of the AFDX standard.
187:. A host computer simply arranged the data in the correct packet format, inserted the address of the destination host computer, and sent the message across the interface to its connected
376:
attempts to provide reliable service for all traffic. The sending station will resend a frame if the sending station does not receive an ACK frame within a predetermined period of time.
245:
In the context of distributed protocols, reliability properties specify the guarantees that the protocol provides with respect to the delivery of messages to the intended recipient(s).
439:, is, in effect, a version of MIL-1553 augmented with a 20 Mbit/s shared media bus for data transfers, retaining the 1 Mbit/s shared media bus for control purposes.
667:
202:
demonstrated that it was possible to build an effective computer network without providing reliable packet transmission. This lesson was later embraced by the designers of
98:
Reliable protocols typically incur more overhead than unreliable protocols, and as a result, function more slowly and with less scalability. This often is not an issue for
492:
case with MIL-STD-1553B and STANAG 3910, and necessarily so with AFDX and TTEthernet) but the application processes are not synchronized with this schedule.
496:
methods for control of the traffic in the network that would allow the use of such standard IEEE 802.3 network interfaces is a subject of current research.
430:. MIL-1553 uses a 1 Mbit/s shared media for the transmission of data and the control of these transmissions, and is widely used in federated military
728:
759:
447:
56:
809:
388:. In such systems, failure to deliver the real-time data will adversely affect the performance of the systems, and some systems, e.g.
622:
473:
676:
586:
435:
timely delivery and increase the reliability above that of the physical layer. STANAG 3910, also known as EFABus in its use on the
83:
that notifies the sender whether or not the delivery of data to intended recipients was successful. Reliability is a synonym for
843:
344:
132:
or in other situations where speed is an issue and some data loss may be tolerated because of the transitory nature of the data.
564:
In nearly all respects, Davies' original proposal, developed in late 1965, was similar to the actual networks being built today.
476:, that allows the traffic on each virtual link to be limited so that the requirements for shared resources can be predicted and
656:
Dan
Rubenstein, Jim Kurose, Don Towsley, ”Real-Time Reliable Multicast Using Proactive Forward Error Correction”, NOSSDAV ’98
528:
340:
416:
There are a number of protocols that are capable of addressing real-time requirements for reliable delivery and timeliness:
309:
235:
109:
275:
696:
Kim, Y. J.; Chang, S. C.; Un, C. K.; Shin, B. C. (March 1996). "UPC/NPC algorithm for guaranteed QoS in ATM networks".
705:
188:
545:
308:
A reliable delivery protocol can be built on an unreliable protocol. An extremely common example is the layering of
838:
443:
363:
324:
252:
protocol is "at least once", i.e. at least one copy of the message is guaranteed to be delivered to the recipient.
148:
647:
S., Schneider, G., Pardo-Castellote, M., Hamilton. “Can
Ethernet Be Real Time?”, Real-Time Innovations, Inc., 2001
210:
pushed responsibility for error detection onto the sending host in any case. This led to the development of the
735:
47:
520:
451:
384:
There is, however, a problem with the definition of reliability as "delivery or notification of failure" in
239:
176:
121:
80:
410:
406:
260:
guarantees that the protocol provides with respect to the delivery of messages to different recipients.
477:
352:
297:
211:
117:
436:
385:
136:
72:
815:
103:
413:, late data is still valueless but the system can tolerate some amount of late or missing data.
805:
753:
618:
599:
Service
Specific Coordination Function for Transparent Assured Delivery with AAL5 (SSCF-TADAS)
524:
313:
282:
231:
52:
514:
797:
709:
602:
485:
466:
397:
300:, where there is no guarantee that messages will be delivered quickly, in order, or at all.
168:
601:, Military Communications Conference Proceedings, 1999. MILCOM 1999, vol.2, pages 878–882.
773:
458:
393:
389:
332:
289:
184:
140:
129:
401:
125:
409:, all data must be delivered by the deadline or it is considered a system failure. In
366:
Service-Specific
Coordination Function provides for transparent assured delivery with
147:
and port numbers. However, some unreliable protocols are connection oriented, such as
832:
713:
419:
172:
819:
17:
462:
423:
373:
156:
152:
801:
782:, S. Kowalewski and M. Roveri (Eds.), FMICS 2010, LNCS 6371, pp. 148–163, 2010.
606:
575:
144:
226:
A reliable service is one that notifies the user if delivery fails, while an
256:
92:
792:
D. W. Charlton; et al. (2013), "An
Avionic Gigabit Ethernet Network",
431:
427:
215:
203:
199:
195:
113:
336:
249:
180:
99:
638:, Recommendation I.363.5, International Telecommunication Union, 1998.
183:
was a reliable packet delivery procedure to connect its hosts via the
317:
461:(VCs) which have fully deterministic paths through the network, and
116:, is a reliable unicast protocol; it provides the abstraction of a
426:
are well-known examples of such timely and reliable protocols for
328:
367:
356:
684:
Each system has its own computers performing its own functions
88:
31:
230:
one does not notify the user if delivery fails. For example,
281:
One of the most complex strong reliability properties is
794:
Avionics, Fiber-Optics and
Photonics Conference (AVFOP)
155:. In addition, some connectionless protocols, such as
636:
B-ISDN ATM Adaptation Layer specification: Type 5 AAL
617:
ATM Forum, The User
Network Interface (UNI), v. 3.1,
516:
How the Web was Born: The Story of the World Wide Web
472:
AFDX uses frequency domain bandwidth allocation and
139:. For example, TCP is connection oriented, with the
351:One protocol that implements reliable messaging is
270:An example of a reliability property stronger than
238:(TCP) and IP provide a reliable service, whereas
263:An example of a strong reliability property is
234:(IP) provides an unreliable service. Together,
124:is an unreliable protocol and is often used in
323:Strong reliability properties are offered by
8:
669:Avionic Architectures Trends and challenges
248:An example of a reliability property for a
135:Often, a reliable unicast protocol is also
102:protocols, but it may become a problem for
544:Roberts, Dr. Lawrence G. (November 1978).
296:Reliable delivery can be contrasted with
587:WS-ReliableMessaging specification (PDF)
242:(UDP) and IP provide an unreliable one.
143:ID consisting of source and destination
505:
758:: CS1 maint: archived copy as title (
751:
448:Avionics Full-Duplex Switched Ethernet
772:Wilfried Steiner and Bruno Dutertre,
355:, which handles reliable delivery of
288:Reliable messaging is the concept of
112:(TCP), the main protocol used on the
7:
775:SMT-Based Formal Verification of a
546:"The Evolution of Packet Switching"
463:usage and network parameter control
27:Protocol acknowledgement capability
513:Gillies, J.; Cailliau, R. (2000).
218:'s fundamental design principles.
25:
704:(3). Amsterdam, the Netherlands:
345:QuickSilver Properties Framework
87:, which is the term used by the
36:
576:W3C paper on reliable messaging
341:QuickSilver Scalable Multicast
1:
457:ATM uses connection-oriented
310:Transmission Control Protocol
236:Transmission Control Protocol
194:Meanwhile, the developers of
110:Transmission Control Protocol
714:10.1016/0140-3664(96)01063-8
706:Elsevier Science Publishers
325:group communication systems
255:Reliability properties for
189:Interface Message Processor
62:Proposed since August 2024.
45:It has been suggested that
860:
802:10.1109/AVFOP.2013.6661601
625:, Prentice Hall PTR, 1995.
607:10.1109/MILCOM.1999.821329
444:Asynchronous Transfer Mode
149:Asynchronous Transfer Mode
316:, a combination known as
796:, IEEE, pp. 17–18,
779:Synchronization Function
597:Young-ki Hwang, et al.,
48:Fault-tolerant messaging
844:Reliability engineering
698:Computer Communications
521:Oxford University Press
452:Time Triggered Ethernet
411:firm real-time systems
407:hard real-time systems
240:User Datagram Protocol
222:Reliability properties
214:, which is one of the
177:communication protocol
81:communication protocol
171:concepts proposed by
478:congestion prevented
353:WS-ReliableMessaging
298:best-effort delivery
212:end-to-end principle
118:reliable byte stream
55:into this article. (
437:Eurofighter Typhoon
386:real-time computing
137:connection oriented
73:computer networking
553:IEEE Invited Paper
523:. pp. 23–25.
428:avionic data buses
396:, and some secure
104:reliable multicast
18:Reliable messaging
839:Network protocols
811:978-1-4244-7348-9
400:systems, must be
380:Real-time systems
314:Internet Protocol
283:virtual synchrony
232:Internet Protocol
120:to applications.
69:
68:
64:
16:(Redirected from
851:
823:
822:
789:
783:
770:
764:
763:
757:
749:
747:
746:
740:
734:. Archived from
733:
724:
718:
717:
693:
687:
686:
681:
675:, archived from
674:
663:
657:
654:
648:
645:
639:
632:
626:
615:
609:
595:
589:
584:
578:
573:
567:
566:
561:
559:
550:
541:
535:
534:
510:
486:cyclic executive
474:traffic policing
467:network calculus
459:virtual channels
398:mission-critical
272:last copy recall
265:last copy recall
169:packet switching
167:Building on the
159:, are reliable.
60:
40:
39:
32:
21:
859:
858:
854:
853:
852:
850:
849:
848:
829:
828:
827:
826:
812:
791:
790:
786:
771:
767:
750:
744:
742:
738:
731:
729:"Archived copy"
727:
726:AFDX Tutorial,
725:
721:
695:
694:
690:
682:on 2015-02-03,
679:
672:
665:
664:
660:
655:
651:
646:
642:
633:
629:
616:
612:
596:
592:
585:
581:
574:
570:
557:
555:
548:
543:
542:
538:
531:
512:
511:
507:
502:
394:safety-involved
390:safety-critical
382:
333:Appia framework
327:(GCSs) such as
306:
304:Implementations
290:message passing
224:
165:
141:virtual-circuit
130:streaming media
65:
41:
37:
28:
23:
22:
15:
12:
11:
5:
857:
855:
847:
846:
841:
831:
830:
825:
824:
810:
784:
765:
719:
688:
658:
649:
640:
627:
610:
590:
579:
568:
536:
529:
504:
503:
501:
498:
381:
378:
305:
302:
223:
220:
185:1822 interface
164:
161:
126:computer games
79:protocol is a
67:
66:
44:
42:
35:
26:
24:
14:
13:
10:
9:
6:
4:
3:
2:
856:
845:
842:
840:
837:
836:
834:
821:
817:
813:
807:
803:
799:
795:
788:
785:
781:
780:
776:
769:
766:
761:
755:
741:on 2015-06-18
737:
730:
723:
720:
715:
711:
707:
703:
699:
692:
689:
685:
678:
671:
670:
662:
659:
653:
650:
644:
641:
637:
631:
628:
624:
623:0-13-393828-X
620:
614:
611:
608:
604:
600:
594:
591:
588:
583:
580:
577:
572:
569:
565:
558:September 10,
554:
547:
540:
537:
532:
526:
522:
518:
517:
509:
506:
499:
497:
493:
489:
487:
481:
479:
475:
470:
468:
464:
460:
455:
453:
449:
445:
440:
438:
433:
429:
425:
421:
420:MIL-STD-1553B
417:
414:
412:
408:
403:
399:
395:
391:
387:
379:
377:
375:
371:
369:
365:
360:
358:
354:
349:
346:
342:
338:
334:
330:
326:
321:
319:
315:
311:
303:
301:
299:
294:
291:
286:
284:
279:
277:
273:
268:
266:
261:
258:
253:
251:
246:
243:
241:
237:
233:
229:
221:
219:
217:
213:
207:
205:
201:
197:
192:
190:
186:
182:
178:
174:
173:Donald Davies
170:
162:
160:
158:
154:
150:
146:
142:
138:
133:
131:
127:
123:
119:
115:
111:
107:
105:
101:
96:
94:
90:
86:
82:
78:
74:
63:
58:
54:
50:
49:
43:
34:
33:
30:
19:
793:
787:
778:
774:
768:
743:. Retrieved
736:the original
722:
701:
697:
691:
683:
677:the original
668:
666:Mats Ekman,
661:
652:
643:
635:
630:
613:
598:
593:
582:
571:
563:
556:. Retrieved
552:
539:
515:
508:
494:
490:
482:
471:
456:
450:(AFDX), and
441:
418:
415:
383:
372:
361:
350:
322:
307:
295:
287:
280:
271:
269:
264:
262:
254:
247:
244:
227:
225:
208:
193:
175:, the first
166:
145:IP addresses
134:
108:
97:
84:
76:
70:
61:
46:
29:
708:: 216–225.
446:(ATM), the
424:STANAG 3910
374:IEEE 802.11
157:IEEE 802.11
153:Frame Relay
106:protocols.
833:Categories
777:TTEthernet
745:2015-02-03
530:0192862073
500:References
359:messages.
228:unreliable
276:atomicity
257:multicast
93:ATM Forum
85:assurance
754:cite web
432:avionics
216:Internet
204:Ethernet
200:ALOHAnet
196:CYCLADES
114:Internet
77:reliable
820:3162009
634:ITU-T,
337:JGroups
312:on the
250:unicast
198:and of
181:ARPANET
179:on the
163:History
100:unicast
57:Discuss
818:
808:
621:
527:
402:proved
343:. The
318:TCP/IP
53:merged
816:S2CID
739:(PDF)
732:(PDF)
680:(PDF)
673:(PDF)
549:(PDF)
329:IS-IS
806:ISBN
760:link
619:ISBN
560:2017
525:ISBN
442:The
422:and
368:AAL5
362:The
357:SOAP
151:and
91:and
75:, a
798:doi
710:doi
603:doi
469:).
364:ATM
339:or
274:is
122:UDP
89:ITU
71:In
51:be
835::
814:,
804:,
756:}}
752:{{
702:19
700:.
562:.
551:.
519:.
488:.
392:,
370:.
335:,
331:,
320:.
285:.
206:.
128:,
95:.
800::
762:)
748:.
716:.
712::
605::
533:.
59:)
20:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.