[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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


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

   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

   The list of Internet-Draft Shadow Directories can be accessed at

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


   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


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


   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

                          Expires on 4/2/01                         4


   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:


   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:


                          Expires on 4/2/01                         5


   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


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

   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


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

   - 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-

   2.  J. P. Lang, et al., "Link Management Protocol (LMP)," draft-

   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


   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

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/