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

Versions: (draft-aboulmagd-ipo-ason) 00 01 02

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

                                                             July, 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,3].

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

2. Conventions used in this document

Aboul-Magd               Expires January 2002                        1

Draft-ietf-ipo-ason-00.txt                                   July 2001

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

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-optical 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. The ASON architecture at the ITU is discussed in
   two documents. The first document is G.807 (previously known as
   G.astn)[3] describes network level, technology independent,
   requirements for the control plane of ASTN. The second document is
   G.ason [2], and it specifies architecture requirements for ASTN
   network as applicable to SDH transport networks and optical
   transport networks.

4. ASON/ASTN Architecture: An Overview

   ASON/ASTN architecture belongs to client-server models or the
   overlay network models as defined in [6]. The salient feature of
   this model is the existence of well-recognized boundaries between
   client networks and provider domains. Client/provider separation is

Aboul-Magd               Expires January 2002                        2

Draft-ietf-ipo-ason-00.txt                                   July 2001

   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.

   The ASON/ASTN is an architecture that allows for global connectivity
   as shown in Figure 1. Figure 1 illustrates user end systems
   connecting to a global ASTN/ASON network, which may be comprised of
   multiple provider domains. As an overlay model there is no trusted
   relationship between provider domains so the instantiated interfaces
   are E-NNIs. Within a provider domain, the instantiated interface
   between control plane entities is the I-NNI.

                +----+  UNI   +-----------------+  UNI   +----+
                |user|--------|                 |--------|user|
                +----+        |   global ASTN   |        +----+
                             /                   \
                            /                     \
                     +----------+         +----------+
                     |   ASTN   |  E-NNI  | ASTN     |
                     |provider 1|---------|provider 2|
                     +----------+         +----------+
                     /           \
                    /             \
                   /               \
                 |                   |
                 | +--+  I-NNI +---+ |
                 | |  |--------|   | |
                 | +--+        +---+ |

                  Figure 1: ASON/ASTN Global Architecture

   As applied to optical networks, the ASON network interfaces are
   further shown in Figure 2. 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:

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

       +--------------------------+    +--------------+
       |   ASON Control Plane     |    |              |
       |                          |    |              |
   UNI |  +------+ I-NNI +------+ E-NNI|    +------+  |    +------+
   ------>| OCC  |-------| OCC  |-|----|----| OCC  |  | NMI|      |

Aboul-Magd               Expires January 2002                        3

Draft-ietf-ipo-ason-00.txt                                   July 2001

       |  +------+       +------+ |    |    +------+  |<-->|      |
       |     ^              ^     |    |      ^       |    |      |
       +-----|--------------|-----+    +------|-------+    |      |
             | 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 2: Automatic Switching Optical Network (ASON) Interfaces

   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.

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

Aboul-Magd               Expires January 2002                        4

Draft-ietf-ipo-ason-00.txt                                   July 2001

   The control plane shall support either switched connections (SC) of
   soft permenant connections (SPC) of basic connection capability in
   transport networks. These connection capabilities types are:

   - Uni-directional point-to-point connection
   - Bi-directional point-to-point connections
   - Uni-directional point-to-multipoint connections

   The components of the control plane architecture are illustrated in
   Figure 3. This Figure illustrates the control plane functions and
   their relationships. These entities can be packaged in different
   ways, depending upon the required functionality.

        |                                                |
        |                                   +--------+   |
        |                                   |  PA    |   |
        |                                   +--------+   |
        |                                        |       |
        |                                        |       |
        |    +------+         +------+      +--------+   |
        X----| RTU  |---------| RT   |------|  LRM   |---X
        |    +------+         +------+      +--------+   |
        |                        |         /    |        |
        |                        |    -----     |        |
        |    +------+        +------+/     +--------+    |
        |    | PC   |        |  CC  |------|  CAC   |    |
        |    +------+        +------+      +--------+    |
        |                       |                        |

   PA = Policing Agent          RTU = Routing Table Update
   RT = Routing Table           LRM = Link Resource Manager
   CC = Connection Controller   CAC = Connection Admission Control
   PC = Protocol Controller

   X---  External Interface

          Figure 3: ASON/ASTN Control Plane Functional Components

   Directory service processes may be utilized by the control plane to
   provide a mapping/translation of names and association of these
   names between layer networks, sub-network domains (e.g., between
   provider domains), and user name translations. This process includes
   functions such as registration of a user within the ASON network
   (including association of a user name to an ASON name space).

5.1 Connection Controller Function (CC)

   The role of this function within the control plane is:

   - The management and supervision of connection set-ups;
   - The management and supervision of connection releases;

Aboul-Magd               Expires January 2002                        5

Draft-ietf-ipo-ason-00.txt                                   July 2001

   - The modification of connection parameters for existing

   In response to a connection request the function must co-ordinate
   the interrogation of the route table, requests to the call admission
   control function, and updating the status of connection points.

5.2 Route Table Function (RT)

   The route table function consists of a list of reachable
   destinations and for each destination a recommended egress link. The
   role of the route table function is to respond to the request from
   the connection controller for the egress link for a particular

   Note that there are likely to be significant differences between I-
   NNI and E-NNI RT functions. Further, the reachability may also be a
   function of the policy and routing constraints.

5.3 Route Table Update Function (RTU)

   Information stored in routing tables may be manually entered and
   updated, as in the case of static routing. However, networks may
   also automatically generate and maintain route tables and distribute
   them throughout the network (at least within a domain). The role of
   the route table update function is to:

   - Relay the contents of a local route table for a sub-network to all
     of its immediate neighbors;
   - Receive the route tables from immediate neighboring sub-network
     controllers and update local route table to reflect all of the
     destinations it can reach via its neighbors.

5.4 Connection Admission Control Function (CAC)

   The role of this function is to decide if there is sufficient free
   resource on a link to allow a new connection. If there is the call
   admission control may allow a connection request to proceed. If it
   is not allowed to proceed then the connection admission control
   informs the connection controller to either find a new route or,
   where none is available, notify the originator of the connection
   request that the request has been refused. In principle there is a
   connection admission control function associated with every resource

   Connection admission control can also be decided based on
   prioritization or on other policy decisions. CAC policies are
   outside the scope of standardization. The connection admission
   control interacts with:

   - The connection controller from which it receives connection
   - The link resource manager.

Aboul-Magd               Expires January 2002                        6

Draft-ietf-ipo-ason-00.txt                                   July 2001

5.5 Link Resource Manager Function (LRM)

   The role of this function is to keep track of the way link resources
   are allocated to connections. The two primary resources that are
   held by the link resource manager are capacity and connection
   identifiers. The link resource manager records the capacity as seen
   by the connection point group agent or access group agent and
   controls the allocation of capacity to connections when requested as
   part of the connection set-up process. The link resource manager
   interacts with:

   - The connection admission control function from which it receives
     requests for link resources;
   - The policing function for the setting and enforcement of policing
     parameters for a connection;
   - The connection controller that is informed by the link resource
     manager that a connection has been admitted or released.

   The behaviour of the link resource manager is dependent upon the
   type of connection involved and the policies in force for
   reservation and priority. As such the behaviour is technology
   In the case of circuit switching resource management is simple since
   the allocation of capacity is automatic when a link connection is
   connected to a connection.
   The link resource manager function looks after label mappings and
   variable capacity connections.

5.6 Connection Point Status Function (CPS)

   The role of this function is to provide the connection controller
   with visibility of the status of all the connection points on the
   boundary of the subnetwork.  The underlying CTP or TTP agents
   provide the connection point status function. The status is the
   state of the connection point as it proceeds through connection set-
   up and release.

5.7 Policing Agent Function (PA)

   The role of this function is to check that a connection is sending
   traffic according to the parameters agreed at connection set-up or
   as a result of a modification request. Where a connection violates
   the agreed parameters then the policing agent may instigate measures
   to correct the situation. Note: this is not needed for a CBR
   transport layer network. PA relates to the incoming connection only.

5.8 Protocol Controller Function (PC)

   The role of the protocol controller is to provide reliable transfer
   of control messages across the network by means of a defined
   interface. This permits messages to be tracked and to ensure

Aboul-Magd               Expires January 2002                        7

Draft-ietf-ipo-ason-00.txt                                   July 2001

   expected responses are received or that an exception is reported to
   the originator.

   Under normal circumstances signaling primitives are passed between
   the connection controller and the protocol controller within a sub-
   network controller. The protocol controller is semantically
   transparent to the messaging primitives as these result in external
   protocol messages and vice versa. Signaling messages are passed
   between protocol controllers in different sub-network controllers.
   Protocol controllers are used to transfer the following information
   Route table update messages via a route table update protocol

   - Link resource manager messages (where appropriate as in available
     bit rate connections) via a link resource manager protocol
   - Connection control messages via a connection controller protocol

   In addition, different protocol controllers may be implemented for
   the following, I-NNI, E-NNI, and UNI.

   In the case of a ôfabric controllerö there is an additional
   interface, the CCI, between the underlying fabric and the
   controller. This, in a single network element, is not subject to

6. ASON Control Plane: External Interfaces and Protocols

   The ASON CP as shown in Figure 2 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

Aboul-Magd               Expires January 2002                        8

Draft-ietf-ipo-ason-00.txt                                   July 2001

   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
     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 [7]. 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 [8] and RSVP-TE [9] 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

Aboul-Magd               Expires January 2002                        9

Draft-ietf-ipo-ason-00.txt                                   July 2001

   Internetworking Forum (OIF) has adopted both protocols in its UNI
   1.0 specifications [10].

6.2 ASON Internal Node-to-Node Interface

   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 [4] 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 [11] and RSVP-TE [12]
   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,

Aboul-Magd               Expires January 2002                       10

Draft-ietf-ipo-ason-00.txt                                   July 2001

   in support of link state information for generalized MPLS are
   described in [13, 14].

6.3 ASON External Node-to-Node Interface

   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) [15] 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/ASTN CP Transport Network (signaling 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

Aboul-Magd               Expires January 2002                       11

Draft-ietf-ipo-ason-00.txt                                   July 2001

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

   - The control plane protocols shall not assume that the signaling
     network topology is identical to that of the transport network.
     The control plane protocols MUST operate over a variety of
     signaling network topologies.

   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.

Aboul-Magd               Expires January 2002                       12

Draft-ietf-ipo-ason-00.txt                                   July 2001

   Common channel signaling links are associated with user channels in
   the following ways:

   - Associated, whereby signaling messages related to traffic between
     two network elements are transferred over signalling links that
     directly connect the two network elements
   - Non-associated, whereby signaling messages between two network
     elements A and B are routed over several signalling links, whilst
     traffic signals are routed directly between A and B.  The
     signalling links used may vary with time and network conditions
   - Quasi-associated, whereby signaling messages between nodes A and B
     follow a predetermined routeing path over several signalling links
     whilst the traffic channels are routed directly between A and B.

   Associated signaling may be used where the number of traffic channels
   between two network elements is large, thereby allowing a single
   signaling channel to be shared amongst a large number of traffic

   Quasi-associated signaling may be used to improve resiliency. For
   example consider a signaling channel that has failure mechanisms
   independent of the traffic channels. Failure of the signaling channel
   will result in loss of signaling capability for all traffic channels
   even if all the traffic channels are still functional. Quasi-
   associated signaling mitigates against this by employing alternative
   signaling routes. In other words the signaling network must be
   designed such that failure of a signaling link shall not affect the
   traffic channels associated with that signaling channel.

8. Transport Network Survivability

   In a transport network, survivability can be controlled by the
   ASON/ASTN control plane or by transport network mechanisms that are
   independent of the control plane. Survivability can be achieved
   either by means of protection, which requires dedicated capacity, or
   restoration which uses available spare capacity. Specific
   survivability mechanisms such as protection schemes or fast
   restoration schemes are beyond the scope of this recommendation.

   Soft permanent connections are set-up/torn down in response to
   requests initiated by the network management system. As such it is
   possible to determine survivability routings using operational
   support systems, with explicit path information relayed to the
   control plane or by the control plane itself.

   In the case of switched connections, survivability and routing are
   determined by the control plane.

   User requests for explicit survivability mechanisms (e.g. requests
   for 1:1, 1+1, ring, mesh protection etc.) are not supported, as the
   user should not have access to the topology of the provider network
   and in some instances the connection may require different protection
   mechanisms for different parts of the connection. However, the user

Aboul-Magd               Expires January 2002                       13

Draft-ietf-ipo-ason-00.txt                                   July 2001

   may request from the provider diverse connections (i.e. with no
   common routing).

   To provide diverse routing it is necessary to have access to
   information relating to the topology of the layer network in which
   the soft permanent connection or switched connection resides and all
   of the server layer networks including the fiber, cable and duct
   (also known as conduit). Full diversity also requires knowledge of
   the relationship between buildings/locations and transmission
   facilities. Mechanisms to support diverse routing, for those carriers
   wishing to support this functionality, may be provided by either the
   management plane, for soft permanent connections, or the control
   plane for either soft permanent connections or switched connections.

10. Relationship to GMPLS Architecture

   The relationship between ASON/ASTN control plane architecture and
   GMPLS-based protocols is established in section 6, where it has been
   shown how the different GMPLS protocol could be used for the
   realization of the different ASON/ASTN external interfaces.

   Recently, a GMPLS architecture [16] has been introduced. It is
   important to note that there is no real conflict between GMPLS
   architecture and the network architecture presented in this draft.
   ASON/ASTN provides a functional architecture of a control plane that
   allows the establishment of switched paths in optical networks. It
   provides the set of external interfaces that are necessary for the
   ASTN/ASON network to have a global reach. It does that, however, in a
   protocol independent fashion that can be realized in a different ways
   provided that its requirements are satisfied.

   The GMPLS architecture focuses more on the applications of GMPLS-
   defined protocols, e.g. CR-LDP for the setup of generalized LSP
   (GLSP) at the different interfaces of the network, e.g. I-NNI, UNI,
   etc. It does that in a more comprehensible way than what is described
   in section 6 of this draft.

11. Security Considerations

   This draft does not introduce any unknown security issues.

12. References

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

   2  Mayer, M. Ed., "Requirements for Automatic Switched Transport
      Networks (ASTN)", ITU G.807/Y.1301, V1.0, May 2001.

Aboul-Magd               Expires January 2002                       14

Draft-ietf-ipo-ason-00.txt                                   July 2001

   3  M. Mayer, Ed., "Architecture for Automatic Switched Optical
      Networks (ASON)", G.ason Draft v0.5.1, June 2001

   4  Ashwood-Smith, P. et. al., "Generalized MPLS- Signaling
      Functional Description", draft-ietf-mpls-generalized-signaling-
      04.txt, work in progress, May. 2001

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

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

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

   8  Aboul-Magd, O. et. al., "LDP Extensions for Optical User Network
      Interface (O-UNI) Signaling", draft-ietf-mpls-ldp-uni-optical-
      01.txt, work in progress, July 2001.

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

   10 Rajagopalan, B. Editor, "User Network Interface (UNI) 1.0
      Signaling Specifications", OIF Contribution, OIF2000.125.5, June

   11 Ashoowd-Smith, P. et. al., "Generalized MPLS Signaling: CR-LDP
      Extensions", draft-ietf-mpls-generalized-cr-ldp-03.txt, work in
      progress, May 2001

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

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

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

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

   16 Mannie, E., Ed., "Generalized Multi-Protocol Lable Switching
      (GMPLS) Architecture" draft-ietf-ccamp-gmpls-architecture-00.txt,
      work in progress, June 2001.

Aboul-Magd               Expires January 2002                       15

Draft-ietf-ipo-ason-00.txt                                   July 2001

13. Author's Addresses

   Osama Aboul-Magd
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, Ontario, Canada
   Phone: 613-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
   Email: Benjamin@nortelnetworks.com

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

   Ludovico Prattico
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, Ontario, Canada
   Phone: 613-763-1254
   Email: prattico@nortelnetworks.com

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

Aboul-Magd               Expires January 2002                       16

Draft-ietf-ipo-ason-00.txt                                   July 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 January 2002                       17

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