Networking Paradigms

A communication link may be:

• a point-to-point link, connecting exactly two endpoints;
• a shared broadcast medium, on which multiple nodes use the same communication channel.

Examples of point-to-point links include:

• a direct link between a host and an Ethernet switch;
• older dial-up links using the Point-to-Point Protocol (PPP).

Examples of shared media include:

• an Ethernet network built with a hub;
• cable Internet, where multiple customers may share part of the Hybrid Fiber-Coaxial (HFC) infrastructure;
• Wi-Fi and other radio networks;
• satellite networks;
• older shared-bus Ethernet.

An Ethernet switch creates a separate collision domain on each port, but normally does not divide the broadcast domain. A hub divides neither the collision domain nor the broadcast domain.

On a shared medium, two or more simultaneous transmissions may interfere. This is called a collision. The corresponding frames may become corrupted and therefore unusable.

A multiple-access protocol determines how the participating nodes share the common channel.

Suppose that the shared channel has rate \(R\) bits per second.

An ideal protocol should provide the following:

• If only one node transmits, it should be able to use the full rate \(R\).
• If \(M\) nodes continuously wish to transmit, each should obtain an average rate close to \(R/M\).
• The mechanism should be decentralized.
• It should not depend on a permanently distinguished coordinator.
• It should preferably not require precisely synchronized clocks.
• Coordination should use the shared channel itself rather than a separate out-of-band channel.
• The mechanism should be simple and inexpensive to implement.

Precise clock synchronization becomes increasingly difficult as link speeds increase because slot boundaries may have to be aligned with nanosecond accuracy.

The main approaches are:

1. Channel partitioning
   • Divide the channel into fixed pieces.
   • Assign a piece to each participant.
2. Random access
   • A node transmits when it has data.
   • Collisions are possible and must be detected or recovered from.
3. Taking turns
   • Nodes dynamically obtain permission to transmit.
   • The channel is not permanently partitioned, but access is controlled.

In Time Division Multiple Access (TDMA):

• time is divided into repeating rounds;
• each round is divided into time slots;
• each node is assigned one slot;
• a node may transmit only during its own slot.

Advantages:

• transmissions assigned to different slots do not collide;
• bandwidth allocation is predictable;
• the mechanism is conceptually simple.

Disadvantages:

• participating nodes must agree on slot boundaries;
• unused slots remain idle;
• an active node cannot use the slots assigned to inactive nodes.

For example, if a round has six slots but only nodes 1, 3, and 4 currently have data, the other three slots are wasted.

In Frequency Division Multiple Access (FDMA):

• the available frequency spectrum is divided into frequency bands;
• each node is assigned a band;
• several nodes can transmit at the same time using different frequencies.

The same idea can be applied to optical fiber. Different wavelengths, or “colors” of light, can carry independent channels. This is generally called Wavelength Division Multiplexing (WDM).

As with TDMA, bandwidth assigned to an inactive node may remain unused.

In Code Division Multiple Access (CDMA):

• each sender is assigned a distinct code;
• the sender encodes its signal using that code;
• a receiver extracts a desired transmission using the corresponding code.

Multiple encoded signals can overlap in both time and frequency. Carefully selected codes allow the receiver to distinguish them.

The signal-processing and mathematical details were outside the scope of the course.

ALOHA originated in the ALOHANET system in Hawaii.

Slotted ALOHA makes the following assumptions:

• all frames have the same transmission time;
• time is divided into equal-size slots;
• a frame may begin only at the start of a slot;
• nodes are synchronized to the slot boundaries;
• all nodes can determine whether a slot contained a collision.

Operation:

1. When a node obtains a new frame, it transmits in the next slot.
2. If exactly one node transmits, the frame is delivered successfully.
3. If several nodes transmit in the same slot, a collision occurs.
4. After a collision, each node independently retransmits in a later slot with probability \(p\).
5. Randomization prevents all colliding nodes from always retransmitting together.

Advantages:

• if only one node is active, it can use every slot;
• there is no permanent central controller;
• its operation is relatively simple.

Disadvantages:

• slot synchronization is required;
• slots containing collisions are wasted;
• slots may also be idle because all waiting nodes randomly decide not to transmit;
• a node may wait for many slots before succeeding.

With \(N\) continuously active nodes, the probability that a particular slot contains exactly one transmission is

\[ N p(1-p)^{N-1}. \]

At the optimal value of \(p\), the maximum efficiency approaches

\[ \frac{1}{e} \approx 0.37. \]

Thus, under heavy contention, only about 37 percent of the slots carry successful transmissions.

Pure, or unslotted, ALOHA removes slot synchronization.

A node transmits immediately when it receives a frame.

This is easier to implement, but a frame can collide with:

• a frame that began shortly before it;
• a frame that begins before the first frame has finished.

The vulnerable interval is therefore approximately two frame-transmission times, rather than one slot.

Its maximum efficiency is

\[ \frac{1}{2e} \approx 0.18. \]

Thus, removing synchronization approximately halves the maximum efficiency.

Carrier Sense Multiple Access (CSMA) improves on ALOHA by listening before transmitting.

Basic rule:

• If the channel is idle, transmit.
• If the channel is busy, defer transmission.

This is analogous to listening before speaking.

However, carrier sensing cannot eliminate every collision because signals take time to propagate through the medium.

Suppose node A begins transmitting. Before A’s first bit has reached distant node B, B may still sense an idle channel and begin transmitting. Their signals then collide.

The importance of this problem depends on the relationship between:

• propagation delay;
• frame-transmission time;
• physical size of the network.

CSMA with Collision Detection (CSMA/CD) allows a transmitter to monitor the medium while it is transmitting.

The basic Ethernet-style procedure is:

1. The NIC receives a network-layer packet and constructs an Ethernet frame.
2. It senses the channel.
3. If the channel is busy, it waits.
4. When the channel becomes idle, it begins transmission.
5. While transmitting, it monitors the medium.
6. If the complete frame is transmitted without a collision, transmission succeeds.
7. If a collision is detected, the NIC aborts transmission.
8. It sends a short jam signal so that the other stations also recognize the collision.
9. It enters binary exponential backoff.
10. After waiting, it senses the channel and tries again.

After the \(m\)-th collision, a node chooses a random backoff value from an increasing range, conceptually similar to

\[ K \in \{0,\ldots,2^m-1\}. \]

The growing range reduces the probability that the same nodes collide again when contention is high.

Collision detection is practical on wired Ethernet because a transmitter can compare the signal placed onto the cable with the signal observed on the cable.

It is much harder in wireless networks because the transmitter’s own radio signal is normally far stronger than a signal arriving from another station. Wireless systems therefore generally require different mechanisms, such as collision avoidance.

The efficiency of CSMA/CD improves when propagation delay is small relative to frame-transmission time. Unlike ALOHA, it does not waste the entire frame time after detecting a collision.

In polling:

• one node acts as a master;
• the master asks each other node whether it wishes to transmit;
• only a node that has been polled may transmit.

Advantages:

• collisions can be prevented;
• the master can implement priorities or controlled allocation.

Disadvantages:

• polling messages add overhead;
• a node must wait to be polled, increasing latency;
• the master is a single point of failure;
• failure of the master can stop communication.

In token passing:

• a special control message called a token circulates among the nodes;
• only the node holding the token may transmit;
• after transmitting, or if it has nothing to send, the node passes the token onward.

Advantages:

• no permanent master is required;
• collisions can be avoided;
• access can be fair.

Disadvantages:

• token transmission and processing add overhead;
• an otherwise idle node must wait for the token;
• loss of the token requires a recovery procedure;
• a failed node or broken logical ring can disrupt operation.

The network does not necessarily need to be a physical ring, but it must maintain some logical order for passing the token.

Signaling is the exchange of control messages among network entities in order to establish, maintain, modify, measure, or terminate a service, connection, call, or session.

Signaling may occur:

• before communication, for setup;
• during communication, for maintenance or modification;
• after communication, for teardown;
• for measurement, accounting, or billing.

It may take place between:

• one end system and another end system;
• an end system and the network;
• one network element and another network element.

Examples include:

• the TCP handshake and connection teardown;
• RSVP resource-reservation messages;
• SIP messages used to establish Internet calls;
• SS7 signaling in the telephone network.

The IP layer was designed around:

• connectionless forwarding;
• stateless packet handling by routers;
• best-effort delivery;
• no per-connection signaling at the network layer.

An IP packet can normally be forwarded without the endpoint first asking each router to establish a connection.

Nevertheless, other layers require signaling and state.

For example, TCP must establish shared connection state such as:

• initial sequence numbers;
• port numbers;
• receive-window information;
• negotiated options;
• retransmission and RTT-related variables.

Application-layer services may also need signaling.

The Session Initiation Protocol (SIP) is used to establish and manage Internet multimedia sessions such as voice or video calls.

Its functions include:

• locating the current device or IP address of the callee;
• mapping a stable human-oriented identifier to a current network location;
• notifying the callee of an incoming session;
• negotiating media types and encodings;
• adding or removing media streams;
• changing encoding during a call;
• inviting additional participants;
• transferring or placing calls on hold;
• terminating the session.

This demonstrates that even though IP itself is connectionless, applications often need explicit control protocols.

The Resource Reservation Protocol (RSVP) is another signaling protocol.

It allows endpoints to communicate resource requirements to the network, especially for multimedia and multicast applications.

RSVP can request that resources be reserved along an end-to-end path, but it does not itself define the router mechanisms that implement the reservation.

With in-band signaling, control and data share the same communication channel.

HTTP is an example.

A simplified HTTP exchange is:

1. The client establishes a TCP connection to the server.
2. The client sends an HTTP request over that connection.
3. The request line and headers tell the server what operation is requested.
4. The server sends an HTTP response over the same connection.
5. The response contains both control information and, usually, an object body.
6. The connection may be closed or reused.

An HTTP request contains elements such as:

• a request line, for example GET /page.html HTTP/1.1;
• header fields;
• a blank line;
• an optional message body.

An HTTP response contains:

• a status line, such as HTTP/1.1 200 OK;
• response headers;
• a blank line;
• an optional response body.

The blank line separates the headers from the optional body.

Thus, HTTP mixes signaling information and application data in the same logical exchange and normally in the same transport connection.

With out-of-band signaling, control and data use separate channels.

FTP is a classic example.

FTP normally uses:

• a persistent TCP control connection, traditionally to server port 21;
• a separate TCP data connection for file contents.

The control connection carries operations such as:

• authentication;
• directory navigation;
• file-selection commands;
• requests to upload or download files.

The FTP server maintains session state associated with the control connection, such as:

• the authenticated user;
• the current remote directory;
• earlier commands.

In traditional active FTP:

1. The client opens the control connection.
2. The client requests a transfer.
3. The server opens a separate data connection back to the client.
4. The file is transferred.
5. The data connection is closed.
6. The control connection can remain open for later commands.

This design causes problems when the client is behind a firewall or NAT, because an external server may not be allowed to initiate a new connection to the client.

Passive FTP addresses this problem:

1. The server selects and announces a listening port over the control connection.
2. The client opens the data connection to that server port.
3. The server no longer needs to initiate an inbound connection to the client.

Separate channels can:

• allow control messages and large data transfers to proceed concurrently;
• prevent data transfer from delaying urgent control information;
• allow authentication to be performed on the control channel;
• simplify independent processing of control and data;
• apply different QoS or transport properties to each stream;
• preserve a long-lived control session while creating temporary data connections.

Separate channels can:

• require more connections and more endpoint state;
• complicate connection management;
• create NAT and firewall difficulties;
• require additional handshakes;
• increase latency;
• consume additional resources.

The best design therefore depends on the application’s workload.

For many small web objects, establishing a separate control connection and a separate data connection would create unnecessary latency.

The separation need not be absolute.

A multimedia application might, for example:

• send essential information over a reliable stream;
• send optional enhancement information over an unreliable datagram flow.

QUIC allows several logical streams within one connection. This moves part of the separation above the traditional transport-connection level: different streams can carry different classes of information while sharing a single QUIC connection.

State is information stored by a protocol in one or more network nodes.

State must normally be updated when relevant conditions change.

Examples include:

• TCP sequence numbers;
• TCP send and receive buffers;
• TCP timer values and RTT estimates;
• RSVP lists of upstream senders;
• RSVP downstream receiver reservations;
• routing-table information.

In the terminology used in the lecture:

• a sender generates signaling messages that install, refresh, modify, or remove state at another node;
• a receiver creates, maintains, or removes the corresponding state after receiving those messages.

This sender/receiver terminology concerns signaling and does not necessarily mean the sender and receiver of the eventual application data.

With hard state:

• the sender explicitly sends a setup message;
• the receiver explicitly installs the state;
• reliable signaling or an acknowledgement confirms installation;
• the state remains valid unless explicitly removed;
• the sender explicitly sends a teardown message;
• additional mechanisms are needed to remove orphaned state after failures.

The default assumption is:

The state remains valid until the receiver is told otherwise.

A typical hard-state procedure is:

1. The sender transmits an installation request.
2. The receiver installs the state.
3. The receiver acknowledges the installation.
4. Both sides use the established state.
5. The sender later sends an explicit removal request.
6. The receiver removes the state.

Timeout and error handling are still needed in practice.

For example:

• the setup request may be lost;
• the acknowledgement may be lost;
• the sender may crash after state has been installed;
• the teardown message may never arrive;
• the two endpoints may hold inconsistent state.

Hard-state protocol design is therefore strongly affected by failure cases.

TCP is conceptually a hard-state protocol.

Before normal data transfer, the endpoints establish state through the three-way handshake.

The state includes:

• initial sequence numbers;
• send and receive buffers;
• receive-window information;
• the Maximum Segment Size (MSS);
• negotiated TCP options;
• retransmission variables;
• connection-state-machine state.

Normal connection termination uses FIN and ACK messages.

Because TCP is full duplex, one direction may be closed while the other direction remains usable. This produces the TCP half-close and normally requires FIN processing in both directions.

A connection may instead be aborted using a Reset (RST).

For example, if a host receives a TCP segment for which it has no corresponding connection state, it may send an RST. The reset tells the peer to discard its stale or invalid state.

Differences in how systems respond to unexpected TCP segments can also be used by network-scanning tools such as Nmap to infer whether a port is open or closed.

Hard state does not imply that implementations retain state forever.

TCP implementations still need timers and resource limits because:

• endpoints may crash silently;
• a machine may disappear without sending FIN or RST;
• packets may be lost indefinitely;
• keeping abandoned state forever would exhaust memory and connection tables.

Hard state and soft state should therefore be understood as architectural extremes rather than perfectly pure categories.

With soft state:

• a trigger message initially installs the state;
• the sender periodically transmits refresh messages;
• the receiver keeps the state only while refreshes continue to arrive;
• the receiver removes the state after a timeout;
• explicit teardown may be supported, but is not essential.

The default assumption is:

The state becomes invalid unless it is refreshed.

The initial trigger and later refreshes may use essentially the same message format.

A typical sequence is:

1. The sender transmits a best-effort trigger message.
2. The receiver installs the state.
3. The sender periodically retransmits the state.
4. Each received refresh restarts the receiver’s timeout timer.
5. A refresh may also contain updated state.
6. If refreshes stop, the timer eventually expires.
7. The receiver removes the state automatically.

Basic soft-state protocols do not necessarily acknowledge every refresh.

Repeated refreshes provide a form of eventual or implicit reliability: losing one refresh is usually harmless if a later refresh arrives before timeout.

The same message may serve several roles:

• Trigger: install state for the first time.
• Refresh: confirm that existing state remains valid.
• Update: replace old state with new values.
• Implicit removal: the absence of future refreshes means that the sender is gone.

This reduces the number of different error-specific message types.

Some enhanced soft-state protocols reliably acknowledge initial trigger messages so that initial installation happens quickly, while continuing to use best-effort periodic refreshes afterwards.

Soft state can adapt naturally to changing network conditions.

Suppose that:

• a routing path changes;
• a router or link fails;
• later refresh messages follow a new path.

The refreshes can install the state along the new route. Old state along the previous route eventually expires.

The end systems do not necessarily need:

• a special notification describing the exact failure;
• a separate recovery procedure for each possible topology change.

Normal refresh processing performs the recovery.

Let:

• \(T_r\) be the refresh interval;
• \(T_o\) be the state timeout.

Normally,

\[ T_o = nT_r \]

for some \(n>1\), so that the loss of one refresh does not immediately remove the state.

Timer selection creates a trade-off.

Short intervals provide:

• faster detection of failure;
• faster adaptation to changes;
• more signaling traffic;
• greater processing overhead.

Long intervals provide:

• less signaling traffic;
• lower processing overhead;
• slower removal of stale state;
• slower reaction to changes.

Suitable values depend on:

• expected delay;
• loss probability;
• network size;
• the cost of stale state;
• the desired convergence time.

Soft state is often considered:

• robust against lost control messages;
• easy to recover after topology changes;
• easier to decompose and analyze;
• less dependent on perfectly synchronized endpoint state;
• capable of shorter convergence because acknowledgements are not required for every update.

However, it creates continuous signaling overhead because state must be refreshed even when nothing has changed.

In IP multicast:

• a sender addresses a datagram to a multicast-group address;
• hosts may join that group;
• routers replicate and forward packets toward networks containing group members;
• the sender sends one logical packet rather than one separate packet per receiver.

IPv4 traditionally reserves the address block 224.0.0.0/4, formerly called Class D, for multicast.

The service model permits:

• any host to join a group;
• any host to send to a group;
• group membership to change dynamically;
• senders to transmit without necessarily joining the group themselves.

The sender is not given a network-layer list of all group members.

The network must provide the infrastructure that delivers the multicast datagrams to the joined receivers.

Joining has two conceptually separate parts.

1. Local membership signaling
   • A host informs its local multicast router that it wants to receive a group.
   • IPv4 uses IGMP.
2. Wide-area multicast routing
   • Routers communicate to construct or modify the multicast distribution tree.
   • Possible protocols include DVMRP, MOSPF, and PIM.

IGMP itself manages local host-to-router membership. It does not by itself construct the entire wide-area multicast tree.

When an application joins a multicast group, the host sends an IGMP membership report.

On many systems this is requested through a socket option such as IP_ADD_MEMBERSHIP.

Routers periodically transmit membership queries. Hosts that still belong to a multicast group respond with reports.

This is a soft-state mechanism:

• reports establish or refresh group-membership state;
• if no host reports membership, the router eventually removes the state.

IGMPv1 uses:

• general membership queries sent by the router;
• membership reports sent by hosts;
• randomized response delays;
• A host that leaves simply stops responding to future Queries.
• If no host on the LAN reports membership before the timer expires, the router removes the group’s membership state.

Randomization prevents all hosts from responding simultaneously, which would create a burst of traffic and potentially collisions on a shared medium.

IGMPv2 added features including:

• Last host replying to Query can send explicit Leave Group msg
• Router performs group-specific query to see if any hosts left in group
• faster checking when the last reporting host appears to leave.

After receiving a leave message, a router can issue a group-specific query to determine whether another host on the LAN still belongs to the group.

Thus IGMPv2 combines soft-state refresh with optional explicit removal.

IGMPv3 adds source filtering.

A receiver can express that it wants:

• traffic from specified sources;
• or traffic from all sources except specified sources.

This supports source-specific multicast behavior.

IPv6 uses Multicast Listener Discovery (MLD), implemented as part of ICMPv6, instead of IPv4 IGMP.

IPv6 relies more heavily on multicast. For example, Neighbor Discovery uses multicast rather than the link-wide ARP broadcast used in IPv4.

RSVP was designed primarily for multicast communication, where different receivers may experience very different network conditions. One receiver may be connected through a high-bandwidth path, while another may have a much slower access link. Therefore, RSVP allows each receiver to request a level of service appropriate for its own path, rather than forcing every receiver to use one identical reservation.

The protocol must also support different kinds of applications. An audio call, a video stream, and a data-transfer application may require different amounts of bandwidth and may tolerate delay or packet loss differently. RSVP therefore provides a general signaling mechanism through which applications can describe their resource requirements.

Multicast membership is dynamic because receivers may join or leave at any time. RSVP must therefore update reservations when the receiver set changes. A newly joined receiver can create a reservation for its path, while the state associated with a receiver that has left eventually disappears.

RSVP does not calculate routes itself. Instead, it uses the paths selected by the existing unicast or multicast routing protocols. If routing later changes because a router or link fails, subsequent RSVP refresh messages follow the new route and establish reservation state there.

The protocol must remain scalable when a multicast session has many receivers. Its control overhead should therefore not grow quadratically with the number of participants. Where possible, routers merge compatible reservation requests so that shared parts of the multicast tree do not require one completely separate reservation for every receiver.

Finally, RSVP was designed to operate over heterogeneous link technologies. It communicates the requested service in a technology-independent way, while each router or link-layer mechanism decides locally how that request should be implemented.

RSVP does not:

• define the exact mechanism by which a router reserves bandwidth;
• select the network route;
• replace the routing protocol;
• directly forward application packets.

Instead, RSVP communicates requirements.

Routing determines the path. Router-local mechanisms such as admission control, queueing, scheduling, or traffic shaping would have to implement the actual service.

This preserves a separation between:

• the signaling or control plane;
• the packet-forwarding or data plane.

Lecture 20 ended after introducing RSVP and multicast. Its detailed operation continued in Lecture 21.

RSVP uses two principal message directions.

A PATH message travels from a sender toward the receivers, following the same direction as the future data packets. Its purpose is to announce the sender and build path state in the routers.

A RESV message travels in the reverse direction, from a receiver toward one or more senders. Its purpose is to request resources for the data that will later travel toward that receiver.

The relationship can be represented as follows:

Data and PATH direction:

Sender ----> R1 ----> R2 ----> Receiver


RESV direction:

Sender <---- R1 <---- R2 <---- Receiver

The fact that a RESV message travels toward the sender does not mean that the reserved bandwidth is used in that direction. The reservation applies to the opposite direction, namely the downstream path followed by the data.

RSVP can also carry path errors, reservation errors, and explicit teardown messages. These additional messages help report problems or remove state more quickly, but PATH and RESV messages are the core of normal RSVP operation.

A sender periodically transmits PATH messages toward the destination or multicast group.

A PATH message identifies the relevant destination or multicast group and can describe the sender’s traffic. For example, it may state the expected bandwidth of the flow. It can also include source-filtering information, the identity of the previous hop, the identity of the upstream sender, and the lifetime of the state.

When a router receives a PATH message, it records where that sender is located relative to itself. In particular, it records the previous hop and the interface through which the sender can be reached.

Consider the following path:

Sender S ----> R1 ----> R2 ----> Receiver H

After receiving the PATH message, R2 knows that the reverse path toward S goes through R1. This information will later allow R2 to forward a RESV message from H in the correct direction.

A PATH message does not itself reserve bandwidth. It prepares the routers by creating the path state required for the later reservation.

The lecture illustrates RSVP using an audio conference with five hosts, H1 through H5. Every host may both send and receive audio, and all of them are associated with the same multicast group m1.

The example assumes that one audio stream requires bandwidth \(b\). It also assumes that receivers accept traffic from any sender, so no source-specific filter is used.

Each potential sender transmits PATH messages. As these messages traverse the three routers in the example, the routers learn where each sender is located and through which interfaces the multicast traffic may flow.

Because RSVP uses soft state, the routers do not need to acknowledge every PATH message. If an initial or refresh message is lost, a later periodic PATH message can create or refresh the state.

Reservations are initiated by receivers rather than by the sender.

This design is important in multicast because the paths to different receivers may have very different properties. One receiver may be reached through a high-bandwidth path, while another receiver may be behind a slower access link. The sender is not necessarily in a good position to choose one resource reservation that is appropriate for all receivers.

Each receiver therefore requests the service suitable for its own path.

A RESV message may describe the desired bandwidth and the reservation style. It may also identify which sender or senders are allowed to use the reservation. A receiver can request a shared reservation usable by any sender, or it can restrict the reservation to particular sources.

Suppose H1 wants to receive an audio stream at rate \(b\).

H1 sends a RESV message toward the senders. The first router receiving that message reserves the required resources on the outgoing interface leading toward H1. It then consults the earlier PATH state to determine where the senders are located and forwards the RESV message upstream.

Each router repeats the same operation. It reserves resources on the downstream interface used by the future data traffic and forwards the reservation request toward the sender.

The final state therefore looks conceptually like this:

                    bandwidth b             bandwidth b
Sender ----> R1 =================> R2 =================> H1

The RESV message travelled from right to left, but the resources are used by data travelling from left to right.

Now suppose that H2 also requests a shared reservation of bandwidth \(b\).

On a branch used only by H2, new reservation state must be installed. However, on a link already shared by the paths toward H1 and H2, the router does not necessarily reserve another independent \(b\).

If the reservations are compatible and one shared audio stream is sufficient, the router can merge the requests.

For example:

                         ----> H1
Sender ----> R1 ----> R2
                         ----> H2

The two receiver-specific branches need their own reservation state, but the shared link between R1 and R2 may require only one merged reservation.

This merging is central to multicast scalability. Without it, routers might need completely independent state on every shared link for every receiver. RSVP was designed so that its control overhead should grow at worst roughly linearly with the number of receivers rather than exploding much faster.

The loss of one refresh does not normally destroy the state immediately. The router retains the state until the timeout expires, so a later refresh can still renew it.

For this reason, the state timeout must be longer than the normal refresh interval. Otherwise, one delayed or lost control message could remove a valid reservation.

Periodic refreshes therefore provide a form of implicit reliability. RSVP does not need to acknowledge every ordinary refresh because another refresh will normally follow.

If a sender crashes, its PATH refreshes stop. The routers temporarily retain the path state, but the state eventually expires.

Likewise, if a receiver leaves or crashes, its RESV refreshes stop. The corresponding reservation state remains for a limited time and then disappears.

An explicit teardown message can remove the state sooner, but RSVP does not depend entirely on receiving the teardown. This prevents a crashed endpoint from leaving permanent orphaned reservations in the network.

Suppose the original path is:

S ----> R1 ----> R2 ----> R3 ----> H

If the link through R2 fails, the routing protocol may calculate a new path:

S ----> R1 ----> R4 ----> R5 ----> R3 ----> H

RSVP itself does not discover this route. Routing performs that task.

Once the routing tables have changed, later PATH refreshes follow the new path. R4 and R5 therefore create path state. Later RESV refreshes follow the new reverse path and establish reservations on the new data path.

The state on the abandoned part of the old route receives no further refreshes and eventually expires.

The recovery therefore follows this causal sequence:

a router or link fails
        |
        v
routing calculates a new path
        |
        v
new PATH refreshes follow that path
        |
        v
new RESV refreshes establish reservations
        |
        v
old unrefreshed state expires

The endpoints do not need a special RSVP recovery procedure for every possible link or router failure. Normal refresh processing adapts the state after routing has changed.

When a new receiver joins, it can send a RESV message and create a reservation for its branch of the multicast tree.

When a receiver leaves, it stops refreshing its reservation and the state eventually disappears.

When a new sender appears, its PATH messages announce it to the routers. Subsequent RESV messages can then include or exclude that sender according to the receiver’s filter.

Thus, the same soft-state mechanism handles lost signaling messages, changing routes, sender changes, receiver changes, and silent endpoint failures.

In a completely flat routing system, every router would need information about every individual destination.

This would make routing tables enormous. It would also make routing updates very expensive, because routers would have to exchange and process information about a vast number of individual destinations.

Even storing all possible IPv4 /24 prefixes individually would produce millions of entries. A comparable flat structure for IPv6 would be far larger.

The Internet therefore introduces hierarchy.

Routers are grouped into administrative regions called Autonomous Systems (ASes).

Within one AS, routers are controlled by the same administration and normally use a common intra-AS routing protocol, such as OSPF or IS-IS.

Different ASes do not need to use the same internal routing protocol. A small organization and a large service provider can select different internal designs according to their own topology and requirements.

Gateway or border routers participate in two routing contexts. Internally, they run the intra-AS protocol together with the other routers in their AS. Externally, they exchange reachability information with gateways in other ASes using BGP.

A packet travelling between two ASes therefore passes through three logical stages:

source host
    |
    v
intra-AS routing inside source AS
    |
    v
inter-AS routing between ASes
    |
    v
intra-AS routing inside destination AS
    |
    v
destination host

The forwarding table of a router is ultimately influenced by both intra-AS and inter-AS routing information.

Hierarchy solves two problems simultaneously. First, it reduces the amount of global routing information. Second, it preserves administrative autonomy, because each AS can control its own internal routing.

Older IPv4 addressing divided networks into fixed address classes.

A Class A network received a very large address block, a Class B network received a medium-sized block, and a Class C network received a smaller block.

These fixed sizes were inefficient. An organization needing only a few thousand addresses might receive a Class B block containing approximately 65,000 addresses, wasting most of them.

Classless Inter-Domain Routing (CIDR) allows the network prefix to have an arbitrary length.

An address block is written as:

a.b.c.d/x

Here, \(x\) is the number of bits belonging to the network prefix.

Suppose an ISP receives:

200.23.16.0/20

The ISP can extend the prefix by three bits and divide the block into eight /23 networks. These smaller prefixes can then be allocated to different customers.

If all eight customer networks are reached through the same ISP, the ISP does not need to advertise every /23 separately to the rest of the Internet.

Instead, it can advertise one aggregate route:

200.23.16.0/20

External routers only need to know that all addresses in this block are reachable through the ISP. Once a packet reaches the ISP, its internal routing determines which customer link should receive it.

Aggregation reduces global routing-table size and routing-update traffic.

Suppose one customer originally using 200.23.18.0/23 moves to another ISP.

The original ISP can continue advertising the aggregate 200.23.16.0/20, while the new ISP advertises the more specific route:

200.23.18.0/23

An address such as 200.23.18.7 matches both routes. Routers resolve the ambiguity using longest-prefix matching.

Because /23 is more specific than /20, packets for that customer follow the /23 route through the new ISP. The aggregate /20 continues to cover the remaining customer networks.

CIDR therefore allows both aggregation and controlled exceptions to that aggregation.

A shared Ethernet cannot simply be enlarged across an arbitrarily large geographic area.

As distance increases, propagation delay increases. In random-access protocols, this gives distant nodes more time to begin transmitting before they hear one another, which increases collision-related problems.

Thus, the physical size of a network affects which channel-access mechanisms remain practical.

A communication rule that works for a small group may fail when hundreds of participants compete for the same resource.

The lecturer compares this with classroom discussion. A few students can speak informally, but a lecture with hundreds of students needs a more structured method for controlling who speaks.

Similarly, channel-access and routing mechanisms must change when the number of communicating nodes becomes large.

Push systems can work well when there are only a small number of senders. However, large-scale unsolicited pushing can overload receivers or force the sender to maintain substantial per-receiver state.

Pull systems move more responsibility to the clients. A client requests data only when it needs it. HTTP follows this model: the client requests an object and the server returns it.

For many large-scale services, this request-driven structure is easier to manage than continuously pushing information to every possible receiver.

At small scale, users may remember addresses or distribute them manually.

At Internet scale, this is impossible. A naming and lookup system becomes necessary so that users can refer to memorable names while the system locates the current network address.

DNS provides hierarchical naming, distributed storage, caching, and address translation.

A single centralized site eventually becomes a bottleneck and a single point of failure. Large systems therefore require replication or another form of distribution.

Physical distribution does not completely eliminate logical centralization. A provider such as a large CDN, identity service, or cloud operator may use many data centers but still represent one critical dependency. An outage in that provider can therefore affect many otherwise independent websites.

Flooding becomes more expensive as a network grows because every additional node and link receives or forwards more copies.

Large systems therefore replace unrestricted flooding with limited flooding, pruning, hierarchy, caching, or explicit routes.

The same reasoning explains why large networks cannot remain one Layer-2 broadcast domain. As the network grows, it is divided into routed Layer-3 networks or smaller virtual Layer-2 domains.

An IP address normally identifies both an endpoint and its topological location.

When a mobile node moves to another network, its physical location changes, but correspondents still want to reach it through a stable identity.

Two general solutions are considered.

Indirect routing preserves a stable permanent address by sending traffic through a home agent.

Direct routing first discovers the mobile node’s current address and then sends traffic directly to that location.

The home network is the permanent network associated with the mobile node.

The permanent address is an address in the home network that correspondents can continue using even while the mobile is away.

The home agent is an entity in the home network that performs mobility functions on behalf of the mobile node.

The visited network is the network in which the mobile node is currently located.

The care-of address identifies the mobile node’s current location in the visited network.

The foreign agent is an entity in the visited network that helps deliver traffic to the mobile node. In some designs, the mobile node itself performs the foreign-agent function.

The correspondent is the host that wants to communicate with the mobile node.

When the mobile enters a visited network, it registers with the foreign agent. The foreign agent then informs the home agent that the mobile is currently reachable through this visited network.

After registration, the foreign agent knows how to deliver packets locally, while the home agent knows the mobile’s current care-of address.

With indirect routing, the correspondent continues sending packets to the permanent address.

Normal IP routing therefore carries the packet toward the home network. The home agent intercepts it and tunnels it to the care-of address. The foreign agent removes the tunnel encapsulation and forwards the original packet to the mobile node.

The mobile may send its response directly to the correspondent.

Correspondent ----> Home Agent =====tunnel=====> Foreign Agent ----> Mobile

Mobile -----------------------------------------------------------> Correspondent

The main advantage is transparency. The correspondent does not need to know where the mobile currently resides. It continues using the permanent address, and ongoing connections can potentially survive movement.

When the mobile moves again, it registers with a new foreign agent. The home agent updates the care-of address, and later packets are tunnelled to the new location.

Indirect routing may create a path shaped like a triangle.

Even if the correspondent and the mobile are physically close, traffic may first travel to a distant home network and then return to the mobile’s current network.

This can add considerable latency.

The lecturer relates this effect to some roaming and travel-eSIM services. Although the user is connected to a nearby mobile network, the provider may tunnel traffic through a distant home endpoint.

Direct routing avoids the permanent detour through the home network.

The correspondent first asks the home agent for the mobile’s current care-of address. It then sends data directly to the visited network, where the foreign agent delivers the packets to the mobile.

This improves path efficiency, but mobility is no longer transparent.

The correspondent must know and maintain the care-of address. If the mobile moves again, that address becomes stale and the correspondent must be updated. An existing connection may therefore require additional mobility support.

The trade-off is:

Mobile IP standardizes many of these ideas.

Its mechanisms include agent discovery, registration with the home agent, care-of addresses, home and foreign agents, encapsulation, and indirect routing.

Encapsulation creates a packet within another packet. The outer packet is routed to the current location, while the inner packet retains the permanent source and destination information expected by the endpoints.

Early networking consisted of several separate networks, including ARPANET, packet-radio networks, packet-satellite networks, and data-over-cable networks.

These networks differed in their address formats, packet formats, error recovery, routing, and physical technology.

The goal was not to replace all of them with one identical network. Cerf and Kahn instead argued that interconnection should preserve each network’s internal operation.

A common internetwork layer was placed above the heterogeneous local networks.

Gateways connect the networks. A gateway embeds an internetwork packet inside the local packet format, forwards it through the local network, extracts it again, and routes it toward the next gateway.

This creates two addressing levels.

The internetwork layer uses one uniform global address space. The local network may use its own local addresses and frames.

From the perspective of the internetwork layer, the different underlying technologies appear to form one homogeneous Internet. Cable, radio, satellite, or modem details become largely invisible to the application.

This is why the Internet itself can be understood as a network-virtualization architecture.

The early design initially treated internetwork forwarding and reliable transport more closely together.

They were later separated because their responsibilities differ.

IP provides stateless, connectionless, best-effort forwarding. TCP and other transport protocols may keep end-to-end state and implement reliability.

This separation allows the same IP network to support TCP, UDP, and later transport protocols without requiring routers to implement the state machine of each transport.

Traditional IP routing selects paths using IP addresses and network-level metrics.

An overlay can instead use application-specific names and goals. It may route according to a content identifier, user identity, service name, topic, or publish/subscribe relationship.

As a result, performance no longer means only minimizing delay or maximizing throughput. An application may consider a route better because it obtains the desired content, reaches an available replica, or satisfies another application-specific requirement.

An overlay can choose paths that avoid congestion or poor routing in the underlay. It can also implement functions such as broadcast, multicast, security, anonymity, caching, and publish/subscribe without changing every Internet router.

However, the overlay has incomplete knowledge of the physical network.

It may not know the real topology, the shared physical bottlenecks, link-level QoS, or the cause of congestion. Two logical overlay links that appear independent may actually cross the same physical link.

The overlay therefore gains functionality and deployment flexibility, but may lose some performance information available inside the underlay.

Akamai SureRoute directs traffic to a nearby Akamai endpoint and then selects a path through Akamai’s own infrastructure. Because Akamai controls and measures its network, it may avoid badly performing public Internet paths before returning the traffic to the ordinary Internet near the destination.

iCloud Private Relay creates a two-hop proxy overlay. Different proxy hops handle different pieces of information, providing additional privacy through indirection.

Security and anonymity mechanisms are often easier to add at the application or overlay layer than at the IP layer. Changing applications and proxies is usually more practical than upgrading every router on the Internet.

A Virtual Private Network (VPN) appears to its customer as a private network, although it is built over shared service-provider infrastructure or the public Internet.

A company may have offices in several countries. Instead of constructing private physical links between every office, it connects each site to a provider and creates virtual links across the provider’s backbone.

From the customer’s perspective, the sites appear to be directly connected inside one private network. Physically, the packets may pass through many shared routers, links, and carriers.

The architecture normally includes customer-edge devices, provider-edge devices, and the shared provider backbone.

VPN connectivity is commonly implemented using tunnels.

At the tunnel entrance, the device receives the original packet, may encrypt it, and places it inside a new outer packet. The outer header identifies the tunnel endpoint and allows the shared underlay to route the packet.

At the tunnel exit, the outer header is removed. If the inner packet was encrypted, it is decrypted and then forwarded inside the destination private network.

Original private packet
        |
        v
encrypt and add outer header
        |
        v
shared Internet or provider network
        |
        v
remove outer header and decrypt
        |
        v
original packet enters remote private site

The customer therefore sees a logical private link, while the provider sees ordinary tunnel packets between the tunnel endpoints.

Encapsulation adds bytes.

Suppose the path MTU is 1500 bytes and the original endpoint sends a 1500-byte packet. After the VPN adds an outer header, the resulting packet is larger than the path can carry directly.

A managed VPN can reduce the MTU used inside the private network:

\[ MTU_{\text{inner}} \leq MTU_{\text{path}}-\text{tunnel overhead}. \]

However, endpoints do not always know that an ISP or another intermediate provider is using a hidden tunnel. Consequently, assuming that every Internet path can safely carry a full 1500-byte packet may cause fragmentation or other Path-MTU problems.

In a leased-line design, the service provider establishes dedicated or logically dedicated channels between customer sites.

The provider manages much of the configuration and may offer stronger bandwidth or QoS guarantees. However, installation can require considerable time and manpower, and the service may be expensive.

In a customer-edge design, the customer configures and operates the VPN endpoints.

The tunnels run across ordinary provider service, and the provider usually treats the outer packets like normal Internet traffic.

This can be cheaper and more flexible, but it requires the customer to possess the expertise needed to configure, secure, and maintain the VPN.

In a network-based VPN, the provider maintains separate logical routing contexts for different customers.

A single physical provider router may therefore behave like several independent virtual routers. Customers may use private address spaces, and the provider must ensure that routes or packets belonging to one VPN cannot be injected into another VPN.

Encryption can provide confidentiality while traffic crosses shared infrastructure. VPNs also work well for mobility because a remote user can join the virtual network and appear to be located inside the organization’s internal network.

Because VPNs reuse lower-layer infrastructure, they can benefit from the provider’s multiple paths, redundancy, and fault-recovery mechanisms. They also simplify the logical management of geographically separated sites.

However, each VPN design moves complexity somewhere. A leased-line VPN places configuration and maintenance work on the provider. A customer-edge VPN places it on the customer. A network-based VPN requires the provider to maintain strictly isolated routing contexts.

VPN membership is also sometimes treated as proof that a device is trusted. This simplifies access to internal services, but it can create security problems if every device inside the VPN is trusted automatically without additional authentication or authorization.

A single Layer-2 LAN is one broadcast domain.

ARP requests, DHCP traffic, and frames for unknown MAC addresses may be flooded throughout the LAN. As the number of attached devices grows, more machines receive and process this traffic.

A large broadcast domain therefore creates efficiency, security, and privacy problems.

There is also an administrative problem. An employee may physically move to a port on another building’s switch while still needing to remain part of the same departmental network.

A Virtual LAN (VLAN) solves these problems by separating one physical switching infrastructure into several logical LANs.

A VLAN-capable switch behaves conceptually as if it contained several independent switches.

Devices in the same VLAN share one logical Layer-2 network. Devices in different VLANs may be connected to the same physical switch, but their ordinary Layer-2 traffic remains separated.

A broadcast sent inside one VLAN is forwarded only to ports belonging to that VLAN.

Thus, VLANs reduce the size of broadcast domains and allow departments or tenants to share physical infrastructure without sharing one Layer-2 network.

The common design assigns each access port to one VLAN.

An endpoint sends ordinary untagged Ethernet frames. The switch associates those frames with the VLAN configured for that port.

The endpoint does not need to understand VLAN tagging. The switch adds or removes the VLAN information as required inside the switching infrastructure.

From the endpoint’s perspective, it is simply attached to an ordinary LAN.

VLAN membership can also be assigned dynamically according to device identity, MAC address, authentication, or administrative policy. This allows a device to move physically while remaining in the same logical network.

Different VLANs are separate Layer-2 networks.

A host in one VLAN cannot directly send an ordinary Ethernet frame to a host in another VLAN.

Communication between them requires Layer-3 forwarding through a router or a Layer-3 switch. Routing policy can then determine which communication between the VLANs is permitted.

Suppose two switches both contain ports belonging to VLAN 10 and VLAN 20.

The link between the switches must carry traffic from both VLANs. Assigning the link to only one VLAN would prevent the other VLAN from crossing it.

A trunk port solves this problem by carrying frames from several VLANs.

The frames must contain a VLAN identifier so that the receiving switch knows which logical LAN each frame belongs to. IEEE 802.1Q adds this VLAN information to the Ethernet frame.

A trunk may carry every VLAN or only an explicitly allowed subset.

A server or other endpoint can also be connected to a trunk port, but in that case the endpoint normally has to generate and interpret the tagged frames itself.

VLANs provide useful isolation, but incorrect configuration can easily break a network.

A trunk may allow the wrong VLANs, ports may be assigned inconsistently, or traffic may leak between logical networks.

Layer-2 cycles also remain important. It is possible to create a physical topology containing cycles while arranging the VLAN topology differently. Such designs can provide redundant uplinks, but they become difficult to reason about and depend on correct VLAN-aware spanning-tree configuration.

The fundamental goal was to interconnect networks that already existed and were designed independently.

The Internet did not require ARPANET, satellite networks, packet-radio networks, or later Ethernet and wireless networks to adopt one identical internal technology.

Instead, IP provided one common layer above them.

This goal was highly successful and created the Internet’s defining network-of-networks architecture.

The network should continue communicating after router or link failures, provided that the failure has not completely partitioned the network.

A central architectural decision supporting this goal was to move end-to-end connection state out of the routers and into the endpoints.

Suppose a TCP connection’s state were stored in an intermediate router. If routing changed and packets began using another router, the new path would not contain the required state and the connection could fail.

Instead, TCP state is kept by the two hosts. IP routers simply forward datagrams and do not know that the packets belong to a particular call or connection.

This is related to fate sharing. State is placed in the endpoints because if an endpoint fails, the connection is useless anyway. Router failure should not destroy end-to-end state that still matters to surviving hosts.

The IP layer is therefore stateless with respect to end-to-end sessions, connectionless, and best effort.

The lecture assigns approximately grade A- to survivability. The basic architecture handles path failures well, but routing convergence is not instantaneous. BGP may require minutes to converge after some changes, while intra-domain protocols may still require seconds. Communication can therefore be interrupted temporarily even when an alternative path exists.

The Internet should support applications requiring different communication services.

Separating IP from transport allowed different transports to coexist. TCP offers a reliable byte stream, while UDP offers a minimal datagram service. Later transport protocols can also operate above the same IP layer.

The IP datagram acts as a lowest-common-denominator service on which many higher-level behaviors can be constructed.

The architecture also included fields intended for service differentiation, although strong end-to-end QoS did not become universally available.

The lecture gives this goal approximately grade A-. The design enabled a huge variety of applications, although multimedia and QoS requirements are not always served perfectly.

The underlying network is required to make only a minimal promise: it should deliver packets with a reasonable probability of success.

It does not have to guarantee reliable delivery, in-order delivery, one common packet format, or one physical technology.

This minimal interface makes it possible to run IP over Ethernet, Wi-Fi, fiber, satellite, radio, and many other systems.

The experimental idea of transmitting IP packets using carrier pigeons is mentioned to illustrate how weak the lower-layer requirements are.

This goal receives grade A and is one of the Internet’s greatest successes.

No single organization could manage the complete global Internet.

The architecture therefore allows each AS to control its own internal topology, routing protocol, policies, and infrastructure. The AS mainly interacts with the rest of the Internet at its boundaries.

This autonomy made global expansion possible.

However, autonomy also complicates routing. Organizations may hide internal information, optimize according to economic interests, apply conflicting policies, advertise incorrect BGP routes, or prefer some traffic sources over others.

The implementation of distributed management works extremely well and can be viewed as an A. Conceptually and politically, however, the resulting policy problems justify a lower assessment, roughly B.

The Internet contains several sources of inefficiency. Headers consume bandwidth, retransmissions repeat work, and routing paths are not always optimal.

Nevertheless, perfectly optimal performance was never the top priority. A simple system that operates across heterogeneous networks can be more useful than an optimal design that is too expensive or inflexible to deploy.

The lecture gives this goal approximately grade B. The network contains real inefficiencies, but the Internet has nevertheless reduced communication and service costs in many areas.

The original vision suggested that a new host should be easy and inexpensive to connect.

This is not one of the Internet’s strongest results because the architecture places substantial intelligence in the endpoints.

A host must implement IP, transport protocols, configuration mechanisms, congestion and flow control, and application behavior. This is more complex than attaching a traditional telephone.

Bad implementations or malicious users can also harm other systems. For example, an endpoint can open excessive numbers of connections or transmit in ways that consume other hosts’ resources.

DHCP, IPv6 autoconfiguration, and automatic router discovery have made host attachment easier over time.

The lecture assigns approximately grade C, while noting that future automation may justify a higher grade.

Accountability was one of the original goals, but the Internet did not develop a strong general mechanism for establishing responsibility for traffic and actions.

Addresses may be spoofed, shared, translated, dynamically assigned, or hidden behind intermediaries. Administrative domains also reveal limited internal information.

The lecture therefore assigns accountability grade F.