Academia.eduAcademia.edu

Figure 16 – uploaded by Minh Huynh

See full PDFdownloadDownload figure
Fig. 18. A switch redundancy example.

Figure 18 A switch redundancy example.

Related Figures (36)

Fig. 1. Recurring Cost of Operation in a 3 year period study. Ethernet can save more than 50% over a 3 year period in a business case study from the MEF.
Fig. 1. Recurring Cost of Operation in a 3 year period study. Ethernet can save more than 50% over a 3 year period in a business case study from the MEF.
Fig. 2. Availability vs. recovery time for different frequency of failure. more than all the others in determining the market size for services and the resulting potential revenues [18]. The re- sult of one recent market analysis shows that 50% of sub- scribers expect at least the 99.99% service availability. Fig. 2 shows the recovery time for different failure rate and its availability in term of the number of 9s [18]. For example, if the recovery time is 100 min and the failure rate is 10 occurrences per year, then the availability is
Fig. 2. Availability vs. recovery time for different frequency of failure. more than all the others in determining the market size for services and the resulting potential revenues [18]. The re- sult of one recent market analysis shows that 50% of sub- scribers expect at least the 99.99% service availability. Fig. 2 shows the recovery time for different failure rate and its availability in term of the number of 9s [18]. For example, if the recovery time is 100 min and the failure rate is 10 occurrences per year, then the availability is
Fig. 3. Example of a linear topology with leaf nodes. The ring topology is popular in network deployment be- cause of its simplicity, deterministic behavior, and built-in
Fig. 3. Example of a linear topology with leaf nodes. The ring topology is popular in network deployment be- cause of its simplicity, deterministic behavior, and built-in
redundancy. Different variants of the ring topology are shown in Figs. 7-9. A ring topology creates a loop in the network that causes a frame to circulate infinitely. The management protocol must ensure that loops are elimi- nated while still able to exploit the advantages of the redundant links. In a multiple ring topology, all the rings can be managed by a single management instance, or dif- ferent management instances that intercommunicate. Fig. 7. Example of a single ring topology. A mesh topology is a general topology of a network. There are two types: a partial mesh and a full mesh, as shown in Fig. 10. Typically, there is more than one path be- tween any pair of source destination because of the redun- dant links in the mesh. The path with the best cost is used
redundancy. Different variants of the ring topology are shown in Figs. 7-9. A ring topology creates a loop in the network that causes a frame to circulate infinitely. The management protocol must ensure that loops are elimi- nated while still able to exploit the advantages of the redundant links. In a multiple ring topology, all the rings can be managed by a single management instance, or dif- ferent management instances that intercommunicate. Fig. 7. Example of a single ring topology. A mesh topology is a general topology of a network. There are two types: a partial mesh and a full mesh, as shown in Fig. 10. Typically, there is more than one path be- tween any pair of source destination because of the redun- dant links in the mesh. The path with the best cost is used
Fig. 4. Example of a branch from a linear topology.
Fig. 4. Example of a branch from a linear topology.
Fig. 10. Example of a mesh topology.
Fig. 10. Example of a mesh topology.
Fig. 9. Example of a multi-ring with redundancy between rings.
Fig. 9. Example of a multi-ring with redundancy between rings.
Fig. 11. Frequency of network related errors in a LAN across the OSI model. Network failures account for more than one third of IT related failures [1]. These failures can occur across all of the seven OSI layers. Fig. 11 shows the distribution of er- rors in a LAN across the OSI model. Misconfigurations are generally the main cause of failures in the link layer that resulted in corrupted forwarding tables, while a link fail- ures and node failures are the main causes in the physical layer. A link failure occurs when a cable damaged or when errors occur at the network interface. Usually this type of failure is localized and can be fixed quickly via the backup
Fig. 11. Frequency of network related errors in a LAN across the OSI model. Network failures account for more than one third of IT related failures [1]. These failures can occur across all of the seven OSI layers. Fig. 11 shows the distribution of er- rors in a LAN across the OSI model. Misconfigurations are generally the main cause of failures in the link layer that resulted in corrupted forwarding tables, while a link fail- ures and node failures are the main causes in the physical layer. A link failure occurs when a cable damaged or when errors occur at the network interface. Usually this type of failure is localized and can be fixed quickly via the backup
A summary of the requirements and recommendations for each type of application. Table 1
A summary of the requirements and recommendations for each type of application. Table 1
Requirements for end-users applications define in the ITU-T Recommendation G.114 [3].
Requirements for end-users applications define in the ITU-T Recommendation G.114 [3].
Performance requirements for multimedia applications define in the ITU-T Recommendation G.114.
Performance requirements for multimedia applications define in the ITU-T Recommendation G.114.
The typical grace time in an Industrial Network from IEC 62439. Table 4
The typical grace time in an Industrial Network from IEC 62439. Table 4
Performance requirement for PROFINET and SERCOS III (*in reality, 960 kbit/s and 108 kbit/s is the maximum instead of 3.2 Mbit/s and 408 kbit/s, respectively). Table 5
Performance requirement for PROFINET and SERCOS III (*in reality, 960 kbit/s and 108 kbit/s is the maximum instead of 3.2 Mbit/s and 408 kbit/s, respectively). Table 5
Fig. 13. Time division for IRT communication [7]. Most protocols in this category recover in less than the recommended recovery time of 1-3 s, except for STP. In other words, for applications other than the interactive voice message, all other services will operate without interruption during a failure. The few applications that re- cover in less than 1s can satisfy without interruption. As STP was designed well before the emergence of the mod- Running on specialized a ASIC, Isochronous Real-Time (IRT) is defined to have cycle times in the range of 150 Us to 1ms and 1 us jitter with the synchronization of all nodes. However, the fastest time supported by commercial equipment starts from 500 us [7]. IRT is deployed on tree or line topologies where it can support a maximum of 25 devices per line. To achieve deterministic behavior and low cycle time, IRT schedules real-time data at regular interval and inserts best-effort in between, as shown in
Fig. 13. Time division for IRT communication [7]. Most protocols in this category recover in less than the recommended recovery time of 1-3 s, except for STP. In other words, for applications other than the interactive voice message, all other services will operate without interruption during a failure. The few applications that re- cover in less than 1s can satisfy without interruption. As STP was designed well before the emergence of the mod- Running on specialized a ASIC, Isochronous Real-Time (IRT) is defined to have cycle times in the range of 150 Us to 1ms and 1 us jitter with the synchronization of all nodes. However, the fastest time supported by commercial equipment starts from 500 us [7]. IRT is deployed on tree or line topologies where it can support a maximum of 25 devices per line. To achieve deterministic behavior and low cycle time, IRT schedules real-time data at regular interval and inserts best-effort in between, as shown in
Fig. 12. Communication cycle time and their jitter [7].
Fig. 12. Communication cycle time and their jitter [7].
Comparison charts for resilient protocols operating in end-user environment. Table 6 ern applications its recovery time was acceptable, but it is now obsolete. The ring topology boasts the protocols with the fastest recovery time. Since the behavior on a ring is more predictable, it is easier to optimize the management protocol than with mesh networks. However, the recovery time of protocols managing ring networks with a central redundancy manager is directly proportional to the size of the ring. As the ring size grows, the failover time also grows making it difficult to sustain a failover time below 1s. Tables 6 and 7 summarizes the protocols that are suit- able for applications in this class of network performance. its topology. STP is standardized in IEEE 802.1d [12] to for- ward layer 2 frames. Using the shortest path to the central root, STP forms a tree that is overlaid on top of a mesh Ethernet Network as shown in Fig. 14. Unlike IP packets, Ethernet frames do not have a time-to-live field. Therefore, the Spanning Tree blocks redundant links in the topology to avoid a broadcast storm that can bring down the net- work. The drawback of this approach is that the links around the root will be heavily congested, leaving it at risk of failure and unbalance loads. Upon a failure, STP takes 30-60 s to recover.
Comparison charts for resilient protocols operating in end-user environment. Table 6 ern applications its recovery time was acceptable, but it is now obsolete. The ring topology boasts the protocols with the fastest recovery time. Since the behavior on a ring is more predictable, it is easier to optimize the management protocol than with mesh networks. However, the recovery time of protocols managing ring networks with a central redundancy manager is directly proportional to the size of the ring. As the ring size grows, the failover time also grows making it difficult to sustain a failover time below 1s. Tables 6 and 7 summarizes the protocols that are suit- able for applications in this class of network performance. its topology. STP is standardized in IEEE 802.1d [12] to for- ward layer 2 frames. Using the shortest path to the central root, STP forms a tree that is overlaid on top of a mesh Ethernet Network as shown in Fig. 14. Unlike IP packets, Ethernet frames do not have a time-to-live field. Therefore, the Spanning Tree blocks redundant links in the topology to avoid a broadcast storm that can bring down the net- work. The drawback of this approach is that the links around the root will be heavily congested, leaving it at risk of failure and unbalance loads. Upon a failure, STP takes 30-60 s to recover.
Comparison charts for resilient protocols operating in end-user environment (continue).
Comparison charts for resilient protocols operating in end-user environment (continue).
Table 7 Fig. 14. STP’s process of selecting root node and block redundant links to create a loop free topology.
Table 7 Fig. 14. STP’s process of selecting root node and block redundant links to create a loop free topology.
Fig. 15. An example of a MSTP configuration.
Fig. 15. An example of a MSTP configuration.
Fig. 17. A multi-ring topology in MRP-Foundry.
Fig. 17. A multi-ring topology in MRP-Foundry.
Comparison charts for resilient protocols operating in metro area network and multimedia environment. Table 8
Comparison charts for resilient protocols operating in metro area network and multimedia environment. Table 8
Comparison charts for resilient protocols operating in metro area network and multimedia environment (continue). Table 9
Comparison charts for resilient protocols operating in metro area network and multimedia environment (continue). Table 9
Fig. 19. Virtual concatenation (VC). Varadarajan et al. proposed Ethereal [20], a connection oriented architecture, to support assured service and best-effort service at the Ethernet layer. Ethereal uses the Propagation Order Spanning Tree for fast reconvergence once a failure has been detected. Utilizing periodic hello messages to immediate neighbors, a switch can detect a failure if there are missing consecutive hello messages. Once a fault has been detected, all best-effort traffic is dis- carded. The established QoS-assured flows are maintained unless part of the path is affected by the fault. The best-ef- fort flows behave consistent with the STP protocol, while requests to reserve paths with the required QoS parame- ters are required for QoS-assured traffic. Ethereal design is directly aiming at real-time multimedia traffic via hop- by-hop reservation. Similar to a MPLS, each switch makes a request to its immediate downstream hop for the flow reservation, whereupon the penultimate node sends a re- ply indicating whether the reservation was successful. The scalabilty of Ethereal is limited as only 65536 connec- tions can be supported. To protect Ethernet over SONET with a low overhead, Acharya et al. proposed PESO [22]. Traditional SONET uses a 1+1 protection, but this can be considered excessive since data traffic can tolerate failure and operate at a reduced rate. Depending on the protection requirements, PESO will compute an optimum routing path that uses virtual con- catenation (VC), as shown in Fig. 19, and Link Capacity Adjustment Scheme (LCAS) to make the necessary recov- ery. For the scenario where a single failure should not af- fect more than x% of the bandwidth, PESO transforms the link capacity in the topology to the equivalent of y lines. Each chosen line out of y cannot carry more than x% pro- tected bandwidth. PESO determines the number of mem- bers in the VC. Using a path augmentation maximum flow algorithm, such as Ford and Fulkerson [23] or Ed- monds and Karp [24], PESO determines the routes that the virtual concatenation group (VCG) will take. Upon fail- ure, LCAS removes the failed member resulting in a contin- uous connection with the destination but the throughput
Fig. 19. Virtual concatenation (VC). Varadarajan et al. proposed Ethereal [20], a connection oriented architecture, to support assured service and best-effort service at the Ethernet layer. Ethereal uses the Propagation Order Spanning Tree for fast reconvergence once a failure has been detected. Utilizing periodic hello messages to immediate neighbors, a switch can detect a failure if there are missing consecutive hello messages. Once a fault has been detected, all best-effort traffic is dis- carded. The established QoS-assured flows are maintained unless part of the path is affected by the fault. The best-ef- fort flows behave consistent with the STP protocol, while requests to reserve paths with the required QoS parame- ters are required for QoS-assured traffic. Ethereal design is directly aiming at real-time multimedia traffic via hop- by-hop reservation. Similar to a MPLS, each switch makes a request to its immediate downstream hop for the flow reservation, whereupon the penultimate node sends a re- ply indicating whether the reservation was successful. The scalabilty of Ethereal is limited as only 65536 connec- tions can be supported. To protect Ethernet over SONET with a low overhead, Acharya et al. proposed PESO [22]. Traditional SONET uses a 1+1 protection, but this can be considered excessive since data traffic can tolerate failure and operate at a reduced rate. Depending on the protection requirements, PESO will compute an optimum routing path that uses virtual con- catenation (VC), as shown in Fig. 19, and Link Capacity Adjustment Scheme (LCAS) to make the necessary recov- ery. For the scenario where a single failure should not af- fect more than x% of the bandwidth, PESO transforms the link capacity in the topology to the equivalent of y lines. Each chosen line out of y cannot carry more than x% pro- tected bandwidth. PESO determines the number of mem- bers in the VC. Using a path augmentation maximum flow algorithm, such as Ford and Fulkerson [23] or Ed- monds and Karp [24], PESO determines the routes that the virtual concatenation group (VCG) will take. Upon fail- ure, LCAS removes the failed member resulting in a contin- uous connection with the destination but the throughput
Need customized tuning for each individual network. Comparison charts for resilient protocols operating in Industrial Ethernet Networks. Table 10
Need customized tuning for each individual network. Comparison charts for resilient protocols operating in Industrial Ethernet Networks. Table 10
Comparison charts for resilient protocols operating in Industrial Ethernet Networks (continue). Table 11
Comparison charts for resilient protocols operating in Industrial Ethernet Networks (continue). Table 11
The maximum recovery time from a fault for CRP is:
The maximum recovery time from a fault for CRP is:
on the active interface, the end-nodes switch to the alter- nate interface. tpath = 6 x td = 0.174 s. There are different kinds of fault in a BRP network. Firstly, if the leaf link faults are detectable in the end node physical layer, the recovery time is less than 10 us [27]. Secondly, if the faults occurred in the direction of flow of beacon messages and those that are detectable in the node/switch physical layer, then the recovery time is less than 1 ms (two beacon timeouts) [27]. Lastly, if the faults occurred in the opposite direction to the flow of beacon messages, but are not detectable in the node/switch phys- ical layer, the recovery time is the worse case:
on the active interface, the end-nodes switch to the alter- nate interface. tpath = 6 x td = 0.174 s. There are different kinds of fault in a BRP network. Firstly, if the leaf link faults are detectable in the end node physical layer, the recovery time is less than 10 us [27]. Secondly, if the faults occurred in the direction of flow of beacon messages and those that are detectable in the node/switch physical layer, then the recovery time is less than 1 ms (two beacon timeouts) [27]. Lastly, if the faults occurred in the opposite direction to the flow of beacon messages, but are not detectable in the node/switch phys- ical layer, the recovery time is the worse case:
Fig. 24. BRP linear network example.
Fig. 24. BRP linear network example.
Fig. 23. BRP ring network example.
Fig. 23. BRP ring network example.
Fig. 25. BRP star network example.
Fig. 25. BRP star network example.
Parameters for a recovery example. Table 12
Parameters for a recovery example. Table 12
Related topics:
EngineeringTechnologyComputer NetworksFailure RecoveryNetwork ServicesPacket LossHome Network
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved