SDN Controllers in the WAN: protocols and applications
Some operators have recently been deploying SDN Controllers in the WAN for the first time. This presentation discusses the protocols needed to underpin a quasi-rea …
Talk Title | SDN Controllers in the WAN: protocols and applications |
Speakers | Julian Lucek, Juniper Networks |
Conference | NANOG73 |
Conf Tag | |
Location | Denver, CO |
Date | Jun 25 2018 - Jun 27 2018 |
URL | Talk Page |
Slides | Talk Slides |
Video | Talk Video |
Some operators have recently been deploying SDN Controllers in the WAN for the first time. This presentation discusses the protocols needed to underpin a quasi-real-time SDN Controller for the WAN, and the major applications of such controllers. The flow of the presentation is as follows: A/ How an SDN Controller gains visibility of the network, using the following ingredients (i) BGP-LS for topology discovery, including attributes of physical links such as bandwidth and metrics. This will include a discussion of how a controller gains visibility across multiple AS’s, in the case of multiple-AS networks, (ii) Streaming telemetry for link and LSP statistics and link latency data (iii) Status of traffic-engineered LSPs via PCEP B/ How an SDN Controller instantiates or modifies RSVP (via PCEP) or Segment-Routed (via PCEP) traffic-engineered LSPs across the network C/ Bulk Traffic Management use-case. This is especially useful for operators carrying large volumes of internet traffic and who need a way of automatically avoiding traffic hotspots. This is achieved by having the controller monitor link utilization and LSP utilization by consuming streaming telemetry from network nodes, so that it can work out which LSP(s) it needs to reroute in order to ease the congestion on hot links. D/ Creating LSPs to underpin particular service requirements, for example (i) diversely routed pairs of point-to-point LSPs to underpin path-diverse pseudowires, as a next-gen replacement for SONET private circuit services (ii) LSPs that follow the current minimum latency path, for delay-sensitive traffic (iii) pairs of diversely routed Point-to-Multipoint (P2MP) LSPs for Professional Broadcast TV and Financial Market Data feeds.