Packet-Optical Integration using Virtual Topologies Wes Doonan TERENA May 2012

Packet-Optical Integration WAN has converged to two layers: Packet, Optical Packet Service Layer IP Routers, MPLS LSRs Provides various IP/MPLS services directly to clients Provides IP/MPLS infrastructure to Cloud/CDN applications Packet technology, Packet focus, Packet operational practice Optical Transport Layer WDM transport elements, ROADMs, regenerators, amplifiers Provides point-to-point wavelength services to Packet layer Enables optical bypass at router sites where needed Optical technology, Optical focus, Optical operational practice How to Integrate/Virtualize? ORD LAX ATL O-PCE P-PCE DIA PHX DFW

Traditional Layering Concept Client layer network Server layer network = link Connections in Server layer network create Links in Client layer network = server connections = element = client connection

Virtual Network Topologies Abstract representation of a real network Built from virtual components – virtual links, virtual nodes Purpose: Abstraction Represent multiple real components as a single virtual component Example: represent domain A as single virtual node in domain B Purpose: Adaptation Represent server layer network capabilities in client layer network Example: expose a lambda connection as a link in a packet topology Purpose: Activation Coordination activation of capabilities across layers, domains Example: server layer connection activated during client layer signaling Virtual Topologies are generally planned VNTs created during application planning process Prior to service provisioning, ongoing over lifetime of network Represent "potentialities" of the real network E.g. what real connectivity "can" be, when requested

Virtual Topology Concept Client layer network Planning Server layer network = link Connections in Client network trigger Connection setup Server network = server connections = element = client connection = virtual link

Virtual Links Represent "potential" connectivity in a topology Entered into standard Traffic Engineering databases (TEDB) Standardized TE extensions to regular IGP routing Advertised into client TE routing, standard LSA formats/TLVs Annotated with standard TE attributes (metric, bandwidth, etc) Essentially indistinguishable from normal "real" TE links Server network resources not committed to virtual link E.g. bandwidth/wavelength not committed until link is used Made available to path computers in the client network PCE computes paths using links in TEDB, real or virtual When link is used … E.g. when signaling in client network traverses a virtual link Server network control plane is activated Server network connections provisioned to commit resources If successful, signaling in client network allowed to proceed Virtual links coordinate information, activation across networks

GMPLS Overlay GMPLS UNI/ENNI Precursor: RFC4208 Interoperable service activation across layers and domains Precursor: RFC4208 Defines the overlay network model, concepts Outlines multiple scenarios, options, mechanisms Initially issued in 2005, considerable experience since then Update: draft-beeram-ccamp-gmpls-uni-bcp Presents "best current practice" for utilizing RFC4208 Derived from specific experiences, lessons learned Multi-layer activation, use of virtual topologies Label signaling across technologies Coordinating administrative status Routing updates to support virtual nodes Handling of generic constraints Codifies recent/ongoing experience with Packet/Optical interop

User #1 ORD Planning ATL LAX PHX DFW Packet Optical O-PCE = Packet

User #2 ORD Planning ATL LAX PHX DFW Packet Optical O-PCE = Packet

User #3 ORD Planning ATL LAX PHX DFW Packet Optical O-PCE = Packet

Link Activation ORD P-PCE User #2 LAX ATL User #3 PHX DFW User #1 Packet Optical O-PCE = Packet = Optical

Benefit: Diversity Control Virtual Links can reflect diversity of server network Server network connections may share fate Multiple wavelengths which share the same fiber Path computations in client network may require diversity Virtual links must expose fate sharing of server network connections Shared Risk Link Groups (SRLGs) Integer annotations to TE links, identifying fate-sharing groups SRLGs are per-layer/domain, must be coordinated Path computation considers annotations as constraints If paths are SRLG-diverse, guaranteed to not share fate Sharing Server Layer Client Layer SRLG = <nil> SRLG = <X> SRLG = <X>

SDN and OpenFlow Software Defined/Driven Networking Separation of control plane and data plane Direct, programmatic access to payloads and forwarding tables Centralized view of network topology and state OpenFlow defines protcols for flow/switch management Applied to flows in Layer-2 (Ethernet) and Layer-3 (IP) Flow table entries match MAC addresses, IP addresses, ports, etc Virtual switch administration, physical switch slicing OpenFlow provides an SDN mechanism for L2/L3 networks How could an optical network integrate with this? SDN App User LAX = Packet = Optical = OF Controller

Opportunities, Challenges Opportunity: Optical Integration and Interworking Integrate optical networks with existing L2/L3 networks Cross domain boundaries, leverage the SDN ecosystem Opportunity: Packet Networks are Digital Full payload visibility at every switch Switch fabrics are fully orthogonal Any packet on any interface switchable to any other interface Every network path is physically feasible All that matters is connectivity Challenge: Optical Networks are Analog No payload visibility at switches Switch fabrics are highly non-orthogonal Not all paths are feasible Paths may exist topologically which are not optically feasible Equalization, power budgeting, impairments; physics are messy Need a practical approach to interworking across domains

Analog Parameters Transponders / Muxponders Filters / Multiplexers Acceptable Rx Power, ONSR Actual Tx Power, ONSR Filters / Multiplexers Attenuation ROADMs Set Point Constant Gain Amplifiers Per-channel Gain Noise Factor Constant Power Amplifiers Per-channel Output Power Fiber Span Span Loss Source Firmware / Table Provisioned Measured g 1 P i,2 i,1 L A,1 nf 2 i,3 Tx1 Tx2 Mux,1 Connecting optical “flows” across optical networks requires deep/intimate knowledge of analog component characteristics

Potential Approach How can optical networks integrate with Packet SDN? Most SDNs primarily interested in L2/L3 problems Optics seen as point-to-point "wires" between L2/L3 domains Optics are complex, messy, configuration-intensive, constrained Optical domain often run by different group than L2/L3 Network Domains A "domain" represents a single region of administration and control Control domains have various attributes … Attachment points  Ports Adaptation functions at attachment points  Action Sets Connectivity between attachment points  Flows Sound familiar? Virtual Switch A single L2 switch / L3 router is a (highly localized) domain OpenFlow commonly assumes a controller-to-device ratio of 1:1 Instead, how about a controller-to-domain ratio of 1:1?

User #1 SDN App ORD User #1 PHX DFW Packet Optical O-PCE = Packet = OF Controller

User #2 SDN App ORD User #2 PHX DFW Packet Optical O-PCE = Packet = OF Controller

User #3 SDN App ORD User #3 PHX DFW Packet Optical O-PCE = Packet = OF Controller

Observations Virtual Links Virtual Switches Topology exposed to client defines server-layer utilization Transparent coordination between layers/domains Operator concentrates on packet layer, automates optical layer "Just enough topology" exposed to client, to serve applications Hide transport details where possible, expose where needed Packet layer can exercise more direct control over optical layer Helps with diversity discovery, needs more configuration Virtual Switches Simplest possible abstraction; "one big switch" Whole companies have been named after this concept  Encapsulates optical complexity Again, operator concentrates on packet service delivery rather than span losses and OSNR and Raman tilt and, and, and … Limited topological control When L2/L3 is the primary SDN focus, simplicity is good Result: choose the right tool for the specific problem at hand

Summary Multi-layer, multi-domain networks are a Reality Packet + Optical network technologies are intermixed Multi-layer control mechanisms are also real Architectures defined, standards in place Virtual Network Topologies enable inter-layer coordination Existing methods and abstractions, extended across layers Overlay networks manage inter-layer/domain interactions

Thank you wdoonan@advaoptical.com IMPORTANT NOTICE The content of this presentation is strictly confidential. ADVA Optical Networking is the exclusive owner or licensee of the content, material, and information in this presentation. Any reproduction, publication or reprint, in whole or in part, is strictly prohibited. The information in this presentation may not be accurate, complete or up to date, and is provided without warranties or representations of any kind, either express or implied. ADVA Optical Networking shall not be responsible for and disclaims any liability for any loss or damages, including without limitation, direct, indirect, incidental, consequential and special damages, alleged to have been caused by or in connection with using and/or relying on the information contained in this presentation. Copyright © for the entire content of this presentation: ADVA Optical Networking.