Week 5: Sept 24 ns/nam demo java demo stalk UDP: client, server TCP client, server, threaded server Virtual circuits (brief discussion) IP IP forwarding IP router table construction Chapter 3: switching. Read the following: 3.1.1: datagram switching (IP routing) // described class 4; skip the rest IP Spanning-tree issues limitations of bridges Limits to size: b'cast, table sizes (10^4 v. 10^6) Cannot use loop topology There is lots of debate in the networking community regarding the point at which one should convert from switching (bridging) to IP routing. IP routers are relatively slow, so there is some pressure to route instead. ===================================================================== 3.1.2: virtual circuit switching The road not taken by IP. Routers know about connections. To send a packet, it needs to be marked with a "connection ID" (traditionally called the VCI, for Virtual Circuit Identifier). The namespace for VCIs is small, and compact (eg contiguous). VCIs are *local* identifiers. IP advantages: less state info to manage router crashes and partial connection state loss are not a problem per-connection billing is very difficult VC advantages: connections can get resource guarantees smaller headers / faster throughput 3.1.3: source routing 3.3: basics of ATM: fixed cells, etc ================================================================ NOT covered on the midterm 3.3: ATM cell basics Fixed-size cells: ATM (and cell networks in general): small cells (typically 5 bytes header + 48 bytes data) virtual circuits; connection-oriented (28-bit addresses after connection is established) Switched point-to-point links; *some* rings Note ATM *mandates* no cell reordering! No physical b'cast cells: fixed size makes hardware simpler reduce store-and-forward delay reduce latency of high-priority traffic Need only 6 ms to fill a cell with voice, versus 1/8 sec for 1KB fixed length packets (a win, generally, for switching) => 1/2 of last cell is wasted, so small cells are better Forwarding delay & packet size; cut through loss of 1 cell destroys packet; need reliable medium error correction of Shacham & McKenney [1990] send N cells and then one of all N XOR'ed together allows recovery from any one lost cell 3.3.2: Skim. Segmentation/reassembly and AAL 3/4, AAL 5. SAR/AAL. AAL 1, 2, 3/4, 5 AAL 5: high-level crc; just take cells in order. Addressing: VPI/VCI VCI: local use only? 3.3.3: virtual circuits as applied to ATM store-and-forward of cells v. cut-through for packets 3.4: switching: cut-through v. store-and-forward (not done) Crossbar switch, other switching fabrics ================================================================ Chapter 4 4.1: network service models (best effort) IP addressing header fields and what they do 3.1. Internet Header Format (from RFC 791) A summary of the contents of the internet header follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example Internet Datagram Header Figure 4. TOS fragmentation TTL, protocol, checksum options basics of fragmentation/reassembly (rfc 791 again) An Example Reassembly Procedure For each datagram the buffer identifier is computed as the concatenation of the source, destination, protocol, and identification fields. If this is a whole datagram (that is both the fragment offset and the more fragments fields are zero), then any reassembly resources associated with this buffer identifier are released and the datagram is forwarded to the next step in datagram processing. If no other fragment with this buffer identifier is on hand then reassembly resources are allocated. The reassembly resources consist of a data buffer, a header buffer, a fragment block bit table, a total data length field, and a timer. The data from the fragment is placed in the data buffer according to its fragment offset and length, and bits are set in the fragment block bit table corresponding to the fragment blocks received. If this is the first fragment (that is the fragment offset is zero) this header is placed in the header buffer. If this is the last fragment ( that is the more fragments field is zero) the total data length is computed. If this fragment completes the datagram (tested by checking the bits set in the fragment block table), then the datagram is sent to the next step in datagram processing; otherwise the timer is set to the maximum of the current timer value and the value of the time to live field from this fragment; and the reassembly routine gives up control. If the timer runs out, the all reassembly resources for this buffer identifier are released. The initial setting of the timer is a lower bound on the reassembly waiting time. This is because the waiting time will be increased if the Time to Live in the arriving fragment is greater than the current timer value but will not be decreased if it is less. The maximum this timer value could reach is the maximum time to live (approximately 4.25 minutes). The current recommendation for the initial timer setting is 15 seconds. This may be changed as experience with this protocol accumulates. Note that the choice of this parameter value is related to the buffer capacity available and the data rate of the transmission medium; that is, data rate times timer value equals buffer size (e.g., 10Kb/s X 15s = 150Kb).