Introduction

On Monday, we talked about two algorithms to compute routing tables:
1. The original Arpanet algorithm, RIP (Routing Information Protocol).
2. The currently used OSPF (Open Shortest Paths First) protocol.
We then discussed software implementation of switches and gave some examples of the performance you might expect.
Today, we begin by discussing hardware switch implementation.

Hardware Switch Implementation

Traditionally, high-performance switches and routers were implemented as specialized devices with Application-Specific Integrated Circuits (ASICs).
ASICs though generally have a much longer turnaround time to design and fabricate than software, so one would have a delay in the roll out of new features to switches in years, not days or weeks.
Nowadays, the turnaround time has decreased because of domain-specific processors, and the availability of the full architectural specification for switches that take advantage of these processors online through project like the Open Compute Project.
This allows you to download a blueprint of switch, buying the components and assembling them, much like you can build your own PC.
Then one can download a L2 or L3 stack off GitHub to run on your switch.
You can also buy pre-assembled versions for such "open/white-box" switches.

Hardware Switch Example

Above is a depiction of a white-box switch.
One difference from our Software Switch of last day, is the NPU (Network Processor Unit), a domain specific processor with an architecture and instruction set optimized for processing packet headers. This processor is for networking what a GPU might be for graphics processing.
NPUs are able to process packets in terabits per second (Tbps), fast enough to keep up with 32x100Gbps ports or the 48x40 Gbps ports of the diagram above.
Such a device can be programmed to be an L2 switch, an L3 router or a combination, just by a matter of programming. The exact same control plane software stack (control plane runs RIP, OSPF, BGP, etc., data plane does per packet processing/forwarding) used in a software defined switch still runs on the CPU.
The data plane programs are loaded onto the NPU by CPU just like shaders are loaded onto a GPU from a CPU for graphics.
P4 is an example language for writing NPU-based forwarding pipelines. P4 programs "compile" to the underlying NPU instruction set, but hide many of the differences between vendor instruction sets.

Hardware Switch Internals

NPUs rely on three internal components to make forwarding decisions quickly:
1. SRAM to buffer packets while they are being processed. Static RAM (SRAM) is an order of magnitude faster than dynamic RAM (DRAM) used by main memory
2. Ternary Content Addressable Memory (TCAM). This allows you to use keys to look up items in a table as the address into memory to look up that item. It allows keys to be written with 0,1, X where a key 10X1 would match for example both 1001 and 1011.
3. The use of a forwarding pipeline (implemented by an ASIC, but programmable). It executes a sequence of (MATCH, ACTION) pairs: if you match such-and-such field in the header, then execute this or that action.
Forwarding a packet might involve looking at multiple header fields. Each stage of the pipeline can be programmed to look at a different combination of fields. Using a pipeline allows multiple packets to be processed at a time. For example, Stage 2 in a pipeline might be performing a second lookup on Packet A while Stage 1 is operating on Packet B.
The last component of a white-box switch is a pluggable transceiver. This module takes care of all the media access details-- be it Gigabit Ethernet, 10-Gigabit Ethernet, SONET, etc. Such transceivers come in standardized form factors such as SFP+ and can be connect to a standardized bus (such as SFI - Serialize/Desserialize Framer Interface).

Software Defined Networks

Software Defined Networks (SDNs) attempt to further decouple the network control plane from the data plane, by moving the control plane into software run on commodity servers and using a standard interface across network devices between the control and data plane.
The standard interface allows any implementation of the control plane to talk to any implementation of the data plane, without having a dependency on one vendor's bundled solution.
This decoupling is often called disaggregation.
OpenFlow was the original interface for disaggregation. Now P4 can also be used.
Using dissagregation, a logically centralized control plane can control a distributed network data plane.
The state collected by this logically centralized control plane is maintained in a global data structure such as Network Map, the implementation of this data structure is still distributed over multiple servers, for example in the cloud in datacenters.
The logically centralized control plane can now manage interconnects between physical servers, and interconnect between virtual servers and containers. The number of virtual ports in the internet passed physical ones in 2012.
Note in the above: cloud providers often provide virtual servers which are supposed to act like real servers, but there might be several on one physical machine. Since they act as real server, they might act as if they are connected to an ethernet by a virtual port. Since there is a limit on the number of devices that can be connect to a single ethernet, one can also end up with virtual switches in this setting.

Network Operating Systems

SDNs developed in the 2010s along with the Network Operating System (NOS).
An NOS makes it easier to network control functionality, also known as control apps.
It abstracts the details of network switches and provides a Network Map abstraction to the application developer.
The NOS detects changes in the underlying network (switches, ports, and links going up and down), and the control application simply implements the behavior it wants on this abstract graph.
The NOS takes on the burden of collecting network state (the hard part of link-state, and distance vector), and the app is free to simply implement the shortest-path algorithm and load the forwarding rules into the underlying switches. This allows for a more globally optimized solution.

Global Internet

So far our discussion of internetworks has been somewhat "scalable".
Each router does not need to know each host on the internet, but it does need to know each network.
Today's internet has ten or hundreds of thousands of networks connected to it, and the routing protocols we've discussed so far don't scale to those kinds of sizes.
We next look at techniques which can scale to the needed sizes.
To discuss these techniques, we first recall from last day we described how using OSPF we split our internetworks into autonomous systems (AS's), where an AS might be an ISP or some other entity that is under one organizations administrative control.
Each router just needs to know how to route in its AS or AS's. (Might belong to backbone AS and some other one)
Two issues we need to address with scaling: (1) minimizing the number of network numbers that get carried around in the protocol, (2) making sure that the available IP addresses do not get consumed too quickly.

Interdomain Routing

So far we have looked at routing within autonomous systems (AS's) (aka domains), that is, internetworks under a single administrative control.
The interdomain routing problem is the problem of having different AS's share reachability information -- the IP addresses that can be reached via a given AS.
Each AS is allowed and needs to be able to set its own routing policies.
Such a policy might be to always prefer to send traffic via AS X versus AS Y, perhaps because, your AS gets a cheaper rate for sending traffic over AS X than over AS Y.
Other issues might be you can't send traffic through such and such country.
Whatever interdomain routing procedure is used, it needs to support such policies.
The first major interdomain routing protocol was the Exterior Gateway Protocol (EGP).
It severely constrained the topology of the AS's into a tree.
Its replacement is the Border Gateway Protocol (BGP) which we'll consider next.

The Multi-backboned Internet

Unlike EGP, BGP supports multiple backbone networks. These are usually called service provider networks.
The topology of today's network might be abstracted as:
Given this view of the internet, we define local traffic as traffic that originates and terminates within an AS; and we define transit traffic as traffic that passes through an AS.
We can classify AS's into three types:
- Stub AS - an AS that has only one single connection to one other AS. For example, a small corporation in the above
- Multi-homed AS - an AS that has connections to more than one other AS, but that refuses to carry transit traffic. A large corporation might be an example of this.
- Transit AS - an AS that has connections to more than one other AS and that is designed to carry both transit and local traffic. An example of this might be a backbone provider.

Challenges of Interdomain Routing

Scale - a backbone router must be able to forward any packet destined anywhere on the internet. CIDR helps control this, but still there are on the order of a couple hundred thousand of valid address prefixes.
Difficulty in Computing Path Costs - each AS might be using a different interior routing protocol, each with their own path metrics. So it is hard to combine these into one cost. Instead, interdomain routing advertises only path reachability.
Trust - Provider A might not believe certain advertisements from Provider B. For instance, B (for example, North Korea) might be misconfigured to say it supports routes to anywhere. This often means having policies of the form: "use AS X to reach prefixes p and q, if and only if AS X advertised reachability to these prefixes."

BGP

The current version of BGP is version 4.
When configuring BGP, the administrator of each AS picks at least one node to be a BGP speaker, this is essentially the spokesperson for the entire AS.
The BGP speaker establishes BGP sessions to other BGP speakers in other AS's.
BGP runs on top of TCP on port 179, and counts on the fact that TCP provides reliable transport of data.
A BGP speaker's neighbors are manually configured.
A BGP speaker can be viewed as belonging to more than one AS: It has its home AS as well as the AS of the BGP speakers it can talk with. These might not be the same. It has to belong to the latter so that TCP can be used between speakers without a chicken (use to BGP to route) and the egg (BGP needs route to work) problem .
Speakers send keep-alive messages every 60 seconds or so to keep the connections to their neighbors.
BGP sessions are used to exchange reachability information among AS's
When a speaker comes alive it sends to all its BGP neighbors the networks it knows of; thereafter, it only sends updates.
In addition to BGP speakers, the AS has one or more border gateways, these are routers through which packets enter or leave the AS.
Unlike distance-vector or link-state, BGP advertises complete paths as an enumerated list of AS's to reach a particular network.
Using paths for routing, is sometimes referred to as path-vector routing.
The complete path is needed to enable checking against a given AS's policies.
It also makes it easy to check for routing loops.

BGP Example

Assume in the above that providers are transit networks, customers are stubs.
A BGP speaker for the AS of provider A (AS 2) would be able to advertise reachability information for each of the network numbers assigned to customers P and Q.
These advertisements would be sent in so-called UPDATE messages.
So it would say: "128.96, 192.4.153, 192.4.32, and 192.4.3 are directly reachable from AS2."
The Backbone network AS 1 can advertise something like: "128.96, 192.4.153, 192.4.32, and 192.4.3 can be reached along (AS1, AS2)."
It can also advertise : "192.12.69, 192.4.54, and 192.4.23 can be reached along (AS1, AS3)."
In terms of the BGP message format the path (AS1, AS3), is referred to as the AS-PATH
The network portion of the message is referred to as the network prefix being advertised.
The advertisement also includes a NEXT HOP attribute which is the border router to use to start the path towards the given AS. So the advertisement received with AS1 from AS2 would include the NEXT HOP border router to get one to AS2.
The whole advertisement is referred to as Network Layer Reachability Information (NLRI).

In-Class Exercise

What would AS3 advertise to AS1 in the previous slide, if it also had a Customer T with networks 188.2 and 189.3.54?
Please post your solution to the Mar 8 In-Class Exercise Thread.

Integrating Interdomain and Intradomain Routing

Let's look now at how Interdomain and Intradomain Routing interact.
In the case of a stub AS, the border router is the only choice for routes out of the AS.
Such a router can inject a default route in the intradomain routing protocol, so that any network not explicitly advertised in the intradomain protocol is reachable through the border router.
A border router of a provider AS might learn either through BGP or through configuration that some networks are in a given customer AS.
It could then inject a route to that prefix into the routing protocol running inside the provider AS.
A border router in the backbone does not use injection, as given the number of prefixes this would be too costly.
Instead a variant of BGP called interior BGP (iBGP) is used (in contrast to the exterior or eBGP we have been discussing). iBGP is essentially BGP run with peers all within the same AS (in the case we're considering the AS is the backbone).
In iBGP we only advertise routes that come from outside the current AS we do not advertise routes from other peers with data from only within the current AS.
iBGP allows any backbone router to learn the best border router to use when sending a packet to any address.

More Integrating Interdomain and Intradomain Routing

If a packet comes into the backbone AS, it will be directed to the nearest speaker router, via intra-AS routing. This can be done because each of these speakers says in intra-AS land that it can handle all traffic external to the backbone. This means for the backbone AS the link state packets exchanged will not grow with each new incoming network.
Once at a speaker, the packet can be directed using the tables collected from BGP messages to the correct border router.
In a simple set-up, iBGP requires a full mesh of speakers -- every speaker would need to maintain connections to every other speaker.
To make this scalable central point routers called route reflectors are typically peered with several BGP routers to reduce the number of connections. Confederations, which are sets of AS's grouped into one, are also used.
To reduce the number of routes that need to be advertised, advertisements on this backbone might aggregate networks by decreasing the n in addr/n and only making a single advertisement for what was several advertisements from other AS's.
Still, the so-called global routing tables in the backbone as of 2018 have about 700,000ish entries.
A conventionalal intradomain routing protocol such as Distance Vector or OSPF is used to allow a router to know how to forward to that particular border router.

Route Selection BGP

If a BGP speaker has a choice of several different routes to a destination, it will choose the best amongst these according to its own local policies.
If, after these policies decisions, there still exists more than one route, then the route with the shortest AS-PATH is chosen.
If, after this, there is still more than one route, the one with the closest next hop is selected (where closeness is is determined by the intra-AS algorithm).
Finally, if more than one route still remains, the route that uses the smallest BGP Identifier is used.
A BGP speaker is under no obligation to advertise a route to a destination even if it has one.
BGP also supports negative advertisements if a route needs to be withdrawn.

Routing Areas

One thing to note: AS don't correspond to necessarily to OSPF areas.
An internetwork using OSPF might all be one AS, so we would then have the hierarchy: area - AS - Internet
The book abbreviates routers that border areas as ABRs (area border routers).

IPv6

Despite using subnetting and CIDR the number of available IPv4 addresses was exhausted in 2011.
To address this issue in 1991, the IETF began work on IPng (IP - the next generation), which later became IPv6.
This project also accreted additional problems that it would try to solve, for instance, real-time services, security support, autoconfiguration, and mobile host support.
Although many of these things were absent from IPv4 when IPv6 was first designed they were added to it later.

IPv6 Addressing and Routing and Allocation

IPv6 addresses are 8 two-byte numbers.
So the address space is 128 bits as opposed to the 32 bits of IPv4.
Like IPv4, IPv6 addresses are classless, but the address space is still subdivided in various ways based on the leading bits.
These leading bits specify the kind of use of that particular IPv6 address:
- all 0's -- unspecified
- 127 0's 1 -- loopback
- 1111 1111 -- multicast address
- 1111 1110 10 -- link local unicast (unique to the given network)
- 1111 1110 11 -- site local unicast (unique to the given private internetwork)
- Everything else

IPv6 Addressing Notation

The standard representation of an IPv6 address is as: x:x:x:x:x:x:x:x where each x represent a 4-digit hexadecimal number.
For example, 47cd:1234:4422:AC02:0022:1234:A456:0124
Often lead 0's are not written so 0022 becomes 22.
Since the address space is so huge, often many of these 4-digit numbers are 0. In which, case, it is common to not write that field. For example,
```
47cd:1234:5432:AC02:0000:0000:A456:0124
```
would be written as
```
47cd:1234:5432:AC02:::A456:0124
```
you don't need to repeat colons, so even more simply:
```
47cd:1234:5432:AC02::A456:0124
```
This is allowed provided you don't have multiple blocks of 0's
There are two different ways of having IPv4 compatible IPv6 addresses: (a) zero extend a 32 bit address to 128 bits; (b) ::FFFF:IP address. For example, ::FFFF:128.96.33.81
The former indicates the node is capable of understanding IPv6 the latter indicates the node only understands IPv4.

Hardware Switch Implementation - SDNs - Global Internet

Outline

Introduction

Hardware Switch Implementation

Hardware Switch Example

Hardware Switch Internals

Software Defined Networks

Network Operating Systems

Global Internet

Interdomain Routing

The Multi-backboned Internet

Challenges of Interdomain Routing

BGP

BGP Example

In-Class Exercise

More on BGP

Integrating Interdomain and Intradomain Routing

More Integrating Interdomain and Intradomain Routing

Route Selection BGP

Routing Areas

IPv6

IPv6 Addressing and Routing and Allocation

IPv6 Addressing Notation