Optical Networks: A Practical Perspective - Part 62 ppt

580 NETWORK SURVIVABILITY These protection routing tables are similar to the routing tables maintained in IP networks, which work well even in very large IP networks with thousands of nodes. However, we need to realize that routing tables in IP networks are not always consistent. If the tables are inconsistent, routing pathologies, such as looping, can be present in the network with fairly high probabilities. For example, at the end of 1995, the likelihood of encountering a major routing pathology in the Internet was 3.3% [Pax97]. These pathologies can cause packets to be forwarded incorrectly in the network, but these packets eventually find their way to their destination or are dropped by the network. In the latter event, the packets are retransmitted by a higher-layer protocol (TCP). While this approach works well in IP networks, we cannot afford to have routing pathologies in transport networks because they could prevent restoration of service after a failure. Therefore, fast and reliable topology update mechanisms need to be in place to maintain the protection routing tables. We now look at the different variations of mesh protection. One aspect of this is whether the entire network is protected as a single domain, or whether it is broken down into multiple domains, with each domain protected independently, and the different domains then tied together. In a degenerate scenario, each domain could be a single ring, in which case we get back to the usual mode of ring-based protection. Another important aspect that differentiates protection schemes is whether the protection routes are precomputed ahead of time (offline), or whether they are com- puted after a failure has occurred (online). In both cases, another dimension to consider is the degree of distributed implementation. This affects the complexity of the signaling protocols required and has a direct impact on the speed of restoration. Let us first consider the case where the protection routes are precomputed. In this case, the protection route for a lightpath is computed at the time it is set up and stored in the network. Sufficient bandwidth is allocated on all the links so as to ensure the lightpath can be restored in the event of any possible failure. (Note that this protection bandwidth is still shared among many lightpaths and is not dedicated to a single lightpath. This is the distinction between 1 + 1 dedicated protection and shared protection.) Depending on the sophistication of the scheme used, there may be one or many possible alternate routes for a given lightpath, based on the actual failure scenario. For example, the simplest scenario is to compute a single disjoint path through the network as the protection route. Alternatively, we may use multiple protection routes, based on which link fails in the network. Clearly the amount of information needed to be stored in the network depends on the number of protection routes per lightpath. 10.5 Optical Layer Protection Schemes 581 In a centralized implementation of this scheme, a central controller in the network is notified if a failure occurs. The central controller then sets up all the alternate routes for the lightpaths by signaling to all the affected network elements to reconfigure their switches as needed. The problem with this approach is that the central controller is a single point of failure and is likely to be a significant bottleneck, both in terms of communication and processing speed. Several variants of a distributed implementation are possible. In one variant, the failure information is flooded to all the network nodes. Each node then looks up its routing table and reconfigures its switch, based on the exact failure that occurred. Another possibility is to signal the failure to the sources/destinations of all the affected lightpaths. Each source-destination pair then sets up the alternate routing path by signaling to the nodes along the new path. Next let us consider computing routes on the fly. In this case, new routes are computed after the failure has been discovered. One major issue that comes up in this context is whether sufficient bandwidth is available in the network to handle all the lightpaths that need to be restored. Without essentially precomputing the routes, it is not possible to determine the amount of protection bandwidth needed a priori. In this case, it is possible that some lightpaths are restored and others aren't. Again this scheme can be implemented in a centralized or distributed manner. The distributed implementation is more complex than for the case where routes are precomputed. Here it is possible that multiple nodes acting independently may con- tend for the same link or wavelength resource to restore two independent lightpaths. These contentions will have to be dealt with, making the signaling scheme more com- plex and the recovery possibly slower. A centralized implementation would avoid such conflicts, but would suffer even worse communication and processing bottle- necks, compared to the centralized implementation for the case where the routes are precomputed. Based on our discussions so far, we see that mesh protection requires the fol- lowing functions: route computation, topology maintenance, and signaling to set up the protection routes. These functions have been implemented in IP and ATM networks. For example, in IP networks, route computation is done using a Dijkstra shortest-path-first algorithm, and the topology is maintained using a routing pro- tocol such as OSPF (open shortest path first). Signaling has been used to establish paths in MPLS networks and ATM networks. Several signaling protocols are avail- able for this purpose, including the resource reservation protocol (RSVP) [BZB+97], private network-network interface (PNNI) signaling protocol [ATM96], and Signal- ing System 7 (SS7) [ITU93]. Today, there is a significant amount of work under way to expand MPLS (called GMPLS, for generalized MPLS) [AR01] to provide similar capabilities in optical networks. 582 NETWORK SURVIVABILITY 10.5.9 Choice of Protection Technique We have explored a number of different optical layer protection options. It is still too early to determine which ones will be deployed widely. An operator wanting to offer the different types of protection on the lightpaths as discussed in Section 10.4.1 must use an OCh layer protection method. On the other hand, an operator who is satisfied with protecting all lightpaths together will likely prefer an OMS layer scheme. Many of the protection schemes discussed above are being implemented in commercial products. 10.6 Interworking between Layers We have seen that protection functions can be done in the optical layer, SONET/SDH layers, or in the service layer (IP/ATM). How should protection in the network be coordinated between all these layers? By default, the protection mechanisms in different layers will work independently. In fact, a single failure might trigger multiple protection mechanisms, all trying to restore service simultaneously, which would result in a large number of unneces- sary alarms flooding the management center. This results in allocating protection bandwidth at each of the layers, which is inefficient. An area of significant concern is that protection mechanisms in different layers could potentially contend with each other, preventing or delaying service restoration, although careful design can eliminate such occurrences. The following argument shows that multilayer protection schemes will eventually converge and restore traffic under the right assumptions: Consider two network layers, a client layer operating over a server layer, each with its own protection mechanisms. If the following conditions are met, the network will always restore traffic in the event of a failure: 1. A viable protection path exists for each layer. 2. The server layer does not depend on the client layer to detect failures and invoke its protection-switching functions. 3. The client layer protection is revertive in the sense that it will repeatedly try switching to the other path if its current path fails. Observe that since the server layer is independent of the client layer and does not depend on client layer indicators, in the event of a failure, the server layer will detect the failure and restore the traffic. After the failure occurs, there may be a period of time when the client layer is unable to restore service because the server Summary 583 layer is invoking its protection scheme. Ultimately, since the server layer converges, the client layer will see either a working path or a protection path available for it, and will therefore eventually converge. If any of the conditions above are not met, then the protection scheme may not converge. For example, if the client layer protection is ~nonrevertive, it may switch over once to the protection path, discover that path is not available, and not switch back to its primary path. While it is desirable to have some sort of coordination between protection mecha- nisms in different layers, this may not always be possible. For example, the protection mechanisms in different layers may actually be activated by different nodes. In some cases, it may be possible to add a priority mechanism where one layer attempts to restore service first, and only afterwards does the second layer try. One automatic way to ensure this is to have the restoration in one layer happen so quickly that the other layer doesn't even sense that a failure has occurred. For example, consider a WDM network carrying IP traffic. As we saw in Section 10.3, it can take several seconds for the IP layer to detect a failure. It is entirely feasible for the optical layer to have completed its restoration within this time scale so that the IP layer doesn't detect the failure. This may not, however, be feasible when we have SONET rings operating over a WDM network. The SONET rings detect failures very quickly and can initiate protection switching as early as 2.3 #s after a failure occurs. Another way to implement orderly restoration would be to impose an additional hold-off time in the higher layer before it attempts restoration so as to provide sufficient time for the lower layer to do its restoration. However, a large hold-off time would increase the overall restoration time and is therefore not highly desirable either. In general, it would make sense to have the priorities arranged such that the layer that can provide the fastest restoration tries first. Summary Engineering the network for survivability plays an increasingly important role in transport networks. Protection techniques are well established in SONET and SDH and include point-to-point, dedicated protection rings, and shared protection rings. Point-to-point protection schemes work for simple systems with diverse fiber routes between node locations. Dedicated protection rings are primarily used to aggregate traffic from remote locations to one or two hub locations. Shared protection rings are used in the core parts of the network where the traffic is more distributed. Protection in the optical layer is emerging, with several commercial products now implementing optical layer protection. Optical layer protection is needed to protect the data services that are increasingly being transported directly on the optical layer 5 84 NETWORK SURVIVABILITY without the SONET/SDH layer being present. It can also be more efficient with respect to reducing the protection bandwidth required (by sharing the bandwidth across multiple clients) and therefore more cost-effective. Optical channel layer protection is needed if some channels are to be protected while others are not. Optical multiplex section layer protection is more cost-effective for those cases where all the traffic needs to be protected. There is a growing trend toward the use of shared mesh protection in the optical layer, which is viewed as being more bandwidth-efficient and flexible, compared to the traditional ring-based approaches. Further Reading There is a vast literature on protection in SONET and SDH networks. SONET rings and protection schemes are described in ANSI T1.105.1 and Telcordia GR-253 and GR-1230. ITU G.841 describes the equivalent SDH architectures. We also refer the reader to the books by Sexton and Reid [SR97] and Wu [Wu92]. Providing reliable service in IP and MPLS networks is a topic of great interest today. Several protection schemes are being developed. See, for example, [DR00, Section 7.4], [CO99], and several Internet drafts available at www.ietf.org. There is a lot of activity under way on optical layer protection schemes, with several being implemented in products today. These have not yet been standard- ized. [DWY99, RM99a, RM99b, Ram01, MM00, Bar00, GR00a, GR00b, Dos99, MBN99, Wu95, WO95, Tel98, GR96, GRS97] provide good coverage of the major issues. Interworking of protection schemes between different layers is covered in [Dem99, MB96]. 10.1 10.2 10.3 Problems Consider a shared protection ring with two types of restoration possible. In the first scheme, the connection is rerouted by the source and destination around the ring in the event of a failure. In the second, the connection is rerouted around the ring by the nodes adjacent to the failed link (as in a BLSR). Give an example of a traffic pattern where the first scheme uses less ring bandwidth than the second. Give another example where the two require the same amount of bandwidth. Show that in a ring architecture if the protection capacity is less than the working capacity, then service cannot be restored under certain single failure conditions. Compare the performance of UPSRs and BLSR/2s in cases where all the traffic is between a hub node and the other nodes. Assume the same ring speed in both Problems 585 Figure 10.24 Network topology for Problem 10.6. 10.4 10.5 10.6 cases. Is a BLSR/2 any more efficient than a UPSR in traffic-carrying capacity in this scenario? Construct a traffic distribution for which the traffic-carrying capacity of a BLSR/4 is maximized. What is this capacity as a multiple of the bit rate on the working fibers? Assuming a uniform traffic distribution, compute the traffic-carrying capacity of a BLSR/4 as a multiple of the bit rate on the working fibers. Consider the topology shown in Figure 10.24 over which STS-ls are to be transported as dictated by the bandwidth demands specified in the table below for each node pair. Assume all the bandwidth requirements are bidirectional. STS-1 B C D E A 12 6 4 12 B 8 10 6 C 12 2 D 8 Given the fiber topology and the STS-l-based bandwidth requirements, we will utilize a two-fiber OC-N SONET ring architecture, but we need to determine which SONET ring architecture is the most suitable for the given network~the UPSR or the BLSR/2. (a) Provide a detailed illustration of how the six STS-ls between nodes A and C would be transported by a UPSR and a BLSR/2. Redraw Figure 10.24 to begin each illustration. (b) Suppose that a backhoe cuts the fiber pair between nodes B and C. Again, redrawing Figure 10.24 and referencing your illustrations above, provide a detailed illustration of how the six STS-ls between nodes A and C would be transported just after this failure for the UPSR and the BLSR/2. Use dashed lines to highlight any differences in the routing from normal operation. 586 NETWORK SURVIVABILITY 10.7 10.8 10.9 10.10 10.11 10.12 (c) Using the bandwidth demands given in the table above, design best-case ring routing plans for the UPSR and the BLSR/2. Illustrate the routing on the network topology of Figure 10.24. In addition, specify the quantity of STS-ls being transported over each fiber link for both cases. (d) Assuming that we want to use a single OC-N ring, what would be the minimum standard value of N in each case for the designed UPSR and BLSR/2? (e) Given all of this information, which ring architecture is better suited for this application? Briefly explain your reasoning. The UPSR, BLSR/4, and BLSR/2 are designed primarily to handle single failures. However, they can handle some cases of simultaneous multiple failures as well. Carefully characterize the types of multiple link/node failure combinations that these different architectures can handle. The 1 + 1 protection in a SONET UPSR is not implemented at a fiber level but at an individual SONET connection level: for each connection, the receiver picks the better of the two paths. An alternative and simpler approach would be to have the receiver simply pick the better of the two fiber lines coming in, say, based on the bit error rate. In this case, the receiver would not have to look at the individual connections in order to make its decision, but rather would look at the error rate of the composite signal on the fiber. Why doesn't this work? Suppose you had only two fibers but could use two wavelengths, say, 1.3 #m and 1.55/~m, over each fiber. This can be used to deploy a BLSR/4 ring in three different ways: (1) the two working fibers could be multiplexed over one fiber and the two protection fibers over the other, (2) a working fiber and a protection fiber in the same direction could be multiplexed over one fiber, or (3) a working fiber and a protection fiber in the opposite direction could be multiplexed over one fiber. Which option would you choose? Consider a four-fiber BLSR that uses both span and ring switching. What are the functions required in network management to (a) coordinate span and ring switching mechanisms, and (b) allow multiple failures to be restored? Consider the example shown in Figure 10.14. Carefully characterize the set of simul- taneous multiple fiber cuts that can be handled by this arrangement. Consider a five-node optical ring with one hub node and four access nodes. The traf- fic to be supported is one lightpath between each access node and the hub node. You can deploy either a two-fiber OCh-DPRing or a two-fiber OCh-SPRing in this appli- cation. No wavelength conversion is allowed inside the network, so each lightpath must use the same wavelength on every link along its path. Compare the amount of References 587 10.13 protection and working capacity needed for each case. Using a wavelength on a link counts as one unit of capacity. Would your answer change if wavelength conversion was allowed in both types of rings at any node in the ring? Develop computer software that performs the following functions: (a) Allows you to input a network topology graph and a set of lightpaths (source- destinations). (b) Routes the lightpaths using a shortest-path algorithm. (c) Computes protection bandwidth in the network for two cases: 1 + 10Ch protection and OCh shared mesh protection. For 1 + 10Ch protection, use an algorithm to provide two disjoint shortest paths for each lightpath, such as the one in [ST84]. For shared mesh protection, use the following algorithm: for each failure i, determine the amount of protection capacity, Ci(l), that would be required on each link 1 in the network. Prove that the total protection capacity needed on link 1 is then simply maxi Ci (l). (d) Experiment with a variety of topologies, traffic patterns, and different routing/protection computation algorithms. Summarize your conclusions. References [AJY00] C. Alaettinoglu, V. Jacobson, and H. Yu. Towards millisecond IGP convergence. In North American Network Operators Group Fall Meeting, 2000. See also IETF drafts draft-alaettinoglu-isis-convergence-OO.txt and draft-ietf-ospf- scalability-OO.txt. JAR01] D. Awduche and Y. Rekhter. Multiprotocol lambda switching: Combining MPLS traffic engineering control with optical crossconnects. IEEE Communications Magazine, 39(4):111-116, Mar. 2001. [ATM96] ATM Forum. Private Network-Network Interface Specification: Version 1.0, 1996. [Bar00] S. Baroni et al. Analysis and design of backbone architecture alternatives for IP optical networking. IEEE Journal of Selected Areas in Communications, 18(10):1980-1994, Oct. 2000. [Bat98] R. Batchellor. Optical layer protection: Benefits and implementation. In Proceedings of National Fiber Optic Engineers Conference, 1998. [BZB+97] R. Bradon, L. Zhang, S. Berson, S. Herzog, and S. Jamin. Resource Reservation ProtocolmVersion 1 Functional Specification. Internet Engineering Task Force, Sept. 1997. 588 NETWORK SURVIVABILITY [CO99] T.M. Chen and T. H. Oh. Reliable services in MPLS. IEEE Communications Magazine, 37(12):58-62, Dec. 1999. [Dem99] P. Demeester et al. Resilience in multilayer networks. IEEE Communications Magazine, 37(8):70-77, Aug. 1999. [Dos99] B.T. Doshi et al. Optical network design and restoration. Bell Labs Technical Journal, 4(1):58-84, Jan March 1999. [DR00] B.S. Davie and Y. Rekhter. MPLS Technology and Applications. Morgan Kaufmann, San Francisco, 2000. [DWY99] P. Demeester, T H. Wu, and N. Yoshikai, editors. IEEE Communications Magazine: Special Issue on Survivable Communication Networks, volume 37, Aug. 1999. [GR96] O. Gerstel and R. Ramaswami. Multiwavelength optical network architectures and protection schemes. In Proceedings of Tirrenia Workshop on Optical Networks, pages 42-51, 1996. [GR00a] O. Gerstel and R. Ramaswami. Optical layer survivabilityma services perspective. IEEE Communications Magazine, 38(3):104-113, March 2000. [GR00b] O. Gerstel and R. Ramaswami. Optical layer survivability: An implementation perspective. IEEE JSAC Special Issue on Optical Networks, 18(10):1885-1899, Oct. 2000. [GRS97] O. Gerstel, R. Ramaswami, and G. H. Sasaki. Fault tolerant WDM rings with limited wavelength conversion. In Proceedings of IEEE Infocom, pages 508-516, 1997. [HYCG00] G. Hjalmtysson, J. Yates, S. Chaudhuri, and A. Greenberg. Smart routers simple optics: An architecture for the optical Internet. IEEE/OSA Journal on Lightwave Technology, 18(12):1880-1891, 2000. [ITU93] ITU-T. Recommendation Q.700" Introduction to CCITT Signaling System No. 7, 1993. [Kha97] S. Khanna. A polynomial time approximation scheme for the SONET ring loading problem. Bell Labs Technical Journal, 2(2):36-41, Spring 1997. [LC97] C.Y. Lee and S. G. Chang. Balancing loads on SONET rings with integer demand splitting. Computer Operations Research, 24(3 ):221-229, 1997. [MB96] J. Manchester and P. Bonenfant. Fiber optic network survivability: SONET/optical protection layer interworking. In Proceedings of National Fiber Optic Engineers Conference, pages 907-918, 1996. [MBN99] J. Manchester, P. Bonenfant, and C. Newton. The evolution of transport network survivability. IEEE Communications Magazine, 37(8):44-51, Aug. 1999. References 589 [MM00] G. Mohan and C. S. R. Murthy. Lightpath restoration in WDM optical networks. IEEE Network Magazine, 14(6):24-32, Nov Dec. 2000. [Pax97] V. Paxson. End-to-end routing behavior in the Internet. IEEE/ACM Transactions on Networking, 5(5):601-615, Oct. 1997. [Ram01] R. Ramamurthy et al. Capacity performance of dynamic provisioning in optical networks. IEEE/OSA Journal on Lightwave Technology, 19(1):40-48, 2001. [RM99a] B. Ramamurthy and B. Mukherjee. Survivable WDM mesh networks, Part Improtection. In Proceedings of IEEE Infocom, pages 744-751, 1999. [RM99b] B. Ramamurthy and B. Mukherjee. Survivable WDM mesh networks, Part II restoration. In Proceedings of IEEE International Conference on Communication, pages 2023-2030, 1999. [SR97] M. Sexton and A. Reid. Broadband Networking: ATM, SDH and SONET. Artech House, Boston, 1997. [ST84] J.W. Suurballe and R. E. Tarjan. A quick method for finding shortest pairs of disjoint paths. Networks, 14:325-336, 1984. [Tel98] Telcordia Technologies. Common Generic Requirements for Optical Add-Drop Multiplexers (OADMs) and Optical Terminal Multiplexers (OTMs), Dec. 1998. GR-2979-CORE, Issue 2. [WO95] L. Wuttisittikulkij and M. J. O'Mahony. Multiwavelength self-healing ring transparent networks. In Proceedings of IEEE Globecom, pages 45-49, 1995. [Wu92] T.H. Wu. Fiber Network Service Survivability. Artech House, Boston, 1992. [Wu95] T.H. Wu. Emerging techniques for fiber network survivability. IEEE Communications Magazine, 33(2):58-74, Feb. 1995. . than a UPSR in traffic-carrying capacity in this scenario? Construct a traffic distribution for which the traffic-carrying capacity of a BLSR/4 is maximized. What is this capacity as a multiple. Tirrenia Workshop on Optical Networks, pages 4 2-5 1, 1996. [GR0 0a] O. Gerstel and R. Ramaswami. Optical layer survivabilityma services perspective. IEEE Communications Magazine, 38(3):10 4-1 13, March. Towards millisecond IGP convergence. In North American Network Operators Group Fall Meeting, 2000. See also IETF drafts draft-alaettinoglu-isis-convergence-OO.txt and draft-ietf-ospf- scalability-OO.txt.