Bod and md vpn service status in g ant sa3 network service delivery
1 / 20

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

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' BoD and MD-VPN service status in GÉANT SA3 – Network Service Delivery' - jillian-bond

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Bod and md vpn service status in g ant sa3 network service delivery

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

Objectives network service delivery sa3
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.

Connectivity services problem statement
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

Network service solutions 2 different approaches
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

Bod service overview
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

Bod signaling and control flow
BoD Signaling and control flow


  • 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








Mdvpn service overview
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

Mdvpn service overview cont
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

Proof of concept


  • 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

Service footprint
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

Bridging bod and mdvpn
Bridging BoD and MDVPN


















Traffic engineering
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

Service operations and testing
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)


    • Testing service provisioning speed and bandwidth should be ongoing tests as well for both services

Network service delivery service catalogue
Network Service DeliveryService Catalogue


In service



Open Call


But what about campus networks
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







Mdvpn a efficient solution
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

What to monitor
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)

Mdvpn statistics monitoring
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.