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

Versions: 00 01

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


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/