Network layer: data plane


We now leave the network edge and enter the core. Layer 3 is where machines that do not belong to you make decisions about your traffic: a router reads the Internet Protocol (IP) header, decides by which of its output links the packet should leave, and moves it there, billions of times a second, with only a few nanoseconds to spend on each packet. Today covers that mechanism, the data plane: a router has two jobs, and this is the one that handles an individual packet. We read the IP header field by field out of a real capture, see where IP addresses originate, and then walk through a router from input port to output link. How routers learn the information those decisions depend on is the control plane, next class.

Slides from class

Files:

Additional information:

Agenda

These notes follow the two jobs a router performs, then spend the bulk of their time on the first one. We review what each layer contributes to a packet, separate forwarding from routing and the data plane from the control plane, read the network layer header out of a real Domain Name System (DNS) query, see how IP addresses are allocated, and then work through a router from its input ports to its output links. A supplemental section at the end accounts for every byte of two complete Internet interactions.

Notes

We begin by placing Layer 3 among the layers around it, then turn to what a router does with the header that layer adds.

Review: what each layer adds

Each layer contributes one piece of critical information to a packet, and every piece is an address of some kind except the first:

Today's layer is the third one. One point to carry forward: the receiver decodes Layer 3 before Layer 4, which is why the Layer 3 header has to say what protocol sits inside it.

A router's two jobs: forwarding and routing

The network layer transports segments from a sending host to a receiving host. The sender encapsulates segments and passes packets down to the link layer; the receiver delivers segments up to the transport layer. Network layer protocols run in every Internet device, hosts and routers alike. A router examines the header fields of all IP packets passing through it, moves each packet from an input port to an output port along its end-to-end path, and in doing so sends traffic between LANs. Diagrams draw routers with truncated protocol stacks, because traditionally a router does not operate at Layer 4 or above.

A router has two jobs, and the standard analogy is taking a trip:

Concretely, here is what a router does when a packet arrives. The router strips the Layer 2 header; if the frame's destination MAC address matches the router's own, the router passes the payload up to its Layer 3, and otherwise it drops the frame. Layer 3 reads the destination IP address in the header, determines the IP address of the next hop, and determines which physical port connects to that next hop. The router then rewrites the Layer 2 header with the next hop's MAC address, which it obtains through the Address Resolution Protocol (ARP), and sends the packet out that port. The MAC rewriting we noticed back on Day 3 happens right here. Note also that the next hop may well not be the final destination.

Data plane and control plane

The data plane is a local, per-router function that determines how a packet arriving on an input port is forwarded to an output port. The control plane is network-wide logic that determines how a packet is routed among routers along the end-to-end path, and its product is the forwarding table that the data plane consults.

Two approaches to building the control plane exist, and the important thing about them is what they share.

Traditional routing puts routing algorithm components in each and every router. The routers communicate with one another to set the forwarding table that each one maintains locally, and that local table tells the router which link to use based on the IP address in the Layer 3 header.

Software-defined networking (SDN) separates the control plane out entirely. A remote controller computes routes and installs forwarding tables in the routers, and each router runs a control agent that talks to the controller. The data plane in an SDN network is the same as in a traditional one, which is the point worth keeping: the match-and-forward machinery below does not care about the origin of its table.

One aside on where protocols live. The IP protocol at Layer 3 covers the header format, IP addressing, and packet handling conventions, and the Internet Control Message Protocol (ICMP) sits alongside it doing error reporting and router signaling. Why do we consider ICMP a Layer 3 protocol? It deals in IP addresses, so it is not below Layer 3; it has no port numbers, so it is not Layer 4; and it carries no higher-level message, so it is not Layer 7. Path-selection algorithms such as Open Shortest Path First (OSPF) and the Border Gateway Protocol (BGP), or an SDN controller, belong to the control plane and arrive next class.

The best-effort service model

What service model should the channel that carries datagrams provide? A rich menu is imaginable. For a flow of datagrams: in-order delivery, a guaranteed minimum bandwidth, and restrictions on changes in inter-packet spacing. For individual datagrams: guaranteed delivery, guaranteed delivery within a bounded delay, and encryption.

The Internet's answer is best effort, which provides none of these. There is no guarantee of successful delivery to the destination, no guarantee of the timing or order of delivery, and no guarantee of the bandwidth available to an end-to-end flow. Other architectures made other choices. Asynchronous Transfer Mode (ATM) offered Constant Bit Rate and Available Bit Rate services, each guaranteeing timing or ordering or both, and the Internet community proposed Intserv Guaranteed (RFC 1633) and Diffserv (RFC 2475). Best effort is what won.

Recall the origin of the guarantees you do get. TCP at Layer 4 provides non-loss and in-order delivery, but provides neither bandwidth nor timing. Everything the network layer refused to promise was built somewhere above it: reliability in TCP, low latency in content delivery networks (CDNs) placed close to clients, ordering in the receiver's buffer. That pattern is the end-to-end argument in action, and it is the reason the core could stay simple enough to scale.

Why did such a minimal model succeed? The simplicity of the mechanism let the Internet be deployed and adopted widely; sufficient provisioning of bandwidth makes real-time applications good enough most of the time; replicated application-layer services provide from many locations what the network will not guarantee from one; and congestion control of elastic services helps. Proposals for guaranteed performance keep appearing, and the classic best-effort approach keeps proving good enough, even for demanding applications such as Netflix.

The network layer header

These are the fields a router uses to decide where to send a packet. The values below come from a real DNS query in dns.pcapng, which the supplemental section takes apart in full; reading them in hexadecimal alongside the decimal is a useful skill when you are staring at raw bytes.

The origin of IP addresses

An IP address is a 32-bit identifier associated with each host or router interface, not with a host. An interface is the connection between a host or router and a physical link. Routers typically have many interfaces, and hosts typically have several. Dotted-decimal notation simply writes the four bytes in decimal: 223.1.1.1 = 11011111 00000001 00000001 00000001.

The course virtual machine (VM) shows this directly. Running ifconfig lists several interfaces, each with its own address: eth0 at 192.168.159.129 for the Ethernet connection, docker0 at 172.17.0.1 and two bridge interfaces at 10.10.0.1 and 10.20.0.1 for Docker's virtual networks, and lo at 127.0.0.1 for loopback. One machine, five addresses, because addresses belong to interfaces.

Getting an address is really two questions: how does a host get the host part of its address, and how does a network get the network part?

The host part

Either a system administrator hard-codes it in a configuration file, such as /etc/rc.config on a UNIX system, or the host gets one dynamically from a server using the Dynamic Host Configuration Protocol (DHCP). DHCP is plug-and-play, and the DHCP server is often part of the LAN's router.

Subnets and CIDR notation

Look at a small network and you will see hosts clustering into groups whose addresses share a prefix: 223.1.1.xxx, 223.1.2.xxx, 223.1.3.xxx. Those groups are subnets, and the definition is physical rather than administrative: a subnet is a set of device interfaces that can physically reach one another without passing through an intervening router. Organizations usually use subnets to divide a network into logical components, such as sales, accounting, or one building.

Classless interdomain routing (CIDR) notation lets the network portion of an address be any length. The format is a.b.c.d/x, where x is the number of bits in the network portion:

200.23.16.0/23 = 11001000 00010111 00010000 00000000

Here 23 bits are the subnet part, which leaves 32 − 23 = 9 bits for hosts, so 29 = 512 addresses, minus 2 reserved. A /24 leaves 8 host bits, giving 256 addresses minus 2. The split may fall at any bit, though in practice /8, /12, /16, and /24 are the common choices.

The network part

A network gets an allocated portion of its provider's address space. The hierarchy runs downward: the Internet Assigned Numbers Authority (IANA) gives blocks to the five regional Internet registries (RIRs) — ARIN for North America, RIPE for Europe, APNIC for Asia, LACNIC for Latin America, and AFRINIC for Africa — which give blocks to Internet service providers (ISPs), which give blocks to organizations.

Follow one block down a level. An ISP holding 200.23.16.0/20 controls the low 32 − 20 = 12 bits, so it could in principle create 212 = 4,096 distinct networks from the block — though a split that fine would leave each network no room for hosts. Suppose instead the ISP hands a /23 to each client, using 3 bits to identify the client and so creating 23 = 8 subnets, each with room for 232−23 = 512 hosts: 

ISP's block       11001000 00010111 00010000 00000000    200.23.16.0/20
Organization 0    11001000 00010111 00010000 00000000    200.23.16.0/23
Organization 1    11001000 00010111 00010010 00000000    200.23.18.0/23
Organization 2    11001000 00010111 00010100 00000000    200.23.20.0/23
   ...
Organization 7    11001000 00010111 00011110 00000000    200.23.30.0/23

A client receiving a /23 can subdivide it again into smaller subnets of its own. And this hierarchy is what keeps the Internet's routing tables tractable: the ISP advertises to the rest of the world a single entry, "send me anything beginning 200.23.16.0/20," covering all eight organizations. That economy is route aggregation, and without it every organization would need an entry in every router on Earth. When an organization moves to a different provider, the new provider advertises a more specific route for just that block, and the matching rule in the next section then sends the traffic the new way automatically. The addressing hierarchy and the forwarding rule were designed for each other.

Inside a router

A generic router has four parts: input ports, a high-speed switching fabric, output ports, and a routing processor. The division that matters is by timescale.

The routing processor executes routing protocols, computes the forwarding table, and then copies that table to each of the ports. It also handles links going up and down, which can operate on a timescale of seconds. This part is the control plane, software implements it.

The input ports, switching fabric, and output ports are the data plane. Hardware implements them, and they work in a nanosecond time frame. Here is why. On a 100 Gbps link, a 64-byte IP packet arrives every 5.12 nanoseconds, which is the entire budget for processing one packet before the next one lands. With N ports a router must go N times faster still, or work on N packets in parallel. Software cannot meet that budget, which is why these functions are implemented in hardware.

An input port does three things in sequence. Line termination handles bit-level reception at the physical layer, converting an electrical signal into bits. The link layer protocol block assembles those bits into an Ethernet frame, checks the MAC address, and drops the frame if it is not addressed to this router. Then comes the critical part, lookup and forwarding, which uses header field values to look up the output port in a forwarding table held in the input port's own memory. The lookup is decentralized, since each input port holds its own copy of the table and so lookups do not contend for a central resource, and the goal is to complete input port processing at line speed. A lookup slower than the arrival rate fills the input queue and loses packets. Packets also queue here if they arrive faster than the fabric can carry them away.

Lookup comes in two flavors. Destination-based forwarding uses only the destination IP address, and is the traditional approach. Generalized forwarding uses any set of header field values, and is the SDN approach we reach at the end of these notes.

Destination-based forwarding and longest prefix matching

Suppose a packet passes its version, checksum, and TTL checks. The router now needs the output link for the packet's destination address. Why not use a hash table for a lookup in constant time, as in CS 10?

Because 32-bit addresses give 232 = 4.2 billion possible addresses, and no table can hold one entry per address. Instead the table stores ranges of addresses, one range per output port.

The simple version matches a fixed-length prefix, so a router with four output links numbered 0 through 3 needs only four entries: if the destination address falls in this range, leave by this port. That design works when the address ranges divide up neatly, but they normally do not. What happens when a subset of the addresses in one range should leave by port 3 while the rest of the range leaves by port 0? Splitting the range into pieces would work, and there is a more elegant solution.

Longest prefix matching: when looking for the forwarding table entry for a given destination address, use the longest address prefix that matches that address. Take this table, in which * matches anything: 

Destination Address Range                    Link interface
11001000 00010111 00010***  ********               0
11001000 00010111 00011000  ********               1
11001000 00010111 00011***  ********               2
otherwise                                          3

Which interface serves 11001000 00010111 00010110 10100001? Only the first entry matches, so interface 0. Easy.

Which interface serves 11001000 00010111 00011000 10101010? It matches the third entry, for interface 2, and it also matches the second entry, for interface 1. The second is longer, and the longest, most specific prefix wins, so interface 1. That rule is what makes overlapping entries useful rather than a defect: a specific exception can be layered on top of a general route without splitting up the general route.

Routers often perform longest prefix matching with ternary content addressable memory (TCAM). Content addressable means you present an address and retrieve the answer in one clock cycle regardless of table size, which is how a router meets the nanosecond budget. A Cisco Catalyst holds roughly one million routing table entries in TCAM.

Notice the general shape of what just happened. The router performed a match plus action: match the output link from the destination IP address, then act by sending the packet to that link. Hold on to that phrasing, because the last section of these notes generalizes both halves of it. Once the lookup finds the output link, the packet is ready for the switching fabric, where it may queue if the fabric is busy.

Switching fabrics

The fabric transfers a packet from an input link to the appropriate output link. Its switching rate is the rate at which it can move packets from inputs to outputs, often expressed as a multiple of the line rate. With N input ports, a switching rate of N times the line rate is desirable, so that the fabric itself never becomes the bottleneck.

Output queueing and buffer management

Buffering is required when datagrams arrive from the fabric faster than the outbound link can transmit them. Consider what happens if N packets arrive on N input ports all destined for the same output port: when the inbound and outbound line rates are equal, N−1 packets must buffer, and that happens at every time step. Because buffers are finite, datagrams can be lost to congestion. This buffering is the router-internal version of the congestion story from Day 6, and two policy questions live here: which datagrams to drop when no free buffers remain, and which buffered packet to send next.

How much buffering?

The RFC 3439 rule of thumb is average buffering equal to a typical round-trip time (RTT), say 250 ms, times the link capacity C. For a 10 Gbps link that gives a 2.5 Gbit buffer. A more recent recommendation accounts for the number of flows N:

buffer = (RTT × C) / √N

You might assume that more buffering is always better. It is not. Too much buffering increases delay, a particular problem in home routers, and long RTTs mean poor performance for real-time applications and sluggish TCP response, since TCP infers congestion from delay and loss. Recall the goal of delay-based congestion control: keep the bottleneck link just full enough to stay busy, but no fuller. Buffering is like salt, in that the right amount improves things and too much ruins them.

Buffer management

Two decisions. Drop: which packet to add or drop when the buffers are full. Tail drop discards the arriving packet, or a router can drop and remove packets on a priority basis. Marking: which packets to mark to signal congestion, as explicit congestion notification does. Note what marking buys: a router can tell a sender about congestion without destroying a packet to do it.

Packet scheduling

Packet scheduling is deciding which packet to send next on the link. Four policies:

First in, first out (FIFO), also called first come, first served: the output port transmits packets in the order they arrived. Simple, and exactly the queue abstraction from CS 10.

Priority: the router classifies arriving traffic and queues it by class, and any header field can serve as the basis for classification, the IP ToS field for example. The scheduler sends from the highest-priority queue that holds buffered packets, and serves FIFO within a class. A low-priority packet waits until the high-priority queue is empty.

Round robin: the router classifies traffic into queues, and the server cyclically and repeatedly scans the class queues, sending one complete packet from each class in turn when one is available.

Weighted fair queueing (WFQ): generalized round robin. Each class i has a weight wi and receives a share of the service in each cycle equal to wi / Σjwj. The result is a minimum bandwidth guarantee per traffic class.

Scheduling is where technical mechanism meets public policy. A router that classifies traffic by header field and serves some classes before others is deciding who gets good performance, and the available header fields include the source and destination addresses, which is to say who sent the traffic and who will receive it. That capability is the technical substance of the network neutrality debate. The question is not whether prioritization is possible, since it is possible and is a standard feature, but whether and when a network operator should be permitted to use it. The mechanism exists in every output port on the Internet.

Generalized forwarding

Every router contains a forwarding table, and the abstraction has been match plus action all along. Destination-based forwarding is one instance: match the destination IP address, act by forwarding out a link. Generalized forwarding loosens both halves. Many header fields can determine the action, and many actions are possible: drop, copy, modify, or log a packet.

The general structure is a flow table, where a flow is defined by header field values drawn from the link, network, and transport layers. Each entry holds a match pattern over any packet header fields; one or more actions for a matched packet, namely drop, forward, modify, or send the packet to the controller; a priority to disambiguate overlapping patterns; and counters for bytes and packets. For example, with * as a wildcard: 

src = *.*.*.*,   dest = 3.4.*.*      forward(2)
src = 1.2.*.*,   dest = *.*.*.*      drop
src = 10.1.2.3,  dest = *.*.*.*      send to controller

OpenFlow is a popular implementation of generalized routing. Its match fields span three layers: ingress port; Layer 2 header fields, Layer 3 header fields, and Layer 4 header fields. Its actions are to forward the packet to one or more ports, drop it, modify fields in its headers, or encapsulate it and forward it to the controller. It also keeps packet and byte counters. Three short examples give the flavor: match destination IP 51.6.0.8 and forward to output port 6, which is ordinary destination-based forwarding; match destination TCP port 22 and drop, which is a firewall blocking Secure Shell (SSH); and match source IP 128.119.1.1 and drop, which blocks one host.

Here is the payoff, and it is a satisfying unification. Match plus action describes devices we have been treating as different kinds of thing:

Four devices, one abstraction. And because a controller installs flow tables, tables at several switches can be orchestrated to produce network-wide behavior. The example from class: datagrams from hosts h5 and h6 on 10.3.0.0 should reach h3 or h4 on 10.2.0.0 by way of switch s1 and then s2, which three coordinated table entries accomplish — s3 matches the source and destination prefixes and forwards toward s1, s1 matches the ingress port along with those prefixes and forwards toward s2, and s2 matches the ingress port and the specific destination address and forwards to the right host port. That orchestration is a simple form of network programmability: programmable, per-packet processing.

Supplemental: two packets, byte by byte

We have now covered every layer that a normal packet contains, so it is worth looking at two complete packets and accounting for every byte. Both packets are in the capture files linked above. Nothing here is new material; the value is in seeing that a packet really is just the bytes, and that Wireshark's readable tree is a decoding of them and nothing more.

A DNS request: all 76 bytes

Open dns.pcapng, filter on DNS, and look at the query in packet 3. The entire transmission is 76 bytes, displayed as rows of 16 bytes. Those 76 bytes are the whole transmission.

Reading from the inside out, as the sender builds it:

Layer 7, the DNS query, 34 bytes. A 2-byte transaction identifier, 0x9994, which lets the client match a reply to its request. Two bytes of flags, 0x0100, in which the leading 0 means a query rather than a reply and the set bit means recursion desired. Then four 2-byte counts: questions, answers, additional records, and authority records. Questions is 1, and the other three are zero in a query, to be filled in by the reply. Then the question itself, vibrantcloud.org with type A, written as length-prefixed labels in the American Standard Code for Information Interchange (ASCII): v is 0x76, i is 0x69, b is 0x62, r is 0x72, and so forth. The question ends with a 2-byte type, 0x0001 for an A record where 0x000F would be MX, and a 2-byte class, 0x0001 for IN, meaning Internet.

Layer 4, the UDP header, 8 bytes. Source port 51658, which is 0xC9CA, chosen by the operating system. Destination port 53, which is 0x0035 and is where DNS listens. Length 42, 0x002A, being the 8-byte header plus the 34-byte message. Checksum 0xC010. Note how the receiver knew that Layer 7 held a DNS query: when it decoded Layer 4 it saw destination port 53 and demultiplexed the datagram to the socket where DNS listens.

Layer 3, the IP header, 20 bytes. Every field from the section above, with a total length of 62 bytes, a TTL of 64, a protocol of 17 for UDP, and the source and destination addresses 192.168.159.129 and 192.168.159.2.

Layer 2, the MAC header, 14 bytes. Destination MAC address 00:50:56:F5:9E:21, which is the router, source MAC address 00:0C:29:A8:D0:96, which is the VM, and a 2-byte type field of 0x0800 meaning that the payload is IPv4, where IPv6 would be 0x86DD. That type field is how the receiving link layer knows which Layer 3 protocol should receive the payload, the same trick that the IP protocol field performs at the layer above.

The total: 14 + 20 + 8 + 34 = 76 bytes. Every layer we have studied, in one small packet, and the nesting is literal.

The reply is in packet 7. Its DNS answer section gives www.vibrantcloud.org as 173.201.179.249, which is 0xAD.C9.B3.F9 in hexadecimal.

An HTTP request over TCP

Now that the host knows the web server's IP address, it can make a web request using the HyperText Transfer Protocol (HTTP). Open vibrantcloud2.pcapng, filter on tcp or http, and look at packet 4.

The exchange opens with the three-way handshake from last class, visible in the three segments before this one: the client picks a random sequence number and sends it in the SYN; the server picks its own random sequence number and sends it in the SYN ACK, with an acknowledgement of one more than the client's; and the client increments its sequence number and acknowledges one more than the server's.

Layer 7, the HTTP request, 70 bytes of TCP payload: 

GET /index.html HTTP/1.1\r\n
Host: 173.201.179.249\r\n
Connection: close\r\n\r\n

In the raw bytes, G is 0x47, E is 0x45, T is 0x54, and the line endings are 0x0D for carriage return and 0x0A for newline.

Layer 4, the TCP header, 20 bytes. Source port 33700, which is 0x83A4, and destination port 80, which is 0x0050. Sequence number 2433442851 (0x910B6423) and acknowledgement number 1977043062 (0x75D74876). An offset of 5, which times 4 gives the 20-byte header. Two flags set, ACK and PSH, the latter asking the receiver to deliver the bytes to Layer 7 now. A receive window of 64240, 0xFAF0, which is how many bytes the sender of this segment can accept. The urgent pointer, which nothing uses these days. And no options here, though two are common: the maximum segment size, often 1460, and selective acknowledgement (SACK), which lets a receiver say "I am missing bytes 1000 through 1999 but I have 2000 through 2999" so that the sender resends only the gap.

The TCP checksum deserves a note of its own, because it breaks the layer separation we have otherwise described. It covers the header and the payload, and it also covers a pseudo header built from Layer 3 fields: the source and destination IP addresses, the protocol number, and the TCP segment length. A Layer 4 checksum that reaches down into Layer 3 is a deliberate violation, and the reason for it is to catch a segment delivered to the wrong host.

Layer 3, the IP header, 20 bytes. Version 4, header length 5 meaning 20 bytes, ToS 0 for best effort, and a total length of 110 (0x6E), which checks out as 20 bytes of IP header plus 20 bytes of TCP header plus the 70-byte Layer 7 message. No fragmentation, a TTL of 64, protocol 6 for TCP, source 192.168.159.129, destination 173.201.179.249 (0xAD.C9.B3.F9), and no options.

Layer 2, the MAC header, 14 bytes. The same destination and source MAC addresses as before, and type 0x0800 so that the network stack knows the next layer is IPv4.

So the request on the wire is 14 + 110 = 124 bytes, carrying a 70-byte message. Compare the DNS query: 76 bytes carrying 34. Headers are a real fraction of small packets, which is worth remembering the next time someone proposes adding a field to one.

Exercises

Complete these before or around the next class.

  1. Parse the IP header yourself. Begin with parse_ip_starter.py, which opens a raw socket and hands you the bytes of each packet that arrives. Fill in parse_ipv4_packet so that it extracts and prints the IP version (4 or 6), the header length in bytes (probably 20), the upper-layer protocol (ICMP is 1, TCP is 6, UDP is 17), the time to live, and the source and destination IP addresses.

    A few notes on the starter code, since the socket differs from the ones we have used so far. AF_PACKET sniffs directly at the device driver level, which is a Linux feature. SOCK_DGRAM strips the Layer 2 header but keeps Layer 3 and above, so the bytes you receive begin at the IP header. socket.htons(3) captures all protocols in both directions. Because the program sniffs, you must run it with sudo.

    Start the program, then in another terminal run ping 8.8.8.8 and watch what your parser prints. Confirm your output against a simultaneous Wireshark capture. Then answer one question in writing: your program never looked at the total length field, so how did recvfrom know where each packet ended?

  2. Open dns.pcapng and account for all 76 bytes of the query yourself, without consulting the walkthrough above: how many bytes belong to each of Layers 2, 3, 4, and 7, and what fraction of the packet is header rather than message?
  3. Compare vibrantcloud.pcapng and vibrantcloud2.pcapng. In each, check that the IP total length field equals the IP header plus the TCP header plus the Layer 7 message.
  4. Run ip route on your VM and read the output as a forwarding table. For a packet destined to 10.10.0.5, which entry matches? For one destined to 8.8.8.8? Which entry is the longest prefix match in each case?
  5. Build a small longest-prefix-matching table by hand: three entries plus a default, and two destination addresses whose correct interfaces differ only because of the longest-prefix rule.

Terms

Not a comprehensive reference — the textbook has much more — but these are the terms from Day 7 that recur throughout the course.

forwarding versus routing
Forwarding moves a packet from a router's input link to the appropriate output link, and is local and per-packet. Routing determines the end-to-end route packets take, and is network-wide.
data plane
The local, per-router function determining how a packet arriving on an input port is forwarded to an output port. Hardware implements it, on a nanosecond timescale.
control plane
The network-wide logic determining the route a packet takes among routers, whose product is the forwarding table. Software implements it, on a millisecond timescale.
SDN (software-defined networking)
A control plane in which a remote controller computes routes and installs forwarding tables in routers, each of which runs a control agent. The data plane is unchanged.
ICMP (Internet Control Message Protocol)
The Layer 3 companion to IP, used for error reporting and router signaling. It is Layer 3 because it deals in IP addresses, carries no ports, and carries no higher-level message.
best-effort service
The Internet's network-layer service model: no guarantee of delivery, timing, ordering, or bandwidth. Compare ATM's Constant Bit Rate and Available Bit Rate services, and the Intserv and Diffserv proposals.
interface
The connection between a host or router and a physical link. IP addresses belong to interfaces, not to hosts, which is why one machine can have several.
nibble
Half a byte. The IP version and header length fields are one nibble each, sharing the first byte of the header.
IHL (Internet header length)
The IP header length in 32-bit words; multiply by 4 for bytes. A value of 5 means the usual 20-byte header, and the field exists because options make the header variable.
total length
The IP header plus its payload, where the payload is the Layer 4 header plus the application message.
TTL (time to live)
Hops remaining, commonly starting at 64. Each router decrements it, and a router decrementing it to zero discards the packet and reports the fact, which is the mechanism traceroute exploits.
protocol field
The IP header field naming the Layer 4 protocol inside: UDP is 17, TCP is 6, ICMP is 1. The Ethernet type field does the same job one layer down, with 0x0800 for IPv4 and 0x86DD for IPv6.
header checksum
The IP checksum, covering the header only, unlike the Layer 4 checksum. Every router must recompute it because the TTL changes at each hop. IPv6 drops it.
DHCP (Dynamic Host Configuration Protocol)
How a host obtains the host part of its address dynamically, rather than from a hard-coded configuration file. Often served by the LAN's router.
subnet
A set of device interfaces that can reach one another physically without passing through an intervening router.
CIDR (classless interdomain routing)
Address notation a.b.c.d/x in which x gives the number of bits in the network portion, so the network-host split can fall at any bit. A /23 leaves 9 host bits, or 512 addresses minus 2 reserved.
IANA and the RIRs
The Internet Assigned Numbers Authority allocates address blocks to five regional Internet registries — ARIN, RIPE, APNIC, LACNIC, and AFRINIC — which allocate to ISPs, which allocate to organizations.
route aggregation
Advertising one prefix that covers many customer networks, which is what keeps global routing tables tractable. A customer that changes providers is handled by the new provider advertising a more specific prefix.
line speed
The rate at which an input port must finish processing a packet to keep up with arrivals. On a 100 Gbps link a 64-byte packet arrives every 5.12 nanoseconds.
longest prefix matching
Choosing the forwarding table entry whose address prefix matches the destination and is longest, which lets specific exceptions overlay general routes.
TCAM (ternary content addressable memory)
Memory that returns the matching entry in one clock cycle regardless of table size, which is how routers perform longest prefix matching fast enough. Around one million entries on a Cisco Catalyst.
match plus action
The forwarding abstraction: match bits in an arriving packet's headers, then take an action. Destination-based forwarding is the narrow case; generalized forwarding is the broad one.
switching fabric
The hardware moving a packet from an input port to an output port.
switching rate
The rate at which the fabric moves packets from inputs to outputs, ideally N times the line rate for N ports so that the fabric is not the bottleneck.
output port queueing
Buffering that occurs when datagrams arrive from the fabric faster than the outbound link transmits them. With N inputs aimed at one output at equal line rates, N−1 packets buffer per time step, and finite buffers mean loss.
tail drop
Dropping the arriving packet when the buffer is full. The alternative is to drop or remove packets by priority.
marking
Signaling congestion by setting a bit in a packet rather than by dropping it, as explicit congestion notification does.
packet scheduling
Choosing which buffered packet to send next: FIFO, priority, round robin, or weighted fair queueing. WFQ gives class i a share wi/Σjwj of each cycle, which is a minimum bandwidth guarantee per class.
network neutrality
The policy debate over whether and when an operator may prioritize traffic by class. The mechanism, priority scheduling on header fields including addresses, is standard in every output port.
flow table
A generalized forwarding table whose entries hold a match pattern over any header fields, actions (drop, forward, modify, or send to the controller), a priority to disambiguate overlapping patterns, and byte and packet counters.
OpenFlow
The standard generalized-forwarding specification, matching on fields from the link, network, and transport layers. Its match-plus-action abstraction describes a router, a switch, a firewall, and a NAT as one kind of device.

Credit: Most information on this page is from Computer Networking: A Top-Down Approach, 9th edition by Kurose and Ross.
This page was generated by Claude from in-class slides.