Using the Path Computation Element to Enhance SDN for Elastic Optical Networks (EON)

Transcription

1 Using the Path Computation Element to Enhance SDN for Elastic Networks (EON) Daniel King Old Dog Consulting Victor Lopez, Juan Pedro Fernandez-Palacios, Oscar Gonzalez De Dios Telefonica I+D Quintin Zhao Huawei Page 1

2 Recent Network Developments Flexible and Elastic Networks Photonic Integrated Circuit (PIC) technology Paving the path towards cost effective transmission schemes beyond 100Gbps. Digital Coherent and SuperChannel technology solutions Variable >100Gbps client signals and cost effective >100Gbps transponders Capable of long reach up to 400Gbps without regeneration Cost effective and flexible transponders Flexi-grid The Sliceable-Bandwidth Variable Transponder (SBVT). Reduce bandwidth to extend reach More spectrum to extend reach More bandwidth over short reach A variable-sized optical frequency range. ITU-T Study Group 15 ( Page 2

3 EC FP7 IDEALIST Project Industry-Driven Elastic and Adaptive Lambda Infrastructure for Service and Transport (IDEALIST) Networks The work is partially funded by the European Community s Seventh Framework Programme FP7/ through the Integrated Project (IP) IDEALIST under grant agreement nº IDEALIST Website: The network architecture proposed by IDEALIST is based on four technical cornerstones: An optical transport system enabling flexible transmission and switching beyond 400Gbps per channel. Control plane architecture for multi-layer and multi-domain optical transport network, extended for flexi-grid labels and variable bandwidth. Dynamic network resources allocation at both IP and optical transport network. layer. Multilayer network optimization tools enabling both off-line planning, on-line network reoptimization in across the IP and optical transport network. Page 3

4 Control of Today s Networks Current network operation is not adapted to flexible optical networking Multiple manual configuration actions are needed for network nodes Network solutions from different vendors typically use specific OSS/ implementations Very long provisioning times Lack of network bandwidth flexibility and inefficient use of inherent function Applications Internet Voice CDN Cloud Business Umbrella OSS Network OSS Metro OSS IP Core OSS OSS Vendor A Vendor B Vendor C Vendor D Vendor E Vendor A Vendor B Vendor C Network s Metro Vendor A Metro Vendor A IP Vendor C IP Vendor C IP Vendor C Vendor B Vendor B Vendor B Page 4

5 EON Network Management Requirements The network does not need to be seen any longer as a composition of individual elements. Applications need to be capable of interaction with the network. Support of the next generation of variable and dynamic optical transport characteristics. Automated deployment and operation of services. Create a new transport connection for me Reoptimize my network after restoration switching Respond to how my network is being used Schedule these services Page 5

6 EON Network Management Requirements Discovery of network resources. Routing and path computation. Network resource abstraction, and presentation to application layer. Multi-layer coordination and interworking. Multi-domain & multi-vendor network resources provisioning through different control mechanisms (e.g.,, OpenFlow, GMPLS, MPLS). Policy Control. OAM and performance monitoring. Leveraging existing technologies What is currently available Must integrate with existing and developing standards Support for flexi-grid draft-ogrcetal-ccamp-flexi-grid-fwk draft-farrkingel-ccamp-flexigrid-lambda-label Page 6

7 Adaptive Network Manager (ANM) Development of a unified network provisioning and operational architecture for EONs. Based on Application-Based Network Operation (ABNO) framework. A -based Architecture for Application-based Network Operations IETF Draft: draft-farrkingel-pce-abno-architecture Service Management Systems Network Controller Internet Voice CDN Cloud Business ANM / ABNO OSS Metro Vendor A Metro Vendor B IP Vendor C IP Vendor D IP Vendor E Vendor A Vendor B Vendor C Network s 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 Page 7

8 Application-Based Network Operation (ABNO) Standardized components and co-operation. Policy Management Network Topology LSP-DB TED Path Computation and Traffic Engineering, PCC Stateful & Stateless Online & Offline P2P, P2MP, MP2MP Multi-layer Coordination Virtual Network Topology Manager Network Signaling & Programming RSVP-TE ForCES and OpenFlow Interface to the Routing System (I2RS) Page 8

9 ANM Use Cases ANM is the network management and operation platform being developed by IDEALIST for control of the EON. The following slides present the initial use cases shaping the development program: Multi-layer Path Provisioning Multi-layer Restoration Network Optimization after Restoration Page 9

10 ANM - Multi-layer Path Provisioning (Path) ALTO Server Policy Agent 2 VNTM 1 OSS 6 ABNO Controller 3 L3 I2RS Client OAM Handler 1. OSS requests for a path between two L3 nodes. 2. ABNO controller verifies OSS user rights using the Policy Manager. 3. ABNO controller requests to L3- (active) for a path between both locations. 4. As L3- finds a path, it configures L3 nodes using Provisioning Manager. 5. Provisioning manager configures L3 nodes using the required interface (RSVP-TE, OpenFlow, etc.) 6. OSS is notified that the connection has been set-up. Databases TED LSP-DB L0 Provisioning Manager 4 5 Client Network Layer (L3) Server Network Layer (L0) Page 10

11 ANM - Multi-layer Path Provisioning (No Path) ALTO Server Databases TED LSP-DB Policy Agent 5 2 VNTM 9 1 OSS ABNO Controller L0 7 3 L3 11 Provisioning Manager 8 12 Client Network Layer (L3) Server Network Layer (L0) I2RS Client OAM Handler 1. OSS requests for a path between two L3 nodes. 2. ABNO controller verifies right asking to the Policy Manager. 3. ABNO controller requests to L3- (active) for a path between both locations. 4. As L3- cannot find a path, it sends a request to the VNTM to create a new link in the VNT. 5. VNTM checks rights for the operation. 6. VNTM requests L0 to set-up a path between two locations. 7. L0 finds a path and tells provisioning manager to set-up the connection. 8. Provisioning Manager creates the path using the required interface (RSVP-TE, OpenFlow etc.) 9. Elements (Provisioning Manager and ) advertise that path is set-up properly. 10. VNTM advertises L3 that path is properly set-up. 11. L3 waits until TE adjacency appears in the TED and configures L3 nodes using Provisioning Manager. 12. Provisioning manager configures L3 nodes using the required interface (RSVP-TE, OpenFlow, etc.) 13. OSS is notified that the connection is properly set-up. Page 11

12 ANM - Multi-Layer Restoration ALTO Server Databases TED LSP-DB Policy Agent 4 3 VNTM OSS 9 1 ABNO Controller L0 L3 Provisioning Manager I2RS Client 2 OAM Handler 1. Upon network failure, the OSS notifies the ABNO controller of all failed L3 links and possibly of the root cause. 2. considers all free ports (including those that became inactive due to the failure), and proposes how to best reconnect the IP layer. 3. The OSS requests the new IP links between the relevant L3 nodes to the ABNO Controller. 4. ABNO controller verifies right asking to the Policy Manager. 5. ABNO controller requests to L3- (active) for a path between both locations. 6. As L3- finds a path, it configures L3 nodes using Provisioning Manager. 7. Provisioning Manager configures L3 nodes using the required interface (RSVP-TE, OpenFlow, etc.) 8. OAM Handler verifies new connectivity. 9. OSS is notified that the new IP links are up and tested (SNMP, etc.). 7Client Network Layer (L3) Server Network Layer (L0) Page 12

13 ANM - Optimization After Restoration ALTO Server Databases TED LSP-DB OSS/ / Application Service Orchestrator Policy Agent 3 2 VNTM ABNO Controller 5b 10 5a L0 L3 Provisioning Manager Client Network Layer (L3) 9 Server Network Layer (L0) 6 4 I2RS Client OAM Handler 1. OSS initiates a request for multi-layer reoptimization after restoration. 2. The ABNO controller checks applicable policies and inspects LSP-DB. Obtains relationship between virtual links and forwarding adjacencies and transport paths. 3. The ABNO controller decides which L3 paths are subject to re-routing and the corresponding L0 paths. 4. The ABNO controller requests new paths to the L3, using e.g. GCO and passing the currently used resources 5. L3 finds L3 paths, requesting the VNTM for Virtual Links. Virtual Links may need to be resolved via L0. 6. The responses are passed to the ABNO controller 7. The ABNO controller requests the VNTM to provision the set of paths, avoiding double booking of resources 8. The VNTM proceeds to identify the sequence of re-routing operations for minimum disruption and requests the provisioning manager to perform the corresponding rerouting. 9. Provisioning Manager sends the required GMPLS requests to the LO network nodes. 10. OSS is notified that the re-optimization is complete. Page 13

14 Next Steps for ANM & ABNO IDEALIST Adaptive Network Manager Design and development based on EON (SVBT) operational requirements. Presenting progress on ANM and control plane work at FUNEMS in Portugal, June Application-Based Network Operations Continued definition of use cases. Continued identification of protocol, interface and functionality gaps. Service interface to/from application/oss/. Definition of service templates. Investigation of protocol methods for communicating templates. Page 14

15 Questions? Thank you for your attention. If you have any questions please myself, or the other authors and contributors. Daniel King Page 15