Internet DRAFT - draft-aboulmagd-ipo-ason
draft-aboulmagd-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
Protocols
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
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.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
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
separately.
- 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
Protocol).
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
domains.
- 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
including:
- 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
diversity.
- 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
connection.
- 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
services.
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.
(Reword)
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
functions:
- 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.
2000
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.
2000
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
K1Y-4H7
Phone: 623-763-5827
E.mail: Osama@nortelnetworks.com
Michael Mayer
Nortel Networks
P.O. Box 3511, Station C
Ottawa, Ontario, Canada
K1Y-4H7
Phone: 613-765-4153
Email: mgm@nortelnetworks.com
David Benjamin
Nortel Networks
2351 BOULEVARD ALFRED-NOBEL
ST LAURENT, QUEBEC, CANADA
H4S-2A9
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
K1Y-4H7
Phone: 613-763-1254
Stephen Shew
Nortel Networks
P.O. Box 3511, Station C
Ottawa, Ontario, Canada
K1Y-4H7
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
