the network graph model

To compute paths, a router first needs a way to think about the network mathematically. The standard trick is to draw it as a graph: a set of dots (called nodes or vertices) connected by lines (called edges or links). Each router is a node; each direct connection between two routers is an edge. It is the same picture as a subway map, where stations are dots and tracks are lines.

Each edge gets a number called its cost or weight, written c(x, y) for the cost of the link between x and y. The cost might represent the physical link's delay, the inverse of its bandwidth (so faster links look cheaper), a dollar figure, or just a number an operator picked by hand. A path is a sequence of nodes joined by edges, and the cost of a path is the sum of its edge costs. Two nodes are neighbors if there is a single edge directly between them. This abstraction is deliberately simple: it throws away almost everything about the real hardware and keeps only who-connects-to-whom and how-expensive.

Why bother? Because once the network is a weighted graph, finding good routes becomes a classic, well-understood math problem: the shortest-path (least-cost) problem, for which fast algorithms like Dijkstra's and Bellman-Ford already exist. Decades of graph theory become instantly usable. The whole of intra-domain routing is, at heart, repeatedly solving shortest paths on this graph.

An honest caveat: the model is a snapshot, and the real network is not. Links go up and down, costs change, and different routers can briefly hold different ideas of what the graph looks like. Routing protocols spend much of their effort just keeping every router's copy of the graph fresh and consistent.