Group A — Short Answer Questions (1 Mark Each)
Ans: Concise point-wise definition/formula for Define Computer Network. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is OSI Reference Model? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Name all 7 layers of OSI Model in order. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is TCP/IP Model? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define Physical Topology. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Star Topology? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Mesh Topology? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define Bandwidth. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define Throughput in networking. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define Propagation Delay. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define Transmission Delay. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Bandwidth-Delay Product? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define Simplex, Half-Duplex, and Full-Duplex. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Guided Transmission Media? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Unguided Transmission Media? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define Optical Fiber communication. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Bit Rate and Baud Rate? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define Pulse Code Modulation (PCM). in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Framing in Data Link Layer? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define Error Detection and Error Correction. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Parity Check? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Cyclic Redundancy Check (CRC)? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Hamming Code? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define Hamming Distance. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Flow Control? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Stop-and-Wait Protocol? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Sliding Window Protocol? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Go-Back-N ARQ? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Selective Repeat ARQ? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define Piggybacking. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is MAC Address? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define CSMA/CD. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define CSMA/CA. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Pure ALOHA? --- Page 2 --- in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Slotted ALOHA? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is IP Address? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define IPv4 Address structure. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define IPv6 Address structure. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Subnetting? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is CIDR? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Network Address Translation (NAT)? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is ARP? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is RARP? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is ICMP? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is DHCP? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Distance Vector Routing? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Link State Routing? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for Define Congestion Control. in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Leaky Bucket Algorithm? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is Token Bucket Algorithm? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is DNS? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is HTTP and HTTPS? in accordance with MAKAUT examination pattern.
Ans: Concise point-wise definition/formula for What is FTP? in accordance with MAKAUT examination pattern.
Group B — Medium / Descriptive Questions (5 Marks Each)
Ans: The OSI (Open Systems Interconnection) model is a 7-layer conceptual framework (ISO standard) that standardizes how data moves from one application on a source host to an application on a destination host across a network.
- Physical: Transmits raw bits over a physical medium; deals with voltage, cabling, connectors, bit synchronization.
- Data Link: Framing, physical (MAC) addressing, error detection, and flow control over a single link.
- Network: Logical (IP) addressing and routing of packets across multiple networks.
- Transport: End-to-end reliable/unreliable delivery, segmentation, flow and congestion control (TCP/UDP).
- Session: Establishes, manages, and terminates sessions/dialogs between applications.
- Presentation: Data translation, encryption, and compression (syntax layer).
- Application: Provides network services directly to end-user applications (HTTP, FTP, SMTP).
Ans: The OSI model is a 7-layer theoretical reference model, while TCP/IP is a 4-layer practical protocol suite that actually runs the Internet.
| Basis | OSI Model | TCP/IP Model |
|---|---|---|
| Layers | 7 (Physical, Data Link, Network, Transport, Session, Presentation, Application) | 4 (Network Access/Link, Internet, Transport, Application) |
| Development | Reference model, protocol-independent, defined first | Developed along with the protocols (DoD project), defined after implementation |
| Session/Presentation | Separate dedicated layers | Merged into Application layer |
| Reliability | Model is generic — reliability not tied to a layer | Transport layer explicitly offers both reliable (TCP) and unreliable (UDP) service |
| Usage | Used as a teaching/reference standard | Used in actual Internet implementation |
| Approach | Horizontal (layer-to-layer) approach | Vertical, protocol-driven approach |
Both models use encapsulation/de-encapsulation and layered, modular design so each layer can evolve independently as long as the interface to adjacent layers is preserved.
Ans: Guided (wired) transmission media carry signals along a solid path; the three principal types differ in bandwidth, noise immunity, and cost.
| Medium | Construction | Bandwidth | Noise Immunity | Typical Use |
|---|---|---|---|---|
| Twisted Pair (UTP/STP) | Two insulated copper wires twisted together to cancel electromagnetic interference | Up to 10 Gbps (Cat6a) over short runs | Low-Moderate (STP better than UTP) | LAN/Ethernet, telephone lines |
| Coaxial Cable | Central copper conductor, insulator, braided metallic shield, outer jacket | Up to ~1 Gbps | Better than twisted pair (shielded) | Cable TV, older Ethernet (10BASE2/5) |
| Optical Fiber | Glass/plastic core carrying light pulses via total internal reflection | Tens of Gbps to Tbps | Immune to EMI, very low attenuation | Backbone links, long-haul, FTTH |
Fiber offers the highest bandwidth and longest distance with lowest attenuation but is costlier to install and splice; twisted pair is cheapest and easiest to terminate; coaxial sits in between and is largely obsolete for new LAN deployments.
Ans: Switching decides how data travels through intermediate nodes from source to destination.
| Basis | Circuit Switching | Packet Switching |
|---|---|---|
| Path | Dedicated physical path set up before data transfer | No dedicated path; each packet routed independently |
| Setup | Requires call setup/teardown phase | No setup phase needed (connectionless) or virtual circuit for connection-oriented |
| Bandwidth use | Wasted if idle (reserved even when not sending) | Efficient — bandwidth shared/statistically multiplexed |
| Delay | Constant delay once connected, no queuing after setup | Variable delay due to queuing at each router |
| Example | Traditional PSTN telephone network | Internet (IP networks) |
Ans: Cyclic Redundancy Check (CRC) is a polynomial-based error-detection technique used at the Data Link layer to detect burst errors with very high probability.
Mechanism:
- Sender and receiver agree on a generator polynomial G(x) of degree r (represented as an (r+1)-bit pattern).
- Sender appends r zero bits to the data (message M) and divides the resulting bit string by G using modulo-2 (XOR) binary division.
- The remainder of this division is the CRC checksum/FCS; it replaces the appended zeros to form the transmitted frame T = M·2^r XOR remainder.
Analysis: CRC with an r-bit generator detects all single-bit errors, all double-bit errors (if G has ≥2 terms and is not divisible by x), all odd number of errors (if G has factor (x+1)), and all burst errors of length ≤ r. It is far stronger than simple parity and is widely used in Ethernet, HDLC, and USB frame trailers.
Ans: Hamming Code adds redundant parity bits at positions that are powers of 2 so that not only can an error be detected, its exact bit position can also be located and corrected (single-error correction).
Example (4 data bits d1d2d3d4 = 1 0 1 1): Using 3 parity bits (p1,p2,p4) placed at positions 1,2,4 gives a 7-bit code p1 p2 d1 p4 d2 d3 d4 at positions 1-7.
| Position | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|
| Bit | p1 | p2 | d1=1 | p4 | d2=0 | d3=1 | d4=1 |
Each parity bit covers positions whose binary index has that bit set:
- p1 covers 1,3,5,7 → checks bits (p1),1,0,1 → p1 XOR 1 XOR 0 XOR 1 = 0 → p1 = 0
- p2 covers 2,3,6,7 → checks (p2),1,1,1 → p2 XOR 1 XOR 1 XOR 1 = 0 → p2 = 1
- p4 covers 4,5,6,7 → checks (p4),0,1,1 → p4 XOR 0 XOR 1 XOR 1 = 0 → p4 = 0
Final transmitted code = 0 1 1 0 0 1 1 (positions 1-7). At the receiver, the same three parity groups are recomputed; if all match, no error. If a mismatch pattern occurs, the binary value of the mismatched parity positions (c4 c2 c1) directly gives the erroneous bit's position, which is then flipped to correct it — e.g. if bit 3 flips, checks p1 and p2 fail (positions 1+2=3), pinpointing position 3.
Ans: In Stop-and-Wait ARQ, the sender transmits one frame and then waits for the receiver's acknowledgement (ACK) before sending the next frame; a timer triggers retransmission if the ACK is lost or delayed.
Efficiency formula: Let Tt = transmission time, Tp = propagation delay, and a = Tp / Tt. One full cycle takes Tt + 2Tp, so:
When propagation delay is large compared to transmission time (large a, e.g. satellite links), efficiency drops sharply because the sender remains idle for most of the round-trip time — this motivates sliding-window protocols (GBN, SR).
Ans: Go-Back-N ARQ is a sliding-window protocol where the sender can transmit up to N frames without waiting for individual acknowledgements, but the receiver only accepts frames in strict order (cumulative ACK).
Window sizes: with an m-bit sequence number field, sender window size = 2^m - 1 and receiver window size = 1 (receiver only buffers the next expected frame, discarding out-of-order arrivals). Cumulative ACKs mean one ACK confirms all frames up to that sequence number, but a single error forces re-sending the entire window from the lost frame onward, wasting bandwidth on high-error links.
Ans: Selective Repeat ARQ improves on Go-Back-N by having the receiver individually buffer and acknowledge out-of-order frames, so only the specific corrupted/lost frame needs retransmission.
Window sizes: both sender and receiver maintain a window; to avoid ambiguity between new and retransmitted frames the maximum window size for both sender and receiver is restricted to 2^(m-1) (half of Go-Back-N's), where m is the sequence-number field width. Selective Repeat is more bandwidth-efficient on lossy/high-latency links but requires more receiver buffering and sequencing logic than Go-Back-N.
Ans: ALOHA is a random-access MAC protocol where stations transmit whenever they have data, risking collisions; throughput S is analyzed against offered load G (average number of transmission attempts per frame time).
| Scheme | Vulnerable Period | Throughput Formula | Max Throughput |
|---|---|---|---|
| Pure ALOHA | 2 × frame time (2Tf) — station can transmit any instant | S = G·e^(-2G) | 18.4% at G = 0.5 |
| Slotted ALOHA | 1 × frame time (Tf) — transmission confined to slot boundaries | S = G·e^(-G) | 36.8% at G = 1.0 |
Why slotted is better: Time is divided into slots equal to one frame transmission time, and stations may only start transmitting at a slot boundary. This halves the vulnerable period compared to Pure ALOHA (where a frame can collide with any frame starting up to one frame-time before or after it), doubling the maximum achievable throughput (36.8% vs 18.4%). Both schemes still waste significant capacity to collisions compared to collision-avoidance/detection schemes like CSMA/CD or CSMA/CA, but ALOHA's simplicity (no carrier sensing needed) made it foundational for satellite and early packet radio networks.
Ans: CSMA/CD (Carrier Sense Multiple Access with Collision Detection) is used in classic wired Ethernet: a station listens ("carrier sense") before transmitting, and continues to listen while transmitting to detect collisions.
Binary Exponential Backoff: After the n-th collision on the same frame, the station picks a random integer K from {0, 1, ..., 2^min(n,10) - 1} and waits K slot times before retrying (slot time = 512 bit times in classic Ethernet). This spreads out retransmission attempts, so as contention increases, the retry window grows exponentially, reducing repeated collisions. After 16 failed attempts the frame is dropped and reported as an error.
Ans: CSMA/CA (Collision Avoidance) is used in wireless LANs (IEEE 802.11) because collision detection is impractical over radio (a station cannot listen while transmitting due to its own strong signal drowning out weak received signals, and hidden-terminal effects).
Mechanism: A station senses the channel; if idle, it waits a fixed DIFS (DCF Interframe Space) period, then a random backoff counter (contention window) before transmitting — this avoidance-first approach reduces collision probability instead of reacting after the fact. Optionally, RTS/CTS (Request-to-Send / Clear-to-Send) frames are exchanged first: the CTS frame carries a duration field that instructs all other stations to set their NAV (Network Allocation Vector) and stay silent, solving the hidden-terminal problem. Every successfully received unicast frame is explicitly acknowledged with an ACK, since the sender cannot infer success by listening for collisions.
Ans: Classful IPv4 addressing divides the 32-bit address space into 5 classes, identified by the leading bits of the first octet.
| Class | Leading Bits | First Octet Range | Default Mask | Purpose |
|---|---|---|---|---|
| A | 0 | 0 – 127 | 255.0.0.0 (/8) | Very large networks (few networks, many hosts) |
| B | 10 | 128 – 191 | 255.255.0.0 (/16) | Medium-sized networks |
| C | 110 | 192 – 223 | 255.255.255.0 (/24) | Small networks (many networks, few hosts) |
| D | 1110 | 224 – 239 | N/A | Multicast addressing |
| E | 1111 | 240 – 255 | N/A | Reserved for experimental/research use |
Class A supports ~16.7 million hosts per network (2^24−2), Class B ~65,534 hosts (2^16−2), and Class C 254 hosts (2^8−2) — the −2 accounts for the reserved network and broadcast addresses. This rigid classful scheme wastes address space (e.g. a company needing 300 hosts must take a wasteful Class B), which is why classless CIDR addressing later replaced it in practice.
Ans: Subnetting divides one large IP network into multiple smaller sub-networks by borrowing host bits to extend the network portion of the address (via the subnet mask), improving address utilization and isolating broadcast domains.
Worked example: Subnet 192.168.10.0/24 into 4 equal subnets.
- Need 4 subnets → borrow n bits where 2^n ≥ 4 → n = 2 bits borrowed from the host portion.
- New prefix = /24 + 2 = /26 → subnet mask = 255.255.255.192 (11000000 in last octet).
- Block size = 2^(32-26) = 2^6 = 64 addresses per subnet.
| Subnet | Network Address | Usable Host Range | Broadcast Address |
|---|---|---|---|
| 1 | 192.168.10.0 | .1 – .62 | 192.168.10.63 |
| 2 | 192.168.10.64 | .65 – .126 | 192.168.10.127 |
| 3 | 192.168.10.128 | .129 – .190 | 192.168.10.191 |
| 4 | 192.168.10.192 | .193 – .254 | 192.168.10.255 |
Each subnet provides 64−2 = 62 usable host addresses (excluding network and broadcast addresses), and the four blocks exactly partition the original /24 with no overlap.
Ans: CIDR (Classless Inter-Domain Routing) replaces rigid classful addressing with a flexible "slash notation" address/prefix-length, where the prefix length explicitly states how many leading bits form the network portion, independent of class boundaries.
- Notation: e.g. 203.0.113.0/26 means the first 26 bits are the network id, leaving 6 host bits (block size 64).
- Variable Length Subnet Masking (VLSM): CIDR allows different-sized subnets to be carved from the same block, so a large ISP can allocate a /28 (16 addresses) to a small office and a /22 (1024 addresses) to a large enterprise from the same pool, minimising waste.
- Route aggregation (supernetting): Multiple contiguous smaller blocks (e.g. four /24s) can be summarised into one larger route (a /22) in routing tables, reducing the size of global BGP routing tables.
Benefit over classful addressing: Classful addressing forced allocation in fixed chunks (/8, /16, /24) causing massive address waste (e.g., a 300-host organisation would need a full Class B of 65,534 addresses). CIDR allocates exactly the number of addresses needed and slowed IPv4 exhaustion while also shrinking core router routing tables through aggregation.
Ans: ARP (Address Resolution Protocol) maps a known IP (logical) address to its corresponding MAC (physical) address on a local network segment, since Data Link layer frames need MAC addresses for delivery.
Workflow: (1) Host A checks its local ARP cache for the MAC of target IP; if absent, (2) A broadcasts an ARP Request frame (destination MAC = FF:FF:FF:FF:FF:FF) containing B's IP address to the whole LAN; (3) all hosts receive it but only host B, recognising its own IP, replies; (4) B sends a unicast ARP Reply containing its MAC address directly to A; (5) A caches this mapping (with a timeout) in its ARP table for future use, avoiding repeated broadcasts.
Ans: RARP, BOOTP, and DHCP are protocols that assist a host in obtaining IP configuration, evolving from RARP's minimal function to DHCP's fully automated configuration.
| Protocol | Function | Limitation / Improvement |
|---|---|---|
| RARP (Reverse ARP) | Diskless workstation broadcasts its known MAC address to get its IP address from a RARP server | Requires a RARP server on every physical segment; provides only the IP, no subnet mask/gateway/DNS; operates at Data Link layer (needs new server per LAN) |
| BOOTP (Bootstrap Protocol) | UDP/IP-based protocol providing IP address, subnet mask, gateway, and boot file location to diskless hosts at startup | Works across routers (uses UDP/IP), but configuration is static — mappings manually configured, no automatic lease/renewal |
| DHCP (Dynamic Host Config Protocol) | Fully automatic, dynamic IP allocation with a lease time; also supplies subnet mask, default gateway, DNS servers | Superset of BOOTP (backward compatible); supports dynamic pools, lease renewal, and reclaiming unused addresses |
DHCP operates via the well-known DORA sequence: Discover (client broadcasts) → Offer (server proposes an IP) → Request (client requests that IP) → Acknowledge (server confirms the lease), making it the modern standard for automatic network configuration.
Ans: In Distance Vector Routing (e.g. RIP), each router maintains a vector of distances (hop counts) to every known destination and periodically shares this entire table with its directly connected neighbours only ("routing by rumour"), using the Bellman-Ford idea: D_x(y) = min_v { c(x,v) + D_v(y) }.
Count-to-Infinity problem: If link B–C fails, B initially sets its distance to C as infinite. But if A still (incorrectly, from stale info) advertises "I can reach C in 2 hops" (via B), B updates its own table to "reach C via A in 3 hops", A then updates to 4 hops via B, and so on — the two routers repeatedly increment the hop count toward infinity before converging, causing slow convergence and routing loops.
Solutions: Split Horizon (never advertise a route back to the neighbour it was learned from), Split Horizon with Poison Reverse (explicitly advertise that route as infinite/unreachable back to that neighbour), and setting a low maximum hop count (RIP uses 16 = infinity) to bound the problem.
Ans: Link State Routing (e.g. OSPF) requires every router to know the complete network topology: each router floods "link-state advertisements" (its ID and the cost to each directly connected neighbour) to all other routers, so every router independently builds an identical topology graph and computes shortest paths using Dijkstra's algorithm.
Steps performed by each router: (1) Discover neighbours and measure link cost (HELLO protocol); (2) build a Link State Packet (LSP) describing its neighbours and costs; (3) flood the LSP reliably to all routers in the area; (4) each router uses received LSPs to construct the full topology graph; (5) run Dijkstra locally from itself as source to compute the shortest-path tree, from which the forwarding table is derived. Because every router computes routes independently from full topology knowledge (rather than second-hand distance vectors), link-state routing converges faster and avoids the count-to-infinity problem, at the cost of higher memory/CPU and flooding overhead.
Ans: ICMP (Internet Control Message Protocol) is a Network-layer companion protocol to IP used to report errors and exchange diagnostic/control information (it does not carry user data); ICMP messages are themselves encapsulated inside IP packets.
| Message Type | Purpose |
|---|---|
| Echo Request / Echo Reply | Used by Ping to test reachability and measure round-trip time |
| Destination Unreachable | Router/host cannot deliver the packet (network, host, port, or protocol unreachable) |
| Time Exceeded | TTL reached 0 before arrival — used by Traceroute |
| Redirect | Informs host of a better next-hop route |
| Source Quench | (Legacy) requests sender to slow down due to congestion |
Ping sends ICMP Echo Request packets to a target; each Echo Reply confirms reachability and lets the sender compute round-trip time and packet loss.
Traceroute discovers the router path by sending packets with progressively increasing TTL (1, 2, 3, ...). Each router that decrements TTL to 0 discards the packet and returns an ICMP Time Exceeded message identifying itself; by incrementing TTL one hop at a time, traceroute reveals every intermediate router until the destination finally responds (or returns Port/Destination Unreachable for UDP-based traceroute), reconstructing the full path hop-by-hop.
Ans: TCP establishes a reliable, full-duplex connection using a 3-way handshake before any application data flows, so both ends agree on initial sequence numbers.
- Step 1 (SYN): Client sends a segment with the SYN flag set and an initial sequence number x, moving to the SYN_SENT state.
- Step 2 (SYN+ACK): Server, in LISTEN state, replies with SYN and ACK flags set, its own initial sequence number y, and acknowledgement number x+1, moving to SYN_RCVD.
- Step 3 (ACK): Client acknowledges with ACK flag and acknowledgement number y+1; both sides now move to ESTABLISHED and data transfer can begin.
This handshake synchronizes sequence numbers in both directions and confirms both endpoints are alive and willing to communicate, forming the basis of TCP's connection-oriented reliability.
Ans: TCP connection termination uses a 4-way handshake because TCP is full-duplex — each direction of the connection must be closed independently.
- FIN (client→server): Client has no more data; sends FIN, moves to FIN_WAIT_1.
- ACK (server→client): Server acknowledges the FIN; client moves to FIN_WAIT_2. Server can still send remaining data.
- FIN (server→client): When server also finishes, it sends its own FIN; client moves to TIME_WAIT.
- ACK (client→server): Client acknowledges; server moves to CLOSED. Client waits in TIME_WAIT (typically 2×MSL) before finally closing, to handle any delayed duplicate segments.
Ans: TCP uses a sliding window mechanism for flow control so a fast sender cannot overrun a slow receiver's buffer.
Mechanism: Every ACK segment carries a receive window (rwnd) field advertising how many additional bytes the receiver's buffer can currently accept. The sender may transmit unacknowledged data up to this window size without waiting for individual ACKs (unlike Stop-and-Wait). As the receiver's application reads data out of the buffer, the receiver advertises a larger window in subsequent ACKs, "sliding" the window forward; if the receiver's buffer fills up, it advertises rwnd = 0 ("zero window"), pausing the sender until space frees up (checked later via window probes). This dynamically adapts the sending rate to the receiver's actual processing capacity — distinct from congestion control, which reacts to network capacity instead.
Ans: TCP congestion control regulates how much data a sender injects into the network to avoid overwhelming routers, using a sender-side congestion window (cwnd), distinct from the receiver's flow-control window.
- Slow Start: cwnd starts at 1 MSS and doubles every RTT (cwnd += MSS per ACK) — exponential growth — until it reaches ssthresh (slow-start threshold) or a loss occurs.
- Congestion Avoidance: Once cwnd ≥ ssthresh, growth becomes additive — roughly +1 MSS per RTT (AIMD: Additive Increase) — to probe capacity cautiously.
- On packet loss (timeout): ssthresh is set to cwnd/2, and cwnd resets to 1 MSS, restarting Slow Start (Multiplicative Decrease).
- Fast Retransmit / Fast Recovery: On 3 duplicate ACKs (implying an isolated loss, network not fully congested), the sender retransmits immediately without waiting for a timeout, sets ssthresh = cwnd/2, and cwnd = ssthresh (skipping full Slow Start).
Ans: The Leaky Bucket algorithm shapes bursty traffic into a fixed-rate output stream, analogous to a bucket with a small hole: water (data) leaks out at a constant rate regardless of how fast it pours in.
Working: Incoming packets are placed in a finite-size queue (the "bucket"). The network interface removes and transmits one packet (or a fixed number of bytes) from the queue at a constant, fixed output rate, irrespective of the input burst rate. If the bucket (queue) is full when a new packet arrives, that packet is discarded (or marked). This strictly smooths bursty traffic into a uniform stream, protecting downstream routers from congestion, but it is rigid — even if the network is idle, output cannot exceed the fixed rate, so brief legitimate bursts are needlessly delayed or dropped (a limitation solved by the Token Bucket algorithm).
Ans: The Token Bucket algorithm allows bursty transmission (unlike the rigid Leaky Bucket) by permitting a host to send as fast as it wants as long as it has accumulated "tokens" (permission credits).
Working: Tokens are added to a bucket of capacity C at a fixed rate r tokens/sec. A packet (or byte) can only be transmitted if a matching token is available, in which case one token is removed; if the bucket has accumulated many tokens (during an idle period), a burst of packets can be sent back-to-back up to the bucket's capacity. If no tokens are available, the packet must wait (or is dropped/marked non-conforming). This allows the average rate to still be bounded by r while accommodating short bursts up to C — the maximum burst size for capacity C, arrival rate r, and output rate M is given by S = C / (M − r) seconds, making Token Bucket more flexible than Leaky Bucket for real, bursty network traffic.
Ans: DNS (Domain Name System) is a distributed, hierarchical, tree-structured naming system that translates human-readable domain names (e.g. www.example.com) into IP addresses.
Hierarchy: Root servers (13 logical root server clusters) know the addresses of all TLD (Top-Level Domain) servers (.com, .org, .in, etc.); each TLD server knows the authoritative name servers for domains registered under it (e.g. example.com); the authoritative server holds the actual resource records for that domain.
Resolution: A client's resolver (usually at the ISP) is queried recursively by the application; the resolver then queries root → TLD → authoritative servers iteratively (each referring it to the next level) until it obtains the final IP address, which is cached (per TTL) and returned to the client — combining a recursive query from client-to-resolver with iterative queries from resolver onward reduces load on upper-tier servers.
Ans: HTTP and HTTPS are Application-layer protocols for web communication; HTTPS is HTTP layered over TLS/SSL encryption.
| Basis | HTTP | HTTPS |
|---|---|---|
| Full form | HyperText Transfer Protocol | HTTP Secure (HTTP over TLS/SSL) |
| Port | 80 | 443 |
| Security | Plaintext — data readable by any eavesdropper | Encrypted using TLS — confidentiality, integrity, and server authentication |
| Certificate | Not required | Requires a digital certificate (issued by a CA) to establish trust |
| Performance | Slightly faster (no encryption/handshake overhead) | Marginal overhead from TLS handshake, negligible with modern session resumption/HTTP2 |
| URL scheme | http:// | https:// (padlock icon shown by browsers) |
HTTPS wraps every HTTP request/response inside a TLS record after a TLS handshake (certificate exchange, key negotiation) is completed, so intermediate routers/ISPs can see that a connection exists but cannot read the URL path, headers, or body content — essential for protecting logins, payments, and any sensitive data in transit.
Ans: FTP (File Transfer Protocol) is unusual among Application-layer protocols in that it uses two separate TCP connections — one for control (commands) and one for the actual data.
- Control Connection (Port 21): Remains open for the entire session; carries commands (USER, PASS, LIST, RETR, STOR) and server replies (status codes).
- Data Connection (Port 20 in Active mode, or negotiated port in Passive mode): Opened separately for each file transfer or directory listing, then closed once that transfer completes.
- Active mode: Server initiates the data connection back to the client (can be blocked by client-side firewalls/NAT).
- Passive mode: Client initiates both connections to the server, which is more NAT/firewall friendly and common in modern usage.
Separating control and data allows commands to be exchanged (e.g. aborting a transfer) even while a large file transfer is in progress on the data channel.
Ans: Email delivery uses different protocols for sending versus retrieving mail.
| Protocol | Role | Port | Key Characteristic |
|---|---|---|---|
| SMTP (Simple Mail Transfer Protocol) | Sends mail from client → mail server, and relays server → server | 25 (relay), 587 (submission) | Push protocol; only used to send/relay, not to read mail |
| POP3 (Post Office Protocol v3) | Retrieves mail from server to a single client | 110 (995 secure) | Downloads and typically deletes mail from server; simple, no server-side folder sync |
| IMAP (Internet Message Access Protocol) | Retrieves and manages mail while keeping it on the server | 143 (993 secure) | Mail stays on server; supports folders, flags, and multi-device synchronization |
A typical flow: sender's mail client uses SMTP to push a message to its outgoing mail server, which relays it (via further SMTP hops, possibly through MX-record lookups) to the recipient's mail server; the recipient's client then uses POP3 (download-and-delete, single-device) or IMAP (server-synced, multi-device) to fetch the message from the mailbox.
Ans: Network devices operate at different OSI layers and provide progressively more intelligent traffic handling.
| Device | OSI Layer | Function |
|---|---|---|
| Hub | Physical (L1) | Simply repeats/broadcasts incoming electrical signal to all ports; no addressing intelligence, creates one large collision domain |
| Switch | Data Link (L2) | Forwards frames based on learned MAC address table; each port is a separate collision domain, reduces unnecessary traffic vs a hub |
| Bridge | Data Link (L2) | Connects two LAN segments, filters traffic by MAC address to reduce collision domain size (conceptually a 2-port switch) |
| Router | Network (L3) | Forwards packets between different networks based on IP address, using a routing table; separates broadcast domains |
| Gateway | All layers (up to Application) | Connects networks using different protocol stacks entirely (e.g. converts between different application protocols), performing protocol translation |
Overall intelligence increases with layer: a Hub is "dumb" broadcast repetition, a Switch/Bridge make forwarding decisions using MAC addresses, a Router makes decisions using IP addresses and can connect dissimilar networks, and a Gateway can translate between entirely different protocol stacks (e.g. an email gateway between SMTP and a proprietary messaging system).
Ans: IPv6 uses 128-bit addresses and a simplified, fixed 40-byte header (versus IPv4's variable 20-60 byte header) to speed up router processing.
| Field | Size | Purpose |
|---|---|---|
| Version | 4 bits | Always 6 |
| Traffic Class | 8 bits | QoS / DSCP marking (like IPv4 ToS) |
| Flow Label | 20 bits | Identifies packets belonging to the same flow for special handling |
| Payload Length | 16 bits | Length of data following the header |
| Next Header | 8 bits | Identifies the following extension header or upper-layer protocol (replaces IPv4's Protocol + Options) |
| Hop Limit | 8 bits | Equivalent to IPv4's TTL |
| Source / Destination Address | 128 bits each | Vastly larger address space (2^128) |
Benefits over IPv4: (1) Enormous address space (2^128 vs 2^32) solving exhaustion; (2) simplified fixed header speeds up router processing (no header checksum, no in-network fragmentation — routers no longer fragment, source must use Path MTU Discovery); (3) built-in support for auto-configuration (SLAAC) and IPsec; (4) extension headers (instead of IPv4 options) keep the base header simple while allowing optional features; (5) native multicast/anycast support, eliminating the need for broadcast.
Ans: IEEE 802.11 defines the architecture for Wireless LANs, built around the concept of a Basic Service Set.
- Station (STA): Any device with a wireless network interface.
- Access Point (AP): Bridges wireless stations to the wired network; base station of infrastructure mode.
- BSS (Basic Service Set): A group of stations controlled by one AP (infrastructure BSS) or communicating directly (Independent BSS / ad-hoc).
- DS (Distribution System): The backbone (usually wired Ethernet) connecting multiple APs.
- ESS (Extended Service Set): Multiple BSSs connected via a DS, sharing the same SSID, enabling roaming between APs.
Ans: Bluetooth (IEEE 802.15.1) is a short-range wireless technology organised around small ad-hoc networks called piconets.
- Piconet: A small network of up to 8 active devices — 1 master and up to 7 slaves — all synchronized to the master's clock and frequency-hopping sequence. The master controls channel access and timing for all slaves.
- Scatternet: Formed when a device participates in more than one piconet simultaneously (as a slave in one and master or slave in another), interconnecting multiple piconets into a larger, ad-hoc mesh-like network, extending coverage beyond a single piconet's range.
Ans: NAT (Network Address Translation) allows multiple devices on a private network to share a single public IP address when accessing the Internet, conserving scarce public IPv4 addresses.
NAT: Translates a private source IP address (e.g. 10.0.0.2) into the router's public IP (203.0.113.5) in outgoing packets, and reverses the mapping for return traffic, using a translation table.
PAT (Port Address Translation, "NAT overload"): Since one public IP alone cannot distinguish multiple internal hosts, PAT additionally rewrites the source port number for each connection, so the router's translation table maps (private-IP, private-port) ↔ (public-IP, unique-public-port). This lets hundreds of internal hosts share one public IP simultaneously, which is why PAT is the mechanism actually used in almost every home/office router today.
Ans: Cryptography secures data using either a shared secret key (symmetric) or a mathematically linked key pair (asymmetric).
| Basis | Symmetric Cryptography | Asymmetric Cryptography |
|---|---|---|
| Keys used | Single shared secret key for both encryption and decryption | Key pair — public key (encrypt/verify) and private key (decrypt/sign) |
| Speed | Fast, low computational overhead | Much slower, computationally intensive (large modular exponentiations) |
| Key distribution | Hard — the secret key itself must be shared securely beforehand | Easy — public key can be freely distributed; private key never leaves owner |
| Key count (n users) | n(n−1)/2 keys needed for pairwise secure communication | Only 2n keys (one pair per user) |
| Examples | AES, DES, 3DES, RC4 | RSA, ECC, Diffie-Hellman |
| Typical use | Bulk data encryption (actual payload) | Key exchange, digital signatures, certificates |
In practice, protocols like TLS use a hybrid approach: asymmetric cryptography securely negotiates/exchanges a temporary symmetric session key during the handshake, then fast symmetric encryption (e.g. AES) protects the bulk of the actual data — combining asymmetric key-management convenience with symmetric encryption speed.
Ans: RSA is an asymmetric-key algorithm whose security rests on the practical difficulty of factoring the product of two large primes.
Why it is secure: Given only the public key (e, n), an attacker would need to factor n back into p and q to derive phi(n) and hence the private key d — for sufficiently large primes (2048+ bits) this factorization is computationally infeasible with current classical computers, even though multiplying p×q to get n was trivial. RSA is also used for digital signatures (sign with private key: S = M^d mod n; verify with public key: M = S^e mod n), providing authentication and non-repudiation in addition to confidentiality.
Ans: A firewall enforces a security policy by controlling traffic between a trusted internal network and an untrusted external network; different types inspect traffic at different depths.
| Type | OSI Layer | Inspection Basis | Limitation |
|---|---|---|---|
| Packet Filtering Firewall | Network/Transport | Static rules on source/destination IP, port, protocol per packet, independently | No memory of connection state; vulnerable to spoofing and cannot detect application-layer attacks |
| Stateful Inspection Firewall | Network/Transport | Maintains a connection-state table; only allows packets matching an established, legitimate session | Higher resource usage than packet filters; still limited application-layer visibility |
| Proxy (Application-level) Firewall | Application | Terminates the client connection itself and opens a new connection to the destination on the client's behalf, fully inspecting application data (e.g. HTTP content) | Highest overhead/latency; needs a separate proxy per application protocol |
Modern deployments typically layer these: stateful packet filtering at the network perimeter for speed, combined with application-layer proxies/deep packet inspection for sensitive services (e.g. web application firewalls), balancing performance against depth of inspection.
Ans: Quality of Service (QoS) refers to a network's ability to provide differentiated, predictable performance guarantees for different traffic types (e.g. prioritising live video call packets over a background file download).
| QoS Parameter | Meaning | Sensitive Applications |
|---|---|---|
| Bandwidth (Throughput) | Data rate available to a flow | File transfer, video streaming |
| Delay (Latency) | Time for a packet to travel from source to destination | Interactive voice/video calls, gaming |
| Jitter | Variation in packet delay | VoIP, live video (needs jitter buffers) |
| Packet Loss | Fraction of packets that fail to arrive | All, especially real-time streams (no time to retransmit) |
Techniques:
- Traffic Shaping/Policing: Leaky Bucket / Token Bucket to smooth or bound traffic to agreed rates.
- Scheduling: Priority Queuing, Weighted Fair Queuing (WFQ) to give preferential service to high-priority flows.
- Admission Control: Reject/renegotiate new flows if resources cannot meet their requirements.
- DiffServ / IntServ: DiffServ marks packets with a per-hop-behaviour class (DSCP field); IntServ (RSVP) reserves resources end-to-end per flow.
Ans: A socket is the Application layer's programming abstraction for a network communication endpoint, uniquely identified by the tuple (IP address, Port number, Protocol).
- IP Address: Identifies the host on the network (Network layer address).
- Port Number: A 16-bit number (0-65535) identifying the specific process/application on that host (e.g. port 80 for HTTP, port 443 for HTTPS); well-known ports (0-1023) are reserved for standard services.
- Socket API: The set of system calls (originating from Berkeley/BSD sockets) that let applications create and use sockets over TCP (stream, connection-oriented) or UDP (datagram, connectionless).
UDP sockets use SOCK_DGRAM instead, and skip connect()/listen()/accept() — data is exchanged directly using sendto()/recvfrom() since UDP is connectionless.
Group C — Long / Numerical Questions (15 Marks Each)
Part (a): CRC Calculation
Data M = 1101011011 (10 bits). Generator G(x) = x^4+x+1 → bit pattern 10011 (5 bits, so degree r = 4). Append 4 zero bits to M and perform modulo-2 (XOR) division by G:
Verification: dividing the full transmitted codeword 11010110111110 by G = 10011 gives remainder 0000, confirming the CRC is correct (the receiver performs exactly this check — a non-zero remainder signals a transmission error).
Part (b): Sliding Window Protocol Efficiency
Let Tt = transmission time, Tp = propagation delay, a = Tp/Tt, and m = sequence number field width.
| Protocol | Window Size | Efficiency | Remark |
|---|---|---|---|
| Stop-and-Wait | 1 | 1/(1+2a) | Sender idle after every frame; very poor for large a (e.g. satellite links) |
| Go-Back-N | 2^m - 1 | min(1, N/(1+2a)) | Pipelines frames; one lost frame forces resending the whole window (bandwidth waste on lossy links) |
| Selective Repeat | 2^(m-1) | min(1, N/(1+2a)) with smaller N | Only the lost frame is retransmitted; most bandwidth-efficient but needs more receiver buffering/logic |
When window size N ≥ 1+2a, the sender never has to pause and efficiency approaches 100%. Go-Back-N and Selective Repeat both pipeline frames to overcome Stop-and-Wait's idle-time problem, but Selective Repeat degrades more gracefully under errors since it avoids needless retransmission of already-correctly-received frames.
Part (a): Subnetting 192.168.1.0/24 into 4 equal subnets
To create 4 equal subnets, borrow n host bits where 2^n ≥ 4 → n = 2. New prefix = /24 + 2 = /26.
1. Subnet mask: /26 → 255.255.255.192 (last octet = 11000000).
2. Block size = 2^(32-26) = 2^6 = 64 addresses per subnet.
| Subnet | Network Address | Usable Host Range | Broadcast Address |
|---|---|---|---|
| Subnet 1 | 192.168.1.0 | 192.168.1.1 – 192.168.1.62 | 192.168.1.63 |
| Subnet 2 | 192.168.1.64 | 192.168.1.65 – 192.168.1.126 | 192.168.1.127 |
| Subnet 3 | 192.168.1.128 | 192.168.1.129 – 192.168.1.190 | 192.168.1.191 |
| Subnet 4 | 192.168.1.192 | 192.168.1.193 – 192.168.1.254 | 192.168.1.255 |
Verification: the four blocks (0-63, 64-127, 128-191, 192-255) exactly partition the original 256 addresses of the /24 with no overlap and no gap; each subnet gives 64−2 = 62 usable hosts after excluding the network and broadcast address.
Part (b): CIDR Advantages
- Efficient address allocation: Blocks are sized to actual need (e.g. /26 for 62 hosts) instead of wasteful fixed classful sizes (/24 = 254 hosts minimum), slowing IPv4 exhaustion.
- Route aggregation (supernetting): Multiple contiguous smaller blocks can be summarised into a single, larger routing table entry, reducing the size of core/BGP routing tables and speeding up lookups.
- VLSM support: Different subnets within the same organisation can have different sizes matched to their host counts, unlike classful addressing.
- Simplified, class-independent design: Removes the rigid class A/B/C boundary, giving ISPs and administrators full flexibility in prefix length choice.
Part (a): Dijkstra's Shortest Path from A
Since the exact edge weights are not reproduced in this extracted question, a representative 6-node weighted graph (A–F) is used to fully demonstrate the algorithm, with edges: A-B=4, A-C=2, B-C=1, B-D=5, C-D=8, C-E=10, D-E=2, D-F=6, E-F=3.
| Step | Vertex Selected | dist[A] | dist[B] | dist[C] | dist[D] | dist[E] | dist[F] |
|---|---|---|---|---|---|---|---|
| 0 (init) | — | 0 | ∞ | ∞ | ∞ | ∞ | ∞ |
| 1 | A (0) | 0 | 4 | 2 | ∞ | ∞ | ∞ |
| 2 | C (2) | 0 | 3 (via C) | 2 | 10 | 12 | ∞ |
| 3 | B (3) | 0 | 3 | 2 | 8 (via B) | 12 | ∞ |
| 4 | D (8) | 0 | 3 | 2 | 8 | 10 (via D) | 14 |
| 5 | E (10) | 0 | 3 | 2 | 8 | 10 | 13 (via E) |
| 6 | F (13) | All vertices settled | |||||
Final shortest distances from A: A=0, C=2, B=3, D=8, E=10, F=13, with shortest-path tree edges A-C, C-B, B-D, D-E, E-F (each relaxation step only updates a distance when a shorter path is found, verified consistent since every non-source node's final distance equals its parent's distance plus the connecting edge weight).
Part (b): Distance Vector vs Link State Routing
| Basis | Distance Vector | Link State |
|---|---|---|
| Information shared | Entire distance table, shared only with neighbours | Own link costs only, flooded to all routers in the area |
| Topology knowledge | Only knows distance to destinations, not full topology | Every router builds the complete network topology |
| Algorithm | Distributed Bellman-Ford | Dijkstra's shortest path (run locally by each router) |
| Convergence | Slow; prone to count-to-infinity / routing loops | Fast; loop-free by construction |
| Overhead | Lower CPU/memory, but slower convergence | Higher CPU/memory (full topology + Dijkstra), but converges quickly |
| Example protocol | RIP | OSPF, IS-IS |
Part (a): TCP Congestion Control Algorithms
- Slow Start: cwnd initialised to 1 MSS; for every ACK received, cwnd increases by 1 MSS, which doubles cwnd every RTT (exponential growth) — a deliberately fast ramp-up from a cold start. Continues until cwnd reaches ssthresh or a loss is detected.
- Congestion Avoidance: Once cwnd ≥ ssthresh, growth switches to additive: cwnd increases by roughly 1 MSS per RTT (approximated as +MSS×MSS/cwnd per ACK), cautiously probing for more available capacity — the "Additive Increase" half of AIMD.
- Fast Retransmit: On receiving 3 duplicate ACKs (a strong signal that a single segment was lost but later segments are arriving fine, i.e. no full congestion collapse), the sender retransmits the missing segment immediately without waiting for the retransmission timer to expire.
- Fast Recovery: After fast retransmit, instead of dropping cwnd all the way to 1 MSS (as on a timeout), ssthresh is set to cwnd/2 and cwnd is set to ssthresh (+3 MSS for the duplicate ACKs already received), resuming congestion avoidance directly — avoiding an unnecessary return to slow start.
- Timeout (severe loss): ssthresh = cwnd/2, cwnd resets to 1 MSS, and Slow Start restarts from scratch ("Multiplicative Decrease").
Part (b): Congestion Window Graph
The graph shows cwnd doubling every round during slow start (exponential curve) up to ssthresh, then growing linearly (~+1 MSS/RTT) during congestion avoidance (a classic "sawtooth" pattern seen repeatedly over the connection's life), with a sharp halving (not a full reset to 1) followed by linear growth when loss is detected via duplicate ACKs (fast recovery) — versus a full drop to cwnd=1 and restart of slow start after a timeout.
Part (a): RSA Numerical Example (p=61, q=53, e=17)
This confirms the key pair is mathematically consistent: encrypting with the public key (17, 3233) and decrypting with the private key (2753, 3233) recovers the exact original plaintext, and the security relies on the fact that recovering d from the public (e, n) alone requires factoring n = 3233 back into 61 × 53, which becomes computationally infeasible for realistic (2048-bit+) primes.
Part (b): Digital Signatures and SSL/TLS Handshake
Digital Signature: The sender computes a hash of the message, then encrypts the hash with their private key (S = Hash(M)^d mod n) to produce a signature. The receiver decrypts the signature with the sender's public key and compares it against an independently computed hash of the received message; a match proves authenticity (only the private-key holder could have produced it) and integrity (any tampering changes the hash), and non-repudiation (the sender cannot later deny signing it).
SSL/TLS Handshake (simplified):
- ClientHello: Client sends supported TLS versions, cipher suites, and a random nonce.
- ServerHello + Certificate: Server responds with chosen cipher suite, its own nonce, and its digital certificate (containing its public key, signed by a trusted CA).
- Key Exchange: Client verifies the certificate against trusted CAs, then generates a pre-master secret, encrypts it with the server's public key (or uses Diffie-Hellman) and sends it over.
- Session Keys Derived: Both sides independently derive the same symmetric session keys from the pre-master secret and exchanged nonces.
- Finished: Both sides send a Finished message (MAC-protected) to confirm the handshake succeeded; all further application data is encrypted using the fast symmetric session key (a hybrid cryptosystem — asymmetric for key exchange, symmetric for bulk data).
Part (a): 7-bit Hamming Code for data 1011
4 data bits d1d2d3d4 = 1,0,1,1 need 3 parity bits (r) satisfying 2^r ≥ m+r+1 → r=3 (2^3=8 ≥ 4+3+1=8). Parity bits p1,p2,p4 are placed at positions 1,2,4; data bits occupy positions 3,5,6,7.
| Position | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|
| Bit | p1 | p2 | d1=1 | p4 | d2=0 | d3=1 | d4=1 |
Part (b): Error Detection and Correction (3rd bit flipped)
Transmitted code: 0 1 1 0 0 1 1. Bit at position 3 (originally d1=1) is flipped to 0 during transmission, so the received code is: 0 1 0 0 0 1 1.
The syndrome value 3 directly points to position 3 as the erroneous bit. The receiver flips position 3 back (0 → 1), recovering the original transmitted code 0110011, from which the original data bits (positions 3,5,6,7) = 1,0,1,1 are correctly extracted — demonstrating Hamming code's single-bit error correction capability without needing retransmission.
Part (a): CSMA/CD Timing Constraint
For a transmitting station to reliably detect a collision, it must still be transmitting when the collision signal (from the farthest station) propagates back to it. This gives the constraint:
If a frame is transmitted in less time than 2*T_prop, the sender could finish transmitting and assume success before a collision signal (created near the far end of the cable, just as the frame was arriving there) has time to propagate back — the sender would never detect it. This is why Ethernet mandates a minimum frame size (64 bytes for classic 10/100 Mbps Ethernet) for a given cable length/data rate.
Part (b): Minimum Frame Size for 1 Gbps Ethernet over 1 km
Assume signal propagation speed v ≈ 2 × 10^8 m/s (typical for copper/fiber, about 2/3 the speed of light).
Result: for a 1 Gbps link over a 1 km span, the minimum Ethernet frame size must be at least 10,000 bits (1250 bytes) — dramatically larger than the 64-byte minimum used at 10 Mbps, which is exactly why Gigabit Ethernet over shared/half-duplex media required "carrier extension" padding, and why virtually all modern Gigabit+ Ethernet instead runs full-duplex (switched, point-to-point), making CSMA/CD's collision-detection constraint obsolete in practice.
Part (a): Subnetting and Supernetting with Numerical Examples
Subnetting divides one large network into smaller sub-networks by extending the network prefix (borrowing host bits) — e.g. splitting 192.168.1.0/24 into four /26 subnets of 64 addresses each (see worked example in Q2), used when an organisation needs to segment a large block into smaller, isolated broadcast domains.
Supernetting (Route Aggregation) is the reverse: combining multiple contiguous smaller network blocks into a single larger block with a shorter prefix, so they can be advertised as one routing table entry — used by ISPs to keep backbone routing tables small.
Part (b): Aggregating 4 Class C Networks into a Single CIDR Block
Given: 200.10.0.0/24, 200.10.1.0/24, 200.10.2.0/24, 200.10.3.0/24.
Verification: the four original /24 blocks (200.10.0.x, .1.x, .2.x, .3.x) are contiguous and power-of-2 aligned (starting at a multiple of 4 in the third octet), so they aggregate exactly and losslessly into 200.10.0.0/22 with no address left out and no overlap with adjacent blocks (e.g. 200.10.4.0/24 remains outside this supernet) — this route summarisation lets a single BGP/OSPF advertisement replace 4 separate ones.
Part (a): Distance Vector Routing — Bellman-Ford Algorithm
Each router x maintains a distance vector D_x giving its current best-known distance to every destination. It periodically exchanges this entire vector with directly connected neighbours only, and updates using the Bellman-Ford relation:
This is a fully distributed, asynchronous, iterative algorithm — no router needs global topology knowledge, only what its immediate neighbours tell it, which is computationally cheap but slow to converge and prone to routing loops during transients.
Part (b): Count-to-Infinity Problem, Split Horizon, Poison Reverse
Consider a chain A—B—C where the link B–C fails. B correctly sets D_B(C)=∞. But if A still advertises its stale route "D_A(C)=2 (via B)" before learning of the failure, B (seeing a route to C via A) updates D_B(C) = c(B,A)+D_A(C) = 1+2 = 3. B re-advertises this to A, which now updates D_A(C) = 1+3 = 4, and so on — both routers keep incrementing the hop count toward infinity in small steps, taking many exchange rounds to finally stabilize (RIP defines 16 as "infinity" to bound this).
- Split Horizon: A router never advertises a route back to the same neighbour it learned that route from (since B learned about C via nobody else, A should never have re-advertised its route to C back toward B in the first place if it originally learned it through B).
- Split Horizon with Poison Reverse: Stronger version — instead of simply omitting the route, the router explicitly advertises that destination as unreachable (distance = ∞) back to the neighbour it was learned from, actively breaking the loop rather than passively hiding it, which converges faster.
These heuristics solve two-node loops effectively but do not fully eliminate looping in more complex topologies (3+ node loops), which is one reason link-state protocols are preferred in larger networks.
Part (a): BGP Path Vector Routing
BGP (Border Gateway Protocol) is the exterior routing protocol that connects autonomous systems (AS) across the Internet. Unlike distance vector (which shares only a cost) or link state (which floods full topology), BGP is a Path Vector protocol: each route advertisement carries the complete ordered list of AS numbers (the "AS-PATH") that must be traversed to reach the destination, not just a metric.
- A BGP router advertises reachable prefixes to its peers along with the AS-PATH attribute (its own AS number prepended to the path it received).
- Loop prevention is trivial and robust: if a router sees its own AS number already present in an incoming AS-PATH, it rejects that route outright (avoids routing loops without needing complex distance computations).
- Route selection uses policy (not just shortest path) — preferring routes based on local preference, AS-PATH length, origin type, and other administratively configured attributes, allowing ISPs to enforce business/peering agreements rather than pure cost minimization.
- BGP runs over a reliable TCP connection (port 179) between peers and only sends incremental updates, not periodic full-table dumps.
Part (b): IGP (RIP, OSPF) vs EGP (BGP)
| Basis | Interior Gateway Protocol (RIP/OSPF) | Exterior Gateway Protocol (BGP) |
|---|---|---|
| Scope | Routes within a single Autonomous System (AS) | Routes between different Autonomous Systems (the Internet backbone) |
| Goal | Find the technically shortest/fastest path (metric-based) | Enforce administrative/business policy, not just shortest path |
| Algorithm type | Distance Vector (RIP) or Link State (OSPF) | Path Vector |
| Convergence speed | Fast (seconds, small trusted network) | Slower (large scale, policy-based decisions, dampening) |
| Trust model | All routers within one organisation's control | Routers belong to different, mutually untrusting organisations — must be policy-driven and loop-safe |
| Table size | Small (one organisation's network) | Very large (entire global Internet routing table, 900k+ prefixes) |
Part (a): IPv4 Header Fields
| Field | Size | Purpose |
|---|---|---|
| Version | 4 bits | IP version (4) |
| IHL | 4 bits | Header length in 32-bit words (min 5 = 20 bytes) |
| Type of Service (DSCP/ECN) | 8 bits | Priority/QoS marking |
| Total Length | 16 bits | Entire packet size (header+data) in bytes, max 65535 |
| Identification | 16 bits | Uniquely identifies fragments of the same original packet |
| Flags | 3 bits | DF (Don't Fragment), MF (More Fragments) |
| Fragment Offset | 13 bits | Position of this fragment (in 8-byte units) within the original packet |
| TTL | 8 bits | Hop limit; decremented by every router, packet discarded at 0 (prevents infinite loops) |
| Protocol | 8 bits | Identifies next-layer protocol (6=TCP, 17=UDP, 1=ICMP) |
| Header Checksum | 16 bits | Error-checks the header only (recomputed at every hop since TTL changes) |
| Source / Destination Address | 32 bits each | Sender and receiver IP addresses |
| Options + Padding | variable | Optional fields (rarely used); padded to a multiple of 32 bits |
Part (b): Fragmentation and Reassembly Example
Consider an IP packet with 4000 bytes of data that must traverse a link with MTU = 1500 bytes. Usable data per fragment (excluding 20-byte header) = 1480 bytes, which must also be a multiple of 8 for the Fragment Offset field (1480 is already a multiple of 8).
| Fragment | Data Size | Identification | MF Flag | Fragment Offset (in 8-byte units) |
|---|---|---|---|---|
| 1 | 1480 bytes (bytes 0-1479) | same ID (e.g. 111) | 1 (more fragments follow) | 0 |
| 2 | 1480 bytes (bytes 1480-2959) | 111 | 1 | 1480/8 = 185 |
| 3 | 1040 bytes (bytes 2960-3999, last fragment) | 111 | 0 (last fragment) | 2960/8 = 370 |
All fragments share the same Identification field so the destination knows they belong together; the Fragment Offset tells the receiver where each fragment's data belongs in the reassembled packet; MF=1 on all but the last fragment tells the receiver more pieces are coming, while MF=0 on the final fragment signals reassembly can complete once all offsets 0 to (offset+length) are received. If any single fragment is lost, the entire original packet must be discarded and retransmitted (IP itself has no per-fragment retransmission).
Part (a): TCP Header Format Fields
| Field | Size | Purpose |
|---|---|---|
| Source / Destination Port | 16 bits each | Identifies sending/receiving application (socket endpoint) |
| Sequence Number | 32 bits | Byte-stream position of the first data byte in this segment |
| Acknowledgement Number | 32 bits | Next byte the receiver expects (valid if ACK flag set) |
| Header Length (Data Offset) | 4 bits | TCP header length in 32-bit words (accounts for options) |
| Flags (Control Bits) | SYN,ACK,FIN,RST,PSH,URG (1 bit each) | Connection control: establish (SYN), acknowledge (ACK), terminate (FIN), abort (RST), push data immediately (PSH), urgent data (URG) |
| Window Size | 16 bits | Receiver's advertised flow-control window (rwnd) |
| Checksum | 16 bits | Error-checks header + data + pseudo-header |
| Urgent Pointer | 16 bits | Offset to urgent data, valid if URG flag set |
| Options | variable | MSS, Window Scale, SACK, Timestamps, etc. |
Part (b): TCP Connection State Transition Diagram
Key states: LISTEN — server waiting for a connection request; SYN_SENT — client has sent SYN, awaiting SYN-ACK; SYN_RCVD — server received SYN, sent SYN-ACK, awaiting final ACK; ESTABLISHED — handshake complete, data transfer possible in both directions; FIN_WAIT_1/2, CLOSE_WAIT, LAST_ACK, TIME_WAIT — the various stages of the 4-way graceful termination, ending in CLOSED.
Part (a): Leaky Bucket vs Token Bucket
| Basis | Leaky Bucket | Token Bucket |
|---|---|---|
| Output rate | Strictly constant, regardless of input burstiness | Can vary — allows bursts up to bucket capacity |
| Bursty traffic | Fully smooths out bursts (rigid) | Permits controlled bursts when tokens have accumulated |
| Idle capacity | Unused output capacity during idle periods is wasted (cannot be "saved up") | Unused tokens accumulate (up to capacity C), usable for a later burst |
| Implementation | FIFO queue + constant-rate server | Token counter incremented at rate r, packet sent only if a token is available |
| Best suited for | Strict, non-negotiable rate shaping | Realistic bursty traffic (e.g. compressed video, web traffic) needing average-rate policing with flexibility |
Part (b): Maximum Burst Duration Calculation
Given: Token bucket capacity C = 1 MB, token arrival (fill) rate r = 2 MB/s, maximum transmission (output) rate M = 10 MB/s.
Result: the host can transmit at the full 10 MB/s peak rate for at most 125 milliseconds before the bucket is drained and the sending rate must fall back to the sustainable arrival rate of 2 MB/s.
Part (a): DNS Iterative vs Recursive Resolution
| Basis | Recursive Resolution | Iterative Resolution |
|---|---|---|
| Who does the work | The queried server takes full responsibility for obtaining the final answer, querying further servers itself | The queried server returns its best current answer or a referral (pointer to another server) — the client must ask again itself |
| Typical usage | Used between the client (stub resolver) and its local/ISP recursive resolver | Used between the recursive resolver and the root/TLD/authoritative servers |
| Load | Higher load on the server doing recursion (must chase down the answer) | Lower load on root/TLD servers — they just redirect, not resolve |
| Caching benefit | Recursive resolver caches full answers for reuse by many clients | Each referral can also be cached independently |
In practice a client sends one recursive query to its configured DNS resolver; that resolver then performs a chain of iterative queries — root → TLD → authoritative — following referrals at each step, and finally returns the complete answer to the client in a single response.
Part (b): DNS Resource Records
| Record Type | Purpose |
|---|---|
| A | Maps a hostname to an IPv4 address |
| AAAA | Maps a hostname to an IPv6 address |
| CNAME | Canonical Name — aliases one hostname to another (e.g. www → the real server name) |
| MX | Mail Exchanger — specifies the mail server(s) responsible for accepting email for the domain, with priority values |
| NS | Name Server — delegates a domain/subdomain to a specific authoritative name server |
| PTR | Pointer — used for reverse DNS lookup, mapping an IP address back to a hostname |
Part (a): HTTP 1.0 vs 1.1 vs 2.0 vs 3.0
| Version | Connection Model | Key Feature |
|---|---|---|
| HTTP/1.0 | New TCP connection per request (no reuse) | Simple but very high connection-setup overhead for pages with many objects |
| HTTP/1.1 | Persistent connections by default (Connection: keep-alive) | Pipelining allowed (rarely used in practice due to head-of-line blocking); chunked transfer encoding |
| HTTP/2.0 | Single persistent TCP connection, multiplexed streams | Binary framing, true multiplexing (parallel requests without head-of-line blocking at the HTTP layer), header compression (HPACK), server push |
| HTTP/3.0 | Runs over QUIC (UDP-based), not TCP | Eliminates TCP-level head-of-line blocking entirely, faster connection establishment (0-RTT/1-RTT), built-in TLS 1.3 encryption |
Part (b): Persistent Connections, Pipelining, Multiplexing, and QUIC
- Persistent Connections (HTTP/1.1): The same TCP connection is reused for multiple sequential requests/responses, avoiding the cost of a new TCP handshake for every object on a page.
- Pipelining (HTTP/1.1): Client sends multiple requests back-to-back without waiting for each response, but responses must still return strictly in order — one slow response blocks all later ones (head-of-line blocking), which limited real-world adoption.
- Multiplexing (HTTP/2): Multiple independent request/response "streams" share a single TCP connection simultaneously, interleaved as small frames; a slow response no longer blocks others at the HTTP layer, solving HTTP-level head-of-line blocking (though TCP-level HOL blocking on packet loss remains).
- QUIC (HTTP/3): A transport protocol built on UDP that combines connection setup and TLS encryption into a faster handshake, and multiplexes independent streams at the transport layer itself so a lost packet only stalls the one stream it belongs to — fully eliminating head-of-line blocking, which is HTTP/2's remaining weakness over TCP.
Part (a): Cryptographic Hash Functions and Digital Certificates
A cryptographic hash function maps arbitrary-length input to a fixed-length digest, with three key properties: pre-image resistance (cannot reverse hash to input), second pre-image resistance (cannot find a different input with the same hash), and collision resistance (cannot find any two inputs with the same hash).
- MD5: Produces a 128-bit digest; now considered cryptographically broken (practical collisions demonstrated) and unsuitable for security purposes, though still used for non-security checksums.
- SHA-256: Part of the SHA-2 family, produces a 256-bit digest; currently considered secure and is the standard choice for TLS certificates, blockchain, and password hashing (with salting).
A Digital Certificate (X.509 format) binds a public key to an identity (e.g. a domain name or organisation), digitally signed by a trusted Certificate Authority (CA), containing the subject's public key, validity period, issuer details, and the CA's signature over a hash of the certificate contents.
Part (b): PKI and Certificate Authority Verification
Public Key Infrastructure (PKI) is the overall system of hardware, software, policies, and roles needed to create, distribute, manage, and revoke digital certificates.
- Certificate Authority (CA): A trusted third party that verifies an applicant's identity and issues a signed certificate binding their public key to that identity.
- Chain of Trust: Certificates form a chain from a Root CA (self-signed, pre-installed as trusted in browsers/OS) → Intermediate CA → End-entity (server) certificate; a client verifies the chain by checking each certificate's signature using the issuer's public key, up to a trusted root.
- Verification steps: (1) Check the certificate's validity period, (2) verify the signature chain up to a trusted root CA, (3) check the certificate has not been revoked (via CRL or OCSP), (4) confirm the domain name matches the certificate's subject/SAN field.
- Revocation: If a private key is compromised, the CA can revoke the certificate; clients check Certificate Revocation Lists (CRL) or use the Online Certificate Status Protocol (OCSP) to detect this.
Part (a): IPsec Protocol Suite Architecture
IPsec is a suite of protocols that secures IP traffic at the Network layer, providing confidentiality, integrity, and authentication transparently to applications above it.
- AH (Authentication Header): Provides data integrity and origin authentication for the entire IP packet (including parts of the header), but no encryption — protects against tampering and spoofing, not eavesdropping.
- ESP (Encapsulating Security Payload): Provides confidentiality (encryption) as well as optional integrity/authentication of the payload — the more commonly used protocol since it covers both secrecy and integrity.
- IKE (Internet Key Exchange): Handles the negotiation of security associations (SAs) — the agreed algorithms and shared secret keys — between two IPsec endpoints, typically using Diffie-Hellman key exchange, so AH/ESP do not need manual key configuration.
Part (b): Transport Mode vs Tunnel Mode
| Basis | Transport Mode | Tunnel Mode |
|---|---|---|
| What is protected | Only the payload (transport-layer segment); original IP header stays exposed | The entire original IP packet (header + payload) is encapsulated and protected inside a new IP packet |
| Header | Original IP header retained, IPsec header inserted after it | New outer IP header added; original header hidden inside the encrypted payload |
| Typical use | End-to-end host-to-host secure communication | Site-to-site VPNs (gateway to gateway), where original source/destination addresses must remain hidden |
| Overhead | Lower (no extra IP header) | Higher (extra IP header added) |
Part (a): IEEE 802.11 MAC Layer CSMA/CA
802.11 uses CSMA/CA (not CD) because a wireless station cannot reliably transmit and simultaneously sense the medium for collisions on the same frequency. The DCF (Distributed Coordination Function) works as follows: a station wanting to transmit senses the channel; if idle for a DIFS (Distributed Inter-Frame Space) period, it picks a random backoff counter from its contention window and counts down (pausing the countdown whenever the channel becomes busy); when the counter reaches zero, it transmits. Every unicast frame must be positively acknowledged by an ACK from the receiver (sent after a shorter SIFS gap) since the sender has no other way to know whether the frame collided/was corrupted over the air.
Part (b): RTS/CTS and the Hidden/Exposed Terminal Problems
- Hidden Terminal Problem: A and C are both within range of B but out of range of each other. If A senses the channel, it finds it idle (cannot hear C) and transmits to B; if C also senses idle and transmits to B simultaneously, a collision occurs at B that neither A nor C can detect — carrier sensing alone fails.
- Exposed Terminal Problem: If B is transmitting to A, and C (in range of B but not A) wants to transmit to a distant D, C senses the channel busy (hears B) and unnecessarily refrains from transmitting, even though its transmission to D would not actually interfere with A's reception — wasting available capacity.
- RTS/CTS solution: Before sending data, the sender transmits a short RTS (Request to Send) frame; the receiver replies with CTS (Clear to Send). Both RTS and CTS carry a duration field specifying how long the upcoming data transfer will occupy the medium. Any station that hears either the RTS or the CTS sets its NAV (Network Allocation Vector) timer and defers transmission for that duration — since C hears B's CTS (even though it may not hear A's RTS), it correctly defers, solving the hidden terminal problem.
Part (a): Software Defined Networking (SDN) Architecture
SDN centralizes network intelligence into a software-based SDN Controller, which maintains a global view of the network and programs the behaviour of simple, "dumb" forwarding switches — a sharp departure from traditional networking where every router/switch independently runs its own control-plane logic (routing protocols, etc.).
Part (b): Control/Data Plane Separation, OpenFlow, and Controller
- Data Plane: The switches/routers that simply forward packets at high speed according to flow rules installed by the controller — they no longer make independent routing decisions.
- Control Plane: Centralized in the SDN Controller, which computes routing/forwarding logic for the entire network and pushes flow rules down to switches — decoupling "what to do" (control) from "doing it fast" (data forwarding).
- OpenFlow: The standard southbound protocol/API through which the controller communicates with switches — it lets the controller install, modify, and remove flow-table entries (match fields → actions) in each switch, and lets switches forward unmatched packets to the controller for a decision.
- SDN Controller: The centralized "brain" (e.g. ONOS, OpenDaylight) that runs network applications (routing, load balancing, firewalling) via a northbound API, translates their intent into OpenFlow rules, and pushes them to switches via the southbound interface — enabling centralized, programmable, vendor-independent network management.
Part (a) & (b): Complete Trace — Entering https://www.google.com in a Browser
- DNS Query: Browser checks its cache; if absent, the OS resolver sends a recursive DNS query (typically via UDP port 53) to the configured DNS server, which iteratively resolves www.google.com through root → .com TLD → Google's authoritative servers, returning an IP address (e.g. 142.250.x.x), cached per its TTL.
- ARP Resolution: To send the first IP packet, the host needs the MAC address of its default gateway (since Google's server is off-link). It checks its ARP cache; if absent, it broadcasts an ARP Request ("who has gateway IP?") and receives an ARP Reply with the gateway's MAC address.
- TCP 3-Way Handshake: The browser opens a TCP connection to the server on port 443: SYN → SYN-ACK → ACK, establishing a reliable connection with synchronized sequence numbers.
- TLS Handshake: Over the established TCP connection, a TLS handshake negotiates the cipher suite, the server presents its certificate (verified against a trusted CA), and both sides derive a shared symmetric session key (via ECDHE or similar) for encrypting subsequent traffic — securing the HTTPS session.
- HTTP GET Request: The browser sends an encrypted HTTP GET / request over the TLS-protected TCP connection; the server responds with the HTML document (status 200 OK) plus further resource references.
- IP Routing: Each IP packet is routed hop-by-hop: the local host sends it to the default gateway (using the ARP-resolved MAC), which consults its routing table to forward it toward the next router, and so on across ISP backbone routers (each decrementing TTL) until it reaches Google's edge network and finally the serving datacenter.
- Ethernet Framing: At each hop, the IP packet is wrapped in a Data Link (Ethernet, at least on the LAN segments) frame with the appropriate source/destination MAC addresses for that specific link, stripped and re-framed at every router along the path (MAC addresses are link-local, unlike IP addresses which stay constant end-to-end).
This trace illustrates the full protocol stack working together: Application (HTTP) → Security (TLS) → Transport (TCP, reliability) → Network (IP, routing, using ARP for local delivery and DNS for name resolution) → Data Link/Physical (Ethernet framing, actual bit transmission) — each layer adding its own header via encapsulation on the way down, and removing it via de-encapsulation on the way up at the receiver.
Part (a): Maximum Throughput Derivation
Let G = average number of transmission attempts (new + retransmitted) per frame time (offered load), and S = throughput (successfully transmitted frames per frame time).
Pure ALOHA — a frame collides if any other station transmits within the vulnerable period of 2 frame-times (one frame-time before and one after). Probability of zero other arrivals in 2 frame-times (Poisson) = e^(-2G), so:
Slotted ALOHA — transmissions confined to slot boundaries, halving the vulnerable period to 1 frame-time:
Result: maximum throughput is 18.4% for Pure ALOHA (at G=0.5) and 36.8% for Slotted ALOHA (at G=1) — slotted ALOHA doubles the maximum achievable throughput by halving the vulnerable collision period.
Part (b): Throughput S vs Offered Load G
| G | S (Pure ALOHA) | S (Slotted ALOHA) |
|---|---|---|
| 0.1 | 0.082 | 0.090 |
| 0.5 | 0.184 (peak) | 0.303 |
| 1.0 | 0.135 | 0.368 (peak) |
| 2.0 | 0.037 | 0.271 |
| 3.0 | 0.007 | 0.149 |
Both curves rise to a peak and then decline because beyond the optimal G, increasing offered load causes more collisions than successful transmissions, reducing net throughput — an inherent instability of pure random-access schemes under overload.
Part (a): Optical Fiber Principles — TIR, Single-mode vs Multi-mode
Total Internal Reflection (TIR): An optical fiber consists of a glass core (higher refractive index n1) surrounded by a cladding (lower refractive index n2 < n1). When light traveling inside the core strikes the core-cladding boundary at an angle greater than the critical angle theta_c = sin^-1(n2/n1), it is completely reflected back into the core rather than refracting out — this principle lets light bounce along the fiber over long distances with minimal loss, effectively guiding it like a "pipe for light".
| Basis | Single-Mode Fiber (SMF) | Multi-Mode Fiber (MMF) |
|---|---|---|
| Core diameter | Very narrow (~8-10 microns) | Wider (~50-62.5 microns) |
| Light paths | Only one path (mode) — light travels nearly straight down the axis | Multiple paths/modes bounce at different angles |
| Modal dispersion | Negligible (single path) | Significant (different modes arrive at different times, spreading the pulse) |
| Distance / Bandwidth | Very long distance, very high bandwidth (backbone/long-haul) | Shorter distance, lower bandwidth (LAN/campus) |
| Cost | Higher (requires laser source, precise alignment) | Lower (can use cheaper LED sources) |
Part (b): Attenuation and Dispersion Calculation
Attenuation is expressed logarithmically in dB: Loss(dB) = 10 * log10(Pin/Pout), with typical single-mode fiber attenuation around 0.2-0.35 dB/km at 1550/1310 nm.
Dispersion limitation: Chromatic and modal dispersion cause transmitted pulses to spread in time as they travel; if pulse spreading approaches the bit period, adjacent bits smear into each other (inter-symbol interference), capping the maximum usable bit rate × distance product for a given fiber — this is why long multi-mode links are bandwidth-limited compared to single-mode, and why single-mode fiber (negligible modal dispersion) is preferred for high-speed, long-haul backbone links, with chromatic dispersion managed via dispersion-compensating fiber or operating near the fiber's zero-dispersion wavelength.
Part (a): Data Link Layer Framing Methods
| Method | Mechanism | Drawback |
|---|---|---|
| Byte/Character Count | A length field at the start of the frame tells the receiver exactly how many bytes follow | If the count field itself is corrupted, frame boundary is completely lost (no resynchronization method) — rarely used alone today |
| Byte Stuffing (Character Stuffing) | Special flag bytes (e.g. 0x7E) mark frame start/end; if the flag byte pattern appears in the data itself, an escape byte (e.g. 0x7D) is inserted before it so the receiver can distinguish real data from a frame delimiter | Adds variable, data-dependent overhead; requires byte-aligned data |
| Bit Stuffing | A specific bit pattern (e.g. 01111110, used by HDLC) marks frame boundaries; whenever 5 consecutive 1s occur in the actual data, a 0 is automatically inserted after them so the flag pattern never accidentally appears mid-frame | Slight, data-dependent overhead; works at the bit level so is protocol-independent of byte boundaries |
Part (b): Bit Stuffing on Frame 011111101111110
Rule: insert a 0 immediately after every 5 consecutive 1s encountered in the original data (regardless of what follows), so the flag pattern 01111110 can never occur naturally inside stuffed data.
At the receiver, whenever 5 consecutive 1s are seen followed by a 0, that 0 is automatically removed (destuffed) if it is not part of the actual 01111110 flag context, correctly reconstructing the original 15-bit data frame.
Part (a): SNMP Architecture (v1, v2, v3)
SNMP (Simple Network Management Protocol) lets a central manager monitor and control network devices (routers, switches, servers) through software agents running on each device.
| Version | Key Characteristics |
|---|---|
| SNMPv1 | Original version; uses simple, plaintext "community strings" (like a password) for access control — weak security; basic GET/SET/TRAP operations |
| SNMPv2 (v2c) | Adds GETBULK (efficient retrieval of large tables) and improved error handling; still uses weak community-string security (v2c = "community-based") |
| SNMPv3 | Adds robust security: authentication (verifying the message sender), encryption (privacy of data), and access control (View-based Access Control Model) — the current recommended standard |
Core components: a central Network Management Station (NMS/Manager) polls or receives unsolicited Trap messages from Agents on managed devices, using operations GET (read a value), SET (write a value), GETNEXT/GETBULK (walk a table), and TRAP (agent-initiated alert, e.g. link down).
Part (b): Management Information Base (MIB) and SMI
- MIB (Management Information Base): A structured, hierarchical (tree-like) database of manageable objects on a device (e.g. interface counters, CPU load, routing table entries), each identified by a unique Object Identifier (OID) such as 1.3.6.1.2.1.1.3.0 (a dotted path through the tree).
- SMI (Structure of Management Information): Defines the rules for naming objects in the MIB tree and specifying their data types (INTEGER, OCTET STRING, Counter, Gauge, etc.), ensuring different vendors' devices describe manageable data in a common, unambiguous format so any SNMP manager can interpret any agent's MIB.
Together, SMI provides the "grammar" and MIB provides the "dictionary" that lets SNMP managers query standardized as well as vendor-specific ("private enterprise") data from heterogeneous network devices.
Part (a): Mobile IP Architecture
Mobile IP allows a mobile device to stay reachable at a single, permanent IP address (its Home Address) even as it physically moves to different networks, without breaking ongoing higher-layer (TCP) connections.
Part (b): Home Agent, Foreign Agent, Care-of Address, Tunneling
- Home Agent (HA): A router on the mobile node's home network that maintains a record of the node's current location and intercepts packets addressed to the node's permanent home address whenever it is away.
- Foreign Agent (FA): A router on the network the mobile node is currently visiting; it registers the visiting node's presence with the Home Agent and forwards received tunneled packets to the mobile node locally.
- Care-of Address (CoA): A temporary IP address associated with the mobile node's current location on the foreign network (either the Foreign Agent's address, or a co-located address obtained by the node itself, e.g. via DHCP) — used as the tunnel endpoint.
- Tunneling: The Home Agent encapsulates each packet destined for the mobile node's home address inside a new IP packet addressed to the Care-of Address (IP-in-IP encapsulation) and sends it across the network to the Foreign Agent, which de-encapsulates it and delivers the original packet to the mobile node — this way the mobile node's permanent home address remains unchanged and usable by correspondents, hiding all the physical mobility beneath the tunnel.
Part (a): Network Security Threats
| Threat | Description |
|---|---|
| DoS (Denial of Service) | An attacker floods a target with excessive traffic or requests, exhausting its resources (bandwidth, CPU, connection table) so legitimate users cannot be served |
| DDoS (Distributed DoS) | Same goal as DoS but launched simultaneously from a large number of compromised hosts (a botnet), making the traffic volume far larger and the sources harder to block individually |
| Man-in-the-Middle (MitM) | An attacker secretly intercepts (and possibly alters) communication between two parties who believe they are communicating directly with each other, e.g. via ARP spoofing or rogue Wi-Fi access points |
| SQL Injection | An attacker inserts malicious SQL code into an application's input fields, causing the backend database to execute unintended commands — extracting, modifying, or deleting data |
Part (b): SYN Flood Attack and SYN Cookies
SYN Flood: An attacker exploits the TCP 3-way handshake by sending a large volume of SYN segments (often with spoofed source IPs) to a target server, which allocates connection state (in the SYN_RCVD state, in its backlog queue) and replies with SYN-ACK for each, waiting for the final ACK that never arrives. Once the connection backlog queue fills up with these half-open connections, the server can no longer accept genuine new connections — a classic resource-exhaustion DoS attack.
SYN Cookies defense: Instead of allocating state for each SYN, the server encodes essential connection information (a hash of source/destination IP+port, a timestamp, and a secret) into the initial sequence number of its SYN-ACK reply, without storing anything in memory. Only when the final ACK arrives (with the acknowledgement number = cookie + 1) does the server recompute and verify the cookie and, if valid, reconstruct the connection state — completely eliminating the need to hold half-open connection state for spoofed/never-completed handshakes, defeating the resource-exhaustion attack.
Part (a): P2P vs Client-Server Architecture
| Basis | Client-Server | Peer-to-Peer (P2P) |
|---|---|---|
| Roles | Fixed roles — dedicated server(s) provide resources, clients only consume | Every node (peer) can act as both client and server simultaneously |
| Scalability | Limited by server capacity; server becomes a bottleneck as clients grow | Scales naturally — each new peer adds both demand and supply capacity |
| Single point of failure | Yes — server outage takes down the whole service | No single point of failure — network degrades gracefully as peers leave |
| Management | Centralized, easier to secure/administer/update | Decentralized, harder to enforce consistent policy/security |
| Example | Web browsing (HTTP), email, database applications | BitTorrent, blockchain networks, Skype (early versions) |
Part (b): BitTorrent Protocol, DHT, and Choking Algorithm
- BitTorrent protocol: A large file is split into many fixed-size pieces; a .torrent file (or magnet link) describes the pieces (via hashes) and points to a tracker (or DHT) that helps peers discover each other; peers download different pieces from different peers in parallel and simultaneously upload pieces they already have to others ("swarming"), dramatically improving download speed and eliminating a single distribution bottleneck.
- DHT (Distributed Hash Table): A fully decentralized, distributed key-value lookup structure (e.g. Kademlia) that lets peers find other peers sharing a given file without relying on a central tracker — each peer stores routing information about a subset of other peers, and lookups are resolved by successively querying peers "closer" (in the DHT's XOR/ID-distance metric) to the target key.
- Choking Algorithm: Each peer uploads to only a limited number of other peers at a time ("unchoked" peers) to conserve its own upload bandwidth, typically favoring peers that reciprocate with good upload rates back to it ("tit-for-tat"), while periodically "optimistically unchoking" a random peer to discover potentially better trading partners — this incentivizes fair sharing and discourages free-riding (leeching without uploading).
Part (a): VLAN IEEE 802.1Q Tagging
A VLAN (Virtual LAN) logically partitions a single physical switched network into multiple separate broadcast domains, as if they were on physically separate switches, without needing separate physical hardware.
The 802.1Q tag is a 4-byte field inserted into the Ethernet frame containing a Tag Protocol Identifier (0x8100) and a 12-bit VLAN ID (supporting up to 4094 usable VLANs), allowing a switch to identify which VLAN each frame belongs to and enforce that broadcasts/traffic stay confined within that VLAN, even across multiple switches connected by a shared "trunk" link carrying multiple VLANs' traffic simultaneously.
Part (b): VLAN Configuration and Inter-VLAN Routing
- Access ports: Connect to end devices (PCs); carry traffic for exactly one VLAN, untagged from the device's perspective (the switch adds/removes the tag).
- Trunk ports: Connect switches to each other (or to a router); carry tagged traffic for multiple VLANs over a single physical link, using 802.1Q tags to distinguish which VLAN each frame belongs to.
- Inter-VLAN Routing: Since VLANs are separate broadcast/IP subnets, a Layer-3 device (router, or a Layer-3 switch) is required to route traffic between them. A common setup is "router-on-a-stick": a single physical router interface (or switch trunk port) is subdivided into logical sub-interfaces, one per VLAN, each tagged and configured with that VLAN's gateway IP, allowing the router to forward packets between VLANs despite them being logically isolated at Layer 2.
Part (a): Overlay Networks and Content Delivery Networks (CDN)
An Overlay Network is a virtual network built as a layer on top of an existing physical network, where nodes are connected by logical (virtual) links that may span multiple physical hops — enabling new topologies, routing behavior, or services (e.g. P2P overlays, VPN tunnels, SDN control overlays) without modifying the underlying physical infrastructure.
A CDN (Content Delivery Network) is a geographically distributed network of proxy/cache servers (edge servers) that store copies of content (web pages, videos, images) close to end users, reducing latency and origin-server load by serving requests from a nearby edge location rather than a single, potentially distant, origin server.
Part (b): Anycast Routing and Edge Caching Strategies
- Anycast Routing: The same IP address is announced from multiple geographically distributed locations; standard BGP/IGP routing (which naturally selects the topologically "shortest"/lowest-cost path) automatically directs each client's request to its nearest (in terms of network cost) instance of that address — used heavily by CDNs and root DNS servers to route users to the nearest edge server transparently, without any client-side configuration.
- Edge Caching strategies:
- Pull (Cache-on-demand): An edge server fetches and caches content from the origin only on the first request (cache miss), serving subsequent requests directly from cache until it expires (TTL).
- Push (Pre-positioning): Popular/predicted content is proactively pushed to edge servers ahead of demand (e.g. before a scheduled high-traffic event).
- Cache eviction policies (e.g. LRU — Least Recently Used) decide which cached objects to discard when storage is full, to keep the most popular/relevant content available at the edge.
Together, anycast gets the user's request to a nearby edge node with minimal latency, and edge caching ensures that node can usually answer immediately from local storage rather than forwarding the request all the way back to the origin server.
Part (a): Real-time Audio/Video Streaming Protocols
| Protocol | Role |
|---|---|
| RTP (Real-time Transport Protocol) | Carries the actual encoded audio/video payload over UDP, adding sequence numbers (for reordering/loss detection) and timestamps (for correct playback timing/synchronization); does not itself guarantee delivery |
| RTCP (RTP Control Protocol) | Runs alongside RTP to periodically report QoS statistics (packet loss, jitter, round-trip time) between participants, allowing senders to adapt (e.g. change codec/bitrate) based on network conditions |
| RTSP (Real-Time Streaming Protocol) | An out-of-band "remote control" protocol for streaming sessions — provides VCR-like commands (PLAY, PAUSE, SETUP, TEARDOWN) to control media delivery, typically setting up the underlying RTP session |
| HLS (HTTP Live Streaming) | Splits video into small segments (e.g. 2-10 sec chunks) described by a playlist (.m3u8) manifest, delivered over ordinary HTTP; supports adaptive bitrate streaming by offering multiple quality-level playlists and letting the client switch based on measured bandwidth |
Part (b): Jitter Buffering and Packet Loss Concealment
- Jitter: Because packets travel through a shared, best-effort network, consecutive packets arrive with varying delay (not evenly spaced as they were sent) — direct playback would cause audible/visible stutter.
- Jitter Buffer: The receiver intentionally holds incoming packets in a small buffer for a short, adaptive delay before playback, re-ordering them by their RTP timestamps and releasing them to the decoder at a smooth, constant rate — absorbing network delay variation at the cost of added end-to-end latency. Adaptive jitter buffers dynamically resize based on observed jitter (reported via RTCP) to balance latency against smoothness.
- Packet Loss Concealment (PLC): When a packet is lost or arrives too late to be useful, instead of leaving a gap (silence/frozen frame), the decoder synthesizes a plausible replacement — e.g. for audio, repeating/interpolating the previous waveform pattern; for video, using motion-compensated frame interpolation or simply repeating the last good frame — minimizing perceptible quality degradation from the loss, which is essential since RTP/UDP does not retransmit lost packets (retransmission would arrive too late for a real-time stream anyway).