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