CCAMP Working Group E. Mannie (Ebone) Internet Draft G. Bernstein (Ciena) Category: Informational Bala Rajagopalan (Tellium) Expiration Date: June 2002 Mike Raftelis (WhiteRock) Dimitri Papadimitriou (Alcatel) Abhimanyu Das (Mahi) Document: draft-mannie-mpls-sdh- ospf-isis-02.txt Suresh Katukam (Cisco) Vishal Sharma (Metanoia) (Editors) December 2001 Considerations in Advertising Ring Properties for MPLS-based SDH/SONET Control draft-mannie-mpls-sdh-ospf-isis-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document provides the background and motivation behind advertising certain properties of SDH/SONET rings in the IP routing protocols [2],[3] used to control optical transport networks. The protocol extensions in [2],[3] enable the protection capabilities of TDM rings to be utilized when automatically setting up TDM circuits in the network. The current document provides the rationale for those extensions. Table of Contents 1. Introduction.....................................................2 2. Specification of Requirements....................................2 Expires June 2002 [Page 1] draft-mannie-mpls-sdh-ospf-isis-02.txt December 2001 3. Abbreviatios.....................................................2 4. Enhancement to Link Protection to Account for SDH/SONET Rings....3 4.1. New Code Points in the Link Protection Type....................3 4.2. A BLSR Illustrative Example....................................6 4.3. Ring ID in the Link Protection Type............................7 5. Other Observations...............................................9 6. Security Considerations..........................................9 7. References.......................................................9 8. Author's Addresses..............................................10 1. Introduction A framework for MPLS-based control of SDH/SONET networks was presented in [4]. It provides an overview of the operation and management of SDH/SONET networks and discusses many of the routing and signaling issues that must be considered in the dynamic control of SDH/SONET transport networks. The current document clarifies the reasons behind the protection- related extensions specified in [2], [3]. In particular, we will explain the SDH/SONET-related extensions to the Link Protection Type sub TLV. There are two main extensions to the Link Protection Type sub-TLV that are related to SDH/SONET rings. -- The first is the addition of new code points in the bit vector describing the protection capabilities of a link in the Link Protection Type sub-TLV. Namely, the addition of "TSI-capable BLSR", "Non-TSI capable BLSR", and "UPSR" values to this field. -- The second is the addition of a new field, the "Ring ID" field, in the Link Protection Type sub-TLV. In the following sections, we will discuss why these extensions are needed in the context of SDH/SONET rings. 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. Abbreviations ADM Add-Drop Multiplexer AU-n Administrative Unit-n (SDH) AUG Administrative Unit Group (SDH) DCC Data Communication Channel LSA Link State Advertisement Katukam/Sharma Eds. Expires January 2002 [Page 2] draft-mannie-mpls-sdh-ospf-isis-02.txt December 2001 LSP Label Switched Path (MPLS terminology) LSP Link State PDU (IS-IS terminology) MPLS Multi-Protocol Label Switching POH Path Overhead RSOH Regenerator Section Overhead SDH Synchronous Digital Hierarchy SOH Section Overhead STM(-N) Synchronous Transport Module (-N) STS(-N) Synchronous Transport Signal-Level N (SONET) TSI Time Slot Interchange TU-n Tributary Unit-n (SDH) TUG(-n) Tributary Unit Group (-n) (SDH) VC-n Virtual Container-n (SDH) VTn Virtual Tributary-n (SONET) 4. Enhancement to Link Protection to Account for SDH/SONET Rings The protection capability that exists on a link is an important static capability that can be advertised through the routing protocol, and used by the route computation process to: (a) discover (where needed) the complete topology of SDH/SONET rings in the network, and (b) set up SDH/SONET circuits with appropriate protection characteristics. There are some special considerations that must be kept in mind when considering SONET UPSR (Unidirectional Path Switched Ring) and BLSR (Bidirectional Path Switched Ring) rings or SDH DPRing (Dedicated “ unidirectional - Protection Ring) and MS-SPRing (Shared Protection Rings) rings. Thus, the Link Protection Type sub-TLV defined in [2], [3] must be extended to cover SDH/SONET circuit requirements, as has been done in the latest versions of these documents. In particular, as we will see shortly, it is very important to know the type of ring that a link belongs to, and to be able to identify links that belong to the same ring. 4.1. New Code Points in the Link Protection Type As explained earlier, the first addition made to the Link Protection Type sub-TLV is the introduction of three new code points, two of which describe links belonging to BLSR rings with different time- slot interchange capabilities, while the third describes links belonging to UPSR rings. The motivation for the introduction of these code points is the need for a remote node receiving the routing protocol updates to be able to identify the type of SDH/SONET ring to which a given link belongs. Katukam/Sharma Eds. Expires January 2002 [Page 3] draft-mannie-mpls-sdh-ospf-isis-02.txt December 2001 In the case of UPSR rings, this is important for the remote node to be able to determine the working and protect fibers on the ring, and to be able to determine the direction (clockwise or anticlockwise) of the working and protection fibers. (Note that the ŸUPSR÷ code point, by itself, does not tell a remote node all of these details. Rather, this code point, in conjunction with some other rules about how a remote node interprets the LSAs describing ŸUPSR÷ links allows that node to make these deductions.) In other words, this code point enables a network node to determine the complete topology of a remote UPSR ring. A similar argument applies for links belonging to BLSR rings as well. In the BLSR case, however, the situation is more complex, and there are additional reasons for requiring these code points. This is because special requirements apply to LSPs established over SDH/SONET cross-connects on BLSR rings. The BLSR standards [5] require that, on a given BLSR ring, the same time slots be assigned to a given LSP on every link that it passes through (this is the non-TSI (Time Slote Interchange) capable property of the nodes on a BLSR ring). (The primary reason for this requirement is to simplify squelch table. There are vendors that are implementing time slot independence on BLSR. The computation for squelching and protection is more complicated in this case, but can be done.) We call this the BLSR requirement. In other words, if an LSP traverses successive links on a BLSR ring, it must be assigned the same time slots on each of those links. If a LSP passes through multiple BLSR rings, this requirement applies individually to the set of links belonging to each BLSR ring that the LSP passes through. As an example, suppose that an STS-3c LSP uses three successive links on a BLSR ring. If time slots 4, 5, and 6 are assigned to this LSP on its first hop, the same time slots must also be assigned to the LSP on the other two links of the ring. To meet this requirement, the source of the circuit or LSP, therefore, needs to know exactly which time slots or channels are available on each BLSR link at any particular point in time. If one were to satisfy this requirement by advertisements in the IGP routing protocol, this would lead to a large amount of flooded information. For example, an OC-192 link would require that all available (up to 192) channels be advertised. Clearly, this would result in very large IGP advertisements. Furthermore, every node would need to advertise this LSA whenever a channel was allocated or freed. A simpler way to achieve this effectively is by applying the following mechanism in conjunction with a GMPLS-based control plane. We assume that every node of a BLSR ring is aware, via external means outside of the IGP, of all the links of the BLSR and of all of the available channels on those links. Thus, there is a distinction between the configuration and discovery process on a ring, which enables the nodes on a ring to become aware of state of the ring as Katukam/Sharma Eds. Expires January 2002 [Page 4] draft-mannie-mpls-sdh-ospf-isis-02.txt December 2001 described above, from the advertising of the resources (to nodes external to the ring) by an IGP. A node could achieve this via some local discovery process that operates only over the ring in question. Armed with this information, each node on a BLSR ring can calculate whether or not a remote node on the ring is reachable via a channel of non-zero bandwidth in the following way. For each remote node on the ring, the node in question calculates the intersection of the available slots on each of the links between itself and the remote node. If there is a non-zero intersection of one or more contiguous time slots (and there can be more than one such intersection), the remote node is reachable from the local node, via a channel whose bandwidth is given by the number of contiguous time slots in the intersection. A LSR node can now advertise either one or two virtual links corresponding to each channel of non-zero bandwidth that it obtained by the process explained above. This is because a node on a ring can reach any other node in two ways, using either the clockwise or anticlockwise direction. These virtual links, which have SDH/SONET link properties, are like LSP tunnels (or logical links from one node to the other). A virtual link consists of two or more physical links that belong to the same BLSR ring. When a node advertises such a link, it should compute the Minimum Reservable Bandwidth and Maximum Reservable Bandwidth (see [2], [3]) for that link by taking into account the BLSR requirement outlined above and the currently available channels on the physical links comprising that virtual link. These computed values are the ones advertised in the Link Descriptor as described in [2], [3]. Thus, in order to meet the BLSR time-slot assignment requirement, a path computation algorithm should not consider two or more contiguous standard BLSR links (either physical links or LSP tunnels of the type described above) of a given BLSR ring in a shortest path computation. (Since the exact time slot availability is not advertised in the IGP, a remote node that considers contiguous BLSR links as candidates for the hops on the path of an LSP will not be guaranteed to actually have time slots available on those links.) A node can, however, consider multiple non-contiguous BLSR links in the shortest path computation. This may be the case, for example, when there are two interconnected BLSR rings, and a path computation engine computes a path whose first and third hops traverse a physical or virtual link on the first ring, while its second hop traverses a physical or virtual link on the adjacent interconnected BLSR ring. Finally, the Bellcore non-TSI requirement that the same time slots be assigned to an LSP on each link of a BLSR ring imposes the requirement that only one physical or virtual link of a BLSR ring may be used by a contiguous segment of a path passing through a BLSR Katukam/Sharma Eds. Expires January 2002 [Page 5] draft-mannie-mpls-sdh-ospf-isis-02.txt December 2001 ring. (Note that as discussed above, non-contiguous segments of the path may use more than one link on a BLSR ring.) For the path computation algorithm to be able to do this efficiently, the Ring ID is again quite handy, and therefore needs to be advertised in the Link Protection Type sub-TLV. The remote node must simply make sure that no two consecutive contiguous segments of a path are assigned to links that have the same Ring ID. Note that it is entirely possible for the nodes on a BLSR ring to run proprietary algorithms that do away with the requirement to have the same set of time slots assigned to an LSP at each hop of the ring. (Some vendors have, in fact, implemented protocols for this that run among the nodes on a BLSR ring.) Given this scenario, it is also necessary for the nodes in a network to know whether or not a given BLSR ring requires the time-slot assignment required by the Bellcore standards. This requires that the Link Protection Type sub- TLV also provide a way to distinguish between standard BLSR rings and enhanced BLSR rings of the type just described. 4.2. A BLSR Illustrative Example To illustrate the points made in Section 4.1, consider an OC-192 BLSR ring with 6 nodes A, B, C, D, E, and F as shown below: +---+ +---+ | B | ------- | C | +---+ +---+ / \ / \ / \ +---+ +---+ | A | BLSR ID = 1 | D | +---+ +---+ \ / \ / \ / +---+ +---+ | F | ------- | E | +---+ +---+ Suppose that Node A advertises virtual links corresponding to this BLSR ring. A has direct physical links to B and F, which can be advertised as such. Node A also creates virtual tunnels to nodes C, D, E and advertises these into its OSPF area (assuming that the sequence of links between A, and C, D, and E, satisfy the BLSR time- slot assignment requirement). As a result, Node A provides the following view to the other nodes in its area: +---+ +---+ | B | | C | +---+ +---+ / / Katukam/Sharma Eds. Expires January 2002 [Page 6] draft-mannie-mpls-sdh-ospf-isis-02.txt December 2001 / /------+ / +------+ +---+ / +---+ | A | --------------------------- | D | +---+ \ +---+ \ +----+ \ \ \ ------+ \ \ +---+ +---+ | F | | E | +---+ +---+ Observe that each channel/connection between node A and any other node on the BLSR ring could be represented by one or two virtual links from node A to that node. It is up to node A to determine whether it wishes to advertise one or two tunnels to every other node. If both links have similar Link Descriptor values, it may be sufficient to only advertise the virtual link that takes the shorter path around the ring. 4.3. Ring ID in the Link Protection Type The Link Protection Type sub-TLV in [2, [3] also needs to be enhanced to carry a Ring ID, which helps in several ways. First, it enables the setting up of SDH/SONET paths where each segment of the path is adequately protected by underlying SDH/SONET protection mechanisms. Second, it allows for the path computation algorithm to meet the BLSR time-slot assignment requirement outlined in the previous section. Third, it allows for more efficient routing of connections on stacked BLSR/UPSR rings (by ensuring that, where possible, a connection is routed on links belonging to only one of the parallel stacked rings), thus making more efficient use of capacity. The simplest motivation for requiring a Ring ID is to distinguish between links belonging to different (possibly parallel) UPSR/BLSR rings. For example, consider the situation where we have a number of parallel, stacked UPSR rings passing through a set of nodes. When routing a TDM LSP passing between two nodes from this set, it is desirable that the sequence of links for the segment of the LSP that passes through these nodes be chosen to lie on the same ring. This is because if these links lie on different UPSR rings, protection bandwidth for this LSP would be consumed on multiple rings. Assuming that only a single fault occurs in the network at a time, this is quite wasteful. A better solution would be to ensure that all of the hops through these nodes travel over the same UPSR ring (assuming Katukam/Sharma Eds. Expires January 2002 [Page 7] draft-mannie-mpls-sdh-ospf-isis-02.txt December 2001 that it has adequate capacity available). In such a case, protection bandwidth would be consumed on only a single ring. This could easily be achieved by assigning a Ring ID to each ring, and advertising the Ring ID of the ring to which a link belongs as part of the LSA describing that link. A remote node receiving such LSAs would be able to determine which links belong to the same ring, and chose the path for an LSP accordingly. The case of BLSR rings is similar. An added disadvantage of not having a Ring ID in the BLSR case could be that a connection routed over parallel BLSR rings may not be able to benefit from BLSR protection at all, as we explain shortly. To understand why the BLSR Ring ID is useful, consider the following example. Consider a network with 6 nodes A, B, C, D, E, and F as shown below: +--------+ +--------+ | B |---------| C | | |---------| | +--------+ +--------+ / / \ \ / / \ \ / / \ \ +--------+ +--------+ | A | | D | | | | | +--------+ +--------+ \ \ / / \ \ / / \ \ / / +--------+ +--------+ | F |---------| E | | |---------| | +--------+ +--------+ Suppose that these nodes sit on two parallel BLSR rings, an inner ring with Ring ID = 1 and outer ring with Ring ID = 2. When an LSP is being created from node A to node D, it is technically possible for the path for that LSP to go from A to B on the inner ring, from B to C on the outer ring, and C to D again on the inner ring. Not only is this inefficient, it also does not work well with BLSR protection. In fact, such an assignment of links to an LSP does not provide any protection at all if node B were to fail. Instead, if the LSP path were to choose all the links from same ring, it would provide protection for the LSP even when node B failed. Katukam/Sharma Eds. Expires January 2002 [Page 8] draft-mannie-mpls-sdh-ospf-isis-02.txt December 2001 Given the above, it is necessary for a path computation entity to know the Ring ID of each ring in its purview, and this parameter should therefore be advertised in the Link Protection Type sub-TLV. To provide all of the necessary information discussed above, the Link Protection Type sub-TLV needs to be modified, and has the form given in [2] and [3], for the OSPF-TE and IS-IS routing protocols, respectively. 5. Other Observations It may also be useful for the Link Protection Type values to be defined as integer values instead of bit values, since it is not possible for a link to provide multiple types of protection. Note that this is different than the encoding for the Link Protection sub-object in the signaling protocols [6]. This is because when signaling for the type of desired protection on a link/hop taken by a SDH/SONET LSP, it is possible to indicate a multiplicity of values, leaving the actual choice to be a local decision. This is because the circuit in question may be willing to accept any form of protection from among the specified set. This is not true, however, when one is merely describing the types of protection that a link supports, which is the case here. 6. Security Considerations Security considerations are not discussed in this version of the document. 7. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] K. Kompella et al, "OSPF Extensions in Support of Generalized MPLS,÷ Internet Draft, Work in Progress, draft-kompella-ospf- gmpls-extensions-03.txt, November 2001. [3] K. Kompella et al, "IS-IS Extensions in Support of Generalized MPLS,÷ Internet Draft, Work in Progress, draft-ietf-isis-gmpls- extensions-03.txt, November 2001. [4] G. Bernstein, E. Mannie, V. Sharma, "Framework for MPLS-based Control of SDH/SONET Networks,÷ Internet Draft, Work in Progress, draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt, July 2001. [5] SONET BLSR Ring Equipment Generic Criteria, GR-1230-CORE, Dec. 1998. [6] P. Ashwood-Smith, L. Berger (Editors), "Generalized MPLS Katukam/Sharma Eds. Expires January 2002 [Page 9] draft-mannie-mpls-sdh-ospf-isis-02.txt December 2001 Signaling Functional Description", draft-ietf-mpls-generalized signaling-05.txt, Internet Draft, Work in Progress, October 2001. 8. Author's Addresses Eric Mannie Greg Bernstein EBONE Ciena Corporation Terhulpsesteenweg, 6A 10480 Ridgeview Court 1560 Hoeilaart, Belgium Cupertino, CA 94014, USA Ph: +32 2 658 56 52 Phone: +1(408) 366-4713 Email: eric.mannie@ebone.com Email: greg@ciena.com Bala Rajagopalan Mike Raftelis Tellium, Inc. White Rock Networks, Inc. 2 Crescent Place 18111 Preston Road, Suite 900 P.O. Box 901 Dallas, TX 75252, USA Oceanport, NJ 07757-0901, USA Ph: +1(972)588-3728 Ph: +1 732 923 4237 Email: MRaftelis@WhiteRockNetworks.com Email: braja@tellium.com Dimitri Papadimitriou Abhimanyu Das Alcatel IPO-NSG Mahi Networks, Inc. Francis Wellesplein 1, 1039 N. McDowell Boulevard B-2018 Antwerpen, Belgium Petaluma, CA 94954 Ph: +32 3 240-8491 Ph: 707-283-1022 Email: Email: adas@mahinetworks.com Dimitri.Papadimitriou@alcatel.be Suresh Katukam Vishal Sharma Cisco Systems Metanoia, Inc. 1450 N. McDowell Blvd 305 Elan Village Ln., Unit 121 Petaluma, CA 94954-6515 USA San Jose, CA 95134-2545, USA Ph: +1 (707) 285-5427 Ph: +1 (408) 955 0910 Email: skatukam@cisco.com Email: v.Sharma@ieee.org Katukam/Sharma Eds. Expires January 2002 [Page 10]