Download - CSCI-370/EENG-480 Computer Networks
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 1
CSCI-370/EENG-480
Computer Networks
Khurram Kazi
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 2
Major sources of the slides for this lecture
Slides from Tanenbaum’s and William Stallings’ website are used in this lecture
Interworking with TCP/IP, M9000-02, Global knowledge, training manual, (http://am.globalknowledge.com)
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 3
Changing the ordering of Topics covered in the course (sections 5.6 & 6.4) Based on some feedback from previous class, the
ordering of the topics to be covered in the course will change. For now we will concentrate on
Protocols IP TCP / UDP
IP Addressing Go through an example of the Life of a Packet in a
Network In the process we will develop a functional model of a
ROUTER.
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 4
Reference Network: For discussion purposes
Router A
Router B
Router C
Router D
Router F
Router E
LAN 1
LAN 2
Wide Area Network or Metro Area Network
Edge Router
Edge Router
Source of IP Traffic
Destination of IP Traffic (server)
Shows traffic flow
ip addr
ip addr
ip addr
ip addr
ip addr
ip addr
ip addr
ip addr
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 5
Source of IP Traffic
Application Traffic type could be FTP (file transfer) Instant messaging Secure or non-secure web access Streaming video Document sharing (similar to net meeting) Database access (across the street or across the
continent) Voice over IP
It all boils down to what protocols are used
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 6
Summarizing Features of the Protocol Functions
have a small set of functions that form basis of all protocols Encapsulation (e.g. IP packets encapsulated in Ethernet frames) fragmentation and reassembly (e.g. fragmentation of a file during
an FTP and reassembly of it at the destination) connection control (e.g. during TCP session) ordered delivery flow control error control addressing multiplexing transmission services
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 7
Demonstrate file transfer using FTP while capturing the data by Wireshark
Starting from the traffic source
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 8
PDUs (Protocol Data Units) and Fragmentation
Example: Fragmentation seen during file transfer using FTP
This can be an IP Packet
This can be a TCP component of the Packet
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 9
Fragmentation and Reassembly
Protocol exchanges data between two entities Lower-level protocols may need to break data up into smaller
blocks, called fragmentation For various reasons
Network only accepts blocks of a certain size More efficient error control & smaller retransmission units Fairer access to shared facilities Smaller buffers
Disadvantages Smaller buffers More interrupts & processing time
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 10
Starting the protocol stack analysis with The IP Protocol (RFC 791)http://www.ietf.org/rfc/rfc0791.txt?number=791
The IPv4 (Internet Protocol) header.0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Octet 1 Octet 2 Octet 3 Octet 4
Version IHL Type of Service Total Length
Identification Flags Fragment Offset
Source Address
Destination Address
Options Padding
Data (payload) portion of the datagram
1st 32 bit word
2nd 32 bit word
3rd 32 bit word
4th 32 bit word
nth 32 bit word
Time to Live Protocol Header Checksum
5th 32 bit word
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 11
IP Header Fields continued
Version (4 bits) (whether the format is of type)
currently IP v4IP v6
Internet header length (IHL) (4 bits)Is the length of header in 32 bit words, Points to the beginning of the data (payload) including optionsMinimum value for a correct header is 5
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 12
IP Header Fields continuedType of Service (8 bits) (see RFC 791 for details)
Is an indication of the abstract parameters of the Quality of Service (QoS) desired. These parameters are to be used to guide the selection of the actual service parameters when transmitting a datagram through a particular network. Several networks offer service precedence, which somehow treats high precedence traffic as more important than other traffic (generally by accepting only traffic above a certain precedence at time of high load). The major choice is a three way tradeoff between low-delay, high-reliability, and high-throughput.
Bits 0-2: Precedence. Bit 3: 0 = Normal Delay, 1 = Low Delay. Bits 4: 0 = Normal Throughput, 1 = High Throughput. Bits 5: 0 = Normal Reliability, 1 = High Reliability.Bit 6 1 = minimize monetary cost [defined in RFC 1349]
Bit 7: Reserved for Future Use. Only one of the bits [6:3] can be set to a 1
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 13
IP Header Fields continued
Total Length (16 bits) Total Length is the length of the datagram, measured
in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets. Such length of a datagram are impractical for most hosts and networks.
Since there is no “end of datagram” character/indicator, network hosts use the datagram length to figure out when the datagram ends and other network data begins.
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 14
IP Header Fields continued
Identification (16 bits)An identifying value assigned by the sender to
aid in assembling the fragments of a datagram. It is assigned by the originating host. At the source, there is one-to-one relation between datagrams and datagram identifier. As these datagrams traverse the network, they could be split. Hence this field is used by the receiving host to reassemble the original datagram.
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 15
IP Header Fields continued
Flags (3 bits)Bit 0: reserved, must be zero Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment.
Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. If the datagram cannot be routed without being
fragmented, the router will throw it away and send an error message back to the originating host.
When MF=1, it means that the datagram is one of the two or more fragments, but not the last one of the fragments. Receiving hosts use this flag along with the fragment offset to reassemble the fragmented datagrams.
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 16
IP Header Fields continued
Fragment Offset (13 bits) This field specifies how many units from the
start of the original datagram the current datagram is. In other words, the first fragment datagram would have a value of 0 for the offset; if the second datagram starts 100 units from the beginning of the original datagram, the offset would be 100. the unit size is eight bytes (instead of one byte) since the field is only 13 bits wide.
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 17
IP Header Fields continued
Time to Live (8 bits) This field indicated how long the datagram
should be allowed to exist after entering the internetwork, measuring in seconds (maximum TTL is 255). Presently as datagrams traverse a router, this number is decremented by one.This informally represents the maximum
number of hops that a datagram can make before being discarded.
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 18
IP Header Fields continued
Protocol (8 bits) This field identifies the next higher layer
protocol of the data being carried in the datagram.
01 hex ICMP
06 hex TCP
11 hex UDPhttp://www.ietf.org/rfc/rfc1700.txt?number=1700 lists the different
protocols and their identifier numbers
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 19
IP Header Fields continued
Header Checksum (16 bits) This field provides error checking on the IP
header only, and does not cover the data that is carried at the end of the header. If the header is extended using the options field, then the checksum includes the extended header field too.
If the target IP-addressed interface receives a datagram with a failed checksum, the entire datagram is silently discarded.
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 20
IP Header Fields continued
Source IP Address (32 bits) The sender’s interface’s 32-bit Internet
address is identified in four bytes/octets. e.g. C0 99 B8 01 Four pair of Hex characters 192.153.184.1
Find the decimal equivalent of the following IP address represented in Hex
0F 10 07 11 ---.---.---.--- ??
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 21
IP Header Fields continued
Destination IP Address (32 bits) The target’s host’s 32-bit Internet address is
identified in four bytes/octets. e.g. C0 99 B8 03 Four pair of Hex characters 192.153.184.3
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 22
Connectionless Transport with User Datagram Protocol (UDP) Connectionless
protocols have the ability to transmit messages without first establishing a circuit.
The network does not need to do anything except transmit packets to the destination
All error checking and flow control is handled by the sending and receiving applications
` `
Data
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 23
Advantages and disadvantages of UDP
Speed UDP offers speed as it carries short messages between
hosts on the same network Can be used in events where a single packet of data
needs to be exchanged between hosts Reliability
In UDP the data is transmitted “blindly” as opposed to sending the data and waiting for an acknowledgement. This may result in data loss
Only application layer deals with error recoveryApplications can simply turn to the user to send the
message again! Optional checksum
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 24
UDP Header
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Octet 1 Octet 2 Octet 3 Octet 4
Source Port Destination Port
UDP Length UDP Checksum (optional)
1st 32 bit word
2nd 32 bit word
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 25
UDP Header
The process layer uses TCP or UDP to pass information to the internetwork layer. It is necessary to identify the client or server tasks uniquely so that the information is passed to the proper service or user task. The identification used in the TCP/IP protocol is called the “Port Number”.
UDP and TCP identify server tasks by using a port number that is consistent and well known. To access a service such as DNS (Domain Name Server), the software knows that DNS is waiting for sessions to be established at port 53.
Client tasks are identified by using port numbers that are variable and temporary, called random port numbers. The client random port numbers exist during the communication process and are discarded when the communication process is complete.
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 26
UDP Headers
Port 53
Port 69 Port
161
Port 8193
Random Ports
Server
ClientClient computer creates random ports as needed
Port 53 = Domain Name Server (DNS)
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 27
UDP Headers
Port 53
Port 69 Port
161
Port 8193
Random Ports
Server Client
Port 53 = Domain Name Server (DNS)
IP Address: 192.136.118.30 Port: 53
IP Address: 192.153.118.30 Port: 8193
The term sockets refers to both an API (application program interface) between hos systems and the TCP/IP applications, and a pairing of the IP address and the port number being used. It is also considered the complete network address of an end of the UDP session.
In the language of UDP, the sockets in the figure are 192.136.118.30,53 and 192.153.118.30,8193
This indicates the client is asking for DNS service
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 28
Assignment 1, Phase 1. Write a program that generates 4 IP packets at a time with
different IP source and destination addresses. Use TCP as the client signal of the 2 of IP packets and UDP as
the client signal of the other two IP packets Use http://www.ietf.org/rfc/rfc1700.txt?number=1700 to get the
protocol numbers for the TCP and UDP. In your program use Hex values for the protocol numbers and not the decimal values.
Use any pattern of your choice (could be random) that populates the payload port of the IP packet, i.e. in our context, data after the TCP or UDP headers. Keep in mind that payload is part of the UDP or TCP
datagram and should be accounted for in their respective headers (Hint: length).
(Defer the calculation of the checksum till we cover it, for now just put some value as a place holder)
New York Institute of Technology
Engineering and Computer Sciences
Kazi Fall 2007 CSCI 370/EENG 480 29
Assignment 1, Phase 1.
Become familiar with reading of RFCs www.ietf.org
click on RFC Pages Enter the RFC number and click on go.
Read/browse through RFCs 791, 1180, 760, 349, 1700 and write a very short summary of what is being standardized in the RFCs. (no more than couple of paragraphs per RFC)