Embed Size (px)
DESCRIPTION
Luigi IANNONE - Luigi is currently an Associate Professor at Telecom ParisTech (Paris), since May 2012. He was previously Senior Research Scientist at Deutsche Telekom Innovation Laboratories (TLabs, Berlin Germany); post-doc Researcher at Université catholique de Louvain (UCL - Belgium); and worked at the Université Pierre et Marie Curie (Paris VI – France), first as Ph.D. candidate and later as post-doc. His current research interests include intra- and inter- domain routing, future Internet architectures, as well as mobility, wireless networks, and wired/wireless convergence. He is currently serving on the editorial board of Elsevier Computer Networks Journal. Luigi Iannone is also co-chair of the LISP Working Group at the IETF (Internet Engineering Task Force) and the main developer of the OpenLISP Project. Wenqin Shao – Wenqin SHAO is a PhD candidate at Telecom ParisTech. Meanwhile he is also a research engineer working for BORDER 6. He received an Engineering degree from Telecom ParisTech in 2013 and a Bachelor of Engineering in 2010 from Fudan University, Shanghai. He previously worked as solution manager and network architect separately for SFR and Wibox, both of which are French telecom operators. His current research interests cover internet routing and traffic engineering, and more generally enhanced solutions for operating network systems, so as to deliver ever-evolving services in a less constrained Internet. Abstract: “LISP (locator/Identifier Separation Protocol) brings a revolutionary model for routing in largescale networks. Its original aim is to help reducing the size of the routing tables and thus bringing better scalability to the Internet. Due to its inherent flexibility, there are today several scenarios and use-cases where LISP is experimented and deployed either to enable new features or to fix (or at least alleviate) issues with current models and protocols (e.g., VM mobility, IPv6 transition, traffic-engineering, etc.). These new and improved capabilities are experimented within two co-existing environments: the LISP Beta-Network (http://www.lisp4.net), where Cisco is a major contributor, and LISP-lab (http://www.lisplab. org), mainly built on the open-source OpenLISP Project (http://www.openlisp.org). Within this session, we propose to present a case study where LISP is used as a control-plane signaling protocol for traffic engineering over the Internet. It intends to showcase how the current Internet performance can be improved through coordinated traffic engineering via orchestrated source and destination Autonomous Systems routing decisions. Such an objective is achieved without touching or tweaking in any way the current BGP routing infrastructure. In the proposed deployment model LISP provides both control- and data- plane functions; with a full LISP stack on both ends, it can as well operate as an traffic engineering control-plane on top of the BGP routing infrastructure.
Citation preview
Internet Traffic Engineering with LISP
Wenqin Shao & Luigi Iannone [wenqin.shao, luigi.iannone]@telecom-paristech.fr
!!
PLNOG September 2014
Roadmap
• Why we need more than BGP for TE?
• Why is LISP the answer?
• What is LISP?
• LISP & TE
3
Sub-optimal Inbound Path (I)
data from
for this specific remote AS 80ms performance drop !!for this local AS 314.6GB inbound traffic 54% of total inbound traffic in 24h
4
Sub-optimal Inbound Path (II)
5
Sub-optimal Inbound Path (III)
Min Transit (ms)
Sub-optimal Inbound Path (IV)
6
!!Selective announcement !• stop announcing local prefixes to transit A !• advertise more specific local prefixes to transit B !
7
Sub-optimal Inbound Path (V)
connectivity risk not granular enough
all inbound traffic impacted
/20 [/21,/21]
Sub-optimal Inbound Path (VI)
8
!!AS prepending w/o BGP community !•prepend local AS’s ASN several times when announcing routes to transit A !!•add BGP communities that make transit A prepend its ASN several times when announcing local AS’s prefixes to certain upstream AS where locates the target remote AS
can’t override local preference setting unpredictable results
Need for Inbound Load Balancing (I)
9 data from
10
Need for Inbound Load Balancing (II)
Real time traffic rate > CDR possibility of losing guaranteed service quality > Interface rate certainty of packet loss !95th percentile traffic rate > CDR extra billing
if you don’t know how to balance the load, you pay more for bad service
Need for Inbound Load Balancing (III)
11
!!Selective announcement !• stop announcing local prefixes to transit A !• advertise more specific local prefixes to transit B !
not granular enough possibility of saturating Transit B if overdo
Need for Inbound Load Balancing (IV)
12
!!AS prepending w/o BGP community !•prepend local AS’s ASN several times when announcing routes to transit A !!•add BGP communities that make transit A prepend its ASN several times when announcing local AS’s prefixes to some upstream ASes
real data speaks not effective
can’t override local preference setting
Does BGP have a limit? (aka from where LISP comes from……)
0
100000
200000
300000
400000
500000
600000
88 89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09 10 11 12 13
http://bgp.potaroo.net/as2.0/bgp-
Com
mercial Internet
CID
RDotCom Bubble
2008’s Economic Backdrop
IPv4
IPv6Growth Fear!!!
13
Core/Edge Separation (aka do we really need a unique routing/addressing space?)
85%
14
Who are all those prefixes?
http://bgp.potaroo.net/as2.0/bgp-active.html
• Number of Active ASes: 48349
• Number of Origin Only ASes: 41274 (85%)
• Average entries per Origin AS: ~11
• Roughly ~454 000 Prefixes are Stub Networks
ASdASs
Packets in Core/Edge Separation
Internet (DFZ)
Core (Push Routing Model) Edge (Pull Routing Model) Payload
ASw
ASkASz
ASj
Oracle
15
ASdASs
LISP Locator/Id Separation Protocol
Internet (DFZ)
Core (Push Routing Model) Edge (Pull Routing Model) Payload
ASw
ASkASz
ASj
Oracle
Routing LOCator [RLOC] space (Push Routing Model) Endpoint ID [EID] space (Pull Routing Model) Payload
Mapping System
EIDsEIDd
RLOC1EIDd
RLOC2EIDd
RLOC2EIDs
RLOC1EIDs
16
Routing LOCator [RLOC] space (Push Routing Model) Endpoint ID [EID] space (Pull Routing Model) Payload
ASdASs
Internet (DFZ)
ASw
ASkASz
ASj
Mapping System
EIDsEIDd
RLOC1EIDd
RLOC2EIDd
RLOC2EIDs
RLOC2EIDd to EIDs to EIDd Payload
RLOC1EIDs
RLOC1EIDs
Where is EIDd ?EIDd-Pfx maps to: ! RLOC2EIDd
RLOC1EIDd
LISP Locator/Id Separation Protocol
17
Playing with Mappings
• What if mappings change dynamically based on: • traffic volume • policies • path quality (e.g., delay, packet drops, etc) • choose your metric…
EIDd-Pfx maps to: ! RLOC2EIDd
RLOC1EIDd
Just image the possibilities!
18
LISP & Sub-optimal Inbound Path
19
Remote AS specific mapping !generate a EID-RLoC mapping depending on the remote AS
EID-Pfx_X: RLOC_B
EID-Pfx_X: RLOC_B High RLOC_A Low
LISP & Inbound TE Agility
EID-Pfx_X: RLOC_B
EID-Pfx_X: RLOC_B High RLOC_A Low
EID-Pfx_X: RLOC_A
EID-Pfx_X: RLOC_A High RLOC_B Low
Goup specific mapping •identify groups •generate EID-RLoC mapping according to AS group
20
LISP & Inbound Load Balancing
EID-Pfx_X: RLOC_B 50% RLOC_A 50%
mapping entry is accompanied with LB weight need equipment implementation support
21
We finally have the right tool! (TE made easy)
• Presented use-cases will be tested on
• www.lisp-lab.org
In collaboration with
22
