Networks Week 2

Comp 343/443     Fall 2011, LT 412, Tuesday 4:15-6:45

Read:
    Ch 1, sections 1,2,3 and 5 (section 4 is about network programming in C; we'll skip that for now)
    Ch 2, sections 1, 2, 3, 5

Ethernet switching

forwarding tables
one entry for every node

Table-based forwarding has one significant potential weakness: if the tables are not consistent, routing loops can be created.

IP

Addresses have structure: they can be divided into the network portion (a prefix) and the host portion (the remainder).
Addresses are administratively assigned, so that all hosts on the same physical LAN can be given the same net portion.
IP in effect delivers to the destination network; that network must correspond to a physical (or logical!) LAN that can complete the delivery.
CLASSIC IP: classes A, B, C (deprecated)
class determination (and thus net/host division) was determined by the first few bits.
IP header v Ethernet header (ignore fields of IP header for now)
IP header is 20 bytes (plus options), and contains:

destination and source addresses
indication of ipv4 versus ipv6
a Time To Live (TTL) value, to prevent infinite routing loops
a field indicating what comes next in the packet
fields supporting fragmentation and reassembly.

What an IP ROUTER does
Extraction of Dest_net
Routing tables
Routing table size

This is the year (2011) that APNIC (Asia-Pacific NIC) runs out of IPv4 addresses.

Actually, IANA (Internet Assigned Numbers Authority) has already run out of blocks (at least /8 (class-A-sized) blocks):
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
(The point of the reference is that there are no /8 blocks listed as unallocated.)

IP has no broadcast (well, there is a limited form of IP broadcast, basically intended for your LAN only)

best-effort delivery: if the packet is lost (eg through router queue overflow), the IP layer is not responsible for replacing it. Nor does the IP layer handle acknowledgements.

Example of delivery through a router

IP routing algorithm:
Extract destination_network from packet, and decide if this router connects to that network

YES: local delivery; use LAN to deliver
NO: look up destination_network in forwarding table and send to the next_hop

Significance of administrative assignment : the destination_network part of each IP address represents something about the host's location.

Compare to Ethernet switch, with per-host forwarding table

A    B    C                         D    E    F
|    |    | |    |    |
+----+----+--S1-------S2------S3----+----+----+
200.0.0                                                      200.0.1

Ethernet forwarding: S2 has to maintain entries for each of A,B,C,D,E,F
IP forwarding: S2 has just two networks to maintain: 200.0.0/24 and 200.0.1/24

Goal of smaller routing tables

Two benefits to IP:

allows interconnection ("internetworking") of incompatible LANs
routing strategy is SCALABLE: works well with very large Internet

Since the mid 1990s, IP addresses have not used the old Class A/B/C mechanism. Separation into network and host portion is still done, but is now "floating". When you buy a block of IP addresses, you get the network portion, or network prefix. The length of that portion in bits is your prefix length, and is usually appended to the address prefix itself following a slash, eg
    10.0.0.0/8
    147.126.0.0/16
    19.192.0.0/10   (192 = 1100 0000)

If we don't care about the prefix, we omit it:
    "Class A's are /8 address blocks; class B's are /16"
    "It cost me $2,000/year to get a /18!"

Note that the IP protocol has not been changed, so there is no place in the IP header to specify this prefix length.

This means that routers must use some other way to divide addresses into net & host portions (typically, by keeping track of the prefix length for each prefix it is configured to know about)
This means that the routers may use different prefix lengths for the same address, at different points of the routing infrastructure.

UDP

User Datagram Protocol: simple header, no retransmission or acknowledgement features
UDP is a very simple extension to IP; it basically just adds port numbers for application-level multiplexing, and a checksum over the data.
Socket = ⟨host,port⟩; this acts like a mailbox address in that anything sent to it will be delivered to the receiving application (typically through some sort of socket handle in the underlying OS)

demo of stalkc, stalks (defer)
demo with two clients

TCP

Adds:

stream-oriented connection: no application packetization
reliability (both as to lost packets and to delivery order!)
port-number multiplexing like UDP

Also: uses sliding-windows to establish a maximum number of packets en route at any one time, per connection.
Later, TCP sliding-windows was adapted to manage congestion.

You connect TO a socket = ⟨host,port⟩ (this is actually a "listening" socket, not a "connected" socket.)
Everything sent on that connection goes to same place.
A ⟨host,port⟩ doesn't received directly; only "connected_sockets" receive data; you can only receive data from the endpoint to which you are connected. A connected socket can be represented as a "socketpair" ⟨myhost, myport, remote_host, remote_port⟩.

TCP semantics are more like "telephone" semantics, for a room with dozens of phones all answering to the same phone number (eg for telephone sales). Each remote phone's data goes to, say, 1-800-LOYOLA1, but it is routed by the phone switch to the correct phone based on what phone it came from. That way, each remote phone has its own connection.

(Actually, phone numbers are not really like routing addresses at all!)

Uses:
TCP: telnet, http/ftp
UDP: voice/video. Why?

Chapter 2

Direct links:
    Read 2.1: basic ideas
        "as a network node, a workstation runs at memory speeds, not CPU speeds"

encoding and framing:
    encoding: recognizing byte boundaries in a stream of bits
    framing: recognizing packet boundaries
    These are related, though not the same.

2.2: NRZ is the simplest encoding; we have two signal levels lo and hi, and set the signal for each bit according to 0=lo, 1=hi. We do this at a regular rate.

Problems with NRZ: idle-line detection, baseline wander and clock desynchronization. This last problem is perhaps the most fundamental: the receiver loses track in long runs of 0's or 1's and might interpret 10 bits as either 9 or 11.

NRZI: 0=no transition, 1=transition
Note that for NRZI, long runs of 1 bits do not pose a problem. Long runs of 0's still do.

Manchester and 4B/5B
Manchester encoding: adda clock pulse between each 0/1 bit. This means that the signaling rate is now double the data rate, eg 20 MHz for 10Mbps Ethernet (which does use Manchester encoding).

4b/5b: For each 4-bit "nybble" of data, we actually transmit a fixed 5-bit code, selected to have "enough" 1-bits. Specifically, each 5-bit code has at most one leading 0-bit and at most two trailing 0-bits. The result is then sent with NRZI, where runs of 1's are ok. Note that the worst-case run of 0-bits has length three. Note also that the signaling rate here is 1.25 times the data rate. 4b/5b is used in 100-Mbps Ethernet ("fast" Ethernet).

data	code
0000	11110
0001	01001
0010	10100
0011	10101
0100	01010
0101	01011
0110	01110
0111	01111
1000	10010
1001	10011
1010	10110
1011	10111
1100	11010
1101	11011
1110	11100
1111	11101
IDLE	11111
DEAD	00000
HALT	00100

Note the option for "extra" codes.

The choice of 5-bit codes is in principle arbitrary; note though that from 0100 to 1101 we simply insert a 1 in the fourth position, and in the last two we simply insert a 0 in the fourth position. The first four codes (those with the most zeroes) are highly arbitrary, though.

2.3: basics of framing (on a dedicated serial link):

Ethernet (interpacket gaps)
Character "stuffing"(as in bisynch, below)

basic packet

escape char is DLE; stuffed as prefix to ETX and DLE in data

4b/5b and special bit patterns
hdlc (typical bit-oriented)

bisync (typical byte-oriented framing)

Basic packet format is SYN SOH header STX data ETX
The ETX byte (End of TeXt) marks the end of the data. What if the data actually includes the ETX byte?
Any ETX in body is "escaped" with an extra DLE char
Any DLE in body is also escaped with an extra DLE
Like C/Java quoted strings: " and \ in body are each escaped with \

PPP

PPP uses 0x7e (0111 1110) as a start-of-frame flag, and 0x7d as an escape byte. Any data bytes of 0x7d and 0x7e are escaped. (Actually, they are transmitted as 0x7d followed by (original byte) xor 0x20).

HDLC (typical bit-oriented framing)
The special bit-pattern 0111 1110 (exactly six 1-bits in a row) is used to mark packet boundaries.
Whenever five consecutive 1-bits appear, eg 011111, a 0-bit is inserted by the sender (regardless of whether or not the next bit is also a 1). The receiver then knows that

six 1-bits in a row marks the end of the packet
when five 1-bits in a row are seen, followed by a 0-bit, the 0-bit is removed

Data:       011110 0111110    01111110
Sent as:    011110 01111100 011111010 (stuffed bits underlined)

Sonet (clock-based)

The basic SONET format is STS-1. Data is organized as a 9x90 byte grid. The 1st 3 bytes of each row (that is, first three columns) form the frame header. Frames are not addressed; SONET is a point-to-point protocol and a node sends a continous sequence of frames to each of its neighbors. When the frames reach their destination, in principle they need to be fully demultiplexed for the data to be forwarded on. In practice, there are some shortcuts to full demultiplexing.

The actual bytes sent are scrambled: data is transmitted as (frame XOR std_random_pattern). This introduces many 1-bits, on which clock resynchronization can occur, with a high degree of probability.
There are two other special columns in a frame, so the max run of data bytes is limited to ~30; this is the longest run of possible 0's

Frame synchronization check is based on first two bytes of first row expected to be 0xF628.
Frame re-synchronization procedure: if synchronization fails: search for those 0xF628 bytes at regular 810-byte spacing. After a few frames, you are "very sure" you're looking at the synchronization bytes and not at a data-byte position. Note that there is no evident byte boundary either, so you have to check for 0xF628 beginning at every bit position.

STS-3 = Three STS-1 frames, 9x270
9×87 byte payload envelope can float within physical frames
need for accuracy in sending voice bytes at 8000/sec
Basic rate of 51.84 Mbps is exactly 810 bytes/frame * 8 bits/byte * 8000 frames/sec

Classic SONET use is that each data byte represents a voice call (DS-0 line)
Packets can also be embedded in SONET frames. For this use, SONET is a link technology; packets need to be extracted at the far end of the link.
Most IP backbone traffic is carried by SONET.

STS-1	STM-0	51.84 Mbps
STS-3	STM-1	STS-3 = OC-3
STS-12	STM-4	622.08 Mbps (=12*51.84, exactly)
STS-48	STM-12

Sliding Windows ; §2.5, P&D

2.5: stop-and-wait versus sliding windows
Four stop-and-wait scenarios
                    (a) Frame/ACK
                    (b) Frame / lost ACK; Frame retransmitted
                    (c) Lost Frame, retransmitted, one ACK sent
                    (d) late ACK (arriving after Frame is retransmitted)

Either side can implement timeouts, retransmitting their previous Data or Ack if nothing new is received.
Either side can also retransmit on receipt of a duplicate (ie old) packet from the other side.
retransmit-on-timeout v. retransmit-on-duplicate
At least one side must implement timeout (otherwise a lost packet would lead to deadlock!)
At least the other side (maybe both) must then implement retransmit-on-duplicate.
Usual procedure:
    data sender: implements timeout
    data receiver: implements retransmit-on-duplicate
sorcerers' apprentice bug (both sides retransmit on duplicate)
See Disney's Fantasia, http://www.youtube.com/watch?v=XChxLGnIwCU, around T= 5:35