Bod and md vpn service status in g ant sa3 network service delivery
This presentation is the property of its rightful owner.
Sponsored Links
1 / 20

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


  • 120 Views
  • Uploaded on
  • Presentation posted in: General

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.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

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


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


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

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


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

BoDDOMAINS

MDVPN DOMAINS

NSI

NSI

L1

NREN A

NREN C

X

PROXY

NREN X

X

X

NREN B

U

U

U

U


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)

    • MPLS OAM (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

piloting

In service

piloting

?

Open Call

piloting


Network service delivery

Network Service Delivery

Q&A


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

VPN1

VPN2

BoD

VPN1

VPN2

BoD


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.


  • Login