Carrier Motivations and Requirements for Automatically Switched Optical

Carrier Motivations and Requirements for Automatically Switched Optical Network (ASON) by Wesam Alanqar and Tammy Ferris ITU-T Workshop IP/Optical (Chitose, Japan, 9 -11 July 2002) International Telecommunication Union

Abstract This paper discusses business motivations and network requirements for automatically switched optical networks from a service provider perspective. The paper identifies potential automatically switched optical network services, identifies optical network functions needed to support those services, and compares advantages of control vs. management planes for overlapping functions. Different migration scenarios from legacy management systems to optical control planes will be addressed taking into consideration the implications per deployment scenario. Service Provider Motivations and Requirements for ASON 2

Overview l Business Motivations for ASON Deployment l Optical Network Functions Needed l Management vs. Control Plane l Possible Deployment Scenarios l ASON Challenges and Future Research Areas l Summary Service Provider Motivations and Requirements for ASON 3

Business Motivations for ASON Deployment New Services l Differentiated Private Line SLAs l l Additional Protection/Restoration Mechanisms Bandwidth on Demand l Long-term Coarse Grained Pipes for Average Steady State Bandwidth l Short-term Finer Grained Pipes for Hitless Bandwidth Adjustment å Charging customers sooner for the service å Increase customer satisfaction l Partitioned Network Management View l More Configuration Flexibility å Closed membership å Additional security å O-VPN standardization under study in IETF and ITU Service Provider Motivations and Requirements for ASON 4

Business Motivations for ASON Deployment Cost Savings and Improved Operations l Reduce Current Operations Cost l l Common Terminology l Interface Integration Across Layers l l Reuse of Protocols at Different Layers Packet Network and Circuit Network Integration Improved Network Utilization l l l Shared Protection Paths Using Mesh Architectures Opportunity for Concentration Near Real-time Self Healing Capability Within Layer l Occurrence of Fault å Need for SLA manager to prioritize restoration of service l Recovery from Fault Service Provider Motivations and Requirements for ASON 5

Optical Network Functions Needed Automatic Switching Functions l Call Processing l l Allows Calls with No Connections (e. g. , short lived condition for restoration) l l Allows Multiple Connections Per Call Connection Modifications without Call Tearing Down (e. g. , equipment protection) Routing and Link Management l l Rapid Convergence of Network Topology Updates l Isolation of Topology or Resources Across Routing Areas l l Need for Constraint Shortest Path First (CSPF) Paths Link State Aggregation Connection Processing l Management and Supervision of Connection: å Set-ups, Releases, and Modifications of Parameters for Existing Connections Service Provider Motivations and Requirements for ASON 6

Optical Network Functions Needed Administrative Functions l Fault Management l l l Fault Isolation & Localization Link Connectivity Verification Address Configuration l l Addressing Independence l l Scalable Naming and Addressing Scheme Provisionable Addressing Traffic Management l Race limit (or pace) call and connection setup attempts into the network l Load balance across call and connection processes å Dual homed scenario for call processors å Alternate connection paths for connection processors l Record call/connection setup attempts and blockages, and usage å Data made available to management plane for analysis and long term storage Service Provider Motivations and Requirements for ASON 7

Optical Network Functions Needed Resiliency l Integrity and Reliability of Control Plane l Reliable Message Transfer of Optical Control Plane Messages l Control Plane Link Failure Capabilities l Control Plane Node and Node Component Failure Capabilities å Node Component is a field replaceable software or hardware entity l Protection of Data Plane Connections l Protection Options å 1+1, 1: n, no protection å Revertive and non-revertive l Protection Route Selection Options å Least cost, least delay, greatest diversity, alternate destination Service Provider Motivations and Requirements for ASON 8

Optical Network Functions Needed Security l Admission Control l Authentication of Client, Verification of Services, and Control of Access to Network Resources å Carrier E-NNI, I-NNI, UNI policies related to the above may vary l Prevention of Misconnection l For Data Plane Security å It may be helpful to support scrambling of data at layer 2 or encryption of data at a higher layer. l In the Event of Restoration å Event sequencing may be required. l Reporting of Security Violations l Generation of Alarm Notifications about Security Related Events å Ability to send to the management plane in an adjustable and selectable fashion Service Provider Motivations and Requirements for ASON 9

Optical Network Functions Needed Other Supporting Functions l Auto Discovery l Allows Peer Communication of Relationships l Allows Peers to Communicate Capabilities and Provisioning Information l Allows Peer Validation of Connectivity å Test connections not be used for new data connections. å Degree of validation required will vary / Integrity of information provided by the transport plane / Integrity of information provided by the management plane / Integrity of the processes used to establish relationships Service Provider Motivations and Requirements for ASON 10

Management vs. Control Plane l Control Plane Introduces Notion of a Call to an Optical Network l Control Plane May Add Need for Call Records l l Information Necessary for Billing Control Plane Adds Need for Demand Capacity Statistics l Demand Statistics å Usage provides aggregate usage information å Attempts provides aggregate call attempts å Blockages provides aggregate call blockages l Capacity Statistics å Capacity (available, used or under maintenance) l Other CP Functions Redundant with MP Functions l Control Plane Offers an Alternative Approach with Emphasis Toward Maximum Functional Distribution å Control plane functions can be contained in an NE å Make neighbor NEs collaborative, communicating peers Service Provider Motivations and Requirements for ASON 11

Possible Deployment Scenarios l Integration With Legacy Systems and Incomplete New Systems å Also applies to incomplete or incompatible automatically switched systems l Allocation of Functions Between Control Plane and Management Plane l l l Only Routing and Link Management Done via Management Plane Routing and Link Management, Call Processing, and Connection Processing All via Control Plane Mix of Switched and Not Switched Within Different Transport Network Layers l l l Client Layer Switched and Server Layer Not Switched Server Layer Switched and Client Layer Not Switched Mix of Switched and Not Switched Within Transport Network Partitions l l UNI, E-NNI, I-NNI, Sub-networks Combinations and Permutations of Above Service Provider Motivations and Requirements for ASON 12

Possible Deployment Scenarios Integration With Legacy Systems and Incomplete New Systems l Management Based Solution with In-house Development l l Carrier-specific control plane Expensive to maintain under dynamic market business requirements Integration scope is broader (multiple complex interfaces required) Provide a Thin Layer Above Multiple Vendor Control Domains l l l Carrier-independent control plane Less expensive to maintain under dynamic market business requirements Integration scope is narrower (control-management interface required) OSS-Management Plane Administrative Area Carriers-specific integrated control plane OSS-Management Plane Administrative Area Control-Management Interface API Control Domain 1 API Control Domain 2 I-NNI ? Carrier-independent integrated common control plane API Control Domain 3 I-NNI ? Control Plane-Administrative Area API Control Domain 1 API Control Domain 2 I-NNI ? API Control Domain 3 I-NNI ? Control Plane-Administrative Area I-NNI ? : Possible no standardized multi-vendor control domains Service Provider Motivations and Requirements for ASON 13

Possible Deployment Scenarios Mix of ASTN and Not ASTN Within Transport Network Partitions l One Domain ASTN, another Domain Not ASTN OSS-Management Plane Administrative Area Transport-Management Interface Control-Management Interface Contro l Domai Plane-Administrative Area Control n 1 Transport - Control Interface OXC Vendor domain 1 Optical Transport-Service Provider OXC Vendor domain 2 Service Provider Motivations and Requirements for ASON 14

Possible Deployment Scenarios Mix of ASON and Not ASON Within Transport Network Partitions l E-NNI Supported as Interface to other Providers, but not Fully Automatically Switched within Provider Network å Control and management planes need to collaborate for E-NNI requested connections å Routing and link management is done by the management plane å E-NNI call / connection processing is done by the control plane OSS-Management Plane Administrative Area Management-Control Interface Control Domain Administrative Area 1 Transport -Management Interface OXC OXC Vendor domain 1 domain 2 Optical Transport-Service Provider 1 E-NNI Management-Control Interface Control Domain Administrative Area 2 Transport -Management Interface OXC Vendor domain 1 OXC Vendor domain 2 Optical Transport-Service Provider 2 Service Provider Motivations and Requirements for ASON 15

ASON Challenges and Future Research Areas Per Functional Area l Automatic Switching l Routing Optimality with Long Holding Time Connections å Grooming of existing connections å Large overhead of message processing when little or no changes to network l Administrative l Role of Control Plane vs Management Plane å Alarm filtering and root cause analysis and fault isolation å Data replication and synchronization l Resiliency l l Security l l Signaling, Routing, and Link Management Message Storms Detection Of Dropped Calls Monitoring Call Performance when Connections are A Moving Target Keeping the ASON DCN Secure Other Supporting Functions l l Communicating Discovery Processes Need to be managed and scaleable Must Accept Input when no Automatic Discovery Between Peers Service Provider Motivations and Requirements for ASON 16

ASON Challenges and Future Research Areas Vendor Interoperability OSS-Management Plane Administrative Area 1 OSS-Management Plane Administrative Area 2 Control-Management Interface Third-Party or Sprint-Specific common control EC -NNI Control Domain 1 O-UNI I-NNI Control Domain 2 Control Domain 3 I-NNI Control Plane-Administrative Area 1 ATM C C 1 C C 2 C C 1 API Control Domain 1 API I-NNI ? Control Domain 2 API I-NNI ? Control Domain 3 Control Plane-Administrative Area 2 C C 3 C C 1 C C 2 C C 3 DCS Router IT-NNI ET-NNI ADM OXC Vendor domain 1 OXC Vendor domain 2 Optical Transport-Service Provider 1 OXC Vendor domain 3 OXC IT-NNI OXC OXC ATM OXC Vendor domain 1 domain 2 domain 3 Optical Transport-Service Provider 2 All management interfaces not even shown DCS Router ADM I-NNI ? : Possible no standardized multi-vendor control domains Service Provider Motivations and Requirements for ASON 17

Summary l Historical Industry Expressed Need for ASON l Enhanced Support of Packet Services (e. g. , IP, ATM, FR) å Harmony between demand capacity l Improved “Provisioning Speeds” over Management Systems (I. e. increased dynamicity of a connection) å Introduces call concept to optical network l Assumptions l Available Network Capacity Can be More Efficiently Utilized å Dynamic control mechanism l l At Least Some Connections Have Short Hold Times Value Propositions for ASON l Combination of NNI and UNI for New Services l NNI for Cost Savings å Trunk lines (NNI) became automatically switched before access lines (UNI) å A desire to find ways to best utilize optical networks Service Provider Motivations and Requirements for ASON 18

Summary: Packet & Optical Convergence Example Future Integrated Network l l l Overlay “Layered” model is the best fit for: transport layer and packet layer in different business units, topology isolation, security, scalability, upgradeable , and interoperability MPLS can be used in forwarding & control planes Forwarding: Tunneling L 2 cells/frames into MPLS labels Control: GMPLS or other control plane O-UNI between packet and transport layers and O-NNI within the transport layer Converged network IP G M P L S V O T A I F D T I P R M M C E MPLS Optical Transport Possible Layered Approach Sprint LD Packet layer O-UNI Optical Switch Fiber Optical Switch A S O N O-NNI Interfaces are (SONET, SDH, or OTN) framed Service Provider Motivations and Requirements for ASON 19