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

Versions: 00 01

Network Working Group                                      G. Bernstein
Internet Draft                                                    Ciena
Expiration Date: May 2001                                B. Rajagopalan
Document: draft-bernstein-optical-bgp-00.txt                    Tellium
                                                          February 2001

               Optical Inter Domain Routing Requirements

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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
   The list of current Internet-Drafts can be accessed at
   The list of Internet-Draft Shadow Directories can be accessed at


   GMPLS is being considered as an extension to the MPLS framework to
   include optical non-packet switched technologies. This draft
   discusses requirements for inter domain routing protocols such as
   BGP for use in the optical domain.

1. Introduction

   Multi Protocol Label Switching (MPLS) has received much attention
   recently for use as a control plane for non-packet switched
   technologies.  In particular optical technologies have a need to
   upgrade their control plane as reviewed in reference [2]. Many
   different optical switching and multiplexing technologies exist and
   more are sure to come.  For the purposes of this draft we only
   consider non-packet (i.e. circuit switching) forms of optical
   As we have looked at requirements and extensions to interior gateway
   protocols such as OSPF and IS-IS in reference [3], we consider the
   requirements that optical networking and switching place on an
   exterior gateway protocol such as BGP.  In particular we look at
   optical path diversity, various optical switching and transport
   capabilities, and bandwidth/resource status with respect to inter
   domain routing.
                  draft-bernstein-optical-bgp-00.txt         July 2000

1.1. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   this document are to be interpreted as described in RFC 2119.

1.2 Abbreviations

   LSP        Label Switched Path (MPLS terminology)
   LSR        Label Switched Router (MPLS terminology)
   MPLS       Multiprotocol Label Switching
   SDH        Synchronous Digital Hierarchy (ITU standard)
   SONET      Synchronous Optical NETwork (ANSI standard)
   STM(-N)    Synchronous Transport Module (-N)
   STS(-N)    Synchronous Transport Signal-Level N (SONET)
   TU-n       Tributary Unit-n (SDH)
   TUG(-n)    Tributary Unit Group (-n) (SDH)
   VC-n       Virtual Container-n (SDH)
   VTn        Virtual Tributary-n (SONET)

2.0. Motivation for Optical Inter Domain Routing

   The motivation for inter domain routing in optical networks (circuit
   switched)is very similar to that in the case of IP datagram routing.

        1. Distribute "reachability" information throughout an
           internetwork. An internetwork consists of an interconnected
           set of networks under different routing and/or
           administrative domains.

        2. Maintain a clear separation between distinct administrative
           or routing domains.

        3. Provide "information hiding" on the internal structure of
           the distinct administrative or routing domains.

        4. Limit the scope of interior gateway routing protocols. This
           is for security, scalability and policy reasons.

        5. Provide for address/route aggregation.

2.1. Major Differences from IP datagram Routing

   Although the differences in requirements between an exterior gateway
   protocol for IP datagram routing and that for optical circuit
   routing will be explored in detail in the following section.  It is
   useful to review the major difference between routing for optical
   (circuit switched networks) and IP datagram networks.  In particular
   IP datagram networks packet forwarding is done on a hop-by-hop basis
   (no connection established ahead of time).  While with circuit
   switched optical networks end to end connections must be explicitly
   set established based on network topology and resource status
   information.  This topology and resource status information can be
                  draft-bernstein-optical-bgp-00.txt         July 2000

   obtained via routing protocols. Note that the routing protocols in
   the circuit switch case are not involved with data (or bit)
   forwarding, i.e., they are not "service impacting".  While in the IP
   datagram case the routing protocols are explicitly involved with
   data plane forwarding decisions and hence are very much service

   This does not imply routing is unimportant in the optical case but
   that its service impacting effect is secondary.  For example,
   topology and resource status inaccuracies will affect whether a new
   connection can be established (or a restoration connection can be
   established) but will not (and should not) cause an existing
   connection to be torn down.

   This tends to lead to a slightly different view towards
   incorporating new information fields (objects, LSA, etc.) into
   optical routing protocols versus IP routing protocols.  In the
   optical circuit case any information that can potentially aid in
   route computations or be used in service differentiation may be
   incorporated into the route protocol as either a standard element or
   a vendor specific extension.  Whether a route computation algorithm
   uses this information and whether two route computation algorithms
   use this information in the same way doesn't matter since the
   optical connections are explicitly routed (although perhaps
   loosely). The optical route computation problem is really a
   constraint-based routing problem.

2.2. Policy Mechanisms

   BGP-4 [4] provides a number of policy mechanisms that relate to how
   routing information is used and disseminated. In particular the E-
   BGP border router model keeps distinct the routing information
   received from each of a border routers autonomous systems external
   peers (Adj-RIBs-In -- Adjacent Routing Information Base In), the
   routing information that the Autonomous System (AS) itself is using
   (Loc-RIB -- Local Routing Information Base), and the routing
   information that the AS forwards onto its external peers (Adj-RIBs-
   Out -- Adjacent Routing Information Base Out).  Via this model one
   can develop policies with regards to which routes get chosen for use
   in the AS, i.e., which routes from the Adj-RIBs-In are chosen to
   populate the Loc-RIB. One also develops policies concerning what
   routing information gets advertised to external peers, i.e., which
   routes from Loc-RIB gets exported to each of the Adj-RIBs-Out.

   The choice of which routes get imported for local routes generally
   is concerned with the "quality" of those advertising the routes
   since not too much else is known (besides the AS path vector). In
   deciding which routes to advertise to external peers "transit
   policies", i.e., whose traffic is allowed to transit this AS is the
   prime consideration.

   In the MPLS and in particular the explicitly routed optical case we
   have a very strong additional policy mechanism, that of connection
                  draft-bernstein-optical-bgp-00.txt         July 2000

   admission control (CAC).  Although an optical AS probably shouldn't
   advertise transit capabilities that it doesn't wish to support, CAC
   during connection establishment will be the final arbiter of any
   transit policy.  In addition, some areas that are being addressed by
   policies in the IP datagram case such as load balancing are much
   easier to implement via CAC and/or explicit routing.

2.3. Multi-Domain Connection Control

   MPLS' loose routing allows one to specify a route for an optical
   connection in terms of a sequence of optical AS numbers.  This, for
   example, is handled via RSVP-TE's abstract node concept [5].
   Currently there is nothing in the GMPLS signaling specification that
   differentiates between intra AS boundaries, i.e., between two
   neighbor optical LSRs in the same AS, and inter AS boundaries, i.e.
   between two neighbor optical LSRs in different ASs.  Note that these
   same notions can apply to separate routing domains within an AS.
   There may however be some useful reasons for differentiating these
   two cases:

         1. Separation of signaling domains,
         2. Separation of protection domains.

   While routing protocols (used for their topology information) in the
   optical are not "service impacting", signaling protocols most
   certainly are.  It is desirable to build some type of "wall" between
   optical ASs so that faults in one that lead to "signaling storms" do
   not get propagated to other ASs.

   The natural situation where "signaling storms" would be most likely
   to arise is during network restoration signaling, i.e., signaling to
   recover connections during major network outages, e.g., natural
   disasters etc. In this case it may be very advantageous to break up
   general source reroute forms of restoration into per domain segments
   or to start reroute at domain boundaries rather than all the way
   back at the originating node.  Such a capability requires some loose
   coordination between the local, intermediate and global protection
   mechanisms.  This is typically implemented via hold off timers,
   i.e., one layer of protection will not attempt restoration until a
   more fundamental (local) form has been given a chance to recover the

   In other words: prevention of restoration related signaling storms
   may require the breaking up of a large network into multiple
   signaling (and hence routing) domains. These domains could be within
   the same AS. Routing across these domains will require some BGP-like
   protocol, hence another motivation for a BGP like protocol.

3.0. Diversity in Optical Routing

   There are two basic demands that drive the need to discover diverse
   routes for establishing optical paths:
                  draft-bernstein-optical-bgp-00.txt         July 2000

        1. Reliability/Robustness
        2. Bandwidth capacity.

   Many times multiple optical connections are set up between the same
   end points. An important constraint on these connections is that
   they must be diversely routed in some way.  In particular they could
   be link diverse (not traversing the same link) or node diverse (not
   traversing the same nodes).  Additionally insufficient bandwidth may
   exist to set up all the desired connection across the same path (set
   of links) and hence we need to know about alternative (diverse) ways
   of reaching the destination that may still have unused capacity.

3.1 Pick One! (route that is)

   With datagram routing we need to pick one route to a destination and
   make sure this choice is consistent throughout the AS.  In
   particular BGP specifically reduces the number of choices according
   to the following rule [6]:

        Fundamental to BGP is the rule that an AS advertises to its
        neighboring AS's only those routes that it uses. This rule
        reflects the "hop-by-hop" routing paradigm generally used by
        the current Internet.

   In the optical circuits case we are not using a "hop-by-hop" routing
   paradigm.  Hence it seems that BGP constrains our knowledge of
   diverse routes in the optical case.  This hits a major difference in
   use between the optical and IP datagram forwarding case.  In the
   optical case we are really interested in topology information that
   allows an optical connection path to be computed based on whatever
   criteria is desired for that connection.  In the IP datagram case we
   are interested in a consistent set of routes for use in hop-by-hop
   forwarding.  Hence the optical case has tended to favor link state
   protocols since they furnish raw topology information that can be
   used in computing routes as opposed to distance vector protocols
   whose output is a set of routes (without necessarily providing
   complete topology information).

3.2.  Some Additional Diversity Issues

   In a previous section we mentioned node and link diversity and gave
   a brief definition.  Unfortunately these definitions are not really
   adequate for optical networking.  Optical networks may posses a
   number of hierarchical signaling layers.  For example two routers
   interconnected across an optical network may communicate with IP
   packets encapsulated within an STS-48c SONET path layer signal.
   Within the optical network this STS-48c signal may be multiplexed at
   the SONET line layer into an OC-192 line layer signal.  In addition
   this OC-192 may be wavelength division multiplexed onto a fiber with
   other OC-192 signals at different wavelengths (lambdas).  These WDM
   signals can then be either lambda switched, wave band switched or
   fiber switched.  Hence when we talk about diversity we need to
   specify which layer.  In the previous example we can talk about
                  draft-bernstein-optical-bgp-00.txt         July 2000

   diversity with respect to the SONET line layer, wave bands, and
   optical fibers.  A similar situation arises when we consider the
   definition of node diversity.  For example are we talking with
   respect to a SONET path layer switch or an optical switch or

   The Shared Risk Link Group concept in reference [7] can help us with
   this type of information within an AS, but there are some additional
   complexities in the exterior routing case.  First its useful with
   respect to major outages (cable cuts, natural disasters) to have a
   few more types of diversity defined:

        1. Cable (conduit) diversity (allows us to know which fibers
           are in the same cable (conduit).  This helps avoid sending
           signals over routes that are most vulnerable to "ordinary"
           cable cuts (technically known as backhoe fades).

        2. Right of Way (ROW) diversity.  This helps avoid sending
           signals over routes that are subject to larger scale
           disasters such as ship anchor drags, train derailments, etc.

        3. Geographic diversity. This type of diversity can help one
           avoid sending signals over routes that are subject to
           various larger scale disasters such as earthquakes, floods,
           tornadoes, hurricanes, etc.

   We can attempt to extend the SRLG concept to links between ASs but
   we will need the two ASs to agree on the meaning and number of the
   list of 32 bit integers that comprise the SRLG, i.e., previously the
   SRLG concept was one of AS scope.  And this is also where things get
   tricky since it may not be possible to distinguish diverse routes
   based upon differing path vectors (i.e., AS number traversal list).
   The reason for this is due the fact that many carriers "fill out"
   there networks by renting either dark fiber or "lambdas" from a WDM
   system and hence although the path vectors may be AS diverse they
   may not even be fiber diverse.

   Hence there is a need for sharing of diversity information or
   constraints between ASs when setting up diverse connections across
   multiple ASs.  This gets us somewhat into a quandary over which
   information needs to be public and how to coordinate.  In this sense
   geographic link information may be the simplest and least
   contentious to get various players to disclose and standardize.

4.0. AS Capability Advertisement
   In addition to reachability information from an AS we will want to
        1. Switching capabilities
        2. Protection Capabilities
        3. Available Capacity
        4. Reliability Measures (if available)
                  draft-bernstein-optical-bgp-00.txt         July 2000

    The tricky part of advertising any of these properties is that we
   would like to summarize this information in a reasonable way so as
   to keep it reasonably brief and suitable for distribution within a
   routing protocol but at the same time deliver sufficient information
   to be of use in most path computation situations.  This is in
   general a topology aggregation problem, but to keep in the spirit of
   AS autonomy and opaqueness at most this would be represented as a
   "hub and spoke" type of aggregate where the "psuedo links" and the
   "hub" can posses various attributes corresponding to the previously
   mentioned capabilities.

5.0 Conclusion and Recommendations
   This draft highlighted some of the requirements for exterior gateway
   routing protocol for use in optical internetworking.  The
   similarities and differences between which of these requirements are
   currently answered by BGP and which would require extensions to BGP
   were discussed.  In addition, information that would need to be
   shared between optical domains in order for an exterior gateway
   routing protocol to be viable was discussed.

6. Security Considerations

   Security considerations are not discussed in this version of the

7. References

   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   [2] G. Bernstein, J. Yates, D. Saha, "IP-Centric Control and
      Management of Optical Transport Networks", IEEE Communications
      Magazine, October 2000.

   [3] G. Bernstein, E. Mannie, V. Sharma, "Framework for MPLS-based
      Control of Optical SDH/SONET Networks", <draft-bms-optical-
      sdhsonet-mpls-control-frmwrk-00.txt>, November 2000.
   [4] Rekhter Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
      RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems,
      March 1995.
   [5] Awduche, D., et. Al., "RSVP-TE: Extensions to RSVP for LSP
      Tunnels", Work in Progress, draft-ietf-mpls-rsvp-lsp-tunnel-
      07.txt, August 2000.
   [6] Rekhter, Y., and P. Gross, "Application of the Border Gateway
      Protocol in the Internet", RFC 1772, T.J. Watson Research Center,
      IBM Corp., MCI, March 1995.
   [7] Kompella, K., et. al. "IS-IS Extensions in Support of
      Generalized MPLS", Work in Progress, draft-ietf-isis-gmpls-
      extensions-01.txt, November 2000.

8. Acknowledgments
                  draft-bernstein-optical-bgp-00.txt         July 2000

9. Author's Addresses

   Greg Bernstein
   Ciena Corporation
   10480 Ridgeview Court
   Cupertino, CA 94014
   Phone: (408) 366-4713
   Email: greg@ciena.com

   Bala Rajagopalan
   Tellium, Inc
   2 Crescent Place
   Ocean Port, NJ 07757
   Email: braja@tellium.com

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