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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16. 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?

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

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

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

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

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

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