CS5480: Data Communication and Networks Overall organization: - Simple internetworking - Introduction and overview of IP (internet) protocol - Design issues in datagram protocols - IPv4 datagram format - Fragmentation and Reassembly - IP addressing - Datagram forwarding --------------------------------------------------------------------------- Topic: Simple Internetworking - internet: network of networks - The Goal: ability to communicate with any other node in the network - Most important problems: - Heterogeneity - Scalability * discuss what do u mean by that - a simple example from book (fig 4.1) Network 1: Ethernet --+---+----+-- | | | H1 H2 H3 H7 | H8 | | | | -+----+---+-+- ___R3 Network2 | ____/ (Ethernet) \ __/ (Leased T1 line) R1 __R2__/ \ / +-----+ / Net 3 \ H4---+ (FDDI) +---H6 \_______/ / \ H5 H9 Connecting H1 to H8: H1 H8 +-----+ +-----+ | TCP | R1 R2 R3 | TCP | | | +---------+ +--------+ +--------+ | | | IP | | IP | | IP | | IP | | IP | | | | | | | | | | | | ETH | |ETH FDDI| |FDDI P2P| |P2P ETH| | ETH | +-----+ +---------+ +--------+ +--------+ +-----+ \_______/ \_____/ \____/ \________/ Note: different physical/link layer protocols. Note: common denominator is the IP protocol --------------------------------------------------------------------------- Topic: Introduction and overview of IP (internet) protocol IP: common Internet Protocol - nothing special about it vs IPx or others.. - except that it is completely dominant (and for an internet protocol, being universal is what counts) Delivery model: datagram (connectionless), best efforts * datagram: no connection setup, each packet carries complete destination address * best efforts --> unreliable delivery: - out of order delivery - duplicates - lost packets If you want a RELIABLE protocol -- build it on TOP of IP (e.g., TCP) Advantages of IP model: - easiest to implement - simplest routers - most flexible (``runs over anything'') - robust: each datagram is self-contained - good fit for common connectionless transports (UDP, RPC) --------------------------------------------------------------------------- Topic: Design issues in datagram services Routing: * special router nodes forward traffic toward destination network * table-driven (static or dynamic) * dynamic table maintenance via variety of internet cntl messages Datagram Lifetime: * important if adaptive or dynamic routing is used - endlessly looping datagram consumes resources - transport layer may rely on bounded datagram lifetime * need a `time to live' field for each datagram - ideally related to real time - most often based on hop counts Segmentation: * individual networks have different min/max/fixed packet sizes * routers need to segment large outgoing datagrams Reassembly: but where? * at destination: simple monotonic decrease in packet size, but... - increased overhead due to headers for extra packets - increased packet count adds arbitration, contention, and software handling overheads * at intermediate routers -- even more problems - large buffers required in routers (bad) - implicit requirement that all segments pass through same downstream routers - hence no adaptivity Error control: * datagram service does not guarantee delivery * when router discards a datagram -- tell sender (NACK!) - sender can modify its transmission strategy - still need timeouts in case packets are corrupted on wire Flow control: * without a connection, it's hard to do much * common choice: routers that are overloaded send REDUCE FLOW messages to source IP stations and routers to which they are directly connected --> BACK PRESSURE --------------------------------------------------------------------------- Topic: IPv4 datagram format (Figure 4.3) 0 4 8 16 19 31 +--------+--------+----------------+--------------------------------+ | Vers. | HLen | Type of Serv. | Packet Length (incl. header) | +--------+--------+----------------+-------+------------------------+ | Ident | Flags | Offset | +-----------------+----------------+-------+------------------------+ | TTL | Protocol | Checksum | +-----------------+----------------+--------------------------------+ | Source Address | +-------------------------------------------------------------------+ | Destination Address | +--------------------------------------------------+----------------+ | Options (variable) | Pad (variable) | +--------------------------------------------------+----------------+ | | ~ DATA ~ ~ ~ | | +-------------------------------------------------------------------+ Version : version of IP (for interoperability) HLen : length of header in 32-bit words (most often 5) TOS : type of service -- allows for priorities, -- not used often Length : length of packet (including headers) in bytes (max 65535) TTL : Time to live -- hop count before datagram nuked Protocol: Demultiplexing tag --> what transport layer gets datagram TCP = 6, UDP = 17, ICMP = 1 (see /etc/protocols) Checksum: cheap-o error detection on IP header Source Address and Destination Address: self-explanatory --------------------------------------------------------------------------- Topic: Fragmentation and Reassembly [This is very similar to flow control issues discussed earlier.] Individual physical links have different packet size requirements: - Ethernet: min (~64 bytes) and max (~1500 bytes) - FDDI : varies depending on dynamic configuration - ATM : max PDU size, not cell size, is limit Rather than enforce a particular limit for all of IP --> adapt. Each router determines the ``MTU'' (MAXIMUM TRANSMISSION UNIT) of the networks to which it is attached. Sender transmits datagram with `arbitrarily large' length: - routers FRAGMENT packets larger than next step's MTU Implementation details of fragmentation: * IDENT field used to identify fragments from common datagram. (chosen by sender, unique to all datagrams from SRC->DST over some fairly long time span) * OFFSET field indicates the byte offset of the data in this particular fragment from the start of the datagram * FLAGS field includes bits for things like `more to come' Receiving host reassembles fragments: * when it gets them all, it uses Protocol demultiplex * if fragments don't arrive in timely fashion -- drops everything Important details to note: * each fragment is self-contained IP datagram, routed independently, etc. * each IP datagram is re-encapsulated for each physical link simple example: H1 --- R1 --- R2 --- R3 --- H8 1400 1400 512 512 512 512 376 376 show how headers look like. --------------------------------------------------------------------------- Topic: IP addressing Properties of IPv4 addresses: * globally unique (but so is Ethernet...) * hierarchical (address has some relationship to location) - addresses consist of NETWORK part and HOST part - all hosts on same network have same IP address prefix Addresses are divided into different ``classes'': * Class A addresses: - leading bit is `0' - 7 bits of network ==> 128 class A networks - 24 bits of host ==> 4 million hosts per network! * Class B addresses: - leading bits are `10' - 14 bits of network ==> 16K class B networks - 16 bits of host ==> 64K hosts per network! * Class C addresses: - leading bits are `110' - 21 bits of network ==> 4 million class C networks - 8 bits of host ==> 255 hosts per network --------------------------------------------------------------------------- Topic: Datagram Forwarding Forwarding: process of taking a packet from an input port and sending it out the correct output port, where `correct' is usually determined by a table lookup Routing: process of building up the table used above to pick the correct output port for a given packet/destination Remember, every IP address has a NETWORK portion -- route to networks. Basic forwarding algorithm: * Am I on same network as specified IP address? [Done by comparing network portion of destination IP address with network portion of our network interface(s).] - Yes: Packet can be directly delivered over local physical network (should be able to map IP address to link-layer address - see below) - No : Need to forward packet to next router along path. Look in FORWARDING TABLE for `best' router to use, and forward packet directly to that router. --> note that this is different than with a bridge, where the existence of the bridge is transparent. Hosts (and routers) direct packets to routers, routers DO NOT simply yank packets off of network. Simplistic view of routing table: Network Number | Next Hop --------------------------- 128.42. | R4 129.37. | R4 64. | R1 67. | R4 ... | ... Default | R1 Compare network number with entries in routing table: if present, forward packet to specified router, else, forward packet to default router. Hosts (as opposed to routers) usually just forward remote packets directly to a default router if the destination is not on a local physical network. Back to our favorite example... Network 1: Ethernet --+---+----+-- | | | H1 H2 H3 H7 | H8 | | | | -+----+---+-+- ___R3 Network2 | ____/ (Ethernet) \ __/ (Leased T1 line) R1 __R2__/ \ / +-----+ / Net 3 \ H4---+ (FDDI) +---H6 \_______/ / \ H5 H9 Again, let's have H1 try to send a packet to H8: - H1 checks --> is H8 on the same local network? NO! (net1 != net2) -> Forward packet to default router (R1). - R1 checks -> is H8 local to either of the networks R1 is on? NO! (net1 != net2 && net1 != net3) R1 looks up H8's network number in its routing table: - either net3 is in R1's table (and says `R2') OR default router for R1 == R2 R1 forwards packet to R2 - R2 makes similar checks, forwards packet to R3 - R3 checks --> is H8 on same local network? YES! R3 sends packet directly to H8 DONE! ---------------------------------------------------------------------------