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

Versions: 00 draft-ietf-ipo-ason

IPO WG                                                    O. Aboul-Magd
Internet Draft                                                 M. Mayer
Document: draft-aboulmagd-ipo-ason-00.txt                   D. Benjamin
Category: Informational                                     B. Jamoussi
                                                            L. Prattico
                                                                S. Shew
                                                        Nortel Networks

                                                         February, 2001

 Automatic Switched Optical Network (ASON) Architecture and Its Related

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

1. Abstract

   This draft describes an architecture for intelligent optical
   networks. This architecture is called the automatic switched optical
   networks (ASON). ASON is a client-server architecture with well-
   defined interfaces that allows clients to request services from the
   optical network (server). ASON architecture and its generic
   automatic switched transport networks (ASTN) has been an active
   study area both at T1X1 and ITU [2].

   The protocols that run over ASON interfaces are not specified in
   [2]. The emerging of IP-based protocols, e.g. generalized MPLS [3],
   for the control of the optical layer makes it possible for the ASON
   architecture to benefit from the protocols design work that has been
   progressing at the IETF.

2. Conventions used in this document

Aboul-Magd                Expires July 2001                         1

         Draft-aboulmagd-ipo-ason-00.txt        February 2001

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

3. Introduction

   The existing transport networks provide SONET/SDH and WDM services
   whose connections are provisioned via network management protocols.
   This process is both slow (weeks to months) relative to the
   switching speed and costly to the network providers.

   An automatic switched optical network (ASON) is an optical/transport
   network that has dynamic connection capability. It encompasses
   SONET/SDH, wavelength, and potentially fiber connection services in
   both OEO and all-opical networks. There are a number of added values
   related to such a capability:

   - Traffic engineering of optical channels: Where bandwidth
     assignment is based on actual demand patterns.

   - Mesh network topologies and restoration: Mesh network topologies
     can in general be engineered for better utilization for a given
     demand matrix. Ring topologies might not be as efficient due to
     the asymmetry of traffic patterns.

   - Managed bandwidth to core IP network connectivity: A switched
     optical network can provide bandwidth and connectivity to an IP
     network in a dynamic manner compared to the relatively static
     service available today.

   - Introduction of new optical services: The availability of switched
     optical networks will facilitate the introduction of new services
     at the optical layer. Those services include bandwidth on demand
     and optical virtual private networks (OVPN).

   This draft describes the ASON architecture. ASON and its generic
   ASTN has been a topic of active discussion both at the T1X1 and ITU.
   The draft focuses on ASON control plane, its requirements, and
   related protocols.

4. ASON Architecture: An Overview

   The ASON network architecture is shown in Figure 1. In this Figure
   all the components that can form part of ASON are shown. The
   architecture shown is intended to allow switching of optical network
   connections within the optical transport network under control of
   ASON signaling network.

   There are three separate planes involved in the network:

Aboul-Magd                Expires July 2001                         2

         Draft-aboulmagd-ipo-ason-00.txt        February 2001

   - A transport plane (TP)
   - A control plane (CP)
   - A management plane (MP)

       +--------------------------+    +--------------+
       |   ASON Control Plane     |    |              |
       |                          |    |              |
   UNI |  +------+ I-NNI +------+ E-NNI|    +------+  |    +------+
   ------>| OCC  |-------| OCC  |-|----|----| OCC  |  | NMI|      |
       |  +------+       +------+ |    |    +------+  |<-->|      |
       |     ^              ^     |    |      ^       |    |      |
       +-----|--------------|-----+    +------|-------+    |      |
             | CCI          |                 |            |      |
       +-----|--------------|-----+    +------|-------+    |      |
       |     v              v     |    |      v       |    |      |
       |  +------+       +------+ |    |    +-----+   |<-->|      |
       |  | OXC  |       | OXC  | | PI |    | OXC |   | NMI+------+
       |  |      |-------|      |-----------|     |   |
       |  +------+       +------+ |    |    +-----+   |    Management
       | Transport Plane          |    |              |       Plane
       +--------------------------+    +--------------+

   OCC = Optical Network Controller        UNI = User Network Interface
   CCI = Connection Control Interface      OXC = Optical Cross Connect
   I-NNI = Internal Node to Node Interface
   E-NNI = External Node to Node Interface
   NMI = Network Management Interface
   PI = Physical Interface

     Figure 1: Automatic Switching Optical Network (ASON) Architecture

   The transport plane contains the transport network elements
   (switches and links) that carry the entity that is switched, i.e.
   optical connections. End-to-end connections are setup within the
   transport plane under the control of the ASON control plane (CP).
   This draft is concerned with the CP part of the ASON architecture.
   Both the TP and MP are out of the scope of this draft.

   ASON architecture belongs to client-server models or the overlay
   network models as defined in [5]. The salient feature of this model
   is the existence of well-recognized boundaries between client
   networks and provider domains. Client/provider separation is a
   direct recognition of today's networking realities where ownership
   of layer 3 and layer 1 equipment belongs to different organizations.
   This client/provider domain separation entails the running of
   different routing instants at each domain. Thus there is no need to
   share topology information between carriers and their clients.

5. ASON Control Plane: General Requirements

   A well-designed control plane architecture should give service
   providers better control of their network, while providing faster
   and improved accuracy of circuit set-up. The control plane itself

Aboul-Magd                Expires July 2001                         3

         Draft-aboulmagd-ipo-ason-00.txt        February 2001

   should be reliable, scalable, and efficient.  It should also be
   sufficiently generic to support different technologies and differing
   business needs and different partitions of functions by vendors
   (i.e., different packaging of the control plane components).  In
   summary, the control plane architecture should:

   - Be applicable to a variety of transport network technologies
     (e.g., SONET/SDH, OTN, PXC).  In order to achieve this goal, it is
     essential that the architecture isolate technology dependent
     aspects from technology independent aspects, and address them

   - Be sufficiently flexible to accommodate a range of different
     network scenarios. This goal may be achieved by partitioning the
     control plane into distinct components. This, allows vendors and
     service providers to decide the location of these components, and
     also allows the service provider to decide the security and policy
     control of these components.

   The ASON control plane can be divided into several components,
   namely, resource discovery, state information dissemination, path
   selection and path management components. These orthogonal
   functional components work together to complement each other and
   form an overall architecture. This approach is intended to avoid
   inappropriate focus upon certain functional components of the
   architecture, to the inadvertent exclusion of others, that could
   result in unnecessary dependencies and non-optimal solutions. The
   basic modules are described below.

5.1 Resource Discovery

   Resource discovery is defined as the transaction that establishes
   the adjacencies of the port-pairs. Its basic function is address
   discovery, service discovery, data path connectivity discovery,
   verification, and management.   The role of the resource discovery
   module is to establish a complete map of physical connectivity
   including attributes, remote identifiers, and real-time status. The
   control procedure of this component could be generic, yet, its
   contents could be technology specific.

5.2 State Information Dissemination

   State information dissemination is defined as the manner in which
   local physical resource information is disseminated throughout the
   network.  First, the local physical resource map is summarized into
   logical link information according to link attributes.  This
   information can then be distributed through the network piggybacked
   onto the control plane transport network IGP (Interior Gateway

5.3 Path Selection

Aboul-Magd                Expires July 2001                         4

         Draft-aboulmagd-ipo-ason-00.txt        February 2001

   Transport network routing procedures typically utilize explicit
   routing, where path selection can be done either by operator,
   software scheduling tools in management systems.  In a switched
   optical network, end-to-end optical channel connections are
   requested with certain constraints. Path selection for a connection
   request should employ constrained routing based algorithms that
   balance multiple objectives.

5.4 Path Management

   Path management mainly deals with path operations such as connection
   setup, modification, deletion, query, auto-rerouting, and protection
   switching/restoration.  Control messages could be conveyed through
   suitable signaling protocols.

   Network topology information is typically only provided on a link
   (and typically not at a link-connection) basis. Link connections are
   not advertised in the topology dissemination component due to
   drawbacks with respect to lack of scalability.  Therefore, the
   result of a path selection algorithm is also only at the link level.
   This implies that the local intelligence in the NE must decide upon
   the actual link connection that is used for that path.

6. ASON Control Plane: Interfaces and Protocols

   The ASON CP as shown in Figure 1 defines a set of interfaces:

   - User-Network Interface (UNI): UNI runs between the optical client
     and the network.

   - Internal Node-to-Node Interface (I-NNI): I-NNI defines the
     interface between the signaling network elements, i.e. OCC within
     the switched optical network.

   - External Node-to-Node Interface (E-NNI): E-NNI defines the
     interface between ASON control planes in different administration

   - Connection Control Interface (CCI): The CCI defines the interface
     between ASON signaling element, i.e. OCC and the transport network
     element, i.e. the cross connect.

   The different ASON interfaces are described in the next few
   sections. Candidate protocols for use at the different interfaces
   are also discussed.

6.1 ASON User-Network Interface

   ASON UNI allows ASON client to perform a number of functions

   - Connection Create: Allows the clients to signal to the network to
     create a new connection with specified attributes. Those

Aboul-Magd                Expires July 2001                         5

         Draft-aboulmagd-ipo-ason-00.txt        February 2001

     attributes might include bandwidth, protection, restoration, and

   - Connection Delete: Allows ASON clients to signal to the network
     the need to delete an already existing connection.

   - Connection Modify: Allows ASON clients to signal to the network
     the need to modify one or more attribute for an already existing

   - Status Enquiry: Allows ASON clients to enquire the status of an
     already existing connection.

   Other functions that might be performed at the ASON UNI are, client
   registration, address resolution, neighbor and service discovery.
   Those functions could be automated or manually configured between
   the network and its clients.

   Client registration and address resolution are tightly coupled to
   the optical network address scheme. Requirements for optical network
   addresses and client names are outlined in [6]. In general the
   client name (or identification) domain and optical address domain
   are decoupled. The client id should be globally unique to allow for
   the establishment of end-to-end connections that encompass multiple
   administration domains. For security, it is required that the nodal
   addresses used for routing within an optical domain do not cross
   network boundaries. The notion of closed user groups should also be
   included in ASON addressing to allow for the offering of OVPN

   Address registration and resolution usually involves some kind of a
   directory service. The client uses the registration process to
   register his identification with the provider network for a
   particular user group or groups. Address resolution involves the
   process of translating client names to network addresses. Address
   resolution can be performed at clients, edge network element, or at
   every administrative boundary entry. It could involves
   authentication and policy look up to make sure that a client has the
   necessary credentials to join a user group.

   ASON UNI realization requires the implementation of a signaling
   protocol with sufficient capabilities to satisfy UNI functions. Both
   LDP [7] and RSVP-TE [8] have been extended to be used the signaling
   protocol across the ASON UNI. The extensions involve the definition
   of the necessary TLVs or objects to be used for signaling connection
   attributes specific to the optical layer. New messages are also
   defined to allow for connection status enquiry. The Optical
   Internetworking Forum (OIF) has adopted both protocols in its UNI
   1.0 specifications [9].

6.2 ASON Internal Node-to-Node Interface

Aboul-Magd                Expires July 2001                         6

         Draft-aboulmagd-ipo-ason-00.txt        February 2001

   The I-NNI defines the interface between adjacent optical connection
   controls (OCC) in the same network. There are two main aspects of I-
   NNI. Those are signaling and routing.

   Path selection and setup through the optical network requires a
   signaling protocol. Transport networks typically utilize explicit
   routing, where path selection can be done either by operator or
   software scheduling tools in management systems. IN ASON, end-to-end
   optical channels (connections) are requested with certain
   constraints. Path selection for a connection request should employ
   constrained routing algorithms that balance multiple objectives:

   - Conform to constraints such as physical diversity, etc.

   - Load balancing of network traffic to achieve the best utilization
     of network resources.

   - Follow policy decisions on routing such as preferred routes.

   To facilitate the automation of the optical connection setup, nodes
   in the optical network must have an updated view of its adjacencies
   and of the utilization levels at the various links of the network.
   This updated view is sometime referred to as state information.

   State information dissemination is defined as the manner in which
   local physical resource information is disseminated throughout the
   network. First the local physical resource map is summarized into
   logical link information according to link attributes. This
   information can then be distributed to the different nodes in the
   network using the control plane transport network IGP.

   ASON I-NNI could be based on two key protocols, IP and MPLS. Since
   MPLS employs the principle of separation between the control and the
   forward planes, its extension to support I-NNI signaling is
   feasible. Generalized MPLS [3] defines MPLS extensions to suit types
   of label switching other than the in-packet label. Those other types
   include, time slot switching, wavelength and waveband switching, and
   position switching between fibers. Both CR-LDP [10] and RSVP-TE [11]
   have been extended to allow for the request and the binding of
   generalized labels. With generalized MPLS, a label switched path
   (LSP) is established with the appropriate encoding type (e.g. SONET,
   wavelength, etc.). LSP establishment takes into account specific
   characteristics that belong to a particular technology.

   MPLS traffic engineering requires the availability of routing
   protocols that are capable of summarizing link state information in
   their databases. Extensions to IP routing protocols, OSPF and IS-IS,
   in support of link state information for generalized MPLS are
   described in [12, 13].

6.3 ASON External Node-to-Node Interface

Aboul-Magd                Expires July 2001                         7

         Draft-aboulmagd-ipo-ason-00.txt        February 2001

   E-NNI is an inter-domain interface for use between ASON networks
   that are under different network administrations. It is similar to
   the UNI interface with some routing functions to allow for the
   exchange of reachability information between different domains. BGP
   is an IP based protocol that could be used to summarize reachability
   information between different ASON domains in the same manner as it
   has been in use today for IP networks.

6.4 ASON Connection Control Interface

   CCI defines the interface between the ASON signaling element (OCC)
   and the transport network elements. Connection control information
   is passed over this interface to establish connections between the
   ports of the optical transport switch. The CCI is included as part
   of ASON control plane because it enables switches of various
   capacities and internal complexities to be part of an ASON node.

   The protocol running across the CCI must support two essential

   - Adding and deletion of connections.

   - Query of port status of the switch.

   General Switch Management Protocol (GSMP) [14] fits CCI
   requirements. GSMP is a general-purpose protocol that allows a
   controller to establish and release connections across a switch.
   GSMP is well suited for network architectures that employs label
   swapping in the forwarding plane, e.g. ATM, FR, and MPLS. This
   property makes GSMP a good fit for generalized label as defined by
   generalized MPLS. GSMP extensions for generalized MPLS are yet to be
   worked out.

7. ASON CP Transport Network

   In this section, we detail some architectural considerations for the
   makeup of the transport network that is used to transport the
   control plane information.  For circuit based networks, the ability
   to have an independent transport network for message transportation
   is an important requirement.

   The control network represents the transport infrastructure for
   control traffic, and can be either in-band or out-of-band. An
   implication of this is that the control plane may be supported by a
   different physical topology from that of the underlying ASON. There
   are fundamental requirements that control networks must satisfy in
   order to assure that control plane data can be transported in a
   reliable and efficient manner. In the event of control plane failure
   (for example, communications channel or control entity failure),
   while new connection operations will not be accepted, existing
   connections will not be dropped. Control network failure would still
   allow dissemination of the failure event to a management system for

Aboul-Magd                Expires July 2001                         8

         Draft-aboulmagd-ipo-ason-00.txt        February 2001

   maintenance purposes. This implies a need for separate notifications
   and status codes for the control plane and ASON. Additional
   procedures may also be required for control plane failure recovery.

   It is recognized that the inter-working of the control networks is
   the first step towards control plane inter-working. To maintain a
   certain level of ease, it's desirable to have a common control
   network for different domains/sub-networks or types of network.

   Typically, control plane and transport functions may co-exist in a
   network element. However, this may not be true in the case of a
   third party control. This situation needs further study.
   Furthermore, addressing issues in the control plane vis-€-vis the
   transport network is also for further study.

   ASON CP transport network requirements includes:

   - Control plane message transport should be secure. This requirement
     stems from the fact that the information exchanged over the
     control plane is service-provider specific and security is of
     utmost importance.

   - Control message transport reliability has to be guaranteed in
     almost all situations, even during what might be considered
     catastrophic failure scenarios of the controlled network.

   - The control traffic transport performance affects connection
     management performance.  Connection service performance largely
     depends on its message transport. Time sensitive operations, such
     as protection switching, may need certain QoS guarantees.
     Furthermore, a certain level of survivability of the message
     transport should be provided in case of control network failure.

   - The control network needs to be both upward and downward scalable
     in order for the control plane to be scalable. Downward
     scalability may be envisioned where the ASON network offers
     significant static connections, reducing the need for an extended
     control network.

   Given the above requirements, it is critical that the maintenance of
   the control network itself not pose a problem to service providers.
   As a corollary this means that configuration-intensive operations
   should be avoided for the control network.

8. Security Considerations

   This draft does not introduce any unknown security issues.

9. References

Aboul-Magd                Expires July 2001                         9

         Draft-aboulmagd-ipo-ason-00.txt        February 2001

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

   2  Mayer, M. Editor, "Architecture for the Automatic Switched
      Transport Networks", ITU G.astn, Draft V.0.3, Nov. 2000

   3  Ashwood-Smith, P. et. al., "Generalized MPLS- Signaling
      Functional Description", draft-ietf-mpls-generalized-signaling-
      00.txt, work in progress, Oct. 2000

   4  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   5  Rajagopalan, B. et. al., "IP over Optical Networks: A Framework",
      draft-many-ipo-optical-framework-02.txt, work in progress, Nov.

   6  Lazar, M. et. al., "Alternate Addressing Proposal", OIF
      Contribution, OIF2001.21, January 2001.

   7  Aboul-Magd, O. et. al., "LDP Extensions for Optical User Network
      Interface (O-UNI) Signaling", draft-ietf-mpls-ldp-uni-optical-
      00.txt, work in progress, Dec. 2000

   8  Yu, J., et. al., "RSVP Extensions in Support of OIF Optical UNI
      Signaling", draft-yu-mpls-rsvp-oif-uni-00.txt, work in progress,
      Dec. 2000.

   9  Rajagopalan, B. Editor, "User Network Interface (UNI) 1.0
      Signaling Specifications", OIF Contribution, OIF2000.125.3, Dec.

   10 Ashoowd-Smith, P. et. al., "Generalized MPLS Signaling: CR-LDP
      Extensions", draft-ietf-mpls-generalized-cr-ldp-00.txt, work in
      progress, Nov. 2000

   11 Ashwood-Smith, P. et. al., "Generalized MPLS Signaling: RSVP-TE
      Extensions", draft-ietf-mpls-generalized-rsvp-te-00.txt, work in
      progress, Nov 2000.

   12 Kompella, K. et. al., "IS-IS Extensions in Support of Generalized
      MPLS", draft-ietf-isis-gmpls-extensions-01.txt, work in progress,
      Nov. 2000.

   13 Kompella, K. et. al., "OSPF Extensions in Support of Generalized
      MPLS", draft-kompella-ospf-gmpls-extensions-00.txt, work in
      progress, Nov. 2000.

   14 Doria, A. et. al., "Generalized Switch Management Protocol V3",
      draft-ietf-gsmp-08.txt, work in progress, Nov. 2000.

Aboul-Magd                Expires July 2001                        10

         Draft-aboulmagd-ipo-ason-00.txt        February 2001

11. Author's Addresses

   Osama Aboul-Magd
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, Ontario, Canada
   Phone: 623-763-5827
   E.mail: Osama@nortelnetworks.com

   Michael Mayer
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, Ontario, Canada
   Phone: 613-765-4153
   Email: mgm@nortelnetworks.com

   David Benjamin
   Nortel Networks
   Phone: 514-818-7812

   Bilel Jamoussi
   Nortel Networks
   600 Technology Park Drive
   Billerica, MA 01821, USA
   Phone: 978-288-4506
   Email: jamoussi@nortelnetworks.com

   Ludo Prattico
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, Ontario, Canada
   Phone: 613-763-1254

   Stephen Shew
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, Ontario, Canada
   Phone: 613-763-2462
   Email: sdshew@nortelnetworks.com

Aboul-Magd                Expires July 2001                        11

         Draft-aboulmagd-ipo-ason-00.txt        February 2001

Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into

Aboul-Magd                Expires July 2001                        12

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