Internet Draft Bala Rajagopalan Document: <draft-rs-optical-bundling-01.txt> Debanjan Saha This draft expires on April, 2, 2001 Tellium, Inc. Link Bundling in Optical Networks draft-rs-optical-bundling-01.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 is used, these links may all be bundled together and advertised in a single link state advertisement (LSA). This draft describes the requirements, and proposes a method for bundling optical links. The proposed method aims to reduce the number of routing adjacencies between neighboring nodes, and works in conjunction with a link management protocol (e.g., LMP [2]). The discussion in this draft is related specifically to OSPF. 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-3 OC-48, OC-192, etc. With the advent of Rajagopalan Expires on 2/25/01 1 draft-rs-optical-bundling-01.txt 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 In this network, consider the application of link state IP routing protocols, specifically OSPF, with suitable extensions for resource discovery and dynamic route computation. When there are a relatively large number of multiple, parallel links between adjacent OXCs, an issue arises as to how to aggregate the parallel links information to minimize the link state propagation overheads. This is the topic of this draft. The optical links considered in this draft 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) that introduce specific constraints in the manner in which links could be bundled. Expires on 4/2/01 2 draft-rs-optical-bundling-01.txt 4. Shared-Risk Link Groups (SRLGs) 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. 5. Bundling Method The bundling approach proposed in this draft consists of forming "link groups", where links that belong to the same link group 1. Belong to exactly the same set of SRLGs. 2. Have the same link encoding type (e.g., OC-48, OC-192, etc). 3. Have the same protection type (see below) The link groups formed this way is identified at each OXC by a locally significant link group identifier. All the link groups between a pair of neighboring OXCs collectively form a "bundle", or a virtual adjacency between these OXCs. A bundle is therefore advertised in a single (link) LSA. A bundle also is represented as a single adjacency in router LSAs corresponding to each OXC. The bundle is identified by either an IP address at each end (numbered), or by the OXC (router) ID at each end (unnnumbered). As an example, with reference to Figure 1, OXC1 would advertise a "bundle LSA", with the following information: Expires on 4/2/01 3 draft-rs-optical-bundling-01.txt Link Group ID SRLGs Link Encoding Number Other Info ------------- ----- ------------- ------ ---------- 1 1,2 OC-48 3 --- 2 1,3 OC-192 1 --- The bundled link representation is discussed in detail next. 6. Bundled Link Representation The representation of a bundled link contains a number of sub- objects, one for each link group. A bundled link is unidirectional, and therefore a bundle is advertised by both neighboring OXCs. These OXCs must therefore follow the same bundling rule. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link Group Object // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // // // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Link Group Object // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The link group object itself contains the following essential information: Expires on 4/2/01 4 draft-rs-optical-bundling-01.txt 0 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Link Group Id | Link Encoding Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Links | 0X00 | Protect. Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Reservable bw | Max Reservable bw | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG #m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.1 Link Group ID 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. 6.2 Link Encoding Type The following are examples of Link Encoding 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 encoding for this parameter is same as that defined for the GMPLS LSP Encoding Type [4]. 6.3 Protection Type The following are examples of Protection Types: 1:1 1:N M:N 1+1 Expires on 4/2/01 5 draft-rs-optical-bundling-01.txt The encoding for this parameter is same as that defined for the GMPLS Link Protection Type [4]. 6.4 Min and Max Reservable Bandwidth Minimum and Maximum Reservable Bandwidths indicate the minimum and maximum granularity of reservation possible on the given link. The encoding for these is same as the link encoding type. 6.5 SRLG An SRLG is a 32-bit, configured identifier. 7. Establishing Bundles and OXC Adjacencies 7.1 Configured Information The SRLG, protection, link encoding, min and max bandwidth information must be configured for each link at an OXC. Link groups may be configured or automatically established as described below. 7.2 Automatic Establishment of Link Groups A link management protocol such as LMP [2] can be used between neighboring OXCs to automatically detect links and exchange their configured parameters. The detected links can automatically be classified by the concerned OXCs into link groups according to SRLGs, link types, etc., as described above. Whether link groups are automatically formed or configured, they become part of a single bundle between the neighboring OXCs. 7.3 OXC Routing Adjacencies A link management protocol (e.g., LMP) maintains a single control channel per bundle between neighboring OXCs. This control channel may be physically mapped onto any of the links between the OXCs (in case of in-band control). A link bundle itself is represented as a logical interface to OSPF running in the OXCs. Link state advertisements emanating from OXCs at either end of the bundle are thus sent to the neighbor over the logical interface. These LSAs are transported over the control channel corresponding to the bundle. Thus, a bundle represents an OXC routing adjacency. Under this proposal, only a SINGLE routing adjacency exists between a pair of OXCs with multiple links between them. Expires on 4/2/01 6 draft-rs-optical-bundling-01.txt 8. Advertising Bundled Links A bundled link is advertised as a single LSA. Such an LSA may be advertised periodically, and when a change occurs in the Min or Max reservable bandwidth of any of the component link groups. For example, consider a link group which consists of a number of OC-48 links, with Min = Max = OC-48. Then, an LSA update occurs when the number of available links in the group drops to 0 (i.e., Max reservable bandwidth is 0). On the other hand, suppose a link group consists of OC-192 links, with Min = OC-48 and Max = OC-192. Suppose a number of OC-48 lightpaths are routed in sequence over this link group. In this case, an LSA update need occur only when there is no longer any capacity to route an OC-192 lightpath, i.e., when Max = OC-48. Thus, updates of a bundled link LSA can be effectively damped. Under OSPF, a bundled link LSA is also represented in router LSAs as a single adjacency. 9. Single vs Multiple Bundles Between Nodes Bundling of link groups can be based on different strategies. On the one hand, each link group can be individually bundled and advertised. Or, all link groups can be part of a single bundle. The former method is advocated in [3]. With this method, an IGP such as OSPF running in one OXC will still see multiple adjacencies to a neighbor to which multiple bundles have been established. In this case, an LSA advertised by the OXC will be sent multiple times to the neighbor, once over the control channel corresponding to each bundle. Separate, IGP-specific procedures must be used to limit the number of copies of LSAs sent to just one. OSPF procedures for limiting flooding are described in [5]. Similarly, ISIS procedures must be separately developed. On the other hand, using exactly one bundle as defined in this draft obviates the need for modifying the flooding procedure of each IGP. One consequence of the bundling approach described in this draft is that the entire bundle LSA must be generated when there is a change in any link group. This will not pose a problem if the number of link groups within a bundle is small. We indeed expect this to be the case in optical networks, where there are only a few discrete link types and SRLG groupings are expected to be few in practice. Note that the bundling structure does not affect the frequency of LSA generation, since a change in a link group will always result in update generation whether the link group is bundled separately or as part of a larger bundle. Only the size of the LSA generated is affected by the bundling structure. Expires on 4/2/01 7 draft-rs-optical-bundling-01.txt 10 Lightpath Set-up During lightpath establishment, both the bundle identifier and a link group identifier must be specified. The explicit route information in RSVP-TE or CR-LDP can accommodate node IDs which essentially indicate bundles. The link group identifier must be indicated in addition. Modification to the explicit route information is therefore necessary. The details of this are not considered in this draft, but the requirements are similar to those described in [6]. 11. Summary This draft considered the issue of bundling optical links, and proposed a specific scheme for link bundling along with a description of bundle components. This scheme 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. - A single routing adjacency is maintained between neighboring OXCs connected by multiple links. 12. References 1. B. Rajagopalan, J. Luciani, D. Awduche, B. Jamoussi and B. Cain, "IP Over Optical Networks: A Framework," draft-ip-optical- framework-01.txt. 2. J. P. Lang, et al., "Link Management Protocol (LMP)," draft- mpls-lmp-01.txt 3. K. Kompella, Y. Rekhter, and L. Berger, "Link Bundling in MPLS Traffic Engineering," draft-kompella-mpls-bundle-02.txt. Expires on 4/2/01 8 draft-rs-optical-bundling-01.txt 4. P. Ashwood-Smith, et al., "Generalized MPLS Signaling Functional Description" draft-ashwood-generalized-mpls-signaling-00.txt. 5. A. Zinin and M. Shand, "Flooding Optimizations in Link State Routing Protocols," draft-zinin-flood-opt-00.txt. 6. K. Kompella and Y. Rekhter, "Traffic Engineering with Unnumbered Links," draft-kompella-mpls-unnum-02.txt. 13. 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 April, 2, 2001 ****** Expires on 4/2/01 9