Colt inter-provider SDN NNIs and APIs
•Download as PPTX, PDF•
3 likes•1,331 views
As SDN & NFV services become commercially available, the industry needs to approach once again the reach issue. There is not a single service provider with complete reach; that is why we build NNIs and need a wider SDN/NFV Ecosystem.
Report
Share
Colt inter-provider SDN NNIs and APIs
- 1. Colt SDN NNI Inter-provider Standard APIs BoF MEF Members Meeting – Q4 2016 Ottawa Simon Farrell, Javier Benitez Strategy & Architecture 25 October 2016 1
- 2. Agenda A new Era in Networking: SDN & NFV 2 Colt Overview On Demand Vision SDN NNI PoC API Evolution MEF LSO & Next Steps 1 2 3 4 5
- 3. On-Net Fibre Coverage Network Reach Partner Coverage • 24K + On-Net buildings • 585+ 3rd-party data centres • 29 Colt-owned DCs • 2500 PAON buildings • 205 city PoPs in 28 countries • 49 MANs • 49K+ km terrestrial network • 130K+ km subsea network • 919 COs (635 EFM) • 390 E-NNIs in 180 cities to 146 countries
- 4. On Demand Services (Colt Novitas) 4 Changing the nature of today’s network services: Self- provision Near real-time Interworking with other providers Available through portal and APIs Provides performance analytics And delivering important benefits: Supports value added services Elastic Topology Elastic Service Deliver programmable flexible topologies based on overlay and underlay networks. Deliver virtualised off-net and on-net L2 and L3 edge services on top of basic connectivity. SDN NFV Elastic Bandwidth Deliver programmable elastic links with variable bandwidth.
- 5. Available through the Colt portal or via API Intuitive / Human friendly Enables automation / Machine friendly Standard HTTP based RESTful API delivered with TLS over the internet or 5
- 6. Problem Statement: the need for a wider SDN/NFV Ecosystem • There is not a single SP with complete reach; that is why we build NNIs • But, traditional NNIs have been bespoke, i.e., very expensive to implement • Focused on replacing “electronic paper” and not the overall order/request management • As SDN & NFV services become commercially available, the industry needs to approach once again the reach issue (customers already asking) • Colt Novitas has been designed from day one with the vision to extend the new OnDemand network capabilities beyond Colt’s footprint and into third-party networks • Colt has engaged with a number of SPs to discuss and plan for real SDN inter- provider connections (consensus around the need to solve the reach issue) • Colt jointly with a Tier 1 US SP successfully built a PoC last summer demonstrating Ethernet on demand across the two networks, between US and EU • What now?: how do we drive the industry towards “agreed” APIs? And more importantly, how do we do it quickly? 10/25/2016 6
- 7. 10/25/2016 7 SDN NNI PoC (July’16) US Tier-1 SP Network US Tier-1 Service Provider site Colt London Beaufort House Colt Barcelona Colt Frankfurt US Tier-1 Service Provider portal Novitas portal Novitas engine Service Enquiry Service Activation Service modification (Bandwidth Flexing) Service Cease Novitas SDN API calls SDN E-NNI Scope: ordering, delivery and in-life management of Ethernet services between the east coast of the US and various locations in Europe using a live video stream to visualize the actions taken: our partner could, through their own online portal which communicated to the NOVITAS API, reserve ports, order a point-to-point Ethernet service, flex the bandwidth up and down and cease the service.
- 8. SDN & NFV NNI Full Concept Objective: drive the industry towards API “agreement” enabling scalable, simple, fast and cost-effective SDN & NFV Network to Network Interconnections. 8 Backend Access Ring 3rd-party Network Colt Network Node DC NNI 3rd-party portal Novitas portal OSS/BSSOSS/BSS SDN/NFV Service Abstraction Layer API Backend Colt SDN & NFV Controller 3rd-party SDN & NFV Controller API VNF A VNF B
- 9. APIs 25 October 2016 Presentation title 9
- 10. APIs - Technical detail • RESTful API • Username/password + persistent session • Simple domain model, initially Standard HTTP based RESTful API delivered with TLS over the internet using Object Create Read Update Delete Port Connection Request Product / Price • Partner = customer • One set of APIs for all clients
- 11. Under the hood
- 12. Evolution 25 October 2016 Presentation title 12 API Functionality •EPLs •Existing DCs •Single ME domain •Soft provisioning • EVPLs • Existing on-net with CPE • NNIs • CSP access • Long-running (hard provisioning) • EPNs • Multi-vendor CPE • Multiple ME domains • L3 services •Port •Connection •Request •Pricing • RBAC • Bill prediction • Intelligent route selection • Address book • Cloud resilience • Chain long-running requests • Performance Reporting • L3 services Ethernet Functionality Premature standardisation can hold back innovation Just In Time design Example: address book management Example: automated route selection
- 13. API Swagger example PUT /api/connection/<connection id> A HTTP PUT request to the /api/connections resource initiates the process of modifying an EVC. The body of the request must be a JSON object containing details of the EVC to be modified and its target specification. There are two forms of request. The first requests a commercial change of some kind – e.g. a change to the commitment period or a bandwidth change; this is uniquely specified by a price ID and takes the first form shown. The second form requests a change to non- commercial attributes, currently VLAN configuration. This operation requires a session token provided in the auth-token HTTP header. The response to this call is a HTTP 200 response code and a JSON object containing the URL of the trackable request that represents the EVC modification. { "price_id": "11", "coterminus_option":"true“ } } { "a_end_vlan_mapping":"F", "b_end_vlan_mapping":"F", "a_end_vlan_type":"C", "b_end_vlan_type":"C", "a_end_vlan_ids":[ { "from_id_range":23, "to_id_range":23 } ], "b_end_vlan_ids":[ { "from_id_range":23, "to_id_range":23 } ] } { “response_url": “https://ondemand.colt.net/api/requests/4662" } Request Object – commercial change Request Object – VLAN change Response Object
- 14. API technical evolution – under consideration HATEOAS?............many standards for JSON support Redesign API responses? SAML/Oauth…… “Nice to have” initially, now becoming important for UI & therefore APIs Redesign Authentication? Multi-language APIs?.....probably not Reconsider Swagger….does not easily support overloaded methods Websockets…. mainly for UI support & to eliminate API polling Eliminate or restrict polling? Proper semantic versioning…...big mistake not to include this from the start Developer sandbox with stateful model behind the APIs
- 15. Lessons learned Premature design stifles innovation - Use cases (and therefore APIs) are still evolving: add attributes, add query parameters, add new services Domain Objects vs Data Model - Data Model approach requires a crystal ball and an extremely generic model, which is harder to code against, not self-explanatory and easy to misinterpret - The same comment applies to API functionality No difference between customers and partners - (and salesmen!) 80/20 rule and YAGNI apply to API design exactly as they do to application design 25 October 2016 Presentation title 15
- 16. Thoughts on Standardisation Simplicity – juggle completeness of vision with ease of adoption Start small – Minimum Viable Product - Wait for adoption before extending - How many adopters constitute a critical mass? - The bigger the API, the harder it is to adopt: discuss! Post-adoption – what frequency is best to revise & extend? - Juggle requests for enhancement with stability/ ease of adoption - Providers will enhance the APIs themselves, anyway - How to adopt best practise as defined by what enhancements get used? Open source model – is forking good or bad? - Decentralised by its nature - Software is judged by number of pull requests, number of forks - But standards need stability! How to resolve this tension? 25 October 2016 Presentation title 16
- 17. Thank you For your time Any questions?
Editor's Notes
- So beginning with network reach and coverage, Colt has over 20,000 connected buildings in 42 metro networks across Europe. We can connect to over 450 DCs, CHs which represents over 60% of the European market! This is supported by our LDN, long distance network, which connects 23 countries and is used to provide national and international services. In addition to this, we have approximately 630 EFM – enabled central offices across Europe and circa 150 OLO partners with whom we have over 400 Ethernet E-NNIs in 121 locations. Of particular note, we’ve also identified over 2000 ‘pre-approved’ business sites close to our network, which we will connect On Demand at standard list pricing. A key message is that Colt continues to invest for growth through 4 related network expansion programmes that relate to each of these areas – some more details are on the slide. Through what we call Customer Driven On-Net Expansion, in the last year we added over 800 buildings, bringing our total to almost 20,000, and 30 additional Ethernet First Mile - enabled central offices, bringing the total to nearly 630 across Europe. As part of our Targeted Strategic Sites programme, we’ve continued to add data centres and key business sites to the network, 11 more in the last year, and we’ve also identified over 2000 ‘pre-approved’ business sites close to our network, which we will connect On Demand at standard list pricing. Our LDN continues to expand, and we’ve added 25 new city PoPs in the last year, bringing the total number to 192 across 23 countries. And we continue to expand our off-net partnerships with over 400 E-NNIs in 121 locations serving 65 countries, 3 global MPLS NNIs in 2013 with 2 more nearing completion.
- Colt have been evolving their Networks by adopting SDN and NFV to meet evolving demand of business globally and are delivering meaningful benefits for customers
- 5