saurav das, guru parulkar & nick mckeown stanford university
DESCRIPTION
Why OpenFlow /SDN Can Succeed Where GMPLS Failed. Saurav Das, Guru Parulkar & Nick McKeown Stanford University European Conference on Optical Communications (ECOC) 18 th Sept, 2012. What is the Transport Network good at?. Guarantees: Bandwidth Latency Jitter - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/1.jpg)
Saurav Das, Guru Parulkar & Nick McKeownStanford University
European Conference on Optical Communications (ECOC) 18th Sept, 2012
Why OpenFlow/SDN Can Succeed Where GMPLS Failed
![Page 2: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/2.jpg)
2
What is the Transport Network good at?
Guarantees:• Bandwidth• Latency• Jitter• Path
Bandwidth on Demand• Scheduled• On- Demand
Recovery
![Page 3: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/3.jpg)
TRANSPORT Network
INTERNET
The Future?
INTERNETEnterprise Private -LinesPrivate-Nets
CellularBackhaul
PSTN
All Services
As much as 60% of AT&T’s Transport Network directly or indirectly supports the Internet
A. Gerber, R. Doverspike. “Traffic Types and Growth in Backbone Networks”. OFC/NFOEC 2011
![Page 4: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/4.jpg)
4
What is the Transport Network good at?
Guarantees:• Bandwidth• Latency• Jitter• Path
Bandwidth on Demand• Scheduled• On- Demand
Recovery
What does the Internet want?
-- Give me a Big Fat Dumb Pipe
![Page 5: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/5.jpg)
5
Transport Network
Client Network
ClientNetwork
Client Network
Client Network
UNI
UNI
UNI
UNI
In theory…
In practice: There is no commercial deployment of an IP network in the world that dynamically interacts with a transport network using UNI/GMPLS
![Page 6: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/6.jpg)
6
Why did GMPLS fail? -- I
Transport Network
Packet Network
UNI
Router vendors can just say NO• Political Reason
SDN can help..
![Page 7: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/7.jpg)
7
Why did GMPLS fail? -- II
Transport Network
Packet Network
UNI
Routers can do it all• Technical Reason
But it will cost you..• Economic Reason
![Page 8: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/8.jpg)
SDN + Dynamic Circuits can help..
1
59%
See “Rethinking IP Core Networks” under Publications www.openflow.org/wk/index.php/PAC.C
![Page 9: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/9.jpg)
9
Why did GMPLS fail? -- III
9
EMS EMS EMS
Proprietary Interface Proprietary Interface
Vendor Islands
IP NetworkTransport Network
OSPF-TERSVP-TE + many many more
OSPF-TERSVP-TE
IP/MPLS Control Plane
GMPLS Control Plane
UNI
We Didn’t Make it Easy
![Page 10: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/10.jpg)
VOIPHTTP
VOIP
HTTP
VIDEO
Example Network ApplicationControl Function: Treat different kinds of traffic differently
Function Impl.: Use both packets and circuits, at the same time.
Traffic-type Delay/Jitter Bandwidth Recovery VoIP Lowest Delay Low Medium
Video Zero Jitter High Highest
Web Best-effort Medium Lowest
“Aggregation and Traffic Engineering in a Converged Packet-Circuit Network” OFC/NFOEC 2011
![Page 11: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/11.jpg)
11
SDN-Two Orders of Magnitude Lesser LOC
![Page 12: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/12.jpg)
12
Why did GMPLS fail? -- IV
Services are tied to Protocols – not easily extensible
![Page 13: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/13.jpg)
13
Adding a serviceWhat would it take in today’s networks?
B C J
Carrier need/idea
Ask vendors to implement
solution
B
C
J
XJBC
Long time later non-interoperable pre-
standard solutionsStandardCarrier Lab Trials
Limited Field Trials
DEPLOYMENT
3-5 year process..if it gets off the ground
Extensions…
![Page 14: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/14.jpg)
14
Adding a serviceProtocols may interoperate; Services don’t
OSPFv2
RSVP-TE
MP-BGP
I-BGP + RR
LDP RSVP-TE
MP-BGP
I-BGP + RR
LDPOSPFv2
RSVP-TE
MP-BGP
I-BGP + RR
LDP
Juniper Cisco Brocade
TE TE TE
Auto-RouteAuto-Bandwidth
PrioritiesLoad-Share
DS-TEFRR
Re-opt
Auto-RouteAuto-Bandwidth
PrioritiesLoad-Share
DS-TEFRR
Re-opt
Auto-RouteAuto-Bandwidth
PrioritiesLoad-Share
DS-TEFRR
Re-opt
![Page 15: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/15.jpg)
1515
Why is SDN the Right Abstraction?Extensibility of Applications/Services
NetOS
Packet and Circuit Switches
Unified ControlPlane
1. Common Flow Abstraction
2. Common Map Abstraction
Interface: OpenFlow Protocol
The Common Map Abstraction hides the complexity of the control plane from the applications/services. In effect it decouples the applications from
the protocols, thereby allowing the applications/services to be implemented in a simple, centralized, extensible way.
![Page 16: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/16.jpg)
16
1. Common Flow Abstraction
2. Common Map Abstraction
L4L3L2.5L2L1L0
IP Router
EthernetSwitch
Wavelength Switch
TDMSwitch
Multi-layerSwitch
Network Functions
Tables for identifiers and actions
Flow is any combination
Network - API
routing, access-control, mobility, traffic-engineering, guarantees, recovery, bandwidth-on-demand …
Switch - API
Unified Control Plane
State Collection, Dissemination & Application Isolation
Built for Performance Scale & Reliability
Network Operating System (netOS)
Configuration, Control over Forwarding & Monitoring
![Page 17: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/17.jpg)
17
Transport Network
Packet Network
UNI
Don’t want to give infoDon’t want to give up control
![Page 18: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/18.jpg)
18
Transport Service Provider’s Virtualization
Plane
ISP# 1’s NetOS
App App App
Transport Network
TN Slice
Packet Network
Virtualization
Virtualization == Isolation +
Programmability
ISP# 2’s NetOS
App App App
TN Slice
Packet Network
Common Maphere
Common Maphere
Data Plane Isolation- circuits!
Control Plane Isolation
Programmability
![Page 19: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/19.jpg)
19
Don’t want to give infoDon’t want to give up control
- -- give up some- -- only the part in the slice
- -- retain overall control via the virtualization plane
What’s the incentive?--- a new service
Otherwise-- stuck with UNI/GMPLS which no IP network uses
-- stuck being a dumb-pipe seller
![Page 20: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/20.jpg)
Transport network operators • dislike giving up precise (manual) control
• to an automated software control plane
• irrespective of how intelligent it may be
&
• decades worth of established procedures
Is there a gradual adoption path?
Why did GMPLS fail? -- V
![Page 21: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/21.jpg)
CK
CK
CK
PP
CK
P
CKP
Gradual Adoption Path
D
D
D D
D
D
DD
D
C C
D
D
DD
D
D
DD
D
D
D
DD
D
D
DD
D
ISP ‘A’ Client Controller
ISP ‘B’ Client Controller
ISP ‘C’ Client Controller
21
Transport Service Provider’s Virtualization
Plane
![Page 22: Saurav Das, Guru Parulkar & Nick McKeown Stanford University](https://reader035.vdocuments.net/reader035/viewer/2022062410/56816334550346895dd3bd73/html5/thumbnails/22.jpg)
Summary• Why did GMPLS fail ?
Router vendors can say NO SDN can help
Routers can do it all SDN + Optical switching can help reduce costs significantly
Did not make it simple SDN can be two orders of magnitude simpler
Services tied to protocols - not easily extensible SDN abstracts away distributed control, so applications can be
centralized – helps service/application extensibility Conservative nature of operators
SDN based Virtualization for sharing limited information, providing a new service and presenting a gradual adoption path