1 / 20

BoD and MD-VPN service status in GÉANT SA3 – Network Service Delivery

BoD and MD-VPN service status in GÉANT SA3 – Network Service Delivery. LHCOPN and LHCONE joint meeting – Pasadena (US) 3-4 December 2013 Brian Bach Mortensen/ NORDUnet , SA3 Activity Leader. Objectives Network Service Delivery – SA3.

Download Presentation

BoD and MD-VPN service status in GÉANT SA3 – Network Service Delivery

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. BoD and MD-VPN service status in GÉANTSA3 – Network Service Delivery LHCOPN and LHCONE joint meeting – Pasadena (US) 3-4 December 2013 Brian Bach Mortensen/NORDUnet, SA3 Activity Leader

  2. ObjectivesNetwork Service Delivery – SA3 • To ensure that the GÉANT service area is able to deliver multi-domain connectivity services and monitoring according to requirements from NRENs and their users. • To ensure that service deployment footprints are transitioned in place from GN3 and increased in GN3plus. • To ensure dependable roadmaps are provided for the multi-domain connectivity services. • To ensure that connectivity services are properly integrated with service management systems, as developed in SA4. • To deliver “best of breed” BoD provisioning systems for NRENs’ operations teams.

  3. Connectivity servicesProblem statement • Independent NRENs => 37 • Regional networks hidden behind NRENs • Campus/research attached to NREN/Reg. • Building customs solutions • But it’s a long command chain •  slow provisioning •  performance issue hard to solve •  last mile networks are not 24/7 • Clearly not scalable • Turn around time much too slow • Network Service Delivery activity is a “partnership” between NRENs to mediate the above mentioned problems

  4. Network Service Solutions2 different approaches • Bandwidth on Demand • Guaranteed bandwidth (obviously) • Point to point connectivity • Flexible resource allocation • Production service on the GÉANT backbone • Accessible through 27 GEANT pops • 10 NRENs involved • Multi Domain Virtual Private Network • Best effort service (as of speaking) • Point to point • Multipoint • Piloting effort – no production (as of speaking) • 17 NRENs involved

  5. BoD Service overview • BoDservice is using AutoBahn provisioning tool in the GÉANT backbone • Currently running NSI1.1 • We have chosen to make a clean slate redesign of our IDM to support NSI2.0 • Currently testing of latest draft is ongoing (r107) • Expected release of AutoBahn v3.0 March • Rollout immediately after! • Continuously engaging with “new” NRENs to widen the service footprint

  6. BoD Signaling and control flow sd • Resource allocation is dealt with at a layer on top of the backbones • Above local management systems • E.g. above Junos space in the GÉANT backbone • Reservation request are then communicated down through the management system • Introduces additional SW layer that needs to be tested • However, to keep networks manageable its important not to make hacks that short cuts the local management system • Taking our results back to vendor Domain A CP MN M1 L1 X X X

  7. MDVPN Service overview • A joint service delivered by NRENs and GÉANT backbone • GEANT provides VPN transport service • NRENs use the GÉANT VPN transport service • NRENs can provision as many VPNs as they want • Regional and campus networks connect via their NREN • Resilience may be increased due usage of “cross border” fibers • Once service is configure in network • Only configuration at the provider edge is necessary VPN provider and VPN transit provider VPN provider VPN transit provider VPN transport provider

  8. MDVPN Service overview (cont) • MDVPN service is an “umbrella” service: • L3VPN • P2P-L2VPN • MP-L2VPN (VPLS) • Based on • MPLS • BGP/MPLS IP Virtual Private Networks (VPNs) • RFC4364 • BGP-LU • Carrying label information in BGP-4 • RFC3107 • Available in many routers in the NREN footprint VPN provider and VPN transit provider VPN provider VPN transit provider VPN transport provider

  9. Proof of concept 15th,June2013 • Proof of concept demonstrated on SAT3 test-bed • Pioneer, DFN, NORDUnet, RENATER, AMRES, LITnet, FCCN, FUnet… • Being deployed in the backbone and interconnecting the first 6 NRENs during this week • Potentially a production service spring/summer 2014

  10. Service footprint • MD-VPN footprint • Combining the footprint of MD-VPN and BoDwhen possible and needed (p2p) • NSI2.0 in some domains and BGP-LU in others • An NREN connected to both services may choose to provision service using any of the above methods • Regional networks (not) likely to deploy BoD

  11. Bridging BoD and MDVPN BoDDOMAINS MDVPN DOMAINS NSI NSI L1 NREN A NREN C X PROXY NREN X X X NREN B U U U U

  12. Traffic engineering • Converged networks carry BoD and MD-VPN traffic on the same data plane…. • So the main difference is the ability to guarantee the BW • However few converged networks use traffic engineering capabilities AFAIK • Instead they use utilization monitoring and netflow dumps to do “what” if analysis on their networks • Policing of ingress traffic according to signaled bandwidth should be applied • Its done in the GÉANT backbone • Prioritization of research traffic over plain IP traffic • BoDconfigure through southbound API in each domain • MDVPN could use RSVP-TE or other methods available

  13. Service operations and testing • Assuring service is available through various methods: • Passive monitoring • Exported through local monitoring instance • Typically simple information • Utilization • Packet Drop • CMon (SA4 activity) • Active monitoring (service assurance) • Control plane monitoring (NSI) • Ethernet OAM (BoD & MDVPN) • MPLS OAM (MDVPN) • Testing service provisioning speed and bandwidth should be ongoing tests as well for both services

  14. Network Service DeliveryService Catalogue piloting In service piloting ? Open Call piloting

  15. Network Service Delivery Q&A

  16. But what about campus networks? • Going back to users located in campus networks • Small CE/PE required in order to provide tunneling service • Invite many “small” users • Advertise the services to end users • “Demo pack” installed in the labs • MDVPN usage example (L3VPN, L2VPN, BoD) • exceed the critical mass • Allow the end users to test the service – not wait until they request it • Examples • Juniper SRX100 • Delivers MPLS based service(s) to your desk • Juniper ACX100 • MPLS based services • Rack mounted (no fans) • LDP DoD support VPN1 VPN2 BoD VPN1 VPN2 BoD

  17. MDVPN a efficient solution … • A set of services useful for end users • Cover a wide scope of user needs:from the long-term infrastructure with intensive network usage to quick point-to-point for a conference demonstration • Scientist DMZ concept • Allow to access the highest network performance • Security is required within international collaboration context (patent, medical data) • Cost Reduction for international collaboration at site level • VPN is deployed much more faster • Based on MPLS and BGP standard • easy to configure • It's flexible and quick to deploy • No Cost in terms of CAPEX • OPEX cost reduction for NREN and DANTE • A service that you can not find in commercial ISP offer/portfolio because multi-domain

  18. What to monitor • Underlying principle behind this Multi-Domain VPN technology • The LSP is extended from a PE up to the remote PE in another domain Monitoring is decentralized: • monitor SDPs and SSPs state • Labeled unicast BGP peering • Multi-hop BGP VPNv4 peering Peerings to be monitored # of peering BGP reduction VPN Route Reflector (VR) label exchange (BGP protocol) in MDVPN service for L3VPN and L2VPN (Kompella)

  19. MDVPNStatistics Monitoring • The VPN transport provider (GÉANT) is not able to distinguish the different VPNs. • At GÉANT level, only SSP availability and usage (throughput statistics) will be provided. • The traffic carried by a particular VPN instance can be monitored, at least at interface (SDP) level. It is up to the NREN to provide statistics on their SDP • NRENs and GÉANT cannot provide a general view of VPN usage, so it will be on the responsibility of end users to manage this. • The list of the different statistics that should be collected at SSP level and at SDP level is not totally specified.

More Related