Internet Draft Network Working Group Bala Rajagopalan Internet Draft Debanjan Saha Expiration Date: December, 31, 2000 Tellium, Inc. Link Bundling Considerations in Optical Networks draft-rs-optical-bundling-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 2. Abstract In an optical mesh network, two adjacent optical cross connects (OXCs) may have multiple, parallel, discrete bandwidth links connecting them [1]. When a link state routing protocol (e.g., OSPF) is used, these links may all be bundled together and advertised in a single link state advertisement (LSA). This draft describes the issues that arise when optical links are bundled, and proposes a rule for bundling optical links. This work is complimentary to the work on link bundling for MPLS TE [2]. The differences between optical link bundling and link bundling for MPLS TE are also described. 3. Introduction Consider the optical network mesh topology shown in Figure 1. Here, adjacent optical cross-connects (OXCs) are connected by multiple, parallel optical links. These optical links are of discrete capacity, for instance, OC-48, OC-192, etc. With the advent of high port capacity OXCs, the number of such links between adjacent OXCs could be very high. +--------------+ +------------+ +------------+ | +-1:OC48---+ +-5:OC192-+ | | +-2:OC48---+ +-6:OC192-+ | | OXC1 +-3:OC48---+ OXC2 +-7:OC48--+ OXC3 | | +-4:OC192--+ +-8:OC48--+ | | | | | +------+ | +--------------+ +----+-+-----+ | +----+------+-----+ | | | | | | | | | | +--------------+ | | | | | | | +----+-+-----+ | | +------+-----+ | +----------+ +--+ | | | | OXC4 +----------+ +----+ | | | +----------+ OXC5 +--------+ OXC6 | | | | +--------+ | +--------------+ | | | | +------+-----+ +------+-----+ Figure 1: Mesh Optical Network It has been commonly accepted that the control plane in optical mesh networks will be IP-centric. Specifically, it is common wisdom that link state IP routing protocols (e.g., OSPF) with suitable extensions for propagating resource availability information will be used for resource discovery and dynamic route computation for lightpath provisioning. In this regard, when there are a relatively large number of multiple, parallel links between adjacent OXCs, an issues arises as to how to aggregate the parallel links information into a single LSA to minimize the link state propagation overheads. This is the topic of this draft. The concept of link bundling for MPLS traffic engineering has been dealt with in [2]. In that draft, the authors consider a network of LSRs where two adjacent LSRs could have multiple links, each with arbitrary capacity and occupancy (e.g., a 100 Mbps link with 42 Mbps occupied). With this assumption, [2] considers ways to represent resource information in a concise fashion when multiple such links are bundled. The problem addressed in this draft is somewhat different: The optical links considered have discrete capacities, drawn from a small set. Furthermore, from a route computation point of view, a link is either fully occupied or empty. Also, it may not be possible to assign a lower capacity request to a higher capacity link due to policy reasons (e.g., it may not be desirable to allocate a OC-48 lightpath to a OC-192 link if this link should is designated to carry only an OC-192 lightpath). Finally, route computation for lightpaths may take into account Shared Risk Link Groups (SRLGs) which introduces specific constraints in the manner links could be bundled. 4. Route Computation in an Optical Mesh Network To understand the bundling requirements, the route computation procedure for lightpaths in an optical network must be examined. A lightpath provisioning request specifies two endpoints, an ingress and egress port, along with bandwidth, protection and other parameters of relevance. The route computation procedure takes into account the network topology, resource availability and other link characteristics to determine the end-to-end path. Mesh optical networks will offer automatic protection of lightpaths. Protection is typically implemented by provisioning an exclusive or shared back-up path for a given primary path [1]. The concept of SRLG is used to ensure that the primary and the back-up path are not affected by the same failure. An SRLG is an identifier assigned to a group of optical links that share a physical resource. For instance, all optical channels routed over the same fiber could belong to the same SRLG. Similarly, all fibers routed over a conduit could belong to the same SRLG. The notable characteristic of SRLGs is that a given link could belong to more than one SRLG, and two links belonging to a given SRLG may individually belong to two other SRLGs. Taking the example shown in Figure 1, links 1,2,3 and 4 may belong to SRLG 1, links 1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3. Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8 could belong to SRLG 4. (In this example, the same SRLG, i.e., 1, contains links from two different adjacencies). When routing an alternate path for protection purposes, the general principle followed is that the alternate path is not routed over any link belongs to an SRLG that some link in the primary path belongs to. Thus, it is essential that the SRLGs in the primary path be known during alternate path computation, along with the availability of resources in links that belong to other SRLGs. This requirement has certain implications on optical link bundling. Specifically, a bundled LSA must include adequate information such that a remote OXC can determine the resource availability under each SRLG that the bundled link refers to, and the relationship between links belonging to different SRLGs in the bundle. For example, considering Figure 1, if links 1,2,3 and 4 are bundled together in an LSA, the bundled LSA must indicate that there are three SRLGs which are part of the bundle (i.e., 1, 2 and 3), and that links in SRLGs 2 and 3 are also part of SRLG 1. It is somewhat complex to encode the SRLG relationships in a link bundle LSA. This information, however, is naturally captured if the link bundle is encoded as a set of "link groups", each specifying the links that belong to exactly the same set of SRLGs. Within the link group, it is possible to specify the number of links of a particular type, for example, OC-48. With reference to Figure 1, for example, a bundle LSA can be advertised for the entire set of links between OXC1 and OXC2, with the following information: Link Group ID SRLGs Link Type Number Other Info ------------- ----- --------- ------ ---------- 1 1,2 OC-48 3 --- 2 1,3 OC-192 1 --- This is the bundling approach followed in this draft. Assuming that the above information is available for each bundle at every node, there are several approaches possible for path computation. For instance, 1. The primary path can be computed first, and the (exclusive or shared) back-up is computed next based on the SRLGs chosen for the primary path. In this regard, o The primary path itself can be computed by taking into account specific link groups in a bundle. That is, the primary path computation procedure can output a series of link groups the path is routed over. Since a link group is uniquely identified with a set of SRLGs, the alternate path can be computed right away based on this knowledge. In this case, if the primary path set up does not succeed for lack of resources in a chosen link group, the primary and backup paths muse be recomputed. o It might be desirable to compute primary paths using bundle- level information (i.e., resource availability in all link groups in a bundle) rather than specific link group level information. In this case, the primary path computation procedure would output a series of bundles the path traverses. Each OXC in the path would have the freedom to choose the particular link group to route that segment of the primary path. This procedure would increase the chances of successfully setting up the primary path when link state information is not up to date everywhere. But the specific link group chosen, and hence the SRLGs in the primary path, must be captured during primary path set-up, for example, using the RSVP-TE Route Record Object [3]. This SRLG information is then used for computing the back-up path. The back-up path may also be established specifying only which SRLGs to AVOID in a given segment, rather than which link groups to use. This would maximize the chances of establishing the back-up. 2. The primary path and the back-up path are comptuted together in one step, for example, using Suurbaale's algorithm [4]. In this case, the paths must be computed using specific link group information. To summarize, it is essential to capture sufficient information in link bundle LSAs to accommodate different path computation procedures and to maximize the chances of successful path establishment. Depending on the path computation procedure used, the type of support needed during path establishment (e.g., the recording of link group or SRLG information in Route Record) may differ. 5. Bundled Link Components The representation of a bundled link contains a number of sub-objects, one for each link group bundled. To recapitulate, a link group must contain only links that belong to the same set of SRLGs. A bundled link is unidirectional, advertised by an OXC. The OXCs at both sides of the bundled link must follow the same bundling rule. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link Group Object // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // // // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link Group Object // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The issue of bundle identification is dealt with in [2]. The link group object itself contains the following essential information: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Link Group Id | Link Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Links | Protection Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG #m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The link group ID is a locally unique identifier, selected by the OXC advertising the link group. The link group ID together with the bundle identifier uniquely defines the link group. The following are examples of link types: OC-3/STM-1; OC-3c; OC-12/STM-4; OC-12c; OC-48/STM-16; OC-48c; OC-192/STM-64; OC-192c; OC-768/STM-256; OC-768c The following are examples of protection types: 1:1 1:N M:N 1+1 Specific formats of these parameters are described elsewhere (e.g., [5]). The manner in which bundled link information is updated is covered in [2]. Bundling of link groups can be based on different strategies. On the one hand, each link group can be individually bundled and advertised. Or, multiple link groups can be combined in a bundle. The formation of link groups within a bundle may also be based on other link parameters than just SRLG. In this case, links must be ordered first by SRLG, then by each of the other parameters (for example, link type) and link groups must be formed by suitably combining the links. 6. Summary This draft considered the issue of bundling optical links, and proposed a specific rule for link bundling along with a description of essential bundle contents. This rule was based on the following properties of optical links: - The optical links have discrete capacities, drawn from a small set. - From a route computation point of view, a link is either fully occupied or empty. - It may not be possible to assign a lower capacity request to a higher capacity link, and - Route computation for lightpaths may take into account Shared Risk Link Groups (SRLGs) which introduces specific constraints in the manner links could be bundled. The view taken in this draft is that bundled link LSAs should convey sufficient information to be of use to the path computation process. In this regard, it is not a particular concern in making bundled link LSAs fairly descriptive about the bundled information. A bundled LSA reduces the number of individual LSAs propagated and processed, and this is the main advantage of bundling. In many practical cases, the bundled information may also be internally aggregated efficiently, when the parameters permit it (e.g., when SRLGs are not defined very finely). 7. References 1. J. Luciani, B. Rajagopalan, D. Awduche, B. Jamoussi and B. Cain, "IP Over Optical Networks: A Framework," draft-ip-optical- framework-00.txt. 2. K. Kompella, Y. Rekhter, and L. Berger, "Link Bundling in MPLS Traffic Engineering," draft-kompella-mpls-bundle-01.txt. 3. D. Awduche, L. Berger, et al., " RSVP-TE: Extensions to RSVP for LSP Tunnels," draft-ietf-mpls-rsvp-lsp-tunnel-05.txt. 4. J. Suurballe, "Disjoint Paths in a Network," Networks, vol. 4, 1974. 5. D. Saha, B. Rajagopalan, and B. Tang, " RSVP Extensions for Signaling Optical Paths," draft-saha-rsvp-optical-signaling-00.txt 8. Author Information Bala Rajagopalan Debanjan Saha Tellium Inc. 2 Crescent Place Ocean Port, NJ 07757 Ph: 732-923-4237, 4264 Email: {braja, dsaha}@tellium.com **** This draft expires on December, 31, 2000 ******