Chapter 1

The Internet/BGP

Collection of Autonomous Systems (ASes)
Each is a network operator
Peered with one or more neighbours
There are different types of providers, although classification is fuzzy
Domestic ISPs: provide internet to a particular country/state/region
Global ISPs: have presence in several countries, connect their domestic counterparts
Content and cloud providers: do not charge for internet access, provide other services instead
Transit providers: large Tier-1 networks, customer are other service providers

A router at the border of an AS is called an AS Border Router (ABR)
ABRs speak to one another through the Border Gateway Protocol (BGP)
Runs on top of TCP
Also called external/ eBGP if the two endpoints are in diff. ASes
internal/ iBGP if within the same AS

Routers within an ISP have certain functions:
Provider Edge (PE): both internal and external connections
Provider (P): internal backbone connections to more than one other core router
(Devices can act as both P and PE)
AS Border Router (ASBR): ISP-owned core routers peering to other Service Providers
Not considered ASBRs when peered to customers

... more yapping about BGP ...

MPLS

MPLS was invented when Asynchronous Transfer Mode (ATM) was commonly used in WAN
ATM provided:
Multi-service
Async
Class of Service
Reduced forwarding state
Predictability
...
But also had downsides
No tolerance to data loss or re-ordering
No native integration with IP
...

MPLS learned from ATM
MPLS creates Label-Switched Paths (LSPs)
Attach label on first router
Route based on label, instead of constant IP lookup

Router roles in an LSP:

• Ingress PE / Ingress Label Edge Router (LER), LSP Head-end, LSP Upstream Endpoint
• Transit P, P-Router, Label Switching Router (LSR), P
• Egress PE, LER, LSP Tail-End, Downstream Endpoint

LSP Example

1. Packet arrive at PE1, destined for H3
2. PE1 pushes the correct MPLS label
   • Since H3 is reachable through PE4, it adds the label for that path: 1000001
     • Any labels are only significant to the source machine
3. PE1 sends the packet to P1
4. P1 receives the packet and inspects the MPLS label
   • It removes the original label, and based on it's value, pushes a new one: 1000002
     • Called a swap operation
5. P1 sends the packet to P2
6. P2 receives the packet, and processes the label
   • As this is the penultimate (second-to-last) router in the path, and Penultimate-Hop-Popping is default behaviour, it will remove the label and forward
7. P2 sends the packet to P4
8. P4 receives it without any MPLS header
   • This is fine, since P4 speaks BGP and is thus aware of IP routes and can forward to the destination
   • In this case -> BR4 -> H3

MPLS Header

20bits: MPLS Label
3b: Traffic class
1b: Bottom of stack
Set to one if this is the MPLS header in contact with the next protocol (i.e. IP)
Used to determine which is the bottom of the stack, since there is no header type nor stack size field
8b: MPLS Time To Live
Similar to IP TTL
Can either be copied from and to the IP packet or started at some arbitrary value

MPLS Forwarding

Only the topmost label is affected by operations
More than 1 label operation can be done by a node

... Some yapping about specific config in Junos

Forwarding Equivalence Class

A certain PE can be the next hop for 100,000 routes
Every packet that a PE maps to the same nexthop belongs to a single Forwarding Equivalence Class (FEC)
Any transit LSRs only need to know how to forward in the context of this FEC
Thus, 1 FIB entry instead of 100,000

Again, What is MPLS?

MPLS is not encapsulation
It is an architectural framework for decoupling transport from services
Service is IP
Transport handled by MPLS LSPs
Achieved by encoding instructions into packet headers

Another important aspect: instruction stacking
For network services that go beyond simple connectivity, this is a key feature

OpenFlow

Assumes:
A central controller is running somewhere
Which can communicate over in-band network connection, with pre-configured forwarding state

Each switch has a lightweight control plane (Agent) and a comparatively more powerful forwarding engine
Connected to the central controller over TCP
Most important part is the flow table

Example

1. Switch 1 gets a packet, realizes the flow is not in the flow table, forwards it to the controller instead
2. The controller has already learned where host B is (assumption) and is able to provide an instruction to switch 1 on how to handle this flow
3. Switch 1 (and later 2) receive this instruction and put it in their flow table
4. They can now successfully forward the packet

Flow-Based Forwarding

Openflow uses flow-based forwarding model

However, a model like that is not applicable everywhere
The internet core needs aggregation (FECs) not more state (flows)
Keeping state is more expensive than packet-based forwarding
Especially considering the short-timed nature of the internet (many small requests for e.g. pictures and ads)
But there are applications (e.g. CGNAT) that need flow-based control

Thus, when you need to choose:

1. Do I need flow-based forwarding?
2. If not, go with packet-based, as its simpler

P4

High-level control hides complexity, but reduces flexibility
Low-level control brings flexibility, but increases complexity

Only time will tell whether standardising the way a network device is programmed will increase or slow down innovation

SDN

Since the 1990s manufacturers have been gradually decoupling the forwarding and control planes
They may run in the same chassis, but they are separate
E.g. control on general-purpose CPUs, forwarding on a purpose-built ASIC

This decoupling is also a fundamental feature of SDN
Though SDN takes it further by not only decoupling but also centralising the control
Sometimes the centralisation is only logical, not physical. If you were to physically decouple too:
You need 2 networks, one for each function, what happens when one or both fail
Latency matters for responding to network events, how far can the controller be from forwarding elements

Data Center Overlays

A good use case foor SDN is the overlay architecture at data centers, assuming:

• There is an underlying network providing resilient connectivity between the overlay's forwarding plane (e.g. vRouter, vSwitch on a server) and the control plane (central controller)
• The latency is contained within working limits

WAN IP / MPLS

How does SDN apply to WAN IP and MPLS?

Although some control plane functions can be centralised, not all of them can
If you place the entire control plane 78458745 hops away, it ain't gonna go well
Thus, one must be tactical when applying SDN principles to WAN

Some centralised network-wide intelligence can help things like traffic engineering
The distributed control plane is enhanced by additional centralised intelligence

This shows that SDN is relevant to / can be applied to different degrees

SDN and the Protocols

... Discussion on whether Openflow is the cornerstone of SDN ...

BGP and MPLS are gaining momentum as SDN-enabler protocols
BGP is the most scalable protocol
The MPLS paradigm of decoupling service from transport is more-and-more relevant in deploying scalable SDN solutions

The SDN Era

SDN is used to solve two main things:
Automation: Creating the conditions to automate actions on the networks (config, provisioning, operation, troubleshooting, ...)
Abstraction: Achieving north-south communication by surpassing the vendor-specific barriers and complexities that customers had to adapt to, or avoid

The goal:

Say what you want and make the network smart enough to figure out the best way to achieve that

SDN-Era use cases

Data Centers

Demand has been growing massively
Turning from big LANs to hyperscalers
Some proposed architectures use OpenFlow with a central controller
But other technologies that work at scale are also considered:
Decouple transport and services (principle of MPLS)
Build a stable service-agnostic transport infrastructure (fabrics)
Provision services only at the edge, use scalable protocols for the control plane (BGP)

... Some more other use cases that do not seem to really demonstrate anything concrete ...