High-Level Carrier Requirements for Cross Layer Optimization

1. High-Level Carrier Requirements for Cross Layer Optimization Dave McDysan Verizon

2. Outline • A few more multi-layer scenarios that could be optimized • Content on Demand delivery to wired and wireless users • Enterprise cloud computing • Issues with prior approaches to optimizing cross layer applications • Application signaling for resources (QoS, Bandwidth) • Discovery of resources via management query and management provisioning • Overlay networks which probe for lower layer network characteristics • Service providers seeking further optimizations in a number of multi-layer scenarios

3. Content on Demand Delivery to Wired/Wireless Users 1. Initial user service request for content to a wired device VoD Service Controller (ANC) 4. Check if Wireless Access and which LHE can support, augment backbone and/or access capacity if needed and possibly change LHE Wired End Users 2. Check if Wired Access and which LHE can support, augment backbone and/or access capacity if needed CE CDN TNC PE Local Area Head End 1 CE Wired Access Transport Network Content Ingestion CE Super Head End (SHE) Location 1 CE CE TNC PE PE PE PE Content Source CE Backbone Transport Network PE Wireless End Users Super Head End (SHE) Location 2 CE PE PE CE TNC PE CE CE Wireless Access Transport Network Application Cloud 3. User moves viewing of content to Wireless Device Local Area Head End 2 CE PE CE CDN ANC – Application Network Controller TNC- Transport Network Controller

4. Content on Demand (CoD) Delivery Optimization • Currently • Backbone, and Access “Transport” Network capacity is often statically provisioned • Homing to a specific Local Head End (LHE) is also often static • Popular content distributed from SHE to LHE and then stored there to achieve caching efficiency • optimization as to when to distribute to cache and allocate resources covered in problem statement presentation • Cross Layer coordination could optimize transport network (L1, L2, L3) and choice of application sites (e.g, LHE) more dynamically • Probably would not do this for individual CoD sessions, but instead if significant traffic pattern shifts occurred • For example, due to commuting, travel to particular events, response to outages in network elements, head end sites, etc.

5. Dynamic Enterprise Cloud Computing (CC) 1. Customer requests Cloud Computing (CC) service instance 2. CC service checks resource status, commands resource changes as needed Virtual Machines CC Service Controller (ANC) Customer Data Centers, Sensors, etc. 5. CC service releases all resources, updates status, 4. Customer releases CC service instance Storage TNC Processing PE Cloud Computing Center 1 CE TNC Apps CE Access Transport Network PE PE Virtual Machines PE 3. Customer executes Cloud Computing (CC) application TNC PE Storage Backbone Transport Network CE Cloud Computing Center 2 Processing PE Access Transport Network Apps CE ANC – Application Network Controller TNC- Transport Network Controller

6. Dynamic Enterprise Cloud Computing (CC) • Currently • Customer applications (e.g., in data centers, sensors, supercomputers, etc.) interconnected by mostly static L1/L2L3 networks • Some dynamic bandwidth on demand being done in access networks and backbone networks • In order to provide more capacity for peak application demand, virtualized resources (e.g., processing, storage, apps/OS) are being deployed in “Cloud Computing Centers” • Cross Layer Optimization could optimize transport network (L1, L2, L3) and Cloud Computing site selection and/or resource allocation more dynamically • May be done reactively in response to large requests • May also be done proactively in response to aggregate of a number of smaller request

7. Haven’t We Tried to Solve this Problem Before? (1) • Application signaling for resources (QoS, bandwidth) • FR, ATM Switched Virtual Connections driven by IP applications in 1990s • Not widely adopted • RSVP signaled by IP applications in 2000s • More adoption, but not widespread • RSVP-TE signaling for MPLS-TE coupled with resource status learned via IGP in 2000s • Most adoption to date, but scaling of control processing is O(N^2), N being number of nodes connected via a potentially full MPLS LSP mesh • Has issues when used in multi-layer networks • Higher layers don’t know about some actions that lower layers can take which impact QoS (e.g., increased latency seen by a higher layer due to a lower layer restoration action) • Communication of fate sharing instances not well communicated between layers if they are in different IGPs • Some drafts and discussion on this type of approach in L3VPNs

8. Haven’t We Tried to Solve this Problem Before? (2) • Discovery of resources via management query and management provisioning • SNMP semantics are local to a device or EMS (set of devices) • Good thing is that this type of data is quite accurate • Correlating devices or portions of layer networks requires maintaining an accurate database • Errors can create significant suboptimality • Even more difficult to do if one or more of the layers is also running dynamic control protocols • Large complexity needed to coordinate the interaction of multiple levels of control • Overlay networks which probe for lower layer network characteristics • Used by various applications to find least latency (e.g., VoIP, CDNs) • No means for overlay network to determine cause of a change in lower layer network characteristics (e.g., increased latency due to congestion, or rerouting) • No means for overlay to query and/or request change in characteristics from lower layer network • These can result in suboptimal overlay network performance and economics

9. What We Need is Some Better Tools • More Scalable Means for Applications to discover resource status and make requests for changes in resource allocations • Either in response to individual or aggregate demands • Pre-planned guaranteed reservations, or on-demand (may result in some requests blocked) • Define protocol means to communicate important characteristics from lower layer to higher layer networks • Dynamic and rapidly in response to changes • Communicate fate sharing to enable implementation of applications with high availability (as differentiated from those with lower availability) • Work across a variety of “transport” layer network technologies • L1 TDM, Lambda • L2 Ethernet, MPLS-based L2VPNs • MPLS-based L3VPNs