New Control Architectures for E2E networks

1. New Control Architectures for E2E networks • Juan Pedro Fernandez-Palacios, Telefonica I+D (jpfpg@tid.es) April 2013

2. Traditional core network operation is very complex and expensive • Core network operation is not adapted to flexible networking • Multiple manual configuration actions are needed in core network nodes • Network solutions from different vendors typically use particularized Network Management System (NMS) implementations • Very long service provisioning times CURRENT APPROACH FOR NETWORK PROVISIONING Service Management Systems Complex and long workflows for network provisioning over different segments (metro, IP core, Optical transport) requiring multiple configurations over different NMS Internet Voice CDN Cloud Business Umbrella Provisioning System Network Provisioning Systems Metro NMS IP Core NMS Optical Transport NMS NMS Vendor C NMS Vendor D NMS Vendor E NMS Vendor A NMS Vendor B NMS Vendor C NMS Vendor A NMS Vendor B IP Node Vendor C IP Node Vendor D Metro Node Vendor B IP Node Vendor E Optical Node Vendor A Optical Node Vendor B Optical Node Vendor C Metro Node Vendor A Core Network Nodes

3. Unified network provisioning architecture • Control plane and SDN pave the path towards a unified network provisioning architecture • Key building block of such unified network provisioning architecture are: • Network configuration interface: Multivendor edge nodes configuration (e.g OLT and BRAS, IP core routers, etc) by standard interfaces (e.gOpenFlow) • IT and network SDN orchestration: Coordinated network and datacenter resources control according to service requirements (e.g orchestrated Virtual Machine transfer among datacenters) • Network-Service API: Application level API hiding details of the network Service Management Systems Internet Voice CDN Cloud Business Network-Service API Multiservice network provisioning system (SDN Orchestrator) Network Provisioning Network configuration interface IP Node Vendor C IP Node Vendor D Metro Node Vendor B IP Node Vendor E Optical Node Vendor A Optical Node Vendor B Optical Node Vendor C Metro Node Vendor A Standard signaling mechanisms running over network nodes enabling flexible networking and automated network provisioning over different network segments (metro, core IP, optical transport) including multiple vendors Core Network Nodes

4. Basic SDN Approach for OpenFlow Domains Application Layer API ALTO SDN orchestrator OAM Handler SDN Controller SDN CONTROLLER PCE TED VNTM Provisioning Manager OpenFlow is based on the concept of actions that are applied to each packet of a given flow (Ethernet-level addresses, VLAN tags, IP addresses, MPLS labels or transport-level ports). The actions taken by SDN the controller comprise: inserting and removing tags (layer 2), performing routing (layer 3) and also providing differentiated treatment to packets (QoS) OPENFLOW Infrastructure Layer (e.gDataCenter)

5. Main actions to be taken by the SDN controller in E2E networks • 1) Discovery of network resources • 2) Routing, path computation • 3) Automated network orchestration in response to changing network conditions and service requirements • 4) Network resources abstraction to application layer • 5) QoS control and performance monitoring • 6) Multilayer interworking • 7) Multidomain/multivendor network resources provisioning through different control domains (e.gOpenFlowDataCenter, OpenFlow MAN, GMPLS optical transport…) E2E networks might be pure OpenFlow based one day, but the migration process will take some time 82nd IETF, Taipei

6. SDN controller based on standard building blocks Most of these building blocks are still on definition and standardization process Applications (Internet, CDN, cloud…) SDN Controller 4-ALTO 3-SDN orchestrator 5-OAM Handler 2-PCE 1- TED 6-VNTM 7-Provisioning Manager OPENFLOW NETCONF PCEP OPENFLOW CLI OPENFLOW GMPLS Optical Domains OpenFlow Optical Domain OpenFLow Data Center OpenFlow MAN Domain IP/MPLS core MPLS MAN

7. Inside SDN Orchestrator Cloud Services Live OTT Internet … API API API Network APIs Orchestration mechanisms (*) … CDN and nionetworkoptimizat CSO Link Provisioning Multilayer Orchestrator NETWORK OPERATING SYSTEM Provisioning Manager NetConf OpenFlow PCEP UNI Physical Network

8. E2E SDNcontrol SDN controller Virtual Machine (e.g BRAS) Multidomain L2 service provisioning CPE Access Network Metro Area Network Core Network Data Center Network Optical Transport Multilayer orchestration • Technical challenges: • Horizontal Orchestration. Automated L2 service provisioning through different packet switching domains (metro, core, datacenter). • Vertical Orchestration. This orchestration enables adaptive network resources allocation in IP and optical layers according to the traffic pattern to efficiently use network resources

9. Multidomain L2 service provisioning (short term) SDN controller OpenFlow CLI Virtual Machine (e.g BRAS) CLI CPE Access Network Metro Area Network Core Network Data Center Network Multidomain pseudowire over seamless MPLS Intra datacenter connection

10. Multidomain L2 service provisioning (Medium term) SDN controller OpenFlow OpenFlow Virtual Machine (e.g BRAS) OpenFlow CPE Access Network Metro Area Network Core Network Data Center Network Multidomain pseudowire over seamless MPLS Intra datacenter connection

11. Multidomain L2 service provisioning (Medium term) • For this scenario, OF is used to trigger control plane. This means that edge nodes have to decode OF and translate into CP messages. • For the case of creating a Pseudo-Wire following parameters are required: • Pseudowire Label • MPLS Label • Service VLAN (VLANs) • Output port OF Request CP node 2 1 OF Information Updated 3 4 OF and CP node enable node

12. Multidomain L2 service provisioning (Long term) SDN controller Common Interface SDN controller SDN controller SDN controller Virtual Machine (e.g BRAS) OpenFlow CPE OpenFlow Access Network Metro Area Network Core Network Data Center Network Connection to datacenter Intra datacenter connection • Options: • Hierarchical Approach. There is a controller which has a global view so it can orchestrate the configuration in each domain. • Peer Relationship. Each controller can request for information or connections to other peers.

13. Vertical Orchestration • Load balancing between IP and optical networks • Multi-layer restoration Access Region 2 Transit R2 • Increased survivability • Extended reparation processes • Capex Savings (best effort traffic only) Interconnection Transit R1 Access R1 Transit Backup R3 Transit R3 Access R3

14. EU projects situation in this picture Applications (Internet, CDN, cloud…) IDEALIST: Multilayer IP over FlexiGrid Orchestration STRAUSS: VM transfer orchestration SDN Controller 4-ALTO 3-SDN orchestrator 5-OAM Handler IDEALIST IDEALIST IDEALIST 2-PCE 1- TED 6-VNTM IDEALIST: IP and Flexgrid configuration 7-Provisioning Manager OPENFLOW PCEP, GMPLS OPENFLOW, GMPLS NETCONF OPENFLOW OFELIA STRAUSS DISCUS IDEALIST IDEALIST GMPLS FlexiGrid OpenFlow WSON network OpenFLow OPS Data Center OpenFlow Metro-Core Node (L3/L2/L1) IP/MPLS core

15. EU –Japan collaboration within STRAUSS project

16. List of potential topics for future collaboration EU-Japan • E2E SDN control (KDDI, NTT, NEC…) • Network Operating System • Multilayer and multidomain orchestration mechanisms • Network Functions Virtualisation • Optical data plane (NTT, Fujitsu, Osaka University, NEC…) • Subwavelength, Flexgrid, Optical OFDM • Sliceable and Programmable Transponders “sliceable” BVT. Figure from NTT. • Joint EU-Japan standardization contributions (IETF, ONF, NFV, ITU…)